Question

我有一个关于在UML图中指示多重性的问题。

我有一个SpriteObject类，它有一个动画列表。 SpriteObject可以有0 .. *动画。所有动画都在SpriteObject中创建，并且不存在。

我不是100％确定我应该如何用多重性表明这一点。搜索网络后，我找到了以下3个选项：

选项1：多重性应该像这样表示，因为每个SpriteObject都有0个或更多个动画。由于动画没有关于SpriteObject存在的线索，因此在SpriteObject的一侧没有指示多重性。 enter image description here

选项2：应该在这两侧指示多重性，因为我们需要指出两个类之间的局部关系，因此1个SpriteObject具有0个或更多个动画。 enter image description here

选项3：双方都应该表示多样性，因为我们需要能够阅读多重性并将其理解为整体（游戏）的一部分。游戏可以包含0 .. * SpriteObjects，SpriteObject可以包含0 .. *动画。这就是为什么0 .. * SpriteObjects有0 .. *动画 enter image description here 谁能告诉我哪个选项是正确的？（如果有的话）

Answer 1

[编辑]

应该是选项1.这是composition relationship

这意味着SpriteObject包含并管理Animation对象的生命周期。

作为一个例子。

public class SpriteObject : IDispose
{
  private List<Animation> animations;

  // constructor
  public SpriteObject()
  {
    animations = new List<Animations>();

    // initialise the list
  }

  public ovveride Dispose()
  {
    // clear list
  }
}

如果这是一种聚合关系。

enter image description here

注意符号，空心钻石。这是aggregagtion relationsip。这意味着实例SpriteObject可以有零个或多个Animation实例，但Animation对象的生命周期不依赖于SpriteObject的生命周期。

C＃代码示例如下：

public class SpriteObject
{
  private List<Animation> animations;

  // constructor
  public SpriteObject(List<Animation> animations)
  {
    this.animations = animations;
  }
}

Answer 2

对于多重性部分 - 如果在任何地方省略多重性信息（组合，聚合，关联结束，属性，部分...），根据UML规范，这意味着 - 你没有＆＃ 39;提供信息，它是未知的或不相关的。

您可以选择为模型提供默认值（UML语言规范本身并未指定用户模型的默认多重性值）。大多数UML用户选择的默认值只有一个[1]，但我已经看到了其他选择的默认值，如[0 .. *]。没有正式的方法来为UML模型定义多重性的默认值，您必须以其他方式告知读者您的模型（介绍性文本段落，注释等）。

如果您遇到的模型没有提供此信息，最安全的假设是默认多重性设置为[1]。

从这个角度来看，我认为案例1和案例2是相同的。

对于组合部分 - 组合关系的语义，根据UML规范，如下：＆＃34; composite：表示属性是复合聚合的，即复合对象有责任对于组合对象的存在和存储（参见11.2.3中部分的定义）。＆＃34;） - 因此该规则适用于对象，而不是类。

确实，所有组合对象都必须遵守此规则，但这并不一定意味着所有动画对象都必须以精灵组成。你可以在你的介绍初始屏幕上有一个动画，它不属于任何精灵。另一方面，组合对象（部分）确实不能同时在几个组合对象（整体）中组合。

因此，可能的情况是：

组合的Sprite端的多重性0..1 - 这意味着某些动画是精灵的一部分。这些动画和它们的生命由这些精灵管理。除此之外，系统中可能还有其他与精灵无关的动画。
精确为1的多重性（显式设置，如情况2中的情况，或者默认情况下，可能是情况1） - 这意味着动画的所有实例都必须是某些精灵的一部分。
其他多重性情况，上限大于1 - 因为我无法共享组合部分，组合语义禁止我每个动画都有多个精灵实例。

最后可能会有一些主题评论：

将多重性设置为，在组合的精灵末端设置0 .. *仍然会产生有效的UML（从抽象语法角度来看）。它没有多大意义，读者可能会犯某种错误，但是当你想到它时，你可以制作一个尊重所有结构和语义约束的实例模型，只需要＃34;不要使用＆＃34;每个动画有多个精灵的可能性。它就像是说你希望某个数字同时大于0和10。它并没有错，只是它可以用更简单，更容易理解的方式指定。

Answer 3

我会直接拒绝选项3，因为你提到Animation实例本身不存在，我会非常惊讶同一个实例可能与几个SpriteObject实例有关。

下一个问题是Animation个实例是否引用了其SpriteObject所有者？如果没有，你选择了选项1。

Answer 4

第三个不正确。这一行的写作是关于一个关系的一个实例（这次是关联）。您正在描述其功能。为了更好的感觉，你最好把它命名。例如，将animationList放在连接的右侧。这意味着，每个animationList都连接到一个spriteObject（通过归属，最有可能），以及许多动画（它们更像是列表中的项目）。
第一个变种也不同。它没有定义左侧的多重性。所以，它可能意味着你想要的东西，但它可能意味着别的东西，你不是故意的。如果您还没有决定该关联不是列表结构，而是更复杂的，可以连接到几个或零个spriteObjects，那么就可以了。

你在所有三张图片中也有一个错误 - 如果有一些从精灵到动画的函数参考，反之亦然，你必须在右侧放一个箭头。

如果您已确定连接实际上是spriteObject的属性，则可以通过在右箭头和右类之间放置DOT来更精确地显示它。通过为关联的右端设置classifier's owning，可以在大多数工具中设置它。

将多重性置于最后是一个非常好的想法。而且不仅仅是他们。您将更多信息放在聚合上：名称，箭头，点，可见性，您对自己模型的了解越多，您就会发现更多机会出现问题。

顺便说一句，当你的两侧没有箭头时（它与两个箭头上的箭头相同），它可以显示两种不同的变体：一种是知道两侧的实例，或者（更常见的）同时有两种情况 - 两个不同类的两个不同实例的两个不同属性 - 一端是从右到左的参考，另一端是从左到右的参考。那些点变得非常必要。

UML组合多样性

4 个答案: