基于統(tǒng)一建模語言的軟件需求分析應(yīng)用研究

鄒楠，厲志成

摘要：需求是軟件產(chǎn)品開發(fā)的重要輸入，好的需求分析可以有效規(guī)避后期開發(fā)風(fēng)險。軟件領(lǐng)域提出了許多需求分析方法，然而隨著軟件的規(guī)模和復(fù)雜程度與日俱增，傳統(tǒng)需求分析方法的局限性日益凸顯?；诮y(tǒng)一建模語言的軟件需求分析方法通過對現(xiàn)實(shí)問題做抽象映射，將需求以模型語言的方式進(jìn)行可視化表達(dá)，可以有效解決傳統(tǒng)需求分析方法中存在的不足，使開發(fā)人員可以很好地理解用戶需求，從而提升產(chǎn)品開發(fā)效率和質(zhì)量。

關(guān)鍵詞：統(tǒng)一建模語言；軟件需求；需求分析

中圖分類號：TP311? ? ? ? 文獻(xiàn)標(biāo)識碼：A

文章編號：1009-3044（2022）35-0022-03

1 概述

隨著軟件工程技術(shù)的不斷發(fā)展，軟件開發(fā)關(guān)注的重點(diǎn)已經(jīng)逐漸從后端的編碼向前端的需求分析轉(zhuǎn)移，需求分析的好壞對軟件成功與否至關(guān)重要[1]。據(jù)權(quán)威部門統(tǒng)計，目前軟件的成功率約為25%，75%的軟件是失敗的。在這75%的失敗中，約有50%以上的軟件是在需求分析階段存在問題[2]。

為了能夠有效地進(jìn)行分析和設(shè)計活動，需要相應(yīng)的技術(shù)和工具支持。軟件行業(yè)經(jīng)過多年的發(fā)展，目前有許多需求分析的方法，對于普通軟件而言，用戶需求相對簡單，傳統(tǒng)的分析方法可以應(yīng)對，然而對于大型復(fù)雜系統(tǒng)如ERP等，其規(guī)模和設(shè)計都比較復(fù)雜，傳統(tǒng)的需求分析方法已經(jīng)不能滿足要求，存在開發(fā)人員不能識別業(yè)務(wù)需求書、需求反復(fù)確認(rèn)等問題，影響開發(fā)效率[3]。

因此，需要研究應(yīng)用一種新的需求分析方法，促進(jìn)業(yè)務(wù)人員與軟件開發(fā)人員之間一致且高效地交流，幫助開發(fā)人員深入理解用戶需求，從而實(shí)現(xiàn)系統(tǒng)設(shè)計的可讀性、可理解性和通用性。

2 傳統(tǒng)結(jié)構(gòu)化需求分析

傳統(tǒng)需求分析主要以結(jié)構(gòu)化分析方法為主，是面向過程的以功能為驅(qū)動的分析方法。其主要是根據(jù)用戶需求，確定大致業(yè)務(wù)框架以及系統(tǒng)的功能范圍，采用非開發(fā)人員也易于理解的圖形符號結(jié)合文字等形式來描述每個功能的處理邏輯和業(yè)務(wù)規(guī)則，并適當(dāng)輔助一些功能分解圖和數(shù)據(jù)流圖等[4]。

這種分析方法適用于一些簡單場景，可以快速靈活地定義需求，但在復(fù)雜的業(yè)務(wù)場景下，其以功能為驅(qū)動的邏輯導(dǎo)致該方法對需求變化的適應(yīng)能力比較弱，尤其是在易變化的場景下，其面臨的問題較多，程序的可重用性和可維護(hù)性較低[5]。此外，開發(fā)人員可能無法準(zhǔn)確識別業(yè)務(wù)需求語言，在設(shè)計階段需要重新去做分析，導(dǎo)致開發(fā)效率低下。

3 統(tǒng)一建模語言

與傳統(tǒng)結(jié)構(gòu)化方法不同，面向?qū)ο蟮男枨蠓治龇椒ㄗ⒅赜诂F(xiàn)實(shí)問題的底層邏輯，將實(shí)際問題抽象化以此來解決問題，其從類與對象的關(guān)系上出發(fā)，具備更強(qiáng)的通用性，可以有效支持變動的業(yè)務(wù)需求。同時，面向?qū)ο蟮男枨蠓治鋈鞒淌且詫ο笞鳛榉治雠c設(shè)計的目標(biāo)，在最終編碼中也都是對象，可以有效保證從需求到分析、從分析到設(shè)計、從設(shè)計到編碼的一致性。

統(tǒng)一建模語言（Unified Modeling Language，UML）作為面向?qū)ο笮枨蠓治龇椒ǖ慕９ぞ?，具有?guī)則統(tǒng)一、易于表達(dá)、功能強(qiáng)大的優(yōu)勢，適用于各類軟件系統(tǒng)的需求建模，從一般的信息管理系統(tǒng)到大型復(fù)雜工程系統(tǒng)都可以用UML來描述、構(gòu)建需求分析模型[6]。

UML是一種可視化的建模語言而非程序設(shè)計語言，目的在于對系統(tǒng)進(jìn)行抽象化并構(gòu)建可視化分析模型，包括對象模型、動態(tài)模型以及功能模型，如表1所示。功能模型是從用戶的視角來描述系統(tǒng)的功能，最常用的是用例圖；對象模型用來分析識別系統(tǒng)的對象與類，以及它們之間的靜態(tài)關(guān)系，主要用到類圖和對象圖；動態(tài)模型用來展現(xiàn)系統(tǒng)的內(nèi)部行為、時序關(guān)系及狀態(tài)變化，包括活動圖、時序圖和狀態(tài)圖[7]。

4 統(tǒng)一建模語言在軟件需求分析中的應(yīng)用

軟件需求通常分為功能性需求和非功能性需求（如可靠性、可支持性等）。在這些需求中，功能性需求是需求定義的重點(diǎn)。本文以某企業(yè)倉庫管理系統(tǒng)為例，利用統(tǒng)一建模語言進(jìn)行功能性需求分析，分為用例建模和用例分析兩大階段。

4.1 用例建模

用例建模需要用到用例圖，用例圖為組織需求模型提供了有效手段，它通過將功能抽象為用例，進(jìn)而為系統(tǒng)構(gòu)建合適的用例模型。通過用例模型完成對需求的開發(fā)和管理，同時為后續(xù)用例分析提供輸入。本節(jié)詳細(xì)介紹構(gòu)建用例模型的四個步驟：獲取原始需求、識別參與者、識別用例、繪制用例圖。

4.1.1 需求獲取

企業(yè)倉庫管理系統(tǒng)主要是解決如何合規(guī)化、精益化的管理企業(yè)庫存的問題。系統(tǒng)功能涵蓋出庫、入庫及庫存管理等，用戶涉及生產(chǎn)、銷售、倉儲、采購、財務(wù)等多個部門。通過對系統(tǒng)進(jìn)行調(diào)研，將業(yè)務(wù)需求、痛點(diǎn)問題整理到調(diào)研表中，為接下來的UML建模分析做準(zhǔn)備，如表2所示。

4.1.2 識別參與者

參與者是指在系統(tǒng)之外，通過系統(tǒng)邊界與系統(tǒng)進(jìn)行交互的任何事物。識別模型中的參與者可以更好地去識別用例。對于倉庫管理系統(tǒng)而言，識別參與者過程如表3所示，參與者包括生產(chǎn)人員、銷售人員、倉庫管理員、采購人員、財務(wù)人員、系統(tǒng)管理員，如圖1所示。

4.1.3 識別用例

用例是參與者可以感受到的系統(tǒng)服務(wù)或功能單元，它從用戶的角度定義了系統(tǒng)要實(shí)現(xiàn)的一個目標(biāo)[8]。用例不是功能分解，一個用例可能需要多個功能來實(shí)現(xiàn)，一個功能也可能被用于多個用例，所以將系統(tǒng)需求表示成用例的過程并不等同于傳統(tǒng)方法中對系統(tǒng)進(jìn)行功能分解的過程。

將獲取到的需求進(jìn)行總結(jié)提煉、分類，通過參與者與系統(tǒng)交互需求說明，明確業(yè)務(wù)活動，進(jìn)而識別業(yè)務(wù)用例，如表4所示。

4.1.4 繪制用例圖

識別系統(tǒng)的參與者和用例后，就可以采用用例圖表示，如圖2所示。通過用例圖可以清晰地構(gòu)建需求模型。

4.2 用例分析

在用例建模階段，得到初步的需求模型。接下來的用例分析階段則需要采用另一種建模方案對用例進(jìn)行精確化的描述，將以用戶視角描述的需求模型轉(zhuǎn)換為以開發(fā)團(tuán)隊(duì)視角描述的分析模型，從而保證設(shè)計開發(fā)的準(zhǔn)確性[9]。

4.2.1 識別分析類

在對象系統(tǒng)中，系統(tǒng)的所有功能都是通過相應(yīng)的類來實(shí)現(xiàn)。因此，首先需要從用例模型中抽象出這些可用的類，再將系統(tǒng)行為分配到這些類中。

為了識別分析類，UML擴(kuò)展出三種不同的分析類：1）邊界類，比如UI界面；2）控制類，即控制業(yè)務(wù)流程的類，如銷售出庫業(yè)務(wù)類；3）實(shí)體類。即問題空間中的業(yè)務(wù)對象的集合，比如出庫信息類。由于邊界類和控制類比較容易確定，因此，對實(shí)體類的識別才是整個分析階段的重點(diǎn)。以出庫管理業(yè)務(wù)為例，抽象出的實(shí)體類包括系統(tǒng)用戶類、出庫信息類、貨品信息類、銷售信息類和生產(chǎn)信息類，通過確定類之間的關(guān)系創(chuàng)建實(shí)體類圖，如圖3所示。

4.2.2 分析交互

目前，所識別的類都是靜態(tài)的描述，而為了確認(rèn)所識別的類是否達(dá)成用例實(shí)現(xiàn)的目標(biāo)，必須分析由這些類所產(chǎn)生的對象的動態(tài)行為。利用UML時序圖來描述對象間的交互行為，可以表示用例實(shí)現(xiàn)是如何達(dá)成用例目標(biāo)[9]。以銷售出庫業(yè)務(wù)為例，其時序圖模型如圖4所示，開發(fā)人員通過時序圖可以清晰地理解業(yè)務(wù)間各個對象交互及消息傳遞的過程。

至此，已經(jīng)建立了一套需求分析模型，系統(tǒng)用例及用例實(shí)現(xiàn)的相關(guān)交互分析以可視化的表達(dá)形式記錄在模型里。接下來，需求分析人員需要基于系統(tǒng)用戶目標(biāo)、范圍和需求模型，完成用例的細(xì)化描述，并在此基礎(chǔ)上，結(jié)合非功能性需求、約束條件以及外部關(guān)聯(lián)接口等完成需求文檔的編寫。最后還需要評審審查，從而確保在開始架構(gòu)設(shè)計時需求是完整的、一致的，規(guī)避后期開發(fā)風(fēng)險。

5 結(jié)論

需求分析是整個軟件項(xiàng)目開發(fā)的關(guān)鍵環(huán)節(jié)，不同的分析方法各有側(cè)重，業(yè)務(wù)人員需要根據(jù)所開發(fā)的項(xiàng)目特點(diǎn)找到適合的分析方法。本文以某企業(yè)倉庫管理系統(tǒng)為例，詳細(xì)闡述了基于統(tǒng)一建模語言的軟件需求分析方法的應(yīng)用過程。通過該分析方法，能夠有效地保證需求開發(fā)的質(zhì)量，產(chǎn)出符合規(guī)范性和完整性要求的需求，大大提高溝通效率，并減少需求變更帶來的麻煩。

軟件開發(fā)實(shí)踐表明，在提高軟件工程質(zhì)量、降低軟件開發(fā)風(fēng)險、處理復(fù)雜功能需求、減少代碼開發(fā)工作量等諸多關(guān)鍵問題上，基于統(tǒng)一建模語言的需求分析方法是行之有效的。

參考文獻(xiàn)：

[1] Maciaszek L A.需求分析與系統(tǒng)設(shè)計[M]. 馬素霞，王素琴，謝萍，等譯.北京：機(jī)械工業(yè)出版社，2009.

[2] 吳政.軟件開發(fā)過程中的需求分析探討[J].電腦知識與技術(shù)，2008，4（32）：1125-1128.

[3] Wiegers K，Beatty J.軟件需求[M].3版. 李忠利，譯.北京：清華大學(xué)出版社，2016.

[4] 黃藍(lán)會.基于UML進(jìn)行軟件需求分析的研究[J].微型電腦應(yīng)用，2016，32（7）：9-11.

[5] 李鴻君.大話軟件工程需求分析與軟件設(shè)計[M].北京：清華大學(xué)出版社，2020.

[6] 田林琳，李鶴.UML軟件建模項(xiàng)目教學(xué)版[M].北京：北京理工大學(xué)出版社，2018.

[7] 袁濤，孔蕾蕾.統(tǒng)一建模語言UML[M].2版.北京：清華大學(xué)出版社，2014.

[8] 趙會盼.一種基于UML的面向?qū)ο蟮能浖枨蠓治龇椒╗J].電子技術(shù)與軟件工程，2021（9）：63-65.

[9] 譚火彬.UML 2面向?qū)ο蠓治雠c設(shè)計[M].2版.北京：清華大學(xué)出版社，2019.

【通聯(lián)編輯：唐一東】