Building a Preliminary Behavioral Model
“Things are always at their best in their beginning.” - Blaise Pascal, Lettres Provinciales, 1656-1657, no. 4
IN THIS CHAPTER, YOU WILL LEARN:
- Why a pure top-down approach to the behavior model is difficult
- How to develop a preliminary behavior model using event partitioning
- How to develop the initial ERD model.
In the previous chapter, we saw how to develop the environmental model for a system. If you were working on a real project at this point, you would have finished the context diagram, the event list, and a statement of purpose. In addition, you should have begun constructing the data dictionary, with at least a definition of the data elements that represent interfaces between the external terminators and the system.
Our task now is to begin building the behavioral model, that is, the model of what the internal behavior of the system must be in order to deal successfully with the environment. This will involve the development of a preliminary dataflow diagram and entity-relationship diagram, as well as an elaboration of the initial data dictionary entries.
Basically, this approach involves drawing a first-cut dataflow diagram, with one process (bubble) for the system response to each event that we have identified in our event list. We then draw stores on our first-cut DFD to model the data that must be remembered between asynchronous events. Finally, we connect appropriate input flows and output flows to the bubbles and check our set of DFDs against the context diagram for consistency.
Once having done this, we will go through a clean-up process, described in Chapter 20, to produce a well-organized process model and data model for presentation to the end user. This approach was given the name event partitioning in [McMenamin and Palmer, 1984].
We begin by comparing this approach to the classical top-down approach.
THE CLASSICAL APPROACH
The approach suggested in this chapter is substantially different from the top-down approach described in such classical textbooks as DeMarco [DeMarco, 1979], Gane [Gane and Sarson, 1979], and others. The classical approach assumes that you have already drawn your context diagram; but it assumes that you will proceed directly from the single bubble in the context diagram to a high-level DFD (known as Figure 0), in which each of the bubbles represents a major subsystem. Each bubble in Figure 0 is then partitioned into lower-level figures, and each bubble in the lower-level figures is partitioned further, and so on, until you have reached the level of an “atomic” bubble that requires no further decomposition. This is illustrated by Figure 19.1.
Though this top-down approach is different than the one presented in this book, I am not opposed to its approach ... if it works. However, you should be aware that many systems analysts encounter the following problems when attempting to follow a top-down approach:
- Analysis paralysis. In many large, complex systems, there simply isn’t a clue to guide the systems analyst in drawing an appropriate Figure 0 from the context diagram. So the analyst sits at her desk, staring at the context diagram, waiting for divine inspiration, or for someone to tell her that the project has run out of time for systems analysis and that it’s time to begin coding.
- The six-analyst phenomenon. On a large, complex system, there is often more than one systems analyst staring at the context diagram. In order to divide up the work equally and not get in each other’s way, they arbitrarily create a Figure 0 with one bubble for each systems analyst. Thus, if there are six systems analysts, Figure 0 will consist of six bubbles. Needless to say, this may not be the optimal partitioning of the system. What happens, for example, if the same system is specified by three systems analysts? Nine analysts? One analyst?
- An arbitrary physical partitioning. In many cases, a new system is based on an existing system, or it represents the computerization of an existing organization. The top-level partitioning of the current system (e.g., the current organizational units or the existing computer systems) is often used as the rationale for developing the partitioning of the new system. Thus, if the existing system is represented by a Purchasing Department and a Quality Assurance Department, the new system will often have a Purchasing Subsystem and a Quality Assurance Subsystem even though those might not be (and often are not) the best partitioning (from a functional point of view) of the system.
The approach described in this chapter is not a pure top-down approach; neither is it a pure bottom-up approach. It is, in a sense, a “middle-out” approach; after the initial DFD is developed, some upward leveling is required, and some further downward partitioning may be necessary.
IDENTIFYING EVENT RESPONSES
The event partitioning approach involves the following four steps:
- A bubble, or process, is drawn for each event in the event list.
- The bubble is named by describing the response that the system should make to the associated event.
- Appropriate inputs and outputs are drawn so that the bubble will be able to make its required response, and stores are drawn, as appropriate, for communication between bubbles.
- The resulting first-cut DFD is checked against the context diagram and event list for completeness and consistency.
The first step is straightforward, indeed almost mechanical in nature. If there are 25 events in the event list, you should draw 25 bubbles. For convenient reference, you should number the bubble to match the associated event. Thus, event 13 corresponds to bubble 13. (Later, as we will see in Chapter 20, we will renumber the bubbles appropriately.)
The second step is also straightforward and mechanical: each bubble is given an appropriate name based on its required response. This means that you should examine the event and ask yourself, “What response is the system supposed to make to this event?” Remember, though, that you should choose names that are as specific as possible. Thus, if an event is CUSTOMER MAKES PAYMENT, an appropriate bubble name might be UPDATE ACCOUNTS RECEIVABLE (if that is the only required response from the system), rather than PROCESS CUSTOMER PAYMENT (which tells us nothing about the nature of the response).
The third step is definitely not mechanical, but it is usually fairly straightforward. For each bubble that you have drawn, you must identify the inputs that the bubble requires to do its work; you must identify the outputs (if any) that the bubble produces; and you must identify the stores that the bubble must access. This is normally done by interviewing the appropriate user(s) and concentrating on each event and its associated bubble. “What does this bubble need to do its job?” you will ask the user, and “What outputs does it generate?”
In many cases, the event is flow-driven; this means that the system becomes aware of the occurrence of the event because of the arrival of some data from an external terminator. Obviously, this means that the appropriate dataflow must be attached to the process required to respond to that event. But, as shown in Figures 19.2(a) and (b), additional inputs (from other terminators and possibly from data stores) may be required in order for the process to be able to produce its required output.
Similarly, you must draw in the appropriate outputs produced by the process as part of the response. In many cases, this will involve outputs being sent back to the terminators outside the system; however, it may involve outputs that are sent to data stores, to be used as inputs by other processes. This is illustrated by Figures 19.3(a) and (b).
Finally, the fourth step is a consistency-checking activity similar to the balancing steps described in Chapter 14. You must verify that every input shown on the context diagram is associated with an input on one of the processes in the preliminary DFD; and you must verify that every output produced by a process in the preliminary DFD is either sent to a store or is an external output shown on the context diagram.
There are two special cases: (1) single events that cause multiple responses and (2) multiple events that cause the same response. In the first case, a single event may cause multiple responses, each of which is modeled with its own bubble in the preliminary DFD. This is illustrated in Figure 19.4. This is appropriate only if all the responses use the same incoming dataflow, and only if all the responses are independent of one another. No output from one part of the overall response should be needed as input by another part of the overall response.
Conversely, there will be occasional situations where one process is associated with more than one event; this is illustrated by Figure 19.5. This is valid and appropriate only if the response made by the bubble is identical for the various events, and only if the input data and output data are identical for the various event responses.
CONNECTING EVENT RESPONSES
Note that in the previous examples, none of the processes in the preliminary dataflow diagram are connected to each other: bubbles do not talk directly to other bubbles. Instead bubbles communicate with each other through data stores.
Why is this? Simply because the bubbles in the preliminary DFD represent responses to an event, and events that occur in the external environment are, in the general case, asynchronous. That is, we have no way of guaranteeing that two events will occur at the same instant, or within two seconds of one another, or within any other specified period of time. Events happen in the external environment whenever the environment feels like making them happen.
- the response to one event may require data produced by some other event, and
- we have no way of knowing when the events will occur in time, and
- we have to assume, in an essential model, that each process will perform its work infinitely quickly, and
- each dataflow acts as a pipeline that can transmit data elements at infinite speed
it follows that the only way we can synchronize multiple interdependent events is through a store. Note that this is an essential store: a store required, not because of time delays associated with imperfect technology, but because of timing considerations in the environment.
Thus, you should not see a preliminary dataflow diagram like the one shown in Figure 19.6(a); since the associated events are asynchronous, Figure 19.6(a) could only work if a time-delayed storage of data was hidden within one of the processes or the dataflow itself. Thus, Figure 19.6(b) is the proper way of showing the communication between processes.
DEVELOPING THE INITIAL DATA MODEL
As we have seen, the procedure of sketching the initial DFD involves drawing data stores between asynchronous processes. In most cases, the nature of these stores will be obvious, and the names can be chosen from your understanding of the subject matter of the project.
Meanwhile, however, you or one of your colleagues should have begun working on the initial version of the entity-relationship diagram as an independent activity, in parallel with the development of the initial DFD. This should be done using the techniques described in Chapter 12.
As the ERD and DFD are being developed in parallel, they can be used to cross-check each other. Thus, stores that have been tentatively defined in the preliminary DFD can be used to suggest objects in the preliminary ERD; and objects that have been tentatively identified in the preliminary ERD can be used to help choose appropriate stores in the preliminary DFD. Neither model should be considered the dominant model that controls the other; each is on an equal footing and can provide invaluable assistance to the other.
You may also find that the event list is as useful for creating the initial ERD as it is for creating the initial DFD. Nouns in the event list will often turn out to be objects in the ERD; for example, if an event is “Customer places order,” we would immediately identify customer and order as tentative objects. Similarly, we can use the event list as a means of cross-checking the initial ERD: all the object types in the ERD should correspond to nouns in the event list.
The most important thing to realize from this chapter is that you will not produce a behavioral model that is ready to be shown to the user. It is not finished; it is not pretty; it is not simple enough or well-organized enough to be understood in its entirety. You can see an example of this by looking at the case study in Appendix F.
So what is it? What is the point of carrying out the steps described in Section 19.3? Very simply, it is a beginning, a framework upon which you can base the development of the finished, final version of the essential model.
You should not be concerned at this point about the organization of the behavioral model, or its complexity, or its understandability. You should resolutely resist the temptation to reorganize, package, decompose, or “recompose” any of the bubbles in the preliminary DFD. All you should care about at this point is the underlying correctness of the model: Does it have a process for each event? Does it show the necessary inputs and outputs for each event? And does it show the necessary connections between events?
Once you have established this, then you can begin working on a reorganization of the model. This is discussed in more detail in Chapter 20.
- Tom DeMarco, Structured Analysis and Systems Specification. Englewood Cliffs, N.J.: Prentice-Hall, 1979.
- Chris Gane and Trish Sarson, Structured Systems Analysis: Tools and Techniques. Englewood Cliffs, N.J.: Prentice-Hall, 1979.
- Steve McMenamin and John Palmer, Essential Systems Analysis. New York: Yourdon Press, 1984.
QUESTIONS AND EXERCISES
- What is a behavioral model of a system? What is its purpose?
- What are the three major components of the preliminary behavioral model?
- What is the classical approach to building a behavioral model? Why is it characterized as a top-down approach?
- What are the three major problems typically faced by systems analysts when trying to follow the classical top-down approach to building a behavioral model of an information system?
- Why do you think that some systems analysts suffer paralysis, or “writer’s block,” when trying to develop a Figure 0 DFD from the context diagram?
- Why does the behavioral model in some projects exhibit an arbitrary physical partitioning?
- What does the term event partitioning mean?
- What are the four steps in event partitioning?
- If the systems analyst has discovered 13 events in the environmental model, how many processes (bubbles) should be in the first-cut behavioral model?
- What kind of numbering scheme is used to number the bubbles in the first-cut DFD of the behavioral model?
- What rationale is used to give a name to each bubble in the first-cut DFD of the behavioral model?
- How should the systems analyst determine the inputs, outputs, and stores required by each bubble in the first-cut DFD?
- If an event is flow-driven, how many input dataflows must the bubble processing that event receive?
- What are the consistency-checking guidelines that the systems analyst must go through when drawing the first-cut DFD of the behavioral model?
- How should the first-cut DFD be drawn for the case of an event that produces multiple responses?
- Under what conditions could a single bubble in the first-cut DFD be associated with more than one event?
- In the first-cut DFD, how do bubbles communicate with one another? That is, how does an output produced by one bubble become input to another bubble?
- How does the first-cut DFD show the synchronization of multiple, asynchronous, interdependent events?
- Which should be developed first: the first-cut DFD or a first-cut data model (ERD)? Why?
- What should the systems analyst do with the first-cut DFD and first-cut ERD after he or she has finished them?
- When the first-cut DFD has been finished, should it be reviewed with the user? Why or why not?
- What is wrong with the following first-cut DFD?
- What’s wrong with the following first-cut DFD?