Software Engineering
OO Analysis
(Object-Behaviour Models)
Objectives
1. To show the object-behaviour design process
2. To introduce the UML interaction and state
diagram notations
Analysis = Process + Models
Process
Model Output
1. Elicit customer
Use-Case Diagrams
requirements and identify
use-cases
2. Extract candidate classes,
Class Responsibility
Identify attributes and
Collaborator (CRC) Cards
methods, Define a class
hierarchy
3. Build an object-relationship Conceptual Class Diagram
model (structural)
4. Build an object-behaviour
model (dynamic)
Interaction and State
Diagrams
Object-Behavioural Modelling
 CRC and object-relationship model  static
 Object-behaviour model  dynamic (function of
specific events and time)
 Process:
1. Evaluate use-cases to understand the sequence of
system interaction
2. Identify events that drive the interaction sequence and
relate these to specific objects
3. Create an interaction diagram for each use-case
4. Build a state diagram for the system
5. Review model to verify accuracy and consistency
Event Identification
 Events occur whenever the system and an actor
exchange information
 Events are boolean: not the information but the
fact that information is or is not exchanged
 Examine the use-case narratives for points of
information exchange
 Some events have an impact on the flow of control
 Next allocate events to objects. Some will generate
and other recognize events
Example: Event Identification
 Use-Case Narrative:
 The homeowner observes the control panel to determine if the
system is ready for input. If the system is not ready, the homeowner
must physically close window/doors so that the ready indicator is
present [a not ready indicator implies that a sensor is open].
 The homeowner uses the keypad to key in a four-digit password.
The password is compared with the valid password stored in the
system. If the password is incorrect, the control panel will beep once
and reset itself for additional input. If the password is correct, the
control panel awaits further action.
 Typical Event:
 homeowner uses the keypad to key in a four-digit password.
 Event “password entered” transmitted between homeowner and
control panel
 Does not alter flow of control (but “password compared” does)
Interaction Diagrams
 A model that describes how groups of objects
collaborate in some behaviour
 Captures interaction in a single use case
 To look at a single object across many use cases
employ state diagrams
 Works for a sequential process without conditional
or looping behaviour
 Two flavours:
 Sequence (emphasise the sequence of events)
 Collaboration (use layout to indicate how objects are
statically connected)
Sequence Diagrams
 Sequence models show the sequence of object
interactions that take place
 Objects are arranged horizontally across the top
 Time is represented vertically so models are read top to
bottom
 Each object has a vertical life-line representing its
period of existence
 Interactions (events) are represented by labelled arrows.
Different styles of arrow represent different types of
interaction
 A thin rectangle in an object lifeline represents the time
when the object is the controlling object in the system
Example: Sequence Diagram
Control
Panel
Homeowner
Object
System
system ready
enters password
initiates beep
ready for activation/deactivation
Active
selects stay or away
Event
activate/deactivate sensors
Life Line
red light on request
ready for next action
Further Notation
Construct
Description
Deletion
Indicates that an object has
been terminated
Asynchronous
Message
Message that does not block
the caller (which carries on
with its own prcoessing)
Return Message
Return from a previous
message (can be omitted)
Self-Call
A message that an object sends
to itself
Syntax

Control Information
Construct
Description
Condition
A message is sent only when
the condition is satisfied
Iteration marker
Message is sent many times to
multiple receiving objects
 Only use these if they help with clarity
 Examples:
[sensor active] deactivate
*[for all items] add
Syntax
[condition]
*[iteration
control]
Further Example
new
Transaction
new
Transaction
Coordinator
Transaction
Checker #1
new
new
Transaction
Checker #2
fail

Kill checker
Kill
beInvalid


Collaboration Diagrams
 Objects are shown as icons, arrows indicate messages and
sequence is indicated by a decimal numbering scheme.
 Otherwise similar to sequence diagrams
 Example:
1: enters password
1.2: ready for (de)activation
Homeowner
2: selects stay or away
2.3: ready for next action
1.1: initiates beep
Control
Panel
2.1: activate/deactivate sensors
2.2: red light on request
System
State Diagrams
 Objects can be either:
 passive (current status of attributes)
 active (status as it undergoes a continuous transformation)
 State diagrams concentrate on the active states of a single
event-driven object
 An event occurs to force an object to make a transition
from one active state to another
 Events must be discrete rather than continuous
 Begin with externally observable states. Later, you can
refine these states into behaviours that are not evident from
outside the system
 State diagrams owe much to the theory of finite automota
Basic UML State Diagram
State
Ready
Event
Initial Pseudostate
stop [user quits] /ctr := 0
Transition
Done
stop
Final State
Guard
Action
State Components
 Transitions:
 Three parts, all optional Event [Guard] / Action
 Events (or triggers)
 Guard is a logical condition returning “true” or “false”. Transition
occurs only if the condition is true. Guards exiting a state must be
mutually exclusive
 Action represents a processes which occurs quickly and is not
interruptible
 States:
 Two parts, label and activity
Label
do/activity
 Activity (with syntax do/activity) represents a process which is
longer than a transition action and can be interupted
Example: Control Panel State
[Compare password = incorrect]
[Compare password = incorrect]
At Rest
Password
entered
Comparing
Reenter
[Compare password = correct]
Selecting
[Compare password = correct]
activation
successful
Superstates
 If several states have the same transition (e.g.
cancel) then a superstate can enclose them with a
single transition
 Substates inherit the transitions of the superstate
Active
Cancelled
Checking
Waiting
Dispatching
Static Conditional Branching
 A graphical shortcut for convenient rendering of
decision trees
Selling
bid
[value >= 200] /sell
[value < 100] /reject
[(value >= 100) & (value < 200)] /sell
Unhappy
Happy
Summary
 State diagrams good at describing the behaviour of
an object across several use-cases
 Interaction diagrams useful for describing the
behaviour of several objects in a single use case
 Use each in situations for which it is most
appropriate
Analysis
build a
prototype
requirements
the problem
elicitation
develop
Specification
create
analysis
models
Review