Include and Extend Use Case

Include

A 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. (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).

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 why included use cases can be: a) base use cases in their
own right and b) shared by a number of base use cases.

Extend

The extending use case is dependent on the base use case; it literally extends the
behaviour described by the base use case. 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.

Extending use cases can be used in several situations:

1. The base use case represents the “must have” functionality of a project while
the extending use case represents optional (should/could/want) behaviour.
This is where the term optional is relevant – optional whether to build/deliver
rather than optional whether it sometimes runs as part of the base use case
sequence.
2. In phase 1 you can deliver the base use case which meets the requirements at
that point, and phase 2 will add additional functionality described by the
extending use case. This can contain sequences that are always or sometimes
performed after phase 2 is delivered (again contrary to popular
misconception).
3. It can be used to extract out subsequence of the base use case, especially when
they represent ‘exceptional’ complex behaviour with its own alternative
flows.
One important aspect to consider is that the extending use case can ‘insert’
behaviour in several places in the base use case’s flow, not just in a single place
as an included use case does. For this reason, it is highly unlikely that an
extending use case will be suitable to extend more than one base use case.
As to dependency, the extending use case is dependent on the base use case and
is again a one-way dependency, i.e. the base use case doesn’t need any reference
to the extending use case in the sequence. That doesn’t mean you can’t
demonstrate the extension points or add an x-ref to the extending use case
elsewhere in the template, but the base use case must be able to work without the
extending use case.

Vehicle Sales Systems

Use cases share different kinds of relationships. Defining the relationship

between two use cases is the decision of the software analysts of the use case
diagram.

 A relationship between two use cases is basically modelling the

dependency between the two use cases.
 Reuse of an existing use case by using different types of relationships
reduces the overall effort required in developing a system.
Include

 When a use case is depicted as using functionality of another

functionality of another use case, this relationship between the uses cases
is named as include or uses relationship.
 A use case includes the functionality described in another use case as a
part of its business process flow.
 A uses relationship from base use case to child use case indicates that an
instance of the base use case will include the behaviour as specified in
the child use case.
 An include relationship is depicted with a directed arrow having a dotted
line. The tip of arrowhead points to the child use case and the parent use
case connected at base of the arrow.
 The stereotype "<<include>>" identifies the relationship as an include
relationship.

Extends

 Indicates that an "Invalid Password" use case may include (subject to

specified in the extension) the behaviour specified by base use
case "Login Account".
  Depict with a directed arrow having a dotted line. The tip of arrowhead
points to the base use case and the child use case is connected at the base
of the arrow.
 The stereotype "<<extends>>" identifies as an extend relationship

2nd

Use Case Example - Include Relationship

The include relationship adds additional functionality not specified in the base
use case. The <<Include>> relationship is used to include common behaviour
from an included use case into a base use case in order to support re-use of
common behaviour.

Use Case Example - Extend Relationship

The extend relationships are important because they show optional functionality
or system behaviour. The <<extend>> relationship is used to include optional
behaviour from an extending use case in an extended use case. Take a look at the
use case diagram example below. It shows an extend connector and an extension
point "Search".
Difference between Extend and Include
Consider the following use case