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

本文提出了如何使用UML構(gòu)件和用例分析技術(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ā)過程獲益。

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

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

　　1用例分析

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

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

　　1.1尋找參與者(Actor)

　　用UML構(gòu)件進(jìn)行面向構(gòu)件分析與設(shè)計(jì)時(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)正常運(yùn)行？

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

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

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

　　1.2尋找用例(UseCase)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【編輯推薦】

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