领域模型类图中的关联类属性答案

【问题标题】：Association class attributes in Domain Model Class Diagram领域模型类图中的关联类属性
【发布时间】：2019-10-09 01:10:05
【问题描述】：

您好，我最近开始学习系统分析和设计，但在理解领域模型类图 (DMCD) 关联类时遇到了一些麻烦。

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

关联类查询图片：

我是否包含图片中显示的属性？或者我是否假设 Invoice 已经具有这些属性，因为它是从 Appointment 和 Service 派生的，并且没有必要包含它们，因为它们可以引用回键 apptNo 和 svcID？

我对这个概念感到困惑。我应该如何呈现关联类？有人可以提供一些指导吗？

谢谢。

【问题讨论】：

不，不需要复制关联类中的id字段。您正在制作 UML 类图，而不是数据库图。
谢谢先生的解释。这是否也适用于与生成关联类相关的类中的任何非键属性 (svcName)？它们也不应该在关联类中吗？
也许你应该考虑一下。你会把发票号码之类的东西放在哪里？
嗯...我会将发票编号保留在发票类中，但它不再是关联类。相反，我会从 Appointment 和 Service 创建一个名为ointmentService 的关联类，并将其链接到 Invoice，假设一张发票可以有多个约会服务，但一个约会服务必须属于一张发票。我不确定是否应该这样做，请指教。谢谢。
似乎您可能希望将 invoice 设为普通类，并在 invoice 和 Appointment 之间创建链接。从预约开始，您可以进一步导航到服务，因此无需直接链接。如果每次约会只有一张发票，那可能是一个很好的模型。

标签： class uml associations diagram system-analysis

【解决方案1】：

正如 Geert Bellekens 在上面的评论中已经指出的那样，您不会在关联类中重复关联类中涉及的类的任何属性。您只包括专门表征由关联类分类的链接的属性。

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

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

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

【讨论】：

感谢您的友好解释。这也适用于非关键属性？
是的，关联类的实例也是一个“链接”或关系，这意味着它具有对参与链接的两个对象的引用，这反过来意味着它具有访问权限到它们的所有属性/属性。因此，重复它们是没有意义的。
您好先生，如果我解释您的解释，这意味着即使服务名称需要在类 Invoice 中显示，但是因为 Invoice 可以通过类 Service 访问属性服务名称，不需要在发票中包含服务名称作为属性吗？
是的，在您的示例中，您应该只包含特定于 Invoice 链接的属性，例如 invNo、invDate 和 totalPrice。但我将添加一些关于建模涉及一项预约和多项服务的发票的建议。
感谢您的建议。我现在有了更清晰的画面。

【解决方案2】：

简而言之：

是（有点；请阅读下面的 cmets）的替代符号

这意味着Class3 已经与Class1 和Class2 有关联。所以在关联类中添加后者的属性是没有意义的。如果您处于数据库级别，您最终会出于性能原因引入冗余，但会以违反单一事实来源原则为代价。但那是另一回事了。

【讨论】：

您好，感谢您的回答。我知道在数据库设计中，与原始实体相关的非键属性也不会添加到关联实体中，因为它们可以使用外键引用回来，外键顺便说一句是原始实体的主要属性。在 SQL 中，这意味着在 FK 上连接，然后分区到所需的视图。我想知道的是，该规则是否也适用于 DMCD 中可以在原始类中找到的关联类的非关键属性？
你的答案很明确。只是一个小评论：第二张图并不完全是第一张图的简写。在第一个图中，Class3 的每个实例都代表 Class1 实例和 Class2 实例的唯一组合。在第二张图中，可能有多个 Class3 实例与同一对 Class1 和 Class2 实例相关联。
@qwerty_so：您的图表的两种模式通常不等效，但仅在 Class3 表示关系类型并且您（1）向下图中的链接组合或 (2) 在上图中的两个关联端添加 non-unique 注释。记住：意义很重要！
@www.admiralalit.nl 谢谢，我会更新我的答案以使其更清楚。我是在飞行中做的（经常这样）。
@GerdWagner 确实如此。我以前在哪里听到的？请参阅我上面的评论。

【解决方案3】：

视情况而定。

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

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

（要仔细检查，您可以问“是否可以说预约号码不是发票的一部分，但发票以某种方式与具有特定预约号码的预约相关联？”）

也许领域专家说发票不包含约会号码或服务名称，因为相应的约会和服务总是以附件或超链接或其他方式与发票相关联。在这种情况下，Invoice 是 Appointment 和 Service 关联上的关联类就足够了。您不必在 Invoice 中包含这些类的属性。这些可能会在稍后将领域模型类图转换为系统模型类图或数据库模型类图时添加。

【讨论】：

谢谢先生的解释。如果必须在关联类 Invoice 中具有属性 svcName，这是否意味着我必须将它包含在 Invoice 中，即使它是类 Service 的非关键属性？
是的，键和非键的区别并不重要。在我的回答中，我会将“服务 ID”替换为“服务名称”。
谢谢您的建议先生。当我将来查看需求时，我会牢记这一点。