UML 中的构造型和类继承有什么区别？答案

【问题标题】：What's the difference between a stereotype and a class inheritance in UML?UML 中的构造型和类继承有什么区别？
【发布时间】：2010-10-24 05:08:38
【问题描述】：

我对 UML 中“刻板印象”和“超类”之间的区别感到困惑。

假设我想创建一个包含“WidgetMaker”的图表。 WidgetMaker 显然是 Actor，所以 UML 标准是对其进行刻板印象：

<<Actor>> WidgetMaker

但我是在 Java/Ruby/C++ 世界中长大的。在那个世界里，关系是：

class Actor
end

class WidgetMaker < Actor
end

在 UML 中看起来像这样：

  Actor
    ^
    |
WidgetMaker

所以我的问题是：当您可以使用类继承轻松地对这些概念进行建模时，为什么 UML 还具有原型，它也具有。

一旦我们有了更多“种类”的演员，问题就变得更加模糊：

              Actor
                ^
                |
    ------------------------
    |           |          |
  Person      Robot      Group
    ^
    |
WidgetMaker

对

<<Actor>> <<Person>> WidgetMaker

【问题讨论】：

这个链接可能对sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10有帮助

标签： inheritance uml stereotype

【解决方案1】：

据我了解，构造型的主要目的是支持 UML 本身的扩展（作为一种建模语言），而不是建模任何东西。

话虽如此，我还认为您的问题暗示了另一个可能的有效答案：有些人更喜欢使用刻板印象来指定（非正式地！）类之间的某些共性。他们可能会这样做只是因为它比子类化更容易，并且对于他们的模型而言“足够好”。

例如，许多软件系统都有代表所谓领域实体（如公司、客户、采购订单、产品等）的类。最终，您可能希望拥有一个像 Entity 这样的通用类来派生 Company、Customer 等。但最初可能只使用诸如<<Entity>> Company、<<Entity>> Customer 等的定型类就足够了。本质上，这只是建模工作的方便（和成本/收益！）问题。

【讨论】：

【解决方案2】：

在您的示例中，Actor 可能不需要实现为一个类，但这可能会或并非总是如此。刻板印象是可以应用于大多数 UML 元素的抽象，而不仅仅是类。

它们封装语义而不暗示这些语义将如何提供。另一个例子可能是一个原型为 HTTP 或 RPC 的通信通道。他们正在与读者交流如何在不使模型复杂化的情况下提供一些不必要的细节。

UML 规范提供了许多预定义的构造型，但它们真正的威力来自于能够通过配置文件定义您自己的构造型。您可以将域对象标记为 EJB，以免自己指定所有样板代码。

【讨论】：

【解决方案3】：

Stereotype 存在并用于呈现有关工件的更多信息，文档或将其分类到特定工件块中可能无法提供这些信息。例如，您已经确定了一个数据类，您可以给它命名，解释属性和操作，但它本身可能不会给出完整的信息。当您将其定型为时，它指定了完整的信息；在此之前，它会像开发人员的任何其他类一样继续存在。

“Stereotypes 用于扩展 UML 符号元素，对关联、继承关系、类和组件进行分类和扩展”

Stereotype 提供了创建新型建模元素的能力。刻板印象必须基于作为 UML 元模型一部分的元素。类的一些常见原型是实体、边界、控制、实用程序和异常。类的构造型显示在用 guillemets 括起来的类名下方（即 « 和 »，发音为 gee-may）。如果需要，图形图标或特定颜色可以与原型相关联。

【讨论】：

除了图标和颜色之外，这个“完整信息”是什么？为什么不能仅仅通过子类化一个定义了颜色和图标的元属性的类来实现呢？如果我想创建一个特定类型的数据，我怎么知道是对它进行原型>还是继承Data类？
您应该将构造型视为一种根据共同目的对类进行分组的方式：边界类、控制类、实用程序类等。它不会改变您的类的性质，而是帮助记录它.
这使它听起来更像是一个静态属性。但是 WidgetMaker 是一个 Actor，它不只是像 Actor 一样行事或具有 Actor-ness。
这不能回答 IMO 的问题。

【解决方案4】：

可以从 OMG 如何在 SysML 或 BPMN 配置文件中应用它们来很好地表明刻板印象背后的意图。具体来说，构造型描述了一组新的建模结构，作为指定域的语言的一部分。例如，SysML 中的 Block 是应用于 Class 的原型。它带来了用于系统工程的类的定制。在这种情况下，它取代了 Class 的使用，并建立了与其他元素和图表类型的新关系，例如块>要求（允许的关系）或块可以使用内部框图（允许的行为）建模。刻板印象不用于模拟您的主题空间。它将建模构造的使用分类为系统定义的垂直或水平方面。

【讨论】：

【解决方案5】：

我觉得谈论刻板印象而不将 MOF METALEVELS 带入讨论会导致无法真正解释关键点。

在 M2 中“存在”刻板印象（请参阅“OMG 统一建模语言 (OMG UML)，基础设施，Verison 2.4.1”），它专门用于定义建模语言。刻板印象生活在这个级别，而不是在 M1 或 M0 中。换句话说，刻板印象是一种专门用于定义新建模语言的结构，而不是用于定义新领域模型。

因此，在层次 M1 中用泛化替换刻板印象在域建模范围内可能在语义上是可以的，但由于它位于错误的元层次中，因此在语义上并不完全等效。

另外一点是，刻板印象可能是可选的或强制性的。但是，继承不能是可选的。

【讨论】：

这个讨论：这不是一个讨论。请通过tour 了解 Stack Overflow 是什么。

【解决方案6】：

根据 https://sites.google.com/site/assignmentssolved/mca/semester2/mc0069/10 如果您想要标记值，则需要将它们定义为构造型上的属性（因为 UML 2.0 是必需的）

在 UML 1.3 中，标记值可以扩展模型元素而不需要存在构造型。在 UML 1.4 中，尽管仍受支持，但已弃用此功能，仅出于向后兼容的原因使用。

自 UML 2.0 起，标记值只能表示为在构造型上定义的属性。因此，模型元素必须通过构造型扩展才能通过标记值进行扩展。为了支持与 UML 1.3 的兼容性，一些 UML 工具可以自动定义一个原型，将附加“未附加”属性（标记值）。

标签值可以显示在原型名称下的类隔间中。对于要显示其值的每个应用的构造型，都需要一个额外的隔间。每个这样的隔间都以 guillemets 中应用的刻板印象的名称为标题。

2003 年关于刻板印象的有趣读物可能是 https://www.semanticscholar.org/paper/Systematic-stereotype-usage-Atkinson-K%C3%BChne/3253db03c11f4f99be580277716d3b78d750618a

这是摘要：

作为 UML 的主要扩展机制之一，构造型在 UML 服务于广泛且不断增长的用户群的能力中发挥着至关重要的作用。然而，刻板印象的确切含义及其预期的使用方式从未完全清楚，甚至在专家之间引发了激烈的争论。在实践中观察到了使用 UML 原型的两种基本方法：一种支持类分类作为模拟元模型扩展的一种手段，另一种支持对象分类作为为其分配某些属性的一种手段。在本文中，我们分析了这两种公认的刻板印象使用场景，并解释了明确识别第三种使用场景的基本原理。我们提出了一些符号概念，可用于明确区分三种使用场景，并提供关于何时应该使用每种场景的启发式方法。最后，我们提出了对 UML 的增强，它可以干净简洁地支持所有三种形式。

【讨论】：