第六章 圖

前言

建模實際上是對真實世界進行簡化，從而可以更好地理解你要開發的系統。使用UML中基本的建筑塊如：類、接口、關系、協作、組件、依賴、繼承等，可以建立你想要的模型。還可以利用第五章介紹的機制擴充UML來表達問題領域獨特的東西。

圖是你組織這些建筑塊的方式。圖代表著一系列的元素，這些元素常常被畫成用點（事物）和?。P系）相連的圖。利用圖來從不同的視角來觀察系統。由于沒有一個復雜的系統可以從一個透視圖弄明白，UML定義了一些圖使得我們可以獨立地從幾個不同的視角來了解系統。

好的圖使得你要開發的系統是易于理解和可以接近的。選擇好的圖對系統建模讓你找到系統中真正要問的問題，幫助你闡述清楚你的系統。

術語和概念

系統是組織起來完成特定目標的一組子系統。系統可以用一組模型，可能來自不同的視角，進行描述。子系統是一組元素，其中一些通過包含的另外的元素組成特定的行為。模型是對系統進行語義上的抽象，它是整個真實系統的簡化，為了更好地理解系統而創建的。圖是一系列的元素，這些元素常常被畫成用點（事物）和?。P系）相連的圖。利用圖來從不同的視角來觀察系統。

系統代表著你要開發的事物，通過不同的模型從不同的透視圖來觀察系統，這些透視圖以圖的形式表達。

在對真實世界進行建模的時候，你可以發現不管你的問題處于什么樣的領域，你都會創建相同的圖，因為他們代表著通用的模型的通用的視。通常，你利用下面的圖來觀察系統的靜態部分：

1.         類圖(Class Diagram)

2.         對象圖(Object Diagram)

3.         組件圖(Compoment Diagram)

4.         分布圖(Deployment Diagram)

使用下面的五種額外的圖來觀察系統動態的方面：

1.         Usecase圖

2.         序列圖(Sequence Diagram)

3.         協作圖(Collaboration Diagram)

4.         狀態圖(Statechart Diagram)

5.         活動圖(Activity Diagram)

UML定義了這五種圖。

結構化圖（Structural Diagrams）

1.         類圖(Class Diagram)          類、接口和協作

2.         對象圖(Object Diagram)       對象

3.         組件圖(Compoment Diagram)   組件

4.         分布圖(Deployment Diagram)   節點（Notes）

類圖 類圖顯示了一組類、接口和協作以及它們之間的關系。類圖在面向對象的建模設計中是很常用的。利用類圖闡明系統的靜態的設計。包含活動類（active classes）的類圖通常用來說明看到的系統靜態過程。

對象圖 對象圖顯示了一組對象和他們之間的關系。使用對象圖來說明數據結構，類圖中的類或組件等的實例的靜態快照。對象圖和類圖一樣反映系統的靜態過程，但它是從實際的或原型化的情景來表達的。

組件圖 組件圖顯示了一些組件和它們之間的關系。使用組件圖來說明系統的靜態實現。組件圖和類圖是有聯系的，通常一個組件可以映射成一個或多個類，接口或協作。

分布圖 分布圖顯示了一些節點和它們之間的關系。使用分布圖來說明系統的靜態結構。分布圖和組件圖是有聯系的，通常一個節點封裝了一個或多個組件。

動作圖（Behavioral Diagrams）

UML中定義的動作圖包括：

1.         Usecase圖

2.         序列圖(Sequence Diagram)

3.         協作圖(Collaboration Diagram)

4.         狀態圖(Statechart Diagram)

5.         活動圖(Activity Diagram)

Usecase圖 Usecase圖顯示了一些Usecase和角色（特殊的類）和他們的關系。使用usecase圖來描述系統靜態的功能場景。Usecase圖對于組織和模型化系統的動作是很重要的。

序列圖 序列圖是一種交互圖（interaction diagram），強調的是時間和消息的次序。一個序列圖顯示了一系列的對象和在這些對象之間發送和接收的消息。對象通常是命名或匿名的類的實例，也可以代表其他事物的實例，例如協作、組件和節點。使用序列圖來說明系統的動態情況。

協作圖 協作圖是一種交互圖（interaction diagram），強調的是發送和接收消息的對象之間的組織結構。一個協作圖顯示了一系列的對象和在這些對象之間的聯系以及對象間發送和接收的消息。對象通常是命名或匿名的類的實例，也可以代表其他事物的實例，例如協作、組件和節點。使用協作圖來說明系統的動態情況。

注意：序列圖和協作圖是同構的，它們相互之間可以轉化而不損失信息。

狀態圖 狀態圖顯示了一個狀態機，由狀態、轉換、事件和活動組成。使用狀態圖說明系統動態情況。狀態圖對于建模接口的動作、類的動作或協作的動作是重要的。狀態圖強調的是事件驅動的對象的動作，這在對反應式系統的建模是相當重要的。

活動圖：活動圖顯示了系統中從一個活動到另一個活動的流程?；顒訄D顯示了一些活動，他們很象傳統的流程圖有序列或分支?；顒訄D對于給系統的功能建模是很重要的?；顒訄D強調的是對象之間的流程控制。

通用建模技巧

1.         對系統的不同視進行建模

l         決定采用哪個視才能最好地表達系統的結構，以及暴露出項目的技術風險。前面討論的五種圖是很好的開始點。

l         對每一種視圖決定要畫那些圖，通常一個視圖會對應多個圖

l         作為你的過程計劃的一部分，決定那些圖是要作為項目文檔保存。

l         不要認為一次能夠將圖畫好，最好準備一個裝廢紙的房間。

例如，如果你為一個簡單的應用建模。你可能只需要其中一部分視圖。

如果你是一個反應式的系統或系統的重點在處理流程上，你可能想包括狀態圖和活動圖來建立系統的動作模型。

同樣的，如果你是一個Client/Server系統，你可能想用組件圖和分布圖來為你的系統的物理細節進行建模。

最后，如果你是要對一個復雜的、分布式的系統建模，你需要使用所有的UML的圖來表達系統的結構和項目的技術風險，如下所示：

1.         不同抽象層次建模

你不僅要從不同的視角觀察系統，還要系統進行不同層次的抽象，因為參加項目開發的人可能對同一個系統的視圖需要不同的抽象層次。對于程序員來說，他希望看到的是類的屬性、方法，而對于一個系統分析員使用usecase場景來說只要看到存在這么個類就可以了，這里程序員要求的抽象層次較底層?？梢酝ㄟ^隱藏或顯示不同層次的細節來實現不同抽象層次的模型，或者創建不同層次抽象的圖。

l         考慮你的讀者的需要，從一個給定的模型開始

l         如果你的讀者使用模型是構造一個實現，他需要的是較低層的抽象，也就是說他需要更多的細節。如果他利用概念模型只是為了和最終用戶交流，他需要的是高層次的抽象，不需要細節的東西。

2.         復雜視圖建模

l         首先確信沒有更好的方法可以利用高層次的抽象表達要表達的信息，即便是刪除一部分圖或保留細節到另外一部分。

l         如果你隱藏了你所能隱藏的細節而你的圖還是很復雜，考慮將一部分元素分組放到包里或放到較高層次的協作中，然后在你的圖中只畫這些包和協作。

l         如果你的圖還是很復雜，使用注釋或顏色來鉤出你的重點好引起讀者的注意

l         如果你的圖依然很復雜，哈哈，打印出來，貼到墻上，將讀者叫來親自講解給他聽吧。希望他能明白……其實你可以自己慢慢研究，最后發現簡化還是可以的。

聯系本文作者：21newtimes@163.net
如果本文某些術語翻譯得不正確，敬請大家指教。關于ＵＭＬ的東西我也是最近才接觸，本文如有錯誤還請原諒。