PROCEDURALLY ORIENTED DESIGN REPRESENTATIONS

In this section we will provide some examples of the use of different procedurally ori- ented design representations for a single-system example. We will consider object-oriented design representations for the same system later in this chapter in Section 4.9.

Consider a common situation: software that controls a terminal concentrator. A termi- nal concentrator is a hardware device that allows many different terminal lines to access the same CPU. At one time, these were quite common, since the only means of access to computing power was through the use of relatively inexpensive “terminals” that were con- nected remotely to a mainframe or minicomputer. For reasons we will discuss in the next paragraph, this seemingly obsolescent technology is becoming more common in settings where the top-level domain is running out of fixed IP addresses, but the use of DHCP to extend network access is not always appropriate because of the need for some IP addresses to remain static to meet with the needs of specific applications.

Perhaps the most common example of this concept can occur in a hospital setting, where the output from a monitoring device is sent to a computer located at, say, a nurses’ station in an intensive care unit. It is critical to know the patient’s room in which the device is located, so dynamic IP is probably not appropriate to use. There is no need for all the data being monitored to be sent any further than the nurses’ station, although there may be some secondary or tertiary data storage devices nearby because of the need for hospitals to be able to defend themselves against medical malpractice suits. Anyone who has either stayed in a room in an intensive care unit or visited a patient in one is well aware of the fact that these monitoring devices often need to be reset because of such things as inappro- priate alarms, patients accidentally disconnecting the devices, or the plastic bags holding fluids used for IVs becoming empty.

Because this particular situation is likely to be more familiar to you than the classical terminal concentrator, we will use the term “medical device terminal concentrator” for the remainder of this discussion. We will reserve the word “terminal” to describe the devices located in patient rooms.

Input from any of the lines is associated with the medical device terminal concentra- tor to which the line is attached at one end. Corresponding output for a data collection or analysis program running on one of the terminals is sent to the appropriate medical device terminal concentrator’s screen.

To keep the data being sent to and from different terminals from going to the wrong place, the signals are “multiplexed” by the medical device terminal concentrator. Multiplexing hardware and software allow the attachment of many terminals to the same port of the computer, thereby allowing for more simultaneous users (at a potential cost of reduced processing speed, which does not really matter in this application). All terminals on the same terminal concentrator share the same connection to the computer, as is shown in Figure 4.4.

Multiplexing means that a single set of wires is used for the connection from the termi- nal concentrator to the centralized computer. The decision about which terminal to com- municate with along these wires can be made by using different frequencies for the signals or by attaching routing information to each packet of information sent.

The essential data structure in a multiplexed system is a queue. A user’s data is sent from his or her terminal to the medical device terminal concentrator CPU in a stream in a first-in, first-out manner. The data passes through the multiplexing operation of the medical device terminal concentrator and is sent to the CPU when the process is scheduled

for execution. All other processes (and the input/output [I/O] from their terminals) wait for the process to relinquish control of the CPU. Output is then sent from the CPU to the appropriate terminal, also by means of the multiplexing operation of the medical device terminal concentrator.

Thus, there are queues for input, queues for output, and mechanisms for determining which data is attached to which terminal (for either input or output).

A small portion of a flowchart for the software that controls a terminal concentrator is shown in Figure 4.5. You should compare this with the example of pseudocode for the medical device terminal concentrator system (Example 4.2). Many of the steps indicated in Figure 4.5 can be decomposed into additional steps.

Example 4.2: A Pseudocode Representation for a Medical Device Terminal Concentrator

For each terminal {

Repeat forever {

When time for input to CPU {

get input from medical device terminal concentrator’s input queue

place on medical device terminal concentrator input queue to CPU

include information to identify terminal

send input data from concentrator to medical device terminal

Terminals

Terminal

concentrator CPU

FIGURE 4.4 A medical device terminal concentrator. (From Leach, R. J., Object-Oriented Design

concentrator CPU

remove data from concentrator queue }

When time for output from CPU {

receive output data from CPU

place on medical device terminal concentrator’s output queue include information to identify terminal

send output data to terminal queue

remove data from medical device terminal concentrator queue }

} }

Repeat forever

Repeat forever _{Repeat forever}

While input from terminal Get input from terminal While output from CPU Get output from CPU Send output to terminal Send input to CPU

FIGURE 4.5 A portion of a flowchart for a medical device terminal concentrator. (From Leach, R. J., Object-Oriented Design and Programming in C++, Academic Press Professional, Boston, 1995. With permission.)