Finishing the Behavioral Model
“Give us the tools, and we will finish the job.” — Winston Churchill Radio broadcast, 1941
IN THIS CHAPTER, YOU WILL LEARN:
- How to level an initial DFD upward
- How to hide local data stores
- When and how to partition initial DFD bubbles downward
- How to complete the initial data dictionary
- How to complete the process specifications
- How to complete the data model
- How to complete the state-transition diagram
In the previous chapter, I presented a strategy for developing an initial version of the behavioral model. However, it should be evident that this model cannot be presented to the user for verification. Why not? Primarily because it is too complicated. As we saw in Chapter 19, the preliminary DFD will have one process for each event that we identified in the environmental model; hence, it may have as many as 40 or 50 bubbles, or possibly more. Similarly, the initial version of the ERD is probably too rough to review with the users; as we discussed in Chapter 12, refinement is necessary to eliminate unnecessary objects and/or to add new objects.
There is a second problem with the model: it consists largely of graphics, with little or no textual support. While the dataflow diagram and entity-relationship diagram are excellent vehicles for presenting an overview of the system to the user, they need the support of a full data dictionary and complete set of process specifications.
Finishing the process model
Leveling The DFD
The first order of business is to reorganize the DFD that we developed in Chapter 19. As we have seen, it consists of a single level, with far too many bubbles on it. Hence, we need upward leveling of the preliminary DFD. This means that we want to group related processes together into meaningful aggregates, each of which will represent a bubble in a higher-level diagram. This is illustrated in Figure 20.1.
There are three guidelines that you should keep in mind as you do this:
- Each grouping of processes should involve closely related responses (remember that each bubble in the preliminary DFD is named for the response to an event in the event list). This usually means that the processes are dealing with closely related data.
- Look for opportunities to hide, or “bury,” stored data that appear at the lower level. Thus, if you see a group of processes in the preliminary DFD that refer to a common store, and no other processes in the preliminary DFD refer to that store, then you can create a higher level bubble that hides the store. This is illustrated in Figure 20.2.
- Keep in mind that the person who looks at your dataflow diagrams, whether it is a user or another systems analyst, will not want to look at too much at one time. Thus, you should create aggregates or groups from the preliminary DFD consisting of roughly 7 plus or minus 2 chunks of information, where a process (and its related flows) or a store could be considered a chunk.<ref name=processchunk>This seemingly arbitrary number (seven plus or minus two) is a guideline for controlling complexity in a variety of problem-solving situations. It is based on the work of George Miller, who first observed peoples’ difficulty dealing with multiple chunks of information in a classic paper entitled “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information,” published in Psychological Review, Volume 63 (1956), pp.81-97</ref>
Of course, this means we may need several upward leveling efforts. For example, if we began with a preliminary DFD that had (for the sake of argument) 98 processes in it, and if we organized the diagram into groups of 7 bubbles (ignoring, for the sake of simplicity, all the stores), then we would create a higher-level diagram with 14 bubbles, each of which represents an “abstraction” of seven of the lower-level bubbles. But 14 bubbles is too much to deal with and too much to show the user at one time; so we would probably be inclined, as illustrated in Figure 20.3, to create an even higher-level diagram with only two bubbles on it.
Note that this example involves entirely artificial numbers. You should not conduct your leveling activity in order to ensure that each diagram has exactly seven bubbles! Indeed, the first two guidelines mentioned above, grouping bubbles around common data and looking for opportunities to conceal local stores, should be your primary rationale for upward leveling, not some arithmetic rule.
Note also that you may also need some downward leveling. That is, the processes identified in the preliminary DFD may not turn out to be primitive processes and may require downward partitioning into lower-level DFDs. This means only that the initial processes, each of which is responsible for producing the response to an event, may turn out to be too complex to describe accurately in a one-page process specification. Often, this will become evident as soon as you look closely at the process, or when you ask the user for an explanation of what the bubble must do. If the user thinks for a moment, takes a deep breath, and says, “Well, it’s a long story, but it goes something like this ... ” you have a strong clue that your preliminary bubble probably needs to be partitioned!
In other cases, it may not become evident that downward leveling is required until you actually try to write the process specification; if you find that you’ve written three pages of material about a preliminary bubble and there is much, much more to say, once again you have a strong clue that downward partitioning is necessary.
Here are some guidelines for carrying out downward leveling:
- In some cases, a pure functional decomposition approach is appropriate. That is, if you find a process bubble that is carrying out a complex function, try to identify subfunctions, each of which could be carried out by a lower-level bubble. For example, suppose that we had a process called “Adjust missile trajectory”; this might be the bubble that is responsible for handling a temporal event in a real-time missile guidance system. The overall function of adjusting the missile trajectory might be decomposed into several subfunctions:
- Calculate x-coordinate variance
- Calculate y-coordinate variance
- Calculate z-coordinate variance
- Calculate new atmospheric “drag” factor
- Calculate new wind velocity
- Compute x-coordinate thrust impulse
- Compute y-coordinate thrust impulse
- In other cases, the bubble’s incoming dataflows and outgoing dataflows will provide the best guidance for downward leveling. For example, supposed we had a bubble like the one shown in Figure 20.4. It is likely that a lower-level DFD could be created with the general form shown in Figure 20.5. Obviously, more than one bubble might be needed for combining or aggregating individual data elements, but the idea is the same: let the data be the guide.
Keep in mind as you go through this activity of upward and downward leveling that balancing is important. That is (as we discussed in Chapter 14), you must ensure that the net inputs and outputs shown for a high-level bubble correspond to the net inputs and outputs shown for the lower-level diagram. To see an example of the upward leveling activity, look at the YOURDON Press Information System case study in Appendix F. In this case, we began with a preliminary DFD containing 40 bubbles; one level of upward leveling was required, leading to a Figure 0 DFD diagram with nine bubbles on it.
Completing the Data Dictionary
As you began developing the preliminary DFD in Chapter 19, you should have begun developing the data dictionary; indeed, it is quite common to begin the data dictionary when the context diagram is being developed. However, it is by no means complete at this point. Typically, it will be necessary to fill in the description of the meaning of each data item; it may also be appropriate to break complex data items into subitems for clarity.
As the data dictionary becomes more complete, you should also begin checking it for consistency and completeness. Check to make sure that the dictionary is internally consistent (e.g., that one part of the dictionary doesn't contradict another part). Also, check to ensure that the dictionary is balanced against the leveled dataflow diagram and the entity-relationship diagram and the process specifications.
Completing the Process Specifications
When you develop the preliminary dataflow diagram, using the event-partitioning approach shown in Chapter 19, chances are that you will not have written any process specifications. There may be a few cases where an individual process specification will be sketched out because of particular interest on your part or the user’s part, but your primary concern will simply be to organize the DFD itself.
Indeed, it is often a bad idea to devote any time to the writing of process specifications until the preliminary DFD has been finished, because the initial development of the DFD is subject to many changes, corrections, and revisions. Bubbles may appear, disappear, and be moved around and renamed. When the preliminary DFD begins to settle down, and when it has stood the test of upward leveling (i.e., if that activity does not uncover any major flaws in the model), then you can begin writing the process specifications.
This will often be a lengthy, time-consuming effort, because each of the bottom-level bubbles in the DFD set requires a process specification. Thus, it may be possible for a group of two or three systems analysts to draw a few dozen DFDs; but it may take a larger group of analysts to complete all the process specifications in a timely fashion.
As the process specifications are completed, they should be balanced and cross-checked against the data dictionary and ERD, using the guidelines presented in Chapter 14.
Finishing the data model
As we pointed out in Chapter 12, the ERD is developed in a fashion somewhat similar to what we have described for the DFD: a rough ERD is developed, and then it is refined and improved. Much of this improvement can take place simply by assigning or attributing data elements to the appropriate object types; this will usually help us identify new object types or unnecessary object types.
However, keep in mind that the ERD is often being developed at roughly the same time as the DFD. It is very common to find one person (or a small group) within the project team working on the ERD, while another person (or a small group) works on the DFD. Or the DFD might be developed by the project team, while the ERD is developed by a centralized data administration group within the EDP organization. In any case, if the ERD and DFD are being developed at approximately the same time, then the knowledge gained from the DFD (e.g., the existence of stores, dataflows, etc.) can often be used to refine and cross-check the ERD. <ref name=dfderd>Ideally, the DFD and ERD models should be developed by the same group, working together. This prevents communication problems, and it also tends to ensure that equal emphasis will be given to both models. Unfortunately, it rarely happens in the real world.</ref>
Finishing the State-Transition Diagram
If your system has real-time characteristics, you will be developing a state-transition diagram in addition to the DFD and entity-relationship diagram. Detailed knowledge of the behavior of the system should help you refine this model. As we pointed out in Chapter 13, you should examine the initial state-transition diagram to look for the following common types of errors:
- Have all the states been defined?
- Can you reach all the states?
- Can you exit from all the states?
- In each state, does the system respond properly to all possible conditions?
Having gotten this far, we have reached the end of the essential model. If you have followed all the steps in Chapters 18, 19, and this chapter, you should have a complete, detailed, formal, rigorous model of everything that the system must do to meet the user’s requirements. It will contain all of the following items:
- Context diagram
- Event list
- Statement of purpose
- Complete set of leveled dataflow diagrams
- Complete, finished entity-relationship diagram
- Complete set of state-transition diagrams
- Complete data dictionary (for the analysis phase of the project)
- Complete set of process specifications, with one such specification for each bottom-level process
Assuming that you have reviewed the components of the specification to ensure that they are complete and consistent, and assuming the user has reviewed and approved the document, you should be through. You should be able to wrap a nice red ribbon around the entire package and deliver it to the design/programming team whose job will be to build the system. Then you can retire to the cozy comfort of your office until the next project comes along.
But wait! There is one last step. Everything that we have developed in this, the essential model, has assumed the existence of perfect technology, but has also assumed that the user would have no implementation constraints to impose on the system. Perfect technology is a figment of our imagination, but we can leave it to the implementation team to decide how best to strike a reasonable compromise with existing technology.
Assuming that the user will ignore all implementation constraints is also a figment of our imagination and one that we must deal with before we turn over the final version of the specification to the implementation team. This final activity, which must be done with the collaboration of users, systems analysts, and some members of the implementation team, is the development of the user implementation model. This is discussed in the next chapter.
QUESTIONS AND EXERCISES
- Why can’t the initial, first-cut behavioral model be presented to the user?
- Is the first-cut behavioral model complete? If not, what elements are missing?
- What does upward leveling mean in the context of this chapter?
- What rationale should the systems analyst use for grouping bubbles together in a DFD?
- What are the three guidelines that the systems analyst should keep in mind as she or he carries out upward leveling?
- What does the concept of hiding stored data mean in the context of this chapter?
- How many levels of higher-level DFDs should be created from a single first-cut DFD? Is there a mathematical formula that can be used to give an approximation of the number of levels required?
- Under what conditions will downward leveling of a DFD be necessary?
- Is it possible that the systems analyst will have to carry out both upward and downward leveling of the DFD? Why or why not?
- Why does the data dictionary typically have to be completed during this stage of development of the behavioral model?
- What kind of error-checking should be done on the data dictionary during this period of the project?
- Why is it often a bad idea for the systems analyst to spend time writing process specifications before the preliminary DFD is completed? Under what conditions might it make sense to write at least a few process specifications?
- What are the eight major components of the finished model of user’s requirements?