在Java中保留Stereotype

发表于:2007-05-25来源:作者:点击数: 标签:java保留Stereotype@Stereotype
/** * @Stereotype concreteState * @author AuthorName * @version 0.0001 */ public class Sent implements MessageStatus { } 在UML中,并非只有类可以通过指定构造型而约束其定义。图二显示了两个类之间的依赖关系,用构造型来表示这种依赖关系的类型。

            /**
            * @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.ltesting.net