Information and Software Technology 1994 36 (2) 67-86

Improving object-oriented analysis

Gabriel Eckert*
Software Engineering Laboratory, Department of Computer Science, Swiss Federal Institute of Technology,
EPDFL-DI-LGL, 1015 Lausanne, Switzerland

Paul Golder
Department of Computer Science and Applied Mathematics, Aston University, Aston Triangle, Birmingham
B4 7ET, UK

This paper evaluates current object-oriented analysis methods and proposes some possible
improvements. We start by describing software requirements definition activities and reviewing
the concepts of data modelling and object-orientation. We then identify key principles of object-
oriented analysis and judge a selection of emerging methods against these principles. Finally,
a proposal is presented which attempts to avoid some of the identified shortcomings. The
proposal provides a nested object-relationship-operation framework which is based on a
consistent use of the object model, a strong notion of encapsulation and a clear distinction
between the essential and the contingent properties of the modelled entities.

Keywords: object-orientedanalysis, modelling, analysis methods, software requirements

This paper focuses on the modelling of tangible and standing and explaining how they interact with one another
intangible objects from the real world during the early is the aim of object-oriented analysis.
phases of the software development process. These early The paper is organized into three parts: Analysis and
activities are commonly called analysis and the use of an specification; Existing methods; and A proposal--plus an
object-oriented approach leads to the term object-oriented Appendix. The first part sets the context of the analysis activi-
analysis, although both 'object-oriented' and 'analysis' ties. Object orientation is discussed and is related to other
have become extremely overloaded terms. approaches. The second part surveys and compares emerging
Analysis is a communication intensive software engi- object-oriented analysis methods. Ways of improving these
neering task that attempts to bridge the initial gap between methods are discussed in the final part, and a proposal is pre-
the users (or procurers) and the developers of a software sented which attempts to avoid some of their shortcomings.
system. Users are problem specialists and developers are
solution specialists. Analysts bring them together, uniting
them with a common vocabulary and understanding. Analysis and specification
Object orientation is a way of thinking about problems Gause and Weinberg say that the requirements phase is 'the
using models organized around real-world concepts. The part of development in which people attempt to discover
object-oriented technology has evolved in diverse segments what is desired '~. However, this definition does not account
of computer science as a means of managing the complexity for the two different types of activities involved in defining
inherent in many different kinds of systems. Object- software requirements2:
oriented methodst are now having a profound impact on
areas such as programming languages and databases, but • Requirements analysis (problem analysis). Understanding
they have only recently begun to gain attention as an the problem and the user's needs, identifying all possible
alternative to the more traditional ways of analysing constraints on a solution; organizing the plethora of
systems. Identifying the elements of a problem and under- assembled information.
• Requirements specification (product description). Des-
* Formerly at Aston University, Birmingham. cribing the expected behaviour of the product to be built
t The word 'method' is used throughoutthis article ratherthan the overused to solve the now-understood problem; making some
word 'methodology'which is here taken to refer to the study of methods. difficult decisions in order to resolve conflicting views.

0950-5849/94/020067-200 1994 Butterworth-HeinemannLtd 67

Improving object-oriented analysis: G Eckert and P Golder

Requirements analysis can be thought of as defining the Influence of data models

product space, i.e. the range of all possible problem A data model is a way of perceiving, describing and
solutions that meet all known constraints. The requirements organizing data. Data modelling is the activity by which a
specification defines some particular product in this data model is applied to derive a logical organization that
space2. These two types of activities do not represent is documented in a (conceptual) schema 6. Database design
temporally sequential phases but are freely interleaved is the primary application area for data models.
during the requirements definition phase. The schema which results from applying a data model is
Analysis is primarily a decomposition process for which a formal representation of some slice of reality called a
there are two major schools of thought: 'universe of discourse'. The common core of data models
• The functional world. The problem domain is analysed is the notion of an entity as a representation of an object of
from the perspective of functions that must be provided the universe of discourse about which there is a desire to
to solve those problems. record information.
• The object-oriented world. The problem domain is Providing increased expressiveness and incorporating a
analysed from the perspective of objects in the richer set of semantics into the representation has been the
application domain. goal of various so-called semantic data models, the entity-
relationship model being generally considered to be the
Many analysis methods have been proposed in the first7. The primary components of semantic models are the
literature, the most popular today being the family of so- explicit representation of entities, attributes and relation-
called structured analysis methods, a function-oriented ships. Various additional abstraction mechanisms are
top-down approach typified by the work of DeMarco 3, usually provided. They can be considered as built-in
Yourdon 4, and Ward and Mellor5. specific relationships with predefined semantics and usually
Structured analysis has been applied to a wide variety of include the following:
problems with mixed success. Many authors acknowledge
that function/subfunction breakdowns are difficult to • Generalization-specialization (is-a relationship) between
construct and highly volatile. The very weak data structure entity types.
emphasis is another great concern which causes a difficult • Aggregation (cartesian product) of attributes into a new
transition from analysis to design. Structured analysis has entity type.
therefore been extended in order to include aspects of data • Classification (is-instance-of relationship): collection of
modelling, primarily using entity-relationship diagrams. entities considered as a higher level entity (often called
This data model (or information model) is sometimes class).
considered object-oriented in the sense that it maps directly
the problem domain to model entities which are found by For a comprehensive survey of various semantic data
considering the real world objects. models, refer to Hull 8 or Peckham 9.
The current trend in analysis methods is toward pure
object-oriented analysis by identifying and modelling the Semantic modelling and object orientation
essential problem domain objects with their logical relation- There are many commonalities between the entity notion
ships and interactions. It is felt that analysts applying coming from the semantic data models and the object notion
object-oriented methods will gain the much-needed coming from the object-oriented approach. Is there really
problem domain understanding from which they may begin a clear distinction between the two notions? According to
to describe a particular product. The activity of precisely King, 'Semantic models attempt to provide structural
documenting the external behaviour of this product is abstraction while object-oriented models are geared
commonly called specification. towards behavioural abstraction. In other words, semantic
The major product of an object-oriented analysis is the models are oriented toward the representation of data,
object model of the application domain. The specification while object-oriented languages are concerned with the
activities are therefore based on this explicit model, the manipulation of data '~°. Typical semantic models do not
internal structure of which can be internalized and provide the encapsulation of attributes and methods within
evaluated. Constructing and refining the object model an object but allow general access to the aggregation
fosters a deep understanding of the problem domain and components and relationships of an entity. The notion of
facilitates the communication with the client. Information is inheritance of attributes in semantic models is also different
extracted and formalized while the object model is from the inheritance of operations in object-oriented
evolving. Requirements specification (which is likely to be models. In a semantic model, the inheritance of attributes
performed in parallel) is the task of precisely expressing the (specialization) is only between entity types where one is a
chosen product in terms of this refined object model. subset of the other. There is no such constraint in object-
As their name implies, object-oriented analysis methods oriented models where the inheritance of operations can be
primarily concentrate on problem analysis, although they between unlike types because it is a reuse mechanism for
also frequently address some specification issues. There is behavioural properties.
little available literature about object-oriented requirements On the other hand, object-oriented models do not
specification and this paper mainly focuses on a pure typically provide the various type constructors of semantic
object-oriented approach to requirements analysis resulting models and they only have limited structural primitives. By
in an object model. supporting a form of local behaviour, an object-oriented

68 Information and Software Technology 1994 Volume 36 Number 2

 Improving object-oriented analysis: G Eckert and P Golder

model is more expressive and general than a semantic data Object-oriented approach. Class hierarchies may be
model, but by having a single structural primitive (the incrementally defined by an inheritance mechanism
object), it requires the explicit building of every simple where subclasses inherit their basic template (which may
application by an ad hoc assembly. For example, there is be modified) from their superclass.
no primitive for constructing a set of objects or a
relationship between objects. A minor relational database Therefore
application would become a major development project if
implemented in an object-oriented programming language Object-oriented = objects + classes + inheritance ~2.
such as C + + .
In that sense, the classical object model is conceptually Blair argues that this traditional view is too restrictive because
not appropriate for the modelling activity, although it is an it is based on language implementation mechanisms ~3. He
effective design and implementation tool. Its lack of higher proposes to compare and contrast object-oriented
level modelling primitives with built-in semantics makes it environments using four independent dimensions which he
inappropriate for many data-intensive applications. claims capture the very essence of object-orientation:
The aim of language-database integration is a great
(1) Encapsulation. The grouping together of various
motivation towards a unified object-oriented analysis
properties associated with an identifiable entity (the
approach. The software community is interested in object-
object) to which access is restricted by a well-defined
oriented data models which include the advantages of both
interface.
semantic models and classical object-orientation.
(2) Classification. The ability to group associated objects
The challenge of the object-oriented analysis area is to
according to common properties.
identify and define how to extend the object model in order
(3) Flexible sharing. The ability for an object to belong to
to keep its advantages but increase its modelling power. In
more than one classification.
other words, the object model needs to be structurally
(4) Interpretation. The resolution of the precise
extended with the aim of applying it both during classical
semantics of the shared item of behaviour.
software development and for database schema definition.
This leads us to the question of the meaning of object- This model of object-oriented systems defines a four-
orientation during analysis. dimensional design space which is useful for comparing
object-oriented systems. The first dimension (encapsulation)
The meaning o f object-orientation is fundamental because it conveys the very notion of
Object-orientation is an engineering principle used to create objects, but nevertheless large variations are possible
a representation of the real-world problem domain and to according to the possible properties which are grouped
map it into a software solution domain. It is our assumption together (attributes, operations, representation, constraints,
that object-orientation is applicable in all phases of the life- triggers, algorithms, identity, etc.).
cycle: however, it may not have the same interpretation in Database objects often only encapsulate attributes and
the different phases. The object-oriented approach does not constraints while programming languages concentrate on
abandon all the sound principles and experience of previous representation, operations and algorithms. Deciding upon
methods but it introduces several novel elements that build the visibility of these properties is another major step. The
upon these earlier models. As a result, many researchers information hiding principle implies that only the
see projections of their ideas within object-oriented operational interface is visible while data representation
systems. The consequence is conflicting ideas even on basic and operation implementation remain concealed. There
definitions like 'What is an object, a class? What is are, however, several cases where this principle is broken:
inheritance?' The same term is being used in different ways • Inheritance in which a subclass is dependent on the
in each of the different application areas. Anything which internal representation and algorithms of its superclass.
is not purely functional might be termed 'object-oriented'. • Databases which usually make attribute values visible
Clearly then, it would be futile to attempt to provide a (by allowing 'direct' read access).
single definition of what it means to be object-oriented.
The object notion is the only common concept included The second dimension (classification) is a natural extension
in all object-oriented approaches, although it is not to encapsulation in which various groupings of objects can
precisely defined. Any perceived entity in a system may be be defined. All objects within a particular grouping will
considered as an object. It is very tempting to adopt a de share common properties. The choice of how to model
facto definition based on the popular Smalltalk-like classification is absolutely central. It is important to
concepts j~. This traditional view considers object- distinguish between the intensional* and the extensional
orientation as the result of three conceptual steps: aspects of a particular classification:
• The intent of a classification is the description of that
• Object-based approach. Support the object notion
classification characteristic. The intent denotes all the
(encapsulation of a set of operations and a state that
possible objects which exhibit a certain behaviour and
remembers the effect of operations).
• Class-based approach. Every object is instance of a
class. A class is a template from which objects with * The word 'intension' is used rather than 'intention' to implya thorough
uniform behaviour may be created. and intensive definition.

Information and Software Technology 1994 Volume 36 Number 2 69

Improving object-oriented analysis: G Eckert and P Golder

is therefore potentially infinite. The intent specifies a explicitly address the analysis phase and for which compre-
predicate. hensive documentation is available on the open market. We
• The extent of a classification is the (finite) set of identified the following four representative methods which
objects in the current environment which feature such are compared in separate sections.
behaviour. The extent is a population selected by
applying a predicate. • Object-oriented systems analysis, by Shlaer and
Mellor 15.16.
Various classification schemes are possible and the most
• Object-oriented analysis, by Coad and Yourdon 66.
important are the set, the type, the class and the prototype.
• Object-oriented modelling technique, by Rumbaugh
There is a lot of confusion about the notions of sets, types
et al. ~8.
and classes. For example, the set extent is commonly
• Object-oriented analysis and design, by Martin and
denoted by the term class in the database area, while class
Odell ~9.
has the meaning of type intent for programmers.
The third dimension (flexible sharing) implies that
The interested reader may consult the appendix, where
classifications can overlap and intersect. Objects can
more than 20 other proposed analysis approaches are
therefore belong to many classifications and will require a
referenced.
flexible form of behaviour sharing depending on the
The OOA methods we have compared in this article (and
considered context. Flexible sharing is based on existing
most other OOA approaches) result from the influence of
relationships between classifications and there are
three domains:
therefore many possible techniques depending on the
considered classification scheme and the intended sharing
• Semantic data modelling.
goals. Inheritance (subclass), subtype, subset or generics
• Structured analysis methods.
are some of the possible techniques that may be applied,
• Object-oriented programming languages.
depending on the encapsulated properties and on the chosen
classification constructs. Flexible sharing is obviously
It might be surprising that the prominent OOA methods can
strongly related to polymorphism in its fundamental
be considered as enhanced data models, the influence of
forms~4.
object-oriented languages being often less important than
The last dimension (interpretation) is responsible for the
the name would imply. In this section we compare existing
resolution of the shared behaviour across many classifi-
OOA methods from both their data modelling capabilities
cations. This is typically necessary for polymorphic oper-
and their 'object-orientedness'.
ations where the possible ambiguities have to be resolved.
For any systems analysis method, there are many factors
This decomposition along four dimensions does not
to assess:
provide a rigid definition of object-orientation but helps in
defining a framework which captures all the encountered
• The support for the underlying principles of structuring
variations. Inheritance, class, dynamic binding and other
used during analysis: partitioning, abstraction and
'classical' object-oriented concepts are no longer
projectionz°.
considered fundamental but are now possible choices in the
• The general features that an analysis technique should
given framework t3.
exhibit: facilitate communication; provide a means of
During the analysis phase, it is likely that aspects of these
defining the system boundary; encourage thinking in
four dimensions will spontaneously turn up from the user
terms of the problem as opposed to the solution; allow
point of view. Identification of encapsulation and classifi-
for opposing alternatives; make it easy to modify the
cation will probably be quite natural, whereas flexible
knowledge structure2.
sharing and interpretation are less intuitive. The analyst
• The foundations of the method which should provide a
will have more and more difficulty in getting information
strong theoretical framework thus suppressing mis-
from users or procurers when moving along these four
understandings.
dimensions of increasing abstraction.
• The availability of an expressive graphical notation.
Paying particular attention to the presentational aspects
of the model is important in order to make them
Existing methods
understandable to the non-specialist.
Object-Oriented Analysis (OOA) is a rapidly evolving • The procedural guidance provided: a method should be
discipline, and there have been many related books decomposable into defined activities with their related
published in the past few years in addition to numerous rules, heuristics and resulting products. Furthermore,
research papers. However, several methods are not well the method should be applicable incrementally, pro-
documented (sometimes only a single short publication). viding refinements and additional detailed representation
The problem of unwanted digression from analysis to to support a non-monolithic approach. Quality assurance
design is especially acute when the same approach is being criteria should also be available in order to have some
used during the whole development process. It is therefore measure of certainty that the method has been correctly
not always clear which method to consider for analysis applied.
purposes.
Our choice has been to consider only methods which It is not surprising that no existing method addresses all

70 Information and Software Technology 1994 Volume 36 Number 2

 Improving object-oriented analysis: G Eckert and P Golder

the mentioned areas. Object-oriented analysis methods are

not yet mature and may be expected to undergo further
expansion.
intension
The provision of computer-based tools to support a.l~nr,.~,of t 1.n 0,1
level
analysis methods is another important aspect for their
practical use. However, support tools will not be con- m D .

sidered in this survey as the emphasis is on methodology

exemplar
and not on selecting an existing method. level

We shall concentrate on the coverage of structural I,I

aspects of a universe (static dimension) as this aspect is , :;~.~, . . . . . . . . . . . . .

o~
addressed by all methods. The dynamic dimension is level
addressed less uniformly and will only be superficially
covered here. This does not mean that operations should be
excluded. On the contrary, operations are part of the static Figure 2 OOSA-SM modelling constructs
object-oriented description of a universe because they
define the possible object behaviour. Furthermore it is the ship is also considered but is deferred until the trans-
consistent integration of operations into the modelled world formation into a relational data model has been performed.
that is typical for object-orientation. There is therefore a large overlap between this approach
In order to facilitate the comparison of the investigated and the entity-relationship and the relational model, the
methods, their modelling constructs are represented by an latter being more than just an implementation of the former.
entity-relationship (meta-model) diagram. An example of As shown in Figure 2, OOSA-SM addresses both the
such a diagram is given in Figure 1 and attempts to describe intensional and the extensional level. Its relational
the basic entity-relationship model itself. Primitive implementation defines an extensional level where tuples
modelling constructs are represented as entities (bubbles) are the exemplars.
while abstraction constructs are represented as relation- Single inheritance from an abstract supertype does not
ships between the primitive entities (arcs). The arc turn an entity-relationship model into an object-oriented
terminating notation depicts cardinality while the central one and, apart from the book title, there is not much object-
arrow is related to the given textual description and indi- orientation in this analysis technique. Perhaps this is the
cates the direction of its explanation. Where appropriate, a reason why the authors consider the method so easy to
distinction between the intensional, extensional and apply: 'Identifying objects is pretty easy to do. Start out by
exemplar level is shown. focussing on the problem at hand and ask yourself, What
An entity-relationship model is based on three primitive are the things in this problem ?'. The excessive preoccu-
constructs (the three- bubbles representing entities, pation with relational database tables and database keys
relationships and attributes) used to describe the modelled make objects look very much like tuples in a relation: no
universe. There are three related concepts at the exemplar proper identity, only atomic attributes and normalization
level (entity instance, link and value) but no explicit rules! The dynamic modelling is totally separated from the
distinction is made between intension and extension. data modelling. The second, more recent, book improves
and provides good procedural guidance for applying the
OOSA by Shlaer and Mellor method, including additional notation for representing large
The Object-oriented systems analysis method by Shlaer and systems (partitioning based on domains and subsystems).
Mellor (OOSA-SM) is based on a relational implementation However, operations are still kept totally separate and are
of an entity-relationship model. OOSA-SM is a very not considered until late in the analysis process.
traditional approach to information modelling where the
only additional modelling construct (abstraction) provided OOA by Coad and Yourdon
is the specialization-generalization relationship between Object-oriented analysis by Coad and Yourdon (OOA-CY)
entity types (called objects in OOSA-SM), although it is is primarily based on an entity-relationship model mixed
only briefly described. Addition of attributes to a relation- with some typical features of object-oriented languages or
databases such as message passing and system-generated
[Link]~tc object identifiers.
intension a n d
extension level The available modelling constructs (Figure 3) include
subtype relationship (single and multiple inheritance of

i1 o,n
) both attributes and operations) as well as two kinds of
relationship between entities:
n m
il-i~ata~-at il-iMtvc~-ef •
The traditional relationship known from the entity-
relationship approach and called 'instance connection'.
exemplar
level The assembly relationship (called whole-part structure)
which has a stronger meaning, although its semantics
stays very vague: 'Whole-part is one of the basic
Figure 1 Entity-relationship modelling constructs methods of organization that pervade all human thinking'.

Information and Software Technology 1994 Volume36 Number 2 71

Improving object-oriented analysis: G Eckert and P Golder

h~4tnlbuf¢
intensionand
extensionlevel

1,1 ~ l

me ~ ~ ~ mm ~ ~ am. is-instance-of , is-insumo=-of ms ~ ~ has-v~Jue

Figure 3 0 0 A - C Y modelling constructs

is-wb~o, f
(se~em)
has-atuibu~
>
intensionand
extensionlevel
is-d~i'¢~l-from

filet*

"2 (qtudtfl~l-auoeia~n)

d i~insw~e-of I~-valu¢
1,1
~ exemplar
level

Figure 4 0 M T - R a l modelling constructs

This sentence is repeated ad nauseam throughout the inheritance), the operations are not very consistently
book, but the reader has still to decide what it is integrated into the static model.
supposed to mean. Many specific notations are available for expressing
constraints and advanced modelling. The result could be
Operations (called services) are included in the overwhelming but fortunately the available constructs are
encapsulated objects, but very little guidance is provided divided into basic and advanced concepts. There are quite
for their formalization and definition. The dynamic good explanations and, although not formally defined, the
dimension (which is obviously more difficult) is only proposed notation is justified and compared with previously
superficially addressed and the examples provided are too introduced constructs. The description is intense and
simple to be realistic. condensed, and likely to be too demanding for an
Overall, the method provides simple and intuitive introduction into the field.
constructs clearly influenced by Smalltalk. The analysis The OMT-Ral model (Figure 4) can be considered as a
process is supported by an OOA model decomposed into superset of the OOA-CY model. It includes virtually all the
layers, one of them explicitly devoted to providing a higher constructs introduced by Coad and Yourdon and provides
level perspective and a domain summary (subject layer, not many more, while also defining them more precisely. The
included in Figure 3 for simplicity). The authors provide a major drawback is probably the total separation between
pragmatic and easy approach with a high level of the static and the dynamic model: operations are formally
informality. part of the static model but they are effectively ignored until
An implicit support for entity extensional level is pro- a separate dynamic model (influenced by structured
vided by class operations, which are used for the creation analysis) is constructed.
and deletion of instances. However, the term 'class' is used Intensional and extensional levels are mixed up by the
both with an intensional and an extensional meaning. introduction of metaclasses which can provide answers to
queries about their instances. The corresponding operations
OMT by Rumbaugh et al. (class operations) are said to be part of a metaclass
Object-oriented modelling technique by Rumbaugh et al. definition which is alternatively viewed as an entity type or
(OMT-Ral) is primarily an enhanced form of entity- as a collection containing instances.
relationship approach adding new concepts and constructs.
Although the influence of object-oriented languages or OOAD by Martin and Odell
databases is clearly visible with regard to generalization- The Object-oriented analysis and design approach by
specialization relationships between entity types (class Martin and Odell (OOAD-MO) is based on a relational

72 Information and SoftwareTechnology1994 Volume36 Number2

 Improving object-oriented analysis: G Eckert and P Golder

is-~~-~
is-mlalion~ip-bctwccn

is~mbly-between intension
0,2
level
~l.d~l is-immmable-usembly- betwee~ 0.~...I~
ig-lulaype-of-- ~ ¢ t ~ O , n ] (iw'mutable
0e ° 'm P2mm t~t i ~~l " is-subtyl~o f

q P hal-,~ is-atla'il~Re-ofN ~ lug-value

um mum iul i i ,urn Be i in i m ~ mm m i i m mm i

exemplar
level

mmm mm mm | m m mm m | m m | m m m m m m m •
is-row-of
extension
level

Figure 5 OOAD-MO modelling constructs

implementation of an extended binary data model. The and OOAD-MO is questionable as they have very weak
entity types represent simple, single values which are encapsulation and do not explicitly integrate operations.
related to other entities by binary relationships. Aggre- Being close to a relational data model, they do not provide
gation, association, composition and relation are the a high level of abstraction and are therefore not very
various possible interpretations of a relationship whose appropriate for problem analysis. OOA-CY and OMT-Ral
exact meaning depends on the interpretation of the two are similarly based on the entity-relationship model. In our
entities it connects (Figure 5). opinion, OOA-CY is a good initial approach to problem
While this simple generic structure is intuitively analysis because it is simple and intuitive and does foster
appealing, it is unfortunately not semantically more a broad understanding of the problem domain with various
expressive than a relational data model to which it can be levels of abstraction. It is a pragmatic method with good
considered as dual 21. Adding subtype relationship and guidance. However, it will be less suited to a meticulous
pompous terminology does not turn a binary model into an and more detailed analysis.
object-oriented one, but it can result in a very confused Some of its shortcomings are:
presentation of a data model, which is what has been
achieved. Using only trivial examples and inserting many • Restriction to atomic attributes.
irrelevant chapters, the authors succeed in confusing • Weak encapsulation.
readers by means of pseudo formal definitions. • Confused separation between object, definition of
Relationships are alternatively considered as immutable objects (object type), and collection of objects (set of
composition of entity types or as entity types themselves. object instances).
In order to avoid an infinite regress, it is important to avoid • No practical support for dynamic behaviour analysis.
continually making entity-relationship substitution: 'The • Very informal semantics.
replacement . . . should only occur when necessary'.
Object instances become pure value while relationships are OMT-Ral is a superset of OOA-CY. It does provide more
expressed by tuples. This results in objects without identity power; unfortunately this is mainly achieved through
and encapsulating nothing but an atomic value, which is additional specific constructs. As a result the method
visible. Operations are not considered while modelling the becomes more complex. Dynamic analysis is mostly
data. Modelling concepts and relation implementation achieved through an approach similar to structured
issues are mixed up at every stage. analysis.

Summary Other related methods

Figure 6 provides a summary of the four methods reviewed Other possible approaches are briefly discussed here:
here. This has been extracted from a more detailed
survey 22. It only covers material from the analysis phase Structured analysis as a front-end to object-oriented
of the four methods, although they possibly address design development: There is strong disagreement about the
or implementation issues as well. possible 'objectification' of structured analysis methods or
The methods which have been investigated are very much its use as front-end to object-oriented design 23'24. During
influenced by semantic data models. They all use entities an international conference, many experienced analysts
and relationships as foundation for later stages of analysis (including some 'fathers' of structured analysis) came to
and therefore significantly overlap with information model- the conclusion that structured analysis cannot be used
ling methods. The 'object-orientedness' of OOSA-SM effectively to produce requirements for a system that will

Information and Software Technology 1994 Volume 36 Number 2 73

Improving object-oriented analysis: G Eckert and P Golder

OOSA-SM OOA-CY OMT-Ral OOAD-MO

Origin ER + relational ER + [Link]. ER + [Link]. Binary + relational

Major problem low level superficial complex confused
OBJECT ORIENTATION
Object identity no yes yes no
Encapsulated properties atomic attribute atomic attribute operations atomic attribute operations single value
Classification mixed intensional and mixed intensional and mixed intensional and mixed intensional and
extensional extensional extensional extensional
Flexible sharing subtyping, single subtyping, single or subtyping, single or subtyping, single or multiple
abstract supertype multiple abstract or multiple abstract or concrete supertype
concrete supertype concrete supertype
Interpretation statically defined static typing dynamic
binding
DATA MODELLING
Primitives constructs entity entity entity entity
relationship relationship relationship relationship
attribute attribute attribute
operation operation
Abstractions classification classification classification classification
generalization generalization generalization generalization
assembly assembly assembly
operation activation qualified association immutable assembly
derived association relation
homomorphism constraints
constraints
TERMINOLOGY
Entity type object class class object type
Instance object object object
Relationship instance connection association
Generalization gen-spec structure inheritance
Assembly whole-part structure aggregation
Operation service
Operation activation message connection
SUPPORT
Reference Shlaer ~5'~6 Coad 66,6v Rumbaugh ~8 Martin 19
Work products 15 documents 7 documents 6 documents 5 documents
Graphical documentation 9 diagrams 3 diagrams 4 diagrams 5 diagrams
Large-scale support 2 constructs: 1 construct: 1 construct:
- domain - subject - module
- subsystem
Formality relatively formal very informal informal relatively formal
Procedural guidance 3 steps 5 guiding activities elaborated sequence 2 main parts
of 17 steps
Illustration 2 examples 3 examples 4 examples
Analysis description size 395 pages 233 pages 319 pages 339 pages
Transformation into design yes yes yes yes
Transf. into implementation no no yes yes

Figure 6 Summary of OOA methods

be designed and implemented in an object-oriented fashion. about the 'object-orientedness' of JSD although it is
However, some of them suggested that some extensions generally recognized that the initial JSD phase (modelling)
like entity-relationship diagrams would help to transform is close to an object-oriented approach. Rumbaugh et al.
real-time structured analysis into an OOA method2s'26. A find the JSD approach complex, difficult to fully
practical issue here affecting the debate is that out in the comprehend and not appropriate to analysis because it
field there are many analysts trained and experienced meticulously handles details but does not foster broad
primarily in structured analysis. Consequentially, there are understanding of a problem ~8. Other authors acknowledge
strong reasons for continuing to improve it 27-29. that the meaning of a JSD entity (object) is primarily an
ordered set of actions and not a data encapsulation, but still
Jackson System Development (JSD): JSD was developed consider JSD an object-oriented m e t h o d 32'33.
by Jackson 3° and Cameron 31. It is a three-phase process:
modelling, networking and implementation. JSD is prob- Design methods: Many design methods also include
ably the most mature instance of the operational approach guidance about the identification of objects in the problem
and has therefore a great deal of appeal. It is a mixture of space. This usually consists of an informal strategy outlined
problem analysis, requirements specification and system in a single paragraph describing the system to be built.
design without clear-cut phase activity. Authors disagree Looking for nouns and pronouns should help in identifying

74 Information and Software Technology 1994 Volume 36 Number 2

 Improving object-oriented analysis: G Eckert and P Golder

the objects of interest while adjectives would map to further steps away from this basis are required in order to
attributes and verbs be related to operations. Iterations and achieve a truly object-oriented approach to system analysis.
refinements eventually lead to the identification of all the In this section, we will discuss possible improvements to
relevant elements in a whole specification document 34-37. current object-oriented analysis methods. There are three
In our opinion, these steps should not be included in a main aspects in our proposal. We will first argue that a pure
design method but are typical of problem analysis. It is object-oriented approach should not be based on the entity-
sensible to assume that the deliverables produced by an relationship-attribute trilogy but on an object-relationship-
OOA method include all the above elements. The snag operation triad. Within this framework, we advocate a
about this argument is that design methods were developed strong notion of encapsulation and finally we claim that
before OOA methods. Therefore they start from a functional clearly distinct constructs should be used to model
requirements document that already exists and suggest classification intent and extent.
steps to reorganize it into an object-oriented requirements
document. This approach is unlikely to be very efficient as Attributes
it does not analyse the problem itself but rather a textual Is there a firm distinction between the concepts of entity and
description of one prescribed solution. A discussion of its attribute? For the entity-relationship approach (and most
practical difficulties can be found in Freitas et al. 38. OOA methods), the answer is 'yes', and it would be a
OOA methods typically do not offer any guidance contradiction to consider an attribute of an entity as an
concerning the way to deal with an existing specification entity itself. The well-known restrictions of this basic
document as they are intended to be applied before this assumption have led to a variety of extensions to the entity-
document has been written. relationship model. For example, Parent and Spaccapietra
Another point is the reusability issue which is considered allow for either atomic or complex, possibly multivalued
fundamental by object based design methods. Again, attributes. A complex attribute is made up of a set of other
software reuse is not an issue during analysis, although the attributes (its components). Component attributes may be
reuse of analysis artefacts is an emerging area (so-called atomic or complex, with any number of nesting levels. But
domain analysis). in order not to confuse the respective roles of entities and
attributes, these extended models do not allow entities to be
Other surveys: There are some recently published used as attributes of other entities 44.
comparative studies of OOA methods: Current OOA methods map entities to objects and
therefore keep this ontological view. The resulting clean
• Comparison of object-oriented and conventional separation between objects and attributes could be
analysis and design methods39: Fichman and Kemerer considered as a sound basis, or it might be considered as
specifically discuss whether object-orientation is a a major flaw in the approach. How can we decide whether
radical change or just an elaboration of old techniques. a real-world concept is to be modelled as an object or as an
• Comparison of 12 OOA methods4°: Champeaux and attribute? What are the consequences of a possibly wrong
Faure include methods for which documentation is decision?
minimal. Their study also surveys the behaviour A commonly suggested approach is to consider
dimension. 'primitive' or 'atomic' elements as attributes. Typically,
• Evaluation of 23 OOAD methods4t: Monarchi and Puhr integers and characters are supposed to be pure data values,
attempt to identify the critical components of a cohesive without identity and therefore suitable as attributes (like
approach, and to map many development methods to this lower class citizens). This argument seems to be very much
framework. influenced by programming language implementation
• Survey of both structured and object-oriented issues. How can we recognize atomic elements in the real
methods42: Sutcliffe briefly surveys some object- world? It is likely that the perceived atomic elements will
oriented and system development methods. very much depend on the considered universe and
• Section 7.3 of Graham 43 concentrates on existing application. For a clerk issuing passports, a picture may be
object-oriented analysis methods and suggests an atomic element. But for a photographer creating
extensions to them. pictures, it is a whole universe.
Considering attributes as objects themselves leads to a
In contrast to those studies, this paper formally compares simpler model with a small number of modelling
the available modelling constructs by meta-modelling them. constructs. Furthermore, it is a nice theoretical approach
Meta-models reveal similarities and differences which often and, we believe, a sound basis for modelling at various
go unnoticed in informal comparisons. levels of abstraction. During analysis, we have to modify
or refine our model and it is an advantage to keep the same
mental tool at various levels of detail while consistently
A proposal
applying our object model. At a given level of abstraction,
Current object-oriented analysis methods are enhanced data we identify concepts and objects which appear to be simple
models ('objectified' entity-relationship models) which and understood. We may abstract them as 'primitive'
have not consistently integrated the very essence of object- objects and leave unanswered the question of their internal
orientation. We recognize that information modelling structure. Later we will perhaps have to refine our
represents an appropriate foundation but we argue that description, or we will consider additional details. As our

Information and Software Technology 1994 Volume 36 Number 2 75

Improving object-oriented analysis: G Eckert and P Golder

attributes are themselves always objects with full rights For every kind of mass about which we want to record
(upper class citizens), adding further details should not information, we define a measure, which is a function from
change much of our model, but only refine it. masses to discrete objects45 Attribute objects are used to
This capability of progressively incorporating more represent mass measurements.
knowledge while retaining the already established frame- Object-oriented languages often use the term attribute
work is an advantage claimed for the object-oriented with the meaning of object designators (a reference or a
approach and the main reason for applying a uniform object pointer to a particular object). Object designators are
model. By focusing first on existing objects in the neither objects nor proper relationships between objects.
application domain, we hope to establish a firm and stable
model which can be extended once we have identified more Relationships
details. The term attribute does therefore not refer to a The inclusion of association (or connection) relationships as
special kind of object but only to a special relationship a fundamental semantic construct is a major distinction
between objects: the encapsulation. An object may between object-oriented analysis and current object-
encapsulate other objects (its attributes) which are used to oriented design methods. Rumbaugh claims that relation-
represent its internal properties (its state). ships are more important than generalizations for large
We could say that attributes are components and systems because of their effect on the partitioning46.
therefore participate in a composition relationship (aggre- Indeed, all the studied OOA methods provide a relationship
gation). However, this introduces the unwanted whole-part construct that clearly expresses associations and constraints
semantics. Is the attribute 'red' a component of my car? We among objects, capturing the semantics of a system.
advocate a more neutral and universal relationship between Association relationships are inherently symmetric and can
an object and its attributes; a relationship that does not be traversed in either direction. A link (relationship
intrinsically convey a definite meaning. The whole-part instance) is not part of either related object by itself, but
semantics is only one possible meaning for this relation- depends on both of them together. It should therefore be
ship. Furthermore, the whole-part semantics proposed by modelled externally, using a higher level semantic
Coad-Yourdon and others do not imply the encapsulation of construct. The externalization of references between
the components. On the contrary, the parts are considered objects permits a symmetric, non-redundant conceptual
at the same level than the whole and are accessible without model with its own special notation.
any restriction. The fundamental notion of encapsulation is Associations are often implemented in object-oriented
therefore not conveyed. databases and programming languages as pointer attributes
We want proper attributes to be strongly encapsulated from one object to another: an object contains an explicit
within the object they are describing. Simultaneously, we reference to another object. In our view, this confuses
want attributes to be objects themselves, with full rights. attributes (internal property or state of an object) and
The Figure 7 is a possible representation of an object associations (external links between objects at the same
person encapsulating three attribute objects describing its level). Furthermore, a bidirectional link would have to be
properties. The encapsulated arcs are used to visualize the implemented using a pair of matched pointers that are
attribute relationship between the person and its character- dependent upon each other but are hidden in their related
istics. Relationship cardinality constraints allow for object. The inherent cardinality constraints would be buried
optional, single or multiple attribute objects. It is worth within operation code instead of being specified abstractly
adding here that additional relationships are possible among without imposing an implementation ~8. Representing an
the encapsulated attributes themselves. association between two objects as an attribute in each
Considering attributes as objects does not imply that object fails to capture its semantics because the information
everything in the world is an object. Wieringa distinguishes abut the association is distributed and hidden rather than
between objects and masses: being specified in one place. The constraint that related
objects must mutually reference each other cannot be
• An object is anything that can be put in a set. Objects are
explicitly expressed.
discrete and can be counted. Of objects we can ask how
The conclusion is that the use of the association
many of them there are.
relationship as a conceptual construct can help capture the
• By contrast, a mass cannot be put into a set or counted.
semantics of a system more clearly than the use of object
Of mass we can ask how much of it there is. Splitting or
pointers. Binary associations seem adequate to model most
merging a mass yields a mass.
applications while the specification of cardinality is useful
in tightening semantics and reducing unnecessary
operations.
Like programming languages, most object-oriented
databases do not provide direct support for association
relationship between objects but only for object references
through attributes (sometimes called complex objects) 47.
Such complex (or composite) objects may be used to repre-
sent aggregation or composition between objects, provided
that the intrinsic asymmetry of object referencing is accept-
Figure 7 An object and its attributes able. However, we believe that the general association

76 Information and Software Technology 1994 Volume 36 Number 2

 Improving object-oriented analysis: G Eckert and P Golder

Figure $ Nested objects and their relationships

relationship should not be confused with the more specific clusters of related objects from a given perspective. Every
aggregation relationship. Aggregation is a special form of object may itself contain other objects which represent its
association. It adds the 'part-of semantics and it is often the internal structure and model its intrinsic properties. Every
case that only the whole-part direction need to be traversed. encapsulation therefore divides the universe into an inside
Moreover it is not sensible to only provide an intrinsically view (its internal structure, focusing on additional details at
asymmetric construct because it is a rather low level a lower level of abstraction) and an outside view (all other
building block unable to model general associations among objects, at the same or at a higher level of abstraction,
objects. Modelling association relationships must be based neglecting internal details). It is sensible to restrict
on a more universal construct. Existing object-oriented data visibility of the nested objects and not to allow association
models provide various ad hoc constructs that aim at relationships to go through an encapsulation (an object).
relationship modelling. For instance, Kim et al. provide Therefore an object may only have links with objects which
detailed and formal discussions of a model of composite are part of the same encapsulation (same inside view). A
objects which is somewhere between the use of references major task during modelling is therefore to organize
and the use of association relationships 48'49. meaningful chunks of objects.
Objects which are equally important entities of the
Encapsulation universe of discourse at a given focus of attention should all
Encapsulation is the grouping of various properties behind be visible together. At the highest level, we can think of our
a protective interface. Encapsulation is completely funda- whole universe as being a single object encapsulating all
mental to the object-oriented approach and is the reason for relevant properties as its attributes which define its internal
many of its benefits, e.g. modularity and maintainability. structure (inside view). The main concepts are represented
However, many OOA methods only provide a weak by internal objects which in turn encapsulate their own
encapsulation of atomic attributes, without operations. properties as attributes. These attributes may be linked
Furthermore, the object is considered a white box, being together by assocation relationships. Therefore we can
little more than a logical grouping of visible primitive represent our universe as a kind of nested object-
values. relationship diagram. Each object may contain attributes
If we suppress the conceptual distinction between (other objects) and their possible links. There is no limit in
attributes and object and only keep objects and relationships the depth of the nesting but most systems will exhibit a
as fundamental constructs, we obtain a kind of binary data much larger structure at the top level (the whole universe)
model 2'. The graph of a binary data model can be than at lower levels. Figure 8 illustrates this notion of
considered as a dual of the table structure of the relational nested objects and their relationships.
data model, elegant in its simplicity, but very limited Returning to the role of object attributes, it becomes clear
semantically. that it is therefore possible to consider two fundamental
Encapsulation enhances and elaborates this basic data kinds of relationships between objects:
model by providing nesting within objects. Abstraction and
encapsulation are complementary concepts: abstraction is • The (internal) attribute relationship where an attribute is
the outside view of an object and encapsulation prevents contained (encapsulated) within another object. Its
viewers from seeing the internals. Encapsulation provides semantics will usually be 'has-property', 'has-a', 'is-
explicit barriers among different abstractions 5°. Note that composed-of', etc.
during analysis we do not really want to hide the internal • The (external) association relationship between two
structure of an object. These internals are also relevant objects existing at the same conceptual level. This is the
parts of the modelled world, albeit at a different level of traditional relationship of the entity-relationship
details. During analysis, we only want to clearly separate approach. The corresponding semantics is usually very
different focuses of attention. This is not quite the same precise but encompasses a broad spectrum of possible
goal as the use of encapsulation in programming languages meanings: 'works-for', 'manufactures', 'manages',
where it is applied to hide a freely modifiable implement- 'drives', etc. Note that 'is-composed-of' is also a
ation. During modelling, encapsulation is used to define possible semantics, as with the attribute relationship.

Information and Software Technology 1994 Volume 36 Number 2 77

Improving object-oriented analysis: G Eckert and P Golder

This depends on the role that the parts play at the level universes are more expressive and there is strong evidence
under consideration. We may consider a car as an that a priori categories imposed on human cognition should
assembly of parts. For a car manufacturer, it is likely be emulated in the artificial worlds designed by humans.
that major parts will be treated in the same way as the A type defines an abstract interface and possibly a
finished assembly, while for a car driver the components corresponding structure. A type denotes a behaviour.
will simply be an internal property of the car. Every instance of a type will obey this behaviour which is
shared by all instances. Every instance knows its type and
Because we do not consider any specific implementations, has exactly one type for its whole lifetime. Note that there
it is not necessary to discuss how such a nested object- are other approaches considering multiple types or
relationship model could possibly be transformed into an changing types but most of the benefits of such flexibility
object-oriented database or programming language imple- can be achieved by other distinct mechanisms which will be
mentation. However, it can be assumed that all the described in the next section.
relationships will eventually be implemented in terms of Each object is said to be an instance of exactly one object
object references, which therefore represents an imple- type, where the instantiation relation is an unexplained
mentation rather than a modelling construct. A rather primitive. Types themselves may be instances of higher-
surprising consesequence is that the use of references order types or metatypes but this issue will not be discussed
breaks down the encapsulation barriers and means that here. The concept of type is intensional because it describes
objects can directly access and manipulate the 'internal' common features of a possibly infinite number of cases.
state of others 5~. This is due to the fact that systems with The term class is often used in databases to denote the set
reference semantics only encapsulate the references, but do of all instances of a type; in other words a class is the
not encapsulate the objects they refer to. Incidentally extension of a type. Unfortunately the term class is also
encapsulation is also severely compromised in most object- used in programming languages to denote a type, together
oriented languages by the introduction of inheritance 52. with its particular implementation.
By defining a type the way we did, we imply that the type
Operations of an instance is an essential property. This means that the
Authors in the object-oriented programming language and common behaviour and structure associated with the type
database area all agree that objects encapsulate both data cannot exist without displaying those features and remains
(attributes) and operations (methods, services) acting upon an instance of this type in all possible states of the system.
that data. The operational interface to an object is restricted This clearly relates the notion of type to the internal
to its defined set of operations which are allowed to perform structure of an instance (its attributes and their internal
within the context of the object. relationships) and excludes the external association relation-
However, many OOA methods do no explicitly include ships because they are not essential but only contingent.
operations but concentrate on the structural abstraction of Different types may be related by supertype-subtype
objects and relationships. This is clearly a consequence of relationships. A particular type S is a subtype of a type T
the data modelling driven approach because data models if S provides at least the behaviour of T 54. An instance of
are oriented towards the representation of data rather than type S can thus be used as if it were of type T because it
its manipulation. The consequence is the poor integration of is guaranteed to provide at least the operations and
operations which are described using separate functional properties of T. This is also referred to as conformance
models (mostly based on distinct data flow diagrams). (type S conforms to type T).
There is no doubt that operations should be included The subtyping relationship has well-defined semantics
during analysis. Both the structural and the behavioural based on the mathematics of partial orders and its well-
aspects of objects most be modelled. The synergy between known properties therefore hold for subtyping:
these two views can only be achieved by encapsulating both
together. By ensuring that the defined operations for an • Reflexivity (all types conform to themselves).
object provide the only way to access that object's • Transitivity (if one type is a subtype of a second type and
properties, we provide a specific behavioural description. that second type is a subtype of a third type, then the first
We consider operations as the third fundamental modelling type is also a subtype of the third type).
construct, together with objects and relationships. Object • Antisymmetry (two types are equivalent if they are both
operations are ultimately responsible for providing the subtypes of each other).
expected system functions. No services exist unless there
are related operations performed by the appropriate Subtyping between object types is related to subtyping
objects. A set of object operations is defined by creating an between abstract data types 55. An abstract data type S is a
object type. subtype of an abstract data type T if and only if:

Object type • S provides at least the operations of T (S may have more

In a detailed discussion, Wegner claims that typing should options).
occur early rather than late in the process of modelling a • For each operation in T, the corresponding operation in
universe of discourse, even when developing informal S has the same number of arguments and results.
models 53. Typed universes provide a richer and more • The types of the results of S's operations conforms to the
flexible framework for thinking and model building. Typed types of the results of T's operations.

78 Information and Software Technology 1994 Volume 36 Number 2

 Improving object-oriented analysis: G Eckert and P Golder

• The types of the arguments of T ' s operations conform to but redefine (override) particular operations. The
those of S's operations. resulting subclass will generate instances of the same
type as its superclass because they have the same
Note that the last rule is rather surprising because it re- interface with different implementations.
quires the parameters of subtype operations to be instances • Another common case is the selective (or restricted)
of supertypes (antimonotonicity or contravariance). There inheritance where only a subset of operations are
is no question that these conformance rules ensure that type inherited by the subclass, particular operations being
errors will not occur. However it is also recognized that the blocked because they are inappropriate for the subclass.
rules are too restrictive. For example, many correct This results in actually creating a supertype because its
programmes could not be successfully typed using these interface is a generalization and not a specialization.
rules 56. More permissive subtyping rules would be both • If the subclass solely adds new operations then the
natural and useful, allowing more flexibility. An attempt to resulting type is a subtype.
provide more flexibility was partially implemented in the
Eiffel language 57. Unfortunately it has been shown that it In many practical cases, all three kinds of modifications are
is unsound because run-time typing errors can occur performed together (extension by adding new operations,
although the language is said to be strongly typed5g. Other redefinition by reimplementation of some operations and
recent proposals for subtyping rules can be found in restriction by blocking operations). This results in a sub-
Ghelli 59 and Leavens 6°. Another drawback of the above class with no defined typing relationship to its superclass:
rules is the fact that they are based on the syntax of the it will generate instances that are neither of the same type
specification alone, although subtyping should include nor of a supertype or a subtype. This is a consequence of
semantics conformance as well. the fundamental purpose of inheritance or subclassing in
Resolution of these difficulties is an active research area programming languages: it is basically a mechanism for
and further discussion about it can be found in the code reuse and not a modelling construct.
references already cited as well as in Cardelli 14. However,
the above rules provide a workable means of incorporating Collection of objects
static type checking in a polymorphic description of a It has been mentioned that there is a tension between the
universe. programming language notion of class to mean object type
and the database notion of class to refer to the set of objects
Consequences of the subtyping rules. A subtype can only themselves. While a type is referred to as specifying an
extend its supertype by adding new operations (strict intensional aspect, there is a need to be able to denote the
inheritance) but is not allowed to restrict the set of inherited related extension which groups objects in a collection.
operations (selective inheritance). Semantics preserving Programming languages have traditionally concentrated
redefinition or alteration of operations does neither lead to on providing sophisticated ways of defining object intents
a proper subtype nor to a supertype but results in an while in the database view there is an assumption that there
equivalent type which is therefore not distinct in the type must be system-supported mechanisms for grouping objects
hierarchy. into collections automatically so that they can be referred
A given type may have an unlimited number of different to as a single unit. This collection will be used by ad hoc
subtypes, leading to a hierarchy whose root type is typically queries and its member objects are always accessible in this
called 'object', 'concept' or 'any'. Allowing multiple manner.
supertypes leads to a directed acyclic graph (lattice) On the other hand, the programming language com-
between types. munity considers a collection of objects as an application
The abstract data type approach implies that the internal that the programmer has to create and manage. The
structure and implementation remain hidden. Subtypes programmer is also free to decide whether objects should
therefore only inherit the operation specifications and not be accessible or not without acquiring explicit references.
the operation implementations or the internal type Types themselves do not provide access to their object
structure. The conformance rules do not require anything instances. This has many profound consequences, one
about object internals and therefore do not compromise of them being the way objects can be created and
proper encapsulation. Note that this is not the case for most deleted. Programming languages can automatically delete
object-oriented programming languages where the internal objects when they are no longer accessible (out of scope or
structure and the operation implementations are reused without an explicit reference pointing to them). On the
(usual meaning of the term 'inheritance'). other hand databases require explicit deletion because every
Traditional object-oriented programming languages object is always accessible through the collection it is
commonly have no explicit notion of type, the closest member of 61.
concept being the class. A class is fundamentally an We believe that an analysis method must provide separate
implementation whereas a type l in our definition - - is constructs for typing objects (specifying their abstract
concerned with specifying an abstract behaviour. The properties) and collecting them into various chunks with
difference between class and type is perhaps better built-in accesibility.
understood when comparing subclassing and subtyping: Collection, set or extent can be use as alternative terms
to denote the set of object instances while avoiding the
• A subclass may retain the same interface as its superclass overused term class. Collections allow access to their

Information and Software Technology 1994 Volume 36 Number 2 79

Improving object-oriented analysis: G Eckert and P Colder

members at any time and let them participate in association can play. Person would be considered as a type while
relationships with other objects which are members of the employee would be modelled by a subcollection of persons
same or another collection. having an employment relationship with a company. If the
A collection of objects might also be divided into modelled universe includes genetic mutations the analyst
subcollections (subsets). This should neither be confused may even consider person as a possibly changing role
with subtyping nor with the specialization mechanism played by living beings!
provided by many semantic data models. The specialization We believe that there is a need for an appropriate modelling
between data model entity types (is-a hierarchy) usually support for such decisions. A comprehensive analysis method
includes two constraints: should therefore provide appropriate conceptual tools
by distinguishing clearly between object types and collection
• The descendant elements must have specialized of objects, and by providing distinct support for both.
properties compared to the ancestor elements. This is an This distinction means that a collection can itself be
intensional constraint which was dealt with in the considered as an object representing a repository and
previous section using the subtyping relationship. having an association relationship with its members. A
• The descendant elements must represent a subset of the collection is therefore not a distinct fundamental construct.
ancestor elements. This is an extensional constraint However it would be an undue burden to have to devise
which is also useful during modelling and will be called such collections and they are better included via a built-in
subcollecting hereafter. modelling construct, together with its related predefined
operations (query, creation, etc.). Furthermore, it is
The reasons for subcollecting objects are quite different important to realize that a collection is not an object
from the reasons for defining object subtypes and this is containing a group of objects. It is only a way of grouping
why these two mechanisms should be kept clearly separate. and accessing all existing object instances. There is no
Members of a subcollection are members of its super- encapsulation of the collection members.
collection as well. An object may be a member of many There are published research accounts of database
collections within different levels of a single collection systems which emphasize a clear distinction between type
hierarchy and its memberships may change over time. and collections, for instance62-64.
Collection membership is therefore usually related to
external events or relationships with other subjects. While Consequences of the subcollection rules. It is easier to only
type was essential, collection membership is only consider partition into disjoint subcollections (non-
contingent which means that a member plays a role and overlapping subsets) which can be complete or partial,
can exist without playing that role. Events (operations) may meaning that the subcollections include or do not include all
cause an object to start playing a role or to change its role. the members of their supercollection. However, there are
Playing a role will often involve links with other objects many situations where it is useful to allow overlapping sub-
playing related roles. Collections are therefore repositories collections or multiple supercollections. Considering single
for objects involved in association relationships. supercollections we obtain a collection hierarchy with a col-
In order to decide whether subtyping or subcollecting (or lection root. There are basically no restrictions on the number
both) is appropriate, one should investigate the related of collection hierarchies in a system. There is usually at least
instance properties. If a property is essential and will be one collection for each defined object type but it is perfectly
satisfied in all possible states of the system during the whole possible to have a type without any collection using it or
lifecycle of the instances then a subtype is appropriate. If another type used by many collections and subcollections.
the property is changing and only applicable for particular A given collection is declared to group instances of a
states of the instance then subcollecting should be used, particular type. The member objects of that collection must
possibly together with specific association relationships therefore conform to this type (they may be instances of the
with other collections. declared type or of any of its subtypes). A collection
Once again this is a modelling decision which depends on declared to group instances of the root type 'object' may
the universe of discourse. In a given context an employee therefore include objects of any defined type. A sub-
may be considered to be an instance of a type employee collection may further restrict the type of its members.
because the corresponding instances have no existence Type restriction is an example of constraints that a
other than as employees. We may then decide that our collection may enforce. Other possible constraints may be
abstraction of employee is a specialization of the type object imposed through cardinality range or various predicates.
or perhaps of the type person. In the same context, em- Collections also provide predefined operations, for instance
ployees may play various roles, for example they may creation, deletion, retrieval, etc.
either be hourly or monthly paid and may change from one
to the other, thus involving different relationships with Atomic and immutable objects
other existing enterprise entities. Subcollecting the em- Because every attribute is an object, it must itself have
ployee instances into distinct groups would be appropriate. attributes. And what about the attributes of the attribute
This model of the problem space is not objectively given objects? This recursion is broken by atomic objects (objects
but results from a decision made by the analyst. In a without attributes). As attributes are used to internally store
different context, the analyst may consider that being an the changing state of an instance, the state of atomic objects
employee is only one of many possible roles that a person cannot change over time. Their behaviour is therefore

80 Information and Software Technology 1994 Volume 36 Number 2

 Improving object-oriented analysis: G Eckert and P Golder

completely defined by their operations alone and they are internal structure and adding attribute objects and association
immutable. From an external point of view, immutable relationships within the previously atomic object.
objects are simply instances of a type that does not provide This illustrates the recursive application of the entire
update operations. Therefore no change in their properties object-oriented analysis method at successively lower
will ever be possible and they are purely static. Distinct levels of abstraction. By breaking the problem into
instances of the same type can no longer be different in the manageable chunks, the analyst can incrementally refine
sense that they must have exactly the same properties, the object composition hierarchy, create new object types
although they are distinct and uniquely identifiable through and add new objects. The important point is that these
their object identity. refinements are local to an entity and therefore hidden
Integers are conveniently considered as immutable within an object type definition.
objects. But they do not all share the same properties; we
expect that the integer object '2' behaves differently from Object identity
the integer object '7'. Do integer objects have an attribute Object-oriented databases stress the unique identification of
to remember their state (2 or 7 or whatever)? evey object by an object identifier. Every real-world object
At this point we must clearly distinguish between is an individual with something unique. When real-world
atomicity and mutability. Atomicity is an internal objects are modelled with some particular purpose in mind,
characteristic (no attributes), whereas immutability is however, only some subset of that object's description is
externally observable (no update operations). Atomicity included in the model. This subset may not be complete
implies immutability, but the converse is not true. Integer enough to capture the object's uniqueness 65.
objects must clearly be immutable, but not necessarily The proposed solution is to incorporate a strong notion of
atomic. Let us illustrate both atomic and non-atomic integer identity at the conceptual level. This means that an object's
representation: uniqueness is modelled even though its description is not
unique. Objects exist independently of their current attribute
• The atomic alternative is to consider every different values; there is therefore always a (system-managed) way
integer value as generated by a different subtype of inte- to distinguish between two objects which happen at some
ger. This subtype specializes the integer behaviour for one point in time to have the same property values. The identi-
specific integer value. Under this assumption, all subtype fication of objects is based on nothing but their existence
instances exhibit a common integer behaviour in addition and this therefore frees the analyst from the bothersome
to their value-specific behaviour. Different integers are task of defining artificial identifier attributes (keys).
modelled by instances of different integer subtypes. Those
instances behave differently although they do not have any A simple example
attribute to remember a state. On the other hand, all Figure 9 summarizes the proposed analysis approach by
integer instances which model a given integer value have representing its modelling constructs in the same way that
the same behaviour. They are all equal, although they are the other OOA methods were represented.
distinct objects. Finally, we may consider a restricted The type hierarchy defines the external view of each
range of possible integer values, therefore avoiding an possible object instance in the universe and therefore
infinite number of integer subtypes. addresses the intensional level of the model. The
• Immutable integer objects may alternately be defined in extensional level is described by the various collection-
terms of other attribute objects like digits or bits and relationship diagrams used to define the related internal
would therefore not be atomic. According to such a non- structures. Recall that these diagrams are nested, the
atomic integer representation (as a collection of digits nesting occurring when a population of object instances is
for instance) ten distinct digit subtypes would be enough created, each of them containing an internal collection-
to allow the representation of any number. Even two relationship structure with its own object population.
basic symbols would be sufficient using binary There is a top level collection-relationship diagram
representation. Integer objects would then be non- representing the extensional level of the whole application.
atomic immutable objects, the digits (or bits) being the As such it therefore describes the internal structure of the
atomic building blocks. object type 'application' or 'universe' which usually
generates a single object instance.
This discussion has led to low level considerations which Finally, the behaviour of object instances is further
are not appropriate during analysis but illustrates that we do described through their operations. This description is
not need additional primitives. In a practical implemen- usually based on events and predefined operations applied
tation, it is clear that built-in operations can simulate both to the internal collection-relationship structure.
described solutions. Figure 10 summarizes the characteristics of our proposal,
Atomic objects are also useful as rough drafts. When using the previously defined criteria. We do not claim that
beginning the modelling task, a first approximation of a real the proposed approach is a mature method and therefore we
world object may be an atomic object. Using the predefined only incorporate the object-orientation and data modelling
manipulation facilities for collections of objects, it is already dimensions.
possible to model real world entities and prototype simple The following simple example should clarify the app-
simulation scenarios. It is later possible to add more details roach. We consider a company application with a type
and move to a lower level of abstraction, investigating the hierarchy given by Figure 11. The meaning of this diagram

Information and Software Technology 1994 Volume 36 Number 2 81

Improving object-oriented analysis: G Eckert and P Golder

intension
level

exemplar
level

extension
level

Figure 9 Proposed OOA modelling constructs

is that any object instance in our model must be an instance

of one of the declared types. The whole application will be
an instance of the type COMPANY which is a specialised
OBJECT type. Other possible objects in our model may be
instances of types PERSON, EMPLOYEE (a specialized
OBJECT ORIENTATION person), DEPARTMENT, ROOM or simply OBJECT. For
Object identity yes each type, we have to define its related operations
Encapsulated properties object, relationship, operation according to the conformance rules (see above).
Classification distinct, intensional and extensional
Flexible sharing subtyping and subcollecting The next step is the definition of the internal collection-
Interpretation statically defined relationship structure for our top level abstraction. A
simplistic collection-relationship diagram for an instance of
DATA MODELLING
COMPANY could be defined as shown by Figure 12.
Primitives constructs object
relationship This is a diagram similar to the conventional entity-
operation relationship representation but the collections explicitly add-
Abstractions encapsulation ress the extensional issue by defining a range for their
essential classification (type: 'is-instance-of)
contingent classification instance population. The collection Employees will group be-
(collection: 'is-element-of') tween 0 and 'max' instances of type EMPLOYEE. Each mem-
essential generalization (subtype) ber of the collection Employees is either a junior or a senior
contingent generalization (subcollection)
employee, two possible roles considered in the company and
modelled by subcollections. Every employee works for
Figure l0 Summary of the proposal exactly one department while only senior employees may be
head of a department. Membership to the Seniors collection
is restricted to those who have been employed at least during
six months by the company. We also see that the company
may not be divided into more than 10 departments.
We can now move to a lower level of detail and consider
the internal structure of other objects in the system.
DEPARTMENT instances could be modelled in the way
illustrated by Figure 13.
Every department instance is defined by a collection of
ROOM instances. Every room communicates with one or
many other department's rooms. Exactly one room must be
used as general office. It is important to recall that the
rooms which are members of subcollections are simul-
taneously members of their supercollection O~ces as well
and therefore also participate in the communicate-with
Figure 11 Simple company type hierarchy relationship. On the other hand, the semantics of subtyping

@2 Information and Software Technology 1994 Volume 36 Number 2

 Improving object-oriented analysis: G Eckert and P Golder

Figure 12 COMPANY collection-relationship structure

Figure 13 DEPARTMENT collection-relationship structure

in the type hierarchy is different because an instance of • Every application has its own type hierarchy with root
EMPLOYEE is not an instance of PERSON. The behaviour OBJECT. However, practical modelling may be based
of an employee is a specialization of the behaviour of a on a predefined type hierarchy which can be freely
person, which means that an employee is able to perform adapted for each application.
any operation that a person could be requested to carry out.
The internal structure of an employee may be different from
Remaining problems and practical work
the internal structure of a person. It may add collections and
relationships, modify existing cardinality constraints or Outstanding problems
totally change the collection-relationship structure. The Our proposal is not an extension of existing OOA methods;
only restriction is that the employee must [Link] able to it departs radically from many of their aspects. It is still in
perform the person's operations. a preliminary stage of development and we do not claim
We could now further refine our model by describing that it is mature and adequately precise in its current state.
this employee structure, which would probably require There are still many unresolved issues which need further
additional types like BIRTH____DATE and NAME to be added improvements, the most blatant one being related to the
to the type hierarchy. description of operations. How should operations be formally
Some remarks are worth making here: specified and described? What kind of parameters may be
used? What results will be produced? We should avoid
• An object collection with cardinality constraint 1,1 is algorithmic descriptions and use a declarative style of
similar to a traditional attribute value. A cardinality of operation specification, possibly using preconditions and
0,1 implies an optional attribute while constraints like postconditions based on the state of the collection-
O,n allows for multivalued attributes. Subcollections and relationship structure. We also have to consider predefined
relationships have no traditional equivalent at the operations applicable to any collection: query, retrieval,
attribute level. update. A declarative specification language would
• A collection-relationship diagram may include any num- probably be appropriate.
ber of collection-subcollections hierarchies using any Could the result of an operation be an object, or the copy
defined type. The same type may be used by different of an object, or a reference to an object? Because all objects
collections in different structures of the universe. model real world objects we have to be very cautious:
• There are no meaningful structural inheritance rules.
Each subtype must therefore describe its own collection- • If an operation returns an object, then this unique
relationship structure together with their related instance has been extracted from some collection and
operations. Because of the strict encapsulation of the this should reflect a change in the real world.
internal structure, operation descriptions based on the • If an operation returns the copy of an object, then we
internal collection-relationship structure cannot be have created another unique object with its own identity.
reused. • If an operation returns a reference to an object, is it

Information and Software Technology 1994 Volume 36 Number 2 83

Improving object-oriented analysis: G Eckert and P Golder

possible for this reference to go through an encap- Conclusion

sulation barrier?
This paper has attempted to describe a framework for
object-oriented analysis. Current object-oriented analysis
There are many related issues like visibility rules for
methods are rapidly evolving but the field is by no means
operation activation, concurrency, instance creation and
fully mature. We claimed that current methods are little
deletion, etc. More generally, the dynamic modelling area
more than enhanced data modelling techniques. We
has not been addressed in this paper.
advocated a systematic and consistent use of three
Another area for further improvements is the lack of
constructs (objects, relationships and operations), together
support for projections. A flexible approach should allow
with a strong notion of encapsulation and distinct type and
multiple viewpoints because we often have conflicting
collection classification support.
perspectives. For a car manufacturer, a car is an assembly
of parts where each component must be visible. For its
driver, the same car is a single object with encapsulated Acknowledgements
components. Could both perspectives be reconciled?
Finally there is a clear need to formalize or at least Most of this research has been accomplished at Aston
standardize object-oriented concepts if a true foundation University, G. Eckert would like to express his gratitude to
for object-orientation is to be laid. Advances in type the Swiss National Science Foundation and the Foreign and
theory, data models and knowledge representation should Commonwealth Office for making this research possible.
enable consistent approaches to be formally defined. In The authors would also like to thank Alfred Strohmeier and
identifying the features that should be expected of an the anonymous referees for their valuable comments on an
object-oriented analysis method, there are also issues that earlier version of the paper.
are more general and related to facilitating analysis in the
broadest sense (facilities and support provided to the References
potential analyst). The more difficult activities involved in
object-oriented analysis are not catered for by the proposed 1 Gause, D C and Weinberg, G M Exploring requirements -- quality
before design Dorset House Publishing (1989)
approach, which is little more than a notation for the 2 Davis, A M Software requirements -- analysis and specification
expression of an object model. A true prescriptive method Prentice-Hall (1990)
should comprise more than a notation. Procedural 3 DeMarco, T Structured analysis and system specification Prentice-
Hall (1979)
guidance, rules and related heuristics have only been 4 Yourdon, E Modern structured analysis Prentice-Hall (1989)
touched on in this article. 5 Ward, P and Mellor, S Structured development for real-time systems
Prentice-Hall (1985)
6 Klein, H K and Hirschheim, R A 'A comparative framework of data
A supporting tool modelling paradigms and approaches' The Computer Journal, Vol 30
No I (1987) Cambridge University Press, pp 8-15
A software tool which supports the proposed approach has 7 Chen, P 'The entity-relationship model: towards a unified view of
been developed22. The current version allows the user to data', ACM Transactions on Database Systems Vol 1 No 1 (1976)
navigate through applications (universes of discourse) for pp 9-37
8 Hull, R and King, R 'Semantic database modelling: survey,
defining, enhancing or modifying their object-oriented applications and research issues' ACM Comput. Surv. Vol 19 No 3
model. Each application comprises: (1987) pp 201-260
9 Peckham, J and Maryanski, F 'Semantic data models'. ACM Comput.
Surv. Vol 20 No 3 (1988) pp 153-189
• A type hierarchy defining all the relevant object types 10 King, R 'My cat is object-oriented' in Object-oriented concepts,
and their applicable operations. databases and applications Addison-Wesley (1989)
11 Goldberg, A and Robson, D Smalltalk-80 -- the language and its
• For each type in the type hierarchy, a collection- implementation Addison-Wesley (1983)
relationship structure diagram describing the internal 12 Wegner, P 'Dimensions of object-based language design' Proc. Conf.
structure of the corresponding object instances in terms on Object-Oriented Programming Systems, Languages and
Applications (OOPSLA 87) Orlando, Florida. Meyrowitz, N (ed).
of collections of object attributes and their possible Special issue of ACM SIGPLAN Notics Vol 22 (1987) pp 168-182
relationships. 13 Blair, S G 'What are object-oriented systems?' in Object-oriented
• For each defined operation of a type, a textual languages, systems and applications Blair, G, Gallagher, J,
Shepherd, D (eds). (Pitman 1991)
description of its semantics. 14 Cardelli, L and Wegner, P 'On understanding types, data abstraction,
and polymorphism' ACM Computing Surveys Vol 17 No 4 (1985) pp
471-522
The developed tool is intended to both facilitate the 15 Shlaer, S and Mellor, S J Object-oriented systems analysis --
proposed analysis approach and evaluate the method itself. Modelling the world in data Yourdon Press, Prentice-Hall (1988)
Operational experience should provide guidance about the 16 Shlaer, S and Mellor, S J Object lifecycles -- modelling the world in
states Yourdon Press, Prentice-Hall (1992)
suitability of the proposed modelling approach. Being itself 17 Cherry, G W 'System construction with object-oriented pictures' ACM
primarily a validation tool and as such a prototype, the SIGSOFT Software Engineering Notes Vol 16 No 4 (1991) pp 42-51
current version has been implemented and integrated in the 18 Rumbaugh, J, Blaha, M, Premerlani, W, Eddy, F and Lorenson, W
Object-oriented modelling and design Prentice-Hall (1991)
Smalltalk environment, exactly like other software 19 Martin, J and Odell, J J Object-oriented analysis and design Prentice-
development tools in the Smalltalk programmer's arsenal. Hall (1992)
It supports the modelling task but does not currently allow 20 Yeh, R and Zave, P 'Specifying software requirements' Proc. IEEE
Vol 68 No 9 (1980) pp 1077-1085
the creation and animation of an object population. It is 21 Tsichritzis, D C and Lochovsky, F H Data models, Prentice-Hall
planned to add this desirable prototyping facility. (1982)

84 Information and Software Technology 1994 Volume 36 Number 2

 Improving object-oriented analysis: G Eckert and P Golder

22 Eckert, G 'Object-oriented analysis for object prototyper' MSc Thesis, Meyrowitz, N (ed). Special Issue of ACM SIGPLAN Notices Vol 22
Department of Computer Science and Applied Mathematics, Aston (1987) pp 466-481
University, Birmingham (1992) 47 Bertino, E and Martino, L 'Object-oriented database management
23 Shumate, K 'Structured analysis and object-oriented design are systems: concepts and issues' IEEE Computer (April 1991) pp 33-47
compatible' ACM Ada Letters Vol 11 No 4 (1991) pp 78-90 48 Kim, W, Banerjee, J, Chou, H-T, Garza, J F and Woelk, D
24 Firesmith, D 'Structured analysis and object-oriented development 'Composite object support in an object-oriented database system'
are not compatible' ACM Ada Letters Vol 11 No 9 (1991) pp 56-66 Proc. of Conference on Object-Oriented Programming Systems,
25 Champeaux, D. de, Constantine, L, Jacobson, I, Mellor, S, Ward, P Languages and Applications (OOPSLA 87). Orlando, Florida.
and Yourdon, E 'Panel: Structured analysis and object-oriented analysis' Meyrowitz, N (ed). Special Issue of ACM SIGPLAN Notices Vol 22
Proc. of Conf. on object-oriented programming: systems languages and (1987) pp 118-125
applications. European Conf. on Object-Oriented Programming 49 Kim, W, Bertino, E and Garza, J F 'Composite objects revisited'
(ECOOP/OOOPSLA 90). Ottawa, Canada. Meyrowitz, N (ed). Special Proc. of 1989 ACM SIGMOD Int. Conf. Management of Data.
issue of ACM SIGPLAN Notices Vol 25 No 10 (1990) pp 135-139 Portland, Oregon. SIGMOD Record Vol 18 No 2 (198) pp 337
26 Archibald, J L and Yakemovic, K C B 'Panel: Structured analysis and 50 Booch, G Object-oriented design with applications Benjamin
object-oriented analysis' Addendum to the Proc. of Conf. on object- Cummings (1991)
oriented programming: systems, languages, and applications. 51 Atkinson, C Object-oriented reuse, concurrency and distribution --
European Conference on Object-Oriented Programming An Ada based approach Addison-Wesley (1991)
(ECOOP/OOPSLA 90) Ottawa, Canada. Special Issue of ACM 52 Snyder, A 'Encapsulation and inheritance' Proc. of Conf. on Obect-
SIGPLAN Notices (1990) pp 15-17 Oriented Programming Systems Portland, Oregon. Meyrowitz, N
27 Alabiso, B 'Transformation of data flow analysis models to object- (ed). Special Issue of ACM SIGPLAN Notices Vol 21 No 11 (1986)
oriented design' Proc. of Conf. on object-oriented programming pp 38-45
systems, languages and applications (OOPSLA 88) San Diego, 53 Wegner, P 'The object-oriented classification paradigm' in Shriver, B
California. Meyrowitz, N (ed). Special issue of ACM SIGPLAN and Wegner, P (eds) Research directions in object-oriented
Notices Vol 23 No 1 (1988) pp 335-353 programming MIT Press (1987)
28 Ward, P T 'How to integrate object orientation with structured 54 Blair, S G 'Types, abstract data types and polymorphism' in Object-
analysis and design' IEEE Software (March 1989) pp 74-82 oriented languages, systems and applications Blair, G, Gallagher, J,
29 Sully, P and Ince, D 'The synthesis of object-oriented designs from Hutchinson, D, Shepherd, D (eds). (Pitman 1991)
the products of structured analysis' Proc. of Soft. Eng. 90. Hall, 55 Danforth, S and Tomlinsen, C 'Type theories and object-oriented
P A V (ed) (1990) pp 404-432 programming' ACM Computing Surveys Vol 20 No 1 (1988)
30 Jackson, M A System development Prentice-Hall (1983) pp 29-73
31 Cameron, J R 'An overview of JSL' IEEE Trans. on Soft. Eng. Vol 56 Canning, P S, Cook, W R, Hill, W L, Olthoff, W G Proc. of Conf.
12 No 2 (1986) pp 222-240 on Object-Oriented Programming Systems, Languages, and Applications
32 Hull, M E C, Zarea-Aliabadi, A, Guthrie, D A 'Object-oriented (OOPSLA 89). New Orleans, Louisiana. Meyrowitz, N (ed). Special
design. Jackson system development (JSD) specifications and issue of ACM SIGPLAN Notices Vol 24 No 10 (1989) pp 457-467
concurrency' Soft. Eng. J. (March 1989) pp 79-83 57 Meyer, B Object-oriented software construction Prentice-Hall (1988)
33 Poo, C C D 'Adapting and using JSD modelling technique as front- 58 Cook, W 'A proposal for making Eiffel type-safe' Proc. of European
end to object-oriented systems development' Inf. and Soft. Technol. Conf. on Object-Oriented Programming ECOOP 89 (1989).
Vol 33 No 7 (1991) Cambridge University Press
34 Abbott, R 'Program design by informal English descriptions' 59 Ghelli, G 'A static type system for message passing' Proc. of Conf.
Commun. ofACM Vol 26 (1983) pp 882-894 on Object-Oriented Programming Systems, Languages and Applications
35 EVB Software Engineering Inc. An object-oriented design handbook (OOPSLA 91). Phoenix, Arizona, Paepcke, A (ed). Special Issue of
for Ada software (1985) ACM SIGPLAN Notices Vol 26 No 11 (1986) pp 129-145
36 Booch, G Software engineering with Ada -- Second Edition Benjamin 60 Leavens, G T and Weihl, W E 'Reasoning about object-oriented
Cummings (1987) programs that use subtypes' Proc. of the Conf. Object-Oriented
37 Cordes, D W and Carver, D L 'An object-based requirements Programming: Systems, Languages and Applications European
modelling method' J. American Society for Information Science Vol Conference on Object-Oriented Programming (ECOOP/OOPSLA
43 No 1 (1992) pp 62-71 90). Ottawaa, Canada, Meyrowitz, N (ed). Special Issue of ACM
38 Freitas, M M, Moreira, A and Guerreiro, P 'Object-oriented SIGPLAN Notices Vol 25 No 10 (1990) pp 212-223
requirements analysis in an Ada project' ACMAda Letters, Vol 10 No 61 Bloom, T and Zdonik, B 'Issues in the design of object-oriented
6 (1990) pp 97-109 database programming languages' Proc. of Conf. on object-oriented
39 Fichman, R and Kemerer, C F 'Object-oriented and conventional programming systems, languages and applications (OOPSLA 87).
analysis and design methodologies' IEEE Computer Vol 25 No 10 Orlando, Florida. Meyrowitz, N (ed). Special Issue of ACM
(1992) pp 22-39 S1GPLAN Notices Vol 22 (1987) pp 441-451
40 Champeaux, D and Faure, P 'A comparative study of object-oriented 62 O'Brien, P, Bullis, B, Schaffert, C 'Persistent and shared objects in
analysis methods' J. Object-Oriented Programming (March/April Trellis/Owl' Proc. Int. Workshop on Object-Oriented Database
1992) pp 21-33 Systems (1986) Dittrich, K, Dayal, U (eds) (September 1986) Pacific
41 Monarchi, D E and Puhr, G I 'A research typology for object-oriented Grove, CA
analysis and design' Comm. ofACM Vol 35 No 9 (1992) pp 35-47 63 Albano, A, Ghelli, G, Occhiuto, M E, Orsini, R 'A strongly typed,
42 Sutcliffe, A G 'Object-oriented system development: Survey of interactive object-oriented database programming language' Proc.
structured methods' Inf. and Soft. Technol. Vol 33 No 6 pp 433-442 Int. Workshop on Object-Oriented Database Systems 1986. Dittrich,
43 Graham, I Object-oriented methods Addison-Wesley (1991) K and Dayal, U (eds) (September 1986) Pacific Grove CA
44 Parent, C and Spaccapietra, S 'About entities, complex objects and 64 Goutas, S, Soupos, P and Christodoulakis, D 'Formalization of
object-oriented data models. Information system concepts -- an in- object-oriented database model with rules' Inf. and Soft. Technol.
depth analysis' Proc. of an IFIP WG 8.1 Working Conference Vol 33 No 10 (1991) pp 741-757
Falkenberg, E D (ed) Namur (October 1989) 65 Koshafian, S N and Copeland, G P 'Object identity' Proc. of Conf.
45 Wieringa, R 'Steps towards a method for the formal modelling of on Object-Oriented Programming Systems, Language and Applications
dynamic objects' Data & Knowledge Engineering Vol 6 (1991) (OOPSLA 86). Portland, Oregon, (ed) Meyrowitz, N. Special Issue
pp 509-540 of ACM SIGPLAN Notices Vol 21 No 11 (1986) pp 406-416
46 Rumbaugh, J 'Relations as semantic constructs in an object-oriented 66 Coad, P and Yourdon, E Object-oriented analysis - Second Edition,
language' Proc. of Conf. on Object-Oriented Programming Systems, Prentice-Hall (1991)
Languages and Applications (OOPSLA 87), Orlando, Florida. 67 Coad, P and Yourdon, E Object-oriented design Prentice-Hall (1991)

Information and Software Technology 1994 Volume 36 Number 2 85

Improving object-oriented analysis: Go Eckert and P. Golder

Appendix: Other analysis approaches

Bailin, S C 'An object-oriented requirements specification method'. Proc. of Conf on Object-Oriented Programming Systems, Languages and
Comm. ofACM Vol 32 No 5 (1989) pp 608-623 Applications (OOPSLA 91). Phoenix, Arizona, Paepcke, A (ed). Special
Barbier, F 'Object-oriented analysis of systems through their dynamical issue ofACSIGPLANNotices Vol 26 No 11 (1986)pp 171-183
aspects' J. of Object-Oriented Programming (May 1992) pp 45-51 Jacobson, I Object-oriented software engineering Addison-Wesley (1992)
Bear, S, Allen, P, Coleman, D and Hayes, F 'Graphical specification of Lee, S and Carver, D L 'Object-oriented analysis and specification: a
object-oriented systems' Proc. of Conf. on Object-Oriented Programming: knowledge base approach', J. of Object-Oriented Programming (January
Systems, Languages, and Applications European Conference on Object- 1991) pp 35-43
Oriented Programming (ECOOP/OOPSLA 90). Ottawa, Canada. Jacobson, I 'Object-oriented development in an industrial environment',
Meyrowitz, N (ed). Special issue of ACM SIGPLAN Notices Vol 25 Proc. of Conf. on Object-Oriented Programming Systems, Languages and
No 10 (1990) pp 28-37 Applications (OOPSLA 87). Orlando, Florida, Meyrowitz, N (ed). Special
Benci, G, Foucault, O and Rolland, C Information systems design -- The issue of ACM SIGPLAN Notices. Vol 22 (1987) pp 183-191
REMORA Method. Eyrolles Publishing (1988) 'Methode generale de conception par objets' Castellani Informatique,
Champeaux, D. de and Olthoff, W 'Towards an object-oriented analysis Evry (1991) (course notes)
method' 7th Annual Pacific Northwest Software Quality Conference. Page, T W, Berson, S E, Cheng, W C and Muntz, R R, 'An object-
Portland OR (1989) pp 323-338 oriented modelling environment'. Proc, of Conf. on Object-Oriented
Cherry, G W 'Software construction by object-oriented pictures: specifying Programming: Systems, Languages, and Applications (OOPSLA 89). New
reactive & interactive systems' Thought**ToolsInc. Canandaigua NY (1990) Orleans, Louisiana, Meyrowitz, N (ed). Special Issue of ACM SIGPLAN
Colbert, E 'The object-oriented software development method: a practical Notices Vol 24. No l0 (1989) pp 287-296
approach to object-oriented development' TRI-Ada 89 Proceedings (1989) Reenskaug, T, Andersen, E P, Berre, A J, Hurlen, A, Landmark, A, Lehne,
Edwards, J 'Basic Ptech skills'. Associative Design Technology, O A, Nordhagen, E, N~ss-Ulseth, E, Oftedal, G, Shkaar, A L and Stenslet,
Westborough MA (1989) (course notes) P 'OORASS: Seamless support for the creation and maintenance of object-
Embley, D W, Kurtz, B D and Woodfield, S N Object-oriented systems oriented systems' J. Object-Oriented Programming (October 1992)
analysis: a model driven approach Yourdon Press, Prentice-Hall (1992) Rubin, K S and Goldberg, A 'Object behavior analysis. Comm. ACM Vol
EVB Software Engineering Inc 'Object-oriented requirements analysis' 35 No 9 (1992) pp 48-62
EVB Software Engineering Inc. (1989) (course notes) Seidewitz, E and Stark, M 'General object-oriented software
Firesmith, D 'Object-oriented graphics for requirements analysis and development'. Report SEL-86-002 NASA Goddard Space Flight Center
logical design', ACMAda Letters Vol 11 No 9 (1991) pp 100-115 (1986)
Gibson, E 'Objects -- born and bred', Byte (October 1990) pp 245-254 Wirfs-Brock, R and Wilkerson, B 'Object-oriented design: a
Gorman, K and Choobineh, J 'Object-oriented entity-relationship model' responsibility-driven approach'. Proc. of Conf. on Object-Oriented
J. Manag. Inf. Syst. Vol 7 No 3 pp 41-65 Programming: Systems, Languages, and Applications (OOPSLA 89). New
Graham, I 'Migration using SOMA: A semantically rich method of object- Orleans, Louisiana. Meyrowitz, N (ed). Special issue of ACM SIGPLAN
oriented analysis'. J. of Object-Oriented Programming (February 1993) Notices Vol 24 No 10 (1989) pp 71-75
pp 31--42 Wirfs-Brock, R J, Wilkerson, B and Wiener, L Designing object-oriented
Hayes, F and Coleman, D 'Coherent models for object-oriented analysis' software Prentice-Hall (1990)

86 Information and Software Technology 1994 Volume 36 Number 2