这个UML类图正确吗？

Question

我一直在努力使我的系统进入类图。 我倾向于在数据库结构中考虑太多而犯错。 我有一个类图：

因此，为了解释这种情况，我需要：

员工部分：

• 可以在一个项目阶段将一个员工分配给0个或多个项目

项目部分：

• 项目是某种类型的（如果项目是HAS或IS是某种类型，我会感到困惑）。
• 一个项目类型包含1个或多个项目阶段
• 某个阶段的项目阶段IS

要解释系统必须执行的操作：

可以将员工分配到项目的特定阶段。 该项目应为某种类型，并且该类型由某些项目阶段组成。 项目阶段是某个阶段。

因为员工需要查看他当前的所有项目等，所以我也链接到员工和项目。 我不知道这是正确的还是在项目阶段，有责任向员工提供正确的项目。

Answer 1

根据经验，不存在绘制图表的唯一正确方法。

聚合

一个明显的错误是您使用复合聚合。 通过这种用法，您假定ProjectPhase已附加到一个雇员，并且不能与其他雇员共享，并且绝对不是您想要在此处描述的内容。

如果您想表明该项目是由多名员工组成的，则最终可以使用共享聚合，这意味着您应该有相反的方向并拥有开放的菱形。

对于ProjectPhase和ProjectType，这是一个复合聚合，但方向相反（ProjectType是特定ProjectPhase的构建，而ProjectPhase正是一个ProjectType的一部分）。

概括

Project to ProjectType和Phase to ProjectPhase是存在多个选项的地方。

1. 如果您假设某个项目是“阶段”的构建，然后您想要对特定类型的项目（例如ProjectWaterfall，ProjectScrum，ProjectXP，ProjectRUP，ProjectPrince2）进行建模，这将专门化具有特定结构的项目，则可以使用归纳法，但是Project和阶段将在通用端（带箭头的一端），而特定的ProjectType和ProjectPhase将在专用端（无箭头）。 如果使用此方法，则可以显示每个ProjectType的详细结构。 有关详细信息，请参见示例。 还要注意如何使用一些附加约束来更精确地定义如何理解建模系统的逻辑。 最后要知道，在我的图中，我假设每个项目以及阶段都必须是特定类型。 您不能拥有这样的项目（不一定必须是真实的），因此我将它们抽象化了。 这是某个ProjetType的项目IS 。

2. 另一个选择是将ProjectType和PhaseType分别用作Project和Phase的属性，并保留其他类型的Project中特定类型的逻辑。 在这种情况下，通常将ProjectType和PhaseType建模为枚举数，然后将它们分别作为Project和Phase中的属性，以依赖关系链接各个元素。 这里Project具有某些ProjetType 。

笔记

• 给定选择并不能创建可能性的完整列表。 这只是两种最常用的方法。
• 您可以在哪种模型中混合使用哪种方法，具体取决于哪种方法更适合您的目的。 但是，通常在类之间的这种依赖级别上，您将使用与在图上受益的方法相同的方法（请参见示例）。

员工-项目关系

显然，仅通过阶段分配员工到项目，因此直接关系是多余的。 您最终可以将其描述为派生关系。

例子

特殊类型

本示例使用第一种方法。 请注意，我定义了确切的特定项目类型，而不是一些未定义的常规ProjectType（与Phases相同）。

在此示例中，我完全省略了有关Employee和Phase之间关系的冗余信息。

类型为枚举

此示例未提供有关特定类型的结构的详细信息。 您可能需要在此处添加其他类，这些类为您的项目创建模板，以定义项目结构的外观（包括哪些阶段）。 该类未在示例图上显示。 此外，我添加了Employee和Project之间的直接派生关联。

Answer 2

一些明显的错误：

• 在两种情况下都应除去组合物。 它们是错误的，并且通常不会（几乎始终）添加足够多的语义以致无法使用。
• 将概括更改为简单关联。 这里不是继承，而是归因。

在我看来，这符合您的解释：

您不需要从Employee到Project的关联，因为它是通过阶段和类型链接的。 没有关于phase解释，所以我只添加了一个简单的属性。 我猜这是一个枚举或一个字符串。 最终， ProjectType也是一个简单的枚举，可以用Project的属性替换（需要调查）。

Answer 3

我认为这是适合您要求的类图：

我已经对Project / ProjectPhase之间以及ProjectType / Phase之间的组合关联进行了建模，因为一个项目由ProjectPhase组成，而ProjectPhase不能没有它们的Projects，并且ProjectType / Phase也是如此。

员工和ProjectPhase既没有部分关系也没有存在依赖关系，因此在这里组合结构是不合适的。

在我的图表中，Employee是通过ProjectPhases隐式分配给Projects的，但是如果您想强调Employees和Projects之间的关系，则可以很好地显式地在这些类之间建立关联。