Object-Oriented
Analysis and Design
Introduction
Topics and skills covered
Sample
Activities
Principles &
Guidelines
OO Analysis
& Design
Topics and Skills
UML notation
Patterns
Case Study
OO Technology
Owning a hammer does not make one an
architect
 Knowing an OO language and access to a
rich library is a necessary but insufficient
first step in creating object systems
 Analyzing and designing a system from an
object perspective is also critical

Analysis and Design
Analysis
Design
Investigation
of the
Problem
Logical
Solution
OO Analysis and Design

Emphasis on finding
and describing the
objects or concepts in
the problem domain

Emphasis on defining
logical software
objects that will
ultimately be
implemented in an OO
programming
language
Activities in A&D




2 most important
The most single important ability in OO is to
skillfully assign responsibilities to software
components
Must be performed (inescapable) and it has the
most profound effect on the robustness,
maintainability, and reusability of software
components.
Next is finding suitable objects
OO emphasizes objects
Domain Concept
Representation in
analysis of concepts
Book
title
Representation in an OO
programming language
Public class Book
{
public void print();
private String title;
}
OO Versus Function Oriented
Analysis and Design
The Library
Information
System
OO A/D
Structure A/D
System
Catalog
Librarian
Record Loans
Book
Library
Add Resources Report Fines
Is it Analysis or is it Design?
The division between analysis and design is fuzzy!
Some methods classify an activity at varying
points on the continuum.
Use cases:
-expanded
essentials
Use case
diagrams
Conceptual
Model
Glossary
System
sequence
diagrams
Operation
Contracts
State
diagrams
Use cases:
-real
Window &
reports
Interaction
diagrams
Methods
Design class
diagrams
Class &
Interface
definitions
Architectural
package
diagrams
dependency on
Database
schema
SQL
Test
Cases
An Example of OO Analysis and
Design
A dice game in which a player rolls two die.
If the total is seven, they win; otherwise
they lose
Defining Use Cases of the Dice
Game
Define use
cases
Define
Define
conceptual collaboration
model
diagrams
Define
design class
diagrams
For example, in the dice game, here is the Play a Game use
case.
Use Case:
Play a game
Actors:
Player
Description: This use case begins when the player picks up
the dice and rolls the dice. If the dice total seven, they win;
otherwise, they lose
Conceptual Model of the Dice
Game
Define use
cases
Player
name
1
Define
Define
conceptual collaboration
model
diagrams
1
Rolls
Plays
1
DiceGame
1
Includes
2
Define
design class
diagrams
Die
faceValue
2
Collaboration Diagram Illustrating
Messages Between Software
Define use
cases
Play()
Define
Define
conceptual collaboration
model
diagrams
:Player
1:r1 :=roll()
Define
design class
diagrams
D1 : Die
2:r2 :=roll()
D2 : Die
Design class diagram of software
components
Define use
cases
Define
Define
conceptual collaboration
model
diagrams
Player
Dice
Rolls
name
Define
design class
diagrams
1
2
play()
faceValue
roll()
1
DiceGame
1
1
Plays
2
Includes
initialize()
What is Visual Modeling?
Order
“Modeling captures essential
parts of the system.”
Item
Dr. James Rumbaugh
Ship via
Business Process
Visual Modeling is
modeling
using standard graphical
notations
Computer System
Visual Modeling Captures
Business Process
Use Case Analysis is a technique to capture
business process from user’s perspective
Visual Modeling is a
Communication Tool
Use visual modeling to capture business objects and logic
Use visual modeling to analyze and design your application
Visual Modeling
Manages Complexity
Visual Modeling Defines
Software Architecture
User Interface
(Visual Basic,
Java)
Business Logic
(C++, Java)
Database Server
(C++ & SQL)
Model your system
independent of
implementation language
Visual Modeling
Promotes Reuse
Multiple Systems
Reusable
Components
Key Ingredients
notation
 modeling tool
 process

UML
Rational Rose
Rational Objectory Process
What is the UML?
Unified Modeling Language
 a modeling language for object-oriented
analysis and design
 It is not a methodology
 standard notation (v 1.1 11/97)
 metamodel (model of a model)

What is the UML?

The UML combines the best of the best from






Data Modeling concepts (Entity Relationship Diagrams)
Business Modeling (work flow)
Object Modeling
Component Modeling
The UML is the standard language for visualizing,
specifying, constructing, and documenting the artifacts of
a software-intensive system
It can be used with all processes, throughout the
development life cycle, and across different
implementation technologies
Rumbaugh
Jacobson
Meyer
Pre- and postconditions
Booch
Odell
Harel
Classifications
State Charts
Wirfs-Brock
Shlaer-Mellor
Object Life Cycles
Gamma et al.
Responsibilities
Embly
Singleton Classes
Frameworks, patterns,notes
Fusion
Operation descriptions,
message numbering
History of the UML
Industrialization
Standardization
Unification
UML 1.0
UML Partner’s
Expertise
UML .9 and .91
Unified Method 0.8
Booch ‘93 OMT-2
Fragmentation Other methods
Booch ‘91
OMT-1 OOSE
Goals of UML
Provide users a ready-to-use, expressive
visual modeling language so they can
develop and exchange meaningful models
 Be independent of particular programming
languages and development processes
 Provide a formal basis for understanding the
modeling

Goals of UML
Provide a formal basis for understanding the
modeling language
 Encourage the growth of the OO tools
market
 Support higher-level development concepts
such as collaborations, frameworks,
patterns, and components
 Integrate best practices

Process
constrained versus. creativity
 discipline versus bureaucracy
 well managed iterative and incremental life
cycle provides the necessary control without
affecting creativity
 UML focuses on a modeling language, NOT
a standard processes

Define iteration to
Initial risks
address the highest
Initial project
risk
scope
Plan and develop
the iteration
Assess the iteration
Revise project
plan
Revise risk
assessment
Risks
Eliminated
Modeling Language - Method

Language



Syntax
Notation
Semantics

Method



what to do
how to do it
why to do it
Objectory
Coad/Yourdon
Shlaer/Mellor
OMT
Fusion
Views of the UML
Logical
Component
Class &
Package
Design
Use Case
Deployment
External
Agents
Jacobson
Sequence &
State Diagrams
Concurrency
UML categories
Relationships
Things
Diagrams
UML Things
Structural
Behavioral
Groups
Annotational
Structural Things
Nouns of the UML models
 Mostly the static parts of a model,
representing elements that are either
conceptual or physical

UML Things
Classes
Interfaces
Collaborations
Use Classes
Components
Nodes
Structural
Behavioral
Groups
Annotational
Class

Description of set
of object that share
the same
attributes,
operations,
relationships and
semantics
Window
Origin
Size
Open()
Close()
Move()
Display()
Interface

Collection of
ISpell
operations that
specify a
service of a
class or
component. IUnknown
interfaces
IThesaurus
Wordsmith.dll
component
Collaboration

Defines an interaction and is a society of
roles and other elements that work together
to provide some cooperative behavior that is
bigger that the sum of all the elements.
Chain of
responsibility
Use case

Description of a set of sequence actions that
a systems performs that yields an
observable result of value to a particular
actor
Place
Order
Component


A physical and replaceable
part of the system that
conforms to and provide the
realization of a set of
interfaces.
Typically represents the
physical package of
otherwise logical elements,
such as classes, interfaces
and collaborations.
Orderform.java
Node

Physical
element that
exists at run
time and
presents a
computational
resource
server
UML Things
Structural
Behavioral
Groups
Annotational
Interaction
State machine
Behavioral Things
Dynamic parts of UML models
 Represent behavior over time and space

Interaction

Behavior that
comprises a set of
messages exchanged
among objects within a
particular context to
accomplish a specific
purpose
display
State Machine

Behavior that
specifies the
sequences of states
an object
Waiting
UML Things
Structural
Behavioral
Groups
Annotational
Package
Package
General-purpose
mechanism for
organizing elements
into groups.
 Unlike components,
which exist at run time,
a package is purely
conceptual

Business rules
UML Things
Structural
Behavioral
Groups
Annotational
Annotational

Explanatory parts
Return copy of self
UML Relationships
Dependency
Generalization
Association
Aggregation
UML Diagrams
Object
Statechart
Class
Collaboration
Sequence
Activity
Use Case
Component
Deployment
Diagrams








Class - Set of classes, interfaces and collaborations and their
relationships
Object – represents static snapshots of instances of things found
in class diagrams
Use case – set of use cases and actors
Interaction – shows an interaction consisting of a set of objects
and their relationships (sequence and collaboration are
isomorphic)
Statechart – shows a state machine
Activity – special kind of statechart that shows the flow from
activity to activity within a system
Component – organization and dependencies among a set of
components
Deployment – configuration of run-time processing nodes and
the components that live on them
Case Study
Plan and
Elaborate
Phase
Case Study: Point-of-Sale
The main case study is a point-of-sale terminal (POST)
system. A point-of-sale terminal is a computerized
system used to record sales and handle purchases. It
includes hardware components such as a computer
and a bar code scanner and software to run the system
We create the software!
Understanding the Requirements
Create requirement phase artifacts, such as
function specifications
 Identify and categorize system functions
 Identify and categorize system attributes
and relate them to functions

Basic Functions
Ref #
Function
Category
R1.1
Record the underway (current) sale- the
items purchased
Calculate current sale total, including tax
and coupon calculations
Capture purchase item information from
a bar code scanner, or manual entry of a
product code, such as a universal product
code (UPC)
Reduce inventory quantities when a sale
is committed
evident
R1.2
R1.3
R1.4
evident
evident
hidden
Understanding the Requirements

Need to grasp
 the
domain process
 users/surroundings
Grasping the Domain Process

Use cases (Jacobson)
a
narrative description of a domain process
 a typical interaction between a user and a
computer system
 captures some user-visible function
Borrow Books
 may be small or large
from the Library
 achieves a discrete goal for the user
 the use case diagram is now part of the UML
High-level and Expanded Use
Cases
UML does not specify a rigid format
 High Level

Use Case:
Buy Items
Actors:
Customer, Cashier
Type:
Primary
Description:
A Customer arrives at a checkout with the
items to purchase. The Cashier records the
purchase items and collects payment. On
completion, the Customer leaves with the items .
ACTORS
Someone or something that
interacts with the system
Actors





Not part of the system
may initiate
interaction with the
system
are autonomous from
the system
can be people
can be other systems





Electrical or
mechanical device
Is a role
a role can be played by
more than one user
one user can play
more than one role
documented in the
Actor Catalog
Actor Catalog



Actor
Customer
Cashier
Customer



Role Description
buys/returns items
Process transactions
Cashier
UML icon for a user case actor
Expanded Use Case (Top section)
Use Case: Buy Items with Cash
Actors:
Customer (initiator), Cashier
Purpose:
Capture a sale and its cash payment
Overview: A Customer arrives at a checkout with items to
purchase. The Cashier records the purchase items
and collects a cash payment. One completion, the
Customer leaves with the items.
Type:
primary and essential
Cross Refs: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1
Explaining Expanded Use Case
(Top section)
Use Case:
Actors:
Name of the use case.
List of actors(external agents), indicating who
initiates the use case.
Purpose:
Intention of the use case
Overview: Repetition of the high-level use case, or some
similar summary
Type:
1. primary, secondary or optional (later)
2. essential or real
Cross Refs: Related use cases and system functions
Expanded Use Case Remaining
Sections

Typical contents - middle section
 how
the use case starts and ends
 normal flow of events

Typical contents - Final section
 alternative
flow of events
 exceptional flow of events
Expanded Use Case
(middle section)
Typical Course of Events
Actor Action
System Response
1.This use case begins when a
Customer arrives at a POST
checkout with items to purchase.
2.The Cashier records the identifier 3. Determines the item price
for each item.
and adds the item
information to the running
sales transaction.
If there is more than one of the same
item, the Cashier can enter the
The description and price
quantity as well.
of the current item are
presented.
Expanded Use Case
(middle section continued)
Typical Course of Events
Actor Action
System Response
4.On completion of item entry, the 5.Calculates and presents the
Cashier indicates to the POST
sale total.
that item entry is complete.
6.The Cashier tells the Customer
the total.
7. The Customer gives a cash payment -- the “cash tendered” -possibly greater than total.
8. The Cashier records the cash
9.Shows the balance due back
received amount.
to the Customer. Generates
a receipt.
Expanded Use Case (middle section
continued)
Typical Course of Events
Actor Action
System Response
10. The Cashier deposits the cash 11. Logs the completed sale.
received and extracts the
balance owing. The Cashier
give the balance owing and the
printed receipt to the Customer.
12. The Customer leaves with items
purchased
Expanded Use Case (final section)
Alternative Courses
Event 2: Invalid identifier entered. Indicate error.
Event 7: Customer didn’t have enough cash. Cancel sales
transaction.
Decision Points and Branching
Use cases may contain decision points.
 Example: in Buy Items, the customer may
choose to pay via cash, credit, or check or
payment time
 If one of these decisions overwhelmingly
represents the typical case and the others are
rare, then the others should be mentioned in
the alternatives section

Buy Items
Section: Main
Typical Course of Events
Actor Action
…
7. Customer chooses payment type:
a. If cash payment, see section
Pay by Cash
b. If credit payment, see section
Pay by Credit
c. If check payment, see section
Pay by Check
…
Section: Pay by Cash
System Response
A Common Mistake in Use Cases
Represent individual steps, operations or
transactions as use cases.
 Example: Printing the Receipt - the
printing operation is merely a step in much
larger use case process Buy Items
 can break down activities or portions in subuse cases (abstract use cases) but this is not
the norm

Identifying Use Cases

Actor-based
 Identify
the actors related to a system or
organization.
 For each actor, identify the processes they
initiate or participate in.

Event-based
 Identify
the external events that a system must
respond to.
 Relate the events to actors and use cases.
Notation - Naming Use Cases

Name a use case starting with a verb in
order to emphasize that it is a process.
 Buy
Items
 Enter an Order
Examples
Actor-based
Event(process)-based
Cashier
Withdraw cash from ATM
Order a product
Register for courses at a school
Check the spelling of a
document in a word processor
Handle a telephone call
Log In
Cash Out
Customer
Buy Items
Refund Items
Manager
Start Up
Sys-Admin Manage Users
Use Case Diagrams
Buy Items POST
Customer
Cashier
Log In
Refund Items
Start Up
Manage Users
System
Administrator
Manager
Essential versus Real Use Cases

Essential
 free
of technology and implementation details
 design decisions are deferred and abstracted
especially related to the user interface

Real
 concretely
describes the process in terms of its
real current design, committed to specific input
and output technologies
Buy Items Use Case (essential)
The expanded Buy Items use case already
shown tends towards being an essential use
case. Note, it is very non-committal with
respect to the technical realization.
 Example. The Cashier records the identifier
for each item.

Buy Items Use Case (real)
Real
Actor Action
System Response
1. For each item, the Cashier
2. Displays the item price and
types in the Universal Product and adds the item inforCode (UPC) in the UPC input
mation to the running sales
field of Window1. They then
transaction,
press the “Enter Item” button
with the mouse or by pressing
The description of the price
<Enter>.
of the current item are
displayed in Textbox 2 of
Window 1.
3. Etc.
Ranking and the Scheduling of
Use Cases
Completed the artifacts of Requirements
Spec and Use Cases
 transition to the build phase of the iterative
development life-cycle
 development cycles are organized around
use cases - a development cycle is assigned
to implement one or more use cases or
simplified version of use cases

Ranking Use Classes
High ranking use classes are tackled early
 Qualities that increase the ranking are:

 significant
impact on architectural design
 risky, time-critical, or complex functions
 involve significant research, or new technology
 represents the primary line-of-business
 directly support increased revenue or decreased
cost
POST Scheduling

Buy Items should be tackled first. Also a
simple version of Start Up to support other
use cases
 Buy
Items - v1 (cash payments, no inventory
updates)
 Buy Items - v2 ( allow for all payment types)
 Buy Items - v3 ( complete version including the
handling of inventory updates)
Allocation of Use Cases
Development
Cycle 1
Development
Cycle 2
Development
Cycle 3
Development
Cycle 4
Buy Items
Version 1
...
Buy Items
Version 2
...
Buy Items
Version 3
...
Log in
...
Refund
Items
...
Case Study
Analysis
Continued