初學UML之-------用例圖

 本文轉載至：http://blog.csdn.net/a649518776/article/details/7493148

一．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）兩種泛化的特例。

擴展用於子用例的動做步驟基本上和父用例的動做步驟相同，只是增長了另外的一些步驟的狀況下。包含用於子用例包含了全部父用例的動做，它將父用例做爲了本身的一個大步驟，子用例經常包含一個以上的父用例。以下圖：