我的类图中的关系正确吗

Question

我试图弄清楚每个类之间的关系是否正确。我试图学习它，但对每个应该是什么感到困惑。

这是每个的代码：

package part1;
public enum Role {
    STUDENT, ACADEMIC
}

package part1;
import part1.part11.Students;
import part1.part12.AcademicStaffMembers;
public class Controller {
    private int id;
    public Controller(Role role) {
        if(role == Role.ACADEMIC){
            AcademicStaffMembers academicStaffMembers=new AcademicStaffMembers();
        }
        else if(role == Role.STUDENT) {
            Students students = new Students();
        }
    }
}

package part1.part11;
public class Students{
    private Student[] students;
}

package part1.part11;
import part2.Module;
import part2.ModuleCode;
public class Student {
    private int id;
    private Module[] modules;
    private ModuleCode[] moduleCodes;
}

package part1.part12;
public class AcademicStaffMembers {
    private AcademicStaffMember[] academicStaffMembers;
}

package part1.part12;
import part2.Module;
import part2.ModuleCode;
public class AcademicStaffMember {
    private int id;
    private Module[] modules;
    private ModuleCode[] moduleCodes;
}

package part2;
public class Module{
    private ModuleCode moduleCode;
}

package part2;
public enum ModuleCode{
    CSC1022, CSC1023, CSC1024, CSC1025, CSC1026, CSC1027, CSC1028, CSC1029, CSC1030, CSC1031
}

目前我认为关系如下：

控制器：

• 与角色的关联
• 与学生的依赖
• 与学术人员的依赖性

学生们

• 与学生作文（学生钻石）

学术人员

• 与学术人员作文（学术人员钻石级）

学生

• 与模块关联
• 与 ModuleCode 的关联

学术职员

• 与模块关联
• 与 ModuleCode 的关联

模块

• 与 ModuleCode 组合（模块处的钻石）

任何帮助或建议都会很棒，谢谢。

Answer 1

一般情况下，我们不在这里做评论。

但是，鉴于操作时的瞬态关系和语义关系之间的混淆，您的示例很有趣：

• Controller

  和

  Role

  之间的关系是暂时的：它仅在操作期间暂时存在，即使该操作是构造函数。这不是类之间的关联，而是依赖关系。

  这显示了一个设计缺陷，因为

  students

  和

  acedemicStaffMembers

  集合是在操作期间创建的，但不能在该操作之外使用，这使得它们有些无用。为了使其工作，

  Students

  和

  AdademicStaffMembers

  都应该是单例类，或者

  students

  和

  acedemicStaffMembers

  都应该成为

  Controller

  的私有属性。

使用复合聚合（黑菱形）来建模集合也很有趣：

• 在 UML 中，枚举是值对象。在这种情况下，为枚举添加复合聚合是没有意义的：更喜欢简单的关联。
• 对于收藏而言，这并没有错，但意味着如果复合材料被破坏，这些收藏中的学生和教职员也会被破坏。这在 Java 中并不是微不足道的，因为对学生和教职员工的引用可能存在于其他地方，从而防止了这些对象的破坏。我建议更喜欢在集合方面使用具有显式多重性

  0..1

  的简单关联，并在要收集的元素上使用

  *

  ，这更加有用和准确。仅在严格需要时才考虑使用复合聚合。

显示多样性还可以显着提高图表的表达能力（例如，阐明学术人员可以与许多模块和许多模块代码相关联）。

其他建议：（滥用）枚举的使用应该引起一些问题：

• 枚举的目的是改变行为（至于

  Controller

  ）？如果是，请考虑专业化 - 从更通用的

  StudentController

  继承一个

  AcademicStaffMemberController

  和

  Controller

  是非常有意义的，因为两者的行为、验证、规则、操作可能不一样。
• 枚举的目的是充当数据列表（至于

  ModuleCode

  ）吗？如果是，仅当列表需要长期固定时才保留它们。然而，如果列表可能发生变化（例如，每年都会引入新的课程模块，例如用于新 VR UX 的 CS1032 或用于 LLM AI 最新开发的 CS1033），则考虑放弃枚举并使用 ModuleCodes 作为具有属性代码和标题。