But there are many
different kinds of models that we could build
for the user:
narrative models, prototype models,
various graphical
models, and so on.
Indeed, the final system
that we
build for
the user may turn out to be a model — in
the sense that it may represent,
for the first time, a way for the
user
to visualize what
it is that he
or she wants.
In this book, we
concentrate on paper models (or paper models
produced
by automated CASE systems). But here again,
there
is an enormous amount
of variety:
as we will see in more
detail in the
next several chapters, there are
flowcharts, HIPO diagrams, decision tables, dataflow
diagrams, systems flowcharts,
state-transition diagrams,
decision
trees, entity-relationship diagrams,
Ferstl diagrams, Hamilton-Zeldin
diagrams,
PAD
diagrams, and an endless
array of charts,
tables, and graphs that we
can present to the user. Which
should we use?
The basic premise
of this book is that you should use any model
that works for you and for the
situation
you’re in.
Different users may
require
different modeling tools either
because of past
experience or because they find
certain kinds of diagrams confusing
and intimidating. [1] Different
projects may require different
modeling tools in order to comply
with documentation
standards imposed by external
organizations. And different
kinds of systems
may require different models
in order
to properly highlight
important characteristics.
To
carry this last point further,
most systems require multiple models:
each model focuses on a limited
number of aspects
of the system,
while downplaying
(or ignoring altogether)
other
aspects of the system. This
is especially true of many
of the
systems being built
today, for they have
complex functional characteristics,
complex data structures,
and complex timing
considerations.
Any tool
you use should have the following
characteristics:
We will
elaborate on each of these points next.
8.1 GRAPHICAL
MODELS
Most of the popular
system models, and all of the ones used in this
book, rely heavily on graphics. It
is by no means required to use graphics in a system model,
but the old adage that “a picture is worth a thousand words” is
a good explanation for our preference for graphics over narrative
text. A well-chosen picture can convey an
enormous amount of information concisely and compactly.
This does
not mean that a picture can necessarily describe everything about
a system; to do so would usually mean a terribly cluttered
mess that nobody would
be willing to
look at. In
general, we use graphics to identify the components of
a system and the interfaces between the components;
all the other details (i.e., the answers to such questions
as “How
many?” and “In what
sequence?”, and so on) are presented in supporting textual
documents. The
supporting textual documents described in this book are the process
specification and the data dictionary.
This does
not mean that all systems analysts must use the particular
set of graphic and text-oriented
modeling tools presented in this book; the Great Systems
Analyst in the sky will
not strike you
down with lightning bolts for failure to use dataflow diagrams.
However, you probably should be struck down by lightning
bolts if you choose either
the
extreme of all graphics (with no supporting text)
or all text
(with no graphics). And you should be zapped with at least
a small lightning bolt if you make text the dominant part
of the model, with graphics playing
a minor, subordinate role. One or more graphics should be
the primary document
that the user turns to in order to understand the system;
the textual documents should serve as reference material
to be
consulted when necessary.
8.2 TOP-DOWN PARTITIONABLE
MODELS
A second important aspect of a good
modeling tool is its ability to portray a system in a top-down
partitioned fashion. This is not important for tiny systems,
for we can say everything
that needs to be said in one or two pages, and anyone who
needs to know about any
aspect of the system can learn about all of the
system.
However, real projects
in the real world are generally not
tiny. [2] Indeed,
most of the projects you are likely to become involved
with will range from medium-sized to enormous. Consequently,
it
will be
impossible
for anyone,
whether they are users, systems analysts or programmers,
to focus on the entire system at once. Nor will it be
possible to present
a graphical
model
of a
large, complex system on a single sheet of paper — unless
one wants to consider the ludicrous extreme of an 8-foot
by 10-foot sheet of
microfiche!
So our modeling tools must allow us to portray individual
parts of the system in a
stand-alone fashion, together with a straightforward
way of getting from one part of the system model to another.
However, we need
even more than this: it would not be appropriate,
for example, to create an enormous
100 foot by 100 foot graphical model and then cut it
into 10,000 separate one
foot by
one foot
pieces, with thousands of “off-page” connectors.
That would be roughly equivalent to drawing a street
map of the entire United
States
on a
single (albeit large) sheet of paper and then cutting
it into thousands of page-sized pieces.
Indeed, our
experience with maps and atlases illustrates how
we need to organize a model
of a complex system. An atlas of the United States,
for
example, typically
starts with a single
one-page
diagram of the entire country, as shown in Figure
8.1. That
page shows the individual states, and may also show
major interfaces between the
states
(rivers, interstate highways, train lines, airline
routes, etc.). Subsequent pages are typically devoted
to each
individual state, with each page
showing the individual towns and counties within
a state, as well as the local state
highways that would not have been shown on the country-level
map. One could imagine lower-level maps that would
provide details about each
county, each city
within a county, and each neighborhood within a city.
Figure 8.1:
A map of the United States
A good model
of a complex information system should proceed
in the same top-down fashion.
A high-level overview portion of the model should
give the
reader a good
idea of the major
high-level components and interfaces of the system.
Subsequent
portions of the model
should provide information about low-level detail
components of the system. And just as an atlas
provides a convenient
mechanism for traversing the
entire set
of individual maps (i.e., getting from the country-level
map down to the appropriate county-level map
without a lot of confusion),
so a good
model of an
information system provides a convenient mechanism
for traversing smoothly from high level to low
level.
8.3 MINIMALLY
REDUNDANT MODELS
Models are a representation
of some real-world system, and the system itself
may be static (nonchanging) or dynamic. A map
of the United
States,
for example, is a
graphical representation of the
country we live in. And while many aspects
of our country are obviously very dynamic, one
could
argue
that the
aspects modeled by a map are relatively
static: individual states don’t appear
or disappear very often, and the boundaries between
states have
been relatively
constant
for quite a long
time.
(By contrast, we wouldn’t be able to
say this about a map of the entire world!)
Why does
this matter to the person
building a model? Simply because it
is desirable to maintain the model in an accurate
and up-to-date
form.
If the system
changes, then the model
must be
changed if we are to keep it up to
date. Obviously, if only one local aspect of
the system changes,
we would prefer
to
change only one corresponding
local
aspect of the model; without being
forced to change any other aspect. Indeed, if
multiple changes are
required, there is
a good chance that
they won’t be
made, or that they will be made haphazardly.
And this means that the model will
gradually become
less and
less
accurate.
To illustrate this,
consider our example of the atlas of the United
States once
again. We could imagine, in the simplest
case, one page
showing
the
entire country,
and 50 subsequent
pages showing the
details of each state. Now imagine
what would happen if the state of
New Jersey
were to disappear[3]:
the country-level map would have
to be redrawn to show the new 49-state
country,
and the former
state-level
map of New
Jersey would be
discarded.
But it would be a
little more difficult with real atlases
because, as is
typical with many system models,
there is some
built-in redundancy. Each state-level
map shows
not only the
state being
described, but portions of the
bordering states — information
that is adequately provided in
the country-level map, but that is convenient
to have
at the state level, too. So this
means
that if New Jersey were to disappear,
we
would probably have to redraw the
maps of New York and Pennsylvania,
and perhaps
even
Maryland
and Delaware. What a nuisance!
Professional
cartographers might object to this and argue
that a
certain amount
of redundancy is necessary in
order to make the atlas easy to
read. But
it should be evident
that the
more redundancy
the model contains, the more
difficult it is to maintain. Imagine, for
example, that our mythical
atlas shows
the interstate highways on the
country-level map
and all the state-level maps.
Imagine also that some enterprising map
maker has decided
to show
the overall
length of each
interstate
highway on each state
map through which the highway travels.
Thus, Interstate 95, which runs
from Maine to Florida,
would appear
on roughly a dozen state maps,
each of which
would be inscribed with the (redundant)
fact that the entire highway
is approximately 1700 miles
long. Now
what happens
if we discover that
this figure
was wrong or that part of the
highway was extended or rerouted?
Obviously,
a dozen
different state-level
maps
will have
to be changed.
8.4 TRANSPARENT
MODELS
Finally, a good model
should be so easy to read that the reader doesn’t
even stop to think that she or he is looking
at a representation of
a system,
rather than the
system itself.
This is
not always
easy to accomplish, and it
often does take
some education and practice on
the part
of the reader.
Think about
a map, for
example: how often
do you
think
to yourself that you are
looking
at an abstract representation of the state
of New Jersey rather than the real thing?
On the other
hand, observe a small child
looking at a map as his parents
or his teacher
try to explain
that New Jersey
borders New York and that
Newark is
ten miles away from New
York City. “No, it’s
not,” the child will
say, “Newark
is only half an
inch away from New York City.”
As
we grow older, though,
we become more and more familiar
with the
concept of
abstract representations
as
long as they fit comfortably
into our heads. Scientists
have studied the
behavior and
organization of the human
brain and have found that
the left
side of
the brain deals with sequential,
one-thing-at-a-time
processing; it is also
the left
side of the brain that
deals with text, for example, the
words that
you are
reading,
one at a time, on this
page of paper. The right side
of the
brain deals
with pictures
and with
asynchronous, “lots
of things going on at the
same time” processing.
This tells us that if we
are trying
to model something
that
is intrinsically
linear and sequential,
such as the
flow of control
in a computer program, we
should use a textual modeling
tool that fits comfortably
into
the left side of the brain
that will
be best at dealing
with it. And
if
we are trying to model something
that is intrinsically multidimensional,
with
lots
of activities going on at
the same time, we
should use a graphical modeling
tool.
8.5 SUMMARY
No
doubt you will be so busy learning the modeling tools
presented in this book that you won’t think
about the possibility of other modeling tools. However,
they do exist, and we will briefly examine a variety
of alternative tools in Chapter
15.
More
importantly, you will be exposed to
a variety
of modeling
tools
in real-world projects.
While the details
(and shapes
and forms) of these
modeling tools
may vary widely,
you should check
carefully to see
that they follow the basic
principles and guidelines
presented in this
chapter.
