1. 程式人生 > >用例圖及用例描述

用例圖及用例描述

一.UML簡介

UML(統一建模語言,Unified Modeling Language)是一種定義良好、易於表達、功能強大且普遍適用的視覺化建模語言。它融入了軟體工程領域的新思想、新方法和新技術。它的作用域不限於支 持面向物件的分析與設計,還支援從需求分析開始的軟體開發的全過程。在系統分析階段,我們一般用UML來畫很多圖,主要包括用例圖、狀態圖、類圖、活動 圖、序列圖、協作圖、構建圖、配置圖等等,要畫哪些圖要根據具體情況而定。其實簡單的理解,也是個人的理解,UML的作用就是用很多圖從靜態和動態方面來 全面描述我們將要開發的系統。

二.用例建模簡介

用例建模是UML建模的一部分,它也是UML裡最基礎的部分。用例建模的最主要功能就是用來表達系統的功能性需求或行為。依我的理解用例建模可分為 用例圖和用例描述。用例圖由參與者(Actor)、用例(Use Case)、系統邊界、箭頭組成,用畫圖的方法來完成。用例描述用來詳細描述用例圖中每個用例,用文字文件來完成。

1. 用例圖

參與者不是特指人,是指系統以外的,在使用系 統或與系統互動中所扮演的角色。因此參與者可以是人,可以是事物,也可以是時間或其他系統等等。還有一點要注意的是,參與者不是指人或事物本身,而是表示 人或事物當時所扮演的角色。比如小明是圖書館的管理員,他參與圖書館管理系統的互動,這時他既可以作為管理員這個角色參與管理,也可以作為借書者向圖書館 借書,在這裡小明扮演了兩個角色,是兩個不同的參與者。參與者在畫圖中用簡筆人物畫來表示,人物下面附上參與者的名稱。

用例是對包括變數在內的一組動作序列的描述,系統執行這些動作,併產生傳遞特定參與者的價值的可觀察結果。這是 UML對用例的正式定義,對我們初學者可能有點難懂。我們可以這樣去理解,用例是參與者想要系統做的事情。對於對用例的命名,我們可以給用例取一個簡單、 描述性的名稱,一般為帶有動作性的詞。用例在畫圖中用橢圓來表示,橢圓下面附上用例的名稱。

系統邊界是用來表示正在建模系統的邊界。邊界內表示系統的組成部分,邊界外表示系統外部。系統邊界在畫圖中方框來表示,同時附上系統的名稱,參與者畫在邊界的外面,用例畫在邊界裡面。因為系統邊界的作用有時候不是很明顯,所以我個人理解,在畫圖時可省略。

箭頭用來表示參與者和系統通過相互發送訊號或訊息進行互動的關聯關係。箭頭尾部用來表示啟動互動的一方,箭頭頭部用來表示被啟動的一方,其中用例總是要由參與者來啟動。

2. 用例描述

用例圖只是簡單地用圖描述了一下系統,但對於每個用例,我們還需要有詳細的說明,這樣就可以讓別人對這個系統有一個更加詳細的瞭解,這時我們就需要寫用例描述。

對於用例描述的內容,一般沒有硬性規定的格式,但一些必須或者重要的內容還是必須要寫進用例描述裡面的。用例描述一般包括:簡要描述(說明)、前置(前提)條件、基本事件流、其他事件流、異常事件流、後置(事後)條件等等。下面說說各個部分的意思:

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

前置條件:執行用例之前系統必須要處於的狀態,或者要滿足的條件;

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

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

異常事件流:表示發生了某些非正常的事情所要執行的流程;

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

三. 用例圖和用例描述設計例項

這裡用我開發的一個家教網站來簡單的分析用例圖的畫法和用例描述的寫法。這個網站我用UML完整的分析一下,以下我提取了用例圖和用例描述的部分。這個家教網站分為前臺客戶系統和後臺管理系統。

前臺客戶系統的用例圖如下:


後臺管理系統用例圖如下:


對於用例描述,篇幅有限,我在這裡只列了後臺管理系統中的網站公告發布這個用例的描述。如下:

用例名稱:網站公告發布
用例標識號:202
參與者:負責人
簡要說明

負責人用來填寫和修改家教網站首頁的公告,公告最終顯示在家教網站的首頁上。
前置條件:

負責人已經登陸家教網站管理系統
基本事件流:

1.負責人滑鼠點選“修改公告”按鈕

2.系統出現一個文字框,顯示著原來的公告內容

3.負責人可以在文字框上修改公告,也可以完全刪除,重新寫新的公告

4.負責人編輯完文字框,按“提交”按鈕,首頁公告就被修改

5.用例終止
其他事件流A1

在按“提交”按鈕之前,負責人隨時可以按“返回”按鈕,文字框的任何修改內容都不會影響網站首頁的公告
異常事件流

1.提示錯誤資訊,負責人確認

2.返回到管理系統主頁面
後置條件

網站首頁的公告資訊被修改
註釋:無
四. 總結

其實用例建模並不是這麼簡單,它涉及到的知識還有很多,這裡只是簡單的介紹一下。

感謝:http://www.51cto.com 2006-01-13 10:10 出處:51CTO.com整理


補充:

用例之間也可以存在包含、擴充套件和泛化等關係:

  (1)包含關係:用例可以簡單地包含其他用例具有的行為,並把它所包含的用例行為做為自身行為的一部分,這被稱作包含關係。

  (2)擴充套件關係:擴充套件關係是從擴充套件用例到基本用例的關係,它說明為擴充套件用例定義的行為如何插入到為基本用例定義的行為中。它是以隱含形式插入的,也就是說,擴充套件用例並不在基本用例中顯示。在以下幾種情況下,可使用擴充套件用例:

  a.表明用例的某一部分是可選的系統行為(這樣,您就可以將模型中的可選行為和必選行為分開);

  b.表明只在特定條件(如例外條件)下才執行的分支流;

  c.表明可能有一組行為段,其中的一個或多個段可以在基本用例中的擴充套件點處插入。所插入的行為段和插入的順序取決於在執行基本用例時與主角進行的互動。

  圖2.3給出了一個擴充套件關係的例子,在還書的過程中,只有在例外條件(讀者遺失書籍)的情況下,才會執行賠償遺失書籍的分支流。


(3)泛化關係:用例可以被特別列舉為一個或多個子用例,這被稱做用例泛化。當父用例能夠被使用時,任何子用例也可以被使用。如在圖2.4中,訂票是電話訂票和網上訂票的抽象。


------------------------------------------------------------

泛化、包含和擴充套件

泛化(Generalization)在面嚮物件的技術中無處不在,它的另一個名字也許更為著名,就是“繼承”。下圖給出了一個使用泛化的用例圖:


可知,在用例圖中,角色和用例都能夠泛化。角色的泛化/繼承很容易理解,因為角色本來就是類(Class),它是一種版型(stereotype)為Actor的類,所以角色的繼承直觀而自然。但是用例的繼承實際上分為兩種情況,並不是簡單的使用泛化,而是使用擴充套件(extended)和包含(include)兩種泛化的特例。

擴充套件用於子用例的動作步驟基本上和父用例的動作步驟相同,只是增加了另外的一些步驟的情況下。包含用於子用例包含了所有父用例的動作,它將父用例作為了自己的一個大步驟,子用例常常包含一個以上的父用例。如下圖: