892 OBIECT-ORIENTED DEVELOPMENT

Conference, Fifth National Conference on Ada Technology and E. N. Yourdon, ed.. Classics in Software Engineering, Yourdon
Washington Ada. Symposium, U.S. Army Communications- Press, New York, 1979.
Electronics Command, Fort Monmouth, NJ, 1987, pp. 213-222. E. Yourdon and L. L. Constantine, Structured Design: Fundamen-
W. P. Stevens, G. J. Myers and L. L. Constantine, "Structured tals of a Discipline of Computer Program and System Design,
Design," IBM Systems Journal 13(2), 115-139 (May 1974), re- Prentice-Hall, Englewood Cliffs, NJ, 1979.
printed in Freeman and Wasserman (1983, pp. 328-352).
B. Stroustrup, The C+-r Programming Language, 2nd ed., Addi- EuwARD V. BERARD
son-Wesley, Reading, MA, 1991. Berard Software Engineering,
D. K. Taylor and A. Hecht. "Using CASE for Ohject-Oriented Inc.
Design with C+-f," Computer Language 7(11), 49-57 (Novem-
ber 1990).
TBE (Teledyne Brown Engineering), Software Methodology Cata-
log, Technical Report MC87-COMM/ADP-0036, TBE, Tinton OBJECT-ORIENTED DEVELOPMENT
Falls, NJ, Octoher 1987.
H. Toetenel, J. van Katwijk, and N. Plat, "Structured Analysis— HISTORICAL PERSPECTIVE
Formal Design, Using Stream and Object-Oriented Formal
Specification," Proceedings of the ACM SIGSOFT Interna-
tional Workshop on Formal Methods in Software Development, The object-oriented model for software development has
Special Issue of Software Engineering Notes, Vol. 15, No. 4, become exceedingly attractive as the best answer to the
September 1990, pp. 118-127. increasingly complex needs of the software development
R. F. Vidale and C. R. Hayden, "A Student Project to Extend community. What was first viewed hy many as a research
Ohject-Oriented Design," Proceedings of the Ada Software curiosity and an impractical approach to industrial
Engineering Education and Training Symposium, June 9-11, strength software is now being enthusiastically emhraced.
1987, pp. 89-98. Object-oriented versions of most languages bave been or
P. Vielcanet, "HOOD Design Method and Control/Command Tech- are being developed. Numerous object-oriented methodo-
niques for the Development of Realtime Software," Proceedings logies have heen proposed. Conferences, seminars, and
of the 6th Washington Ada Symposium, June 26-29, 1989, courses on object-oriented topics are extremely popular.
pp. 213-219. New journals and countless special issues of both academic
J. M. Vlissides and M. A. Linton, "Applying Ohject-Oriented and professional journals have been devoted to tbe subject.
Design to Structured Graphics," Proceedings ofthe C++ Con- Contracts for software development that specify ohject-
ference, Denver, Colorado, October 1988, USENIX Association, oriented tecbniques and languages currently have a com-
Berkeley, CA, 1988, pp. 81-94. petitive edge. Ohject-oriented development is to the 1990s
N. L. Walters, "An Ada Object-Based Analysis and Design what structured development was to the 1970s, and tbe
Approach," Ado Letters 11(5), 62-78 (July/August 1991). object-oriented movement is still accelerating.
P. T. Ward, "How to Integrate Object Orientation with Structured Concepts like "objects" and "attributes of ohjects" actu-
Analysis and Design," IEEE Software 6(2), 74-82 (March ally date back to the early 1950s when they appeared in
1989). early works on artificial intelligence (Berard, 1993). How-
P. T. Ward and S. J. Mellor, Structured Development for Real- ever, the real legacy of tbe object-oriented movement
Time Systems, Vols. 1, 2, and 3, Yourdon Press, New York, began in 1966 when Kristen Nygaard and Ole-Joban
1985. Dabl moved to higher levels of ahstraction and introduced
A. I. Wasserman, P. Pitcher, and R. J. MuUer, "An Object- the language Simula. Simula provided encapsulation at a
Oriented Design Method for Code Generation," Software Engi- more ahstract level than subprograms; data ahstraction
neering Notes 14(1), 32-55 (January 1989).
and classes were introduced in order to simulate a pro-
A. I. Wasserman, P. Percher, and R. J. Muller, "An Object- blem. During approximately this same time frame, Alan
Oriented Design Notation for Software Design Representa- Kay was working at the University of Utah on a personal
tion," IEEE Computer 23(3), 50-63 (March 1990).
computer tbat he hoped would he able to support graphics
P. Wegner, 'Concepts and Paradigms of Object-Oriented Pro- and simulation. Due to both hardware and software limita-
gramming," OOPS Messenger 1(1), 7-^7 (August 1990).
tions. Flex, Kay's computer venture, was unsuccessful.
R. S. Wiener, ed., Foeus on Analysis and Design, SIGS Publica- However bis ideas were not lost and surfaced again
tions, New York, 1991. when be joined Xerox at Palo Alto Researcb Center
R. J. Wirfs-Brock and R. E. Johnson, "Surveying Current (PARC) in the early 1970s.
Research in Object-Oriented Design," Communications ofthe
ACM 33(9), 105-124 (September 1990). At PARC he was a memher of a project that espoused
the belief tbat computer technologies are the key to
R. Wirfs-Brock and B. Wilkerson, "Object-Oriented Design: A
Responsibility-Driven Approach," SIGPLAN Notices (Special
improving communication channels between people and
Issue), 24110), 71-76 (Octoher 1989). between people and machines. Based upon this conviction
and influenced hy the class concept in Simula; tbe turtle
R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object-
Oriented Software, Prentice-Hall, Englewood ClifTs, NJ, ideas LOGO provided in the Pen classes; the abstract
1990. data typing in CLU; and the incremental program execu-
S. S. Yau and J. J.-P. Tsai, "A Survey of Software Design Tecbni-
tion of LISP; the group developed Smalltalk. In 1972, the
ques," IEEE Transactions on Software Engineering SE-12(6), first version of Smalltalk was released hy PARC. Ahout
713-721 (June 1986). this time the term "ohject-oriented" was coined. Some
 OBJECT-ORIENTED DEVELOPMENT 893

people credit Alan Kay hecause he is said to have used tbe and encourages tbe software engineering practices of
term to ebaracterize Smalltalk. Smalltalk is considered to information biding, data abstraction, and encapsulation.
be the first true ohject-oriented language (Goldherg and In an ohject, revisions are localized. Object-orientation
Rohson, 1983). The goal of Smalltalk has been to enable results in software that is easily modified, extended, and
the design of software in units tbat are as autonomous as maintained (Berard, 1993). Object-orientation extends
possihle. Everything in the language is an ohject; that is, across the Ufe cycle in that a consistent approach is used
an instance of a class. Objects in this nascent Smalltalk from analysis througb coding. The use of object-oriented
world bave heen associated witb nouns. The Smalltalk development encourages the reuse of not only software
effort has supported a highly interactive development hut also design and analysis. Furthermore, object-oriented
environment and prototyping. Tbis original work has not development facilitates interoperability; that is, the
heen publicized and bas been viewed with academic inter- degree to whicb an application running on one node of a
est as bighly experimental, (see SMALLTALK). network can make use of a resource at a different node of
Smalltalk 80 was tbe culmination of a numher of ver- the network. Object-oriented development also supports
sions of the PARC Smalltalk, and was released to the the concurrency, hierarchy and complexity present in
non-Xerox world in 1981. Tbe August 1981 issue of Byte some of today's software systems. It is currently necessary
featured tbe Smalltalk efforts. On the cover of the issue to build systems, not just black-box applications. These
was a picture of a bot air balloon leaving an isolated island complex systems are often hierarchically composed of dif-
whicb symbolized the launch of the PARC object-oriented ferent kinds of suhsystems. Object-oriented development
ideas. It was time to start puhlicizing to tbe software devel- supports open systems; there is much greater flexibility
opment community. The impact was gradual at first hut to integrate software across applications. Finally, use of
mounted to tbe current level of fiurry about object-oriented the object-oriented approach tends to reduce tbe risk of
techniques and products. Tbe balloon was in fact launcbed developing complex systems, primarily because system
and there was an efTect. The early Smalltalk researcb in integration is diffused throughout the life cycle (Booch,
environments led to window, icon, mouse and pulldown 1991).
window environments. Tbe Smalltalk language influenced
the development in the early to mid 1980s of otber object-
oriented languages, most notahly: Objective-C (1986), OBIECT-ORIENTED MODEL
C++ (1986), Self (1987), Eiffel (1987), and Flavors
(1986). Tbe application of ohject-orientation was broa-
The ohject-oriented model is more than a collection of new
dened. Objects no longer were associated just with nouns,
languages; it is a new way of tbinking ahout what it means
but also witb events and processes. In 1980, Grady Boocb
to compute and ahout how information can be structured.
pioneered witb tbe concept of ohject-oriented design
In the ohject-oriented model, systems are viewed as co-
(Booch, 1982). Since tben others have followed suit, and
operating ohjects tbat encapsulate structure and behavior
object-oriented analysis techniques have also begun to he
and tbat helong to classes whicb are hierarchically con-
puhlicized. In 1985, tbe first commercial ohject-oriented
structed. All functionality is achieved by messages tbat
database system was introduced. Most recently, object-
are passed to and from objects. The object-oriented model
oriented domain analysis, testing, metrics and manage-
can he viewed as a conceptual framework with the follow-
ment are heing investigated.
ing elements: abstraction, encapsulation, modularity,
hierarchy, typing, concurrence, persistence, reusability,
and extensibility.
MOTIVATION The emergence of tbe object-oriented model does not
mark any sort of computing revolution. Instead, ohject-
Why has tbe ohject-oriented movement gained such orientation is the next step in a methodical evolution
momentum? In reality some of its popularity probably from botb procedural approacbes and strictly data-driven
stems from the bope that it, like so many other earlier soft- approaches. New approaches to software development
ware development innovations, will address the crying have heen precipitated hy hoth programming language
needs for greater productivity, reliability, maintainability, developments and increased sophistication and breadth
and manageability. However, aside from the hope that in the prohlem domains for whicb software systems are
ohject-orientation is in fact the "silver bullet," there are being designed. While in practice the analysis and design
many other documented arguments to motivate its adop- processes ideally precede implementation, it bas heen tbe
tion. language innovations which have necessitated new
Ohject-oriented development adds emphasis on direct approaches to design and then later, analysis. Language
mapping of concepts in the prohlem domain to software evolution in turn bas been a natural response to enhanced
units and their interfaces. Furthermore, it is felt by some architecture capahiiities and the increasingly sophis-
that based upon recent studies in psychology, viewing the ohject-oriented software development has followed this
world as ohjects is more natural since it is closer to tbe way general trend. Figure 1 depicts the many contributing
bumans tbink. Objects are more stable than functions; influences.
what most often precipitates software changes is change Perbaps the most significant influencing factors are the
in required functionality, not cbange in the players, or advances in programming methodology. Tbe support for
ohjects. In addition, object-oriented development supports abstraction in languages has progressed to higher levels.
894 OBIECT-ORIENTED DEVELOPMENT

structured languages database nor do they refer to the same concepts with consistent ver-
biage "across the board." Likewise there is no consensus on
structured analysis and design data driven
how to do object-oriented analysis and object-oriented
design nor the symbology to use in order to depict these
activities. Nevertheless, object-oriented development has
already proven successful in many application areas
advances m programming including: air traffic control, animation, banking, business
methodology data processing, command and control systems, computer-
aided design (CAD), computer integrated manufacturing,
databases, document preparation, expert systems, hyper-
object-oriented programming
media, image recognition, mathematical analysis, music
composition, operating systems, process control, rohotics,
space station software, telecommunications, telemetry
systems, user interface design, and VLSI (very large scale
integrated circuit) design.
Ob|ect-Orienled Development

OBIECT-ORIENTED PROGRAMMING
advances in cognitive science
Concepts
advances In computer architecture
Since the object-oriented programming efforts predate the
Figure 1. Influences in object-oriented development.
other object-oriented development techniques, it is reason-
able to focus first on object-oriented programming. In
object-oriented programming, programs are organized as
This abstraction progression has gone from address co-operating collections of objects, each of which is an
(machine languages), to name (assembly languages), to instance of some class and whose classes are all members
expression (first generation languages, e.g., FORTRAN}, of a hierarchy of classes united via inheritance relations
to control (second generation languages, e.g., COBOL) to (Booch, 1991). Object-oriented languages are character-
procedure and function (second and early third generation ized by the following: object-creation facility, message-
languages, e.g., Pascal), to modules and data (late third passing capability, class capability, and inheritance. While
generation languages, e.g, Modula 2), and finally to these concepts can and have been used individually in
ohjects (object-based and object-oriented languages). The other languages, they complement each other synergi-
development of Smalltalk and other object-oriented lan- stically in object-oriented languages.
guages as discussed above has necessitated the discovery Figure 2 illustrates the procedural programming mo-
of different analysis, and design techniques. del. To achieve functionality, arguments are passed to a
These new object-oriented techniques are really the cul- procedure and results are passed back. Object-oriented
mination of the structured and database approaches. In languages involve a change of perspective. As depicted in
the object-oriented approach, the smaller scale concerns Figure 3, functionality is achieved through communication
of data flow-orientation, like coupling and cohesion, are with the interface of an object. An object can be defined to
very relevant (Booch, 1992). Similarly, the behavior within be an entity that encapsulates state and behavior; that is,
objects of the object-oriented approach will ultimately data structures (or attributes) and operations. The inter-
require a function-oriented design approach. The ideas of face, also called the protocol, of the ohject is the set of mes-
the entity-relationship (ER) approach to data modeling sages to which it will respond. Messaging is the way
from the database technology are also embodied in the objects communicate and therefore the way that function-
object-oriented model. ality is achieved. Objects respond to the receipt of mes-
Likewise, advances in computer architecture, both in sages by either performing an internal operation, also
the increased capability combined with decrease in cost,
and in the introduction of objects into hardware (capability
systems and hardware support for operating systems con- Arguments in
cepts) have impacted the object-oriented movement.
Object-oriented programming languages are frequently
memory- and MlPS-intensive. They have required and
are now utilizing added hardware power. And finally, phi-
losophy and cognitive science have influenced the
advancement of the object-oriented model in their hierar-
chy and classification theories (Booch, 1991).
Because there are many and varied influences on
object-oriented development and because this approach
has not reached maturity, there is still considerable diver-
Results out
sity in thinking and terminology and unfortunately confu-
sion. All object-oriented languages are not created equal Figure 2. Procedural model.
 OBIECT-ORIENTED DEVELOPMENT 895

Interface

Figure 3. Object-oriented model.

sometimes called a method or routine, or by delegating the Figure 5. Inberitance.

operation to be performed by another object. All objects are
instances of classes, which are sets of objects with similar
characteristics or, from another viewpoint, a template sent to an object, the search for the corresponding metbod
from which new ohjects may be created. Tbe metbod begins in the class of tbe object and will progress up the
invoked by an object in response to a message is deter- superclass chain until such a metbod is found or until
mined by tbe class of tbis receiver object. All objects of a the chain bas been exhausted (wben an error would occur).
given class use the same metbod in response to similar In some languages it is possible for a given class to inberit
messages. Figure 4 shows a DOG class and objects instan- from more than one superclass. Tbis capability is called
tiated from tbe dog class. All the DOG objects respond in multiple inheritance.
tbe same way to the messages sit, bark, and roll. All When dynamic binding is present, inberitance results
DOG objects will also bave the same state (data struc- in polymorpbism. Polymorphism essentially describes
tures), although tbe values contained in what are typically the phenomenon that a given message sent to an object
called state variables can vary from DOG object to DOG will he interpreted differently at execution, based upon
object. subclass determination. Figure 6 illustrates a superclass
Classes can be arranged in a bierarchy. A suhclass will UNMEMBER witb its subclasses. If the message "speak"
inberit state and bebavior from its superclass higber in the is sent to an object, at execution time it will he determined
inberitance bierarchy structure. Inberitance can he wbere the appropriate speak method will be found based
defined as the transfer of a class' capabilities and charac- on the current subclass association of tbe object. Tbus
teristics to its subclasses. Figure 5 sbows a subclass the polymorphism means that tbe speak capahility will
DOBERMAN of tbe original DOG class. An ohject of the vary and in fact will be determined at execution. It is pos-
DOBERMAN class will have the hark, sit, and roll beba- sible for a method to not he actually defined in tbe super-
vior of the DOG class, but in addition, the kill hebavior class but still be included in the interface and hence be
particular to tbe DOBERMAN class. When a message is inberited by subclasses. One calls such a superclass an
abstract class. Abstract classes do not have instances
and are used only to create subclasses. For example,
UNMEMBER would be an abstract class if tbe method
for the message speak was not defined in UNMEMBER.
Including speak in tbe interface of UNMEMBER, bow-
ever, would dictate tbat speak would be a message com-
mon to all subclasses of UNMEMBER but the exact
speak behavior would vary witb each subclass. Ahstract
classes are used to capture commonality without deter-
mining idiosyncratic bebavior.

Languages

There are essentially four brancbes of object-oriented

languages: Smalltalk-based, C-based, LISP-based, and
Pascal-hased. Simula is actually the common ancestor of
all tbese languages. Tbe terminology and capability of
the object-oriented languages varies considerably. A sam-
pling of popular object-oriented languages in eacb hrancb
is given in Table 1. The Smalltalk-based languages include
tbe five versions, including Smalltalk 80, developed
Figure 4. Instantiation of ohjects from a class. at PARC, as well as Digitalk Smalltalk and other such
896 OBIECT-ORIENTED DEVELOPMENT

Figure 6. Polymorphism.

versions. Smalltalk 80 is considered the truest object- Pascal, developed by Borland, has followed the Object Pas-
oriented language although it and the others in this group cal lead. Eiffel has been released by Bertrand Meyer of
do not have multiple inheritance capability. Interactive Software Engineering, Inc. in 1987. Eiffel is a
In the C-based category are languages that are derived full object-oriented language that has an Ada-Hke syntax
from C. Objective-C was developed by Brad Cox, has an and operates in a UNIX environment.
extensive library and has been used successfully to build There are also languages that are referred to as object-
large systems (Saunders, 1989). C-I--I- was written by based. A sample of object-based languages appears in
Bjarne Stroustrup of AT&T Bell Labs. C's STRUCT con- Table 2. Object-based languages differ from object-
cept is extended in C-\--\- to provide class capability with oriented languages extensibly in their lack of inheritance
data hiding. Polymorphism is implemented by virtual capability. It should be noted that while Ada is object-
functions whieh deviate from the normal C typing that is based, its successor, Ada 95, 15 object-oriented (see ADA).
still resolved at compilation. C-I--I- version 2.0 includes
multiple inheritance. C-H-l- is a popular choice in many
software areas, especially those where UNIX is preferred. OBIECT-ORIENTED SOFTWARE ENGINEERING
James Gosling of Sun Microsystems designed Java. Java is
a strongly typed, object-oriented programming language Life Cycle
with emphasis on supporting distrihuted applications, While the object-oriented languages are exciting develop-
(see JAVA). ments, coding is not the primary source of problems in soft-
The many dialects including LOOPS, Flavors, Common ware development. Requirements and design problems are
LOOPS, and New Flavors, in the LISP-based branch have much more prevalent and much more costly to correct. The
been precipitated by knowledge representation research. focus on object-oriented development techniques, there-
Common LISP Object System (CLOS) has been an effort fore, should not be strictly on the programming aspects,
to standardize object-oriented LISP. The Pascal-based lan- but more appropriately on the other aspects of software
guages have included, among others. Object Pascal and engineering. The promise object-oriented methodologies
Turbo Pascal as well as Eiffel. Object Pascal has been hold for attacking complexity during analysis and design
developed by Apple and Niklaus Wirth for the Macintosh. and accomplishing analysis and design reuse, is truly signi-
The class library for Object Pascal is MacApp. Turbo ficant. If it is accepted that object-oriented development is
more than object-oriented coding, then a whole new app-
roach, including life cycle, must be adopted (Henderson-
Table 1. Object-Oriented Languages Sellers and Edwards, 1990).
Smalltalk 80
Objective C Table 2. Object-Based Languages
C++
Flavors XLISP Alphard
LOOPS CLU
CLOS Euclid
Object Pascal Gypsy
Turbo Pascal Mesa
Eiffel Modula
Java Ada
 OBIECT-ORIENTED DEVELOPMENT 897

Analysis

Specification

Design

Implementation

Testing

System
inte^ation

Maintenance

Figure 7. Waterfall life cycle.

The most widely accepted life cycle to date is the objects and their relationships are the medium of expression
waterfall/structured life cycle (Lorenz, 1993). The water- for each of analysis, design, and implementation. There is
fall organization has come into existence to stem the ad also a switch of effort from coding to analysis and an
hoc approaches which had led to the software crisis as it emphasis on data structure hefore function. Furthermore,
was first noted in the late 1960s. A version of the waterfall the iterative and seamless nature of object-oriented devel-
life cycle is pictured in Figure 7. As is shown, the process is opment makes the inclusion of reuse activities natural.
sequential; activitiesflowin primarily one direction. There
is little provision for change and the assumption is that the
system is quite clearly understood during the initial Object-Oriented Analysis (OOA) and
stages. Unfortunately, any software engineering effort Object-Oriented Design (OOD)
will inherently involve a great deal of iteration, whether Since object-oriented technology is still relatively new,
it is scheduled or not. Good designers have heen descrihed there is, as noted ahove, a number of approaches to
as practitioners who work at several levels of abstraction Ohject-Oriented Analysis and Design. Most of them use
and detail simultaneously (Curtis, 1989). The waterfall graphics representation models, whose idea was likely
life cycle does not accommodate real iteration. The water- inherited from structured methodologies. Object-oriented
fall/structured life cycle is also criticized for placing no analysis huilds on previous information modeling techni-
emphasis on reuse and no unifying model to integrate ques, and can be defined as a method of analysis that
the phases (Korson and McGregor, 1990). examines requirements from the perspective of the classes
The object-oriented approach admits and supports and objects found in the vocabulary of the prohlem domain.
iteration. Figure 8 illustrates a version of the water foun- Analysis activities yield black-hox objects which are
tain life cycle that has been used to describe the ohject- derived from the problem domain. Frameworks have
oriented development process. The fountain idea conveys become very useful in capturing an ohject-oriented analy-
that the development is inherently iterative and seamless. sis for a given problem domain and making is reusahle for
The same portion of the system is usually worked on a related applications. Basically a framework is a skeleton of
numher of times with functionality being added to the evol- an application or application subsystem implemented by
ving system with each iteration. Prototyping and feedback concrete and ahstract classes. In other words, a framework
loops are standard. The seamlessness is accounted for in is a specialization hierarchy with ahstract superclasses
the lack of distinct boundaries during the traditional activ- that depicts a given prohlem domain. One of the draw-
ities of analysis, design, and coding. The reason for remov- backs of all current ohject-oriented analysis techniques is
ing the boundaries is that the concept of ohject permeates; their universal lack of formality.
898 OBIECT-ORIENTED DEVELOPMENT

physical as well as static and dynamic models of the sys-

tem under design (Booch, 1991). OOD techniques have
actually been defined before OOA techniques had been
conceieved.
There is difficulty in identifying and characterizing cur-
rent OOA and OOD techniques because, as described
above, the boundaries between analysis and design activ-
ities in the object-oriented model are fuzzy. Given that pro-
blem, the following descriptions provide an overview to
some of the OOA and OOD techniques being used.
Meyer uses language as a vehicle for expressing design.
His approach is really not classifiable as an OOD tech-
nique (Meyer, 1988), Booch's OOD techniques extend his
previous Ada work. He advocates a "round-trip gestalt"
process during which: objects are identified, semantics of
the objects are identified, relationships are identified,
implementation is accomplished, and iteration occurs. He
Integrate uses class diagrams, class category diagrams, class tem-
plates, and object diagrams to record design (Booch,
1991). Wirfs-Brock's OOD technique is driven by delega-
tion of responsibilities. Class responsibility cards (CRCs)
are used to record classes responsible for specific function-
ality, and collaborators with the responsible classes. The
initial exploration of classes and responsibilities is fol-
Test lowed by detailed relationship analysis and implementa-
tion of subsystems (Wirfs-Brock et al., 1990). More
recently, the Unified Modeling Language (UML) has
been used within systems engineering to enable practi-
tioners to collaborate and address increasingly complex
problem. (See UNIFIED MODP:LING LANGUACK.)
Rumbaugh and co-workers (1991) use three kinds of
Code models to descrihe a system: the object model, which is a
static structure of the objects in a system; the dynamic
model, which describes the aspects of a system that change
over time; and the functional model, which describes the
data value transformations within a system. Object dia-
grams, state diagrams, and data flow diagrams are used
to represent the three models, respectively (Rumbaugh
et al., 1991). Similarly, Shlaer and Mellor (1988) use three
Design
models: the information model, the state model, and the
process model to perform OOA.
In their OOA technique, Coad and Yourdon (1991a,b)
advocate the following steps: find classes and objects, iden-
tify structures and relationships, determine subjects,
define attributes, and define services, to delineate a multi-
layer object-oriented model. The layers corresponds to the
Analysis steps, namely: class and object layer, subject layer, struc-
ture layer, attribute layer, and service layer, respectively.
Their OOD technique is hoth multilayer and multicompo-
nent. The layers are the same as in analysis. The compo-
nents include problem domain, human interaction, task
management, and data management.
There are also other puhlished OOA and OOD tech-
niques as well as variations of the ahove which are not
Figure 8. Water fountain life cycle for object-oriented software listed here.
development.
Management Issues
During object-oriented design the object focus shifts to
the solution domain. Object-oriented design is a method of As organizations begin to shift to object-oriented develop-
design encompassing the process of object-oriented decom- ment techniques, the management activities that support
position and a notation for depicting both logical and software development will also necessarily have to change.
 OBJECT-ORIENTED DEVELOPMENT 899

The seamless, iterative, prototyping nature of object- following reasons: traceability improvement, reduction in
oriented development eliminates traditional milestones. significant integration problems, improvement in concep-
New milestones will have to be established. Also, some of tual integrity of process and product, minimization of
the ways in which measurements were made seem less need for objectification and deobjectification, and maximi-
appropriate in an object-oriented context. LOC is defi- zation ofthe benefits of object-orientation (Berard, 1993).
nitely not helpful. Reuse measurements would be useful
as would number of class-to-class relationships. Most
work in object-oriented metrics is relatively new, but refer- FUTURE TRENDS
ences are beginning to surface (Lorenz, 1993).
Resource allocation needs to be reconsidered as does In summary, object-oriented development is a natural out-
team organization. Smaller development teams are sug- growth of previous approaches and has great promise for
gested (Booch, 1991), as is cultivation of reuse experts. software development in many application domains.
Incentives should be based on reuse, not LOC. A entirely Object-oriented development is not, however, a panacea
new mind set is required if reuse is to really be operative. and has not yet reached maturity. While the future of
Libraries and application frameworks have to be sup- object-oriented development cannot be defined, there
ported and built along with contracted application soft- have been predictions. It is likely that the movement will
ware. Long-term investment strategies are imperative. continue to gain in popularity, and techniques will mature
Regarding quality assurance, typical review and testing significantly as experience increases. Class libraries and
activities are still essential, but their timing and definition application frameworks will be readily available in the
must be changed. For example, a walkthrough could marketplace. Information access will be transparent
involve enacting a scenario of interacting objects proposed across applications and environments. Object orientation
to effect some specific functionality. Testing of ohject- will provide environments in which users can communi-
oriented systems is another area which is only recently cate among applications. Integrated object-oriented multi-
being formally addressed. Release in terms of a steady media tool kits will be available (Winblad et al,, 1990), It is
stream of prototypes requires a flavor of configuration also likely that object orientation will eventually be
management that differs from that that is being used to replaced or absorbed into an approach that deals at an
control products generated using structured techniques. even higher level of abstraction. Of course, these are just
Another management concern ought to be appropriate predictions. In the not-too-distant future, talk about
tool support. An object-oriented development environment objects will no doubt be passe, but for now there is much
is essential. Also needed are: a browser for class library, an information available to generate genuine enthusiasm.
incremental compiler, debuggers that know about class
and object semantics, graphics support for design and ana-
lysis notation and reference checking, configuration man- BIBLIOGRAPHY
agement and version control tools, and a database
application that functions as a class librarian. E. V. Berard, Essays on Object-Oriented Software Engineering,
Vol. 1, Prentice-Hall, Englewood Cliffs, NJ, 1993.
Estimates can also be problematic until there is an
G. Booch, "Object-Oriented Design," Ada Letters 1(3), 64-76
object-oriented development history to substantiate pro- (March-April 1982).
posed development estimates of resource and cost. Cost
G. Booch, Object-Oriented Design with Applications, Benjamin/
of current and future reuse must be factored into the equa-
tion. Finally, management must be aware of the risks Cummins, Redwood City, CA, 1991.
involved in moving to an object-oriented approach. Also T. Budd, An Introduction to Object-Oriented Programming,
there are potential performance risks such as: cost of mes- Addison-Wesiey, New York, 1991.
sage passing, explosion of message passing, class en- P. Coad and J. Nicola, Object-Oriented Programming, Prentice-
cumbrance, paging behavior, dynamic allocation and Hall, Englewood Cliffs, NJ, 1993.
destruction overhead. Tbere are also start-up risks includ- P. Coad and E. Yourdon, Object-Oriented Analysis, 2nd ed.,
ing: acquisition of appropriate tools, strategic and appro- Prentice-Hall, Englewood Cliffs, NJ, 1991a.
priate training, and development of class libraries (see P. Coad and E, Yourdon, Object-Oriented Design, Prentice-Hall,
RESOURCE ESTIMATION and RISK MANAGEMENT). Englewood Cliffs, NJ, 1991b.
B. J. Cox, Object-Oriented Programming: An Evolutionary
Approach, Addison-Wesley, Reading, MA, 1986.
B. Curtis, ... But You Have to Understand. This Isn't the Way We
OB)ECT-ORIENTED TRANSITION Develop Software at Our Company, MCC Technical Report No.
STP-203-89, Microelectronics and Computer Technology Cor-
There are documented success stories, but there are also poration, Austin, TX, 1989.
implicit recommendations. The transition has to progress A. Goldberg and P. Robson, Smalltalk-80: The Language and Its
through levels of absorption before assimilation into a soft- Implementation, Addison-Wesley, Reading, MA, 1983.
ware development organization actually occurs. This tran- B. Henderson-Sellers and J. M. Edwards, "The Object-Oriented
sition period can take considerable time. Training is Systems Life Cycle," Communications of the ACM, pp. 143-
essential. Pilot projects are recommended. Combinations 159 (September 1990).
of structured and object-oriented approaches are not T. Korson and J. McGregor, "Understanding Object-Oriented: A
recommended. There is growing evidence that success Unifying Paradigm," Communications ofthe ACM, pp. 41-60
requires a total ohject-oriented approach for at least the (September 1990).
900 OBIECT-ORIENTED LANGUAGES

M. Lorenz, Object-Oriented Software Development, Prentice-Hall, component to component relationship can be seen across
Englewood Cliffs, NJ, 1993. the artifacts of the system through requirements, design,
B. Meyer, Object-Oriented Software Construction, Prentice-Hall, coding, and testing. This increase in visibility at the earlier
Englewood Cliffs, NJ, 1988. phases of development has resulted in a greater desire for
D. Monarchi and G. Puhr, "A Research Typology for Object- and emphasis on metrics for measuring the products ofthe
Oriented Analysis and Design," Communications ofthe ACM, early phases, particularly 0 0 requirements and design.
pp. 3 5 ^ 7 (Sept. 1992).
R. Pressman, Software Engineering: A Practitioner's Approach,
3rd ed., McGraw-Hilt, New York, 1992. BRIEF HISTORY
J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Loren-
sen, Object-Oriented Modeling and Design, Prentice-Hall, Eng- Early metrics developed for 0 0 software were extensions
lewood Cliffs, NJ, 1991. of then-existing measures for the procedural paradigm.
S. Shlaer and S. J. Meilor, Object-Oriented Systems Analysis: For example, Morris's {1988) 0 0 metrics suite includes a
Modeling the World in Data, Yourdon Press/Prentice-Hall, method complexity based on McCabe's cyclomatic com-
Englewood Cliffs, NJ, 1988. plexity and a cohesion metric based on fan-in. Chidamber
A. L. Winhtad, S. D. Edwards, and D. R. King, Object-Oriented and Kemerer (1991, 1994) developed one ofthe first widely
Software, Addison-Wesley, Reading, MA, 1990. used metrics suites specific for 0 0 software. Their suite
R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object- consisted of size and structure measures: the number of
Oriented Software, Prentice-Hall, Englewood Cliffs, NJ, methods per class, the number of children, the inheritance
1990. depth of a class, noninheritance coupling with other
classes, the number of methods that a class invokes, and
LINDA M . NORTHROP a class lack of cohesion metric—a metric based on the num-
Software Engineering Institute ber of instance variables sbared across methods in a class.
Definitions from this suite were further refined by
Churcher and Shepperd (1995), who also developed a con-
OBJECT-ORIENTED LANGUAGES. See ceptual framework for 0 0 metrics based on an entity-rela-
OBJECT-ORIENTED PROGRAMMING; SMALLTALK.
tionship model. Other early work includes: Sheetz and
Tegarden (Sheetz et al., 1991) who claimed to measure sys-
tem complexity at the application, object, method and vari-
able level based on characteristics such as fan-in fan-out
OBJECT-ORIENTED MEASUREMENT
and polymorphism; Li and Henry (1993) who examined
OF SOFTWARE
the Chidamber and Kemerer metrics along with several
additional metrics they defined in a study to predict main-
INTRODUCTION tenance effort; Bieman (1992) who presented a set of
metrics to account for differing types of reuse in OO soft-
The 1990s saw an insurgence in the use of object-oriented ware as well as developed measures for cohesion of classes
(00) technologies. Along with this shift has been an (Bieman and Kang, 1995); and Ott (Ott and Bieman, 1998)
increase in the demand for metrics to aid in evaluating who developed measures for cohesion based on slices.
the processes and the products associated with these new
technologies. 0 0 measurement focuses primarily on those An extensive set of metrics tbat were developed and col-
metrics that have been specifically developed to be used lected through experience with commercially developed
with 0 0 technologies and products. 0 0 software were published by Lorenz and Kidd (1994).
This collection also included guidelines and uses for the
Many traditional metrics are paradigm neutral and, metrics presented, many of which are based on structure
therefore, can still be used in the 0 0 paradigm to answer attribute counts.
certain kinds of questions. As a trivial example, lines of
code is as valid a size metric in the 0 0 paradigm on vi-hich Metrics for encapsulation, inheritance, coupling and
to base an estimate ofthe amount of paper needed to print polymorphism were presented by Abreu (1995). Additional
out a software package as it is in the procedural paradigm. cohesion measures based on data definition and use inter-
New language constructs, however, imply significant dif- actions within a class (Briand et al., 1998) and coupling
ferences in 0 0 program structure. Thus, metrics specifi- measures based on interactions between classes were
cally developed for 0 0 technologies are often required. developed by Briand et al. (1999). Metrics for various types
In particular, measurements associated with classes and of polymorphism were proposed by Benlarbi and Melo
class structure take on significant importance in 0 0 pro- (1999J (see MEASUREMENT, and METRICS).
ducts. For example, measurements of reuse via class
inheritance are not found in traditional procedural para- CURRENT STATUS
digm metric sets.
Besides the change in language constructs, the 0 0 Current research efforts in 0 0 software measurement
development process frequently differs from traditional typically focus on one or more of
processes in several ways. Much greater emphasis is often
placed on more formal documentation during the early • Validation and Studies of Software Metrics. The
phases of development, such as the use of UML (Unified software measurement community's increased
Modeling Language); and a clearer, more direct understanding of measurement and measurement