CODEWITHSUNDEEP
inheritanceumlassociationsclass-diagram
Mee98
Mee98

Reputation: 185

Question about association classes in UML class diagram

So I need to model the situation where we have a collection of people who are members of a federation. You can either be an active member or an inactive member of the federation. If you're inactive, you're not a member of any club. If you're an active member, you are a main member to exactly one club and can have any number of clubs that you're an internal member of.

My current UML model does not enforce that every active player should have exactly one main membership so I'm wondering how I can fix this. I personally think that I can solve this by drawing a regular association between 'Main' and 'Active' but I don't really know if this is allowed or if there are any other solutions to my problem.enter image description here

Upvotes: 3

Views: 1122

Answers (2)

Geert Bellekens
Geert Bellekens

Reputation: 13701

Although not necesarrily wrong, you might be overusing Generalization

A Generalization is a is a relationship, and where I can follow if you say

  • a Player is a Person

but I'm having a harder time understanding

  • a Active is a Player is a Person

It seems to make more sense to model Active or NotActive as values of the Status of a Player.

Here's how the most basic model to express those requirements could look like.

enter image description here

Some pointers

  • Player becomes a role played by Person, not the same object. So if a Player is deleted, the Person object can live on. In the other direction I have modelled it using compositions. So if a Person is deleted, it's Player role is deleted, and also it's Memberships
  • Using Composition over Inheritance is a known software engineering principle
  • I've used a constraint with natural language to express the Active member should have one main membership requirement. If you like (or need) it to be more formal you could use OCL as well. An alternative option might be to add another association with [0..1] multiplicity for the main Membership. You could add a constraint there that says it's only for Memberships with property IsMainMembership = True, and that it is mandatory for Players with Status = "Active"
  • In order to insure consistency between Player.Status, and the existence of a main Membership, you could also opt to make the Player.Status derived. You could then derive the Status by checking the existence of an association to a main Membership.
  • In most implementations an instance cannot change classes. So if your Active where to become NotActive you would have to delete the Active object and create a new NotActive object. Having Active/Notactive as a status would allow you to use the same object and simply change it's status. How these statusses can be changed could be modeled using a State Machine.
  • Most OO languages also don't support multiple inheritance, so you should be careful about choosing a Generalization. If you choose to make Player a Person, you might get into trouble if you later need players that are not Persons, such as computers, or organisations, or teams. UML does support multiple inheritance, but in most organisations I've worked so far the guidelines forbid the use of multiple inheritance.
  • In this case I even did away with the association-class in favor of a regular class with regular associations. Association classes make your model harder to understand for the less UML savvy

I'm not saying this model is better or worse than your model, but it's worth think about the other end of the complexity spectrum, and where you want your model to end up at.

Upvotes: 2

Jim L.
Jim L.

Reputation: 6529

Main is an instance of a UML Association Class because its superclass is Membership. That means Main can specialize the association (which requires another dashed line) and can subset one or both association ends. When you say

isMemberOf { subsets isMemberOf } 1

on the left end of the new association line, that means every active player must participate in exactly one Main membership, plus any number of other kinds of memberships.

You should consider renaming the subsetting and / or subsetted properties for clarity, but UML does not require it. For example,

isMainMemberOf { subsets isMemberOf } 1

(Although that name implies a person is the Main member of a club, which is not quite right.)

Upvotes: 1

Related Questions