UML系統分析與設計SystemAnalysis&Design冀振燕北京交通大學

第六章用例圖用例圖參與者用例用例圖的應用UML系統分析與設計第2版ZhenyanJi2UML系統分析與設計第2版ZhenyanJi3用例圖用例模型描述的是系統外部的參與者所理解的系統功能。用例模型用于需求分析階段，它的建立是系統開發者和最終用戶反復討論的結果，也是開發者和用戶對需求規格定義達成的共識。用例圖用例模型描述了待開發系統的功能需求將系統看作黑盒，從外部參與者的角度來理解系統驅動了需求分析之后各階段的開發工作，用例不僅在開發過程中保證了系統所有功能的實現，還被用于驗證和檢測所開發的系統是否滿足系統需求，從而影響到開發工作的各個階段和UML的各個模型。UML系統分析與設計第2版ZhenyanJi4UML系統分析與設計第2版ZhenyanJi5用例圖用例圖的3種建模元素用例(Use

Case)參與者(Actor)依賴關系、類屬關系和關聯關系。用例圖描述了用例、參與者以及它們之間的關系。用例圖UML系統分析與設計第2版ZhenyanJi6UML系統分析與設計第2版ZhenyanJi7用例圖參與者和用例之間存在的關聯關系通常被稱為通信關聯，因為它代表著參與者和用例之間的通信。這個關聯可以是雙向導航（從參與者到用例，并從用例到參與者），也可以是單向導航（從參與者到用例，或從用例到參與者）。導航的方向表明了是參與者發起了和用例的通信，還是用例發起了和參與者的通信。UML系統分析與設計第2版ZhenyanJi8用例圖在UML中用來實現用例的元素是協作（Collaboration），協作是實現用例行為的類和其他元素的總稱。如圖所示，可以用協作“Dealwithbill”（處理賬單）來實現用例“Payforbill”（付賬單）。通常，每個給定的用例都會由一個相應的協作來實現，所以大多數情況下不必顯式地為這種關系建模。UML系統分析與設計第2版ZhenyanJi9參與者參與者（Actor）代表了與系統接口的事物或人，它是具有某一種特定功能的角色。因此，參與者是虛擬的概念，它可以是人，也可以是外部系統或設備。同一個人可能對應著多個參與者，因為一個人可能扮演了多個角色。參與者不是系統的一部分，它們處于系統的外部。UML系統分析與設計第2版ZhenyanJi10參與者如何識別參與者？可以通過回答一系列問題●誰是系統的主要用戶？ ●誰從系統獲得信息？●誰向系統提供信息？ ●誰從系統刪除信息？●誰支持、維護系統？ ●誰管理系統？●系統需要與其他哪些系統交互（包含其他計算機系統和其他應用程序）？●系統需要操縱哪些硬件？ ●在預設的時間內，有事情自動發生嗎？●系統從哪里獲得信息？ ●誰對系統的特定需求感興趣？●幾個人在扮演同樣的角色嗎？ ●一個人扮演幾個不同的角色嗎？●系統使用外部資源嗎？ ●系統要用在什么地方？UML系統分析與設計第2版ZhenyanJi11參與者識別參與者需要注意：參與者代表角色。當建立用例模型時，參與者是用來模擬角色的，而不是用來模擬物理的、現實世界的人、組織或系統本身。角色不是對職位進行建模。UML系統分析與設計第2版ZhenyanJi12參與者UML系統分析與設計第2版ZhenyanJi13用例用例（UseCase）是對系統行為的動態描述可以增進系統設計人員、開發人員與用戶的溝通，正確地理解系統需求；還可以劃分系統與外部實體的界限。用例是系統設計的起點，是類、對象、操作的來源，可以通過邏輯視圖的設計，獲得軟件的靜態結構。UML系統分析與設計第2版ZhenyanJi14用例如何識別用例？可以通過以下問題幫助識別：●每個參與者的任務是什么？●有參與者要創建、存儲、改變、刪除或讀取系統中的信息嗎？●什么用例會創建、存儲、改變、刪除或讀取這個信息？●參與者需要通知系統外部的突然變化嗎？●需要通知參與者系統中正在發生的事情嗎？●什么用例將支持和維護系統？●所有的功能需求都能被用例實現嗎？UML系統分析與設計第2版ZhenyanJi15用例在描述用例事件流時，每個軟件項目都應使用一個標準模板。下面給出一個目前應用最廣泛的模板。

X.用例XX（用例名）的事件流 X.1前置條件（Pre-Conditions） X.2后置條件（Post-Conditions） X.3擴充點（ExtensionPoints） X.4事件流 X.4.1基流（BasicFlow） X.4.2分支流（Subflows）（可選） X.4.3替代流（AlternativeFlows）UML系統分析與設計第2版ZhenyanJi16用例用例與腳本一個用例描述了一個序列集，而序列集中的每一個序列描述了一個流，這個流代表了用例的一個變種，每一個這樣的序列就被稱為一個腳本或場景（Scenario）。腳本是系統行為的一個特定動作序列。腳本與用例的關系就像實例與類的關系，即腳本是用例的一個實例。UML系統分析與設計第2版ZhenyanJi17用例用例間的關系類屬關系用例間的類屬關系如同類間的類屬關系。也就是說，子用例繼承父用例的行為和含義，它也可以添加新行為或覆蓋父用例的行為。UML系統分析與設計第2版ZhenyanJi18用例用例間的關系包含關系多個用例可能具有一些相同的功能，通常將這些共享的功能放在一個單獨的用例中，在這個新用例和其他需要使用其功能的用例之間創建包含（Include）關系。用例間的包含關系表示在基用例的指定位置，基用例顯式地包含另一個用例的行為。被包含的用例是不能獨立存在的，只是作為包含它的更大用例的一部分。UML系統分析與設計第2版ZhenyanJi19用例用例間的關系（接上頁）包含關系在UML中，Include關系可以用衍型為<<include>>的依賴關系表示。UML系統分析與設計第2版ZhenyanJi20用例用例間的關系擴充關系擴充關系用來說明可選的、只在特定條件下運行的行為。根據參與者的選擇，具有擴充關系的用例可以運行幾個不同的流。用例間的擴充關系表示基用例在指定的擴充點隱式地包含另一個用例的行為。擴充關系被用來描述特定的用例部分，該用例部分被用戶視為可選的系統行為，這樣就將可選行為與義務行為區分開來。UML系統分析與設計第2版ZhenyanJi21用例用例間的關系（接上頁）擴充關系擴充關系用衍型為<<extend>>的依賴關系表示。UML系統分析與設計第2版ZhenyanJi22用例圖的應用用例圖可以用來為系統的靜態用例視建模。靜態用例視體現系統的行為，即系統提供的外部可見的服務。用例圖可以被用來完成以下功能：為系統的上下文建模。為系統的需求建模。用例圖的應用UML系統分析與設計第2版ZhenyanJi23用例圖的應用

為系統的上下文建模。如上頁圖所示，用例圖描述了一個公司管理系統的上下文，這個圖強調了系統周圍的參與者。為系統的需求建模。如上頁圖所示，用例圖可視化地描述了公司管理系統的功能需求，為最終用戶、領域專家和開發人員之間的交流提供了途徑。UML系統分析與設計第2版ZhenyanJi24小結用例模型用于需求分析階段，它描述了待開發系統的功能需求，并驅動了需求分析之后各階段的開發工作。用例圖（UseCaseDiagram）是UML中用來對系統的動態方面進行建模的7種圖之一。用例圖描述了用例、參與者以及它們之間的關系。U