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

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 <identifier> : ARRAY[<lbound>:<ubound>] OF <datatype>    DECLARE <identifier> : ARRAY[<lbound1>:<ubound1>,[<lbound2>:<ubound2>] OF <datatype> 2.2.3 Files 

show understanding of why files are needed 

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

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

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 <identifier>   <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 <identifier> (BYREF <identifier>: <datatype>)    <statement(s)>  ENDPROCEDURE 
  • show understanding of passing parameters by value  PROCEDURE <identifier> (BYVALUE <identifier>: <datatype>)    <statement(s)>  ENDPROCEDURE

 – a call is made to the procedure using CALL <identifier> () 

  • 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 <identifier> RETURNS <data type> // function has no                                                                                                                     parameters    <statement(s)>  ENDFUNCTION  FUNCTION <identifier> (<identifier>: <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(<filename>) 

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

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

2.1.4 Adaptive maintenance 

  • make amendments to an algorithm and data structure in response to specification changes 
  • analyse an existing program and make amendments to enhance functionality