Chapter 8

 Complex use cases can be built from smaller pieces with the
include, extend, and generalization relationships.
 Include Relationship
 The include relationship incorporates one use case within the
behavior sequence of another use case.
 The include relationship could be used:
◦ to simplify large use case by splitting it into several
use cases,
◦ to extract common parts of the behaviors of two or
more use cases.
 The base use case is incomplete without the
included use case.
 The included use case is mandatory and not
optional.
Include Relationship Between Use Cases
 Extend Relationship
 The extend relationship adds incremental behavior to a use
case.
 It represents the frequent situation in which some initial
capability is defined, and later features are added modularly.
 The include and extend relationships both add behavior to a
base use case.
 The extend relationship connects an extension use case to a base
use case. The extension use case often is a fragment- that is, it
cannot appear alone as a behavior sequence.
 The base use case, however must be a valid use case in the
absence of any extensions.
 The extend relationship can specify an insert location within the
behavior sequence of the base use case; the location can be a
single step in the base sequence or a range of steps.
 The behavior sequence of the extension use case occurs at the
given point in the sequence.
 In most cases, an extend relationship has a condition attached. The
extension behavior occurs only if the condition is true when
control reaches the insert location.
 In the context of use case modeling the use
case generalization refers to the relationship
which can exist between two use cases and
which shows that one use case (child) inherits
the structure, behavior, and relationships of
another actor (parent).
 The child use case is also referred to
the more specializeduse case while the parent
is also referred to as the more abstract use
case of the relationship.
 Use the generalization relationship when you
find two or more use cases which have
common behavior/logic.

 Describe the common parts in a separate use

case (the parent) which then is specialized
into two or more specialized child use cases
.
Combinations of Use case Relationships
 Guidelines for use case relationships
 Use case generalization: If a use case comes in several
variations, model the common behavior with an abstract use
case and then specialize each of the variations.
 Do not use generalization simply to share a behavior fragment;
use include relationship for that purpose.
 Use case inclusion: If a use case includes a well-defined
behavior fragment that is likely to be useful in other situations,
define a use case for the behavior fragment and include it in
the original use case.
 In most cases, we should not think of the included use case as
a meaningful activity but not as an end in itself.
 For Ex: validating a password is meaningful to users but has a
purpose only within a broader context.
 Use case extension: If we can define a meaningful use case with
optional features, then model the base behavior as a use case and
add features with the extend relationship.
 This permits the system to be tested an debugged without the
extensions, which can be added later.
 Use the extend relationship when a system might be deployed in
different configurations, some with the additional features and
some without them.
 Include vs extend relationship: The include relationship and
the extend relationship can both factor behavior into smaller
pieces.
 The include relationship, implies that the included behavior is a
necessary part of a configured system
 Extend relationship implies that a system without the added
behavior would be meaningful.
The UML has elaborations for sequence diagrams to
show procedure calls.
Sequence Diagrams with Passive Objects
Most objects are passive and do not have their own
threads of control. Activation shows the time period
during which a call of a method is being processed,
including the time when the called method has invoked
another operation.
Sequence Diagrams with Passive Objects
Sequence Diagrams with Transient Objects
 Guidelines for Procedural Sequence Models
 Active vs Passive: Differentiate between active and passive
objects.
 Most objects are passive and lack their own thread of control.
Active objects are always activated and have their own focus of
control.
 Advanced features: Advanced features can show the
implementation of sequence diagrams.
 Be selective in using these advanced features. Only show
implementation details for difficult or especially important
sequence diagrams.
 3.11 Special Constructs for Activity Models
3.11.1 Sending & Receiving Signals: The UML shows the sending of a
signal as a convex pentagon & Receiving of a signal as a concave signal.

3/30/2019
Figure 3.21 Activity diagram with signals
Swimlanes
• In a business model, it is often useful to know which human organization is
responsible for an activity.
Example: Sales, finance, marketing, and purchasing
• It is sufficient to partition the activities among organizations.
• Lines across swimlane boundaries indicate interactions among different
organizations.

Figure: 3.22Activity diagram with swimlanes.

Object Flows
It is helpful to see the relationships between an operation and the objects
that are its argument values or results. An input or output arrow implies a
control flow. Frequently the same object goes through several states
during the execution of any activity diagram.UML shows an object value
in a particular state by placing the state name in square brackets
following the object name .

Figure 3.23 Activity diagram with object flows.