用UML構(gòu)件進(jìn)行面向構(gòu)件分析與設(shè)計

本文提出了如何使用UML構(gòu)件和用例分析技術(shù)進(jìn)行面向構(gòu)件的分析與設(shè)計。在一些大型的項目開發(fā)環(huán)境中，由于各開發(fā)設(shè)計人員的經(jīng)驗不一，采用通用的標(biāo)準(zhǔn)的方法來進(jìn)行需求分析、功能分解，能夠使整個團(tuán)隊以及開發(fā)過程獲益。

　　以下以某業(yè)務(wù)流程為例，概要介紹如何使用本方法，進(jìn)行分析，以及如何分解得到EOS構(gòu)件。詳細(xì)的用例分析技術(shù)、分析模型技術(shù)由下文進(jìn)行闡述。

　　本文附帶一個UML構(gòu)件分析的樣例模型，以供參考。(在Rose中導(dǎo)出來的，html版本，用IE可以直接瀏覽)。

　　1用例分析

　　用例方法首先描述了系統(tǒng)有哪些外部參與者（抽象成為Actor），這些參與者與系統(tǒng)發(fā)生交互；針對每一參與者，用例方法又描述了系統(tǒng)為這些參與者提供了什么樣的服務(wù)（抽象成為UseCase），或者說系統(tǒng)是如何被這些參與者使用的。所以從用例圖中，我們可以得到對于系統(tǒng)的一個總體功能的集合。

　　與傳統(tǒng)的功能分解方式相比，用例方法完全是從外部來定義系統(tǒng)的功能，它把需求與設(shè)計完全分離開來。用例定義了系統(tǒng)功能的使用環(huán)境與上下文，每一個用例描述的是一個完整的系統(tǒng)服務(wù)。用例方法比傳統(tǒng)的功能分解方法更易于被用戶所理解，它可以作為開發(fā)人員和用戶之間針對系統(tǒng)需求進(jìn)行溝通的一個有效手段。

　　1.1尋找參與者(Actor)

　　用UML構(gòu)件進(jìn)行面向構(gòu)件分析與設(shè)計時參與者是指所有存在于系統(tǒng)外部并與系統(tǒng)進(jìn)行交互的人或其他系統(tǒng)。通俗地講，參與者就是我們所要定義系統(tǒng)的使用者。尋找參與者可以從以下問題入手：

　　誰使用系統(tǒng)的主要功能？

　　誰負(fù)責(zé)處理流程中的環(huán)節(jié)？

　　誰從系統(tǒng)獲取信息？

　　誰負(fù)責(zé)維護(hù)、管理并保持系統(tǒng)正常運行？

　　系統(tǒng)需要和哪些外部系統(tǒng)交互？

　　有時候我們需要在系統(tǒng)內(nèi)部定時地執(zhí)行一些操作，如當(dāng)任務(wù)到達(dá)時自動發(fā)送通知短信、當(dāng)任務(wù)超出處理時限自動發(fā)送催辦通知、定期地生成統(tǒng)計報表等等。從表面上看，這些操作并不是由外部的人或系統(tǒng)觸發(fā)的，應(yīng)該怎樣用用例方法來表述這一類功能需求呢？對于這種情況，我們可以抽象出一個系統(tǒng)時鐘或定時器參與者，利用該參與者來觸發(fā)這一類定時操作。

　　以派發(fā)故障單環(huán)節(jié)為例，故障派單人負(fù)責(zé)使用派單功能，因此需要派單人這個參與者。經(jīng)過對某流程各環(huán)節(jié)的分析，我們識別出以下參與者：

　　1.2尋找用例(UseCase)

　　用UML構(gòu)件進(jìn)行面向構(gòu)件分析與設(shè)計時找到參與者之后，我們可以根據(jù)參與者來確定系統(tǒng)的用例。主要是看各參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說參與者是如何使用系統(tǒng)的。尋找用例可以從以下問題入手（針對每一個參與者）：

　　參與者是否在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲數(shù)據(jù)？

　　參與者如何驅(qū)動流程的流轉(zhuǎn)，對流程中的環(huán)節(jié)進(jìn)行了哪些操作？

　　參與者是否會將外部的某些事件通知給該系統(tǒng)？

　　系統(tǒng)是否會將內(nèi)部的某些事件通知該參與者？

　　在用例的抽取過程中，必須注意：用例必須是由某一個參與者觸發(fā)而產(chǎn)生的活動，即每個用例至少應(yīng)該涉及一個參與者。如果存在與參與者不進(jìn)行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對應(yīng)的參與者是否被遺漏。反之，每個參與者也必須至少涉及到一個用例，如果發(fā)現(xiàn)有不與任何用例相關(guān)聯(lián)的參與者存在，那么該參與者可能是一個多余的模型元素，應(yīng)該將其刪除。

　　在用例建模過程中必須注意參與者和用例的名稱應(yīng)該符合一定的命名約定，如參與者的名稱一般都是名詞，用例名稱一般都是動賓詞組等。

　　用例分析就是分析什么人做什么事，描述做事要描述詳細(xì)到什么程度呢？這就是粒度問題。一個用例的粒度是否合適，是以該用例是否完成了參與者的某個目的為依據(jù)的。舉個例子，某人去圖書館，查詢了書目，出示了借書證，圖書管理員查詢了該人以前借閱記錄以確保沒有未歸還的書，最后借到了書。從這段話中能得出多少用例呢？用例分析是以參與者為中心的，因此用例的粒度以能完成參與者目的為依據(jù)。這樣，實際上適合用例是：借書。只有一個，其它都只是完成這個目的過程?，F(xiàn)實情況中，一個大型系統(tǒng)和一個很小的系統(tǒng)用例粒度選擇會有一些差異。這種差異是為了適應(yīng)不同的需求范圍。一般來說，一個系統(tǒng)的業(yè)務(wù)用例定義在多于10個，少于50個之間，否則就應(yīng)該考慮一下粒度選擇是否合適了。

　　對于同一個系統(tǒng)，不同的人對于參與者和用例都可能有不同的抽象結(jié)果，因而得到不同的用例模型。我們需要在多個用例模型方案中選擇一種"最佳"（或"較佳"）的結(jié)果，一個好的用例模型應(yīng)該能夠容易被不同的涉眾所理解，并且不同的涉眾對于同一用例模型的理解應(yīng)該是一致的。

　　以派發(fā)故障單環(huán)節(jié)為例，參與者“故障派單人”需使用派單功能，來完成對故障工單派發(fā)的目的，因此形成派發(fā)故障單這個用例。

　　經(jīng)過對某流程各個環(huán)節(jié)的分析，我們抽取出以下用例：

　　以上的用例模型，除了從流程環(huán)節(jié)功能分析得到的用例外，還有一部分是從通用功能角度分析而來的，如：查看日志，查看流程圖等等。

　　1.3用例分析與功能分解矩陣

　　用UML構(gòu)件進(jìn)行面向構(gòu)件分析與設(shè)計過程中經(jīng)過以上分析獲得的用例模型，一方面是用標(biāo)準(zhǔn)的需求分析方法對流程環(huán)節(jié)的功能進(jìn)行了描述，另一方面也為我們進(jìn)行下一步驟的功能分解打下了扎實的基礎(chǔ)。

　　在建設(shè)用例模型的過程中，我們以流程名稱建立一級包名，以環(huán)節(jié)名稱建立二級包名，如下圖所示：

　　在將用例模型映射到功能跟蹤矩陣的過程中，一般的規(guī)則是：一級包名映射到一級模塊，二級包名映射到二級模塊，用例名稱映射到三級模塊。以用例模型為基礎(chǔ)，我們將用例包名和用例名稱映射到功能跟蹤矩陣中，得到如下的功能跟蹤矩陣：

 請關(guān)注下節(jié)用UML構(gòu)件進(jìn)行面向構(gòu)件分析與設(shè)計介紹。

【編輯推薦】

1. 實例解析軟件設(shè)計中面向?qū)ο骍ML技術(shù)的應(yīng)用
2. UML動態(tài)建模機制專家解析
3. UML學(xué)習(xí)入門手冊
4. UML建模過程中需要注意要點專家提醒
5. 體驗免費UML建模工具