4.4. Solutions: More on Data Flow Diagrams

1. All but one of the data flows have a single-character name; these should be replaced with clearly functional names.

2. Bubble 3 has no output. There is no reason for a process to have input but no output.

3. Bubble 4 has no input. Apart from a random number generator, or the production of pure fiction, processes must have some kind of data input to transform into their output.

4. The data flow SOMETHING TO DO WITH INVOICES is badly named. It appears that the analyst has not studied the system sufficiently to fully understand what this data flow represents. Also, the terminator that is the source of the flow is unnamed.

5. There is a data flow Q between the terminators x and Y. If there is a real need to know about this flow, then one or the other terminators should be a process inside the context of study.

6. The STORE RRR is write-only, and there is no business reason for such a store. Either a process should read this store, or it should be a terminating data store.

7. The data flow called J is stored in STORE SSS. However, the only data retrieved from it are called M. Either some of the stored data are not being used, or not enough data are stored. You need definitions of the flows and store to determine precisely what is wrong.

8. The data flow out of bubble 5 has no name.

Some other problems with the model are

1. FLIGHT RECORD is a write-only data store. It may be created for use by another system, in which case it’s better to annotate the store with a terminator symbol, like so:

2. PASSENGER IS REGISTERED appears to be a control flow. Its name does not indicate that it carries any data, and so it should be removed from the model.

3. The name of bubble 3, PREFERENCES, indicates that it is not a well-defined function. The output data flows suggest confused functionality within the bubble.

We have reworked the model to correct its errors. The result is shown in Figure 4.4.1. Note that most airlines require advance notice for special meals. The model shows SPECIAL MEAL REQUEST flowing from the write-only data store FLIGHT RECORD. Therefore, the meal request must be entered at the time the reservation is made, or at least some time before the passenger arrives to check in for the flight. This implies that there is some other system to maintain some of the data in the FLIGHT RECORD data store.

Figure 4.4.1: An alternative airline check-in model.

The SEATING PLAN store is also created outside this system. This store reflects the seating layout of the airplane assigned to the flight. Airlines change the seats in their planes, and the type of plane assigned to a flight may differ from day to day. Both of these factors are outside the scope of a check-in system, so we chose to show data stores that are created by another system.

We introduced information into our model that was based on our interpretation of the requirements. Whatever improvements you choose to make, your model must produce the same output as the original. After all, you cannot change the system’s requirements to make the model more convenient.

We have shown the PASSENGER TICKET as an input. The reason for this is that part of the process of registering a passenger is checking that the passenger has a valid ticket. So here, the existence of a ticket, as well as its data, is important. However, in other circumstances, you omit physical articles from the model. For example, the passenger’s bags in and of themselves are not interesting, but the system needs to know the weight of each bag. You’ll notice in many of the other models in this book that there is no reference to inanimate objects, only to their properties. Why is this? Systems analysis is usually the prelude to designing an information system, and most of the time you are more interested in studying the information used by the system than the material that comes in contact with the system.

Once the flows around the edge of the system are in place, you follow each one to find the functionality. We came up with the diagram shown in Figure 4.4.2.

Figure 4.4.2: Diagram 0 for the Government Research Paper Clearing House system. Note that the two data flows REJECT and TEAR-OFF STRIP were not shown in the context diagram.

Your model may differ because you partitioned the system differently. There is no fixed rule that dictates the correct partitioning, so different analysts on the first attempt usually come up with different models. However, as you spend time working with the users, you’ll eventually arrive at a partitioning that satisfies all concerned. The important objective for this exercise is that you use the data flow notation correctly, and show all the boundary data flows.

We do not show terminators in this model. They are in the context diagram, and to repeat them here would be redundant. If you want to know where a given data flow comes from, look at the context diagram. However, some analysts prefer to show terminators at all levels. While there is nothing technically incorrect with doing that, we feel the extra overhead of maintenance outweighs the slight gain in readability of the model. It is better to get used to working with more than one level of model simultaneously rather than creating an incomprehensible monster by trying to fit everything you know on the one model. Some CASE tools maintain the repetition of terminators on lower-level diagrams, in which case you have no choice. The best CASE tools give you a choice. We suggest that you show terminators in some lower-level models and leave them off others, in order for you to decide for yourself which you prefer. For the remainder of this book, we will show terminators at the highest level only, normally the context diagram, and thereafter omit them.

The data flow into the CHECK REQUEST bubble carries a question mark. The wording of the problem is vague about exactly what is being identified: Does it simply make sure that the paper exists, or does it also check that the request is coming from a registered subscriber? The problem statement doesn’t say what happens to rejected requests for papers. If they are merely discarded, then REJECT is a trivial reject and is not shown on the context diagram. However if rejected requests are returned to the subscriber, you should update the context diagram to show the flow to the subscriber.

You weren’t told if the charge for all papers is the same. This model assumes the same fee, but this must be checked with the users. The TEAR-OFF STRIP is shown as a rejection arrow. As it is simply discarded, there is no need to show it on the context diagram.

REQUESTED PAPERS FILE and PENDING LABELS are data stores. The policy of the system states that the order to the PAPERS STORE (a terminator) is sent only once a day. Yet, the Clearing House processes many individual requests during the day. This means that the requests must be stored (in the REQUESTED PAPERS FILE) until it is time to send the order. For a similar reason, the PENDING LABELS store is necessary because the labels have to wait until the store delivers the papers each morning.

Look through the model and reconcile it with your own. The important lesson is your use of the data flow notation, and your growing familiarity with the idea of building a model of the system that you are studying.

Exercise 4: La Cave du Morey Saint-Denis

Figure 4.4.3: Context diagram of the Morey Saint-Denis System for Buying Wine.

Again, your partitioning for the Morey Saint-Denis system may be different from ours, but it is important that you portray the same functionality and use the equivalent data. For example, the bubbles DETERMINE IF NEEDED and DETERMINE IF SUITABLE may be combined into one process. Your data stores may be different provided you correctly recognized the stored data needed by the system.

The data flows UNSTOCKED WINE/LOW STOCK and SUITABLE WINE + SUGGESTED QUANTITY must both contain the price, as well as the name of the wine. This price comes from the WINE OFFER.

Whenever he buys, Monsieur Saint-Denis updates the CELLAR LOG with the order. This prevents him from reordering the same wine should he be offered it again before the arrival of his order.

UPDATE GOOD PERFORMERS is definitely a judgmental process. The shading on the sides of the bubble helps you to explain to Morey Saint-Denis that this process consists mainly of his own opinions. On the other hand, DETERMINE IF SUITABLE can be formalized into a set of rules, and so is not shaded.

Figure 4.4.4: Lower-level diagram of the Morey Saint-Denis system.

Feeling good about your models? We hope so. At this stage, we want you to be comfortable with the modeling conventions, and very happy with the idea of building models of systems. You will have many opportunities to draw data flow diagrams as you work your way through this book, but we want you to concentrate on the system, not the diagramming conventions.