【发布时间】：2019-12-18 15:26:29
【问题描述】：
我们被分配了一个任务，我们要在其中创建一个由文本文档描述的概念模型。文档中给出了许多约束，但我们也被指示不要在模型中使用约束。
我们已经能够解决一些限制，但有一个我们无法解决。我编造了一个场景，与我们遇到问题的任务部分有些相似。
您的任务是创建游戏工作室结构的模型。公司由多个部门组成，每个部门至少有一名员工。每个员工都在一个部门工作。员工分为三种不同类型：开发人员、设计师和工程师。
除此之外，员工还可以担任许多领导角色：部门主管、部门副主管、首席技术官或首席执行官（是的，首席技术官和首席执行官是普通员工的角色）。每个部门必须有 1 名部门主管和至少 1 名副主管。
除此之外，只能有一名 CTO 和一名 CEO，而且这些角色只能由工程师担任。每个员工只能担任一个领导角色。
为了解决这个问题，我们制作了一个额外的抽象实体：BasicRole。该实体是LeadershipRole 的特化，是任何员工可以担任的三个角色的泛化。这解决了其中一个问题，现在我们可以简单地在 Designer/Developer 和 BasicRole
之间创建适当的关联但是，除了与 CEO 和 CTO 的关联之外，我们还希望 Engineer 与 BasicRole 有关联。添加这些关联会生成一个如下所示的概念模型：
但是，这是有问题的，因为现在我们说工程师可以拥有 0 到 3 个角色。
我们考虑过将公司作为一个实体包括在内，并在公司和 CTO/CEO 之间添加关联，以指定公司只能拥有一个，但我们在本课程中一再被告知不要将我们作为实体建模的事物包含在模型中。
现在，似乎我们所有的问题都可以通过约束来解决（如果我们继续阅读这些），对三个关联进行某种异或。然而，鉴于我们被指示不要在概念模型中使用约束，我们不知所措。
【问题讨论】：
-
{disjoint}泛化没有意义，是吗？ -
@qwerty_so 啊，感谢您指出这一点。对 UML 来说还是相当新的。我假设您的意思是最右边的 {disjoint} 应该是 {overlapping} 因为如果某些员工具有 HeadOfDepartment 角色，他们在技术上也有一个 BasicRole （因为 HeadOfDepartment is a 基本角色）？ LowerRole 的特化的 {disjoint} 仍然有意义，对吧？
-
如果您不想使用约束，我认为您别无选择，只能将
Company添加为一个类。我看到有些人使用构造型 «singleton» 来表示只能存在一个类的一个实例，但是 UML 标准中没有定义该构造型。 -
对于初学者来说，您正在涉足我从未尝试过的领域：泛化集。无论如何，看起来您需要指定
{complete, disjoint}才能正式正确。 UML 2.5 的第 120 页
标签： constraints uml conceptual-model