Language-sensitive editors

Language-sensitive editors are now available for many programming languages. They contain an interpreter that helps the user to write syntactically correct code. For example, if the user selects 'open a file', a menu appears of the known files of the right type. Language-sensitive editors are not ideal for some programming languages, because of the richness of their syntax. Skilled programmers often find them restrictive.

Another approach provides the reserved words of a language from a keypad, which may be real (on a keyboard or tablet), or virtual (on a screen panel). The selection of a keyword like WHILE with a single action is a convenience: the editor may also insert associated syntactic items, such as brackets and comments such as /* END WHILE */ . This does not prevent errors, but is at least a useful guide and the freedom of the programmer is not sacrificed.

The simplest language-sensitive editors do little more than recognise brackets and provide indentation to match. For example, the Pascal reserved words BEGIN and END bracket blocks in IF... THEN... ELSE statements. Automatic indentation after these words have been typed helps to make programs readable and reduces mistakes.

It is also possible to provide templates for program construction, containing standard headers, the obligatory sections for constant and type declarations, and so on. These may be generated automatically by CASE tools. Editors which recognise these templates (and the general form of a legal module), can speed development and help prevent errors. There is considerable scope for the further integration with CASE tools and code generators.

Static analysers

Static analysis is the process of scanning the text of a program to check for faults of construction, dangerous or undesirable features, and the application of software standards. They are especially useful for relatively unstructured languages such as assembler and FORTRAN. Static analysers may:

• check for variables that are not used, or are used before being assigned a value:

• check that the ranges of variables stay within bounds:

• provide a view of the structure of an application:

ESAPSS-05-05 Issue 1 (May 1992) 49 TOOLS FOR DETAILED DESIGN AND PRODUCTION

• provide a view of the internal logical structure of each module;

• measure the complexity of the code with respect to a metric, such as cyclomatic complexity [Ref. 11];

• translate the source code to an intermediate language for formal verification:

• symbolically execute the code by substituting algebraic symbols for program variables:

• measure simple attributes of the code, such as the number of lines of code, and the maximum level of nesting.

Although they can be used to expose poorly structured code, static analysers should not be relied upon to improve poor programming. Structuring should be done in architectural and detailed design, not after implementation.

Most compilers provide some simple static analysis features, such as checking for variables that are not used (see Section 4.3.6). Dedicated static analysis tools usually provide advanced static analysis functions, such as analysis of code structure.

Static analysis tools are no substitute for code review. They just support the review process. Some bad programming practices, such as the choice of meaningful identifiers, evade all known static analysis tools, for example.

Compilers

The choice of compiler on a given computer or operating system may be limited. However, compilers vary widely in speed, thoroughness of checking, ease of use, handling of standard syntax and of language extensions, quality of listings and code output, and programming support features. The choice of compiler is therefore crucial. Trade-offs can become complex, leading to selection by reputation and not by analysis. Users should assess their compilation needs and compare the available options on this basis.

Speed of compilation affects the ease and cost of developing, debugging, and maintaining the product, whereas code quality affects the runtime performance of the product itself. Benchmark source code should therefore reflect the type of code likely to be found in the product to be developed. Compilers should be compared on such data by

50 ESAPSS-05-05 Issue 1 (May 1992) TOOLS FOR DETAILED DESIGN AND PRODUCTION

measuring compilation time, execution time, and object code size. Runtime stack and heap sizes may also be critical where memory is scarce.

Full checking of compiler compliance with language standards is beyond the means of essentially all ESA software projects. Standards organisations such as ISO, ANSI and BSI certify compilers for a few languages including FORTRAN, COBOL and Pascal. The US Department of Defense certifies Ada compilers. Manufacturers' documentation should be scanned for extensions to, or omissions from, the standards.

Compilers vary widely in programming support features. Good compilers offer much help to the developer, for example:

• full listings:

• cross-reference:

• data on module sizes;

• diagnostics;

• thorough checking;

• switches (e.g. array bounds checking; strict language or extensions).

Some compilers now offer many of the features of development environments, including built-in editors and debuggers, trace tools, version control, linkers, and incremental compilation (with a built-in interpreter). These can substantially speed development.

Where there are switchable checks, project programming standards (DDD, section 2.4) should state which options are applicable.

The most advanced compilers perform a range of optimisations for sequential and parallel machines, attempting to discover and eliminate source code inefficiencies. These may be switchable, for example by directives in the source code. Ada explicitly provides for such directives with the 'pragma' statement. Users should investigate whether the optimisations they require are implemented in candidate compilers.

Linkers

The linker may be provided with the machine, operating system, or compiler; or, as with Ada, may be integrated with the compiler/interpreter and runtime system. The user therefore has little control over the choice

ESA PSS-05-05 Issue 1 (May 1992) 51 TOOLS FOR DETAILED DESIGN AND PRODUCTION

of linker. When there is a choice, it should be considered carefully, as modern linkers vary considerably in performance, affecting especially the speed of debugging and maintenance.

It is convenient if the linker can automatically discover the appropriate libraries and directories to use, and which modules or components to link. Most linkers can be controlled by parameters, which can be created by a build or make utility; some are closely integrated with such utilities, or indeed with compilers.

In a large system, linking can take significantly longer than compilation, so users should compare linker performance on realistic benchmarks before selecting one for a project. Speed is not the only parameter to consider: some linkers may generate better quality executable code than others.

Debuggers

The use of interactive symbolic debuggers is strongly encouraged, especially for verification. A good debugger is integrated with an editor as well as a compiler/interpreter, and permits a range of investigative modes. Convenient debugging modes include step-by-step execution, breakpoint (spypoint) tracing, variable value reporting, watch condition setting (e.g. a variable beyond a limit value), and interaction.

For graphics, windows, menus, and other software involving cursor control, the debugger must be properly windowed to avoid confusion with the software being debugged. On some devices, illegal calls, e.g. graphics calls outside the frame area, cause processes to abort; debuggers should be able to trap such calls and permit interactive recovery action, or at least diagnosis.

The debugging of real-time software, where it is not possible to step through code, is a special challenge. The traditional diagnostic log is still useful here. The requirement is, as with all debugging, to view the software in a realistic environment. This may be possible with a simulator: if not, hardware-style techniques, in which bus or circuit signals are monitored in real time, may be necessary. Impiementers of real-time projects should consider how they may debug and verify their software, and should allocate resources for this purpose.

52 ESAPSS-05-05 Issue 1 (May 1992) TOOLS FOR DETAILED DESIGN AND PRODUCTION

Dynamic analysers

Dynamic analysis is the process of measuring how much machine resources (e.g. CPU time, i/o time, memory) each module, and line of code, consumes. In contrast to static analysis (see Section 4.3.5), dynamic analysis is performed on a running program.

Dynamic analysis toots are used for measuring test coverage, since lines of code that are not executed consume no resources. The verification of test coverage, i.e. that all statements have been executed during testing, is a requirement of ESA PSS-05-0. Test coverage is best measured automatically.

Dynamic analysis enab.les a variety of optimisations to be carried out to 'tune' the system. Optimisation can be a very inefficient process without detailed knowledge of the system performance. Dynamic analysis tools can locate the parts of the system that are causing performance problems. Source-level modifications can often yield the desired performance gains.

Where there are precise performance requirements, developers should use a dynamic analyser to verify that the system is satisfactorily tuned, and to direct optimisation effort. If there are no precise performance requirements, and a system runs satisfactorily, dynamic analysis can still help detect some types of coding errors (e.g. unnecessary initialisations).

If a dynamic analyser is not available, resource consumption can be measured by means of timing routines. An interactive debugger can be used to observe coverage.

Test tools

Test tools may support one or more of the following functions:

• test data generation:

• test driving and harnessing;

• automated results checking:

• fault diagnosis and debugging;

• test data management.

General purpose test tools can sometimes generate large quantities of input based on simple assumptions. System-specific simulators and modelling tools are needed if realistic test data is required.

ESAPSS-05-05 Issue 1 (May 1992) 53 TOOLS FOR DETAILED DESIGN AND PRODUCTION

Test drivers and harnesses normally have to be provided by the developers. The integration plan should identify what test drivers and stubs are required for testing, and these normally have to be specially developed.

Interpreter systems permit test drivers and harnesses to be created interactively. Short test drivers, consisting of little more than such a call, can be prepared and called as interpreted commands. Such test drivers do not need to be compiled into the final version. Of the languages mentioned in Section 3.3.1, Pascal, ML, Prolog, LISP and Smalltalk are known to be runnable interpretatively.

Tools that provide automated results checking can greatly increase the efficiency of regression testing, and thereby its depth and scope.

If the comparison reveals a discrepancy between past and present results, support for fault diagnosis, via tracebacks of the execution, reports of the contents of variables, can ease the solution of the problem identified in the test.

Perhaps of alt the functions, support for the management of test data is the most important. Management of the input and output test data is required if regression testing is to be meaningful.

Word processors

A word processor or text processor should be used. Tools for the creation of paragraphs, sections, headers, footers, tables of contents and indexes all ease the production of a document. A spelling checker is essential, and a grammar checker is desirable. An outliner may be found useful for creation of sub-headings, for viewing the document at different levels of detail and for rearranging the document. The ability to handle diagrams is very important.

Documents invariably go through many drafts as they are created, reviewed and modified. Revised drafts should include change bars. Document comparison programs, which can mark changed text automatically, are invaluable for easing the review process.

Tools for communal preparation of documents are now beginning to be available, allowing many authors to comment and add to a single document.

54 ESA PSS-05-05 Issue 1 (May 1992) TOOLS FOR DETAILED DESIGN AND PRODUCTION

Date: 2016-01-03; view: 801