Object-Oriented Design

Maintenance Further

Necessary to investigate the Development
Operations mode
precise behaviour of the
system to complete
Software Engineering descriptions of classes
Implementation and
Integration phase

UML provides a number of Implementation

phase
alternatives for representing Object-Oriented
Lecture 8 the behaviour of systems Design phase

So what happens inside classes?
Examine documentation to

Object-Oriented
Behavioural Modelling I produce diagrams Analysis phase
– Use Cases / Scenarios Requirements
phase
– CRC cards
– Class Diagrams

Dynamic Modelling: State

Moving on From Class Diagram Diagrams

Classdiagrams give a basis for the
Create a state diagram explaining the
operation of each class
structure of the system

State represented by:
– divides program up in manageable units

Predicate or guards (Boolean expressions)

NextStep: Need to model behaviour of shown in [ ]
each class

Actions within states indicated by keyword
– i.e. what happens inside each class DO
– need a way to write the behaviour down
Initial state shown by:
– (N.B. use second class diagram from lecture 6)
Final State shown by:
 State Diagram State Diagram

Identifies States an object may pass through together with
States belong to a single class and represent
stimuli that change state for a given class
combinations of attribute values that may occur

Identified by ellipse containing name, variables and actions
(not all necessarily stated)
An event is something which triggers a state
transition (not necessarily belonging to a class)
Full Version – caused by object receiving a message
State
State Variables
– certain condition being met
Cut down versions
Condition is a Boolean expression
Event / Action description

Transition
State State
State State event(Arguments)
State
[condition]
State Variables Event / Action description

Another
straightforward class,

Straightforward class,
Button Class : Lift / Floor merely process each
request and return to Lift Class
waiting state
Requests are either to
turn the button on or
off Open Doors() Close Doors()

Button initial state Lift wait state

[Button on [Button off

request] Request]
Process Open Request Floor Up() Process Close Request

do / Open Doors Floor do / Close Doors

Down()
Process On Request Process Off Request

do/ turn on button do/ turn off button Process Down Request
Process Up Request

do/ move up 1 floor do / move down 1 floor

[button [No Another Example: Airline
pushed, Requests
already lit]

Lift Wait Loop

Pending]

Deals with events for
Seat Reservation
Cancel() Reserve()
– opening / closing flight reservation, [freeSeats >1] [freeSeats >1]
[button [Lift [Lift stopped,
pushed, moving in request
cancelling flight
button unlit] direction d] pending] – reserving / cancelling a booking

Stop Requested Reserve()

Process Button
Close Lift Doors No Reservation Partially reserved
Do / Turn on Button Do / Check Requests Cancel()
Do / Add Request Do / Close Doors [reservedSeats =1]
[Request to OpenFlight() CancelFlight()
stop at current Do / Turn off floor button
Close() Cancel() Reserve()
[No Request floor] Do / Move Lift one floor
to stop at [freeSeats =1]
current floor] in direction of next
Stop At Floor request
Do / Cancel Request
Continue Moving
Do / Move lift one
Do / Open Doors
Do / Turn off Lift and Controller
Only Significant class
Flight Closed
Close()
Fully Booked
floor in direction d Floor Buttons Consider all the various scenarios
Not easy to get right first time!
Needs to be kept under review

An Example Scenario (Lecture 2)

Collaboration Diagram 1. User A presses UP floor button at floor 3 to request elevator. User A
wishes to go to floor 7

Next need to model interactions between objects 2. UP floor button is turned on

Shows interactions between objects for a given 3. An elevator arrives at floor 3. It contains User B who has entered the
scenario elevator at floor 1 and pressed the elevator button for floor 9
4. UP floor button is turned off

Objects shown as rectangular boxes Object
5. Elevator doors open. User A enters elevator.

Messages are noted on association lines between 6. User A presses elevator button for floor 7
objects with arrows showing the direction of the 7. Floor 7 elevator button is turned on
8. Elevator doors close
message
9. Elevator travels to floor 7

Sequence numbers used to record chronology of 10. Floor 7 elevator button is turned off
messages 11. Elevator doors open to allow User A to exit.
12. Timer starts. User A exits
1: message
Object1 Object2 13. Elevator doors close after timeout
14. Elevator proceeds to floor 9 with User B
 Collaboration Diagram for
Lecture 2 Scenario Complete Class Diagrams
Floor Button
Collaboration Diagrams show what messages
4. Turn off light
need to be sent
2. Turn on light 9. *Move up 1 floor

Use these to associate operations with the
5. Open Doors classes
1. Press floor button 3. *Move up 1 floor
Lift Controller Lift
Does sender or recipient perform operation?
6. Press lift button 8. Close Doors
User 11. Open Doors
– Use rule that state variables should only be
7. Turn on light 13. Close Doors
Study each scenario 12. Wait
14. *Move up 1 floor accessible within a class (or subclass)
and build a 10. Turn off light
collaboration diagram – Also if an action is required in a number of places,
to show what object
interactions (messages) Lift Button
place implementation (method) within a single
are required by each class
step in the scenario

Include Operation on Class

Diagram Summary
Button
illuminated:Boolean
T
Need to complete Class Diagrams and clarify
Turn button on {abstract}
Turn button off {abstract} behaviour within a class and between classes

Behavioural Diagrams used to clarify system
operations and inter-class messages
Lift Button Lift Controller Floor Button
m×n 1 1 2m-2 – State Diagrams
Turn button on
Turn button off
Turn button on
Models behaviour within a class
1 n Turn button off
– Collaboration Diagrams
Lift
doors open:Boolean
Remaining
Models inter-class communication
Open Doors operations in Lift
Close Doors Controller
Move up 1 Floor
Move down 1 floor