OO Analysis and Design
CMPS 2143
2
OOA/OOD
• Cursory explanation of OOP emphasizes
▫ Syntax
 classes, inheritance, message passing, virtual, static
• Most important aspect:
▫ Design technique to create a universe of autonomous
interacting agents
▫ We will focus on the OOD technique called responsibilitydriven design
3
Responsibility
• Implies degree of independence and noninterference
• Client code doesn’t need to worry about
representation/implementation
• Responsibility design elevates information hiding from a
technique to an art.
▫ Vitally important for “programming in the large”
4
Begin with Behavior
• Why?
▫ Usually it is understand long before any other aspect
• Do this before data structures / order of function calls
• Structural elements usually only understood after
considerable amount of analysis
• Customers understand system behavior
5
OOA: Describing a system
• Initial system specifications are sketchy, ambiguous
• Often describe actions to be performed  behavior
▫ Perfect for responsibility driven design
• How? With scenarios
▫ Act out the running of the application – example in book
• Use these to rewrite the specifications
• THEN identify components
▫ Component == abstract entity that can perform tasks to
fulfill responsibilities
6
Characteristics of a Component
• Must have a small, well-defined set of responsibilities
• Interacts with other components to the minimal extent
possible
Component-ResponsibilityCollaborator (CRC) Modeling
• OOA classes have “responsibilities”
▫ Responsibilities are the attributes and operations
encapsulated by the component/class
• OOA classes collaborate with one another
▫ Collaborators are other components/classes that are
required to provide a component/class with the
information needed to complete a responsibility.
▫ In general, a collaboration implies either a request for
information or a request for some action.
7
8
Identifying Components
• Analyze specifications (problem description) and
scenarios
• Underline nouns/circle verbs (ignore system, data,
information….too vague)
• Nouns  components or attributes of components 
classes and member data
• Verbs  responsibilities of components  methods
CRC Modeling - Use index cards
Class:
Class:
Description:
Class:
Description:
Class: FloorPlan
Description:
Responsibility:
Description:
Responsibility:
Responsibility:
Responsibility:
Collaborator:
Collaborator:
Collaborator:
Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows
Wall
shows position of video cameras
Camera
9
10
Why you should use index cards!!!
• Cheap, widely available, erasable
• Encourages EXPERIMENTATION
▫ Try different designs, throw them away…
• Forces you to keep components PHYSICALLY separate
• Constrains complexity
▫ Divide components
▫ Move some responsibilities
• Start of documentation
Example-Vending Machine
Let us take an example application and examine the
process of identifying the objects/classes and
describe their responsibilities using CRC cards.
The example application is a Vending Machine that
allows users to buy snack items. In addition, a user
can find out the caloric content of her choice.
11
Example-Vending Machine
Specification :
A Vending machine holds a number of snack items and
displays the list of snack items and their prices
through an user interface with a display screen and
buttons for making selections. In addition, the
vending machine has a receptacle for money and an
item dispenser.
A user can make a selection and query for the number
of calories of a snack item. The calories are displayed
on pressing a button. A user can place the money in
the receptacle and select an item.
12
Example-Vending Machine
Step 1: Let us seelct the nouns and the verbs in the
specification.
Nouns are in blue and the verbs are in green.
A Vending machine holds a number of snack items
and displays the list of snack items and their prices
through an user interface with a display screen and
buttons for making selections. In addition, the
vending machine has a receptacle for money and an
item dispenser.
A user can make a selection and query for the number
of calories of a snack item. The calories are
displayed on pressing a button. A user can place the
money in the receptacle and select an item.
13
Example-Vending Machine
Most of the nouns are objects/classes.
Some nouns are attributes of these classes.
The verbs are actions that can be attached to these
objects.
In order to focus on the problem-domain objects, let
us separate the object/classes into presentationspecific (user-interface related) and problem-specific
classes.
We will then select two problem specific classes and
write the CRC cards for them.
14
15
Example-Vending Machine
Problem-specific classes:
• Vending Machine
• Snack item
• Price
• Calories
• Selection
• User
Presentation-specific classes:
• Display screen
• Selection Buttons
• Item Dispenser
• Money receptacle
A CRC card for class SnackItem
Class name: SnackItem
Responsibility
Knows its price
Know its calories
16
Collaborator
A CRC card for the Vending Machine
Class name: VendingMachine
Responsibility
Maintains a collection of SnackItems.
Allows addition of SnackItem
Allows removal of SnackItem
17
Collaborator
SnackItem
Showing the Collaboration of a VendingMachine
and SnackItem
18
19
In class work
Working in teams of two, complete the steps below. Your
team may be asked to display your work for the whole class
to review.
1. Treat the problem description next as a problem narrative
and do the necessary "underlining/circling".
2. Propose a class to be used in this problem. Propose a set
of responsibilities (methods) for the class. Mention any
collaborators.
3. Create a CRC card. Be sure to include both the behavioral
and knowledge responsibilities. I recommend using the
“back” of the CRC card to list the properties (and indicate
the type for each property).
20
Problem: SPU is a new over-night shipping company.
They have asked you to write a program to keep track of
their packages. Specifically, they want a program that will
store data about individual packages including the
sender’s name and address, the receiver’s name and
address, the weight of the package (in pounds and
ounces), the location of the package (represented with a
special SPU code), the status of the package (delivered or
not), and the type of shipping (1 day air, 2 day air, anytime-soon). The program should allow an operator to find
out any of these pieces of information about a package
and change the status and location. Operators should be
able to ask for the weight in pounds/ounces or
kilograms/grams.
21
Class: ________________
Responsibilities
Collaborators
22
Knowledge
data
type
Chapter 10: Object models
• Object models describe the system in terms of object classes and
their associations.
• An object class is an abstraction over a set of objects with
common attributes and the services (operations) provided by
each object.
• Various object models may be produced
▫
▫
▫
▫
Simple object models
Inheritance models
Aggregation models
Interaction models
• UML notations exist for these…
Object Model: Class Diagram
Class name
System
systemID
verificationPhoneNumber
systemStatus
delayTime
telephoneNumber
masterPassword
temporaryPassword
numberTries
program()
display()
reset()
query()
modify()
call()
attributes
operations
24
Class
(Relationship)
Diagram
FloorPlan
type
name
outsideDimensions
determineType ( )
positionFloorplan
scale( )
change color( )
is placed wit hin
is part of
Cam era
Wall
t ype
ID
locat ion
f ieldV iew
panA ngle
Zoom Set t ing
t ype
wallDim ensions
determineType ( )
computeDimensions ( )
det erm ineType ()
t ranslat eLocat ion ()
displayID()
displayV iew()
displayZoom ()
is used t o build
is used t o build
is used t o build
WallSegm ent
t ype
st art Coordinat es
st opCoordinat es
next WallSem ent
determineType ( )
draw( )
Window
Door
t ype
st art Coordinat es
st opCoordinat es
next Window
t ype
st art Coordinat es
st opCoordinat es
next Door
determineType ( )
draw( )
determineType ( )
draw( )
25
Inheritance models
• Organize the domain object classes into a hierarchy.
• Classes at the top of the hierarchy reflect the common
features of all classes.
• Object classes inherit their attributes and services from
one or more super-classes. These may then be
specialised as necessary.
LibraryItem
Class Hierarchy
Diagram
Library item
Catalogue n umber
Acquisition da te
Co st
Typ e
Status
Number o f cop ies
Acquire ()
Catalogue ()
Disp ose ()
Issue ()
Return ()
Pub lish ed item
Reco rded item
Title
Medium
Title
Pub lish er
Bo ok
Autho r
Editio n
Pub licatio n da te
ISBN
Magazin e
Year
Issue
Film
Directo r
Date of release
Distributor
Co mp uter
pro gram
Version
Platfor m
LibraryUser
Class Hierarchy
Diagram
Library user
Name
Address
Ph on e
Reg istratio n #
Reg ister ()
De-reg ister ()
Reader
Bo rrower
Items on lo an
Max . lo ans
Affiliatio n
Staff
Depar tmen t
Depar tmen t p ho ne
Student
Majo r subject
Hom e ad dress
Multiple inheritance
Bo ok
Vo ice reco rding
Autho r
Editio n
Pub licatio n da te
ISBN
Speak er
Duratio n
Reco rding da te
Talking boo k
# Tapes
Object Aggregation
• An aggregation model shows how classes that are
collections are composed of other classes.
• Aggregation models are similar to the part-of
relationship in semantic data models.
Object Aggregation
UML Notation
Object behaviour modelling
• Diagrams so far illustrate static relationships between
components
• Dynamic interactions also need to be described
• A behavioural model
▫ shows the interactions between objects
▫ to produce a behaviour that was specified as a use-case
• Collaboration diagrams in UML are used to model
interaction between objects
▫ Example: Sequence diagrams
Interaction | Sequence diagrams
• These show the sequence of events that take place
during some user interaction with a system.
• You read them from top to bottom to see the order of
the actions that take place.
ATM
Sequence
Diagram
of ATM
Withdrawal
Card
PIN request
Database
Card number
Card OK
PIN
Validate card
Option menu
TIME
<<exception>>
invalid card
Withdraw request
Amount request
Balance reques t
Balance
Handle reques t
Amount
Debit (amount)
<<exception>>
insufficient cas h
Messages
Debit response
Card
Card removed
Cash
Cash removed
Receipt
Complete
transaction
UML Modeling
UML Modeling Serial View
37
State
• Components are NOT just characterized by behavior, but
also by the information they contain
• State – all the information (data values) within a
component at any given moment in time
• Class refers to a set of objects with similar behavior
• Object/Instance refers to an individual representative of
a class
38
Other concepts
• Cohesion
▫ Degree to which the responsibilities of a single component
form a meaningful unit
▫ Aim for high cohesion / associate related tasks w/i same
component
• Coupling
▫ Degree that software components are related
▫ Aim for low coupling / reduce the amount that one
component must access the data values – the state- of
another component
39
40
Interface represented in UML
• Interface
▫ Discussed already
41
Implementation
• Choose your language
• Implement the representation  choose your data
structures
▫ Choose a classic data structure
▫ Make up your own
• Implement components’ desired behavior
▫ Choose your algorithms
42
Testing
• Unit test individual components
▫ Need drivers (for example: MyQueueTest.java)
• Integration test
▫ Start combining components
▫ If a component isn’t finished – stub it out
References
• References on CRC cards:
• A Laboratory For Teaching Object-Oriented Thinking Kent Beck, Apple
Computer,Inc http://c2.com/doc/oopsla89/paper.html
• Introduction to CRC cards by David Rubin http://www.softstarinc.com/Methodology/CRCIntro.htm
• Designing Object-Oriented Software by Rebecca Wirfs-Brock, Brian
Wilkerson and Lauren Wiener
• References on UML
• Basic UML Class Diagram Notation,
http://www.umich.edu/~eecs381/handouts/UMLNotationSummary.pdf
• UML Class Diagrams Reference, Similar Web
http://www.uml-diagrams.org/class-reference.html
43