UML簡介

UML，統一建模語言（Unified Modeling Language），是第三代用來為面向物件開發系統的產品進行說明、視覺化和編制文件的方法

什麼是UML

UML是一種標準的圖形化建模語言，它是面向物件分析與設計的一種標準表示。它：

• • 不是一種視覺化的程式語言，而是一種視覺化的建模語言；
  • 不是工具或知識庫的規格說明，而是一種建模語言規格的說明，它是一種表示標準；
  • 不是過程，也不是方法，但允許任何過程和方法是用它；

UML的目標

• • 易於使用、表達能力強，進行視覺化建模；
  • 與具體實現無關，可應用於任何語言平臺和工具平臺；
  • 與具體過程無關，可應用於任何軟體開發的過程；
  • 簡單並且可擴充套件，具有擴充套件和專有化機制，便於擴充套件，無對核心概念進行修改；
  • 為面向物件與開發中湧現的高階概念（協作、框架、模式和元件）提供支援，強調在軟體開發中，對架構、框架、模式和元件的重用；
  • 與最好的軟體工程實踐經驗整合；
  • 可升級，具有廣闊的適用性和可用性；
  • 有利於面向物件工具市場成長。

UML的架構

UML由圖和元模型組成。圖是UML的語法，元模型則給出圖的意思，是UML的語義。UML的語義定義在一個四層（四個抽象級）建模概念框架中：

• • 元元模型（meta-metamodel）層，組成UML最基本的元素“事物（Thing）”，代表要定義的所有事物；
  • 元模型（metamodel）層，組成UML的基本元素，每個概念都是元元模型中的“事物”概念的例項。
  • 模型（model）層，組成UML的模型，每個概念都是元模型中概念的例項。這一層模型通常稱為類模型（class model）或型別模型（type model）。
  • 使用者模型（user model）層，所有模型都是UML模型的例子，每個概念都是模型層和元模型的例項。這一層模型通常稱為物件模型（object model）或例項模型（instance model）。

UML的檢視（view）和圖（diagram）

UML檢視從不同視角為系統架構建模，有：

• • 用例檢視（use case view），起吊從使用者角度看到的貨需要的系統功能，也稱為使用者模型檢視（user model view）或想定檢視（scenario view）
  • 邏輯檢視（logical view），展現系統的靜態貨結構組成及特徵，也稱為結構模型檢視（structural mdel view）或靜態模型檢視（static view）
  • 併發檢視（concurent view），體現系統的動態或行為特徵，也稱為模型檢視（behavioral model view）、過程檢視（process view）、協作檢視（collaboratiive view ）、動態檢視（dynamic view）
  • 元件檢視（conponent view），體現系統實現的結構和行為特徵，也稱為實現模型檢視（implementation model view）、開發檢視（development view）
  • 展開檢視（deployment view），體現系統實現環境的機構和行為特徵，也成為環境模型檢視（Environment model view）、物理檢視（physical view）

每一種UML的檢視都是由一個或多個圖（diagram）組成的，一個圖是系統架構在某個側面的表示，它與其他圖是一致的，所以圖一起組成了系統的完整性。

UML提供了9種不同的圖，可以分成兩大類：靜態圖（用例圖、類圖、物件圖、元件圖、配置圖）和動態圖（序列圖、協作圖、狀態圖、活動圖）。根據不同架構檢視，也分成：

在使用者模型檢視：

• 用例圖（User case diagram），描述系統功能。

在結構模型檢視：

• 類圖（Class diagram），描述系統的靜態結構。
• 物件圖（Object diagram），描述系統在某個時刻的靜態結構。

在行為模型檢視：

• 序列圖（Sequence diagram），按時間順序描述系統元素間的互動。
• 協作圖（Collaboration diagram），按照時間和空間的順序描述系統元素間的互動和他們之間的關係。
• 狀態圖（State diagram），描述系統元素的狀態和響應。
• 活動圖（Activity diagram），描述系統元素的活動。

在實現模型檢視：

• 元件圖（Component diagram），描述系統元素的組織。

在環境模型檢視：

• 展開圖（Deployment diagram），描述環境元素的配置，並實現系統元素的對映到配置上。

UML與面向物件軟體分析與設計

UML的最終用途：表示方法的的標準化，有效地促進了不同背景人們的交流，有效地促進軟體設計、開發和測試人員的相互理解，為不同領域的人們提供統一的交流標準。

在眾多成功的軟體設計與實現的經驗中，最突出的兩條，一是注重系統架構的開發，一是注重過程的迭代和遞增型。儘管UML本身沒有對過程有任何定義，但是UML對任何使用它的方法（或過程）提出的要求是：支援用力驅動（use-case driven），以架構為中心（architecture-centric）以及遞增（incremental）和迭代（iterative）地開發。遞增和遞增的開發過程反映了專案開發的節奏。

UML在軟體開發的不同階段中的應用

• 需求分析。UML的用力檢視可以表示客戶的需求。通過用例建模，可以對外部的角色以及它們所需要的系統功能建模。角色和用例是用它們之間的關係、通訊建模。每個用例都指定了客戶的需求：他/她需要系統幹什麼。不僅要對軟體系統，對商業過程也要進行需求分析。
• 分析。分析階段主要考慮所要解決的問題，可用UML的邏輯檢視和動態檢視來描述：類圖描述系統的靜態結構，協作圖、狀態圖、序列圖、活動圖描述系統的動態特徵。在分析階段，只為問題領域的類建模，不定義軟體系統的解決方案細節（使用者介面的類，資料庫）。
• 設計。在設計階段，把分析階段的結果擴充套件成技術解決方案。加入新的類來提供技術基礎結構（使用者介面，資料庫操作等）。分析階段的領域問題類被嵌入在這個技術基礎結構中。設計階段的結果 是構造階段的詳細的規格說明。
• 構造。在構造（程式設計階段），把設計階段的類裝換成某種面向物件程式設計語言的程式碼。在UML表示的分析和設計模式進行轉換時，最好不要直接把模型轉換為程式碼。因為在早期階段，模型是理解系統並對系統進行結構化的手段。
• 測試。對系統的測試通常分為單元測、整合測試、系統測試和接受測試幾個不同級別。單元測試時對幾個類貨一組類的測試，通常由程式設計師進行；整合測試整合元件和類，確認它們之間是否欠當地協作；系統測試把系統當作一個“黑箱”，驗證系統是否具有使用者所要求的所有功能。接受測試由客戶完成，驗證系統是否滿足所有需求。不同測試小組使用不同UML作為他們的工作基礎：單元測試使用類圖和類說明規格，整合測試典型地使用元件圖和協作圖，而系統測試實現用例圖來確認系統的行為符合這些圖中的定義