### 2.1 Algorithm design and problem-solving

Candidates should be able to:

2.1.1 Algorithms

• show understanding that an algorithm is a solution to a problem expressed as a sequence of defined steps
• use suitable identifier names for the representation of data used by a problem

– summarise identifier names using an identifier table

• show understanding that many algorithms are expressed using the four basic constructs of assignment, sequence, selection and repetition
• show understanding that simple algorithms consist of input, process, output at various stages
• document a simple algorithm using:

– structured English

– pseudocode (on the examination paper, any given pseudocode will be presented using the Courier New font)

– program flowchart

• derive pseudocode or a program flowchart from a structured English description of a problem
• derive pseudocode from a given program flowchart or vice versa
• show an appreciation of why logic statements are used to define parts of an algorithm solution
• use logic statements to define parts of an algorithm solution

### 2.2 Programming and data representation

Candidates should be able to:

2.2.1 Data types

• select appropriate data types for a problem solution
• use in practical programming the data types that are common to procedural high-level languages: integer, real, char, string, Boolean, date (pseudocode will use the following data types:  INTEGER, REAL, CHAR, STRING, BOOLEAN, DATE, ARRAY, FILE)
• show understanding of how character and string data are represented by software including the ASCII and Unicode character sets

2.2.2 Arrays

• use the technical terms associated with arrays including upper and lower bound
• select a suitable data structure (1D or 2D array) to use for a given task

• use pseudocode for 1D and 2D arrays (pseudocode will use square brackets to contain the array subscript, for example a 1D array as A[1:n] and a 2D array as C[1:m, 1:n])
• write program code using 1D and 2D arrays
• write algorithms/program code to process array data including:

– sorting using a bubble sort

– searching using a linear search

• given pseudocode will use the following structures:   DECLARE <identiﬁer> : ARRAY[<lbound>:<ubound>] OF <datatype>    DECLARE <identiﬁer> : ARRAY[<lbound1>:<ubound1>,[<lbound2>:<ubound2>] OF <datatype> 2.2.3 Files

show understanding of why files are needed

• use pseudocode for file handling:   OPENFILE <ﬁlename> FOR READ/WRITE/APPEND // Open ﬁle (understand the    difference between various ﬁle modes)  READFILE <ﬁlename>,<string> // Read a line of text from the ﬁle  WRITEFILE <ﬁlename>,<string> // Write a line of text to the ﬁle  CLOSEFILE <ﬁlename>         // Close ﬁle   EOF(<ﬁlename>)        // function to test for the end of the ﬁle
• write program code for simple file handling of a text file, consisting of several lines of text

### 2.3 Stepwise refinment and structured charts

Candidates should be able to:

• use the process of stepwise refinement to express an algorithm to a level of detail from which the task may be programmed
• decompose a problem into sub-tasks leading to the concept of a program module (procedure/ function)

2.1.2 Structure chart

• use a structure chart to express the parameters passed between the various modules/ procedures/functions which are part of the algorithm design
• describe the purpose of a structure chart
• construct a structure chart for a given problem
• derive equivalent pseudocode from a structure chart

### 2.4 Structured programming

Candidates should be able to:

• use a procedure
• explain where in the construction of an algorithm it would be appropriate to use a procedure

– given pseudocode will use the following structure for procedure definitions: PROCEDURE <identiﬁer>   <statement(s)> ENDPROCEDURE

– a procedure may have none, one or more parameters

– a parameter can be passed by reference or by value

• show understanding of passing parameters by reference  PROCEDURE <identiﬁer> (BYREF <identiﬁer>: <datatype>)    <statement(s)>  ENDPROCEDURE
• show understanding of passing parameters by value  PROCEDURE <identiﬁer> (BYVALUE <identiﬁer>: <datatype>)    <statement(s)>  ENDPROCEDURE

– a call is made to the procedure using CALL <identiﬁer> ()

• use a function
• explain where in the construction of an algorithm it is appropriate to use a function
• use the terminology associated with procedures and functions: procedure/function header, procedure/function interface, parameter, argument, return value

– given pseudocode will use the following structure for function definitions:  FUNCTION <identiﬁer> RETURNS <data type> // function has no                                                                                                                     parameters    <statement(s)>  ENDFUNCTION  FUNCTION <identiﬁer> (<identiﬁer>: <data type>)  RETURNS <data type> // function has one or more parameters    <statement(s)>  ENDFUNCTION

– a function is used in an expression, for example

○ x ← SQRT(n)

○ WHILE NOT EOF(<ﬁlename>)

• write programs containing several components and showing good use of resources

### 2.5 Software development

Candidates should be able to:

2.4.1 Programming

• show understanding of the design, coding and testing  stages in the program development cycle
• show understanding of how to write, translate, test and run a high-level language program
• describe features found in a typical Integrated Development Environment (IDE):

– for coding, including context-sensitive prompts

– for initial error detection, including dynamic syntax checks

– for presentation, including prettyprint, expand and collapse code blocks

– for debugging, including: single stepping, breakpoints, variables/expressions report window

2.4.2 Program testing

• show understanding of ways of exposing faults in programs and ways of avoiding faults
• locate and identify the different types of errors:

– syntax errors

– logic errors

– run-time errors

• correct identified errors

2.4.3 Testing strategies

• choose suitable data for black-box testing
• choose suitable data for white-box testing
• understand the need for stub testing

2.1.3 Corrective maintenance

perform white-box testing by:

– selecting suitable data

– using a trace table

• identify any error(s) in the algorithm by using the completed trace table
• amend the algorithm if required