Is an abstract role needed to ensure that a customer can only have one role out of several? [closed]

Question

I have the following UML class diagram in a C++ context. I want to make sure that a Customer can have only one role:

Can the Customer now only assume one role, and what does <<abstract>> have to do with this restriction? Do I even need to make customerRole abstract in this case?

Answer 1

What does the diagram mean?

This UML design ensures that the Customer has 1 and exactly 1 CustomerRole, but that the instances of that role must be one of its specialization Recipient, Participant or Prospect.

You could further clarify that the relevant specializations are all in the diagram, using a generalization set and {disjoint,complete}:

Is the abstract CustomerRole needed?

In UML, an abstract class is a class that cannot be directly instantiated. This means that every instance of the CustomerRole shall be an instance of one of its specializations. If that class would not be abstract, an unspecialized CustomerRole could be allowed. By the way, «abstract» is not standard UML even if the notation is popular (see this answer on SO).

Without CustomerRole at all, it would be much more difficult to tell that there is only one single role:

• Customer would need 3 associations 0..1, as well as a constraint to guarantee that exactly only one of the 3 associations is active for each instance.
• If other kind of roles would be added later on, you'd need to add more such associations, thus modifying Customer, which makes that alternative design difficult to extend (the contrary of the Open-Closed Principle)

Are there other alternatives ?

An alternative UML design would be to make CustomerRole an «interface» and make Recipient, Participant and Prospect independent classes that realize this interface:

It is not possible to advise you to use the one or the other without knowing anything about the class features (aka the members in C++). The advantage of interfaces is less coupled classes. Interfaces are natively supported by many languages , whereas abuse of abstract classes could lead to more complex scenarios with multiple inheritance, something that is more difficult to deal with and supported in only a few languages (fortunately for you, C++ is among them).

Answer 2

I think you are misunderstanding something here. Customer is not an abstract class. Instead, a "Customer" has a reference to a "CustomerRole" object. There are three "CustomerRole" classes, but the "Customer" doesn't know / care which one it is using. "CustomerRole" is an abstraction and not a concrete class. "Abstraction" has nothing to do directly with abstract classes.

In C++, your three classes Recipient, Participant and Prospect would have a common baseclass "CustomerRole". That base class might be abstract, but doesn't really have to be. In other languages supporting interfaces, you would have an interface "CustomerRole", Customer would have a reference to a "CustomerRole" interface, and Recipient, Participant and Prospect would implement the interface.