域模型类图中的关联类属性

Question

嗨，我最近开始学习系统分析和设计，并且在理解域模型类图（DMCD）关联类时遇到了一些麻烦。

根据图像，在绘制DMCD时，我想了解是否允许关联类包含其派生类的属性。发票需要包含属性apptNo和svcName。

协会班级查询图像：

我是否包含图片所示的属性？ 还是我假设发票已经具有这些属性，因为它是从约会和服务派生的，并且没有必要包含它们，因为可以将其返回给键apptNo和svcID？

我对这个概念感到困惑。我应该如何介绍联想班？ 有人可以提供一些指导吗？

谢谢。

Answer 1

正如Geert Bellekens在上面的评论中已经指出的那样，您不会在关联类中重复关联类中涉及的类的任何属性。您仅包含专门描述按关联类分类的链接的属性。

在您的示例中，您应仅包括特定于发票链接的属性，例如invNo，invDate和totalPrice。

该规则独立于类图（域/设计/实现模型）的类型。

但是，您的模型仅适合于引用一项约会和一项服务的发票。它不考虑有关一项约会的发票，无论它包含多少服务。在用于此业务逻辑的模型中，Invoice将不再是关联类，而是与Appointment关联的普通类。这样一来，它便可以访问约会中包含的每个服务，并将其转换为发票行。

Answer 2

要视情况而定。

domain model类图对领域中找到的概念进行建模，即与您的项目相关的现实世界的一部分。在这些类中，您仅包含域专家或描述域的其他来源指示的属性。

我将假定域专家知道约会号码和服务名称是什么。如果这些只是技术数据，那么它们首先不应该是约会和服务的属性。要确定这些属性是否也应包含在发票中，您需要询问域专家他们的想法。发票是否总是包含约会编号和服务名称？仅当域专家说“是”时，我才会将它们建模为“发票”的属性。

（要进行仔细检查，您可以问“约会编号不是发票的一部分，但是发票与某种具有特定约会编号的约会相关联吗？”

域专家可能说发票不包含约会编号或服务名称，因为相应的约会和服务始终以附件或超链接或其他方式与发票相关联。在那种情况下，发票是约会和服务之间的关联的关联类这一事实就足够了。您不必在发票中包含这些类的属性。当域模型类图转换为系统模型类图或数据库模型类图时，这些可能会在以后添加。

Answer 3

简而言之：

是（替代；请阅读下面的评论）

的替代表示法

，这意味着Class3已经与Class1和Class2都有关联。因此，没有必要在关联类中添加后者的属性。如果您是数据库级别的用户，出于性能原因，最终会引入冗余，但代价是违反单一事实来源的原则。但这是另一个故事。