问UML属性是关联类还是简单类？

EN

关联类的属性？

您对Employee实例"Jack"与Skill实例"Java"与level of "beginner"相关联的叙述表明，该技能与级别无关，并且该级别与给定员工和给定技能的组合有关。

为了准确地模拟这种叙述的语义，level确实应该是关联类EmployeeSkill的属性。

会不会是这种技能的一种特性？

将level移动为Skill的属性并不是错误的。但是模型的语义不同，因为每个与Employee关联的Skill都共享相同的级别。这意味着"Jack"与"Java"这样的技能相关联，而与Elementary Java这样的技能相关联。

这种替代模式还减少了拼命搜索所有知道Neural network的员工的方便性，而不管级别如何。而且，对于系统来说，不太明显的是，elementary neural network与advanced neural network expertise相关，而Advanced java与Advanced javascript没有什么关系。

为了具有同样的表达能力，相关但对应于不同层次的技能将需要明确的关联，这将使模型的使用更加繁琐和脆弱。

与你的问题无关的评论

• 您似乎在JobCategory和Country的属性中重复了Employee的属性。这是令人困惑的，因为关联已经将类与这些属性的另一组关联起来。您是指用于实现关联和显示db表布局的冗余属性，而不是类吗?如果是这样，应该使用一些定制定型来消除歧义。但是，我建议删除冗余项，并在图表底部发表评论，解释您实现关联的原因。
• 我不知道Skill和SkillCategory之间的关联的多重性是否是颠倒的(也就是说，一个类别可以有多个技能，而每个技能只与一个类别相关联)？或者你指的是多到多的关联，如果技能属于几个类别的话。
• 在关联类中，使用前缀FK突出显示外键。使用<<FK>>使其成为自定义原型(参见可能首先提到使用原型)。
• 正如所以在注释中所指出的，您使用嵌套连接器来关联枚举。这在语法上是可以接受的，但并不是你所想的。这是为了处理名称空间。只要去掉那个圆圈加符号，让它成为一个正常的联想，它就会像你想的那样。