Data Flow and Control Flow

The flow chart is a most thoroughly oversold piece of program documentation. . . . The detailed blow-by-blow flow chart . . . is an absolute nuisance, suitable only for initiating beginners into algorithmic thinking.

(F. P. Brooks 1995, p. 167)

PERSPECTIVES

You're All Just Guessing!

The following humorous but sobering Socratic dialogue written by Michael Jackson (Addison-Wesley, 1995, pp. 4247) reveals the confusion that happens when users of a documentation methoddata flow diagrams in this caseare too loose with the definitions of terms used and the underlying semantics implied. Most of the miscommunication and unintended misdirection come from participants' lack of common understanding of the definitions of the important terms used. Each participant has a separate understanding of what the fundamental terms mean. Additionally, DFDs are bereft of any formal mechanisms that allow the designer to record unambiguous semantic information. Although a common and accepted data dictionary, as recommended by DFD advocates, would go a long way to alleviate many of the problems illustrated in this example, DFDs still do not have the semantic rigor to do more than present a simplistic view of a system.

This example might appear to be contrived, but these lessons generalize. We too have experienced situations in many different settings and with many different representation techniques and methods. The DFD notation is not the only one that suffers from these problems and misuses.

They were all ready to start the walkthrough. Fred had been working on part of the sales accounting system: the problem of matching customers' payments to their outstanding invoices. He had produced a data flow diagram, and was going to walk through it with Ann and Bill. Jane was there too, because she was new to the team and didn't know about data flow diagrams. This was a good opportunity for her to learn about them. Fred had invited her, and the project manager said it was a good idea.

"The diagram I'm going to show you," said Fred, "expands a process bubble in the diagram at the next level up. Here's the bubble to be expanded." He showed this viewgraph on the overhead projector:

"The payments come in from customersthat's the arrow on the left. Basically, we have to send the payment details to the cashiers for bankingthat's the arrow on the rightand put a payment record into the Receivables file on the top right. To do that, we must match the payments with invoices that we get from the Receivables file. If we can't match a payment we put it into the Untraced Payments file, and someone else deals with it. If the payment is not enough to cover the amount in the invoice we send the customer a request to pay in fullthat's up at the top left. Oh, and we also send them requests to explain untraced payments. OK so far?"

"I suppose you need the Customer file so you can put names and addresses on the payment and explanation requests," said Ann.

"Right," said Fred. "Now here's the diagram I've done that expands the process bubble." He put another viewgraph on the projector. It was this:

"Looks good," said Bill. "Let me see if I can walk through it. The Verify Payments process checks to see whether a payment has an invoice number. If it has, you find the invoicethat's the Find Invoice by No process at the top of the diagramand send it with the payment to the Compare Amount process. If it hasn't, you have to search for the invoice by using the customer's name and the amount of the payment. If that doesn't work you have an untraced payment. Otherwise, you send the invoice and payment details to the Compare Amount process as before. Am I on the right lines?"

"Absolutely," said Fred. "Right on."

"The Compare Amount process checks the amount paid against the invoice, and whether it's a full or a part payment you send the details to the cashier for banking and put a payment record in the Receivables file. If it's a part payment you also produce a full payment request. Am I right, or am I right?"

"Terrific," said Fred. "You just forgot to say that untraced payments go to the Produce Explanation Request process so we can send a request to the customer."

"Sounds good to me," said Ann. "We could have an early lunch."

"Well, wait a minute," said Jane. "I haven't really understood what's going on. You said that Verify Payments sends each payment either to Find Invoice by No, or to Search for Invoice, depending on whether it has an invoice number or not. Where does it say that in the diagram?"

"Verify Payments has one input data flow and two outputs," said Ann. "That's where it says it. It's just like the Search for Invoice process. That's got one input data flow of payments without invoice numbers, and two output flows, one for untraced payments, and one for payments with invoices."

"But the Create Payment Record process also has two output flows," said Jane, "one for payment records for the Receivables file, and one for payment details for the bank. But it sends each full or part payment to both of those, not just to one."

"Ann's a bit confused," said Bill. "A data flow diagram doesn't show whether a process writes to one or more of its output flows for each input message. That's at a lower level, probably in the process specification. It's a top-down technique."

"I'm not at all confused," said Ann. "It just depends on your conventions. And I know about top-down as well as you do."

"All right," said Jane. "So we're using Bill's convention. So how do you know that Verify Payments never writes on both its output data flows?"

"That's a funny question," said Fred. "It's obvious, because one flow is named Payment Quoting Invoice No and the other one is Payment Without Invoice No. You have to read the names. Names are very important in systems analysis."

"I am reading the names," said Jane, "and I don't understand them at all. For example, does 'Full Payment' mean the exactly right amount has been paid, or does it include overpayments? And does 'Invoice and Payment Details' mean exactly one invoice and one payment? Don't customers sometimes send one payment to cover more than one invoice? And they could send two checks to cover one invoice, I suppose, as well, couldn't they? And then, what's this Search for Invoice process doing? Suppose there are two invoices for the customer, both with the same amount as the payment? Or two invoices adding up to the amount of the payment? Does 'Search for Invoice' mean it's only searching for one invoice? Or suppose it finds just one invoice, but it's less than the payment? I don't see how you can work out from the diagram whether these are real possibilities, and, if so, what's supposed to happen when they turn up."

"Look, Bill's already said it's top-down," said Fred, "so you can't expect to answer all these detailed questions now. You'll have to come along to the next walkthrough when I'll have the next level of data flow diagrams for the more complicated processes hereprobably for Search for Invoice and Compare Amountand process specifications for the rest."

"But I don't think these are detailed questions," said Jane. "The problem is matching payments to invoices, and you're telling me that the diagram doesn't show whether the matching is one-to-one, one-to-many, many-to-one, or many-to-many. I'd have thought that was a fundamental question about a matching problem, not a detailed question. If the diagram doesn't show that, what does it show?"

"Well," said Bill, "it shows that the function of matching payments to invoices needs seven processes connected by the data flows you can see. That's what it shows."

"I don't understand," said Jane. "It seems to me that it just shows that Fred thinks that seven processes connected like that would be useful. But to find out what the function is, or what the processes are, we have to wait till the next level. So the diagram shows that Fred thinks seven processes would be good for the function, but we don't know what function and we don't know what processes. That can't be right, surely?"

"Hold on," said Fred. "We're going way off track here. The questions Jane is asking about the matching problem are all good questions, and the whole point of the data flow diagram is that it makes you think about the good questionsjust like Jane is doing. She's got the idea pretty fast," he said, ingratiatingly. "That's what a walkthrough's all about."

"Nice of you to say so," said Jane, "but I'm still lost. Suppose we do discuss and think about these questions, would we be able to show the answers in the diagram? From what everyone's been saying, we wouldn't be able to. We'd have to wait till the next level. But I don't see how you'd do it at the next level either. Until you get down to the process specifications you keep talking about. I suppose you could tell from them what it's all about, but if there are lots of levels you might have to wait a long time. The data flow diagrams in the levels above don't seem to be much use. They're just vague pictures suggesting what someone thinks might be the shape of a system to solve a problem, and no one's saying what the problem is."

"Jane, that's offensive," said Bill. "Everyone uses data flow diagrams here, and everyone knows that top-down is the right way to do things. There just isn't any other way. You have to start with the big picture and work your way down to the details."

"Perhaps," said Jane, "but the big picture isn't much use if it doesn't say anything you can understand. You're all just guessing what Fred's diagram means. It wouldn't mean anything at all to you if you didn't already have a pretty good idea of what the problem is and how to solve it."

They went to lunch after that. It was a rather uncomfortable lunch. After lunch Bill and Fred were walking together back to the office they shared. "I don't understand Jane," said Fred. "No," said Bill. "I don't think we should invite her to the next walkthrough, do you?"

R. L.