1

Object-Oriented System Development:

Will the New Approach Solve Old Problems?
G. Engelsa and G. Kappelb
aDept. of Computer Science, Leiden University,

P.O. Box 9512, NL-2300 RA Leiden, The Netherlands

bDept. of Computer Science, University of Linz,

Altenbergerstr. 69, A-4040 Linz, Austria

Abstract
Object-oriented system development is wideley recognized as improving productivity
and reducing system maintenance costs. However, existing approaches have not su-
ciently addressed the following three questions which are equally important to users and
researchers. Firstly, what are the benets of object-oriented system development com-
pared to traditional approaches? Secondly, what are the essential features of an object-
oriented life cycle model to fulll the benets of object-oriented development? And thirdly,
what are the pitfalls of object-oriented development and how to cope with them? The
paper investigates answers to all three questions in concert.
Keyword Codes: D.1.5; D.2.1; D.2.10
Keywords: Programming Techniques, Object-oriented Programming; Software Enginee-
ring, Requirements/Specication; Software Engineering, Design
1. Introduction
Building quality systems has been the driving goal of all software engineering eorts
within the last two decades. Among the key qualities a system should support are main-
tainability, and reusability. Object-orientation is discussed as new paradigm which helps
in building such maintainable, and reusable systems. Object-oriented languages [9] and
development environments [6] go already a long way in providing support for building such
systems. But, for their own, they are not a panacea for building quality systems. They
have to be accompanied by a life cycle model which supports both reusability throughout
the whole life cycle and the development of open, i.e., maintainable systems.
Reusability of components requires that reusable components have been developed in the
rst place. Reusable components comprise analysis results, design results, and software
components. Thus, a life cycle model which supports reusability has to support the
development of reusable components, too [11].
The development of open systems necessitates the adaptability to changing require-
ments. Thus, a life cycle model for open system development has to treat maintenance
2

as integrated part of the whole development process [10].

In the following sections we introduce a life cycle model which fullls the above re-
quirements. We will uncover existing deciencies of the object-oriented approach, and
we'll point to future research directions. As a prerequisite for a deeper understanding
of object-oriented development, and to ensure acceptance of the new approach among
both developers and clients, the commonalities and dierences between structured and
object-oriented development as well as the benets of the object-oriented approach are
discussed beforehand.
2. From Structured Development to Object-Oriented Development
Structured development has undergone considerable changes since its early beginnings
in the seventies. At that time structured development did only take into account the
process perspective of a system [2]. Meanwhile, there exist several approaches to structu-
red development modeling the data perspective and the behavior perspective of a system
next to the process perspective (e.g., [5,12,13]). These three perspectives are also trea-
ted during object-oriented development. Thus, in the next subsection an evolutionary
transformation from structured to object-oriented development is exhibited.
2.1. Three Perspectives of a System
It is well-known, that there are three fundamental perspectives of a system, which are
data (with whom does something happen?), behavior (when does something happen?),
and process (what happens?) [8].
Structured development emphasizes the process perspective. It starts from the required
top most functionality of the system and continues top-down with functional decomposi-
tion. Data and functions accessing these data are independently analyzed, designed, and
implemented. Only in a second step, the events which drive the processes are analyzed.
The data perspective plays a minor role compared to the other two. Thus, the hit list
of the three system perspectives due to their priority in structured development is rst,
process, second, behavior(= events), and third, data.
Structured development for real-time systems emphasizes the behavior perspective. This
branch of structured development has evolved out of the necessity of modeling event-driven
systems, such as real-time systems and interactive systems. It starts out with the analysis
of events. In a second step, the data which is accessed in response to the events is modeled.
The process perspective plays a minor role compared to the other two. Thus, the hit list
of the three system perspectives is rst, behavior, second, data, and third, process.
Object-oriented development emphasizes the data, i.e., the object perspective. Only in
the very rst step, the system functionality has to be identied (similar to structured
development), as the user of a system asks for a certain system functionality. He or she
is not interested in objects per se! Afterwards, all development steps focus on objects.
During these steps, it is investigated which objects and which behavior of these objects
are involved to fulll a system functionality. The main dierence and at the same time
the main advantage compared to structured development is the following. The system
architecture based on structured development consists of a hierarchy of functions with
exactly one function at the top. Any changes to the system functionality might imply
severe changes to the system architecture. Contrary, the system architecture based on
 3

object-oriented development consists of a set of interacting objects. Changes to the system

functionality imply local changes to objects like changing existing operations or adding
new operations, but do not impair the underlying system architecture. Events control
the behavior of objects. If a message is sent to an object, i.e. an event is raised, the
object executes a corresponding operation in turn. Thus, the hit list of the three system
perspectives due to their priority in object-oriented development is rst, data, second,
behavior, and third, process.
Corresponding to the three perspectives, three modeling techniques have been used
in structured development. These are Entity/Relationship Diagrams for data modeling,
State Diagrams for behavior modeling, and Data Flow Diagrams for process modeling. All
three diagram techniques or dialects thereof are also used during object-oriented develop-
ment. Entity/Relationsip Diagrams are employed for modeling the structural information
of objects, and state diagrams for modeling the behavior, i.e. the possible life cycles of
objects. Finally, a Data Flow Diagram is used to specify the intrinsics of a single ope-
ration. In general, it will consist of calls to other operations on the same or on dierent
objects.
2.2. Benets of Object-Oriented Development
The main advantages of object-oriented development compared to structured develop-
ment can be summarized in the following three points.
1. encapsulation of data and functions into object classes
2. same concepts in analysis, design, and implementation
3. database view and application program view grow together
Concerning the rst point, encapsulation is one of the underlying principles of the
object-oriented paradigm. Due to the encapsulation of data and functions into object
classes some basic consistency constraints are insured, such as there does not exist any
function without corresponding data, which has to be insured manually in structured
development.
Concerning the second point, the object-oriented paradigm is used in all phases during
system development. Contrary to structured development, where there is a gap between
analysis and design, object-oriented analysis (OOA) and object-oriented design (OOD)
are based on the same concepts and modeling techniques. Yet, their aims are dierent.
The aim of OOA is to describe the problem domain in terms of an application model . This
is done by executing the following steps being essential for any object-oriented analysis
independent of a specic development method.
1.  identify the system functionality
 identify the involved objects
2.  identify the object classes
 identify the classes' exported operations to fulll the system functionality (=
suered interface of an object class)
4

Real World Problem

System Model of Solution Domain
- base objects OOA
- system objects
Appl. Model of Problem Domain
- problem domain objects
- user interface objects
- control objects OOD

Figure 1. Relationship between Analysis and Design (after [7])

3.  identify the properties of the object classes

 identify the life cycles of the object classes
4.  identify the partOf and isA relationships
 identify the operations required from other object classes to fulll the behavior
of a specic class (= required interface of an object class)
5.  identify associations between object classes
 identify coordination constraints between object classes
6.  identify subsystems of functional cohesive classes
The aim of OOD is to describe the solution domain in terms of a system model consi-
sting of the enhanced application model of OOA, enriched with architectural information
(concerning hardware platform and system software) and implementation specic infor-
mation (concerning performance restrictions and limited concepts in the implementation
environment). The input to OOD is the output of OOA plus implementation contraints.
The relationship between OOA and OOD is depicted in Figure 1. The system model
of OOD includes the application model of OOA, but in general is more. For example, the
data management component is part of the solution to some problem but not part of the
problem itself. A possible distinction between OOA and OOD is in terms of the objects
which are encountered during both phases. During OOA problem domain objects, user
interface objects, and control objects are specied [3]. Problem domain objects represent
real world objects and concepts of the problem domain, such as Client, Account, and
Contract of a banking system. Since the output of OOA is not only a domain analysis
but a high-level specication of the system to be developed, also user interface objects
and control objects are specied. User interface objects represent the look and feel of the
system to be developed, as it is perceived by the user. And control objects represent the
system to be developed itself. The operations of the control objects model the requested
system functionality. Whereas these three categories of objects are application dependent,
 5

base objects and system objects are application independent. They are used during
OOD to enhance the application model with implementation specic information. Base
objects represent basic functionality, such as basic data structures, numbers and predened
user interface objects. System objects represent system functionality of the underlying
hardware and system software, such as an interface to a database management system
and a debugger window.
Concerning the third and last point, the object-oriented paradigm is used both for pro-
gramming languages and for database systems. The problems of coupling programming
languages and database systems based on dierent modeling paradigms are well known
as impedance mismatch . This metaphor describes the problems caused by two dierent
paradigms, the programming language paradigm and the database paradigm. Whereas
traditional programming languages may be characterized as being procedural, supporting
record-at-a-time processing and complex structured data types, traditional (relational)
database systems can be characterized as being declarative, supporting set-at-a-time pro-
cessing, and simple data types. The object-oriented paradigm helps to overcome the
disadvantages of working with two dierent worlds. The data model of an object-oriented
database system is based on similar concepts as the semantic model underlying an object-
oriented programming language. The schema of an object-oriented database system con-
sists of a set of objects which are developed in terms of the same analysis and design
concepts as object-oriented systems in general. The seaming schism between database
view and application program view is resolved due to the same underlying object-oriented
modeling paradigm.

3. Object-Oriented Life Cycle Model

We already stated the most important requirements an object-oriented life cycle model
should fulll. These are, rstly, the support of evolutionary software development , i.e.,
the maintenance phase is an integrated part of this evolution - the rst product version
which is shipped to the customer is at the same time the rst maintenance version. And
secondly, the development of reusable components as necessary prerequisite for providing
reusability throughout all development phases. An additional requirement tightly coupled
to the previous one concerns the bootstrap problem of development with reusability. Since
it may happen that there are no reusable components the life cycle model should support
application development with various degrees of reusability .
The state of practice in terms of reusability is focused on reusable class libraries. A
class library consists of a set of independent classes, implemented in some object-oriented
programming language and providing some basic functionality, such as basic data struc-
tures. However, the goal of object-oriented development with reusability is to extend this
reuse in the small to a reuse in the large . For the latter, two extensions to class libraries
are necessary. Firstly, not only single classes but a set of classes that embodies an ab-
stract design for solutions to a family of related problems should be reused. This set of
classes is called an application framework [4]. And secondly, not only code but analysis
documents and design documents should be reused. Thus, an application framework for
some problem domain should embody the output of all development phases.
Subsequently, an object-oriented life cycle model following the above requirements is
6
Problem Statement Problem Statement
Product Db 3 Framework Db
1 2
Analysis Analysis

Design Design

Implementation Implementation

4 rk
e wo t
m en
Fra lopm
ve
De

Figure 2. Life cycle model for object-oriented development

introduced. The model distinguishes two kinds of development cycles, one for the deve-
lopment of specic projects and the other for the development of reusable components.
For the former, again three dierent development cycles are oered depending on the
degree of reusability. Each development cycle consists of three phases, namely analysis,
design, and implementation, which are iteratively processed. However, the life cycle mo-
del does not constrain the underlying development method in terms of which steps have
to be processed and which outputs produced. To this extent the life cycle model is also a
generic life cycle model.
Figure 2 depicts the four kinds of development cycles of the object-oriented life cycle
model. During Development from Scratch (1) the object classes of the application at hand
are developed from scratch. Descriptions of these classes resulting from analysis, design
and implementation are stored as analysis results, design results, and implementation
results, respectively, in a conguration management system, called product database. The
information stored in the product database serves two purposes. Firstly, it is used for the
development of reusable components (see (4) below), and secondly, it eases the iterative
processing of the various phases. Since the feedback loops from implementation to design
and from design to analysis should be taken with care they are depicted with dashed lines.
During Development through Reuse (2) the object classes of the application at hand are
all constructed from reusable components of a repository, called framework database . If
no component with the required behavior is found in the database the specication of the
system has to be slightly modied to t existing components or the development has to
switch to Development with Reuse (see (3) below). Note that reuse covers all development
phases.
During Development with Reuse (3) the object classes of the application at hand are
looked up in the framework database. If no components proper for the current problem
can be found, the object classes are newly developed. The results of development with
 7

reuse are stored in the product database. Note that development with reuse describes
the current state of practice. However, on the long run we should go for development
through reuse. As a prerequisite for both (2) and (3) we have to stock the framework
database. Thus, during Development of Reusable Components (4) precursor applications
of a particular problem domain stored in the product database are analyzed and/or general
domain analysis of this problem domain is performed. As a result, application frameworks,
i.e. reusable components for the inspected problem domain are developed and stored in
the framework database.
Development based on reusability has impacts on the project organization of an enter-
prise. There are at least two new job proles necessary to put into practice the life cycle
model of Figure 2. Firstly, there must be a reuse promotor who motivates members of a
particular project to reuse existing components. And secondly, there must exist a project
independent reuse administrator responsible for stocking the framework database. The
latter task is also known as experience factory in the literature [1].

4. Object-Oriented Development Revisited

Object-oriented development is on its way to fulll its promises, namely improving
productivity and reducing maintenance costs. However, it has to overcome two obstacles,
one technical by nature and one organisational, to prove success in the large.
The technical obstacle has two reasons. Firstly , we have stated previously that a main
advantage of object-oriented development is due to the same concepts employed in all
development phases. This is true and false at the same time. On one hand, it is true that
the main concern in all development phases are communicating objects and how they have
to interact to fulll the required system functionality. On the other hand, some of the
concepts of object-oriented analysis methods and object-oriented programming languages
comprise subtle yet severe dierences. Examples are the use of multiple inheritance during
analysis and single inheritance during implementation, and the use of associations during
the former and inverse references during the latter, to mention just a few. And secondly ,
the almost exclusive concentration on the concept of an \object" forces that everything
has to be expressed in terms of encapsulated objects. However, there are situations which
demand further concepts, too. For example, complex symmetric operations involving
several object classes should be modeled independently of a particular object class. In
today's object-oriented systems each operation has to be assigned to a single object class.
Another example concerns the modeling of local object behavior versus the modeling of
global system behavior. Whereas the former comprises the possible life cycles of objects
the latter should be stated in a exible manner, for example in terms of production rules.
In today's object-oriented systems both local object behavior and global system behavior
are modeled in terms of objects. A last example concerns the information hiding aspect of
objects. To be able to decrease the complexity of an object-oriented system it is necessary
to resolve the coupling between objects beforehand. This can be done easily if the required
interface, i.e., the operations used from other object classes, is part of the public visible
interface of objects. In today's object-oriented systems the information hiding principle
prohibits required interfaces of objects next to suered interfaces.
The organisational obstacle is due to a lack of new project management principles. If
8

reuse in the large is more than just a lip service the following organisational principles have
to be taken seriously. Firstly, object-oriented development is development by investment .
Reusable components have to be developed although no client will pay the initial costs of
component development. Secondly, object-oriented development has to go for a no-not-
invented-here syndrom . The developers have to be motivated to reuse existing components
despite the extra work to learn the contents of the framework database. And thirdly, new
metrics like the lines-of-reused-code metric are necessary to take reusability into account.
We conjecture that the above mentioned obstacles are resolved in the not-so-distant
future, thus making object-oriented development a real alternative for building quality
systems.
Acknowledgements
Thanks to Jan Overbeck and Michael Schre , who contributed to the development of the
object-oriented life cycle model, and to Stefan Rausch-Schott and Werner Retschitzegger
for helpful comments on earlier drafts of the paper.
REFERENCES
1. V. Basili, The Experience Factory and its Relationship to Other Improvement Para-
digms. In I. Sommerville, M. Paul (eds.): Software Engineering (ESEC'93), Springer,
LNCS 717, 1993, 68-83.
2. T. DeMarco, Structured Analysis and Systems Specication, Prentice-Hall, 1979.
3. I. Jacobson, Object-oriented Software Engineering, Addison-Wesley, 1992.
4. R.E. Johnson, A B. Foote, Designing reusable classes, Journal of Object-Oriented
Programming (JOOP), Vol. 1, No. 2, 1988, 22-35.
5. J. Martin, Information Engineering, Prentice Hall, 1990.
6. B. Meyer, Tools for the New Culture: Lessons from the Design of the Eiel Class
Library, Communications of the ACM, Vol. 33, No. 9, 1990, 68-88.
7. D.E. Monarchi, G.I. Puhr, A Research Typology for Object-Oriented Analysis and
Design, Communications of the ACM, Vol. 35, No. 9, 1992, 35-47.
8. T.W. Olle, J. Hagelstein, I.G. Macdonald, C. Rolland, H.G. Sol, F.J.M. Van Assche,
A.A. Verrijn-Stuart, Information Systems Methodologies: A Framework for Under-
standing, 2nd edition, Addison-Wesley, 1991.
9. O.M. Nierstrasz, A Survey of Object-Oriented Concepts. In W. Kim, F. Lochovsky
(eds.): Object-Oriented Concepts, Databases and Applications, ACM Press and
Addison-Wesley, 1989.
10. D. Tsichritzis, Object-Oriented Development for Open Systems. In G.X. Ritter(ed.):
Information Processing 89 - IFIP World Computer Congress, North-Holland, 1989,
1033-1040.
11. D.C. Tsichritzis, O. Nierstrasz, S. Gibbs, Beyond Objects: Objects, International
Journal of Intelligent and Cooperative Information Systems, Vol. 1, No. 1, 1992.
12. P.T. Ward, S. Mellor, Structured Development for Real-time Systems, Prentice-Hall,
1985.
13. E. Yourdon, Modern Structured Analysis, Prentice Hall, 1989.