Software EngineeringSoftware Engineering

Object-Oriented Analysis (State and Interaction Diagrams)

James Gain

(jgain@cs.uct.ac.za)

http://people.cs.uct.ac.za/~jgain

ObjectivesObjectives

1. Show the object-behaviour design process

2. Introduce the UML interaction and state diagram notations

3. Provide case study interaction and state diagrams

4. Do an exercise on interaction diagrams

Analysis = Process + ModelsAnalysis = Process + Models

Process Model Output

1. Elicit customer requirements and identify use-cases

Use-Case Diagrams

2. Extract candidate classes, Identify attributes and methods

Class Responsibility Collaborator (CRC) Cards

3. Build an object-relationship model (structural)

Conceptual Class Diagram

4. Build an object-behaviour model (dynamic)

Interaction and State Diagrams

Object-Behavioural ModellingObject-Behavioural Modelling

CRC and object-relationship model static Object-behaviour model dynamic (function of

specific events and time) Process:

1. Evaluate use-case narratives 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 important parts of the system

5. Review model to verify accuracy and consistency

Event IdentificationEvent 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

Case Study: Event IdentificationCase Study: Event Identification

Use-Case Narrative: A transparent overlay image is placed over the original reference picture.

The draftsman draws black edges of a consistent thickness onto the overlay using the mouse.

The draftsman is also able to erase edges that are incorrect from the overlay.

The draftsman can save the overlay as a black and white image with the same resolution as the reference picture.

Sample Events:

1. “placed over” provides event “place overlay” transmitted between reference picture and overlay. DOES NOT alter flow of control.

2. “draws” provides event “draw” between draftsman and edge. DOES NOT alter flow of control.

3. “onto overlay” provides event “store edge” between edge and overlay. DOES NOT alter flow of control.

Exercise: Event IdentificationExercise: Event Identification

Use-Case Narrative: 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.

Exercise: Identify the events Determine the parties involved in the event Determine if the event will alter the flow of control

Solution: Event IdentificationSolution: Event Identification

Use-Case Narrative: 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.

Events:1. “key in” provides event “password entered” transmitted between

homeowner and control panel. Does NOT alter flow of control.

2. “password is compared” provides event “password compared” transmitted between system and control panel. DOES alter flow of control.

3. “will beep” provides event “panel beeps” between control panel and homeowner. Does NOT alter flow of control.

Interaction DiagramsInteraction 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 DiagramsSequence 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 rectangle in an object lifeline represents the time when the object is active

Case Study: Sequence DiagramCase Study: Sequence DiagramObject

Life LineActive

Event

NotationNotation

Construct Description Syntax

Deletion Indicates that an object has been terminated

Asynchronous Message

Message that does not block the caller (which carries on with its own processing)

Return Message Return from a previous message (can be omitted)

Self-Call A message that an object sends to itself

Control InformationControl Information

Only use these if they help with clarity

Examples:

Construct Description Syntax

Condition A message is sent only when the condition is satisfied

[condition]

Iteration marker Message is sent many times to multiple receiving objects

*[iteration control]

[sensor active] deactivate

*[all particles] Generate

Further ExampleFurther Example

Transaction

Transaction Coordinator

new

beInvalid

new

new

new

Transaction Checker #1

Transaction Checker #2

fail

Kill checker

Kill

Collaboration DiagramsCollaboration Diagrams

Objects are shown as icons, arrows indicate messages and sequence is indicated by a decimal numbering scheme.

Otherwise similar to sequence diagrams

Case Study:

Voronoi Diagram Particle

Designer Direction Field

1.1 Generate

1.2 Render

1.3 Revise Position

1.1.1 Get Direction

1.1.2 Return Direction

1 Initiate

State DiagramsState 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 DiagramBasic UML State Diagram

stop

/ctr := 0stop [user quits]

Final State

Done

Ready

Transition

Initial Pseudostate

Action

Event

State

Guard

State ComponentsState 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 Activity represents a process which is longer than a

transition action and can be interupted

Label

do/activity

Case Study: Voronoi Diagram StateCase Study: Voronoi Diagram State

Initiating[no. particles = n]

Generate Particles

Rendering

Project Particles

Repositioning

[no. iterations <= m]

Centering

Find Centroids

[no. iterations > m]

Projection complete

Centroids calculated

Alter Positions

Exercise: Control Panel StateExercise: Control Panel State

Create a state diagram from the following narrative: 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.

Awaiting Input

ValidatingPassword entered

[password = correct]

[password = incorrect] / beep & reset

Compare Password

SuperstatesSuperstates

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

DispatchingWaitingChecking

Cancelled

Active

Static Conditional BranchingStatic Conditional Branching

A graphical shortcut for convenient rendering of decision trees

Selling Happy

Unhappy

bid

[value >= 200] / sell

[(value >= 100) & (value < 200)] / sell

[value < 100] / reject

Summary: Object-Behavioural Summary: Object-Behavioural ModelsModels

State diagrams are good at describing the behaviour of a single object across several use-cases

Interaction diagrams useful for describing the behaviour of several objects in a single use case

Two flavours of interaction diagrams: Sequence Diagrams: Objects in the horizontal, time in the

vertical Collaboration Diagrams: Objects connected by numbered

events Roughly equivalent

Use each object-behaviour diagram in the situation for which it is most appropriate

Summary: AnalysisSummary: Analysis

the problemrequirements

elicitation

build aprototype

createanalysismodels

developSpecification Review

Summary: Process + ModelsSummary: Process + Models

Process Model Output1. Elicit customer

requirements and identify use-cases

Use-Case Diagrams

2. Extract candidate classes, Identify attributes and methods

Class Responsibility Collaborator (CRC) Cards

3. Build an object-relationship model (structural)

Conceptual Class Diagram

4. Build an object-behaviour model (dynamic)

Interaction and State Diagrams