For close designs and crooked counsels fit,
Sagacious, bold, and turbulent of wit,
Restless, unfix’d in principles and place,
In power unpleas’d, impatient of disgrace;
A fiery soul, which working out its way,
Fretted the pygmy-body to decay ...

— John Dryden
Absalom and Achitophel, 1680

1. The three levels of systems design;
2. The three major criteria for evaluating a design;
3. How to draw a structure chart; and
4. How to use coupling and cohesion to evaluate a design.

• The entire essential model can be allocated to a single processor. This is often referred to as the mainframe solution.
• Each bubble in the essential model’s Figure 0 DFD can be allocated to a different CPU (typically a mini or micro computer) [1]. This is often referred to as the distributed solution.
• A combination of mainframes, minis, and micros can be chosen to minimize costs, maximize reliability, or achieve some other objective.

• A direct connection between the processors. This could be implemented by connecting the processors with a cable, or a channel, or a local area network. This kind of communication will generally permit data to be transmitted from one processor to another at speeds ranging from 50,000 bits per second (often abbreviated as 50KB) to several million bits (megabits) per second.
• A telecommunications link between the processors, typically via the Internet. This is especially common if the processors are physically separated by more than a few hundred feet. Depending on the nature of the telecommunications link, data will typically be transmitted between the processors at speeds ranging from 28.8 KB per second to as high as several megabits per second [2].
• An indirect link between the processors. Data may be written onto magnetic tape, floppy disk, punched cards, or some other storage medium on one processor and then physically carried to another processor to be used as input.

• Cost. Depending on the nature of the system, a single-processor implementation may be the cheapest, or it may not be. For some applications, a group of low-cost microcomputers might be the most economical solution; for others, implementation on the organization’s existing mainframe computer might be the most practical and economical. [3]
• Efficiency. The systems designer is generally concerned with response time for on-line systems and turn-around time for batch computer systems. Thus, the designer must choose processors and data storage devices that are fast enough and powerful enough to meet the performance requirements specified in the user implementation model. In some cases, the designer may choose a multiple-processor implementation so that different parts of the system can be carried out in parallel, thus speeding up overall response time. At the same time, the designer must be concerned about the inefficiency of processor-to-processor communication, as discussed earlier.

• Security. The end user may have security requirements that dictate the placement of some (or all) processors and/or sensitive data in protected locations. Security requirements may also dictate the nature of (or the absence of) processor-to-processor communication; for example, the designer may be precluded from transmitting data from one processor to another over ordinary telephone lines if the information is confidential.
• Reliability. The end user will typically specify reliability requirements for a new system; these requirements may be expressed in terms of mean time between failure (MTBF) or mean time to repair (MTTR), or system availability. [4]
  In any case, this can have a dramatic influence on the kind of processor configuration chosen by the designer: he or she may decide to separate the system processes into several different processors so that some portion of the system will be available even if other parts are rendered inoperable because of a hardware failure. Alternatively, the designer may decide to implement redundant copies of processes and/or data on multiple processors, perhaps even with spare processors that can take over in the event of a failure. This is shown in Figure 22.4; even if the processing CPU should fail (which is perhaps more likely, because it is a large, complex mainframe computer), the individual edit CPUs can continue operating — collecting transactions, editing them, and storing them for later processing. Similarly, if one of the edit CPUs breaks down, the others can presumably continue operating.
• Political and operational constraints. The hardware configuration may also be influenced by political constraints imposed directly by the end user, by other levels of management in the organization, or by the operations department in charge of maintaining and operating all computer systems. This may lead to a specific choice of hardware configuration, or it may preclude the choice of certain vendors. Similarly, environmental constraints (e.g., temperature, humidity, radiation exposure, dust/dirt, vibration) may be imposed upon the designer, and this can have an enormous influence on the processor configuration that he or she chooses.

• Module A is the top-level executive module of the system consisting of modules A and B. The reason that A is identified as the top-level (superordinate) module is not because it is topologically above module B, but rather because no other module calls it. Module B, on the other hand, is said to be subordinate to module A. (Module A is presumed to be called or invoked by the operating system of the computer.)

IF nuclear-war-begins
CALL Module-B
ELSE
...

DO WHILE there are more orders in ORDERS file
CALL Module-B
ENDDO

• When module B is called, module A’s execution is suspended. Module B begins executing at its first executable statement; when it finishes, it exits or returns to module A. Module A then resumes its execution at the point where it left off.
• Module A may or may not pass input parameters to module B as part of its call, and module B may or may not return output parameters when it returns to module A. In the example shown in Figure 22.7, module A passes parameters X and Y to module B, and module B returns parameters P and Q. Detailed definitions of X, Y, P, and Q would normally be found in a data dictionary. The actual mechanics of transmitting the parameters will vary from one programming language to another.

• Cohesion. The degree to which the components of a module (typically the individual computer instructions that make up the module) are necessary and sufficient to carry out one, single, well-defined function. In practice, this means that the systems designer must ensure that she or he does not split essential processes into fragmented modules; and the designer must ensure that she or he does not gather together unrelated processes (represented as bubbles on the DFD) into meaningless modules. The best modules are those that are functionally cohesive (i.e., modules in which every program statement is necessary in order to carry out a single, well-defined task). The worst modules are those that are coincidentally cohesive (i.e., modules whose program statements have no meaningful relationship to one another at all). [7]
• Coupling. The degree to which modules are interconnected with or related to one another. The stronger the coupling between modules in a system, the more difficult it is to implement and maintain the system, because a modification to one module will then necessitate careful study, as well as possible changes and modifications, to one or more other modules. In practice, this means that each module should have simple, clean interfaces with other modules, and that the minimum number of data elements should be shared between modules. And it means that one module should not modify the internal logic or data of another module; this is known as a pathological connection. (The dreaded ALTER statement in COBOL is a preeminent example.)
• Module size. If possible, each module should be small enough that its program listing will fit on one page (or, alternatively, so that it can be displayed on one screen of a CRT). Of course, sometimes it is not possible to determine how large a module will be until the actual program statements have been written; but initial design activities will often give the designer a strong clue that the module is going to be large and complex. If this is the case, the large complex module should be broken into one or more levels of submodules. (On rare occasions, designers create modules that are overly trivial, for example, modules consisting of two to three lines of code. In this case, several such modules can be aggregated together into a larger supermodule.)
• Span of control. The number of immediate subordinates that can be called by a manager module is known as the span of control. A module should not call more than approximately half a dozen lower-level modules. The reason for this is to avoid complexity: if a module has, say, 25 lower-level modules, then it will probably contain so much complex program logic (in the form of nested IF statements, nested DO-WHILE iterations, etc.) that nobody will be able to understand it. The solution to such a situation is to introduce an intermediate level of manager modules, just as a manager in a human organization would do if he found that he was trying to directly supervise 25 immediate subordinates. [8]
• Scope of effect/scope of control. This guideline suggests that any module affected by the outcome of a decision should be subordinate (though not necessarily immediately subordinate) to the module that makes the decision. It is somewhat analogous to a management guideline that says that any employee affected by the outcome of a manager’s decision (i.e., within the scope of effect of the decision) should be within the manager’s scope of control (i.e., working somewhere in the hierarchy of people that reports to the manager). Violating this guideline in a structured design environment usually leads to unnecessary passing of flags and switches (which increases the coupling between modules), or redundant decision making, or (worst of all) pathological connections between modules.

1. Meilir Page-Jones, The Practical Guide to Structured Systems Design, 2nd ed. Englewood Cliffs, N.J.: Prentice-Hall, 1988.
2. Edward Yourdon and Larry L. Constantine, Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Englewood Cliffs, N.J.: Prentice-Hall, 1989.
3. Paul Ward and Steve Mellor, Structured Development for Real-Time Systems, Volume 3. New York: YOURDON Press, 1986.
4. Michael Jackson, Principles of Program Design. New York: Academic Press, 1975.
5. Ken Orr, Structured Systems Development. New York: YOURDON Press, 1977.
6. Grady Booch, James Rumbaugh, and IvarJacobson. The Unified Modeling Language User Guide. Addison Wesley, 1999.
7. Peter Coad and Edward Yourdon. Object-Oriented Design. Prentice Hall/Yourdon Press, 1991.
8. Sally Shlaer and Stephen J. Mellor. Object-Oriented Systems Analysis: Modeling the World in Data. Prentice Hall/Yourdon Press, 1988.

1. What activity follows the development of the user implementation model in a typical systems development project?
2. What are the three major stages of design in a typical systems development project? What models are developed during these three stages?
3. Why are models important during the design phase of a project?
4. What is the major purpose of the processor model during the design activity?
5. Give three examples of how the processes in an essential model could be mapped onto CPUs in an implementation model.
6. What decisions must be made during the processor modeling activity about data stores that were identified in the essential model?
7. List three common methods for interprocessor communication.
8. What factors should the designer take into account when choosing one of these three methods? Which of these factors do you think is most important?
9. If you are working on a systems development project where reliability is a high priority, how would this affect your decision about allocating essential processes and essential stores to different processors?
10. Give an example of how political constraints could influence the allocation of essential tasks and essential stores to different processors.
11. What is a task model in the context of this chapter? What are its components?
12. Give three common synonyms for task.
13. Under what circumstances could different tasks be operating at the same time?
14. Research Project: Pick a common computer and operating system. Describe how different tasks operating under the control of the operating system can communicate with each other. What is the typical overhead (in terms of CPU time, memory utilization, and any other significant hardware resources) for such intertask communication?
15. Give a definition of the program implementation model. What are its components?
16. How should the designer transform an asynchronous, network-oriented DFD essential model into a synchronous, hierarchical model?
17. Under what conditions does each bubble in the essential model become a module in the program implementation model?
18. List two common design strategies. Give a brief description of each.
19. What is the primary objective that the designer is trying to achieve when he or she translates the essential model into an implementation model?
20. What other objectives does the designer usually try to achieve when he or she creates an implementation model?

1. [1] Before the mid-1990s, this was not realistic for anything other than a trivial system. If a system had 500 bottom-level bubbles in its essential model DFD, would it be realistic to consider implementing the system with 500 separate CPUs? With today’s technology, the answer often turns out to be “yes,” particularly if the separate CPUs actually belong to the end-users (who are presumed to have acquired them, and paid for them, out of their own budget).
2. [2] In many cases, the speed of the telecommunications link depends on whether the end-user is accessing the system through a dial-up connection and his/her own modem, or whether the connection is accomplished via hardware, modems, and telecommunication lines acquired by the development team. In the former case, the development team typically has little or no control over the nature of the equipment or the speed of the connection. Indeed, that becomes a design constraint in many cases: the system needs to be designed so that it will still behave in an acceptable fashion even if the user dials in with a reasonably slow modem.
3. [3] Keep in mind that there is a budget for the entire project, which should have been determined as part of the analysis process (see Chapter 5). Thus, the designer must choose the most efficient system that fits within the budget. However, keep in mind also the fact that budgets can change: the budgets developed during the analysis phase of the project were only estimates and may be subject to revision if the designer can show that more money needs to be spent for an acceptable implementation.
4. [4] System availability is usually defined as the percentage of time that the system is available for use. It can be calculated based on MTBF and MTTR as follows:
   availability = MTBF/(MTBF+MTTR)
5. [5] Of course, a module called EXTRACT CHARACTER does not sound as if it would require 50 to 100 statements; it might only require two to three statements in a typical high-level programming language. In a lower-level machine-oriented language, though, many more statements would typically be required.
6. [6] Indeed, one could interpret the essential model portrayed in Figures 22.1 and 22.2 as an object model (though it obviously does not show such OO concepts as class hierarchies, and it is not diagrammed with popular notations such as UML (See [Booch, 1999] for details of the UML notation). But if one interprets each “bubble” as an object/class, and each “dataflow” between the bubbles as a message between objects, then there is not a fundamental difference between the “structured” view of the system, and an “object-oriented” view; see [Shlaer and Mellor, 1988] for more discussion of this concept.
7. [7] Examples of functionally cohesive modules are CALCULATE-SQUARE-ROOT, COMPUTE-NET-SALARY, and VALIDATE-CUSTOMER-ADDRESS. An example of a coincidentally cohesive module is MISCELLANEOUS-FUNCTIONS
8. [8] There is an exception to this, known as a transaction center. If the manager module makes one simple decision in order to invoke only one of the immediate subordinates, then the program logic within that manager module will probably be fairly simple. In this case, we do not have to worry about the manager’s span of control.