The base use case represents the “must have” functionality of a project while the extending use case represents optional (should/could/want) behavior.The base use case should be a fully functional use case in its own right (‘include’s included of course) without the extending use case’s additional functionality.Įxtending use cases can be used in several situations:
The extending use case is dependent on the base use case it literally extends the behavior described by the base use case. This is why included use cases can be: a) base use cases in their own right and b) shared by a number of base use cases. In the best practice of one way dependency the base use case knows about (and refers to) the included use case, but the included use case shouldn’t ‘know’ about the base use case.
(This is contrary to a popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario use cases can easily be restructured to represent a different flow as the main scenario and this should not matter).
includeĪ base use case is dependent on the included use case(s) without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. I’ll use the terms ‘base’, ‘included’ and ‘extending’ to refer to the use case roles. The key to Include and extend use case relationships is to realize that, common with the rest of UML, the dotted arrow between use cases is a dependency relationship.
Here’s a correct approach (in my view, and checked against Jacobson, Fowler, Larmen and 10 other references). This may be contentious but the “includes are always and extends are sometimes” is a very common misconception which has almost taken over now as the de-facto meaning.
0 kommentar(er)
