uml基礎教程第三章用例圖課件

1、第三章 用例圖第1頁，共97頁。本章導讀知道參與者、用例和關系的概念了解用例的粒度和規(guī)約掌握參與者和用例的確定關系第2頁，共97頁。思考學習以下內容 什么是用例？ 創(chuàng)建、包含和擴展用例等的思想 如何開始一個用例分析？ 如何表示一個用例模型？ 如何可視化用例之間的關系？第3頁，共97頁?！居猛尽浚簬椭_發(fā)團隊以一種可視化的方式理解系統(tǒng)的功能需求。用戶對系統(tǒng)的使用方式決定了系統(tǒng)如何設計和構造。用例是能夠幫助分析員和用戶確定系統(tǒng)使用情況的UML組件。一組用例就是從用戶的角度出發(fā)對如何使用系統(tǒng)的描述。可以認為用例是系統(tǒng)的一組使用場景。用例圖的主要要素是參與者、用例和關聯(lián)。第4頁，共97頁。第5頁，共9

2、7頁。 用例圖主要用于描述系統(tǒng)的行為及各種功能之間的關系，是描述參與者（Actor）與用例以及用例與用例之間關系的圖。 用例圖從用戶和外部系統(tǒng)的角度，分析和考察系統(tǒng)的行為，并通過參與者與系統(tǒng)之間的交互關系描述系統(tǒng)對外提供的功能特性，用例圖用于描述系統(tǒng)與外部系統(tǒng)及用戶之間的交互。 UML的用例圖由參與者、用例及它們之間的關系組成，它的表達方式為： 用例圖 = 參與者 + 用例 + 關系 Use Case Diagram = Actor + Use Case + Relationship第6頁，共97頁。3.1 用例圖的構成用例圖可以用于描述系統(tǒng)的功能性需求和系統(tǒng)功能的使用環(huán)境。用例圖可視化地描述

3、了系統(tǒng)外部的使用者（抽象為參與者）和使用者使用系統(tǒng)時系統(tǒng)為這些使用者提供的一系列服務（抽象為用例），并清晰地描述了：參與者和參與者之間的泛化關系；用例和用例之間的包含關系、泛化關系、擴展關系；用例和參與者之間的關聯(lián)關系第7頁，共97頁。要用在用例圖上顯示某個用例：使用人形符號繪制一個參與者；繪制一個橢圓表示用例，將用例的名稱放在橢圓的中心或橢圓下面的中間位置；使用帶箭頭或不帶箭頭的線段來描述參與者和用例之間的關系。第8頁，共97頁。舉例：飲料銷售機 假設你現在正著手設計一臺飲料銷售機。為了獲得用戶的觀點，你會見了許多可能的用戶以了解這些用戶將如何與這臺機器交互。 飲料銷售機的主要功能是允許一個

4、顧客購買一罐飲料，很可能用戶立刻就能告訴你一些有關的場景（換句話說就是用例），你可以給這組場景加上一個標簽“買飲料”。下面我們來考察這個用例中每一種可能的場景。第9頁，共97頁。（1）用例“買飲料” 這個用例的參與者是買飲料的顧客。顧客將錢插入銷售機觸發(fā)了這個用例的場景被執(zhí)行，然后用戶進行選擇。如果一切順利，銷售機內至少還存儲有一罐被選擇的飲料，則銷售機會自動彈出這種飲料給顧客。 上面的“買飲料”場景是唯一可描述的場景么？。顯然，我們立即會想到還有其他的場景。顧客所要購買的飲料銷售機中可能沒有。顧客投入的錢數不是剛好等于購買飲料所需要的錢。應該如何設計飲料銷售機來處理這些場景呢？第10頁，共9

5、7頁。 先看看沒有所需的飲料這個場景，它是用例“買飲料”的另一場景?？梢园堰@個場景看成是用例執(zhí)行時的一條可選路徑。用例是由顧客在銷售機中插入錢幣所發(fā)起的。然后客戶進行一個選擇，銷售機中至少要有一罐選擇的飲料，如果沒有，銷售機就給顧客提示一個信息，告訴顧客沒有這種品牌的飲料。沒有所需飲料的場景第11頁，共97頁。 理想情況下，顧客看到這條消息后會立即選擇其它品牌的飲料。銷售機也必須提供給顧客取回原來的錢的選項。這表示，銷售機應給顧客兩種選擇：讓顧客選擇另一種飲料并且給顧客提供這種飲料（如果這種飲料還有存貨的話）或者讓顧客選擇退錢。 該場景的前置條件是顧客感到口渴，后置條件是顧客得到一罐飲料或者顧

6、客投入的錢被退回。第12頁，共97頁。 另一種“缺貨”的場景。“指定品牌的飲料售完”消息顯示在機器上，直到對這臺機器補充為止。在這種情況下，用戶不再輸入錢了。銷售機的客戶可能更喜歡第一種場景：如果顧客已經投了錢，應該讓顧客做另外一種選擇而不是要機器退錢?！叭必洝钡膱鼍暗?3頁，共97頁。緊接著讓我們來看看“付款數不正確”的這個場景。顧客按照通常的方式發(fā)起了這個用例，并進行了一個選擇。假設這是機器中備有選擇的飲料。如果機器中剛好存有適合的零錢，那么機器就會退還零錢并交付飲料。如果機器中沒有保存零錢，它將退還錢，并顯示一條消息提示用戶投入適當的零錢。 前置條件和前面場景一樣，后置條件是顧客得到一罐

7、飲料和找回零錢或者按原款歸還錢?！案犊顢挡徽_”的場景第14頁，共97頁。 另一種可能是機器的儲備零錢一旦用光，就會在機器上顯示一條小子告訴用戶需要投入適當的零錢。直到對這臺機器補充零錢為止，這條消息才會消失。第15頁，共97頁。（2）其他用例 已經從用戶的觀點考察了飲料銷售機。除了這些用戶外，當然還有其他人加入。供貨人負責為銷售機提供飲料，收款人（可能與供貨人是同一個人）負責定期收集銷售機中的錢。這說明至少需要建立兩個用例：“供貨”和“取錢”，這些用例細節(jié)可以通過與供貨人和收款人交談來獲得。第16頁，共97頁。考慮“供貨”用例。供貨人發(fā)起這個用例是由于某個時間間隔到期所引起的。供貨代表打開銷

8、售機拉出銷售機前面的架子，在架子上補滿各種品牌的飲料。銷售員還要在機器中加零錢。然后他放好銷售機的前端架子，并鎖好機器。 這個用例的前置條件是一個時間間隔的流逝，后置條件是供貨人在機器中放置了新的待售飲料?！肮┴洝庇美?7頁，共97頁。還有一個“取錢”用例，同樣也是因為一段時間的流逝，收款人發(fā)起了這個用例。它的前期工作步驟與”供貨“一樣，也是打開銷售機前端架子。收款人從機器中取出錢，然后按照”供貨“步驟，放回架子鎖好機器。 這個用例的前置條件也是時間間隔的流逝，后置條件是收款人收到了錢。“取錢”用例第18頁，共97頁。3.1.1 參與者 參與者是用例的啟動者，參與者處于用例的外部并且能夠初始

9、化一個用例，但它并不是所描述系統(tǒng)的一部分，它可能是人或其他外界系統(tǒng)。 參與者是指存在于系統(tǒng)外部并直接與系統(tǒng)進行交互的人、系統(tǒng)、子系統(tǒng)或類的外部實體的抽象。 每個參與者都可以參與一個或多個用例，每個用例也可以有一個或多個參與者。用一個小人表示：第19頁，共97頁。 特別注意：參與者并不僅僅是指一個人，它代表的是一個集合。也就是說，參與者（角色）是一個群體概念，代表的是一類能使用某個功能的人或事，不能將角色的名字表示成角色的某個實例（如，張三）。 參與者是啟動用例的前提條件，先發(fā)送消息給用例，初始化用例后，用例開始執(zhí)行，在執(zhí)行過程中，該用例也可能向一個或多個角色發(fā)送消息第20頁，共97頁。參與者可

10、以分為兩種類型：（1）主要參與者和次要參與者。 主要參與者指的是執(zhí)行系統(tǒng)主要功能的參與者，次要參與者指的是使用系統(tǒng)次要功能的參與者。 標識出主要參與者有利于找出系統(tǒng)的核心功能。（2）發(fā)起參與者和參加參與者 發(fā)起參與者發(fā)起用例的執(zhí)行過程，一個用例只有一個發(fā)起參與者，可以有若干個參與者。 在用例中標識出發(fā)起參與者是一個有用的做法。第21頁，共97頁。通過回答一些問題，可以幫助建模者發(fā)現角色：使用系統(tǒng)主要功能的人是誰（即主要角色）？需要借助于系統(tǒng)完成日常工作的人是誰？誰來維護、管理系統(tǒng)（次要角色），保證系統(tǒng)正常工作？系統(tǒng)控制的硬件設備有哪些？系統(tǒng)需要與哪些其它系統(tǒng)交互？對系統(tǒng)產生的結果感興趣的人或事

11、是哪些？第22頁，共97頁。3.1.2 用例 用例是參與者可感受到的系統(tǒng)服務或功能單元。它定義了系統(tǒng)如何被參與者使用，描述了參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)發(fā)生的對話。 用例是站在用戶的角度上（從系統(tǒng)的外部）來描述系統(tǒng)的功能。 當系統(tǒng)有很多參與者時，用例是捕獲系統(tǒng)需求最好的選擇。 所有用例都應有名稱，建議使用動名詞為用例命名。 用例名可以包括任意數目的字母、數字和除冒號以外的大多數標點符號，用例的名字是一個能準確描述功能的動詞短語或動詞詞組。第23頁，共97頁。用例具有3個明顯的特征： （1）用例表明的是一個類，而不是某個具體的實例 （2）用例必須由某一個參與者觸發(fā)激活后才能執(zhí)行

12、，即每個用例至少應該涉及一個參與者 （3）用例是一個完整的描述橢圓來表示用例第24頁，共97頁?！盎仡櫋憋嬃箱N售機在前面的分析中，我們獲得了系統(tǒng)中有3個用例，分別是“Buy soda（買飲料）”、“Restock（供貨）”、“Collect（收款）”。參與者有Customer（顧客）、Suppliers Representative（供貨代表）和Collector（收款人）。第25頁，共97頁。跟蹤場景中的步驟 每個用例就是一組場景的集合，而每個場景又是一個步驟序列。而這些步驟在上圖中并沒有表現出來。通常也不用附加注釋來說明這些用例。因為如果對每個用例都附加注釋進行說明，則布圖就很混亂。那么如

13、何并在哪里記錄和跟蹤這些場景中的步驟呢？第26頁，共97頁。用例圖通常是供客戶和開發(fā)組參考的一部分。每個用例中的場景在文檔中要描述下列內容：發(fā)起用例的參與者用例的假設條件用例中的前置條件場景中的步驟場景完成后的后置條件從用例中獲益的參與者 要說明一個場景中的步驟，還可以使用UML活動圖對場景進行描述。第27頁，共97頁。通過詢問下列問題就可發(fā)現用例：角色需要從系統(tǒng)中獲得哪種功能？角色需要做什么？角色需要讀取、產生、刪除、修改或存儲系統(tǒng)中的某種信息嗎？系統(tǒng)中發(fā)生的事件需要通知角色嗎？或者角色需要通知系統(tǒng)某件事嗎？這些事件（功能）能干些什么？如果用系統(tǒng)的新功能處理角色的日常工作是簡單化，還提高了工

14、作效率？系統(tǒng)當前的這種實線方法要解決的問題是什么？第28頁，共97頁。補充：子系統(tǒng)（visual Paradigm有）用來展示系統(tǒng)的一部分功能，這部分功能聯(lián)系緊密。第29頁，共97頁。3.1.3 關系用例圖之間的關系分為3種：用例和用例之間的關系；參與者和參與者之間的關系；用例和參與者之間的關系。第30頁，共97頁。一、用例之間的關系 一般情況下，能夠在用例之間抽象出包含、擴展和泛化這3種關系。 包含即在一個用例中重用另一個用例在步驟； 擴展允許通過對已有用例增加步驟創(chuàng)建一個新的用例； 泛化指一個用例繼承了另一個用例。 有時也會有分組的關系，分組是一組用例的簡單組織方式。第31頁，共97頁。1

15、.泛化 用例的泛化是指一個父用例可被特化形成多個子用例，而父用例和子用例之間的關系就是泛化關系。 在用例的泛化關系中，子用例繼承了父用例所有的結構、行為和關系。 子用例還可添加、覆蓋、改變繼承的行為 在UML中，用例的泛化關系是從子用例指向父用例的三角箭頭來表示。 當發(fā)現系統(tǒng)中有兩個或多個用例在行為、結構和目的方面存在共性時，就可用泛化關系。 這時，可用一個新的用例來描述這些共有部分，這個新的用例就是父用例。第32頁，共97頁。 假設正在對一臺飲料機建模，這臺飲料銷售機允許顧客選擇買一罐飲料或是買一杯飲料。在這種情況下，“Buy Soda”就是一個父用例，“Buy a can of soda”

16、和“Buy a cup of Soda”就是子用例。用例之間的泛化關系建模與類之間泛化關系建模方法相同，用一條帶空心三角形箭頭的實線從子用例指向父用例。第33頁，共97頁。例： 飛機訂票系統(tǒng)中，預訂飛機票有兩種方式，一種是通過電話預訂，另一種是通過網上預訂。繼承關系，子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的?！炯^指向】：指向父用例第34頁，共97頁。2. 擴展(Extend) 有時我們可通過對已有用例增加一些額外的步驟來建立新的用例。（指用例功能的延伸，相當于為基礎用例提供一個附加功能

17、） 在“供貨”這個用例中，在給機器補充新飲料的時候，供貨代表注意到有些品牌的飲料銷售的好，有些品牌的飲料銷售不好。在這種情況下，他不是簡單的把所有品牌的飲料補充給機器，而是把一些銷售情況下不太好的飲料取出來，用銷售情況好的飲料來代替它們。同時供貨代表還要在機器前修改飲料品種的指示牌。 如果我們把上述的步驟加入到“供貨”用例，我們將得到一個新的用例，不妨稱它為“根據銷售情況供貨”。這個新用例是對原用例的擴展，這種技術叫做擴展用例。第35頁，共97頁。 在一定條件下，把新的行為加入到已有的用例中，獲得的新用例稱為擴展用例（Extension），原有的用例稱為基礎用例（Base），從擴展用例到基礎用

18、例的關系就是擴展關系。 擴展是兩個用例之間的關系，它使得每個用例可以通過擴展用例向基礎用例中添加額外的行為來擴展基礎用例的功能。 用例的擴展機制允許從一個基礎用例開始開發(fā)一個復雜的系統(tǒng)，并且能夠在不改變基礎用例的前提下向基礎用例中擴展更多的行為。第36頁，共97頁。 一個基礎用例可以擁有一個或多個擴展用例，這些擴展用例可以一起使用。 在UML中，擴展關系通過帶箭頭的虛線段加來表示，箭頭指向基礎用例。 擴展關系往往用于處理異?；驑嫾`活的系統(tǒng)框架。擴展關系還可用于處理基礎用例中的那些不易描述的問題。第37頁，共97頁。【箭頭指向】：指向基礎用例第38頁，共97頁。例：圖書館紫系統(tǒng)中管理用例圖，其

19、中基礎用例是“用戶管理”，擴展用例是是“用戶級別設置”。 一般情況下，只需執(zhí)行“用戶管理”用例即可。但是如果要設置用戶級別，就不能執(zhí)行用例的常規(guī)操作了，如果去修改“用戶管理”用例，就又增加了系統(tǒng)的復雜性。 此時，可以在基礎用例“用戶管理”中增加插入點，這樣如果想設置用戶級別，就執(zhí)行擴展用例。第39頁，共97頁。舉例：飲料銷售機 上面提及的“Restock”用例是另一個用例“Reatock according to sales（根據銷售情況供貨）”的基礎。不是簡單地把各種品牌的聽裝飲料以同樣的數目補充個飲料機器，供貨代表要注意到用銷售情況好的品牌來代替銷售情況不好的品牌，并進行相應的補充。 在“

20、Restock”用例中，新步驟（關注銷量并安排添貨）發(fā)生在供貨代表打開機器準備向機器中補充飲料時。因此在這個例子中，擴展點是“before filling the compartments（補充飲料）”。第40頁，共97頁。 與包含關系相似，可視化擴展關系也是用一條依賴線（帶箭頭的虛線），沿線上加上一個用雙尖括號擴起來的“extend”關鍵字。在基用例中，擴展點出現在“Extension point”（如果有多個擴展點，就是“Extension points”）的下方。第41頁，共97頁。例： 圖書管理系統(tǒng)中，在一切順利的情況下，只需要執(zhí)行”還書“用例即可。但是，如果借書超期或者書有所破損，借

21、書用戶就要交納一定的罰金。第42頁，共97頁。3. 包含(Include)包含關系用來把一個較復雜用例所表示的功能分解成較小的步驟。 在“供貨”和“取貨”用例中，也許你會發(fā)現會有一些相同的步驟。兩個用例都以打開機器為起始點，以關閉和鎖好機器為終點。能不能消除用例中的重復步驟呢？ 可以。方法是從各個步驟序列中抽取出公共步驟形成一個每個用例都要使用的附加用例?？梢詫ⅰ伴_機”和“拉出飲料架”這兩個步驟合并為一個叫做“打開銷售機”的用例，將“放回架子”和“鎖機器”合并為一個叫做“關閉銷售機”的用例。第43頁，共97頁。 有了這兩個新用例，用例“供貨”就可以用例“打開銷售機”為開始，供貨代表通過前面步驟

22、，以用例“關閉銷售機”結束。類似地，用例“收款”也以“打開銷售機”為開始，進行前面的步驟，以關閉“銷售機”結束。 如上所述，“供貨”和“收款”這兩個用例都包含了新的用例。這種技術被稱為“包含用例”。 包含關系指用例可簡單地包含其它用例具有的行為，并把它所包含的用例行為作為自己行為的一部分。 在UML中，包含關系是通過帶箭頭的虛線段加來表示，箭頭由基礎用例(Base)指向被包含用例(Inclusion)。第44頁，共97頁。箭頭指向】：指向分解出來的功能用例第45頁，共97頁。 在處理包含關系時，具體的做法是把幾個用例的公共部分單獨抽象出來成為一個新的用例。主要有以下的兩種情況需要用到包含關系：

23、 一個用例的功能過多、事件過于復雜時，可以把某一段事件流抽象成為一個被包含的用例，以達到簡化描述的目的。 當多個用例用到同一段行為時，則可把這段共同的行為單獨抽象為一個用例，然后讓其他用例來包含這一用例。第46頁，共97頁。例： 有一個資源網站，維護人員要對網站的資源進行維護，包括添加資源、修改資源和刪除資源。其中，添加資源和修改資源后都要對新添加的資源和修改的資源進行預覽，用來檢查添加和修改操作是否正確完成。第47頁，共97頁。包含關系和擴展關系也存在較大的區(qū)別： 基礎用例的執(zhí)行并不一定會涉及擴展用例，擴展用例只有滿足一定條件時才會被執(zhí)行。 而在包含關系中，當基礎用例執(zhí)行后，被包含用例是一定

24、會被執(zhí)行的。 在擴展關系中，基礎用例提供了一個或多個插入點，擴展用例為這些插入點提供了需要插入的行為。 而在包含關系中，插入點只能有一個。 即使沒有擴展用例，擴展關系中的基礎用例本身是完整的。 而對于包含關系，基礎用例在沒有被包含用例的情況下就是不完整的存在。第48頁，共97頁。 我們來細看“Restock”和“Collect”用例。這兩個用例都從開鎖和拉開銷售機的門開始，都以關門和上鎖結束。第1步建立了“Expose the inside（打開銷售機）”用例，并且第2步創(chuàng)建了“Unexpose the inside（關閉銷售機）”用例。“Restock”和“Collect”兩者都包含了這兩個

25、新用例。 要表達用例的包含關系，可以使用類之間依賴關系的表示符號，也就是連接兩個類之間的虛線，箭頭指向被依賴的類。在線上要加一個關鍵字，也就是用雙尖括號擴起來的“include”。第49頁，共97頁。分組 在一些用例圖中，用例圖的數目可能非常多，這時就需要組織這些用例。這種情況在一個系統(tǒng)包含很多個子系統(tǒng)時就會出現。另一種可能是，當你按順序和用戶會談，收集系統(tǒng)需求時，每個需求必須用一個單獨的用例來表達。 最直接的方法是把相關的用例放在一個包中組織起來。第50頁，共97頁。二、參與者之間的關系 參與者與參與者之間的關系主要是泛化關系。泛化關系的含義就是把某些參與者的共同行為提取出來表示通用行為。

26、在UML圖中，使用帶空心三角箭頭的實線表示泛化關系，箭頭指向超類參與者。 在需求分析中，常常遇到用戶權限的問題第51頁，共97頁。就是通常理解的繼承關系，子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。箭頭指向】：指向父用例第52頁，共97頁。三、參與者和用例之間的關系 參與者和用例之間屬于關聯(lián)關系(Association)。關聯(lián)關系是雙向的一對一的關系，這種關系表明了哪個參與者與用例通信。 用例圖中參與者和用例之間的關系使用帶箭頭或者不帶箭頭的線段來描述，箭頭表示在這一關系中哪一方是對話的主

27、動發(fā)起者，箭頭所指方是對話的被動接受者。 如果不想強調對話中的主動與被動關系，可以使用不帶箭頭的線段。第53頁，共97頁。參與者與用例之間的通信，任何一方都可發(fā)送或接受消息。箭頭指向】：指向消息接收方第54頁，共97頁。包含(include)、擴展(extend)、泛化(Inheritance) 的區(qū)別條件性：泛化中的子用例和include中的被包含的用例會無條件發(fā)生，而extend中的延伸用例的發(fā)生是有條件的；直接性：泛化中的子用例和extend中的延伸用例為參與者提供直接服務，而include中被包含的用例為參與者提供間接服務。對extend而言，延伸用例并不包含基礎用例的內容，基礎用例也

28、不包含延伸用例的內容。對Inheritance而言，子用例包含基礎用例的所有內容及其和其他用例或參與者之間的關系；第55頁，共97頁。例子第56頁，共97頁。四、系統(tǒng)邊界 系統(tǒng)邊界是指系統(tǒng)與系統(tǒng)之間的邊界，這里的系統(tǒng)可認為是由一系列的相互作用的元素形成的具有特定功能的有機整體。 用例圖中的系統(tǒng)邊界用來表示正在建模系統(tǒng)的的邊界。邊界內表示系統(tǒng)的組成部分，邊界外表示系統(tǒng)外部。Visio建模工具可畫出。 在項目開發(fā)過程中，邊界是很重要的概念。系統(tǒng)與環(huán)境之間存在邊界，子系統(tǒng)與其他子系統(tǒng)之間存在邊界，子系統(tǒng)與整體系統(tǒng)之間存在邊界。第57頁，共97頁。3.2 確定參與者 在獲取用例前首先要確定系統(tǒng)的參與者

29、，確定參與者可從幾方面來考慮，如書第44頁 確定參與者時要注意幾個問題，如書第44頁所述。第58頁，共97頁。3.3 確定用例 確定用例的最好方法是從分析系統(tǒng)參與者開始，在這個過程中往往會發(fā)現新的參與者。 當找到參與者之后，就可以根據參與者來確定系統(tǒng)的用例，主要是看各參與者如何使用系統(tǒng)，需要系統(tǒng)提供什么樣的服務。第59頁，共97頁。3.4 用例的粒度 用例的粒度指的是用例所包含的系統(tǒng)服務或功能單元的多少。用例的粒度越大，用例包含的功能就越多，反之則包含的功能越少。用例的粒度對于用例模型來說很重要。 在確定用例粒度的時候，應該根據系統(tǒng)具體問題具體分析。當大致確定用例個數后，就可以很容易確定用例粒

30、度的大小。第60頁，共97頁。3.5 用例規(guī)約 有時也要對每一個用例還需要有詳細的描述信息，以便讓其他人對于整個系統(tǒng)有更加詳細的了解，這些信息包含在用例規(guī)約之中。 用例模型是由用例圖和每個用例的詳細描述用例規(guī)約所組成的。第61頁，共97頁。每個用例的用例規(guī)約應包含以下內容：（1）簡要說明 對用例作用和目的的簡要描述（2）事件流 包括基本流和備選流?；玖髅枋龅氖怯美幕玖鞒?，是指用例“正?！边\行時的場景。備選流描述的是用例執(zhí)行過程中可能發(fā)生的異常和偶爾發(fā)生的情況。（3）用例場景 同一個用例在實際執(zhí)行的時候會有很多不同的情況發(fā)生，稱之為用例場景。也可以說用例場景就是用例的實例。第62頁，共97

31、頁。（4）特殊需求 指的是一個用例的非功能性需求和設計約束。非功能性需求包括可靠性、性能、可用性和可擴展性等。設計約束可以包括開發(fā)工具、操作系統(tǒng)及環(huán)境、兼容性。（5）前置條件 執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。 （6）后置條件 用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。第63頁，共97頁。運用用例模型舉例(網上論壇)一個基本的網上論壇系統(tǒng)，大致有如下的流程： 1、用戶（一般為游客或注冊會員）登錄進入論壇，就某個帖子的主題展開討論； 通過發(fā)帖功能發(fā)布新的主題； 通過回帖功能回復已有的主題； 通過搜索功能查找已有的主題； 2、 論壇管理員通過管理功能創(chuàng)建、編輯、刪除論壇的板塊；管理注冊用戶和管理帖子。第

32、64頁，共97頁。運用用例模型舉例(網上論壇)一、理解領域 論壇的用戶主要分為三種： 普通用戶即游客； 論壇的注冊會員； 論壇的管理員。 三者的身份不同，權限不同，所以具體的功能需求也不同。第65頁，共97頁。對普通用戶來說，需要具有以下的兩個功能：（1）無須注冊即可以瀏覽論壇的信息，系統(tǒng)提供論壇文章的查詢和閱讀功能，即提供對應文章的標題信息以及詳細內容。 （2）如果要想對某個主題發(fā)帖和回復，則該用戶必須先注冊成為論壇注冊的會員。系統(tǒng)提供新會員的注冊功能，在用戶輸入個人信息后，經檢查注冊信息有效后，將注冊會員的信息保存到相應的數據庫中。第66頁，共97頁。 對于注冊會員，除了普通用戶所有的功能

33、，還擁有以下功能 （1）要想針對主題發(fā)帖或回復必須是登錄的注冊用戶。無論在進入論壇首頁時還是在發(fā)帖和回帖時，進行登錄都是可以的。注冊會員在登錄頁面中要輸入注冊的用戶賬號和密碼，通過身份驗證才能獲得發(fā)帖和回復的權限。 （2）注冊會員可以針對某一主題發(fā)表帖子（文章）和修改發(fā)帖的內容。 （3）注冊會員能夠對某一個主圖展開討論，發(fā)表意見，并進行回復。 （4）注冊會員可以修改自己的個人會員信息、修改密碼、找回密碼和注銷。第67頁，共97頁。 對于論壇管理員來說，其功能范圍包括以下內容： （1） 當網上論壇會員注冊后，系統(tǒng)會在數據庫中加入會員的資料，包括會員名稱、會員密碼、會員E-mail等個人信息。論壇

34、管理員對會員資料進行管理，可查看用戶的基本信息、刪除該用戶的信息、修改會員的積分和排行等。 （2）根據不同的討論內容，論壇管理員將整個討論區(qū)劃分成不同的板塊，會員可以選擇進入不同的討論區(qū)，允許管理者對版塊進行調整，刪除不必要的版塊，修改版塊的名稱、類型和數量，同時提供不同討論區(qū)中包括文章數量的統(tǒng)計功能。 （3）論壇管理員能夠對會員發(fā)表的帖子進行修改、刪除內容反動或不健康的帖子、轉移/指定/設置精華帖，控制帖子的點擊率等操作。第68頁，共97頁?？蓸嫿ǔ鼍W上論壇的參與者包含以下4種：（1）用戶。 泛指所有使用網上論壇系統(tǒng)的人，是專門抽象出來的一個參與者。（2）普通用戶。 也就是游客，沒有在論壇中

35、進行注冊的用戶，無權發(fā)帖和回帖，僅能瀏覽論壇文章。（3）注冊會員。 已經注冊成為論壇會員的用戶，登錄論壇后即可擁有發(fā)帖和回帖的權限。 （4）管理員。 擁有對本論壇進行設置管理、會員管理、板塊管理、帖子管理和用戶管理的權限。二、理解用戶第69頁，共97頁。三、理解用例對普通用戶來說，可通過本系統(tǒng)進行如下活動： 在網上論壇中進行注冊成為注冊會員。 在論壇中查詢帖子（文章）。 在論壇中瀏覽帖子的具體內容。第70頁，共97頁。 對于注冊會員，除了普通用戶所有的功能，還可進行以下活動：登錄網上論壇。在論壇中發(fā)帖和回復貼子，包括修改發(fā)帖的內容。修改個人注冊信息，包括修改登錄密碼。在忘記登錄密碼時，可以找回

36、該密碼?？梢栽诰€注銷登錄。第71頁，共97頁。對于論壇管理員，可以通過本系統(tǒng)進行如下的活動：對論壇會員進行管理，包括刪除會員、設置會員等級、查詢會員信息、添加會員等。對論壇的帖子進行管理，包括帖子置頂、設置精華貼、刪除帖子、修改帖子等。對論壇板塊分類進行管理，包括添加板塊和刪除板塊等。登錄到BBS網上論壇。第72頁，共97頁。第73頁，共97頁。 思考題1：1、發(fā)起一個用例的實體被稱為什么？2、包含用例是什么含義？3、擴展用例是什么含義？4、用例和場景是同一概念么？第74頁，共97頁。思考題2系統(tǒng)管理員主要職責是管理用戶、修改所有用戶的密碼、管理用戶的權限，還可以瀏覽所有用戶的信息。第75頁，

37、共97頁。思考題3根據如下關于電梯控制的問題描述，繪制一個用例圖 每部電梯都有樓層按鈕，每一樓層有一組。乘坐電梯的人可以按下樓按鈕，按鈕被按下時指示燈會閃亮，然后通知電梯運行到指定的樓層。等電梯到達指定樓層時，按鈕停止指示燈閃亮。乘客在必要時可以按下緊急求助按鈕，該按鈕會自動發(fā)出求救信號。技術員可以通過一個控制按鍵激活或終止電梯的樓層按鈕。出于安全方面的考慮，只有保安人員可以通過一個控制鍵打開地下室的電梯樓層按鈕。所有電梯都是通過大廳前臺的一個控制中心控制的。第76頁，共97頁。課后練習題畫出銀行取款過程的用例圖。問題描述為：儲戶用存折取款，首先填寫取款單，根據“ 銀行卡”中的信息檢驗取款單與

38、存折，如有問題，將問題反饋給儲戶，否則，登錄“儲戶存款數據庫”，修改相應數據，并更新“銀行卡”，同時發(fā)出付款通知，出納向儲戶付款。第77頁，共97頁。實例講解（一）建立項目與資源管理系統(tǒng)的用例圖。 系統(tǒng)的主要功能是：項目管理、資源管理和系統(tǒng)管理。項目管理包括項目的增加、刪除、更新等功能。資源管理包括對資源和技能的添加、刪除和更新、系統(tǒng)管理包括系統(tǒng)的啟動和關閉，數據的存儲和備份等功能。第78頁，共97頁。 實例2 醫(yī)院病房監(jiān)護系統(tǒng)一、問題描述 為了對危重病人進行實時監(jiān)護，隨時了解病人病情，及時進行處理，建立病房監(jiān)護系統(tǒng)。病癥監(jiān)視器安置在每個病床，通過網絡將病人的病癥信號（組合）實時傳送到中央監(jiān)護

39、系統(tǒng)進行分析處理。在中心值班室里，值班護士使用中央監(jiān)護系統(tǒng)對病員的情況進行監(jiān)控，監(jiān)護系統(tǒng)實時地將病人的病癥信號與標準的病診信號進行比較分析，當病癥出現異常時，系統(tǒng)會立即自動報警，并打印病情報告和更新病歷。系統(tǒng)根據醫(yī)生的要求隨時打印病人的病情報告，系統(tǒng)定期自動更新病歷。第79頁，共97頁。請對系統(tǒng)需求進行分析！經過初步的需求分析，得到系統(tǒng)功能要求：1. 監(jiān)視病員的病癥（血壓、體溫、脈搏等）2. 定時更新病歷3. 病員出現異常情況時報警。4. 隨機地產生某一病員的病情報告。產生病情報告監(jiān)視病情更新病歷第80頁，共97頁。二、簡單的需求分析說明對“醫(yī)院病房監(jiān)護系統(tǒng)”進行分析，確定系統(tǒng)的主要功能如下：

40、1. 病癥監(jiān)視器可以將采集到的病癥信號（組合），格式化后實時的傳送到中央監(jiān)護系統(tǒng)。2. 中央監(jiān)護系統(tǒng)將病人的病癥信號分解后與標準的病癥信號庫里的病癥信號的正常值進行比較，當病癥出現異常時系統(tǒng)自動報警。3. 當病癥信號異常時，系統(tǒng)自動更新病歷并打印病情報告。4. 值班護士可以查看病情報告并進行打印。5. 醫(yī)生可以查看病情報告，要求打印病情報告，也可以查看或要求打印病歷。6. 系統(tǒng)定期自動更新病歷。需求分析第81頁，共97頁。1. 通過以下6個問題識別角色(1)誰使用系統(tǒng)的主要功能？(2)誰需要系統(tǒng)的支持以完成日常工作任務？(3)誰負責維護，管理并保持系統(tǒng)正常運行？(4)系統(tǒng)需要應付（或處理）哪些

41、硬設備？(5)系統(tǒng)需要和哪些外部系統(tǒng)交互？(6)誰（或什么）對系統(tǒng)運行產生的結果（值）感興趣？三、建立系統(tǒng)的用例模型值班護士、醫(yī)生、病人值班護士、醫(yī)生系統(tǒng)管理員監(jiān)護器,網絡,報警系統(tǒng)標準病癥信號庫、病歷庫同(2)第82頁，共97頁。通過回答這6個問題以后，再進一步分析可以識別出本系統(tǒng)的4個角色：值班護士，醫(yī)生，病人，標準病癥信號庫。角色描述模板：角色：病 人角色職責：提供病癥信號角色職責識別：負責生成、實時提供各種病癥信號。角色：值班護士角色職責：負責監(jiān)視病人的病情變化角色職責識別： (1)使用系統(tǒng)主要功能 (2)對系統(tǒng)運行結果感興趣角色:標準病癥信號庫角色職責：負責向系統(tǒng)提供病癥信號的正常值

42、角色職責識別： (1)負責保持系統(tǒng)正常運行 (2)與系統(tǒng)交互角色：醫(yī) 生角色職責：對病人負責，負責處理病情的變化角色職責識別： (1)需要系統(tǒng)支持以完成其日常工作 (2)對系統(tǒng)運行結果感興趣第83頁，共97頁。. 識別用例回答下面的問題： 與系統(tǒng)實現有關的主要問題是什么？ 系統(tǒng)需要哪些輸入/輸出？這些輸入/輸出從何而來？到 哪里去？ 執(zhí)行者需要系統(tǒng)提供哪些功能？ 執(zhí)行者是否需要對系統(tǒng)中的信息進行讀、創(chuàng)建、修改、刪除或存儲？通過分析可以初步識別出系統(tǒng)的用例為： 中央監(jiān)護，病癥監(jiān)護，提供標準病癥信號，病歷管理，病情報告管理。第84頁，共97頁。進一步將用例細化，即分解用例：1. 中央監(jiān)護 分解:

43、a 分解信號 將從病癥監(jiān)護器傳送來的組合病癥信號分解為系統(tǒng)可以處理的信號。 b 比較信號 將病人的病癥信號與標準信號比較 。 c 報警 如果病癥信號發(fā)生異常（即高于峰值），發(fā)出報警信號。 d 數據格式化 將處理后的數據格式化以便寫入病歷庫 。2. 病癥監(jiān)護 分解: e 信號采集 采集病人的病癥信號。 f 模數轉換 將采集來的模擬信號轉換為數字信號。 g 信號數據組合 將采集到的脈搏，血壓等信號數據組 合為一組信號數據。 h 采樣頻率改變 根據病人的情況改變監(jiān)視器采樣頻率用例細化第85頁，共97頁。3.提供標準病癥信號 i（此用例不分解）4. 病歷管理 分解為：j 生成病歷。將各種病癥符號經過格

44、式化后，加上時間戳，存入病歷庫。k 查看病歷。醫(yī)生隨時根據需要在計算機屏幕上查看病歷。l 更新病歷 。定時清理病歷庫，更新病歷。m 打印病歷。隨時打印病歷，作為醫(yī)生診斷依據。5. 病情報告管理 分解為：n 顯示病情報告 在顯示器上顯示病情o 打印病情報告 在打印機打印病情報告用例細化第86頁，共97頁。給出細化的用例圖細化的用例圖病人模數轉化數據格式化值班護士報警信號采集比較信號標準病癥信號庫 醫(yī)生信號數據組合采樣頻率改變提供標準病癥信號生成病歷查看病歷更新病歷打印病歷顯示病情報告打印病情報告分解信號第87頁，共97頁。用例名： 中 央 監(jiān) 視執(zhí)行者： 值班護士、醫(yī)生目標： 對病人的病癥信號進

45、行監(jiān)測、處理，超過極限報警。功能描述：1.分解信號：將從病癥監(jiān)護器傳送來的組合病癥信號分解為系統(tǒng)可以處理的信號。2.比較信號：將病人的病癥信號與標準信號比較 。3.報警：如果病癥信號發(fā)生異常（即高于峰值），發(fā)出報警信號。4.數據格式化：將處理后的數據格式化以便寫入病歷庫 。其他非功能需求: 高可靠性、實時性主要步驟：按設定頻率連續(xù)接收來自各病人的病癥信號，并進行分解。將病人的病癥信號與專家系統(tǒng)（標準病癥信號庫）中的標準信號進行比較判斷是否超過極限值。若超過極限值，進行報警，并及時更新病歷和打印病情報告。相關用例：病癥監(jiān)護、提供標準病癥信號、病歷管理、病情報告管理。相關信息：(優(yōu)先級、性能、頻執(zhí)行率)：優(yōu)先級：報警處理具有最高優(yōu)先級3,一般病歷管理為1,其他為2.性能：實時性、高可靠性頻執(zhí)行率：根據病情嚴重程度 1230次/小時用例“中央監(jiān)護”描述模板 第88頁，共97頁。 實例講解3 超市信息管理系統(tǒng)根據需求分析，系統(tǒng)包括