基于統一建模語言的軟件需求分析應用研究

鄒楠，厲志成

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

關鍵詞：統一建模語言；軟件需求；需求分析

中圖分類號：TP311? ? ? ? 文獻標識碼：A

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

1 概述

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

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

因此，需要研究應用一種新的需求分析方法，促進業務人員與軟件開發人員之間一致且高效地交流，幫助開發人員深入理解用戶需求，從而實現系統設計的可讀性、可理解性和通用性。

2 傳統結構化需求分析

傳統需求分析主要以結構化分析方法為主，是面向過程的以功能為驅動的分析方法。其主要是根據用戶需求，確定大致業務框架以及系統的功能范圍，采用非開發人員也易于理解的圖形符號結合文字等形式來描述每個功能的處理邏輯和業務規則，并適當輔助一些功能分解圖和數據流圖等[4]。

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

3 統一建模語言

與傳統結構化方法不同，面向對象的需求分析方法注重于現實問題的底層邏輯，將實際問題抽象化以此來解決問題，其從類與對象的關系上出發，具備更強的通用性，可以有效支持變動的業務需求。同時，面向對象的需求分析全流程是以對象作為分析與設計的目標，在最終編碼中也都是對象，可以有效保證從需求到分析、從分析到設計、從設計到編碼的一致性。

統一建模語言（Unified Modeling Language，UML）作為面向對象需求分析方法的建模工具，具有規則統一、易于表達、功能強大的優勢，適用于各類軟件系統的需求建模，從一般的信息管理系統到大型復雜工程系統都可以用UML來描述、構建需求分析模型[6]。

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

4 統一建模語言在軟件需求分析中的應用

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

4.1 用例建模

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

4.1.1 需求獲取

企業倉庫管理系統主要是解決如何合規化、精益化的管理企業庫存的問題。系統功能涵蓋出庫、入庫及庫存管理等，用戶涉及生產、銷售、倉儲、采購、財務等多個部門。通過對系統進行調研，將業務需求、痛點問題整理到調研表中，為接下來的UML建模分析做準備，如表2所示。

4.1.2 識別參與者

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

4.1.3 識別用例

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

將獲取到的需求進行總結提煉、分類，通過參與者與系統交互需求說明，明確業務活動，進而識別業務用例，如表4所示。

4.1.4 繪制用例圖

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

4.2 用例分析

在用例建模階段，得到初步的需求模型。接下來的用例分析階段則需要采用另一種建模方案對用例進行精確化的描述，將以用戶視角描述的需求模型轉換為以開發團隊視角描述的分析模型，從而保證設計開發的準確性[9]。

4.2.1 識別分析類

在對象系統中，系統的所有功能都是通過相應的類來實現。因此，首先需要從用例模型中抽象出這些可用的類，再將系統行為分配到這些類中。

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

4.2.2 分析交互

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

至此，已經建立了一套需求分析模型，系統用例及用例實現的相關交互分析以可視化的表達形式記錄在模型里。接下來，需求分析人員需要基于系統用戶目標、范圍和需求模型，完成用例的細化描述，并在此基礎上，結合非功能性需求、約束條件以及外部關聯接口等完成需求文檔的編寫。最后還需要評審審查，從而確保在開始架構設計時需求是完整的、一致的，規避后期開發風險。

5 結論

需求分析是整個軟件項目開發的關鍵環節，不同的分析方法各有側重，業務人員需要根據所開發的項目特點找到適合的分析方法。本文以某企業倉庫管理系統為例，詳細闡述了基于統一建模語言的軟件需求分析方法的應用過程。通過該分析方法，能夠有效地保證需求開發的質量，產出符合規范性和完整性要求的需求，大大提高溝通效率，并減少需求變更帶來的麻煩。

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

參考文獻：

[1] Maciaszek L A.需求分析與系統設計[M]. 馬素霞，王素琴，謝萍，等譯.北京：機械工業出版社，2009.

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

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

[4] 黃藍會.基于UML進行軟件需求分析的研究[J].微型電腦應用，2016，32（7）：9-11.

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

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

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

[8] 趙會盼.一種基于UML的面向對象的軟件需求分析方法[J].電子技術與軟件工程，2021（9）：63-65.

[9] 譚火彬.UML 2面向對象分析與設計[M].2版.北京：清華大學出版社，2019.

【通聯編輯：唐一東】