0bj ect - 0r ient ed System DeveIo pment

Methods

ALAN R. HEVNER
Information Systems Department and
Systems Research Center
College of Business and Management
University of Maryland
College Park, Maryland

I . Object-Oriented Concepts . . . . . . . . . . . . . . . 135

1.1 Theobject . . . . . . . . . . . . . . . . . . 136
1.2 Object-Oriented Principles . . . . . . . . . . . . . . 139
1.3 System Development Background . . . . . . . . . . . . 142
2. Object-Oriented System Development Methods . . . . . . . . . 146
2.1 Object-Oriented System Life Cycle . . . . . . . . . . . 146
2.2 Object-Oriented Analysis . . . . . . . . . . . . . . 150
2.3 Object-Oriented Design. . . . . . . . . . . . . . . 153
2.4 Object-Oriented Implementation and Testing . . . . . . . . 157
2.5 Critique of Current OOSD. . . . . . . . . . . . . . 158
3. Object-Oriented System Development with Box Structures . . . . . . 160
3.1 Box Structure Overview . . . . . . . . . . . . . . 161
3.2 The Mathematical Foundations of Box Structures . . . . . . . 162
3.3 Box Structure Principles . . . . . . . . . . . . . . 165
3.4 Box Structures as Objects . . . . . . . . . . . . . . 167
4. The Cleanroom System Development Process . . . . . . . . . . 170
4.1 Cleanroom Concepts . . . . . . . . . . . . . . . 170
4.2 OOA and OOD with Box Structures . . . . . . . . . . . 172
4.3 Critique of Box Structure Methods . . . . . . . . . . . 176
5 . Conclusions and Future Research Directions . . . . . . . . . . 177
Acknowledgments. . . . . . . . . . . . . . . . . . 180
References . . . . . . . . . . . . . . . . . . . . 180
Appendix: A Case Study of Box Structured Design-The CARS System . . 184

1. Object-Oriented Concepts
Information systems have been successfully (and unsuccessfully) devel-
oped for centuries. The advent of the computer revolutionized the develop-
ment of information systems, making computer-based information systems
(CBIS) essential components of our lives. Numerous methods, techniques,
and tools for building systems have been developed since the beginning of
the computer era to support the tremendous demand for CBIS in business
135 Copyright 0 1992 by Academic Press, Inc.
All rights of reproduction in any form reserved.
ADVANCES IN COMPUTERS, VOL. 35 ISBN 0-12-012 135-2
136 A. R. HEVNER

and industry. The recent trend of viewing systems as collections of identifi-

able, interacting objects has the potential to initiate a new revolution in
information system development.
Object-orientation provides a different perspective from the traditional
descriptive view of a system as processes, data flows, and control flows.
Object-oriented system development offers to radically change the manner
in which information systems are analyzed, designed, and implemented. The
objectives of this chapter are to explain what is meant by object-orientation,
to survey current methods of object-oriented system development, and to
present an integrated methodology for performing object-oriented system
development. In the remainder of this section, we define objects and explain
object-oriented concepts as a basis for understanding the object-oriented
system development methods described later in the chapter.

1.1 The Object

What is an object? A dictionary defines an object as simply “something
perceptible.” Humans have a cognitive ability to perceive both tangible
objects (i.e., appealing to the senses of touch, sight, hearing, and taste; for
example, a table or an airplane) and intangible objects (i.e., mental con-
structs; for example, a mathematical equation or a chemical process). It is
a naturalistic viewpoint to conjecture that humans view reality through
objects and relationships among objects. It is this viewpoint that allows
adherents of object-orientation to claim that it is the most natural way for
humans to develop systems.
The following object definitions use widely accepted terms for basic con-
cepts. However, the reader should be prepared to encounter many different
terms for the same concepts throughout the object-oriented literature. A
good definition of an object comes from Booch (1991). He defines an object
as having state, behavior, and identity:

0 The state of an object is defined by the (usually static) properties (or

attributes) of the object plus the current (usually dynamic) values of
each of these properties.
0 The behavior of an object is how the object acts and reacts in its environ-
ment. Object behavior is based on accepting stimuli from the environ-
ment and producing internal state changes and responses to the
environment. Behavior is typically defined by a set of specific methods
within the object.
0 The identity is that inherent property of an object that distinguishes it
from all other objects.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 137

Objects are grouped into classes based upon common state structures and
common behaviors. For example, all individual car objects can be grouped
into the car class. Further, lower-level classes (i.e., subclasses) can be grouped
into higher-level classes (i.e., superclusses). For example, cars and trucks can
be grouped into a wheeled-vehicle class. Such relationships among classes
are defined by inheritance hierarchies. (Note that a node in an inheritance
hierarchy can be either a class or an object at the leaf nodes. In the remainder
of the chapter, we use the term object-class to refer to an arbitrary node in an
inheritance hierarchy.) A simple example can help explain these definitions.
The description of a class for a generic tennis racquet is shown in Fig. 1.
(A straightforward representation of objects and classes is used for this
example. More detailed representations are discussed in later sections.)
The properties that describe a generic tennis racquet are listed. Further
development would design appropriate structures (e.g., simple and complex
data structures) for each property. Necessary behaviors are also listed with
the procedural design details to be added later as a system design is
completed.
A sample inheritance hierarchy that includes the tennis racquet class is
shown in Fig. 2. Note the grouping of subclasses (i.e., children in the hierar-
chy) into superclasses (i.e., parents in the hierarchy). This grouping repre-
sents one of three types of relationships among classes:
Generalization. Lower-level concepts generalize into a higher-level con-
cept. Such relationships can be termed isa or kind of relationships. For
example, collies, poodles, and terriers are all kinds of dogs (i.e., a collie

CLASS: TENNIS-R ACQUET

SUPERCLASSES: TENNIS-EQUIPMENT, STRING-RACQUETS
SUBCLASSES: BILL'S-RACQU ETS, JOE'S-RACQUETS, ...
WILSON-RACQUETS, HEAD-RACQUETS, ...

PROPERTIES:
MANUFACTURER, MODEL, DIMENSIONS,HITTING-AREA,
WEIGHT, BALANCE, STRING-TENSION, STRING-PATTERN,
STIFFNESS, MATERIALS, GRIP-SIZE
BEHAVIORS:
CONSTRUCT
RESTRING
MODIFY-FRAME
MODIFY-GRIP
DESTROY
FIG. 1. Tennis racquet class.
138 A. R. HEVNER

TENNIS- TENNIS- TENNIS- TENNIS-

COURTS RACQUETS CLOTHING BALLS
CLASS CLASS CLASS CLASS

FIG.2. Tennis racquet inheritance hierarchy.

is a dog). In Fig. 2, JOE’S-RACQUETS and BILL’S-RACQUETS are grouped

(generalized) in the superclass TENNIS-RACQUETS.
Aggregation. Lower-level concepts aggregate as parts of a higher-level
concept, These relationships can be termed part of relationships. In
Fig. 2, the superclass TENNIS-EQUIPMENT is made up of subclasses
TENNIS-COURTS, TENNIS-CLOTHES, TENNIS-RACQUETS, and TENNIS-
BALLS.
Association. Lower-level concepts are associated in a higher-level concept
based on some meaningful semantic connection. For example, baseball
and apple pie are associated as symbols of American life.

A subclass or an object at the leaf of the hierarchy inherits all properties

and behaviors of its ancestor superclasses. In addition, the subclass or object
can define new properties and behaviors unique to that level of the hierarchy.
Thus, Bill can define properties and behaviors unique to his collection of
racquets (e.g., BILL‘S-RACQUETS subclass) and to each of his racquets
individually (e.g., BILL’S-RACQUET # 1 object). For example, Bill can define
properties PURCHASE-DATE, RETIRE-DATE, and COMMENTS with behaviors
PURCHASE, RETIRE, and EVALUATE to the BILL’S-RACQUETS subclass. Then
each tennis racquet object would inherit properties and behaviors from both
SUpe~ClaSSeSTENNIS-RACQUET and BILL’S-RACQUETS.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 139

Objects and classes can participate in as many inheritance hierarchies as

are needed in a system. Thus, an object may have multiple inheritance of
properties and behaviors from several hierarchies.
A principal gap in the current state-of-the-art of object-orientation is that
no formal, mathematical definition of an object is widely accepted. Objects
share many of the same fundamental concepts (e.g., encapsulated state and
defined behavior) as abstract data types (ADTs). Formal theories of ADTs
have been developed by researchers such as Guttag (1980) and Liskov et al.
(1977). However, ADTs are not flexible enough to capture all aspects of
inheritance among object classes (Danforth and Tomlinson, 1988). Thus,
research remains on-going to discover a complete and sound mathematical
definition of an object.

1.2 Object-Oriented Principles

Object-oriented system development emphasizes a number of essential
principles. These principles provide important guidance for the construction
of objects, classes, and class relationships into a system object model. Collec-
tions of object-oriented principles are presented and analyzed in Korson and
McGregor (1990), Booch (1991), Coad and Yourdon (1991), and Rum-
baugh et al. (1991). In many cases these principles are extensions of well-
known software engineering and computer programming principles as
applied to object-oriented system development. Here, the most important of
these object-oriented principles are surveyed.

I . 2.1 Abstraction
Abstraction is the human cognitive ability to concentrate on the relevant
aspects of an object while ignoring nonrelevant aspects. Shaw (1984)
describes a system abstraction as “a simplified description, or specification,
of a system that emphasizes some of the system’s details or properties while
suppressing others. A good abstraction is one that emphasizes details that
are significant to the reader or user and suppresses details that are, at least
for the moment, immaterial or diversionary.”
Abstraction is essential in order to deal with the complexity of systems.
Attempting to specify all details of even a small system quickly results in
confusion and loss of perspective. Thus, an experienced system developer
will model system components (e.g., objects) at high levels of abstraction in
order to establish component boundaries and essential behaviors. As the
development proceeds and system requirements are better understood, the
system component is fleshed out with design details at lower levels of
abstraction.
 A. R. HEVNER

1.2.2 Modularity
Complex systems are divided into modules in order to gain intellectual
control of the development (Gannon, Hamlet, and Mills, 1987). Each mod-
ule should represent a single meaningful abstraction in the system domain.
A module is defined by its internal design and its interfaces to the other
modules in the system. An important goal is for each module to be developed
and maintained independently from the other modules in the system (Parnas,
Clements, and Weiss, 1985).
The selection of system modules is a critical development activity.
Attempts at measuring the “goodness” of a module have identified the char-
acteristics of cohesiveness and coupling. A highly cohesive module “sticks
together” the state and behavior of a single, meaningful system abstraction.
A loosely coupled module is highly independent of other modules. All com-
munication among modules is strictly defined in module interfaces. Guide-
lines for achieving highly cohesive and loosely coupled system modules for
traditional software engineering approaches have been around for a number
of years (e.g., Parnas, 1972). Object-oriented approaches present unique
opportunities for defining modules in terms of objects and classes.

1.2.3 Encapsulation
Encapsulation hides the internal details of a module implementation.
These internal details would include data designs for state and procedural
designs for behavior. A user of the module is not aware of the internal
designs of the module, only the visible module interfaces. This principle is
also known as information hiding. Encapsulation supports effective mainten-
ance and evolution of the module. For example, the internal design of the
module can be enhanced and improved without effecting the use of the
module through existing interfaces.

1.2.4 Hierarchy
It is not enough just to “divide and conquer” a complex system through
abstraction, modularity, and encapsulation. We must “divide, connect, and
conquer” to gain true intellectual control of system development. The ability
to connect the different levels of system abstractions within modules is essen-
tial. Hierarchies have been used effectively to describe system models in most
software engineering methods. In particular, the foundation of structured
programming is based on the insight that any program can be defined as a
strict hierarchy of mathematical functions (Mills 1986).
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 141

The development of system hierarchies can be performed via bottom-up

composition or top-down decomposition. Both of these techniques are very
useful at different stages of system development. Top-down decomposition
supports the division of a high-level system abstraction into several lower-
level abstractions. The connection of the simpler abstractions to provide the
state and behavior of the original complex abstraction must be defined in
the hierarchy. Bottom-up composition connects lower-level abstractions into
a high-level abstraction. For example, two objects and their interactions are
combined to form a higher level system component.
A system is specified by one or more hierarchies. We will see that different
types and forms of system hierarchies distinguish different system develop-
ment methodologies.

7.2.5 Implementation Principles

The preceding four principles are essential characteristics of object-orien-
ted system development methods. Booch ( 1991) describes abstraction,
encapsulation, modularity, and hierarchy as the four major elements of the
object model. He states that without support for these elements, a model is
not object oriented. In addition to these basic principles, other object-orien-
ted system development principles have been proposed. Most of these
additional principles address implementation issues of the object concept.
Object-oriented programming languages vary as to the degree of support
they provide for these principles. Briefly, these include
Typing. The concept of typing comes from programming languages where
variables are typed as defined data structures, such as integer, real, or
record types. Abstract data types include both structural and behavioral
components. Typing can be extended to objects through the object class.
Strong typing in a language checks that the object exhibits only the state
structures and behaviors defined for that class; while weak typing does
not require adherence to the class definition. While some object-oriented
languages allow weak typing for its flexibility and performance benefits,
the dangers of misusing objects are significant.
Dynamic Binding. Static binding means that all variables are bound to
types at compilation time. Dynamic binding waits until execution time
before binding variables to types. An advantage to dynamic binding is
that a variable may represent one of many different objects from different
classes. For any execution, a specific class-object is assigned to the variable
under strong typing.
Polymorphism. A variable that can potentially represent more than one
class of object is polymorphic. The use of polymorphism provides a
142 A. R. HEVNER

powerful and flexible capability to object-oriented programming lan-

guages (Cardelli.and Wegner, 1985).
Multiple Inheritance. Multiple inheritance allows a subclass and an object
to inherit properties and behaviors from more than one inheritance hierar-
chy. Again, this is a powerful capability of some object-oriented languages.
Potential naming conflicts must be resolved by a language that allows
multiple inheritance.
Persistence. Requirements for the persistence of information are prevalent
in system development. In traditional programs, databases and files are
maintained outside of the program in persistent state. Likewise, objects
and classes are required to be persistent in many object-oriented systems.
This has led to the demand for object-oriented database systems, as
discussed later in Section 1.3.2.
Concurrent and Real-Time Behavior. In order to model the behavior of
real systems, it is necessary to model, design, and implement concurrent
and real-time activities. This is an area of much interest and research
activity (SIGPLAN Notices, 1989). In particular, the problems of model-
ing multiple active objects and then implementing these objects on multiple
processors are challenging ones.

1.3 System Development Background

Armed with a basic understanding of object-oriented concepts, principles,
and terminology, we can now survey the background of research and practice
in the object-oriented field.
The first applications of object-oriented concepts in computer-based sys-
tems can be found in capability-based hardware architectures (Ramamoor-
thy and Sheu, 1988). Experimentation with object-oriented operating
systems quickly followed. The seminal research project was Dijkstra’s devel-
opment of the THE multiprogramming operating system in the 1960s (Dijk-
stra, 1968). Over the years a number of innovative computer hardware
and software architectures have been developed based on object concepts.
However, the use of objects for computer-based system development did not
occur until the introduction of object-oriented programming languages that
could run on generally available, non-object-oriented computers.

1.3.I Object- Oriented Programming (OOP)

The concepts of object and class were first present in the simulation lan-
guage Simula-67. Experience with Simula had an important influence on the
breakthrough research and development performed at Xerox PARC on the
Smalltalk language during the 1970s. Smalltalk is a pure object-oriented
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 143

language in that everything is treated as an object and objects can only

communicate via message passing. The current version of the language,
Smalltalk-80, includes a customized software development environment that
emphasizes graphic user interfaces (Goldberg and Robson, 1989). Smalltalk
was clearly a language that was ahead of its time and its early application
to complex system development was limited by its uniqueness.
Throughout the 1970s and into the 1980s, the structured programming
revolution promoted the development and use of languages such as Pascal
and C, as well as structured versions of COBOL and FORTRAN, for system
development. While system development projects in business and industry
assimilated the lessons of structured programming, several research and
development projects experimented with the object-oriented concepts of
abstract data types, encapsulation, and inheritance. Languages, such as
CLU, Euclid, Mesa, and Modula, with varying features of object orientation
were developed. The lessons learned in developing small- to medium-sized
systems with these languages were invaluable contributions to the current
generation of OOP languages.
The currently popular OOP languages have combined the advantages of
structured programming with the innovative concepts of object orientation.
C++ and Objective C are enhanced versions of C with object-oriented fea-
tures. The augmentation of Pascal with object-oriented concepts has resulted
in the languages Object Pascal, Eiffel, and Ada. Even the artificial intelligence
language Lisp has object-oriented versions in the languages LOOPS and
CLOS. The details of these OOP languages are beyond the scope of this
chapter. Comprehensive surveys of OOP can be found in Cox ( 1986),Shriver
and Wegner (1987), Stroustrup (1988), and Wegner (1990).
While many other programming languages may claim some elements of
object orientation, only languages that fully support objects, classes, inheri-
tance hierarchies, and the object-oriented principles of abstraction, modu-
larity, encapsulation, and hierarchy are considered fully object-oriented
programming languages (Cardelli and Wegner, 1985; Stroustrup, 1988;
Booch, 1991). All of the languages in the preceding paragraph are considered
object-oriented, with the exception of Ada. Ada is termed an object-based
language because of its support for object and classes. However, Ada, in its
current version, does not directly support inheritance hierarchies. Excellent
surveys of how well the different OOP languages support object-oriented
concepts and principles can be found in Booch (1991) and Rumbauch et al.
(1991).

1.3.2 Object- Oriented Database Systems

As OOP languages evolved into serious contention for complex system
development, questions of object and class persistence came to the fore. Real
144 A. R. HEVN-ER

systems require large, shared, persistent storage; as well as, facilities for
object-class organization, efficient manipulation (e.g., querying, retrieval,
and updating), concurrency control, and recovery. Database systems provide
these capabilities for the storage of data in traditional systems development.
What new requirements are needed for object-oriented database systems
(OODBS)?
The unit of storage in the OODBS is the object-class. This requires that
encapsulated combinations of data and methods (i.e., procedures) must be
managed as an integral unit. The goal of the OODBS is to provide logical
and physical independence of the objects to the application object-oriented
programs that form systems. Thus, multiple systems can query, retrieve, and
utkdate objects concurrently and independently while the OODBS manages
all -letails of object consistency, currency, security, recovery, and integrity
(Hughes 1991). Since multiple systems share the OODBS, communication
among applications through objects is provided.
We can identify four basic requirements of OODBS beyond conventional
database systems :

1. An OODBS must support the concept of object identity. The object

must be identifiable independent of properties and property values.
Typically, this is done by the system generating a system-wide object
identifier.
2. An OODBS must support user-dejined data structures and methods.
Objects and classes should not be constrained to a few built-in data
types and operations (e.g., relations and relational operators).
3. An OODBS must support inheritance hierarchies. Efficient techniques
for enabling inheritance among classes and objects is critical to OODBS
performance.
4. An OODBS must support object relationships. While some might argue
that relationships among objects should be wholly within application
programs, system efficiency can be gained by providing means to estab-
lish well-known relationships in the OODBS. Relationships in OODBS
are typically implemented with object pointers rather than associative
properties requiring joins, as is done in relational databases.

It is clear from these requirements that conventional relational database

systems are ill-suited to directly support objects and classes. Some research
on extending existing relational databases to support user-defined data types,
“long field” data types, and new access methods has been performed (Stone-
braker, 1986; Lehman and Lindsay, 1989). Further, a considerable amount
of research and development in the 1980s went into extensible database
systems (e.g., EXODUS [Carey et al., 19861, GENESIS [Batory et al.,
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 145

19881). In order to provide maximum extensibility to many application

domains, the majority of these systems employ a relational database system
kernel upon which are built facilities to support many different data types,
access methods, reasoning methods, and other capabilities. Many object-
oriented adherents, however, would say the relational data model concepts
are incompatible with object-oriented concepts, and thus, OODBS should
be built from scratch and not “on top of” relational database systems. A
thorough comparison and evaluation of OODBS and extended relational
database systems is found in (Manola, 1989).
The first comprehensive OODBS are being developed commercially and
in research (see Banerjee et al., 1987; Fishman et al., 1987). Typically these
systems are closely related to specific application domains (e.g., computer-
aided design [CAD], computer aided systems engineering [CASE]) and archi-
tectural environments (e.g., specific hardware and software bases). A few of
the better known systems that have resulted from OODBS research and
development include
Gemstone from Servio Logic Development Corporation,
Iris from Hewlett-Packard Laboratories,
O2 from GIP Altair,
OBJECT-BASE from OBJECT-Sciences Corporation,
Objectstore from Object Design, Inc.,
Ontos from Ontologic,
ORION from Artemis.
Again, it is beyond the scope of this chapter to describe the details of these
OODBS. More complete presentations of current OODBS concepts and
implementationscan be found in (Kim and Lochovsky, 1989; Manola, 1989;
IEEE TKDE, 1990; Kim, 1990; Hughes, 1991).

1.3.3 System Development Methods

The research and development activities in OOP and OODBS provide a
solid basis for the development of complex systems with object-orientea
concepts and principles. Just as new languages and new database systems
are needed for object support, it is clear that new object-oriented paradigms
are needed for system development. Thus, the late 1980s has seen important
research and development on methods and tools for object-oriented systems
development (OOSD). Section 2 presents a thorough survey of current
OOSD methods.
Conventional paradigms for information system development can be
described as either process oriented or data oriented. The development of
process-oriented methods was strongly influenced by the sequential flow
146 A. R. HEVNER

of computation supported by traditional programming languages, such as

COBOL and FORTRAN. The focus of system development under this para-
digm is to identify the principal processes (or functions) of the system and
the data flows among these processes. Persistent data stores are identified
and data flows between processes and data stores are also recorded. System
processes are hierarchically decomposed into more detailed descriptions of
processes and data flows. Then, after sufficient description and analysis, the
resulting processes and data stores are designed and implemented as system
modules with input-output interfaces to data stores and the external system
environment. Primary examples of process-oriented system development
methods include structured analysis and structured design (Yourdon, 1989)
and the Jackson system development (Cameron, 1989).
Data-oriented system development places the primary focus on the
required system data. This data-centric paradigm is based on the importance
of data files and data bases in large business and industrial applications.
System data models are developed and analyzed. System processes are
designed to support the data processing requirements of the application. The
design and implementation of the application system is constructed around
the database system and file systems. Primary examples of data-oriented
system development methods include Warnier-Orr systems development
(Orr, 1977) and information engineering (Martin, 1989).
In contrast to the conventional approaches, object-oriented system devel-
opment methods focus primary attention on objects and classes. We will see
that OOSD combines aspects of both process-oriented and data-oriented
methods. After all, what is an object but encapsulated state (ie., data) and
behaviors (i.e., processes)? The potential to provide a dual focus on both
state and behavior is one of the strengths of the object-oriented paradigm.

2. Object-Oriented System Development Methods

The use of object-oriented concepts is rapidly evolving to cover the com-
plete system life cycle. We first survey representations of the object-oriented
system life cycle and then discuss existing methods, techniques, and tools
that support the development phases of object-oriented analysis, object-
oriented design, and object-oriented implementation and testing. Brief
surveys of research and development projects on object-oriented system
development methods and tools are presented. The section concludes with
a critique of current object-oriented system development (OOSD).

2.1 Object-Oriented System Life Cycle

The system life cycle must be represented in a realistic way to provide
intellectual and management control of the system’s development. (While
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 147

the complete life cycle includes development, operation, maintenance, and

evolution of a system, we will concentrate on system development in this
chapter. The use of object-orientation for effective system operation, main-
tenance, and evolution is an interesting topic, but is beyond the scope of our
discussion.) Traditional descriptions of a system life cycle have been based
on the so-called waterfall model. Distinct system development phases are
performed in a sequential pattern with limited opportunities to return to
previous phases in feedback loops if deficiencies are found in the developing
system. The advantages of the waterfall model are that activities within each
development phase are well defined and clear completion criteria (typically
in the form of required documentation) can be enforced. However, the
disadvantages are many. It is difficult, if not impossible, to complete one
phase of system development without some knowledge or experience with
later phases of development. Requirements to complete detailed documenta-
tion at the completion of each phase are onerous and often unnecessary.
Recent thinking on system life cycle models has led to the description of
spiral models for system development. The spiral is a flexible arrangement
of sequential and concurrent activities with well-defined points of progress
review and approval. Two principal spiral approaches to system develop-
ment have been proposed:

The Boehm Spiral (Boehm, 1988). The Boehm spiral model of system
development is risk driven. The objective of each loop is to reduce the
risks involved with the evolving stages of system development. Each loop
has four steps:
Determine objectives, alternatives, and constraints,
Evaluate alternatives, identify and resolve risks,
Develop and verify next-level product,
Plan next phases.
Prototyping is supported as an effective means of evaluating and resolving
risk. As many loops as needed are performed to complete the system
development. If the system can be divided into increments, parallel
development spirals are executed.
The Mills Spiral (Mills, Linger, and Hevner, 1987b). The Mills spiral
model defines a set of limited, time-phased activity loops to manage a
system development. Each activity loop is initiated and managed dynami-
cally on the basis of the outcome of previous loops. The activity loops in
the spiral can be sequential or concurrent and can be one of three types;
investigation, specification, or implementation. Each loop regardless of type
has three steps:
Planning the activity objectives, statement of work, and schedules,
Performance of the work needed to achieve the activity objectives,
148 A. R. HEVNER

Evaluation to determine if the objectives are met and to plan for the
next activities.
Activity loops are performed in the spiral until the system development is
completed.
These spiral models provide the flexibilityto plan and record system devel-
opment activities in a controlled, user-defined pattern. Activities are not
predefined into phases. Thus, a loop of investigation can be followed by a
loop of implementation, followed by a loop of specification, followed by a
loop of investigation, etc. in no predefined order.
The spiral system life cycle is a natural one for object-oriented system
development. The three activities of the Mills’s spiral model correspond
closely with the three principal OOSD activities: object-oriented analysis
(OOA), object-oriented design (OOD), and object-oriented implementation
and testing (OOIT) (Henderson-Sellers and Edwards, 1990; Booch, 1991;
Coad and Yourdon, 1991). Each of these activities can be defined as follows:
0 OOA works in the problem domain of the system. Investigation and
analysis tasks are performed to capture and understand system require-
ments based on the set of problems to be solved by the system. Required
objects and classes are proposed and modeled.
0 OOD works in the solution domain of the system. Based on the results
of OOA, system designs are specified under the opportunities and con-
straints of the development environment. Design tasks, such as module
definition and hierarchy definition via decomposition and composition,
are performed and validated as to correctness and predicted system
performance.
0 OOIT builds the system design in combinations of hardware, software,
and human behavior. System testing is an integral part of implementa-
tion. OOIT makes use of OOP languages and OODBS to support obj-
ect-Orientation directly in implementation.
The spiral model supports flexible patterns of OOA, OOD, and OOIT activ-
ity loops during a system development, as illustrated in Fig. 3. Integration
of the object concept throughout all system development activities is essential
for the spiral model to be most effective. This allows the results of each
activity to be shared efficiently with all other activities without the need for
information transformations (i.e., bridges) between development steps. As
discussed in Section 5, integrated CASE environments for OOSD is an
important area of current and future research and development (IEEE
Software, 1992).
Henderson-Sellersand Edwards (1990) analyze the combination of OOSD
methods and traditional methods for system development; for example, the
 OBJECT-ORIENTED SYSTEM DEVELOPMEN-T METHODS 149

-
A MANAGEMENT
APPROVAL
A

COMPLETION
FIG.3. Object-oriented spiral model.

use of OOA and OOD with a procedural programming language (e.g., Pas-
cal), or the use of a process-oriented analysis technique (e.g., data-flow
diagrams) with OOD and OOIT. While these combined methods may appear
to be a natural evolution toward object-orientation, the disparities in system
concept and information representation cause many problems. Bridges must
be constructed to map information from one activity to another, forfeiting
true integration throughout the development process.
In the same paper, Henderson-Sellers and Edwards (19%) propose the
fountain life cycle model for OOSD. The central plume of water in the
fountain represents the main path of OOSD activities. Multiple, separate
water plumes represent the development of system modules. Each module
contains a “cluster” of related classes grouped for independent design and
implementation. The modules are placed into a library for use in the current
system and reuse in future systems. Similarly, the spiral model accommod-
ates concurrent paths of OOSD for the development of independent system
modules.
We now survey current methods for OOA, OOD, and OOIT. It is impor-
tant to view these methods in light of the integration required by the spiral
development model. While current OOSD methods can be fit into the tricho-
tomy of OOA, OOD, and OOIT, future research and development in OOSD
will emphasize total life-cycle integration.
150 A. R. HEVNER

2.2 Object-Oriented Analysis

The goal of OOA is to achieve an adequate understanding of the problem
domain in order to describe the requirements of the desired system. This is
the most critical, yet least understood, phase of systems development. Most
system development projects fail because of inadequate understanding of
problem requirements. Many times, even when a system is completed, it does
not solve the target problem. It has also been observed that the identification
and correction of errors in requirement specifications consume a major por-
tion of system development time and resources (Boehm, 1988). Thus, OOA
entails close cooperation between the system developer and the system cus-
tomer. Behavioral skills are just as important as technical skills in order to
get the system requirements “right.” It is imperative that developers have
solid methodological support for this critical phase of system development.
Requirements determination methods consist of activities to gather and
analyze requirements, and modeling techniques (both graphical and syntact-
ical) to specify requirements. Many such methods have been proposed over
the years. Davis (1990) provides an excellent survey and analysis of these
methods. Traditional requirements determination methods emphasize the
understanding and modeling of process and data, not objects and classes.
Two approaches have been used to develop OOA methods; the extension of
traditional methods to object-orientation and the invention of new methods
devoted to OOA.

2.2.1 Object- Oriented Extensions to Requirements

Determination Methods
The wide use of data flow diagrams (DFDs) for structured system analysis
has led to several attempts to include and extend DFDs into OOA methods.
Booch (1986) and Seidewitz and Stark (1987) suggest the construction of a
DFD model and, then, the identification of objects, classes, and inheritance
hierarchies within the model. This additional step of object-oriented analysis
of the DFD model provides a transition to OOD methods. Ward (1989)
describes a similar technique for real-time system models that include both
data flows and control flows among processes.
Traditional data-oriented requirements methods highlight the modeling
of required system data. Problem data is structured and analyzed in a seman-
tic data model (Hull and King, 1987), the most popular model being the
extended entity-relationship diagram (EERD) (Chen, 1976; Teorey, Yang,
and Fry, 1986). Shlaer and Mellor (1988) describe the use of basic EERD
techniques as object-oriented analysis. Few details are presented, however,
on how objects and classes are derived from EERDs.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 151

Bailin ( 1989) proposes an object-oriented requirements specification

method that is based on modifying DFDs to emphasize entities in the prob-
lem domain. The entity data flow diagram (EDFD) models system entities
and the functions associated with each entity. A series of steps are applied
to decompose and refine passive and active entities in the EDFD. An EERD
is also developed to provide a data context. Eventually, each entity together
with its functions corresponds to an object or class.
The problem with extending existing requirements techniques to OOA is
the need at some point to switch concepts from processes and data to objects
and classes. Such mappings are typically time consuming and have a poten-
tial for information loss. Why not begin directly with objects for OOA? This
approach is best exemplified by the Coad and Yourdon (1991) OOA method.

2.2.2 Coad and Yourdon Object- Oriented Analysis

The Coad and Yourdon (1991) OOA approach consists of five activities
applied as needed to build a system model in the problem domain:
Finding Class-&-Objects. Information gathering techniques (e.g., reading,
interviews, prototyping) are used to gain an in-depth understanding of the
problem domain. This understanding is used to specify the required objects
and classes of the desired system. The term class-&-object is used to describe
a class as well as all objects in the class. Generic classes with no objects are
just termed a class.
Zdentifying Structures. Hierarchical structures are defined based on the rela-
tionships among class-&-objects and classes. A generalization-specialization
(Gen-Spec) structure and the Whole-Part structure depict, respectively, the
generalization and the aggregation relationships described in Section 1.1.
Inheritance is provided through the Gen-Spec structure. More complex lat-
tice structures that represent multiple inheritance may also be defined. Multi-
ple structures show generalization and aggregation relationships throughout
the system model.
Identifying Subjects. Subjects provide high-level abstractions for guiding
customers through the system model. The selection of subjects is closely tied
to subdomains of the problem.
Defining Attributes. Attributes (i.e., properties) add detail to class-&-objects
and structures. Instance connections are added to the model to indicate
special object-&-class relationships not shown in the structures.
Defining Services. Required system services (i.e., behaviors) are defined
along with the message connections that support the services. The procedural
details of the services are specified with object-state diagrams and service
charts.
152 A. R. HEVNER

The application of these activities produces an evolving object-oriented sys-

tem model. The Coad and Yourdon OOA system model is presented and
reviewed in five layers as shown in Fig. 4. The layers are considered overlap-
ping transparencies that gradually present more and more model detail.
The graphic notation used in this OOA methodology is relatively straight-
forward and the basic notation is demonstrated in the following simple
application. Complete notation details are found in Coad and Yourdon
(1991).
In Fig. 5, a OOA system model is developed for collecting information
on the book-buying habits of college graduates and high school (not college)
graduates. Following the five activities of OOA modeling, first the class-&-
objects of the problem are found. The double boxes indicate class-&-objects.
(A single box indicates a class with no objects.) Next, structures relating the
class-&-objects are identified. A Gen-Spec inheritance hierarchy relates both
CollegeGrad and HSGrad with the superclass of Person. Another Gen-Spec
structure provides a detailed description of the superclass of Book. A Whole-
Part structure shows that a nonfiction book can be classified by many Key-
words, and a Keyword can be used to classify many books. The system can
be divided into two subject areas: the Person subject and the Book subject.
The PurchEvent class-&-object is included in the Person subject because of
the primary focus on persons in collecting information.
Essential attributes are defined for each class-&-object. Instance connec-
tions are defined between Person and Book, Person and PurchEvent, and
PurchEvent and Book. The numbers on the instance connection lines indi-
cate lower and upper bounds on object participation in the connection. A
single number requires an exact number of participating objects.

SUBJECT LAYER

CLASS-&-OBJECT LAYER

~~

STRUCTURE LAYER

AlTRIBUTE LAYER

SERVICE LAYER
FIG. 4. Coad and Yourdon OOA model layers.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 153

El
I I
Non-Fiction

CalcPurchStat CalcPurchStat
I

I
Science-Fic. Classificatlon

FutureEra Keyword

I I

FIG. 5. Purchase example in Coad and Yourdon OOA notation.

Finally, system services are defined and allocated to class-&-objects. The

Purchase service is placed in PurchEvent. A message connection is estab-
lished with Book in order to add information on the book(s) purchased.
The CalcPurchStat service is included in Person with extended versions in
CollegeGrad and HSGrad. This service requires access to data in PurchEvent
and Book, thus, message connections to these class-&-objectsare established.
The Coad and Yourdon OOA notation is meant to be easily read and
understood by developers and customers during analysis activities. However,
graphic notations can quickly become very complex for medium to large
system models. Insightful techniques (e.g., OOA subjects) for navigating
large system models are necessary.

2.3 Object-Oriented Design

The goal of object-oriented design is to transform the system models of
OOA into system specifications in the solution domain of hardware,
1 54 A. R. HEVNER

software, and human behavior. Design is a creative endeavor in which trade-

offs must be made to take advantage of opportunities and to deal with
constraints of the implementation environment. In this section, we survey
the research and development of OOD methods and present the Booch
(1991) OOD method as a current example.

2.3.1 Survey of OOD Methods

In the early 1980s, as OOP languages were being accepted and used,
system developers recognized the need for new methods to design object-
oriented systems. Experiences in developing program designs for the Simula
and Smalltalk systems produced early guidelines for OOD (Reenskaug,
1981). A seminal paper by Abbott (1983) envisioned using English descrip-
tions of system requirements as the basis for object-oriented program
designs.
Research and development on OOD methods was spurred by the Depart-
ment of Defense (DOD) project that produced the Ada programming
language. The use of “packages” and “generics” in Ada provides support
for the concepts of objects and classes. The promise of widespread Ada use
in future, large DOD system developments led to tremendous activity on
Ada OOD methods. Booch (1986), Seidewitz and Stark (1986), and Sincover
and Wiener (1984) propose OOD methods and notations for program design
in Ada. Booch (1987b) demonstrates the use of his method on a number of
reusable software components in Ada.
There are a number of projects in academic and industrial research labora-
tories on OOD methods and techniques. The following list provides concise
overviews of several of the better known OOD development projects.

Eiffel. Meyer was one of the first to realize the potential advantages of
object-oriented development for large scale systems. Finding no satisfac-
tory OOP language in which to design and build object-oriented systems,
Meyer (1988) developed the Eiffel language and programming environ-
ment. The Eiffel language is truly object-oriented, including multiple inheri-
tance, polymorphism, and strong typing. The system development
environment emphasizes the storage and reuse of classes and objects
(Meyer, 1987). The Eiffel OOD method has evolved through numerous
commercial applications of the language.
Object Modeling Technique (OMT). OMT has been developed at General
Electric Research and Development Center to support the complete devel-
opment life cycle of object-oriented systems (Rumbaugh et al., 1991). The
OMT graphic notation is used to build system models during OOA. These
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 155

models are transformed into system and object designs by adding imple-
mentation details. OMT is language independent and allows the selection
of a implementation language that best suits the application.
Responsibility Driven Design (RDD). Based on experience with Smalltalk
applications. Tektronix has developed RDD methods for OOD (Wirfs-
Brock, Wilkerson, and Weiner, 1990). Objects are assigned responsibilities
in the system to maintain knowledge and provide actions. The RDD
methodology iterates through phases of exploration and analysis to pro-
duce object-oriented system designs. Reuse is emphasized in forming
objects and classes.
Object-Oriented Role Analysis, Synthesis, and Structuring (OORASS).
The development group at the Senter for Industriforskning (SI) in Norway
has been building Smalltalk systems since 1983. Their OORASS method
of OOD centers on the roles that objects play in systems (Reenskaug and
Nordhagen, 1989). The five-stage design method covers the development
life cycle in Smalltalk from developing role models through system
implementation.
Other OOD projects are surveyed in (Wirfs-Brock and Johnson, 1990).
Many experienced system development organizations are beginning to cus-
tomize their own OOD methods. We will see a large number of proposed
object-oriented methods and tools in the near future. Currently, the most
widely known OOD method is due to Booch (1991). We now look at this
method in more detail.

2.3.2 Booch Object- Oriented Design

The Booch OOD methods have evolved from early work on Ada program
design (Booch, 1987a) to generic, language-independent OOD methods
(Booch, 1991). The four major steps of the Booch approach mix aspects of
both OOA and OOD; however, the goal is to produce an object-oriented
design specification. Both a graphic set and a syntactic set of notations are
presented. While graphic notation is very useful for OOA system models,
the detailed syntactic notation is more appropriate for formal OOD speci-
fications. The following discussion will illustrate the syntactic templates used
in the Booch OOD method.
The following four steps are to be performed iteratively and concurrently
in a system development spiral, as described previously in Section 2.1 :

1. Identfy the classes and objects at a given level of abstraction. This step
emphasizes the discovery of information from the application domain
156 A. R. HEVNER

CLASS TEMPLATE OPERATION TEMPLATE

Name: identifier Name: identifier

Documentation: text Documentation: text
Visibility: expotted/ private / Category: text
impotted Qualification: text
Cardinality: O/ l / n Formal Parameters: list ofparameter
Hierarchy: declarations
Superclasses: list of class names Result: class name
Metaclass: class name Preconditions: PDL/ object diagram
Generic parameters: list of parameters Action: PDL / object diagram
Interface I Implement Postconditions: PDL /object diagram
(Public / Protected / Exceptions: list of exceptional
Private): declarations
Uses: list of class names Concurrency: sequential/guarded
Fields: fist of field / mncurrent/ multiple
declarations Time Complexity: text
Operations: list of operation Space Complexity: text
declarations
Finite State Machine: state transition
diagram
Concurrency: sequential/ blocking
/active
Space Complexity: text
Persistence static / dynamic

FIG.6. Class and operation templates.

in order to identify potential classes and objects. Candidate classes and

objects are proposed, diagrammed, and analyzed.
2. Identifv the semantics of these classes and objects. Considerable effort
is spent to understand the semantics of each class and object in the
system. The design templates for classes and objects are initiated in this
step. The final two steps complete the class and object designs. Figure
6 shows the class template and the operation template. Figure 7 shows
the object template and the message template. The complete description
of the template parameters are presented in Booch (1991). The tem-
plates are shown here to give a flavor of the detail and effort required
in OOD. Note that the state (i.e., fields) and the behavior (i.e., opera-
tions) of the class are designed as part of its interfaces to other classes
as defined by the “uses” parameter.

OBJECT TEMPLATE MESSAGE TEMPLATE

Name: identifier Operation: operation name

Documentation: text Documentation: text
Class: class name Frequency: aperiodic/ periodic
Persistence: persistent/static/ Synchronization: simple/synchronous
dynamic / balking/ timeout /
asynchronous

FIG. 7. Object and message templates.

 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 157

3 . Identfy the relationships among these classes and objects. The relation-
ships (e.g., generalization, aggregation, and association) among classes
and objects are discovered, analyzed, and represented in the design
templates. This is a highly creative exercise that determines the
structure of the system.
4. Implement these classes and objects. The final design decisions are made
to complete the specification of these classes and objects. Additional
design templates are defined. In the module template, classes and objects
are allocated to physical modules for implementation. Required pro-
cesses are defined in the process template and are assigned to processors
in the processor template. Hardware resources are considered in the
device and connection template.

Booch emphasizes the iterative and spiral application of these four steps. He
recommends a complete pass through the four steps for each important level
of abstraction in the system.
A comprehensive set of examples is presented by Booch (1991) to illustrate
the use of his OOD method. Each example includes a partial implementation
of the example design in different OOP languages. The languages demonstra-
ted are Smalltalk, Object Pascal, C++, CLOS, and Ada.

2.4 Object-Oriented Implementation and Testing

OOIT accepts the OOD specification and produces an operational system.
Implementation decisions include selection of the most appropriate OOP
language for software development and selection of an OODBS if the man-
agement of a large object database is required. The principles of software
engineering can be applied and adapted to object-oriented software develop-
ment (Cox, 1986). A comprehensive testing strategy to verify the correctness
and to evaluate the performance of the system implementation is essential.
Another activity of OOIT is the production of a complete set of documenta-
tion summarizing all system development work and system user manuals.
It is unlikely that a complex system can be implemented successfully in
one pass. The spiral development model lends itself to the incremental devel-
opment of systems. Incremental development allows intellectual control over
complex systems by dividing the development into manageable increments.
Each increment defines a complete “end-to-end” system with added func-
tionality over previous increments. An incremental development plan is built
during the early stages of system development. Once an initial understanding
of the system requirement specifications is achieved, increments are defined
based on several criteria (Cobb and Mills, 1990):
158 A. R. HEVNER

Increment size, increments should be less than 10,000 lines of code;

The availability of reusable components and the reliability of these
components ;
The size and skills of the development team, in order to determine the
potential for parallel development;
Cohesiveness of the object-oriented requirements within the increment.

The spiral activities of OOA, OOD, and OOIT can be performed for each
increment. The activities of one increment can overlap the activities of pre-
ceding and succeeding increments. The incremental development plan details
and controls the sequencing of increments. Each successive increment of
classes, objects, and structures builds onto the system until the system is
eventually completed. Incremental development supports the objectives of
system prototyping, configuration management, version control, incremental
verification, and incremental testing.

2.5 Critique of Current OOSD

The material presented in this section is, at best, a snapshot in time of the
state of the art in object-oriented system development. Since the early 1980s
the pace of research and development in object-oriented areas has been
rapid, and all indications are that it will accelerate into the future. Viewing
the system life cycle, object-orientation has grown from the middle toward
both ends. The original investigations on OOP languages for system imple-
mentation led toward the beginning of the system life cycle to interest in
OOD methods. Work on design ideas, then, generated interest and research
on the front-end requirements determination and OOA methods. As evid-
enced thus far, the areas of OOP, OODBS, OOD, and OOA have reached
a level of some maturity. Real object-oriented systems are being analyzed,
designed, and built. In the other direction of the system life cycle, however,
object-oriented concepts are just beginning to be applied to the areas of
system testing, maintenance, and evolution. Also, a challenging area of
future research will be object-oriented reverse engineering of existing non-
object-oriented systems. Much additional research is needed to support the
complete object-oriented system life cycle. A survey of OOSD research topics
is presented in Section 5.
The new object-oriented concepts and system development methods are
strong competitors to the traditional process-oriented and data-oriented
development methods. The system and software engineering communities
are currently engaged in an intriguing debate on the future role of object-
orientation for systems development (Constantine, 1989; Loy, 1989; de
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 159

Champeaux et al., 1990). The following questions provide a brief glimpse of

level of this debate:
Are object-oriented concepts the answer to the many problems we face in
systems development. Object orientation is not the long-sought “silver
bullet” that will destroy the many werewolves of system development
(Brooks, 1988). However, it is a new way of thinking about systems. Fresh
insights are gained by looking at old problems in new ways. Thus, object-
oriented methods are providing new solution approaches for such prob-
lems as reusability, concurrency, and reliability.
Are OOSD methods suficiently mature for developing large, complex, real-
time systems? Until system developers begin building large, complex sys-
tems with object-oriented methods, this question cannot be adequately
answered. As Ed Yourdon has stated, “A system composed of 100,000
lines of C++ is not to be sneezed at, but we don’t have that much trouble
developing 100,000 lines of COBOL today. The real test of OOP will
come when systems of 1 to 10 million lines of code are developed” (de
Champeaux et al., 1990). More research on real-time OOSD and concur-
rent OOP are needed, but just as important, trial-and-error experience in
developing actual, large object-oriented systems is essential
Can current structured analysis and design methods be used with object-
oriented methods? There is a wide divergence of opinion on this question.
Based on large investments (e.g., training, CASE tools, systems documen-
tation) in traditional structured methodologies, there would be tremend-
ous pragmatic advantages to merging OOSD methods with existing
methods. Many advocate the judicious use of structured techniques, such
as data flow diagrams, entity-relationship diagrams, and state-transition
diagrams, in OOA and OOD. Others, however, insist the OOSD should
be a totally integrated process based solely on objects. They decry the
inherent clash of concepts and the loss of information that comes from
bridging from one representation (i-e., data flow diagrams) to another
(i.e., a class inheritance hierarchy). This debate is likely to continue for
many years.
Can we identifv application domains or problem types that are best suited
to system development with object orientation, process orientation, or data
orientation? If there were a good answer to this question, it would be
possible to analyze a given problem statement and then select the best
development approach. One can find a number of rules of thumb to
provide guidance in this selection. For example, “object-oriented develop-
ment best supports reuse requirements” and “data-oriented development
should be used for systems with large information requirements.” Cur-
rently however, this remains a very interesting question that deserves
research attention.
160 A. R. HEVNER

The fundamental question in evaluating any system development methodol-

ogy is Does the methodology develop top-quality systems with a high rate of
developer productivity? Quality is defined broadly to encompass the essential
features of the system, such as correctness, reliability, performance, security,
etc. Productivity is measured by effective use of development resources (e.g.,
human, economic, time) for successful system completion. Do OOSD meth-
ods enhance system quality and development productivity? Again, without
more experience in developing object-oriented systems, there is no clear
answer to this question. However, Booch (1991) points out several benefits
and risks of OOSD. The recognized benefits are

Exploits the expressive power of OOP languages,

Encourages the reuse of components,
Leads to systems that are more resilient to change,
Reduces development risk,
Appeals to the working of human cognition.

The risks are potentially poor system performance and OOSD start-up
costs. The performance overhead of OOP and OODBS in relation to tradi-
tional programming languages and database systems cannot be ignored.
Currently these implementation areas may preclude the use of object-orienta-
tion in certain applications that demand high performance. Also not to be
taken lightly are the costs-time, money, and human stress-required to
learn and apply OOSD methods.
Our analysis of current OOSD concludes that object-orientation has revo-
lutionary potential. However, important deficiencies, theoretical and
pragmatic, will hamper widespread use of OOSD methods until they are
remedied. In this section, we have surveyed the many research and develop-
ment efforts that are addressing object-oriented issues by investigating new
methods of OOA, OOD, and OOIT. In the next two sections, a comprehens-
ive methodology for OOSD, the cleanroom system development process
(CSDP), is presented. In CSDP, objects are defined mathematically as box
structures. As an integrated development process, CSDP provides important
new advances in achieving development productivity and system quality.

3. Object-Oriented System Development

with Box Structures
Research and development on the next generation of system development
methods has highlighted two very important directions: formal development
methods and object-oriented development methods. Formal development
methods are based on rigorous, mathematics-based theories of system
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 161

behavior (Wing, 1990). Formal methods support greater levels of correctness

verification at both system design and implementation. The use of formal
methods is essential for the development of real-time, complex systems where
reliability and safety are critical. The difficulties inherent in formal methods
are making formal concepts applicable for practical use and extending the
rigorous development theory to all phases of the system development
process.
An important goal is to formalize OOSD methods to provide the advan-
tages of both object-orientation and mathematical rigor. While the object
provides an integrating concept throughout the process, varying and, often,
conflicting definitions, interpretations, and representations of an object make
its use as a mathematical formalism difficult. Recent attempts to combine
formal and object-oriented theories of system development in practice have
met with varying degrees of success. One of the most successful formal
methodologies is the cleanroom approach to system engineering (Mills,
Dyer, and Linger, 1987a; Cobb and Mills, 1990). Recent work has also
demonstrated the inherent object-orientation of the cleanroom development
strategy (Hevner and Mills, 1992). Cleanroom system engineering is based
on mathematical models of desired system behavior. System design speci-
fications are verified for correctness and implementations are placed under
statistical quality control.
In this section, the central concepts of cleanroom system development are
presented; box structures, the box structure usage hierarchy, and box struc-
ture principles. Then, in Section 4, the cleanroom system development pro-
cess is detailed and the use of box structures in OOA and OOD is examined.

3.1 Box Structure Overview

Box-structured systems development is a stepwise refinement and veri-
fication process that produces a system design. Such a system design is
defined by a hierarchy of small design steps that permit the immediate
verification of their correctness. Three basic principles underlie the box-
structured design process (Mills, 1988):

1. All data to be defined and stored in the design are hidden in data
abstractions.
2. All processing is defined by sequential and concurrent uses of data
abstractions.
3. Each use of a data abstraction in the system occupies a distinct place
in the usage hierarchy of the system.
162 A. R . HEVNER

Box structure methods define a single data abstraction in three forms in

order to isolate the creative design steps involved in building the abstraction.
The black box gives an external description of data abstraction behavior in
terms of a mathematical function from stimulus histories to responses. The
black box is the most abstract description of system behavior and can be
considered as a requirements statement for the (sub)system. The state box
includes a designed state and an internal black box that transforms the
stimulus and an initial state into the response and a new state. The state is
designed from an analysis of the required stimulus histories and responses
for the system. Finally, the clear box replaces the internal black box with
the designed sequential or concurrent usage of other black boxes as subsys-
tems. These new black boxes are expanded at the next level of the system
box structure usage hierarchy into state box and clear box forms.

3.2 The Mathematical Foundations of Box Structures

Box structures have underlying mathematical foundations that permit the
scale-up of analysis and design to systems of arbitrary size. These founda-
tions are based on sets and functions that can be described in mathematical
notation for small systems or subsystems or in well-structured natural
language in a given context in larger systems. In any case, a black box is
defined by a mathematical function from histories of stimuli. to the next
response. Let S be the set of possible stimuli. and R be the set of possible
responses of a system or subsystem. The black box function, sayf, will map
historical sequences of such stimuli, in this case S*,to responses, R, shown
in the form

The description of functionfmay be very complex for an airline reservation

system, but it is a function, no more, no less. This description of the black
box assumes no data storage between stimuli, even though such storage may
be known to exist, or to be planned for development.
In a simple illustration, consider a stack object of integers, defined by a
set of commands, say reset, push, pop, empty?, and top?, whose functions are
easily inferred from the names. A stimulus is a command plus data, if
required. For example, a possible sequence of stimuli might be
reset, empty?, push 17, push 31 ;pop, top?, push 11, . . . .
The responses for the stimulus histories returning data are
reset, empty? + yes

reset, empty?, push 17, push 31 ; pop, top? + 17.

 0 BJECT-0 R I ENTED SYSTEM DEVELOPMENT METHODS 163

Although a data stack can be readily imagined, the responses can be deter-
mined by examining only the stimulus histories, as in the preceding.
The state box of a system or subsystem expands the black box by identi-
fying data at this system level to be stored between stimuli so that only a
current stimulus is required but not previous history. Let T be a set of
possible data states at the top level, and let t be the initial state of the
system or subsystem. As noted earlier, the state box contains an internal data
abstraction that is defined by another black box, say g. In this case, the
internal black box has a compound stimulus consisting of the external
stimulus and the internal state and a compound response consisting of the
external response and the new internal state. That is, g has the form
g : ( S x T)* -+ ( R x T ) .
Then, each pair ( t , g ) of an initial state and an internal black box function
will uniquely define the behavior of the system. Note that the internal data
abstraction will be capable of maintaining more deeply stored data, with the
internal black box using its compound stimulus histories.
To continue the stack illustration, consider the state to be a list of integers,
where the initial state is the empty list. Then the commands reset, push, pop,
empty?, and top? are functions from the stimuli and state to a response and
new state. For example, the previous sequence of stimuli will produce states
as well as responses as follows:
(reset, ( ) 1 -+ (null, ( ) 1)
(empty?, ( ) 1 -+ (Yes, ( ))
(push 17, ( > ) -+ (null, (17))
(push 31, (17)) + (null, (31, 17))
(pop, (31,17)) -+ (null, (17))
(top?, (17)) -+ (17, (17))
(push 11, (17)) -+ (null, (11, 17)).
Furthermore, all intermediate states of this state box can be eliminated by
mathematical substitution to define a black box function, say k, in which
the initial state will serve as a parameter. Thus, to verify that a state box,
say (t, g ) , has been designed correctly to provide a specified black box
behavior, say f,the new black box k, defined by (t, g ) , need only be com-
pared with f.
Continuing, a state box can be expanded into a clear box by replacing the
internal data abstraction with a procedural structure of new data abstrac-
tions in either sequential or concurrent logic. Sequential structures may
1 64 A. R. HEVNER

involve simple sequence, alternation, or iteration whose semantics are well

known from sequential programming. Since sequential programs are rules
for mathematical functions, from initial states to final states of computation,
a clear box in sequential structures defines the functional behavior in terms
of the next level black boxes. Concurrent structures require more analysis
and discipline in use because of their potential complexities. Becker and
Hevner (1989) propose an extended semantics for box structures to support
concurrent system design.
The procedural structure of data abstractions can also be eliminated to
produce the effect of a single internal data abstraction and a state box, in
much the same way as the state was eliminated to derive a black box.
Sequence and alternation structures are eliminated by function composition
and disjoint union directly. Iteration structures can be reformulated as recur-
sion, but iteration free (Linger, Mills, and Witt, 1979). Again, concurrent
structures require more specific treatment. In this way, clear box designs can
be verified against state box specifications, as well.
Figure 8 shows the relationship among the three views of a single data
abstraction. The creative design steps, along the right side of the figure, are
called expansions. The design verification steps, along the left side of the
figure, are called derivations. A given black box (state box) can be expanded

I Black Box I

D e r i va ti on :
1
Expansion :
Eliminate CIeate State

I-
State
State Box -

I I
D e r i v a t i on : Expansion :
Eliminate Create
Procedure
Clear Box

FIG. 8. Box structure expansion and derivation.

 06J ECT-0 R I ENTED SYSTEM D EVELOPM ENT METH0 DS 165

into many correct state box (clear box) designs. Conversely, a state box
(clear box) will define a unique black box (state box) by derivation.
In order to gain intellectual control over the development of a complex
system, it is necessary to be able to decompose the system into smaller, more
manageable parts. A box structure usage hierarchy represents the use of
black box abstractions in a higher-level clear box abstraction. A usage hierar-
chy of abstractions provides referential transparency among all black boxes
within a clear box (Parnas, 1974). Thus, each black box in a clear box can
be designed independent of the others. Figure 9 illustrates a simple box
structure usage hierarchy.
In order to represent box structures during OOA and OOD, both a graphic
language, the box structure graphics, and a syntdctic language, box descrip-
tion language (BDL), have been developed (Mills et al., 1986). Box structure
graphics are appropriate for the construction of system models during OOA.
The more formal BDL is used for design specifications during OOD.

3.3 Box Structure Principles

The effective use of box structures for the development of systems is guided
by the use of four basic box structure principles ; referential transparency,
transaction closure, state migration, and common services. Here we briefly
define each of these principles.

Referential Transparency. Referential transparency occurs when a black

box abstraction is completely defined within the clear box at the next
higher level in the usage hierarchy. The black box is then logically inde-
pendent of the rest of the system and can be designed to satisfy a well-
defined behavioral specification. The principle of referential transparency
provides a crisp discipline for management delegation and assignment of
responsibility.
Transaction Closure. The principle of transaction closure defines a system-
atic, iterative specification process to ensure that a sound and complete
set of transactions is identified to achieve the required system behavior.
The closure process can be performed at each box structure view of an
object abstraction. At the black box, checks are performed to ensure that
the system stimuli are necessary and sufficient to generate the required
system responses. At the state box, the defined transactions must be neces-
sary and sufficient for the acquisition and preservation of all state data,
and the state data must be necessary and sufficient for the completion of
all transactions. At the clear box, the procedural design and the internal
black boxes must include all transactions.
166 A. R. HEVNER

...J L .......... I ......... ....

I - J I
....

.......... 1.

1 1 I I I

Clear Box ~

....

FIG. 9. Box structure usage hierarchy.

State Migration. State data should be identified and stored in the system
part (i.e., data abstraction) at the lowest level in the box structure hierar-
chy that includes all references to that data. At any time in the system
development process, state data can be migrated upward or downward in
the hierarchy in order to achieve some system objective, such as minimiz-
ing data scope (Hevner and Linger, 1989). State migration must be per-
formed carefully in order to maintain the consistency and mathematical
correctness of data abstractions throughout the hierarchy.
Common Services. A common service is a data abstraction that is
described in a separate box structure usage hierarchy and used in other
box structured systems. System parts with multiple uses should be defined
as common services for reusability. Also, predefined common services,
such as database management systems and input-output interfaces, should
be used to advantage throughout the box structured system. The advan-
tages of reusable common services for system development are obvious.
Box structures directly support the identification and reuse of common
services within and among systems.
 OBJ ECT-OR1ENTED SYSTEM DEVELOPMENT METHODS 167

3.4 Box Structures as Objects

Similarly to objects, the box structure theory can be seen as an extension

of abstract data types in programming languages (Danforth and Tomlinson,
1988). Here, we briefly show that box structures provide the essential object-
oriented characteristics of abstraction, modularity, encapsulation, and
hierarchy.

3.4.1 Abstraction
An object is an abstract representation of an entity in the problem domain.
Much creative skill and experience are needed to identify and design a good
set of system objects and classes. Box structures provide an excellent set of
abstraction capabilities for system description. During analysis, a potential
object can be defined and studied in any of the three box structure views. In
particular, the black box view gives the external, design-free system behavior
that provides the essence of a system abstraction. The state box views the
object as a data abstraction with visible state. Within the clear box view
complex object abstractions can be rigorously decomposed into simpler
objects and simple objects can be grouped into larger objects.
During design, the box structure usage hierarchy provides a framework
in which to capture multiple levels of system abstraction in a controlled
manner. All system design units, from the top-level, complete system to the
smallest subsystem components, and even down to simple variables, are
viewed and described as box structure objects. Throughout the hierarchy,
the ability to manage abstraction applies to all system components ;stimulus
(i-e., input), responses (i.e., outputs), state (i-e., internal data), and
procedures.
The ability to handle abstractions is also important for the reverse
engineering of existing systems. Bottom-up system analysis abstracts func-
tionality (i.e., black box behavior) from system implementation details of
procedure and state. The application of box structure theory to system
reverse engineering is presented in Hausler et al. (1990).

3.4.2 Modularity
Modularity in system development involves dividing the complete system
into manageable units of analysis, design, and implementation. Each system
module must be internally cohesive and loosely connected to the other mod-
ules of the system. Modularity is one of the major strengths of the box
structure development process. The principle of referential transparency
throughout the box structure usage hierarchy provides module independence
168 A. R. HEVNER

for all box structures in the system design. Furthermore, referential transpar-
ency applies to both object decomposition and object composition in the
system development process.

3.4.3 Encapsulation
Encapsulation is supported by the state box and clear box views of a box
structure object. The state of an object and the procedural operations on
that state are hidden within the box structure as design constructs. Whereas
the essential behavioral abstraction, or interface, of the object is described
by the black box view.
An extension to object encapsulation can be found in the box structure
principle of state migration. As box structure objects are decomposed and
composed in a usage hierarchy, opportunities for state migration may exist.
Beneficial state migrations provide insights into new class inheritance struc-
tures. Upward migration of state can identify new superclass structures and
downward migration of state can identify new subclass structures.

3.4.4 Hierarchy
The concept of a system hierarchy is an essential component for box
structure system development. A usage hierarchy of box structures is con-
structed during system design via the application of both object decomposi.-
tion and object composition.
Top-down system decomposition enables an essential intellectual control
in development. The system grows one level at a time. The mathematical
structuring of systems in usage hierarchies of objects allows formal veri-
fication methods to be used. Also, the referential transparency of objects in
a clear box provides an essential modularity and design independence to
each object.
In addition, in this framework of an object hierarchy, the advantages of
object composition come into play. An object requirement, stated as a black
box, can be matched with existing object classes stored for reuse in a reposi-
tory. During the system analysis phase the benefits and costs of object reuse
and modification can be studied. Another opportunity for object composi-
tion comes during the design of the clear box. Knowledge of existing object
classes or insight into desired object classes will influence the designer’s
invention of data abstractions as black boxes at the next level in the
hierarchy.
As an object is used in the system usage hierarchy, it carries with it a
description of its inherent behavior as defined in one or more inheritance
 OBJECT-OR1ENTED SYSTEM DEVELOPMENT METHODS 169

hierarchies. Inheritance is exhibited in the box structure development process

by building new classes from existing classes during systems development.
After an object has been instantiated in a system design, the designer has
the freedom to modify the object design by altering the state design of the
state box and the procedural design of the clear box. If the modified object
is designated for reuse, then a choice can be made as to its representation
in the reuse repository. The new object class, from black box to clear box,
can be stored as a unit or the new subclass can be stored as a set of modifica-
tions with a pointer to the existing superclass. Thus, an inheritance hierarchy
of object classes can be developed. The physical structure of the hierarchy
is a representation issue based upon an optimization of the reuse repository.
Thus, an object is defined and stored in the form of a generic common
service. (We note that this definition of the object inheritance hierarchy
would cause some to describe box structure methods as object-based rather
than truly object-oriented.)

3.4.5 Other Object- Oriented Features

Based upon the fact that the box structure theory supports the four essen-
tial elements of the object model, we conclude that box structures support
object-oriented system development. In fact, box structures provide impor-
tant extensions for object-oriented systems development. These extensions
include the isolation and verifiability of all creative design steps in small
units and systematic derivation of the design in a top-down hierarchy for
intellectual design control. Thus, there is no need to develop transforma-
tional functions to tie objects together, as is required in current object-
oriented design methods (Jalote, 1989).
Box structure methods support a high level of object reuse. In a top-down
manner, each object in the system hierarchy is stored in its three box structure
views in a system development repository. Certain of these objects, usually
the smaller objects at lower levels in the hierarchy, can be selected for future
reuse. Special design requirements are then imposed on the objects, such as
interface standards, documentation standards, and certification require-
ments. These reusable objects are migrated to large organizational reposit-
ories as object classes for potential reuse across all development projects. By
including all three box views of the object in the reuse repository, a verified
design trail of the object from requirement to detailed design is available for
evaluation and use during reuse decisions.
During design, reuse decisions are made for a given black box requirement.
It may be possible to find a reusable object type in the reuse repository that
meets the requirement. (Current research on repository structures and access
methods for reuse is reported in Biggerstaff and Perlis [ 19891.) We recognize
170 A. R. HEVNER

several forms of object instantiation for reuse during a systems development:

Organization-wide object instantiation would encapsulate information

and operations used by many systems. Such objects would include
database-file management systems, common user interfaces, and sen-
sors that maintain the state of physical properties (e.g., temperature,
pressure).
System-wide object instantiation would encapsulate information (e.g.,
data types and constants) and operations used in several different places
in the system usage hierarchy, but not outside of the system. Examples
would include commonly used data structures and their operations
(e.g., files, stacks, queues) and monitors for critical sections of the
system.
One-time object instantiation would allow reuse of information and
operations without information sharing. This would be beneficial
primarily for reusing existing program code.

The first two forms of object instantiations are examples of box structure
common services.

4. The Cleanroom System Development Process

Figure 10 shows the complete cleanroom system development process
(CSDP). While the development activities in the diagram may look familiar,
CSDP stands apart from traditional development approaches by emphasiz-
ing a number of formal development concepts. The disciplined application
of these ideas lead to rigorous systems development under statistical quality
control.

4.1 Cleanroom Concepts

We identify four cleanroom concepts as critical to the development of an
integrated environment for CSDP.
Incremental Development. As discussed in Section 2.4, the intellectual con-
trol of complex system development requires dividing the system into
manageable increments. Incremental development clearly reflects the iter-
ative, spiral nature of real system development work.
Box Structured Analysis and Design. Box structures provide the central
development concepts of CSDP. They provide the mathematical rigor
necessary to support both object-oriented and formal system development.
Correctness Verification. Two types of correctness verification are used in
CSDP. During the design activity, each creative design expansion from
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 171

REQUIREMENTS TEAM

DOCUME~TATIONTEAM

GENERATION DOCUMENTATION

I
N

-
/\

CERTIFIED SYSTEM

FIG. 10. The cleanroom system development process.

black box to state box and from state box to clear box can be verified
immediately for consistency and closure. A state box (clear box) deriva-
tion produces a unique black box (state box). By comparing the derived
black box (state box) with the original black box (state box), the design
expansion can be verified as consistent. Closure can be determined by
ensuring that all stimuli, state, and responses in each box are sufficient
and necessary to support the required system functionality. Iteratively, as
the design evolves, CSDP calls for the design team to perform thorough
functional uerifications. In a group setting, the team develops a proof that
the design correctly implements the requirement specification for
the increment under consideration. The mathematical foundations of func-
tional verification can be found in Linger et al. (1979).
Reliability Certification. The testing team uses the requirement speci-
fication and the usage specification to build a set of random test cases.
The test team can build test cases for an increment in parallel with the
increment design since the requirement specifications are sufficient to
define system functionality. Once the increment is designed and implemen-
ted, it is integrated with previous increments and statistical testing is
172 A. R. HEVNER

performed. The reliability of the implemented system is analyzed via mean-

time-to-failure (MTTF) analysis. Executing the test cases produces a series
of times between system failures. The design team repairs whatever prob-
lems cause the failures. This data is submitted to a certification model to
calculate MTTF, which is used to determine whether the system is under
statistical quality control (Currit, Dyer, and Mills, 1986; Mills and Poore,
1988). If not, the testing is stopped and the increment is redesigned. If
statistical quality control is achieved, then the system can be released with
an estimate of quality based on MTTF reliability.

Together, the cleanroom concepts support a rigorous methodology for sys-

tem development (Mills et al., 1987a; Cobb and Mills, 1990). For the pur-
poses of this chapter, we now expand on the use of box structures as a basis
for a comprehensive set of OOSD methods within CSDP.

4.2 OOA and OOD with Box Structures

Cleanroom supports an object-oriented systems development methodol-
ogy that consists of five phases. The order of performance of the phases
during a system development is based on the spiral paradigm in which the
next phase of development is determined by the results of the previous
phases. This requires definite result milestones and strict management
control of the development process. The five development phases are

1. Problem DeJinition. A clear problem statement must be generated to

provide a basis for system development. Extensive domain analysis is
essential for complete problem understanding.
2. Requirements Definition. Requirements are elicited from the system
domain experts and system users. The requirements are represented in
formats that facilitate customer review and feedback.
3. Analysis. The system requirements are analyzed and information is
gathered to support subsequent design decisions. The discovery of rel-
evant, reusable objects is an important part of analysis.
4. Design and Verijication. Definitive design decisions are made and the
system design is grown via top-down functional decomposition in a
usage hierarchy. Each creative design step is verified to be a correct
expansion of the existing design.
5 . Implementation. The system design is transformed into an operational
system. The final system will be a combination of hardware, software,
firmware, and human behavior components. The boundaries and inter-
faces among these components must be specified in the final system
design.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 173

Our emphasis in this section is to detail the processing found in the middle
three phases and to demonstrate the inherent object orientation of the box
structure development process. The phases of requirement definition, analy-
sis, and design and verification will be performed as a tightly integrated,
iterative process. The ability to achieve this tight integration comes about
because of the unifying box structure concepts and representations. (In the
following presentation, the term box structure will be used to refer to a
component in the system hierarchy; however, the term object could be used
with equivalent meaning.)

4.2.1 Requirements Definition

The input into the requirements definition phase is a complete problem
statement, typically presented as a structured English document. Investiga-
tion tasks are performed in order to precisely determine the requirements of
a system that solves the presented problem. Note that the requirement defi-
nition phase is performed for each box structure in the usage hierarchy.
Requirements for any level of system object can be represented in a box
structure format. The ultimate goal would be to state all requirements in a
state-free, procedure-free black box. Defining requirements solely as a black
box places no constraints on the eventual design. Four box structure
operations are performed iteratively during this phase :
Requirement Determination. Requirement determination involves a series
of investigation activities in which system requirements are specified. The
information is gathered via techniques such as user interviews, ques-
tionnaires, documentation review, and analyzing existing applications.
The gathered requirement information is represented in box structure
formats.
Black Box Definition. The black box of the system is completely defined
based on the requirements for the system. The black box is defined by
identifying its stimuli, responses, and the transactions that map stimulus
histories into responses.
Black Box Analysis. Black box analysis evaluates the quality and com-
pleteness of the black box specification. For example, transaction closure
would ensure that all stimuli are necessary and sufficient in the system.
Black Box Requirement Review. The defined black box is reviewed by
customers and developers to determine whether it truly represents the
desired system requirements. The review involves the users and managers
of the system.
The transactions in a black box are defined as mathematical functions for
deterministic behavior or mathematical relations for nondeterministic
174 A. R. HEVNER

behavior. For high-level, complex box structures it may be necessary to

provide the function or relation in the natural language of the problem
domain, often a mixture of formal and informal language. Whatever the
notation, the black box description is a set of mathematical functions, one
per transaction.
Often system requirements do contain design constraints on such things
as the availability and use of data or the need to conform to a defined
procedure. Such requirements cannot be recorded in a black box; thus, a
clear statement of state box and clear box design constraints must be pro-
vided. In addition, certain “nonfunctional” requirements, such as perfor-
mance, behavioral, and documentation standards, can be stated in structured
English forms. It is important during requirement reviews that the system
owners understand that any requirements beyond a black box are constraints
upon the system’s design freedom In this process, many nonessential require-
ments can be discovered and eliminated.
The results of the requirements definition phase are a precisely defined
black box with accompanying state box, clear box, and nonfunctional design
constraints. This box structure requirement is stored in a repository as the
initial definition of the system object.

4.2.2 Analysis
Analysis is performed to support the decisions that must be made during
systems design. It is part of the creative box structure operations of state
box expansion and clear box expansion. The box structure requirement is
analyzed and information is gathered to enable one or more of the following
types of activities:

0 Feasibility studies are performed to determine the feasibility and cost/

benefit of potential designs.
0 Reuse opportunities are explored. Repositories of system objects from
this project or existing systems can be investigated for requirements
matching. The cost/benefit of reusing existing objects, along with any
required modifications, would be done at this point.
0 Prototyping can be performed to evaluate design alternatives. The pro-
totype development process will take on a life of its own with the
five development phases performed in an iterative manner. Objects
developed in the prototype may be candidates for reuse and mod-
ification in the final system.
Trade-ofl studies evaluate the advantages and disadvantages of design-
ing and implementing the current box structure as hardware, software,
 OBJ ECT-OR1ENTED SYSTEM D EVELOPMENT METHODS 175

firmware, human behavior, or some combination thereof. Such

decisions will impact reuse opportunities and interface designs.
0 Reuse potential should be analyzed for the current box structure. If the
decision is made to design the box structure as a reusable object, then
reuse standards may dictate certain design decisions (e.g., interface
standards).

The preceding types of analyses are essential to support high-quality system

designs. The information, analysis, and conclusions of these studies are
recorded with the evolving box structure in the system repository. Some
analysis discoveries may cause changes in the system requirements, thus,
iteration between the phases of requirements definition and analysis is to be
expected and encouraged.

4.2.3 Design and Verification

This phase takes the box structure requirement and analysis results and
produces a complete design specification of the box structure. First, the state
box is designed from the black box requirement specification.
State Box Expansion. The state of the system is created by encapsulating
required stimulus history in a state box. Data design methods, such as
entity-relationship models, are used to create a state design. An internal
data abstraction is designed to map stimuli and state into responses and
new state.
State Box Analysis. State box analysis evaluates the quality and complete-
ness of the state box design. The principles of transaction closure and
state migration are applied. Data design metrics, such as level of data
normalization, are used to evaluate the quality of the design decisions.
Black Box Derivation. The black box derivation operation discovers the
black box representation of a given state box. A state box can be verified
as correct by deriving an equivalent black box as compared to the original
black box requirement.
The completed and verified state box is stored in the repository. The clear
box can now be designed.
Clear Box Expansion. Clear box expansion is a creative step whose pur-
pose is to design the procedural structure of the system. The uses of black
box subsystems at the next level of design are identified. The intellectual
control of stepwise system decomposition is contained in this operation.
Clear Box Analysis. Clear box analysis evaluates the quality and com-
pleteness of the clear box design. The principles of transaction closure,
176 A. R. HEVNER

state migration, and common services are applied. Design metrics of struc-
tured programming can be used to study the clear box procedural design.
State Box Deviation. The state box derivation operation discovers the
state box representation of a given clear box. A clear box can be verified
as correct by deriving an equivalent state box as compared to the original
state box.
The design and verification of the clear box completes the detailed design
of the current box structure. The complete specification of the box structure
object, from the black box requirement, through the intermediate state box,
to the final clear box design, is stored in the system repository. Then, the
complete box structure development process is invoked recursively on each
internal black box in the clear box.
The procedural clear box design, developed in clear box expansion,
ensures that each internal black box is referentially transparent from all
other peer black boxes and common services in the clear box. Thus, each
black box can be designed independently. For each black box requirement
the development process of requirement definition, analysis, and design and
verification begins. Note that much of the work performed, and dutifully
recorded in the repository, for higher-level box structures in the hierarchy
can be used in the analysis and design of lower-level box structures. The
desired system is complete when no further black box requirements exist in
the leaves of the box structure usage hierarchy. The detailed design of the
complete system is then sent to the final phase of system implementation.
The appendix to this chapter illustrates the use of box structures for the
development of a realistic information system for a car rental agency. This
case study demonstrates the application of both box structure graphics and
the box description language (BDL) for system analysis and design.

4.3 Critique of Box Structure Methods

Box structures provide many of the features required for rigorous and
systematic OOSD. The following observations provide a summary of box
structure methods:

0 Box structures provide for the definition of data abstractions and

objects in three mathematical views.
0 The box structure usage hierarchy allows intellectual control over the
development process.
0 Each box structure in the system usage hierarchy is an object.
0 All design inventions are separated into clearly identified small steps.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 177

0 Design verification is performed after each invention step of design and

provides a systematic basis for inspection.
0 An object is stored in the system repository in all box structure views,
from black box requirement to clear box detailed design.
0 Certain objects can be designated and designed for reuse. Such objects
will be stored in special reuse libraries.
0 Box structures support an integrated development process, in that there
is no need to transform the representation or content of development
information from one phase to another.
0 The systems development process is completely flexible between devel-
opment phases. The next phase to be performed is based upon feedback
from previous work results. The development of a system box structure
usage hierarchy provides a discipline of sound and complete design.

A current weakness of the box structure approach for OOSD is that

inheritance among objects and classes is supported to only a limited extent.
The principles of referential transparency and state migration provide guid-
ance to the construction of class hierarchies in an application usage hierar-
chy. However, persistence of a class hierarchy depends on the development
of a common service that embodies it. Then, inheritance is provided by the
reuse and modification of existing common service class hierarchies.
CSDP and box structure methods have been used successfully in a number
of experimental and actual projects (Linger and Mills, 1988; Cobb and Mills,
1990). Since the cleanroom ideas originated in IBM under Harlan Mills,
IBM has been the leader in the development of cleanroom pilot projects.
However, increasingly more organizations are using cleanroom concepts in
their system developments. More experience with cleanroom is needed in
order to validate claims of development productivity and system quality,
but, the results achieved so far are very encouraging (Cobb and Mills, 1990;
Selby, Basili, and Baker, 1987).

5. Conclusions and Future Research Directions

Object orientation is here. This new way of viewing systems has generated
tremendous excitement in the system and software engineering communities.
System researchers, developers, and users are striving to understand the basic
concepts of object-orientation and, more important, the implications
of object orientation for system development and operation. Important
questions are being asked:

0 Does object orientation provide improved development productivity

and system quality?
178 A. R. HEVNER

0 Is it cost beneficial and timely to commit to object-oriented system

development methods?
0 Is the future object oriented?
There are no simple or definitive answers to these questions. However, the
material presented in this chapter provides a start toward understanding the
issues of object orientation.
To begin, object concepts and principles are defined. No formal definition
of an object is currently accepted by researchers and developers in this area.
Thus, we find a wide disparity in object-oriented terminology, notation, and
representation.
In Section 2, we survey the state of current object-oriented system develop-
ment. The spiral paradigm of system development is inherent in OOSD.
Varying levels of maturity have been achieved in the areas of object-oriented
analysis, object-oriented design, and object-oriented implementation and
testing. Several object-oriented programming languages and object-oriented
database systems are well-tested and commercialized instruments for use in
OOIT. Methods for OOA and OOD are being proposed and promulgated
for use. A critique of the current state of OOSD concludes the survey.
As an example of an integrated system development methodology that
supports both object-oriented and formal concepts, the cleanroom system
development process is presented. The central box structure concepts are
shown to support object orientation in system development. Within CSDP,
methods of OOA and OOD using box structures are employed. The appen-
dix to the chapter summarizes a case study that demonstrates the use of box
structures in a realistic system development. A critique of CSDP discusses
the need for more experience with the practical application of cleanroom
concepts in real development projects.
Results are needed in many areas of object-oriented research and develop-
ment before maturity of the field can be reached. New, innovative ideas are
being sought in the following five areas.
Common Object Dejinitions. As more organizations use OOSD, it becomes
increasingly important that developers use common terminology, nota-
tion, and representation. The ability to share and reuse analysis and design
artifacts, both within and outside of an organization, is an important goal.
An accepted definition of an object as a formal mathematical construct
would be a major step toward standardization of object-oriented concepts.
Toward this end, a study at Hewlett-Packard Laboratories has produced
a glossary of common object-oriented terminology (Snyder, Hill, and
Olthoss, 1989).
Integrated Computer Aided System Engineering (ICASE). A principal
inhibiting factor in the use of object-oriented and formal methods is the
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 179

lack of CASE tools and CASE environments. Much research and develop-
ment is needed before integrated CASE is a reality. Current work on
integrated development architectures, such as IBM’s AD/Cycle (Mercurio
et al., 1990), is a step in the right direction. Research directions to more
fully enable object-oriented CASE include
0 The need for further research on OOA and OOD methods and represen-
tations. In particular, effective ways for representing and managing
both functional and non-functional system requirements will be
important.
0 The central repository for a completed project must be maintained for
systems operations and systems maintenance. Keeping the repository
up to date in the presence of system evolution must be an efficient
process. A claim of object-oriented methods is that the resulting systems
provide more efficient maintenance and evolution. Experimental
research is needed to validate this claim.
0 Information from each project repository should be integrated into a
corporate repository for use by future system development projects.
This will result in the potential reuse of common service objects across
many systems.
A simple CASE tool has been produced for the Coad and Yourdon (1991)
OOA method. Other research on object-oriented CASE include the
Demeter system (Lieberherr and Riel, 1988) and cleanroom ICASE
(Hevner, Becker, and Pedowitz, 1992).
Qualify Control. The production of a top-quality system is a priority of
any system development process. How do we define and measure system
and software quality in object-oriented systems? Research on software
metrics and verification and validation (V&V) techniques is growing rap-
idly in importance (Wallace and Fujii, 1989). The principle rationale for
cleanroom methods is the application of statistical quality control to
software development (Mills et al., 1987a).
Concurrent and Real- Time Systems. Concurrent processing environments
have increasing viability and importance for computer-based information
systems. There are great needs for rigorous methods and tools for the
analysis and design of concurrent systems. Dynamic modeling of concur-
rency allows a developer to modify and evaluate a concurrent system
design until a correct and efficient design is achieved. Modeling tools,
such as simulation, queueing theory, and Petri-nets have been applied to
evaluate concurrency. However, these tools are not integrated well into
analysis and design activities (Becker and Hevner, 1991). Research is
also being performed to develop improved OOP capabilities to implement
concurrent systems (Agha, 1990).
180 A. R. HEVNER

Reverse Engineering. The reengineering of existing systems to object ori-

entation will be a very challenging problem. Immense inventories of poor-
quality systems and software severely impair the ability of organizations
to grow and, even, to survive. Reverse engineering is now recognized as a
critically needed area of research and development (Chikofsky and Cross,
1990). Bringing the benefits of object orientation to existing non-object-
oriented systems will be an area of fruitful study in the future.

Acknowledgments
I wish to acknowledge the many discussions that I have had on cleanroom
and box structure ideas with Richard Linger, Shirley Becker, Jesse Poore,
Richard Cobb, Phil Hausler, and Mark Pleszkoch. In particular, I thank
Harlan Mills for sharing with me his invaluable insights on system develop-
ment and object orientation.

REFERENCES
Current research and development activity in all object-oriented fields is reported annually
in the “Conference on Object-Oriented Programming: Systems, Languages, and Applications
(OOPSLA)” and the “European Conference on Object-Oriented Programming (ECOOP).”
Research on object-oriented system development is also presented at the annual International
Conference on Software Engineering. A two volume collection of papers on object-oriented
topics has been edited by Peterson (1988).
Abbott, R. (1983). Program Design by Informal English Descriptions, Communicarions of rhe
ACMU(11).
Agha, G . (1990). Concurrent Object-Oriented Programming, Communications of rhe ACM
33(9).
Bailin, S. (1989). An Object-Oriented Requirement Specification Method, Communicafions of
the ACM 32(5).
Banerjee, J., Chou, H., Garza, J., Kim, W., Woelk, D.,Ballou, N., and Kim, H. (1987). Data
Model Issues for Object-Oriented Applications, ACM Trans. on Ofice Informarion Systems

Batory, D., Barnett, J., Garza, J., Smith, K., Tsukuda, K., Twichell, B., and Wise, T. (1988).
GENESIS : An Extensible Database Management System, IEEE Trans. on Software Engin-
eering SE14(11).
Becker, S., and Hevner, A. (1989). Concurrent System Design with Box Structures, “Proceed-
ings of the 13th Annual International COMPSAC,” Orlando, FL.
Becker, S., and Hevner, A. (1991). A Dynamic System Modelling Tool Using Box Structures
and Petri Nets, “Proceedings of the Second International Working Conference on Dynamic
Modeling of Information Systems,” Washington, DC.
Biggerstaff, T., and Perlis, A. (1989). “Software Reusability: Vol. I-Concepts and Models”;
“Vol. 2-Applications and Experience.” ACM Press, Addison-Wesley, Reading, MA.
Boehm, B. (1988). A Spiral Model of Software Development and Enhancement, IEEE Com-
puter 21(5).
Booch, G . (1986). Object-Oriented Design, IEEE Trans. on Sofware Engineering SElZ(2).
 OBJ ECT-OR I ENTED SYSTEM D EVELOPMENT M ETHO DS 181

Booch, G. (1987a). “Software Engineering with Ada,” 2nd ed. Benjamin Cummings, Menlo
Park, CA.
Booch, G. (1987b). “Software Components with Ada: Structures, Tools, and Subsystems.”
Benjamin Cummings, Menlo Park, CA.
Booch, G. (1991). “Object Oriented Design with Applications.” Benjamin Cummings, Menlo
Park, CA.
Brooks, F. (1987). No Silver Bullet: Essence and Accidents of Software Engineering, ZEEE
Computer 20(4).
Cameron, J. (1989). “JSP & JSD: The Jackson Approach to Software Development.” IEEE
Computer Society Press, Washington, D.C.
Cardelli, L., and Wegner, P. (1985). On Understanding Types, Data Abstraction, and Poly-
morphism, ACM Computing Surveys 17(4).
Carey, M., DeWitt, D., Richardson, J., and Shekita, E. (1986). Object and File Management
in the EXODUS Extensible Database System, “Proceedings of the 12th International Confer-
ence on Very Large Data Bases.” Kyoto, Japan
de Champeaux, D., Constantine, L., Jacobson, I., Mellor, S., Ward, P., and Yourdon, E.
( I 990). Panel-Structured Analysis and Object Oriented Analysis, “Proceedings of the Joint
OOPSLA and ECOOP ’90 Conferences,” Ottawa.
Chen, P. (1976). The Entity-Relationship Model-Toward a Unified View of Data, ACM
Trans. on Database Systems l(1).
Chikofsky, E., and Cross, J. (1990). Reverse Engineering and Design Recovery: A Taxonomy,
ZEEE Software 7(1).
Coad, P., and Yourdon, E. (1991). “Object-Oriented Analysis,” 2nd ed. Prentice-Hall, Engle-
wood Cliffs, NJ.
Cobb, R., and Mills, H. (1990). Engineering Software under Statistical Quality Control, IEEE
Software 7(6).
Constantine, L. (1989). Object-Oriented and Structured Methods : Toward Integration, Amer-
ican Programmer 2(7-8).
Cox, B. (1986). “Object-Oriented Programming: An Evolutionary Approach.” Addison-
Wesley, Reading, MA.
Currit, A., Dyer, M., and Mills, H. (1986). Certifying the Reliability of Software, ZEEE Trans.
on Software Engineering SE12( 1).
Danforth, S., and Tomlinson, C. (1988). Type Theories and Object-Oriented Programming,
ACM Computing Surveys 20(1).
Davis, A. (1990). “Software Requirements: Analysis and Specification.” Prentice-Hall, Engle-
wood Cliffs, NJ.
Dijkstra, E. (1968). The Structure of the “THE’ Multiprogramming System, Communications
of the ACM ll(5).
Fishman, D., Beech, D., Cate, H., Chow, E., Connors, T., Davis, J., Derratt, N., Hoch, C.,
Kent, W., Lyngbaek, P., Mahbod, B., Neimat, M., Ryan, T., and Shan, M. (1987). Iris: An
Object-Oriented Database Management System, ACM Trans. on Ofice Information Systems
%I).
Gannon, J., Hamlet, R., and Mills, H. (1987). Theory of Modules, IEEE Trans. on Soffware
Engineering S E l 3 ( 7 ) .
Goldberg, A,, and Robson, D. (1989). “Smalltalk-80: The Language.” Addison-Wesley,
Reading, MA.
Guttag, J. (1980). Notes on Type Abstraction, ZEEE Trans. on Software Engineering SE6(1).
Hausler, P., Linger, R., Pleszkoch, M., and Hevner, A. (1990). Using Function Abstraction to
Understand Program Behavior, ZEEE Software 7( I).
Henderson-Sellers, B., and Edwards, J. (1990). The Object-Oriented Systems Life-Cycle,
Communications of the ACM 33(9).
182 A. R. HEVNER

Hevner, A,, and Linger, R. (1989). A Method for Data Re-engineering in Structured Programs,
“Proceedings of the 22nd Annual Hawaii International Conference on System Sciences,
Vol. ]-Software Track.”
Hevner, A., and Mills, H. (1992). Box-Structured Methods for Systems Development with
Objects, IBM Systems Journal, to appear.
Hevner, A., Wilkey, J., Milhiser, C., and Sullivan, K. (1990). CARS, A Case Study of Box-
Structured Systems Development, Working Paper, Information Systems Department, Uni-
versity of Maryland, College Park.
Hevner, A., Wilkey, J., and Becker, S. (1991). CASE Support for Box Structure Systems
Development: A Case Study, “Proceedings of the 24th Annual Hawaii International Confer-
ence on System Sciences, Vol. 11-Software Technology Track.”
Hevner, A., Becker, S., and Pedowitz, L. (1992). Using ICASE for Cleanroom Development,
IEEE Software, 9( I).
Hughes, J. (1991). “Object-Oriented Databases.” International Series in Computer Sciences,
Prentice-Hall, Englewood Cliffs, NJ.
Hull, R., and King, R. (1987). Semantic Database Modelling: Survey, Applications, and
Research Issues, A CM Computing Surveys 19(3).
IEEE Software. (1992). Special Issue on Integrated CASE Systems, IEEE Software, 9( I).
IEEE TKDE. (1990). Special Issue on Database Prototype Systems, IEEE Trans. on Knowledge
and Data Engineering 2(1).
Jalote, P. (1989). Functional Refinement and Nested Objects for Object-Oriented Design, IEEE
Trans. on Software Engineering SE-15(3).
Kim, W. (1990). Object-Oriented Databases : Definition and Research Directions, IEEE Trans.
on Knowledge and Data Engineering 2(3).
Kim, W., and Lochovsky, F., eds. (1989). “Object-Oriented Concepts, Databases, and Applica-
tions.” ACM Press, Addison-Wesley, Reading, MA.
Korson, T., and McGregor, J. (1990). Understanding Object-Oriented: A Unifying Paradigm,
Communications of the ACM 33(9).
Kowal, J. (1988). “Analyzing Systems,” Prentice-Hall, Englewood Cliffs, NJ.
Lehman, T., and Lindsay, B. (1989). The Starburst Long Field Manager, “Proceedings of the
15th International Conference on Very Large Databases,” Amsterdam.
Lieberherr, K., and Riel, A. (1988). Demeter: A {CASE} Study of Software Growth Through
Parameterized Classes, Journal of Object-Oriented Programming l(3).
Linger, R., and Mills, H. (1988). A Case Study in Cleanroom Software Engineering: The IBM
Cobol Structuring Facility, “Proceedings of the IEEE COMPSAC,” Chicago.
Linger, R., Mills, H., and Witt, B. (1979). “Structured Programming: Theory and Practice,”
Addison-Wesley, Reading, MA.
Liskov, B., Snyder, A., Atkinson, R., and Schaffert, C. (1977). Abstraction Mechanisms in
CLU, Communications of the ACM 20(8).
Loy, P. (1989). A Comparison of Object-Oriented and Structured Development Methods,
“Proceedings of the 1989 Pacific Northwest Software Quality Conference,” Portland.
Martin, J. (1989). “Information Engineering: Book I-Introduction”; “Book 2-Planning and
Analysis”; “Book 3-Design and Construction.” Prentice-Hall, Englewood Cliffs, NJ.
Manola, F. (1989). An Evaluation of Object-Oriented DBMS Developments, Technical Report
TR-0066-10-89-165, GTE Laboratories Inc.
Mercurio, V., Meyers, B., Nisbet, A., and Radin, G. (1990). AD/Cycle Strategy and Architec-
ture, IBM Systems Journal 29(2).
Meyer, B. (1987). Reusability: The Case for Object-Oriented Design, IEEE Software 8(4).
Meyer, B. (1988). “Object-Oriented Software Construction.” Prentice-Hall, Englewood Cliffs,
NJ.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 183

Mills, H. (1986). Structured Programming: Retrospect and Prospect, IEEE Software 3(4).
Mills, H. (1988). Stepwise Refinement and Verification in Box-Structured Systems, IEEE
Computer 21(6).
Mills, H., and Poore, J. (1988). Bringing Software Under Statistical Quality Control, Quality
Progress.
Mills, H., Linger, R., and Hevner, A. (1986). “Principles of Information Systems Analysis and
Design.” Academic Press, Inc. Boston, MA.
Mills, H., Dyer, M., and Linger, R. (1987a). Cleanroom Software Engineering, IEEE Software
4(5).
Mills, H., Linger, R., and Hevner, A. (1987b). Box Structured Information Systems Develop-
ment, IBM Systems Journal Xi(4).
Orr, K. (1977). “Structured Systems Development.” Yourdon Press, Prentice-Hall, Englewood
Cliffs, NJ.
Parnas, D. (1972). On the Criteria to Be Used in Decomposing Systems into Modules, Commu-
nications of the ACM 15(12).
Parnas, D. (1974). On a ‘‘Buzzword’’ Hierarchical Structure, “Proceedings of the IFIP Congress
1974.” North-Holland, Amsterdam.
Parnas, D., Clements, P., and Weiss, D. (1985). The Modular Structure of Complex Systems,
IEEE Trans. on Software Engineering SE-ll(3).
Peterson, G., (1988). “Tutorial: Object-Oriented Computing, Vol. 1 : Concepts, Vol. 2: Imple-
mentations.” Computer Society of the IEEE. Washington, D.C.
Ramamoorthy, C., and Sheu, P. (1988). Object-Oriented Systems, IEEE Expert 3(3).
Reenskaug, T. (198 I). User-Oriented Descriptions of Smalltalk Systems, Byte (August).
Reenskaug, T., and Nordhagen, E. (1989). The Description of Complex Object-Oriented
Systems, Technical Report, Senter for Industriforskning, Norway.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1991). “Object-Orien-
ted Modeling and Design.” Prentice-Hall, Englewood Cliffs, NJ.
Seidewitz, E., and Stark, M. (1986). Towards a General Object-Oriented Software Development
Methodology, “Proceedings of the First International Conference on Ada Programming
Language Applications for the NASA Space Station.”
Selby, R., Basili, V., and Baker, F. (1987). Cleanroom Software Development: An Empirical
Evaluation, IEEE Trans. on Software Engineering SE-13(9).
Shaw, M. (1984). Abstraction Techniques in Modem Programming Languages, IEEE Software
1(4).
Shlaer, S., and Mellor, S. (1988). “Object-Oriented Systems Analysis.” Prentice-Hall, Engle-
wood Cliffs, NJ.
Shriver, B., and Wegner, P., eds. (1987). “Research Directions in Object-Oriented Program-
ming,” MIT Press, Cambridge, MA.
SIGPLAN Notices. (1989). “Proceedings of the ACM SIGPLAN Workshop on Object-Based
Concurrent Programming,” SIGPLAN Notices 24(4).
Sincover, R., and Wiener, R. (1984). Modular Software Construction and Object-Oriented
Design Using Ada, Journal of Pascal, Ada, and Modula-2 (March-April).
Snyder, A,, Hill, W., and Olthoss, W. (1989). A Glossary of Common Object-Oriented Termin-
ology, Report STL-89-26, Software Technology Laboratory, Hewlett-Packard Laboratories,
Palo Alto, CA.
Stonebraker, M. ( 1986). Inclusion of New Types in Relational Data Base Systems, “Proceedings
of the International Conference on Data Engineering.” Los Angeles, CA.
Stroustrup, B. (1988). What Is Object-Oriented Programming? IEEE Software 5(3).
Teorey, T., Yang, D., and Fry, J. (1986). A Logical Design Methodology for Relational
Databases Using the Extended Entity-Relationship Model, ACM Computing Surveys 18(2).
184 A. R. HEVNER

Wallace, D., and Fujii, R. (1987). Software Verification and Validation: An Overview, IEEE
Software 6(3).
Ward, P. (1989). How to Integrate Object Orientation with Structured Analysis and Design,
IEEE SoJfware 8( I).
Wegner, P. (1990). Concepts and Paradigms of Object-Oriented Programming, OOPS
Messenger 1(1), ACM SIGPLAN Publication.
Wing, J. (1990). A Specifier’s Introduction to Formal Methods, IEEE Computer U(9).
Wirfs-Brock, R., and Johnson, R. (1990). Surveying Current Research in Object-Oriented
Design, Communications of rhe ACM 33(9).
Wirfs-Brock, R., Wilkerson, B., and Wiener, L. (1990). “Designing Object-Oriented Software.”
Prentice-Hall, Englewood Cliffs, NJ.
Yourdon, E. (1989). “Modern Structured Analysis.” Yourdon Press, Prentice-Hall, Englewood
Cliffs, NJ.

Appendix: A Case Study of Box Structured Design-The

CARS System
To demonstrate the use of box structures on a realistic system develop-
ment, we analyzed and designed a car rental information system. Here, a
brief summary of the system design is presented, highlighting the use of box
structures. The complete development record and the final design spec-
ification of the CARS case study is found in Hevner et al. (1990). We have
implemented CARS as a single-user prototype in the Ada programming
language.

A.l CARS Problem Statement

The convenient auto rental system (CARS) case study is adapted from
(Kowal, 1988). In that text, the system design is developed using the struc-
tured analysis and design methods popularized by Yourdon and DeMarco
(Yourdon, 1989). In this appendix, we present our analysis and design of
CARS via box structure methods.
Briefly, the problem statement for CARS is as follows. CARS takes reser-
vations for autos, issues autos and AUTO-CARDS to customers, accepts
returned cars, computes and issues bills to customers, exchanges autos with
a central auto pool based on an anticipated level of business, controls access
to the parking lot by means of automatic gates, refuels autos, and schedules
periodic and emergency maintenance for each auto. The AUTO-CARD has a
magnetic strip on which is contained all necessary information to enable the
necessary customer functions in the system. In addition, each auto comes
equipped with a mobile telephone. Calls made from the phone are billed to
the customer. Logs of all system transactions are maintained and entered
into archives at the end of each day.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 185

Note that the system has requirements for three on-line, real-time activi-
ties: to control fuel pumps to refuel autos, to control gate access to parking
lot, and to record phone calls from autos. We will highlight our analysis and
design of these real-time functions in this appendix.
Based on the given problem statement, we developed CARS using the box
structure methods. For expository purposes and because of space limitations,
we will state the black box requirements for the system, show the principal
state data design, and then present a portion of the CARS system design in
clear boxes. We will use the box description language, augmented by several
key box structure graphics, to present the design of the clear boxes.

A.2 Black Box Transactions of CARS

CARS can be initially described as a set of black box transactions. Each
black box transaction is described by its transition behavior in terms of
stimuli.and responses.

1. Daily-startup. The system is started and initialized each day by this

routine. New cars from the central auto pool are entered into the
system. If updates to the charging rates are needed for the car types
or the. insurance, they are changed in this transaction. The daily fuel
cost is updated.
2. Reservations. Given the stimuli information, a reservation is entered
into the system. A unique confirmation number is given to the
customer.
3. Car-pickup. The customer presents a confirmation number or a name
and address along with driver’s license number and insurance decision.
A specific car is assigned and a contract (with a unique contract
number) is written. The customer is handed an AUTO-CARD, keys,
contract copy, and is told the location of the car. (The AUTO-CARD
contains the contract number on a magnetic strip.) If no car is avail-
able in the desired type, the customer is offered a free upgrade. If for
any reason the transaction does not result in a contract, the customer
is offered an apology and the customer leaves the system.
4. Gate-manager. Entering the AUTO-CARD into a reader sends a signal
to the system. The AUTO-CARD and request are checked for validity.
If valid, the gate is opened. A mechanical device in the gate senses
when the car has passed through the gate. After a brief delay, the gate
is closed automatically. If the gate request is invalid, a message is sent
to security to come to the gate.
5. Telephone-use. The customer enters the AUTO-CARD into a slot in the
in-car telephone. Upon a connection, the start time and the number
186 A. R. HEVNER

dialed are recorded on the AUTO-CARD. Upon call completion, the

stop time is recorded on the AUTO-CARD.
6 . Return-car. As the customer returns the car, he or she enters the
AUTO-CARD into a reader where it is read for contract number and
phone charges. The keys are left in the car. The customer may enter
any maintenance problems into a terminal. An attendant then takes
over and enters current mileage and fills the car with fuel. A mainten-
ance order is prepared by an attendant who checks the car and notes
any maintenance conditions. The customer problems are included on
the maintenance order.
7. Fuel-manager. Once the attendant starts the fuel pump, the system
monitors the system status and shuts off the fuel upon receipt of a
full signal. Two fuel cycles are monitored, a FAST fueling and a SLOW
fueling. The pumped fuel load is recorded and charged to the
customer.
8 . Customerjayment. The customer presents either a contract number
or a name and address. The amount due is calculated based on all
of the charges accumulated. The customer provides payment. The
manager may be called if this transaction cannot be performed in a
normal manner.
9. Maintenance. Given the auto license number and the maintenance
order the system assigns an appropriate attendant to provide any
minor maintenance to the car before it is returned to service. The
attendant responds with the keys and the car location. If the mainten-
ance is major, the car is removed from the lot that night. If the car
mileage is too high, the car is removed from the lot to be sold.
10. Daily-shutdown. During daily shutdown, cars that are surplus, need
maintenance, or have high mileage are sent to the central auto pool.
Reservations for the next day are scanned to produce a list of car
types to be requested from the central auto pool. A transaction log file
and a hard copy daily report of the day’s transactions are produced.

A.3 State Box Description of CARS

The principal state components will be stored in a file organization com-
mon service system, CARSjiles. This common service will provide an effi-
cient retrieval interface to all users of the files. All other system state is
migrated to lower-level subsystems in the box structure usage hierarchy with
the exception of the daily system transaction log, the daily cost for fuel, and
the parking lot locations, which will be stored at the top level of the box
structure hierarchy of the application system.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 187

We will store four files in CARS-files. In relational notation the files are
as follows: (primary keys of each file are underlined.)

CAR-TYPE ( TYPE-NAME, DAY-RATE, WEEK-RATE,

INSURANCE-RATE)
RESERVATION (CONFIRM_NUMBER, CUSTOMER-RECORD
(FIRST-NAME, LAST-NAME, STREET, CITY, STATE,
ZIP) , TYPE-NAME, STARTING-DATE,
CREDIT-CARD-TYPE, CREDIT-CARD-NUMBER)
CARS (AUTO-LICENSE-NUMBER, STATUS, LOCATION,
TYPE-NAME, NUMBER-OF-DOORS, CAR-MILEAGE)
CONTRACT (CONTRACT-NUMBER, CUSTOMER-RECORD
(FIRST-NAME, LAST-NAME, STREET, CITY, STATE,
ZIP), DRIVERS-LICENSE-NUMBER,
AUTO-LI CENSE-NUMBER , OUT-DATE , IN-DATE ,
RENT-CHARGE, INSURE-CHARGE, FUEL-CHARGE,
*PHONE-CHARGE-RECORD (TIME-START, TIME-STOP,
NUMBER-DIALED))

Here, CUSTOMER-RECORD (. . .) indicates an aggregate attribute and

*PHONE-CHARGE-RECORD (. . .) indicates a repeating group of aggregate
attributes.
We provide six operations on each file:

OPEN opens the file during the daily startup procedure.

CLOSE closes the file during the daily shutdown procedure.
ADD adds new records into the file.
DELETE deletes records from the file.
UPDATE updates values other than the primary key in the file.
GET retrieves a unique record based on the primary key.

The designer of the file system has the capability of building indexes on
the files at the beginning of the day. The indexes are automatically purged
at the end of the day. These operations are LOAD-INDEX and PURGE-INDEX,
respectively.

A.4 Top-Level Clear Box Description for CARS

At the clear box level we recognize and design two additional common
service systems to support real-time system requirements: the telephone-use
188 A. R. HEVNER

common service, which will be duplicated in each rental car; and the monitor-
-system common service, which will be used to monitor the real-time require-
ments of the gate-manager and the fuel-manager subsystems.
The clear box of the top-level of the CARS system will consist of three
sequential subsystems: daily-startup, CARS-on-line (to include all on-line
and real-time transactions), and daily-shutdown. The clear box description
of CARS at the top level is

CLEAR BOX CARS

STIMULUS
Collection of all stimuli in system
transactions
RESPONSE
Collection of all responses in system
transactions
STATE
Transaction-log: List of Transaction record;
Parking-locations: Stack of integer;
Fuel-cost: Real;
COMMON SERVICE
CARS-files (*File organization manager*);
Telephone-use (*Instantiated in each rental
car* ) ;
Monitor-system (*Controls real-time
requirements*);
TRANSACTION
DATA
BEHAVIOR
use Daily-startup;
use CARS-on-line;
use Dai 1y-shutdown;
end CARS.

Figure A. 1 presents the box structure graphic of this design. The clear box
concludes the design of the top-level box structure for CARS. The following
sections present the designs of several major subsystems in CARS. Not all
subsystems are presented here because of space limitations. The complete
design of CARS is contained in (Hevner et al., 1990). Figure A.2 shows the
complete CARS box structure hierarchy for CARS.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 189

CLEAR BOX CARS

STATE:
Transaction-log, Parking-locations, Fuel-co
COMMON SERVICES:
CARS-files, Monitor-system, Telephone-use

‘ i
i
i

Stimuli
1 STARTUP I
- -
\

FIG. A. 1. Top-level CARS clear box design.

A.5 Monitor System Common Service

CARS is composed of sequential and concurrent system components.
Concurrent system components are classified in terms of three characteristics
associated with concurrency : synchronous processing, interaction among
processes, and processing interrupts (Becker and Hevner, 1989). A concur-
rent system component of CARS, the monitorsystem common service, is
presented to demonstrate the box structure design of concurrency.
Two asynchronous concurrent processes, the fuel-manager and the
gate-manager, have been abstracted into the monitor-system design in order
to satisfy the real-time requirements of CARS. Because of the need for
multiple users to share resources in CARS, a monitor is used to accept
external requests and place them in the gate-manager buffers or
fuel-manager buffer. The gate-manager and fuel-manager process asynch-
ronously by continuously removing requests from their buffers, interacting
with the CARS-files common service, and generating appropriate responses.
The monitor-system description follows. Note that the gatemanager man-
ages two buffers, one for exit and one for entry. The abstract data type,
190 A. R. HEVNER

FIG.A.2. Box structure usage hierarchy for CARS.

signal, represents the physical, real-time stimuli and responses with which
the system interacts with its environment.

CLEAR BOX MONITOR-SYSTEM

STIMULUS
Auto-card: Physical-object;
Gate-entry, Gate-exi t: Signal;
Car-sensor: Signal;
On-pump, Bull-signal: Signal;
Fuel-load: Real;
Fuel-cost: Real;
RESPONSE
Gat e-open, Gat e-cl o s e : Signal
S t op-pump: Signal ;
Star t-f as t , Star t-s 1ow: Signal;
Se cur i t y-me s sage : Text ;
Transaction-record: Transaction-log-type;
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 191

STATE
Entry-buffe r: buffer o f C ont ract-number- type;
Exi t-buffe r : buffer o f Contract-number- type ;
Pump-buffer: buffer of Contract-number-type;
COMMON SERVICE
CARS-files: (*File organization manager*);
TRANSACTION
DATA
Time-stamp : Time-type ;
BEHAVIOR
con
select
accept Auto-card (Gate-entry);
do add (Contract-number, Time-stamp) to
Entry-buffer;
or
accept Auto-card (Gate-exit);
do add (Contract-number, Time-stamp) to
Exit-buffer;
or
accept Ant 0- card ( Pump-fuel ) ;
do add (Contract-number, Time-stamp) to
Pump-buffer;
end select;
use Gate-manager;
use Fuel-manager;
noc;
end CLEAR BOX MONITOR-SYSTEM.
With this monitor design, we now show the designs for the gate-manager
and fuel-manager subsystems.

A.5. I Gate-Manager Subsystem Clear Box

Gate-manager controls the gate to the car rental lot as an object. Signals
are sent to open and close the gate. A car sensor signal indicates physical
car entry or exit. The clear box of the subsystem is

CLEAR BOX GATE-MANAGER

STIMULUS
Contract-number: Contract-number-type;
Time-stamp: Time-type;
192 A. R. HEVNER

Car-sensor: Signal;
RESPONSE
Gate-open, Gate-close: Signal;
Security-message: Text;
Transaction-record: Transaction-log-type;
STATE
Gate-position: (UP, DOWN);
COMMON SERVICE
CARS-files (*File organizer manager*);
TRANSACTION
DATA
Val i d-aut0- card: B o o 1ean;
BEHAVIOR
while (Entry-buffer not empty) or (Exit-buffer
not empty)
do retrieve (Contract-number, Time-stamp)
with smallest Time-stamp from Entry-buffer
or Exit-buffer;
if Gate-entry then use Check-entry-request
(stim Contract-number; else
Vali d-auto-card);
else use Check-exit-request (stim
Contract-number; else Valid-auto-card);
end if;
if Valid auto-card then
send Gate-open;
Gate-posi t i on :=UP;
receive Car-sensor;
delay 2 seconds;
send Gate-close;
Gate-posit i on:=DOWN;
if Gate-entry then write (‘Gate-manager
transaction,’ Contract-number,
Gate-entry) to Transaction-log;
else write ( ‘Gatemanager transaction,’
Contract-number, Gate-exit) to
Transaction-log;
end if;
else write (Security-message);
end if;
end while;
end GATE-MANAGER.
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 193

A.5.2 Fuel-Manager Subsystem Clear Box

The fuel-manager subsystem is a real-time procedure. The clear box for
fuel-manager is

CLEAR BOX FUEL-MANAGER

STIMULUS
Contract-number: Contract-number-type;
Time-stamp: Time-type;
On-pump, Full-signal: Signal;
Fuel-load: Real;
Fuel-cost: Real;
RESPONSE
Start-fast, Start-slow: Signal;
St op-pump: Signal;
Transaction-record: Transaction-log-type;
STATE
Pump-status: (OFF, FAST, SLOW) ;
COMMON SERVICE
CARS-files (*File organization manager*);
TRANSACTION
DATA
BEHAVIOR
while Pump-buffer not empty do retrieve
(Contract-number, Time-stamp) with smallest
Time-stamp from Pump-buffer;
(*The attendant inserts hose into gas tank of
car and starts the pump, sending the On-pump
signal to the system*)
receive On-pump;
send Start-fast;
Pump-status :=FAST;
receive Full-signal;
send Start-slow;
Pump status:= SLOW;
receive Full-signal;
send Stop-pump;
Pump status:=OFF;
read (Fuel-load) from Pump;
use CARS-files (CONTRACT, UPDATE,
Fuel-charge :=Fuel-load*Fuel-cost ) ;
194 A. R. HEVNER

write ( ‘Pump-fuel transaction,’

Contract-number, Fuel-load) to
Transaction-log;
end while;
end FUEL-MANAGER.

Note that the design would instantiate the same number of fuel-manager
subsystems as the number of fuel stations concurrently used.

A.6 CARS-On_Line Subsystem

The CARS-on:line subsystem is an on-line system that consists of four
concurrent, asynchronous processes :

1. Reservations transaction,
2. Car-pickup transaction, to include the use of transaction gate manager
for exit,
3. Customer-departure subsystem, to include the sequence of transactions
gate-manager for entry, return-car, and customer-payment,
4. Maintenance transaction.

The clear box for CARS-onIline is

CLEAR BOX CARS-ON-LINE

STIMULUS
Collection of all stimuli from on-line
transactions
RESPONSE
Collection of all responses from on-line
transactions
STATE
Next- re s e rvat i on-numbe r :
Reservation-number-type;
Next-contract-number: Contract-number-type;
COMMON SERVICE
CARS-files (*File organization manager*);
Monitor-system (*Controls real-time
requirements*);
 0 BJECT-0 RI ENTED SYSTEM DEVELOPMENT METHODS 195

TRANSACTION
DATA
BEHAVIOR
con
use Reservation;
use Car-pickup;
use Cust ome r-departure;
use Maintenance;
noc;
end CARS- ON-LINE.

Figure A.3 demonstrates the box structure graphic for Cars-on-line. To

illustrate the use of the monitor-system, we present the clear box design for
the customer-departure subsystem.

A.6. I Customer-Departure
The customer-departure subsystem consists of the sequence of entering
the gate via gate-manager, return-car, and customer-payment. The clear
box for customer-departure i s ,

CLEAR BOX CUSTOMER-DEPARTURE

STIMULUS
Collection o f all stimuli from internal
transactions
RESPONSE
Collection of all stimuli from internal
transactions
COMMON SERVICE
CARS-files (*File organization manager*);
Monitor-system (*Controls real-time
requirements*);
TRANSACTION
DATA
BEHAVIOR
con
use Monitor-system (Gate-entry);
use Return-car;
use Customer-payment;
noc;
end CUSTOMER-DEPARTURE.
 196 A. R. HEVNER

STATE:
Next-reservation-number
Next-contract-num ber

I Reservation I
<
jl I-

T
Stimuli \ Re onse

Y T r e
\

+I----+ Maintenance
 OBJECT-ORIENTED SYSTEM DEVELOPMENT METHODS 197

A.6.1.1 Return-Car
The clear box for return-car is

CLEAR BOX RETURN-CAR

STIMULUS
Auto-card: Physical-object;
Current-mileage: Positive;
Cust-problems: Text;
Keys: Physical-object;
Maint-conditions: Text;
RESPONSE
Maint-order: Text;
Transaction-record: Transaction-log-type;
COMMON SERVICE
CARS-files (*File organization manager*);
Monitor-system (*Controls real-time
requirements*);
TRANSACTION
DATA
BEHAVIOR
read (Contract-number, Phone-charge-records)
from Auto-card;
use CARS-files (CONTRACT, UPDATE,
Phone-charge-records);
read (Cust-problems) from Customer;
use Monitor-system (Pump-fuel);
write (Maint-conditions, Cust-problems) to
Ma int-o rder;
write (‘Return-car transaction,’
Contract-number) to Transaction-log;
end RETURN-CAR.

A.6.1.2 Customer-Payment
Customer-payment subsystem calculates and totals all of the charges on
the rental car. Payment is received from the customer and the customer
leaves the system. The clear box for customer-payment is

CLEAR BOX CUSTOMER-PAYMENT

STIMULUS
Current-dat e : Dat e-type ;
198 A. R. HEVN-ER

Customer-payment: Money-type;
Problems: Bo o l ean;
RESPONSE
Amount-due : Money-type;
Receipt : Physical-objec t ;
Call-manager-message: Text;
Transaction-record: Transaction-log-type;
COMMON SERVICE
CARS-files (*File organization manager*);
TRANSACTION
DATA
Temp-contract-record: Contract-record-type;
BEHAVIOR
read (Contract-number) from customer;
if Contract-number available then
use CARS-files (CONTRACT, GET,
Contract-number);
else
read (Customer-record) from Customer;
use CARS-files (CONTRACT, GET,
Customer-record);
end if;
use Prepare-receipt;
use Collect-payment (else Amount-due,
Problems) ;
if Problem then
write (Call-manager-message);
end if;
use CARS-files (CONTRACT, DELETE,
Contract-number);
write (‘Customer-payment transaction,’
Contract-record) to Transaction-log;
end CUSTOMER PAYMENT.

The subsystem prepare-receipt calculates and totals the car rental

charges (rental-charge), insurance charges (insure-charge), fuel charges
(fuel-charge), and telephone charges (phone-charge-records). A physical
receipt and credit card voucher is prepared and presented to the customer.
The subsystem collecr_payment accepts payment of the amount due or reacts
to nonpayment by setting problems to “true” and calling a manager.