嗨，我最近开始学习系统分析和设计，但在理解领域模型类图 (DMCD) 关联类时遇到了一些麻烦。
根据图像，在绘制 DMCD 时，我想了解是否允许关联类包含它派生的类的属性。发票需要包含属性 apptNo 和 svcName。
协会班级查询图片：
我是否包括图像中显示的属性？或者我是否假设 Invoice 已经具有这些属性，因为它是从 Appointment 和 Service 派生的，并且没有必要包含它们，因为它们可以引用回键 apptNo 和 svcID？
我对这个概念感到困惑。我应该如何呈现关联类？有人可以提供一些指导吗？
谢谢你。
正如 Geert Bellekens 在上面的评论中已经指出的那样，您不会在关联类中重复关联类中涉及的类的任何属性。您只包括专门表征由关联类分类的链接的属性。
invNo在您的示例中，您应该只包含特定于发票链接的属性，例如invDate和totalPrice。
该规则独立于类图的类型（领域/设计/实现模型）。
但是，您的模型仅适用于涉及一项预约和一项服务的发票。它不考虑与一次约会有关的发票，无论它包含多少服务。在此业务逻辑的模型中，Invoice将不再是关联类，而是与Appointment. 这将允许它访问约会中包含的每项服务并将其转换为发票行。
这取决于。
领域模型类图对领域中的概念进行建模，即与您的项目相关的现实世界的一部分。在类中，您只包括由领域专家或描述该领域的其他来源指出的属性。
我假设领域专家知道预约号码和服务名称是什么。如果这些只是技术数据，那么它们首先不应该是 Appointment 和 Service 的属性。要确定这些属性是否也应包含在 Invoice 中，您需要询问领域专家他们的想法。发票是否总是包含预约号码和服务名称？只有当领域专家说“是”时，我才会将它们建模为 Invoice 的属性。
（要仔细检查，您可以问“是否可以说预约号码不是发票的一部分，但发票与具有特定预约号码的预约有某种关联？”）
也许领域专家说发票不包含约会号码或服务名称，因为相应的约会和服务总是以附件或超链接或其他方式与发票相关联。在这种情况下，Invoice 是 Appointment 和 Service 关联上的关联类就足够了。您不必在 Invoice 中包含这些类的属性。这些可能会在稍后将域模型类图转换为系统模型类图或数据库模型类图时添加。
简而言之：
是（有点；请阅读下面的评论）的替代符号
这意味着Class3已经与Class1和有关联Class2。所以在关联类中添加后者的属性是没有意义的。如果您处于数据库级别，您最终会出于性能原因引入冗余，但会以违反单一事实来源原则为代价。但那是另一回事了。