天天看點

uml用例如何描述

來源:http://space.itpub.net/118838/viewspace-483405

一、難點:

寫 好用例就必須了解以下三個概念: --範圍 scope:真正被讨論的系統是什麼? --主執行者 primary actor:    誰有要實作的目标? --層次 level:   目标泊層次是高,還是低? 經典,現在隻體會到先确定範圍和 主執行者才能提到描述用例,還要在沉澱。經驗隻能借鑒而不能照搬!!!! 轉: --------------------------- 正體字為原文,斜體字 為本人見解

1、用例是代表系統中各個項目相關人員之間就系統的行為所達成的契約。用例描述了在不同 條件下,系統對某一項目相關人員的請求所作出的響應。

從文字上看,比較難了解,舉個比較經典的例 子:某人在ATM機提款,這個本身就可以看作一個用例,隻是它的層次比較高,細分下去,人可以在ATM上做什麼?粗略一想,就有幾條:(1)查詢餘額 (2)提款(3)轉帳(4)存款,這四點都可以獨立成為一個用例,而且執行者都是人,簡單來說,用例就是描述執行者和系統之間的互動的集合。

2、 從根本上說,用例是文本形式;他們是作為人與人之間,尤其是沒有受過專門教育訓練的人員之間互相交流的一種手段。是以,簡單的文本通常是編寫用例的首選形式。

很 多人一看到“用例”這兩個字就和用例圖聯系在一起,就是一個小人,一個橢圓,中間有線連接配接那種圖,其實用例圖隻是用例的圖形化表示,用例真正的内容展現在 它的文本描述中,而且描述的語言和平時人們日常寫作的語言一樣,一般有國中文化的人都看的懂。

3、 編寫用例必須掌握的三個概念:

(1)     範圍(scope):真正被讨論的系統是什麼?

(2)     主執行者(primary actor):誰有要實作的目标?

(3)     層次(level):目标的層次是高還是低?

範圍很重要,這個和 項目管理 裡 面的項目範圍概念差不多,不過可能它的粒度小一點,有個可能一個用例隻是一個項目的一小塊功能互動,隻有明确好範圍,才能真正把握需求,但這個還需開發方 與客戶不斷的溝通才能确定。主執行者與項目管理的項目幹系人有些聯系,很多用例主執行者就是項目幹系人中的一員。

4、 隻有一個用例模闆是不夠的。至少要有兩個用例模闆:一個是非正式的(或稱随意的),在要求不嚴的項目中使用;另一個是完整正式的,在要求嚴格的項目中使 用。

無論正式還是非正式,隻要能使客戶和開發人員能建立有效的溝通途徑,就是好用例,隻是有時候一 些項目要求比較嚴格,文檔寫的也比較正式而已。

5、如果把用例作為需求來編寫,請 謹記以下兩點 :

(1)     用例确實是需求。不必将用例轉變成行為需求的其他形式。

(2)     用例不是所有的需求。用例不詳細地描述外部接口、資料格式、業務規則和複雜公式。

需求包含用例,用 例屬于需求的一部分,這恰恰反應了:“用例不是萬能的....”,下一句想必不用說都知道了吧,呵呵。

6、 用例僅僅是行為需求,并且是所有的行為需 求。

注意後半句

小結:這一章 主要是為用例定位,以及怎麼樣在不同的環境和時間安排下編寫用例,使其達到最好的效果。 ------------------------------------------------ 二、基本定義: 執 行者 actor:任何具有行為的人或物。 項目相關人員 stakeholder :對被讨論系統的行為有特定興趣的人或物。 主 執行者 primary actor:啟動與被讨論系統的一次互動活動,進而達到某一目标的人或物。 用例 use case:規定被讨論系統行為的契約。 範圍 scope:界定被讨論的系統。 前置條件和保證 precondition and guarantee:在用例執行之前和之後必須滿足的條件。 主成功場景 main success scenario:一切順利的情況。 擴充 extension:場景執行過程中出現 的不同情況。 擴 展中的編号:是指在主成功場景中不同情況發生時所處的執行步驟号碼(例如,步驟4a步驟4b是指主成功場景中步驟4的兩種不同情況) 下 劃線:當一個用例引用另一個用例時,被引用的用例加下劃線。 ----詳細  格式  begin ------ 用例名稱: 

通常為動賓詞組,展現出對使用者有價值的功能目标 

類型: 

BUC|BUCR|SUC 

範 圍: 

寫出具體的SuD名稱 

層次: 

++|+|!|-|-- 

優先級: 

High|Medium|Low 

版 本: 

目前版本 

作者: 

目前版本的作者 

日期: 

目前版本的日期 

變更曆史: 

曆史 版本号 (日期) 版本說明;變更事項 修訂者 

用例圖: 說明此用例的 SuD 以及主要用角關系(主用角、次用角、輔用角)和用例關系(包含、擴充、繼承)等 

相關用例: 

與此用例相關、存在重要聯系的用 例 

簡述/背景: 

說明此用例的主要目的,基本内容和相關背景 

實作的特性: 

依次列出此用例實作的主要系統特 性(Feature) 

情節舉例: 

用具體的執行個體說明用例執行的一個情況。 

主用角責權利: 

主用角: 責權利 

其他幹系者責權利: 

說明除主用角外,其他次用角、幹系人、外部系統的責權利,所扮演的角色 

幹系者名 稱:責權利 

... 

後置狀态 

與條件 

最小保證: 

無論用例執行成功或失敗,系統對所有幹系者作出的 最小/最起碼的承諾 

保證條件說明 

成功保證: 

用例目标成功達成後,系統為滿足所有幹系者的利益而作出的承諾,達到的 狀态和滿足的條件 

成功狀态名稱:狀态說明,應滿足的條件 

... 

失敗保證: 

用例目标失敗後,系統 為滿足所有幹系者的利益而作出的承諾,達到的狀态和滿足的條件 

失敗狀态名稱:狀态說明,應滿足的條件 

... 

前置狀 态與條件: 

用例開始執行前所處的狀态和/或應滿足的條件 

狀态名稱:狀态說明,條件說明 

... 

觸發事 件: 

觸發用例從前置狀态開始執行的事件 

基本流: 

說明一個最主要的成功執行路徑 

{名稱标記} 

步 驟編号 事件/步驟描述 

... 

公共流: 被此用例的其他動作流引用的公共步驟 

{動作流名稱} 

{片 斷名稱标記} 

步驟編号 事件/步驟描述 

... 

擴充流: 

說明除基本流之外的其他成功流、 失敗流和可選、替換流 

{擴充名稱标記} 

擴充位置引用 

擴充條件: 

擴充處理 

... 

擴 展點: 

此用例允許其他用例擴充插入的位置 

擴充點名稱 {擴充點在基本流、擴充流當中的位置} 

技術和資料變化: 

此 用例執行時,在技術和資料方面不同的做法 

非功能需求: 

(URPS+) 

包括易用性、可靠性、性能、可維護性等方面的要求 

業 務規則: 

作用于此用例的各項業務限制 

資料字段: 

說明此用例中用到資料的字段名稱、類型等細節,可與領域模型聯系起 來 

未決問題: 

此用例目前存在的問題 

備注: 

其他任何需要說明、補充的事項 

---- 詳細  格式  end ------

三、例子 用例1:(符号)通過網際網路購買股票 (注:這裡的符号可以是“黑盒”符号,表示程式運作在與網際網路相連的工作站上,表示所讨論的系統 是一個計算機系統,符号的使用完全可以根據個人的喜好來選擇,但對範圍和層次的标記卻不是)

 主 執行者:購買者

範圍:私人顧問/金融包

層次:使用者目标

項目相關人員和利益:

        購買者----購買股票,并希望所買股票能自動被加到PAF記錄中。

        股票代理商----希望得到全部的購買資訊。

前置 條件:使用者已經打開PAF。

最小保證:有足夠的登入資訊,以便當出現問題時,PAF能夠檢測到問題,并要求使用者提供更詳細的資訊。

成功保 證:遠端web 站點認可此次購買事件;日志和使用者記錄被更新。

主 成功場景:

1、購買者選擇通過網際網路來購買股票。

2、PAF從使用者那裡得到所用站點的名稱(如E*Trade、Schwab等)。

3、 PAF與該站點建立網絡連接配接,并保持控制權。

4、購買者在該站點上浏覽并購買股票。

5、PAF截取站點的響應資訊,并更新購買者的記錄。

6、 PAF向使用者顯示更新後的記錄情況。

擴充:

2a、購買者要使用一個PAF不支援的站點:

    2a1:系統從購買者那裡擷取建立議,帶有取消用例的選項。

3a、在設定過程中,網絡發生故障:

    3a1:系統向購買者報告錯誤,并建議他退回到前一步。

    3a2:購買者或者此用例,或者重新再試。

4a、計算機系統崩潰或者在 交易過程中被關掉:

    4a1:(這時,我們該怎麼辦?)

4b、Web站點沒有及時認可此次購買活動,而是把它推遲處理:

    4b1:PAF把這次推遲事件記入日志,設定一個時鐘,定期向購買者詢問結果。

5a、Web站點沒有傳回關于購買情況的必要資訊:

    5a1:PAF把缺少資訊的事件記入日志,要求購買者更新存有疑問的交易 。

下 面是用例網站公告釋出的用例描述   用例名稱:網站公告釋出    用例辨別号:202     參與者:負責人    簡要說明:   負責人用來填寫和修改家教網站首頁的公告,公告最終顯示在家教網站的 首頁上。    前置條件:   負責人已經登陸家教網站管理系統    基本事件流:    1. 負責人滑鼠點選“修改公告”按鈕   2. 系統出現一個文本框,顯示着原來的公告内容   3. 負責人可以在文本框上修改公告,也可以完全删除,重新寫新的公告   4. 負責人編輯完文本框,按“送出”按鈕,首頁公告就被修改    5. 用例終止    其他事件流A1:   在按“送出”按鈕之前,負責人随時可以按“傳回”按鈕,文本框 的任何修改内容都不會影響網站首頁的公告    異常事件流:   1. 提示錯誤資訊,負責人确認    2. 傳回到管理系統首頁面    後置條件:   網站首頁的公告資訊被修改     注釋:無 例 子3 轉: http://www.cnblogs.com/wxohyer/archive/2006/11/06/552363.html

用例:

用例視圖向外部使用者展示了其捕獲的系統、子系統、類 或者元件的行為。它将系統功能劃分成對執行者和有意義的事物。而互動功能的部分被稱作用例。

是 代表系統中各個項目相關人員之間就形态行為。所達成的契約。

uml用例如何描述

編寫用例必須掌握三個概念

  • 範 圍:真正被讨論的系統是什麼?
  • 主執行者:誰有要實作的目标?
  • 層 次:目标的層次是高是低?

其它概念:

  • 執 行者:任何具有行為的人或物
  •   項 目相關人員:對被讨論的系統的行為有特定興趣的人或物
  • 主執行者:啟動與被讨論系統得一次互動活動,進而達到 某一個目标的人或物
  • 用例:規定被讨論系統行為的契約
  • 範圍:界 定被讨論的系統
  • 前置條件和保證:在用例執行之前和之後必須滿足的條件
  • 主 成功場景:一切順利的情況
  • 擴充:場景執行過程中出現的不同情況

三 個命名的目标層次

1.          概 要層次

包含多個使用者目标。在描述系統時,它們有如下三個方面的功能:

        顯示使用者目标運作的語境

        顯示相關目标的生命周期順序

        為 低層用例(包括白色用例和藍色用例)提供一個目錄表。

2.          用 戶目标級

它是主執行者努力使工作得以完成的目标,或是使用者使用系統的目标。

3.          子 功能級

是指那些再實作使用者目标時可能會被用到的目标。

用例模闆

    用例圖隻是簡單地可視化描述系統,我們還需要對用例進行詳細的說明。為了明确的描述用例我們需要一個用例模闆,但是至今并沒有統一的用例模闆。用例模闆的 内容一般包括:簡要描述、前置條件、後置條件、基本事件流、備選事件流等等。

  簡要描述:對用例的角色、目的的簡要描述。

  前置條 件:執行用例之前系統必須要處于的狀态,或者要滿足的條件。

  後置條件:用例一旦執行後系統所處的狀态。

  基本事件流:描述該用例的 基本流程,指每個流程都“正常”運作時所發生的事情,沒有任何備選流而隻有最有可能發生的事件流。

  備選事件流:表示這個行為或流程是可選的或 備選的,并不是總要總要執行它們。

下面是一個用例模闆的示例:  

用例: < 編号 >< 名 稱 >

特 征資訊:

     用例在系統中的目标(用例目标描述)

     範圍(目前考慮的是哪個系統)

     級别(概要任務 / 首 要任務 / 子功能)

     前提條件(用例執行前系統用具有的狀态)

     成功後繼條件(用例成功執行後應具有的狀态)

     失效後繼條件(用例沒有完成目标的狀态)

     首要角色(與該用例關聯的首要角色)

     觸發(啟動該用例執行的系統動作)

主 要步驟:

     < 步驟編号 >< 動作描述 >

擴 展:

     < 有變化情況的步 驟編号 >< 條件 >:< 動作或另外一個用例 >

變 異:

     < 步驟或變化編号 >< 變異清單 >

相 關資訊:(可選)

     優先級(該用例對于系統組織 的關鍵程度)

     性能目标(該 用例的執行時間耗費)

     頻 度(該用例被執行的頻度)

從屬用例:(可選)

下 屬用例:

與首要角色的聯系管道(包括互動式、靜态檔案、資料庫 等)

公 開問題:(可選)

posted on 2006-11-06 22:50 王興  閱讀 (474) 評論(1)   編輯  收藏  網摘  所屬分類: 技術文章

uml用例如何描述

評論

#1樓   [樓主 ]  2006-11-07 22:09  王興       

用例名 稱: 

通常為動賓詞組,展現出對使用者有價值的功能目标 

類型: 

BUC|BUCR|SUC 

範圍: 

寫 出具體的SuD名稱 

層次: 

++|+|!|-|-- 

優先級: 

High|Medium|Low 

版 本: 

目前版本 

作者: 

目前版本的作者 

日期: 

目前版本的日期 

變更曆史: 

曆史 版本号 (日期) 版本說明;變更事項 修訂者 

用例圖: 說明此用例的 SuD 以及主要用角關系(主用角、次用角、輔用角)和用例關系(包含、擴充、繼承)等 

相關用例: 

與此用例相關、存在重要聯系的用 例 

簡述/背景: 

說明此用例的主要目的,基本内容和相關背景 

實作的特性: 

依次列出此用例實作的主要系統特 性(Feature) 

情節舉例: 

用具體的執行個體說明用例執行的一個情況。 

主用角責權利: 

主用角: 責權利 

其他幹系者責權利: 

說明除主用角外,其他次用角、幹系人、外部系統的責權利,所扮演的角色 

幹系者名 稱:責權利 

... 

後置狀态 

與條件 

最小保證: 

無論用例執行成功或失敗,系統對所有幹系者作出的 最小/最起碼的承諾 

保證條件說明 

成功保證: 

用例目标成功達成後,系統為滿足所有幹系者的利益而作出的承諾,達到的 狀态和滿足的條件 

成功狀态名稱:狀态說明,應滿足的條件 

... 

失敗保證: 

用例目标失敗後,系統 為滿足所有幹系者的利益而作出的承諾,達到的狀态和滿足的條件 

失敗狀态名稱:狀态說明,應滿足的條件 

... 

前置狀 态與條件: 

用例開始執行前所處的狀态和/或應滿足的條件 

狀态名稱:狀态說明,條件說明 

... 

觸發事 件: 

觸發用例從前置狀态開始執行的事件 

基本流: 

說明一個最主要的成功執行路徑 

{名稱标記} 

步 驟編号 事件/步驟描述 

... 

公共流: 被此用例的其他動作流引用的公共步驟 

{動作流名稱} 

{片 斷名稱标記} 

步驟編号 事件/步驟描述 

... 

擴充流: 

說明除基本流之外的其他成功流、 失敗流和可選、替換流 

{擴充名稱标記} 

擴充位置引用 

擴充條件: 

擴充處理 

... 

擴 展點: 

此用例允許其他用例擴充插入的位置 

擴充點名稱 {擴充點在基本流、擴充流當中的位置} 

技術和資料變化: 

此 用例執行時,在技術和資料方面不同的做法 

非功能需求: 

(URPS+) 

包括易用性、可靠性、性能、可維護性等方面的要求 

業 務規則: 

作用于此用例的各項業務限制 

資料字段: 

說明此用例中用到資料的字段名稱、類型等細節,可與領域模型聯系起 來 

未決問題: 

此用例目前存在的問題 

備注: 

其他任何需要說明、補充的事項

繼續閱讀