CPSC 333: Leveled Sets of Data Flow Diagrams

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Leveled Sets of DFDs


This material was covered during lectures on February 3, 1997.


Why One DFD isn't Generally Enough

In order to make them easy to understand, process specifications should be quite simple - if you need more than two or three pages in order to write a single process specification down, then you should consider replacing the process that this corresponds to with several simpler processes (that communicate with each other in order to do a job), and then produce process specifications for each of the resulting simpler processes instead.

If you start with any nontrivial system and follow this rule, you will find that the number of processes you need to include will become quite large.

However, it's also true that any single data flow diagram should be easy to understand quickly. It's advisable not to include more than (approximately) seven processes and data stores on any single diagram. Otherwise, it will be difficult to read the diagram, and even harder to draw it neatly (and update it as system requirements change).

It's necessary to use more than one diagram in order to represent any nontrivial system, if both these rules are to be followed - as the first example we've seen should suggest.

A Leveled Set of Diagrams

We will use a hierarchical, ``tree'' structure to organize the set of data flow diagrams that represent system requirements.

An Example

Once again, consider Version One of the Student Information System. We've already seen one huge diagram for this system. Suppose each of the processes on that diagram are simple enough to be specified by a process specification.

The next few pictures will present a ``leveled set'' of data flow diagrams specifying the same requirements. First, a context diagram for the system is as follows.

Context Diagram
Figure 1: Context Diagram

This is a ``level 0'' data flow diagram. Unless the system is so trivial that all of it can be specified by a single process specification, there is a ``level 1'' diagram for the system, as well. Since each diagram at level 1 must refine some process on a diagram at level 0, and there is only one process at level 0, there is never more than one level 1 diagram.

Now, here is a reasonable ``level 1'' diagram for the system we're currently considering:

Level 1 DFD
Figure 2: Level 1 Data Flow Diagram

The first two processes shown on this diagram are still pretty complex, so we'll refine each of them using a ``level 2'' diagram. On the other hand, the third is reasonably simple (it's one of the processes that was shown on the ``single huge'' diagram that we've seen already), so we'll refine it using a process specification, instead.

Level 2 DFD
Figure 3: Level 2 Data Flow Diagram Refining Process #1

Level 2 DFD
Figure 4: Level 2 Data Flow Diagram Refining Process #2

At this point, we have seven processes shown on the diagrams that haven't (yet) been refined by lower level diagrams: Processes #3, 1.1, 1.2, 1.3, 2.1, 2.2, and 2.3. A quick comparison with the ``huge'' data flow diagram we've seen already will confirm that these have the same names, inputs, and outputs, as each of the seven processes shown there - and they could be refined using the same seven process specifications, as well.

A Numbering Scheme

Here is a simple way to assign a label to each process in a leveled set of data flow diagrams, that will make it easy to find that process in the DFDs. Indeed, the phrase ``numbering scheme'' is being abused here: Each process will actually receive a label that corresponds of a sequence of numbers, separated by periods.

As mentioned above, the context diagram is the only ``level 0'' diagram in the set. It has a single process that doesn't really need to be numbered. You can give this process the number 0, or you can treat it as the one process in the entire set of DFDs that isn't required to have a process number number at all; either choice is acceptable, and, in the examples shown in this course, we'll always take the latter option.

According to the above rules, the root node (containing the context diagram) will have exactly one child, since it included only one process, and that process is almost always too complicated to be described by a three-page process specification.

This child is the only ``level 1'' diagram in the system. If there are n processes in this diagram (for some positive integer n) then the process numbers used in this diagram should be 1, 2, ..., n.

Now, for k greater than or equal to one,

x.1, x.2, ..., x.m.

So, a ``process number'' is actually a sequence of positive integers separated by periods. If k is bigger than or equal to one, then the processes in a level k diagram will have numbers consisting of k integers (separated by k-1 periods) in the string.

For example, if there is a ``process 2.1'' in the last diagram shown above had been too complicated to specify using a simple process specification, and had been refined using a ``level 3'' data flow diagram with 5 processes on it, instead, then these processes would have had ``process numbers'' 2.1.1, 2.1.2, 2.1.3, 2.1.4, and 2.1.5.

It's almost always necessary to give a ``linear'' order to the diagrams as well, because it's necessary to list the diagrams, one after another in some order, in a requirements specification. Therefore, we will also assign ``Figure numbers'' to the data flow diagrams in a leveled set (or ``tree''). If there are m data flow diagrams in the set, then they will be given figure numbers 1, 2, ..., m.

I recommend the following scheme for assigning figure numbers:

Note that, if you did arrange the diagrams in a tree with the context diagram at the root, then this would be the same as starting at the top (with the diagram) and then moving down, moving all the figures at one level before moving down to the next, and numbering all the diagrams in the same level in left-to-right order as you see them in the tree - a ``breadth first traversal'' of the tree.

Conservation of Flow

This is much more important than the above numbering scheme, and in CPSC 333, no exceptions to the following rule will be allowed.

For all integers k, the set of input data flows and output data flows going into and out of a process X in a level k diagram must be exactly the same as the inputs coming into, and outputs going out of, the processes in the lower level diagram that refines X.

That is,

Then (if you had enough time, as well as paper or blackboard space!) you could take the entire set of leveled data flow diagrams, start with the context diagram, and repeatedly ``cut and paste,'' replacing a process with the lower level data flow diagram that refines it (and matching up the data flows using the information described above), until there were no more lower level data flow diagrams to include. At that point you'd have ``one huge data flow diagram'' representing the entire system, such that every process shown in the diagram had a process specification corresponding to it.

Of course, the leveled set of (simple) data flow diagrams is much easier to read (and maintain) than the single huge one would be.

For example, compare the data flows into and out of the process shown on the context diagram, with the data flows crossing the dashed line - coming in from or going out to ``the outside world'' - on this version of the level 1 diagram; you should be able to convince yourself that the ``conservation of flow'' rule has been obeyed:

Redrawn Figure 2

Finally, you should be able to confirm that if you started with the above context diagram and used the ``cut and paste'' process described above, for as long as you could, then you'd end up with the ``single huge'' data flow diagram for Version One of the Student Information System that has already been shown (except that processes would need to be renumbered in order to create a perfect match).

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Leveled Sets of DFDs


Department of Computer Science
University of Calgary

Office: (403) 220-5073
Fax: (403) 284-4707

eberly@cpsc.ucalgary.ca