一、什么叫用例圖

由參與者（Actor）、用例（UseCase）以及它們之間的關系構成的用于描述系統功能的動態視圖稱為用例圖。要在用例圖上顯示某個用例，可繪制一個橢圓，然后將用例的名稱放在橢圓的中心或橢圓下面的中間位置。要在用例圖上繪制一個參與者（表示一個系統用戶），可繪制一個人形符號。參與者和用例之間的關系使用帶箭頭或者不帶箭頭的線段來描述，箭頭表示在這一關系中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者。1、用例圖的含義一、什么叫用例圖由參與者（Actor）、用例（Us1一、什么叫用例圖

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

用例圖是需求分析中的產物，主要作用是描述參與者和用例之間的關系，幫助開發人員可視化的了解系統的功能。借助于用例圖，系統用戶、系統分析人員、系統設計人員、領域專家能夠以可視化的方式對問題進行探討，減少了大量交流上的障礙，便于對問題達成共識。用例圖可視化地表達了系統的需求，具有直觀、規范等優點，克服了純文字性說明的不足。用例方法是完全從外部來定義系統功能，它把需求和設計完全的分離開來。我們不用關心系統內部是如何完成各種功能的，系統對于我們來說就是一個黑箱子。2、用例圖的作用一、什么叫用例圖用例圖是需求分析中的產物，主要作用3二、用例圖的構成要素

參與者（Actor）是指存在于系統外部并直接與系統進行交互的人、系統、子系統或類的外部實體的抽象。每個參與者可以參與一個或多個用例，每個用例也可以有一個或多個參與者。在用例圖中使用一個人形圖標來表示參與者，參與者的名字寫在人形圖標下面。1、參與者二、用例圖的構成要素參與者（Actor）是指存在于系4二、用例圖的構成要素

由于參與者實質上也是類，所以它擁有與類相同的關系描述，即參與者與參與者之間主要是泛化關系（或稱為“繼承”關系）。泛化關系的含義是把某些參與者的共同行為提取出來表示成通用行為，并描述成超類。泛化關系表示的是參與者之間的一般/特殊關系，在UML圖中，使用帶空心三角箭頭的實線表示泛化關系。2、參與者間的關系二、用例圖的構成要素由于參與者實質上也是類，所以它擁5二、用例圖的構成要素

在項目開發過程中，邊界是一個非常重要的概念。這里說的系統邊界是指系統與系統之間的界限。通常我們所說的系統可以認為是由一系列的相互作用的元素形成的具有特定功能的有機整體。系統同時又是相對的，一個系統本身又可以是另一個更大系統的組成部分，因此，系統與系統之間需要使用系統邊界進行區分開來。我們把系統邊界以外的同系統相關聯的其他部分，稱之為系統環境。3、系統邊界二、用例圖的構成要素在項目開發過程中，邊界是一個非常6三、用例的重要元素

任何用例都不能在缺少參與者的情況下獨立存在。同樣，任何參與者也必須要有與之關聯的用例。所以識別用例的最好方法就是從分析系統參與者開始，在這個過程中往往會發現新的參與者。可以通過以下問題來尋找用例：

1參與者希望系統提供什么功能？

2參與者是否會讀取、創建、修改、刪除、存儲系統的某種信息？如果是的話，參與者又是如何完成這些操作的？

3參與者是否會將外部的某些事件通知給系統？

4系統中發生的事件是否通知參與者？

5是否存在影響系統的外部事件。1、識別用例三、用例的重要元素任何用例都不能在缺少參與者的情況下7三、用例的重要元素

用例的粒度指的是用例所包含的系統服務或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。

如果用例的粒度很小，得到的用例數就會太多。反之，如果用例的粒度很大，那么得到的用例數就會很少。

如果用例數目過多會造成用例模型過大和引入設計困難大大提高。如果用例數目過少會造成用例的粒度太大，不便于進一步的充分分析。2、用例的粒度三、用例的重要元素用例的粒度指的是用例所包含的系統服8三、用例的重要元素

用例的粒度指的是用例所包含的系統服務或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。

如果用例的粒度很小，得到的用例數就會太多。反之，如果用例的粒度很大，那么得到的用例數就會很少。

如果用例數目過多會造成用例模型過大和引入設計困難大大提高。如果用例數目過少會造成用例的粒度太大，不便于進一步的充分分析。2、用例的粒度三、用例的重要元素用例的粒度指的是用例所包含的系統服9三、用例的重要元素

比如：網站后臺管理系統中的會員信息維護用例，管理員需要進行添加會員信息、修改會員信息、刪除會員信息等操作。2、用例的粒度

我們還可以根據具體的操作把它抽象成3個用例，它展示的系統需求和單個用例是完全一樣的。三、用例的重要元素比如：網站后臺管理系統中的會員信息維護10三、用例的重要元素

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

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

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

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

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

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

6后置條件:用例執行完畢后系統可能處于的一組狀態。例如，要求在某個用例執行完后，必須執行另一個用例。3、用例規約三、用例的重要元素對于每一個用例，我們還需要有詳細的11四、用例之間的各種重要關系

包含關系指用例可以簡單地包含其他用例具有的行為，并把它所包含的用例行為作為自身行為的一部分。在UML中，包含關系是通過帶箭頭的虛線段加<<include>>字樣來表示，箭頭由基礎用例(Base)指向被包含用例(Inclusion)。1、包含四、用例之間的各種重要關系包含關系指用例可以簡單地包12四、用例之間的各種重要關系

包含關系代表著基礎用例會用到被包含用例，具體的講就是將被包含用例的事件流插入到基礎用例的事件流中。需要注意的是，包含關系是UML1.3中的表述，在UML1.1中，同等語義的關系被表述為使用(uses)。1、包含四、用例之間的各種重要關系包含關系代表著基礎用例會用13四、用例之間的各種重要關系

在處理包含關系時，具體的做法就是把幾個用例的公共部分單獨的抽象出來成為一個新的用例。主要有兩種情況需要用到包含關系：第一，多個用例用到同一段的行為，則可以把這段共同的行為單獨抽象成為一個用例，然后讓其他用例來包含這一用例。第二，某一個用例的功能過多、事件流過于復雜時，我們也可以把某一段事件流抽象成為一個被包含的用例，以達到簡化描述的目的。1、包含四、用例之間的各種重要關系在處理包含關系時，具體的做14四、用例之間的各種重要關系

在一定條件下，把新的行為加入到已有的用例中，獲得的新用例叫做擴展用例(Extension)，原有的用例叫做基礎用例(Base)，從擴展用例到基礎用例的關系就是擴展關系。一個基礎用例可以擁有一個或者多個擴展用例，這些擴展用例可以一起使用。

2、擴展四、用例之間的各種重要關系在一定條件下，把新的行為加15四、用例之間的各種重要關系

用例的泛化指的是一個父用例可以被特化形成多個子用例，而父用例和子用例之間的關系就是泛化關系。在用例的泛化關系中，子用例繼承了父用例所有的結構、行為和關系，子用例是父用例的一種特殊形式。子用例還可以添加、覆蓋、改變繼承的行為。在UML中，用例的泛化關系通過一個三角箭頭從子用例指向父用例來表示。

3、泛化四、用例之間的各種重要關系用例的泛化指的是一個父用例16四、用例之間的各種重要關系

泛化的示例：銀行存款有兩種方式，一種是銀行柜臺存款，一種是ATM機存款。在這里，銀行柜臺存款和ATM機存款都是存款的一種特殊方式，因此“存款”為父用例，“銀行柜臺存款”和“ATM機存款”為子用例。3、泛化四、用例之間的各種重要關系泛化的示例：銀行存款有兩種17五、使用Rose創建用例圖的步驟說明

“企業進、存、銷管理系統”功能性需求包括以下內容：（1）采購員根據生產原料的使用情況判斷采購用品，對需要訂購產品信息統計訂貨的，并制作產品訂單。最后根據訂單進行采購活動。（2）倉庫管理員負責產品的庫存管理。包括產品入庫管理、處理盤點信息、處理報損產品信息和一些信息的設置。這些設置信息，包括：供應商信息、產品信息。倉庫管理員每天對產品進行一次盤點，當發現庫存產品有損壞時，及時處理報損信息。當產品生產后，將產品進行入庫。當產品銷售后時，產品進行出庫處理。（3）統計人員負責統計分析管理，包括：查詢產品信息、查詢銷售信息、查詢供應商信息、查詢缺貨信息、查詢報表信息，并制作報表。統計分析員使用系統的統計分析功能，了解產品信息、銷售信息、供應商信息、庫存信息。（4）在銷售員為客戶提供售貨服務時，接受客戶購買產品，根據系統的定價計算出產品的總價，客戶付款，系統自動保存客戶購買記錄。（5）系統管理員負責本系統的系統維護。系統管理員負責員工信息管理、供貨商信息管理以及系統維護等。每種管理者都通過自己的用戶名稱和密碼登錄到各自的管理系統中。1、需求分析五、使用Rose創建用例圖的步驟說明“企業進、存、銷18五、使用Rose創建用例圖的步驟說明

（1）銷售員：為客戶客提供銷售產品的服務。（2）倉庫管理員：負責庫存產品的管理活動。（3）采購員：負責企業生產原料的訂購。（4）會計：負責企業經營狀況的統計。（5）系統管理員：負責企業員工信息管理、供應商信息管理以及系統維護等。2、識別參與者五、使用Rose創建用例圖的步驟說明（1）銷售員：為客戶19五、使用Rose創建用例圖的步驟說明

銷售員能夠通過該系統進行銷售商品活動。首先登錄系統，驗證身份成功后，獲取商品信息，然后將銷售信息更新，最后對客戶進行商品銷售。3、構建用例模型銷售員用例圖

五、使用Rose創建用例圖的步驟說明銷售員能夠通過該20五、使用Rose創建用例圖的步驟說明倉庫管理員能夠通過該系統進行如下活動：（1）處理盤點，每天需要對庫存產品信息進行盤點。（3）產品入庫。當產品生產后，將產品進行入庫。（4）產品出庫。當產品銷售發貨后，進行出庫處理。（5）管理設置。倉庫管理員負責供應商信息、產品基本信息的管理設置。3、構建用例模型倉庫管理員用例圖

五、使用Rose創建用例圖的步驟說明倉庫管理員能夠通過該系統21五、使用Rose創建用例圖的步驟說明采購員能夠通過該系統進行訂貨管理活動。采購員首先根據經營情況統計所缺的生產資料，根據需要制定出訂單。3、構建用例模型采購員用例圖

五、使用Rose創建用例圖的步驟說明采購員能夠通過該系統進行22五、使用Rose創建用例圖的步驟說明會計負責產品的統計分析管理，它能夠通過該系統進行如下活動：（1）查詢基本信息。會計能夠查詢產品的基本信息，根據產品的基本信息，制定出相應的方案。（2）查詢銷售信息。會計根據銷售情況匯總后交銷售部制定合理的銷售方案。（3）查詢供應商信息。會計能夠查詢供應商信息。（4）查詢缺貨信息。會計能夠查詢缺貨信息。（5）查詢報損信息。會計能夠查詢報損信息。

3、構建用例模型會計用例圖

五、使用Rose創建用例圖的步驟說明會計負責產品的統計分析管23五、使用Rose創建用例圖的步驟說明系統管理員能夠通過該系統進行如下活動：（1）維護員工信息。系統管理員能夠維護企業員工的信息，如添加員工、刪除員工和修改員工信息等。（2）維護供應商信息。系統管理員能夠維護供應商的信息，如添加供應商、刪除供應商和修改供應商信息等。（3）系統設置。系統管理員能夠根據一些需要進行必要的系統設置。3、構建用例模型系統管理員用例圖

五、使用Rose創建用例圖的步驟說明系統管理員能夠通過該系統24一、什么叫用例圖

由參與者（Actor）、用例（UseCase）以及它們之間的關系構成的用于描述系統功能的動態視圖稱為用例圖。要在用例圖上顯示某個用例，可繪制一個橢圓，然后將用例的名稱放在橢圓的中心或橢圓下面的中間位置。要在用例圖上繪制一個參與者（表示一個系統用戶），可繪制一個人形符號。參與者和用例之間的關系使用帶箭頭或者不帶箭頭的線段來描述，箭頭表示在這一關系中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者。1、用例圖的含義一、什么叫用例圖由參與者（Actor）、用例（Us25一、什么叫用例圖

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

用例圖是需求分析中的產物，主要作用是描述參與者和用例之間的關系，幫助開發人員可視化的了解系統的功能。借助于用例圖，系統用戶、系統分析人員、系統設計人員、領域專家能夠以可視化的方式對問題進行探討，減少了大量交流上的障礙，便于對問題達成共識。用例圖可視化地表達了系統的需求，具有直觀、規范等優點，克服了純文字性說明的不足。用例方法是完全從外部來定義系統功能，它把需求和設計完全的分離開來。我們不用關心系統內部是如何完成各種功能的，系統對于我們來說就是一個黑箱子。2、用例圖的作用一、什么叫用例圖用例圖是需求分析中的產物，主要作用27二、用例圖的構成要素

參與者（Actor）是指存在于系統外部并直接與系統進行交互的人、系統、子系統或類的外部實體的抽象。每個參與者可以參與一個或多個用例，每個用例也可以有一個或多個參與者。在用例圖中使用一個人形圖標來表示參與者，參與者的名字寫在人形圖標下面。1、參與者二、用例圖的構成要素參與者（Actor）是指存在于系28二、用例圖的構成要素

由于參與者實質上也是類，所以它擁有與類相同的關系描述，即參與者與參與者之間主要是泛化關系（或稱為“繼承”關系）。泛化關系的含義是把某些參與者的共同行為提取出來表示成通用行為，并描述成超類。泛化關系表示的是參與者之間的一般/特殊關系，在UML圖中，使用帶空心三角箭頭的實線表示泛化關系。2、參與者間的關系二、用例圖的構成要素由于參與者實質上也是類，所以它擁29二、用例圖的構成要素

在項目開發過程中，邊界是一個非常重要的概念。這里說的系統邊界是指系統與系統之間的界限。通常我們所說的系統可以認為是由一系列的相互作用的元素形成的具有特定功能的有機整體。系統同時又是相對的，一個系統本身又可以是另一個更大系統的組成部分，因此，系統與系統之間需要使用系統邊界進行區分開來。我們把系統邊界以外的同系統相關聯的其他部分，稱之為系統環境。3、系統邊界二、用例圖的構成要素在項目開發過程中，邊界是一個非常30三、用例的重要元素

任何用例都不能在缺少參與者的情況下獨立存在。同樣，任何參與者也必須要有與之關聯的用例。所以識別用例的最好方法就是從分析系統參與者開始，在這個過程中往往會發現新的參與者。可以通過以下問題來尋找用例：

1參與者希望系統提供什么功能？

2參與者是否會讀取、創建、修改、刪除、存儲系統的某種信息？如果是的話，參與者又是如何完成這些操作的？

3參與者是否會將外部的某些事件通知給系統？

4系統中發生的事件是否通知參與者？

5是否存在影響系統的外部事件。1、識別用例三、用例的重要元素任何用例都不能在缺少參與者的情況下31三、用例的重要元素

用例的粒度指的是用例所包含的系統服務或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。

如果用例的粒度很小，得到的用例數就會太多。反之，如果用例的粒度很大，那么得到的用例數就會很少。

如果用例數目過多會造成用例模型過大和引入設計困難大大提高。如果用例數目過少會造成用例的粒度太大，不便于進一步的充分分析。2、用例的粒度三、用例的重要元素用例的粒度指的是用例所包含的系統服32三、用例的重要元素

用例的粒度指的是用例所包含的系統服務或功能單元的多少。用例的粒度越大，用例包含的功能越多，反之則包含的功能越少。

如果用例的粒度很小，得到的用例數就會太多。反之，如果用例的粒度很大，那么得到的用例數就會很少。

如果用例數目過多會造成用例模型過大和引入設計困難大大提高。如果用例數目過少會造成用例的粒度太大，不便于進一步的充分分析。2、用例的粒度三、用例的重要元素用例的粒度指的是用例所包含的系統服33三、用例的重要元素

比如：網站后臺管理系統中的會員信息維護用例，管理員需要進行添加會員信息、修改會員信息、刪除會員信息等操作。2、用例的粒度

我們還可以根據具體的操作把它抽象成3個用例，它展示的系統需求和單個用例是完全一樣的。三、用例的重要元素比如：網站后臺管理系統中的會員信息維護34三、用例的重要元素

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

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

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

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

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

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

6后置條件:用例執行完畢后系統可能處于的一組狀態。例如，要求在某個用例執行完后，必須執行另一個用例。3、用例規約三、用例的重要元素對于每一個用例，我們還需要有詳細的35四、用例之間的各種重要關系

包含關系指用例可以簡單地包含其他用例具有的行為，并把它所包含的用例行為作為自身行為的一部分。在UML中，包含關系是通過帶箭頭的虛線段加<<include>>字樣來表示，箭頭由基礎用例(Base)指向被包含用例(Inclusion)。1、包含四、用例之間的各種重要關系包含關系指用例可以簡單地包36四、用例之間的各種重要關系

包含關系代表著基礎用例會用到被包含用例，具體的講就是將被包含用例的事件流插入到基礎用例的事件流中。需要注意的是，包含關系是UML1.3中的表述，在UML1.1中，同等語義的關系被表述為使用(uses)。1、包含四、用例之間的各種重要關系包含關系代表著基礎用例會用37四、用例之間的各種重要關系

在處理包含關系時，具體的做法就是把幾個用例的公共部分單獨的抽象出來成為一個新的用例。主要有兩種情況需要用到包含關系：第一，多個用例用到同一段的行為，則可以把這段共同的行為單獨抽象成為一個用例，然后讓其他用例來包含這一用例。第二，某一個用例的功能過多、事件流過于復雜時，我們也可以把某一段事件流抽象成為一個被包含的用例，以達到簡化描述的目的。1、包含四、用例之間的各種重要關系在處理包含關系時，具體的做38四、用例之間的各種重要關系

在一定條件下，把新的行為加入到已有的用例中，獲得的新用例叫做擴展用例(Extension)，原有的用例叫做基礎用例(Base)，從擴展用例到基礎用例的關系就是擴展關系。一個基礎用例可以擁有一個或者多個擴展用例，這些擴展用例可以一起使用。

2、擴展四、用例之間的各種重要關系在一定條件下，把新的行為加39四、用例之間的各種重要關系

用例的泛化指的是一個父用例可以被特化形成多個子用例，而父用例和子用例之間的關系就是泛化關系。在用例的泛化關系中，子用例繼承了父用例所有的結構、行為和關系，子用例是父用例的一種特殊形式。子用例還可以添加、覆蓋、改變繼承的行為。在UML中，用例的泛化關系通過一個三角箭頭從子用例指向父用例來表示。

3、泛化四、用例之間的各種重要關系用例的泛化指的是一個父用例40四、用例之間的各種重要關系

泛化的示例：銀行存款有兩種方式，一種是銀行柜臺存款，一種是ATM機存款。在這里，銀行柜臺存款和ATM機存款都是存款的一種特殊方式，因此“存款”為父用例，“銀行柜臺存款”和“ATM機存款”為子用例。3、泛化四、用例之間的各種重要關系泛化的示例：銀行存款有兩種41五、使用Rose創建用例圖的步驟說明

“企業進、存、銷管理系統”功能性需求包括以下內容：（1）采購員根據生產原料的使用情況判斷采購用品，對需要訂購產品信息統計訂貨的，并制作產品訂單。最后根據訂單進行采購活動。（2）倉庫管理員負責產品的庫存管理。包括產品入庫管理、處理盤點信息、處理報損產品信息和一些信息的設置。這些設置信息，包括：供應商信息、產品信息。倉庫管理員每天對產品進行一次盤點，當發現庫存產品有損壞時，及時處理報損信息。當產品生產后，將產品進行入庫。當產品銷售后時，產品進行出庫處理。（3）統計人員負責統計分析管理，包括：查詢產品信息、查詢銷售信息、查詢供應商信息、查詢缺貨信息、查詢報表信息，并制作報表。統計分析員使用系統的統計分析功能，了解產品信息、銷售信息、供應商信息、庫存信息。（4）在銷售員為客戶提供售貨服務時，接受客戶購買產品，根據系統的定價計算出產品的總價，客戶付款，系統自動保存客戶購買記錄。（5）系統管理員負責本系統的系統維護。系統管理員負責員工信息管理、供貨商信息管理以及系統維護等。每種管理者都通過自己的用戶名稱和密碼登錄到各自的管理系統中。1、需求分析五、使用Rose創建用例圖的步驟說明“企業進、存、銷42五、使用Rose創建用例圖的步驟說明

（1）銷售