UML圖中類之間的關系
一、依賴關系(Dependence)
依賴關系（Dependence）：假設A類的變化引起了B類的變化，則說名B類依賴於A類。
• 依賴關系(Dependency) 是一種使用關系，特定事物的改變有可能會影響到使用該事物的其他事物，在需要表示一個事物使用另一個事物時使用依賴關系。大多數情況下，依 賴關系體現在某個類的方法使用另一個類的對象作為參數。
依賴關系有如下三種情況：
1、A類是B類中的局部變量；
2、A類是B類方法當中的一個參數；
3、A類向B類發送消息，從而影響B類發生變化；
二、泛化關系（Generalization）
泛化關系（Generalization）：A是B和C的父類，B,C具有公共類（父類）A，說明A是B,C的一般化（概括，也稱泛化）
在UML當中，對泛化關系有三個要求：
1、子類與父類應該完全一致，父類所具有的屬性、操作，子類應該都有；
2、子類中除了與父類一致的信息以外，還包括額外的信息；
3、可以使用父類的實例的地方，也可以使用子類的實例；
三、關聯關系（Association）
關聯關系（Association）:類之間的聯系，如客戶和訂單，每個訂單對應特定的客戶，每個客戶對應一些特定的訂單，再如籃球隊員與球隊之間的關聯（下圖所示）。
表示方式 多重性說明
1..1 表示另一個類的一個對象只與一個該類對象有關系
0..* 表示另一個類的一個對象與零個或多個該類對象有關系
1..* 表示另一個類的一個對象與一個或多個該類對象有關系
0..1 表示另一個類的一個對象沒有或只與一個該類對象有關系
m..n 表示另一個類的一個對象與最少m、最多n個該類對象有關系 (m<=n)
四、聚合關系（Aggregation）
聚合關系（Aggregation）:表示的是整體和部分的關系，整體與部分可以分開
如：電話機包括一個話筒
電腦包括鍵盤、顯示器，一台電腦可以和多個鍵盤、多個顯示器搭配，確定鍵盤和顯示器是可以和主機分開的，主機可以選擇其他的鍵盤、顯示器組成電腦；
五、組合關系（Composition）
組合關系（Composition）:也是整體與部分的關系，但是整體與部分不可以分開
如：公司和部門，部門是部分，公司是整體，公司A的財務部不可能和公司B的財務部對換，就是說，公司A不能和自己的財務部分開； 人與人的心臟.
六、實現關系（Implementation)
實現關系（Implementation）：是用來規定接口和實線接口的類或者構建結構的關系，接口是操作的集合，而這些操作就用於規定類或者構建的一種服務。
UML的9中圖例概述
作為一種建模語言，UML的定義包括UML語義和UML表示法兩個部分。
l UML語義：描述基於UML的精確元模型定義。
l UML表示法：定義UML符號的表示法，為開發者或開發工具使用這些圖形符號和文本語法為系統建模提供了標准。這些圖形符號和文字所表達的是應用級的模型，在語義上它是UML元模型的實例。
標准建模語言UML可以由下列5類圖來定義。
- 用例圖：從用戶角度描述系統功能，並指出各功能的操作者。
- 靜態圖：包括類圖和對象圖。類圖描述系統中類的靜態結構，不僅定義系統中的類，表示類之間的聯系，如關聯、依賴、聚合等，也包括類的屬性和操作，類圖描述的是一種靜態關系，在系統的整個生命周期都是有效的。對象圖是類圖的實例，幾乎使用與類圖完全相同的標識。一個對象圖是類圖的一個實例。由於對象存在生命周期，因此對象圖只能在系統某一時間段存在。
- 行為圖：描述系統的動態模型和組成對象間的交互關系，包括狀態圖和活動圖。狀態圖描述類的對象所有可能的狀態以及事件發生時狀態的轉移條件，狀態圖是對類圖的補充，活動圖描述滿足用例要求所要進行的活動以及活動間的約束關系，有利於識別並進行活動。
- 交互圖：描述對象間的交互關系，包括時序圖和協作圖。時序圖顯示對象之間的動態合作關系，它強調對象之間消息發送的順序，同時顯示對象之間的交互；協作圖描述對象間的協作關系，協作圖跟時序圖相似，顯示對象間的動態合作關系。除顯示信息交換外，協作圖還顯示對象以及它們之間的關系。如果強調時間和順序，則使用時序圖；如果強調上下級關系，則選擇協作圖。
- 實現圖：包括組件圖和部署圖。組件圖描述代碼部件的物理結構及各部件之間的依賴關系，組件圖有助於分析和理解部件之間的相互影響程度；部署圖定義系統中軟硬件的物理體系結構。
采用UML來設計系統時，第一步是描述需求；第二步根據需求建立系統的靜態模型，以構造系統的結構；第三步是描述系統的行為。其中在第一步與第二步中所建立的模型都是靜態的，包括用例圖、類圖、對象圖、組件圖和部署圖等5種圖形，是標准建模語言UML的靜態建模機制。其中第三步中所建立的模型或者可以執行，或者表示執行時的時序狀態或交互關系。它包括狀態圖、活動圖、時序圖和協作圖等4種圖形，是標准建模語言UML的動態建模機制。
首先對UML中的各個圖的功用做一個簡單介紹：
和序列圖相似，顯示對象間的動態合作關系。可以看成是類圖和順序圖的交集，協作圖建模對象或者角色，以及它們彼此之間是如何通信的。如果強調時間和順序，則使用序列圖；如果強調上下級關系，則選擇協作圖；這兩種圖合稱為交互圖。
一：這九種模型圖各有側重，
1:用例圖側重描述用戶需求，
2:類圖側重描述系統具體實現；
二：描述的方面都不相同，
1:類圖描述的是系統的結構，
2:序列圖描述的是系統的行為；
三：抽象的層次也不同，
1：構件圖描述系統的模塊結構，抽象層次較高，
2：類圖是描述具體模塊的結構，抽象層次一般，
3：對象圖描述了具體的模塊實現，抽象層次較低。
在有的文獻書籍中，將這九種模型圖分為三大類：結構分類、動態行為和模型管理：
1：結構分類包括用例圖、類圖、對象圖、構件圖和部署圖，
2：動態行為包括狀態圖、活動圖、順序圖和協作圖，
3：模型管理則包含類圖。
畫圖說明
UML中有3種構造塊：事物、關系和圖，事物是對模型中最具有代表性的成分的抽象；關系是把事物結合在一起；圖聚集了相關的的事物。具體關系圖標如下：
說明：
行為事物是動態部分，表示行為。
分組事物是組織部分。
注釋事物是解釋部分。
聚集：特殊的關聯，描述整體與部分的組合關系。
泛化：是一種特殊與一般的關系，如子元素（特殊）與父元素（一般），箭頭指向父元素。
實現：類元之間的關系，其中一個類元指定了由另一個類元保證執行的契約。一般用在接口和實現他們的類之間或用例和實現它們的協作之間。
在UML系統開發中有三個主要的模型：
對象模型: 采用對象，屬性，操作，關聯等概念展示系統的結構和基礎，包括類圖。
動態模型: 展現系統的內部行為。 包括序列圖，活動圖，狀態圖。
下面具體說明：
1.類圖：描述一組對象、接口、協作等事物之間的關系。如下圖(摘自網絡)：
3.用例圖：描述一組用例、參與者以及它們之間的關系，其展示的是該系統在它的外面環境中所提供的外部可見服務。如下圖(摘自網絡)：
4.交互圖：包括序列圖（順序圖）和協作圖，兩者對應，順序圖是強調消息時間順序，有對象生命線和控制焦點。協作圖是強調接收和發送消息的對象的結構組織，有路徑和順序號。如下圖(摘自網絡)：
5.狀態圖：展示了一個狀態機，由狀態、轉換、事件和活動組成。強調事件行為的順序。如下圖(摘自網絡)：
UML中的幾種關系詳細解析
在UML類圖中，常見的有以下幾種關系: 泛化（Generalization）, 實現（Realization），關聯（Association)，聚合（Aggregation），組合(Composition)，依賴(Dependency)
1. 泛化（Generalization）
【泛化關系】：是一種繼承關系，表示一般與特殊的關系，它指定了子類如何特化父類的所有特征和行為。例如：老虎是動物的一種，即有老虎的特性也有動物的共性。
【箭頭指向】：帶三角箭頭的實線，箭頭指向父類
2. 實現（Realization）
【實現關系】：是一種類與接口的關系，表示類是接口所有特征和行為的實現.
【箭頭指向】：帶三角箭頭的虛線，箭頭指向接口
3. 關聯（Association)
【關聯關系】：是一種擁有的關系，它使一個類知道另一個類的屬性和方法；如：老師與學生，丈夫與妻子關聯可以是雙向的，也可以是單向的。雙向的關聯可以有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭。
【代碼體現】：成員變量
【箭頭及指向】：帶普通箭頭的實心線，指向被擁有者
上圖中，老師與學生是雙向關聯，老師有多名學生，學生也可能有多名老師。但學生與某課程間的關系為單向關聯，一名學生可能要上多門課程，課程是個抽象的東西他不擁有學生。
下圖為自身關聯：
4. 聚合（Aggregation）
【聚合關系】：是整體與部分的關系，且部分可以離開整體而單獨存在。如車和輪胎是整體和部分的關系，輪胎離開車仍然可以存在。
聚合關系是關聯關系的一種，是強的關聯關系；關聯和聚合在語法上無法區分，必須考察具體的邏輯關系。
【代碼體現】：成員變量
【箭頭及指向】：帶空心菱形的實心線，菱形指向整體
5. 組合(Composition)
【組合關系】：是整體與部分的關系，但部分不能離開整體而單獨存在。如公司和部門是整體和部分的關系，沒有公司就不存在部門。
組合關系是關聯關系的一種，是比聚合關系還要強的關系，它要求普通的聚合關系中代表整體的對象負責代表部分的對象的生命周期。
【代碼體現】：成員變量
【箭頭及指向】：帶實心菱形的實線，菱形指向整體
6. 依賴(Dependency)
【依賴關系】：是一種使用的關系，即一個類的實現需要另一個類的協助，所以要盡量不使用雙向的互相依賴.
【代碼表現】：局部變量、方法的參數或者對靜態方法的調用
【箭頭及指向】：帶箭頭的虛線，指向被使用者
各種關系的強弱順序：
泛化 = 實現 > 組合 > 聚合 > 關聯 > 依賴
下面這張UML圖，比較形象地展示了各種類圖關系：
UML幾種圖介紹
用例圖
用例圖描述了系統提供的一個功能單元。用例圖的主要目的是幫助開發團隊以一種可視化的方式理解系統的功能需求，包括基於基本流程的"角色"（actors，也就是與系統交互的其他實體）關系，以及系統內用例之間的關系。用例圖一般表示出用例的組織關系 —— 要么是整個系統的全部用例，要么是完成具有功能（例如，所有安全管理相關的用例）的一組用例。要在用例圖上顯示某個用例，可繪制一個橢圓，然后將用例的名稱放在橢圓的中心或橢圓下面的中間位置。要在用例圖上繪制一個角色（表示一個系統用戶），可繪制一個人形符號。角色和用例之間的關系使用簡單的線段來描述，如圖1所示。
圖1：示例用例圖
圖字（從上到下）：CD銷售系統；查看樂隊CD的銷售統計；樂隊經理；查看Billboard 200排行榜報告；唱片經理；查看特定CD的銷售統計；檢索最新的Billboard 200排行榜報告；排行榜報告服務
用例圖通常用於表達系統或者系統范疇的高級功能。如圖1所示，可以很容易看出該系統所提供的功能。這個系統允許樂隊經理查看樂隊CD的銷售統計報告以及Billboard 200排行榜報告。它也允許唱片經理查看特定CD的銷售統計報告和這些CD在Billboard 200排行榜的報告。這個圖還告訴我們，系統將通過一個名為"排行榜報告服務"的外部系統提供Billboard排行榜報告。
此外，在用例圖中，沒有列出的用例表明了該系統不能完成的功能。例如，它不能提供給樂隊經理收聽Billboard 200上不同專輯中的歌曲的途徑 —— 也就是說，系統沒有引用一個叫做"收聽Billboard 200上的歌曲"的用例。這種缺少不是一件小事。在用例圖中提供清楚的、簡要的用例描述，項目贊助商就很容易看出系統是否提供了必須的功能。
類圖表示不同的實體（人、事物和數據）如何彼此相關；換句話說，它顯示了系統的靜態結構。類圖可用於表示邏輯類，邏輯類通常就是業務人員所談及的事物種類 —— 搖滾樂隊、CD、廣播劇；或者貸款、住房抵押、汽車信貸以及利率。類圖還可用於表示實現類，實現類就是程序員處理的實體。實現類圖或許會與邏輯類圖顯示一些相同的類。然而，實現類圖不會使用相同的屬性來描述，因為它很可能具有對諸如Vector和HashMap這種事物的引用。
類在類圖上使用包含三個部分的矩形來描述，如圖2所示。最上面的部分顯示類的名稱，中間部分包含類的屬性，最下面的部分包含類的操作（或者說"方法"）。
圖2：類圖中的示例類對象
根據我的經驗，幾乎每個開發人員都知道這個類圖是什么，但是我發現大多數程序員都不能正確地描述類的關系。對於像圖3這樣的類圖，您應該使用帶有頂點指向父類的箭頭的線段來繪制繼承關系1，並且箭頭應該是一個完全的三角形。如果兩個類都彼此知道對方，則應該使用實線來表示關聯關系；如果只有其中一個類知道該關聯關系，則使用開箭頭表示。
圖3：一個完整的類圖，包括了圖2所示的類對象
在圖3中，我們同時看到了繼承關系和兩個關聯關系。CDSalesReport類繼承自Report類。一個CDSalesReport類與一個CD類關聯，但是CD類並不知道關於CDSalesReport類的任何信息。CD類和Band類都彼此知道對方，兩個類彼此都可以與一個或者多個對方類相關聯。
一個類圖可以整合其他許多概念，這將在本系列文章的后續文章中介紹。
序列圖顯示具體用例（或者是用例的一部分）的詳細流程。它幾乎是自描述的，並且顯示了流程中不同對象之間的調用關系，同時還可以很詳細地顯示對不同對象的不同調用。
序列圖有兩個維度：垂直維度以發生的時間順序顯示消息/調用的序列；水平維度顯示消息被發送到的對象實例。
序列圖的繪制非常簡單。橫跨圖的頂部，每個框（參見圖4）表示每個類的實例（對象）。在框中，類實例名稱和類名稱之間用空格/冒號/空格來分隔，例如，myReportGenerator : ReportGenerator。如果某個類實例向另一個類實例發送一條消息，則繪制一條具有指向接收類實例的開箭頭的連線，並把消息/方法的名稱放在連線上面。對於某些特別重要的消息，您可以繪制一條具有指向發起類實例的開箭頭的虛線，將返回值標注在虛線上。就我而言，我總喜歡繪制出包括返回值的虛線，這些額外的信息可以使得序列圖更易於閱讀。
閱讀序列圖也非常簡單。從左上角啟動序列的"驅動"類實例開始，然后順着每條消息往下閱讀。記住：雖然圖4所示的例子序列圖顯示了每條被發送消息的返回消息，但這只是可選的。
圖4：一個示例序列圖
通過閱讀圖4中的示例序列圖，您可以明白如何創建一個CD銷售報告（CD Sales Report）。其中的aServlet對象表示驅動類實例。aServlet向名為gen的ReportGenerator類實例發送一條消息。該消息被標為generateCDSalesReport，表示ReportGenerator對象實現了這個消息處理程序。進一步理解可發現，generateCDSalesReport消息標簽在括號中包括了一個cdId，表明aServlet隨該消息傳遞一個名為cdId的參數。當gen實例接收到一條generateCDSalesReport消息時，它會接着調用CDSalesReport類，並返回一個aCDReport的實例。然后gen實例對返回的aCDReport實例進行調用，在每次消息調用時向它傳遞參數。在該序列的結尾，gen實例向它的調用者aServlet返回一個aCDReport。
請注意：圖4中的序列圖相對於典型的序列圖來說太詳細了。然而，我認為它才是足夠易於理解的，並且它顯示了如何表示嵌套的調用。對於初級開發人員來說，有時把一個序列分解到這種詳細程度是很有必要的，這有助於他們理解相關的內容。
狀態圖表示某個類所處的不同狀態和該類的狀態轉換信息。有人可能會爭論說每個類都有狀態，但不是每個類都應該有一個狀態圖。只對"感興趣的"狀態的類（也就是說，在系統活動期間具有三個或更多潛在狀態的類）才進行狀態圖描述。
如圖5所示，狀態圖的符號集包括5個基本元素：初始起點，它使用實心圓來繪制；狀態之間的轉換，它使用具有開箭頭的線段來繪制；狀態，它使用圓角矩形來繪制；判斷點，它使用空心圓來繪制；以及一個或者多個終止點，它們使用內部包含實心圓的圓來繪制。要繪制狀態圖，首先繪制起點和一條指向該類的初始狀態的轉換線段。狀態本身可以在圖上的任意位置繪制，然后只需使用狀態轉換線條將它們連接起來。
圖5：顯示類通過某個功能系統的各種狀態的狀態圖
圖5中的狀態圖顯示了它們可以表達的一些潛在信息。例如，從中可以看出貸款處理系統最初處於Loan Application狀態。當批准前（pre-approval）過程完成時，根據該過程的結果，或者轉到Loan Pre-approved狀態，或者轉到Loan Rejected狀態。這個判斷（它是在轉換過程期間做出的）使用一個判斷點來表示 —— 即轉換線條間的空心圓。通過該狀態圖可知，如果沒有經過Loan Closing狀態，貸款不可能從Loan Pre-Approved狀態進入Loan in Maintenance狀態。而且，所有貸款都將結束於Loan Rejected或者Loan in Maintenance狀態。
活動圖表示在處理某個活動時，兩個或者更多類對象之間的過程控制流。活動圖可用於在業務單元的級別上對更高級別的業務過程進行建模，或者對低級別的內部類操作進行建模。根據我的經驗，活動圖最適合用於對較高級別的過程建模，比如公司當前在如何運作業務，或者業務如何運作等。這是因為與序列圖相比，活動圖在表示上"不夠技術性的"，但有業務頭腦的人們往往能夠更快速地理解它們。
活動圖的符號集與狀態圖中使用的符號集類似。像狀態圖一樣，活動圖也從一個連接到初始活動的實心圓開始。活動是通過一個圓角矩形（活動的名稱包含在其內）來表示的。活動可以通過轉換線段連接到其他活動，或者連接到判斷點，這些判斷點連接到由判斷點的條件所保護的不同活動。結束過程的活動連接到一個終止點（就像在狀態圖中一樣）。作為一種選擇，活動可以分組為泳道（swimlane），泳道用於表示實際執行活動的對象，如圖6所示。
圖6：活動圖，具有兩個泳道，表示兩個對象的活動控制：樂隊經理，以及報告工具
圖字（沿箭頭方向）：樂隊經理；報告工具；選擇"查看樂隊的銷售報告"；檢索該樂隊經理所管理的樂隊；顯示報告條件選擇屏幕；選擇要查看其銷售報告的樂隊；從銷售數據庫檢索銷售數據；顯示銷售報告。
該活動圖中有兩個泳道，因為有兩個對象控制着各自的活動：樂隊經理和報告工具。整個過程首先從樂隊經理選擇查看他的樂隊銷售報告開始。然后報告工具檢索並顯示他管理的所有樂隊，並要求他從中選擇一個樂隊。在樂隊經理選擇一個樂隊之后，報告工具就檢索銷售信息並顯示銷售報告。該活動圖表明，顯示報告是整個過程中的最后一步。
組件圖提供系統的物理視圖。它的用途是顯示系統中的軟件對其他軟件組件（例如，庫函數）的依賴關系。組件圖可以在一個非常高的層次上顯示，從而僅顯示粗粒度的組件，也可以在組件包層次2上顯示。
組件圖的建模最適合通過例子來描述。圖7顯示了4個組件：Reporting Tool、Billboard Service、Servlet 2.2 API和JDBC API。從Reporting Tool組件指向Billboard Service、Servlet 2.2 API和JDBC API組件的帶箭頭的線段，表示Reporting Tool依賴於那三個組件。
圖7：組件圖顯示了系統中各種軟件組件的依賴關系
部署圖表示該軟件系統如何部署到硬件環境中。它的用途是顯示該系統不同的組件將在何處物理地運行，以及它們將如何彼此通信。因為部署圖是對物理運行情況進行建模，系統的生產人員就可以很好地利用這種圖。
部署圖中的符號包括組件圖中所使用的符號元素，另外還增加了幾個符號，包括節點的概念。一個節點可以代表一台物理機器，或代表一個虛擬機器節點（例如，一個大型機節點）。要對節點進行建模，只需繪制一個三維立方體，節點的名稱位於立方體的頂部。所使用的命名約定與序列圖中相同：[實例名稱] : [實例類型]（例如，"w3reporting.myco.com : Application Server"）。
圖8：部署圖
圖字：由於Reporting Tool組件繪制在IBM WebSphere內部，后者又繪制在節點w3.reporting.myco.com內部，因而我們知道，用戶將通過運行在本地機器上的瀏覽器來訪問Reporting Tool，瀏覽器通過公司intranet上的HTTP協議與Reporting Tool建立連接。
圖8中的部署圖表明，用戶使用運行在本地機器上的瀏覽器訪問Reporting Tool，並通過公司intranet上的HTTP協議連接到Reporting Tool組件。這個工具實際運行在名為w3reporting.myco.com的Application Server上。這個圖還表明Reporting Tool組件繪制在IBM WebSphere內部，后者又繪制在w3.reporting.myco.com節點內部。Reporting Tool使用Java語言通過IBM DB2數據庫的JDBC接口連接到它的報告數據庫上，然后該接口又使用本地DB2通信方式，與運行在名為db1.myco.com的服務器上實際的DB2數據庫通信。除了與報告數據庫通信外，Report Tool組件還通過HTTPS上的SOAP與Billboard Service進行通信。
UML之用例圖解析
用例圖主要用來描述“用戶、需求、系統功能單元”之間的關系。它展示了一個外部用戶能夠觀察到的系統功能模型圖。
【用途】：幫助開發團隊以一種可視化的方式理解系統的功能需求。
用例圖所包含的元素如下：
1. 參與者(Actor)
表示與您的應用程序或系統進行交互的用戶、組織或外部系統。用一個小人表示。
2. 用例(Use Case)
用例就是外部可見的系統功能，對系統提供的服務進行描述。用橢圓表示。
3. 子系統(Subsystem)
用來展示系統的一部分功能，這部分功能聯系緊密。
4. 關系
用例圖中涉及的關系有：關聯、泛化、包含、擴展。
如下表所示：
a. 關聯(Association)
表示參與者與用例之間的通信，任何一方都可發送或接受消息。
【箭頭指向】：指向消息接收方
b. 泛化(Inheritance)
就是通常理解的繼承關系，子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。
【箭頭指向】：指向父用例
c. 包含(Include)
包含關系用來把一個較復雜用例所表示的功能分解成較小的步驟。
【箭頭指向】：指向分解出來的功能用例z
d. 擴展(Extend)
擴展關系是指用例功能的延伸，相當於為基礎用例提供一個附加功能。
【箭頭指向】：指向基礎用例
e. 依賴(Dependency)
以上4種關系，是UML定義的標准關系。但VS2010的用例模型圖中，添加了依賴關系，用帶箭頭的虛線表示，表示源用例依賴於目標用例。
【箭頭指向】：指向被依賴項
5. 項目(Artifact)
用例圖雖然是用來幫助人們形象地理解功能需求，但卻沒多少人能夠通看懂它。很多時候跟用戶交流甚至用Excel都比用例圖強，VS2010中引入了“項目”這樣一個元素，以便讓開發人員能夠在用例圖中鏈接一個普通文檔。
用依賴關系把某個用例依賴到項目上：
然后把項目-》屬性 的Hyperlink設置到你的文檔上；
這樣當你在用例圖上雙擊項目時，就會打開相關聯的文檔。
6. 注釋(Comment)
包含(include)、擴展(extend)、泛化(Inheritance) 的區別：
條件性：泛化中的子用例和include中的被包含的用例會無條件發生，而extend中的延伸用例的發生是有條件的；
直接性：泛化中的子用例和extend中的延伸用例為參與者提供直接服務，而include中被包含的用例為參與者提供間接服務。
對extend而言，延伸用例並不包含基礎用例的內容，基礎用例也不包含延伸用例的內容。
對Inheritance而言，子用例包含基礎用例的所有內容及其和其他用例或參與者之間的關系；
一個用例圖示例：
牢騷：
感覺用例圖還不成熟，並不能很好地表達系統的需求， 沒有UML背景的用戶幾乎不知道畫的是些什么。
其次，包含關系、擴展關系的箭頭符號竟然是同樣的箭頭，僅靠上方寫個文字來加以區別，翻譯成其他語言的話，幾乎就不知道代表什么意思。擴展關系的箭頭朝向也很難理解，為何要指向基用例，而不指向擴展用例。
VS2010添加的“項目”元素，是個很好的創新，能夠在用例圖中關聯word, excel這些文檔。但為什么不把這些功能直接集成到用例里面，雙擊用例就彈出一份文檔豈不更容易理解，非要畫蛇添足地加一個元件，僅僅為了提供個鏈接功能。
用例描述表：
鑒於用列圖並不能清楚地表達功能需求，開發中大家通常用描述表來補充某些不易表達的用例，下圖的表給大家提供一個參考：
UML之序列圖解析
序列圖主要用於展示對象之間交互的順序。
序列圖將交互關系表示為一個二維圖。縱向是時間軸，時間沿豎線向下延伸。橫向軸代表了在協作中各獨立對象的類元角色。類元角色用生命線表示。當對象存在時，角色用一條虛線表示，當對象的過程處於激活狀態時，生命線是一個雙道線。
消息用從一個對象的生命線到另一個對象生命線的箭頭表示。箭頭以時間順序在圖中從上到下排列。
序列圖中涉及的元素：
1. 生命線：
生命線名稱可帶下划線。當使用下划線時，意味着序列圖中的生命線代表一個類的特定實例。
2. 同步消息
發送人在它繼續之前，將等待同步消息響應。
3. 異步消息
在發送方繼續之前，無需等待響應的消息。
4. 注釋
5. 約束
約束的符號很簡單；格式是: [Boolean Test]
6. 組合片段
組合片段用來解決交互執行的條件及方式。它允許在序列圖中直接表示邏輯組件，用於通過指定條件或子進程的應用區域，為任何生命線的任何部分定義特殊條件和子進程。
常用的組合片段有：
抉擇（Alt）
抉擇用來指明在兩個或更多的消息序列之間的互斥的選擇，相當於經典的if..else..。
抉擇在任何場合下只發生一個序列。 可以在每個片段中設置一個臨界來指示該片段可以運行的條件。else 的臨界指示其他任何臨界都不為 True 時應運行的片段。如果所有臨界都為 False 並且沒有 else，則不執行任何片段。
選項（Opt）
包含一個可能發生或不發生的序列
循環（Loop）
片段重復一定次數。 可以在臨界中指示片段重復的條件。
並行（Par）
下表列出了常用的組合片段：
有關如何解釋序列的片段
默認情況下，序列圖表明可能發生的一系列消息。 在運行的系統中，可能會出現您未選擇顯示在關系圖上的其他消息。
以下片段類型可用於更改此釋義：
UML之活動圖解析
一、活動圖的組成元素 Activity Diagram Element
1、活動狀態圖（Activity）
2、動作狀態（Actions)
3、動作狀態約束（Action Constraints）
4、動作流（Control Flow）
5、開始節點（Initial Node）
6、終止節點（Final Node）
7、對象（Objects）
8、數據存儲對象（DataStore）
9、對象流（Object Flows）
10、分支與合並（Decision and Merge Nodes）
11、分叉與匯合（Fork and Join Nodes）
12、異常處理（Exception Handler）
13、活動中斷區域（Interruptible Activity Region）
14、泳道（Partition）
二、活動圖案例分析
三、總結
活動圖是UML用於對系統的動態行為建模的另一種常用工具，它描述活動的順序，展現從一個活動到另一個活動的控制流。活動圖在本質上是一種流程圖。活動圖着重表現從一個活動到另一個活動的控制流，是內部處理驅動的流程。
一、活動圖的組成元素 Activity Diagram Element
1、活動狀態圖（Activity）
活動狀態用於表達狀態機中的非原子的運行，其特點如下：
(1)、活動狀態可以分解成其他子活動或者動作狀態。
(2)、活動狀態的內部活動可以用另一個活動圖來表示。
(3)、和動作狀態不同，活動狀態可以有入口動作和出口動作，也可以有內部轉移。
(4)、動作狀態是活動狀態的一個特例，如果某個活動狀態只包括一個動作，那么它就是一個動作狀態。
UML中活動狀態和動作狀態的圖標相同，但是活動狀態可以在圖標中給出入口動作和出口動作等信息。
2、動作狀態（Actions）
動作狀態是指原子的，不可中斷的動作，並在此動作完成后通過完成轉換轉向另一個狀態。動作狀態有如下特點：
(1)、動作狀態是原子的，它是構造活動圖的最小單位。
(2)、動作狀態是不可中斷的。
(3)、動作狀態是瞬時的行為。
(4)、動作狀態可以有入轉換，入轉換既可以是動作流，也可以是對象流。動作狀態至少有一條出轉換，這條轉換以內部的完成為起點，與外部事件無關。
(5)、動作狀態與狀態圖中的狀態不同，它不能有入口動作和出口動作，更不能有內部轉移。
(6)、在一張活動圖中，動作狀態允許多處出現。
UML中的動作狀態圖用平滑的圓角矩形表示，如下：
3、動作狀態約束（Action Constraints）
動作狀態約束：用來約束動作狀態。如下圖展示了動作狀態的前置條件和后置條件
4、動作流（Control Flow）
動作之間的轉換稱之為動作流，活動圖的轉換用帶箭頭的直線表示，箭頭的方向指向轉入的方向。
5、開始節點（Initial Node）
開始節點：表示成實心黑色圓點
6、終止節點（Final Node）
分為活動終止節點（activity final nodes）和流程終止節點（flow final nodes）。
活動終止節點表示整個活動的結束
而流程終止節點表示是子流程的結束。
使用關鍵字«datastore»
對象流是動作狀態或者活動狀態與對象之間的依賴關系，表示動作使用對象或動作對對象的影響。用活動圖描述某個對象時，可以把涉及到的對象放置在活動圖中並用一個依賴將其連接到進行創建、修改和撤銷的動作狀態或者活動狀態上，對象的這種使用方法就構成了對象流。
對象流中的對象有以下特點：
(1)、一個對象可以由多個動作操作。
(2)、一個動作輸出的對象可以作為另一個動作輸入的對象。
(3)、在活動圖中，同一個對象可以多次出現，它的每一次出現表面該對象正處於對象生存期的不同時間點。
對象流用帶有箭頭的虛線表示。如果箭頭是從動作狀態出發指向對象，則表示動作對對象施加了一定的影響。施加的影響包括創建、修改和撤銷等。如果箭頭從對象指向動作狀態，則表示該動作使用對象流所指向的對象。
狀態圖中的對象用矩形表示，矩形內是該對象的名稱，名稱下的方括號表明對象此時的狀態。
10、分支與合並（Decision and Merge Nodes）
分支與合並用菱形表示
分為水平風向和垂直方向。
對象在運行時可能會存在兩個或多個並發運行的控制流，為了對並發的控制流建模，UML中引入了分叉與匯合的概念。分叉用於將動作流分為兩個或多個並發運行的分支，而匯合則用於同步這些並發分支，以達到共同完成一項事務的目的。
當受保護的活動發生異常時，觸發異常處理節點。
13、活動中斷區域（Interruptible Activity Region）
活動中斷區域圍繞一些可被中斷的動作狀態圖。比如下圖，正常情況下【Process Order】順序流轉到【Close Order】，訂單處理流程完畢；但在【Process Order】過稱中，會發送【Cancel Order】請求，這時會流轉到【Cancel Order】，從而訂單處理流程結束
14、泳道（Partition）
泳道將活動圖中的活動划分為若干組，並把每一組指定給負責這組活動的業務組織，即對象。在活動圖中，泳道區分了負責活動的對象，它明確地表示了哪些活動是由哪些對象進行的。在包含泳道的活動圖中，每個活動只能明確地屬於一個泳道。
泳道是用垂直實線繪出，垂直線分隔的區域就是泳道。在泳道的上方可以給出泳道的名字或對象的名字，該對象負責泳道內的全部活動。泳道沒有順序，不同泳道中的活動既可以順序進行也可以並發進行，動作流和對象流允許穿越分隔線。
二、活動圖案例分析
1、 泳道分為：會員泳道和系統泳道。會員選擇商品並加入購物車，系統完成訂單生成及其支付完畢。
2、 開始節點：會員添加商品到購物車，點擊【訂單確認】，開始交於系統處理訂單流程
3、 結束節點：商品發送完畢和付款成功，訂單處理流程結束
4、 活動狀態：產生訂單、Check Credit Cart核對信用卡、Check Stock 核對庫存量、Deliver Goods 發送商品、Process Credit Cart付款
5、 分叉與匯合：【產生訂單】份叉為檢查庫存量和會員支付金額是否足夠，如果不足，取消訂單，如過庫存量和支付金額足夠，發送商品和付款，最后匯合為訂單完成。
三、總結
活動圖描述的是對象活動的順序關系所遵循的規則，它着重表現的是系統的行為，而非系統的處理過程。活動圖能夠表示並發活動的情形，活動圖是面向對象的。
UML之關系圖解析
一、簡介
二、類的構成
三、類之間的關系（Relationship）
1、單向關聯
2、雙向關聯
3、自身關聯
4、多維關聯(N-ary Association)
5、泛化(Generalization)
6、依賴(Dependency)
7、聚合(Aggregation)
8、組合（Composite）
四、總結
一、簡介
類是對象的集合，展示了對象的結構以及與系統的交互行為。類主要有屬性（Attribute）和方法（Method）構成,屬性代表對象的狀態，如果屬性被保存到數據庫，此稱之為“持久化”；方法代表對象的操作行為，類具有繼承關系，可以繼承於父類，也可以與其他的Class進行交互。
類圖展示了系統的邏輯結構，類和接口的關系。
二、類的構成
類主要有屬性和方法構成。比如商品屬性有：名稱、價格、高度、寬度等；商品的方法有：計算稅率，獲得商品的評價等等。如下圖
關聯(Association)
兩個相對獨立的對象，當一個對象的實例與另外一個對象的特定實例存在固定關系時，這兩個對象之間就存在關聯關系。
1、單向關聯
A1->A2: 表示A1認識A2，A1知道A2的存在，A1可以調用A2中的方法和屬性
場景：訂單和商品，訂單中包括商品，但是商品並不了解訂單的存在。
類與類之間的單向關聯圖:
2、雙向關聯
B1-B2: 表示B1認識B2，B1知道B2的存在，B1可以調用B2中的方法和屬性；同樣B2也知道B1的存在，B2也可以調用B1的方法和屬性。
場景：訂單和客戶，訂單屬於客戶，客戶擁有一些特定的訂單
類與類之間的雙向關聯圖
3、自身關聯
同一個類對象之間的關聯
類與類之間自身關聯圖
4、多維關聯(N-ary Association)
多個對象之間存在關聯
場景：公司雇用員工，同時公司需要支付工資給員工
類與類之間的多維關聯圖：
5、泛化(Generalization)
類與類的繼承關系，類與接口的實現關系。
場景：父與子、動物與人、植物與樹、系統使用者與B2C會員和B2E會員的關系
類與類之間的泛化圖：
系統的使用者包括：B2C會員、B2B會員和B2E會員。
接口的實現，動物都有吃的行為，而人是動物的一個具體實例,實現具體Eat的動作
6、依賴(Dependency)
類A要完成某個功能必須引用類B，則A與B存在依賴關系，依賴關系是弱的關聯關系。C#不建議雙相依賴，也就是相互引用
場景：本來人與電腦沒有關系的，但由於偶然的機會，人需要用電腦寫程序，這時候人就依賴於電腦。
類與類的依賴關系圖
在程序中一般為 using 引用。
7、聚合(Aggregation)
當對象A被加入到對象B中，成為對象B的組成部分時，對象B和對象A之間為聚合關系。聚合是關聯關系的一種，是較強的關聯關系，強調的是整體與部分之間的關系。
場景：商品和他的規格、樣式就是聚合關系。
類與類的聚合關系圖
8、組合（Composite）
對象A包含對象B，對象B離開對象A沒有實際意義。是一種更強的關聯關系。人包含手，手離開人的軀體就失去了它應有的作用。
場景： Window窗體由滑動條slider、頭部Header 和工作區Panel組合而成。
類與類的組合關系圖
UML之狀態圖解析
狀態圖目錄：
一、狀態圖簡介（Brief introduction）
二、狀態圖元素（State Diagram Elements）
1、狀態（States）
2、轉移（Transitions）
3、動作（State Actions）
4、自身轉移（Self-Transitions）
5、組合狀態（Compound States）
6、進入節點（Entry Point）
7、退出節點（Exit Point）
8、歷史狀態（History States）
9、並發區域（Concurrent Regions）
三、狀態圖案例分析（State Diagram Example Analysis）
四、總結（Summary）
一、狀態圖簡介（Brief introduction）
狀態圖（Statechart Diagram）主要用於描述一個對象在其生存期間的動態行為，表現為一個對象所經歷的狀態序列，引起狀態轉移的事件（Event），以及因狀態轉移而伴隨的動作（Action）。一般可以用狀態機對一個對象的生命周期建模，狀態圖用於顯示狀態機（State Machine Diagram），重點在與描述狀態圖的控制流。
如下圖例子，狀態機描述了門對象的生存期間的狀態序列，引起轉移的事件，以及因狀態轉移而伴隨的動作（Action）.
狀態有Opened、Closed、Locked。
事件有 Open、Close、Lock和Unlock。
注意：
1、並不是所有的事件都會引起狀態的轉移，比如當門是處於【Opened】狀態，不能進行【Lock】事件。
2、轉移（Transition）有警備條件（guard condition），比如只有doorWay->isEmpty 條件滿足時，才會響應事件。
二、狀態圖元素（State Diagram Elements）
1、狀態（States）
指在對象的生命周期中的某個條件或者狀況，在此期間對象將滿足某些條件、執行某些活動活活等待某些事件。所有對象都有狀態，狀態是對象執行了一系列活動的結果，當某個事件發生后，對象的狀態將發生變化。
狀態用圓角矩形表示
初態和終態（Initial and Final States）
初態用實心圓點表示，終態用圓形內嵌圓點表示。
2、轉移（Transitions）
轉移（Transitions）是兩個狀態之間的一種關系，表示對象將在源狀態（Source State）中執行一定的動作，並在某個特定事件發生而且某個特定的警界條件滿足時進入目標狀態（Target State）
事件標記（Trigger）：是轉移的誘因，可以是一個信號，事件、條件變化（a change in some condition）和時間表達式。
警界條件（Guard Condition）：當警界條件滿足時，事件才會引發轉移（Transition）。
結果（Effect）：對象狀態轉移后的結果。
3、動作（State Actions）
動作（Actions）是一個可執行的原子操作,也就是說動作是不可中斷的，其執行時間是可忽略不計的。
在上例中，對象狀態轉移后的結果顯示在轉移線上，如果目標狀態有許多轉移，而且每個轉移有相同的結果，這時把轉移后的結果（Effect）展示在目標狀態中（Target State）更好一些，可以定義進入動作（Entry Action ）和退出動作（Exit Action），如下圖
4、自身轉移（Self-Transitions）
狀態可以有返回自身狀態的轉移，稱之為自身轉移（Self-Transitions）
2S后，Poll input事件執行，轉移到自己狀態【Waiting】
5、組合狀態（Compound States）
嵌套在另外一個狀態中的狀態稱之為子狀態（sub-state）,一個含有子狀態的狀態被稱作組合狀態（Compound States）. 如下圖，【Check PIN】是組合狀態，【Enter PIN】是子狀態。
也可用以下方式進行描述
如上圖，狀態機【Check PIN】的細節被分割到另外一個圖中了。
6、進入節點（Entry Point）
如下圖所示，由於一些原因並不會執行初始化（initialization），而是直接通過一個節點進入狀態【Ready】，則此節點稱之為進入節點（Entry Point）
7、退出節點（Exit Point）
8、歷史狀態（History States）
歷史狀態是一個偽狀態（Pseudostate）,其目的是記住從組合狀態中退出時所處的子狀態，當再次進入組合狀態，可直接進入這個子狀態，而不是再次從組合狀態的初態開始。
在上圖的狀態圖中，正常的狀態順序是:【Washing】- >【Rinsing】->【Spinning】。
如果是從狀態【Rinsing】突然停電（Power Cut）退出，,洗衣機停止工作進入狀態【Power Off】，當電力恢復時直接進入狀態【Running】。
9、並發區域（Concurrent Regions）
狀態圖可以分為區域，而區域又包括退出或者當前執行的子狀態。說明組合狀態在某一時刻可以同時達到多個子狀態。如下圖剎車系統，同時進入前剎車【Applying Front Brakes】狀態和后剎車【Applying Rear Brakes】狀態。
三、狀態圖案例分析（State Diagram Example Analysis）
按照blink518的建議（“出貨中”是屬於條件分支應該使用Decision），改成如下圖也是很好的做法：
訂單成立狀態主要有：
訂單成立
訂單取消（Guard:會員訂單-繳款期限已過期）
備貨中（Guard:已付款、訂單成立、庫存量足夠）
出貨中（Effect:扣除商品可接單量及移除購物車中的購買資料）
出貨確認（Guard:實際配達日及發票代碼、號碼均不為空值）
出貨完畢（Guard:實際配達日不為空）
出貨失敗
訂單成立（Guard:出貨完畢，已付款、鑒賞期結束日期 小於等於 [系統日期]）
分析：
1、購物車生成訂單進入狀態【訂單成立】
2、系統檢測訂單已經付款並且庫存量足夠，則進入狀態【備貨中】
3、物流發貨，進入狀態【發貨中】，狀態轉移為【發貨中】后，需要做的操作有“扣除商品可接單量及移除購物車中的購買資料”
4、發貨完畢后，狀態分為【出貨確認】和狀態【出貨失敗】，如果狀態是【出貨失敗】，則【結束】，如果狀態為【出貨確認】，則進入下一步。
5、配貨人員填寫實際配達日期，進入狀態【出貨完畢】。
6、如果”已付款、鑒賞期結束日期 小於等於 [系統日期]”,則【訂單成立】。
四、總結（Summary）
狀態圖重點在於描述對象的狀態及其狀態之間的轉移，狀態圖的基本元素主要有：狀態、轉移、動作、自身轉移、組合狀態、進入節點、退出節點、歷史狀態、並發區域等，狀態中的事件分為調用事件（Call）、變化事件（Change）、時間事件（Time）和信號事件(Singal)。最后以實例對狀態對進行了分析。
UML之時序圖解析
一、時序圖簡介（Brief introduction）
二、時序圖元素（Sequence Diagram Elements）
角色（Actor）
對象（Object）
生命線（Lifeline）
控制焦點（Focus of Control）
消息（Message）
自關聯消息（Self-Message）
Combined Fragments
三、時序圖實例分析（Sequece Diagram Example Analysis）
時序圖場景
時序圖實例
時序圖實例分析
四、總結（Summary）
一、時序圖簡介（Brief introduction）
時序圖（Sequence Diagram）是顯示對象之間交互的圖，這些對象是按時間順序排列的。順序圖中顯示的是參與交互的對象及其對象之間消息交互的順序。時序圖中包括的建模元素主要有：對象（Actor）、生命線（Lifeline）、控制焦點（Focus of control）、消息（Message）等等。
二、時序圖元素（Sequence Diagram Elements）
角色（Actor）
系統角色，可以是人、及其甚至其他的系統或者子系統。
對象（Object）
對象包括三種命名方式：
第一種方式包括對象名和類名；
第二中方式只顯示類名不顯示對象名，即表示他是一個匿名對象；
第三種方式只顯示對象名不顯示類明。
生命線（Lifeline）
生命線在順序圖中表示為從對象圖標向下延伸的一條虛線，表示對象存在的時間，如下圖
控制焦點（Focus of Control）
控制焦點是順序圖中表示時間段的符號，在這個時間段內對象將執行相應的操作。用小矩形表示，如下圖。
消息（Message）
消息一般分為同步消息（Synchronous Message），異步消息（Asynchronous Message）和返回消息（Return Message）.如下圖所示：
同步消息=調用消息（Synchronous Message）
消息的發送者把控制傳遞給消息的接收者，然后停止活動，等待消息的接收者放棄或者返回控制。用來表示同步的意義。
異步消息（Asynchronous Message）
消息發送者通過消息把信號傳遞給消息的接收者，然后繼續自己的活動，不等待接受者返回消息或者控制。異步消息的接收者和發送者是並發工作的。
返回消息（Return Message）
返回消息表示從過程調用返回
自關聯消息（Self-Message）
表示方法的自身調用以及一個對象內的一個方法調用另外一個方法。
Combined Fragments
Ø Alternative fragment（denoted “alt”） 與 if…then…else對應
Ø Option fragment (denoted “opt”) 與 Switch對應
Ø Parallel fragment (denoted “par”) 表示同時發生
Ø Loop fragment(denoted “loop”) 與 for 或者 Foreach對應
三、時序圖實例分析（Sequece Diagram Example Analysis）
時序圖場景
完成課程創建功能，主要流程有：
1、請求添加課程頁面，填寫課程表單，點擊【create】按鈕
2、添加課程信息到數據庫
3、向課程對象追加主題信息
4、為課程指派教師
5、完成課程創建功能
時序圖實例分析
1、序號1.0-1.3 完成頁面的初始化
2、序號1.4-1.5 課程管理員填充課程表單
3、序號1.6-1.7 課程管理員點擊【Create】按鈕，並響應點擊事件
4、序號1.8 Service層創建課程
5、序號1.9-1.10 添加課程到數據庫，並返回課程編號CourseId
6、序號1.11-1.12 添加課程主題到數據庫，並返回主題編號topicId
7、序號1.13 給課程指派教師
8、序號1.14 向界面拋創建課程成功與否的消息
四、總結（Summary）
時序圖（Sequence Diagram）是顯示對象之間交互的圖，這些對象是按時間順序排列的。順序圖中顯示的是參與交互的對象及其對象之間消息交互的順序。時序圖中包括的建模元素主要有：對象（Actor）、生命線（Lifeline）、控制焦點（Focus of control）、消息（Message）等等。最后，以課程創建功能演示一時序圖實例。
實例演示 -- 基於UML的面向對象分析與設計
摘要
本文以實例的方式，展示了如何使用UML進行面向對象的分析與設計。本文將假設讀者對UML、面向對象等領域的基本內容已了然於胸，所以將不會過多闡述，而將重點放在應用過程上。本文的目的是通過一個完整的實例，展現基於UML的OOA&D過程 的一個簡化模式，幫助朋友們更好的認識UML在OOA&D中起的作用。
前言
經常聽到有朋友抱怨，說學了UML不知該怎么用，或者畫了UML卻覺得沒什么作用。其實，就UML本身來說，它只是一種交流工具，它作為一種標准化交流符號，在OOA&D過程中開發人員間甚至開發人員與客戶之間傳遞信息。另外，UML也可以看做是OO思想的一種表現形式，可以說“OO是神，而UML是型”。所以，想用好UML，扎實的OO思想基礎是必不可少的。然而，在UML應用到開發過程中時，還是有一定的模式可以遵循的。（注意，是模式而不是教條，我下面給出的流程只是一個啟發式過程，而不是說一定要遵循這個流程。）下面，我們通過一個CMS系統的分析設計實例，看看如何將UML應用到實際的開發中。
1.從需求到業務用例圖
OOA&D的第一步，就是了解用戶需求，並將其轉換為業務用例圖。我們的CMS系統需求非常簡單，大致課做如下描述：這個系統主要用來發布新聞，管理員只需要一個，登錄后可以在后台發布新聞。任何人可以瀏覽新聞，瀏覽者可以注冊成為系統會員，注冊后可對新聞進行評論。管理員在后台可以對新聞、評論、注冊會員進行管理，如修改、刪除等。
通過以上需求描述，我們畫出如下的業務用例圖：
這里要注意三點：
1.業務用例是僅從系統業務角度關注的用例，而不是具體系統的用例。它描述的是“該實現什么業務”，而不是“系統該提供什么操作”。例如，在實際系統中，“登錄”肯定要作為一個用例，但是這是軟件系統中的操作，而用戶所關注的業務是不包含“登錄”的。
2.業務用例僅包含客戶“感興趣”的內容。
3.業務用例所有的用例名應該讓客戶能看懂，如果某個用例的名字客戶看不懂什么意思，它也許就不適合作為業務用例。
2.從業務用例圖到活動圖
完成了業務用例圖后，我們要為每一個業務用例繪制一幅活動圖。活動圖描述了這個業務用例中，用戶可能會進行的操作序列。活動圖有個很重要的使命：從業務用例分析出系統用例。例如，下面是“新聞管理”的活動圖：
可以看到，一個“新聞管理”這個業務用例，分解出N多系統操作。這里要特別注意這些操作，其中很多“活動”都很可能是一個系統用例（當然，不是每個都是）。例如，由這個活動圖可以看出，系統中至少要包含以下備選系統用例：登錄、注銷登錄、查看新聞列表、修改新聞、刪除新聞。
這樣，將每個業務用例都繪制出相應的活動圖，再將其中的“活動”整合，就得出所有備選系統用例。
3.從活動圖到系統用例圖
找出所有的備選系統用例后，我們要對他們進行合並和篩選。合並就是將相同的用例合並成一個，篩選就是將不符合系統用例條件的備選用例去掉。
一個系統用例應該是實際使用系統的用戶所進行的一個操作，例如，“查看新聞列表”就不能算一個系統用例，因為他只是某系統用例的一個序列項。
最終我們得出的系統用例圖如下：
4.從系統用例圖到用例規約
得出系統用例圖后，我們應該對每一個系統用例給出用例規約。關於用例規約，沒有一個通用的格式，大家可以按照習慣的格式進行編寫。對用例規約唯一的要求就是“清晰易懂”。
下面給出“登錄”這個系統用例的一個規約：
5.繪制業務領域類圖
完成了上面幾步，下面應該是繪制業務領域類圖了。所謂業務領域類圖要描述一下三點：
1.系統中有哪些實體。
2.這些實體能做什么操作。
3.實體間的關系。
這里要特別強調：這里的實體不是Actor，而是Actor使用系統時使用的所調用的實體，是處在系統邊界之內的實體。例如，管理員就沒有作為一個實體出現在這里，因為管理員處在系統邊界之外，它所有的工作都可以通過調用這三個類的方法完成。並且，這里的“注冊會員”實體也不是剛才用例圖中注冊會員這個Actor，而是作為一個系統內的業務實體，供Actor們使用的。例如，其中的注冊功能是給注冊會員這個Actor使用，而移除則是給管理員這個Actor使用的。
理解以上這段話非常重要，我經常看到由於混淆了實體和Actor的關系而導致畫出的領域類圖不准確或職責分配不准確。
大家可能還注意到，我們這里沒有給出每個實體的屬性。其實，在領域分析階段，實體的屬性並不重要，重要的是找出實體的操作。
6.繪制實現類圖
以上這幾步，就是分析的過程。而下面的步驟就是設計了。
設計沒有分析那么好描述，因為分析是“客戶面”，它只關心系統本身的功能和業務，而不關心任何和計算機有關的東西。但是，設計和平台、語言、開發模型等內容關系緊密，因而很難找出一個一致的過程。但是，一般在設計過程中實現類圖是要繪制的。
實現類圖和領域類圖不一樣，它描述的是真正系統的靜態結構，是和最后的代碼完全一致的。因此，它和平台關系密切，必須准確給出系統中的實體類、控制類、界面類、接口等元素以及其中的關系。因此，實現類圖是很復雜的，而且是平台技術有關的。所以，我在這里不可能給出一個准確的實現類圖，不過為了描述，我還是給出一個簡化了的實現類圖，當然，它是不准確的，而只是從形式上給出實現類圖的樣子。
我們假設這個系統建構於.NET 3.5平台上，並且使用ASP.NET MVC作為表示層，整體使用三層架構。那么，用戶模塊體系的實現類圖大體是這樣子（不准確）：
7.繪制序列圖
有了靜態結構，我們還要給出動態結構，這樣，才能看清系統間的類是如何交互的，從而有效幫助程序員進行編碼工作。
上圖給出的是用戶登錄的序列圖。首先注冊會員作為Actor，調用UserController的Login方法啟動序列，然后序列按圖示步驟執行。其中UserServices作為業務組件，首先調用數據訪問組件的GetByName確定用戶是否存在，如果存在，再調用GetByNameAndPassword確定輸入密碼是否是此用戶的密碼。從而完成業務功能。
要注意，序列圖在實際中是很多的，幾乎每個類方法都配有相應的序列圖。
8.后面的步驟
在完成了上面的過程后，就可以進行編碼、調試、測試等工作了。但這些已經超出了本文討論的范圍。
總結
本文簡要給出了使用UML進行OOA&D的過程。當然，由於示例較小，而且本人水平有限，所以給出的相關內容可能不是很准確。而且軟件分析設計本來就不是一個固定模式的過程，隨着系統的不同整個過程會有變化。本文只是想起到一個拋磚引玉的作用，讓朋友們大致了解UML的使用流程。至於實際的分析設計，還需要深入的學習和實踐的積累。
UML類圖關系（泛化 、繼承、實現、依賴、關聯、聚合、組合）
繼承、實現、依賴、關聯、聚合、組合的聯系與區別
分別介紹這幾種關系：
繼承
指的是一個類（稱為子類、子接口）繼承另外的一個類（稱為父類、父接口）的功能，並可以增加它自己的新功能的能力，繼承是類與類或者接口與接口之間最常見的關系；在Java中此類關系通過關鍵字extends明確標識，在設計時一般沒有爭議性；
實現
指的是一個class類實現interface接口（可以是多個）的功能；實現是類與接口之間最常見的關系；在Java中此類關系通過關鍵字implements明確標識，在設計時一般沒有爭議性；
依賴
可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關系是具有偶然性的、、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關系就是依賴；表現在代碼層面，為類B作為參數被類A在某個method方法中使用；
關聯
他體現的是兩個類、或者類與接口之間語義級別的一種強依賴關系，比如我和我的朋友；這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，而且雙方的關系一般是平等的、關聯可以是單向、雙向的；表現在代碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；
聚合
聚合是關聯關系的一種特例，他體現的是整體與部分、擁有的關系，即has-a的關系，此時整體與部分之間是可分離的，他們可以具有各自的生命周期，部分可以屬於多個整體對象，也可以為多個整體對象共享；比如計算機與CPU、公司與員工的關系等；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；
組合
組合也是關聯關系的一種特例，他體現的是一種contains-a的關系，這種關系比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關系，但此時整體與部分是不可分的，整體的生命周期結束也就意味着部分的生命周期結束；比如你和你的大腦；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；
對於繼承、實現這兩種關系沒多少疑問，他們體現的是一種類與類、或者類與接口間的縱向關系；其他的四者關系則體現的是類與類、或者類與接口間的引用、橫向關系，是比較難區分的，有很多事物間的關系要想准備定位是很難的，前面也提到，這幾種關系都是語義級別的，所以從代碼層面並不能完全區分各種關系；
但總的來說，后幾種關系所表現的強弱程度依次為：組合>聚合>關聯>依賴；
聚合跟組合其實都屬於關聯 只不過它們是兩種特殊的關聯 因為本是同根生 所以它們之間難免會有相似之處 下面讓我們一起來看一下它們之間有何不同
聚合與組合的概念相信不用我在此贅述大家就已經了解了 下面直接上例子
程老師的《大話》里舉大那個大雁的例子很貼切 在此我就借用一下 大雁喜歡熱鬧害怕孤獨 所以它們一直過着群居的生活 這樣就有了雁群 每一只大雁都有自己的雁群 每個雁群都有好多大雁 大雁與雁群的這種關系就可以稱之為聚合 另外每只大雁都有兩只翅膀 大雁與雁翅的關系就叫做組合 有此可見 聚合的關系明顯沒有組合緊密 大雁不會因為它們的群主將雁群解散而無法生存 而雁翅就無法脫離大雁而單獨生存——組合關系的類具有相同的生命周期
聚合關系圖：
組合關系圖：
從從代碼上看這兩種關系的區別在於：
構造函數不同
聚合關系的類里含有另一個類作為參數
雁群類（GooseGroup）的構造函數中要用到大雁（Goose）作為參數把值傳進來 大雁類（Goose）可以脫離雁群類而獨立存在
組合關系的類里含有另一個類的實例化
大雁類（Goose）在實例化之前 一定要先實例化翅膀類（Wings） 兩個類緊密耦合在一起 它們有相同的生命周期 翅膀類（Wings）不可以脫離大雁類（Goose）而獨立存在
信息的封裝性不同
在聚合關系中，客戶端可以同時了解雁群類和大雁類，因為他們都是獨立的
而在組合關系中，客戶端只認識大雁類，根本就不知道翅膀類的存在，因為翅膀類被嚴密的封裝在大雁類中。