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):
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:
Solution:
Question:
Option
once have a dashed line and a normal line to Contract
?Minutes
not listed as a class like Data
and SMS
?Phone
and DoubleTransfer
have no connection to the other classes?There is a serious inconsistency in this diagram:
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.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;
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.
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.