Object Oriented

Analysis and Design

using the UML

Modelling System Behaviour

Agenda

 Realizing your use cases

 Modeling the details of behaviors
 Choosing the best functional modeling
approach
 Process of designing classes diagrams

2
Interaction diagrams
 Interaction diagrams are a subset of behaviour diagrams
 Interaction diagrams emphasize the flow of control and
data among the things in the system being modeled
 Communication diagram: shows the interactions between
objects or parts in terms of sequenced messages.
 Interaction overview diagram: provides an overview in
which the nodes represent interaction diagrams.
 Sequence diagram: shows how objects communicate
with each other in terms of a sequence of messages.
 Timing diagrams: are a specific type of interaction
diagram, where the focus is on timing constraints.

3
Interaction diagram

 Interaction diagrams model the behavior of use

cases by describing the way groups of objects
interact to complete the task
 Interaction diagrams are used when you want
to model the behavior of several objects in a
use case
 They demonstrate how the objects collaborate for
the behavior.
 Interaction diagrams do not give a in depth
representation of the behavior

4
Sequence diagrams

 Sequence diagrams describes the objects and

the messages they pass.
 the diagrams are read left to right and
descending.

5
Sequence diagram

6
Example: a sequence diagram
for placing an order

7
Sequence diagrams

 One of the two types of interaction diagrams

 Useful for showing complex interactions
between a limited number of objects
 Can be used to show one scenario of use from
a “technical” perspective
 Shows order of interaction vertically
 Not useful for most users
 Can show high or low level of detail

8
 Lifelines

 Lifeline elements are placed across the top of

the diagram
 Represent either roles or object instances
that participate in the sequence
 Drawn as a box with a dashed line
descending from the centre of the
aCustomer ac1:Account
bottom edge
 The lifeline object’s name is placed
inside the box.
 The UML standard for naming a lifeline follows
the format of
 Instance (Object) Name : Class Name
 Underlined in UML1

9
 Messages
 Messages show what operations take place between
objects
 i.e. which methods are needed in which classes
 Objects can send messages to themselves (i.e. call their own
methods)
 Messages may be numbered & nested
 Parameters may be passed
 Values may be returned using assignment :=
 Return is often assumed (not shown on the diagram)
 You may also see diagrams without the ‘activation box’ shown
 Not all case tools use Return from synchronous
 arrows in the same way Synchronous (procedure)
Asynchronous (concurrent)
10
Control logic in Interaction
Diagrams
 Conditional Message
 [ variable = value ] : message()
 Message is sent only if clause evaluates to true
 Iteration (Looping)
 * [ i := 1..N ]: message()
 “*” is required; [ ... ] clause is optional
 Communication diagrams add Seq. Numbers
before conditional messages or loops

11
 Order price : centralised
calculate
control
anOrder anOrderEntry aProduct

Price
getQuantity

getProduct
See how the
calculatePrice
getPricingDetails
method in
Order calls one calc OrderEntry
of its own Price
methods product : Product
quantity : int
Code in Order
int quantity = entry.getQuantity(); + getProduct: Product
Product prod = entry.getProduct(); + getQuantity : int
double cost = prod.getPricingDetails();
double entryCost = this.calculatePrice(quantity, cost);
12
 Order price : distributed control
anOrder anOrderEntry aProduct

calculatePrice
calcPrice
getPrice
(quantity)

OrderEntry
Code in Order
double entryCost = entry.calcPrice(); product : Product
Quantity : int
Code in OrderEntry + calculatePrice()
public double calculatePrice() { : double
return product.getPrice(quantity);
}
13
Communication diagram

 Previously called Collaboration diagram in old

version of UML
 Called communication diagrams in UML 2
 UML 2 Communication diagrams used to model
the dynamic behavior of the use case.
 When compare to Sequence Diagram, the
Communication Diagram is more focused on
showing the collaboration of objects rather than
the time sequence.

14
Communication diagram

15
Communication diagrams
 Also shows interaction between classes, but
emphasises structural relationships between
objects
 The sequences of messages shown in
sequence diagrams can then be super-imposed
on these, with their arrows following the links.
 Wherever a message is to be sent, there must
be a link and, by implication, an association
must exist between the classes.
 Furthermore, the association must be navigable in
the required direction.

16
Basics

 Each object is shown as rectangle, which is

labelled objectName: className
 Underlined in earlier versions of UML
 Objects are linked through message paths
 Links between objects are shown like associations
in the class model
 Messages are attached to the message paths
 The class of the object at the point of the arrow
must provide the appropriate operation
 Messages have a sequence number to denote time

 Actors can be shown as on a use case diagram

17
 Communication diagram with
nested decimal numbering
Centralised control

1 : calculatePrice

1.5.1 : getDiscountInfo
1.4 : calculateBasePrice an Order a Customer
1.5 :calculateDiscounts

1.3 : getPricingDetails
1.1 : getQuantity
1.2 :getProduct

an Order Line a Product

18
 Communication diagram with
numbering
Distributed control
1 : calculatePrice

4 : getDiscountedValue
an Order A Customer
5 : getBaseValue

2 : calculatePrice

an Order Line a Product

3 : getPrice

19
Summary
 Sequence & Collaboration diagrams together form the interaction
diagrams
 These diagrams describe the same information, and can be
transformed into one another
 Both describe the flow of messages between objects
 Sequence diagrams focus on the order in which the messages are sent.
Useful for describing the procedural flow through many objects, and for
finding race conditions in concurrent systems
 Collaboration diagrams focus on relationships between objects, Useful
for visualising the way several objects collaborate to get a job done, and
for comparing a dynamic model with a static model
 Choose depending on what you want to make visually apparent

20
Activity Diagram

 Interaction diagram looks at the objects that

pass messages
 Activity diagram looks at the operations that are
passed among objects
 The semantic difference results in a very different
way of looking at the world
 Activity diagrams commonly contain
 Activity states and action states (simply Activity)
 Transitions
 Objects

21
Action state

 A simple action state represents processing.

 For example, the project management system
may have the following simple action states:
 Project Manager Enters Report Criteria
 Indicates that the project manager enters
report criteria
 Project Management System Generates Report
 Indicates that the project management
system generates a report
 Printer Prints Report
 Indicates that the printer prints the report

22
Initial and final state, transition

 An initial action state indicates the first

action state on an activity diagram.
 A final action state indicates the last
action state on an activity diagram
 A control-flow transition indicates the
order of action states

23
Illustration

24
Object-Flow Transitions
 An object-flow transition indicates that an action state
inputs or outputs an object.
 For example, the action states shown previously may
have inputs and outputs as follows:
 Project Manager Enters Report Criteria
 Outputs a Report Criteria object and may be renamed as
the Project Manager Enters Data action state
 Project Management System Generates Report
 Inputs the Report Criteria object and outputs a Report
object and may be renamed as the Project Management
System Generates Information action state
 Printer Prints Report
 Inputs the Report object and may be renamed as the
Printer Prints Information action state

25
Control-flow and object-flow
transitions

26
Swimlanes

 a swimlane is a visual region in an activity

diagram that indicates the element that has
responsibility for action states within the region
 swimlanes allows to rename the action states to
omit the responsible element for each action
state
 A swimlane is shown as a visual region
separated from neighboring swimlanes by
vertical solid lines on both sides and labeled at
the top with the element responsible for action
states within the swimlane

27
Swimlanes

28
Decision and Concurrency

 A decision involves selecting one control-flow

transition out of many control-flow transitions
based upon a condition.
 For example, once a report is printed by the project
management system, other reports may be
selected and printed if the project manager
chooses to print more reports.
 Concurrency involves selecting multiple
transitions simultaneously.
 For example, while the printer is printing a report,
the printer must also monitor for other incoming
print requests.

29
Decision

30
Concurrency

31
UML Diagrams hierarchy

32
State Chart Diagram

 Goal:
 Position processing with respect to states
of the classes
 Show the sequence of different states of a
class
 Constitutive elements
 State
 transitions
 events
33
State

 It is a sustainable situation that may be

the objects of a class
 Example: "Order" can be
 "In Preparation"
 " In progress "
 Predefined/particular states
 Initial state
 end State

34
Transitions and Events

 A transition is a relationship between two

states
 => Transition from one state to another
 Event causes a state change
 A transition is accompanied by the event
that causes the change

35
State description

 Actions / activities can be carried in the

input or output of state
 Action: elementary operation and
instantaneous
 Activity: operation that lasts
 can be assimilated to a state
 Necessarily associated with a condition

36
 Description formalism

State In Preparation
Entry:
Input action - select providers
- determine initial quantities
Events:
- New price : revaluation
- new needs: update
Do :
Activity - preparation of the order
Exit :
Output action - register expedition date
- send to provider

37
 Formal description of a process
Open market

Initiated
Do: check customer
Waiting client signature
entry: ICL sends DM to buyer Deadline
expired

Buyer sign DM
End of process Pending review
Do: examine Demand

DR sends agreement
to ICL
Deadline occurs

Close market
Do: settle market Proceed market

Market is over
38
Customer incident
Points clés

 Diagramme d’interaction
 Utilisé lorsqu’on veut montrer le comportement de
plusieurs objets dans un cas d’utilisation
 Intéressant pour exprimer la collaboration entre
plusieurs objets
 Il ne précise pas la définition d’un comportement

 Diagramme d’état-transition: montre le

comportement d’un objet unique a travers
plusieurs cas d’utilisation
 Diagramme d’activité: montre le comportement
de plusieurs threads ou cas d’utilisation

39