UML用例圖

原文地址： http://blog.csdn.net/zhuojiajin/article/details/8657853

 

　　看過了UML視頻，覺的UML裏的內容其實看的挺明白的。在開始畫圖的時候才發現，純粹是老師講到好。聽的明白或者說覺的本身明白了只是一種錯覺。對於UML裏的圖仍是理解上不夠透徹，固然如今要求本身就透徹也是癡人說夢。雖然是一種錯覺吧，好賴也讓我看視頻的時候感受的痛快。再者這種錯覺確定仍是以必定的「明白」爲根據的。因此這種錯覺我喜歡！這篇博客開始對UML中的9種圖作個總結，這一篇先講用例圖。

　　那麼用例圖是UML用來描述一個軟件系統中人和功能之間，即角色和用例之間的關係的一種圖形化的表達。能夠清晰的反應出角色的權限，角色的對應的功能之間的關係。它是從軟件系統的外部用戶的角度來描述系統、子系統或者類的行爲的。用例模型是有開發者和用戶共同達成的某種共識。用例模型用若干個用例圖描述。用例圖必須包含：功能的描述、角色、而且角色和功能對應關係。

 

　　角色（actor）：

軟件系統中的角色，是與系統、子系統、或類交互的外部人員、進程或事物的理想化。一個活動這能夠對應一個或多個用例。只要是和軟件系統有互動的外部對象均可是角色，例如：人員、其餘系統、外部服務器、數據庫等。UML中用小人圖形表示。在畫圖時，角色相對來講仍是比較好找的。

--能夠激活系統交互信息；

--能夠對系統進行輸入；

--能夠從系統被動的接受信息。

角色：角色既能夠是人也能夠是物

尋找執行者的幾個原則：

-誰使用系統的功能；

-誰須要系統支持平常工做；

-誰來維護關係系統；

-系統須要操縱那些硬件-須要與系統交互的其餘系統；

-對系統產生的結果感興趣的人或事物。

　　用例（usecase）：

用例是軟件系統中一個個的功能單元，用例的目的是定義清晰的行爲塊而不是解釋系統的結構。一個用例包括了它所具有的全部行爲：主線（理想功能）、行爲的不一樣變形、行爲的異常條件、以及所需的響應。其實就是一個完整的功能，能夠是一個大的功能模塊，也能夠是系統菜單上的每個功能。

　　關係（assosciation）：

用於描述角色和功能之間的關係，有四種：關聯、泛化、包含、擴展。

　　用例圖中的主要屬性：事件流、前置條件、後置條件、粒度、範圍

　　事件流：簡單的說就是一個用例要作什麼的問題，描述的是用例在執行時執行者和系統之間交互的過程。包括基本流（用例中常規和預期的路徑的描述：如登陸）和備選流（用例出現特殊狀況時執行的其餘路徑如錯誤處理）

　　--基本流--對用例中常規和預期路徑的描述

　　--備選流--因爲受到其餘因素影響，用例執行了其餘的路徑。

　　前置、後置條件：即用例執行時須要知足的條件和結束時的處理結果。應該是相似於DO while循環的兩種狀況。 

　　前置條件：該用例執行的前提條件，用來描述條件下能夠開始執行一個事件流。

　　後置條件：說明用力結束時系統的狀態。

　　粒度和範圍：是評價一個用例圖的優劣的屬性。描述了用例圖的寬度和離散程度吧。

　　UML用例圖的粒度與範圍：用例的多少、概述級、用戶目標級、子功能級。設計時要重要考慮的方面，一開始粗略的設計用例圖，而後慢慢細化。用例圖的粒度不該太粗或太細。

 

用例注意點：

◆應該清晰的定義系統邊界

◆防止用例過多

◆應該從執行者的角度來命名用例

◆用例描述的正規程度

◆避免執行者的名字不一致

◆避免執行者和用例之間的關係

◆注意用例的大小是否恰當（粒度）

◆避免用例描述混亂

◆區分用力分解和功能分解

◆避免客戶不能理解用例的狀況

◆有些場合，用用例來描述不適合 

 

　　下面來一個例子吧：自動售貨機銷售貨物功能，這裏個過程當中涉及的人員有：顧客 用例有：按鈕，指示燈，投幣槽，退幣槽。用例圖以下：