重點內(nèi)容： 什么叫用例圖 用例圖的構(gòu)成要素 用例的重要元素 用例之間的各種重要關(guān)系 使用Rose創(chuàng)建用例圖的步驟說明 使用Rose創(chuàng)建用例圖的步驟說明,第6章 用例圖,一、 什么叫用例圖,由參與者（Actor）、用例（Use Case）以及它們之間的關(guān)系構(gòu)成的用于描述系統(tǒng)功能的動態(tài)視圖稱為用例圖。要在用例圖上顯示某個用例，可繪制一個橢圓，然后將用例的名稱放在橢圓的中心或橢圓下面的中間位置。 要在用例圖上繪制一個參與者（表示一個系統(tǒng)用戶），可繪制一個人形符號。參與者和用例之間的關(guān)系使用帶箭頭或者不帶箭頭的線段來描述，箭頭表示在這一關(guān)系中哪一方是對話的主動發(fā)起者，箭頭所指方是對話的被動接受者。,1、用例圖的含義,一、 什么叫用例圖,在用例建模中，為了更加清楚的描述用例或者參與者，會使用到注釋。,1、用例圖的含義,一、 什么叫用例圖,用例圖是需求分析中的產(chǎn)物，主要作用是描述參與者和用例之間的關(guān)系，幫助開發(fā)人員可視化的了解系統(tǒng)的功能。借助于用例圖，系統(tǒng)用戶、系統(tǒng)分析人員、系統(tǒng)設(shè)計人員、領(lǐng)域?qū)＜夷軌蛞钥梢暬姆绞綄栴}進行探討，減少了大量交流上的障礙，便于對問題達成共識。 用例圖可視化地表達了系統(tǒng)的需求，具有直觀、規(guī)范等優(yōu)點，克服了純文字性說明的不足。 用例方法是完全從外部來定義系統(tǒng)功能，它把需求和設(shè)計完全的分離開來。我們不用關(guān)心系統(tǒng)內(nèi)部是如何完成各種功能的，系統(tǒng)對于我們來說就是一個黑箱子。,2、用例圖的作用,二、用例圖的構(gòu)成要素,參與者（Actor）是指存在于系統(tǒng)外部并直接與系統(tǒng)進行交互的人、系統(tǒng)、子系統(tǒng)或類的外部實體的抽象。 每個參與者可以參與一個或多個用例，每個用例也可以有一個或多個參與者。 在用例圖中使用一個人形圖標來表示參與者，參與者的名字寫在人形圖標下面。,1、參與者,二、用例圖的構(gòu)成要素,由于參與者實質(zhì)上也是類，所以它擁有與類相同的關(guān)系描述，即參與者與參與者之間主要是泛化關(guān)系（或稱為“繼承”關(guān)系）。 泛化關(guān)系的含義是把某些參與者的共同行為提取出來表示成通用行為，并描述成超類。泛化關(guān)系表示的是參與者之間的一般/特殊關(guān)系，在UML圖中，使用帶空心三角箭頭的實線表示泛化關(guān)系。,2、參與者間的關(guān)系,二、用例圖的構(gòu)成要素,在項目開發(fā)過程中，邊界是一個非常重要的概念。這里說的系統(tǒng)邊界是指系統(tǒng)與系統(tǒng)之間的界限。通常我們所說的系統(tǒng)可以認為是由一系列的相互作用的元素形成的具有特定功能的有機整體。 系統(tǒng)同時又是相對的，一個系統(tǒng)本身又可以是另一個更大系統(tǒng)的組成部分，因此，系統(tǒng)與系統(tǒng)之間需要使用系統(tǒng)邊界進行區(qū)分開來。我們把系統(tǒng)邊界以外的同系統(tǒng)相關(guān)聯(lián)的其他部分，稱之為系統(tǒng)環(huán)境。,3、系統(tǒng)邊界,三、用例的重要元素,任何用例都不能在缺少參與者的情況下獨立存在。同樣，任何參與者也必須要有與之關(guān)聯(lián)的用例。所以識別用例的最好方法就是從分析系統(tǒng)參與者開始，在這個過程中往往會發(fā)現(xiàn)新的參與者。 可以通過以下問題來尋找用例： 1 參與者希望系統(tǒng)提供什么功能？ 2 參與者是否會讀取、創(chuàng)建、修改、刪除、存儲系統(tǒng)的某種信息？如果是的話，參與者又是如何完成這些操作的？ 3 參與者是否會將外部的某些事件通知給系統(tǒng)？ 4 系統(tǒng)中發(fā)生的事件是否通知參與者？ 5 是否存在影響系統(tǒng)的外部事件。,1、識別用例,三、用例的重要元素,用例的粒度指的是用例所包含的系統(tǒng)服務(wù)或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。 如果用例的粒度很小，得到的用例數(shù)就會太多。反之，如果用例的粒度很大，那么得到的用例數(shù)就會很少。 如果用例數(shù)目過多會造成用例模型過大和引入設(shè)計困難大大提高。 如果用例數(shù)目過少會造成用例的粒度太大，不便于進一步的充分分析。,2、用例的粒度,三、用例的重要元素,用例的粒度指的是用例所包含的系統(tǒng)服務(wù)或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。 如果用例的粒度很小，得到的用例數(shù)就會太多。反之，如果用例的粒度很大，那么得到的用例數(shù)就會很少。 如果用例數(shù)目過多會造成用例模型過大和引入設(shè)計困難大大提高。 如果用例數(shù)目過少會造成用例的粒度太大，不便于進一步的充分分析。,2、用例的粒度,三、用例的重要元素,比如：網(wǎng)站后臺管理系統(tǒng)中的會員信息維護用例，管理員需要進行添加會員信息、修改會員信息、刪除會員信息等操作。,2、用例的粒度,我們還可以根據(jù)具體的操作把它抽象成3個用例，它展示的系統(tǒng)需求和單個用例是完全一樣的。,三、用例的重要元素,對于每一個用例，我們還需要有詳細的描述信息，以便讓別人對于整個系統(tǒng)有一個更加詳細的了解，這些信息包含在用例規(guī)約之中。 每一個用例的用例規(guī)約都應(yīng)該包含以下內(nèi)容： 1 簡要說明:對用例作用和目的的簡要描述。 2 事件流:事件流包括基本流和備選流?；玖髅枋龅氖怯美幕玖鞒?，是指用例“正?！边\行時的場景。 3 用例場景:同一個用例在實際執(zhí)行的時候會有很多不同的情況發(fā)生，稱之為用例場景，也可以說用例場景就是用例的實例。 4 特殊需求: 特殊需求指的是一個用例的非功能性需求和設(shè)計約束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可擴展性等。例如法律或法規(guī)方面的需求、應(yīng)用程序標準和所構(gòu)建系統(tǒng)的質(zhì)量屬性等。 5 前置條件: 執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。例如，前置條件是要求用戶有訪問的權(quán)限或是要求某個用例必須已經(jīng)執(zhí)行完。 6 后置條件:用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。例如，要求在某個用例執(zhí)行完后，必須執(zhí)行另一個用例。,3、用例規(guī)約,四、用例之間的各種重要關(guān)系,包含關(guān)系指用例可以簡單地包含其他用例具有的行為，并把它所包含的用例行為作為自身行為的一部分。在UML中，包含關(guān)系是通過帶箭頭的虛線段加字樣來表示，箭頭由基礎(chǔ)用例(Base)指向被包含用例(Inclusion)。,1、包含,四、用例之間的各種重要關(guān)系,包含關(guān)系代表著基礎(chǔ)用例會用到被包含用例，具體的講就是將被包含用例的事件流插入到基礎(chǔ)用例的事件流中。需要注意的是，包含關(guān)系是UML1.3中的表述，在UML1.1中，同等語義的關(guān)系被表述為使用(uses)。,1、包含,四、用例之間的各種重要關(guān)系,在處理包含關(guān)系時，具體的做法就是把幾個用例的公共部分單獨的抽象出來成為一個新的用例。主要有兩種情況需要用到包含關(guān)系： 第一，多個用例用到同一段的行為，則可以把這段共同的行為單獨抽 象成為一個用例，然后讓其他用例來包含這一用例。 第二，某一個用例的功能過多、事件流過于復(fù)雜時，我們也可以把某一段事件流抽象成為一個被包含的用例，以達到簡化描述的目的。,1、包含,四、用例之間的各種重要關(guān)系,在一定條件下，把新的行為加入到已有的用例中，獲得的新用例叫做擴展用例(Extension)，原有的用例叫做基礎(chǔ)用例(Base)，從擴展用例到基礎(chǔ)用例的關(guān)系就是擴展關(guān)系。 一個基礎(chǔ)用例可以擁有一個或者多個擴展用例，這些擴展用例可以一起使用。,2、擴展,四、用例之間的各種重要關(guān)系,用例的泛化指的是一個父用例可以被特化形成多個子用例，而父用例和子用例之間的關(guān)系就是泛化關(guān)系。 在用例的泛化關(guān)系中，子用例繼承了父用例所有的結(jié)構(gòu)、行為和關(guān)系，子用例是父用例的一種特殊形式。 子用例還可以添加、覆蓋、改變繼承的行為。在UML中，用例的泛化關(guān)系通過一個三角箭頭從子用例指向父用例來表示。,3、泛化,四、用例之間的各種重要關(guān)系,泛化的示例：銀行存款有兩種方式，一種是銀行柜臺存款，一種是ATM機存款。在這里，銀行柜臺存款和ATM機存款都是存款的一種特殊方式，因此“存款”為父用例，“銀行柜臺存款”和“ATM機存款”為子用例。,3、泛化,五、使用Rose創(chuàng)建用例圖的步驟說明,“企業(yè)進、存、銷管理系統(tǒng)” 功能性需求包括以下內(nèi)容： （1）采購員根據(jù)生產(chǎn)原料的使用情況判斷采購用品，對需要訂購產(chǎn)品信息統(tǒng)計訂貨的，并制作產(chǎn)品訂單。最后根據(jù)訂單進行采購活動。 （2）倉庫管理員負責(zé)產(chǎn)品的庫存管理。包括產(chǎn)品入庫管理、處理盤點信息、處理報損產(chǎn)品信息和一些信息的設(shè)置。這些設(shè)置信息，包括：供應(yīng)商信息、產(chǎn)品信息。倉庫管理員每天對產(chǎn)品進行一次盤點，當發(fā)現(xiàn)庫存產(chǎn)品有損壞時，及時處理報損信息。當產(chǎn)品生產(chǎn)后，將產(chǎn)品進行入庫。當產(chǎn)品銷售后時，產(chǎn)品進行出庫處理。 （3）統(tǒng)計人員負責(zé)統(tǒng)計分析管理，包括：查詢產(chǎn)品信息、查詢銷售信息、查詢供應(yīng)商信息、查詢?nèi)必浶畔?、查詢報表信息，并制作報表。統(tǒng)計分析員使用系統(tǒng)的統(tǒng)計分析功能，了解產(chǎn)品信息、銷售信息、供應(yīng)商信息、庫存信息。 （4）在銷售員為客戶提供售貨服務(wù)時，接受客戶購買產(chǎn)品，根據(jù)系統(tǒng)的定價計算出產(chǎn)品的總價，客戶付款，系統(tǒng)自動保存客戶購買記錄。 （5）系統(tǒng)管理員負責(zé)本系統(tǒng)的系統(tǒng)維護。系統(tǒng)管理員負責(zé)員工信息管理、供貨商信息管理以及系統(tǒng)維護等。每種管理者都通過自己的用戶名稱和密碼登錄到各自的管理系統(tǒng)中。,1、需求分析,五、使用Rose創(chuàng)建用例圖的步驟說明,（1）銷售員：為客戶客提供銷售產(chǎn)品的服務(wù)。 （2）倉庫管理員：負責(zé)庫存產(chǎn)品的管理活動。 （3）采購員：負責(zé)企業(yè)生產(chǎn)原料的訂購。 （4）會計：負責(zé)企業(yè)經(jīng)營狀況的統(tǒng)計。 （5）系統(tǒng)管理員：負責(zé)企業(yè)員工信息管理、供應(yīng)商信息管理以及系統(tǒng)維護等。,2、識別參與者,五、使用Rose創(chuàng)建用例圖的步驟說明,銷售員能夠通過該系統(tǒng)進行銷售商品活動。首先登錄系統(tǒng)，驗證身份成功后，獲取商品信息，然后將銷售信息更新，最后對客戶進行商品銷售。,3、構(gòu)建用例模型,銷售員用例圖,五、使用Rose創(chuàng)建用例圖的步驟說明,倉庫管理員能夠通過該系統(tǒng)進行如下活動： （1）處理盤點，每天需要對庫存產(chǎn)品信息進行盤點。 （3）產(chǎn)品入庫。當產(chǎn)品生產(chǎn)后，將產(chǎn)品進行入庫。 （4）產(chǎn)品出庫。當產(chǎn)品銷售發(fā)貨后，進行出庫處理。 （5）管理設(shè)置。倉庫管理員負責(zé)供應(yīng)商信息、產(chǎn)品基本信息的管理設(shè)置。,3、構(gòu)建用例模型,倉庫管理員用例圖,五、使用Rose創(chuàng)建用例圖的步驟說明,采購員能夠通過該系統(tǒng)進行訂貨管理活動。采購員首先根據(jù)經(jīng)營情況統(tǒng)計所缺的生產(chǎn)資料，根據(jù)需要制定出訂單。,3、構(gòu)建用例模型,采購員用例圖,五、使用Rose創(chuàng)建用例圖的步驟說明,會計負責(zé)產(chǎn)品的統(tǒng)計分析管理，它能夠通過該系統(tǒng)進行如下活動： （1）查詢基本信息。會計能夠查詢產(chǎn)品的基本信息，根據(jù)產(chǎn)品的基本信息，制定出相應(yīng)的方案。 （2）查詢銷售信息。會計根據(jù)銷售情況匯總后交銷售部制定合理的銷售方案。 （3）查詢供應(yīng)商信息。會計能夠查詢供應(yīng)商信息。 （4）查詢?nèi)必浶畔?。會計能夠查詢?nèi)必浶畔ⅰ?（5）查詢報損信息。會計能夠查詢報損信息。,3、構(gòu)建用例模型,會計用例圖,五、使用Rose創(chuàng)建用例圖的步驟說明,系統(tǒng)管理員能夠通過該系統(tǒng)進行如下活動： （1）維護員工信息。系統(tǒng)管理員能夠維護企業(yè)員工的信息，如添加員工、刪除員工和修改員工信息等。 （2）維護供應(yīng)商信息。系統(tǒng)管理員能夠維護供應(yīng)商的信息，如添加供應(yīng)商、刪除供應(yīng)商和修改供應(yīng)商信息等。 （3）系統(tǒng)設(shè)置。系統(tǒng)管理員能夠根據(jù)一些需要進行必要的系統(tǒng)設(shè)置。,3、構(gòu)建用例模型,系統(tǒng)管理員用例圖,