Chapter 8

Characteristics of Modeling Tools

“Anything is easy, if you can assimilate it to your collection of models.”

-- Seymour Papert
Mindstorms

---

IN THIS CHAPTER, YOU WILL LEARN:

1. Why system modeling tools are usually graphical;
   
2. Why systems modeling tools are top-down partitionable;
   
3. Why system modeling tools have minimal redundancy; and
   
4. Why system modeling tools help model system behavior.

The next several chapters of this book describe the various modeling tools you will use as a systems analyst. Before we plunge into the details of dataflow diagrams, entity-relationship diagrams, and so on, there are some introductory points that we need to review.

You will recall from Chapter 4 that a model is an inexpensive facsimile of a complex system that we want to study. We build models of systems for three reasons:

1. To focus on important system features while downplaying less important features.
2. To discuss changes and corrections to the user’s requirements at a low cost and with minimal risk.
3. To verify that we understand the user’s environment and have documented it in such a way that systems designers and programmers can build the system.

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.<ref>A corollary to this is that good modeling tools will usually involve very simple notation, with very few rules, symbols, and new words for the user to have to learn. A purist might even argue that a good modeling tool requires no explanation or training; in any case, it should not be necessary to read through a 700-page book like this one in order to learn how to read and understand a model developed by the systems analyst.</ref> 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:

• It should be graphical, with appropriate supporting textual detail.
• It should allow the system to be viewed in a top-down, partitioned fashion.
• It should have minimal redundancy.
• It should help the reader predict the system’s behavior.
• It should be transparent to the reader.

We will elaborate on each of these points next.

---

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.

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.<ref>Or to put this another way, more and more of the “tiny” projects are being developed by the users without any assistance from systems analysts or programmers. With the widespread availability of personal computers, spreadsheet packages, and “visual” programming languages and development tools, many of the jobs that would have required a few days (or even weeks) of work by a professional computer person can now be done in a matter of minutes or hours by the user. However, there continue to be many information systems developed today that require more than 10 million program statements to carry out their required purpose.</ref> 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.

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<ref>If you happen to live in New Jersey or have some other pathological connection to the state, feel free to use another state for this example. Apologies to Bruce Springsteen.</ref>: 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.

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.

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.

QUESTIONS AND EXERCISES

1. What are the three major reasons for building system models?
2. Describe three different types of system models?
3. What are the major characteristics that a system modeling tool should have?
4. Why are graphical modeling tools generally preferred over textual modeling tools?
5. Is it necessary to use graphical modeling tools to develop an information system? Can you think of any situations where you would not want to use such tools?
6. What things do graphical models typically not show about a system?
7. Why is it important for a modeling tool to portray a system in a top-down fashion? Are there any situations where it doesn’t matter?
8. Does a top-down description of a system require that the system be designed in a top-down fashion?
9. Describe a situation where it would be acceptable to include redundancy in a system model.

ENDNOTES

<references/>