Distinguishing "data" and "control".
This can be tricky, especially with flowcharts and other types of graphical "system modeling" techniques.
In fact, there are at least two different kinds of traditional flowcharts: "system" flowcharts and "program"
flowcharts. (Newer forms of graphical modeling, such as the Unified Modeling Language (UML) have as
many as nine different types of standard diagrams.) There are, of course, different rules for the construction
of each type. Even more confusing, the arrows in a system flowchart represent the flow of data from one
process or storage device to the next. On the other hand, the arrows in a program flowchart represent the
flow of "control" through the procedural logic of a program.
The flowcharts the book has been discussing so far are program flowcharts. Since programs are ultimately
executed by the CPU of the computer, you can think of a program flowchart as a kind of roadmap for the
CPU. The arrows indicate how the CPU "steps" through the program from one step to the next. You could
also think of the arrows as "links" that tell the CPU where to find the next chunk of instructions after it
completes its current chunk. The execution of a program and its procedural logic consists of the CPU
following the flow of control from one step to next and interpreting and executing each step as it
encounters it in that flow of control. The CPU and the flow of control through the procedural logic of a
program constitute the more or less "dynamic" or "behavioral" aspect of the computer system.
With program flowcharts, the non-CPU components of the computer, such as memory, disk storage, inputoutput, and other peripheral devices, are "in the background". Compared to the CPU, these non-CPU
components, and the data they hold or communicate, are considered to be more or less "static". It is the
program, or more correctly, the CPU under the "control" of the program, that does things to the CPU itself,
to the non-CPU components, and to the data that the CPU and non-CPU components hold or communicate.
Only in very special cases do we allow for the possibility that data stored in memory or on auxiliary storage
may change independently of the execution of the program.
Of course, there is data flow during the execution of a program. However, in a program flowchart, data
flow is specified by the particular instructions that the CPU encounters, such as "print", "get", or
"assignment". Note carefully that in a program flowchart data flow is never indicated by the flow lines and
arrows.
These concepts carry over into structured programming as well (Chapter 2). The various "structures", or
"constructs", such as sequence, selection, and repetition, represent constraints on the design of the flow of
control through a program--how the CPU will step through the program. Again, these types of control
structures do not represent data flow. Data flow is specified in the individual statements or steps within the
control structures.
These concepts also carry over into object-oriented programming (Chapter 12), though with a few twists.
We now think of objects that can do things to themselves or even other objects in response to messages
they receive. The CPU disappears mysteriously into the background. But, if we look under the hood of an
object, what do we find? We find attributes on the one hand; and, on the other hand, methods, or
operations, that describe how to implement the object's response to received messages. The attributes are
objects in a component relationship to the object that contains them. (Some languages also allow traditional
static data elements to be attributes.) Attributes are "static" in the sense that their state (or value) does not
change unless they receive a message (or are acted on by a traditional statement). A method consists of
statements that send messages to the attribute objects. These statements are embedded in (what else?) a
flow of control (preferably structured)--that is to say, procedural logic. (Some programming languages even
allow traditional statements that operate on traditional static data items to be included in the object-oriented
flow of control.)
Who actually executes this object-oriented procedural logic? Well, of course, it's the good old CPU, hiding
"behind the screen", so to speak. In return for this little fiction of objects doing things, we get some very
nice things out of object-oriented programming: data hiding, inheritance, polymorphism, and, if we are
very clever and/or lucky, objects that behave more intuitively or in a more "real-world" sort of way than the
crotchety old CPU in its "natural" state.
ARR (Summer, 2003; 1/23/2004; 5/15/2004)