Let’s Do Analysis

1. Analyze the problem statement

 Identify functional requirements
 Identify nonfunctional requirements
 Identify constraints (pseudo requirements)
2. Build the functional model:
 Develop use cases to illustrate functionality requirements
3. Build the dynamic model:
 Develop sequence diagrams to illustrate the interaction between
objects
 Develop state diagrams for objects with interesting behavior
4. Build the object model:
 Develop class diagrams showing the structure of the system
Case Study: A Design Example
The interplay between static and dynamic models.
♦ There is a tendency among novice OO designers to put too
much emphasis upon static models. Static models depicting
classes, inheritance relationships, and aggregation relationships
are often the first diagrams that novice engineers think to
create. Disastrously, they are sometimes the only diagrams that
they create.
♦ In fact, a static emphasis on object oriented design is
inappropriate. Software design is about behavior; and behavior
is dynamic. Object oriented design is a technique used to
separate and encapsulate behaviors. Therefore an emphasis
upon dynamic models is very important.
♦ More important, however, is the interplay that exists between
the static and dynamic models. A static model cannot be
proven accurate without associated dynamic models. Dynamic
models, on the other hand, do not adequately represent
considerations of structure and dependency management.
A Cellular Phone

Consider the software that controls a very simple cellular

telephone. Such a phone has buttons for dialing digits, and a
“send” button for initiating a call. It has “dialer” hardware and
software that gathers the digits to be dialed and emits the
appropriate tones. It has a cellular radio that deals with the
connection to the cellular network. It has a microphone, a
speaker, and a display.

UML Tutorial: Collaboration Diagrams

Robert C. Martin
Engineering Notebook Column
Nov/Dec, 97
Question: Is this the right model?
Compare with the real world
“It is very hard to argue with this static model. The composition relationships reflect,
very clearly, the specification above. Indeed, the telephone “has” all the listed
components. But is this the correct static model? How would be know?”
More analysis: dynamic modeling
• How do the objects in the static model collaborate to execute this
procedure?
• The first thing that happens when this use case is initiated is that the user
presses a digit button to begin entering the phone number. How does the
software in the phone know that a button has been pushed?
• There are a variety of ways that this can be accomplished; but they can all
be simplified to having a Button object that sends a digit message. Which
object should receive the digit message?
• It seems clear that it should be the Dialer. The Dialer must then tell the
Display to show the new digit, and must tell the Speaker to emit the
appropriate tone. The Dialer must also remember the digits in the list that
accumulates the phone number. Each new button press follows the same
procedure until the “Send” button is pressed.
• When the “Send” button is pressed, the appropriate Button object sends the
Send message to the Dialer. The Dialer then sends a Connect message to the
CellularRadio and passes along the accumulated phone number. The
CellularRadio then tells the Display to illuminate the “In Use” indicator.
• The structure of the objects in the dynamic model is different from the
structure of the classes in the static model. However in a collaboration
diagram, a link between objects must be represented by a relationship
between the classes. Thus, we have a problem.
• The problem could be that our dynamic model is incorrect. Perhaps we
should force the dynamic model to look like the static model. However,
consider what such a dynamic model would look like.
• There would be a Telephone object in the middle that would receive
messages from the other objects.
• The Telephone object would respond to each incoming message with
outgoing messages of its own.
• Such a design would be highly coupled.
• The Telephone object would be the master controller.
• It would know about all the other objects, and all the other objects
would know about it.
• It would contain all the intelligence in the system, and all the other
objects would be correspondingly stupid.
• This is not desirable because such a “god” object becomes highly
interconnected. When any part of it changes, other parts of it may
break.
Note that a new class
called Connection is
developed and
should be added into
your class diagram.
Backup Slides
Problem Statement:
Direction Control for a Toy Car

1. Power is turned on 6. Power is turned off

 Car moves forward and car  Car stops and headlight goes
headlight shines out.
2. Power is turned off 7. Power is turned on
 Car stops and headlight goes  Headlight shines
out. 8. Power is turned off
3. Power is turned on  Headlight goes out.
 Headlight shines 9. Power is turned on
4. Power is turned off  Car runs forward with its
headlight shining.
 Headlight goes out.
5. Power is turned on
 Car runs backward with its
headlight shining.
Find the Functional Model: Do Use Case Modeling

♦ Use case 1: System Initialization

 Entry condition: Power is off, car is not moving
 Flow of events:
 Driver turns power on
 Car moves forward, headlight is on
 Exit condition: Car moves forward, headlight is on
♦ Use case 2: Turn headlight off
 Entry condition: Car moves forward with headlights on
 Flow of events:
 Driver turns power off, car stops and headlight goes out.
 Driver turns power on, headlight shines and car does not move.
 Driver turns power off, headlight goes out
 Exit condition: Car does not move, headlight is out
Use Cases continued
♦ Use case 3: Move car backward
 Entry condition: Car is stationary, headlights off
 Flow of events:
 Driver turns power on
 Car moves backward, headlight on
 Exit condition: Car moves backward, headlight on
♦ Use case 4: Stop backward moving car
 Entry condition: Car moves backward, headlights on
 Flow of events:
 Driver turns power off, car stops, headlight goes out.
 Power is turned on, headlight shines and car does not move.
 Power is turned off, headlight goes out.
 Exit condition: Car does not move, headlight is out.
♦ Use case 5: Move car forward
 Entry condition: Car does not move, headlight is out
 Flow of events
 Driver turns power on
 Car runs forward with its headlight shining
 Exit condition:
 Car runs forward with its headlight shining.
Use Case Pruning

♦ Do we need use case 5?

♦ Use case 1: System Initialization

 Entry condition: Power is off, car is not moving
 Flow of events:
 Driver turns power on
 Car moves forward, headlight is on
 Exit condition: Car moves forward, headlight is on

♦ Use case 5: Move car forward

 Entry condition: Car does not move, headlight is out
 Flow of events
 Driver turns power on

 Car runs forward with its headlight shining

 Exit condition:
 Car runs forward with its headlight shining.
Non-functional requirement

♦ Response time
♦ Reliability
♦ Others?
 Energy saving
 User friendly
 ……
Find the Dynamic Model: Create sequence diagram

♦ Name: Drive Car

♦ Sequence of events:
 Billy turns power on
 Headlight goes on
 Wheels starts moving forward
 Wheels keeps moving forward
 Billy turns power off
 Headlight goes off
 Wheels stops moving
 ...
Sequence Diagram for Drive Car Scenario

:Headlight Billy:Driver :Wheel

Power(on) Power(on)

Power(off) Power(off)

Power(on) Power(on)
Toy Car: Dynamic Model
Wheel
Headlight
Forward
Off power
power off
on
power power
off on

Stationary Stationary
On

power power
on
off

Backward
Now assuming a central controller,
draw a state chart diagram of the car?
Toy Car: Object Model

Car

Power Headlight Wheel

Status: (On, Off) Status: (On, Off) Motion: (Forward,

Backward,
TurnOn() Switch_On() Stationary)
TurnOff() Switch_Off()
Start_Moving()
Stop_Moving()
When is a model dominant?
♦ Object model: The system has objects with nontrivial state.
♦ Dynamic model: The model has many different types of events:
Input, output, exceptions, errors, etc.
♦ Functional model: The model performs complicated
transformations (e.g. computations consisting of many steps).
♦ Which of these models is dominant in the following three cases?
 Compiler
 Database system
 Spreadsheet program
 Elevator system
Dominance of models
♦ Compiler:
 The functional model most important. (Why?)
 The dynamic model is trivial because there is only one type input and
only a few outputs.
♦ Database systems:
 The object model most important.
 The functional model is trivial, because the purpose of the functions is
usually to store, organize and retrieve data.
♦ Spreadsheet program:
 The functional model most important.
 The dynamic model is interesting if the program allows computations on
a cell.
 The object model is trivial, because the spreadsheet values are trivial
and cannot be structured further. The only interesting object is the cell.
♦ Elevator system:
 The dynamic model most important.