本節繼續和大家學習UML構件方面的知識，本節提出了如何使用UML和用例分析技術進行面向構件的分析與設計。在一些大型的項目開發環境中，由于各開發設計人員的經驗不一，采用通用的標準的方法來進行需求分析、功能分解，能夠使整個團隊以及開發過程獲益。

UML構件面向分析與設計

      1.分析模型

　　首先看一下UML構件面向分析與設計，我們是通過對用例的分析，從而形成分析模型(AnalysisModel)來完成分解的工作的。

　　分析模型采用MVC模式，在系統架構和框架的約束下，來分析用例的實現的。在分析過程中，將使用UML的語言來描述系統中的人、事、物、規則(actor，boundary，engity，control)之間的交互和動作的。通過使用UML的時序圖將是將用例中所包含的業務處理流程表示出來，一方面能夠對功能進行粒度較細的分解，另一方面又能有效的指導設計與實現。

　　在分析工作中，有以下主要的產出：

　　分析類—業務領域中建模的主要概念，代表了系統設計中的類或子系統的抽象。分析類代表“系統中具備職責和行為的事物”的初期概念模型。這些概念模型最終將演進為設計模型中的類和子系統。

　　用例實現—演示分析類的實例如何交互以實現由用例所說明的系統行為。用分析類及交互圖(協作圖、順序圖)來表示。

　　1.1尋找分析類

　　分析類的構造型可分為以下幾種：邊界類(BoundryClass)、控制類(ControlClass)、實體類(EntityClass)。

　　邊界類是一種用于對系統外部環境與其內部運作之間的交互進行建模的類。這種交互包括轉換事件，并記錄系統表示方式（例如接口）中的變更。

　　控制類用于對一個或幾個用例所特有的控制行為進行建模?？刂茖ο螅刂祁惖膶嵗┩ǔ？刂破渌麑ο螅虼怂鼈兊男袨榫哂袇f調性質。

　　實體類是用于對必須存儲的信息和相關行為建模的類。實體對象（實體類的實例）用于保存和更新一些現象的有關信息，例如：事件、人員或者一些現實生活中的對象。

　　考慮參與者“故障派單人”執行用例“派發故障單”這個場景。用MVC的模式對該用例進行分析：故障派單人需要在某個界面上(邊界類)，錄入故障信息，然后提交給業務邏輯處理(控制類)；業務邏輯負責保存故障工單信息(實體類)。經過對用例“派發故障單”的分析，我們得到以下的分析類：

　　1.2用例實現

　　UML構件面向分析與設計中用例實現是描述如何在設計模型內部利用協作對象來實現一個特定的用例。對于每個用例，都可以用一個或多個交互圖來描述它的參與對象以及它們之間的交互。多數情況下，我們使用序列圖來說明對象如何通過交互來執行全部或部分用例的行為。

　　序列圖對設計人員特別重要，因為它們明確了構件在調用流程中的角色，因而可以為確定構件的責任和接口提供基本的輸入。

　　通過對用例“派發故障單”的分析，我們繪制作了以下的順序圖：

　　可以看到，順序圖是以交互為主線，將交互過程中各交互對象識別出來，并由上至下、從左到右，以時間發送為序，將交互關系表示為一個二維圖的?？v向是時間軸，時間沿豎線向下延伸。橫向軸代表了在協作中各獨立交互對象。

　　1.3分析模型與EOS構件

　　繪制出上面基本的順序圖之后，我們還需針對“派發故障單業務邏輯”進行細化。將業務邏輯中的處理操作的步驟分析出來，將其中的操作分散在各構件包中，并將構件包調用關系在順序圖上描繪出來。

　　在這里我們先對構件包的概念和分包的原則進行闡述。

　　EOS構件包是由六種構件(業務構件、展現構件、頁面構件、數據構件、運算構件、工作流構件)（或者其中的幾種）組成，是EOS系統發布、復用的基本單位，它由一組相關的EOS構件組成，能夠完成相對獨立、完整的業務功能。EOS構件包中可以包含一個或多個的EOS構件，它相當于一組有關系的構件的容器或命名空間(Namespace)。

　　UML構件包分包原則：

　　1.相關性：從應用功能維度上，每個構件包實現了一組具有相關性的業務功能。在劃分構件包過程中，始終要考慮在構件包中的構件在業務上是否有相關性。如對工單(數據或流程)的一系列操作，從業務角度看，是具有高度的相關性，因此可以形成一個工單構件包。

　　2.公共性：實際上構件包可以理解為業務功能分解后的功能模塊。對業務功能分解之后，往往能抽取出一些具有公共性的操作，比如附件管理、記錄日志、查詢待辦工單等等。這些操作不直接與業務相關，但能提供給業務流程各個環節中復用。因此可以形成一個通用構件包。

　　根據對某故障流程的分析，按照業務功能相關性的原則，我們將業務邏輯分為以下五大構件包：

　　工單構件包：提供與故障工單相關功能的一組構件包，例如：設置工單狀態，獲取故障工單信息，獲取工單處理情況等等；

　　任務單構件包：提供與任務單相關功能的一組構件包，例如：設置任務單狀態，分派任務單，保存任務單等等；

　　通用構件包:提供在其他構件包調用到的通用功能的一組構件包，例如：上傳附件，管理附件權限，發送短信，保存工單時限設置等等；

　　接口構件包：提供與接口解析相關功能的一組構件包，例如：自動派單，半自動派單，草稿生成工單，告警工單處理狀態實時通知等等；

　　統計構件包:提供與KPI相關功能的一組構件包，例如：統計故障處理及時率，統計故障一次處理完成率，統計故障一級解決率等等。

　　對于同一個系統，不同的人對于構件包分包都可能有不同的拆分結果。我們需要在多種分包方案中選擇一種"***"（或"較佳"）的結果。一個好的分包方案應該能夠容易被業務分析人員、系統設計人員及系統開發人員等所理解。

　　針對“派發故障單業務邏輯”，我們進行再次分析，結合流程特點和業務功能，重新繪制新的順序圖，將派發過程中“工單構件包”、“通用構件包”等協作交互表達出來。首先，在請求派單階段，系統在顯示派單信息錄入界面，需要自動匹配告警監控網管信息和告警級別；其次，如果派單人在派單界面上進行“抄送”操作，系統需要顯示抄送人員列表供其選擇；再次，如果派單人進行“上傳附件”操作，系統需要提供附件上傳功能；***當派單人選擇提交派單，系統將調用工單構件包中的保存故障單信息功能構件，在此保存故障單信息的過程中，還需調用通用構件包中的獲取工單時限設置、獲取工單派單對象，完成保存后還需調用完成工作項、設置流程活動的參與者、設置流程的流轉條件等。

　　如下圖所示，在派發故障單過程，我們經過分析抽取出以下細粒度的功能：匹配告警監控網管信息、映射網管告警級別、獲取抄送人員、上傳附件、保存故障單信息、獲取工單時限設置、獲取工單派單對象、完成工作項、設置流程活動的參與者、設置流程的流轉條件。

　　根據“派發故障單”的用例實現順序圖，我們將順序圖上的操作功能映射到功能跟蹤矩陣。映射的一般原則是，由界面(派發故障單頁面)開始的操作功能映射為功能點，如“獲取抄送人員”，“上傳附件”等；由構件包（工單構件包、通用構件包等）開始的操作映射為功能分解，如“獲取工單時限設置”、“獲取工單派單對象”。映射完成的功能跟蹤矩陣，如下圖所示：

　　這樣我們經過用例分析，和用例實現分析，逐步細化的得到了系統功能跟蹤矩陣。

　　對所有的用例進行分析，并繪制出順序圖之后，我們將獲得如下構件包圖：

　　以上的UML構件包圖，共有五個構件包，每個構件包中都包含若干個操作功能，每一個操作功能都可以映射成一個獨立的業務處理邏輯構件。這些構件涵括了某故障流程各環節中處理的功能。以該用例模型為基礎，能有利于我們形成功能分解矩陣，也能有利于我們識別可復用構件。

【編輯推薦】

1. 用UML構件進行面向構件分析與設計
2. 實例解析軟件設計中面向對象UML技術的應用
3. UML動態建模中合作圖和活動圖解析
4. UML建模過程中需要注意要點專家提醒
5. 體驗免費UML建模工具