轉自：http://www.360doc.com/content/10/1206/23/3123_75672033.shtml
前些時間參加了潘加宇老師的技術講座，UML建模技術受益匪淺。我也把平時的一些積累和上次的收獲總結在這篇文章中，主要講解用例圖相關的知識。
用例圖是軟件需求分析到最終實現的第一步，它描述用戶如何使用系統及使用系統什么樣的功能。用例圖從業務角度上體現誰來使用系統、用戶希望系統提供什么樣的服務，以及用戶需要為系統提供的服務，也便於軟件開發人員最終實現這些功能。用例圖在開發中被廣泛的應用，但是它最常用來描述系統提供了什么樣的功能給什么樣的用戶使用。
在官方文檔中用例圖包含六個元素，分別是：執行者(Actor)、用例(Use Case)、關聯關系(Association)、包含關系(Include)、擴展關系(Extend)以及泛化關系(Generalization)。但是有些UML的繪圖工具多提供了一種直接關聯關系(DirectedAssociation)。
用例圖可一個包含注釋和約束，還可一個包含包，用於將模型中的元素組合成更大的模塊。有時，可以將用例的實例引入到圖中。用例圖模型如下所示，執行者用人形圖標來標識，用例用橢圓來表示，連線表示它們之間的關系。
一、執行者（Actor）
1、執行者概念
是指用戶在系統中扮演的角色。如圖1-1是一個用戶管理的用例圖，圖中的用戶、管理員就是用例的執行者。
圖1-1
2、從業務中找出執行者
獲取系統用例首先要找出系統的執行者。我們可以通過用戶回答一些問題的答案來識別執行者。可以參考以下問題：
- 誰使用系統的主要功能（主要使用者）？
- 誰需要系統支持他們日常工作？
- 誰來維護、管理系統使其正常工作（輔助使用者）？
- 系統需要控制哪些硬件？
- 系統需要其他哪些系統交互？這里包含其他計算機系統或者應用程序。
- 對系統產生結果感興趣的是哪些人和哪些事物？
3、執行者之間關系
因為執行者是類，所以多個執行者之間可以具有與類相同的關系。在用例圖中，使用了泛化關系來描述多個執行者之間的公共行為。如果系統中存在幾個執行者，它們既扮演自身的角色，同時也扮演更具一般化的角色，那么就用泛化關系來描述它們。這種情況往往發生在一般角色的行為在執行者超類中描述的場合。特殊化的執行者繼承了該超類的行為，然后在某些方面擴展了此行為。執行者之間的泛化關系用一個三角箭頭來表示，指向扮演一般角色的超類。這與UML中類之間的返還關系符號相同。圖1-2
圖1-2
二、用例（Use Case）
1、用例概念
用例就是外部可見的系統功能，對系統提供的服務進行描述。
2、從業務中找出用例
找出系統的用例，我們從執行者入手，對每個執行者提出一些問題，然后從執行者對這些問題的答案中獲取用例。可以參考以下問題：
- 執行者要求系統提供哪些功能（執行者需要做什么）？
- 執行者需要讀、產生、修改、刪除或者存儲系統中的信息有哪些類型？
- 執行者必須提醒系統事件有哪些？把這些事件表示成系統用例。
3、用例之間關系
二、用例之間關系
1、關聯關系（Association）
關聯關系是連接執行者和用例，表示該執行者代表的外部系統實體與該用例描述的系統需求有關。
圖1-3
2、包含關系（Include）
包含關系是來自於用例的抽象，即從數個不同的Use Case中，分離出公共的部分，而成為可以復用的用例。
圖1-4
3、擴展關系（Extend）
擴展關系表示某一個用例的對話流程中，可能會根據條件臨時插入另外一個用例，而前者稱為基礎用例后者稱為擴展用例。
圖1-5
4、泛化關系（Generalization）
一個用例可以被特別列舉為一個或多個用例，這被稱為用例泛化，如果系統中一個或多個用例是某個一般用例的特殊化時，就需要使用用例的泛化關系。
UML中幾種類間關系：繼承、實現、依賴、關聯、聚合、組合的聯系與區別
2009-03-01
本文已同步發於：http://blog.csdn.net/sfdev/archive/2009/02/18/3906243.aspx
這是一堂關於UML基礎知識的補習課；現在我們做項目時間都太緊了，基本上都沒有做過真正的class級別的詳細設計，更別提使用UML來實現規范 建模了；本篇主要就以前自己一直感覺很迷糊的幾種class之間的關系進行整理，讓我們在真正用UML進行比如類圖設計時能夠更加清晰明了；以下就分別介 紹這幾種關系：
繼承
指的是一個類（稱為子類、子接口）繼承另外的一個類（稱為父類、父接口）的功能，並可以增加它自己的新功能的能力，繼承是類與類或者接口與接口之間最常見的關系；在Java中此類關系通過關鍵字extends明確標識，在設計時一般沒有爭議性；
實現
指的是一個class類實現interface接口（可以是多個）的功能；實現是類與接口之間最常見的關系；在Java中此類關系通過關鍵字implements明確標識，在設計時一般沒有爭議性；
依賴
可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關系是具有偶然性的、、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關系就是依賴；表現在代碼層面，為類B作為參數被類A在某個method方法中使用；
關聯
他體現的是兩個類、或者類與接口之間語義級別的一種強依賴關系，比如我和我的朋友；這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性 的，一般是長期性的，而且雙方的關系一般是平等的、關聯可以是單向、雙向的；表現在代碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯 類A引用了一個類型為被關聯類B的全局變量；
聚合
聚合是關聯關系的一種特例，他體現的是整體與部分、擁有的關系，即has-a的關系，此時整體與部分之間是可分離的，他們可以具有各自的生命周期， 部分可以屬於多個整體對象，也可以為多個整體對象共享；比如計算機與CPU、公司與員工的關系等；表現在代碼層面，和關聯關系是一致的，只能從語義級別來 區分；
組合
組合也是關聯關系的一種特例，他體現的是一種contains-a的關系，這種關系比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關系，但此 時整體與部分是不可分的，整體的生命周期結束也就意味着部分的生命周期結束；比如你和你的大腦；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區 分；
對於繼承、實現這兩種關系沒多少疑問，他們體現的是一種類與類、或者類與接口間的縱向關系；其他的四者關系則體現的是類與類、或者類與接口間的引 用、橫向關系，是比較難區分的，有很多事物間的關系要想准備定位是很難的，前面也提到，這幾種關系都是語義級別的，所以從代碼層面並不能完全區分各種關 系；但總的來說，后幾種關系所表現的強弱程度依次為：組合>聚合>關聯>依賴；
目的
對前段時間學習 UML過程的一個記錄
起因
為了理清mall的一些業務邏輯，以便今后的順利開發，需一種工具來幫助自己更好更快的熟悉這些業務，這種工具很多，如各類思維導圖軟件，UML, 我就選了UML。因為之前也沒怎么畫，知識也很缺乏，就開始邊學邊畫啦
經過
在邊學邊畫前，要找一款好點的畫UML軟件,經同事TJJ的推薦，用上了一款韓國人開發的startUML,用來
畫了幾個圖后發現不是特別好用，sigh~ 通過偉大的google,用上了 ArgoUML界面雖難看了點，但確實好用，在這里也推薦下，哈哈。
在學UML過程中，接觸到了幾個概念，記錄下：
關聯: 模型元素之間的一種語義聯系，是類之間的一種很弱的聯系, 如：當僅當一個類為另一個 類方法中的參數時為關聯關系
組合：表示類之間整體和部分的關系，但是組合關系中部分和整體具有統一的生存期。一旦整體
對象不存在，部分對象也將不存在。部分對象與整體對象之間具有共生死的關系。
聚合: 也指的是整體與部分的關系。需求描述中“包含”、“組成”等詞常意味着聚合關系。
親密關系從大到小為 組合>聚合>關聯
結果
通過畫uml圖來熟悉開發中的業務需求，會讓自己更加深刻的理解需求