How to succeed with ADA

Guidelines for getting started

by TONY ORME

F aced with exorbitant and increas- ing bills for software of variable quality, the US Department of

Defense (DOD) initiated a series of moves in 1973. One of these led to an international contest to produce a new progr~m~g language designed especially to reduce the largest com- ponent of the DOD’S software costs - maintenance. The eventual winner was a brand-new language from a mainly European team of experts. It was named ADA in honour of Charles Babbage’s assistant, the first person to express concisely the scope of pro- gramming.

An associated move was to attempt the definition of an ADA progr~~g support environment (APSE) - a set

Abstract: The programming language ADA was devel~ed o~na~l~ to reduce sof~are ~~nte~nce costs for the US Department of Defense. A support environment (APSE) is also under development. A survey has been conducted among UK and US ADA users which has resulted in a set of eight guidelines for managers who are ~~t~plati~ the use ofADA.

Keywords: data processing, programming languages, ADA.

Tony Orme is a systems engineer with Rolm MiI-Spec.

of integrated aids to software develop- ment and maintenance. Knowledge of this subject is less advanced than the design of programming languages. Standardization of APSES by the DOD is still in the future. Conse- quently, different vendors of ADA

system software supply different APSES with different tools.

Why use ADA?

ADA incorporates the latest ideas in programming technology. It is de- signed for what John Barnes calls ‘Programming in the Large’ - pro- gramming and maintenance of medi- um- to huge-scale projects by profes- sionals. Reasons for using ADA usu-

ally derive from one or more of the following:

Software engineering. ADA more readily allows one to achieve the goals of modifiability, reliability and understandability. How it is done is described by Grady Booth in his book Software Engineering

with ADA', already considered a classic. Military requirement. The DOD has required ADA in its projects for some time, but the UK Ministry of Defence (MOD) has announced that ADA will be mandatory in defence projects after 1 July 1987.

NATO made ADA obligatory in January 1986. Exportability. ADA is a truly inter- national language and is much more acceptable than older real- time languages such as CORAL or RTL!Z. Also, in a world where international joint ventures are be- coming more necessary and each country has its own favourite real- time language, ADA is an obvious compromise. Feasibility. Using ADA it is pos- sible to attempt systems of a size or complexity previously considered infeasible. System software support. System software houses are backing away from the older real-time languages. If only because of its sponsors, ADA

will be acceptable and supported over the long term by these sup- pliers. Program design. ADA is possibly the first programming language to be practical as a program design language (PDL). Where ADA PDL has been used, coding is an elabor- ation of the design, ensuring con- sistency between the two. The APSE. ADA will be supported by the widest selection of program- ming tools. Because of the lan- guage portability and the fact that tools are traditionally written in

236 0011-684x/86/050236-05$03.00 0 1986 Butterworth & Co (Publishers) Ltd. data processing

ADA, the best APSE components will have an availability over many machine ranges.

Guidelines

Eight years separated the first require- ments definition for a new language from the validation of the first com-

pilers in 1983. During this time no- body knew how the language would turn out, and ADA became an easy target for abuse. Since then, a number

of small-scale projects have completed or are nearly complete.

To assess the managerial implica- tions of using ADA, the author col- lected the management experiences of 19 sites from eight organizations in Europe and 11 in the USA. The results of the survey were presented to the recent ADA UK conference at York University. From the findings, a set of guidelines was formulated so that the lessons learnt are available in a concise form. The remainder of this article addresses how the reader, as a

prospective project manager (PM) of an ADA project, may take advantage of the experience available in the guidelines. *

Incidentally, the survey was not confined to RolmiDG clients: al- though 13 of the sites were in that category, all of them possessed at least an ADA compiler from other sup- pliers.

Guideline One: Design

Choose a proven design method- ology. The design phase must be tightly controlled: The chief de- signer has to keep his team focused on design goals, not methodological discussions. Use ADA as a PDL.

Design methodology

Almost everybody agreed that any methodology is better than none.

One well-known methodology, ad-

*The guidelines were first published in the user groups’ journal Adu User (April 1986)

vo128 no 5 june 1986

Guidelines for ADA project managers Design

Choose a proven design methodology. The design phase must be tightly controlled: the chief designer has to keep his team focused on design goals, not methodological discussions. Use ADA as a PDL.

Project schedule

The project phases should be scheduled so that design takes O-50% more effort than normal. Once the adjustment to the schedule has been made, no more action is required of scheduling.

Training

Ensure a good training of staff to include the APSE, software engineering principles and design methodology where appropriate. Take a view on whether the complexity of the project warrants a training exercise (other than for new recruits). Software managers on the project will benefit from an understanding of the nature and use of ADA. Ensure that staff have access to a pool of experts after training.

Compiler and APSE

Do not use an unvalidated compiler if at all possible. Obtain a comprehensive APSE; the most essential items are a full symbolic debugger and configura- tion control/library management tools compatible with your site standards.

Reusability

Manage reusability by:

l ensuring existing ADA software within the organization is available to the project,

l appointing staff to keep a reusable library if one does not exist.

Two necessary functions are:

l identification of suitable components l checking the adequacy of the documentation provided.

Responsibility for the former may be diffused throughout the project.

Isolation of tasks

Ensure that the division of tasks between individuals at the design stage is sufficient to eliminate dependencies between them on the completion of software (until integration).

Portability

If portability is a requirement, find a compiler front-end that comes with code generators for all potential targets. Follow the portability recommend- ations discussed above.

Otherwise manage as you would any other project.

237

vacated in particular by Grady Booth and said to complement ADA well, is object-oriented design (OOD). It was tried at half the sites in the survey, but has not been entirely successful. Some of these sites will not use it again and some will use heavily modi- fied forms of OOD. It was reported that problems grow with project size. The minimum remedy appears to be greater formalization of the method- ology. In the meantime, the prospec- tive ADA PM should consider very carefully just what OOD skills and experience are available in their or- ganization before committing to it.

ADA pf)f,

Several sites reported that ADA makes a good PDL, and some use ADA PDL on non-ADA projects. It is felt Safe to use ADA PDL before a decision on implementation language. The advan- tages of using ADA as a PDL were said to be:

automatic checking of module in- terfaces, more reference information, consistency between program de- sign and coding is assured, because the coding is simply an elaboration of the PDL.

Design phase

The design phase with ADA is a long one, and one with a considerable interplay between the people in- volved. From the viewpoint of avoid- ing the delays that plague many com- puter projects, it is a potential danger time. Methodologies are only useful insofar as they deliver the goods; there is no benefit in discussing methodologies per se. If designers (particularly the chief designer) start to flounder or do not look like settling on a workable design, the PM must take action quickly.

Guideline Two: project schedule

The project phases should be sche-

238

duled so that design takes O-SO% more effort than normal depending on circumstances. Coding through testing should take considerably less than normal. Once the adjustment to the schedule has been made, no more action is required of schedu- ling.

Design time

Design was found usually to take more time than the previous high- level languages. Generally the design problem will be better understood, the solution refined (and to some extent machine-checked, if ADA PDL is used) in the extra time, so that time invested here reaps rewards in later stages. The exact amount of extra time that should be scheduled will depend on the designers’ familiarity with the problem and with the tools they will be using.

Parkinson’s Law* operates in com- puting as anywhere else, so the PM needs to ensure that the design team is getting to grips with the problem. The extra time should not be used for the deterioration of a situation already out of control.

Because of a reduction in total project lengths under ADA, a project will be approximately half-way through when design is complete. Before the completion of design, some separation of tasks between team members is desirable in order to reduce dependence (see Guideline six).

Coding, integration and testing

Coding may not be quicker using ADA on smaller projects, but should be on larger projects. Integration is amaz- ingly fast because of the rules govern- ing dependent compilation. Testing with ADA is generally quicker, prob- ably due to more checking during compilation and the use of symbolic debuggers. Problem repair time in

*Work expands to fit the time available.

particular is greatly improved. For scheduling, it is difficult to

quote an exact figure for time savings because of the variability of results reported. For the purposes of report- ing to management, up to 50% im- provement might be mentioned, while a greater improvement could be indicated to the team members.

All figures will improve when staff are fully competent and familiar with the language and the principles of software engineering.

Guideline Three: training

Ensure a good training of staff to include the APSE, software engine- ering principles and design method- ology where appropriate. Take a view on whether the complexity of the project warrants a training exer- cise (other than for new recruits). Software managers on the project will benefit from an understanding of the nature and use of ADA. Ensure that staff have access to a pool of experts after training.

While some smaller sites have man- aged ADA projects with little or no formal training, most sites considered training essential. There appears to be a gradation of difficulty in learning ADA. Those trainees with a back- ground in block-structured languages (e.g. PASCAL, C, CORAL) appear to find it easiest, with no admitted fail- ures in this group. Those who come from unstructured scientific lan- guages (e.g. Scientific BASIC or FOR- TRAN) or ASSEMBLER found it less easy. The small number from a past of commercial languages (like COBOL,

RPG, Business BASIC) had the highest proportion of failures, although still quite low overall. It should be empha- sized, however, that mental attitude is more important than background; a long experience of one language allied to a resistance to new ways of thinking is the most potent cause of failure.

Some sites provided individual or group training projects lasting one or two weeks. It is not clear that use of

data processing

systems

the language, software engineering principles or the different parts of an

APSE actually warrant these exer- cises. The use of a new methodology may justify them. There may, of course, be other issues, such as com- plexity or life-criticality.

Almost all the larger sites had a pool of experts, accessible after train- ing for problems and difficulties. It was usually a group with duties such

as training, research, and/or software support. The availability of such a pool is valuable both for resolving

technical questions and for morale.

Guideline Four: compiler and APSE

Do not use an unvalidated compiler if at all possible. Obtain a compre- hensive APSE; the most essential items are a full symbolic debugger and configuration control/library management tools compatible with your site standards.

The use of an unvalidated compiler always causes problems eventually.

Not only do such compilers usually compile only subsets of the language, but they also frequently reinterpret the syntax or semantics. The result is a constraint during use and a conver- sion problem when finally moving to a validated compiler. The wary are sceptical of claims that a product is close to validation.

Sites which possessed an environ- ment generally found them beneficial, and all wished for or had obtained

additional tools. A symbolic debugger is a great aid to productivity during testing, permitting the possibility of debugging to those unversed in machine internals.

Configuration control and library

management is an area where many tools are currently unsatisfactory or lacking in functionality. A special effort to find tools that really suit will repay many times over.

Other tools found useful or desir- able are:

l syntax-oriented editor, or, failing

~0128 no 5 june 1986

that, a syntax-checking tool, which improves productivity during the coding stage, PDL/design support tools, which are generally marketed independ- ently of particular APSES, real-time compilers as code effici- ency in current compilers is less

than is often desired, particularly by the avionics industry.

Guideline Five: reusability

Manage reusability by:

0 ensuring existing ADA Software within the organization is avail- able to the project,

l appointing staff to keep a reus- able library if one does not exist.

Two necessary functions are:

identification of suitable com- ponents checking the adequacy of the documentation provided.

Responsibility for the former may be diffused throughout the project.

Reusability has to be designed into a component. A sizeable minority of sites believed that there is no over-

head in reusability. The average esti- mated overhead figure is 15% for everything except generics. Generics, which are a kind of procedure tem- plate, are much more difficult to design and test for reusability and 50-100% overhead should be allowed. Those who believe that there is an overhead consider that most of it lies in extra design time, with testing and documentation taking the rest. The documentation must be excellent be- fore any component is submitted to any reusable library.

Some sites formally examine for reusability at the design stage, but that may not be necessary with experi- enced designers. What is essential is that resources be provided to main- tain a reusable library (outside the project unless it is a very large one).

There must be a system for approval of accessions, bug reporting and fix- ing, and good configuration control for both sources and documentation.

Guideline Six: isolation of tasks

Ensure that the division of tasks between individuals at the design stage is sufficient to eliminate dependencies between them on the completion of software (until inte- gration).

While the average productivity gain

using ADA was found to be about 35%, it could be shown statistically that certain kinds of sites did better

than others. Those sites reporting smaller team sizes, or that team mem- bers’ activities could be isolated to a greater extent than previously, en-

joyed more benefits from using ADA.

What happens is that, at the design stage, once the function and interfaces of an ADA package have been speci- fied, there is no longer any need for cooperation between the package maker and the package users. That principle applies equally whether the package maker is a whole team or a team member. Discussions are then about methods or reuse of compo- nents. Coordination and dependence on the completition of the work of others will be greatly reduced. It is also easier to bring newcomers into the project if more manpower is needed.

The PM may take the opportunity to give each project member respon- sibility for a package or set of pack- ages, instead of dividing by function into designers, coders, etc.

Guideline Seven: portability

If portability is a requirement, find a compiler front end that comes with code generators for all potential targets. Follow the portability re- commendations.

Portability of code is important from the outset in most cases, and frequently will be important after initial installation in order to maxi-

239

mize the return on investment in

software. Generally, program conversions

cause problems. ADA is an order-of- magnitude improvement over other

languages, with source line changes of the order of one per cent or less. Normally porting is easier if the ‘front end’ is retained and only the code

generator changed. The serious problems which have

occurred are mostly to do with im- mature compilers. Especially avoid unvalidated compilers, although vali- dated ones have been known to gener- ate erroneous code. Discussion of the sites’ problems has produced the fol-

lowing rules:

l Design with portability in mind. l Avoid using non-standard pragmas

or vendor-supplied packages (un- less the source is available).

l Either isolate all calls to the operat- ing system or write easily alterable interface packages.

Isolate references to terminal con- trol characters so as to be readily changed. Avoid machine dependencies (re-

presentation specs, predefined numeric types, code exits).

There is a guide to portability written by Nissen and Wallis’.

Guideline eight

Otherwise manage as you would any other project.

ADA is a high-level programming language, not very different from others. It was designed, as said above, to incorporate the latest in program- ming technology, with the benefits already mentioned, but it is an evolu- tionary rather than a revolutionary advance. There are no unpleasant surprises in store. Just managing the project with reason and common sense is sufficient; there is nothing to

fear in the language.

Conclusion

Earlier, reasons were given for the use of ADA. The author might, at this point, seek to persuade by naming some of the increasing number of projects using ADA, or listing the powerful organizations backing the language. Instead, just one more reason for using ADA will be added: ADA has been found to work with

many benefits and no nasty surprises;

ADA iS proven.

References

Booth, G Software Engineering with ADA Benjamin Cummings

(1983) Nissen, J and Wallis, P Portability and Style in ADA Cambridge Uni- versity Press (1984)

0

- Rolm Mil-Spec Computers UK Ltd, Dorna House, Guildford Rd, West End, Woking, Surrey GU24 9PW, UK.

Barbican, London, UK 2-5 September 1986

7th international conference on the computer as a design tool

organized by the journal Computer-Aided Design

For conference programme, call for papers and further details contact the CAD 86 Conference Organizer, Butterworth Scientific Ltd, Westbury House, Bury Street, Guildford, Surrey, GU2 5BH, UK. Telephone: 0483 31261. Telex: 859556 SCITEC G.

cl

!Xl Butterworths

240 data processing