Object-Orientation FAQ

1.21) What Is OOA/OOD (And Where Can I Get What I Need On It)?

  See also section 3.7, the Annotated Bibliography, and APPENDIX D.  The
  classified bibliography in [Booch 94] also contains entries on OOA(B), OOD(F)
  and OOP(G).
[Booch 91]
  "In OOA, we seek to model the world by identifying the classes and objects
  that form the vocabulary of the problem domain, and in OOD, we invent the
  abstractions and mechanisms that provide the behavior that this model
[Coad 91]
  "OOA is the challenge of understanding the problem domain, and then the
  system's responsibilities in that light".
  "To us, analysis is the study of a problem domain, leading to a specification
  of externally observable behavior; a complete, consistent, and feasible
  statement of what is needed; a coverage of both functional and quantified
  operational characteristics (e.g. reliability, availability, performance)".
  "Design.  The practise of taking a specification of externally available
  behavior and adding details needed for actual computer system implementation,
  including human interaction, task management, and data management details."
And on Domain Analysis:
  "Whereas OOA typically focuses upon one specific problem at a time, domain
   analysis seeks to identify the classes and objects that are common to all
   applications within a given domain, [...]".  - [Booch 91]
  [The following quotes on domain analysis are from [Berard 93]]
  "An investigation of a specific application area that seeks to identify the
   operations, objects, and structures that commonly occur in software systems
   within this area.  - Dan McNicholl
  "Systems analysis states what is done for a specific problem in a domain
   while domain analysis states what can be done in a range of problems in a
   domain.  ...A domain analysis is only useful in many similar systems are to
   be built so that the cost of the domain analysis can be amortized over the
   cost of all the systems.
   The key to reusable software is captured in domain analysis in that it
   stresses the reusability of analysis and design, not code. - Jim Neighbors
  "The process of identifying, collecting, organizing, and representing the
  relevant information in a domain based on the study of existing systems and
  their development histories, knowledge captured from domain experts,
  underlying theory, and emerging technology within the domain."  - Kang et al.
  Object-oriented domain analysis (OODA) seeks to identify reusable items
  localized around objects, e.g., classes, instances, systems of interacting
  objects, and kits [frameworks]. OORA analysts and OOD designers will
  interact on a fairly frequent basis with the domain analysis effort.
OOA and OOD stand for Object-Oriented Analysis and Object-Oriented Design,
respectively.  OOA strives to understand and model, in terms of object-oriented
concepts (objects and classes), a particular problem within a problem domain
(from its requirements, domain and environment) from a user-oriented or domain
expert's perspective and with an emphasis on modeling the real-world (the
system and its context/(user-)environment).  The product, or resultant model,
of OOA specifies a complete system and a complete set of requirements and
external interface of the system to be built, often obtained from a domain
model (e.g. FUSION, Jacobson), scenarios (Rumbaugh), or use-cases (Jacobson).
[Shlaer 88] is often credited as the first book on OOA, although their method
adds OO techniques to the traditional structured analysis principles of Yourdon
and Constantine. Their complete approach ([Shlaer 88, 92]) consists of
information modeling and recursive design, or OOA/RD and represents a recent
addition to the structured analysis family (as does Martin and Odell).
[Yourdon 92] provides a critique, although may only refer to their earlier
work.  Many other methodologies including Rumbaugh's OMT, Martin and Odell's
OOA/D, and many others, also share common ground with SA and other existing
analysis methodologies with such constructs as associations (E-R), functional
models, and even DFD's.  Booch, Jacobson, and Wirfs-Brock are examples of OO
methodologies representing a greater departure from the conventional
"structured" techniques, with greater emphasis on objects.  OOram [Reenskaug
91] provides support and emphasis on types and roles as guiding principles,
which is quite powerful.  [Booch 94] presents a methodology which is an
evolutionary step beyond the first edition by incorporating a collection of the
best features from several of the major OO methodologies, as does HP's new
FUSION methodology.
The usual progression is from OOA to OOD to OOP (implementation) and this
Universal Process Model roughly corresponds to the Waterfall Model [Royce 70].
See [Humphrey 89] and [Yourdon 92] for a few of many discussions on software
life-cycle models and their use.  Humphrey also details Worldy and Atomic
Process Models for finer grained analysis and design in the Defined Process
(see below) and discusses other alternatives to the task oriented models.  He
also provides the following critisisms on the Waterfall Model which had led to
Boehm's seminal work on the Spiral Model:
  * It does not adequately address changes
  * It assumes a relatively uniform and orderly sequence of development steps
  * It does not provide for such methods as rapid prototyping or advanced
Modern OO methodologies directly address these points and emphasize the
incremental, iterative, evolutionary, concurrent and situational nature of
software development.  [Boehm 86] presents a seminal spiral life-cycle model
with a risk-driven incremental prototyping approach.  [Booch 91, 6.1]
proposes a "round-trip gestalt" design with analyze-design iterations and
an overall system perspective and [Berard 93] proposes an (incremental)
"parallel-recursive design" with analyze-design-implement-test iterations.
[Coad 91b] presents the following development cycle breakdown:
    Analysis, prototyping, risk management
    Design, prototyping, risk management
    Programming, prototyping, risk management
    [Boehm, 1988]  
    A little analysis
    A little design
    A little programming
    [Gilb, 1988]
[Author's note: The spiral model is often incremental and may waterfall if
 called for.]
Since classes and objects are used in all phases of the OO software life-cycle,
the process is often referred to as seamless, meaning there is no conceptual
gap between the phases as is often the case in other software development
methodologies, such as the analysis (DFD's) to design (structure charts) to
programming gaps found in traditional structured analysis and design.
Seamlessness together with naturalness is a big advantage for consistency.
A problem domain has many realizations, or differing OOAs.  An OOA has many
realizations, or differing OODs, but a similar notation is often used for
the two.  An OOD also has many realizations, or differing OOPs, but allows a
selection from among various languages for implementation (choosing the best
language to implement the design).  But some, such as Bjarne Stroustrup, don't
like OOA and OOD getting too far from OOP (implementation independent), for
fear that great discrepancies could occur between OOD and OOP by losing sight
of the implementation language, which in some cases is predetermined.  See also
[Stroustrup 91].
From a greater perspective, the SEI has developed the Capability Maturity Model
(CMM), a process-based TQM model for assessing the level of an organization's
software development and which is often required of government contractors
in the US [Humphrey 89].  The CMM also serves as a 5 level improvement process
by specifying steps for organizations to progress to the next level, ultimately
leading to statistical (process) control and sustained improvement.  Watts S.
Humphrey is now working on the Personal Software Process (PSP), a scaled down
version of the CMM for individuals [Humphrey 95].  Next should follow a team-
based software process (TSP?).  Other CMM's in the works at the SEI include a
personnel management CMM (PM-CMM).
 Level 1: Initial:    Every project is handled differently; ad hoc and chaotic.
 Level 2: Repeatable: Every project is handled similarly.
 Level 3: Defined:    Standard processes are defined and used for all projects.
 Level 4: Managed:    A measurable basis for all improvements to the process.
 Level 5: Optimizing: Emphasis on defect prevention and optimizing/continually
                      improving the process.
See also:
Kitson, D.H. and Masters, S. "An Analysis of SEI Software Process Assessment
Results 1987-1991", CMU/SEI-92-TR-24
Humphrey, W., Snyder, T. and Willis, R. "Software Process Improvement at
Hughes Aircraft", IEEE Software, July 1991
Dion, R., "Elements of a Process Improvement Program," IEEE Software, July
"Concepts on Measuring the Benefits of Software Process Improvement,"
See also [Yourdon 92], [Wilkie 93], and [Booch 94] for discussions on this
often cited model.  There is also an ISO 9000 standard applicable to software
quality and ami working group in Europe creating the SPICE standard (among
other work), which is similar in scope to the CMM.  To join the ami mailing
list email to:
with the following message:
  subscribe firstname, lastname, e-mail address.
Object-oriented analysis now includes "Enterprise Modeling" [Martin 92], also
found in [Jacobson 92], and along with recent business process "reengineering"
efforts places information systems within an organizational perspective by
modeling entire organizations or a large part of them, with the information
processing system and software products development as integrated components.
[Yourdon 92] even calls for "global modeling"!

This document was translated by ms2html v1.8 on 01.06.95.