Structured programming

The rules of structured programming are given in section 3.2.3. These rules should always be followed when a procedural language is used (such as FORTRAN, COBOL, Pascal or Ada). It is easy to break the rules of structured programming when the older procedural languages (e.g. FORTRAN, COBOL) are used, but less so with the more modern ones (Pascal, Ada).

Consistent programming

Language constructs should be used consistently. Inconsistency often occurs when modules are developed and maintained by different people. Coding standards can help achieve consistency, but it is not realistic for them to cover every situation. Modifications to the code should preserve the style of the original.

Module size

Modules should be so short that the entire module can be seen at once. This allows the structure, and the control logic, to be appreciated easily. The recommended maximum size of modules is about 50 lines, excluding the header and diagnostic code.

Code simplicity

Modules should be 'simple'. The principle of 'Occam's razor', (i.e. that an idea should be expressed by means of the minimum number of entities), should be observed in programming. Simplicity can be checked formally by applying complexity measures [Ref. 11]. Simplicity can be checked informally using the rule of seven: the number of separate things that have to be held in mind when examining a part of the module should not exceed seven. Whatever method of evaluation is used, all measurements of simplicity should be confirmed by peer review.

ESA PSS-05-05 Issue 1 (May 1992) 19 THE DETAILED DESIGN AND PRODUCTION PHASE

Coding standards

Coding standards should be established for alt the languages used, and documented or referenced in the DDD. They should provide rules for:

• presentation, (e.g. header information and comment layout):

• naming programs, subprograms, files, variables and data;

• limiting the size of modules;

• using library routines, especially:

- operating system routines:

- commercial library routines (e.g. numerical analysis):

- project-specific utility routines:

• defining constants;

• defining data types:

• using global data;

• using compiler specific features not in the language standard;

• error handling.

The standard header should be made available so that it can be edited, completed and inserted at the head of each module.

Unit testing

Unit tests verify the design and implementation of all components from the lowest level defined in the detailed design up to the lowest level in the architectural design (normally the task level). Test harnesses, composed of a collection of drivers and stubs, need to be constructed to enable unit testing of modules below the top level.

Unit tests verify that a module is doing what it is supposed to do ('black box' testing), and that it is doing it in the way it was intended ('white box' testing). The traditional technique for white box testing is to insert diagnostic code. Although this may still be necessary for testing real-time behaviour, debuggers are now the preferred tool for white box testing. The usual way to test a new module is to step through a few test cases with the debugger and then to run black box tests for the rest. Later, black box tests are run to fully exercise the module. The input test data should be realistic and cover the whole range of possibilities. Programmers revert to 'white box' testing mode when they have to debug a problem found in a black box test.

20 ESAPSS-05-05 Issue 1 (May 1992) THE DETAILED DESIGN AND PRODUCTION PHASE

Before a module can be accepted, every statement shall be successfully executed at least once (DD06). Coverage data should be collected during unit tests. Tools and techniques for collecting coverage 'data are:

• debuggers:

• dynamic analysers;

• diagnostic code.

The inclusion of diagnostics can clutter up the code (see Section 2.5.1.10) and debuggers and dynamic analysers are much preferable. Coverage should be documented in a debug log, a coverage report, or a printout produced by the diagnostic code.

Unit testing is normally carried out by individuals or teams responsible for producing the component.

Unit test plans, test designs, test cases, test procedures and test reports are documented in the Unit Test section of the Software Verification and Validation Plan (SWP/UT).

Date: 2016-01-03; view: 723