如何在UML类图中建模非成员聚合

Posted 2021-03-28

在下面的UML图中，Account有一个Orders聚合。基于大多数在线资源，这通常意味着Account类具有类似于List的实例。

但实际上，对于具有持久存储的真实世界Web应用程序，通常不是帐户类的方式。它不会将订单列表作为实例。相反，其他一些控制器类只会查询数据存储区，询问属于某个帐户的所有订单。所以在这种应用程序的UML类图中，这仍然是表示关系的正确方法吗？从数据库实体的角度来看，基数和聚合的概念是正确的。只是钻石从阶级角度来看没有任何意义。

或者它应该使用getOrdersForAccount（）方法显示DataStore / DataManager并通过依赖关系（带箭头的虚线）将其连接到Account类和Orders类？

答案

这取决于您想要表达的内容。

您已经足够的类模型作为逻辑域模型，表示域中实体之间的逻辑关系。这可能不是您如何精确地在代码中实现您的软件，但它将指导您（和其他人）理解实体及其关系，而不会陷入该实现细节中。在这个级别，您的图表可能有一些设计选择（例如，强聚合可以说是设计选择，但它可能不是，使用枚举和键），但不是那么多，没有任何真正减损底层逻辑。如果有的话，你可以在这里放弃一些设计选择并改进逻辑的表达。

您可能还需要提供一个表示OO代码如何在物理上实现的表示。这将是一个额外的类图，更准确地显示了实现细节。您将在此图表中有更多的设计选择 - 是否对订单使用集合（例如列表或其他集合类型类），您的数据访问模式是什么（适配器，管理器，ORM等）。在这个级别，你很可能会松开强聚合符号，因为在这个级别我们讨论的是彼此引用的类，这些类最简单地用基本关联表示。您可能希望使用箭头和/或点符号来指示结束所有权和参考方向，以便更清楚地了解类之间的关系。

所以，我认为你的问题是关于模型和分析与设计中抽象层次的经典问题。谢谢你的问候！

另一答案

聚合只是意味着：“如果删除帐户，您还需要删除订单”。

我还建议将聚合保留（大多数情况下），因为它只会给模型增加一些额外的语义。在这种情况下，删除帐户时删除订单似乎很明显。聚合在这里添加的唯一内容是（在大多数情况下）一些混乱或关于钻石价值的一些徒劳的讨论。

如果您有一个填充钻石的域，则应在建模规则中记录。当使用共享聚合时，文档甚至是强制性的，因为规范中没有语义（参见UML 2.5的第110页的框）。

另一答案

这取决于你想要用UML设计的深度。

如果您从UML定位代码生成，那么您可能需要添加您提到的类。它看起来很像Registry Pattern：UML Diagram

• 您可以添加抽象，以便可以更改DataManager的实现（如果您的DataManager是第三方，那么只需从DataManagerImplementation调用API）。
• 之后，根据您的实现，一旦您有了列表，如果您需要保留它，然后添加关联Account -> Order，如果您可以使用堆栈上的列表，那么您很高兴。

C ++ instanciation示例：

DataManagerImplementation *db = new DataManagerImplementation();
// Dependency injection
Account *acc = new Account(db);

然后在“帐户”类中：

Account::Account(DataManager *db)
{
  // Fetch list at creation
  // Here 'orders' could be a member
  m_db = db;
  vector<Order*> *orders = m_db->GetOrders(this);
}

PS：我还建议在关联/聚合上放置箭头（方向），否则它意味着关联是双向的，因此该帐户具有指向订单列表的指针，并且每个订单也有指向帐户的指针，并且我不确定这是否需要。

要编辑PlantUML：http://www.plantuml.com/plantuml/png/SoWkIImgAStDuN99B4dqJSnBJ4yjyimjo4dDJSqhIIp9pCzJqDMjiLFmBqf9BK9ImuKk05Hcfw2afGHHYIbjfL2McboINsG3bj6oKz1oJoq1iuir79EJyqlpIZIve0m5a566IfYMEgJcfG0T2m00