域模型 Class 图中的关联 class 属性
Association class attributes in Domain Model Class Diagram
嗨，我最近开始学习系统分析和设计，但在理解域模型 class 图 (DMCD) 关联 class 时遇到了一些困难。
根据图像，在绘制 DMCD 时，我想了解是否允许关联 class 包含它派生的 classes 的属性。发票需要包含属性 apptNo 和 svcName。
协会class询价图片：
我是否包含图中所示的属性？
或者我是否假设发票已经具有这些属性，因为它是从约会和服务派生的，并且没有必要包括它们，因为它们可以返回到键 apptNo 和 svcID？
我对这个概念感到困惑。我应该如何呈现关联class？
有人可以提供一些指导吗？
谢谢。
视情况而定。
domain modelclass 图表对领域中的概念进行建模，即与您的项目相关的现实世界的一部分。在 classes 中，您仅包括由领域专家或描述该领域的其他来源指出的属性。
我假设领域专家知道预约号码和服务名称是什么。如果这些只是技术数据，那么它们本来就不应该是预约和服务的属性。要确定这些属性是否也应包含在 Invoice 中，您需要询问领域专家他们的想法。发票是否总是包含预约号码和服务名称？只有领域专家说 "Yes"，我才会将它们建模为 Invoice 的属性。
（要仔细检查，你可以问"Is it also valid to say that the appointment number is not part of the invoice, but that the invoice is somehow associated with an appointment having a particular appointment number?"）
也许领域专家说发票不包含预约号或服务名称，因为相应的预约和服务始终作为附件或超链接或其他方式与发票相关联。在这种情况下，Invoice 是 Appointment 和 Service 之间关联的关联 class 就足够了。您不必在发票中包含这些 class 的属性。当域模型 class 图变成系统模型 class 图或数据库模型 class 图时，这些可能会在以后添加。
正如 Geert Bellekens 在他上面的评论中所指出的，您不会在关联 class 中重复关联 class 中涉及的 classes 的任何属性 class.您只包括专门描述由关联 class 定义的链接 class 的属性。
在您的示例中，您应该只包含特定于发票链接的属性，例如 invNo、invDate 和 totalPrice。
此规则独立于 class 图（domain/design/implementation 模型）的种类。
但是，您的模型仅适用于涉及一次约会和一项服务的发票。它不考虑一次约会的发票，无论它包括多少服务。在此业务逻辑的模型中，Invoice 将不再是关联 class，而是与 Appointment 关联的普通 class。这将允许它访问预约中包含的每项服务并将其转换为发票行。
简而言之：
是（有点；请阅读下面的评论）
的另一种表示法
这意味着 Class3 已经与 Class1 和 Class2 都有关联。所以在关联 class 中添加后者的属性是没有意义的。如果您处于数据库级别，您最终会出于性能原因引入冗余，但代价是违反单一真实来源原则。但那是另外一回事了。
嗨，我最近开始学习系统分析和设计，但在理解域模型 class 图 (DMCD) 关联 class 时遇到了一些困难。
根据图像，在绘制 DMCD 时，我想了解是否允许关联 class 包含它派生的 classes 的属性。发票需要包含属性 apptNo 和 svcName。
协会class询价图片：
我是否包含图中所示的属性？ 或者我是否假设发票已经具有这些属性，因为它是从约会和服务派生的，并且没有必要包括它们，因为它们可以返回到键 apptNo 和 svcID？
我对这个概念感到困惑。我应该如何呈现关联class？ 有人可以提供一些指导吗？
谢谢。
视情况而定。
domain modelclass 图表对领域中的概念进行建模，即与您的项目相关的现实世界的一部分。在 classes 中，您仅包括由领域专家或描述该领域的其他来源指出的属性。
我假设领域专家知道预约号码和服务名称是什么。如果这些只是技术数据，那么它们本来就不应该是预约和服务的属性。要确定这些属性是否也应包含在 Invoice 中，您需要询问领域专家他们的想法。发票是否总是包含预约号码和服务名称？只有领域专家说 "Yes"，我才会将它们建模为 Invoice 的属性。
（要仔细检查，你可以问"Is it also valid to say that the appointment number is not part of the invoice, but that the invoice is somehow associated with an appointment having a particular appointment number?"）
也许领域专家说发票不包含预约号或服务名称，因为相应的预约和服务始终作为附件或超链接或其他方式与发票相关联。在这种情况下，Invoice 是 Appointment 和 Service 之间关联的关联 class 就足够了。您不必在发票中包含这些 class 的属性。当域模型 class 图变成系统模型 class 图或数据库模型 class 图时，这些可能会在以后添加。
正如 Geert Bellekens 在他上面的评论中所指出的，您不会在关联 class 中重复关联 class 中涉及的 classes 的任何属性 class.您只包括专门描述由关联 class 定义的链接 class 的属性。
在您的示例中，您应该只包含特定于发票链接的属性，例如 invNo、invDate 和 totalPrice。
此规则独立于 class 图（domain/design/implementation 模型）的种类。
但是，您的模型仅适用于涉及一次约会和一项服务的发票。它不考虑一次约会的发票，无论它包括多少服务。在此业务逻辑的模型中，Invoice 将不再是关联 class，而是与 Appointment 关联的普通 class。这将允许它访问预约中包含的每项服务并将其转换为发票行。
简而言之：
是（有点；请阅读下面的评论）
的另一种表示法这意味着 Class3 已经与 Class1 和 Class2 都有关联。所以在关联 class 中添加后者的属性是没有意义的。如果您处于数据库级别，您最终会出于性能原因引入冗余，但代价是违反单一真实来源原则。但那是另外一回事了。