UML关联与组合和细节级别

Question

实际上，制作一些业余的UML问题！在创建UML图表来模拟某些域概念时，您会遇到一个域概念，即＃34;持有＆＃34;关于另一个概念的一些信息，是否更好地持有该实体的印章/引用或将整个实体保留在模型本身中？请记住，这与创建一个简单的高级模型有关 - 我确信在实现阶段，情况会略有不同。

例如，下面两个模型中的哪一个实际上是正确的？第一个有一个组合关系，FlightBooking持有整个Flight。在第二个中，FlightBooking只是对Flight的引用。

其次，在创建高级UML图建模领域概念时，您真正想要了解多少细节？例如，在下图中，航班可以将有关原点/目的地的详细信息保存为字符串，或者我可以为这些概念建模单独的类并创建组合关系。哪两个是可取的？

另外，另一件事是，在对上面的飞行＆＃34;持有＆＃34;作为另一个类而不是字符串的orig / destination，这两种方式中的哪一种是正确的建模方式？我很困惑何时展示协同作用以及何时展示作文。

Answer 1

协会：
这意味着两个班级有某种关系，可能是真的 例如：A使用B，A以给定方式与B相关。

成分：
这也是一种用于建模“所有权”的特殊关联类型。这与聚合非常相似，唯一的区别在于它描绘了整体关系，而“部分”实体没有自己的独立存在

例如：A由B组成; B是A的一部分，因此没有A就不存在。

好的解释：UML Class Diagram: Association, Aggregation and Composition

Answer 2

对不起，如果这有点长......

如果您正在尝试对域概念进行建模，那么我建议您忘记组合/聚合并坚持使用简单的关联。为什么？因为决定组合/聚合会妨碍重要问题。他们是：

1. 为什么关系存在？具体来说，它捕获了哪些域规则/约束？
2. 两端的基数是什么？
3. 什么是创造＆amp;删除行为？即谁创建/删除该关联的实例？

关系命名您可以通过命名rel结束来完成（1）。不使用角色名称（例如第一个示例中的“Flights”），因为它不会告诉您关于为什么存在关系的信息。所以在你的例子1中：这种关系代表什么？它是飞机上的预留座位吗？一个确认的？支付？无法从图中看出它的立场。基于动词的命名有多种方法，参见例如this post。为什么这样？因为它会提示您确保了解域。关系中存在很大比例（可能是大多数，尽管我从未证明过）域规则。因此，理解关系存在的原因是理解领域的基础。

基数可能比命名更明显。你应该在两端确定 - 包括上限和下限。在下端重要的是它是否是可选的（即0或1）。在上端，1或多个。这再次表明了域中的重要规则。回到你的例子：航班预订中有多少航班？一次飞行可以进行多次预订吗？ （无论'在'意思是......）。

创建/删除行为谁创建了关系实例？谁删了？如果一端被删除，另一端会发生什么？同样，来自问题域的所有重要规则。

那些希望也回答你的第二个问题。不要吝啬关系。花点时间了解它们。它们是了解域名的秘诀。回答上面提到的所有问题，比在组合/聚合/关联中做出更多决定会给你更多的洞察力。

如果您确实想要显示合成与关联，但如果您回答上述问题则它是机械的：

1. 如果关系一端的基数是1：1（即只能是一个），和
2. 同一端负责创建和删除另一端的实例，那么
3. 可以显示为合成。

否则使用简单的关联。至于聚合：忽略它。从词汇表中删除它。造成更多混乱而不是它的价值。通过聚合，您可以说出的所有内容都可以通过正确定义的简单关联更加清晰准确地说出来。

第h

PS：语法点：Composition使用填充的钻石。你所展示的是聚合。

Answer 3

成分，聚合和关联。

• 在其他事情之前，您应该了解A到B的关联是什么。
  • 基本上它是A和B之间的实线。它可以表示一个结构，它将A的类/实例与B的类/实例连接起来。结构可以是任何类型，属于任何地方。所有关于该行的信息都描述了这种结构。
  • 如果有两个结构，一个结构连接A的一个实例和B的实例，另一个结构连接B的实例和A的实例，则可以在一个关联中显示它们。然后，关于其B端写入的信息描述第一结构（b-> a），关于另一端的信息描述另一结构。
  • 如果您有多个结构从A到B引导，则必须绘制两个不同的关联。
  • 如果连接结构很复杂，您可以将其表示为关联类。在那里你可以定义更多细节。
  • 连接结构可以连接两个以上的类，然后它将显示为一个大的菱形，并且具有到这些类的实心分支。它还是联想！注意：现有工具非常支持这两个更复杂的关联。您可以轻松地创建一些绝对无意义的东西。他们很难。小心使用。
• 在C ++实例中，A可以使B实例不是指针，而是直接。没有特殊的UML符号，它应该以与普通的指针属性相同的方式显示。

---

---

• 组合物由所谓的黑色或全钻石显示。它位于容器的一侧。
• 另一个，空白钻石，被称为“共享聚合”，或者，很快，“共享”。它没有严格定义，您可以使用它创建自己的标准。当然，将它放在项目 - 容器关联的项目方面是愚蠢的。但它很容易在关联的两端。
  • 为什么组合钻石只能在一边？因为组合意味着，只有在容器（或容器本身）存在引用它们时才存在这些项目。当然，这对双方都不利。
  • 相反，双方的'共享'往往是有道理的。例如，学生实例可以包含所有参加课程的列表，课程实例可以包含所有参加课程的学生列表。
• 通常，您可以看到用于“共享聚合”的名称“聚合”。这是一个不好的错误。因为，根据标准composition，shared甚至none，所有三个都是聚合。

所以， composition 是聚合的一个子集 和 聚合是<的一个特征kbd> association

Answer 4

对于您的第一个示例，第一个图表（包含合成）是正确的。你的第二个选项，将flightID称为int，可以工作，但它不完整：int本身并没有为你提供访问Flight对象的方法。 Flight类不会神奇地存储您可以按编号检索的航班对象列表，因此第二个选项需要某个第三个类来存储所有Flight对象。

对于你的第二个问题，在高层次上它实际上取决于个人偏好（或你教授的个人偏好！）。试着用你最好的判断。