IN THIS CHAPTER, YOU WILL LEARN:

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.

19.1 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.

Figure 19.1: The top-down development of the behavioral model

 

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:

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.

19.2 IDENTIFYING EVENT RESPONSES

The event partitioning approach involves the following four steps:

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.

Figure 19.2(a): A dataflow signaling the occurrence of an event

 

Figure 19.2(b): Additional inputs required to produce the response

 

Figure 19.3(a): An output sent from a process to a terminator

 

Figure 19.3(b): An output being sent from a process to a store

 

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.

Figure 19.4 : Multiple responses from the same event

 

Figure 19.5: Multiple events with the same response

 

19.3 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.

And since: