我們比較了在Java編程語言以及UML建模語言這兩種環境中
類以及類之間關系在表達方式以及概念方面的差異
下面我們要來看看UML Stereotype機制對於編寫Java代碼的影響
在Java程序中保留Stereotype
UML擁有一系列可用來擴展其核心概念的機制
但最為人們熟知的也許就是Stereotype
Stereotype一般譯作
構造型
它是一種擴展元模型語義的建模元素
構造型必須基於元模型中特定的現有類型或類
構造型可擴展已有類型和類的語義
但不能改動它們的結構
構造型默認的表示方法是在關鍵詞周圍加上尖角雙括號
這種雙括號在某些歐洲語言中自然存在
因為它很象兩個尖括號
所以用兩個尖括號也是一種被認可的表示方式
構造型幾乎適用於UML中的任何元素
包括類
屬性
操作以及關聯等
例如
我們可以用構造型來顯示UML圖中一個類別的類
圖一顯示了用構造型來表示State設計模式中一個類扮演的角色
改編自《Design Patterns》一書
UML定義了大量的標准構造型
我們既可以使用這些標准構造型
也可以定義自己的構造型
圖一
UML構造型用於表示類在設計模式中的角色
圖一中的MessageStatus接口本來應該讓interface這個詞位於尖括號之內
但是
為了把接口和其他構造型區分出來
用來制作本文UML圖的Together ControlCenter工具已予以省略
這是因為接口與其他構造型不同
在UML元模型中接口也具有與類相似的特性
直到UML
之前（
年
月）
UML中的一個圖形元素只能有一個構造型
但在UML
中
OMG（對象管理組織）取消了這個限制
現在一個圖形元素可以有多個構造型
許多UML工具由於未能跟上這一變化
所以仍沒有提供這方面的支持
那麼
構造型對於我們的Java代碼又有何影響呢？從某種意義上講
答案是
完全沒有
因為Java沒有提供任何讓我們按照這種方式對類進行分類的手段（前面幾篇文章已經討論了接口和繼承
在UML中它們都有自己特定的表示方法）
但是
另一方面
我們可以利用構造型更清楚
明白地說明Java代碼的含義
首先約定構造型的具體意義
然後在源代碼注釋中以一個新的javadoc標記的形式包含構造型
有效地減少為了說明Java代碼含義而需要手工編寫的說明文字數量
下面的代碼片斷就是圖一Sent類的骨架代碼
構造型以一個定制javadoc標記的形式加入到了注釋之中
/**
* @Stereotype concreteState
* @author AuthorName
* @version
*/
public class Sent implements MessageStatus {
}
在UML中
並非只有類可以通過指定構造型而約束其定義
圖二顯示了兩個類之間的依賴關系
用構造型來表示這種依賴關系的類型
在這個例子中
Factory類的對象負責創建Item類的對象
Factory類的代碼顯示了定制的javadoc標記如何用構造型來簡潔明了地說明這種依賴關系
圖二
加注instantiate構造型的UML依賴關系
符號說明
在前面的文章中
我們看到了三種類之間的關系
這裡出現的是第四種
關聯關系用一根實線加上開叉的箭頭表示（如果關聯關系是單向的話）
一般化關系用實線加上封閉的箭頭（從子類指向超類）表示
Realization關系用虛線加上封閉的箭頭（從實現接口的類指向接口）表示
現在我們看到了第四種箭頭與線型的組合
虛線加上開叉箭頭表示的依賴關系
public class Factory
{
/**
* @dependency <
> 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類圖語義信息
其他表示方法
本文開頭提到尖括號是顯示構造型的默認方式實際上構造型還可以用改變圖形符號或形狀的方式表示圖四的例子顯示了兩個帶有<>構造型的類Cashier利用<>構造型的替代符號畫出Manager類用默認的矩形畫出在使用替代符號時很難再列出類的各種屬性和操作所以通常省略還有第三種表示方法即在常規的矩形符號內的類名稱右邊放上一個很小的替代符號但現在這種表示方法已經不太見到了
圖四<>構造型的替代符號
在類圖中使用替代符號表示構造型有一個很大的缺點如果有些人不熟悉類圖用到的符號要理解類圖表達的是什麼意思就很困難了另外多一種符號理解圖形的負擔就增加一分在這個系列的文章中我們只關注那些最常見的UML類圖符號
除了用改變符號形狀的方法來表示已經指定了某種構造型之外我們還可以通過改變圖形元素的顏色或紋理來表達同樣的信息運用色彩意味著我們可以保留常規的圖形形狀和符號同時又能表達出與改變形狀同樣多的視覺信息（如果不是更多的話）另外與抽象的形狀相比簡單的配色方案一般更容易掌握一些
圖五在類圖中運用色彩
圖五的彩色類圖運用了Peter Coad等人的四色原型（Archetype）組合來定義類
粉紅色的<>類表示在一個系統中由於業務或者合法性的原因必須跟蹤的事件或活動CarSale和CarRental就是兩個粉紅色類的例子
黃色的<>類代表參與事件或活動的方式例如CarSalesperson和Customer都是黃色類的例子
綠色的類可進一步分成<>（通常是一個人或組織）<>（事件或活動發生的地點）以及>（實際涉及事件或活動的物體）
第四種原型是藍色的catalogentrylikedescription（簡稱<>）表示的是諸如現實當中的汽車與展覽目錄中的描述之間的差異汽車型號屬於藍色的類它包含一系列的值和取值范圍描述所有屬於該類別的車而每一輛現實中的車則由綠色的<>來表示
屬於特定原型的類具有或多或少相似的屬性和行為屬於同一原型的類還會傾向於以通常而言可預測的方式與其他原型的類交互這些特征和行為模式可以幫助我們快速構造出健壯的可擴展的對象模型迅速掌握有可能被忽略的屬性和操作增強我們對代碼結構的信心圖五顯示了我們可能在各種原型的類中找到的屬性和操作以及各種原型之間的典型關系
結束語在這篇文章中我們了解了對於UML中一些很有用的概念如果它在Java語言中沒有直接的等價概念如何在Java代碼中利用UML的這些概念來保留高層次的設計思想在下一篇文章中我們將告別UML類圖轉而討論UML另一種重要的圖形——交互圖包括序列圖和協作圖
From:http://tw.wingwit.com/Article/program/Java/Javascript/201311/8556.html
