ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 1

A Brief History of the Object-Oriented Approach

Luiz Fernando Capretz
University of Western Ontario
Department of Electrical & Computer Engineering
London, ON, CANADA, N6G 1H1
[email protected]

ABSTRACT: quite naturally into the concepts of the object-oriented para-

Unlike other fads, the object-oriented paradigm is here to stay. The digm.
road towards an object-oriented approach is described and several • Reusability: reusing software components already available
object-oriented programming languages are reviewed. Since the facilitates rapid software development and promotes the pro-
object-oriented paradigm promised to revolutionize software de- duction of additional components that may themselves be re-
velopment, in the 1990s, demand for object-oriented software sys- used in future software developments. Taking components
tems increased dramatically; consequently, several methodologies created by others is better than creating new ones. If a good
have been proposed to support software development based on that library of reusable components exists, browsing components
paradigm. Also presented are a survey and a classification scheme to identify opportunities for reuse should take precedence over
for object-oriented methodologies. writing new ones from scratch. Inheritance is an object-
oriented mechanism that boosts software reusability.

1. INTRODUCTION The rapid development of this paradigm during the past ten years
has important reasons, among which are: better modeling of real-
Over the past three decades, several software development meth-
world applications as well as the possibility of software reuse dur-
odologies have appeared. Such methodologies address some or all
ing the development of a software system. The idea of reusability
phases of the software life cycle ranging from requirements to
within an object-oriented approach is attractive because it is not
maintenance. These methodologies have often been developed in
just a matter of reusing the code of a subroutine, but it also en-
response to new ideas about how to cope with the inherent com-
compasses the reuse of any commonality expressed in class hierar-
plexity of software systems. Due to the increasing popularity of
chies. The inheritance mechanism encourages reusability within an
object-oriented programming, in the last twenty years, research on
object-oriented approach (rather than reinvention!) by permitting a
object-oriented methodologies has become a growing field of in-
class to be used in a modified form when a sub-class is derived
terest.
from it [1, 2, 3, 4].
There has also been an explosive growth in the number of software
systems described as object-oriented. Object-orientation has al-
2. THE BACKGROUND OF THE OBJECT-ORIENTED
ready been applied to various areas such as programming lan-
APPROACH
guages, office information systems, system simulation and
artificial intelligence. Some important features of present software The notion of “object” naturally plays a central role in object-
systems include: oriented software systems, but this concept has not appeared in the
object-oriented paradigm. In fact, it could be said that the object-
• Complexity: the internal architecture of current software sys- oriented paradigm was not invented but actually evolved by im-
tems is complex, often including concurrency and parallelism. proving already existing practices. The term “object” emerged
Abstraction in terms of object-oriented concepts is a technique almost independently in various branches of computer science.
that helps to deal with complexity. Abstraction involves a se- Some areas that influenced the object-oriented paradigm include:
lective examination of certain aspects of an application. It has system simulation, operating systems, data abstraction and artifi-
the goal of isolating those aspects that are important for an cial intelligence. Appearing almost simultaneously in the early
understanding of the application, and also suppressing those 1970s, these computer science branches cope with the complexity
aspects that are irrelevant. Forming abstractions of an applica- of software in such a way that objects represent abstract compo-
tion in terms of classes and objects is one of the fundamental nents of a software system. For instance, some notions of “object”
tenets of the object-oriented paradigm. that emerged from these research fields are:
• Friendliness: this is a paramount requirement for software
systems in general. Iconic interfaces provide a user-friendly • Classes of objects used to simulate real-world applications, in
interaction between users and software systems. An icon is a Simula [5]. In this language the execution of a computer pro-
graphical representation of an object on the screen, with a cer- gram is organized as a combined execution of a collection of
tain meaning to its observer, and is usually manipulated with objects, and objects sharing common behavior are said to con-
the use of a mouse, a process that has come to be known as stitute a class.
WYSIWYG (What You See Is What You Get) interaction. In • Protected resources in operating systems. Hoare [6] proposed
such interfaces, windows, menus and icons are all viewed as the idea of using an enclosed area as a software unit and in-
objects. The trend to object-oriented graphical interfaces is troduced the concept of monitor, which is concerned with
evident in many areas of software development; experience process synchronization and contention for resources among
suggests that user interfaces are significantly easier to develop processes.
when they are written in an object-oriented fashion. Thus the • Data abstraction in programming languages such as CLU [7].
object-oriented nature of the WYSIWYG interfaces maps It refers to a programming style in which instances of abstract
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 2

data types (i.e. objects) are manipulated by operations that are level of this tree structure inherit behavior of higher level objects;
exclusively encapsulated within a protected region. inheritance turned out to be the main structuring mechanism which
• Units of knowledge called frames, used for knowledge repre- made it possible for similar objects to share program code. Despite
sentation. Minsky [8] proposed the notion of frames to capture many authors being concerned with providing precise definitions
the idea that behavior goes with the entity whose behavior is for the object-oriented paradigm, it was difficult to come up with a
being described. Thus a frame can also be represented as an single generally accepted definition.
object.
Rentsch [10] defines object-oriented programming in terms of
All these influences have been gathered together and the object- inheritance, encapsulation, methods, and messages, as found in
oriented paradigm has been seen as a way to converge them, as Smalltalk. Objects are uniform in that all items are objects and no
shown in Figure 1. The common characteristic of these ideas is object properties are visible to an outside observer. All objects
that an object is a logical or a physical entity that is self-contained. communicate using the same mechanism of message passing, and
Clearly, other belated items could be added to that list, such as processing activity takes place inside objects. Inheritance allows
innovations in programming languages, as demonstrated in Ada; classification, sub-classification and super-classification of ob-
and advances in programming methods, including the notion of jects, which permits their properties to be shared.
modularization and encapsulation. Nevertheless, Simula was the
Pascoe [11] also presents object-oriented terminology from the
first programming language that had objects and classes as central
Smalltalk perspective. Pascoe defines an object-oriented approach
concepts. Simula was initially developed as a language for pro-
in terms of encapsulation, data abstraction, methods, messages,
gramming discrete-event simulations, and objects in the language
inheritance, and dynamic binding for object-oriented languages.
were used to model entities in the real-world application that was
Pascoe also affirms that some languages that have one or two of
being simulated.
these features have been improperly called object-oriented lan-
Despite the early innovation of Simula, the term “object-oriented” guages. For instance, Ada could not be considered an object-
became prominent from Smalltalk [9]. The Smalltalk language, oriented language because it does not provide inheritance.
first developed in 1972 in the Learning Research Group at Xerox
Other authors, such as Robson [12] and Thomas [13], emphasize
Palo Alto Research Center, was greatly influenced by Simula as
the idea of message passing between objects and dynamic binding
well as by Lisp. Smalltalk was the software half of an ambitious
as fundamental to object-oriented programming. There is no doubt
project known as the Dynabook, which was intended to be a pow-
those authors have also been influenced by the Smalltalk language,
erful personal computer. Research on Smalltalk has continued and
wherein the message passing mechanism plays a fundamental role
the Smalltalk language and the environment were by-products of
as the way of communication among objects. On the other hand,
that project. From Smalltalk, some common concepts and ideas
Stroustrup [14] claims that object-oriented programming can be
were identified and they gave support, at least informally, to the
seen as programming using inheritance, and that message-passing
object-oriented paradigm. Because of the evolution and dissemina-
is just an implementation technique, not at all an inherent part of
tion of programming languages like Smalltalk, this new paradigm
the paradigm.
has evolved, and new languages, methodologies, and tools have
appeared. Nygaard [15] discusses object-oriented programming in terms of
the concept of objects in Simula. In that language an execution of
a computer program is organized as the joint execution of a collec-
3. CHARACTERISATION OF AN OBJECT-ORIENTED tion of objects. The collection as a whole simulates a real-world
MODEL application, and objects sharing common properties are said to
Although object-oriented programming has its roots in the 1970s, constitute a class. Madsen and Moller-Pedersen [16], like Nygaard
there were many definitions about what precisely the term object- [15], sees object-oriented programming as a model that simulates
oriented meant. The term meant different things to different people the behavior of either a real or imaginary part of the world. The
because it had become very fashionable to
describe any software system in terms of ob-
ject-oriented concepts. To some, the concept System Operating Data Artificial
of object was merely a new name for abstract Simulation Systems Abstraction Intelligence
data types; each object had its own private
variables and local procedures, resulting in
Abstract Data Frames
modularity and encapsulation. To others, Classes + Monitors
classes and objects were a concrete form of Types +
Objects
type theory; in this view, each object is con- Encapsulation
sidered to be an element of a type which itself
can be related through sub-type and super-
type relationships.
Object-Oriented
To others still, object-oriented software sys- Paradigm
tems were a way of organizing and sharing
code in large software systems. Individual
procedures and the data they manipulate are
organized into a tree structure. Objects at any
Figure 1: The Background of the Object-Oriented Paradigm.
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 3

model consists of objects defined by attributes and actions, and the The object-oriented paradigm goes a step further than abstract data
objects simulate phenomena. Any transformation of a phenomenon types; that is, object-oriented languages allow similarities and dif-
is reflected by actions on the attributes. The state of an object is ferences between abstract data types to be expressed through in-
expressed by its attributes and the state of the whole model is the heritance, which is a key defining feature of the object-oriented
state of the objects in that model. paradigm. Therefore it would be better to characterize the evolu-
tion of object-oriented languages based on the support for both
The object-oriented paradigm was still lacking a well-known and
abstract data types and inheritance; in this case the immediate an-
profound theoretical understanding, then some research come out
cestor of object-oriented languages was Simula, which was an
in this area. Cardelli and Wegner [17], for example, with formal
Algol-based language. Simula was the first language to introduce
methods that used denotational semantics, described the essential
the concept of class and to allow inheritance to be expressed, and
features of the object-oriented paradigm, such as abstract data
it should be recognized as the “mother” of a few object-oriented
types, objects, classes and inheritance.
programming languages. Besides, because object-oriented con-
Lastly, Wegner [18] characterized an object-oriented approach in cepts have also arisen from the artificial intelligence community, it
terms of objects, classes and inheritance. Objects are autonomous is not surprising that Lisp has influenced a number of object-
entities that have a state and respond to messages; classes arrange oriented languages. For instance, Flavors [19], Loops [20] and
objects by their common attributes and operations; inheritance CLOS [21], have all borrowed ideas from Lisp and Smalltalk.
serves to classify classes by their shared commonality. Thus: ob-
The prominence of the object-oriented paradigm has influenced
ject-orientation = objects + classes + inheritance. The characteriza-
the design of other programming languages. There are languages
tion of an object-oriented approach proposed by Wegner has been
that incorporate object-oriented constructs into the popular C, Pas-
the most accepted one.
cal and Modula-2, resulting in the hybrid languages Objective-C
As it has been described, there are many different interpretations [22], C++ [23], ObjectPascal [24] and Modula-3 [25]. The inclu-
of the object-oriented paradigm. Nevertheless, one thing that all sion of object-oriented concepts into traditional languages sophis-
definitions have in common, not surprisingly, is the recognition ticated them, in that programmers had the flexibility to use or not
that an object is the primitive concept of the object-oriented para- to use the object-oriented extensions and benefits. Although these
digm. The object is an encapsulation of protected data along with hybrid languages became more complex, those extensions enabled
all the legal operations that act on that hidden information. programmers who had considerable experience with those tradi-
tional procedure languages to explore incrementally the different
concepts provided by the object-oriented paradigm. Nevertheless,
4. COMPARISON BETWEEN “OBJECT-ORIENTED” when using a hybrid language, programmers had to exercise more
LANGUAGES discipline than when using a pure object-oriented language be-
cause it was too easy to deviate from sound object-oriented princi-
At the beginning of programming language development, assem- ples. For instance, C++ allows global variables, which violates the
bly languages only enabled programmers to write code based on fundamental principle encapsulation.
machine instructions (operators) that manipulated the contents of
memory locations (operands). Therefore the level of control and As far as concurrency is concerned, objects can also be viewed as
data abstraction achieved was very low. A great leap forward oc- concurrent agents that interact by message passing, thus emphasiz-
curred when the first higher-level languages, e.g. Fortran and Al- ing the role of entities such as actors and servers in the structure of
gol, appeared. The operators turned into statements and operands a real-world application. The main idea behind object-oriented
into variables and data structures. The traditional view of programs languages that support concurrency is to provide programmers
in these languages is that they were composed of a collection of with powerful constructs that allow objects to run concurrently.
variables that represented some data and a set of procedures that Concurrency adds the idea of simultaneously executing objects
manipulated those variables. The majority of traditional program- and exploiting parallelism. Languages to which this applies in-
ming languages supported this data-procedure paradigm. That is, clude: Actor [26], ABCL [27], POOL-T [28], Orient84 [29] and
active procedures operate upon passive data that is passed to them. ConcurrentSmalltalk [30].
Things happen in a program by invoking a procedure and giving to Other languages influenced basically by Simula and CLU, such as
it some data to manipulate. Through a sequence of statements and Beta [31] and Eiffel [32] have also appeared and are believed to
procedures, early higher-level languages had reasonable support to give good support for the object-oriented paradigm. Although Eif-
implement actions; however, they had shortcomings to represent fel and Smalltalk seem to be coherent object-oriented languages
abstract data types. with integrated programming environments, C++ has become the
Abstract data types are abstractions that may exist at a higher level most used object-oriented programming language, due to the in-
than operands and operators, or variables and procedures sepa- fluence of UNIX and the popularity of the C language from which
rately. Some languages provided a construct that allowed both C++ derived. Finally, Java [33] should look familiar to C and C++
variables and procedures to be defined within a single unit; for programmers because Java was designed with similar but cleaner
instance the cluster construct in CLU, which satisfies the definition constructs; it also provides a more robust library of classes. Java is
of abstract data types. The same idea can also be found in Ada rapidly gaining territory among programmers, and it is expected to
through the package construct. Nevertheless, if two abstract data become the most popular object-oriented language. Analyzing the
types are similar but not identical, there is no means of expressing evolution of all those languages over time leads to the dependency
their commonality conveniently in a programming language that graph shown in Figure 2.
supports only abstract data types.
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 4

A programming language is called object-based if it permits the Table 1: Comparing Languages

definition of objects as abstract data types only, whereas, a lan-
guage is called object-oriented if it allows the definition of objects Features Abstract Inheritance Dynamic Extensive
and supports the inheritance mechanism. According to this classi- X Data Support Binding Library
fication, the set of object-based languages includes Ada and CLU. Languages Types
This is so because objects in Ada are defined as packages and ob- Simula yes yes yes no
jects in CLU are instances of clusters. The set of object-oriented CLU yes no yes no
languages is smaller than the set of object-based languages, and Ada yes no no yes
excludes Ada and CLU but includes Smalltalk and C++ because Smalltalk yes yes yes yes
the latter two support inheritance. Table 1 shows a comparison ObjectiveC yes yes yes yes
between some of the programming languages mentioned above. C++ yes yes yes yes
When serious programming is mentioned, it is not just about the CLOS yes yes yes no
language, it is also about library support that has been built around Obj.Pascal yes yes yes no
a language, forming a platform that helps to develop software sys- Beta yes yes yes no
tems. Eiffel yes yes yes yes
Actor yes yes yes no
It can be concluded that, despite the possibility of following an Java yes yes yes yes
object-oriented fashion using languages (e. g. Ada and CLU) with
less or more difficulty, direct language support is beneficial in oriented concepts into a language that does not provide inheritance
facilitating as well as encouraging the use of the object-oriented is that weird constructions may be produced, impairing software
tenets such as in Eiffel or Java. Not only do these languages sup- development and jeopardizing the quality of the resulting software.
port the object-oriented paradigm, but also they enforce it because
the main language constructs dealt with are related to objects,
classes and inheritance. The danger in trying to force object-

Assembly
50s

Fortran

60s Lisp Algol

Simula
Pascal
70s
C Ada CLU
Smalltalk
Beta
Modula-2
C++

80s

Flavors Actor ObjectPascal

Loops POOL-T Objective-C Modula-3
Eiffel
CLOS ABCL
Orient84

90s
Java
Figure 2: Language Evolution.
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 5

5. CLASSIFICATION OF OBJECT-ORIENTED vides complex functions into sub-functions. When the resulting
METHODOLOGIES sub-functions are simple enough, decomposition stops. This proc-
An important idea brought forward by software engineering is the ess of refinement was known as the functional decomposition ap-
concept of software life cycle models. Several models have been proach. Structured development also included a variety of
proposed in order to systematize the several stages that a software notations for representing software systems. During the require-
system goes through [34, 35, 36]. In parallel, many software de- ments and analysis phases, data flow diagrams, entity-relationship
velopment methodologies have also been proposed over the last diagrams and a data dictionary are used to logically specify a
few decades. Such methodologies provided some discipline in software system. In the design phase, details are added to the
handling the inherent software complexity because they usually specification model and the data flow diagrams are converted into
offered a set of rules and guidelines that helped software engineers structure chart diagrams ready to be implemented in a procedural
understand, organize, decompose and represent software systems. language.

Those methodologies may be classified into three approaches. Structured analysis appeared to be an attractive starting point to be
First, some methodologies dealt with functions; they emphasized followed by object-oriented design primarily because it was well
refinement through functional decomposition as, for example, known, many software professionals were trained in its techniques,
Structured Design [37], HIPO [38] and Stepwise Refinement [39]. and several tools supported its notations. However, structured
Typically, software development has to follow a top-down fashion analysis was not the ideal front-end to object-oriented design,
by successively refining functions. mainly because it perpetuated a functional decomposition view of
the system. Applying a functional decomposition approach first
In a second line of thought, there were methodologies that recom- and an object-oriented approach later on the same software system
mended that software systems should be developed with emphasis led to trouble because functions could not be properly mapped into
on data rather than on functions. That is, the system architecture objects.
was based on the structure of the data to be processed by the sys- Ideally, object-oriented design and implementation should be part
tem. The software system should be structured mainly through the of a software development process in which an object-oriented
identification of data components and their meaning. This tech- philosophy is used throughout software development, as shown in
nique could be noted in the early Jackson Structured Programming Figure 3. In that figure, the dashed arrows represent an unnatural
methodology [40] and the Entity-Relationship Model (ERM) [41]. mapping between concepts of different approaches, as opposed to
The Entity-Relationship Model was the most common approach to the bold arrows, which indicate a smooth transition from one
data modeling in the 1970s and 1980s. ERM is a graphical tech- phase to the next. Consequently, attempting to combine an object-
nique easy to understand yet powerful enough to model real-world oriented approach with a structured development approach gave
applications, then entity-relationship diagrams are readily trans- rise to some problems.
lated into a database implementation.
Because, in early phases, a software system was described in terms
A third style consisted of methodologies that aimed at developing of functions and later on the description was changed to object-
software systems from both functional and data points of view, but oriented terms (see Figure 3), it jeopardized traceability from re-
separately. Examples of such methodologies are SADT [42], quirements to implementation. Structured development method-
Structured Analysis [43] and Structured System Analysis [44]. ologies did not place data within objects but on the data flow
SADT provides different kinds of diagrams to represent functions, between functions, and a software system was described with data
control, mechanisms and data. As far as Structured Analysis and flows and functions. In contrast, the object-oriented paradigm or-
Structured System Analysis are concerned, designers can represent ganizes a software system around classes and objects that exist in
and refine functions through data flow diagrams, (which also show the designer's view of the real-world application.
functions) and use a data dictionary to describe data. So that engi-
neering applications could be better modeled, Ward and Mellor On the other side, there has also been a profusion of so-called “ob-
[45] introduced real-time extensions into structured analysis. Fi- ject-oriented” methodologies for analysis and design influenced by
nally, Structured System Analysis and Design Methodology different backgrounds, and found in a variety of software life cycle
(SSADM) [46] is another renowned structured analysis approach. models. Nevertheless, two major trends can be noticed:

These methodologies, known as structured, organize a system 1) Adaptation: it has been concerned with mixing an object-
specification and design around hierarchies of functions. Struc- oriented approach with well-known structured development
tured analysis begins by identifying one or more high level func- methodologies.
tions that describe the overall purpose of a software system. Then, 2) Assimilation: it has emphasized the use of an object-oriented
each high level function is broken down into smaller less complex methodology for developing software systems, but has fol-
functions, followed by structured design and structured program- lowed the traditional waterfall software life cycle model.
ming. Needless to say, these methodologies have been supported 5.1 Adaptation
by a myriad of CASE tools. The main purposes of the tools were Adaptation proposes a framework to mix an object-oriented ap-
to increase productivity, help with system documentation and en- proach with existing structured methodologies. Henderson-Sellers
hance the quality of the developed software. and Constantine [47] suggested that a combination of structured
A combination of approaches that followed structured analysis, development with an object-oriented approach could smooth soft-
structured design, and structured programming was collectively ware development. Based on a functional decomposition designers
known as structured development. This approach iteratively di- could use their experience and intuition to derive a specification
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 6

from an informal description in order to get a high Structured Object-

level abstraction for a software system. The adaptation Analysis ANALYSIS Oriented
of structured development to an object-oriented ap- Analysis
proach preserves the specification and analysis phases Data Flow +
using data flow diagrams, and it proposes heuristics to ERM Class
convert these diagrams into an object model in such Diagrams Diagrams
way that subsequent phases can then follow an object-
oriented approach. Some advantages of this adaptive
approach are:
• A complementary coupling between structured Object-
development and the object-oriented approach. Oriented
• A smoother migration from well-practiced and Structured Design
well-known approaches to a new one that included Design DESIGN
classes, objects and inheritance. Class +
• Gradual change from old tools and environments Structure Object
to a new paradigm. Charts Diagrams

The most widely used software engineering method-

ologies have been those for structured development.
Such methodologies have been popular because they
were applicable to many types of application domains. Object-
Structured Oriented
Because of this popularity, structured development has
Programming
IMPLEMENTATION
been combined with an object-oriented approach. Programming
Software engineers, who had used functional decompo-
Data Abstract
sition and data modeling techniques, have probably
Structures + Data Types +
found the methodologies of Shlaer and Mellor [48] as
Functions Inheritance
well as Coad and Yourdon [49] familiar because these
methodologies are clearly adaptations of traditional Figure 3: Some Combinations of Approaches
structured development methodologies and data model-
ing techniques. fication model. Lastly, Alabiso [55] and Ward [56] combined ob-
ject-oriented development with Structured Analysis [43],
Those methodologies oversimplified the object-oriented paradigm Structured Design [37] and the Entity-Relationship Model [41].
by misusing the concepts of classes and objects during the analysis
phase. Basically, they concentrated on modeling real-world enti- The first significant step towards an object-oriented design meth-
ties as objects, and they can be considered as extensions of the odology started within the Ada community. Many ideas about ob-
Entity-Relationship Model [41], suggesting that they are incre- ject-oriented design came out with the work of Abbott [57] and
mental improvements of existing approaches to data modeling. Booch [58]. Booch rationalized Abbott's method, and referred to it
Moreover they have not discussed the impact of their methodology as Object-Oriented Design [59]. Both Abbott and Booch have rec-
on other phases of the software life cycle. These methodologies ommended that a design should start with an informal description
were used during a period of transition from structured develop- of the real-world application and from that narrative description
ment to object-oriented development as a compromise. However, designers could identify classes and objects from nouns, and op-
they did not permit the full advantages of an object-oriented ap- erations from verbs. Booch’s work was significant because it was
proach. one of the earliest object-oriented design methodologies to be de-
scribed. He was also one of the most influential advocates of ob-
Jackson [50] has proposed a methodology called the Jackson Sys- ject-oriented design within the Ada community.
tem Development (JSD). JSD has some features that appear on the
surface to be similar to object-oriented design. The main task is to Realizing the drawbacks of the technique based on identification
model the application and to identify entities (which could be of classes and objects from informal descriptions, later, Booch no
viewed as objects), actions (i.e. operations) and their interactions. longer used a narrative description. Instead, Booch [60] combined
However, JSD is not fully suitable for object-oriented design be- object-oriented design with existing methodologies and called it
cause there is little to support the object-oriented paradigm, and Object-Oriented Development. He suggested that existing meth-
inheritance is completely ignored. Other less known proposals in odologies such as SREM [61] or Structured System Analysis [44]
which object-oriented concepts are derived from structured devel- or JSD [50] could be used during the system analysis phase as a
opment can also be mentioned. Some of these methods were step before object-oriented design. Subsequently, Booch [62] pro-
merely extensions of structured development techniques. Masiero posed a truly object-oriented design methodology.
and Germano [51] and Hull et al. [52] put together object-oriented
design with JSD, and the by-product of the design is implemented
in Ada. Bailin [53] and Bulman [54] combined object-oriented As far as Booch's influences are concerned, they can be summa-
development with Structured System Analysis [44] and the Entity- rized as follows: what has come to be known as object-oriented
Relationship Model [41] in an object-oriented requirements speci- design in the context of Ada was first proposed by Booch [58],
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 7

later extended and generalized by Booch [60], then refined by Sei- ware life cycle model.
dewitz [63], Heitz [64] and Jalote [65]. Berard [66] and Sincovec
Booch [62] introduced a comprehensive object-oriented methodol-
and Wiener [67] also presented principles and methods biased by
ogy for software development with a graphical notation to express
Booch [58] with implementation driven towards Ada. These de-
a design, one that could form the basis for automated tools. He
sign methodologies concentrated on identifying objects and opera-
also included a variety of models that addressed the functional and
tions, and were object-oriented in the sense that they viewed a
dynamic aspects of software systems.
software system as a collection of objects. Wasserman et al. [68]
have proposed OOSD, a graphical representation for Object-
Oriented Structured Design. OOSD provided a standard design 6. FINAL REMARKS
notation by supporting concepts of both structured and object- This paper has expanded upon the background of the object-
oriented design. The main ideas behind OOSD came from Struc- oriented paradigm. This paradigm has provided a powerful set of
tured Design [37] and Booch [60] notation for Ada packages. Most concepts completely absorbed into the software development cul-
of these methodologies were based on an informal description or ture of the 1990s, just as, in the same way, structured development
representation of the software requirements, from which objects, methodologies (and, to some extent abstract data types concepts)
attributes and operations were identified. Moreover, all of these had been in the 1970s and 1980s. This is evident in the abundance
methodologies applied hierarchical decomposition, a trend to de- of tools supporting all aspects of software development following
compose a software system by breaking it into smaller components this paradigm. Consequently the last decade has been a period of
through a series of top-down refinements towards an implementa- gradual acceptance of the object-oriented paradigm, which has
tion in Ada. become the main approach to developing software systems since
the early 1990s.
5.2 Assimilation
In the 1980s and 1990s several object-oriented methodologies ap- One great advantage of using the object-oriented paradigm is the
peared but they covered only partially the software life cycle conceptual continuity across all phases of the software develop-
model. Assimilation was a trend that put the object-oriented para- ment life cycle; that is, the conceptual structure of the software
digm within the traditional waterfall software life cycle model. system remains the same, from system analysis down through im-
Several authors tried to fit the object-oriented paradigm into this plementation. Therefore when the object-oriented paradigm is
framework: Lorensen [69], Jacobson [70], Wirfs-Brock et al. [71], used, the design phase is linked more closely to the system analy-
Rumbaugh et al. [72] and Booch [62] can be considered good ex- sis and the implementation phases because designers have to deal
amples. with similar abstract concepts (such as classes and objects)
throughout software development. Capretz and Capretz [76] de-
Lorensen [69] described the rudiments of object-oriented software scribe a methodology for object-oriented design and maintenance,
development by explaining that it was fundamentally different which takes domain analysis and software reusability into account
from traditional structured development methods, such as those as important aspects of an alternative software life cycle model.
based on data flow diagrams and a functional decomposition ap- However, object-orientation has needed an organized and manage-
proach. able view of software development permeating all phases of the
Jacobson [70] claimed to have a full object-oriented development software life cycle model. That demand has been met by the Uni-
methodology named the ObjectOry, which combined a technique fied Modeling Language (UML) [77] and by CASE tools such as
to develop large software systems termed block design [73] with Rational Rose.
conceptual modeling [74] and object-oriented concepts. Jacobson Because there are unique object-oriented concepts involved in the
stated that it was quite natural to unite these three approaches since whole software development process, there should have been spe-
they rely on similar ideas aiming at, among other things, the pro- cific methodologies suitable to the development of that object-
duction of reusable software components. oriented software. However, history shows that the object-oriented
Wirfs-Brock et al. [71] focused on the identification of responsi- software development has been combined with other approaches;
bilities and contracts to build a responsibility-driven design. Re- it was influenced by, and has been influencing, other ideas. After
sponsibilities are a way to apportion work among a group of more than thirty years since the first object-oriented programming
objects that comprise a real-world application. A contract is a set language was introduced, the debate over the claimed benefits of
of related responsibilities defined by a class, and describes the the object-oriented paradigm still goes on. But there is no doubt
ways by which client objects can interact with server objects. In- that most new software systems will be object-oriented; that, no-
troduced by Beck and Cunningham [75], was a technique that re- body disputes.
corded design on cards, and which proposed the Class,
Responsibility, and Collaboration (CRC) cards. It has been sug- REFERENCES
gested that using CRC cards is a simple technique for teaching
object-oriented thinking to newcomers. [1] Johnson R. E. and Foote B. Designing Reusable Classes,
Journal of Object-Oriented Programming, 1(2), pp. 22-35,
Rumbaugh et al. [72] developed the Object Modeling Technique June/July 1988.
(OMT), which focused on object modeling as a software develop-
ment technique. OMT is a comprehensive methodology that incor-
porates structured development based on a functional [2] Micallef J. Encapsulation, Reusability and Extensibility in
decomposition approach following the traditional waterfall soft- Object-Oriented Programming Languages, Journal of Ob-
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 8

ject-Oriented Programming, 1(1), pp. 12-36, April 1988. [20] Stefik M. and Bobrow D. G. Object-Oriented Programming:
Themes and Variations, The AI Magazine, 6(4), pp. 40-62,
[3] Gossain S. and Anderson B. An Iterative-Design Model for
April 1986.
Reusable Object-Oriented Software, ACM SIGPLAN Notices,
25(10), pp. 12-27, October 1990. [21] DeMichiel L. G. and Gabriel R. P. The Common Lisp Object
System: An Overview, Lecture Notes in Computer Science,
[4] Capretz L. F. and Lee P. A. Reusability and Life Cycle Is-
No. 276, pp. 151-170, Berlin: Springer-Verlag, 1987.
sues Within an Object-Oriented Design Methodology, Ege R.
Singh M. and Meyer B. (eds.) Proceedings of TOOLS [22] Cox B. J. Object-Oriented Programming - An Evolutionary
USA'92 - Technology of Object-Oriented Languages and Approach, Readings, Massachusetts: Addison-Wesley, 1986.
Systems, Englewood Cliffs, New Jersey: Prentice Hall, pp.
[23] Stroustrup B. The C++ Programming Language, Reading,
139-150, August 1992.
Massachusetts: Addison-Wesley, 1986.
[5] Dahl O.-J., Myhrhaug B. and Nygaard K. SIMULA67 Com-
[24] Tesler L. Object Pascal Report, Santa Clara, California: Ap-
mon Base Language, Publication No. S-22, Oslo: Norwegian
ple Computer, 1985.
Computing Centre, 1970.
[25] Cardelli L. Modula-3 Report, Palo Alto, California: Digital
[6] Hoare C. A. R. Monitors: an Operating Systems Structuring
Equipment Corporation, 1989.
Concept, Communications of the ACM, 17(10), pp. 549-577,
October 1974. [26] Agha G. An Overview of Actor Languages, ACM SIGPLAN
Notices, 21(10), pp. 58-67, October 1986.
[7] Liskov B., Snyder A., Atkinson R. and Schaffert, C. Abstrac-
tion Mechanisms in CLU, Communications of the ACM, [27] Yonezawa A., Shibayama E., Takada T. and Honda Y. Mod-
20(8), pp. 564-576, August 1977. elling and Programming in an Object-Oriented Concurrent
Language ABCL/1, Yonezawa A. and Tokoro M. (eds.) Ob-
[8] Minsky M. A Framework for Representing Knowledge, Wis-
ject-Oriented Concurrent Programming, pp. 55-90, Cam-
ton P. (ed.) The Psychology of Computer Vision, New York:
bridge, Massachusetts: MIT Press, 1987.
McGraw-Hill, 1975.
[28] America P. POOL-T: A Parallel Object-Oriented Language,
[9] Goldberg A. and Robson D. Smalltalk-80: The Language
Yonezawa A. and Tokoro M. (eds.) Object-Oriented Con-
and its Implementation, Reading, Massachusetts: Addison-
current Programming, pp. 199-220, Cambridge, Massachu-
Wesley, 1983.
setts: MIT Press, 1987.
[10] Rentsch T. Object Oriented Programming, ACM SIGPLAN
[29] Yutaka I. and Tokoro M. A Concurrent Object Oriented
Notices, 17(9), pp. 51-57, September 1982.
Knowledge Representation Language Orient84/K: Its Fea-
[11] Pascoe G. A. Elements of Object-Oriented Programming, tures and Implementation, ACM SIGPLAN Notices, 21(11),
Byte 11(8), pp. 139-144, August 1986. pp. 232-241, November 1986.
[12] Robson D. Object-Oriented Software Systems, Byte, 6(8), [30] Yokote A. and Tokoro M. Concurrent Programming in Con-
pp. 74-86, August 1981. currentSmalltalk, Yonezawa A. and Tokoro M. (eds.) Object-
Oriented Concurrent Programming, pp. 129-158, Cam-
[13] Thomas D. What's in an Object, Byte, 14(3), pp. 231-240,
bridge, Massachusetts: MIT Press, 1987.
March 1989.
[31] Kristensen B. B., Madsen O. L., Moller-Pedersen B. and
[14] Stroustrup B. What is Object-Oriented Programming?, Lec-
Nygaard K. Multi-Sequential Execution in the Beta Pro-
ture Notes in Computer Science, No. 276, pp. 51-70, Berlin:
gramming Language, ACM SIGPLAN Notices, 20(4), pp. 57-
Springer-Verlag, 1987.
70, April 1985.
[15] Nygaard K. Basic Concepts in Object Oriented Program-
[32] Meyer B. Object-Oriented Software Construction, Engle-
ming, ACM SIGPLAN Notices, 21(10), pp. 128-132, October
wood Cliffs, New Jersey: Prentice-Hall, 1988.
1986.
[33] Arnold K. and Gosling J. The Java Programming Language.
[16] Madsen O. L. and Moller-Pedersen B. What Object-Oriented
Reading, Massachusetts: Addison-Wesley, 1996.
Programming May Be and What It Does Not Have to Be,
Lecture Notes in Computer Science, No. 322, pp. 1-20, Ber- [34] Royce W. W. Managing the Development of Large Software
lin: Springer-Verlag, 1988. Systems, Proceedings of the 9th International Conference on
Software Engineering, pp. 328-338, IEEE Press, 1987.
[17] Cardelli L. and Wegner P. On Understanding Types, Data
Abstraction, and Polymorphism, ACM Computing Surveys, [35] Boehm B. W. A Spiral Model of Software Development and
17(4), pp. 471-522, December 1985. Enhancement, IEEE Computer, 21(5), pp. 61-72, May 1988.
[18] Wegner P. Dimensions of Object-Based Language Design, [36] Henderson-Sellers B. and Edwards J. M. The Object-
ACM SIGPLAN Notices, 22(12), pp. 168-182, December Oriented Systems Life Cycle, Communications of the ACM,
1987. 33(9), pp. 142-159, September 1990.
[19] Moon D. A. Object-Oriented Programming with Flavors, [37] Yourdon E. and Constantine L. L. Structured Design,
ACM SIGPLAN Notices, 21(11), pp. 1-8, November 1986. Englewood Cliffs, New Jersey: Prentice-Hall, 1979.
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 9

[38] Stay J. F. HIPO and Integrated Program Design, IBM System [56] Ward P. How to Integrate Object Orientation with Structured
Journal, 15(2), pp. 143-154, April 1976. Analysis and Design, IEEE Software, 6(2), pp. 74-82, March
1989.
[39] Wirth N. Program Development by Stepwise Refinement,
Communications of the ACM, 14(4), pp. 221-227, April [57] Abbott R. J. Programming Design by Informal English De-
1971. scription, Communications of the ACM, 26(11), pp. 882-894,
November 1983.
[40] Jackson M. A. Principles of Program Design, New York,
New York: Academic Press, 1975. [58] Booch G. Software Engineering with Ada, Menlo Park, Cali-
fornia: Benjamin/Cummings, 1983.
[41] Chen P. P. The Entity-Relationship Model: Toward a Unified
View of Data, ACM Transactions on Database Systems, 1(1), [59] Booch G. Object-Oriented Design, Freeman P. and
pp. 9-36, March 1976. Wasserman A. I. (eds.) Tutorial on Software Design Tech-
niques, 4th Edition, pp. 420-436, IEEE Press, 1983.
[42] Ross T. R. and Schoman K. E. Structured Analysis for Re-
quirements Definitions, IEEE Transactions on Software En- [60] Booch G. Object-Oriented Development, IEEE Transactions
gineering, SE-3(1), pp. 6-15, January 1977. on Software Engineering, SE-12(2), pp. 211-221, February
1986.
[43] DeMarco T. Structured Analysis and System Specification,
Englewood Cliffs, New Jersey: Prentice-Hall, 1979. [61] Alford M. W. A Requirements Engineering Methodology for
Real-Time Processing Requirements, IEEE Transactions on
[44] Gane C. and Sarson T. Structured System Analysis: Tools
Software Engineering, SE-3(1), pp. 60-69, January 1977.
and Techniques, Englewood Cliffs, New Jersey: Prentice-
Hall, 1979. [62] Booch G. Object-Oriented Design with Applications, Red-
wood City, California: Benjamin/Cummings, 1991.
[45] Ward P. and Mellor S. Structured Development for Real-
Time Systems, Englewood Cliffs, New Jersey: Prentice-Hall, [63] Seidewitz E. General Object-Oriented Software Develop-
1985. ment: Background and Experience, Journal of Systems and
Software, 9(2), pp. 95-108, February 1989.
[46] Eva M. SSADM Version 4: A User’s Guide, London:
McGraw-Hill, 1994. [64] Heitz M. HOOD Reference Manual, Issue 3.0, Noordwijk,
The Netherlands: European Space Agency, 1989.
[47] Henderson-Sellers B. and Constantine L. L. Object-Oriented
Development and Functional Decomposition, Journal of Ob- [65] Jalote P. Functional Refinement and Nested Objects for Ob-
ject-Oriented Programming, 3(5), pp. 11-17, January 1991. ject-Oriented Design, IEEE Transactions on Software Engi-
neering, SE-15(3), pp. 264-270, March 1989.
[48] Shlaer S. and Mellor S. J. Object-Oriented Systems Analysis:
Modeling the World in Data, Englewood Cliffs, New Jersey: [66] Berard E. An Object-Oriented Design Handbook, Rockville,
Prentice-Hall, 1988. Maryland: EVB Software Engineering Inc., 1986.
[49] Coad P. and Yourdon E. Object-Oriented Analysis, Engle- [67] Sincovec R. F. and Wiener R. S. Modular Software Con-
wood Cliffs, New Jersey: Prentice-Hall, 1990. struction and Object-Oriented Design Using Ada, Peterson
G. E. (ed.) Tutorial: Object-Oriented Computing, pp. 30-36,
[50] Jackson M. A. System Development, London: Prentice-Hall,
IEEE Press, 1987.
1983.
[68] Wasserman A. I., Pircher P. A. and Muller R. J. The Object-
[51] Masiero P. and Germano F. S. R. JSD as an Object-Oriented
Oriented Structured Design Notation for Software Design
Design Method, Software Engineering Notes, 13(3), pp. 22-
Representation, IEEE Computer, 23(3), pp. 50-63, March
23, July 1988.
1990.
[52] Hull M. E. C., Zarca-Aliabadi A. and Guthrie D. A. Object-
[69] Lorensen W. Object-Oriented Design, CRD Software Engi-
Oriented Design, Jackson System Development (JSD) Speci-
neering Guidelines, General Electric Co., 1986.
fication and Concurrency, Software Engineering Journal,
4(2), pp. 79-86, March 1989. [70] Jacobson I. Object Oriented Development in an Industrial
Environment, ACM SIGPLAN Notices, 22(12), pp. 183-191,
[53] Bailin S. C. An Object-Oriented Requirements Specification
December 1987.
Method, Communications of the ACM, 32(5), pp. 608-623,
May 1989. [71] Wirfs-Brock R., Wilkerson B. and Wiener L. Designing Ob-
ject-Oriented Software, Englewood Cliffs, New Jersey: Pren-
[54] Bulman D. M. An Object-Based Development Model, Com-
tice Hall, 1990.
puter Language, 6(8), pp. 49-59, August 1989.

[72] Rumbaugh J., Blaha M., Premerlani W., Eddy F. and Loren-
[55] Alabiso B. Transformation of Data Flow Analysis Model to
sen W. Object-Oriented Modeling and Design, Englewood
Object-Oriented Design, ACM SIGPLAN Notices, 23(11), pp.
Cliffs, New Jersey: Prentice Hall, 1991.
335-353, November 1988.
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 10

[73] Jacobson I. Language Support for Changeable Large Real

Time System, ACM SIGPLAN Notices, 21(11), pp. 377-384,
November 1986.
[74] Borgida A. Features of Languages for the Development of
Information System at the Conceptual Level, IEEE Software,
2(1), pp. 63-72, January 1985.
[75] Beck K. and Cunningham W. A Laboratory for Teaching
Object-Oriented Thinking, ACM SIGPLAN Notices, 24(10),
pp. 1-6, October 1989.
[76] Capretz L. F. and Capretz M. A. M. Object-Oriented Soft-
ware: Design and Maintenance. Singapore: World Scientific,
1996.
[77] Booch G., Rumbaugh J. and Jacobson I. The Unified Model-
ing Language User Guide. Reading, Massachusetts: Addi-
son-Wesley, 1999.

Author’s bio-sketch: Dr. L. F. Capretz has

extensive experience in software engineer-
ing. He has worked (both at technical and
managerial levels), taught and done research
on the engineering of software in Brazil,
Argentina, England and Japan since 1981. In
the Faculty of Engineering at the University
of Western Ontario (Canada), he teaches
software design in an accredited program
that offers a degree in software engineer-
ing. Currently, he is focusing his research
in component-based software engineering and
software product lines.