This presentation is on problem solving & design for students taking computer science [2210]. Unfortunately I can't give the full explanation here. For any suggestions or clarifications, you can mail me on buxooa72@gmail.com.

1. UNIT 2.1.1 – PROBLEM SOLVING & DESIGN
• show understanding that every computer system is made up of sub-systems, which in turn are
made up of further sub-systems
• use top-down design, structure diagrams, flowcharts, pseudocode, library routines and subroutines
• work out the purpose of a given algorithm
• explain standard methods of solution
• suggest and apply suitable test data
• understand the need for validation and verification checks to be made on input data (validation
could include range checks, length checks, type checks and check digits)
• use trace tables to find the value of variables at each step in an algorithm
• identify errors in given algorithms and suggest ways of removing these errors
• produce an algorithm for a given problem (either in the form of pseudocode or flowchart)
• comment on the effectiveness of a given solution

2. What is a computer system?
A COMPUTER SYSTEM is made up of software, data, hardware,
communications and persware (the people who drive and run the
information system).
TOP-DOWN DESIGN is the breaking down of a computer system into a set of
sub- systems, then breaking each sub-system down into a set of smaller
sub-systems, until each sub-system just performs a single action. Each part
of the problem is broken down into smaller more manageable problems.
Stepwise refinement is the process of breaking down a complex system into
smaller sub-systems.
SUB-ROUTINE: It is a sequence of steps, part of a larger computer program.
Sub-routines written in high-level programming languages are called
‘procedures’ or ‘functions’ depending on how they are used.
PROGRAM LIBRARY / SUB-ROUTINE LIBRARY: It is a collection of standard
programs (subroutine, procedure, function etc), often designed to handle
commonly occurring problems or tasks that are stored. It is pretested and
usually performs a task that is frequently required.
Library routines are stored in a program library and given names. This
allows them to be called into immediate use when needed, even from other
programs. Using library routines make writing programs faster and easier
as part of the work has already been done (and debugged).

3.  BENEFITS OF MODULAR PROGRAMMING
 Modules can be easily tested and debugged (debug: remove errors from program)
 Modules can be prewritten and reused.
 Several programmers can work on separate modules.
 It is easier to make changes to module without updating the entire program.
 DRAWBACKS OF MODULAR PROGRAMMING
 There should be proper planning of each module.
 Additional testing must be done when linking the different module.
 Testing and debugging of separate modules may prove to be time consuming.
 TOOLS AND TECHNIQUES - There are different tools and techniques for modular programming: Structure chart,
flowchart and pseudocode. These techniques can be used to break down a complex problem and refine it to a sub-
system.
 A top-down design approach can be used to produce structure diagrams that demonstrate the modular construction
the system. Each sub-system can be developed by a programmer as sub-routine or an existing library of routine may
already available for use.
 STRUCTURE DIAGRAM - It shows the hierarchy or structure of the different components or modules of the system and
shows how they connect and interact with each other. It visualises how a system works from the initial input, to
processing and, finally, to the desired output.

4. STRUCTURE DIAGRAM EXAMPLE 1
Divide sum
by 10
Calculate sum
of 10
numbers
Program average of 10
numbers
Input 10 numbers Calculate average Print average

5. THIS IS THE END OF
CHAPTER 2.1.1- PROBLEM SOLVING &
DESIGN
IT IS DIFFICULT TO EXPLAIN
EVERYTHING. IT TOOK ME ALMOST 2
MONTHS TO EXPLAIN.
THERE ARE SO MANY EXERCISES TO
PRACTICE BUT UNFORNATELY CANNOT
ADD AS IT WILL BE TOO LENGTHY

6. STRUCTURE DIAGRAM EXAMPLE 2
Read payroll
record
Validate
payroll record
Calculate
deductions
Calculate
gross pay
Update
employee
record
Generate payroll
Get payroll record Calculate net pay Print payroll

7. STRUCTURE DIAGRAM EXAMPLE 3

8.  PSEUDOCODE uses English-like words and mathematical operators that are set out to look like a
program.

 FLOWCHART - a diagrammatic representation of an algorithm or process showing boxes representing
steps and arrows connecting the boxes, showing the flow of data. It is an effective way to
the algorithm that shows how a system or sub-system works.

 ALGORITHM – It is a set of steps for solving a problem in terms of actions to be executed. This is
usually shown as a flowchart or pseudocode. Put it simply, the sequence of steps taken to solve a
problem, for example a recipe.
 An algorithm expects a defined set of inputs, for example entering a series of marks in a computer
science exam.
 It produces a define set of outputs, for example the number of passes and failures.
 It terminates and produces a result always stopping after a finite loop. (a rogue value to stop the loop).
 Most algorithms are guaranteed to produce the correct result.

9. TEST DATA
TEST DATA – A system should be thoroughly tested before
implementation. Computer programs can be tested using test data by
running them on a computer using any data that is required and seeing
what result is output. Test data is the data that is used in tests of a
software system. In order to test a software application, we need to enter
some data for testing most of the features.

10. NORMAL DATA
 NORMAL DATA (ACCEPTABLE/VALID) – A system needs to be working
correctly. Normal test data will accept the data being tested to prove that
the solution works correctly. A set of normal test data should be used
together with the result(s) that are expected from that data.
 Example: days of the month should be any value between 1 and 31 or
students marks in a test may be between 0 and 100.
 A set of normal test data could be: 3,11,25,30 for days of the month.

11. ABNORMAL TEST DATA
ABNORMAL OR ERRONEOUS TEST DATA. This type of test data will
indicate the user that there is a problem. It will usually be rejected as
they are not appropriate and an error message displayed. Testing,
needs to be done to prove that the solution does not give incorrect
results.
Example: negative numbers for days of the month or students marks
in a test.
 A set of abnormal test data could be: -5, 0, P,35 for days of
month.

12. EXTREME & BOUNDARY DATA
 EXTREME/ LIMIT DATA - Extreme data are the largest and the smallest values that the system can
take and will be accepted.
 Example: percentage marks should only be 0 (lowest possible value} and 100 (highest possible value}.
 BOUNDARY DATA – Tests are performed using the boundary values and is used to establish where
the largest and smallest values occur. At each boundary two values are required, one value is
and the other value is rejected.
 Example: In an exam the pass boundary is at 50 percent, merit at 75 percent and distinction at 85
percent. The Valid Boundary values for this situation will be as follows:
49, 50 - for pass
74, 75 - for merit
84, 85 - for distinction
 Boundary values are validated against both the valid boundaries and invalid boundaries.
 A SET OF TEST DATA is all the items of data required to work through a solution.
 For example {-5, 0, 1, 20, 31, 50} can be used to test dates for a month.

13. VALIDATION AND VERIFICATION - In order for computer systems to only accept
data inputs that are reasonable and accurate, every item of data needs to be
examined before it is accepted by the system.
 VALIDATION
 It is the automated checking by a program that data is reasonable before it is
accepted into a computer system (performed automatically by a computer
program). Different types of check may be used on the same piece of data; for
example, an examination mark could be checked for reasonableness by using a
range check, a type check and a presence check. When data is validated by a
computer system, if the data is rejected a message should be output explaining
why the data was rejected and another opportunity given to enter the data.
VALIDATION & VERIFICATION

14. THERE ARE MANY DIFFERENT TYPES OF
VALIDATION CHECKS INCLUDING:
1. RANGE CHECK checks that the values lie within a specified range are accepted.
For example, days of the month should be between 1 and 31 inclusive or
percentage marks between 0 and 100 inclusive.
2. LENGTH CHECK (Check the correct length is entered) - Checks the data
isn't too short or too long. values must be a specific length.
Checks either:
• data contains an exact number of characters. Example: a password must be
exactly eight characters in length else, rejected. OR
• data entered is a reasonable number of characters, for example a family
name could be between 2 and 30 characters inclusive so that names with
one character or 31 or more characters would be rejected.

15. 3. TYPE CHECK checks that the data entered is of a given data type, for example
integer or real number.
4. CHARACTER CHECK checks that when a string of characters is entered it does not
contain any invalid characters or symbols, for example a name would contain letters
only and a telephone number would only contain digits.
5. FORMAT CHECK checks that the characters entered conform to a pre-defined
pattern, for example date of the year is in the format DD/MM/YY.
6. PRESENCE CHECK checks to ensure that some data has been entered and the value
has not been left blank, for example an email address must be given for an online
transaction or key field is not left blank

16. 7. CHECK DIGIT is the final digit included in a code; it is calculated from all the
other digits in the code. Check digits are used for barcodes, product codes,
International Standard Book Numbers (ISBN) and Vehicle Identification Numbers
(VIN).
Check digits are used to identify errors in data entry caused by mis-typing or mis-
scanning a barcode.
They can usually detect the following types of error:
• incorrect digit entered, for example 5327 entered instead of 5307
• transposition errors where two numbers have changed order, for example
5037 instead of 5307
• omitted or extra digits, for example 537 instead of 5307 or 53107 instead of
5307
• phonetic errors, for example 13, thirteen, instead of 30, thirty.

17. VERIFICATION
 VERIFICATION - Verification is performed to ensure that the data entered exactly matches the
original source. Verification means checking the input data with the original data to make sure that
there have been no transcription errors (transcription means copying the data from one source to
another).
 It is used to check that the data does not change as it is being entered. It involves a human as the
computer cannot do this by itself.

 Verification methods include:
 Double entry - to input data twice to the computer system. For example, entering password twice
during sign-up
 Screen/visual check – it involves checking visually the data that has been input. The user may be
asked to confirm that it is correct before continuing
 Proof reading – data entered is checked against the original, generally a person specially trained for
this.
 Parity check
 Checksum

18. TRACE TABLE
It is a technique used to test algorithms, to ensure that no logical
errors occur whilst the algorithm is being processed. The table is made
up of multiple rows and columns. The trace table is used to show any
changes to key variables or key expressions after each line in the
program has been "executed". Each column showing a variable and
any output, and each row showing each number input into the
algorithm and the subsequent values of the variables.
C-temp F_temp Output

19. DRY RUN
 Dry running a program involves the programmer working through a program
on paper, usually using a table called a ‘trace table’. The programmer adds
columns for any variables or expressions that are important. When this has
been done, the programmer works through the program, line by line, filling
into the trace table the values of variables and expressions as they change. By
doing this, the programmer can spot the exact position when things start going
wrong with the program - when variables suddenly contain unexpected values
or expressions don't hold the expected state.

20. STAGES IN PRODUCING ALGORITHMS
 An algorithm is a set of step by step plan to solve a computer-related problem and is
similar to a recipe.

 Obtain a description of the problem and make sure that the problem is clearly specified.
 Break the problem down into sub-problems;
 Identify the input (what need to be input in the system and how is it going to be obtained)
 Identify the processing (A process is an action that is carried out). {calculate, sort, locate,
search, etc..}
 Output of results. (what to display/print etc.…)
 To construct algorithm, should a flowchart or pseudocode be used.
 Step by step test using several sets of test data and trace tables to find any errors.
 Identify the different constant, variable and loop to be used.
 If any errors are found, repeat the process until you think that your algorithm works
perfectly.
 The algorithm should be understandable and clear. use meaningful names for any data
stores.
 Refine the algorithm by adding more details if needed.


21. THE EFFECTIVENESS OF A SOLUTION
 It is a measure of how good the results of the algorithm produced are, as there
are many different solutions to the same problem.
 Does it do what it is supposed to do?
 Does the solution work for all sets of data? (Normal/ abnormal/ boundary)
 There should be no ambiguity. Each step should be clearly and precisely defined.
 Can the algorithm be simplified?
 Does the solution have any unnecessary processes that are never used?
 Are any actions repeated more often than necessary?


22. EXAMPLE 1: AN ALGORITHM TO CONVERT A TEMPERATURE
FROM DEGREES CENTIGRADE TO DEGREES FAHRENHEIT.
FLOWCHART PSEUDOCODE TRACE TABLE
Input C_temp
F_temp := (1.8 * C_temp) + 32
Output F_temp
C-temp F_temp Output

23. EXAMPLE 1: AN ALGORITHM TO CONVERT A TEMPERATURE
FROM DEGREES CENTIGRADE TO DEGREES FAHRENHEIT.
FLOWCHART PSEUDOCODE TRACE TABLE
Input C_temp
F_temp := (1.8 * C_temp) + 32
Output F_temp
C-temp F_temp Output

24. ERRORS IN PSEUDOCODE
Always check that:
IF NUM < SMALL THEN SMALL = NUM; IF NUM > LARGE THEN LARGE = NUM; IF
X>Y THEN Y = X.
Output is always outside the loop.
Small = 1000 (a large number).
Count = count + 1.
There is no counter in repeat loop.
Total = total + num (if num is input) and average = total/ counter.
Check initialized value against counter
Check =, >, <, <=, >=, ><etc

25. SOME PAST EXAM QUESTIONS
AND ANSWERS ON THIS
CHAPTER
PROBLEM SOLVING &DESIGN

26. Study the flowchart very carefully. [JUN 09/P1/14]

27. Study the flowchart. [NOV09/P1/9]

28. [NOV 10/P13/11]

29. Study the following flowchart very carefully: [JUN 10/P11/5]

30. The following flowchart inputs ten temperatures and outputs the average (mean) temperature and the number of
temperatures which were negative (i.e. < 0). [JUN 11/P12/10]

31. Carefully study the following flowchart: [JUN 12/P12/6]

32. NOV 06/P1/9 - A computer program is required which inputs 10 numbers, multiplies them together and
finally outputs the answer (the product). The following algorithm has been written to do this.

33. JUN 10/P11/12 - A golf course charges $10 for each game of two people. Each additional person incurs a
further charge of $2 per game. If they book two or more games in advance, they get a 10% discount on the
total charge. The following program has been written in pseudocode to calculate the charges for a game.

34. [NOV 10/P11 & 12/9] - The following algorithm inputs 20 numbers and outputs how many
numbers were positive (> 0) and how many numbers were negative (< 0).

35. JUN 10/P12/7 - (a) Read the following section of code that inputs twenty (20) numbers and
then outputs the largest number input.