Why does the class have a dashed line once and a normal line once?

Question

I have a task which requires me to draw a UML diagram based on the description. I have received the solution (see the photo). However, I can't figure out the solution and have a few questions why the solution is the way it is. I have described these below.

Description:

The contract of a prepaid cell phone should be modelled and implemented. A basic contract has a contract number (of type int) and a balance (of type double), but no monthly charges. The contract number is not automatically generated, but is to be set as a parameter by the constructor as well as the initial balance. The balance has a getter and a setter. The following options can be added to a contract (if needed also several times):

• 100 MB of data (monthly charge 1.00 €)
• 50 SMS (monthly charge 0.50 €)
• 50 minutes (monthly charge 1.50 €)
• Double Transfer Rate (monthly charge 2.00 €) Implement this this requirement with the help of the decorator pattern. All contract elements should be able to understand the methods getCharges():double, getBalance():double and setBalance (double).

The method getCharges() should provide the monthly charge of a contract with all its options selected. The methods getBalance() and setBalance(…) should be passed through and access the basic contract.

Exercise:

• Draw an UML-Diagram with all the classes / interfaces and their relationships, fields and methods (no constructors needed).
• Also provide a client class which holds a contract.

Solution:

Question:

• Why does Option once have a dashed line and a normal line to Contract?
• Why are the Minutes not listed as a class like Data and SMS?
• Why does Phone and DoubleTransfer have no connection to the other classes?

Answer 1

Preliminary remarks

There is a serious inconsistency in this diagram:

• Either Contract is an abstract class (name in italic) and other classes such as BasicContract can specialize it (inheritance, with a plain line from BasicContract to Contract, and a hollow triangle at the Contract end.
• Or Contract is an interface (with keyword «Interface» preceding the name of the classifier, or as lollipop), and classes such as BasicContract can realize it (implementation, with a dashed line but a hollow triangle at the Contract end).

There's a serious ambiguity as well: since at least one hollow triangle was replaced with a tiny plain arrow head, it is not clear if the other arrow heads are arrow heads (i.e. navigable association) or if they are meant to be hollow triangles (i.e. inheritance).

I'll assume the interface scenario, and I'll assume that the arrow between Option and Contract is a navigable association;

The double line for Option

Option implements the decorator design pattern. This means that it implements the Contract interface (dashed line + hollow arrow) but it adds responsibilities to an associated Contract (plain line, with or without tiny plain arrow head).

Two remarks:

• Very often, you'll find decorators modelled with an aggregation instead of an association. This is not wrong, but is really not necessary.

• Unfortunately, this decorator doesn't seem to add any responsibility. to the original contract. This is weird, and could only make sens if Data and SMS would be specializations of Option but then again, we have the issue with the inconsistent arrow head (which should then be hollow triangle not tiny plain arrow head), making this "solution" extremely ambiguous, and not at the level one could expect a "solution" to be.

Other questions

The missing Minutes is an interesting question. Indeed, one could add a class Minute, and use it as a type for properties or operations. Surprisingly, Euros and MegaBytes are not modelled either. What do all these types have in common?

The missing links for Phone and Double Transfer are indeed weird. Perhaps the author ran out of ink, or used a limited demo edition of an UML editor allowing at most 6 connectors? Probably it is like SMS and Data, but cross-check the narrative to be sure.