關於UML中的Stereotype

在Java程式中保留Stereotype

UML擁有一系列可用來擴充其核心概念的機制，但最為人們熟知的也許就是Stereotype。Stereotype一般譯作“構造型”，它是一種擴充元
模型語義的建模元素。構造型必須基於元模型中特定的現有類型或類。構造型可擴充已有類型和類的語義，但不能改動它們的結構。構造型預設的表示方法是在關鍵
詞周圍加上尖角雙括弧，這種雙括弧在某些歐洲語言中自然存在，因為它很象兩個角括弧，所以用兩個角括弧也是一種被認可的表示方式。

構造型幾乎適用於UML中的任何元素，包括類、屬性、操作以及關聯等。例如，我們可以用構造型來顯示UML圖中一個類別的類。圖一顯示了用構造型來表示State設計模式中一個類扮演的角色，改編自《Design
Patterns》一書。UML定義了大量的標準構造型，我們既可以使用這些標準構造型，也可以定義自己的構造型。

圖一：UML構造型用於表示類在設計模式中的角色

圖一中的MessageStatus介面本來應該讓interface這個詞位於角括弧之內。但是，為了把介面和其他構造型區分出來，用來製作本文UML圖的Together
ControlCenter工具已予以省略。這是因為介面與其他構造型不同，“在UML元模型中介面也具有與類相似的特性”。

直到UML1.4之前（20001年9月），UML中的一個圖形元素只能有一個構造型。但在UML
1.4中，OMG（對象管理組織）取消了這個限制，現在一個圖形元素可以有多個構造型。許多UML工具由於未能跟上這一變化，所以仍沒有提供這方面的支援。

那麼，構造型對於我們的Java代碼又有何影響呢？從某種意義上講，答案是“完全沒有”，因為Java沒有提供任何讓我們按照這種方式對類進行分類的手段
（前面幾篇文章已經討論了介面和繼承，在UML中它們都有自己特定的表示方法）。但是，另一方面，我們可以利用構造型更清楚、明白地說明Java代碼的含
義：首先約定構造型的具體意義，然後在原始碼注釋中以一個新的javadoc標記的形式包含構造型，有效地減少為了說明Java代碼含義而需要手工編寫的
解說文字數量。下面的代碼片斷就是圖一Sent類的骨架代碼，構造型以一個定製javadoc標記的形式加入到了注釋之中：

/** * @Stereotype concreteState * @author AuthorName * @version 0.0001 */ public class Sent implements MessageStatus { }

在UML中，並非只有類可以通過指定構造型而約束其定義。圖二顯示了兩個類之間的依賴關係，用構造型來表示這種依賴關係的類型。在這個例子
中，Factory類的對象負責建立Item類的對象。Factory類的代碼顯示了定製的javadoc標記如何用構造型來簡潔明了地說明這種依賴關
系。

圖二：加註instantiate構造型的UML依賴關係

符號說明：在前面的文章中，我們看到了三種類之間的關係，這裡出現的是第四種。關聯關係用一根實線加上開叉的箭頭表示（如果關聯關係是單向的話），一般化
關係用實線加上封閉的箭頭（從子類指向超類）表示，Realization關係用虛線加上封閉的箭頭（從實現介面的類指向介面）表示。現在我們看到了第四
種箭頭與線型的組合：虛線加上開叉箭頭表示的依賴關係。

public class Factory { /** * @dependency <<instantiate>> Item * @return a new Item */ public Item createItem() { return new Item(); } }

操作和屬性同樣可以指定構造型。三所示，兩個操作被加註了構造型，用來表示它們是否會修改屬性的值。與圖三對應的原始碼同樣利用定製的javadoc標記說明該方法的構造型資訊。

圖三：為類的操作加註UML構造型

public class Sale { ... /** * @Stereotype query * @return total price of sale */ public BigDecimal calcTotal() { } ... }

在java原始碼中加上了描述構造型資訊的定製javadoc標記之後，好處不僅僅在於減少了需要手工編寫的注釋，而且使得UML工具有可能處理這些標記並完成下面這類任務：

從Java原始碼重建（比沒有定製javadoc標記的情況下）更加完整的UML圖。

在Javadoc產生的文檔中增加額外的資訊。

例如，本文所用的建模工具TogetherSoft的Together
ControlCentre，就是用這種方法來保留各種無法直接在Java原始碼中保留的UML類圖語義資訊。

其他表示方法

本文開頭提到，角括弧是顯示構造型的預設。實際上，構造型還可以用改變圖形符號或形狀的方式表示。圖四的例子顯示了兩個帶有
<<actor>>
構造型的類。Cashier利用<
>構造型的替代符號畫出，Manager類用預設的矩形畫出。在使用替代符號時，很難再列出類的各種屬性和操作，所以通常省略。還有第三種表示方
法，即在常規的矩形符號內的類名稱右邊放上一個很小的替代符號，但現在這種表示方法已經不太見到了。

圖四：<<actor>>構造型的替代符號

在類圖中使用替代符號表示構造型有一個很大的缺點，如果有些人不熟悉類圖用到的符號，要理解類圖表達的是什麼意思就很困難了。另外，多一種符號，理解圖形的負擔就增加一分。在這個系列的文章中，我們只關注那些最常見的UML類圖符號。

除了用改變符號形狀的方法來表示已經指定了某種構造型之外，我們還可以通過改變圖形元素的顏色或紋理來表達同樣的資訊。運用色彩意味著我們可以保留常規的
圖形形狀和符號，同時又能表達出與改變形狀同樣多的視覺資訊（如果不是更多的話）。另外，與抽象的形狀相比，簡單的色彩配置一般更容易掌握一些。

圖五：在類圖中運用色彩

圖五的彩色類圖運用了Peter Coad等人的四色原型（Archetype）組合來定義類。

粉紅色的
<<moment-interval>>
類表示在一個系統中，由於業務或者合法性的原因必須跟蹤的事件或活動。CarSale和CarRental就是兩個粉紅色類的例子。

黃色的
<<role>>
類代表參與事件或活動的方式，例如，CarSalesperson和Customer都是黃色類的例子。

綠色的類可進一步分成
<<party>>（通常是一個人或組織）、<<place>>（事件或活動發生的地點）以及<thing>>（實際涉及事件或活動的物體）
。

第四種原型是藍色的catalog-entry-like-description（簡稱
<<description>>
），表示的是諸如現實當中的汽車與展覽目錄中的描述之間的差異：汽車型號屬於藍色的類，它包含一系列的值和取值範圍描述所有屬於該類別的車，而每一輛現實中的車則由綠色的
<<thing>>
來表示。

屬於特定原型的類具有或多或少相似的屬性和行為，屬於同一原型的類還會傾向於以通常而言可預測的方式與其他原型的類互動。這些特徵和行為模式可以協助我們
快速構造出健壯的、可擴充的物件模型，迅速掌握有可能被忽略的屬性和操作，增強我們對代碼結構的信心。圖五顯示了我們可能在各種原型的類中找到的屬性和操
作，以及各種原型之間的典型關係。

結束語：在這篇文章中，我們瞭解了對於UML中一些很有用的概念，如果它在Java語言中沒有直接的等價概念，如何在Java代碼中利用UML的這些概念來保留高層次的設計思想。在下一篇文章中，我們將告別UML類圖，轉而討論UML另一種重要的圖形——互動圖，包括順序圖表和共同作業圖表。

轉自：http://www.uml.org.cn/UMLApplication/UMLApplication30.htm