articles

D a v i d E. M o n a r c h i and Gret(:hen I. O u h r

A Research Typology for

Object-Oriented Analysis
and Design
his article evaluates current research on object-oriented analysis and design
(OOAD). Critical components in OOAD are identified and various OOAD
techniques (i.e., processes or methods) and representations are compared based
on these components. Strong and weak areas in OOAD are identified and areas for future
research are discussed in this article. • • • • • • • • • • • • • • • • • • •

T h e authors assume the reader
has a basic understanding o f object-
oriented concepts and the object
paradigm in general. (Excellent dis-
cussions and definitions of the ob-
ject paradigm are contained in the
first section [5] and in [29].) We use
"class" to mean a collection o f
things with common attributes and/
or behavior; "instance" to mean a
realization of a class (one of the
things in a class), and "object" to
mean either a class or an instance
(as in Smalltalk).
There is a great deal of current
literature on object-oriented (OO)
systems development. But there is,
as yet, little consensus or standardi-
zation among these new develop-
ment techniques. At one extreme
are "pure" thoroughbred OO de-
velopment techniques, encompass-
ing OO analysis, design and/or
implementation [11]. They involve
new notations and approaches that
are different from more traditional
function- or data-oriented model-
ing techniques. At the other ex-
treme are approaches that are
termed "object-oriented," but
which seem to be little more than
new words applied to old concepts.
In between are various analysis and
design techniques, many overlap-
ping in scope and/or conflicting in
approach. Notations that blend ob-
ject-orientation with process, data
and other modeling techniques
may be poorly integrated and bal-
anced with each other. As Iivari
[13] notes, "Despite their common
roots, the different OO approaches
are not particularly well inte-
grated." In short, there are volumes
o f information on OOAD, but
there is a lack o f mechanisms or
frameworks for synthesizing or
evaluating the work that has been
done. This article addresses that
void.
Mrdalj [20] recognizes a "need
for collection, classification and
evaluation of the available material"
and his bibliography is a collection
o f 83 references which, taken to-
gether, represent much of the re-
search on object-oriented systems
development. He does not, how-
ever, provide a classification or
evaluation of the research identi-
fied. Ladden [16] discusses several
factors to consider in developing an
object-based methodology and
specifies an object-based design
process. These factors are not
meant to be a complete listing o f
the essential ingredients in OO sys-
tems development; they are simply
desirable characteristics o f an object
methodology. Ladden does not in-
vestigate to what extent existing
research addresses his factors or
complies with his design process.
Henderson-Sellers and Constantine
[11] outline several systems devel-
opment methodologies and strate-
gies which incorporate object-
orientation to varying degrees.
They mention the OO thorough-
bred approach, as well as two hy-
brid methodologies, which combine
function- and object-oriented ap-
proaches. They also suggest a "syn-
ergistic" methodology which blends
function- and object-oriented tech-
niques during specific phases of
development. These different
methodologies provide a useful
classification, which may assist re-
searchers and practitioners in eval-
uating the various OO methodolo-
gies and techniques. However, this
classification only considers one
aspect of OO methodologies, the
degree to which (and the manner in
which) function- and object-
oriented approaches are incorpo-
rated.
This article develops a frame-
work for evaluating and comparing
current object-oriented analysis
and design (OOAD) research. The
framework will serve as a basis for
assimilating various pieces of re-
search into a cohesive and complete
O O A D methodology. The objec-
tives of this article are: 1) to identify
critical components in a "complete
and cohesive" O O A D methodol-
ogy; 2) to evaluate current O O A D
approaches and representations
based on these components; and 3)
to identify strong and weak areas in
O O A D research.
Research Review
The existing research can be di-
vided into three broad categories:
1) processes only; 2) representa-
tions only; and 3) processes and
representations. The first category,
processes, refers to procedural
methods for performing object-

COMMUNICATION8 OF THE ACM/September 1992/Vo1.35, No.9 ~


oriented analysis or design, or some
particular aspect o f analysis or de-
sign. These processes do not in-
clude O O A D diagrams or nota-
tions. The second category,
representations, refers to graphical
notations or diagrams for depicting
the output of OOAD. T h e focus is
on visually representing a design,
not on how to derive a particular
design. T h e third category, pro-
cesses and representations, encom-
passes both processes for perform-
ing (some subset of) O O A D and
representations for specifying the
results.
Table 1 groups the research re-
viewed in this article into these cate-
gories. This list of research is not
meant to be complete; it is, how-
ever, intended to be representative
of work being conducted on OO
systems development. The research
listed spans a brief time period, ba-
sically from 1988 to 1991. While
there are publications on OO sys-
tems prior to 1988, in general these
earlier articles focus mainly on ob-
ject-oriented programming or gen-
eral object-oriented concepts. More
recently, in the late 1980s and early
1990s, OO research has turned
toward methods and notations for
object-oriented systems develop-
ment. Mrdalj's [20] collection en-
compasses much of the research
that has been done on OO systems
development. Many of the sources
reviewed in this article are included
in Mrdalj's bibliography.
BackgrOund
Various systems development
methodologies have evolved, corre-
sponding to different systems life
cycles, such as the traditional water-
fall model [23] and the fountain
model [12]. Despite individual dif-
ferences in the models and their
variations, they all have compo-
nents corresponding to analysis,
design, and implementation. In this
article, we do not specifically ad-
dress implementation or physical
design; we will focus on analysis
and logical design for object-
oriented systems.
Analysis involves problem defini-
36
o'R
artEcles
1ruble 1.
Research R e v i e w e d
CATEGORY 1
Process only (no representation)
Bulman [61
Henderson-Sellersand Constantine [11]
Johnson and FOOte[14]
Scharenberg and Dunsmore [25]
CATEGORY 2
Representation only (no technique)
Ackroyd and Daum [l)--a graphical notation
Beck and Cunningham [4]--Class-Responsibillty Collaboration (CRC) cards
Cunnlngham and Beck [9)--message diagrams
Page-Jones et al. [22)--Uniform Object Notation (UON)
Wasserman et al. [27|--00 Structured Design Notation (OOSD)
Wilson [28]~Class Diagrams
CATEGORY 3
Process and Representation
Alablso [2)--Transformation from Analysis to Design (TAD)
Bailin [3)--Object-Oriented Requirements Specification Method
BoOch [5[--Object-Oriented Design
Coad and Yourdon [7)=Object-Oriented Analysis (OOA) and Design (OOD)
Gorman and Chooblneh [10]--Object-Orlented Entity Relationship Model
(OOERM)
Ilvarl [13]--A Framework for Object identification
Kappel [15]--Object/Behavior Model
Lleberherr et al. [181--The Law of Demeter
Meyer [19)--Object-oriented Software Construction
Rumbaugh et al. [24)--Object Modeling Technique (OMT)
Shlaer and Mellor [261=ObJect-Oriented Systems Analysis (OOSA)
wires-Brock et al. [29]~Designing Object-Oriented Software
analysis
Real World Problem
Problem
Domain
Representation
design
Solution Domain
Representation
F i g u r e 1. The relationship between analysis and design
September 1992/Vo1.35, No.9/COMMUNICATIONS OF T H E A C M

tion/modeling and design focuses
on solution specification/modeling
[7, 8, 30]. Systems design trans-
forms the problem representation
into a solution representation.
Figure 1 depicts the relationship
between analysis and design. T h e
problem and solution domain rep-
resentations are different and
smaller than the real-world prob-
lem. And the solution domain in-
cludes everything in the problem
domain, plus any additional con-
structs required by the solution. For
example, the user interface is typi-
cally part of the solution to a prob-
lem, rather than a part of the prob-
lem itself.
Colter [8] and Pressman [23] de-
scribe a n u m b e r of analysis and
design methodology characteristics.
These characteristics can be sum-
marized, extended and applied to
the object arena. OOAD compo-
nents include:
(1) An OOA process: A general-
domain analysis technique (i.e., an
analysis procedure, the "how to's");
(2) An OOD process: A solution do-
main modeling technique (includ-
ing the specification of interface
objects and other solution domain
objects discussed later in this sec-
tion);
(3) OOAD representations: For struc-
ture, function and control at differ-
ent levels of abstraction (the macro
and micro layers are two key ab-
straction levels); and
(4) An OOAD complexity abstraction
and management mechanism: For par-
titioning the problem and manag-
ing the complexity of the system.
OOA or OOD
Using these criteria to e v a h a t e cur-
rent OOAD techniques may be dif-
ficult because of the blurred dis-
tinction between analysis and
design in the object paradigm. T h e
first two criteria indicate that prob-
lem domain analysis is distinct and
separate from solution domain de-
sign. It is, however, difficult to find
a clear distinction in the OOAD re-
search. In particular, it is difficult
to determine where O O A ends and
OOD begins. This phenomena is
COMMUNICATIONSOF THE ACM/Septembcr 1992/Vo1.35, No.9
articles
reflected in the overlapping stages
in Henderson-Sellers and Edwards'
fountain model [12].
Some authors present only O O A
methods (e.g., [17, 26]). Most of
these analysis methods emphasize
modeling the problem domain, or
"universe of discourse" [13]. They
are concerned with abstracting rel-
evant objects form the problem
domain, defining the objects' struc-
ture and behavior, and determin-
ing the objects' interrelationships.
A goal of O O A is to model the se-
mantics of the problem, in terms of
distinct but related objects.
Other authors focus on OOD
(e.g., [5, 19]) rather than OOA.
They assume that relevant problem
domain objects have been identi-
fied. They model the details of each
object's behavior and the interob-
ject communications (messages)
necessary to meet system require-
ments. O O D also involves reexam-
ining the problem domain classes--
refining, extending or reorganizing
t h e m - - t o improve reusability and
take advantage of inheritance.
In general, the OO analyst may
be more concerned with the struc-
ture of objects and the OO designer
with the dynamic behavior of ob-
jects. But even this is not necessarily
true. Coad and Yourdon [7] men-
tion state-transition diagrams and
other dynamic representations as
part of OOA, whereas Booch [5]
discusses dynamic views of the sys-
tem in OOD. Rumbaugh et al. [24]
use separate structural, dynamic
and functional representations
during both analysis and design.
Kappers [15] notation, which is
based on two dynamic models, state
transition diagrams and predicate
transition nets, integrates static
structure and dynamic behavior
into one design model.
To further complicate the issue,
the analysis and design stages in
OO development are frequently
comingled. Many authors (e.g.,
[29]) espouse an iterative develop-
ment strategy in which objects
are identified and defined, and re-
lationships and communication
patterns are specified. As the devel-
oper continues defining relation-
ships, behavior and communica-
tion, he or she finds new classes
and/or redefines existing classes.
Table 2 lists the steps or activities
in OO analysis and/or design that
various authors have proposed.
One common theme is that the
problem domain objects must
somehow be identified, and their
meaning defined. This process is a
part of all the O O A techniques re-
viewed and some of the OOD
methods as well. Beyond object
identification, though, there is little
agreement on what other functions
are involved in OOAD.
Although there is no standardi-
zation across existing OOAD meth-
ods, the definitions of analysis and
design can be used to distinguish
O O A from OOD. Analysis deals
with the problem domain, and de-
sign with the solution domain;
OOA focuses on problem domain
objects and O O D on solution do-
main objects. Figure 2 shows a clas-
sification of problem and solution
domain objects which are discussed
in the following paragraphs.
Problem-domain objects repre-
sent things or concepts used in de-
scribing the problem (rather than
the solution). We call them seman-
tic objects because they have mean-
ing in the problem domain. For
example, an order entry system
might have semantic classes such as
Customer, Order, Item and Employee.
T h e solution domain includes, but
is not limited to, the semantic ob-
jects. During analysis, the focus is
on representing the problem, iden-
tifying abstractions that are mean-
ingful given the system require-
ments and specifications. During
design, the emphasis is on defining
a solution. T h e semantic classes
may be extended during analysis or
design, as useful abstractions are
discovered. In the order entry ex-
ample, an abstract class Person may
be created as the superclass of Cus-
tomer and Employee.
Other kinds of solution-domain
objects include: interface, applica-
tion, and base/utility objects. Inter-
face objects are associated with the
37

T a b l e 2.
Examples of OOAD Processes
OOA PROCESSES
Coati and Yourclon I71:
Find class-and-objects
Identify structures
Identify subjects
Define attributes
Define services
Rumbaugh et al. ]241/shlaer and Mellor [26]: Initial exploration (classes, resp.,...)
Build object model/Information model
Build dynamic model/state model
Build functional model/process model
Alabiso [21:
Perform structured analysis
Translate DFDs Into an object model
Lee and Carver [171:
AbStract facts from data-flow diagrams
Abstract objects and actions from facts
Construct entity-relationship model
Construct object model
Solution Domain
F i g u r e 2. Problem and solution do-
main objects
user interface. They are not di-
rectly a part of the problem do-
main; instead they represent the
users' view(s) of the semantic ob-
jects. Application objects can be
thought of as the drivers or control
mechanisms for the system. They
are objects that start the application
and perhaps control the sequencing
of high-level functions. In proce-
dural languages, this corresponds
to the main module. In d O devel-
opment, the application class may
do nothing more than drive a menu
or initiate message-passing to other
38
IBm,t i c les
OOD PROCESSES
BOOCh IS]:
Identify objects
Identify semantics of objects
Identify relationships
Implement and iterate
Wirfs-Brock et al. 1291:
Detailed analysis (relationships,...)
Build subsystems
Shlaer and Mellor 126]:
Build system architecture design
Build data structure design
Bulman [61:
Identify candidate objects
Specify objects
Refine objects and operations
Complete operations
Design object-oriented structure
objects. Base/utility objects are com-
ponents that are application-inde-
pendent. The main characteristic of
base/utility objects is that they are
application- and domain-indepen-
dent. Examples of base objects are
collections (strings, arrays, etc.) and
numbers; an example of a utility
object is the debugger window in
Smalhalk.
In summary, the boundary be-
tween OOA and O d D is inconsist-
ently defined in the literature.
Some processes used by one author
during OOA may be included in
another author's O d D technique.
In fact, most of the O d D processes
are the same as (or are a superset
September 1992/Vol.35, No.9/GOMMUNiGATIONSOF T H E AGM
oi) the OOA processes; what is dif-
ferent is the objects or domain to
which the processes are applied.
Using the categorization of objects
just described, we can distinguish
between OOA and O d D in the fol-
lowing manner:
O0 Analysis (.OOA) models the
problem domain by identifying and
specifying a set of semantic objects
that interact and behave according
to system requirements.
O0 Design (ODD) models the solu-
tion domain, which includes the
semantic classes (with possible addi-
tions) and interface, application,
and base/utility classes identified
during the design process. O d D
should still be language-indepen-
dent, and precedes physical design.
These are the two primary compo-
nents in OOAD. In addition, as dis-
cussed earlier, OOAD needs to
graphically or textually represent
its results and to manage analysis
and design complexity.
OOAD C o m p o n e n t s
Table 3 lists critical components in
OOAD. These components are
based on the combined Colter/
Pressman criteria with the exten-
sions and additions discussed in this
section. Many of these components
can be generalized to apply to any
methodology, but Table 3 presents
them as they apply to the object
paradigm.
There are static (structural) and
dynamic (control) considerations in
each of the four major areas de-
fined in Table 3. For example,
items (1)(a) and (1)(b) address
structure, while item (1)(c) consid-
ers control. Figure 3 depicts the
structural aspects of Table 3 in
more detail. In particular, Figure 3
shows the relationship between the
identification and placement pro-
cesses (items (1)(a) and (b)) as they
apply to both problem- and solu-
tion-domain objects.
The processes in Figure 3 are the
same for both the problem space
and the solution space, but they dif-
fer in the kinds of objects used. The
problem space is defined during
OOA in terms of semantic objects
 ortlcles

(noted by the subscript s); the solu-

1 ~ b l e 3.
tion space is defined during C O D Critical C o m p o n e n t s In OOAD
in terms of semantic, interface,
application and base/utility objects (1) OOA: PrOblem Domain Analysis Process
(noted by the subscript values s, i, a
or b). (a) Identification of:
semantic classes
Regardless of whether the do- attributes
main is the problem or solution behavior
relationships (e.g., generalization, aggregation, association)
space, an important process in (b) Placement of:
O O A D is the identification of classes
classes, attributes and methods (be- attributes
behavior
havior), noted in Figure 3 by C, A (c) Specification of dynamic behavior
and M, respectively, and shown on
(2) OOD: Solution Domain Design Process
the left side o f the figure. Relation-
ships between classes are also part (a) Same as (a), (b) and (c) above, applied to the following kinds of classes:
o f the identification process. The Interface
class lattices listed on the right side Application
Base/Utility
of the figure signify the kinds of (b) Optimization of classes
relationships which may be speci-
(3) OOAD Representations
fied among classes (and instances).
All of these elements in Figure 3 (a) Static view:
represent the identification phase of Objects
Attributes
O O A and C O D (e.g., As means the Behavior
identification of semantic attri- Relationships:
butes). The arcs represent the place- Generalization
Aggregation
ment of attributes, methods, and Other (e.g., ASSOciation)
classes. Attributes and methods (b) Dynamic View:
Communication
must be allocated to (or placed in) Control/Timing
classes; classes are arranged into (c) Constraints:
predefined relationships or organi- on structure (attribute values, relationship cardlnalltles)
On dynamic behavior
zations. Notice that the two pro-
cesses fit together in a complemen- (4) OOAD Complexity Management
tary way, both diagrammatically
(a) Mechanism for conceptually managing structural complexity
and operationally. (b) Mechanism for conceptually managing behavioral complexity
Two relationships are explicitly (c) Representation of system level:
declared in the figure: AKO (a- Static Structure
Dynamic Behavior/Control
kind-of, generalization-specializa-
tion) and APO (a-part-of, aggrega-
tion). Most authors would agree
that these are two primary ways o f
For the Problem and the Solution Space
organizing objects, or two kinds of
generic relationships among ob- IDENTIFICATION
jects. T h e r e are many other kinds
of relationships which could be de-
fined; these are grouped under
"Association Lattices," since there
does not appear to be a high degree
of consistency across the research in
terms of what these relationships
are and what they mean. An exam-
ple o f a user-defined association
lattice may be a "uses" lattice, as PLA CEMENT
Where
described by either [5] or [1]. Other A = attributes.
possibilities are AEO (an-element- M -- methods.
C -- classes.
of) and AVO (a-view-of). n = {s, i, b, a} and
s = semantic, I = interface, b = base/utility, a = application.
A K O = A Kincl Of, or generalization, relationship.
F i g u r e 3. OOAD: Identification and A P O = A Part Of, or aggregation, relationship.
placement processes

COMMUNICATIONS OF THE ACM/Septernber 1992/Vol.35, No.9 39

 The relationships specified in
Figure 3 are of the form
<relationship name> Lattice. The
term lattice is used because it en-
compasses hierarchical tree struc-
tures and one-to-one relationships,
as well as lattices. Many OO pro-
gramming languages do not sup-
port multiple inheritance (i.e., lat-
tice class structures); however, the
analysis and (logical) design stages
should be implementation-inde-
pendent and should therefore per-
mit modeling lattices if this best
represents the situation. Similarly,
AKO is the only kind of relation-
ship directly supported in most OO
programming languages, but other
relationships may be utilized dur-
ing OOAD to represent the seman-
tics of the problem and solution
spaces. How these other lattices will
be implemented in a particular lan-
guage is an issue for more detailed
design or implementation phases
(which are not specifically ad-
dressed in this article).
An important point to emphasize
with regard to Figure 3 is that it
does not indicate the order in which
problem or solution space elements
should be identified or placed. This
is intentional: classes, attributes,
and methods may be identified in
any order, and may be placed in
any order once they are defined.
(Obviously, an attribute or method
cannot be allocated to a clas,~ until
that class is defined; similarly,
classes cannot be placed in a rela-
tionship lattice unless they and that
relationship have been defined.)
There may be a sequencing of these
processes which works "best" or an
order which is advocated by some
authors; however, in our experi-
ence, the discovery and allocation
of attributes, methods and classes is
an iterative, nonsequential process.
At this time, the effectiveness of
various strategies seems to be
highly dependent on the back-
ground and expertise of the ana-
lyst/designer and the characteristics
of the problem space, as well as the
merits of any particular strategy.
Figure 3 addresses only the
structural (static) aspects of OOAD;
40
it does not address dynamic consid-
erations such as control or commu-
nication (message-passing). Refer-
ring again to Table 3, OOAD
representations are needed for
static and dynamic views of the sys-
tem at both macro and micro levels
(see the following paragraphs).
Static representations should por-
tray objects, relationships, attri-
butes, and methods (the elements
shown in Figure 3). Dynamic repre-
sentations should depict communi-
cation (message-passing) and con-
trol. In addition, the constraints
specified for the system in such
areas as attribute values, relation-
ship cardinalities, and error han-
dling may be supported by the no-
tations.
The last major component of
OOAD (referring to Table 3) is
complexity management. Com-
plexity management is important
from both a conceptual and visual
standpoint. Different views of a sys-
tem have been defined that are
meaningful and can help in manag-
ing a large, complex design: micro
and macro; static and dynamic. The
micro level includes the individual
classes and their interrelationships.
The macro level includes groupings
of these classes (e.g., subjects in [6]).
Naturally, there can be multiple
macro levels just as there are multi-
ple levels in data-flow diagrams.
And there may be macro levels or-
ganized according to different cri-
teria (aggregation vs. generaliza-
tion, for example). Both the macro
and the micro levels have static and
dynamic characteristics. However,
while a micro-level diagram obvi-
ously consists of objects, it is not
clear what constructs are shown on
a macro-level diagram. Complexity
management requires that we: 1)
define the base component for a
macro-level diagram (the counter-
part to an object on a micro-level
diagram); 2) provide guidelines on
identifying or deriving this compo-
nent; and 3) specify the graphical
representation of this construct,
including its relationship to lower-
level constructs and its static and
dynamic features.
September 1992/Vol.35~No.9/COMMUNICATION$
Several mechanisms have been
developed which address this ques-
tion. Some mechanisms group ob-
jects based on a particular relation-
ship (e.g., generalization) in which
they participate; others group ob-
jects based on dynamic communica-
tions they share (e.g., objects which
send messages to .each other to ac-
complish some high-level function).
Coad and Yourdon's [7] subjects
are an example of the former;
Wirfs-Brock et al.'s subsystems [29],
Meyer's clusters [19], and Johnson
and Foote's frameworks are exam-
ples of the latter [14]. (Frameworks
are at a higher level of abstraction
than subsystems and clusters.)
These mechanisms manage struc-
tural complexity. One of the few
constructs which addresses behav-
ioral complexity is contracts [29].
Another mechanism for managing
complexity is the use of patterns
discussed, for example, by
Nierstrasz et al [21].
Table 4 tabulates the literature
based on whether the authors ad-
dress each component in Table 3.
As noted in the table, a shaded cell
indicates the issue is addressed; a
blank cell indicates it is not. The
table does not grade the research
on how well the issues are handled;
it simply identifies consideration of
a topic.
Observations on C u r r e n t OOAD
Processes a n d
Representations
An overall review of Table 4 rein-
forces our initial classification of
the research. We can quickly see
which authors provide only a rep-
resentation (only the boxes under
Representation have shading)
which focus only on the analysis or
design process, and which address
both process and representation.
Observations on OOA Processes
(refer to section [4] of Table 4).
Most of the problem-domain analy-
sis components have been ad-
dressed by (at least) several authors.
The identification of semantic
(problem-domain) classes and be-
havior has been extensively c o v -
OF THE A C M

ered. It is interesting to note that
identifying attributes has not been
addressed as often as behavior. A
reason for this is that an object can
be viewed as an encapsulation of
both structure and behavior which
can be accessed only via its inter-
face. Therefore, some authors (e.g.,
[6, 29]) feel that it is not important
to specify attribute names, or any
object internals--the external spec-
ification of the object (its interface)
is sufficient.
We agree that objects are encap-
sulations of data and behavior and
that they have an interface to other
objects. At a conceptual level, how-
ever, the characteristics (attributes)
of an object are an important, inte-
gral aspect of that object's semantic
definition. For example, name and
social security number seem natural,
logical properties of an employee.
They should be modeled as part of
the employee object's structure.
While identifying classes, attri-
butes and behavior has been fairly
thoroughly covered, placing them
has been largely neglected. Most
research in placement has been
done with respect to methods. T h e
Law o f Demeter [18], for example,
provides some valuable operational
rules for placing methods and re-
stricting the messages a method can
send. Other O O A D research, how-
ever, includes overly simplistic rules
or rules based on mappings from
data-flow diagrams to behavior in
objects (e.g., [2] and [17]). Another
problem is that placing methods in
the appropriate classes implies that
the classes have already been placed
correctly (again refer to the Law of
Demeter). T h e heuristics o f placing
classes, however, are weak, itera-
tive, and often nonoperational.
Meyer [19] provides an example of
a window-oriented text editor,
which can be placed as a subclass of
a class window, a class text editor, or
both, or neither. Is a window-
oriented text editor a special kind
of window, or text editor, or both?
I f it is any of these, a generalization
structure is appropriate. On the
other hand, the new object may not
be a specialization of an existing
COMMUNICATIONS OF THE AOM/September 1992/Vol.35, No.9
articles
object; it may be a new object which
simply has a window and a text edi-
tor as components. This implies a
different kind of class structure. We
could not find any practical guide-
lines to determine where to place a
new class in situations like this.
Observations on OOD Processes
(refer to section [2] of Table 4)
OOD involves the same processes
used during analysis, applied to dif-
ferent kinds of objects. O u r division
of objects into semantic, interface,
application, and base/utility is not a
widely accepted division. There-
fore, we might expect that few au-
thors have addressed these specific
categories o f objects. Several au-
thors, however, describe objects
that fit our definition of base/utility
objects. Wirfs-Brock et al. [29], for
example, describe component ob-
jects, black boxes that can be reused
in many systems. Bulman [6] dis-
cusses new abstract data types
(ADTs) which may be identified
during design and added to the sys-
tem library. He states that ADTs
may be discovered as designers see
a need for a new kind of data struc-
ture and that the original design
should be examined to see if objects
can be added as reusable "compo-
nents." This is the only guideline
we located for finding base/utility
classes.
User interfaces are a prevalent
and integral part of systems devel-
opment today and should be a part
of any software analysis and design
methodology. Surprisingly, inter-
face objects are rarely addressed
unless the system being modeled is
one in which the interface objects
are part of the problem domain
(automated teller machines, for
example) Iivari [13] recognizes the
absence of interface objects in other
analysis methods and includes them
in his framework for identifying
objects. A few other authors men-
tion that user interfaces are an ele-
ment o f systems, but they offer little
in the way of identifying or model-
ing interface objects.
Application objects are rarely
discussed in the literature. These
objects, as mentioned earlier, may
be viewed as the drivers of a partic-
ular application. Application ob-
jects are different from semantic
classes; they are probably not
things, concepts, roles, or devices
which could be identified during
problem-domain analysis. Applica-
tion objects are also different from
interface objects, which are essen-
tially views o f the semantic classes.
An application object is not a kind
of interface object, although it may
use an interface object (e.g., a main
application window). Application
objects are also different from base/
utility objects; they are not applica-
tion-independent. Application ob-
jects are somewhat like function
objects described by [25] in that
they are best defined by what they
do rather than what they are. Appli-
cation objects may not have a state
that persists over time; typically,
they have only behavior. For these
reasons, we consider application
classes separately from semantic,
interface, and base/utility classes.
Another activity in OOD is refin-
ing classes. This involves examining
the class structure for opportunities
to abstract c o m m o n behavior and
attributes. It also involves making
sure the classes are complete and
correct in their design. Are there
methods missing? Are the methods
and attributes in the proper place?
Considerable work has been
done on refining classes, particu-
larly with regard to finding better
abstractions (classes), creating
deeper hierarchies, and refining or
adding methods. Bulman [6] points
out that abstractions and better hi-
erarchies can be discovered as we
examine other classes, looking for
c o m m o n features and/or behavior.
He also suggests several questions
to ask when deciding if a class's
behavior is adequate (complete).
For example, are there other be-
haviors that make sense for an ob-
ject but which have not been in-
cluded because they were not in the
requirements specification? Is there
an inverse (undo) operation, or a
complementary operation which is
an appropriate addition to an ob-
41
 T a b l e 4.
Comparison o f OOAD Representations and Processes

PROCESS AND
REPRESENTATION

Coad Gorman Lleb- Rum-

and and erherr baugh Lee &
Alablso Ballln Booch Yourdon Chooblneh Ilvarl Kappel Carver et al. Meyer e t a l .

1. OOA PROCESS
Problem Domain Analysis
(a) Identification of:
Semantic classes X X x x x X x x X x
Attributes X X x X
Behavior X X X X X X X X X
Relationships:
Generalization X X X X X X
Aggregation X X X
Other X X
(b) Placement of:
Classes X X
Attributes X
Behavior X X X X X X X X
(c) Specification of:
Dynamic behavior X X X
(i.e., message passing)

2. OOD PROCESS
Solution Domain Design
(a) Identification of:
Interface classes X X
Application classes
Base/utility classes X X X
(b) Optimization o f classes X X X X X

3. REPRESENTATIONS
(a) static View
Objects x x x X X x x X X X
Attributes X X X X X X X X
Behavior X X X X X X X X X X
Relationships:
Generalization X X X X x x X X x
Aggregation X X X X X
Other X X X
(b) Dynamic View
Communication X X X X X X
Control/Timing X X X X x x
(c) Constraints
On structure X X X X
On dynamic behavior X X X

4. COMPLEXITY MGT.
(a) For structural complexity X X X X X
(b) For behavioral complexity
(c) Representation of:
Static structure X X
Dynamic behavior

No. o f Issues Addressed 12 5 21 19 12 9 12 8 2 9 20

A marked cell indicates that the issue is addressed; a blank cell indicates that it is not. The table does not grade the research on how well the issues are handled; it simply identifies
consideration of a topic.

42 September 1992/Vol.35 No.9/COMMUN CAT ONSOFTHEACM

 arficleS

REPRESENTATION PROCESS
ONLY ONLY

Shlaer Wlrfs- BeCk and Cunning- Page- Wasser- Henderson- JOhnson Scharen-
and Brock Ackroyd Cunning- ham Jones man Sellers and and berg and
Mellor et al. & Daum ham and BeCk et al. et al. WilSOn Bulman Constantine Foote Dunsmore

X X X X X

X X X X X

X X X X
X
X

X X

X X X

X
X X
i

X X X X X X X X
X X X X
X X X X X X X X

X X X X X X

X X X X

X X X X X
X X

X X X
X
i

X X X
X

13 15 5 3 4 5 8 5 7 3 5 6

G O M M U N I G A T I O N S OF T H E ACM/September 1992/Vol.35, No,9 43

ject's protocol? Bulman uses the
example of an add operation which
should also have an inverse delete
operation and a complementary
modify operation.
Observations on Representations
(refer to section [3] of Table 4)
One of the first things to note is the
large n u m b e r of static representa-
tion models. These representations
all model similar constructs; how-
ever, the notations used and con-
structs emphasized vary greatly. A
detailed comparison of all the rep-
resentations is beyond the scope of
this article. There are, however,
some important observations that
can be made.
First, there are more OO static
models than OO dynamic models.
O f the dynamic models that are in-
cluded, most of them consist of
state transition diagrams which
must then be mapped or translated
into behavior in an object model.
One reason for the emphasis on
static structure rather than dynamic
behavior may be the heavy influ-
ence on O O A D from data model-
ing. Data modeling focuses primar-
ily on structure, not dynamic
behavior or control. Dynamic mod-
eling, on the other hand, focuses on
event-handling--the sequence,
timing and control of events and
processes. Dynamic modeling is
currently used for real-time systems
and office automation applications
[15]. As the popularity of dynamic
modeling increases, we may see
more of a balance between the
number of static and dynamic rep-
resentations in OOAD. For exam-
ple, Kappel's object/behavior model
includes a set of diagrams that
model both structure and behavior
of objects. Many of the diagrams in
his model are extensions to existing
dynamic models.
Another important point regard-
ing notations involves the represen-
tation of relationships. As seen in
Table 4, most representations sup-
port generalization relationships.
Aggregation relationships are also
supported, but to a lesser extent.
Beyond that, several other relation-
ships are mentioned, but none is
well supported by representations
or accepted by many authors. One
explanation for the wide accept-
ance of generalization structures is
that they are directly supported in
object-oriented programming lan-
guages.
Observations on Complexity
Management (refer to section [41
of Table 4)
Many authors provide a conceptual
grouping mechanism to manage
the complexity of large designs.
Most of these mechanisms manage
structural complexity; i.e., they are
a way of grouping classes into more
abstract "things." Coad and Your-
don's subjects [7] and Wirfs-Brock
et al.'s subsystems [29] are two ex-
amples of problem-partitioning
mechanisms.
A subject is a mechanism that
encapsulates objects in any rooted
structure or substructure (e.g., a
generalization or aggregation
structure). Subjects are created by
collapsing a structure down to its
root, thereby reducing its complex-
ity. Wirfs-Brock et al.'s subsystems
are different from subjects in that
they are not necessarily based on
rooted structures. A subsystem con-
sists of classes or other subsystems
that work together to achieve some
higher-level function. (Subsystems
have long been used as an engi-
neering design principle). For ex-
ample, an automated teller ma-
chine application might have a
financial subsystem and a user-
interface subsystem [29], which are
defined by their functionality
rather than by a structural relation-
ship. While subsystems are a useful
mechanism for reducing complex-
ity, it may be difficult to operation-
alize the identification of subsys-
tems. T h e authors of these
mechanisms do not provide many
heuristics for identifying subsys-
tems.
Subjects and subsystems are sup-
ported by Coad and Yourdon's and
Wirfs-Brock et al.'s representations,
respectively. Other authors suggest
conceptual grouping mechanisms,
September 1992/Vol.35,No.9/COMMUNICATIONSOF THE ACM
but do not provide a tool for repre-
senting them. Rumbaugh et al. [24]
discuss modules as a way of group-
ing classes and relationships. They
do not provide a notation for view-
ing the module level, however.
OOAD Research Strengths and
weaknesses
An overall problem with the cur-
rent O O A D research is that there is
no comprehensive methodology
that integrates and balances differ-
ent views of a system from macro to
micro levels. Most the OO ap-
proaches are simply variations on a
t h e m e - - w h e t h e r the theme is func-
tional decomposition, data model-
ing or dynamic modeling--with
incomplete heuristics for transla-
tion to an object design.
There is nothing wrong with
using or modifying existing ap-
proaches; many of them can fit into
an OO methodology. OO is a new
way of packaging units in a system,
a different way to solve p r o b l e m s - -
but many aspects remain the same.
Developers still have to define and
represent the system's structure
and dynamic behavior (i.e., con-
trol). And they still have to perform
functional decomposition on meth-
ods [11]. There is a need to incor-
porate or modify existing processes
and representations which model
these characteristics (structure,
function and control) into a com-
plete and comprehensive O O A D
methodology.
There are three general ap-
proaches to OOAD, characterized
by the manner and degree to which
they incorporate other paradigms:
1) The combinative approach: Use ob-
ject-oriented, function-oriented,
and/or dynamic-oriented tech-
niques to separately model struc-
ture, functionality and/or dynamic
behavior and provide a method for
integrating the different models.
2) The adaptive approach: Use exist-
ing techniques in a new (object-
oriented) way, or extend existing
techniques to include object-orien-
tation.
3) The "pure" object-oriented ap-
proach: Use new techniques to

model object structure, functional-
ity and dynamic behavior.
The combinative approach mod-
els separate views of a system using
traditional techniques. Rumbaugh
et al. [24] and Shlaer and Mellor
[26] are in this category. They have
processes and representations for
structural, dynamic and functional
modeling. The structural represen-
tations are derived from database
modeling and ERDs in particular,
even though the notation is new.
The dynamic model consists of
state-transition diagrams. The
functional model resembles data-
flow diagrams.
These three models are generally
independent of one another, and
they capture different aspects of
the system. However, these combi-
native approaches deteriorate when
they try to integrate the different
views into an object-oriented de-
sign. The structural model gener-
ally includes objects, attributes, and
relationships, but not behavior
(e.g., [26]). A major problem is
mapping the data-flow processes
from the functional (DFD) model,
and the events and activities from
the dynamic (STD) model into be-
havior of particular objects in the
object model.
Bailin [3], Gorman and
Choobineh [10], Henderson-Sellers
and Constantine [11], and Kappel
[15] provide adaptive approaches.
These authors blend existing pro-
cesses and representations with an
object-oriented perspective. For
example, traditional data-flow dia-
grams and other function-oriented
representations can be used in a
new context--representing an ob-
ject's functionality rather than the
system's functionality [11]. Bailin's
technique uses entity data-flow dia-
grams, which are DFDs whose
functions are associated with spe-
cific objects or entities. Gorman and
Choobineh's object-oriented entity
relationship model extends the en-
tity-relationship and semantic data
models to include behavior model-
ing. Kappel's object/behavior
model, as noted earlier, is an object-
oriented version of state transition
COMMUNICATIONS OF THE ACM/September 1992/Vol.35, No.9
articles
diagrams and predicate transition
nets. Another example is Nierstrasz
et al.'s [21] component-oriented
software development (COSD)
which is object-oriented with a pri-
mary emphasis on reusable frame-
works and components.
The "pure" object-oriented ap-
proach describes work done, for
example, by [4, 5, 29]. These au-
thors approach software design
using an object-oriented perspec-
tive. They focus on modeling the
objects in the problem domain,
their protocols, and their commu-
nication and relationships with
other objects. Each object has re-
sponsibilities, collaborators, and
relationships with other objects in
the system. These techniques do
not require a translation process as
do the combination approaches.
They do, however, need a complex-
ity management mechanism to per-
mit viewing the design at varying
levels of detail (as in data-flow dia-
grams) or from various perspec-
tives (as in the combination ap-
proaches).
The representation for OOAD is
still incomplete and is not standard-
ized. A great deal of research ad-
dresses micro- (i.e., object- ) level
static and dynamic representations;
much less work has been done on
macro-level static and dynamic nota-
tions (particularly macro-level dy-
namic notations).
T u b l e S.
Strengths and Weaknesses of Current OOAD Research
STRENGTHS
• Identifying semantic classes
• Identifying attributes and behavior
• Placing methods (Law of Demeter)
• Identifying and representing
generalization and
aggregation structures
• Representing static views
(structure)
Table 5 lists the key OOAD
strengths and weaknesses identified
and discussed in this article.
Future Research
This section discusses four direc-
tions for future research: 1) defin-
ing and integrating various abstrac-
tion levels and views of a system in
OOAD; 2) developing evaluative
models for the results of OOAD;
3) identifying typologies of objects,
behavior, and relationship to use
during OOAD; and 4) specifying a
typology of OOAD approaches.
Each of these items is discussed
briefly in the following subsections.
Layers a n d V i e w s
There is an effort among OOAD
researchers to model several views
of a system. For example, struc-
tural, functional, and control views
can be modeled. There also is work
on building higher levels of abstrac-
tion than objects, such as Coad and
Yourdon's subjects and Wirfs-
Brock et al.'s subsystems. What is
missing, however, is a clear defini-
tion of what layers and views are
important for representing and
designing a system, and a means of
integrating and balancing them.
As can be seen from section (4) of
Table 4, relatively few of the
OOAD approaches include mecha-
nisms for managing the complexity
of a large design. A solution to this
WEAKNESSES
• Identifying interface, application
and system classes
• Determining when an attribute,
relationship or behavior
should be a class
• Placing classes
• Identifying and representing
other kinds of relationships
• Maintaining consistent and correct
semantics for relationships
• Representing dynamic views
(message passing,
control,...)
• Integrating static and dynamic
models
• Maintaining consistent levels of
abstraction/g ranularlty
4S

problem may be to define various
"abstraction layers" of the system.
The top, or macro, layer(s) should
communicate the system structure,
function and control, and would be
developed during requirements
specification and analysis. T h e bot-
tom, or micro, layer should repre-
sent the objects' structure, func-
tionality, and control and would be
developed during analysis and/or
object design. Any intermediate
layers should provide a smooth
transition from the macro to micro
view. T h e bottom layers will have
much more detail and the top lay-
ers will be much broader in scope.
A model that synthesizes the
static and dynamic features of a sys-
tem at various levels o f abstraction
may be the most important need in
O O A D research. For example'., con-
sider Rumbaugh et al.'s [24] Object
Modeling Technique. It includes an
object diagram, data-flow diagrams
and state-transition diagrams.
These diagrams, taken together,
represent three different, impor-
tant views of the system. However,
they are not well integrated. It is
difficult to recognize how an object,
behavior or attribute in the object
model relates to a data flow or data-
flow process in the functional
model or to an event or state in the
dynamic model. These three dia-
grams also represent different ab-
straction levels--the object model
depicts micro-level structure, and
the dynamic model portrays micro-
level states and transitions, while
the functional model describes
macro-level functionality. Tile dif-
ferent levels of granularity make it
difficult to integrate or synthesize
the separate models.
Evaluative Models for OOAD
Another direction for future re-
search is in developing evaluation
models for OOAD. Presently, the
O O A D models are prescriptive
rather than evaluative in nature.*
*This section refers mostly to designs, since
there is already some work on defining what
constitutes a good design (e.g., [8]). However,
evaluative models are also needed for analy-
sis.
46
ao'e
articles
Prescriptive models specify the
steps or procedures for developing
an analysis or design; evaluative
models measure the quality of an
analysis or design. A number of
authors (e.g., [5, 14, 29])discuss
qualities or characteristics which
are desirable in an OO design. But
many of the characteristics are
vague, difficult to define and diffi-
cult to measure. Designs that are
reusable are considered "good," but
what is "good" and what constitutes
reusability? A design should be
measured along at least two dimen-
sions, the technical and semantic
dimensions. T h e technical dimen-
sion should address software engi-
neering issues such as the amount
of coupling and cohesion among
objects in a design. T h e semantic
dimension should assess whether
the design is a good semantic model
of the problem and solution spaces.
In other words, how closely does
the design reflect the mental model
which the users, analysts and devel-
opers have of the situation?
Typologies of Classes, Behavior,
and Relationships
This article presented a typology of
classes (semantic, interface, applica-
tion, and base/utility). Another ty-
pology has been presented by [13].
Behavior classifications are men-
tioned by [7, 24]; various categories
of relationships (e.g., generalization
and aggregation) are discussed in
the O O A D research. Most of these
typologies, however, are incom-
plete. Research is needed to extend
existing classifications or to develop
new ones, to integrate them, and to
test their completeness and useful-
ness. Existing typologies should be
compared to see what characteris-
tics are redundant. T h e remaining
characteristics could then be
treated as different dimensions on
which to classify classes, and so on.
Typology of 00AD Approaches
This article discussed three ap-
proaches to OOAD: combinative,
adaptive and pure. An area for fu-
ture research is to determine which
of these approaches is "better" and
September 1992/Vol.35, No.9/(:OMMUNICATIONS
in which circumstances. Intuitively,
it seems that the combinative ap-
proach is the least desirable, be-
cause it is more complex than the
others. It tries to combine the struc-
tured and object-oriented para-
digms, but many of the fundamen-
tal concepts of these paradigms are
conflicting. It also seems, however,
that structured techniques and con-
cepts do have a place in object-
oriented systems development.
Structured techniques may best be
applied in the context of designing
the behavior of an object, rather
than the behavior or functionality
of the entire system [11]. Whether
and how different modeling tech-
niques should be blended into
O O A D is a hotly debated question
which has not been adequately an-
swered in the research.
Summary
Object-oriented systems develop-
ment is a popular topic in both aca-
demia and industry these d a y s - - s o
popular, in fact, that it is difficult to
stay abreast o f all the research and
literature being published on ob-
ject-oriented analysis, object-
oriented design and object-oriented
programming. This article has at-
tempted to bring some order to the
collection o f current O O A D re-
search by building a framework for
comparing O O A D research. This
framework includes the critical
components of an O O A D method-
ology, which are based on O O ex-
tensions to Colter's [8] and Press-
man's [23] work. In Table 4, 24
O O A D processes and/or represen-
tations are mapped to this frame-
work. Observations are made with
respect to this comparison, and
strengths and weaknesses in O O A D
research are identified. Possible
directions for future research in
O O A D were mentioned, based on
the review of existing research. []
References
1. Ackroyd, M. and Daum, D. Graphi-
cal notation for object-oriented de-
sign and programming. J. Object-
Oriented Program 3, .5 (Jan. 1991),
18-28.
OF THE ACM

2. Alabiso, B. Transformation of data
flow analysis models to object-
oriented design. In Proceedings of
OOPSLA '88 Conference (San Diego,
Calif., Sept. 1988), 335-353.
3. Bailin, S.C. An object-oriented re-
quirements specification method.
Commun. ACM 32, 5 (May 1989),
608-623.
4. Beck, K. and Cummingham, W. A
laboratory for teaching object-
oriented thinking. In Proceedings of
OOPSLA '89 Conference (New Orle-
ans, La., Sept. 1989), pp. 1-6.
5. Booch, G. Object-OrientedDesign with
Applications. Benjamin/Cummings,
1991.
6. Bulman, D. Refining candidate ob-
jects. Comput. Language (Jan. 1991),
30-39.
7. Coad, P. and Yourdon, E. Object-
Oriented Design. Prentice Hall, En-
glewood Cliffs, N.J., 1991.
8. Colter, M.A. A comparative exami-
nation of systems analysis tech-
niques. MIS Q. (Mar. 1984), 51-66.
9. Cunningham, W. and Beck, K. A
diagram for object-oriented pro-
grams, In Proceedings of OOPSLA "86
Conference. (Portland, Ore., Sept.
1986), pp 39-43.
10. Gorman, K. and Choobineh, J. The
object-oriented entity-relationship
model (OOERM). J. Manage. Inf.
Syst. 7, 3, 41-65.
11. Henderson-Sellers, B. and Con-
stantine, L.L. Object-oriented de-
velopment and functional decom-
position. J. Object-OrientedProg. 33,
9 (1991), 11-17.
12. Henderson-Sellers, B. and Ed-
wards, J.M. The object-oriented
systems life cycle. Commun. ACM 33,
9 (Sept. 1990), 142-169.
13. Iivari, J. Object-oriented informa-
tions systems analysis: A framework
for object identification. IEEE
Trans. (1991), 205-218.
14. Johnson, R.E. and Foote, B. De-
signing reusable classes. J. Object-
Oriented Program. 1, 2 (June/July
1988), 22-35.
15. Kappel, G. Using an object-oriented
diagram technique for the design of
information systems. Dynamic
Modelling of Information Systems.
H,G. Sol and K.M. van Hee Eds.
Elsevier Science Publishers B.V.,
1991, 121 164.
16. Ladden, R.M. A survey of issues to
be considered in the development
of an object-oriented development
methodology in Ada. Ada Letters 9, 2
(Mar./Apr. 1989), 78-88.
C O M M U N I C A T I O N S OF THE ACM/September1992/Vo1.35,No.9
articles
17. Lee, S. and Carver, D.L. Object-
oriented analysis and specification:
A knowledge base approach. J. Ob-
ject-Oriented Program. (Jan. 1991),
35-43.
18. Lieberherr, K., Holland, I., and
Riel, A. Object-oriented program-
ming: An objective sense of style. In
Proceedings of OOPSLA '88 Confer-
ence (San Diego, Calif., Sept. 1988),
pp. 323-334.
19. Meyer, B. Object-Oriented Software
Construction. Prentice Hall, Engle-
wood Cliffs, N.J., 1988.
20. Mrdalj, S. Bibliography of object-
oriented system development. ACM
SIGSOFT Softw. Eng. Not. 15, 5
(1990), 60-63.
21. Nierstrasz, O., Gibbs, S. and
Tsichritzis, D. Component-oriented
software development. Commun.
ACM 35, 9 (Sept. 1992).
22. Page-Jones, M., Constantine, L.L.
and Weiss, S. Modeling object-
oriented systems: The uniform ob-
ject notation. Comput. Language
(Oct. 1990), 70-87.
23. Pressman, R.S. Software Engineering:
A Practitioner'sApproach. Second ed.,
McGraw-Hill, 1987.
24. Rumbaugh, J., Blaha, M., Premer-
lani, W., Eddy, F. and Lorensen, W.
Object-oriented modeling and design.
Prentice Hall, Englewood Cliffs,
N.J., 1991.
25, Scharenberg, M.E. and Dunsmore,
H.E. Evolution of classes and ob-
jects during object-oriented design
and programming.J. Object-Oriented
Program. (Jan. 1991), 30-34.
26. Shlaer, S. and Mellor, S.J. Object-
Oriented SystemsAnalysis: Modeling the
World in Data. Prentice Hall, 1988.
27, Wasserman, A.I., Pircher, P.A. and
Muller, R.J. The object-oriented
structured design notation for soft-
ware design representation. IEEE
Comput. (Mar. 1990), 50-62.
28. Wilson, D. Class diagrams: A tool
for design, documentation, and
teaching. J. Object-OrientedProgram.
(Jan./Feb. 1990), 38-44.
29. Wirfs-Brock, R.J., Wilkerson, B.
and Wiener, L. Designing Object-
Oriented Software. Prentice Hall,
Englewood Cliffs, N.J., 1990.
30. Yourdon, E. and Constantine, L.L.
Structured Design: Fundamentals of a
Discipline of Computer Program and
Systems. Prentice Hall, Englewood
Cliffs, N.J., 1979.
CR Categories and Subject Descrip-
tors: D.2.1 [Software]: Software Engi-
neeriixg--requirements/specifications;
D.2.10 [Software]: Software Engi-
neering-design; 1.6.0 [Computing
Methodologies]: Simulation and Mod-
eling-general; 1.6.3 [Computing Meth-
odologies]: Simulation and Modeling--
applications; K.6.3 [Computing
Milieux]: Management of Computing
and Information Systems--software
management; K.6.4 [Computing
Milieux]: Management of Computing
and Information Systems--system man-
agement
General Terms: Design, Methodology
Additional Key Words and Phrases:
Analysis, Modeling
About the Authors:
DAVID E. MONARCHI is an associate
professor in information systems at the
University of Colorado at Boulder. Cur-
rent research interests include object-
oriented systems, data modeling, and
knowledge representation.
GRETCHEN I. PUHR is a Ph.D stu-
dent in Information Systems at the Uni-
versity of Colorado at Boulder. Current
research interests include object-
oriented analysis and design, and evalu-
ative models (including metrics) for
analysis and design.
Authors' Present Address: University
of Colorado, School of Business and
Administration, Campus Box 419,
Boulder, Colorado, 80309-0419; email:
{monarchi_d, puhr_g}@cubldr.colora
do.edu
Permission to copy without fee all or part of
this material is granted provided that the
copies are not made or distributed for direct
commercial advantage, the ACM copyright
notice and the title of the publication and its
date appear, and notice is given that copying
is by permission of the Association for
Computing Machine W, To copy otherwise, or
to republish, requires a fee and/or specific
permission.
© ACM 0002-0782/92/0900-035$1.50
47