UML對很多人來說應該不是一個陌生的概念，這一兩年來，UML被大家越來越多的討論著。本來UML跟我這個主題似乎並不能扯上多大的關系（它是語言無關的，甚至可以說其本身就是一種語言——用於交流的）。我在此談到它有兩個目的：
1．UML是針對面向對象軟件開發的，而C++正是這樣的一種語言
2．UML在設計中被越來越多的使用著，而下一篇雜談准備討論設計模式，如果不了解UML，那麼無法進行下去
UML，全稱：Unified Modeling Language，其目的是為了對軟件密集型的制品進行可視化、詳述、構造和文檔化的圖形語言。UML是依據許多前人的思想總結出的成果，1997年被OMG通過並成為標准（所以在《設計模式》書中如果你看到與標准不一樣的地方，不要奇怪，那本書是95年的）。關於UML的歷史和更詳細的描述，可以參考《UML 參考手冊》。UML主要由一系列視圖組成，其中包括靜態視圖（Static view），用例視圖（Use case view）活動視圖（Activity view）等，不同的圖用處自然也不一樣，而對開發人員來講（或者說為我的下一篇來說），更重要的應該是靜態視圖中的類圖（class diagram）和交互視圖（Interaction view）中的順序圖（Sequence diagram），請注意view和diagram的區別。
類圖
靜態視圖說明了對象的結構，其中最常用的就是類圖，類圖可以幫助我們更直觀的了解一個系統的體系結構，有時侯，描述系統快照的對象圖（Object diagram）也是很有用的。在這裡，我們主要介紹類圖，下面的圖就是一個簡單的類圖：
在類圖中，類由矩形框來表示，如上圖中，定義了4個類，分別為Base、A、B、C，類之間的關系通過各種線條和其他符號來表示，在上圖中，空心的三角表示繼承關系，在UML的術語中，這種關系被稱為泛化（Generalization），所以上面的類用等價代碼表示為：
class Base{…};
class A:public Base{…};
class B:public Base{…};
class C:public Base{…};
我們再看下一幅圖：
這幅圖與上幅幾乎沒有什麼區別，唯一的不同就是Base類中增加了成員，一個私有的integer _x（UML術語為property）和一個公有的fun()的函數（method），是否需要這些類的內部細節UML本身並沒有限制，完全取決於你自己如何使用，UML的用處在於幫助你了解系統，所以只要你自己覺得足夠清楚，那麼夠了，不要再復雜了。
接著看第三幅圖：
上面圖中的箭頭表示一種關系，箭頭另一邊有一個菱形（空心）表示聚合（aggregation），聚合的意義表示has-a關系，其等價代碼如下：
class A{…};
class B{ A* theA;…};
聚合是一種相對松散的關系，聚合類B不需要對被聚合的類A負責。
下面的圖：
這幅圖與上面的唯一區別是菱形為實心的，它代表了一種更為堅固的關系——組合（composition）。組合表示的關系也是has-a，不過在這裡，A的生命期受B控制，通常情況，等價代碼如下:
class A{…};
class B{A theA;…};
即A會隨著B的創建而創建，隨B的消亡而消亡。
下圖：
這裡B與A的關系只是一種依賴關系，這種關系表明，如果類A被修改，那麼類B會受到影響，一個簡單的例子就是：
class A{…};
class B{fun(A params);…};
常用的關系就是我們上面用的這些，通過這些關系和類表示的類圖，我們可以用圖形化的方式描述一個系統的設計部分，當你習慣使用UML後，你會發現，這往往比你告訴同伴某某類從某某類派生，派生類又和某某類具有什麼關系容易的多。
順序圖：
UML中另外一個常用的圖形就是交互視圖中的順序圖，在以往的過程化語言中，我們通常使用流程圖來描述一個函數（系統）是如何工作的，而在面向對象的系統中，這顯然是不可行的，而順序圖正是來解決這個問題的。
假設有如下的偽代碼：
class circle
{
public:
void fillcolor()
{
// ...
};
void draw()
{
fillcolor();
};
};
class window
{
public:
void drawcircle()
{
_circle.draw();
};
private:
circle _circle;
};
對於下面的調用：
window wnd;
wnd.drawcircle();
對應的順序圖如下：
圖中上方的方塊表示參與的對象，垂直的虛線表示對象的生命線，方框表示激活，其中箭頭表示了一個調用消息（也可以有回送return），如果是異步的消息，則用半箭頭表示，其中draw表示了一個自調用(self call)
至此，UML中最常用的（從開發人員的角度），當然UML的內容遠遠不只這些，這裡的介紹只是一些簡單的概括，並且UML本身也在不斷的發展之中，無論怎樣，我覺得UML會越來越多的深入我們的開發過程中，特別是對下一篇我們要介紹的設計模式而言，類圖是主要的描述工具（到那個時候你會體會到UML描述的優越）。
如果你看過《設計模式》著本書，你會發現與我上面所描述的有一些細微的不同，不要緊張，《設計模式》是GOF95年的作品，那時候UML還沒有形成，而且，其中也明確那是OMT方法（Jim Rumbaugh在通用電氣發表的建模技術——Object Modeling Technique）和Booch方法。如果你覺得UML有些讓你無所適從，也不必緊張，UML本身只是一個輔助工具，它的目的是幫助你描述系統，不是復雜你的工作，如果你的系統很簡單，一句話可以說的很清楚，那麼不要用UML，如果你只想說明類之間的關系，而不是類的接口描述，那麼像第一副圖那樣簡單的描述就很好，總之不要去追求細節，只要能說明問題，那麼你的目的就達到了（甚至你沒有必要完全遵守規范）。
