Object-Oriented Analysis Models
Oracle Database Tips by Donald Burleson
Object-oriented analysis starts with a
traditional structured specification, and adds the following information:
of all objects - A list
describing the data contents of each noun, or physical entities
in the DFD.
all system behaviors - A list
of all verbs within the process
names such as Prepare order
summary report, generate invoices, etc.
of the associate the primary behaviors (services) with each object
- Each object will have behaviors which uniquely belong to the
object. Other objects may request the
behavior of the object.
description of the contracts in the system
- A contract is an agreement between two objects, such that one
object will invoke the services of the other.
behavior script for each object - A script describes each initiator,
action, participant, and service.
classification for each object and the object relationships -
Generate an entity/relationship model and a generalization
hierarchy (IS-A) for each object, using traditional E/R or normalization
Over the past 12 years there have numerous books
about different approaches to object analysis bit they all contain these common
elements. Now that we see the basic analysis requirements, let's explore the
basic methodologies for object-oriented analysis.
Different Models for
Unlike the traditional systems analysis where
user requirements are gathered and then specifications are put on the
requirements and users are then asked to sign off on the specifications, the
object methodologies use a more iterative process where the requirements and
specifications are reviewed repeatedly and the users are heavily involved.
Object technology has many different
methodologies to help analyze and design computer systems. We will review four
of the more popular systems: Rumbaugh, Booch, Coad-Yourdon, and Shlaer-Mellor.
In most cases these methodologies are very similar, but each has its own way to
graphically represent the entities. To understand and use these four
methodologies would become difficult, if not impossible, for all projects. If
need be, it is possible to use concepts from one method with concepts from
another technique, basically creating your own object development technique.
The most important point is to remember is that the final outcome is what really
matters, not the choice of one analysis technique over another technique.
Remember, it is more important to do proper analysis and design to meet user
requirements than it is to just follow a blind, meaningless procedure.
The traditional systems development approach is
sometimes referred to as the waterfall method. By waterfall, object analyst's
follow a logical progression through analysis, design, coding, testing, and
maintenance. Unfortunately system development seldom fits this kind of
structured approach. End-users are notorious for changing their minds or
identifying some feature that they forgot to identify. These changes in
requirements can happen at any phase of system development and the analyst must
struggle to accommodate these changes into the system. What it means to the
systems analyst is that you have to go back to whatever step in the development
life cycle and make the necessary changes that will then cascade these changes
through the entire system. For example, suppose that our end-users are in the
testing phase when they realize that they need an additional screen. This would
require a change to the initial requirements document, which would, in turn,
cascade to analysis, design, and so on.
The object-oriented methodologies require a more
iterative process with the same five steps. The iterative process either adds
new or more clearly defines existing properties, unlike the traditional approach
that would re-hash specifications that are already done. The iterative process
helps to reduce confusion around what the system is really suppose to do and
what the users really want. The object-oriented software development methods
make the assumption that user requirements will change. However it doesn't
matter which programming language you use, be it FORTRAN or C++. Furthermore,
it doesn't matter which system development technique you use, you will follow
the same five steps in system development. It is just, how these five steps are
applied that will make the difference in your system development project.
The Rumbaugh method
The Rumbaugh method is listed first because it
is these authors favorite, and we find it a very friendly and easy methodology.
For traditional system analyst's, the Rumbaugh's methodology is the closest to
the traditional approach to system analysis and design, and beginners will
recognize familiar symbols and techniques. The Rumbaugh methodology has its
primary strength in object analysis but it also does an excellent job with
object design. Rumbaugh has three deliverables to the object analysis phase; the
Object model, the Dynamic model, and the functional model. These three models
are similar to traditional system analysis, with the additions for the object
model, including definitions of classes along with the classes variables and
behaviors. The Rumbaugh object model is very much like an entity relationship
diagram except that there are now behaviors in the diagram and class
hierarchies. The dynamic model is a "state transition" diagram that shows how
an entity changes from one state to another state. The functional model is the
equivalent of the familiar data flow diagrams from a traditional systems
The Booch method
Booch's methodology has its primary strength in
the object system design. Grady Booch has included in his methodology a
requirements analysis that is similar to a traditional requirements analysis, as
well as a domain analysis phase. Booch's object system design method has four
parts, the logical structure design where the class hierarchies are defined, the
physical structure diagram where the object methods are described. In addition,
Booch defines the dynamics of classes in a fashion very similar to the Rumbaugh
method, as well as an analysis of the dynamics of object instances, where he
describes how an object may change state.
The Coad-Yourdon method
Coad-Yourdon methodology has its primary
strength in system analysis. Their methodology is based on a technique
which stands for the five steps that help make up the analysis part of their
methodology. The first step in system analysis is called "Subjects", which are
basically data flow diagrams for objects. The second step is called "Objects",
where they identify the object classes and the class hierarchies. The third
step is called "Structures", where they decompose structures into two types,
classification structures and composition structures. Classification structures
handle the inheritance connection between related classes, while composition
structures handle all of the other connections among classes. The next step in
analysis is called "Attributes", and the final step is called "Services", where
all of the behaviors or methods for each class are identified.
Following analysis, Coad and Yourdon define four
parts that make up the design part of their methodology. The steps of system
The problem domain component
- This will define the classes that should be in the problem domain.
The human interaction
component - These steps defines the interface classes between objects.
The task management component
- This is where system-wide management classes are identified.
The data management component
- This design step identifies the classes needed for database access methods.
The Shlaer-Mellor method
Shlaer-Mellor methodology has its primary
strength in system design and is considered somewhat weak on analysis. The
Shlaer-Mellor methodology includes three models; the information model, the
state model, and the process model. The information model contains objects,
variables, and all the relationships between the objects, and is basically a
data model for the system. The state model records the different states of
objects and changes that can occur between the objects. The process model is
really not much more than a traditional data flow diagram.
Now that we have covered the basics of the
object approach, let's take a look at how a real-world object is created by
using these techniques.