Object-oriented analysis and design 

(OOAD) is a software
engineering approach that models a system as a group of
interacting objects. Each object represents some entity of interest in the
system being modeled, and is characterized by its class, its state (data
elements), and its behavior. Various models can be created to show the
static structure, dynamic behavior, and run-time deployment of these
collaborating objects. There are a number of different notations for
representing these models, such as the Unified Modeling Language (UML).

Object-oriented analysis (OOA) applies object-modeling techniques to

analyze the functional requirements for a system. Object-oriented design
(OOD) elaborates the analysis models to produce implementation
specifications. OOA focuses on what the system does, OOD on how the
system does it.

Object- Oriented System

An object-oriented system is composed of objects. The behavior of the

system results from the collaboration of those objects. Collaboration
between objects involves them sending messages to each other. Sending a
message differs from calling a function in that when a target object receives
a message, it itself decides what function to carry out to service that
message. The same message may be implemented by many different
functions, the one selected depending on the state of the target object.
The implementation of "message sending" varies depending on the
architecture of the system being modeled, and the location of the objects
being communicated with.

Object-Oriented Analysis

Object-oriented analysis (OOA) looks at the problem domain, with the aim of

producing a conceptual model of the information that exists in the area
being analyzed. Analysis models do not consider any implementation
constraints that might exist, such as concurrency, distribution, persistence,
or how the system is to be built. Implementation constraints are dealt during
object-oriented design (OOD). Analysis is done before the Design.
The sources for the analysis can be a written requirements statement, a
formal vision document, interviews with stakeholders or other interested
parties. A system may be divided into multiple domains, representing
different business, technological, or other areas of interest, each of which
are analyzed separately.

The result of object-oriented analysis is a description of what the system is

functionally required to do, in the form of a conceptual model. That will
typically be presented as a set of use cases, one or more UML class
diagrams, and a number of interaction diagrams. It may also include some
kind of user interface mock-up. The purpose of object oriented analysis is to
develop a model that describes computer software as it works to satisfy a
set of customer defined requirements.

Object-Oriented Design

Object-oriented design (OOD) transforms the conceptual model produced in

object-oriented analysis to take account of the constraints imposed by the
chosen architecture and any non-functional – technological or environmental
– constraints, such as transaction throughput, response time, run-time
platform, development environment, or programming language.

The concepts in the analysis model are mapped onto implementation classes
and interfaces. The result is a model of the solution domain, a detailed
description of how the system is to be built.

Booch Method

The Booch software engineering methodology  provides an object-oriented

development in the analysis and design phases. The analysis phase is split
into steps. The first step is to establish the requirements from the customer
perspective. This analysis step generates a high-level description of the
system's function and structure. The second step is a domain analysis. The
domain analysis is accomplished by defining object classes; their attributes,
inheritance, and methods. State diagrams for the objects are then
established. The analysis phase is completed with a validation step. The
analysis phase iterates between the customer's requirements step, the
domain analysis step, and the validation step until consistency is reached.
Once the analysis phase is completed, the Booch software engineering
methodology develops the architecture in the design phase. The design
phase is iterative. A logic design is mapped to a physical design where
details of execution threads, processes, performance, location, data types,
data structures, visibility, and distribution are established. A prototype is
created and tested. The process iterates between the logical design, physical
design, prototypes, and testing.

The Booch software engineering methodology is sequential in the sense that

the analysis phase is completed and then the design phase is completed.
The methodology is cyclical in the sense that each phase is composed of
smaller cyclical steps. There is no explicit priority setting nor a non-
monotonic control mechanism. The Booch methodology concentrates on the
analysis and design phase and does not consider the implementation or the
testing phase in much detail.

Jacobson Method

Ivar Jacobson's Object-Oriented Software Engineering (OOSE) is one of the

precursors to the more modern Unified Modeling Language (UML). OOSE
includes a requirements, an analysis, a design, an implementation, and a
testing model.
The Jacobson requirements model
The Jacobson requirements model includes a problem domain object
diagram and use case diagrams. This model defines the limits and
functionality of a system.

Jacobson's Problem Domain Object Diagram

The problem domain object diagram provides a logical view of the system,
which is used to specify the use cases for use case diagrams.

Jacobson's Use Case Diagrams

Use case diagrams illustrate how the outside world interacts with elements
of the application system.

Jacobson's Design Model

Jacobson's design model shows how the system behaves. There are two
types of diagrams under this model: interaction diagrams and state
transition diagrams. Interaction diagrams are similar to UML's sequence
diagrams. State transition diagrams are like UML statechart diagrams.
The Object Modeling Technique

The Object Modeling Technique (OMT) software engineering methodology is

another well known example of a software engineering methodology. The
OMT software engineering methodology deals with object-oriented
development in the analysis and design phases.

The analysis phase starts with a problem statement which includes a list of
goals and a definitive enumeration of key concepts within a domain. This
problem statement is then expanded into three views, or models: an object
model, a dynamic model, and a functional model. The object model
represents the artifacts of the system. The dynamic model represents the
interaction between these artifacts represented as events, states, and
transitions. The functional model represents the methods of the system from
the perspective of data flow. The analysis phase generates object-model
diagrams, state diagrams, event-flow diagrams, and data-flow diagrams.
The analysis phase is now complete.

The system design phase follows the analysis phase. Here the overall
architecture is established. First the system is organized into subsystems
which are then allocated to processes and tasks, taking into account
concurrency and collaboration. Then persistent data storage is established
along with a strategy to manage shared-global information. Next, boundary
situations are examined to help guide trade-off priorities.

The object design phase follows the system design phase. Here the
implementation plan is established. Object classes are established along with
their algorithms with special attention to the optimization of the path to
persistent data. Issues of inheritance, associations, aggregation, and default
values are examined.

The OMT software engineering methodology is sequential in the sense that

first comes analysis, followed by design. In each phase, a cyclical approach
is taken among the smaller steps. The OMT is very much like the Booch
methodology where emphasis is placed on the analysis and design phases
for initial product delivery. Both the OMT and Booch do not emphasize
implementation, testing, or other life cycle stages.