UML 关于“抽象"和刻板印象的问题 [英] UML Questions about 'abstract' and stereotypes

问题描述

大家好，我正在努力理解 UML，但有一些关于它的问题

在 UML 中，用构造型 <> 标记一个类有什么意义?

以及如何将此约束表示为不变量，

解决方案

我意识到这个线程已经有几年了，但是当它被其他人引用时我才来到它，以支持 的断言«abstract» 构造型不受 UML 规范支持.这种说法不太准确，我想解释一下原因.我将首先阐明什么是抽象类.

抽象类是不包括完整实现的类的定义.因此，抽象类不能直接实例化；它们必须是专门的(继承的).抽象类通过将类名和抽象方法加斜体来表示，另外还可选地向类名和/或操作添加 {abstract} 属性(我们通常说的方法，但方法实际上是实现操作的方法")是抽象的.

接口实际上是一种特定类型的抽象类:零实现的类.它们的符号与其他类型的抽象类不同(不要斜体，使用 «interface» 关键字，并用虚线标记所有专业化箭头).所以，正如 Christian 在这里所说的，抽象类有标准的表示法——至少在类图中有.

现在，虽然正如 Christian 所说的那样，«abstract» 刻板印象不存在是真的，但如果你愿意，你也可以创建它，并且这样做UML 规范支持 so .您不太可能有理由这样做(至少在类图中)，但您仍然可以这样做.

构造型是一种可扩展性机制"；对于 UML(有三种:构造型、标记值和约束).它允许您更具体地定义某种元素.构造型应用于类(元类实际上，元类是其实例也是类的类).许多刻板印象是预定义的标准刻板印象".(在 UML 1.4 中，它们被称为标准元素").这些示例是 «metaclass»(同样，一个类的实例也是类)和 «file»(开发系统上下文中的物理文件).

刻板印象是一种关键字.规范(上层建筑 2.0，附件 B，第 663 页)对关键字有以下说明:

<块引用>

UML 关键字是保留字，是 UML 的一个组成部分符号，通常作为附加到 UML 的文本注释出现图形元素或作为 UML 图中文本行的一部分.这些词...不能用于命名用户定义的模型元素，这种命名会导致对该模型.例如，关键字trace"是系统定义的抽象的刻板印象(见附录 C，标准刻板印象")和，因此，不能用于定义任何用户定义的构造型.

在 UML 中，关键字有四种不同的用途:

• 要将特定的 UML 概念(元类)与其他共享相同通用图形形式的概念(元类)区分开来...

• 要将 UML 概念(元关联)之间的特定关系与共享相同通用图形形式的其他关系区分开来...

• 要指定附加到 UML 概念的某些修饰符的值(元属性值)...

• 要表明标准的刻板印象(参见附录 C，标准的刻板印象")...

<块引用>

关键字总是用 guillemets («keyword») 括起来，作为视觉提示，更容易区分何时使用关键字......除了识别关键字外，还使用了 guillemets区分用户配置文件中定义的构造型的使用.这意味着:

<块引用>

1. 并非所有出现在 guillemets 之间的词都一定是关键字(即保留词)，并且
2. 出现在 guillemets 中的词不一定代表刻板印象.

换句话说，您可以创建任何您想要的构造型，只要它不是关键字.由于抽象"不是关键字，因此您可以创建 «abstract» 构造型.

然而，为了做到这一点，您将不得不遇到一些麻烦，在 UML 2.0 及更高版本中比在 UML 1.4 中更麻烦.UML 1.4 简单地声明构造型是 UML 规范的扩展机制.可以简单地定义构造型，将其应用于想要的 UML 元模型的任何部分，并记录更改.UML 2.0 希望将构造型与 UML 元类的关系形式化(UML 图中的任何项目都是元类，并且是 UML 元模型的一部分).所以，他们想出了 Profiles.此示例图显示了配置文件的工作原理:

现在，那个黑色箭头可能看起来有点奇怪，因为除了这个箭头之外，您不会在任何上下文中看到它.UML 2.0 引入了扩展的概念，它定义为用于指示元类的属性通过构造型扩展".此黑色箭头表示扩展名.

我会引用 Tom Pender(UML Bible，Wiley Publishing，2004 年)来解释这个图表，因为他比规范做得更好(我当然不能改进就可以了):

<块引用>

它表明一个 Component 由一个 Bean 构造型扩展，这是必需的.Bean 构造型是一种抽象类型，有两个子类型——实体和会话.因此，Component 的每个实例都必须由 Entity 构造型或 Session 构造型的实例扩展.请记住，构造型是一种可以具有属性的类 - 在这种情况下，会话构造型具有名为 state 的属性.这对应于一个标记定义，其值指定会话的状态.标记值是一个枚举 StateKind，它具有无状态或有状态值.

<块引用>

组件对其有约束，显示在组件符号所附的注释中，说明组件不能被泛化或专业.

<块引用>

该图还显示了一个接口元类是由 Remote 和 Home 构造型扩展的.EJB 包有一个约束，显示在包中的注释中，声明一个 Bean 必须完全实现一个 Home 接口.

因此，如果您有理由不厌其烦地创建它，您确实可以使用 «abstract» 构造型.任何人都可能想要在类图以外的某个地方表示抽象类的主要原因.

hi every body i'm trying to understand UML but there are some questions about it

In UML what is the significance of tagging a class with the stereotype <<abstract>>?

and how to express this constraint as an invariant,

解决方案

I realize this thread is a couple of years old, but I came to it when it was referenced by someone else, as supporting the assertion that the «abstract» stereotype isn't supported by the UML spec. That assertion isn't quite accurate, and I'd like to explain why. I'll start by clarifying what abstract classes are.

Abstract classes are definitions of classes that don't include complete implementation. Therefore, abstract classes can't be directly instantiated; they have to be specialized (inherited). Abstract classes are notated by italicizing the class name and the methods that are abstract, and additionally by optionally adding an {abstract} property to the class name and/or to the operations (methods, we usually say, but methods are actually the "method" by which the operation is implemented) that are abstract.

Interfaces are actually a specific type of abstract class: a class with zero implementation. Their notation is different from other types of abstract classes (don't italicize, use the «interface» keyword, and notate all the specialization arrows with dotted lines). So, as Christian says here, there is standard notation for abstract classes--at least, there is in class diagrams.

Now, while it is true, as Christian also says, that the «abstract» stereotype doesn't exist, it is also true that you can create it if you want to, and that doing so is supported by the UML spec. It's unlikely that you'll have a reason to (at least in class diagrams), but you still can.

A stereotype is an "extensibility mechanism" for UML (there are three: stereotypes, tagged values, and constraints). It allows you to more specifically define some sort of element. Stereotypes are applied to classes (metaclasses actually, metaclasses are classes whose instances are also classes). A number of stereotypes are pre-defined "Standard Stereotypes" (in UML 1.4 they were called "Standard Elements"). Examples of these are «metaclass» (again, a class whose instances are also classes) and «file» (a physical file in the context of the system developed).

Stereotypes are a type of keyword. The spec (Superstructure 2.0, Annex B, p. 663) has this to say about keywords:

UML keywords are reserved words that are an integral part of the UML notation and normally appear as text annotations attached to a UML graphic element or as part of a text line in a UML diagram. These words...cannot be used to name user-defined model elements where such naming would result in ambiguous interpretation of the model. For example, the keyword "trace" is a system-defined stereotype of Abstraction (see Annex C, "Standard Stereotypes") and, therefore, cannot be used to define any user-defined stereotype.

In UML, keywords are used for four different purposes:

• To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form...

• To distinguish a particular kind of relationship between UML concepts (meta-association) from other relationships sharing the same general graphical form...

• To specify the value of some modifier attached to a UML concept (meta-attribute value)...

• To indicate a Standard Stereotype (see Annex C, "Standard Stereotypes")...

Keywords are always enclosed in guillemets («keyword»), which serve as visual cues to more readily distinguish when a keyword is being used...In addition to identifying keywords, guillemets are also used to distinguish the usage of stereotypes defined in user profiles. This means that:

1. Not all words appearing between guillemets are necessarily keywords (i.e., reserved words), and
2. words appearing in guillemets do not necessarily represent stereotypes.

In other words, you can create any stereotype that you want, so long as it isn't a keyword. Since "abstract" is not a keyword, it follows that you can create an «abstract» stereotype.

In order to do so, however, you would have to go to some trouble, more trouble in UML 2.0 and above than in UML 1.4. UML 1.4 simply stated that a stereotype was an extension mechanism for the UML spec. One could simply define the stereotype, apply it to whichever part of the UML metamodel one wanted, and document the change. UML 2.0 wanted to formalize the relationship of a stereotype to a UML metaclass (any item on a UML diagram is a metaclass, and part of the UML metamodel). So, they came up with Profiles. This sample diagram shows how profiles work:

Now, that black arrow may look a bit strange, since you don't see it in any context but this one. UML 2.0 introduced the concept of an Extension, which it defines as "used to indicate that the properties of a metaclass are extended through a stereotype." This black arrow indicates an extension.

I'll quote Tom Pender (The UML Bible, Wiley Publishing, 2004) for an explanation of this diagram, since he does a better job than the spec (and I certainly can't improve on it):

It shows that a Component is extended by a Bean stereotype, which is required. The Bean stereotype is an abstract type, with two subtypes - Entity and Session. Each instance of Component, therefore, must be extended by an instance of either the Entity stereotype or the Session stereotype. Remember that a stereotype is a kind of class that can have properties - in this case, a Session stereotype has an attribute named state. This corresponds to a tagged definition whose value specifies the state of the Session. The tagged value is an enumeration, StateKind, which has either a stateless or stateful value.

The Component has a constraint on it, displayed in the note attached to the Component symbol, which states that a Component cannot be generalized or specialized.

The diagram also shows that an Interface metaclass is extended by the Remote and Home stereotypes. The EJB package has a constraint, displayed in the note that sits in the package, that states a Bean must realize exactly one Home interface.

So, you can indeed use an «abstract» stereotype if you have reason to go to the trouble of creating it. The main reason that anyone might want to is to represent an abstract class in some place other than a class diagram.

这篇关于UML 关于“抽象"和刻板印象的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！