一．UML簡介

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

　　二、什么是用例

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

　　三、什么是用例圖

　　用例圖（use case diagram）就是由主角、用例以及它們之間的關系構成的圖。該圖說明了用例模型中的關系。

　　可以將用例圖組織到用例包中，并歸用例包所有，讓特定包中僅顯示互為關聯(lián)關系的內容。

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

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

　　如何發(fā)現角色：

　　1. 使用系統(tǒng)的主要功能的人是誰（即主要角色）？

　　2.需要借助于系統(tǒng)完成日常工作的人是誰？

　　3.誰來維護，管理系統(tǒng)（次要角色），保證系統(tǒng)正常工作？

　　4.系統(tǒng)控制的硬件設備有哪些？

　　5.系統(tǒng)需要與哪些其他系統(tǒng)交互？其他系統(tǒng)包括計算機系統(tǒng)，也包括該系統(tǒng)將要使用的計算機中的其他應用軟件。其他系統(tǒng)也分成兩類，一類是啟動該系統(tǒng)的系統(tǒng)，另一類是該系統(tǒng)要使用的系統(tǒng)。

　　6.對系統(tǒng)產生的結果感興趣的人或事是哪些？

　　用例：用例代表的是一個完整的功能。

　　如何發(fā)現用例：

　　1.角色需要從系統(tǒng)中獲得哪種功能？角色需要做什么？

　　2.角色需要讀取，產生，刪除，修改或存儲系統(tǒng)中的某種系統(tǒng)嗎？

　　3.系統(tǒng)中發(fā)生的事件需要通知角色嗎？或者角色需要通知系統(tǒng)某件事嗎？這些事件（功能）能干些什么？

　　4.如果用系統(tǒng)的新功能處理角色的日常工作是簡單化了，還是提高了工作效率？

　　5.還有一些與當前角色可能無關的問題，也能幫助建模者發(fā)現用例，例如：

　　6.系統(tǒng)需要的輸入/輸出是什么信息？這些輸入/輸出信息從哪兒來到哪兒去？

　　7.系統(tǒng)當前的這種實現方法要解決的問題是什么（也許用自動系統(tǒng)代替手工操作）?

　　四、UML用例圖中用例之間的關系：

　　主要用來圖示化系統(tǒng)的主事件流程，它主要用來描述客戶的需求，即用戶希望系統(tǒng)具備的完成一定功能的動作，通俗地理解用例就是軟件的功能模塊，所以是設計系統(tǒng)分析階段的起點，設計人員根據客戶的需求來創(chuàng)建和解釋用例圖，用來描述軟件應具備哪些功能模塊以及這些模塊之間的調用關系，用例圖包含了用例和參與者，用例之間用關聯(lián)來連接以求把系統(tǒng)的整個結構和功能反映給非技術人員（通常是軟件的用戶），對應的是軟件的結構和功能分解。

　　1）包含關系——include

　　包含關系：使用包含（Inclusion）用例來封裝一組跨越多個用例的相似動作（行為片斷），以便多個基（Base）用例復用?；美刂婆c包含用例的關系，以及被包含用例的事件流是否會插入到基用例的事件流中?；美梢砸蕾嚢美龍?zhí)行的結果，但是雙方都不能訪問對方的屬性。

　　UML用例圖關系中包含關系最典型的應用就是復用，也就是定義中說的情景。但是有時當某用例的事件流過于復雜時，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個被包含的用例；相反，用例劃分太細時，也可以抽象出一個基用例，來包含這些細顆粒的用例。這種情況類似于在過程設計語言中，將程序的某一段算法封裝成一個子過程，然后再從主程序中調用這一子過程。　

　　例如：業(yè)務中，總是存在著維護某某信息的功能，如果將它作為一個用例，那添加、刪除以及修改都要在用例詳述中描述，過于復雜；如果分成添加用例、修改用例和刪除用例，則劃分太細。這時包含關系可以用來理清關系。　　　　　　　　

2）、擴展關系——extend

　　擴展關系：將基用例中一段相對獨立并且可選的動作，UML用例圖關系中用擴展（Extension）用例加以封裝，再讓它從基用例中聲明的擴展點（ExtensionPoint）上進行擴展，從而使基用例行為更簡練和目標更集中。擴展用例為基用例添加新的行為。擴展用例可以訪問基用例的屬性，因此它能根據基用例中擴展點的當前狀態(tài)來判斷是否執(zhí)行自己。但是擴展用例對基用例不可見。

　　對于一個擴展用例，可以在基用例上有幾個擴展點。

　　例如，系統(tǒng)中允許用戶對查詢的結果進行導出、打印。對于查詢而言，能不能導出、打印查詢都是一樣的，導出、打印是不可見的。導入、打印和查詢相對獨立，而且為查詢添加了新行為。因此可以采用擴展關系來描述：

在以下幾種情況下，可使用擴展用例：

　　2.1）.表明用例的某一部分是可選的系統(tǒng)行為（這樣，您就可以將模型中的可選行為和必選行為分開）；

　　2.2）.表明只在特定條件（如例外條件）下才執(zhí)行的分支流；

　　2.3）.表明可能有一組行為段，其中的一個或多個段可以在基本用例中的擴展點處插入。所插入的行為段和插入的順序取決于在執(zhí)行基本用例時與主角進行的交互。

3）、泛化關系——generalization

　　泛化關系：子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。UML用例圖關系中泛化關系在實際應用中很少使用，子用例中的特殊行為都可以作為父用例中的備選流存在。

原文鏈接：http://www.cnblogs.com/lyp3314/archive/2011/11/16/2251906.html

【編輯推薦】

1. 系統(tǒng)架構師談企業(yè)應用架構之開卷有益
2. 系統(tǒng)架構師談企業(yè)應用架構之系統(tǒng)建模1
3. 系統(tǒng)架構師談企業(yè)應用架構之系統(tǒng)建模2
4. 系統(tǒng)架構師談企業(yè)應用架構之系統(tǒng)建模3
5. 系統(tǒng)架構師談企業(yè)應用架構之系統(tǒng)建模4
6. 系統(tǒng)架構師談企業(yè)應用架構之系統(tǒng)設計規(guī)范與原則1
7. 系統(tǒng)架構師談企業(yè)應用架構之系統(tǒng)設計規(guī)范與原則2
8. 系統(tǒng)架構師談企業(yè)應用架構之業(yè)務邏輯層
9. 系統(tǒng)架構師談企業(yè)應用架構之表現層
10. 系統(tǒng)架構師談企業(yè)應用架構之服務層
11. 系統(tǒng)架構師談企業(yè)應用架構之數據訪問層