Interactions modeling

• Model of interactions is the third leg of a tripod:

it supplements object and dynamic models.

• Interaction model says how objects act to each

other – it is an integral view over many objects
(whilst a state model describes behavior of
objects individually).

• To complete description of behavior we need

both: state and interactions model.

• Interactions can be modeled at different

abstraction levels:
- At top level: Use Case describes interactions
of a system with its environment.
- A more detailed view: Sequence diagram
describes an exchange of messages in time
within a set of objects. It is suitable to describe
sequences of behavior from a perspective of a
system-user.
- Detailed view: Activity diagram shows a
control flow between individual steps of
computation (in operations presented in
a sequence diagram). It shows both: data flow
and control flow.

57
Use Case models
• Actor is an external system-user which directly
communicates with a system but is not a part of
the system.
Ex.: Customer, Repair man and Store-keeper
are actors for a vending machine.
• Object can be related with many actors if they
create different aspects of his behavior.
Ex.: Eva, John and George can be customers of
a vending-machine. John can be also a repair
man.
• Actor has a single well defined purpose. It can
represent objects from different classes if they
act analogically with respect to the system.
• Actor need not be only a person.
• Use Case is a coherent part of functionality
which system provides during its communication
with an actor.
• Besides a system itself, Use case deals with one
or more actors.
• Use case joins all behavior, which is related to a
system functionality, i.e. a basic normal behavior
and its variations, special and error conditions
and requirements.

58
 Ex.: use cases for a vending machine: Buy
snakes, Do planned maintenance, Refill
products.

• Use Case diagrams formally depict a structure

of system functionality with respect to its
communication with a surrounding (actors).

Vending machine

Buy snakes

Customer
Do planned
maintenance

Repair man
Repair

Refill products

Store-keeper

• UML notation:
- System: rectangle with an inscribed name
- Actor: icon „stick man“
- Use Case: ellipse with an inscribed name
inside the system (rectangle)

59
 - Connection of actor with the UC: solid line.
• Use cases divide system functionality in a whole
model. They should be at a comparable level of
abstraction.
• Recommendations for building use case models:
- First determine system boundaries.
- Each actor should have a single coherent
purpose (actor is not an independent concept –
it is defined with respect to a system).
- Each use case should provide users with
certain cummulative service; it should not be
defined too narrowly.
- Each use case should have at least one actor
and each actor should participate at least in one
use case.
- Use cases are an informal instrument, attempts
towards an excessive formalization is
counterproductive.
- Use case could be structured.

• Independent use cases suffice for simple

applications.
• For large applications it is suitable to structure
and compose use case from smaller parts by
relationships include, extend and generalization.

60
• Relationship include incorporates one use case
into behavior of another use case. It is similar to
sub-program, it represents that behavior which
should be described repeatedly, otherwise.

• UML notation is a dashed arrow marked with

keyword «include» from container to included
(contained) use case.

Do payment «include»

Password check
hesla
Change limit «include»

Ex. Both use cases Do payment and Change limit

contain a use case Password check.

• Relationship extend adds further functionality to

a use case.

• UML notation is a dashed arrow, labeled by a

keyword «extend», from an added to an original
use case.

61
 Buying flight ticket Check-in

«extend»
«extend»
«extend»

Trip in TA on-line service

• Include and extend relationships act (structure)

on the use case in opposite directions. In include
the added feature is compulsory (original use
case cannot exist without it), whilst in extend the
original use case is meaningful also without an
added behavior.

• Relationship generalization expresses specific

variants of a use case. Notation in UML is same
as in a class diagram (a hollow triangle at a
parent side).

Air tickets sale

Air company Internet TA

62
• Parent use case should be abstract (so that it
cannot be used directly).

Sequence models
• There exist 2 kinds of sequence models:
- Scenarios
- Sequence diagrams.

• Scenario is a sequence of events which occur

during a certain usage of a system (e.g. use case).
• Scenarios have various scope. Mostly they have
a form of text sentences.
• Scenario can be a historical record of behavior of
existing system or expected behavior of a new
system.
• In early stages we create scenarios at higher level
(of abstraction). Later they can express accurate
messages.
• Scenarios contain messages among objects and
also activities conducted by an object. Each
message transfers information from one object to
another one.

63
• Sequence diagrams show participants of
interactions and messages among them.

• Each actor (and also a system) is represented by a

column (a vertical bar called „lifeline“) and each
message is depicted by a horizontal arrow from a
sender to a receiver of a message.

• Time progresses from top towards down. We can

express order of messages in this way (but not
exact timing).
• We can also express concurrent signals.
• Each use case needs one or more sequence
diagrams to express behavior (each of them
shows a partial sequence of behavior of use
case).

64
 Caller PhoneLine Callee

Caller hooks off

Dial tone begins

Digit (5)

End of dial tone

Digit (7)

Digit (2)

Digit (5)

Ringing tone Ringing begins

Callee hooks off

End of tone End of ringing

Devices connected Devices connected

Caller hooks on

Devices disconnected Devices disconnected

Callee hooks on

• It is suitable to build a separate sequence

diagram for each main flow of control or for
each separate task or a special case.

65
 Caller PhoneLine Callee

Ringing tone Ringing begins

Busy

Busy tone End of ringing

Caller hooks on

Devices disconnected

• Recommendations for sequence models.

- Prepare at least one scenario for each use case.
- Convert scenarios into sequence diagrams.
- Split complex interactions into their partial
components and create a sequence diagram for
each component.
- Create a sequence diagram for each error
situation.

66
Procedural sequence models
They enable to model also behavior of passive and
transient (temporary) objects. It is analogy to a
procedure calling in programing languages.
• Sequence diagram with passive objects
• Majority of objects are passive and they are
activated only by calling. They return control
back to a calling object after completing their
operations and become inactive again.
• „The life-line“is represented by a dashed line for
the time when object exists but it is inactive. In
the time of activity it changes into a bar (narrow
rectangle).

:Transaction :CustomerTable :AccTable

Make
transaction
Customer checking

Ok
Account checking

Fees
Ok

67
• Sequence diagram with transient objects
• In the next example ObjectA is an active
object, which initiates operation. It is active,
thus its „life-line“spans the entire time.
• ObjectB is passive. It exists all the time, but it
is not active during all that time.
• ObjectC is a transient one. It is created and
destroyed by completing its activity, so that the
life-line doesn’t span the whole diagram.
ObjectA ObjectB

operationM(a,b)

createC(arg)
ObjectC
operationM(c,d)

result1

result2

• Notation for calling is a solid arrow from caller

to callee (whilst hollow arrow means
asynchroneous signals). Return is denoted by a
dashed arrow.
• A solid arrow to a centre of object depicts
creating a transient object. X shows end of life.
• Overlaping bar is a next operation on ObjectB.
68
Activity models
• Activity diagrams show steps for building a
complex process, e.g. algorithm or workflow.
• Activity diagram shows a control flow (like a
traditional flow chart). Moreover, it can model
also concurrent besides sequential control flows.
• UML notation:
- Activity: extended oval with an inscribed
name
- Decision point: diamond
- Continuation: arrow
- Splitting and merging of branches: solid bar
- Beginning: solid circle
- End: buls eye.
• Some activities run forever, until an outside
event interrupts them, but most of activities
complete their task and spontaneously terminate.
• Terminating of activity is a terminating event and
it usually means that a next activity can begin.
• Non-named arrow from one activity to another
one indicates that the first activity should finish
before next one starts.
• Activity can be decomposed into finer activities.

69
• Concurrent activities (after splitting) can be
executed in arbitrary order. Before a merge can
happen, all inputs must first complete.
Verify
order

Execute
order

[failure]

[OK]

Debit acc.

Send Trade Update

confirmation portfolio

Close Send failure

order notice

• If activity has several successors, each branch

should be labeled by a condition in square
brackets. E.g.. [failure].

70
• Conditions are tested after completing activity.
• It is convenient to use also [else] condition, in
order to guarantee continuation.

Summary to models
• All three models are needed but various types of
systems put different emphasis to individual
models.
• Models offer to view a system from three
different viewpoints:
• Object model expresses a static structure of
objects in a system, mainly classes, associations
and generalizations (attributes and operations are
secondary).
• State model describes changes of object
properties in time and their mutual stimulation.
State model is a collection of state diagrams.
• Interaction model describes cooperation of
objects in several levels of abstraction:
- top: use case,
- middle: sequence diagram and
- most detailed: activity diagram.

71
• Each model focuses at a certain aspect and leaves
remaining aspects without explanation. All three
models are needed for a full system
understanding.
• Generalization is an „OR“ relationship and it
occurs in all three models. Inheritance holds for
classifiers (classes, signals a use cases).
• All super-classifiers are abstract, leaf classifiers
are concrete.
• UML2 doesnot have inheritance of states.

• Aggregation is an „AND“ relationship with

transitivity and antisymetry properties. It has two
forms:
- (general) aggregation – (components can exist
independently of assembly) and
- composition – (a component belongs to at
most one assembly and it has the same
lifetime).

72