Formally, this is not correct. Use-cases could be associated with actors but not with other use-cases: the relationship between two use-cases may be «extend»
, or «include»
or specialization. In consequence, Add mobile number
and mobile
can't be associated the ay you have diagrammed it.
Depending on what you mean, you may correct your diagram:
- by showing that
mobile
includes Add mobile number
(dashed line with arrow), if you mean that every time mobile
is executed, add mobile number
would also be executed.
- by showing that
Add mobile number
extends mobile
(dashed line with arrow), if you mean that in some cases where mobile
is executed, add mobile number
could need to be executed as well.
Other notation improvement coulb be to get rid of the arrows for associations wetween actors and use-cases. This is an obsolete notation.
Beyond these purely formal remarks, it's important to realize that use-cases should represent goals of value for users. While we would certainly agree that payment
is a goal for the user, and we could certainly understand your desire to add extensions for different payment means, we would certainly not agree on the fact that Add mobile number
is a goal for the user. It's either functional decomposition or user-interface details, both aspects that should in principle not be documented in a UC diagram.