1.什么是UML?

OMG組織規范聲明如下 :

"統一建模語言(UML)是一種圖形化的語言，用于軟件密集系統要素的可視化、制定規范、構建對象和編寫文檔。UML提供了一種標準的方式來描述系統的設計圖，既包括概念方面，例如業務過程和系統功能，也包括具體事務，如編程語言語句，數據庫圖示和可重用的軟件組件。

這里著重指出的是UML是一種說明性的“語言”，而不是一種方法或程序。UML通常用來定義軟件系統與細化、編寫、構造系統中的要素，是“寫”設計圖的語言。UML可以用不同的方式來支持軟件開發方法(例如：統一軟件開發過程)-但是它本身并不指定某種方法或過程。

2.UML定義的標注和語義

• 用戶交互或用例模型：描述系統和用戶之間的界定和交互。在某些方面對應于一個需求模型。
• 交互或通信模型：描述系統中的對象彼此之間如何進行交互以完成工作。
• 狀態或動態模型：狀態圖表描述隨著時間變化，類所呈現的狀態和條件?；顒訄D則描述系統即將執行的工作流程。
• 邏輯或類模型：描述構成系統的類和對象。
• 物理組件模型：描述構成系統的軟件(有時也包含硬件)。
• 物理部署模型：描述物理架構與物理架構中組件的部署。

UML 也定義了一些擴展機制，以擴展UML符合特別需要(例如：業務過程建模的擴展)。

3.UML中的13種基本圖

1）結構建模圖

結構圖定義了一個模型的靜態架構。它們通常被用來對那些構成模型的‘要素'建模，諸如：類，對象，接口和物理組件。另外，它們也被用來對元素間關聯和依賴關系進行建模。

• 包圖：用來將模型劃分成不同的邏輯容器或“包”，并在更高層次上描述它們之間的交互關系。
• 類或結構圖：用來定義模型的基本建立模塊 : 類型、類和構成完整模型的一般素材。
• 對象圖：顯示結構元素的實例間如何關聯，以及在運行時如何使用。
• 復合結構圖：提供了一種對元素結構進行分層的方法，并著重體現了元素內部的細節，結構和關系。
• 組件圖：被用來構造更高層次或更復雜的結構，通常由一個或多個類構成，并提供一個定義明確的接口。
• 部署圖：顯示現實環境中重要物件的物理配置。

2）行為建模圖

行為圖用來記錄在一個模型內部，隨時間的變化，模型執行的交互變化和瞬間的狀態；并跟蹤系統在真實環境下如何表現，以及觀察系統對一個操作或事件的反應，以及它的結果。

• 用例圖：用來對用戶/系統的交互關系建模。 用腳本和情形的形式來定義行為，要求和約束。
• 活動圖：廣泛使用于定義基本程序流程和在一般化過程中，記錄判斷點和動作。
• 狀態機圖：對于了解模型執行時的瞬時狀態，即模型的運行狀態是重要的。
• 通信圖：顯示協作實例中，對象間實時消息和通信的網絡結構與順序。
• 順序圖：與通信圖聯系緊密，并在垂直時間線上顯示對象間消息傳遞的順序。
• 時間圖：融合順序圖和狀態圖，以提供觀察對象隨時間變化的狀態和改變這個狀態的消息。
• 交互概覽圖：融合活動圖和順序圖，使交互部分容易與判斷點和流程結合。 

4.如何使用UML

一般地，UML作為軟件開發過程的一部分，在具體的CASE工具支持下，用來定義所開發系統的需求，交互和元素。開發過程的確切性質則取決所采用的開發方法。一個典型的開發過程大致如下：

1. 建立一個業務過程模型。業務過程模型被用來定義發生在企業或組織內部的高級業務活動和業務過程，并且是建立用例模型的基礎。一般來說業務過程模型比一個軟件系統所能實現的更多（比如：業務模型包括人力和其他過程）。
2. 映射用例模型到業務過程模型以精確定義你要提供的功能，并且是站在業務用戶角度考慮的。每增加一個用例時，將創建一個從適當的業務過程到該用例的可跟蹤鏈接（如：一個實現鏈接）。這個映射清楚地表達新系統將提供什么樣的功能來滿足業務過程中所描述的業務需求。這種映射也確保系統中每個用例都是有用的。
3. 完善用例-包括需求，約束、復雜程度、注釋及情形。這些信息清楚地描述用例做什么，如何做以及執行時的相關約束。這個過程要保證用例始終滿足業務過程的需求，包括每個用例的系統測試定義，該定義為該用例定義了接收標準。也包括了一些用戶可接受的測試腳本：這些腳本定義了用戶將如何進行測試和測試接收的標準。
4. 有了業務過程模型的輸入與輸出和用例的詳細信息，就可以開始構建領域模型（高級業務對象）、順序圖、協作圖和用戶接口模型。這些圖描述新系統中的要素以及這些要素之間的相互作用和用戶執行用例時所需各種情形的接口。
5. 在領域模型、用戶接口模型和情形圖的基礎上，開始建立對象類模型。這是制定系統中對象的明確規范：數據、屬性、行為和操作。使用繼承機制，可將領域對象抽象為類層次結構。處理各種情形的消息一般被映射到類的操作。如果使用一個現存的框架或設計模式，則可能導入現存模型的元素到新系統中。為每一個類定義單元測試、集成測試和系統測試。測試目的：1）類的功能是否如所定義的，2）類與其它類及組件的交互是否如期望的。
6. 當開發類模型時，可能需要將它分解成包和組件。一個組件代表一個可使用的軟件塊，它是一個類或者多個類的數據和行為的結合，并嚴格定義一個對外提供服務的接口。所以，從類模型的角度看，構造組件模型就是定義類的邏輯包。對于每一個組件，需要定義集成測試，以證實組件的接口滿足規范要求，即與其它軟件元素的關系。
7. 在完成上述工作的同時，需要獲取一些額外的需求并整理成文檔。例如：非功能性需求，性能需求，安全需求，義務需求，發布計劃等。將這些需求在模型內部進行整合并隨模型的進展而更新。
8. 部署模型定義系統的物理架構。這個工作可以提前開始以便于掌握系統的物理結構特性-使用什么樣的硬件、操作系統、網絡規模、接口與支持軟件，來構成新系統，和系統部署在那里，以及出現災難性故障時的系統恢復，系統可靠性、系統備份與支持等方面所使用的參數。隨著模型開發的不斷進展，物理系統模型應該不斷更新以反映所開發系統的實際情況。
9. 構造系統：將模型的分散模塊分配給一個或多個開發者。如果采用用例驅動的方法構造系統，這將意味分配一個用例給開發小組，讓他們構造用戶界面，業務對象，數據庫表以及執行該用例所必須的相關組件。在構造每個用例時，應該同時完成單元測試、集成測試和系統測試。如果采用組件驅動的方法構造系統，則需將各個組件分配給開發小組。
10. 對照模型中的元素，跟蹤查找出現在測試階段的缺陷。如：查看針對用例的系統測試缺陷，查看針對對象類的單元測試缺陷等等，跟蹤相關模型元素的修改以防止范圍漫延。
11. 隨著工作進展不斷更新和完善模型-每次修改模型或完善模型，都要評價所做的修改或改善對后續工作的影響。在模塊設計中使用反復式工作方法，評介當前構造的模塊，新到達的需求，以及開發過程發現的任何問題。
12. 將完整的，并經過測試的軟件發送到測試生產環節。如果采用分階段發送，那么這種軟件生產方式需要從測試到生產的多次往復才能最終完成整個項目。

注意：上面描述的過程只是項目開發所必須經歷的一個簡要概述，還有很多沒有提及。它不是告你應該如何工作，或者不遵循你已經采用的方法。它只給出如何用UML來支持軟件開發項目的一個例子。

5.常見UML應用軟件資源匯總

Visual Paradigm： | Visual Paradigm軟件最新下載

Enterprise Architect： | Enterprise Architect最新下載

BLU AGE Edition 2009：BLU AGE Edition 2009最新下載

本文的部分資源來自sparxsystems中文網

【年終大促 巔峰盛“慧” 】促銷火熱進行中 iPhone 6 Plus、 iPhone 6、iPad Air等你拿 <<<<點擊查看

【FastReport VCL 5新版發布會 】2014-12-9 15:00網絡直播，免費參加  ，參加者買FastReport全線產品6折!