UML OOD Purpose of design

1
UML OOD - Purpose of design
0
It is important to keep in mind at all times
during the design process the following primary
purposes of design - To decompose the
problem and its solution into smaller, more
manageable components. To keep the structure
simple and understandable to aid maintenance.
To create reusable components if possible.
2
UML OOD Case study - Parking system
1
A city council is to implement a computer based
automatic urban car parking and traffic
management system. In the central shopping area
of the city there are a number of car parks. Each
car park has several entry lanes and exit lanes.
These are controlled by automatic barriers which
work in the following way - Entry barriers
- When a car reaches a barrier, the motorist
presses a button to obtain a ticket. When the
ticket is pulled from the ticket printer, the
barrier is raised. It is lowered again when the
motorist drives over a sensor buried in the entry
lane on the inner side of the barrier. A
computer keeps a record of the number of spaces
in the car park and when the car park becomes
full, a full sign is illuminated at all entry
barriers, which then stops the printing of
tickets until the car park again has spaces.
Exit barriers - When a motorist wishes to leave
the car park, they must insert an exit ticket
(see below) into a ticket reader associated with
the exit lane. If the ticket is valid, the
barrier is raised and lowered again when the
driver drives over a sensor buried in the exit
lane on the outside of the barrier. Payment
machine - At various strategic points around the
shopping area, both near to shops and near to car
parks, are sited a number of payment machines.
The motorist inserts the ticket issued on entry
to a car park and is then asked for a fee.
On payment of the fee, an exit ticket is printed
which can be used (within a grace period) to
operate the exit barrier. Other
functionality - A central computer monitors the
state of the car parks and updates a set of
direction signs which are placed at important
junctions around the town centre and point to the
direction to be taken (left, right, straight-on)
to the nearest car park with spaces. Two other
functions of the system are to record the spaces
available in each car park once an hour and to
record the number of motorists parking for one
hour, two hours etc.
3
UML OOD Case study - Finding objects
2
A city council is to implement a computer based
automatic urban car parking and traffic
management system. In the central shopping area
of the city there are a number of car parks. Each
car park has several entry lanes and exit lanes.
These are controlled by automatic barriers which
work in the following way - Entry barriers
- When a car reaches a barrier, the motorist
presses a button to obtain a ticket. When the
ticket is pulled from the ticket printer, the
barrier is raised. It is lowered again when the
motorist drives over a sensor buried in the entry
lane on the inner side of the barrier. A
computer keeps a record of the number of spaces
in the car park and when the car park becomes
full, a full sign is illuminated at all entry
barriers, which then stops the printing of
tickets until the car park again has spaces.
Exit barriers - When a motorist wishes to leave
the car park, they must insert an exit ticket
(see below) into a ticket reader associated with
the exit lane. If the ticket is valid, the
barrier is raised and lowered again when the
driver drives over a sensor buried in the exit
lane on the outside of the barrier. Payment
machine - At various strategic points around the
shopping area, both near to shops and near to car
parks, are sited a number of payment machines.
The motorist inserts the ticket issued on entry
to a car park and is then asked for a fee.
On payment of the fee, an exit ticket is printed
which can be used (within a grace period) to
operate the exit barrier. Other
functionality - A central computer monitors the
state of the car parks and updates a set of
direction signs which are placed at important
junctions around the town centre and point to the
direction to be taken (left, right, straight-on)
to the nearest car park with spaces. Two other
functions of the system are to record the spaces
available in each car park once an hour and to
record the number of motorists parking for one
hour, two hours etc.
4
UML OOD Case study - Finding objects
3
Extracting the candidate objects and removing
plurals, the initial list of candidate objects
becomes -
city council computer based urban car
parking traffic management system. central
shopping area city car park entry
lane exit lane barrier entry barrier
car motorist button ticket ticket
printer sensor record number of
spaces full sign exit barrier exit
ticket ticket reader driver payment
machine strategic point shopping
area shop fee payment grace
period central computer state direction
sign junction town centre direction
5
UML OOD Case study - Finding objects
4
Deriving principle objects - refinement
The list of candidate classes will be excessively
long and contain many inappropriate items. These
should be filtered out by applying the
following criteria - Classes outside
scope of system Redundant classes -
synonyms Vague classes
Implementation classes Attributes of
other classes Verbs or events
Representing entities over which the system will
have no control. Different names referring to
the same concept. Non-specific concepts too
imprecise to define exactly. Parts of the final
computer system rather than the user
domain. Simple data values not warranting treatmen
t as an object - keep a note. Possibly methods in
other classes
6
UML OOD Case study - Finding objects
5
Objects outside the scope of the system -
city council computer based urban car
parking traffic management system. central
shopping area city car park entry
lane exit lane barrier entry barrier
car motorist button ticket ticket
printer sensor record number of
spaces full sign exit barrier exit
ticket ticket reader driver payment
machine strategic point shopping
area shop fee payment grace
period central computer state direction
sign junction town centre direction
Identify redundant objects from the remaining
candidates.
7
UML OOD Case study - Finding objects
6
Redundant objects (synonyms) -
computer based car park entry
lane exit lane barrier entry barrier
button ticket ticket printer sensor rec
ord number of spaces full sign exit
barrier exit ticket ticket reader paymen
t machine strategic point fee payment
grace period central computer state direct
ion sign direction
Identify vague objects from the remaining
candidates.
8
UML OOD Case study - Finding objects
7
Vague objects -
computer based car
park barrier entry barrier
button ticket ticket printer sensor rec
ord number of spaces full sign exit
barrier ticket reader payment
machine strategic point fee payment
grace period central computer state directio
n sign direction
Identify implementation objects from the
remaining candidates.
9
UML OOD Case study - Finding objects
8
Implementation objects -
car park barrier entry
barrier button ticket ticket
printer sensor record number of
spaces full sign exit barrier ticket
reader payment machine fee payme
nt grace period central computer state di
rection sign direction
Identify attributes from the remaining candidates.
10
UML OOD Case study - Finding objects
9
Attributes of objects -
car park barrier entry
barrier ticket ticket
printer number of spaces exit
barrier ticket reader payment
machine fee payment grace
period central computer state direction
sign direction
Identify verbs or events from the remaining
candidates.
11
UML OOD Case study - Finding objects
10
Verbs or events -
car park barrier entry
barrier ticket ticket
printer exit barrier ticke
t reader payment machine paymen
t central computer direction
sign
Identify the final classes and define them
12
UML OOD Case study - Class definitions
11
From the remaining objects it is possible to draw
up a provisional list of classes and to give a
clear definition of them.
car park this maintains space counts and
controls exit barriers - enabling or
disabling car entry. barrier super-class of
exit and entry barrier. entry barrier
controls entry to car park, issues ticket and
informs car park of car arrival - can be
inhibited. exit barrier controls exit from car
park and informs car park of car
departure. ticket represents a parking
transaction and can be used to provide data on
length of stay. - rename transaction. ticket
printer considered too detailed at this stage -
remove ticket reader considered too detailed at
this stage - remove payment machine debatable
whether this should be included as part of
the system, or a stand alone component -
keep for now. central computer acts as a
monitoring and control centre also
responsible for collecting, storing and
reporting statistics. direction
sign contains routing information to enable
choices on traffic direction.
Identify relationships between classes
construct class diagram
13
UML OOD Case study - Conceptual model
12
Initial class diagram
updates
Controlled by


monitors
stores



creates

Create a Use-Case diagram for the system
14
UML OOD Case study - Use case diagram
13
Car entry when full
ltltextendsgt
Car entry
Report statistics
Car exit
Develop event sequence diagrams for scenarios
15
UML OOD Case study - Determining object behaviour
14
In order to identify the interactions between
objects and hence the requisite behaviour of
objects (methods) we can take the following steps
- Allocate responsibilities to
objects. This follows the example of
Wirfs-Brock responsibility driven
design. Determine interaction
protocols. Identifying which object initiates
the dialog and how objects talk to each
other. Construct event-sequence diagrams for
scenarios. From the use-case diagram, each
functional requirement can be represented by an
example scenario.
16
UML OOD Case study - Allocating responsibilities
15
Barrier - raises the barrier to admit
car detects passage of car lowers barrier on
passage of car informs car-park of
arrival/departure Entry barrier - detects
ticket request prints ticket detects removal
of ticket disables operation when car-park
full Exit barrier - detects insertion of
ticket checks validity of ticket Car park
- creates transaction for parking
event updates and stores transaction on
departure maintains space occupancy
counts informs central system on car park
status informs entry barrier on car park status
17
UML OOD Case study - Allocating responsibilities
16
Central system- obtaining status information
from car parks informing direction signs of
car park states obtaining transactions from
car parks archiving car parking
transactions production of management
reports downloading tariff changes to payment
machines synchronizing car park and payment
machine clocks Direction sign - determination
of best route to nearest car park Payment
machine- detecting insertion of
ticket computing parking fee collecting
money printing/updating ticket updating
clock and tariff Transaction - recording car
park ID and entry/departure times
Determine interaction protocols between objects
18
UML OOD Case study - Interaction protocols
17
Car Park lt-gt Entry/Exit barrier car arrival
clearly an input event so entry informs car
park car departure similar disable/enable to
simplify car park and to avoid entry polling
car park in order to update full-sign, car
park should inform entry of change of
state. clock update again, as car parks are
informed from central system, they can best
pass this on to entries (and exits). Central
system lt-gt Car park state change direction signs
do not want to be changed rapidly, better for
central system to poll car-parks at
regular intervals.
Develop event-sequence diagram for car entry
19
UML OOD Case study - Event sequence diagrams
18
Scenario - Car entry
Driver
Ticket request
Print ticket
Create transaction
Ticket issued
Ticket taken
Raise barrier
Barrier raised
Car entry
Lower barrier
Add car
Barrier lowered,
Develop event-sequence diagram for car entry when
full
20
UML OOD Case study - Event sequence diagrams
19
Scenario - Car entry when full
Driver
Ticket request
Print ticket
Create transaction
Ticket issued
Ticket taken
Raise barrier
Barrier raised
Car entry
Lower barrier
Add car
Barrier lowered,
disable
Full sign on,
Develop event-sequence diagram for direction sign
update
21
UML OOD Case study - Event sequence diagrams
20
Scenario - Sign update
All parks
Timer pulse
Request status
Park status
All signs
Changes of state
Develop further sequence diagrams and revised
class diagram
22
UML OOD Case study - Conceptual model
21
Payment machine
Direction Sign
Central Computer
updates
Controlled by
Tariff data


Tariff data
Geographic data
SetTariffs Ticket insert Coin insert
Update
CarParkStatus
monitors

stores

Car Park
Transaction
SpaceCount

Arrival time Car Park Departure time
GetStatus GetTransactions
creates
Revised class diagram
SetDepartureTime GetInterval GetCarPark

Barrier
Raise Lower Car pass SetTime
Entry Barrier
Exit Barrier
State
Ticket insert Ticket validate
Enable Disable Ticket request Ticket take
Create a state chart for the entry barrier
23
UML OOD Case study - Statecharts
22
State chart for Entry Barrier
Disable/full sign off
Disabled
Idle
Enable/full sign on
Ticket request/ print ticket
Ticket request
Await Ticket Take
Car pass/ lower barrier, add car
Ticket taken/ raise barrier
Await Enable
Await Entry
Enable/ full sign off, print ticket
24
UML OOD Case study - Implementation Issues
23
So far we have been developing a conceptual model
of the system. In moving to an implementation
model some questions need to be asked - Should
extra (super) classes be introduced ? Should a
complex class be split into smaller components
? Should several simple components be combined
into one ? Should relationships (associations,
aggregations) be added/removed ? Should
associations be implemented one-way or
bi-directionally ? How should relationships be
implemented ? Should we introduce association
classes ? Should derived attributes be added
? What should the visibility of attributes and
methods be ? What data structures should we make
use of ? What algorithms are needed for method
code ? What are the non-functional constraints
and how can they be satisfied ? How should the
system be partitioned ? What re-usable
components can we develop ? What implementation
language is to be used ? How should system be
deployed on available hardware ? How is object
persistence handled ? What provisions are made
for security, integrity, reliability ?
25
UML OOD Case study - Implementation model
24
Central Computer
Payment machine ...
Controlled by
updates
-Tariff data Hashtable -Signs Vector -Archive
TransactionDataBase -CarParks
Hashtable -PayMachines Vector
Direction Sign ...


maintains
Transaction DataBase ...
void UpdateSigns() void UpdateTariffs()
void ReportStatistics()
monitors
uses

Car Park

- int SpaceCount
Transaction ...
boolean isFull() int getSpaces() Transaction
GetTransactions() void SetTime(int time) void
SetSpaces(int count)

creates

Barrier ...
26
UML OOD Case study - Systems architecture
25
Another early design consideration concerns the
overall system architecture. How many processors,
where located and how do they communicate
? Central system - Probably a dedicated
processor as it needs to query car parks and
update direction signs on a regular basis as
well as maintain a database and provide a
management interface. Direction signs - Little
need for any intelligence here. A simple matrix
sign. Car parks - Operations could be delegated
to a central system, but this gives a single
point of failure - unreliable. Hence need for
car park processors. Barriers - Operations
could be delegated to car park, but again a
single point of failure. Better to provide
local intelligence. Payment machines - Could
delegate to central system, but would result
in poor response times and again a single point
of failure. Conclusions Processors need as
follows - one per barrier, one for each car
park one central one
and one for each payment machine.
27
UML OOD Case study - Deployment diagram
26
Central system
DataBase

Direction sign
Transaction
ltltLANgtgt
ltltLANgtgt
Transaction
CarPark

Payment machine
ltltLANgtgt
Barrier