Modeling reality -- vernacular
- requirements -- use cases
- analysis -- domain concepts
- design -- system architecture
- implementation -- language support
Design model -- 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 insofar 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 -- 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.
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.