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关系用虚线加上封闭的箭头（从实现接口的类指向接口）表示。现在我们看到了第四种箭头与线型的组合：虚线加上开叉箭头表示的依赖关系。 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另一种重要的图形——交互图，包括序列图和协作图。