Object-Oriented
Analysis and Design
Object-Oriented Analysis
Requirements Model
Analysis Model
Object-Oriented Design
Copyright  1993-97 Thomas P. Sturm
METHODOLOGY
A Methodology is a process for the organized creation of software using
a set of pre-defined techniques.
These techniques involve notational conventions when presented to the
human.
These techniques may also involve computer data structures when stored
in machine-readable form.
Early years: No expressible methodology.
Problem Domain -------------------------------------Solution Domain
(Some Ad-Hoc Model)
Object-Oriented Design and Programming
2
Analysis and Design
TRADITIONAL SDLC
(Software Development Life Cycle)
Waterfall Model
Specification
data structure 1
Analysis
data structure 2
big step
Design
data structure 3
big step
Implementation
data structure 4
Testing
data structure 5
Maintenance
Problem Domain -------------------------------------Solution Domain
Object-Oriented Design and Programming
3
Analysis and Design
Structured Methodology Components
A collection of heterogeneous, non-uniform concepts
Entity-Relationship diagram (ER diagram)
Data Flow diagram (DFD)
Structure chart
Relational model
List of SQL table create commands
etc.
Software development problems
Maintenance costs escalate
Project deadlines slide
Cost estimation difficult
Cost of change prohibitive
Creeping featurism
Processing problems
Excessive transformations
Decreased productivity
No leverage from one project to the next
No leverage of existing code to new features
Object-Oriented Design and Programming
4
Analysis and Design
Object-Oriented Software Development Life Cycle
Iterative rather than sequential
User-centered process of requirements analysis
- captures user requirements through use case
Concepts of objects appears early in analysis and is carried through
design and implementation
Early and easy prototypes with re-usable code
Flexibility between phases
Consistency of concepts and flexibility between phases lead to iterative
and recursive SDLC
Specification
Analysis
Design
Maintenance
Implementation
Problem Domain -------------------------------------Solution Domain
Object 1
Object 2
Message
Object-Oriented Design and Programming
Object n
Message
5
Analysis and Design
Object-Oriented Analysis and Design
Analysis:
A problem model (not designing a solution)
A stage in the development cycle in which a real-world problem is
examined to understand its requirements without planning the
implementation
The process of studying user needs to arrive at a definition of the
system or the software requirements
The systematic process of reasoning about a problem and its
constituent parts to understand what is needed and what must be
done
Design:
A solution model (thinking about how the problem will be solved
by considering alternatives)
The creation of an abstraction of a software system that is
consistent with the requirements specifications and provides a
reasonable description for implementation
Object-Oriented Design and Programming
6
Analysis and Design
Object-Oriented Approaches
CRC (Class Responsibility Collaborators) Cards - a manual approach the others all have some computer-aided component
OMT (Object Modeling Technique) - Rumbaugh, 1991
Jacobson OOSE (Object-Oriented Systems Engineering) - Ivar Jacobson,
1992 (Use Case method)
Booch - Grady Booch, 1991, 1994 (will combine with OMT, probably
be the survivors)
Coad/Yourdon - Coad & Yourdon, 1991a & b
Shlaer/Mellor - Shlaer & Mellor, 1988, 1992
Wirfs-Brock - Rebecca Wirfs-Brock, 1990 (not a full life cycle - mostly
end of analysis phases, beginning of design)
OOIE (Object-Oriented Information Engineering) - Martin & Odell,
1992
Fusion - Coleman, 1994 (synthesis of CRC, OMT, Booch, and one other
- promoted by HP)
... Plus 10 others
Object-Oriented Design and Programming
7
Analysis and Design
Which Language?
Object Magazine report on Gartner Group Survey of 305 IS Managers:
Main OO
Language
C++
OO 4GL
Smalltalk
Other language
Percent
42%
26%
17%
15%
Comparative Analysis of the four major OO Languages
Smalltalk
Uniformity
High
Documentation value Medium
Reliability
Medium
Protected Operations No
Multiple Inheritance No
Efficiency
Low
Garbage Collection
Yes
Language Complexity Low
Object-Oriented Design and Programming
8
Eiffel
Medium
High
Medium
No
Yes
Medium
Yes
Medium
JAVA
Medium
Medium
Medium
Yes
No
Low
Yes
Medium
C++
Low
Medium
Low
Yes
Yes
High
No
High
Analysis and Design
Modeling
A Model is an abstraction of something
Sufficiently detailed to capture the meaning and retain the
functional requirements
Sufficiently abstract to obtain understanding before building it
The purposes of building a model include
testing a physical or logical entity before building it
communicate with users/customers
visualize what it will “look like”
reduce complexity so that basic structure can be understood
Object-Oriented Design and Programming
9
Analysis and Design
Complexity
“Scaling up is hard to do”
interactions grow more rapidly than linearly
expectations increase
number of users increase and become more diverse
impact of a “bug” is more widespread
conducting controlled experiments is more difficult
Five attributes of a complex system
1. Interrelated subsystems nearly decomposible into a hierarchy
2. Lots of choices for which parts are primitive
3. Intracomponent linkages are stronger than intercomponent
4. Common patterns with many arrangements
5. Evolved from a simple system that worked
Object-Oriented Design and Programming
10
Analysis and Design
Algorithmic vs. Object-Oriented Decomposition
Algorithmic decomposition:
- top-down, hierarchical, structured design, in which each module
represents some major part of the PROCESS to be executed
- process centered
- each process obtains the data it needs from a common pool of
data
- problem decomposed by determining which algorithms to execute
Object-oriented decomposition:
- identify objects and their behavior from the problem domain
- view each object as an autonomous agent (anthropomorphize)
- each object has its own internal “state” (data) that can’t be altered
without the object’s knowledge and consent
- objects exhibit behavior (which is where the “processing” takes
place)
- objects can be requested to do things by sending them messages
- problem decomposed by determining which objects to create
Algorithmic vs. OO
- “orthogonal” approaches to the problem - can’t do both
- lack of methodology falls apart at about 1,000 lines of code
- algorithmic appears to fall apart when applications exceed
100,000 lines of code
- OO systems show no similar limitations
Object-Oriented Design and Programming
11
Analysis and Design