第三章 用例圖

第三章用例圖本章導(dǎo)讀知道參與者、用例和關(guān)系的概念了解用例的粒度和規(guī)約掌握參與者和用例的確定關(guān)系思考學(xué)習(xí)以下內(nèi)容什么是用例？創(chuàng)建、包含和擴展用例等的思想如何開始一個用例分析？如何表示一個用例模型？如何可視化用例之間的關(guān)系？用戶對系統(tǒng)的使用方式?jīng)Q定了系統(tǒng)如何設(shè)計和構(gòu)造。用例是能夠幫助分析員和用戶確定系統(tǒng)使用情況的UML組件。一組用例就是從用戶的角度出發(fā)對如何使用系統(tǒng)的描述?？梢哉J為用例是系統(tǒng)的一組使用場景。用例圖的主要要素是參與者、用例和關(guān)聯(lián)。

用例圖主要用于描述系統(tǒng)的行為及各種功能之間的關(guān)系，是描述參與者（Actor）與用例以及用例與用例之間關(guān)系的圖。用例圖從用戶和外部系統(tǒng)的角度，分析和考察系統(tǒng)的行為，并通過參與者與系統(tǒng)之間的交互關(guān)系描述系統(tǒng)對外提供的功能特性，用例圖用于描述系統(tǒng)與外部系統(tǒng)及用戶之間的交互。

UML的用例圖由參與者、用例及它們之間的關(guān)系組成，它的表達方式為：用例圖=參與者+用例+關(guān)系UseCaseDiagram=Actor+UseCase+Relationship3.1用例圖的構(gòu)成用例圖可以用于描述系統(tǒng)的功能性需求和系統(tǒng)功能的使用環(huán)境。用例圖可視化地描述了系統(tǒng)外部的使用者（抽象為參與者）和使用者使用系統(tǒng)時系統(tǒng)為這些使用者提供的一系列服務(wù)（抽象為用例），并清晰地描述了：參與者和參與者之間的泛化關(guān)系；用例和用例之間的包含關(guān)系、泛化關(guān)系、擴展關(guān)系；用例和參與者之間的關(guān)聯(lián)關(guān)系要用在用例圖上顯示某個用例：使用人形符號繪制一個參與者；繪制一個橢圓表示用例，將用例的名稱放在橢圓的中心或橢圓下面的中間位置；使用帶箭頭或不帶箭頭的線段來描述參與者和用例之間的關(guān)系。舉例：飲料銷售機假設(shè)你現(xiàn)在正著手設(shè)計一臺飲料銷售機。為了獲得用戶的觀點，你會見了許多可能的用戶以了解這些用戶將如何與這臺機器交互。飲料銷售機的主要功能是允許一個顧客購買一罐飲料，很可能用戶立刻就能告訴你一些有關(guān)的場景（換句話說就是用例），你可以給這組場景加上一個標簽“買飲料”。下面我們來考察這個用例中每一種可能的場景。（1）用例“買飲料”這個用例的參與者是買飲料的顧客。顧客將錢插入銷售機觸發(fā)了這個用例的場景被執(zhí)行，然后用戶進行選擇。如果一切順利，銷售機內(nèi)至少還存儲有一罐被選擇的飲料，則銷售機會自動彈出這種飲料給顧客。上面的“買飲料”場景是唯一可描述的場景么？。顯然，我們立即會想到還有其他的場景。顧客所要購買的飲料銷售機中可能沒有。顧客投入的錢數(shù)不是剛好等于購買飲料所需要的錢。應(yīng)該如何設(shè)計飲料銷售機來處理這些場景呢？先看看沒有所需的飲料這個場景，它是用例“買飲料”的另一場景?？梢园堰@個場景看成是用例執(zhí)行時的一條可選路徑。用例是由顧客在銷售機中插入錢幣所發(fā)起的。然后客戶進行一個選擇，銷售機中至少要有一罐選擇的飲料，如果沒有，銷售機就給顧客提示一個信息，告訴顧客沒有這種品牌的飲料。沒有所需飲料的場景理想情況下，顧客看到這條消息后會立即選擇其它品牌的飲料。銷售機也必須提供給顧客取回原來的錢的選項。這表示，銷售機應(yīng)給顧客兩種選擇：讓顧客選擇另一種飲料并且給顧客提供這種飲料（如果這種飲料還有存貨的話）或者讓顧客選擇退錢。

該場景的前置條件是顧客感到口渴，后置條件是顧客得到一罐飲料或者顧客投入的錢被退回。另一種“缺貨”的場景?！爸付ㄆ放频娘嬃鲜弁辍毕@示在機器上，直到對這臺機器補充為止。在這種情況下，用戶不再輸入錢了。銷售機的客戶可能更喜歡第一種場景：如果顧客已經(jīng)投了錢，應(yīng)該讓顧客做另外一種選擇而不是要機器退錢?！叭必洝钡膱鼍熬o接著讓我們來看看“付款數(shù)不正確”的這個場景。顧客按照通常的方式發(fā)起了這個用例，并進行了一個選擇。假設(shè)這是機器中備有選擇的飲料。如果機器中剛好存有適合的零錢，那么機器就會退還零錢并交付飲料。如果機器中沒有保存零錢，它將退還錢，并顯示一條消息提示用戶投入適當(dāng)?shù)牧沐X。

前置條件和前面場景一樣，后置條件是顧客得到一罐飲料和找回零錢或者按原款歸還錢?！案犊顢?shù)不正確”的場景另一種可能是機器的儲備零錢一旦用光，就會在機器上顯示一條小子告訴用戶需要投入適當(dāng)?shù)牧沐X。直到對這臺機器補充零錢為止，這條消息才會消失。（2）其他用例已經(jīng)從用戶的觀點考察了飲料銷售機。除了這些用戶外，當(dāng)然還有其他人加入。供貨人負責(zé)為銷售機提供飲料，收款人（可能與供貨人是同一個人）負責(zé)定期收集銷售機中的錢。這說明至少需要建立兩個用例：“供貨”和“取錢”，這些用例細節(jié)可以通過與供貨人和收款人交談來獲得?？紤]“供貨”用例。供貨人發(fā)起這個用例是由于某個時間間隔到期所引起的。供貨代表打開銷售機拉出銷售機前面的架子，在架子上補滿各種品牌的飲料。銷售員還要在機器中加零錢。然后他放好銷售機的前端架子，并鎖好機器。

這個用例的前置條件是一個時間間隔的流逝，后置條件是供貨人在機器中放置了新的待售飲料?！肮┴洝庇美€有一個“取錢”用例，同樣也是因為一段時間的流逝，收款人發(fā)起了這個用例。它的前期工作步驟與”供貨“一樣，也是打開銷售機前端架子。收款人從機器中取出錢，然后按照”供貨“步驟，放回架子鎖好機器。

這個用例的前置條件也是時間間隔的流逝，后置條件是收款人收到了錢?！叭″X”用例3.1.1參與者

參與者是用例的啟動者，參與者處于用例的外部并且能夠初始化一個用例，但它并不是所描述系統(tǒng)的一部分，它可能是人或其他外界系統(tǒng)。參與者是指存在于系統(tǒng)外部并直接與系統(tǒng)進行交互的人、系統(tǒng)、子系統(tǒng)或類的外部實體的抽象。

每個參與者都可以參與一個或多個用例，每個用例也可以有一個或多個參與者。特別注意：參與者并不僅僅是指一個人，它代表的是一個集合。也就是說，參與者（角色）是一個群體概念，代表的是一類能使用某個功能的人或事，不能將角色的名字表示成角色的某個實例（如，張三）。參與者是啟動用例的前提條件，先發(fā)送消息給用例，初始化用例后，用例開始執(zhí)行，在執(zhí)行過程中，該用例也可能向一個或多個角色發(fā)送消息參與者可以分為兩種類型：（1）主要參與者和次要參與者。主要參與者指的是執(zhí)行系統(tǒng)主要功能的參與者，次要參與者指的是使用系統(tǒng)次要功能的參與者。

標識出主要參與者有利于找出系統(tǒng)的核心功能。（2）發(fā)起參與者和參加參與者發(fā)起參與者發(fā)起用例的執(zhí)行過程，一個用例只有一個發(fā)起參與者，可以有若干個參與者。

在用例中標識出發(fā)起參與者是一個有用的做法。通過回答一些問題，可以幫助建模者發(fā)現(xiàn)角色：使用系統(tǒng)主要功能的人是誰（即主要角色）？需要借助于系統(tǒng)完成日常工作的人是誰？誰來維護、管理系統(tǒng)（次要角色），保證系統(tǒng)正常工作？系統(tǒng)控制的硬件設(shè)備有哪些？系統(tǒng)需要與哪些其它系統(tǒng)交互？對系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事是哪些？3.1.2用例用例是參與者可感受到的系統(tǒng)服務(wù)或功能單元。它定義了系統(tǒng)如何被參與者使用，描述了參與者為了使用系統(tǒng)所提供的某一完整功能而與系統(tǒng)發(fā)生的對話。

用例是站在用戶的角度上（從系統(tǒng)的外部）來描述系統(tǒng)的功能。當(dāng)系統(tǒng)有很多參與者時，用例是捕獲系統(tǒng)需求最好的選擇。

所有用例都應(yīng)有名稱，建議使用動名詞為用例命名。用例名可以包括任意數(shù)目的字母、數(shù)字和除冒號以外的大多數(shù)標點符號，用例的名字是一個能準確描述功能的動詞短語或動詞詞組。用例具有3個明顯的特征：（1）用例表明的是一個類，而不是某個具體的實例（2）用例必須由某一個參與者觸發(fā)激活后才能執(zhí)行，即每個用例至少應(yīng)該涉及一個參與者（3）用例是一個完整的描述“回顧”飲料銷售機在前面的分析中，我們獲得了系統(tǒng)中有3個用例，分別是“Buysoda（買飲料）”、“Restock（供貨）”、“Collect（收款）”。參與者有Customer（顧客）、Supplier’sRepresentative（供貨代表）和Collector（收款人）。跟蹤場景中的步驟每個用例就是一組場景的集合，而每個場景又是一個步驟序列。而這些步驟在上圖中并沒有表現(xiàn)出來。通常也不用附加注釋來說明這些用例。因為如果對每個用例都附加注釋進行說明，則布圖就很混亂。那么如何并在哪里記錄和跟蹤這些場景中的步驟呢？用例圖通常是供客戶和開發(fā)組參考的一部分。每個用例中的場景在文檔中要描述下列內(nèi)容：發(fā)起用例的參與者用例的假設(shè)條件用例中的前置條件場景中的步驟場景完成后的后置條件從用例中獲益的參與者

要說明一個場景中的步驟，還可以使用UML活動圖對場景進行描述。通過詢問下列問題就可發(fā)現(xiàn)用例：角色需要從系統(tǒng)中獲得哪種功能？角色需要做什么？角色需要讀取、產(chǎn)生、刪除、修改或存儲系統(tǒng)中的某種信息嗎？系統(tǒng)中發(fā)生的事件需要通知角色嗎？或者角色需要通知系統(tǒng)某件事嗎？這些事件（功能）能干些什么？如果用系統(tǒng)的新功能處理角色的日常工作是簡單化，還提高了工作效率？系統(tǒng)當(dāng)前的這種實線方法要解決的問題是什么？3.1.3關(guān)系用例圖之間的關(guān)系分為3種：用例和用例之間的關(guān)系；參與者和參與者之間的關(guān)系；用例和參與者之間的關(guān)系。一、用例之間的關(guān)系

一般情況下，能夠在用例之間抽象出包含、擴展和泛化這3種關(guān)系。

包含——即在一個用例中重用另一個用例在步驟；擴展——允許通過對已有用例增加步驟創(chuàng)建一個新的用例；泛化——指一個用例繼承了另一個用例。有時也會有分組的關(guān)系，分組是一組用例的簡單組織方式。1.泛化用例的泛化是指一個父用例可被特化形成多個子用例，而父用例和子用例之間的關(guān)系就是泛化關(guān)系。在用例的泛化關(guān)系中，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系。子用例還可添加、覆蓋、改變繼承的行為

在UML中，用例的泛化關(guān)系是從子用例指向父用例的三角箭頭來表示。

當(dāng)發(fā)現(xiàn)系統(tǒng)中有兩個或多個用例在行為、結(jié)構(gòu)和目的方面存在共性時，就可用泛化關(guān)系。這時，可用一個新的用例來描述這些共有部分，這個新的用例就是父用例。假設(shè)正在對一臺飲料機建模，這臺飲料銷售機允許顧客選擇買一罐飲料或是買一杯飲料。在這種情況下，“BuySoda”就是一個父用例，“Buyacanofsoda”和“BuyacupofSoda”就是子用例。用例之間的泛化關(guān)系建模與類之間泛化關(guān)系建模方法相同，用一條帶空心三角形箭頭的實線從子用例指向父用例。例：飛機訂票系統(tǒng)中，預(yù)訂飛機票有兩種方式，一種是通過電話預(yù)訂，另一種是通過網(wǎng)上預(yù)訂。2.擴展

有時我們可通過對已有用例增加一些額外的步驟來建立新的用例。在“供貨”這個用例中，在給機器補充新飲料的時候，供貨代表注意到有些品牌的飲料銷售的好，有些品牌的飲料銷售不好。在這種情況下，他不是簡單的把所有品牌的飲料補充給機器，而是把一些銷售情況下不太好的飲料取出來，用銷售情況好的飲料來代替它們。同時供貨代表還要在機器前修改飲料品種的指示牌。如果我們把上述的步驟加入到“供貨”用例，我們將得到一個新的用例，不妨稱它為“根據(jù)銷售情況供貨”。這個新用例是對原用例的擴展，這種技術(shù)叫做擴展用例。

在一定條件下，把新的行為加入到已有的用例中，獲得的新用例稱為擴展用例（Extension），原有的用例稱為基礎(chǔ)用例（Base），從擴展用例到基礎(chǔ)用例的關(guān)系就是擴展關(guān)系。擴展是兩個用例之間的關(guān)系，它使得每個用例可以通過擴展用例向基礎(chǔ)用例中添加額外的行為來擴展基礎(chǔ)用例的功能。用例的擴展機制允許從一個基礎(chǔ)用例開始開發(fā)一個復(fù)雜的系統(tǒng)，并且能夠在不改變基礎(chǔ)用例的前提下向基礎(chǔ)用例中擴展更多的行為。一個基礎(chǔ)用例可以擁有一個或多個擴展用例，這些擴展用例可以一起使用。在UML中，擴展關(guān)系通過帶箭頭的虛線段加<<extend>>來表示，箭頭指向基礎(chǔ)用例。擴展關(guān)系往往用于處理異?；驑?gòu)件靈活的系統(tǒng)框架。擴展關(guān)系還可用于處理基礎(chǔ)用例中的那些不易描述的問題。例：圖書館紫系統(tǒng)中管理用例圖，其中基礎(chǔ)用例是“用戶管理”，擴展用例是是“用戶級別設(shè)置”。一般情況下，只需執(zhí)行“用戶管理”用例即可。但是如果要設(shè)置用戶級別，就不能執(zhí)行用例的常規(guī)操作了，如果去修改“用戶管理”用例，就又增加了系統(tǒng)的復(fù)雜性。此時，可以在基礎(chǔ)用例“用戶管理”中增加插入點，這樣如果想設(shè)置用戶級別，就執(zhí)行擴展用例。舉例：飲料銷售機上面提及的“Restock”用例是另一個用例“Reatockaccordingtosales（根據(jù)銷售情況供貨）”的基礎(chǔ)。不是簡單地把各種品牌的聽裝飲料以同樣的數(shù)目補充個飲料機器，供貨代表要注意到用銷售情況好的品牌來代替銷售情況不好的品牌，并進行相應(yīng)的補充。在“Restock”用例中，新步驟（關(guān)注銷量并安排添貨）發(fā)生在供貨代表打開機器準備向機器中補充飲料時。因此在這個例子中，擴展點是“beforefillingthecompartments（補充飲料）”。與包含關(guān)系相似，可視化擴展關(guān)系也是用一條依賴線（帶箭頭的虛線），沿線上加上一個用雙尖括號擴起來的“extend”關(guān)鍵字。在基用例中，擴展點出現(xiàn)在“Extensionpoint”（如果有多個擴展點，就是“Extensionpoints”）的下方。例：圖書管理系統(tǒng)中，在一切順利的情況下，只需要執(zhí)行”還書“用例即可。但是，如果借書超期或者書有所破損，借書用戶就要交納一定的罰金。3.包含在“供貨”和“取貨”用例中，也許你會發(fā)現(xiàn)會有一些相同的步驟。兩個用例都以打開機器為起始點，以關(guān)閉和鎖好機器為終點。能不能消除用例中的重復(fù)步驟呢？可以。方法是從各個步驟序列中抽取出公共步驟形成一個每個用例都要使用的附加用例。可以將“開機”和“拉出飲料架”這兩個步驟合并為一個叫做“打開銷售機”的用例，將“放回架子”和“鎖機器”合并為一個叫做“關(guān)閉銷售機”的用例。有了這兩個新用例，用例“供貨”就可以用例“打開銷售機”為開始，供貨代表通過前面步驟，以用例“關(guān)閉銷售機”結(jié)束。類似地，用例“收款”也以“打開銷售機”為開始，進行前面的步驟，以關(guān)閉“銷售機”結(jié)束。如上所述，“供貨”和“收款”這兩個用例都包含了新的用例。這種技術(shù)被稱為“包含用例”。

包含關(guān)系指用例可簡單地包含其它用例具有的行為，并把它所包含的用例行為作為自己行為的一部分。在UML中，包含關(guān)系是通過帶箭頭的虛線段加<<include>>來表示，箭頭由基礎(chǔ)用例(Base)指向被包含用例(Inclusion)。

在處理包含關(guān)系時，具體的做法是把幾個用例的公共部分單獨抽象出來成為一個新的用例。主要有以下的兩種情況需要用到包含關(guān)系：一個用例的功能過多、事件過于復(fù)雜時，可以把某一段事件流抽象成為一個被包含的用例，以達到簡化描述的目的。當(dāng)多個用例用到同一段行為時，則可把這段共同的行為單獨抽象為一個用例，然后讓其他用例來包含這一用例。例：有一個資源網(wǎng)站，維護人員要對網(wǎng)站的資源進行維護，包括添加資源、修改資源和刪除資源。其中，添加資源和修改資源后都要對新添加的資源和修改的資源進行預(yù)覽，用來檢查添加和修改操作是否正確完成。包含關(guān)系和擴展關(guān)系也存在較大的區(qū)別：①基礎(chǔ)用例的執(zhí)行并不一定會涉及擴展用例，擴展用例只有滿足一定條件時才會被執(zhí)行。而在包含關(guān)系中，當(dāng)基礎(chǔ)用例執(zhí)行后，被包含用例是一定會被執(zhí)行的。②在擴展關(guān)系中，基礎(chǔ)用例提供了一個或多個插入點，擴展用例為這些插入點提供了需要插入的行為。而在包含關(guān)系中，插入點只能有一個。③即使沒有擴展用例，擴展關(guān)系中的基礎(chǔ)用例本身是完整的。而對于包含關(guān)系，基礎(chǔ)用例在沒有被包含用例的情況下就是不完整的存在。我們來細看“Restock”和“Collect”用例。這兩個用例都從開鎖和拉開銷售機的門開始，都以關(guān)門和上鎖結(jié)束。第1步建立了“Exposetheinside（打開銷售機）”用例，并且第2步創(chuàng)建了“Unexposetheinside（關(guān)閉銷售機）”用例?！癛estock”和“Collect”兩者都包含了這兩個新用例。要表達用例的包含關(guān)系，可以使用類之間依賴關(guān)系的表示符號，也就是連接兩個類之間的虛線，箭頭指向被依賴的類。在線上要加一個關(guān)鍵字，也就是用雙尖括號擴起來的“include”。分組在一些用例圖中，用例圖的數(shù)目可能非常多，這時就需要組織這些用例。這種情況在一個系統(tǒng)包含很多個子系統(tǒng)時就會出現(xiàn)。另一種可能是，當(dāng)你按順序和用戶會談，收集系統(tǒng)需求時，每個需求必須用一個單獨的用例來表達。最直接的方法是把相關(guān)的用例放在一個包中組織起來。二、參與者之間的關(guān)系

參與者與參與者之間的關(guān)系主要是泛化關(guān)系。泛化關(guān)系的含義就是把某些參與者的共同行為提取出來表示通用行為。

在UML圖中，使用帶空心三角箭頭的實線表示泛化關(guān)系，箭頭指向超類參與者。

在需求分析中，常常遇到用戶權(quán)限的問題三、參與者和用例之間的關(guān)系

參與者和用例之間屬于關(guān)聯(lián)關(guān)系(Association)。關(guān)聯(lián)關(guān)系是雙向的一對一的關(guān)系，這種關(guān)系表明了哪個參與者與用例通信。用例圖中參與者和用例之間的關(guān)系使用帶箭頭或者不帶箭頭的線段來描述，箭頭表示在這一關(guān)系中哪一方是對話的主動發(fā)起者，箭頭所指方是對話的被動接受者。如果不想強調(diào)對話中的主動與被動關(guān)系，可以使用不帶箭頭的線段。四、系統(tǒng)邊界系統(tǒng)邊界是指系統(tǒng)與系統(tǒng)之間的邊界，這里的系統(tǒng)可認為是由一系列的相互作用的元素形成的具有特定功能的有機整體。

用例圖中的系統(tǒng)邊界用來表示正在建模系統(tǒng)的的邊界。邊界內(nèi)表示系統(tǒng)的組成部分，邊界外表示系統(tǒng)外部。Visio建模工具可畫出。

在項目開發(fā)過程中，邊界是很重要的概念。系統(tǒng)與環(huán)境之間存在邊界，子系統(tǒng)與其他子系統(tǒng)之間存在邊界，子系統(tǒng)與整體系統(tǒng)之間存在邊界。3.2確定參與者在獲取用例前首先要確定系統(tǒng)的參與者，確定參與者可從幾方面來考慮，如書第44頁確定參與者時要注意幾個問題，如書第44頁所述。3.3確定用例確定用例的最好方法是從分析系統(tǒng)參與者開始，在這個過程中往往會發(fā)現(xiàn)新的參與者。當(dāng)找到參與者之后，就可以根據(jù)參與者來確定系統(tǒng)的用例，主要是看各參與者如何使用系統(tǒng)，需要系統(tǒng)提供什么樣的服務(wù)。3.4用例的粒度用例的粒度指的是用例所包含的系統(tǒng)服務(wù)或功能單元的多少。用例的粒度越大，用例包含的功能就越多，反之則包含的功能越少。用例的粒度對于用例模型來說很重要。在確定用例粒度的時候，應(yīng)該根據(jù)系統(tǒng)具體問題具體分析。當(dāng)大致確定用例個數(shù)后，就可以很容易確定用例粒度的大小。3.5用例規(guī)約有時也要對每一個用例還需要有詳細的描述信息，以便讓其他人對于整個系統(tǒng)有更加詳細的了解，這些信息包含在用例規(guī)約之中。用例模型是由用例圖和每個用例的詳細描述——用例規(guī)約所組成的。每個用例的用例規(guī)約應(yīng)包含以下內(nèi)容：（1）簡要說明對用例作用和目的的簡要描述（2）事件流包括基本流和備選流?；玖髅枋龅氖怯美幕玖鞒?，是指用例“正常”運行時的場景。備選流描述的是用例執(zhí)行過程中可能發(fā)生的異常和偶爾發(fā)生的情況。（3）用例場景同一個用例在實際執(zhí)行的時候會有很多不同的情況發(fā)生，稱之為用例場景。也可以說用例場景就是用例的實例。（4）特殊需求指的是一個用例的非功能性需求和設(shè)計約束。非功能性需求包括可靠性、性能、可用性和可擴展性等。設(shè)計約束可以包括開發(fā)工具、操作系統(tǒng)及環(huán)境、兼容性。（5）前置條件執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。（6）后置條件用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。運用用例模型舉例(網(wǎng)上論壇)一個基本的網(wǎng)上論壇系統(tǒng)，大致有如下的流程：

1、用戶（一般為游客或注冊會員）登錄進入論壇，就某個帖子的主題展開討論；通過發(fā)帖功能發(fā)布新的主題；通過回帖功能回復(fù)已有的主題；通過搜索功能查找已有的主題；

2、論壇管理員通過管理功能創(chuàng)建、編輯、刪除論壇的板塊；管理注冊用戶和管理帖子。運用用例模型舉例(網(wǎng)上論壇)一、理解領(lǐng)域論壇的用戶主要分為三種：普通用戶即游客；論壇的注冊會員；論壇的管理員。三者的身份不同，權(quán)限不同，所以具體的功能需求也不同。對普通用戶來說，需要具有以下的兩個功能：（1）無須注冊即可以瀏覽論壇的信息，系統(tǒng)提供論壇文章的查詢和閱讀功能，即提供對應(yīng)文章的標題信息以及詳細內(nèi)容。（2）如果要想對某個主題發(fā)帖和回復(fù)，則該用戶必須先注冊成為論壇注冊的會員。系統(tǒng)提供新會員的注冊功能，在用戶輸入個人信息后，經(jīng)檢查注冊信息有效后，將注冊會員的信息保存到相應(yīng)的數(shù)據(jù)庫中。對于注冊會員，除了普通用戶所有的功能，還擁有以下功能（1）要想針對主題發(fā)帖或回復(fù)必須是登錄的注冊用戶。無論在進入論壇首頁時還是在發(fā)帖和回帖時，進行登錄都是可以的。注冊會員在登錄頁面中要輸入注冊的用戶賬號和密碼，通過身份驗證才能獲得發(fā)帖和回復(fù)的權(quán)限。（2）注冊會員可以針對某一主題發(fā)表帖子（文章）和修改發(fā)帖的內(nèi)容。（3）注冊會員能夠?qū)δ骋粋€主圖展開討論，發(fā)表意見，并進行回復(fù)。（4）注冊會員可以修改自己的個人會員信息、修改密碼、找回密碼和注銷。對于論壇管理員來說，其功能范圍包括以下內(nèi)容：（1）當(dāng)網(wǎng)上論壇會員注冊后，系統(tǒng)會在數(shù)據(jù)庫中加入會員的資料，包括會員名稱、會員密碼、會員E-mail等個人信息。論壇管理員對會員資料進行管理，可查看用戶的基本信息、刪除該用戶的信息、修改會員的積分和排行等。（2）根據(jù)不同的討論內(nèi)容，論壇管理員將整個討論區(qū)劃分成不同的板塊，會員可以選擇進入不同的討論區(qū)，允許管理者對版塊進行調(diào)整，刪除不必要的版塊，修改版塊的名稱、類型和數(shù)量，同時提供不同討論區(qū)中包括文章數(shù)量的統(tǒng)計功能。（3）論壇管理員能夠?qū)T發(fā)表的帖子進行修改、刪除內(nèi)容反動或不健康的帖子、轉(zhuǎn)移/指定/設(shè)置精華帖，控制帖子的點擊率等操作?？蓸?gòu)建出網(wǎng)上論壇的參與者包含以下4種：（1）用戶。泛指所有使用網(wǎng)上論壇系統(tǒng)的人，是專門抽象出來的一個參與者。（2）普通用戶。也就是游客，沒有在論壇中進行注冊的用戶，無權(quán)發(fā)帖和回帖，僅能瀏覽論壇文章。（3）注冊會員。已經(jīng)注冊成為論壇會員的用戶，登錄論壇后即可擁有發(fā)帖和回帖的權(quán)限。（4）管理員。擁有對本論壇進行設(shè)置管理、會員管理、板塊管理、帖子管理和用戶管理的權(quán)限。二、理解用戶三、理解用例對普通用戶來說，可通過本系統(tǒng)進行如下活動：在網(wǎng)上論壇中進行注冊成為注冊會員。在論壇中查詢帖子（文章）。在論壇中瀏覽帖子的具體內(nèi)容。對于注冊會員，除了普通用戶所有的功能，還可進行以下活動：登錄網(wǎng)上論壇。在論壇中發(fā)帖和回復(fù)貼子，包括修改發(fā)帖的內(nèi)容。修改個人注冊信息，包括修改登錄密碼。在忘記登錄密碼時，可以找回該密碼。可以在線注銷登錄。對于論壇管理員，可以通過本系統(tǒng)進行如下的活動：對論壇會員進行管理，包括刪除會員、設(shè)置會員等級、查詢會員信息、添加會員等。對論壇的帖子進行管理，包括帖子置頂、設(shè)置精華貼、刪除帖子、修改帖子等。對論壇板塊分類進行管理，包括添加板塊和刪除板塊等。登錄到BBS網(wǎng)上論壇。思考題1：1、發(fā)起一個用例的實體被稱為什么？2、包含用例是什么含義？3、擴展用例是什么含義？4、用例和場景是同一概念么？思考題2系統(tǒng)管理員主要職責(zé)是管理用戶、修改所有用戶的密碼、管理用戶的權(quán)限，還可以瀏覽所有用戶的信息。思考題3根據(jù)如下關(guān)于電梯控制的問題描述，繪制一個用例圖每部電梯都有樓層按鈕，每一樓層有一組。乘坐電梯的人可以按下樓按鈕，按鈕被按下時指示燈會閃亮，然后通知電梯運行到指定的樓層。等電梯到達指定樓層時，按鈕停止指示燈閃亮。乘客在必要時可以按下緊急求助按鈕，該按鈕會自動發(fā)出求救信號。技術(shù)員可以通過一個控制按鍵激活或終止電梯的樓層按鈕。出于安全方面的考慮，只有保安人員可以通過一個控制鍵打開地下室的電梯樓層按鈕。所有電梯都是通過大廳前臺的一個控制中心控制的。課后練習(xí)題畫出銀行取款過程的用例圖。問題描述為：儲戶用存折取款，首先填寫取款單，根據(jù)“銀行卡”中的信息檢驗取款單與存折，如有問題，將問題反饋給儲戶，否則，登錄“儲戶存款數(shù)據(jù)庫”，修改相應(yīng)數(shù)據(jù)，并更新“銀行卡”，同時發(fā)出付款通知，出納向儲戶付款。實例講解（一）建立項目與資源管理系統(tǒng)的用例圖。系統(tǒng)的主要功能是：項目管理、資源管理和系統(tǒng)管理。項目管理包括項目的增加、刪除、更新等功能。資源管理包括對資源和技能的添加、刪除和更新、系統(tǒng)管理包括系統(tǒng)的啟動和關(guān)閉，數(shù)據(jù)的存儲和備份等功能。

實例2醫(yī)院病房監(jiān)護系統(tǒng)一、問題描述

為了對危重病人進行實時監(jiān)護，隨時了解病人病情，及時進行處理，建立病房監(jiān)護系統(tǒng)。

病癥監(jiān)視器安置在每個病床，通過網(wǎng)絡(luò)將病人的病癥信號（組合）實時傳送到中央監(jiān)護系統(tǒng)進行分析處理。在中心值班室里，值班護士使用中央監(jiān)護系統(tǒng)對病員的情況進行監(jiān)控，監(jiān)護系統(tǒng)實時地將病人的病癥信號與標準的病診信號進行比較分析，當(dāng)病癥出現(xiàn)異常時，系統(tǒng)會立即自動報警，并打印病情報告和更新病歷。系統(tǒng)根據(jù)醫(yī)生的要求隨時打印病人的病情報告，系統(tǒng)定期自動更新病歷。請對系統(tǒng)需求進行分析！經(jīng)過初步的需求分析，得到系統(tǒng)功能要求：1.監(jiān)視病員的病癥（血壓、體溫、脈搏等）2.定時更新病歷3.病員出現(xiàn)異常情況時報警。4.隨機地產(chǎn)生某一病員的病情報告。產(chǎn)生病情報告監(jiān)視病情更新病歷二、簡單的需求分析說明

對“醫(yī)院病房監(jiān)護系統(tǒng)”進行分析，確定系統(tǒng)的主要功能如下：

1.病癥監(jiān)視器可以將采集到的病癥信號（組合），格式化后實時的傳送到中央監(jiān)護系統(tǒng)。

2.中央監(jiān)護系統(tǒng)將病人的病癥信號分解后與標準的病癥信號庫里的病癥信號的正常值進行比較，當(dāng)病癥出現(xiàn)異常時系統(tǒng)自動報警。

3.當(dāng)病癥信號異常時，系統(tǒng)自動更新病歷并打印病情報告。

4.值班護士可以查看病情報告并進行打印。

5.醫(yī)生可以查看病情報告，要求打印病情報告，也可以查看或要求打印病歷。

6.系統(tǒng)定期自動更新病歷。需求分析1.通過以下6個問題識別角色(1)誰使用系統(tǒng)的主要功能？(2)誰需要系統(tǒng)的支持以完成日常工作任務(wù)？(3)誰負責(zé)維護，管理并保持系統(tǒng)正常運行？(4)系統(tǒng)需要應(yīng)付（或處理）哪些硬設(shè)備？(5)系統(tǒng)需要和哪些外部系統(tǒng)交互？(6)誰（或什么）對系統(tǒng)運行產(chǎn)生的結(jié)果（值）感興趣？三、建立系統(tǒng)的用例模型值班護士、醫(yī)生、病人值班護士、醫(yī)生系統(tǒng)管理員監(jiān)護器,網(wǎng)絡(luò),報警系統(tǒng)標準病癥信號庫、病歷庫同(2)

通過回答這6個問題以后，再進一步分析可以識別出本系統(tǒng)的4個角色：值班護士，醫(yī)生，病人，標準病癥信號庫。角色描述模板：角色：病人角色職責(zé)：提供病癥信號角色職責(zé)識別：負責(zé)生成、實時提供各種病癥信號。角色：值班護士角色職責(zé)：負責(zé)監(jiān)視病人的病情變化角色職責(zé)識別：

(1)使用系統(tǒng)主要功能

(2)對系統(tǒng)運行結(jié)果感興趣角色:標準病癥信號庫角色職責(zé)：負責(zé)向系統(tǒng)提供病癥信號的正常值角色職責(zé)識別：

(1)負責(zé)保持系統(tǒng)正常運行

(2)與系統(tǒng)交互角色：醫(yī)生角色職責(zé)：對病人負責(zé)，負責(zé)處理病情的變化角色職責(zé)識別：

(1)需要系統(tǒng)支持以完成其日常工作

(2)對系統(tǒng)運行結(jié)果感興趣２.識別用例回答下面的問題：⑴與系統(tǒng)實現(xiàn)有關(guān)的主要問題是什么？⑵系統(tǒng)需要哪些輸入/輸出？這些輸入/輸出從何而來？到哪里去？⑶執(zhí)行者需要系統(tǒng)提供哪些功能？⑷執(zhí)行者是否需要對系統(tǒng)中的信息進行讀、創(chuàng)建、修改、刪除或存儲？

通過分析可以初步識別出系統(tǒng)的用例為：

中央監(jiān)護，病癥監(jiān)護，提供標準病癥信號，病歷管理，病情報告管理。進一步將用例細化，即分解用例：1.中央監(jiān)護

分解:a分解信號將從病癥監(jiān)護器傳送來的組合病癥信號分解為系統(tǒng)可以處理的信號。

b比較信號將病人的病癥信號與標準信號比較。

c報警如果病癥信號發(fā)生異常（即高于峰值），發(fā)出報警信號。

d數(shù)據(jù)格式化將處理后的數(shù)據(jù)格式化以便寫入病歷庫。2.病癥監(jiān)護

分解:e信號采集采集病人的病癥信號。

f模數(shù)轉(zhuǎn)換將采集來的模擬信號轉(zhuǎn)換為數(shù)字信號。

g信號數(shù)據(jù)組合將采集到的脈搏，血壓等信號數(shù)據(jù)組合為一組信號數(shù)據(jù)。

h采樣頻率改變根據(jù)病人的情況改變監(jiān)視器采樣頻率用例細化3.提供標準病癥信號

i（此用例不分解）4.病歷管理

分解為：j生成病歷。將各種病癥符號經(jīng)過格式化后，加上時間戳，存入病歷庫。

k查看病歷。醫(yī)生隨時根據(jù)需要在計算機屏幕上查看病歷。

l更新病歷

。定時清理病歷庫，更新病歷。

m打印病歷。隨時打印病歷，作為醫(yī)生診斷依據(jù)。5.病情報告管理

分解為：n顯示病情報告在顯示器上顯示病情

o打印病情報告在打印機打印病情報告用例細化給出細化的用例圖細化的用例圖病人模數(shù)轉(zhuǎn)化數(shù)據(jù)格式化值班護士報警信號采集比較信號標準病癥信號庫醫(yī)生信號數(shù)據(jù)組合采樣頻率改變提供標準病癥信號生成病歷查看病歷更新病歷打印病歷顯示病情報告打印病情報告分解信號<<extend>><<Extend>><<Extend>><<include>><<include>><<include>><<include>><<include>><<include>><<include>><<include>>用例名：

中

央

監(jiān)

視執(zhí)行者：

值班護士、醫(yī)生目標：

對病人的病癥信號進行監(jiān)測、處理，超過極限報警。功能描述：1.分解信號：將從病癥監(jiān)護器傳送來的組合病癥信號分解為系統(tǒng)可以處理的信號。2.比較信號：將病人的病癥信號與標準信號比較

。3.報警：如果病癥信號發(fā)生異常（即高于峰值），發(fā)出報警信號。4.數(shù)據(jù)格式化：將處理后的數(shù)據(jù)格式化以便寫入病歷庫

。其他非功能需求:

高可靠性、實時性主要步驟：按設(shè)定頻率連續(xù)接收來自各病人的病癥信號，并進行分解。將病人的病癥信號與專家系統(tǒng)（標準病癥信號庫）中的標準信號進行比較判斷是否超過極限值。若超過極限值，進行報警，并及時更新病歷和打印病情報告。相關(guān)用例：病癥監(jiān)護、提供標準病癥信號、病歷管理、病情報告管理。相關(guān)信息：(優(yōu)先級、性能、頻執(zhí)行率)：優(yōu)先級：報警處理具有最高優(yōu)先級3,一般病歷管理為1,其他為2.性能：實時性、高可靠性頻執(zhí)行率：根據(jù)病情嚴重程度12～30次/小時用例“中央監(jiān)護”描述模板實例講解3超市信息管理系統(tǒng)根據(jù)需求分析，系統(tǒng)包括以下幾個小的系統(tǒng)模塊。銷售管理子系統(tǒng)：銷售管理子系統(tǒng)主要用于實