Perspectives of modeling
Understanding a problem domain may be quite demanding.
Understanding is even more difficult when the
description of the domain is cast in some
representation pertaining to the solution domain.
An object-oriented approach is said to require less
translation from the problem domain to the (software)
solution domain, thus making understanding easier.
Many proponents of an object-oriented approach, however,
seem to be overly optimistic in their conception of
the modeling task.
From an epistemological point of view,
modeling may be regarded as being essentially colored
by the mechanisms that are available to express the model.
Hence, rather than opposing the functional and object-oriented
approach by claiming that an object-oriented
approach aims at modeling reality,
I would prefer to characterize the distinction in
terms of (modeling from) a different
vernacular, a different perspective due to
different modeling mechanisms.
In other words, a model is meant to capture
some salient aspects of a system or problem domain.
Dependent on what features are considered as most
important, different means will be chosen to construct
a model.
Even within the confines of an object-oriented approach, there appear to be
radically different perspectives of the modeling required
in the various phases of the software life-cycle.
Modeling reality -- vernacular
- requirements -- use cases
- analysis -- domain concepts
- design -- system architecture
- implementation -- language support
>
Design model {\em -- system oriented}
- provides a justification of the architecture
slide: Perspectives of modeling
An important contribution of [Jacobs92]
is the notion of use cases
that describe the situations in which a user actually
interacts with the system.
Such a (use case) model is an important constituent of
the requirements document, since it precisely
describes what the system is intended for.
For the purpose of analysis,
it may be helpful
to develop a more encompassing (conceptual) model
of the problem domain.
The advantage of such an approach is that the actual system
may later easily be extended due to the generality
of the underlying analysis model.
In contrast to the model used in analysis,
both the design model and the implementation model are more
solution oriented than domain oriented.
The implementation model is clearly dependent on the available
language support.
Within a traditional life-cycle, the design model may be seen as
a transition from analysis to implementation.
The notion of objects may act as a unifying factor,
relating the concepts described in the analysis document
to the components around which the design model is built.
However, as we have noted, object-oriented development
does not necessarily follow the course
of a traditional software life-cycle.
Alternatively, we may characterize the function of the
design document as a justification of the choices
made in deciding on the final architecture of the system.
This remark holds in so far as an object-oriented approach
is adopted for both design and implementation.
However, see [Hend90] for a variety of combinations of
structured, functional and object-oriented techniques.
Dimensions of modeling
When restricting ourselves to design models,
we may again distinguish between different modeling
perspectives or, which is perhaps more adequate
in this context, dimensions of modeling.
In [Rum91], it is proposed to use three complementary
models for describing the architecture and functionality
of a system.
See slide [3-dimensions].
Dimensions of modeling {\em -- OMT}
- object model -- decomposition into objects
- dynamic model -- intra-object state changes
- functional model -- object interaction (data-flow)
Model of control
- procedure-driven, event-driven, concurrent
slide: The OMT method
The OMT method distinguishes between
an object model, for describing the (static)
structure of object classes and their relations,
a dynamic model, that describes for each object
class the state changes resulting from performing operations,
and a functional model, that describes the interaction
between objects in terms of a data-flow graph.
An important contribution of [Rum91]
is that it identifies a number of commonly used
control models, including procedure-driven
control, event-driven control and concurrent
control.
The choice for a particular control model
may deeply affect the design of the system.
See section [duality] for a further discussion.
The OMT approach may be called a hybrid method
since it employs non object-oriented techniques
for describing intra-object dynamics, namely state-charts,
and a functional approach involving data-flow diagrams,
for describing inter-object communication.
Coherent models
The OMT object model, however,
only captures the static structure of the system.
To model the dynamic and functional aspects, the
object model is augmented with a
dynamic model, which is given by state diagrams,
and a functional model, which is handled
by data flow diagrams.
From a formal point of view this solution is rather
unsatisfactory since, as argued in [Hayes91],
it is hard to establish the consistency of the
combined model, consisting of an object,
dynamic and functional model.
Model criteria -- formal approach
- unambiguous -- single meaning
- abstract -- no unnecessary detail
- consistent -- absence of conflict
slide: Coherent models -- criteria
Consistency checking, or at least the possibility
to do so, is important to increase our belief
in the reliability (and reusability) of a model.
To be able to determine whether
a model is consistent, the model should be
phrased in an unambiguous way, that is, in a notation
with a clear and precise meaning.
See slide [3-coherent].
Also, to make the task of consistency checking manageable,
a model should be as abstract as possible, by leaving
out all irrelevant details.
To establish the consistency of the combined
model, covering structural, functional and dynamic aspects,
the interaction between the various models must be clearly
defined.
Currently, to my knowledge, there is no
completely developed method encompassing the
structural, functional and dynamic aspects
of a system in a manner that is amenable to
a rigorous formal approach.
However, there is an emerging understanding of how to
deal with these various aspects.
Moreover, there are attempts towards a standardization of the notions
employed in the various methods.
See sections [OMG] and [methods].