![](bg3.png)
changes throughout development and it therefore
requires an iterative and incremental method. The
iterative style prescribes the re-analysis/ re-design of
a portion of the system, recognizing the possibility
that completed parts might be flawed. Incremental
development implies a piecemeal development of
the whole application.
The structural paradigm requires the conclusion
of each step within each phase before moving to the
next step or phase. For example, the requirements-
gathering phase is seldom revisited because of the
basic assumption that the first attempt was correct
and complete. Accommodating late requirement
changes is complex due to the complexity of
accurately establishing the affected parts. Some
variations of the traditional SDLC such as the spiral
SD model attempted to address this matter, but these
approaches still require the completion of a phase
before the initiation of the subsequent phase.
2.2 Analysis
A fundamental paradigm shift required in the move
to OOSD expands conceptual modelling at the
beginning of the analysis process. The SSD
approach analyses the problem in terms of the
solution domain when it segregates the data and
processes/functions. A conceptual model in SSD is
therefore often includes entity models and
information flow diagrams. OOSD, in contrast,
analyses the problem in terms of the problem
domain when it first models problem domain objects
and their interactions before translating the analysed
information to the solution domain.
A second analysis area where a paradigm shift is
required is on the level of abstraction. Closely
related to conceptual modelling, the level of
abstraction refers to the tools that are used to
perform analysis. OOSD approaches use use-cases,
interaction diagrams, activity diagrams and the
resulting conceptual class diagrams to analyse and
fully understand the problem domain. Structural
approaches, on the other hand, use solution-based
diagrams from the commencement of the analysis.
Paradigm-contaminated analysts often start their
analysis with use cases and then follow this up by
using class models and entity models
interchangeably. In this way the analysis of the
problem domain is fused with an analysis of the
solution domain. Paradigm-contaminated developers
often do not realize that entity models are already at
the design level of system development, while use-
cases, activity and interaction diagrams are at the
analysis level, which makes the application of entity
models to OO analysis inappropriate in problem
domain-based analysis.
2.3 Modelling
We distinguish between two modelling issues,
namely the systems model and diagrammatic
representation. As mentioned above, the
interchangeable use of the entity models and
specifically ER-diagrams, and class diagrams points
to paradigm contamination. Although the different
diagrams have elements of commonality, their
semantics differ completely. Entity identification is
commonly considered as central to design
specification (Bulman 1998). But, as Sha et al.
(2001) put it: "OOSD does not simply imply the
definition of classes, objects and methods, in the
same way that structural programming does not
simply imply the removal of GOTO statements from
spaghetti programs”. Bulman (1998) correctly
summarizes the OO design phase as the
establishment of the system architecture (class
diagrams) as well as the definitions of their
interactions and interrelationships. However, this is
not what the ER-diagram represents.
Structurally contaminated developers are
frequently impatient to get to the solution domain.
Instead of focusing on objects, they concentrate on
data entities when analysing requirements. They
often incorrectly assume that objects are the same as
data entities – often because some OOSD
methodologies suggest noun identification as a first
level of object identification (Booch 1982, 1983a,
1983b).
The second modelling contamination aspect is
found in diagrammatic representation where it is
often accepted that similar diagrammatic
representations have identical semantics. For
example, both paradigms use rectangles, but in the
structured paradigm, a rectangle represents entities
(data without functionality) and in the OO paradigm,
classes (data and functionality). In order to model
the functionality of the system, an ER-diagram
needs an (additional) accompanying data-flow
diagram.
Another example of confusion in diagrammatic
representation is found in the link
3
between two
objects/entities as well as the multiplicity or
cardinality in such a link. In an ER-diagram, a link
represents a time-independent relationship between
entities, while it represents a time-dependent
association in a class diagram where a message is
typically passed from one object to another,
indicating behaviour or interaction. Cardinality
models a general truth between entities, while
3
adjoining lines between rectangles
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
44