論基於UML的需求分析

論基於UML的需求分析

摘要:

需求分析是系統開發人員經過細緻的調研和分析,準確理解用戶對系統的功能、非功能性、約束條件以及擴展接口的具體要求,將用戶非形式化的需求轉化爲完整的需求定義,從而確定系統必須做什麼。而UML可以使用各種靜態圖和動態圖很好的來將需求分析的結果以形象化的圖例展示給用戶和項目組成員,讓其可以很好的理解軟件的藍圖並作爲後續開發的指南。

本文通過我參與過的倉庫管理系統項目的需求分析過程,主要通過用例圖、類圖、活動圖、部署圖的建立過程來討論了基於UML技術的需求分析方法。經過採用各種UML的相關技術,使得我們很好的描繪並展示出系統的需求,有效的保證了需求工作的質量,並提高了用戶滿意度。最後,分析了實際工作中碰到的問題,並提出了相關改進方法。

正文:

2017年3月,我有幸參與了我所在某電子元器件集團公司其中一個分公司的ERP系統的設計和開發。公司的長遠戰略目標是在2021年之前完成所有6個據點的系統統一化,預計投資額爲6百萬,而該跟子公司就是作爲系統實現的第一站。整個系統包含,生產計劃模塊、銷售計劃、生產管理模塊、出貨管理模塊、倉庫管理模塊、財務管理模塊。

    公司也專門成立了專門項目組,包括項目辦公室,項目管理組和各個功能模塊小組,項目一開始我就做爲一個系統分析師的角色駐現場,帶領其中一個小組針對其中一個子模塊-倉庫管理系統進行前期的系統分析工作。而作爲第一個實施的據點,其中的風險性和重要性不言而喻。

    該項目具有較高的業務需求風險和技術風險,各個子公司都有各自一套獨立的運行系統,雖然系統老舊但是運行穩定,加上我們並沒有成熟系統作爲參照。

所以前期需求分析以及用戶的反應和支持將對總公司上層領導對我們團隊和整個戰略信心起很大的作用。整個系統被分爲了多個子模塊,所以各組負責人一起討論了在需求分析期間採用的策略、方法和工具。我們排除了傳統的面向結構的方法,因爲它存在一些侷限性,不能很好的滿足軟件的易複用性、易擴展性和可維護性,同時沒有很好的原型系統支持,用戶需求處於多變的狀態,所以不太適合。我們最終選擇了面向對象的方法,並且採用UML-統一建模語言,它使用了統一的表示法,呈現一致的業界都可以支持的風格,並配套了多種靜態圖和動態圖來展示需求。同時也支持了複用,可擴展性,並具備多種配套的case工具。我們就採用了一種優秀的開源工具StarUML作爲最終項目需求分析工具。並主要應用用例圖、類圖、活動圖、順序圖和部署圖5中圖例。

1.用例圖獲取和設計

用例圖主要描述一個個系統功能單元,描述參與者與系統一次交互作用,用例圖是展示系統需求給用戶最好的圖形模式。我們認爲用例圖獲取關鍵在於如何從用戶那裏儘可能的挖掘系統的功能性、非功能性、系統約束和接口信息等系統需求,並通過識別參與者、合併需求獲取用例、細化用例描述和調整用例模型完成用例圖模型的設計。

在識別參與者環節,考慮到歷史系統具備一定的穩定性和可操作性,因此現場領導和用戶對陌生系統和陌生人有一定的抗拒因素,而且不同層次的人對系統的理解和操作的細節把握不盡相同,所以我們首先通過現場調查,友好詢問方式總結出目前的業務邏輯和實際操作步驟,根據我們的所見所得,通過Viso工具繪製出初步的簡單的形象的用例模型,然後在通過聯合計劃會議方式組織相關的領導,IT技術人員、項目組,會議記錄,而我作爲會議主持,主導多次會議。我們通過對初步用例模型展示和講解,然後通過確認反覆跟用戶確認如下問題來不斷的識別參與者併爲下一步驟做準備。

1.這個活動誰是主要參與者?

2.這個活動需要系統提供服務嗎?

3.需要提供什麼服務?

4.系統需要其他系統提供什麼服務嗎?

我們通過這種方式逐步合併需求,建立初步用例模型,在初步需求收集完之後,識別出主要的參與者,由此我們基本明確了倉庫管理系統的主要目標和主要功能特性,並得出整個系統包含主要10個主要用例包,料架管理用例包,物料上架用例包,出貨單用例包,物流排載用例包,海關報關用例包,撿料單用例包,標籤打印用例包,包裝掃描用例包,出庫確認掃描用例包,庫存管理用例包。一共包含了60個具體用例.

在獲取初步用例模型後,還需要對用例進行細化,對用例進行合併或者分解,同時編寫用例規約,用例規約規定了系統需要完成的步驟,包含了前置條件、後置條件和事件流,前置條件表明用例執行前系統處於的狀態,後置條件是執行後系統應該處於的某種狀態,事件流描述了用例執行的步驟,與之配套的包含了基流、分支流、替代流,基流描述了用例執行的基本步驟,沒有分支和替代,分支流主要描述執行過程中根據不同的條件和不同選擇可能執行的步驟,替代流主要描述當出現故障時,執行的相關的替代步驟。我們爲每個用例設計了基流,主要步驟設置了替代流。

最後我們還逐步的完善用例的描述,我們通體採用“肯定句”方式細化用例說明,並組織編寫了能夠被領導、用戶和項目成員都能理解的《需求規格說明書》,通過評審後,作爲項目驗收的依據。

2.類圖的設計

用例圖可以描述系統需求的動態結構,但是對於需求特徵和用例中出現的概念,並沒有統一詳細的分析,對於用例中的抽象對象,我們設計類圖描述其屬性和操作,同時描述這些類之間的各種關係,包括泛化、關聯、擴展、實現等關係。

3.活動圖的設計

   活動圖主要是用來描述各用例的內部行爲,是用例圖的一個補充,包含併發和同步行爲,我們針對主要的10個用例給出了內部實現方式和順序執行規則,同時包含了相關部門和單位的聯動方式和執行步驟。

4.部署圖的設計

在設計部署圖時,我們主要針對各應用服務器、網絡、終端電腦、掃描設備、打印設備做了部署。考慮到與總公司最初總設計思路接軌,我們將主要的服務器部署在總公司,並由專門的服務器組進行監管。通過與網絡專員確認,採用快速的網絡專線鏈接主幹道,信息終端採用普通的網線連接。根據包裝線的安排和貨架的分配,定義了終端電腦、掃描設備和打印設備的定位。同時在部署圖中並給出了所有設備部署相關的標識和描述。

我們最終用了3個月時間完成了需求分析並完善了相關的《需求規格說明書》,在此期間各級領導給了我們莫大的支持,同時用戶無論是在調查過程和設計過程也給了我們很大的幫助,雖然在後續的系統開發過程中,隨着系統的完善,我們的需求也有一些細節上的變動,但是主體內容並沒有受到影響,所以整個需求分析工作是成功的。

通過此次系統需求分析經驗,我意識到強調配合和引導用戶爲主體進行需求分析的重要性,同時發掘具有強大功能的UML,結合專業的CASE工具StarUML可以很好的完成需求分析工作,併爲我以後的工作提供了很好的經驗基礎。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章