21
Software Engineering Software Engineering OO Analysis (Object-Behaviour Models)

Software Engineering OO Analysis (Object-Behaviour Models)

Embed Size (px)

Citation preview

Page 1: Software Engineering OO Analysis (Object-Behaviour Models)

Software EngineeringSoftware Engineering

OO Analysis

(Object-Behaviour Models)

Page 2: Software Engineering OO Analysis (Object-Behaviour Models)

ObjectivesObjectives

To show the object-behaviour design process

To introduce the UML interaction and state diagram notations

Page 3: Software Engineering OO Analysis (Object-Behaviour Models)

Analysis = Process + ModelsAnalysis = Process + Models

Process Model Output1. Elicit customer

requirements and identify use-cases

Use-Case Diagrams

2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy

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

Page 4: Software Engineering OO Analysis (Object-Behaviour Models)

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

Page 5: Software Engineering OO Analysis (Object-Behaviour Models)

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

Page 6: Software Engineering OO Analysis (Object-Behaviour Models)

Example: Event IdentificationExample: 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)

Page 7: Software Engineering OO Analysis (Object-Behaviour Models)

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)

Page 8: Software Engineering OO Analysis (Object-Behaviour Models)

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 thin rectangle in an object lifeline represents the time when the object is the controlling object in the system

Page 9: Software Engineering OO Analysis (Object-Behaviour Models)

Example: Sequence DiagramExample: Sequence Diagram

Homeowner Control Panel

System

system ready

enters password

ready for activation/deactivation

selects stay or away

ready for next action

initiates beep

activate/deactivate sensors

red light on request

Object

Life Line

Active Event

Page 10: Software Engineering OO Analysis (Object-Behaviour Models)

Further NotationFurther Notation

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 prcoessing)

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

Self-Call A message that an object sends to itself

Page 11: Software Engineering OO Analysis (Object-Behaviour Models)

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

*[for all items] add

Page 12: Software Engineering OO Analysis (Object-Behaviour Models)

Further ExampleFurther Example

Transaction

Transaction Coordinator

new

beInvalid

new

new

new

Transaction Checker #1

Transaction Checker #2

fail

Kill checker

Kill

Page 13: Software Engineering OO Analysis (Object-Behaviour Models)

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

Example:

HomeownerControl Panel System

1: enters password

1.2: ready for (de)activation

2: selects stay or away

2.3: ready for next action

1.1: initiates beep

2.1: activate/deactivate sensors

2.2: red light on request

Page 14: Software Engineering OO Analysis (Object-Behaviour Models)

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

Page 15: Software Engineering OO Analysis (Object-Behaviour Models)

Basic UML State DiagramBasic UML State Diagram

stop

/ctr := 0stop [user quits]

Final State

Done

Ready

Transition

Initial Pseudostate

Action

Event

State

Guard

Page 16: Software Engineering OO Analysis (Object-Behaviour Models)

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 (with syntax do/activity) represents a process which is longer than a transition action and can be interupted

Label

do/activity

Page 17: Software Engineering OO Analysis (Object-Behaviour Models)

Example: Control Panel StateExample: Control Panel State

At Rest Comparing

Reenter

Selecting

Password entered

[Compare password = correct]

[Compare password = incorrect]

[Compare password = incorrect]

activation successful

[Compare password = correct]

Page 18: Software Engineering OO Analysis (Object-Behaviour Models)

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

Page 19: Software Engineering OO Analysis (Object-Behaviour Models)

Static Conditional BranchingStatic Conditional Branching

A graphical shortcut for convenient rendering of decision trees

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

[value >= 200] /sell /sell

[value < 100] /reject /reject

SellingSellingSellingSelling

UnhappyUnhappyUnhappyUnhappy

HappyHappyHappyHappy

bidbid

Page 20: Software Engineering OO Analysis (Object-Behaviour Models)

SummarySummary

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

Page 21: Software Engineering OO Analysis (Object-Behaviour Models)

AnalysisAnalysis

the problemrequirements

elicitation

build aprototype

createanalysismodels

developSpecification Review