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

鄒楠，厲志成

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

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

中圖分類(lèi)號(hào)：TP311? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2022）35-0022-03

1 概述

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

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

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

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

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

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

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

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

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

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

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

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

4.1 用例建模

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

4.1.1 需求獲取

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

4.1.2 識(shí)別參與者

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

4.1.3 識(shí)別用例

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

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

4.1.4 繪制用例圖

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

4.2 用例分析

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

4.2.1 識(shí)別分析類(lèi)

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

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

4.2.2 分析交互

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

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

5 結(jié)論

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

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

參考文獻(xiàn)：

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

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

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

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

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

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

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

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

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

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