UML域模型 - 如何建模两个实体之间关联的多个角色？

Question

假设存在用户具有任务的情况。每个用户可以是任务的观察者或工作者。

此外，工作人员可以提交他在给定任务上工作的时间。

以下图表是否正确？我已经浏览过域模型，但我还没有看到有两个关联（作品，手表）。可以接受吗？

编辑：这种情况怎么样？用户可以向另一个用户提出要约。可能的建模方法如下图所示。

然而，在该图中，用户似乎可以向自己提出要约。是否有可能对某些约束进行建模，或者是否在开发线下进一步处理？

Answer 1

原则上这是正确的，这就是你如何模拟两个类之间的多个关系。

对于约束，UML使用OCL（对象约束语言），因此可以说关联是独占的（xor - exclusive或）。

另请注意，通常最好指定关联的最终角色。

关于其中一条评论说

  

没有UML警察会因为“＃34;不可接受的”而标记你。

这就像是说：没有代码警察会因为编写糟糕的代码而拒绝你。

您创建图表来传达信息（无论如何为学校项目），如果您偏离标准或最佳实践，则会让其他人更难理解您的图表。

就像有针对常见问题检查代码的linters（jslint，...）一样，对于模型，有模型验证可以做同样的事情。

同样的模型，就像代码一样，并不是一成不变的，所以当你找到更好的方式来表达自己的域名时，不要害怕修改它们。

更新

正如吉姆恰当地指出的那样，你通常做的不是用户（或人），而是角色。例如。当你是学生并填写表格时，没有人关心你是人，但你是学生。通常，一个人也会有几个不同的角色（你可以是学生和TA，教授等）。

以这种方式分隔它会使域更清晰，因为您只关心角色，而不是实现它们的人。

Answer 2

在第一个模型上，在Peter出色且非常有趣的答案之后，没有太多要补充的内容。

然而，你的第二张图（在编辑部分）似乎确实给出了真实和公平的对比。从严格的1对1关系，我明白每个用户只向另一个用户提供一个优惠，每个用户只收到另一个用户的一个优惠：

• “用户可以向其他用户提供”意味着基数为0..1或*，而不是1.
• 由此我们隐含地理解并非所有用户都需要收到报价，即基数为0..1或*
• 这可以辩论，但“ 商品”在我看来并不意味着“最多一个优惠“，因此基数的上限不应该是*而不是1，以表明每个用户可以提出多个优惠并收到多个优惠。

如您所见，您可以将constraints添加到架构中以提高表达能力。这是在{ }之间的注释中完成的。但是您可以选择最合适的语法。这里有一个充满自然语言表达能力的例子（正如Martin Fowler在他的“ UML精简”中所建议的那样）但你当然可以使用更正式的OCL，使它成为{{1 }}。

Answer 3

我发现@Peter在我发布这个答案之前更新了他的答案，但无论如何我会发布这个以向你展示其他一些技巧。

通常，在相同的两个类之间存在多个关联是完全有效的。但是，我认为这不是一个好主意。

你说你想构建一个[问题]域模型。我很高兴听到这个消息！问题域模型非常重要，正如我在上一段here中解释的那样。需要指出的一点是，您希望构建一个超越您可以构思的系统的持久模型。在问题域中，没有“用户”。然而，人们会扮演角色。例如，你提到了Watcher和Worker。希望这些是您的客户在“肉类世界”中已有的概念。

在您发布的模型中，您无法挂起工作时间或进度。你可以尝试一下练习。如果您没有计算机，您的客户将如何跟踪这些内容？他们经常拥有（或拥有）一种方式，对于手动系统而言，这可能是非常理想的。

以下是我对您的问题域的理解模型：

有些注意事项：

• 一个人扮演任意数量的角色。
• 角色仅涉及一个任务和一个人。 Watcher只监视一个任务，一个工作人员只分配一个任务，任何类型的角色只由一个人扮演。
• 一个角色是抽象的，它的子类是{complete}，这意味着没有一个有效的Role实例，也不是一个子类的实例。
• 任务由任意数量的观察者观看，并且可以一次分配给一个工作者。有一个限制说{人不是观察者}。 （你可以为此展示OCL，但很少有人会理解它。）
• 我添加了一个Progress概念作为记录任务进度的方法。一名工人在一项任务上取得进展。 Progress的每个位都有Description和Duration。请注意，我没有承诺任何表示描述或持续时间的计算方式。系统的设计者可以从开始和结束时间自由地获取持续时间，或者要求用户自我报告。