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

UML構件面向分析與設計

      1.分析模型

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

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

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

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

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

　　1.1尋找分析類

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

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

　　控制類用于對一個或幾個用例所特有的控制行為進行建模?？刂茖ο螅刂祁惖膶嵗┩ǔ？刂破渌麑ο?，因此它們的行為具有協(xié)調性質。

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

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

　　1.2用例實現(xiàn)

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

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

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

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

　　1.3分析模型與EOS構件

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

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

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

　　UML構件包分包原則：

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

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

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

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

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

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

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

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

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

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

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

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

　　這樣我們經過用例分析，和用例實現(xiàn)分析，逐步細化的得到了系統(tǒng)功能跟蹤矩陣。

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

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

【編輯推薦】

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