UNDERSTANDING

Downloaded from the ACM Digital Library on April 7, 2025.

OBJECT-ORIENTED: A

UNIFYING PARADIGM

40 September 199O/Vo1.33, No.9ICOMYUWICITIONSOCT”EACM

 The need to develop and maintain replacing the waterfall model of soft- beyond the object-based technique in
large complex software systems in a ware development with a fountain the emphasis given to data by utiliz-
competitive and dynamic environ- model. Development reaches a high ing the relationships between objects
ment has driven interest in new ap- level only to fall back to a previous as a fundamental part of the system
proaches to software design and level to begin the climb once again. architecture.
development. The problems with the As an example of the blurring of The goal in designing individual
classical waterfall model have been the traditional boundaries of the life software components is to represent
cataloged in almost every software cycle phases, Coad and Yourdon a concept in what will eventually be
engineering text [19,23]. In response, recommend that classification rela- an executable form. The Abstract
alternative models such as the spiral tionships between objects be cap- Data Type (ADT) is the object-based
RI, and fountain [9] have been tured and documented during the paradigm’s technique for capturing
proposed. object-oriented analysis (OOA) this conceptual information. The
Problems with traditional devel- phase. This classification will be class is the object-oriented para-
opment using the classical life cycle directly reflected in the class in- digm’s conceptual modeling tool.
include no iteration, no emphasis on heritance structure developed in The design pieces resulting from the
reuse, and no unifying model to in- the design and in the code. This object-oriented design technique
tegrate the phases. The difference in classification is in no way required represent a tighter coupling of data
point of view between following data in order to document the system and functionality than traditional
flows in structured analysis and requirements. In other words, Coad ADTs. These artifacts of the design
building hierarchies of tasks in struc- and Yourdon are recommending a process used in conjunction with a

Downloaded from the ACM Digital Library on April 7, 2025.

tured design has always been a ma- traditional design activity in the modeling-based decomposition ap-
jor problem [4]. Each system is built analysis phase. proach yield a paradigm, a tech-
from scratch and maintenance costs The blurring of the traditional nique, which is very natural and
account for a notoriously large share design and implementation phases flexible. It is natural in the sense that
of total system costs. has been fueled by the development the design pieces are closely iden-
The object-oriented paradigm of encapsulation and abstraction tified with the real-world concepts
addresses each of these issues. mechanisms in object-oriented and which they model. It is flexible in the
A look at the object-oriented soft- object-based languages. For exam- sense of quickly adapting to changes
ware life cycle, as described by Meyer ple, Meyer claims [14] that Eiffel is in the problem specifications.
[5], Coad and Yourdon [4], and both a design and an implementation Object-oriented remains a term
Henderson-Sellers and Edwards [9], language. He goes on to say that soft- which is interpreted differently by
identifies the three traditional ac- ware design is sometimes mistakenly different people. Before presenting
tivities of analysis, design, and im- viewed as an activity totally secluded an overview of a set of techniques for
plementation. However, each of the from actual implementation. From the design process, we will give our
referenced descriptions eliminates his point of view, much is to be perspective so the reader may judge
the distinct boundaries between the gained from an approach that in- the techniques in terms of those deli-
phases. tegrates both activities within the nitions. Briefly, we adapt Wegner’s
The primary reason for this blur- same conceptual framework. [27] definition for object-oriented
ring of boundaries is that the items of The object-oriented design para- languages to object-oriented design.
interest in each phase are the same: digm is the next logical step in a pro- The pieces of the design are objects
objects. Objects and the relationships gression that has led from a purely which are grouped into classes for
between objects are identified in both procedural approach to an object- specification purposes. In addition to
the analysis and design phases. Ob- based approach and now to the traditional dependencies between
jects and relationships identified and object-oriented approach. The pro- data elements, an inheritance rela-
documented in the analysis phase gression has resulted from a gradual tion between classes is used to express
serve not only as input to the design shift in point of view in the develop- specializations and generalizations
phase, but as an initial layer in the ment process. The procedural design of the concepts represented by the
design. This continuity provides for paradigm utilizes functional decom- classes.
a much more seamless interface be- position to specify the tasks to be As natural and flexible as the
tween the phases. Analysts, designers completed in order to solve a prob- object-oriented technique is, it is still
and programmers are working with lem. The object-based approach, possible to produce a bad design
a common set of items upon which typified by the techniques of Your- when using it. We will consider a
to build. don, Jackson and Booth, gives more number of general design criteria
A second reason for the blurring of attention to data specifications than and will discuss how the object-
these boundaries is that the object- the procedural approach but still oriented approach assists the de-
oriented development process is utilizes functional decomposition to signer in meeting these criteria. We
iterative. Henderson-Sellers and develop the architecture of a system. will refer to a number of design
Edwards further refine this idea by The object-oriented approach goes guidelines developed specifically for

CCMYVWIC~~ICII~CFTHEACMlSeptember 199O/Vo1.33, No.9

I I I I I I I I I I

the object-oriented design paradigm with the other four concepts in construct for implementing a user-
and will discuss how these properties specific ways that characterizes defined type. For example, in Figure
reinforce the concepts of good design. object-oriented programming. The 2 the variables main-menu and
The paradigm sprang from lan- paradigm is new enough, however, sub-menu are both type MENU.
guage, has matured into design, and that there is not universal agreement Execution of the statement
has recently moved into analysis. on how to characterize it. Other Main-menu.create dynamically
The blurring of boundaries between definitions can be found in [5, 281. allocates space for the object
these phases has led us to include In the following discussion we “Main-menu.” Subsequent
topics in this article that are outside introduce and illustrate each of the execution of the statement
the realm of design, but which we five concepts using Eiffel syntax and sub-menu. create dynamically cre-
consider important to understanding semantics. ates a second instance of the MENU
the design process. Since the para- Figure 1 shows a’ group of related class.
digm sprang from language, we classes referred to as a subsystem or Ideally, a class is an implementa-
define the concepts basic to object- a class cluster [14]. This cluster im- tion of an ADT. This means that the
oriented programming in the follow- plements all of the types necessary for implementation details of the class
ing section. implementing a simple hierarchical are private to the class. The public in-
menu system. terface of such a class is composed of
Basic Concepts 06 two kinds of class methods. The first
OBJects kind consists of accessor functions
Object-Oriented
ProgrammIng Objects are the basic run-time that return meaningful abstractions

Downloaded from the ACM Digital Library on April 7, 2025.

Five general concepts will be dis- entities in an object-oriented system. about an instance’s state. The other
cussed in this section: objects, classes, Objects take up space in memory kinds of methods are transformation
inheritance, polymorphism, and and have an associated address like a procedures used to move an instance
dynamic binding. The first three record in Pascal or a structure in C. from one valid state to another.
concepts appear in high-level design The arrangement of bits in an Information-hiding guidelines
and analysis. The last two are added object’s allocated memory space dictate that all data within a class
during low-level design and im- determines that object’s state at any be private. This is to guarantee that
plementation. given moment. Associated with every the interface of the class is in fact
Although these concepts are basic to object is a set of procedures and func- an abstraction.
object-oriented programming, the tions that define the meaningful Other languages provide a similar
various object-oriented communities operations on that object. Thus, an construct for creating an ADI’. Ada,
often associate different specifics with object encapsulates both state and for example, has the package. A
each concept. In this section we focus behavior. package differs from a class in
on the basics of the concepts. Later From a design perspective, objects that a package encapsulates the type
sections elaborate on the possible model the entities in the application but is not the type itself. This is an
variations. domain. important difference. It results in a
Of the five concepts, only one classes weaker connection between state and
(inheritance) is a unique contribu- A class defines a set of possible ob- behavior as well as the syntactic
tion of the paradigm. jects. From the point of view of a burden of an additional parameter to
It is the blending of inheritance strongly typed language, a class is a most of the package’s procedures.
Some systems, such as Smalltalk,
have run-time class-objects (meta-
class objects). By this we mean that
for each class in the system there is a
corresponding object that stores in-
formation about the class as a whole
and implements the class-level opera-
tions. Such objects are useful for stor-
ing dynamic information about the
type, such as the number of current
instances of the type, and provide an
elegant way to implement operations
such as class constructors and des-
tructors, or maintain global informa-
tion specific to the class.

lnherltance
FIGURE a. Groulpof Related ClassesReferredto as a Subsystemor ClassCluster. Inheritance is a relation between

42 September 199o/vo1.33, No.9/COYY”wcATlo”s OFTWE.CY

I I I I I I I I I I I I I I I 1111111a1- OBJECT-OBIENTED DEBXDM

classes that allows for the definition

and implementation of one class to
be based on that of other existing --This is the ROOT class
classes. Instance-based inheritance --The main-menu is created and execution of main-menu is triggered
has also been studied and imple- -,.The main-menu executes until the stop is set
mented [21], but we will limit this
discussion to traditional class-based Class MENU-DRIVER export
inheritance. set-stop
Inheritance is the most promising feature
concept we have to help us realize the
goal of constructing software systems main-menu :MENU;
from reusable parts, rather than sub-menu MENU;
hand coding every system from stop BOOLE4N;
scratch. Procedural abstraction has Create is
worked well for some select domains, do
such as mathematical libraries, but main-menu.Create(“Main Menu”,“This is the root of menu tree”,‘hn’);
the unit of abstraction is too small, sub-menu.Create(“Print”,“Menu for printing various Reports”,‘P’);
the procedural focus not general main-menu.attach(sub_menu);
enough, and the parameter mech- from
anism too rigid. stop:= False

Downloaded from the ACM Digital Library on April 7, 2025.

until
Another construct that has been
stop
touted as holding a key to reusabil-
iooP
ity is the concept of parametrized main-menu.execute
types or generics as applied to pro- end;
cedures, and Ada packages. The end;
ability to create libraries of generic set-stop is
procedures and packages is a very do
useful one that has not been exploited stop := True;
nearly enough and will prove to be end:
a central concept in the future of
software development. It, however, is end -- Class MENU-DRIVER
-------_--__----__--____________________--------------------
only applicable to strongly typed sys-
class MENU export
tems and is not as general a concept
execute, parent-menu, attach
as inheritance. inherit
Inheritance not only supports MENU-ITEM
reuse across systems, but it directly feature
facilitates extensibility within a given menu-list : ARRAY(MENUJTEM];
system. This theme will be elabor- -- List of polymorphic menu items; note that this feature is not exported
ated upon throughout the article. We
will show that inheritance minimizes Create (item-name-in, help-line-in: STRING; trigger-in: CHARACTER)
the amount of new code needed --parameters required because every menu can also be a menu item.
when adding additional features, attach (item-in: MENU-ITEM)
and that inheritance coupled with --attach item to end of the list of current menu items(‘menu-list’).
polymorphism and dynamic binding --also set the parent of item-in to current menu.
require
minimizes the amount of existing
not item-in.Void
code that must be changed when execute
extending a system. --Display the menu.
To understand exactly what in- --Allow the user to select an item by using Trigger char or by
heritance is and how it provides the --pressing return when the selected item is highlighted.
claimed benefits we introduce some --Branch to execute procedure of selected item.
basic terminology, elaborate on the --Continue in loop until user presses Esc, &C, or the execute
inheritance relation, and then il- --code of a menuJtem caiis set-quit or set-quit-ail.
lustrate it with a simple example. end interface -- class MENU
When class Y inherits from class X
(see Figure 3), we will refer to class
Y as a derived class and class X as a
base class. In this case, class Y has
two parts, a derived nart and an FIGURE 2. A Menu EXiiWjlle.

COYNUNICATIONS OPT”8 ACM/September 199O/Vol.33, No.9 43

 I I I I I I I I

- X (base
ciass)
incremental part. The derived part
is the part inherited from X. The
incremental part is the new code,
written specifically for Y.
The mapping from the members
of X to the derived members of Y is
kinds of mappings require additional
information. For example, if a given
member of X is to be reimplemented
as it is mapped to Y, the code for
reimplementation must be given.
The inheritance relation is often
defined by the rules of the language called the “is a” relation. This is
in conjunction with code written because when a class Y inherits from
by the programmer in class Y. The class X, class Y now has, by in-

0
mapping may be a simple identity in heritance, all the features of X. Thus
which the derived part of Y is Y is an X. Y is undoubtedly more
exactly the same as the members of than an X, but in addition to what-
X. This inheritance mapping may ever else it may be it is also an X.
however, be much richer than a Because of this, the inheritance
simple identity. relation is often used to reflect
In general, a feature of X may be abstraction and structure present
renamed, reimplemented, dupli- in an application domain. A com-
cated, voided, have its visibility monly used example domain is from
changed, or undergo almost any graphics. A rectangle is a special kind
other kind of transformation as it is of polygon (see Figure 4). This rela-

Downloaded from the ACM Digital Library on April 7, 2025.

mapped from X to Y. As with any tionship is easily captured by the
(inheritl3d from X) language feature, inheritance can be inheritance relation. When rectangle
misused. What constitutes the proper inherits from polygon, rectangle gets
use of inheritance is a widely debated all the features of a polygon. In ad-
topic. We favor a very disciplined use dition, a polygon is a closed figure
of inheritance. and so rectangle also inherits all
Each object-oriented language has the features of a closed figure.
its own set of allowable inheritance Yourdon advises capturing this
mappings. At the language level, classification structure explicitly dur-
keywords are provided to indicate the ing the analysis phase. If a software
FIGURE 3. Inhleritance. kind of mapping desired. Certain system is developed using object-
oriented analysis, object-oriented
design, and implemented in an
object-oriented programming lang-
uage, then objects and classifications
identified during analysis are
preserved and enriched during
design, and are directly implemented
in code. We believe this ability to
capture and encapsulate abstraction
directly in code represents a major
breakthrough in software technology.
At the highest level, all figures in a
graphics system have a pixel width
and color and the property of being
able to be scaled, rotated or drawn.
These properties are defined in the
root class “Figure.” Closed figures
have, in addition, a perimeter and
Eiffel syntax Pascal syntax
an area. Polygon adds the attribute
current-figures;: ARRAY[FIGURE] “number-of-sides.” Thus, a rectan-
current-figures.create( 1 ,n) CurrentJigures: array[l ..nJ of figure
gle has, by inheritance, a pixel width,
current-figuredtem(3) currentJigures[3]
scaling procedure, calculate-area
function, etc. Some of these features
currentJigures.put(2,cl) current_figures[2] := cl can be inherited as is, others should
be modified as they are inherited.
The set-pixel-width as defined in
FIGURE 4. AnEMIIPleInheritanceGraph. the figure class may be appropriate

44 September 1990,“0,.33, No.9ICOYMUNICATIONS OFTHE ACM

I I I I I I I I I I I I I I I I1llluEI- OBJECT.OBIENTED DESIGN

for rectangles “as is” but the calcu- is tightly coupled with the idea of this concept. In a graphics system we
late-area procedure should be polymorphism in a strongly typed may want the ability to perform some
redefined to give a more efficient object-oriented language. The idea is action (such as scale or rotate) on all
implementation. that if Y inherits from X, Y is an X, currently displayed figures. It would
In an object-oriented graphics and therefore anywhere that an in- facilitate this operation if a list of all
system, inheritance minimizes the stance of X is expected, an instance displayed figures were available.
incremental effort of adding a new of Y is allowed. Referring to the inheritance
graphics primitive. In the same man- Figure 5 provides an outline for diagram of Figure 4, one can see that
ner, the object-oriented approach discussion. After execution of state- the variable “current-figures:
with inheritance facilitates rapid ment 1, the static type of x is X and ARRAY [Figure]” provides just
prototyping. the dynamic type of x is X. After what is needed. Since Figure is an
The real appeal and power of the statement 4, the static type ofx is still ancestor of Circle, the Eiffel type
inheritance mechanism is that it X but its dynamic type is now Y. system knows that Circle is a Figure
allows the programmer to reuse a A more realistic example will help and allows the assignment: cur-
class that is almost, but not exactly, to clarify the use and importance of rent-figures.put(Cl:,l); {where Cl
what he wants, and to tailor the class
in a way that does not introduce
unwanted side effects into the rest of
the class. Furthermore, the object
paradigm focuses on identifying and

Downloaded from the ACM Digital Library on April 7, 2025.

encapsulating commonality in
higher level abstractions. If these
higher level classes are accumulated
in a software repository it would
eventually be quite likely that for Class X expert
almost any desired class, a general- do-it
ization of that class would already feature
exist in the software repository. do-it is
do
io.output.print-str(“do-it in class X”);
There are many kinds of polymor- end;
phism [3], but in general polymor- end -- Class X
___-_--_____-______------------------------------------------------------------------------
phism means the ability to take more Class Y export
than one form. In an object-oriented do-it
language, a polymorphic reference is inherit
one that can, over time, refer to in- X redefine do-it
stances of more than one class. Be- feature
cause of this ability to refer to more do-it is
than one class of object, a polymor- do
phic reference has both a dynamic io.output.print-str(“do-it in class Y”);
and a static type associated with it. end;
The dynamic type of a polymor- end -- Class Y
_----_---_------________________________---------------------------------------------------
phic reference may change from in- Class DRIVER
stant to instant during the program feature
execution. In strongly typed object- Create is
oriented environments, the run-time
Local
system keeps all polymorphic x:x; y:Y;
references automatically tagged with do
their dynamic type. x.Create; -- Statement 1
The static type is determined from y.Create; -- Statement 2
the declaration of the entity in the x.do-it; -- Statement 3
program text. It is known at compile x .- Yi -- Statement 4
time and determines the set of valid
x.do-it -- Statement 5
types that the object can accept at
end;
runtime. This determination is made
end --Class DRIVER
___-_--______----_______________________---------------------------------------------------
from an analysis of the inheritance
graphs in the system.
The “is a” nature of inheritance FIGURE 5. An Exampleof Polymorphismand DynamicBinding.

CCYLI”WIC~TICIISCFTWEICMIS~~~~~~~~ 199O/Vo1.33, No.9 4s

I I I I I I I I I I

is an object of type Circle}. After this binding. To redraw the entire analysis process serves as input into
assignment the static type of graphics window the following code the design phase but it is in a different
current-.&ures.item(l) would still would suffice: terminology and represents a dif-
be figure, but its dynamic type would Fori: = 1 to Number-of- ferent perspective from the design
be “circle.” Likewise, the elements Shapes phase. For this reason, the traditional
2...n of the array could be Squares, do view of an application life cycle in-
Lines, or any other graphics current&ures.item(i).draw; cludes what may be an unnecessary
primitive. At each pass through the loop, the boundary between analysis and
code matching the dynamic type of design. This boundary results from
currentfigure.item(i) will be called. a shift from the problem domain in
The binding referred to in this sec- Note that if additional kinds of analysis to the solution domain in
tion is the binding of a procedure call shapes are added to the system, this design.
to the code to be executed in response code segment remains unchanged. The object-oriented design
to the call. Dynamic binding means Contrast the resulting simplicity and paradigm takes a modeling point of
the code associat.ed with a given pro- extensibility as compared with a view. The analysis and design phases
cedure call is not known until the traditional case statement design. of the traditional life cycle, while re-
moment of the call at runtime. maining distinctly separate activities
In the object-oriented world, Bask Design Coneepes in the object-oriented life cycle, work
dynamic binding is associated This section presents the fundamen- together closely to develop a model of
with polymorphisrn and inheritance tals of the object-oriented design the problem domain. The model is

Downloaded from the ACM Digital Library on April 7, 2025.

in that a procedure call associated phase of the object-oriented software constructed by viewing the problem
with a polymorphic reference may life cycle. For a reference point domain as a set of interacting en-
depend on the dynamic type of object-oriented design is compared to tities. The software-based models of
that reference. the procedural design paradigm (top- entities and the relationships between
Suppose x is a polymorphic refer- down functional decomposition). them are assembled to form the basic
ence whose static type is X, but The designs produced using the architecture of the application. The
whose dynamic type may be X or Y. object-oriented paradigm are mea- information developed in the analysis
Suppose further that the procedure sured against a set of qualities of well- phase becomes an integral part of the
“do-it” is an operation defined in X designed software. design rather than simply providing
but redefined in Y as a part of the input into the phase. This smooth
inheritance mapping. The call A DIHerenc Rolnl 06 Wew transition is facilitated by the homo-
x.do-it now depends on the dy- Most computer professionals know geneity of the “pieces” being used by
namic type of x. If its dynamic type the syntax of several programming each process. As discussed in Coad
is X, as in statement 3 of Figure 5, languages. Most know several dia- and Yourdon [4] this homogeneity is
the call will be bound to the code de- gramming techniques for represent- in stark contrast to the difference in
fined in class X. If its dynamic type ing design details. Yet most know point of view between Structured
is Y, as in statement 5 of Figure 5, the only one approach to system design. Analysis and Structured Design.
call will be bound to the code as It is perhaps harder to learn a new The pieces produced by the pro-
redefined in class Y. system development technique than cedural design paradigm are pro-
The graphics example, continued it is to learn a new language. This is cedures that perform tasks. These
below, will illust:rate the usefulness of because learning a language involves pieces are artifacts of the design pro-
this concept. In the next section we memorizing a few keywords and cess and relate to the proposed solu-
elaborate on the benefits of this con- their valid arrangements while learn- tion. The pieces produced by the
cept relative to extensibility. ing a new system development tech- object-oriented paradigm are entity
Suppose the class “Figure” in nique requires a fundamental change descriptions, classes. Many of these
Figure 4 contains the procedure in our way of thinking. descriptions can ,be related back
“draw” (with -perhaps a null im- A design paradigm is character- directly to the original problem.
plementation). 13~inheritance, every ized by its view of the decomposition Although many of the classes do not
graphics primitive in Figure 4 will process. The procedural paradigm represent physical objects, they are
have a procedure draw. The draw takes a task-oriented point of view, conceptual entities which can be
algorithm is, however, unique to each which begins its support for the stated in the terminology of the
graphical shape, and so the draw pro- design process when a solution to the problem domain.
cedure will be redefined in each class target problem is proposed. The pro-
that defines a graphics primitive. posed solution is decomposed by An ExammIe For Comparison
Returning to the polymorphic breaking it into a sequence of tasks. Consider an example that will illus-
array of the previous section, one These tasks form the basic building trate the different points of view of
can now see the usefulness of poly- blocks for a procedural application. the procedural and object-oriented
morphism combined with dynamic Information developed as part of the paradigms. Figure 6 presents an ab-

06 September 19901Vo1.33. No.9ICOYYUNICITIOWSOFTHE.CY

I I I I I I I I I I I I I I I 111111111~ OBIECT-ONIENTEDDESIGN

breviated statement of requirements pieces of the problem. information than other data models
for a software system which would To the former because the design such as the relational model.
control the traffic lights at the in- will retain and build directly upon Peckham and Maryanski [18] pro-
tersection of two streets. The applica- the objects identified during analysis, vide a survey of several semantic data
tion would have software interfaces and this facilitates communication models. Other techniques have been
to the hardware pieces like the car between users and designers since proposed for capturing this informa-
sensors and the traffic lights. users are better able to relate to the tion (e.g., Wirfs-Brock [28]).
The procedural paradigm ap- problem than to the computer-based A comparison of the information
proaches the development of the solution to that problem. in Figures 7 and 8 illustrates the dif-
traffic intersection control system by The entities identified above and ference in points of view of the two
considering the sequence of tasks that several others are illustrated in paradigms. Neither technique con-
must be performed. A functional Figure 8. This figure uses an entity- centrates on one type of abstraction
decomposition of the proposed solu- relationship diagram to present the to the exclusion of all others. The
tion provides a set of tasks such as entities and the relationships between procedural paradigm, while giving
those in Figure 7. This hierarchy them. The diagram is the represen- priority to procedural abstraction,
chart illustrates the process of step- tation of a semantic data model of must consider the structures nec-
wise refinement. Each layer in the the problem. A semantic data model essary for data representation at
hierarchy represents the identifica- is so named because it allows some level in the design process.
tion of more detailed functionality. representation of a broader range of Likewise, the object-oriented para-
The tasks are sequenced by reading

Downloaded from the ACM Digital Library on April 7, 2025.

from left to right across the chart.
The object-oriented paradigm
approaches systems development by The requirement is for a software system that will manipulate the hardware for
traffic control located at an intersection. The hardware includes a set of
identifying the entities that are pres- sensors, the traffic lights, and the control box. The software reads the state
ent in the problem. The physical en- of the sensors, determines the new state for the intersection, and signals the
tities involved in this problem include lights to change. In addition, the system is to have other capabilities such as
the sensors, traffic lights, and the a test option which cycles the lights through the set of configurations. The
system can also be set to a default state which might be flashing yellow in one
controller. The paradigm is not direction and red in the other. The sensor indicates the presence (or
limited to physical entities. For this absence) of a vehide in a particular lane. There are several kinds of sensor.
problem, one non-physical entity each of which works differently internally. All the sensors however are
that can be identified is a “lane” en- interrupt-driven and a bit is set whenever the sensor is tripped. After the
decision to change the state of the intersection, every sensor is reset. This
tity. This entity associates a sensor particular intersection uses two kinds of trafffc lights. One is the usual thraa-
with a particular traffic light. The color light which is used for the g-straight lanes. The other light is a four-
lane entity bridges between the prob- position light: red, yellow, green, and turn arrow. Each light has a current
lem domain and the solution do- state, a set of valid next states, and a default state. The controller physically
contains the switches for the lights, the data stores for the sensors, and a
main. It is named and discussed in clock for timing the state of the poll/decision cycle. The controller software
the terminology of the problem, but reads the clock, polls the sensors, determines the next state, and sends the
may arise either through viewing the signals to change the lights.
problem or the implementation of
the controller which must have
information about which light is FIGURE 6. Requirement for a Traffic Intersection Control.
associated with which sensor.
Abstractions of these entities will
become the classes that form the
foundation of the system. The
specifications for these classes will
supplement the information from the
traditional requirements document.
The object-oriented requirements
document uses objects and classifica-
tion to blend traditional analysis
information about the required
systems functionality with descrip-
tions of the objects it manipulates.
The systems specifications are useful
to both the designers and users,
To the latter because the descrip-
tions are not pieces of a solution but FIGURIS 7. Hierarchy Chart for Traffic Intersection Problem.

CCMYUWIC~TICII~CPTllEliCMISeptember 199O/Vo1.33, No.9

I I I I I I I I I I I

digm may use functional decomposi- of the commonality of the object together by the incident of a flight.
tion in designing the operators model. In one phase the analyst iden- The flight is also an entity which has
needed to manipulate an object. tifies problem domain objects while a state that describes the particular
The object model supports the in the next phase, the designer airplane and the particular pilot as
complete software d,evelopment life specifies additional objects necessary well as passengers, cargo, etc.
cycle. Beginning in the requirements for a specific computer-based solu-
phase, objects are identified. By tion. The design process is repeated Relatlonshlps
developing specifications of the en- for these implementation-level ob- The relationships between entities
tities found in the problem domain a jects. The position of object-oriented are the interactions that occur be-
clear and well-organi:zed statement of design in the software development tween objects in the problem space.
the problem is actually built into the process is further detailed in the A pilot flies an airplane. Flies is one
application. These objects form a paper by Henderson-Sellers [9] ap- relationship between pilot and plane.
high-level layer of definitions that are pearing in this special issue. This relationship is an application-
written in the terminology of the level relationship and is expressed in
problem domain. During the reline- Enf Ities the terminology of the problem. Two
ment of the definitions and the im- Object-oriented design is first con- entities may have more than one rela-
plementation of the application cerned with entities-things. These tionship between them. The pilot
entities, other entities, or classes, are things may be tangible objects such is-in-command-of the airplane.
identified. Figure 9 illustrates the as traffic lights, chairs, or airplanes. An entity may have relationships
layers of object specifications that The entities may be abstract concepts with several other entities. The pilot

Downloaded from the ACM Digital Library on April 7, 2025.

result from this process. such as roles, interactions, or in- is-employed-by the airplane.
The object-oriented analysis and cidents. For example, an airplane An important design relationship
the object-oriented design phases and a pilot are tangible objects but in the object-oriented paradigm is the
work more closely together because these two entities may be bound inheritance relation. In order to

0 is_part-of

eeeuRE 8. Entity-Relationship Diagram for Traffic Intersection Problem.

48 September 199OiVol.33, No 9/COMYUWICATIONS OF TRE ACCM

I I I I I I I I I I I I I I I 111111111~ OUECT-ONINNTND DESION

describe a class of pilots, the designer

might wish to begin with the des-
cription of class person. Using the
inheritance mechanism, all the
behavior and attributes of a person
would be added to the pilot class
definition. Linking two classes via the Problem Domain
inheritance relationship means that Objects Defined
future improvements to the person
class will become improvements to
the pilot class automatically
A second design relationship in the
object-oriented paradigm is the
component relation. The description
of person probably includes a name
attribute. This attribute can be pro-
vided by declaring an instance of
the string class in the definition of
person. This instance of string is a

Downloaded from the ACM Digital Library on April 7, 2025.

component of the person class
definition.
The distinction between these two
relationships is an important one. In-
heritance represents a specialization
of the existing definition. That is, a
pilot is a special kind of person, one
who flies planes, but is still a person.
A component is used to provide a
service in the implementation of a FIGURE 9. Layersof Obiect Specifications Resulting from RefinementProcess.
class. A person is not a special kind
of string. The instance of string is
used to represent an attribute of
person, not to define what a person
is. The characteristics of a person
become part of the characteristics of (a) data: array[l ..somenumber] of itemtype;
a pilot when added by inheritance, top: integer;
while the characteristics of a string
are hidden in the implementation of push
a person. POP
W isiempty
Complete Data Model is-full
Object-oriented design has two sep- make-empty
arate components which must be create
blended in the development of an
application: class design and applica-
tion design. Class design is “wrapped
inside” of application design. The
design of an application includes the
identification of the kinds of entities
in the problem domain plus those
specific to implementing the solution
such as menu systems or pointing
devices. Each kind of entity leads to
a class description which should be a
complete model of one concept.
Once these descriptions have been
developed, the application can be
designed. The application is devel- FIGURE 10. Three Parts of a Stack.

CQUM”lllCITlClsCFT”EACDIlSeptcmber 199O/Vol.33, No 9
I I I I I I I I I I I

oped by connectiag instances of the several ways but they all involve configuration. Much of the process
classes-modeling the real world so messages. A message is a communi- is guided by the real-world problem
that they interact with each other cation between t.wo objects. The domain rather than our view of the
resulting in a problem solution. messaging may be either syn- problem solution. This results in an
The class descriptions include chronous or asynchronous depend- application design that, at a high
three parts: definitions of attributes, ing upon the execution model level, contains a model of the prob-
description of the c:lass interface, and chosen. An object may send a lem domain. The application design
the set of valid transitions between message to any other object whose process begins at a top level and
the possible states for an instance of identity is available. The message proceeds through class identification
the class. Consider the design of a can correspond to any operator in to a low level and then moves upward
stack class. Figure 10 shows the three the public interface of the receiv- as low-level classes are designed
parts of the class design. Part (a) of ing object. The receiving object may based on lower-level definitions.
the figure shows that the data at- be an object at the same design level
tributes for the stack class include a or it may be one that is declared as Support #or Dood Des&n
data store for the items contained in part of the implementation of the Modularity. The object-oriented
the stack and some means oflocating sending object. paradigm provides natural support
the top, or visible, item in the stack. Semantic data modeling provides for decomposing a system into
Part (b) gives the public interface of support for developing a complete modules. In this paradigm classes
the class. Part (c) uses a state diagram data model of an application which are the modules. This means that not
to illustrate the sequence of valid incorporates both high-level applica- only does the design process support

Downloaded from the ACM Digital Library on April 7, 2025.

states for the class. This diagram not tion relationships and low-level class modularity, but the implementation
only provides information about the definition relationships. Figure 11 process supports it as well through
states of the class, it provides con- provides an entity-relationship the class definition. Figure 12
straints on the sequence of use of the diagram that illustrates the pieces illustrates a class definition for the
operators from the class interface. of the pilot/plane application used pilot class.
The pattern of interaction between above. All the entities and the rela- Classes as modules represent a
instances of the classes provides the tionships between them can be cap- line-grained approach to system
structure of the a.pplication. These tured in this one model. composition. Others have proposed
interactions are models of the rela- Thus, the development of an a more coarse-grained approach.
tionships between the classes. These object-oriented application is a blend Meyer [15] defines a cluster as a set
relationships are :modeled in one of of class description and application of classes that are conceptually

class person

public interface:
print-name();
tell-age();

private interface:
name: string;
date-of-birth: date;

?t$+Gcgl end person;

class pilot has parent person

is-a
-- public interface:
which-airline();
FAA-license-expirationo;

private interface:
airline: string;
FAAJzense: IicenseJype;

8 person
7 - FIGURE
end pilot;

II. Class Specifications for

FBGURE 1 I. Entlt~RelatlOnShip DiaRraIiI fOf PilOffPlane Application. the Pilot Class.

50 September 19901Vol.33, No.9/COYYUNIWTIONSOFTIlEMY

I I I I I I I I I I I I I I I 111111111- ONINCTONXNNTND DE8IQN

related. This cluster of classes is a Weak Coupling. Classes are de- another class. This coupling assumes
natural grouping to consider because signed as collections of data and the the instance parameter will either
an application, which includes a class set of allowable operations on that provide information for the opera-
representation of a concept, will data. Therefore, the interface oper- tion of that function or the instance
usually need to include instances of ators of a class are inward-looking in will be modified by having one of its
a set of classes in order to fully imple- the sense that they are intended to ac- interface functions invoked.
ment the concept. Wirfs-Brock [29] cess or modify the internal data of the Strong Cohesion. A class is a natu-
defines a subsystem grouping and class. This leads to fewer connections rally cohesive module because it is a
the work of Johnson, reported in between classes. model of some entity. Object-
the Wirfs-Brock article describes Interactions between classes come oriented style guidelines require that
frameworks as other approaches to from two sources. The component for a function to be a member of a
grouping classes. These groupings relationship discussed previously class it must either access or modify
collect classes which as a group form results in a coupling between the two data defined within the class.
an abstraction. For example, the classes. If an instance of class A is The inheritance mechanism could
concept of a linked list might be declared within the implementation be viewed as weakening the cohesion
represented by three classes: a class of class B, then instances of class B of the module. The data and func-
that is the list itself; a class that contain an instance of class A in their tions inherited from another class
describes the links; and a class that implementation. Operators of class B form a natural group separate from
defines iterators for the list. In- send messages to (invoke the inter- those data values and functions
dividually the classes are not very face operators of) the instance of class defined within the new class.

Downloaded from the ACM Digital Library on April 7, 2025.

useful but together they provide A. In Figure 12, the name attribute However, the ultimate test of cohe-
the designer with a commonly used is an instance of the string class. Per- sion is met by the fact that all these
abstraction. son’s print-name operator would pieces are brought together to repre-
Information Hiding. The class con- carry out its task by sending a mes- sent one concept.
struct supports information hiding sage to the name instance to print. Abstraction. Liskov and Guttag [12]
through the separation of the class in- Interface functions of a class may present two methods of abstraction:
terface and the class implementation. take as parameters instances of abstraction by specification and
The separation allows the class inter-
face (i.e., specification) to be mapped
to several different implementations.
It also allows much maintenance Class STACK[TJ export
activity to be hidden from users of
the class. Wpushpop
This separation is in parallel to the feature
design activity of separating the implementation : ARRAY(Tl
behavior of an object from the attri- nb-elements : INTEGER;
butes of the object. The operators in
the public interface represent the Create(n: INTEGER) is
do
possible behaviors of the object. One
implementation.Create(l, n);
of the responsibilities of these
end;
operators is to provide for the con-
top: T is
trolled access to the attributes of the do
object. The representation of these Result :P irnplementation.item(nb~elements);
attributes and the corresponding im- end;
plementation of the operators should push(x : T) is
be hidden from users of the class. do
Figure 12 illustrates a usual divi- nb-elements := nb-elements + 1;
sion between public interface and implementation.put(nb-elements, x);
private implementation. The inter- end;
face operator tell-age hides the fact
that the operator uses the person’s POPis
date-of-birth and the system date do
as the basis for answering the re- nb-elements := nb-elements - 1;
end;
quest. In this case, the object’s at-
tribute age has been mapped to a end -- Class STACK[Tj
representation using date-of-birth
and associated operators to calculate
current age. FIGURE II. A Parameterized Class Definition in Eiffel Syntarr.

CCMYUY~CAT~CWS CFT”E ACM/September 199O/Vol.33, No.9 51

I I I I I I 8 I I I

abstraction by parameterization. oriented languages also supports ex- operator was designed. Thus a new
Object-oriented langwages support tensible designs. Figure 14 shows a feature is added with little or no
both of these meth,ods to varying simple inheritance hierarchy. Con- modification to the remainder of the
degrees. sider the operator x, shown in Figure application.
Abstraction by specification Integrable. The object-oriented de-

[
abstracts the specification of an entity sign process produces designs which
from its implementation. This type facilitate the integration of individual
of abstraction is supported by vir- pieces into complete designs. The
A
tually every object..oriented lang- narrow clearly defined interface of

csib
uage. The public interface of a class a class supports integration with other
constitutes the specification of that software components. The set of
class. The interface specifies the allowable operations and their
legitimate operators of the data con- B C D required parameters are easy to iden-
tained in instances of the class. In t* The narrow interface corresponds
most object-oriented languages, the naturally to the observable behaviors
implementation of these operators of the real-world entity modeled by
and the exact representation of the E F the class. The interfacing of two
class’s data elements are hidden from bb classes then is a model of the natural
access if not from the view of those interactions of the two entities.
outside the class definition. Objects are also very integrable at

Downloaded from the ACM Digital Library on April 7, 2025.

elmmE 14. Simple Inheritance
Abstraction by parameterization Hierarchy. the implementation level. The en-
abstracts the type of data to be capsulation provided by a class hides
manipulated from the specification of the implementation details from the
how it is to be manipulated. This formal function definition remainder of the system. The hiding
type of abstraction is supported by x(P1: A); of data declarations, function-
most object-orienmd languages at the actual usage naming conventions, and complex
operator level but by only a few instance declarations control flows prevents interactions.
languages at the class level. Eiffel, for pb: B; Thus, integration of prewritten com-
example, allows a class definition to ;;;; ponents is much less likely to require
be parameter&d. Consider the modification of existing code in
pe: E;
definition of a stack class. The class pf: F;
either component.
can be totally specified without function invocations
regard to the type of the items to be x(Pbh
“stacked.” The type ofthe items can x(pc); The object-oriented paradigm com-
be identified at compile time through x(fW; All valid under a bines design techniques and lang-
the use of a parameter. Figure 13 x(w); polymorphic uage features to provide strong
shows a parameterized class defini- x(p9; typing system. support for reuse of software
tion in Eiffel syntax. This type of modules. The reuse comes in a vari-
abstraction is only of interest in a ety of forms. Some of the reuse in
FIGURE ‘IE. POlyIblOrphit the object-oriented paradigm is
typed-language environment.
Substitution.
Extensibility. The object-oriented much the same as that in the pro-
paradigm produces designs that are cedural paradigm but the object-
easily extended. The inheritance 15, that takes an instance of class A oriented paradigm adds an addi-
mechanism supports extending as a parameter. The polymorphic tional type of reuse.
designs in two ways. First, the in- behavior of object-oriented typing Every time an instance of a class is
heritance relation. facilitates the reuse systems allows the substitution of in- created, reuse occurs. This is similar
of existing definitions to ease the stances of classes B, C, D, E, or F as to the declaration of a variable of a
development of new definitions. As the actual argument to operator x. specific type. The major difference is
the inheritance structure becomes This polymorphic property sup- that the resulting class instance is a
progressively deeper, the amount of ports the extension of existing much more complex structure than
specification and implementation in- systems in the following way Assume a simple variable. An instance of a
herited by a new class definition further analysis reveals another class provides a combination of data
grows. This usually means that as the specialization, G, would provide the structures and operators on those
inheritance structure grows, the new feature needed by the current data structures. Declaring the in-
.
amount of effort to develop a new apphcatton. Instances of this new stance of the string class to represent
class decreases. class can be used as actual arguments the name attribute in the pilot class
Second, the polymorphic property to operator x even though the class G is an example of this type of reuse.
of the typing system in object- had not been thought of before the x Using an instance of the string class

52 September 199O/Vo1.33, No.9/COYMUNICATIONS 01 T”EACY

I I I I I I I I I I I I I I I I llllllnl- OBJECWOBlElcTED DEilIDl

provides operators for copying, con- the new class. This technique is tools that facilitate the location and
catenating, and, perhaps, even nonintrusive in that the existing code use of specific classes. The article by
editing the string value. is not modified. The new code in the Gibbs et al [6] in this issue discusses
Inheritance provides two levels of subclass can not cause the existing the problem of class management.
support for reuse. As part of the high- code to “break.” The inherited code
level design phase, inheritance serves is included in the new definition Peslgn Gulclellnes
as a means of modeling generaliza- automatically as the new class defini- In any object-oriented application,
tion/specialization relationships. tion is compiled. Any modifications instances of classes make up the ma-
These relationships appear in the to the original class, bug fixes or jority of the system and, if a pure
form of classifications. A chair may feature additions, are incorporated object-oriented approach is used, all
be viewed as a special type of fur- into the newer class at the next com- of the system consists of instances of
niture as well as a general description pilation. This technique allows a class classes. Therefore the design of the
of the more specific categories of to serve as the basis for many new individual classes has a major impact
rocking chairs, straight chairs, and definitions without propagating the on the overall quality of the applica-
reclining chairs. This high-level use errors of the original definitions tion. In this section a set of guidelines
of inheritance encourages the devel- throughout the system. is presented for the design of classes.
opment of meaningful abstractions Much research focuses on support The intent is to illustrate the factors
which, in turn, encourages reuse. for reuse. Several of the research ef- which should be considered when
Often in actual design the forts presented in Wirfs-Brock [29] designing a class without discussing
presence of mid-level abstractions include consideration of reuse. Reen- each guideline in detail. Figure 16

Downloaded from the ACM Digital Library on April 7, 2025.

such as table and chair will be recog- skaug’s work with Role Models and presents the list of guidelines which
nized and considered separately The Johnson’s work with Frameworks ad- are briefly discussed below.
availability of an inheritance relation dress the need for conceptual group- The first four guidelines address
enables the designer to “push ings of classes. As libraries of classes the proper form and use of the class
higher” and to identify commonali- grow very large, locating the classes interface. The information hiding
ty among abstractions and to pro- that are needed to represent a given required by the first guideline rein-
duce higher-level abstractions, (e.g., concept becomes a difficult task. forces the development of represent-
furniture), from this commonality. These conceptual models associate ation-independent designs. This
By identifying this commonality and classes forming larger more readily encapsulation is further specified in
removing it to a higher abstraction, recognized groupings. Lieberherr’s the second guideline which prohibits
it becomes available to be reused later work on the Law of Demeter ap- accessing class instances used as part
in the current design or in future proaches reuse from the point of view of the representation of this class.
designs. Filing cabinets and of the interactions between classes. These guidelines enforce the idea
bookcases may be identified later. The Law addresses the allowable that a class is characterized by its set
Much of their description (attributes dependencies between classes. For of operations and not by its represen-
such as height, weight, color, etc.), example, it explicitly eliminates the tation. The third guideline defines
may already be available from the direct access by one object of another the public interface as containing the
furniture abstraction, The benefits of object’s implementation. This complete set of public operations on
this reuse prompt the designer to reduces the number of dependencies the representation of the class.
search for higher and higher levels of between classes, increasing the “Helper” functions are deferred to
abstraction. design’s flexibility. the protected area in a class delini-
In the low-level design phase, in- tion. The fourth guideline requires
heritance supports the reuse of an ex- SoWware Base that to belong to the class, each
isting class as the basis for the The set of classes together with the operator must represent a behavior
. .
definition of a new class. An existing applmation and implementation of the concept being modeled by the
piece of code can be copied to a new relationships between them form a class. Together these four guidelines
file and modified to lit its new pur- reusable resource for the designer give the designer directions for de-
pose. This “editor inheritance” does which has been referred to as a soft- veloping and separating the class in-
not establish any connection between ware base. This software base further terface and the class representation.
the old piece of code and the new promotes reuse by overcoming one of The second four guidelines con-
code. If a bug is discovered in the old the real-world obstacles to reuse: sider the relationship of this class to
code and repaired, knowledge of this finding the appropriate class. other classes. Guideline number five
change may or may not reach the Large companies have com- constrains the designer to link a class
person responsible for the new code. munications problems. How, in a with as few other classes as possible.
Inheritance provides an important company of 5,000 designers, can in- If a class being designed will need
improvement in this process. formation about existing resources many of the services of another class,
Inheritance establishes a depend- be shared? The following section on perhaps that functionality should be
ency between the existing class and development environments discusses part of the representation of the new

COWYUWlCATlOYSOF THSAOYISeptember 199O/Vo1.33, No.9 53

I I I I I I I I I I I

class. The sixth guideline is intended the object-oriented paradigm relies subset. Generalization supports the
to reduce, and perhaps eliminate, much more heavily on the use of sup- exploitation of commonalities be-
global information. Any information porting tools and environments tween classes. When two or more
needed by one class should be ex- compared to procedural design tech- classes are representing overlapping
plicitly passed to it in a parameter niques. This section presents in- sets of attributes, the common attri-
from another class. Guideline formation about some existing butes may be factored out of both
number seven prohibits the use of in- support systems and considers how classes and used to create a new class.
heritance to develop the representa- these systems may look in the future. The new class then becomes the
tion of a new class rather than its Many of the features of support superclass for those previously over-
interface. The preferred method for systems discussed here are not lapping classes. The inheritance
utilizing an instance of a class as part limited to the object-oriented do- mechanism of an object-oriented lan-
of the representation of another class main, but characteristics of object- guage implements both of these tools.
is to declare an instance of the sup- oriented design make particularly Specialization does not require
porting class in the representation of good use of the support provided by any modification of existing defini-
the newly designed class. Finally, the such an environment. tions. The new definition simply in-
last guideline encourages the cludes a reference to the existing one.
designer to develop inheritance Conceptual mo1s Generalization usually does require
structures of classes which are We have already described a number modification of existing definitions.
specializations of an abstraction. of conceptual tools for object- The definitions and declarations that
These abstractions lead to more oriented design. We will summarize are common among the classes are

Downloaded from the ACM Digital Library on April 7, 2025.

reusable subclasses and to clear-cut them briefly and include others that removed to a new higher-level defini-
differences between the subclasses. have not been explicitly discussed tion. The inheritance mechanism
Articles by Johnson and Foot [lo] and previously in this article. then makes these pieces in the new
Lieberherr and Holland [ll] expand Generalization/Specialization. high-level definition available to the
on each of these guidelines. These closely related concepts pro- definitions at the lower levels.
vide much of the power of the object- Components. One class may be used
So-ware DesSgn oriented paradigm. Specialization as part of the representation of an-
and Development guides the designer in the reuse of an other class. This type of reuse of de-
Environments existing abstraction by defining a sign simply looks for a class that
The object-oriented design process new class that is more specific than already represents some subset of the
produces a large number of software the existing class. The specification of attributes of the new class. An in-
components that are interconnected the new class includes the specifica- stance of this class can then be used
by a network of relationships. Use of tion of the existing class as a proper to provide that representation. In-
stances of several classes may provide
much of the representation of a new
class, making its realization a rela-
1. The only members of the public interface of a class should be the
tively quick process.
operators of l:he class. Contracts. This is a device defined in
2. An instance of class A should not send a message directly to a Wirfs-Brock [29] and Meyer [14] to
component of class B. describe the division of responsibility
between two classes that interact.
3. An operator should be public if and only if it is to be available to users of The contract specifies what capabil-
instances of the class. ities one class will provide and what
4. Each operator that belongs to a class either accesses or modifies some of the other class can expect to receive
the date of the class. when requesting one of the capabil-
ities. The client/server model is a type
5. A class should be dependent on as few other classes as possible. of contract that has been used to
group capabilities even in the pro-
6. The interaction between two classes should be explicit. cedural paradigm.
7. Each subclass should be developed as a specialization of the superclass Clusters/Subsystems/Frameworks.
with the public interface of the superclass becoming a part of the public Each of these concepts is a technique
interface of tie subclass. for recognizing sets of classes that are
conceptually related. It is often
8. The root clas:s of an inheritance structure should be an abstract model of logical to divide the representation of
the target concept. a concept among several classes.
Some of these subconcepts may be of
use in the development of other con-
FIGURE 16. ClilssDeShJn Culdelines. cepts. In the above example of the
I I I I I n I I I I I n I n I I nnnnnnnn~ ONlNCT-ONlNNTND DNUON

linked list, by separating the list Users accessing a class in order to use models mentioned previously. An
iterator into a separate class, we are it as the basis for a new class delini- E-R Diagram provides a very flexi-
able to have multiple iterators on the tion may need more information ble framework in that it can capture
same list at the same time. than those users simply creating any relationship that exists between
No syntactic unit exists that in- instances from the definition. In classes. Excelerator provides an in-
dicates this relationship. This is the particular, some languages give tegrated data dictionary which allows
most important place to apply a tool operators written in the subclass much information about the classes
for support. The designer should be access to some or all of the data or and the relationships to be stored,
able to designate clusters in the soft- protected operators declared in the managed, and manipulated. A num-
ware base. If a user calls up the linked superclasses. ber of other existing computer-as-
list class, the environment should be The person creating the subclass sisted software engineering (CASE)
able to inform the user that these may need to see the data declarations tools support the development of the
other class are probably of interest as well as the interface for the E-R diagrams.
as well. class(es) being accessed. Some of this Most of these tools do not
These conceptual tools are very “data” are actually instances of other “understand” the object-oriented
useful in the design process. They classes declared as part of the paradigm. That is, they do not treat
provide guidelines for the design and representation of the current class. the application-specific relationships.
direction for the designer. Most ex- This implies that the user may need such as is-employed-by, any differ-
isting development environments re- access to definitions for these classes ently than the paradigm-specific re-

Downloaded from the ACM Digital Library on April 7, 2025.

quire that the designer be responsible to fully understand how a class lationships such as inheritance. It is
for respecting the guidelines functions. the designer’s responsiblity to dif-
presented by these conceptual tools. Access for maintaining the class. ferentiate between the relations.
A set of software tools that supports Users accessing a class, in order to re- While a tool dedicated to the para-
the use of these conceptual tools is pair or extend it, need the maximum digm can provide more intelligent
needed. The work of Lieberherr amount of information. Information support and “critique” the design as
reported in Wirfs-Brock [29] is one is needed on all of the following: the it progresses, a more general tool can
effort to develop tools that include a interface, the representation, and the support multiparadigm integration
policy for design. implementation. The environment of systems.
should allow for wide-ranging brows- Interactive Development Environ-
Levels 06 Access ing that lets the user select an opera- ments, Inc. has developed and
The reuse of software components is tor to be edited, a data declaration to markets a product which supports a
a strong feature of the object-oriented be examined, or a relationship to be variant of the object-oriented
paradigm. This reuse will only take followed. The environment should paradigm. Their design technique,
place if there are good tools which provide integrated editing and as reported in [26], is termed Object-
adapt to the various ways that classes much static checking as possible. Oriented Structured Design
are used. These tools will provide the (OOSD). OOSD incorporates the
designer with access to the class Exlstlng Too& features of object-oriented design
definitions, implementations, and Tools for design. A number of de- with the functional approach of
structures of the software base. For sign tools are available which facili- Structured Design. It is beyond the
our purposes, three levels of access to tate some part of the object-oriented scope of this article to present a
a class definition can be identified: design process. These tools can be detailed critique of this methodology
Access for generating instances. divided into two categories: those but the automated design tool, Soft-
Users often reuse an existing class by that provide high-level design tools ware Through Pictures, developed to
creating instances of the class for an and those that assist with low-level support their work is one example of
application they are designing. Ac- design. No commercial tool that we a useful design tool.
cessing a class for this purpose re- are aware of supports both the devel- Software Through Pictures pro-
quires that the designer have access opment of a high-level design and vides a range of CASE tools. A series
to the public interface of the class. takes that design to the lower levels of editors provides the designer with
However, it should be the completein- of development. The work of Reen- the popular graphical notations: E-R
terface. That is, the attributes that skaug reported in the research survey diagrams, Data Flow diagrams, and
are inherited from superclasses up of this special issue [29] is an attempt a data structures editor which sup-
the inheritance structure should be to develop a methodology for the ports Jackson hierarchical data
presented as part of the complete in- complete life cycle. structures. The environment also
terface. A design environment Tools such as Excelerator from supports automatic documentation
should be capable of combining in- Index Technology support the devel- and data dictionary facilities. All
formation from multiple class speci- opment of Entity-Relationship Dia- facilities are integrated and informa-
fications to present to the class user. grams. The Entity-Relationship tion entered in one tool is accessible
Access for creating new subclasses. Model is one of the semantic data in others.

~OYY”~~CIT~ONBOFT”EICMIS~~~~~~~~ 199ONo1.33, No.9 55

I I I I I I I I I I I

The designs developed in Software the relationships that exist between ImDlementing an object-
Through Pictures can be “brought to entities in the problem space. These Orlented Design
life” using the automatic code relationships represent the interac- The software community has long
generation facilities. Unfortunately, tions between complex entities and as realized that iteration is inherent in
the product does not support genera- a result are infinite in variety This re- the software life cycle. Since the soft-
tion in any object-oriented language. quires the flexible approach of the ware development team will be con-
It does provide code generation in entity-relationship semantic data stantly moving back and forth across
Ada, C, and Pascal. The code is not model that allows user-defined rela- the different phases, the joints be-
managed or manipulated by the en- tions rather than a limited number of tween what we have traditionally
vironment. Because the system does “standard” relations. The result at called analysis, design and imple-
not provide low-level design support, this level is a complex structure of mentation should be seamless.
the designer has very little control dependencies. Many environments Therefore it is important to have
over the code that is generated. allow the designer to draw this object-oriented languages and
class/application structure in the development environments that
form of E-R diagrams or some other directly support the object-oriented
Tools for implementation. A num-
notation and retain only the at- design paradigm and that make a
ber of languages are accompanied by
tributes of the picture rather than the smooth transition between design
toolkits which support the low-level
interconnections. This is insufficient. and implementation.
design and implementation process.
The tool should provide a represen- The object-oriented design para-
Smalltalk provides an integrated en-
tation for this structure which can be digm exists independently from any

Downloaded from the ACM Digital Library on April 7, 2025.

vironment which combines a class
the basis for active manipulation. specific implementation environ-
browser, editor, and compiler. The
Baldassari et al. [l] present a CASE ment, and yet there are implementa-
class browser treats each class
tool which uses a variant of Petri nets tion issues that affect the design as
discretely and does not present the
to provide this capability. PROTOB well as the development process. This
complete interface of a class. The
is directed at distributed systems but section explores some of these im-
browser does provide a structured list
provides a hint of what a general- plementation issues. In addition, the
which shows the class inheritance sidebars by Jordan and Kilian pro-
purpose tool should include.
structure. While n.avigating the class vide case studies on the implementa-
The concept of a software base [24,
inheritance structure, a class may be
251 of reusable components will re- tion decisions taken by two major
selected, viewed, and modified in the
quire the support of a comprehensive object-oriented languages: C++
integrated editor. When the designer and Trellis.
set of tools. These tools should pro-
completes the editing process, a pop-
vide the user with a software base As a parenthetical remark we note
up menu in the editor window allows
navigator that can follow any of the that in some environments one may
the new code to be immediately
relation links developed between wish to do an object-oriented design,
checked, compiled, and linked into
classes. Such a tool must be very but implement in a non-object-
the system. Development of a similar
general because the relationships oriented language. High-level design
system for C + + (minus the com-
present in an object-oriented design should be language independent but
piler), has been mported in [20].
span from application-oriented rela- it is not paradigm independent. A
tionships to standard relationships truly object-oriented design can be
TOOIS OF the FUtUPe such as inheritance. directly implemented only in an
The two design environments The toolkit should include low- object-oriented language. What can
described above are passive graphics level tools which operate on both the be done in this situation is to
editors in the sense that they record classes and the relationships between transform the object-oriented design
what the designer enters and display them. This includes the “hierarchy into an object-based design (remove
the information when needed. The flatteners” described above as well as inheritance) and then implement in
language toolkit discussed in the in-line editors and syntax checkers. a traditional language. We view this
same section is more active but does All of these tools should be incor- transformation as part of the design
not include capabilities for high-level porated into the overall environment. process, but others view it as an im-
design functions. The useful tools of The existing tools for object- plementation technique.
the future will integrate high- and oriented design are inadequate. A Newer languages like Ada or
low-level design processes. The tools number of simple tools assist in Modula 2 have language constructs
will provide intelligent support for recording design decisions but these that directly support the encapsula-
the design paradigms being used and tools do not facilitate the design deci- tion of an ADT. In other languages
will be an active “assistant” to the sions themselves. Although the like C or COBOL the implementa-
designer. object-oriented paradigm simplifies tion of an object-based design re-
At a high level, in the object- the solution of complex problems, a quires programmer adherence to a
oriented paradigm, this means sup- comprehensive set of tools will set of coding standards that are
port for recognizmg and recording greatly assist the designer. unenforceable by the compiler.

56
I I I I I Ill1 I I I I I 1111111111~ ONIECT-ONINNTND DES181

S~ec//Ic Issues quires that a function be declared as hierarchy.

As stated in the introduction to this “virtual” in order for it to be a can- Suppose that class Y inherits from
section of this article, there are many didate for dynamic binding. This class X. if the language treats Y as a
facets to the object world. Some tech- limitation may have some efficiency sub-type of X, then compiler will
niques and concepts such as delega- benefits, but makes for less- allow an instance of Y wherever an
tion are often considered under the modifiable software components by instance of X is expected. This allows
object-oriented umbrella, but this restricting which operations on a for an entry in the polymorphic ar-
section considers only the variations type can be modified in a sub-type. ray of menu-items in Figure 2 to
within traditional class-based in- Polymorphism. Even in a strongly refer to any of the specialized menu
heritance systems. typed object-oriented language, the items (including a menu).
typing system is more flexible than in Not all languages treat every user-
Typing. Programming languages
a language like Ada or Pascal. As ex- defined inheritance relation as defin-
are commonly classified according to
plained in section 2, entitled “Basic ing a sub-type. This imposes con-
the extent of type checking provided
Concepts of Object-Oriented Pro- straints on the use of polymorphism.
at compile time. Object-oriented
gramming,” the user-delined in- These variations and their impact on
languages vary widely on this axis.
heritance hierarchy can be taken by polymorphism are further explored
On the one extreme Smalltalk is
the compiler to define a sub-typing in the next sub-section.
essentially a typeless language,
whereas Eiffel is a very strongly
typed language.

Downloaded from the ACM Digital Library on April 7, 2025.

In object-oriented languages, type Class STACKm export
checking is applied at the level of an top.P~Nw
object. Objects not only have data, inherit
but associated operations. Type ARFtAY[T(
rename Create as array-init
checking in the object world must
therefore be associated not only with k?ature
nb-elements : INTEGER;
the interpretation of data, but with
determining which opertions may be Create(n:INTEGER) is
do
applied to an object. array-init(1 , n);
In a strongly typed object-oriented end;

system, the only messages that are top: T is

allowed to be passed to an object are do
Result :- item(nb-elements);
those that can, from a syntactic end:
analysis of the source code, be
push(x : T) is
guaranteed to be resolvable at do
runtime. nb-elements := nb-elements +l:
put(nb-elemenk. x);
This is not true of Smalltalk. The end;
absence of a type system means that POP is
any message may be attempted with do
nb-elements :- nb-elemenk -1;
any object. If, at runtime, a message end;
is applied to an object that does not
end -- Class STACKm
know how to respond, then a run-
time error occurs.
Class EXAMPLE
The weakly typed, interpreted en-
vironments exemplified by the Com- feature
bad-stack : ARRAY/INTEGER];
mon Lisp Object System (CLOS) good-stack : STACKIINTEGER);
and Smalltalk have traditionally been
Create is
associated with rapid prototyping do
[17] whereas the strongly typed, com- g0oc~sta&Create(100);
bad-stack.Create(l , 100);
piled languages such as Eiffel and good-stackpush(5):
C + + are usually chosen for produc- good.stack.push( 15);
good-stackpush(25);
tion environments. bad-stack :- good-stach;
invalid-access := bad-staMitem(2); -- bad_stack[2]
Dynamic binding. In the previous --return the element at second position in the array thus violating the stack protocol
end;
section, the relationship between a
language’s typing system and end -- Class EXAMPLE

dynamic binding were considered.

Some typed languages, however, im-
pose further constraints. C + + re- FecuRE I7. Inheritance for Implementation.

COYY”II,CAT,OW~OFT”EACYIS~~~~~~~~ t99O/Vol.33, No.9 57

 Inheritance. Issues here include heritance is a form of coupling be- in Figure 17.
single versus multiple inheritance, tween classes. Normally modules in Objects. Object-oriented languages
single versus multbple inheritance a software system should be loosely differ in the kind of run-time objects
graph(s), inform.a;ion hiding in coupled. Should inheritance be an that they manipulate, and in how
inheritance, and sub-typing versus exception to this rule? Should inher- these objects are created and
implementation. itance represent tight coupling, or destroyed.
Multiple Inheritance: Many object- loose coupling? Is information hiding Objects as Instances of Classes: Class
oriented languages allow for a class to incompatible with inheritance? instances are the basic objects in an
have more than one direct parent. In Eiffel, inheritance represents object-oriented system. All object-
This facility is espe:cially useful when tight coupling with no information oriented languages allow for dynamic
a class belongs to more than one hiding. Other languages, such as object creation. Dynamically created
classification scheme.. Suppose that a C + + , allow for information hiding objects are referenced through a
system was being developed for the within inheritance, and for variable pointer (either explicitly or implic-
National Wildlife Federation, and a levels of coupling between a base and itly) and have the associated prob-
“Leopard” class was being defined. derived class. This issue has been lems of aliasing, etc. This means that
The designers may already have class widely discussed in the literature object-oriented systems must deal
definitions for “cat” and “endan- [14, 221. with the issue of the management of
gered.” Since a leopard is both a cat Sub-qping versusImplementation: In- objects in memory.
and an endangered species, it would heritance can be used for either sub- Some languages allow objects to be
be natural to inherit from both typing or implementation. All of the created statically or dynamically. In

Downloaded from the ACM Digital Library on April 7, 2025.

classes. Eiffel has ;a.lways had multi- examples used thus far have demon- C + + , this results in having a sepa-
ple inheritance, but only the most re- strated the use of inheritance for sub- rate syntax for pointers to objects.
cent versions of C+ + have added typing: A leopard is a sub-type of a Although statically created objects
this ability. Some languages such as cat. A toggle-item is a sub-type of a may save one level of indirection,
Turbo Pascal V5.5 still only allow for menu-item. Inheritance for sub- many systems, such as MODSIM II,
single inheritance.. typing corresponds to the ‘<is a” do not even allow for them, and in
Number of Inheritance Graphs: Some nature of inheritance described most of those that do they cannot be
languages define a single root class earlier. associated with polymorphism and
from which all other classes automat- Figure 17 shows inheritance for dynamic binding.
ically inherit. This language-defined implementation. A stack is not an ar- For dynamically created objects,
root class thus binds all user-defined ray, but an array can be used for the the language system automatically
classes together into a single inheri- implementation of a stack. Some handles allocation and deallocation
tance graph structure and is used to authors [8, 131 discourage the use of of memory for the object. Initializa-
provide a set of services common to this type of inheritance because it in- tion of the object’s data, and memory
a.ll classes in the system. One such troduces complex implementation management within an object are
service, provided in Eiffel’s root class dependencies into the software sys- treated differently from one system to
adds the ability for each object to tem. Furthermore, this practice, in another.
make a deep (recursive) clone of the presence of polymorphism and C + + has class constructors which
itself. dynamic binding, leads to a design in deal with an object’s data initializa-
In a strongly typed language, the which information hiding can be tion and initial dynamic allocation of
dynamic type of an object reference violated. any memory within an object. Class
is constrained by the programmer- Notice, in Figure 17, that by the constructors are implicitly called
defined class inheritance hierarchies use of polymorphism the stack pro- whenever a class variable declaration
in that system. In a language where tocol can be subverted. C + + avoids is encountered. When an object
every class automa.tically inherits this kind of problem by allowing a passes out of scope or is explicitly
from a single root class there is no base class to be declared as “private” deleted, the class destructor is auto-
constraint on the dynamic type of a in the inheritance clause. This signi- matically called and must deallocate
reference whose static type is the root fies to the compiler that inheritance any dynamically allocated memory
class. for implementation is intended. The internal to the object. Eiffel has no
The presence of an automatic par- compiler then disallows any corre- class destructors, because it has auto-
ent to every class provides a simple, sponding backward polymorphic matic garbage collection. Eiffel con-
elegant solution tco some otherwise assignments. structors must be explicitly called to
messy problems. It allows a language Figure 13 shows an alternate im- create and initialize an object.
to remain small and conceptually plementation of an array-based Other “Objects’? In addition to class
clean, yet at the same time extensible. stack. In C + + in-line functions can instances, an object-oriented lan-
Smalltalk has a single root class, be used to avoid the extra procedure guage may allow other types of run-
C + + does not. calls and thus achieve the same effi- time entities. In the second section of
Information Hiding in Inheritance: In- ciency that was sought by inheritance this article we introduced the idea of

58 September 1990/Vo1.33,No.9ICOYYUNICLlIONSOFTREliCY
I I I I I I I

a class-object. This object is not a database system. digm are not realized on such
class instance, but more like an acces- In Smalltalk and CLOS the entire projects, managers will become dis-
sible class descriptor. Another way of current execution state can be saved illusioned with the “object-oriented”
looking at it is that each class has a to disk. Yet, individual objects cannot approach.
corresponding meta-class that be saved to an external file through Proponents of hybrid languages
describes the class. A class-object is the facilities of the basic language. see them as a natural migration path
an instance of this meta-class. Uses Other languages provide object i/o into the paradigm. Programmers
for such a class-object were given in to disk in the same way that Pascal skilled in the base language can im-
that section. and COBOL provide record i/o. An mediately use the object-oriented
In Smalltalk all run-time entities environment can add this function- version and gradually learn the new
are objects. Even integers are in- ality without altering the language features and paradigm. Proponents
stances of the integer class. Other definition or adding keywords by also claim that not all problems are
languages allow some primitives such adding an object storage manage- best solved by a single tool, thus the
as an integer to be implemented in ment class to the class library. An ob- availability of multiple paradigms is
the traditional way. This saves mem- ject needing persistence would then desirable.
ory space and execution overhead as inherit from the “storable” class.
every integer does not have to have a This is the approach taken by Eiffel. Hlstory Lessons
pointer to its class descriptor, etc. The OOPS class library [7] uses a There is much that has been learned
Other systems treat integers concep- single root class to provide basic per- about software develoment that is or-
tually as objects, but handle them sistence capabilities and guarantee thogonal to the object-oriented para-

Downloaded from the ACM Digital Library on April 7, 2025.

differently at the compiler level for uniform i/o semantics. digm but that nevertheless ought to
efficiency reasons. Keyed access to persistent object be included in any modern program-
may also be provided in a language. ming language and environment.
Encapsulation Pure versus hybrid. Trellis, Eiffel All object-oriented languages pro-
Most object-oriented languages pro- and Smalltalk are pure object- vide classes and objects, but some of
vide direct support for some form of oriented languages. They are pure in them do not provide any construct
information hiding within a class. that they not only support the para- for information hiding within an ob-
Figure 13 shows the use of the export digm, they enforce it. ject. Turbo Pascal 5.5 is particularly
clause to support information hiding. One way in which some languages bad in this aspect.
In Eiffel, every feature of a class is enforce the use of the object-oriented Eiffel provides a generic facility.
automatically private, and thus un- paradigm is by requiring that all This is such an important construct
available outside of the class, unless functions, procedures and variables for supporting reuse that every
it is specifically included in the class’s be declared internal to some class. In strongly typed language ought to
export clause. C + + addresses infor- such a system there are no global support it. Unfortunately, few do.
mation hiding with the language variables, and no free-standing func- Some of the compilers are very fast,
constructs of private, public, pro- tions or procedures. All state is en- others are very slow. Some, like
tected, and friend. capsulated in an object, and all code Smalltalk have large libraries and are
Full support for encapsulation re- is executed relative to some specific integrated into a sophisticated devel-
quires that the programmer have object. The main program becomes opment and testing environment.
complete control over what features the constructor in the class that de- Others provide only a bare-bones
of a class are a part of the public in- fines a specific application. compiler.
terface. In some versions of Small- C + +, Object-Pascal, CLOS are The field is so new, however, that
talk, encapsulation is limited in that hybrid languages. They are object- it should not be judged too harshly.
all methods are automatically public oriented extensions to base languages Commercially, C + + is only 3 years
and all data private. that were designed to support a dif- old, Smalltalk- and Objective C
Encapsulation is such an impor- ferent paradigm. As such, C + + is a only 6 years old. Admittedly, Simula
tant part of the object-oriented multi-paradigm language whereas has existed for more than 20 years,
paradigm that, according to some Smalltalk is a single paradigm but mostly in a research setting.
definitions, a language is not object- language.
oriented unless it provides for “Purists” claim that the hybrid Conclusiion
encapsulation. languages are a detriment to the The purpose of this article has been
Persistence: Some object-oriented paradigm in that groups using a to introduce terminology, concepts,
languages, such as C + + and Turbo hybrid language may claim to be do- and basic techniques surrounding
Pascal V5.5, have no direct way to ing object-oriented programming the object-oriented paradigm. The
store an object. Users of these lan- when, in fact, they may be doing 90 emphasis on data in system design
guages must either manage their own percent of their design in the para- has increased greatly over the past
object i/o (a nontrivial task) or pur- digm of the base language. When the several years and has led to a number
chase a commercial object-oriented benefits of the object-oriented para- of data-driven techniques. By con-

59
 sidering a definition that includes ob- Zompi, R. PROTOB, a hierarchical ob- 21. Sciore, E. Object specialization. ACM
jects, classes, and class inheritance, ject-oriented CASE tool for distributed i%n.r. I$ @St.,7, 2 (April 1989), 103-122.
systems. In ESEC ‘89, Zd European Software
we have tried to focus on a set of con- 22. Snyder, A. Encapsulation and inheritance
Engineering Confemce Lecture Notes in Com-
cepts that we view as a paradigm in object-oriented programming lan-
puter ScienceRO.387, Springer-Verlag, 1989.
separate from the object-based para- 2. Boehm, B. A spiral model of software
guages. In Proceedings of OOPSLA (1986),
digm being supported by the Ada development and enhancement. Computq
pp. 38-45.
and Modula-2 communities. 23. Sommerville, I. Software Engineering.
(May 1988), 61-72.
The design philosophy of the Addison-Wesley, 1989.
3. Cardelli, L. and Wegner, P. On under-
24. Tsichritzis, D., Ed. Active Object Enoiron-
object-oriented paradigm takes a standing types, data abstraction, and
me&. Centre Universitaire D’Informa-
modeling point of view. This allows polymorphism. Comput. Sure. 17, 4 ACM,
tique, Geneve Switzerland, 1987.
the designer to work with one ap- N.Y. 471-522.
25. Tsichritzis, D., Ed. Object OrientedDevelop-
proach which begins in the problem 4. &ad, P. and Yourdon, E. Object-oriented
ment. Centre Universitaire D’Informa-
Analysis. Yourdon Press, 1990.
domain and transitions naturally tique, Geneve Switzerland, 1989.
5. Cox, B. Object-oriented Pmgramming: An
into the solution dornain. By build- 26. Wasserman, A.I., Pircher, P.A., Muller,
Evolutionary Apprwch. Addison-Wesley,
ing a model of the problem into the New York, 1986.
R.J. Concepts of object-oriented struc-
application system, the resulting de- 6. Gibbs, S., Tsichritzis, D., Casais, E.,
tured design. In Proceedings of TOOLS ‘89
sign is more responsive to changes in (1989), pp. 269-280.
Nierstrasz, O., Pintado, X. Class man-
knowledge about the problem situa- 27. Wegner, P. Dimensions of object-based
agement for software communities. Com-
language design. In Proceedings of the Con-
tion. The modularity of these designs mun. ACM 33, 9 (Sept. 1990).
ference on Object-OrientedSystems, Languages,
and information-hiding capabilities 7. Gorlen, K. An object-oriented class li-

Downloaded from the ACM Digital Library on April 7, 2025.

andApplications (1987).
of most object-oriented languages brary for C + + programs. S&u. Exp. and
28. Wirfs-Brock, R., Wilkerson, B., and
contribute to the technique’s respon- Prac. 17, 12, 899-922.
Wiener, L. Designing Object-Oriented Soft-
8. Halbert, Using types and inheritance in
siveness to modificat.ions. ware. Prentice-Hall, 1990.
object-oriented programming, IEEE
A number of languages support 29. Wirfs-Brock, R. and Johnson, R. Survey-
Softw. (Sept. 1987), 71-79.
the object-orientetd paradigm, and 9. Henderson-Sellers, B. and Edwards,.J.M.
ing current research in object-oriented
the variability in language features design. Commun. ACM 33, 9 (Sept. 1990).
The object-oriented systems life cycle.
affects the design process. Although Commun. ACM 33, 9 (Sept. 1990). CR Categories and Subject Descriptors:
most object-oriented languages now 10. Johnson, R.E. and Foot, B. Designing D.2.10 [Software Engineering]: Design;
support multiple inheritance, the in- reusable c1asses.J Object-oriented Program. D.2.1 [Software Engineering]: Require-
heritance mechanism varies greatly (June-July 1988), 22-35. ments/Specifications; D.3.3 [Programming
from one language to another. A 11. Lieberherr, K.J. and Holland, I.M. Languages]: Language Constructs
Assuring good style for object-oriented General Terms: Design
number of languages are available in
programming. IEEE Softw. (Sept. 1989), Additional Key Words and Phrases:
a variety of development environ-
38-48. Object-oriented design, object-oriented
ments which facilitate the systems programming
12. Liskov, B., and Guttag, J. Abstraction and
development process. We have Specijication in Pmgram Deoelopment. MIT
detailed a number of language dif- Press, 1986. About the Authors:
ferences, but we believe that ul- 13. McGregor, J.D. Object-oriented Software TIM KORSON is an assistant professor of
timately it is the richness of this Design and Development. Van Nostrand computer science at Clemson University in
development environment and sup- Reinhold. To be published. Clemson, South Carolina. He has worked at
porting software bsase that will have 14. Meyer, B. Object-OTientedSoftwareConrtruc- the Software Engineering Institute as a
the largest impact on productivity. tion. Prentice-Hall, 1988. Visiting Scientist and serves as a consultant
15. Meyer, B. The new culture of software to AT&T. His current research interests in-
The articles in the remainder of
development: Reflections on the practice clude developing metrics and accounting
this special issue will provide a de-
of object-oriented design. In Proceedings of systems for the management of information
tailed view of many topics that we
the First International Conference on the Tech- assets with emphasis on managing a corporate
have merely introduced. The Proceed- nology of object-Oriented Languages and Sys- transition to object-oriented technology.
ings of ACM’s Confknce on Object- term (1989), pp. 13-23. JOHN D. MCGREGOR is an associate
OrientedSystems, Languages, andAppli- 16.Meyer,B.LessonsfromthedesignoftheEif- professor of computer science at Clemson
cations (OOPSLA) i.s a rich source of fel libraries. Commun. ACM(Sept. 1990). University. He has worked at Lawrence Liver-
material as well. rj 17. Mullin, Object-oriented Program Design with more National Laboratory and is a consultant
Examples in C + +. Addison Wesley, 1989. for AT&T Bell Laboratories. He is an ACM
Acknowledgments. 18. Peckham, J. and Maryanski, F. Seman- Lecturer and recently has been program chair
tic data models. ACM Cornput. Suru. v. 20, ofACM’s Computer Science Conference and
The authors would like to acknowl-
n. 3, 1988, 153-189. general chair of the National Educational
edge the assistance of Jagadish 19. Pressman, R.S. Software Engineering. Computing Conference.
Turimella for his, assistance with McGraw-Hill, 1987.
some of the figures used in thearticle. 20. Raghavan, R., Ramakrishnan, N., and Authors’ Present Address: Department of
Computer Science, Clemson University,
Strater, S. AC + + class browser. In Pro-
ceedings of the C+ + Workshop, USENIX Clemson, SC 29634.
References
1. Baldassari, M., Bruno, G., Russi, V. and Association (19871.
\ ,,.. DD. 274-281. 0 1990ACMOOOl-0782/90/0900-0040S1.50

60 Septcmber1990/Vo1.33,No.9/COYYUNlC*TIOWSOFT"EliCY