我一直在努力将我的系统放入类图中。我倾向于通过在数据库结构中考虑太多来犯关系错误。我有一个类图：
所以解释一下我需要的情况：
员工部分：
项目部分：
解释系统必须做什么：
可以将员工分配到项目的某个阶段。项目应该是某种类型，并且该类型由某些项目阶段组成。项目阶段是某个阶段。
因为员工需要查看他当前的所有项目等，所以我也建立了员工和项目的链接。我不知道这是否正确，或者这是项目阶段，它有责任为员工提供正确的项目。
【问题讨论】：
标签： class oop uml class-diagram
根据经验 - 没有唯一正确的绘制图表的方法。
一个明显的错误是您使用复合聚合。使用这种用法，您假设 ProjectPhase 附加到一个员工，并且不能与其他员工共享，这绝对不是您要在此处描述的内容。
如果您想表明该项目是由多个员工构建的，您最终可以使用共享聚合，这意味着您应该有一个相反的方向和一个开放的菱形。
在 ProjectPhase 和 ProjectType 的情况下，这是复合聚合，但方向相反（ProjectType 是特定 ProjectPhase 的构建，而 ProjectPhase 恰好是一个 ProjectType 的一部分）。
Project 到 ProjectType 和 Phase 到 ProjectPhase 是存在多个选项的地方。
如果您假设一个项目是由阶段构建的，然后您想要对特定类型的项目（例如 ProjectWaterfall、ProjectScrum、ProjectXP、ProjectRUP、ProjectPrince2）进行建模，这些项目将专门化具有特定结构的项目，那么您可以使用泛化，但是 Project 和 Phase 将位于泛化端（带箭头的一端），而特定的 ProjectType 和 ProjectPhase 将位于专用端（无箭头）。如果您遵循此方法，您可以显示每个 ProjectType 的详细结构。有关详细信息，请参阅示例。还要注意如何使用一些额外的约束来更精确地定义如何理解建模系统的逻辑。最后请注意，在我的图表中，我假设每个项目和阶段都必须是特定类型。你不能有这样的项目（不一定是真的），因此我把它们抽象化了。 这里是某个 ProjetType 的 Project IS。
另一个选项是使用 ProjectType 和 PhaseType 分别作为 Project 和 Phase 的属性，并在其他地方保留哪些类型应该在特定类型的 Project 中的逻辑。在这种情况下，您通常将 ProjectType 和 PhaseType 建模为枚举器，然后将它们作为属性分别放在 Project 和 Phase 中，将各个元素与 Dependency 链接起来。 Here Project 有特定的 ProjetType。
注意事项
显然，将员工分配到项目仅通过阶段完成，因此直接关系是多余的。您最终可以将其描述为派生关系。
本示例使用第一种方法。请注意，我定义了精确的、特定类型的项目，而不是一些未定义的通用 ProjectType（阶段相同）。
在这个例子中，我完全省略了关于 Employee 和 Phase 之间关系的冗余信息。
此示例未提供有关特定类型结构的详细信息。您可能希望在此处添加其他类，为您的项目创建模板，以定义项目结构的外观（包括哪些阶段）。示例图中未显示此类。 此外，我添加了 Employee 和 Project 之间的直接派生关联。
【讨论】：
我认为这是适合您要求的类图：
我已经对 Project/ProjectPhase 之间以及 ProjectType/Phase 之间的组合关联进行了建模，因为一个 Project 由 ProjectPhases 组成，ProjectPhases 没有它们的 Projects 就不能存在，ProjectType/Phase 也是如此。
Employees 和 ProjectPhases 既没有部分关系也没有存在依赖关系，因此这里不适合组合关联。
在我的图表中，Employee 通过 ProjectPhases 被隐式分配给 Projects，但如果您想强调Employees 和 Projects 之间的关系，您可以显式地在这些类之间绘制关联。
【讨论】：
【讨论】：