Think like a programmer.

Why we need abstraction.

A real system holds far more detail than any program can or should handle. A rail map (Fig. 1) is drawn for one purpose, getting from station to station, so it keeps the stations, their order and where lines connect, and leaves out everything else.

• Purpose: to produce a simplified model of a problem that keeps only the details relevant to solving it.
• Need: real problems are too complex to solve all at once; without abstraction a program would try to model details that change nothing about the answer.
• Benefits: the problem is easier to understand; the solution takes less time to design and program; the program is smaller and needs less data to be collected and stored; the developer can focus on the parts that matter; a general model can be reused for similar problems.

Building an abstract model.

In the exam you may be given a scenario and asked to produce an abstract model: list only the details the system needs, often as the data it must store. Ask of every detail: does the program need this to do its job?

Decomposition into modules.

Decomposition breaks a problem down step by step until each part is small enough to code. Each part then becomes a module. In the lab, run the first two programs: one module is a function, used inside an expression; the other is a procedure, CALLed as a statement on its own.

A report program can be decomposed into the sub-problems input the data, work out each grade and output the report. Two of those become modules in 9618 pseudocode:

FUNCTION Grade(Mark : INTEGER) RETURNS CHAR
    IF Mark >= 70 THEN
        RETURN 'A'
    ELSE
        IF Mark >= 50 THEN
            RETURN 'B'
        ELSE
            RETURN 'C'
        ENDIF
    ENDIF
ENDFUNCTION

PROCEDURE OutputLine(Name : STRING, Mark : INTEGER)
    OUTPUT Name, " scored ", Mark, ", grade ", Grade(Mark)
ENDPROCEDURE

CALL OutputLine("Amina", 64)

The call outputs Amina scored 64, grade B. The function Grade returns one value and is used inside the OUTPUT expression; the procedure OutputLine is run with CALL.

• Easier to solve: each module is a small, self-contained problem.
• Teamwork: different programmers can write and test different modules at the same time.
• Testing and maintenance: each module can be tested on its own, and an error is easier to find and fix in one module.
• Reuse: a module such as Grade can be called many times, or reused in another program, instead of repeating code.