Question

我对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

Answer 1

据我了解，构造型的主要目的是启用UML本身的扩展（作为建模语言），而不是对任何东西进行建模。

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

例如，许多软件系统都有代表所谓域实体的类（公司，客户，采购订单，产品等）。最后，可能希望有一个像Entity这样的公共类来从中派生Company，Customer等。但最初只使用像<<Entity>> Company，<<Entity>> Customer这样的刻板类就足够了。基本上，这只是建模工作的便利（以及成本/收益！）的问题。

Answer 2

在您的示例中，Actor可能不需要作为类实现，但这可能或不总是如此。 Stereotype是可以应用于大多数UML元素的抽象，而不仅仅是类。

它们封装语义而不暗示将如何提供这些语义。另一个例子可以是定型为HTTP或RPC的通信信道。他们正在与读者沟通如何提供某些东西而不会使模型复杂化不必要的细节。

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

Answer 3

存在一个刻板印象，用于提供有关工件的更多信息，该工件将文档或其分类分类到特定的工件块中可能不会给出。例如，您已经识别出一个数据类，您可以给它命名，解释属性和操作，但它本身可能不会提供完整的信息。当您将其定型为＆lt;＆gt;时，它指定了完整的信息;在此之前，它会继续像开发人员那样继续上课。

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

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

Answer 4

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

Answer 5

我感到，在没有将MOF METALEVELS纳入讨论的情况下谈论定型观念是不可能实际解释要点的。

在M2中进行定型化“生存”（请参阅“ OMG统一建模语言（OMG UML），基础结构，版本2.4.1”），它专门用于定义建模语言。刻板印象生活在这个水平，而不是在M1或M0。换句话说，构造型是专门用于定义新的建模语言而不是用于定义新的领域模型的构造。

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

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

Answer 6

通过指定例如，构造型扩展了UML元模型的结构。 UML模型中元素的特定于域的属性，并且不会改变正在建模的系统的运行时语义 - 它们只会丰富建模语言。

这方面的好例子是在设计模式图中为类赋予“角色”。类的功能在类中给出，而不是由构造型添加 - 这支持上述语句。

现在，棘手的部分是继承或定型类;根据UML 1.3，它们不是可继承的;然而，“A”通过某些刻板印象给予类的约束也适用于专门的类。在我看来，这仍然不适用于运行时，因此语义层面上仍然存在歧义。更多信息this mail thread。

Answer 7

根据 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工具可以自动定义一个＆＃34; unattached＆＃34;属性（标记值）将被附加。

标记值可以在构造型名称下的类隔间中显示。每个应用的构造型都需要一个额外的隔间，其值将被显示。每个这样的隔间都以guillemets中所应用的刻板印象的名称为首。

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

这是摘要：

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

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

7 个答案: