Object-Oriented Analysis
- analysis = extracting the needs
The problem domain -- complex reality
Communication -- with domain experts
Continual change -- user requirements
Reuse -- of analysis results
slide: Object-oriented analysis
Another claim made by proponents of OOP
is that an object-oriented approach enables
a more seamless transition between the respective phases
of the software life-cycle.
If this claim is really met, this would mean
that changing user requirements could be more easily
discussed in terms of the consequences of these changes
for the system,
and if accepted could in principle be more easily
propagated to the successive phases of development.
One of the basic ideas underlying object-oriented
analysis is that the abstractions arrived at
in developing a conceptual model of the problem domain
will remain stable over time.
Hence, rather than focusing on specific functional
requirements, attention should be given to
modeling the problem domain by means of high level abstractions.
Due to the stability of these abstractions, the results
of analysis are likely candidates for reuse.
The reality to be modeled in analysis is usually very complex.
[CY90] mention a number of
principles or mechanisms with which to manage complexity.
These show a great similarity to the abstraction
mechanisms mentioned earlier.
Personally, I do not feel entirely comfortable
with the characterization of the analysis phase
given by [CY90],
since to my mind
user needs and system requirements
are perhaps more conveniently phrased
in terms of functionality and constraints
than in terms of a model that may
simultaneously act as an architectural sketch of
the system that is to be developed.
However, I do agree with [CY90], and others,
that the products of analysis,
that is the documents describing user needs
and system requirements,
should as far as possible provide a conceptual model
of the domain to which these needs and
requirements are related.
Actually, I do consider the blurring of the distinction
between analysis and design,
and as we will see later, between design and implementation,
as one of the attractive features of an object-oriented
approach.
Analysis methods
The phases of analysis and design
differ primarily in orientation:
during analysis the focus is on aspects of the problem
domain and the goal is to arrive at a description
of that domain to which the user and system requirements
can be related.
On the other hand, the design phase must result
in an architectural model of the system,
for which we can demonstrate that it fulfills the user
needs and the additional requirements expressed
as the result of analysis.
Analysis methods
- Functional Decomposition = Functions + Interfaces
- Data Flow Approach = Data Flow + Bubbles
- Information Modeling = Entities + Attributes + Relationships
- Object-Oriented = Objects + Inheritance + Message passing
slide: Analysis methods
[CY90] discuss a number of methods
that are commonly used in analysis
(see slide [1-methods]).
The choice of a particular method will often depend
upon circumstances of a more sociological nature.
For instance, the experience of a team
with a particular method is often a crucial
factor for success.
For this reason, perhaps, an eclectic method
combining the various approaches may
be preferable
(see, for instance, Rumbaugh {\it et al.}, 1991).
However, it is doubtful whether such an approach
will have the same benefits as a purely
object-oriented approach.
See also section [methods].
I will briefly characterize the various methods
mentioned by [CY90]. For a more extensive
description and evaluation the reader is referred
to, for example, [Jones90].
The method of Functional Decomposition
aims at characterizing the steps that must be taken to
reach a particular goal.
These steps may be represented by functions
that may take arguments in order to deal
with data that is shared between the
successive steps of the computation.
In general, one can say that this method
is not very good for data hiding.
Another problem is that non-expert users
may not be familiar with viewing their problem
in terms of computation steps.
Also, the method does not result in descriptions
that are easily amenable to change.
The method indicated as the Data Flow Approach
aims at depicting the information flow
in a particular domain by means of arrows that
represent data and bubbles that represent
processes acting on these data.
Information Modeling
is a method that has become popular primarily
for developing information systems and applications
involving databases.
As a method, it aims at modeling the application domain
in terms of entities, that may have attributes,
and relations between entities.
An object-oriented approach to analysis
is very similar in nature to the information modeling
approach, at least with respect to its aim
of developing a conceptual model of the application domain.
However, in terms of their means, both methods differ
significantly.
The most important distinction between objects,
in the sense of OOP,
and entities, as used in information modeling,
to my mind lies in the capacity of objects
to embody actual behavior, whereas entities
are of a more passive nature.
Concluding this brief exploration of the analysis phase,
I think we may safely set as the goal
for every method of analysis
to aim at stable abstractions,
that is a conceptual model which is robust
with respect to evolving user requirements.
Also, we may state a preference for methods
which result in models that have a close
correspondence to the concepts and notions
used by the experts operating in the application
domain.
With respect to notation UML (the Unified Modeling Language,
see Appendix [UML]) is the obvious choice.
How to apply UML in the various phases of object-oriented software construction
is an altogether different matter.