In many software applications, a module may be required to evaluate a complex combination of conditions and select appropriate actions base...
In many software applications, a module may be required to evaluate a complex combination of conditions and select appropriate actions based on these conditions. Decision tables provide a notation that translates actions and conditions (described in a processing narrative) into a tabular form. The table is difficult to misinterpret and may even be used as a machine readable input to a table driven algorithm. In a comprehensive treatment of this design tool, Ned Chapin states :
Some old software tools and techniques mesh well with new tools and techniques of software engineering. Decision tables are an excellent example. Decision tables preceded software engineering by nearly a decade, but fit so well with software engineering that they might have been designed for that purpose.
Decision table organization is illustrated in figure. Referring to the figure, the table is divided into four sections. The upper left-hand quadrant contains a list of all conditions. The lower left-hand quadrant contains a list of all actions that are possible based on combinations of conditions. The right-hand quadrants form a matrix that indicates condition combinations and the corresponding actions that will occur for a specific combination. Therefore, each column of the matrix may be interpreted as a processing rule.
The following steps are applied to develop a decision table:
1. List all actions that can be associated with a specific procedure (or module).
2. List all conditions (or decisions made) during execution of the procedure.
3. Associate specific sets of conditions with specific actions, eliminating impossible combinations of conditions; alternatively, develop every possible permutation of conditions.
4. Define rules by indicating what action(s) occurs for a set of conditions.
To illustrate the use of a decision table, consider the following excerpt from a processing narrative for a public utility billing system:
If the customer account is billed using a fixed rate method, a minimum monthly charge is assessed for consumption of less than 100 KWH (kilowatt-hours). Otherwise, computer billing applies a Schedule A rate structure. However, if the account is billed using a variable rate method, a Schedule A rate structure will apply to consumption below 100 KWH, with additional consumption billed according to Schedule B.
Figure below illustrates a decision table representation of the preceding narrative. Each of the five rules indicates one of five viable conditions (i.e., a T (true) in both fixed rate and variable rate account makes no sense in the context of this procedure; therefore, this condition is omitted). As a general rule, the decision table can be effectively used to supplement other procedural design notation.
Program Design Language
Program design language (PDL), also called structured English or pseudocode, is "a pidgin language in that it uses the vocabulary of one language (i.e., English) and the overall syntax of another (i.e., a structured programming language)" . PDL is used as a generic reference for a design language.
At first glance PDL looks like a modern programming language. The difference between PDL and a real programming language lies in the use of narrative text (e.g., English) embedded directly within PDL statements. Given the use of narrative text embedded directly into a syntactical structure, PDL cannot be compiled (at least not yet). However, PDL tools currently exist to translate PDL into a programming language “skeleton” and/or a graphical representation (e.g., a flowchart) of design. These tools also produce nesting maps, a design operation index, cross-reference tables, and a variety of other information.
A program design language may be a simple transposition of a language such as Ada or C. Alternatively, it may be a product purchased specifically for procedural design.
Regardless of origin, a design language should have the following characteristics:
• A fixed syntax of keywords that provide for all structured constructs, data declaration, and modularity characteristics.
• A free syntax of natural language that describes processing features.
• Data declaration facilities that should include both simple (scalar, array) and complex (linked list or tree) data structures.
• Subprogram definition and calling techniques that support various modes of interface description.
A basic PDL syntax should include constructs for subprogram definition, interface description, data declaration, techniques for block structuring, condition constructs, repetition constructs, and I/O constructs. The format and semantics for some of these PDL constructs are presented in the section that follows.
It should be noted that PDL can be extended to include keywords for multitasking and/or concurrent processing, interrupt handling, interprocess synchronization, and many other features. The application design for which PDL is to be used should dictate the final form for the design language.
A PDL Example
To illustrate the use of PDL, we present an example of a procedural design for the SafeHome security system software introduced in earlier chapters. The system monitors alarms for fire, smoke, burglar, water, and temperature (e.g., furnace breaks while homeowner is away during winter) and produces an alarm bell and calls a monitoring service, generating a voice-synthesized message. In the PDL that follows, we illustrate some of the important constructs noted in earlier sections.
Recall that PDL is not a programming language. The designer can adapt as required without worry of syntax errors. However, the design for the monitoring software would have to be reviewed (do you see any problems?) and further refined before code could be written. The following PDL defines an elaboration of the procedural design for the security monitor component.
PROCEDURE security.monitor;
INTERFACE RETURNS system.status;
TYPE signal IS STRUCTURE DEFINED
name IS STRING LENGTH VAR;
address IS HEX device location;
bound.value IS upper bound SCALAR;
message IS STRING LENGTH VAR;
END signal TYPE;
TYPE system.status IS BIT (4);
TYPE alarm.type DEFINED
smoke.alarm IS INSTANCE OF signal;
fire.alarm IS INSTANCE OF signal;
water.alarm IS INSTANCE OF signal;
temp.alarm IS INSTANCE OF signal;
burglar.alarm IS INSTANCE OF signal;
TYPE phone.number IS area code + 7-digit number;
•
•
•
initialize all system ports and reset all hardware;
CASE OF control.panel.switches (cps):
WHEN cps = "test" SELECT
CALL alarm PROCEDURE WITH "on" for test.time in seconds;
WHEN cps = "alarm-off" SELECT
CALL alarm PROCEDURE WITH "off";
WHEN cps = "new.bound.temp" SELECT
CALL keypad.input PROCEDURE;
WHEN cps = "burglar.alarm.off" SELECT deactivate signal [burglar.alarm];
•
•
•
DEFAULT none;
ENDCASE
REPEAT UNTIL activate.switch is turned off
reset all signal.values and switches;
DO FOR alarm.type = smoke, fire, water, temp, burglar;
READ address [alarm.type] signal.value;
IF signal.value > bound [alarm.type]
THEN phone.message = message [alarm.type];
set alarm.bell to "on" for alarm.timeseconds;
PARBEGIN
CALL alarm PROCEDURE WITH "on", alarm.time in seconds;
CALL phone PROCEDURE WITH message [alarm.type], phone.number;
ENDPAR
ELSE skip
ENDIF
ENDFOR
ENDREP
END security.monitor
Note that the designer for the security.monitor component has used a new construct PARBEGIN . . . ENDPAR that specifies a parallel block. All tasks specified within the PARBEGIN block are executed in parallel. In this case, implementation details are not considered.
message IS STRING LENGTH VAR;
END signal TYPE;
TYPE system.status IS BIT (4);
TYPE alarm.type DEFINED
smoke.alarm IS INSTANCE OF signal;
fire.alarm IS INSTANCE OF signal;
water.alarm IS INSTANCE OF signal;
temp.alarm IS INSTANCE OF signal;
burglar.alarm IS INSTANCE OF signal;
TYPE phone.number IS area code + 7-digit number;
•
•
•
initialize all system ports and reset all hardware;
CASE OF control.panel.switches (cps):
WHEN cps = "test" SELECT
CALL alarm PROCEDURE WITH "on" for test.time in seconds;
WHEN cps = "alarm-off" SELECT
CALL alarm PROCEDURE WITH "off";
WHEN cps = "new.bound.temp" SELECT
CALL keypad.input PROCEDURE;
WHEN cps = "burglar.alarm.off" SELECT deactivate signal [burglar.alarm];
•
•
•
DEFAULT none;
ENDCASE
REPEAT UNTIL activate.switch is turned off
reset all signal.values and switches;
DO FOR alarm.type = smoke, fire, water, temp, burglar;
READ address [alarm.type] signal.value;
IF signal.value > bound [alarm.type]
THEN phone.message = message [alarm.type];
set alarm.bell to "on" for alarm.timeseconds;
PARBEGIN
CALL alarm PROCEDURE WITH "on", alarm.time in seconds;
CALL phone PROCEDURE WITH message [alarm.type], phone.number;
ENDPAR
ELSE skip
ENDIF
ENDFOR
ENDREP
END security.monitor
Note that the designer for the security.monitor component has used a new construct PARBEGIN . . . ENDPAR that specifies a parallel block. All tasks specified within the PARBEGIN block are executed in parallel. In this case, implementation details are not considered.