SEM510b Theory of Programming. Exercises: Week One.
Example One.
Produce documentation for the following Pascal Procedure, using pseudo-code, flow charts
and BS6224 diagrams to describe the structure.
Procedure ChooseOption (Var choice:integer);
Begin
DISPLAYMENU
Readln (choice);
Case choice of
1: OPTION1;
2: OPTION2;
3: OPTION3;
4: OPTION4;
5: Writeln (Exit Program);
End {of case statement};
End {of procedure};
Note that other procedure names are given in capitals and you will need to comment on the
interface with these procedures. Comments, which are ignored by the complier, appear with
brackets { ---- }. Within a Pascal procedure call, arguments to return values are preceded by
the keyword “Var” and those which supply input data are not.
Example Two.
Produce documentation for the following Pascal Procedure, using pseudo-code, flow charts
and BS6224 diagrams to describe the structure.
Procedure TransferRecord( Var Input:boolean; Var F1; File; Var NextRec: Record;
Var OK;boolean);
Begin
OK := “TRUE”;
If Input {= true}
THEN
IF EOF(F1)
THEN
OK := “FALSE”
ELSE
Read (F1, NextRec)
ELSE
Write (F1,NextRec);
End;
END { of procedure};
You may assume that EOF (filenumber) is a system routine which returns the value TRUE if
the end-of-file has been reached and the value FALSE if it has not.
1
Example Three.
Produce documentation for the following Pascal Procedure, using pseudo-code, flow charts
and BS6224 diagrams to describe the structure.
Procedure CompareCodes( guess,code:string; Var black,white:integer);
Var
G,C : array [1..4] of char;
i,j : integer;
Begin
For I := 1 to 4 do
begin
COPY(guess(i,i), G(i));
COPY(code(i,i),C(I));
end;
black := 0;
For i := 1 to 4 do
IF C(i) = G(i) THEN
Begin
black := black + 1;
G(i) := “x”;
C(i) := “z”;
End;
white := 0;
For i := 1 to 4 do
For j := 1 to 4 do
IF C(i) = G(j) THEN
Begin
white := white + 1;
G(j) := “x”;
C(i) := “z”;
End;
END {of Procedure};
2
SEM510b Theory of Programming.
Week Two Program Testing.
Consider the following module, described by pseudo-code.
Procedure ConvertRtoN (roman:string; VAR number:integer)
Procedure to convert a string containing a roman numeral into the equivalent integer value.
Input: A string variable containing the string of characters making up the roman numeral.
Output: An integer variable containing the same value.
Local: numchar is integer variable containing length of string
i is control variable for loop
Pseudo-code
Set number to zero.
Set numchar to the length of the string using Length(roman).
Begin loop for i from 1 to numchar
Copy ith character from the string into letter
IF letter = “M” then add 1000 to number
IF letter = “D” then add 500 to number
IF letter = “C” then add 100 to number
IF letter = “L” then add 50 to number
IF letter = “X” then add 10 to number
IF letter = “V” then add 5 to number
IF letter = “I” then add 1 to number
End loop
Return to calling module and end procedure.
Black Box Testing.
What are the equivalence classes for this procedure?
How many test cases are needed?
Follow through the logic and say what values you expect for each of the following text
strings.
I II III IIII V VI VII VIII VIIII X FIVE SIX SEVEN IV XIV XIIII
What additional values do you need to test this procdure fully?
Is boundary value analysis suitable for this procedure?
Is it suitable for other single procedures?
Is it suitable for large programs involving several procedures?
Glass-Box testing.
Are there different paths through the procedure which need extra testing?
Do the equivalence classes defined above give tests for each route through the program?
What other error conditions are possible? How does the procedure deal with these?
Hand in your solutions to the above questions by twelve noon on Tuesday.
If time, you might also consider how to extend the module so that it checks for other
conditions in the later Roman numerals. e.g. the use of IV for four and similar cases where the
order of the letters is significant, or a check to ensure that the number of occurrences of any
letter does not exceed its maximum permitted value.
What cohesion does this module exhibit?
3
SEM510b Theory of programming. Week Three
Exercise One.
A thermocouple measures the temperature of a chemical reaction every second for a 24 hour
period, starting at midnight. The measurements are collected into blocks of 60 consecutive
readings (i.e. one block per minute) which are examined for equipment malfunction. If a
malfunction is detected, an alarm will be activated. The average temperature for each block is
printed, together with the time (in hours and minutes) to which it refers.
The data flow diagram representing this process is shown in the figure below: The central
transforms have already been identified and are surrounded by a dotted line.
thermocouple voltage
convert
voltage to
temp
form
temp.
block
temp
temp.block
temp
CENTRAL TRANSFORMS
form
report
line
block
average
report
heading
printer
user keyboard
check
for
alarm
malfunct.
user
display
calculate
average
time (hrs & mins)
convert to
hours & mins.
seconds
clock
(i) What steps are involved in choosing the central transforms?
(ii) Perform first-level factoring on this diagram.
(iii) Which of the three branch types (afferent, efferent and transform) in the diagram
produced by the answer to part (ii) can be factored further. Complete your structure chart by
factoring all the appropriate branches of the chart produced by first-level factoring. In doing
so, you will need to use to following pre-defined modules:
Module getvolt
Input: none
Purpose: To read the voltage generated
by the thermocouple.
Output: voltage (real variable).
Module alarm
Input: flag (type boolean)
Purpose: Sound alarm if flag
is true.
Output: none.
Module clock
Input none
Purpose: return the time in seconds since midnight
Output: time (integer variable)
4
SEM510b Theory of Programming. Week Four
Exercise One. Z Specification.
Consider a program to carry out Roman arithmetic. This will need to contain two conversion
modules, one to convert from a string to be interpreted as a Roman numeral to an integer
value and the other to convert from an integer value to a string which represents that integer
value. (You need not consider the later version with IV for 4, only the version IIII).
Produce Z specifications for each of these modules. Complete them in time to hand in by
noon on Tuesday.
Remember your Z specification does not contain flow-charts, pseudo code or other ways of
describing how the module achieves its result. It gives a very precise definition of the valid
input to a module, the valid output from a module, and the relationship between them.
Consequently the specifications of these modules will be so short you may not believe they
can be correct. Have faith and hand in what you have produced.
5