Page 170 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes • Build shells around the library modules to standardize interfaces (e.g. for error handling)
and enhance portability;

• Define conventions for the library modules to use (more than one combination of library
modules might do the same job).
Developers should resist the temptation to clone a library module and make minor modifications,
because of the duplication that result. Instead they should put any extra processing required in
a shell module that calls the library module. A common reason for reusing software is to save
time at the coding and unit testing stage. Reused software is not normally unit tested because
this has already been carried out in a project or by an external organization. Nevertheless
developers should convince themselves that the software to be reused has been tested to the
standards appropriate for their project. Integration testing of reused software is always necessary
to check that it correctly interfaces with the rest of the software. Integration testing of reused
software can identify performance and resource problems.

8.1.4 Definition of Module Processing
The developer defines the processing steps in the second stage of detailed design. The developer
should first outline the module processing in a Program Design Language (PDL) or pseudo-
code and refine it, step-by step, into a detailed description of the processing in the selected
programming language. The processing description should reflect the type of programming
language. When using a procedural language, the description of the processing should contain
only:
• Sequence constructs (e.g. assignments, invocations);
• Selection constructs (e.g. conditions, case statements);
• Iteration constructs (e.g. do loops).
The definition of statements that do not affect the logic (e.g. I/O statements, local variable
declarations) should be deferred to the coding stage. Each module should have a single entry
point and exit point. Control should flow from the entry point to exit point. Control should flow
back only in an iteration construct, i.e. a loop. Branching, if used at all, should be restricted to
a few standard situations (e.g. on error), and should always jump forward, not backward, in
the control flow.
Recursion is a useful technique for processing a repeating data structure such as a tree, or a list,
and for evaluating a query made up of arithmetic, relational, or logical expressions. Recursion
should only be used if the programming language explicitly supports it. PDLs and pseudo-
code can be included in the code as comments, easing maintenance, whereas flowcharts cannot.
Flowcharts are not compatible with the stepwise refinement technique, and so PDLs and pseudo-
code are to be preferred to flowcharts for detailed design.

8.1.5 Defensive Design
Developers should anticipate possible problems and include defences against them. There are
described three principles of defensive design:
• Mutual suspicion;
• Immediate detection;
• Redundancy.
The principle of mutual suspicion says that modules should assume other modules contain errors.
Modules should be designed to handle erroneous input and error reports from other modules.
Every input from another module or component external to the program (e.g. a file) should be
checked. When input data is used in a condition (e.g. CASE statement or IF... THEN.. ELSE...),
an outcome should be defined for every possible input case. Every IF condition should have an
ELSE clause. When modules detect errors and return control to the caller, they should always

164 LOVELY PROFESSIONAL UNIVERSITY