第5章-用例圖

1、1,第5章 用例圖,主講：才智,2,第5章 用例圖,5.1 概述 5.2 參與者（Actor） 5.3 用例（Use Case） 5.4 用例間的關(guān)系 5.5 用例圖建模 5.6 用例圖建模實(shí)例,3,5.1 概述,面向?qū)ο蟮南到y(tǒng)分析主要特點(diǎn)是把問題域中的事物抽象為系統(tǒng)中的對象，最終建立一個(gè)用面向?qū)ο蟾拍畋磉_(dá)的系統(tǒng)模型。 抽象必須有一個(gè)目標(biāo)，對分析而言，這個(gè)目標(biāo)就是要滿足用戶需求。,4,5.1 概述,Jacobson提出：針對系統(tǒng)對外提供的每一項(xiàng)功能，詳細(xì)地描述對這項(xiàng)功能的使用情況（use case，簡稱用例）。 以用例作為建立需求模型的基本單位，一個(gè)用例只針對一項(xiàng)系統(tǒng)功能，詳細(xì)的描述系統(tǒng)邊界以

2、外的參與者使用這項(xiàng)功能時(shí)與系統(tǒng)進(jìn)行交互的情況，這可以比較確切地定義系統(tǒng)的功能需求。 用例的概念的提出彌補(bǔ)了以往各種面向?qū)ο蠓治龇椒ㄔ谛枨蠖x方面的不足，因此很快就被廣泛采納。,5,5.1 概述,UML的面向?qū)ο笙到y(tǒng)開發(fā)過程中在需求分析階段的需求模型由用例建模完成，以用例為驅(qū)動，因此又稱為用例模型。 用例模型是表達(dá)系統(tǒng)外部事物（參與者）與系統(tǒng)之間交互的可視化工具。 一個(gè)系統(tǒng)的用例模型由若干用例圖組成，用例圖的主要成分有參與者（Actor）、用例（Use Case）以及用例間的各種關(guān)系。 用例圖可以包含注釋和約束，還可以包含包，用于將模型中的元素組合成更大的模塊。,6,5.1 概述,基本用例圖,7

3、,5.2 參與者（Actor）,參與者（Actor）是在系統(tǒng)之外與系統(tǒng)進(jìn)行交互的任何事物，可以是人或其他系統(tǒng)，他以某種方式參與了系統(tǒng)內(nèi)用例的執(zhí)行。 參與者的特征是其作為外部用戶與系統(tǒng)發(fā)生交互，交互的方式可以是參與者向系統(tǒng)發(fā)送消息，也可以是從系統(tǒng)那里接收消息，或與系統(tǒng)之間交換消息。,8,5.2 參與者（Actor）,參與者代表一種角色，而不是具體的某個(gè)人。 在系統(tǒng)的實(shí)際運(yùn)作中，多個(gè)不同的用戶可能只對應(yīng)于一個(gè)參與者；同時(shí)一個(gè)實(shí)際用戶也可能對應(yīng)系統(tǒng)的多個(gè)參與者。 例如，在“房地產(chǎn)開發(fā)經(jīng)營管理系統(tǒng)”中，所有的購房者作為一個(gè)集合，在“房屋銷售子系統(tǒng)”中作為購房合同的簽約方出現(xiàn)，多個(gè)個(gè)體在系統(tǒng)中擔(dān)任一個(gè)參

4、與者；同時(shí)，某個(gè)獨(dú)立的購房者在“物業(yè)管理子系統(tǒng)”中又作為房屋的業(yè)主出現(xiàn)，同一個(gè)人在系統(tǒng)中擔(dān)任了兩類參與者。,9,5.2 參與者（Actor）,參與者的分類 人參與者和外部系統(tǒng)參與者 主參與者和副參與者 主動參與者和被動參與者,10,5.2 參與者（Actor）,人參與者和外部系統(tǒng)參與者 系統(tǒng)的各類用戶是人參與者，用戶通過與系統(tǒng)進(jìn)行交互來操縱系統(tǒng)，完成各種工作。 參與者也可以是位于系統(tǒng)外部的其他軟件系統(tǒng)或硬件設(shè)備，這類參與者統(tǒng)稱為外部系統(tǒng)參與者。 例如，計(jì)算機(jī)網(wǎng)絡(luò)系統(tǒng)的參與者可以包括操作員、系統(tǒng)管理員、數(shù)據(jù)庫管理員以及普通用戶等人參與者，另外也可以有外部系統(tǒng)參與者，如網(wǎng)絡(luò)打印機(jī)。,11,5.2

5、參與者（Actor）,主參與者和副參與者 主參與者使用系統(tǒng)的主要功能，是使用系統(tǒng)較頻繁、業(yè)務(wù)量較大的用戶。 副參與者處理系統(tǒng)的輔助功能，它與用例進(jìn)行交互的主要目的是為了給其他的參與者提供某些服務(wù)，如管理數(shù)據(jù)庫、通信、系統(tǒng)備份以及其他管理等系統(tǒng)維護(hù)工作。 區(qū)分主參與者與副參與者不應(yīng)該以參與者在使用系統(tǒng)時(shí)的權(quán)限為依據(jù)，一般情況下，應(yīng)該以使用系統(tǒng)時(shí)的業(yè)務(wù)量為依據(jù)。,12,5.2 參與者（Actor）,主動參與者和被動參與者 主動參與者是系統(tǒng)的啟動者，負(fù)責(zé)啟動一個(gè)或多個(gè)用例，他們是為了完成某項(xiàng)事務(wù)而啟動系統(tǒng)的，一個(gè)主動參與者可以請求某種服務(wù)或者觸發(fā)一個(gè)事件。 被動參與者從不啟動用例，只是參與一個(gè)或多個(gè)

6、用例，他們相應(yīng)系統(tǒng)的請求，為系統(tǒng)提供某種服務(wù)。,13,5.2 參與者（Actor）,參與者的表示 在用例圖中，參與者用一個(gè)簡化的人體形狀的符號表示，在符號的下方注明了參與者的名稱。,14,5.2 參與者（Actor）,識別參與者 進(jìn)行用例圖建模，首先要做的就是確定系統(tǒng)的參與者。 在確定參與者之前，一定要明確一點(diǎn)：參與者對于系統(tǒng)而言，總是處于系統(tǒng)外部的，而不是系統(tǒng)的組成部分。,15,5.2 參與者（Actor）,識別參與者 誰將使用系統(tǒng)的主要功能（主參與者）？ 誰將借助于系統(tǒng)來完成日常工作？ 為了保證系統(tǒng)正常運(yùn)行，誰將對系統(tǒng)進(jìn)行維護(hù)管理（副參與者）？ 誰將完成系統(tǒng)數(shù)據(jù)的錄入、導(dǎo)出及修改等工作（主

7、動參與者）？ 誰或什么系統(tǒng)對系統(tǒng)產(chǎn)生的結(jié)果感興趣（被動參與者）？ 系統(tǒng)控制的硬件設(shè)備有哪些？ 系統(tǒng)需要與哪些其他外部系統(tǒng)進(jìn)行交互？ 在預(yù)定的時(shí)間，是否有事件自動觸發(fā)？ 系統(tǒng)從何處獲取信息？,16,5.2 參與者（Actor）,參與者之間的關(guān)系 泛化關(guān)系：用一個(gè)三角箭頭來表示，其中箭頭所指向的角色為超類參與者，箭頭尾端的角色為特殊化的參與者。,17,5.3 用例（Use Case）,用例（Use Case）是對參與者使用系統(tǒng)某項(xiàng)功能時(shí)所進(jìn)行的交互過程的描述，過程中包括交互雙方所執(zhí)行的一系列動作。 用例描述了參與者與系統(tǒng)交互的完整過程。,18,5.3 用例（Use Case）,用例特征： 響應(yīng)性。

8、一個(gè)用例不會自動執(zhí)行，總是由參與者啟動或由系統(tǒng)根據(jù)某些事件觸發(fā)，參與者必須直接或間接地指示系統(tǒng)去執(zhí)行用例。 回執(zhí)性。用例執(zhí)行完畢，向參與者提供可識別的返回值。 完整性。用例表示一個(gè)完整的功能，必須是一個(gè)完整的描述。,19,5.3 用例（Use Case）,用例的表示 在UML語言中，用例用一個(gè)橢圓來表示，并且每個(gè)用例必須有一個(gè)名字。 在用例命名時(shí)用例的名字一般用字符串來表示，可分為簡單名和路徑名。其中，路徑名引入了包的概念，在用例名前加上該用例所屬包的名字，兩個(gè)名字之間用兩個(gè)冒號分開。,20,5.3 用例（Use Case）,確定用例 確定用例最好的方法是從分析系統(tǒng)的參與者開始，對于已經(jīng)確定的

9、參與者，通過考慮每個(gè)參與者是如何使用系統(tǒng)的，以及系統(tǒng)對事件的響應(yīng)來識別用例。 使用這種策略進(jìn)行具體分析的過程中，可能會發(fā)現(xiàn)新的參與者，這對完善整個(gè)系統(tǒng)的建模有很大的幫助作用。 用例建模的過程是一個(gè)迭代并逐步細(xì)化的過程。,21,5.3 用例（Use Case）,確定用例 參與者需要系統(tǒng)提供什么功能？即參與者需要系統(tǒng)“做什么”？ 參與者是否需要讀取、產(chǎn)生、刪除、修改或存儲系統(tǒng)中的某種信息？ 當(dāng)系統(tǒng)狀態(tài)改變時(shí)，是否通知參與者？ 是否存在影響系統(tǒng)的外部事件？ 系統(tǒng)需要什么樣的輸入/輸出信息？,22,5.3 用例（Use Case）,描述用例 用例圖通過圖形符號描述了參與者和系統(tǒng)之間的關(guān)系，但是它對于系

10、統(tǒng)行為的細(xì)節(jié)描述比較欠缺。 在一般情況下，需要以書面文檔的形式對于用例進(jìn)行描述，每個(gè)用例應(yīng)具有一個(gè)用例描述。,23,5.3 用例（Use Case）,描述用例 1.名稱：能夠明確的表明用戶的意圖或用例的用途，切記不要使用諸如UseCase1、UseCase2之類的名稱，會使用例圖的讀者在閱讀時(shí)無法讀懂用例圖所描述的內(nèi)容。 2.標(biāo)識符可選：用來唯一標(biāo)識一個(gè)用例，如“UC0001”，這樣就可以在項(xiàng)目的其他元素中用它來引用這個(gè)用例。 3.參與者可選：與此用例相關(guān)的參與者列表。在沒有用例圖時(shí)，它有助于增加對改用里的理解。 4.狀態(tài)可選：用來指示該用例的狀態(tài)，通?？砂ㄟM(jìn)行中、等待審查、通過審查或未通過

11、審查等狀態(tài)。,24,5.3 用例（Use Case）,描述用例 5.頻率：記錄參與者使用該用例的頻率。 6.前置條件：前置條件以一個(gè)條件列表的形式進(jìn)行記錄，用來描述執(zhí)行用例之前系統(tǒng)所必須滿足的條件。這些條件必須在使用用例之前得到滿足。前置條件在使用之前，已經(jīng)由用例進(jìn)行過測試。如果條件不滿足，則用例不會被執(zhí)行。 7.后置條件：后置條件將在用例成功完成以后得到滿足，它提供了系統(tǒng)的部分描述。即在前置條件滿足后，用例做了什么？以及用例結(jié)束時(shí)，系統(tǒng)處于什么狀態(tài)？,25,5.3 用例（Use Case）,描述用例 8.假設(shè)可選：假設(shè)描述的是系統(tǒng)在使用用例之前必須滿足的狀態(tài)，這些條件并沒有經(jīng)過用例的檢測，用

12、例只是假設(shè)它們?yōu)檎妗?9.基本操作流程：參與者在用例中所遵循的主要邏輯路徑。操作流程描述了用戶和執(zhí)行用例之間交互的每一步。 10.可選操作流程：包括用例中很少使用的邏輯路徑，那些在變更工作方式、出現(xiàn)異?；虬l(fā)生錯誤的情況下所遵循的路徑。 11.修改歷史記錄可選：主要記錄的是關(guān)于用例的修改時(shí)間、修改原因和修改人的詳細(xì)信息。,26,借閱圖書用例的描述,27,5.4 用例間的關(guān)系,泛化關(guān)系 包含關(guān)系 擴(kuò)展關(guān)系,28,5.4 用例間的關(guān)系,泛化關(guān)系 泛化關(guān)系表示兩個(gè)用例之間存在用例泛化，其中一個(gè)用例稱為父用例，其派生的用例稱為子用例，子用例是父用例的特殊化形式。子用例除了具有父用例的特性外，還可以有自己

13、另外的特性。,29,5.4 用例間的關(guān)系,包含關(guān)系 一個(gè)用例可以簡單地包含其他用例具有的行為，并把它所包含的用例行為作為自身行為的一部分，這被稱作包含關(guān)系。 包含關(guān)系是一種依賴關(guān)系。 包含關(guān)系把幾個(gè)公共步驟抽取出來形成一個(gè)單獨(dú)的被包含用例，包含有公共步驟的用例稱為基本用例。,30,5.4 用例間的關(guān)系,包含關(guān)系 包含關(guān)系用虛線箭頭加注字樣來表示 。,31,5.4 用例間的關(guān)系,擴(kuò)展關(guān)系 擴(kuò)展關(guān)系也是一種依賴關(guān)系。 它指定了一個(gè)用例可以增強(qiáng)另一個(gè)用例的功能，通過項(xiàng)基本用例添加動作來擴(kuò)展該用例。 一個(gè)用例被定義為基本用例的增量擴(kuò)展，這稱作擴(kuò)展關(guān)系。 在擴(kuò)展關(guān)系中，基本用例可以是獨(dú)立的。在一定條件下

14、，基本用例的動作可由另外一個(gè)用例擴(kuò)展而來?；居美峁┝巳舾伞皵U(kuò)展點(diǎn)”，擴(kuò)展用例只能在這些擴(kuò)展點(diǎn)上增加一個(gè)或多個(gè)新的動作。也就是說，擴(kuò)展用例只能發(fā)生在基本用例序列中的某個(gè)特定的點(diǎn)上。,32,5.4 用例間的關(guān)系,擴(kuò)展關(guān)系,33,5.5 用例圖建模,在UML中，用例圖建模的步驟主要包括： 識別和確定參與者。 識別和確定用例。 描述用例。 定義用例之間的關(guān)系。 建立用例圖，構(gòu)造用例模型。 審核用例模型。,34,5.5 用例圖建模,在所開發(fā)系統(tǒng)較為龐大、比較復(fù)雜的情況下，通?？蓪⑾到y(tǒng)分解為若干子系統(tǒng)，子系統(tǒng)還可以擁有自己的下屬子系統(tǒng)，在構(gòu)造用例模型是也應(yīng)該采用層次化用例圖的方法，每一個(gè)子系統(tǒng)都需要相

15、應(yīng)的用例圖進(jìn)行描述，用例圖之間也具有了層次結(jié)構(gòu)，高層系統(tǒng)的用例可以分解為若干下屬系統(tǒng)的用例，自上而下，逐層細(xì)化，可以更為全面、完整的描述用例模型。 對于一個(gè)功能需求相對簡單的系統(tǒng)，用例圖較少，可以不用對用例圖進(jìn)行分層細(xì)化。,35,5.6 用例圖建模實(shí)例,1.識別和確定系統(tǒng)參與者 圖書管理系統(tǒng)的基本功能： 系統(tǒng)可供圖書管理員處理借閱者的借書及歸還圖書工作； 系統(tǒng)應(yīng)允許圖書管理員查詢借閱者的借閱信息； 系統(tǒng)需要控制借閱者的借書期限，對于超期未還的情況，系統(tǒng)應(yīng)生成超期罰款信息，以便在借閱者歸還圖書時(shí)進(jìn)行相應(yīng)的超期處理； 系統(tǒng)的管理和維護(hù)工作應(yīng)由系統(tǒng)管理員負(fù)責(zé)，系統(tǒng)管理員可以進(jìn)行借閱者信息、圖書信息、

16、借閱信息、圖書管理員信息等內(nèi)容的管理工作。,36,5.6 用例圖建模實(shí)例,1.識別和確定系統(tǒng)參與者 通過需求分析，應(yīng)當(dāng)主要到以下幾點(diǎn)： 借閱者不參與系統(tǒng)的交互，他只是向圖書管理員發(fā)出借書、還書和續(xù)借的請求，其余工作有圖書管理員完成。因此，借閱者不屬于該系統(tǒng)的參與者。 在系統(tǒng)中，直接完成與系統(tǒng)交互以實(shí)現(xiàn)系統(tǒng)功能的是圖書管理員，他完成圖書的借閱、歸還和續(xù)借工作，并且可以進(jìn)行借閱信息的查詢。 一個(gè)系統(tǒng)要正常運(yùn)行，必要的維護(hù)及管理是必不可少的。因此，在這個(gè)系統(tǒng)中，一定要有系統(tǒng)管理員來完成系統(tǒng)的日常管理及維護(hù)工作。,37,5.6 用例圖建模實(shí)例,1.識別和確定系統(tǒng)參與者 圖書管理員Librarian 圖

17、書管理員代理學(xué)生完成借書、還書工作，并可以查詢其借閱信息。 系統(tǒng)管理員Administrator 系統(tǒng)管理員可以添加、修改、刪除為借閱者建立的借閱者賬戶；可以添加、修改、刪除圖書信息；可以添加、修改、刪除圖書書目信息；還可以添加、修改、刪除管理員信息，實(shí)現(xiàn)對訪問系統(tǒng)權(quán)限的管理。,38,5.6 用例圖建模實(shí)例,2.識別和確定系統(tǒng)用例 圖書管理員所涉及到的系統(tǒng)用例包括： 借閱圖書 歸還圖書 查看借閱信息 系統(tǒng)管理員所涉及到的系統(tǒng)用例包括： 管理借閱者信息 管理圖書信息 查看借閱信息 管理圖書管理員信息,39,與圖書管理員相關(guān)的系統(tǒng)用例： Login用例 完成圖書管理員的登錄功能，驗(yàn)證圖書管理員的身

18、份，以保證系統(tǒng)的安全。 ModifyPassword用例 當(dāng)圖書管理員成功登錄系統(tǒng)后，調(diào)用該用例可以完成對用戶密碼的修改。 BorrowBook用例 完成書籍借閱處理。 ReturnBook用例 完成圖書歸還處理。 ProcessOverTime用例 該用例檢查每個(gè)借閱者是否有超期的借閱信息，如有超期信息，進(jìn)行超期處理。 NotifyOverTime用例 如果某借閱者有超期信息，該用例用以通知圖書管理員給借閱者有圖書超期未還，執(zhí)行完畢該用例后，繼續(xù)執(zhí)行ProcessOverTime用例進(jìn)行超期處理。 QueryLoanInfo用例 查找某個(gè)借閱者信息。 DisplayLoanInfo用例 用于顯示某借閱者的所有借閱信息。,40,與系統(tǒng)管理員相關(guān)的系統(tǒng)用例： Login用例 該用例完成對系統(tǒng)管理員身份的驗(yàn)證，以保證系統(tǒng)的安全。 MaintenanceBorrowerInfo用例 用于完成對借閱者信息的管理及維護(hù)，包括添加借閱者（AddBorrower）、修改借閱者信息（UpdateBorrow）、刪除借閱者（DeleteBorrower）。 MaintenanceManagerInfo用例 用于完成對管理員信息的管理及維護(hù)，包括添加管理員（Add