UML需求分析步驟實例解析
本節(jié)向大家介紹一下UML需求分析的一般步驟，本節(jié)用實例向大家介紹，相信通過本節(jié)的介紹你對UML需求分析有一定的認識。下面讓我們一起來學習具體介紹吧。
基于UML需求分析
在初步的業(yè)務需求描述已經形成的前提下，基于UML需求分析大致可分為以下步驟：
?。?）利用用例及用例圖表示需求。從業(yè)務需求描述出發(fā)獲取執(zhí)行者和場景；對場景進行匯總、分類、抽象；形成用例；確定執(zhí)行者與用例、用例與用例圖之間的關系，生成用例圖。
?。?）利用包圖及類圖表示目標軟件系統的總體框架結構。根據領域知識、業(yè)務需求描述和既往經驗設計目標軟件系統的頂層架構；從業(yè)務需求描述中提取“關鍵概念”，形成領域概念模型；從概念模型和用例出發(fā)，研究系統中主要的類之間的關系，生成類圖。
上述兩個步驟并沒有時序關系，它們可以并行展開，如圖5-3-1所示。
圖5-3-1 UML需求分析過程
本節(jié)將依次介紹上述步驟中涉及的UML語言機制，并結合“家庭保安系統”實例說明每步驟中基于UML需求分析方法。
開發(fā)場景
場景是指從單個執(zhí)行者的角度觀察目標軟件系統的功能和外部行為。這種功能通過系統與用戶之間的交互來表征。因此也可以說，場景是用戶與系統之間進行交互的一組具體的動作。相對于用例而言，場景是用例的實例，而用例是某類場景的共同抽象。
對場景的完整描述應包含場景名稱、執(zhí)行者實例，前置條件、事件流和后置條件。
例如，“家庭保安系統”的初步需求描述：“家庭保安系統”的軟件允許用戶在安裝時進行系統配置，實施對傳感器的監(jiān)控并通過控制面板與用戶進行信息交互。
配置操作包括：
?。?）指定每一傳感器的種類和編號；
?。?）設置開、關機密碼；
?。?）指定報警電話電碼；
?。?）指定報警延遲和電話重撥延遲時間（以秒為單位）；
當軟件系統收到傳感器發(fā)出的數據后，判別是否出現異常事件。如果是，則在指定的延遲時間內撥報警電話號碼，撥號操作將按照重撥延遲反復進行，直至電話接通。然后軟件系統負責報告時間、地點和異常事件的性質。
開機后，軟件系統負責顯示當前工作狀態(tài)，接收并處理用戶指令。
根據以上描述，該系統具有“系統配置”、“開機”、“關機”、“門窗監(jiān)測”、“煙霧監(jiān)測”和“復位”等場景。其中，門窗監(jiān)測場景的具體描述如下：
場景名稱：門窗監(jiān)測。
參與執(zhí)行者實例：警報器、報警電話、顯示器和門窗監(jiān)視器。
前置條件：系統已開機。
事件流：
（1）門窗監(jiān)視器發(fā)現門或窗戶發(fā)生異動，向軟件系統報告異常事件。
?。?）軟件系統啟動警報器并撥報警電話號碼。
（3）報警電話接通后，軟件系統播出語音，報告異常事件發(fā)生的時間、地點和事件的性質（門窗異動）。
?。?）系統在控制面板的顯示器上顯示報警時間及當前狀態(tài)（報警：門窗異動）。
后置條件：系統處于“報警”狀態(tài)。
UML需求分析過程中根據場景作用的不同，可以將其劃分為以下類型：
（1）實際場景。對實際的業(yè)務處理流程或其優(yōu)化流程的描述。實際場景是用戶需求的重要組成部分。
（2）設想場景。分析人員對目標軟件系統投入應用后經改進或優(yōu)化的業(yè)務流程的描述。這種場景可視為一種紙面原型，主要用于幫助分析人員挖掘潛在的用戶需求。
（3）評價場景。以確認需求或提出改進建議為主要目的的業(yè)務流程描述。評價場景可以在用例生成后用例進行實例化而形成，以便用戶對用例進行評價或改進。
?。?）培訓場景。面向開發(fā)人員及用戶解釋系統的功能和外部行為的業(yè)務流程描述。
對以下問題的回答有助于分析人員進行UML需求分析獲取場景：
?。?）目標軟件系統有哪些執(zhí)行者？
?。?）執(zhí)行者希望系統執(zhí)行哪些任務？
?。?）執(zhí)行者希望獲得哪些信息？這些信息由誰生成？由誰修改？
?。?）執(zhí)行者需要通知系統哪些事件？系統響應這些事件時會表現出哪些外部行為？
?。?）系統將通告執(zhí)行者哪些事件？
總之，確定執(zhí)行者和場景的關鍵在于理解業(yè)務領域和初步需求描述文檔。場景將促成開發(fā)人員和用戶對業(yè)務處理流程和目標軟件系統的功能范圍的共同理解。在場景確定之后，通過對場景的匯總、分類歸并和抽象即可形成用例。本節(jié)關于UML需求分析相關內容介紹到這里。
【編輯推薦】
