UML用例圖-筆記

UML筆記

一、用例圖（User Case）

用例的基本特征：

1、一個完整的用例定義由參與者、前置條件、場景和後置條件構成，如下圖所示：

2、用例是互相獨立的

         說明：不需要與其他用例互動而獨自完成參與者的目的；

                     任何一個用例必須對于參與者來說有實際的目的以及意義

3、用例必須是由參與者發起的，不存在沒有參與者的用例，用例不應該自己啟動，也不應該主動啟動

4、用例必然是以動賓短語的形式出現的

         用例必須有一個動作和動作的受體，而不僅隻是一個單獨的行為。

5、一個用例就是一個需求單元、分析單元、設計單元、開發單元、測試單元，甚至是部署單元

用例的粒度：

1、 在業務模組化階段，用例的粒度以每個用例能夠說明一件完整的事情為宜。

2、 在系統模組化階段，用例視角是針對計算機的，是以用例的粒度是以一個用例能夠描述操作者與計算機的一次完整互動為宜。

用例的擷取：

1、 用例的定義是參與者來驅動的

2、 用例的來源是參與者對系統的期望

3、 發現用例的前置條件就是發現參與者

4、 确定參與者的同時就是确定了系統的邊界

了解用例的主角：

1、 主角是位于系統邊界之外的

2、 主角對系統有着明确的期望和明确的回報要求

3、 主角的期望和回報要求在系統邊界之内的

了解用例需求的特征：

1、 一個明确的有效的目标才是一個用例的來源

2、 一個真實的目标應該完備地表達主角的期望

3、 一個有效的目标應當在系統邊界内，由主角發動，并具有明确的後果

用例和功能的誤區：

1、 用例的分析過程是面向對象的

2、 功能點的分析過程是面向過程的

3、 描述一個事物，從如下三個觀點出發：

l  這個事物是什麼

l  這個事物能做什麼

l  人們能夠用這個事物做什麼

4、使用者的觀點其實就是用例的觀點

5、用例和功能的區分如下：

l  功能是脫離使用者的願望而存在的

l  功能是孤立的，給一個輸入，通過計算就有一個固定的輸出；而用例是系統性的，是由誰來在什麼情況下使用一個什麼樣的功能

l  如果非要從功能的角度解釋 用例，那麼用例可以解釋為一系列完成一個特定目标的“功能”的組合，針對這些不同的應用場景，這些“功能”展現不同的組合方式。必須是先有場景，才有了功能的

6、 UML中其實是沒有功能這個詞的

用例粒度的誤區：

1、 在同一個需求階段，必須保持所有的用例的粒度在同一個量級上

2、 用例粒度必須建立在合适的邊界上，比如系統級别、業務級别

3、 抽象層次決定于用例的粒度

用例之間的關系：

1、 擴充關系，表示用例場景中某個支流，由特定的擴充點出發而被啟動的。它與包含關系的差別是，擴充表示是可選的，而不是必須的，這就意味着即使沒有擴充用例，基本用例也是完整的；如果有多個擴充用例，在同一時間用例執行個體也隻有一個。

擴充關系的原則：表明用例的某一部分是可選的系統行為。

2、 包含關系，基本用例可控制與包含用例的關系，并可依賴于執行包含用例所得的結果，但基本用例和包含用例都不能通路對方的屬性。

包含關系的原則：

l  包含用例是的必需的，而不是可選的，沒有包含用例，基本用例就是不完整的

3、 泛化關系，表示兩個對象之間的繼承關系，箭頭所指的方向表示父類

備注：用例之間的關系，通常隻需要兩種關系來描述就可以了，包含和擴充。

本文轉自一米一陽光部落格園部落格，原文連結：    <b>http://www.cnblogs.com/candle806/archive/2013/03/15/2961474.html</b>，如需轉載請自行聯系原作者