11.7 Data Flow and Control Flow

For years , data flow and control flow were seen as the primary means to document a software system. Although modern software architecture principles have evolved into the more general study of structures and behavior, these two venerable aspects of software—data and control—rule the day in a few pockets of practice. How do they relate to what we would call a more holistic architecture documentation package?

11.7.1 Data Flow Views

Data flow views of a system are exemplified by data flow diagrams (DFDs), a concept made famous by the structured analysis methods of the 1970s. If your intent is to represent data flows as described earlier, you should choose a style in the C&C viewtype. This viewtype lets you define components for data processing and for data stores. A connector in a C&C view describes an interaction or a protocol between components but usually not the data that flows across the connector. Therefore, to represent data flow diagrams, define a C&C style in which components are procedures—processes—and/or data stores, and the connector is a "data exchange" connector with the additional property of names of data flows. Table 11.13 shows how to represent data flow diagrams in the C&C viewtype.

Table 11.13. Representing data flow diagrams by using the C&C viewtype

	Data Flow Diagram Term	Our Term
Components	Procedure	Component: functionality
	Data store	Component: data store
Connectors	Data exchange	Communication + data flow name

You may also want to describe data flow aspects of modules represented in a style of the module viewtype. To document data type dependencies, you can show which modules are producers or consumers of a specific data type. Representing data flow in a module viewtype is done by defining a style specializing the depends-on relation into a sends-data-to relation. In case it is of interest, data stores can be defined as a specialized type of module. Table 11.14 shows how to represent data flow diagrams in the module viewtype.

Table 11.14. Representing data flow diagrams by using the module viewtype

	Data Flow Diagram Term	Our Term
Element	Procedure	Module
	Data store	Specialized module as data store
Relation	Data flow	Sends-data-to, specialized from depends-on

The allocation viewtype also has the potential to document data flow aspects, especially if analyzing network or storage capacities is important. Such a diagram would represent how much information flows at a time over a network connection or how many megabytes are required for either persistent or temporary storage. Table 11.15 shows how to represent data flow diagrams in the allocation viewtype.

Table 11.15. Representing data flow diagrams by using the allocation viewtype

	Data Flow Diagram Term	Our Term
Software element	Procedure	Process
	Data store	Specialized module as data store
Environmental element	Processor	Physical unit: data store
	Data storage	Physical unit: processor
Relation	Data flow	Sends-data-to
	Communication channel	Communication

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

Finally, note that DFDs don't make the strong distinction among modules, components, and hardware platforms that more modern treatments of architecture do. So if your goal is to reproduce the classic data flow diagrams of structured-analysis fame, you may have to define a hybrid style that combines the module, C&C, and allocation styles. Data dictionaries, a strong part of DFD method, have their counterpart in the element catalogs described in Chapter 10. P- specs , which are essentially pseudocode representations of the elements, can be captured as behavioral information in our world.

If you are a diehard member of the DFD community, take comfort in the fact that you can achieve your goals with the methods of this book. But heed the advice given for the other documentation approaches in this chapter: Augment your favorite with other useful views; then complete the package by adding supporting documentation and beyond view documentation.

11.7.2 Control Flow Views

Whereas a data flow diagram portrays a system from the point of view of the data, a control flow graph, such as a flowchart, portrays the functionality that performs transformation on the data. In Chapter 8, we introduced several modeling languages, some of which have flowchartlike control symbols, such as decisions and loops . Therefore, if flowcharts are part of your system documentation and you are looking for a place to put them in a documentation package prescribed, you can regard them as a form of behavioral documentation and use them in conjunction with any viewtype. In some cases—for example, to support performance analysis or to build in an aid for later debugging—a control flow notation in the primary presentation of a view might be of interest.

In a C&C style, the use of a specific connector defines a control flow, or interaction, between the connected components. (See Table 11.16.) In a module viewtype, control flows would be represented as a uses relation specialized into a transfers-control relation. (See Table 11.17.) In a deployment viewtype, the change of control in the execution environment can be represented. Performance, security, and availability analyses that include the execution platform rely on understanding the flow of control within the system. (See Table 11.18.)

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)

Thus, classic flowcharts, which detail the behavior of programs, can be used as a way to specify the behavior of elements, although many other, more suitable languages are available to do that. At coarser levels of granularity, however, it might make sense to show control flow among architectural elements as a view in its own right, but be clear on the expected use of such a view. Views based on other styles might do the same job and convey richer information as well.

Table 11.16. Representing control flow diagrams by using the C&C viewtype

	Control Flow Diagram Term	Our Term
Components	Procedure	Component: process
Connectors	Control flow	Connector

Table 11.17. Representing control flow diagrams by using the module viewtype

	Control Flow Diagram Term	Our Term
Element	Procedure: process	Module
Relation	Control flow	Transfers-control-to specialized from uses

Table 11.18. Representing control flow diagrams by using the allocation viewtype

	Control Flow Diagram Term	Our Term
Software element	Procedure: process	Process
Environmental element		Physical unit
Relation	Control flow	Communication specialized to control flow

PERSPECTIVES

You're All Just Guessing!

The following humorous but sobering Socratic dialogue written by Michael Jackson (Addison-Wesley, 1995, pp. 42-47) reveals the confusion that happens when users of a documentation method—data flow diagrams in this case—are 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 customers—that's the arrow on the left. Basically, we have to send the payment details to the cashiers for banking—that's the arrow on the right—and 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 full—that'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 invoice—that's the Find Invoice by No process at the top of the diagram—and 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 here—probably for Search for Invoice and Compare Amount—and 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 questions—just 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?"