用UML構件進行面向構件分析與設計
用UML構件進行面向構件分析與設計
本文提出了如何使用UML構件和用例分析技術進行面向構件的分析與設計。在一些大型的項目開發環境中，由于各開發設計人員的經驗不一，采用通用的標準的方法來進行需求分析、功能分解，能夠使整個團隊以及開發過程獲益。
以下以某業務流程為例，概要介紹如何使用本方法，進行分析，以及如何分解得到EOS構件。詳細的用例分析技術、分析模型技術由下文進行闡述。
本文附帶一個UML構件分析的樣例模型，以供參考。(在Rose中導出來的，html版本，用IE可以直接瀏覽)。
1用例分析
用例方法首先描述了系統有哪些外部參與者（抽象成為Actor），這些參與者與系統發生交互；針對每一參與者，用例方法又描述了系統為這些參與者提供了什么樣的服務（抽象成為UseCase），或者說系統是如何被這些參與者使用的。所以從用例圖中，我們可以得到對于系統的一個總體功能的集合。
與傳統的功能分解方式相比，用例方法完全是從外部來定義系統的功能，它把需求與設計完全分離開來。用例定義了系統功能的使用環境與上下文，每一個用例描述的是一個完整的系統服務。用例方法比傳統的功能分解方法更易于被用戶所理解，它可以作為開發人員和用戶之間針對系統需求進行溝通的一個有效手段。
1.1尋找參與者(Actor)
用UML構件進行面向構件分析與設計時參與者是指所有存在于系統外部并與系統進行交互的人或其他系統。通俗地講，參與者就是我們所要定義系統的使用者。尋找參與者可以從以下問題入手：
誰使用系統的主要功能？
誰負責處理流程中的環節？
誰從系統獲取信息？
誰負責維護、管理并保持系統正常運行？
系統需要和哪些外部系統交互？
有時候我們需要在系統內部定時地執行一些操作，如當任務到達時自動發送通知短信、當任務超出處理時限自動發送催辦通知、定期地生成統計報表等等。從表面上看，這些操作并不是由外部的人或系統觸發的，應該怎樣用用例方法來表述這一類功能需求呢？對于這種情況，我們可以抽象出一個系統時鐘或定時器參與者，利用該參與者來觸發這一類定時操作。
以派發故障單環節為例，故障派單人負責使用派單功能，因此需要派單人這個參與者。經過對某流程各環節的分析，我們識別出以下參與者：
1.2尋找用例(UseCase)
用UML構件進行面向構件分析與設計時找到參與者之后，我們可以根據參與者來確定系統的用例。主要是看各參與者需要系統提供什么樣的服務，或者說參與者是如何使用系統的。尋找用例可以從以下問題入手（針對每一個參與者）：
參與者是否在系統中創建、修改、刪除、訪問、存儲數據？
參與者如何驅動流程的流轉，對流程中的環節進行了哪些操作？
參與者是否會將外部的某些事件通知給該系統？
系統是否會將內部的某些事件通知該參與者？
在用例的抽取過程中，必須注意：用例必須是由某一個參與者觸發而產生的活動，即每個用例至少應該涉及一個參與者。如果存在與參與者不進行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對應的參與者是否被遺漏。反之，每個參與者也必須至少涉及到一個用例，如果發現有不與任何用例相關聯的參與者存在，那么該參與者可能是一個多余的模型元素，應該將其刪除。
在用例建模過程中必須注意參與者和用例的名稱應該符合一定的命名約定，如參與者的名稱一般都是名詞，用例名稱一般都是動賓詞組等。
用例分析就是分析什么人做什么事，描述做事要描述詳細到什么程度呢？這就是粒度問題。一個用例的粒度是否合適，是以該用例是否完成了參與者的某個目的為依據的。舉個例子，某人去圖書館，查詢了書目，出示了借書證，圖書管理員查詢了該人以前借閱記錄以確保沒有未歸還的書，最后借到了書。從這段話中能得出多少用例呢？用例分析是以參與者為中心的，因此用例的粒度以能完成參與者目的為依據。這樣，實際上適合用例是：借書。只有一個，其它都只是完成這個目的過程。現實情況中，一個大型系統和一個很小的系統用例粒度選擇會有一些差異。這種差異是為了適應不同的需求范圍。一般來說，一個系統的業務用例定義在多于10個，少于50個之間，否則就應該考慮一下粒度選擇是否合適了。
對于同一個系統，不同的人對于參與者和用例都可能有不同的抽象結果，因而得到不同的用例模型。我們需要在多個用例模型方案中選擇一種"最佳"（或"較佳"）的結果，一個好的用例模型應該能夠容易被不同的涉眾所理解，并且不同的涉眾對于同一用例模型的理解應該是一致的。
以派發故障單環節為例，參與者“故障派單人”需使用派單功能，來完成對故障工單派發的目的，因此形成派發故障單這個用例。
經過對某流程各個環節的分析，我們抽取出以下用例：
以上的用例模型，除了從流程環節功能分析得到的用例外，還有一部分是從通用功能角度分析而來的，如：查看日志，查看流程圖等等。
1.3用例分析與功能分解矩陣
用UML構件進行面向構件分析與設計過程中經過以上分析獲得的用例模型，一方面是用標準的需求分析方法對流程環節的功能進行了描述，另一方面也為我們進行下一步驟的功能分解打下了扎實的基礎。
在建設用例模型的過程中，我們以流程名稱建立一級包名，以環節名稱建立二級包名，如下圖所示：
在將用例模型映射到功能跟蹤矩陣的過程中，一般的規則是：一級包名映射到一級模塊，二級包名映射到二級模塊，用例名稱映射到三級模塊。以用例模型為基礎，我們將用例包名和用例名稱映射到功能跟蹤矩陣中，得到如下的功能跟蹤矩陣：
請關注下節用UML構件進行面向構件分析與設計介紹。
【編輯推薦】
- 實例解析軟件設計中面向對象UML技術的應用
- UML動態建模機制專家解析
- UML學習入門手冊
- UML建模過程中需要注意要點專家提醒
- 體驗免費UML建模工具
