kapok

UML中的四種機制使地它簡單和更易于使用，你可以在UML語言的任何時候用同樣的方法來使用，這四種機制是：

l         specifications

l         adornments

l         common divisions

l         extensibility

本章討論adornments和extensibility這兩種機制。

注釋是最重要的一種修飾。一個注釋在UML中是一個圖形符號，描述了和它相關聯的元素或一組元素的限制或注釋語。

  上圖就是一個使用注釋的例子，圖中右邊的為注釋符號。

  UML的擴充性機制允許你在控制的方式下擴充UML語言。這一類的機制包括：stereotype，標記值、約束。Stereotype擴充了UML的詞匯表，允許你創建新的建筑塊，這些建筑塊從已有的繼承而來，但特別針對你的問題。標記值擴充了UML的建筑塊的屬性，允許你在元素的規格中創建新的信息。約束擴充了UML建筑塊的語義，允許你添加新的規則或修改已有的。你將使用這些機制來讓UML滿足你的領域和開發的特別需要。

 

上面是一個使用擴充機制的例子。<<subsystem>>是stereotype，{version = 3.2}是標記值

術語和概念

    注釋是一種圖形符號用來限制或給一個元素或一組元素加上注解。注釋畫成一個帶折角的矩形，在矩形中加上文字或圖形的注解，stereotype是UML詞匯的擴充，允許你創建新的UML建筑塊，這些新的建筑塊和原有的類似，但特別針對你自己的問題。通常stereotype畫成用<<和>>包圍起來的一個名字，通常放在另一個元素的名字之上。作為可選，stereotype可以畫成加一個圖標。

    標記值是UML元素特性的擴充，允許你創建元素規格的新的信息。在UML中標記值畫成{}內的字符串，跟在元素名后面。

    限制是UML元素語義的擴充，允許你對一個UML元素添加新規則或修改存在的規則。限制通常畫成{}內的字符串，放在關系附近。當然，你也可以把限制用注釋來表示。

通用建模技術

1.         建模注解

使用注釋的目的是為了讓模型更清晰，下面是使用注釋的一些技巧：

l         將注釋放在你要注解的元素邊上，寫下注解的文字。用依賴關系的線將注釋和被注釋的元素連起來會讓人更明白。

l         記住，你可以隱藏元素或使隱藏的元素可見。這就意味著你可以將注釋不隱藏起來，而她注釋的元素是可見的，這樣會使你的模型圖簡潔，在必要的地方讓注釋可見。

l         如果你的注釋很長或不僅僅是普通文本，你可以將你的注解放到一個獨立的外部文件中（如WORD文檔）然后鏈接或嵌入到你的模型中。

下面是一個使用注解的例子：

建立新的建筑塊

    UML的建筑塊如：類、接口、合作、組件、注釋、關系等等，都在為具體問題建模的時候基本上是夠用了。然而，如果你想擴展你的模型的詞匯，如用來表示你的特定的問題領域，你需要stereotypes。

    建立新的建筑塊有如下的技巧：

l         確定沒有現成的基本的UML方法可以表達你的需要。如果你碰到一個普通的建模問題，很有可能已經有某種標準的stereotype是你想要的。

l         如果你確信沒有現成的東西可以表達這些語義，首先找到一個UML中的最接近你要建立的模型的元素（例如：類、接口、組件、注釋、關系等等）然后為她定義一個stereotype。值得一提的是你可以定義stereotypes的層次從而得到一般的stereotypes和為它定義的特別的特性。這種方法盡量少用。

l         通過對普通的stereotype定義一組標記值和對stereotype進行限制可以實現普通stereotype不能實現的功能。

l         如果你希望這些stereotype具有不同的視覺效果，為他們定義一個特別的圖標。

上面是一個例子。假如你用活動圖來為一個涉及到教練工作流和隊員工作流的體育活動建模。在這里，區別教練和運動員以及與其他的本領域的對象是有意義的。上面的圖中有兩個事物是很突出的，教練對象和隊員對象。這里不僅僅是普通的類，更確切地說，他們現在是兩個新的建筑塊。因為定義了教練和員stereotype，并且運用到了UML的類上。在這個圖上，被標記為:Coach和:Team的匿名實例，后者顯示了不同的狀態。

建模新屬性

UML建筑塊的基本屬性如：類的屬性和操作，包的內容等等，都足夠描述清楚你要建立的模型。然而，如果你想擴展這些基本建筑塊（或者用stereotype建立的新的建筑塊）的屬性，你就需要使用標記值。

下面是一些技巧：

l         首先要確定的是你的需要無法用基本的UML表達。如果你碰到一個普通的建模問題，很有可能已經有某種標準的標記值是你想要的

l         如果你確定沒有其他的方法可以表達你需要的語義，添加新的屬性到一個單獨的元素或一個stereotype。繼承的規則是適用的，也就是說對父親定義的標記值對兒子也具有。

建立新的語義

   當你用UML建立模型的時候，你總是使用UML定義的規則，這實在是件好事，因為別的懂得如何讀UML的人可以毫無偏差地讀懂你想要表達的東西。然而，如果你發現你需要表達的語義是UML無法表達的或你想要修改UML的規則，這時你就需要使用限制了。下面是使用限制的一些技巧：

l         首先要確定的是你的需要無法用基本的UML表達。如果你碰到一個普通的建模問題，很有可能已經有某種標準的限制是你想要的。

l         如果你確定沒有其他的方法可以表達你需要的語義，用文本的形式在限制中寫下你的新語義，并且將他放在他涉及的元素附近。你可以使用依賴關系來明確地表示限制和他涉及的元素之間的關聯。

l         如果你需要詳細說明你的語義，你可以用使用OCL把它寫下來。

下面的圖是一個公司人力資源系統的一小部分：

這副圖顯示了每個Person可能是0個或多個Department的成員。每個Department至少要有一個Person成員。這副圖進一步說明每個Department嚴格地有一個Person作為管理者，每個Person可以是0個或多個Department的被管理人員。所有的這些語義可以被簡單的UML表達。然而，為了指出一個管理者必須也是Department的成員是多員關系所忽略的，也是簡單的UML無法表達的。為了表達這種關系，你必須寫下一個限制指出管理者是Department成員的一個子集。從子集到超集用依賴關系將兩個關系聯系起來。





http://www.uml.org.cn/UMLApplication/UMLApplication30.htm

在Java中保留Stereotype

作者：仙人掌工作室    本文選自：賽迪網

在前面兩篇文章中（《用UML描述Java類》和《在UML中表示Java繼承和接口》），我們比較了在Java編程語言以及UML建模語言這兩種環境中，類以及類之間關系在表達方式以及概念方面的差異。下面我們要來看看UML Stereotype機制對于編寫Java代碼的影響。 在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關系用虛線加上封閉的箭頭（從實現接口的類指向接口）表示?，F在我們看到了第四種箭頭與線型的組合：虛線加上開叉箭頭表示的依賴關系。 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另一種重要的圖形——交互圖，包括序列圖和協作圖。