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

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

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.

Defensive design

Developers should anticipate possible problems and include defenses against them. Myers [Ref. 14] describes 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 inform the caller that an error has occurred. The calling module can then check the error flag for successful completion of the called module. It should be unnecessary for the caller to check the other module outputs.

It is possible for a subordinate to fail to return control. Modules should normally set a 'timeout' when waiting for a message, a rendezvous to be kept, or an event flag to be set. Modules should always act appropriately after a timeout (e.g. retry the operation). For a full discussion of error recovery actions,see reference 14.

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

The principle of immediate detection means that possible errors should be checked for immediately. If the reaction is not immediate, the error should be flagged for later action.

Conventions for taking action after detection of an error should be established. Normally error control responsibilities of a module should be at the same level as normal control responsibilities. Error logging, if done at all, should be done at the point where action is taken, and not at the point of error detection, since the significance of the error may not be apparent at the point of detection. It may be appropriate to insert diagnostic code at the point of detection, however.

Only the top level module should have responsibility for stopping the program. Developers should always check that there are no 'STOP' statements lurking in an otherwise apparently useful module. It may be impossible to reuse modules that suddenly take over responsibility for the control flow of the whole system. Halting the program and giving a traceback may be acceptable in prototype software (because it helps fault diagnosis), but not in operational software.

Redundancy has been discussed in ESA PSS-05-04, 'Guide to the Software Architectural Design Phase'. In detailed design, redundancy considerations can lead designers to include checksums in records and identity tags to confirm that an item is really what it is assumed to be (e.g. header record).

Myers also makes a useful distinction between 'passive fault detection' and 'active fault detection'. The passive fault detection approach is to check for errors in the normal flow of execution. Examples are modules that always check their input, and status codes returned from system calls. The active fault detection approach is to go looking for problems instead of waiting for them to arise. Examples are 'monitor' programs that continuously check disk integrity and attempts to violate system security.

Often most system code is dedicated to error handling. Library modules for error reporting should be made available to prevent duplication of error handling code. When modules detect errors, they should call error library modules to perform standard error handling functions such as error logging and display.

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

Defensive design principles have influenced the design of most modern languages. Strong type-checking languages automatically check that the calling data type matches the called data type, for example. Ada goes further and builds range checking into the language. The degree to which a language supports defensive design can be a major factor in its favor.

Optimization

Conventionally, optimization means to make the best compromise between opposing tendencies. Improvement in one area is often associated with degradation in another. Software performance is often traded-off against maintainability and portability, for example.

The optimization process is to:

• define the attributes to change (e.g. execution time):

• measure the attribute values before modifying the software;

• measure the attribute values after modifying the software;

• analyze the change in attribute values before deciding whether to modify the software again.

Optimization can stop when the goals set in the SRD have been met. Every change has some risk, and the costs and benefits of each change should be clearly defined.

The law of diminishing returns' can also be used to decide when to stop optimization. If there are only slight improvements in the values of attribute values after optimization, the developers should stop trying to seek improvements.

Failure to get a group of people to agree about the solution to an optimization problem is itself significant. It means that the attribute is probably optimized, and any improvement in one attribute results in an unacceptable degradation in another.

The structured programming method discourages optimization because of its effect on reliability and maintainability. Code should be clear and simple, and its optimization should be left to the compiler. Compilers are more likely to do a better job of optimization than programmers, because compilers incorporate detailed knowledge of the machine. Often the actual causes of inefficiency are quite different from what programmers might suspect, and can only be revealed with a dynamic analysis tool (see Section 4.3.9).

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

In summary, developers should define what they are trying to optimize and why, before starting to do it. If in doubt, remember Jackson's two rules of optimization [Ref. 6]:

• don't do it, but if you must:

• don't do it yet.

Prototyping

Experimental prototyping can be useful for:

• comparing alternative designs;

• checking the feasibility of the design.

The high-level design will normally have been identified during the AD phase. Detailed designs may have to be prototyped in the DD phase to find out which designs best meet the requirements.

The feasibility of a novel design idea should be checked by prototyping. This ensures that an idea not only works, but also that it works well enough to meet non-functional requirements for quality and performance.

Design reviews

Detailed designs should be reviewed top-down, level by level, as they are generated during the DD phase. Reviews may take the form of walkthroughs or inspections. Walkthroughs are useful on all projects for informing and passing on expertise. Inspections are efficient methods for eliminating defects before production begins.

Two types of walkthrough are useful:

• code reading:

• 'what-if?' analysis.

In a code reading, reviews trace the logic of a module from beginning to end. In 'what-if?' analysis, component behavior is examined for specific inputs.

Static analysis tools evaluate modules without executing them. Static analysis functions are built in to some compilers. Output from static analysis tools may be input to a code review.

When the detailed design of a major component is complete, a critical design review must certify its readiness for implementation (DD10). The project leader should participate in these reviews, with the team leader and team members concerned.

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

Documentation

The developers must produce the DDD and the SUM. While the ADD specifies tasks, files and programs, the DDD specifies modules. The SUM describes how to use the software, and may be affected by documentation requirements in the SRD.

The recommended approach to module documentation is:

• create the module template to contain headings for the standard DDD entries:

n Component identifier

n.l Type

n.2 Purpose

n.3 Function

n.4 Subordinates

n.5 Dependencies

n.6 Interfaces

n.7 Resources

n.8 References

n.9 Processing

n.lO Data

• detail the design by filling in the sections, with the processing section containing the high-level definition of the processing in a PDL or pseudo-code;

• assemble the completed templates for insertion in the DDD.

A standard module template enables the DDD component specifications to be generated automatically. Tools to extract the module header from the source code and create an entry for the DDD greatly simplify maintenance. When a module is modified, the programmer edits, compiles and verifies the source module, and then runs the tool to generate the new DDD entry.

The SUM contains the information needed by the users of the software to operate it. The SUM should be gradually prepared during the DD phase. The developers should exercise the procedures described in the SUM when testing the software.

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

Date: 2016-01-03; view: 664