UML需求實例分析

這篇“UML需求實例分析”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“UML需求實例分析”文章吧。

基于UML需求分析

在初步的業務需求描述已經形成的前提下，基于UML需求分析大致可分為以下步驟：

（1）利用用例及用例圖表示需求。從業務需求描述出發獲取執行者和場景；對場景進行匯總、分類、抽象；形成用例；確定執行者與用例、用例與用例圖之間的關系，生成用例圖。

（2）利用包圖及類圖表示目標軟件系統的總體框架結構。根據領域知識、業務需求描述和既往經驗設計目標軟件系統的頂層架構；從業務需求描述中提取“關鍵概念”，形成領域概念模型；從概念模型和用例出發，研究系統中主要的類之間的關系，生成類圖。

上述兩個步驟并沒有時序關系，它們可以并行展開，如圖5-3-1所示。

圖5-3-1　UML需求分析過程

本節將依次介紹上述步驟中涉及的UML語言機制，并結合“家庭保安系統”實例說明每步驟中基于UML需求分析方法。

開發場景

場景是指從單個執行者的角度觀察目標軟件系統的功能和外部行為。這種功能通過系統與用戶之間的交互來表征。因此也可以說，場景是用戶與系統之間進行交互的一組具體的動作。相對于用例而言，場景是用例的實例，而用例是某類場景的共同抽象。

對場景的完整描述應包含場景名稱、執行者實例，前置條件、事件流和后置條件。

例如，“家庭保安系統”的初步需求描述：“家庭保安系統”的軟件允許用戶在安裝時進行系統配置，實施對傳感器的監控并通過控制面板與用戶進行信息交互。

配置操作包括：

（1）指定每一傳感器的種類和編號；

（2）設置開、關機密碼；

（3）指定報警電話電碼；

（4）指定報警延遲和電話重撥延遲時間（以秒為單位）；

當軟件系統收到傳感器發出的數據后，判別是否出現異常事件。如果是，則在指定的延遲時間內撥報警電話號碼，撥號操作將按照重撥延遲反復進行，直至電話接通。然后軟件系統負責報告時間、地點和異常事件的性質。

開機后，軟件系統負責顯示當前工作狀態，接收并處理用戶指令。

根據以上描述，該系統具有“系統配置”、“開機”、“關機”、“門窗監測”、“煙霧監測”和“復位”等場景。其中，門窗監測場景的具體描述如下：

場景名稱：門窗監測。

參與執行者實例：警報器、報警電話、顯示器和門窗監視器。

前置條件：系統已開機。

事件流：

（1）門窗監視器發現門或窗戶發生異動，向軟件系統報告異常事件。

（2）軟件系統啟動警報器并撥報警電話號碼。

（3）報警電話接通后，軟件系統播出語音，報告異常事件發生的時間、地點和事件的性質（門窗異動）。

（4）系統在控制面板的顯示器上顯示報警時間及當前狀態（報警：門窗異動）。

后置條件：系統處于“報警”狀態。

UML需求分析過程中根據場景作用的不同，可以將其劃分為以下類型：

（1）實際場景。對實際的業務處理流程或其優化流程的描述。實際場景是用戶需求的重要組成部分。

（2）設想場景。分析人員對目標軟件系統投入應用后經改進或優化的業務流程的描述。這種場景可視為一種紙面原型，主要用于幫助分析人員挖掘潛在的用戶需求。

（3）評價場景。以確認需求或提出改進建議為主要目的的業務流程描述。評價場景可以在用例生成后用例進行實例化而形成，以便用戶對用例進行評價或改進。

（4）培訓場景。面向開發人員及用戶解釋系統的功能和外部行為的業務流程描述。

對以下問題的回答有助于分析人員進行UML需求分析獲取場景：

（1）目標軟件系統有哪些執行者？

（2）執行者希望系統執行哪些任務？

（3）執行者希望獲得哪些信息？這些信息由誰生成？由誰修改？

（4）執行者需要通知系統哪些事件？系統響應這些事件時會表現出哪些外部行為？

（5）系統將通告執行者哪些事件？

總之，確定執行者和場景的關鍵在于理解業務領域和初步需求描述文檔。場景將促成開發人員和用戶對業務處理流程和目標軟件系統的功能范圍的共同理解。在場景確定之后，通過對場景的匯總、分類歸并和抽象即可形成用例。

以上就是關于“UML需求實例分析”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。