UML構(gòu)件面向分析與設(shè)計(jì)
本節(jié)繼續(xù)和大家學(xué)習(xí)UML構(gòu)件方面的知識，本節(jié)提出了如何使用UML和用例分析技術(shù)進(jìn)行面向構(gòu)件的分析與設(shè)計(jì)。在一些大型的項(xiàng)目開發(fā)環(huán)境中，由于各開發(fā)設(shè)計(jì)人員的經(jīng)驗(yàn)不一，采用通用的標(biāo)準(zhǔn)的方法來進(jìn)行需求分析、功能分解，能夠使整個(gè)團(tuán)隊(duì)以及開發(fā)過程獲益。
UML構(gòu)件面向分析與設(shè)計(jì)
1.分析模型
首先看一下UML構(gòu)件面向分析與設(shè)計(jì)，我們是通過對用例的分析，從而形成分析模型(AnalysisModel)來完成分解的工作的。
分析模型采用MVC模式，在系統(tǒng)架構(gòu)和框架的約束下，來分析用例的實(shí)現(xiàn)的。在分析過程中，將使用UML的語言來描述系統(tǒng)中的人、事、物、規(guī)則(actor，boundary，engity，control)之間的交互和動(dòng)作的。通過使用UML的時(shí)序圖將是將用例中所包含的業(yè)務(wù)處理流程表示出來，一方面能夠?qū)δ苓M(jìn)行粒度較細(xì)的分解，另一方面又能有效的指導(dǎo)設(shè)計(jì)與實(shí)現(xiàn)。
在分析工作中，有以下主要的產(chǎn)出：
分析類—業(yè)務(wù)領(lǐng)域中建模的主要概念，代表了系統(tǒng)設(shè)計(jì)中的類或子系統(tǒng)的抽象。分析類代表“系統(tǒng)中具備職責(zé)和行為的事物”的初期概念模型。這些概念模型最終將演進(jìn)為設(shè)計(jì)模型中的類和子系統(tǒng)。
用例實(shí)現(xiàn)—演示分析類的實(shí)例如何交互以實(shí)現(xiàn)由用例所說明的系統(tǒng)行為。用分析類及交互圖(協(xié)作圖、順序圖)來表示。
1.1尋找分析類
分析類的構(gòu)造型可分為以下幾種：邊界類(BoundryClass)、控制類(ControlClass)、實(shí)體類(EntityClass)。
邊界類是一種用于對系統(tǒng)外部環(huán)境與其內(nèi)部運(yùn)作之間的交互進(jìn)行建模的類。這種交互包括轉(zhuǎn)換事件，并記錄系統(tǒng)表示方式（例如接口）中的變更。
控制類用于對一個(gè)或幾個(gè)用例所特有的控制行為進(jìn)行建模?？刂茖ο螅刂祁惖膶?shí)例）通常控制其他對象，因此它們的行為具有協(xié)調(diào)性質(zhì)。
實(shí)體類是用于對必須存儲(chǔ)的信息和相關(guān)行為建模的類。實(shí)體對象（實(shí)體類的實(shí)例）用于保存和更新一些現(xiàn)象的有關(guān)信息，例如：事件、人員或者一些現(xiàn)實(shí)生活中的對象。
考慮參與者“故障派單人”執(zhí)行用例“派發(fā)故障單”這個(gè)場景。用MVC的模式對該用例進(jìn)行分析：故障派單人需要在某個(gè)界面上(邊界類)，錄入故障信息，然后提交給業(yè)務(wù)邏輯處理(控制類)；業(yè)務(wù)邏輯負(fù)責(zé)保存故障工單信息(實(shí)體類)。經(jīng)過對用例“派發(fā)故障單”的分析，我們得到以下的分析類：
1.2用例實(shí)現(xiàn)
UML構(gòu)件面向分析與設(shè)計(jì)中用例實(shí)現(xiàn)是描述如何在設(shè)計(jì)模型內(nèi)部利用協(xié)作對象來實(shí)現(xiàn)一個(gè)特定的用例。對于每個(gè)用例，都可以用一個(gè)或多個(gè)交互圖來描述它的參與對象以及它們之間的交互。多數(shù)情況下，我們使用序列圖來說明對象如何通過交互來執(zhí)行全部或部分用例的行為。
序列圖對設(shè)計(jì)人員特別重要，因?yàn)樗鼈兠鞔_了構(gòu)件在調(diào)用流程中的角色，因而可以為確定構(gòu)件的責(zé)任和接口提供基本的輸入。
通過對用例“派發(fā)故障單”的分析，我們繪制作了以下的順序圖：
可以看到，順序圖是以交互為主線，將交互過程中各交互對象識別出來，并由上至下、從左到右，以時(shí)間發(fā)送為序，將交互關(guān)系表示為一個(gè)二維圖的?？v向是時(shí)間軸，時(shí)間沿豎線向下延伸。橫向軸代表了在協(xié)作中各獨(dú)立交互對象。
1.3分析模型與EOS構(gòu)件
繪制出上面基本的順序圖之后，我們還需針對“派發(fā)故障單業(yè)務(wù)邏輯”進(jìn)行細(xì)化。將業(yè)務(wù)邏輯中的處理操作的步驟分析出來，將其中的操作分散在各構(gòu)件包中，并將構(gòu)件包調(diào)用關(guān)系在順序圖上描繪出來。
在這里我們先對構(gòu)件包的概念和分包的原則進(jìn)行闡述。
EOS構(gòu)件包是由六種構(gòu)件(業(yè)務(wù)構(gòu)件、展現(xiàn)構(gòu)件、頁面構(gòu)件、數(shù)據(jù)構(gòu)件、運(yùn)算構(gòu)件、工作流構(gòu)件)（或者其中的幾種）組成，是EOS系統(tǒng)發(fā)布、復(fù)用的基本單位，它由一組相關(guān)的EOS構(gòu)件組成，能夠完成相對獨(dú)立、完整的業(yè)務(wù)功能。EOS構(gòu)件包中可以包含一個(gè)或多個(gè)的EOS構(gòu)件，它相當(dāng)于一組有關(guān)系的構(gòu)件的容器或命名空間(Namespace)。
UML構(gòu)件包分包原則：
1.相關(guān)性：從應(yīng)用功能維度上，每個(gè)構(gòu)件包實(shí)現(xiàn)了一組具有相關(guān)性的業(yè)務(wù)功能。在劃分構(gòu)件包過程中，始終要考慮在構(gòu)件包中的構(gòu)件在業(yè)務(wù)上是否有相關(guān)性。如對工單(數(shù)據(jù)或流程)的一系列操作，從業(yè)務(wù)角度看，是具有高度的相關(guān)性，因此可以形成一個(gè)工單構(gòu)件包。
2.公共性：實(shí)際上構(gòu)件包可以理解為業(yè)務(wù)功能分解后的功能模塊。對業(yè)務(wù)功能分解之后，往往能抽取出一些具有公共性的操作，比如附件管理、記錄日志、查詢待辦工單等等。這些操作不直接與業(yè)務(wù)相關(guān)，但能提供給業(yè)務(wù)流程各個(gè)環(huán)節(jié)中復(fù)用。因此可以形成一個(gè)通用構(gòu)件包。
根據(jù)對某故障流程的分析，按照業(yè)務(wù)功能相關(guān)性的原則，我們將業(yè)務(wù)邏輯分為以下五大構(gòu)件包：
工單構(gòu)件包：提供與故障工單相關(guān)功能的一組構(gòu)件包，例如：設(shè)置工單狀態(tài)，獲取故障工單信息，獲取工單處理情況等等；
任務(wù)單構(gòu)件包：提供與任務(wù)單相關(guān)功能的一組構(gòu)件包，例如：設(shè)置任務(wù)單狀態(tài)，分派任務(wù)單，保存任務(wù)單等等；
通用構(gòu)件包:提供在其他構(gòu)件包調(diào)用到的通用功能的一組構(gòu)件包，例如：上傳附件，管理附件權(quán)限，發(fā)送短信，保存工單時(shí)限設(shè)置等等；
接口構(gòu)件包：提供與接口解析相關(guān)功能的一組構(gòu)件包，例如：自動(dòng)派單，半自動(dòng)派單，草稿生成工單，告警工單處理狀態(tài)實(shí)時(shí)通知等等；
統(tǒng)計(jì)構(gòu)件包:提供與KPI相關(guān)功能的一組構(gòu)件包，例如：統(tǒng)計(jì)故障處理及時(shí)率，統(tǒng)計(jì)故障一次處理完成率，統(tǒng)計(jì)故障一級解決率等等。
對于同一個(gè)系統(tǒng)，不同的人對于構(gòu)件包分包都可能有不同的拆分結(jié)果。我們需要在多種分包方案中選擇一種"***"（或"較佳"）的結(jié)果。一個(gè)好的分包方案應(yīng)該能夠容易被業(yè)務(wù)分析人員、系統(tǒng)設(shè)計(jì)人員及系統(tǒng)開發(fā)人員等所理解。
針對“派發(fā)故障單業(yè)務(wù)邏輯”，我們進(jìn)行再次分析，結(jié)合流程特點(diǎn)和業(yè)務(wù)功能，重新繪制新的順序圖，將派發(fā)過程中“工單構(gòu)件包”、“通用構(gòu)件包”等協(xié)作交互表達(dá)出來。首先，在請求派單階段，系統(tǒng)在顯示派單信息錄入界面，需要自動(dòng)匹配告警監(jiān)控網(wǎng)管信息和告警級別；其次，如果派單人在派單界面上進(jìn)行“抄送”操作，系統(tǒng)需要顯示抄送人員列表供其選擇；再次，如果派單人進(jìn)行“上傳附件”操作，系統(tǒng)需要提供附件上傳功能；***當(dāng)派單人選擇提交派單，系統(tǒng)將調(diào)用工單構(gòu)件包中的保存故障單信息功能構(gòu)件，在此保存故障單信息的過程中，還需調(diào)用通用構(gòu)件包中的獲取工單時(shí)限設(shè)置、獲取工單派單對象，完成保存后還需調(diào)用完成工作項(xiàng)、設(shè)置流程活動(dòng)的參與者、設(shè)置流程的流轉(zhuǎn)條件等。
如下圖所示，在派發(fā)故障單過程，我們經(jīng)過分析抽取出以下細(xì)粒度的功能：匹配告警監(jiān)控網(wǎng)管信息、映射網(wǎng)管告警級別、獲取抄送人員、上傳附件、保存故障單信息、獲取工單時(shí)限設(shè)置、獲取工單派單對象、完成工作項(xiàng)、設(shè)置流程活動(dòng)的參與者、設(shè)置流程的流轉(zhuǎn)條件。
根據(jù)“派發(fā)故障單”的用例實(shí)現(xiàn)順序圖，我們將順序圖上的操作功能映射到功能跟蹤矩陣。映射的一般原則是，由界面(派發(fā)故障單頁面)開始的操作功能映射為功能點(diǎn)，如“獲取抄送人員”，“上傳附件”等；由構(gòu)件包（工單構(gòu)件包、通用構(gòu)件包等）開始的操作映射為功能分解，如“獲取工單時(shí)限設(shè)置”、“獲取工單派單對象”。映射完成的功能跟蹤矩陣，如下圖所示：
這樣我們經(jīng)過用例分析，和用例實(shí)現(xiàn)分析，逐步細(xì)化的得到了系統(tǒng)功能跟蹤矩陣。
對所有的用例進(jìn)行分析，并繪制出順序圖之后，我們將獲得如下構(gòu)件包圖：
以上的UML構(gòu)件包圖，共有五個(gè)構(gòu)件包，每個(gè)構(gòu)件包中都包含若干個(gè)操作功能，每一個(gè)操作功能都可以映射成一個(gè)獨(dú)立的業(yè)務(wù)處理邏輯構(gòu)件。這些構(gòu)件涵括了某故障流程各環(huán)節(jié)中處理的功能。以該用例模型為基礎(chǔ)，能有利于我們形成功能分解矩陣，也能有利于我們識別可復(fù)用構(gòu)件。
【編輯推薦】
