Uml學習-用例建模簡介

用例建模簡介 

用例建模是UML建模的一部分，它也是UML裏最基礎的部分。用例建模的最主要功能就是用來表達系統的功能性需求或行爲。用例圖重點描述用戶需求。 它描述需求、用戶和主要組件之間的關係。 它不會詳細描述用戶需求；在可連接到每一個用例的其餘關係圖或文檔中可詳細描述這些需求。用例圖是UML的九個圖中較爲重要和經常使用的一種圖。經常用於軟件開發的需求分析階段，也能用於軟件的系統測試階段。簡單的來講，用例圖是描述系統的外部視圖，爲了搞清某個項目的大概需求，咱們每每要問兩個問題，

1．  這個系統有什麼用？有哪些人蔘與?

2．  這些人經過這個系統能作些什麼事？

經過這兩個問題，通常就能比較清楚地表達系統的需求了，用例圖就是用來回答這兩個問題的，它能從比較清晰的角度來表達系統的需求，並且不涉及到技術用語。

 

用例建模可分爲用例圖和用例描述。

用例圖由參與者（Actor）、用例（Use Case）、系統邊界、箭頭組成，用畫圖的方法來完成。

用例描述用來詳細描述用例圖中每一個用例，用文本文檔來完成。 

1．  參與者(Actor)

在一個系統開發前，咱們一定首先要肯定系統的用戶，系統的用戶就是系統的參與者。除此之外，咱們還會想一想咱們開發的系統與其餘的系統有什麼關聯？所以，系統的參與者可分爲兩類，一類是人，包括系統的使用者、維護者等，另一類是其餘系統。

參與者不是特指人，是指系統之外的，在使用系統或與系統交互中所扮演的角色。所以參與者能夠是人，能夠是事物，也能夠是時間或其餘系統等等。還有一點要注意的是，參與者不是指人或事物自己，而是表示人或事物當時所扮演的角色。好比小明是圖書館的管理員，他參與圖書館管理系統的交互，這時他既能夠做爲管理員這個角色參與管理，也能夠做爲借書者向圖書館借書，在這裏小明扮演了兩個角色，是兩個不一樣的參與者。參與者在畫圖中用簡筆人物畫來表示，人物下面附上參與者的名稱。

 

2．  用例是對包括變量在內的一組動做序列的描述，系統執行這些動做，併產生傳遞特定參與者的價值的可觀察結果。咱們能夠這樣去理解，用例是參與者想要系統作的事情。對於對用例的命名，咱們能夠給用例取一個簡單、描述性的名稱，通常爲帶有動做性的詞。用例在畫圖中用橢圓來表示，橢圓下面附上用例的名稱。

 

3．系統邊界是用來表示正在建模系統的邊界。邊界內表示系統的組成部分，邊界外表示系統外部。系統邊界在畫圖中方框來表示，同時附上系統的名稱，參與者畫在邊界的外面，用例畫在邊界裏面。由於系統邊界的做用有時候不是很明顯，因此我我的理解，在畫圖時可省略。  

4．箭頭用來表示參與者和系統經過相互發送信號或消息進行交互的關聯關係。箭頭尾部用來表示啓動交互的一方，箭頭頭部用來表示被啓動的一方，其中用例老是要由參與者來啓動。  

 

一：用例之間的關係

1角色的繼承

 

 

2： 用例的包含(Include) 包含關係指用例能夠簡單地包含其餘用例具備的行爲，並把它所包含的用例行爲做爲自身行爲的一部分。在UML中，包含關係是經過帶箭頭的虛線段加<<include>>字樣來表示，箭頭由基礎用例(Base) 指向被包含用例(Inclusion)

         在處理包含關係時，具體的作法就是把幾個用例的公共部分單獨的抽象出來成爲一個新的用例。主要有兩種狀況須要用到包含關係：

A） 第一，多個用例用到同一段的行爲，則能夠把這段共同的行爲單獨抽象成爲一個用例，而後讓其餘用例來包含這一用例。

B） 第二，某一個用例的功能過多、事件流過於複雜時，咱們也能夠把某一段事件流抽象成爲一個被包含的用例，以達到簡化描述的目的。

 

3: 擴展關係 在必定條件下，把新的行爲加入到已有的用例中，得到的新用例叫作擴展用例(Extension) ，原有的用例叫作基礎用例(Base) ，從擴展用例到基礎用例的關係就是擴展關係。一個基礎用例能夠擁有一個或者多個擴展用例，這些擴展用例能夠一塊兒使用。

 

二． 用例描述  

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

下面是一個用例描述模板：

編號	[用例編號,如 UC-01]	名稱	[用例名稱,即用例圖中用例的描述]
執行者	[用戶，角色等]
描述	[簡單的描述本用例，重點說明執行者的目標]
前置條件	[列出執行本用例前必須存在的系統狀態，如：必須錄入什麼數據，須選實現其餘什麼用例等。注意除非狀況特殊，不要寫相似」登陸系統」等每一個用例幾乎都須要具有的前置條件。]
基本流程	[說明在「正常」的狀況下，最經常使用的流程，一般是執行者和系統之間交互的文字描述]
結束狀態	[列出在「正常」結束的狀況下的用例的結果]
可選流程1	[說明 和基本流程不一樣的其餘可能的流程]
可選流程N	[說明 和基本流程不一樣的其餘可能的流程]
異常流程	[說明出現錯誤或其餘異常狀況時和基本流程的不一樣之處]
說明	[對本用例的補充說明，如：業務概念，業務規則等]

 

 三． 用例圖和用例描述設計實例 

這裏以以前的那個考勤系統爲例來簡單分析一個用例圖的畫法。

經分析系統中涉及的角色有以下： 普通員工、行政部員工、財務部員工、部門經理、總經理。

角色的繼承關係以下：

 

 

普通員工的用例：

 

下面是關於普通員工的」提出請假申請」的用例描述

編號	1.1	名稱	提出請假申請
執行者	普通員工
描述	普通員工錄入請假的信息，能成功提出請假申請
前置條件	無
基本流程	1: j顯示請假申請表單。 2：填寫請申請單，選擇請假類型 3：提交申請 4:顯示成功提交的申請信息並返回列表。
結束狀態	系統保存請假申請數據，並提示成功提交申請的信息
可選流程1	3：取消請假申請 4：返回列表
異常流程	2：填寫請申請單，選擇請假類型爲」年假」 3：提交申請 4：提示可休年假不足，顯示相應信息。 5： 修改請假申請單，或取消請假申請.
說明	請假申請單有如下內容：申請者，開始時間，結束時間，請假事由，請假類別。 申請假默認爲當前的用戶，不可修改。 請假的類別爲：事假，病假，婚 嫁，產假，年假，只能並且必須選其一

 其它的用述描述再也不贅述。

 

 以上內容來自於 【火球UML大戰需求分析】中，做爲學習筆記記錄一下