Approaches to Modeling
Most methods
of architectural software design adopt a specific approach to modeling. The
following table shows the modeling techniques described in this book:
|
technique
name |
models |
|
functional
decomposition |
functions
that the software is required to provide |
|
data
structure design |
input
and output data structures |
|
data
flow design |
flow
of data within the system |
|
object-oriented
design |
the
system |
The $64,000
question is: which is best?
One way to answer
this question is to pose the following question: which aspect of a system is
most stable, least likely to change. Things always change during maintenance
because the users requirements will probably change.
But change also takes place during development - again the users
requirements will probably change. So which architecture will be most
resilient? Which software architecture will need the minimum of change?
Function-based
modeling is very appealing. If we look at any of the sample specifications given
in appendix A, we can see that features or functions
play a major role. Starting with functions seems very natural - after all the
purpose of a system is to perform a set of functions. But some people argue
that any structure based on function will be the most vulnerable. This is
because the first thing that is likely to change is what functions should be
provided for the user. This argument attempts to kill off functional
decomposition.
What about
data structure design? Are there any applications in which the structure of the
data dominates? Yes, certainly, in some specialized applications such as
compiler writing, analyzing HTML or XML.
Data flow
design started life as a means of modeling the flow of documents in an office -
the manual version of an information system. Thus there is an existing structure to model. But if data flow design is applied to
new software, how do we identify the flows and the transformations? How can we
be sure that the structure is robust?
The OO
advocates claim that they win the argument. They say that modeling a real-world
system is the most robust approach. They mean that they want to model, or
simulate, some existing real-world system such as an elevator, an ATM, an
airplane. Once the model has been constructed, it is connected to the user.
Probes and commands are added to display information and to control the model.
These are the functions of the software system.
There is,
of course, an implication here - that the model contains all the ingredients
that are needed to provide the desired functionality. Designing a model
establishes the set of concepts that form a basis for the functionality. For
example, in a library information system, if the model describes borrowers,
books, lending, and returning, the system will be capable of supporting
functions that use these concepts. But
if the model does not describe dates of publication, then it is impossible to
provide a function that uses dates of publication. Thus it is crazy to construct
a model of reality without some idea of the purpose for which it will be used.
So we might conclude that model and function have equal stability. The OO
people argue like this:
In
conclusion, OO advocates quote the slogan "model is more stable than
function".