Object-Oriented Analysis and Design

By Michael Gora
DBMS, May 1996

The good, the bad, and the ugly of OOAD methodologies, and various approaches to using them.

Most new client/server application development tools emphasize object-oriented (OO) features. This implies
that an OO analysis and design (OOAD) methodology should be an effective guide to applying these tools to
business problems. But with the numerous methodologies available for OOAD, how do you choose the correct
one? How do you get started, and how do you ascertain whether your approach is as efficient as it should be?
And how do you avoid the pitfalls? OOAD can provide wonderful benefits, but believing that a new
methodology will solve all your problems is like believing in Utopia.

It's time for a reality check. In this article, I review different OOAD methodologies and various approaches to
using them. I explain why I disagree with a number of mainstream concepts, I discuss what has worked and
not worked in a number of projects, and I discuss how client/server applications that are developed with 4GL
Windows tools may require a nonstandard approach to OOAD.

My most common approach to OO methodology involves fairly strict adherence to OO design and construction
guidelines as appropriate to a particular language, but a very loose and flexible approach to OO analysis. For
me, OO analysis has become just another screwdriver in my toolkit -- useful for some projects but not for
others.

I spent all of 1988 and some of 1989 working with Richard Brown, one of the top OO developers in the U.S.,
building an OO EIS/DSS system under OS/2, using C as the language. Brown is a former Mitre Corp. principal
scientist who, in an earlier life, was best known as the architect of the Kurzweil reading machine, which reads
books to the blind, is still found in some libraries, and is still considered a high-water mark in OCR technology.
The architecture of the EIS/DSS system we designed was based on LISP-based OO and artificial intelligence
(AI) systems that Brown created for NASA and the Department of Defense while he was at Mitre. The project
gave me good early exposure to OO concepts that had been proven in the field.

Since 1989, my focus has been on Windows client/server development, although for a while, objects played no
significant role in my work. For the last three years, however, almost all my technical work (that is, some of the
analysis and all of the design and development) has been object oriented. I wouldn't do it any other way, but I'm
still not comfortable with OOAD in the analysis phase.

Although I currently teach three different OOAD courses, and have led custom seminars on OOAD, and one on
managing OO projects, I'm still not completely happy with what I'm teaching. Is my lack of OO analysis
understanding the problem, or is something else wrong?

Every developer I know who has worked with OOAD and OO construction for more than a few months is
extremely reluctant to go back to any other way of developing systems. The development speed, degree of
organization, robustness, and code reuse have all been enhanced so much that going back to any other way of
doing things is completely unthinkable. So why do I continue to squirm?

A survey of available literature shows that the applications competing for "object honors" are written mostly in
C++ or Smalltalk, and have a heavy manufacturing, engineering, aerospace, or scientific focus. That the major
OOAD methodologies are best for such problems, however, does not guarantee that they are also best for
typical business client/server applications. You need to determine which methodology is best suited for your
particular application, and what to do if no methodology matches your requirements precisely. (Using OOAD
often requires adaptations to methodologies.)

The Role of OOAD in the Software Life Cycle

To understand what's right and wrong with OOAD, you need to know where OO methodologies fit into the
software life cycle. These methodologies do not replace traditional approaches (such as data flow, process flow,
and state transition diagrams); they are important new additions to the toolkit.

According to Donald Firesmith in his book Dictionary of Object Technology (SIGS Books, 1995), analysis is
"the development activity consisting of the discovery, modeling, specification and evaluation of requirements,"
while OO analysis is "the discovery, analysis and specification of requirements in terms of objects with identity
that encapsulate properties and operations, message passing, classes, inheritance, polymorphism and dynamic
binding." Firesmith also states that OO design is "the design of an application in terms of objects, classes,
clusters, frameworks and their interactions."

In comparing the definition of traditional analysis with that of OOAD, the only aspect that is really new is
thinking of the world or the problem in terms of objects and object classes. A class is any uniquely identified
abstraction (that is, model) of a set of logically related instances that share the same or similar characteristics.
An object is any abstraction that models a single thing, and the term "object" is synonymous with instance.
Classes have attributes and methods. For an object class named Customer, attributes might be Name and
Address, and methods might be Add, Update, Delete, and Validate. The class definition defines the Customer
class attributes and methods, and a real customer such as "XYZ Corp." is an instance of the class. If you have
different kinds of customers, such as residential customers and commercial customers, you can create two new
classes of customers that are descendants of the Customer class. These descendants use inheritance to gain
access to all of the Customer class attributes and methods, but can override any of the ancestor attributes and
methods, as well as contain any required new attributes and methods.

There are three types of relationships between classes: inheritance, aggregation, and association. Inheritance
(also referred to as generalization/specialization) is usually identified by the phrase "is a kind of." For example,
Student and Faculty are both a kind of Person and are therefore inherited from the Person class. Aggregation is
identified by the phrase "is a part of," as with a product that contains parts. If neither of the first two
relationships applies, but the objects are clearly related (for example, an employee is associated with a
company), then the relationship is association.

An abstract class is a class that has no instances, and is used only for inheritance. A concrete class is a class that
can be instantiated, that is, that can have direct instances. Figure 1 shows some class relationships using
Rumbaugh notation.

All of the major OOAD methodologies have a similar basic view of objects, classes, inheritance, and
relationships. The drawing notation is slightly different in each; the real differences in the methodologies are
more subtle. Figure 2 illustrates the object relationships typically used in a single window. The student window
class w_student in the lower left is the window designed in the application. This window can have any number
of instances at runtime. Each instance of the window is associated with an instance of the sheet menu, as well as
with an instance of a nonvisual class that can contain the business rules and data buffers that allow student data
to be accessed in any window.

Table 1 (page 64) summarizes the major OOAD methodologies. When you're choosing a methodology, it is
important to consider not only the methodology's features, but also the cost of using it, the types of problems to
which it is best suited, its limitations, and the training available. When used in typical initial attempts to develop
client/server applications using OOAD methodologies, all of the methodologies suffer from the same basic
flaws:

* an overemphasis on the OO approach in general, even though another approach might be better for some parts
of the problem

* an overemphasis on the problem domain object model during the analysis phase

* analysis diagrams and output formats that end users may find difficult to understand

* difficulty in the methodology's ability to describe complex analysis problems

* a lack of emphasis on the underlying system architecture

* an inability to understand the limitations of either 4GL OO languages or of beginning OO developers

Every object methodology tells you to start with the object model, not the data model; there are at least four
problems with this approach:

* The data model often exists before the object model.

* The analyst may rightly be more comfortable building the data model before the object model.

* A good object model should be able to map to any data model. For me, it is usually a requirement in complex
systems that an object's attributes can map to one or more tables in one or more databases.

* A good abstract object model of the problem domain may not be easy to implement in the chosen language or
development tool.

The last problem in this list is the only one that is disappearing rapidly. With PowerBuilder 5.0 and new
versions of other tools, the limitations on the problem domain object model have essentially disappeared. In
PowerBuilder 4.0, a good conceptual object model of an order-entry system simply could not be implemented
easily. SQLWindows (Centura Software), Delphi (Borland International Inc.), and other tools all have or had
similar limitations. For example, in SQLWindows 5.0, my company built a good three-tiered object architecture
into one application to aid in managing complexity, and we had to strip it out for performance reasons; the
overhead of the additional layers was unacceptable. These types of problems are now on their way out.

Despite this, your choice of development tool does affect the object architecture. Each major 4GL supports a
slightly different flavor of OO, and the object model that you create during analysis may require significant
adaptation going into the design phase. This should not continue to be the case, but neither the tools nor the
methodologies are perfect.

Another aspect of the problem is that for most developers learning about objects in typical development projects
using OO client/server tools such as PowerBuilder, Delphi, SQLWindows, NewEra (Informix Software Inc.),
Smalltalk, and so on, the problem domain is the least intuitive place to start. To build a client/server application,
OO developers must first learn how to inherit windows, menus, controls, system error objects, and so on.
Learning to describe the problem domain, that is, the accounting problem or order-entry problem, in object
terms is much more difficult. In my experience, most developers using 4GL OO tools spend a year or more
becoming comfortable with window classes, menu classes, and window control classes before they even start to
experiment seriously with problem domain classes such as a Customer class. Of course, there are exceptions to
this. And, although Smalltalk developers typically begin to deal with abstract classes very quickly, I don't
expect Smalltalk to become a major force in the client/server world.

OOAD Methodologies

OOAD methodologies fall into two basic types. The ternary (or three-pronged) type is the natural evolution of
existing structured methods and has three separate notations for data, dynamics, and process. The unary type
asserts that because objects combine processes (methods) and data, only one notation is needed. The unary type
is considered to be more object-like and easier to learn from scratch, but has the disadvantage of producing
output from analysis that may be impossible to review with users.

Dynamic modeling is concerned with events and states, and generally uses state transition diagrams. Process
modeling or functional modeling is concerned with processes that transform data values, and traditionally uses
techniques such as data flow diagrams.

In the following sections, I describe the methodologies of Booch, Coad and Yourdon, Fusion, Jacobson, LBMS,
Rumbaugh, and Shlaer and Mellor. There are several other methodologies that I don't discuss, and if you are
interested in learning more about them, I strongly recommend Ian Graham's book, Object-Oriented Methods
(Addison-Wesley, 1994), which does an excellent job of both describing and comparing available
methodologies.

Booch

Grady Booch's approach to OOAD (see his book Object-Oriented Design with Applications,
Benjamin/Cummings, 1994) is one of the most popular, and is supported by a variety of reasonably priced tools
ranging from Visio to Rational Rose. Booch is the chief scientist at Rational Software, which produces Rational
Rose. (Now that James Rumbaugh and Ivar Jacobson have joined the company, Rational Software is one of the
major forces in the OOAD world.)

Booch's design method and notation consist of four major activities and six notations, as shown schematically in
Table 2.

While the Booch methodology covers requirements analysis and domain analysis, its major strength has been in
design. However, with Rumbaugh and Jacobson entering the fold, the (relative) weaknesses in analysis are
disappearing rapidly. I believe that Booch represents one of the better developed OOAD methodologies, and
now that Rational Rose is moving away from its previous tight link with C++ to a more open approach that
supports 4GLs such as PowerBuilder, the methodology's popularity should increase rapidly.

For systems with complex rules, state diagrams are fine for those with a small number of states, but are not
usable for systems with a large number of states. Once a single-state transition diagram has more than eight to
10 states, it becomes difficult to manage. For more than 20 states, state transition diagrams become excessively
unwieldy.

Coad and Yourdon

Coad and Yourdon published the first practical and reasonably complete books on OOAD (Object-Oriented
Analysis and Object-Oriented Design, Prentice-Hall, 1990 and 1991, respectively). Their methodology focuses
on analysis of business problems, and uses a friendlier notation than that of Booch, Shlaer and Mellor, or the
others that focus more on design.

In Coad and Yourdon, analysis proceeds in five stages, called SOSAS:

* Subjects: These are similar to the levels or layers in data-flow diagrams and should contain five to nine
objects.

* Objects: Object classes must be specified in this stage, but Coad and Yourdon provide few guidelines for how
to do this.

* Structures: There are two types: classification structures and composition structures. Classification structures
correspond to the inheritance relationship between classes. Composition structures define the other types of
relationships between classes. Coad and Yourdon do not deal as well as Rumbaugh, Jacobson, and several other
methodologies do with these structures.

* Attributes: These are handled in a fashion very similar to that in relational analysis.

* Services: The identification of what other methodologies call methods or operations.

In design, these five activities are supplanted by and refined into four components:

* problem domain component: classes that deal with the problem domain; for example, Customer classes and
Order classes

* human interaction component: user-interface classes such as window classes

* task management component: system-management classes such as error classes and security classes

* data management component: database access method classes and the like

Although Coad and Yourdon's methodology is perhaps one of the easiest OO methodologies to learn and get
started with, the most common complaint is that it is too simple and not suitable for large projects. However, if
you adhere to a premise that you should use those pieces of a methodology that work, and add other parts from
other methodologies as required, Coad and Yourdon's methodology is not as limiting as its critics claim.

Fusion

I have never used Fusion, but everything I read and hear about it places it at or near the head of the pack. In
1990, Derek Coleman of Hewlett-Packard led a team in the U.K. to develop a set of requirements for OOAD,
and conducted a major survey of methods in use at HP and elsewhere. The chief requirement was a simple
methodology with an effective notation.

The result was Fusion, which Coleman and others developed by borrowing and adapting ideas from other
methodologies. They incorporated some major ideas from Booch, Jacobson, Rumbaugh, and others, and
explicitly rejected many other ideas from these methodologies. Articles that Fusion practitioners have written
have been some of the most pragmatic and useful that I have seen about OOAD, but, unless you conduct a
significant research effort, you generally hear much more about other methodologies than about Fusion.

Coleman did not use some of the major components of Rumbaugh and Shlaer and Mellor in Fusion, because the
components were not found to be useful in practice. Some writers have called this encouraging and remarkable,
and consider it indirect proof that excessive emphasis on state models comes from Rumbaugh and Shlaer and
Mellor's telecommunications and realtime system backgrounds.

Fusion's pragmatic approach seems to hold considerable potential for client/server applications, but this
methodology is not being marketed as aggressively as most of the other methodologies.
Jacobson: Objectory and OOSE

Although Jacobson's full OOAD methodology, Objectory, is proprietary (to use it you must buy consulting
services and a CASE tool, OrySE, from Rational Software), it is probably the most serious attempt by an
OOAD tool vendor to support the entire software development life cycle. Jacobson is considered to be one of
the most experienced OO experts for applying OO to business problems such as client/server applications.

Jacobson's Object-Oriented Software Engineering (OOSE) is a simplified version of Objectory, which Jacobson
himself has declared inadequate for production applications. According to Jacobson: "You will need the
complete ... description which, excluding large examples, amounts to more than 1200 pages" (Object-Oriented
Systems Engineering, Addison-Wesley, 1992).

Object modeling and many other OO concepts in Objectory and OOSE are similar to OO concepts in other
methodologies. The major distinguishing feature in Jacobson is the use case. A use-case definition consists of a
diagram and a description of a single interaction between an actor and a system; the actor may be an end user or
some other object in the system. For example, the use-case description of an order-entry application would
contain a detailed description of how the actor (the user) interacts with the system during each step of the order
entry, and would include descriptions of all the exception handling that might occur.

According to Jacobson, a use case is any description of a single way to use a system or application, or any class
of top-level usage scenario, that captures how actors use their black-box applications. An actor is an interface to
the system, that is, something with which the system communicates, and may be a person or another program.
Jacobson adds that a use case is any behaviorally related sequence of transactions that a single actor performs in
a dialog with a system, in order to provide some measurable value to the actor.

Generally, you employ use cases to document user requirements in terms of user dialogs with a system. Use
cases appear first in the requirements model, and are then used to generate a domain object model with objects
drawn from the entities of the business as mentioned in the use cases. This is then converted into an analysis
model by classifying the domain objects into three types: interface objects, entity objects, and control objects.

The big danger with OOSE is the assumption that you can express all sequences and business in use cases. One
of my best object analysts ran into major difficulties while trying to force a large, complex client/server
application into the Jacobson methodology. Several major authors have subsequently declared that for many
complex systems and almost all expert systems, it cannot be done.

However, the use-case descriptions and their corresponding interaction diagrams can provide a very useful view
of many parts of a system, and Objectory and OOSE have a good, simple notation. For client/server applications
with rules of typical, rather than extreme, complexity, Jacobson provides a sound approach. The use-case
analyses are easier to review with end users than is much of the output from other OO analysis methodologies;
and use cases use narrative descriptions in plain English and are much easier to review with individuals who are
not OO experts than are object models with object interaction diagrams.

LBMS SEOO

Systems Engineering OO (SEOO) is a proprietary methodology and toolkit from the U.K.-based company
LBMS, which has its U.S. headquarters in Houston. SEOO is tightly integrated with Windows 4GLs such as
PowerBuilder, and is perceived to be a very pragmatic and useful tool, but this perception may be due in part to
a stronger marketing effort than is often made for nonproprietary methodologies. LBMS focuses on selling
CASE tools that support its methodology, and SEOO is the only methodology described in this article that is not
documented in a published book.
Because SEOO is proprietary, there is not as much detailed information available about it as there is about other
methodologies, and it is somewhere between difficult and impossible to try it out just to compare it with the
others.

The four major components of the SEOO methodology are:

* work-breakdown structures and techniques

* an object modeling methodology

* GUI design techniques

* relational database linkages to provide ER modeling and 4GL-specific features

Of all the major OOAD approaches, only SEOO gives the feeling of having started with non-OO approaches
and then adapting to OO. A very positive aspect of this is the heavy focus on data management and data
modeling. SEOO is intended to be object oriented while retaining the advantages of traditional data modeling.
This makes the methodology well-suited for client/server database applications.

SEOO is unique in treating data, triggers, and referential-integrity rules as a set of shared objects in a database.
It treats a data model as a view of the shared objects, which also include constraints, rules, and dynamics (state
transitions and so on). SEOO draws a clear line between shared objects and other objects, and regards the
shared objects as important interfaces between subsystems. This technique allows a distinction, for example,
between customer behavior shared by all applications and customer object behavior unique to a single
application. It is a technique with which a purist would quibble, but which is eminently practical.

Rumbaugh OMT

It offers one of the most complete descriptions yet written of an OO analysis methodology. Although it is
somewhat lacking in OO design and construction, it contains a large number of ideas and approaches that are of
significant use to analysts and designers.

Rumbaugh starts by assuming that a requirements specification exists. Analysis consists of building three
separate models:

* the Object Model (OM): definition of classes, together with attributes and methods; the notation is similar to
that of ER modeling with methods (operations) added

* the Dynamic Model (DM): state transition diagrams (STDs) for each class, as well as global event-flow
diagrams

* the Functional Model (FM): diagrams very similar to data flow diagrams

Because Rumbaugh's notation (as well as that of Booch and Shlaer and Mellor) is supported by low-end
drawing tools such as Visio, I have used it not only for OO analysis, but for a number of diagrams in recent
proposals. For example, I recently drew a diagram of project deliverables (in a proposal for a large OO
development project) using Visio and Rumbaugh notation to show the object hierarchy of deliverables which, at
the first level of inheritance, included hardware, software, and printed deliverables.

Of the major methodologies, Rumbaugh's is one of those with which I feel most comfortable. It supports many
traditional diagrams from structured methodologies, and contains a much richer object modeling notation than
Coad and Yourdon's. Its weakness at this time is that is it less useful for client/server application design and
construction, but experienced analysts can overcome this with enough experience with class libraries for their
development tool, if they have successfully completed other OO projects.

Shlaer and Mellor OO Analysis

When Shlaer and Mellor OO analysis first came out in 1988, it represented one of the earliest examples of OO
methodology and it has evolved very positively since then. (See Shlaer and Mellor's books, Object-Oriented
Systems Analysis -- Modeling the World in Data and Object Lifecycles: Modeling the World in States,
Prentice-Hall, 1988 and 1992, respectively.)

Originally an object-based extension of data modeling, the Shlaer and Mellor methodology starts with an
information model describing objects, attributes, and relationships. (Note that this is more like a data model
than an object model.) Next, a state model documents the states of objects and the transitions between them.
Finally, a data-flow diagram shows the process model.

This methodology seems to be influenced strongly by relational design, but I have not seen it used for
client/server development. This does not mean that it is not usable for such work, but the applications
occasionally cited as examples of its use seem to be in the areas of real-time or process control. This may have
to do with the fact that an earlier version, the Ward/Mellor approach, is widely used in the realtime world.

Using, Not Abusing, Objects

Upon reflection, my discomfort with OOAD may be merely a side effect of the enormous rate of change in our
industry. The object architectures that I used in PowerBuilder 3.0 were no longer optimum for PowerBuilder
4.0, and PowerBuilder 5.0 suggests yet another new class library architecture. The same is true of all other OO
languages. How do we deal with methodologies and development tools that continue to evolve rapidly? How do
we train analysts that may be less versed in the new approaches than the developers are? And how do we assure
that the analysts can deal with what I call the object problem, that is, the fact that using objects requires more
attention to systems architecture than in the past?

The answers lie in training, commitment, experience, discipline, and pragmatism. Of these, the latter two may
require the most attention. Discipline requires us to question what we are doing every day, assure that we are
working on the right objectives every hour, and assure that we are doing this efficiently. Pragmatism in the OO
world, to me, means being certain that my object guru is not an object bigot.

It seems that there are too many object bigots who build excessively complex object architectures and don't
realize that objects can be overused just as easily as the go to statement in Cobol can be abused. I am astounded
at the number of gurus who "ooh" and "aah" (or should I say "om") at every new feature in every new OO
development tool, believing each feature to be the solution to all their problems. But it never is. No one feature
will make all software trivial to write, and no one architecture will be ideal for all problems. Creating good
software will continue to be hard work.

One of my object experts, considered a guru by many, was formerly an object bigot. That changed when he
spent several months trying to force a complex set of business rules into an OO methodology that didn't support
them (at least not without significant adaptation). While he was smart enough to learn from his mistake, the
experience was very expensive. You must be able to recognize quickly if the object methodology isn't working
for your particular project, and you must find another approach that does work, whether it is object oriented or
not.
I have no doubt that OOAD methodologies can deliver faster, better code that is more reliable and reusable than
ever before, but the combination of turmoil and immaturity in the object world requires a great deal of caution
and pragmatism. After my first two years of working in Windows, that is, a GUI world without objects, I saw
that there were more ways to do things right than ever before, but just as many ways to do things wrong. I have
recently come to believe that the same is probably true of objects. If you do not have staff with the right
combination of training, skill, and experience, the object world will not be a better world.

Table 1. Major OOAD Methodologies

Analysis Propri- Type Scope Strengths Primary Cited
Methodology etary Applications /
Markets

Booch No Ternary Complex, Design All

Rich,
Pragmatic

Coad and No Unary Simple, Analysis Client/Server

Yourdon Limited,
Pragmatic

Fusion No Ternary Complex, Full Life All

Rich, Cycle
Pragmatic

Jacobson Yes Ternary Complex, Full Life All

Objectory Rich Cycle

LBMS SEOO Yes Ternary Middle of Full Life Client/Server

the Road, Cycle
Pragmatic

Rumbaugh OMT No Ternary Complex, Analysis & All, but

Rich, Design heavily
Somewhat Embedded,
Pragmatic Real-Time

Shlaer and No Ternary Complex, Design Embedded,

Mellor OOA Rich Real-Time

Table 2. The Steps in Booch's Methodology

Steps Notations

Logical Class Diagrams

structure Object Diagrams

Physical Module Diagrams

structure Process Diagrams

Dynamics of State Transition

Classes Diagrams
Dynamics of Timing Diagrams
Instances