CODEWITHSUNDEEP
classumlassociationsclass-diagram
Michael Efraimidis
Michael Efraimidis

Reputation: 101

UML attribute to association class or simple class?

I'm having a difficulty figuring out where to put the Level attribute. I want the employee to have a variety of skills which have different levels. For that purpose I made a many to many relationship which is implemented as an EmployeeSkill association class.

An example of said class is as follows: An employee named Jack might have a skill of Java which is level beginner, while he could also have a skill of C# which is advanced level. Should the level be saved in the EmployeeSkill association class or in the Skill class? I suspect it should be on the association class.

The image of the UML diagram in drawio

Upvotes: 2

Views: 220

Answers (1)

Christophe
Christophe

Reputation: 73376

A property of the association class?

Your narrative with the Employee instance "Jack" being associated with Skill instance "Java" with a level of "beginner" shows that the skill is independent of the level, and the level is related to the combination of a given employee and a given skill.

To model accurately the semantic of this narrative, level should indeed be the property of the association class EmployeeSkill.

Could it be a property of the skills?

It would not be wrong to move level as a property of Skill. But the model would have a different semantic, since every Employee associated with a Skill would share the same level. This means that "Jack" being associated to a skill like "Java" but rather a skill like Elementary Java.

This alternative model makes it also less convenient to desperately search for all employees knowing about Neural network regardless of the level. And it would not be obvious for the system to see that elementary neural network is related to advanced neural network expertise and that Advanced java has little to do with Advanced javascript.

To have the same power of expression, the skills that are related but correspond to a different level would require an explicit association, which would make the model more cumbersome to use and fragile.

Remarks that are unrelated to your question

  • You seem to repeat the JobCategory's and the Country's attribute within Employee. This is confusing, as the associations already associate the class with another set of each of these attributes. Did you mean the redundant attributes to implement the associations and show the db table layout than the class? If so, you should disambiguate using some custom stereotypes. But I'd rather recommend to remove the redundant items and make a comment at the bottom of the diagram to explain that you implement associations.
  • I wonder if the multiplicities of the association between Skill and SkillCategory are not inverted (i.e. one category can have several skills and each skill is associated with only one category) ? Or that you meant a many-to-many association if skills can belong to several categories.
  • In the association class you use the prefix FK to highlight the foreign keys. Use <<FK>> to make it a custom stereotype (see may first remark about using stereotypes).
  • As qwerty_so pointed out in the comments, you use a nesting connector for the associations with enumerations. This is syntactically acceptable but does not mean what you think. This is meant to deal with namespaces. Just remove that circle-plus symbol to make it a normal association and it will mean what you think.

Upvotes: 2

Related Questions