UML面向對象設計與分析教程（第二版）（微課版）第3章需求分析與用例建模本章的學習目標：理解軟件需求的含義理解需求分析的必要性和重要性掌握參與者和用例的基本概念掌握用例描述的要點和方法掌握用例之間的各種關系理解用例粒度的概念理解業務用例和系統用例的區別掌握如何使用RationalRose建立用例模型需求層次內容業務需求反映組織機構或客戶對系統、產品高層次的目標要求。通常問題定義就是業務需求用戶需求描述用戶使用產品必須要完成什么任務，怎么完成，通常是在問題定義的基礎上進用戶訪談、調查，對用戶使用的場景進行整理，從而建立從用戶角度的需求系統需求從系統的角度來說明軟件的需求，它就包括了用特性說明的功能需求，質量屬性以及其它非功能需求，還有設計約束一、引言什么是需求一、引言什么是需求需求—建造“正確”的系統需求：系統必須滿足的條件或具備的能力RobertGrady軟件質量準則“FURPS”功能性（Functionality）使用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）非功能性需求一、引言什么是需求超預算平均超出費用:189%推遲發布平均超出時間:222%不能滿足期望平均覆蓋率:61%28%Successful72%FailedStandishGroup——美國專門從事跟蹤IT項目成功或失敗的權威機構一、引言軟件業的現狀

在Standish

Group的報告中總結了導致項目失敗的最重要的8大原因中，有5個與需求相關：№1不完整的需求；№2沒有用戶的介入；№3不實際的客戶期望；№4需求和規范的變理；№5提供了不再需要的。一、引言軟件業的現狀一、引言我們在哪重重摔了一跤我要一塊石頭…差不多，但我要小一點的…很好，不過我要藍色的…啊，沒有那么小…咳，還是原來那個好了…小一點的藍色大理石難捕獲，易變！一、引言一、引言需求——難在何處？需求：石頭問題難捕獲易變從用戶視角看問題合理的結構用例一、引言需求問題——對策以用例為中心組織需求！客戶/用戶的要求/想法/期望軟件設計軟件產品開發編碼和測試驗收有價值的

軟件需求分析和設計一、引言需求：也需要開發基本思路問題的提出：在系統尚未存在時，如何描繪用戶需要一個什么樣的系統？如何規范地定義用戶需求？考慮問題的思路：把系統看作一個黑箱，看它對外部的客觀世界發揮什么作用，描述其外部可見的行為。系統是由一條邊界包圍起來的未知空間只通過有限的幾個接口與外部交互系統邊界以外是與系統進行交互的參與者把內外交互情況描述清楚，就確切地定義了系統的需求11如何開始？從用例圖開始！一、引言系統的誕生一、什么叫用例圖由參與者（Actor）、用例（UseCase）以及它們之間的關系構成的用于描述系統功能的動態視圖稱為用例圖（UseCaseDiagram）。要在用例圖上顯示某個用例，可繪制一個橢圓，然后將用例的名稱放在橢圓的中心或橢圓下面的中間位置。要在用例圖上繪制一個參與者（表示一個系統用戶），可繪制一個人形符號。參與者和用例之間的關系使用帶箭頭或者不帶箭頭的線段來描述，箭頭表示在這一關系中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者。1、用例圖的含義一、什么叫用例圖1、用例圖的含義一、什么叫用例圖

在用例建模中，為了更加清楚的描述用例或者參與者，會使用到注釋。1、用例圖的含義一、什么叫用例圖

用例圖是需求分析中的產物，主要作用是描述參與者和用例之間的關系，幫助開發人員可視化的了解系統的功能。借助于用例圖，系統用戶、系統分析人員、系統設計人員、領域專家能夠以可視化的方式對問題進行探討，減少了大量交流上的障礙，便于對問題達成共識。用例圖可視化地表達了系統的需求，具有直觀、規范等優點，克服了純文字性說明的不足。用例方法是完全從外部來定義系統功能，它把需求和設計完全的分離開來。我們不用關心系統內部是如何完成各種功能的，系統對于我們來說就是一個黑箱子。2、用例圖的作用二、用例圖的構成要素用例圖包含3方面內容：用例圖中可以包含注釋、約束以及包。參與者（Actor）用例（UseCase）關系：關聯、泛化、包含、擴展等系統邊界系統邊界：一個系統所包含的所有系統成分與系統以外各種事物的分界線。系統：被開發的計算機軟硬件系統，不是指現實系統。系統成分：在OOA和OOD中定義并且在編程時加以實現的系統元素——對象對象對象對象對象對象對象參與者(人員)參與者(設備)參與者(外系統)參與者：在系統邊界以外，與系統進行交互的事物——人員、設備、外系統系統邊界與參與者17現實世界中的事物與系統之間的關系——分四種情況（1）被抽象為系統中的對象汽車飛機獎杯鐘表起重機職員樓房天平（2）只作為系統外部的參與者與系統交互（4）與系統無關操作員（3）既是系統中的對象，本身又作為參與者與系統交互18人員——系統的直接使用者直接為系統服務的人員設備——與系統直接相聯的設備為系統提供信息在系統控制下運行不與系統相連的設備×計算機設備×外系統——上級系統子系統其它系統如何發現參與者——考慮人員、設備、外系統19參與者參與者是系統外部的一個實體，以某種方式參與用例的執行過程。是為了完成一個事件與系統進行交互的實體，是與系統交互作用的外部用戶、進程或其他系統的理想化概念。在UML中，參與者用名字寫在下面的人形圖標表示。參與者參與者由它們參與用例時所擔當的角色來表示。任何事物人、外系統、硬件設備、時間等參與者參與者參與者25在獲取用例前要先確定系統的參與者，可以根據以下的一些問題來尋求系統參與者。⑴誰將使用該系統的主要功能；⑵誰將需要該系統的支持以完成其工作；⑶誰將需要安裝、維護、管理該系統，以及保持該系統處于工作狀態；⑷系統需要處理哪些硬件設備⑸與該系統發生交互的是什么系統⑹誰或什么系統對本系統產生的結果感興趣參與者的識別26參與者的識別27多個參與者之間可以具有與類之間相同的關系。在用例圖中，可以使用泛化關系來描述多個參與者之間的公共行為。參與者間的關系28例如，在圖書館管理系統中，借書者可以泛化成兩類：學生和老師。再如，航空售票系統接受客戶預定機票，客戶可以進行電話預定和網上預定，如果不考慮客戶是如何與系統接觸的，可以使用一般角色的參與者，即父類；如果強調接觸發生的形式，那么必須使用實際的參與者，即子類。參與者間的關系29更具一般的，可以由下圖表示參與者之間的關系。參與者間的關系思考：識別參與者？尋呼臺系統：用戶如果預定了天氣預報，系統每天定時給他發天氣消息；如果當天氣溫高于35度，還要提醒用戶注意防暑；在這個敘述里，誰是尋呼臺系統的Actor？用戶？氣溫？時間？31用例是外部可見的系統功能單元。用例是對一個系統或一個應用的一種單一的使用方式所作的描述。用例的用途是，在不揭示系統內部構造的前提下定義系統的行為。在UML中，用例用一個橢圓來表示，用例的名字可以寫在橢圓的下方。用例32每個用例都必須有一個惟一的名字以區別于其它用例。用例的名字是一個字符串，包括簡單名和路徑名。

用例33用例圖對整個系統的建模過程非常重要，在繪制系統用例圖前，有許多工作需要做。系統分析者必須分析系統的參與者和用例，它們分別描述了“誰來做”和“做什么”這兩個問題。識別用例最好的方法就是從分析系統的參與者開始，考慮每個參與者是如何使用系統的。使用這種策略的過程中可能會發現新的參與者。1、識別用例34在識別用例的過程中，通過回答以下幾個問題，系統分析者可以獲得幫助。⑴特定參與者希望系統提供什么功能⑵系統是否存儲和檢索信息，如果是，由哪個參與者觸發⑶當系統改變狀態時，是否通知參與者⑷是否存在影響系統的外部事件⑸哪個參與者通知系統這些事件識別用例具體可以通過查找事件的方式來識別用例：主語＋動詞＋賓語簡潔：參與者使用系統達到目標識別用例已被識別出來的參與者動作動詞涉及的目標讀者借閱書籍36識別用例用例的命名執行者視角：（狀語）動詞+（定語+）賓語用例的粒度指的是用例所包含的系統服務或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。如果用例的粒度很小，得到的用例數就會太多。反之，如果用例的粒度很大，那么得到的用例數就會很少。如果用例數目過多會造成用例模型過大和引入設計困難大大提高。如果用例數目過少會造成用例的粒度太大，不便于進一步的充分分析。最常犯錯誤：粒度過細，陷入功能分解過細的粒度，一般都會導致技術語言的描述，而不再是業務語言2、用例粒度用例粒度比較下列兩圖用例的粒度如果用例的粒度很小，得到的用例數就會太多。反之，如果用例的粒度很大，那么得到的用例數就會很少。如果用例數目過多會造成用例模型過大和引入設計困難大大提高。如果用例數目過少會造成用例的粒度太大，不便于進一步的充分分析用例粒度用例粒度常見錯誤：把交互的某個步驟當作用例把系統活動當作用例四輪馬車的錯誤（增加、刪除、修改、查詢）粒度過細，陷入功能分解用例粒度錯誤一：把步驟當用例用例粒度錯誤二：把系統活動當用例用例粒度錯誤三：四輪馬車C(Create)

R(Read)

U(Update)

D(Delete)用例粒度如果CRUD不涉及復雜的交互，一個用例“管理××”即可不管是C、R、U、D，都是為了完成“管理”目標用例粒度靈活處理CRUD可以把包含復雜交互的路徑獨立出去形成用例用例粒度錯誤四：粒度過細用例圖只是在總體上大致描述了系統所提供的各種服務，讓用戶對系統有一個總體的認識。但對于每一個用例還需要有詳細的描述信息，以便讓其他人對于整個系統有一個更加詳細地了解，這些信息包含在用例規約之中。用例模型指的也不僅僅是用例圖，而是由用例圖和用例的詳細描述——用例規約所組成的。用例規約用例圖是骨架，而用例規約則是其內在的肉

對于每一個用例，我們還需要有詳細的描述信息，以便讓別人對于整個系統有一個更加詳細的了解，這些信息包含在用例規約之中。每一個用例的用例規約都應該包含以下內容：

1簡要說明:對用例作用和目的的簡要描述。

2事件流:事件流包括基本流和備選流。基本流描述的是用例的基本流程，是指用例“正常”運行時的場景。

3用例場景:同一個用例在實際執行的時候會有很多不同的情況發生，稱之為用例場景，也可以說用例場景就是用例的實例。

4特殊需求:特殊需求指的是一個用例的非功能性需求和設計約束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可擴展性等。例如法律或法規方面的需求、應用程序標準和所構建系統的質量屬性等。

5前置條件:執行用例之前系統必須所處的狀態。例如，前置條件是要求用戶有訪問的權限或是要求某個用例必須已經執行完。

6后置條件:用例執行完畢后系統可能處于的一組狀態。例如，要求在某個用例執行完后，必須執行另一個用例。3、用例規約高屋建瓴與細致入微相得益彰圖形inRose文本inWord事件流說明用例如何開始和結束。只說明屬于該用例的事件，而不是發生在其他用例中或系統外部的事件。避免不明確的術語，如“例如”、“等等”和“信息”事件流在事件流里要對事件流進行結構化說明基本事件流描述每個情節的行為者:目標語句對的順序假設之前的每一步都是成功的備選事件流異常情況對于異常中的異常，用更長的前綴標記更深一層的失敗情節非功能需求(URPS)可用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）設計約束用Oracle數據庫平臺，用PB開發…軟件必須符合ISO×××標準……本質上不是需求，只是從商業、行政、技術上的約束特殊需求前置、后置條件前置條件約束在用例開始前系統的狀態把它們看做是看門人，它阻止參與者觸發該用例直到滿足所有條件說明在用例觸發之前什么必須為真后置條件約束用例執行后系統的狀態用例執行后什么必須為真對于有多個事件流的用例，則應該有多個后置條件術語是不同專業領域中的專用語，非本專業的人不能理解，為便于不同的人員理解和交流，需要對術語進行解釋和定義。術語表的每一項都定義了一個術語，定義可長可短；術語表可以讓查看軟件開發產品的人覺得行話不再神秘。詞匯表詞匯表用例規約示例用例編號UC03用例名稱記錄時間日志用例概述開發人員可以隨時記錄自己的時間，提供“開始計時”、“暫停計時”、“停止計時”等功能，在停止時，填入任務編號（在線則選擇）、工作關鍵字（以逗號分隔的多個），自動生成開始時間、暫停時間、停止時間、總時長、有效時長（總時長-中斷時長）。主參與者開發人員前置條件用戶進入“記錄時間日志”程序后置條件將本次時間日志存入數據庫基本事件流步驟活動1系統顯示“開始”、“暫停”和“停止”按鈕，但僅“開始”可用2用戶點擊“開始”，系統記錄開始時間，并將“開始”置為不可用，使“暫停”和“停止”按鈕可用3用戶點擊“停止”按鈕，系統記錄停止時間，并統計暫時時間、暫停次數、總時長、有效時長，并要求用戶選擇任務編號、輸入工作關鍵字和相關信息。填寫完成后，點擊確定，用例完成。擴展事件流3a在此期間，若用戶點擊“暫停”按鈕，系統則記錄暫停開始時間，并使暫停次數增加1次，并使“暫停”按鈕變為“恢復”，使“停用”按鈕不可用3a1當用戶點擊“恢復”按鈕，用當前時間減去暫停開始時間得到本次暫停時間，并累加到“暫停時間”時間中，并使“恢復”按鈕變為“暫停”，使“停用”按鈕恢復可用規則與約束時間記錄程序應以離線式工作，該程序會自動連接服務器，完成時間日志上傳的工作，如果未能連接服務器，則在本機暫存時間日志關聯關系表示參與者和用例之間的通信。用例與其參與者之間的關聯關系用帶箭頭的直線表示。用例與其參與者之間的關聯任何用例都不能在缺少參與者的情況下存在；任何參與者也必須要有與之關聯的用例。用例與用例之間的關系

<<include>><<extend>>泛化包含擴展用例除了與其參與者發生關聯外，用例之間具有多種關系，這些關系包括包含關系、擴展關系和泛化關系等。如果系統中一個或多個用例是某個一般用例的特殊化時，就需要使用用例的泛化關系。在UML中，用例泛化與其他泛化關系的表示法相同，用一個三角箭頭從子用例指向父用例。用例與用例之間的關系→泛化關系用例與用例之間的關系→泛化關系泛化——同一業務目的不同技術實現用例與用例之間的關系→泛化關系用例與用例之間的關系→包含關系<<include>><<include>><<include>>用例與用例之間的關系→包含關系用例的包含關系是把一件事情劃分為多個步驟處理包含關系把幾個用例的公共步驟分離成一個單獨的被包含用例。被包含用例稱作提供者用例（基本用例），包含用例稱作客戶用例，提供者用例提供功能給客戶使用。用例與用例之間的關系→包含關系用例與用例之間的關系→包含關系用例與用例之間的關系→包含關系用例與用例之間的關系→擴展關系用例與用例之間的關系→擴展關系<<extend>>擴展關系是把新的行為插入到已有用例中的方法。一個用例也可以被定義為基礎用例的增量擴展，這稱作擴展關系;在UML中，擴展關系表示為虛線箭頭加<<extend>>字樣，箭頭指向被擴展的用例（即基礎用例）。基礎用例的擴展增加了原有的語義，此時是基礎用例而不是擴展用例被作為例子使用。用例與用例之間的關系→擴展關系基礎用例不必知道擴展用例的任何細節，它僅為其提供擴展點。基礎用例即使沒有擴展用例也是完整的。只有特定的條件發生，擴展用例才被執行。擴展關系為處理異常或構建靈活的系統框架提供了一種十分有效的方法。用例與用例之間的關系→擴展關系使用Rose繪制用例圖⑴創建用例圖一般情況下，用例圖是UML中要繪制的第一個圖。在用Rose創建所用的模型之前，首先要新建一個工程。新建工程可以點擊【File→New】菜單項。使用Rose創建用例圖使用Rose繪制用例圖⑴創建用例圖

打開RationalRose后，在UseCaseView圖標上單擊鼠標右鍵，在彈出的快捷菜單中選擇New|UseCaseDiagram命令建立新的用例圖。菜單項功能包含選項OpenSpecification…打開屬性說明New新建UML元素Package（包）UseCase（用例）Actor（角色）Class（類）UseCaseDiagram（用例圖）ClassDiagram（類圖）CollaborationDiagram（協作圖）SequenceDiagram（時序圖）StatechartDiagram（狀態圖）ActivityDiagram（活動圖）使用Rose繪制用例圖⑴創建用例圖

創建新的用例圖后，在UseCaseView樹型結構下多了一個名為NewDiagram的圖標，這個圖標就是新建的用例圖圖標。右鍵單擊此圖標，在彈出的快捷菜單中選擇Rename命令來為新創建的用例圖命名。使用Rose繪制用例圖⑴創建用例圖雙擊用例圖圖標，會出現用例圖的編輯工具欄和編輯區。⑵

用例圖工具箱按鈕簡介圖標作用選擇一項添加文本框添加注釋將圖中的元素與注釋相連包用例參與者單向關聯關系依賴和實例化（包括擴展、使用關系等）泛化關系關聯關系使用Rose繪制用例圖⑶工具欄的定制①選擇菜單views|Toolbars|Configure…②點擊鼠標右鍵…使用Rose繪制用例圖⑷添加參與者與用例①繪制參與者要創建參與者，首先要單擊用例圖工具欄中的圖標，然后在用例圖編輯區內單擊畫出參與者。接下來可以對這個參與者命名，單擊已畫出的參與者，會彈出如下對話框。

使用Rose繪制用例圖⑷添加參與者與用例①繪制參與者對于一個完整的用例圖來說，參與者往往不只一個，這就需要創建參與者之間的關系。

使用Rose繪制用例圖⑷添加參與者與用例②繪制用例單擊工具欄中的圖標，然后在用例圖編輯區內單擊鼠標左鍵畫出用例。單擊已畫出的用例，彈出如圖如下所示的對話框。

使用Rose繪制用例圖

⑸添加參與者與用例之間的關系使用Rose繪制用例圖⑹添加用例之間的關系

①包含關系單擊用例圖工具欄中的圖標，然后在需要創建包含關系的兩個用例之間拖動鼠標，雙擊虛線段，彈出如下對話框。用例之間的包含關系

使用Rose繪制用例圖⑹添加用例之間的關系②擴展關系

使用Rose繪制用例圖⑹添加用例之間的關系

③泛化關系

使用Rose繪制用例圖⑹添加用例之間的關系

③泛化關系

基于用例的需求分析過程1.獲取原始需求2.開發一個可以理解的需求2.1識別參與者2.2識別用例2.3構建用例圖3詳細、完整地描述需求進行用例闡述4重構用例模型4.1識別用例間的關系4.2對用例進行組織和分包實例：圖書管理系統1.確定系統需求圖書管理系統能夠對圖書進行注