IN THIS CHAPTER, YOU WILL LEARN:

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.

20.1 FINISHING THE PROCESS MODEL

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

Figure 20.1: Upward leveling of the DFD

There are three guidelines that you should keep in mind as you do this:

Figure 20.2: Hiding a local store at the upper level

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:

Figure 20.3: Multiple upward leveling of a DFD

Figure 20.4: Downward leveling of a complex bubble

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.

Figure 20.5: The lower-level DFD

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

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

20.2 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. [2]

20.3 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:

20.4 SUMMARY

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:

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

FOOTNOTES