什么是UML,UML主要用于

　　UML有一系列的机制可以用来扩展它的核心概念，但是可能最广为人知的是原型。刻板印象一般翻译为“刻板印象”，是一种引申成分。

　　语义的建模元素。类型构造必须基于元模型中特定的现有类型或类。类型构造可以扩展现有类型和类的语义，但不能改变它们的结构。关键是构造类型的默认表示。

　　单词被带有尖角的双括号包围，这在一些欧洲语言中自然存在。因为很像两个尖括号，所以用两个尖括号也是大家公认的表达方式。

　　类型构造几乎适用于UML中的任何元素，包括类、属性、操作和关联。例如，我们可以使用原型在UML图中显示一个类的类。图1显示了一个类在由原型表示的状态设计模式中的角色，改编自设计

　　模式”。UML定义了大量的标准原型。我们可以使用这些标准的原型或者定义我们自己的原型。

　　图1: UML原型用于表示设计模式中类的角色。

　　图1中的MessageStatus接口应该在尖括号中有interface这个词。但是，为了将该接口与其他原型区分开来，使用了Together来制作本文的UML图。

　　ControlCenter工具已被省略。这是因为接口不同于其他构造型。“接口也具有与UML元模型中的类相似的特征”。

　　直到UML 1.4(2001年9月)，UML中的图形元素只能有一个原型。但是在UML中

　　在1.4中，OMG(对象管理组)取消了这个限制，现在一个图形元素可以有多个原型。许多UML工具跟不上这种变化，所以它们仍然不提供这种支持。

　　那么，构造型是如何影响我们的Java代码的呢？从某种意义上来说，答案是“一点也不”，因为Java并没有提供任何手段让我们以这种方式对类进行分类。

　　(前面的文章已经讨论了接口和继承，它们在UML中都有自己特定的表示方法)。但是，从另一方面来说，我们可以用原型来更清晰明了地解释Java代码的内容。

　　含义：先就stereotype的具体含义达成一致，然后在源代码注释中以一个新的javadoc标签的形式包含stereotype，有效减少了解释Java代码含义的手工编写。

　　解释字数。下面的代码片段是图1中Sent类的框架代码。原型以定制javadoc标签的形式添加到注释中：

　　/**

　　* @原型混凝土状态

　　* @作者AuthorName

　　* @版本0.0001

　　*/

　　发送的公共类实现MessageStatus {

　　}

　　在UML中，不仅类可以通过指定原型来约束它们的定义。图2显示了两个类之间的依赖关系，这种依赖关系的类型由原型表示。在这个例子中

　　在中，工厂类的对象负责创建项目类的对象。工厂类的代码展示了定制javadoc标签如何使用原型来简明地解释这种依赖性。

　　部门。

　　图2:实例化原型的UML依赖关系

　　符号描述：在上一篇文章中，我们看到了三类之间的关系，这里出现了第四类。关系用实线加拆分箭头表示(如果关系是单向的)，这是一般化的。

　　关系用实线加闭合箭头表示(从子类到超类)，实现关系用虚线加闭合箭头表示(从实现接口的类到接口)。现在我们看到第四个。

　　箭头和线型的组合：虚线加拆分箭头表示依赖关系。

　　公共类工厂

　　{

　　/**

　　* @依赖项实例化项目

　　* @返回新项目

　　*/

　　公共项目createItem() {

　　返回新项目()；

　　}

　　}

　　动作和属性也可以指定原型。如图3所示，两个操作用原型进行了标记，以表明它们是否会修改属性值。对应于图3的源代码也使用定制的javadoc标签来说明这个方法的原型信息。

　　图3:为类操作标注UML原型

　　公共类别销售

　　{

　　.

　　/**

　　* @原型查询

　　* @返回销售总价

　　*/

　　public BigDecimal calcTotal() {

　　}

　　.

　　}

　　在java源代码中添加定制的javadoc标签来描述原型信息之后，好处不仅在于减少了需要手工编写的注释的数量，而且使得UML工具能够处理这些标签并完成以下任务：

　　从Java源代码中重新生成一个更完整的UML图(如果没有定制的javadoc标签的话)。

　　向Javadoc生成的文档中添加附加信息。

　　例如，本文中使用的建模工具TogetherSoft。

　　ControlCentre就是用这种方法来保留在Java源代码中无法直接保留的UML类图的各种语义信息。

　　其他表示方法

　　在本文的开始，尖括号是显示原型的默认方式。事实上，刻板印象也可以通过改变图形符号或形状来表达。图4中的例子显示了两个图像

　　行动者

　　类型的构造类。收银员用原型替换符号绘制，经理类用默认矩形绘制。当使用替换符号时，很难列出该类的各种属性和操作，因此通常省略它们。还有第三种表示方式，即在常规的矩形符号中，类名的右边放置一个小的替代符号，但这种表示方式现在已经很少见了。

　　图4:演员刻板印象的替代符号

　　在类图中使用替代符号来表示原型有一个很大的缺点。如果有些人不熟悉类图中使用的符号，就很难理解类图是什么意思。另外，多一个符号，理解图形的负担就会增加一分。在这一系列文章中，我们只关注最常见的UML类图符号。

　　除了改变符号的形状来表明已经指定了一个原型，我们还可以通过改变图形元素的颜色或纹理来表达相同的信息。颜色的使用意味着我们可以保持常规的图形形状和符号，同时表达与改变形状一样多的视觉信息(如果不是更多的话)。另外，相对于抽象的形状，简单的配色一般更容易掌握。

　　图5:在类图中使用颜色

　　图5的颜色类图使用Peter Coad等人的四色原型的组合来定义类。

　　粉红色的时刻-间隔类表示出于业务或法律原因必须在系统中跟踪的事件或活动。CarSale和CarRental是粉色类的两个例子。

　　黄色的角色类别代表参与事件或活动的方式。例如，CarSalesperson和Customer就是黄色类的例子。

　　绿色类可以进一步分为当事人(通常是一个人或组织)、场所(事件或活动发生的地方)和事物(事件或活动实际涉及的对象)。

　　第四个原型是蓝色的catalog-entry-like-description(简称description)，它显示了实车与展览目录中描述的区别：汽车模型属于蓝色类别，它包含一系列值和范围来描述属于该类别的所有汽车，而每辆实车都用绿色的东西来表示。

　　属于特定原型的类具有或多或少相似的属性和行为，属于同一原型的类也倾向于以通常可预测的方式与其他原型的类进行交互。这些特性和行为模式可以帮助我们快速构建一个健壮的、可扩展的对象模型，快速掌握可能被忽略的属性和操作，增强我们对代码结构的信心。图5显示了我们可以在各种原型的类中找到的属性和操作，以及各种原型之间的典型关系。

　　结论：在本文中，我们学习了UML中一些有用的概念。如果Java语言中没有直接等价的概念，如何在Java代码中使用UML的这些概念来保留高层的设计思想。在下一篇文章中，我们将告别UML类图，转而讨论UML的另一个重要图，3354交互图，包括序列图和协作图。

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

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。