Methods and techniques for

object-oriented analysis and design

Report 94-107

C. Pronk
C. Tercero

Faculteit der Technische Wiskunde en Informatica

Faculty of Technical Mathematics and Informatics
Technische Universiteit Delft
Delft University of Technology
ISSN 0922-5641

Copyright c 1994 by the Faculty of Technical Mathematics and Informatics, Delft, The
Netherlands.
No part of this Journal may be reproduced in any form, by print, photoprint, microfilm,
or any other means without permission from the Faculty of Technical Mathematics and
Informatics, Delft University of Technology, The Netherlands.

Copies of these reports may be obtained from the bureau of the Faculty of Technical
Mathematics and Informatics, Julianalaan 132, 2628 BL Delft, phone +3115784568.
A selection of these reports is available in PostScript form at the Faculty’s anonymous ftp-
site, ftp.twi.tudelft.nl. They are located in directory /pub/publications/tech-reports. They
can also be accessed on the World Wide Web at:
http://www.twi.tudelft.nl/TWI/Publications/Overview.html
 Methods and Techniques for
Object-Oriented Analysis and Design
C. Pronk
1 C. Tercero
2

December 13, 1994

1 Delft University of Technology, Faculty of Mathematics and Informatics, The

Netherlands
2 National University of Technology, Faculty of Electrical and Computer Engineering,
Managua, Nicaragua
Contents
1 Introduction 2
2 Towards object orientation 2
2.1 Methods and techniques : : : : : : : : : : : : : : : : : : : : : : : : : 3
2.2 Existing methods : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4
2.3 The OO-paradigm : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4
2.4 OO-development methods : : : : : : : : : : : : : : : : : : : : : : : : 4
3 Developments in OO-methods 7
3.1 Process phases : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 7
3.2 Analysis : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8
3.2.1 The object model : : : : : : : : : : : : : : : : : : : : : : : : : 8
3.2.2 The behavioural (state) model : : : : : : : : : : : : : : : : : : 9
3.2.3 The functional model : : : : : : : : : : : : : : : : : : : : : : : 9
3.3 Design : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 9
4 Modeling experiences 10
4.1 Usability of models : : : : : : : : : : : : : : : : : : : : : : : : : : : : 10
4.2 Developments : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 10
4.3 Semantics : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11
4.4 Reuse : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11
4.5 Metrics : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12
4.6 Clashes : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12
5 A design example 12
6 An overview of some methods 16
6.1 Objectory : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16
6.2 Object Modeling Technique : : : : : : : : : : : : : : : : : : : : : : : 17
6.3 Booch91/94 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18
6.4 Wirfs-Brock : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 18
6.5 KISS : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 19
6.6 OOA/OOD : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 19
6.7 Shlaer/Mellor : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 20
6.8 Fusion : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21
6.9 Overview : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 22
7 Conclusions and recommendations 23

1
1 Introduction
In recent years a ood of new methods for object-oriented analysis and design of
software has appeared. In this report an overview of the principles behind these
methods and a comparison of a number of up-to-date methods will be presented.
This report has the intention to help the reader in obtaining an outline of this quickly
expanding area and to assist the reader in making an eective choice between several
competing methods.
In section 2 we will sketch some general shortcomings of existing older software
development methods and techniques. A short explanation of how object oriented
methods circumvent these shortcomings will be given together with an overview of
current books and methods on object orientation. Section 3 introduces some develop-
ments in object oriented methods; the notation used in this section is a subset from
OMT (Object Modeling Technique). This particular notation was chosen because
of the authors' familiarity with the method. The analysis of a small system will
be shown in section 4. In section 5 the report continues with an overview of some
well known methods. For each of the methods discussed, a short characterization
of the diagrams and notations used, a description of already known problems with
the method and an overview of available tools will be given. Section 6 concludes
the report with a recommendation on how to introduce object oriented methods in a
practical situation.
This report is not to be seen as an introduction to the subject; the reader is
assumed to have some knowledge of the principles of analysis and design, and of
object orientation.

2 Towards object orientation

The process of developing software systems starts with a phase in which the require-
ments of the software product to be developed are captured and analyzed. In the
next phase a specication, or model, of the program to be developed is constructed.
This specication should be as completely and formally correct as is economically
justied for the project at hand. In the nal phase this specication is transformed
into an executable program.
During the analysis, functional and non-functional requirements on the system to
be developed are collected. We distinguish the following categories of requirements:
1. Management level requirements such as: The product should be nished in time
and be delivered against a xed price.
2. Programming level requirements such as: The program should be correct with
respect to the specication, the data should be processed correctly, and the
result of the calculation should be available in time.

2
 3. Non-functional requirements such as: The program should be set-up in such a
way that it is maintainable, testable, modiable, extendible and portable.
During the transformation from specication to implementation many choices are
made, a large number of these are in uenced by the non-functional requirements.
Unfortunately, the software development process turns out to be not well man-
ageable because of insucient metrics. For requirements in category 1 many metrics
are known. Regrettably, in category 2 there are not many metrics supporting the
programmer. Especially in the third category there is not much to go by. Evaluation
of the nished product does not result in many handles to introduce corrections in
the development process.
To remedy this situation, many `methods' for software development have been
devised. The next subsections will rst sketch some drawbacks of the now classical
methods and then proceed to the newer methods incorporating object orientation.

2.1 Methods and techniques

A program development method consists of the following components:
 One or more - often graphical - notations used to write down the result of the
analysis and design stages.
 Tools to manipulate and check designs denoted in those notations.
 A number of heuristics intended to help the designer making the \better" choice.
 Books and courses in which the method is explained.
A comparison of a number of methods can be done by comparing these notations,
tools, heuristics, books and courses. Notations and tools are heavily in uenced by
the facilities of equipment and software. Using generic tool sets such as MetaEd
and Paradigm Plus it is relatively easy to instantiate a new tool for a new notation.
Therefore, we will not thoroughly study notations and tools but concentrate on books
and articles in which the methods and heuristics are dened.
Software engineering as a professional discipline has been, and is still constantly
being, plagued by an devaluation of terminology. This devaluation has been forced
upon the area by rms needing their products being dierentiated from those of
competitors. In this report, we will refrain from using exaggerate, and often incorrect
terminology (like `methodology'). While describing a particular method we will try
to use the terminology of that method consistently, otherwise we will try to keep to
neutral wording.

3
2.2 Existing methods
During program development, Structured Analysis [24] emphasizes the functional as-
pects of the design. Data Flow Diagrams describe the design using processes receiving
and sending ows of data without enforcing any order of invocation on these processes.
The denition of control ow is not well developed using this and similar methods.
On the other hand, Structure Charts as developed by [17] and used in the Struc-
tured Design method, emphasizes control ow. With this method data structuring
is underexposed. Experience has learned that both methods are unsuitable for con-
structing exible models of changing systems.

2.3 The OO-paradigm

The development of object oriented languages that has taken place some 10 years
ago has been continued towards an object oriented paradigm for analysis, design
and programming. Taking some shortcuts, the paradigm promises that the afore
mentioned modeling problems disappear when we are able to:
 Analyze the problem and construct a model of reality (or a simplication of
reality); the model being a set of objects. These objects exchange data using a
particular model of message exchange.
 Design a solution to the problem by mapping these objects and message ex-
changes onto the mechanisms available in an object oriented implementation
language.
By partitioning the modeling process in two steps (gure 1) the transformation of
a specication into an implementation is simplied. Such a practice helps us to
construct systems more adaptable to changing requirements.

2.4 OO-development methods

The past few years have shown the development of approx. forty object oriented
developments methods. Figure 2 shows a short literature overview of the methods
compared in this report. Figure 3 shows a list of books and methods that have come
to the knowledge of the authors in a later stage of the project. These methods were
not used for comparison because either not enough documentation was available, or,
because they arrived too late to be included.
Before delving into a more detailed description of some methods however, a few
general remarks are to be made:
 There is a large amount of similarity between these methods. To say so in
object terms: many of these methods are direct descendants of an - abstract -
class `OO method'.

4
 Description of Real World

Analysis and Modeling

?
Object model and Interaction model

Design and Coding

?
Object language and Interaction Language

Figure 1: OO-development

year author(s) title litref

1991 Booch G. O-O Design with Applications [6]
1994 Booch G. O-O Design with Applications 2nd Ed. [7]
1990 Coad P. O-O Analysis, 2nd Ed. [13]
1991 Coad P. O-O Design [14]
1993 Coad P. O-O Programming [12]
1994 Yourdon E. O-O Systems Design, an Integrated Approach [71]
1993 Coleman D. O-O Development - The FUSION Method [15]
1992 Jacobson I. O-O-SE; a Use Case approach [35]
1993 Kristen G. KISS Methode voor Object Orientatie [41]
1991 Rumbaugh J. O-O Modeling and Design [61]
1988 Shlaer S. O-O Systems Analysis [62]
1992 Shlaer S. O-O Life Cycles [63]
1990 Wirfs-Brock R. Designing O-O Software [70]
Figure 2: Overview of OO-methods

5
year author(s) title litref
1989 Bailin S. C. An O-O Req. Spec. Method [2]
1994 Berard E. O-O Methodology [3]
1993 Champeaux D.de O-O System Development [11]
1994 Connell J.L. O-O Rapid Prototyping [16]
1994 Cook S. Designing Object Systems [18]
1992 Embley D. W. O-O Systems Analysis, A Model-Driven Approach [20]
1993 Firesmith D. G. O-O Requirements Anal. + Logical Design [22]
1994 Firesmith D. G. O-O Methods Standards and Procedures [23]
1993 Graham I. Object Oriented Methods, 2nd Ed. [27]
1993 Halladay S. O-O Software Engineering [29]
1992 Henderson-Sel. B. A Book of O-O-Knowledge [31]
1994 Henderson-Sel. B. Book Two of O-O-Knowledge [32]
1993 Kilov H. Information Modelling, [37]
1993 Knudsen J.L. O-O-Environments [38]
1993 Korienek G. A Quick Trip to Objectland [39]
1994 Krief P. Prototyping with Objects [40]
1993 Lano K. O-O Specication Case Studies [42]
1993 Lorenz M. O-OSD, A Practical Guide [44]
1992 Martin J. O-O A & D [47]
1993 Martin J. Principles of O-O A & D [46]
1994 Martin J. O-O Methods, The Foundations [48]
1993 Meyer B. O-O Applications [51]
1994 Meyer B. Reusable Software [50]
1994 Meyer B. An O-O Environment [49]
1992 Page-Jones M. Modeling O-O Systems [54]
1992 Reenskang E. OORASS: seamless support [56]
1994 Robinson K. Object-Oriented SSADM [58]
1992 Robinson P. Hierarchical O-O Design [59]
1992 Hood Hood Reference Manual [28]
1992 Robinson P. O-O Design [60]
1994 Star L. Practical Guide to Shlaer/Mellor OOA [65]
1992 Verhelst M. Merode [67]
1994 Walden K. Seamless O-O Software Architecture [68]
Figure 3: Overview of other OO-methods

6
  These methods are relatively young, insights about OO methods are far from
stable yet. Several developments in these methods and in the heuristics in
particular are currently taking place. In section 3 these developments will be
elucidated. Graphical notations used for modeling are constantly being adapted
to these developments; courses and tools follow suit.
 In a recent e-mail Steve Mellor wrote:
There are now so many OO methods that one has to admire the
stamina of anyone who can tell you what they are, let alone write
intelligently about them.
 Another | anonymous { quote reads:
A new OO design notation can be churned out over a weekend so
long as the objective is simply squiggles and icons with a unique look
and feel, and issues of usability and power in modeling are considered
unimportant.
Given these remarks an in-depth comparison of methods turns out to be not
well possible. The intention of this report is therefore widened to a more global
comparison, incorporating the signalling of trends in the development of OO-methods.
The material is mainly based on a study of relevant books ([13], [14], [12], [71], [6],
[7], [35], [70], [61], [41], [62], [63], [27], [15] ) and articles in which the methods have
been described ([21] [25], [26], [69], [52], [10], [2], [56], [33]). Additionally, several
articles and books containing comparisons of methods have been studied ([19], [54],
[34], [57], [9], [55], [66], [43]). Such a comparison can not be complete; doing justice
to all features of all methods is impossible in the constrained world of a technical
report.

3 Developments in OO-methods
After the development of object oriented languages had stabilized, extending the ob-
ject oriented paradigm to the analysis and design phases of large software systems
was the next step. In this section we will describe the process phases and the models
used in each of these phases by means of an example. Because of the authors' famil-
iarity with the method OMT (Object Modeling Technique) by Rumbaugh [61] will
be used.

3.1 Process phases

There are several widely known models to give a high level description of the software
development process: amongst them are the `waterfall model' by Boehm [4], the

7
`spiral model' also by Boehm [5] and prototyping models [8]. Most object oriented
development models support the iterating `spiral model'. Within this model the usual
phases requirements analysis, design, coding and testing are present.

3.2 Analysis
Almost every modeling technique uses one or more kinds of diagrammatic notation
to denote a model of reality. The so-called Object Model is found in several notational
variants in all methods. Other models used are state models to describe the dynamic
behaviour of a system and the functional model describing data transformations.
3.2.1 The object model
The purpose of this model is to describe reality in terms of objects, classes and rela-
tions. The rst step while constructing this model is to identify the most important
objects in the informal problem description.
As an early development the work by Booch [6] should be named here. This work
developed in the context of the object based language Ada-83 (Booch cites [1] as an
earlier reference). Booch recommends the following procedure to identify the objects:
Construct a textual description of the problem to be solved that is as
complete as possible using short and active sentences. Underline the nouns
and adjectives; these become the (data-)objects and attributes. Underline
the mass nouns and units of measure; these will become the types (in
OO terminology: classes). Underline the verbs; these will become the
procedures (OO: methods).
This way of working has been copied and rened by many new methods like OMT,
Fusion and KISS. The renement applicable to object orientation is that the result
of parsing a sentence can be used to isolate the sender and receiver of a message:
the subject becomes the sender, the direct object and/or indirect object become the
receiver of the message.
When all objects in the real world have been identied in this manner, a check
is needed to verify whether these objects indeed belong to the system to be realized,
or, whether they belong to the environment of the system. The heuristic that can be
used here is the well known Context Diagram.
After the requirements have been obtained the system to be realized is to be
modeled using one or more diagrams. All methods known use a so-called Object
Model to model relations between objects. Although terminology diers between the
methods discussed here, the following relations are considered:
 Association: two objects have a relation which is stable during the life of the
objects. This relation has a name (e.g. X works for Y). Often multiplicities
and r^oles are identiable.
8
  Aggregation: An object is part-of another object (e.g. cylinder, motor).
 Inheritance/specialization/generalization: An object is-a specialized version of
another object.
The object model is validated with the client.
3.2.2 The behavioural (state) model
The next modeling step is describing the dynamic behaviour of the system. Almost
all methods use variants of the State Charts according to Harel [30]. Older methods
(OMT, KISS) emphasize the state changes occurring within an object. From the
state model, code can be generated implementing the state changes. Newer methods
emphasize the importance of understanding the dynamic behaviour of a system con-
sisting of several thousands of objects (e.g. the object interaction model in Fusion).
The state model is constructed by developing scenarios describing events. These
events occur between objects in the system and on the interface of the system with
the outside world. The state model also has to be validated with the client.
3.2.3 The functional model
Finally, some methods (e.g. OMT) use a third model: the functional model. This
model describes the data ow through the system using a Data Flow Diagram-like
notation. In a DFD processes transform input data into output data. The DFD
notation has been extended with symbols to denote the creation of objects. The
functional model is in particular appropriate when (non-OO) data bases are used to
store persistent data. As before, the functional model has to be validated.

3.3 Design
Starting from one or more of the models just introduced a transformation to a design
has to be made. In OMT the design phase consists of two parts: System Design and
Object Design.
During the System Design phase the system to be designed is divided into sub-
systems. Insofar concurrency is explicit in the problem, subsystems are allocated to
processors. In this phase the data bases are developed.
During the Object Design phase the actions from the dynamic model and the
processes from the functional model are transformed into operations (methods) be-
longing to the classes in the object model. During this transformation low level data
structures are designed and algorithms are coded. In order to obtain the economic
advantages of object orientation in this phase heavy use has to be made of the object
oriented library available in the programming environment.
Starting from the state model the control ow is designed. Implementation choices
here are state machines, classic procedure oriented systems and systems based upon
9
concurrency (tasking). Associations are transformed into pointers or into separate
objects, depending on whether the associations are traversed in one or two direc-
tions. Depending upon the facilities oered by the programming language, multiple
inheritance needs to be transformed into single inheritance.

4 Modeling experiences
4.1 Usability of models
In this section a few generally felt problems stemming from the use of OO-methods
will be presented. These problems have been mentioned during informal conversations
(eg. on the News network). Unfortunately, solutions for these problems are not always
available.
Many users of these methods have indicated that nding the point beyond which
further analysis of the system to be designed would not deliver valuable results, was
found troublesome.
A further problem signalled is nding the correspondence between the various
models. Each of the models does give a dierent view on the system to be developed.
Finding the points of correspondence between the models and between the models
and the real world has shown to be dicult. In particular, OMT has been criticized
on this aspect.
Experience has learned that the usability of the functional model is rather limited.
In a similar way, the state model describing the state within one object does not
contribute much to better understanding.
The object model shows a hierarchy of specializations. Experience shows that
during analysis associations and aggregations are occurring more frequently than
specializations.

4.2 Developments
Earlier methods like Coad & Yourdon [13] and Shlaer/Mellor [62] are direct descen-
dants from existing techniques based upon E-R-modeling.
Developments that were started by Wirfs-Brock and Objectory have resulted in
methods like Fusion and OORASS. In these newer methods the identication of
objects is started by searching for interactions between the objects themselves and
between objects and their environment. These interactions are written down as so-
called Use Cases or Scenarios. This way of analyzing a specication is very suitable
for checking the completeness of a specication by means of symbolic execution.
This new way of doing ts very well with modern `client-server' and `event driven'
approaches.

10
4.3 Semantics
A general characteristic, and a problem of most methods is that the notions and
notations used during analysis do not have any (formal) semantics. Syntax and se-
mantics of the graphical notations are often \dened" by examples. In particular the
semantics of attributes, classes and methods has often to be derived from their names.
Sometimes an informal semantics is given for multiplicities, visibility (Booch) and in-
heritance. Because of the lack of semantics, the functionality of tools is restricted to
simple syntax checks and the generation of code for `headers'.
The Fusion method is an exception to this rule of lacking semantics for methods.
During the construction of the Operation Model a so-called Schema can be constructed
for each `operation' (method). In such a schema, a specication of the method is given
using - informally stated, but easily formalized - pre- and post conditions. The idea
is derived from the Vienna Development Method - Specication Language [36] and
the specication language Z [64].
In a yet to be published book on the Syntropy method [18] a more formal approach
is being developed.
In some methods the modeling of inheritance is subject to special rules. These
rules are devised to simplify the model and to allow easy reasoning about the model.
Some examples of such rules are:
 Fusion distinguishes normal subtypes and disjoint subtypes. The former allow
overlap between the subtypes, the latter don't.
 The notions of specialization and generalization are used somewhat more strictly
in Fusion than they are in most object oriented programming languages: Ob-
jects of a subclass are only allowed to extend the properties of a superclass, but
not to change or to delete them.
 Shlaer/Mellor requires a superclass to be an abstract class (like in C++ ). No
instantiations of a superclass are allowed.
In most cases, conformance to these rules is to be checked by hand. As there is
no requirement on the tool supplier to implement such checks the tool buyer should
check for the presence of these checks in a tool to be selected.

4.4 Reuse
Both reuse of components and design of reusable components are the intended hall-
marks of object orientation. Although most books do spend some paragraphs or
pages on these subjects little guidance is oered.

11
4.5 Metrics
Metrics, in particular metrics for object oriented designs are not yet properly dis-
cussed. The eld is currently an active research area. The book by Lorenz [45]
reports on rst experiences.

4.6 Clashes
The transition from the object oriented world to the conventional, non object oriented
world gives rise to so-called structure clashes. Some examples are:
 The entities available with OO-paradigm show explicit behaviour and hide their
internal data. On the other hand, entities in a relational database do not show
any behaviour and expose the structure of their data.
 Coupling to event driven systems like Windows are not easily derived from an
object oriented design.
Such couplings are special cases of connections to underlying systems. As long as
not all systems are made on the basis of objects such clashes will be present and will
require special attention from the programmer. New developments like IDL, CORBA
[53] that will reduce these problems are taken up quickly by the industry.

5 A design example
This section will present the design of a small agenda system using OMT. The con-
straints of a report do not a allow a more extensive example. The informal description
reads as follows:
Develop an automatic system to manage the agenda of a university teacher.
The program should have the following functionality:
 Making, changing and removing appointments;
 Be able to answer questions like: At what time and date examina-
tion X has to take place? How much time is has been reserved for
appointment Y? When will an appointment needing Z minutes be
possible?
The notation of OMT is quite extensive; we will need only a subset here. Classes,
relations (associations, aggregations and specializations) and multiplicities are drawn
as shown in gure 4.
Figure 5 shows the Object Diagram of the agenda system. For such a simple
system the diagram is believed to be self explanatory.
An event trace derived from the interaction with the user is shown in gure 6.
12
 Class-1 Assembly Superclass
Class

Class-2 Part-Class Subclass-1 Subclass-2

Association Aggregation Inheritance / Specialization

Multiplicities
1 1 n 1 1+ opt

Association name

Class-1 Class-2 Ternary Association

role-1 role-2

role-3

Class-3

Figure 4: OMT-notations

13
 keeps
User Agenda

prints
open
close

365,366 {ordered}
Printer Day

next
format previous

Event
starting time
duration
description

kind of event

Lecture Examination Appointment Practice

code ... place ...

room in use with 1+

Lectureroom Person

room number

kind of person

Student Staff

student# description

Figure 5: Object Diagram

14
User Agenda
open agenda

select date

show appointments

input starting time

input duration

check ok

get room number

get name/etc

.......

close agenda

Figure 6: Event Trace

15
 change
appointment
get update

make input
select
make input test Agenda
function correct?
app.

cancel

appointment get input

Figure 7: Data Flow Diagram

The Data Flow Diagram for making an appointment is shown in gure 7. This
diagram corresponds closely with the usual DFD technique. The `update' shown with
an open arrow shows the creation of a new object.
The State Diagram showing how to operate the agenda system using a three
button mouse is shown in gure 8.

6 An overview of some methods

In this section a short introduction to the features and problems of a number of meth-
ods will be given. As discussed earlier, these methods resemble each other in a large
number of respects. However, there are also large dierences, in particular regarding
notations, number and kinds of diagrams needed, and in the use of formalisms.

6.1 Objectory
Object Oriented Software Engineering (OOSE), as described by Jacobson in [35], and
the Objectory Method have been developed at the Swedish company Objective Sys-
tems. The method has been developed in the context of telecommunication systems
(Ericsson). The method is in existence for ve years and is stable. The tool set used
with the method has had favourable reviews. The book in which the method has
been described is well written but verbose. Belonging to the method is another 1200
page book giving more details and examples.
The method uses so-called Use Cases to describe the interaction (sequences of
transactions) between the objects in the system and their environment and in between
16
 start

press left mouse button / Test on proper day press right mouse button /
previous day next day
do: show date

press middle mouse button /

open display appointments

press left mouse button / Ask starting moment of time press right mouse button /
previous point of time next point of time
do: show points of time

press middle mouse button /

exit

Figure 8: State Diagram

the objects. The Use Case Model guides the construction of the Domain Model, the
Analysis Model, the Design Model, the Implementation Model and the Testing Model.
The Implementation Model uses so-called Interaction Diagrams (timing diagrams)
to show the temporal aspects of the interactions between objects in a clear way.
Given that the method has been developed in a telecommunications environment it
is somewhat disappointing that the use of formal notations is not well developed.
Tool support is available from the author [35].

6.2 Object Modeling Technique

OMT has been developed at General Electric. The method has been described by
Rumbaugh in [61].
Supporting tools are available from GE, Love, SoftwareThroughPictures, Cadre,
Protosoft and other CASE-tool vendors.
The method starts with the construction of a graphical Object Model and a textual
Data Dictionary. In the Object Model objects and classes are described; between these
entities inheritance relations, aggregations and associations are dened. In addition
to an object model a Functional Model and a Dynamic model are constructed. The
functional model proves to be of limited use. It is rumoured that the functional model
will not be present anymore in an announced revision of OMT. A well known problem
of OMT is that these models do have dierent domains which makes consistency
checks more dicult.
17
 Some year ago, Marin Marietta has acquired some parts of General Electric. This
does not seem to have any consequences for the further development of OMT. Very
recently it has been announced on the Internet that Rumbaugh is going to join
Rational, the rm behind the Booch method (see section 6.3).

6.3 Booch91/94
The second (1994) edition of the book Object Design and Applications [7] describes a
revised version of the Booch method presented in the 1991 edition [6]. The method has
been brought up-to-date regarding notions and notations. From Jacobson and other
authors, the idea to use scenarios to describe system behaviour has been introduced.
The notation has been somewhat simplied and adapted to the Rumbaugh style.
The rst edition gave examples in Smalltalk, C++ , Ada, Object Pascal and CLOS.
In the second edition C++ is much more emphasized. Even the graphical notation
has been adapted to the facilities of this language.
The book consists of three parts, a general introduction to OO, a description of
the Booch method and a few case studies.
The method distinguishes several kinds of relations: associations (`links'), `inher-
itance', aggregation, `using' (`client/server'), instantiations (`generics') and `meta-
classes'. The static part of a design is modeled using Class Diagrams, Object Dia-
grams, Module Diagrams and Process Diagrams. Dynamic properties can be denoted
using State Transition Diagrams and Interaction Diagrams. There is no obligation to
use all the kinds of diagrams. The so-called `essentials' have to be used; `advanced
concepts' are available for further optional detailing of a design.
The emphasis of the book is, as the title says, on design. There is very little
attention for data dictionaries and E-R-modeling.
Tool support is available from Rational.

6.4 Wirfs-Brock
The Wirfs-Brock method [70] was developed at Digitalk.
The starting point of this method is the identication of Classes, Responsibilities
and Collaborations during the analysis and design phase.
Classes are discovered by having members of the design team discover scenarios
in the informal problem description. A `class' is written down on a so-called Class
Card. In a second step, the Responsibilities that is, the tasks a system will need
to do, are searched for. These Responsibilities are added to the Class Cards. In a
third step Collaborations - cooperations between classes - are identied. Discovering
inheritance relations is an important aspect of the method; part-of relations are con-
sidered being of less importance. The dynamic model is missing altogether. During
the implementation phase Responsibilities are transformed into `instance' variables
and methods.

18
 The book which describes the method is very well readable and suitable as an
introduction to object oriented design.
As far as known, no tools are available.

6.5 KISS
The KISS method (Kristen Informatie & Software Services) originated in the Nether-
lands. The method has been developed by G. Kristen.
In the analysis phase a so-called Information Quadrant is composed. This quad-
rant relates four aspects of the real world: controlling processes, collaborators, actions
and objects. These aspects describe the controlling system of an organization, the
input functions, the information architecture and the output functions. The method
is rooted in industrial organization and is suited for administrative systems. The
method uses grammatical analysis of sentences written in natural language to con-
struct a tree of classes. A kind of Domino-game, which is used by the project team
to analyze the real world in a way similar to to the Wirfs-Brock method forms part
of the method.
The method is mostly concerned with the analysis and design phase. Less atten-
tion is being paid to state models and implementation aspects.
Unfortunately, the (Dutch!) book describing the method is not well written: de-
nitions are rather woolly, graphical notations are excessive, sometimes gure numbers
are missing in the text and in a few cases trivialities are treated in depth. (An English
translation is expected to appear in 1995.) This all is detrimental to a method that
is not without some merit.
Tool support is available from Paradigm Plus by ProtoSoft.

6.6 OOA/OOD
From the trilogy by Coad (+ Yourdon and Nicola) [13], [14], [12] we will discuss only
the volumes about analysis [13] and design [14]. We will also not discuss the book
by Yourdon [71].
In the analysis phase Coad & Yourdon distinguish ve layers:
 The Subject Layer showing the most important components of the system to be
developed.
 The Class & Object Layer describing the (not yet connected) classes and objects.
 The Structure Layer in which `inheritance' and other relations are added to the
previous layer.
 The Attribute Layer to identify attributes and Instance Connections (relations
with multiplicities). In this layer an informal specication of the attributes is
given.
19
  The Service Layer. An (informal) specication of the `methods' is derived from
an analysis of states and state transitions.
One could consider the ve layers as a stack of overhead slides; with each layer new
details are added. There is no obligation to construct the layers in succession.
In the design phase four components are distinguished:
 The Human Interaction Component containing the denition of the `interface'
to the user.
 The Problem Domain Component in which the algorithms will be developed.
In this part multiple inheritance may be transformed into single inheritance.
 The Task Management Component comprising the denitions of `event-driven',
`clock-driven', priority and coordinating tasks, and nally,
 The Data Management Component giving attention to le systems, relational
and object oriented data bases.
Examples of implementations in C++ , Object Pascal, Smalltalk, Objective C, Eiel,
Ada83 and C are given.
The density of the information in the books is rather limited. The writers do
repeat themselves quite often and can't suppress the inclination to illustrate OO
notions on the basis of denitions in encyclopedias. Five layers seems to be overdone;
similar methods give the same results with the object model only. The separation in
four components as used in the design phase does not use the ve layers in the design.
The description of the coupling between systems developed using this method and
system containing non OO (e.g. relational) data bases is of a very general nature.
Tool support for this method is available from the authors and from other suppliers
of CASE tools.

6.7 Shlaer/Mellor
The Shlaer/Mellor method consists of two parts. The rst part combines the world
of data modeling (data bases) and the world of objects and has been described in
[62]. This part of the method is based upon E-R-modeling. The second part ([63])
supplements the rst one with object oriented analysis, modeling, state descriptions
(also from a Real Time perspective) and design.
The method does use a large number of diagrams, tables and descriptions. The
Information Structure Diagram is, apart from the notation, similar to the Object
Diagram in OMT. Life Cycle diagrams describe state changes for objects. State
diagrams are also used to denote the dynamic behaviour of relations.
When the relations will lead to competition for scarce resources between two or
more objects a Monitor construct is used to prevent con icts. The dynamics of the

20
model is described in the Object Communication Model. Finally, in the Action Model
the dynamic behaviour of the objects is explained in great detail.
The method is most appropriate for the design phase; a notation for a design lan-
guage (OODLE, standing for Object Oriented Design LanguagE) is presented; how-
ever, there is no real direction on how to use that notation. In Action Data Flow
diagrams are used to rene the dynamic behaviour of objects in quite some detail.
The method uses tables to provide for checks on the consistency of diagrams.
Given the large number of diagrams used in the method this is no luxury. Some of
the models are quite detailed and low level; statements in a programming language
are used as annotation in gures and for later code generation. The method suggest
that the diagrams can be constructed sequentially (waterfall model). However, this
is not fully convincing. Although the method uses the term Recursive Design there
is no formal base on which the method has been built.
The books in which the method have been described are well readable. Tools are
available from Project Technology, Cadre and IPSYS.

6.8 Fusion
According to the authors, Fusion is the rst example of a second generation of object
oriented methods. The method has been developed based upon experiences gathered
with Rumbaugh, Booch and Wirfs-Brock. The Fusion method has been developed
at the Hewlett Packard Bristol laboratories. Although HP is providing courses on
Fusion, there is no formal liaison between HP and Fusion.
Starting from an informal requirements document, an Object Model, an Interface
Model and a Data Dictionary are constructed. The Interface Model describes the
relation between the system to be developed and the outside world. This model is
composed of two parts: the Life Cycle Model describing scenarios and the Operation
Model which contains the (formal) specications that have been mentioned in section
4.3.
In the design phase Class Descriptions, Inheritance Graphs, Object Interaction
Graphs and Visibility Graphs are constructed.
In the implementation phase the program is constructed from the Object Interac-
tion Graphs and the Inheritance Graphs. Examples are given in C++ and Eiel.
The book describing the method [15] is well readable and contains clear denitions
and examples. One of the problems already apparent in the method is controlling the
the consistency between the large number of diagrams. The method advises reviews,
but conducting these requires quite some eorts from the development sta.
Tool support is available from ProtoSoft, SoftCASE Consulting and ICON Com-
puting.

21
 Requirements Design Coding Number of
Method Capturing Analysis support tools
Objectory + ++ + + 1
OMT 2 + + 2 3+
Booch91/94 ? ? + 2 1
Wirfs-Brock ? 2 + 2 ?
KISS ? 2 2 ? 1
OOA/OOD ? 2 ? ?? 2+
Shlaer/Mellor ? + 2 ? 3+
Fusion + ++ ++ + 3+
Figure 9: Overview 1
Forma- Concise- Application- Problems
Method lism ness area
Objectory ? low general state model
OMT 2 average general consistency
Booch91/94 ? low general not yet stable
Wirfs-Brock ?? average general introductory
KISS ?? low administrative unclear denitions
OOA/OOD ? low administrative verbose
Shlaer/Mellor ? average general large number of notations
Fusion + high technical large number of models
Figure 10: Overview 2
6.9 Overview
Some features of the methods reviewed here are summarized in the gures 9 and
10. The following conventions are used: ?? will mean that the feature is supported
very badly (or is absent) ? indicates that the feature is supported insuciently (or is
almost absent), 2 expresses moderate support, + means good support (availability)
and ++ displays very good (good support). It should be noted that the contents of the
tables is, in some measure, based upon the preferences of the authors. Additionally,
the reader should keep in mind that these methods for object oriented analysis and
design are constantly changing; the current review is only a snapshot.

7 Conclusions and recommendations

In this report an overview and comparison of several methods for object oriented
analysis and design has been given. It has been shown that actual experience with
these methods is still limited and being built-up.
Every other month a new method appears, a notation is extended or changed and
22
new or revised tools become available. It will take at least two years before a stable
situation will develop. Will it be economically justiable to start using these methods
in an industrial setting?
It is the opinion of the authors that a modest introduction of one of the described
methods is well warranted. As an example, the book of Wirfs-Brock is very well
readable and the method does not require elaborate training or expensive tools. It is
believed that the old adage which says that using a method not precisely adapted to
the problem at hand being better than using no method at all, is still valid.
It is well advisable to rst become thoroughly acquainted with the principles of
object oriented programming before embarking on a study and introduction of a
method for OO analysis and design. Introducing OO in an industrial organization
will take four years: two years to become procient with OO programming and two
years to become acquainted with object oriented methods.
A good start might be to have a small, well known problem being attacked by
a small group of enthusiasts. The problem should be well dened, but no earlier
analysis should have been done with older techniques like DFDs. An object oriented
analysis should start from scratch.
In the opinion of the authors, really large investments in these methods are not
yet warranted. The situation is not yet stable enough; methods and tools are still in
a constant state of turmoil.
Yet, organizations should start obtaining experience in object oriented analysis
and design techniques. It is hoped that this report will help them to set foot on this
interesting software engineering eld.

Acknowledgment The authors are indebted to Ronald Huijsman for his helpful
comments during the preparation of this report.

References
[1] R. J. Abbott. Program Design by Informal Descriptions. Communications of
the ACM, pages 882{894, nov 1983.
[2] S. C. Bailin. An object-oriented requirements specication method. Communi-
cations of the ACM, 32, may 1989.
[3] E. V. Berard. Essays on Object-Oriented Software Engineering, volume 1. Pren-
tice Hall, 1993.
[4] B. W. Boehm. Software engineering. IEEE Transactions on Computers, 25:1226{
1241, 12 1976.
[5] B. W. Boehm. A spiral model of software development and enhancement. IEEE
Computer, 21, may 1988.
23
 [6] G. Booch. Object Oriented Design with Applications. The Benjamin Cummins
Publishing Co, Redwood City, 1991.
[7] G. Booch. Object Oriented Design with Applications, 2nd Ed. The Benjamin
Cummins Publishing Co, Redwood City, 1994.
[8] F. P. Brooks Jr. No silver bullet: essence and accidents of software engineering.
IEEE Computer, 20(4):10{20, 1987.
[9] A. Carmicheal. Object Development Methods. SIGS Books Inc., 1994.
[10] D. de Champeaux and P. Faure. A comparative study of object-oriented analysis
methods. Journal of Object-Oriented Programming, 5, 1992.
[11] D. de Champeaux, D. Lea, and P. Faure. Object-oriented System Development.
Addison-Wesley, 1993.
[12] P. Coad and J. Nicola. Object-Oriented Programming. Yourdon Press / Prentice
Hall, 1993.
[13] P. Coad and E. Yourdon. Object-Oriented Analysis, 2nd Ed. Yourdon Press /
Prentice Hall, 1990.
[14] P. Coad and E. Yourdon. Object-Oriented Design. Yourdon Press / Prentice
Hall, 1991.
[15] D. Coleman, P. Arnold, S. Bodo, C. Dollin, H. Gilchrist, and P. Jeremaes. O-O
Development - The FUSION Method. Prentice Hall, 1993.
[16] J. L. Connell and L. Shafer. Object-Oriented Rapid Prototyping. Prentice Hall,
1994.
[17] L. L. Constantine and E. Yourdon. Structured Design. Prentice Hall, 1979.
[18] S. Cook and J. Daniels. Designing Object Systems. Prentice Hall, 1994.
[19] J. Edwards. Basic Ptech skills. Course notes, Associative Design Technology,
1989.
[20] D. W. Embley, B. D. Kurtz, and S. N. Woodeld. Object-Oriented Systems
Analysis, A Model-Driven Approach. Prentice Hall, 1992.
[21] R. G. Fichman and C. F. Kemerer. Object-oriented and conventional analysis
and design methodologies. IEEE-Computer, 25, oct 1993.
[22] D. G. Firesmith. Object-Oriented Requirements Analysis and Logical Design: A
Software Engineering Approach. Wiley, 1993.

24
[23] D. G. Firesmith. Object-Oriented Development; Methods, Standards and Proce-
dures. Prentice Hall, 1994.
[24] C. Gane and T. Sarson. Structured Systems Analysis. Prentice Hall, 1979.
[25] G. P. M. van der Goor, S. Brinkkemper, and S. Hong. Objectgeorienteerde
Ontwerpmethoden. Informatie, 35, 12 1993.
[26] G. P. M. van der Goor, S. Hong, and S. Brinkkemper. Formalization and com-
parison of six object oriented analysis and design methods. Technical report,
Report Method Engineering Institute, Universiteit Twente, Enschede, 1992.
[27] I. Graham. Object Oriented Methods, 2nd Ed. Addison Wesley, 1993.
[28] Hood User Group. Hood Reference Manual. Prentice Hall, 1992.
[29] S. Halladay and M. Wiebel. Object-Oriented Software Engineering. Prentice
Hall, 1993.
[30] D. Harel. Statecharts, a visual formalism for complex systems. Science of Com-
puter Programming, 8:231{274, 1987.
[31] B. Henderson-Sellers. A Book of Object-Oriented Knowledge. Prentice Hall,
1992.
[32] B. Henderson-Sellers. Book Two of Object-Oriented Knowledge. Prentice Hall,
1994.
[33] B. Henderson-Sellers and J. M. Edwards. The object-oriented systems life cycle.
Communications of the ACM, 33, sept 1990.
[34] IT Works. Object-orientation in practice. Technical report, IT Works, 1994.
[35] I. Jacobson, M. Christerson, and P. Jonsson. Object-oriented software engineer-
ing; a Use Case driven approach. ACM Press, New York, 1992.
[36] C.B. Jones. Systematic Software Development using VDM, Second Edition. Pren-
tice Hall, New York, 1990.
[37] H. Kilov and J. Ross. Information Modelling, An Object-Oriented Approach.
Prentice Hall, 1993.
[38] J. L. Knudsen, O.L. Madsen, B. Magnusson, and M. Lofgren. Object-Oriented
Software Development Environments, The Mjlner Approach. Prentice Hall,
1993.
[39] G. Korienek and T. Wrensch. A Quick Trip to ObjectLand. Prentice Hall, 1993.

25
[40] P. Krief. Prototypig with Objects. Prentice Hall, 1994.
[41] G. Kristen. KISS-methode voor OBJECT ORIENTATIE  . Academic Service,
Schoonhoven, 1993.
[42] K. Lano and H. Haughton. Object Oriented Specication Case Studies. Prentice
Hall, 1993.
[43] F. van der Linden and A. Ouvry. Classication and brief evalution of object-
oriented methods. IST Research Report RWB-508-re-93167, Philips Research,
Eindhoven, 1993.
[44] M. Lorenz. Object-Oriented Software Development. Prentice Hall, 1993.
[45] M. Lorenz and J. Kidd. Object-Oriented Software Metrics, A Practical Approach.
Prentice Hall, 1994.
[46] J. Martin. Principles of Object-Oriented Analysis and Design. Prentice Hall,
1993.
[47] J. Martin and J. J. Odell. Object-Oriented Analysis and Design. Prentice Hall,
1992.
[48] J. Martin and J.J. Odell. Object-Oriented Methods, The Foundations. Prentice
Hal, 1994.
[49] B. Meyer. An Object-Oriented Environment. Prentice Hall, 1994.
[50] B. Meyer. Reusable Software, The Base Object-Oriented Component Libraries.
Prentice Hall, 1994.
[51] B. Meyer and J-M. Nerson. Object-Oriented Applications. Prentice Hall, 1993.
[52] D. E. Monarchi and G. I. Puhr. A research typology for object-oriented analysis
and design. Communications of the ACM, 35, sept 1992.
[53] Object Management Group. The Common Object Request Broker: Architecture
and Specication. OMG, 1992.
[54] M. Page-Jones, L.L. Constantine, and S. Weiss. Modeling object-oriented sys-
tems: The uniform object notation. Computer Language, pages 70{87, oct 1992.
[55] C. Pronk. Objectgeorienteerde ontwerpmethoden en technieken, chapter 2, pages
13{32. ASI Seminar, Object Orientatie Kritisch Bekeken. Schellekens, 1994.
[56] T. Reenskaug and E. P. Andersen. OORASS: seamless support for the creation
and maintenance of object oriented systems. Journal of Object Oriented Pro-
gramming, oct 1992.
26
[57] P. van Renterghem. Object orientation methods and tools inventory. Technical
report, IT Works, 1994.
[58] K. Robinson and G. Berrisford. Object-Oriented SSADM. Prentice Hall, 1994.
[59] P. Robinson. Hierarchical Object-Oriented Design. Prentice Hall, 1992.
[60] P. Robinson. Object Oriented Design. Chapman & Hall, 1992.
[61] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-
Oriented Modeling and Design. Prentice Hall, 1991.
[62] S. Shlaer and S. J. Mellor. Object Oriented Systems Analysis: Modeling the
World in Data. Prentice Hall, 1988.
[63] S. Shlaer and S. J. Mellor. Object Oriented Life Cycles: Modeling the World in
States. Prentice Hall, 1992.
[64] J. M. Spivey. The Z notation; a reference maunal (2nd ed). Prentice Hall, 1992.
[65] L. Starr. Practical Guide to Shlear/Mellor OOA. Prentice Hall, 1994.
[66] Nederlandse Gebruikersgroep van Gestructureerde Ontwikkelingsmethoden;
Werkgroep Object Orientatie. Dertien methoden voor object georienteerde sys-
teemontwikkeling, een vergelijkend rapport. Tutein Nolthenius, 1994.
[67] M. Verhelst. Objectgerichte systeemontwikkeling; een praktische aanpak met JSD
en Merode. Kluwer Bedrijfswetenschappen, 1992.
[68] K. Walden and J-M. Nerson. Seamless Object-Oriented Software Architecture.
Prentice Hall, 1994.
[69] I. J. Walker. Requirements of an object-oriented design method. Software En-
gineering Journal, 7(2), Mar 1992.
[70] R. Wirfs-Brock, B. Wilkerson, and L. Wiener. Designing Object-oriented Soft-
ware. Prentice Hall, 1990.
[71] E. Yourdon. Object-Oriented Systems Design, An Integrated Approach. Yourdon
Press, 1994.

27