Ada* Programming Language Standardization

Paul M. Cohen Defense Communications Engineering Center, Reston, Virginia

The need for software management and standardization of programming languages used in military systems was first identified by DOD in 1975. DOD at that time supported many limited use languages for what are now called embedded computer applications. This diversity of lan- guages contributed to high software costs. In November 1976, DOD first established seven approved HOLS, FOR-

TRAN, COBOL, JOVIAL-J3, JOVIAL-J73, TACPOL, CMS-2, SPL-1.

Eventually the number of approved DOD languages may be reduced to three, Ada, FORTRAN, and COBOL. Ada was established as Military Standard 1815, on 10 December 1980. The ANSI standardization process for Ada is in progress. The Ada concept places restrictions on what may be called an Ada compiler. Compilers may not be called Ada compilers until they have passed validation tests. Up to 80% of software costs are incurred after the software has been put into service. Ada can promote a programming style that leads to maintainable software. It is in the program maintenance phase of the software life cycle where large savings will be achieved through the use of Ada.

DOD RECOGNITION OF THE NEED FOR LANGUAGE STANDARDIZATION

The need for software management and standardiza- tion of programming languages used in military sys- tems was first identified by DOD in a Director of De- fense Research and Engineering (DDRE) memorandum dated 28 January 1975. This memoran- dum recognized that COBOL and FORTRAN have evolved as standards in their respective applications areas, each language having been widely used, and portable code having been developed with each.

The memorandum further noted that DOD has sup-

*Ada is a registered trademark of the Department of Defense (Ada Joint Program O&e).

Address correspondence to Mr. Paul M. Cohen, Code R620, 1860 Wiehle Avenue. Defense Communication Engineering Center, Reston, Virginia 22090.

The Journal of Systems and Software 2.351-355 (1981) Q Elsevier North Holland, Inc, 1982

ported many limited use languages for what are now called embedded computer applications. There were some loose standards within each service. Each service had its own standard languages, the Army had TACPOL, the Air Force had JOVIAL, and the Navy had CMs-2. Not only did several incompatible versions of each lan- guage exist, but the services also used other languages, such as COBOL and FORTRAN. This diversity of lan- guages caused problems in finding programmers with suitable experience. Compilers tended to be less reliable because each compiler was not exercised enough for early discovery of latent errors. This situation contrib- uted to high software costs.

The memorandum called for the formation of a working group with representation from the military departments and appropriate defense agencies. The ini- tial guidance for the group was to determine what was a minimal set of high order languages to accomplish the DOD mission. In accordance with this guidance the High Order Language Working Group (HOLWG) was formed.

The memorandum also established a DOD policy for not supporting further development of new high order languages; however, research into language technology was not forbidden.

After the HOLWG was formed, a second memoran- dum, dated 2 May 1975, called for the HOLWG to de- velop the requirements for a new DOD language for embedded computer systems.

DEFINITION OF AN EMBEDDED COMPUTER SYSTEM

The term Embedded Computer System was coined to define an integrated hardware/software system that forms part of a larger system. Examples of such sys- tems are communications systems, command and con- trol systems, on-board aircraft navigation and weapons control systems, and other real-time control systems.

Note that size does not determine an embedded computer. One may range from a small microcomputer

351 0164-1212/81/040351-05$2.75

352 Paul M. Cohen

system, such as an aircraft autopilot, to a network of large computers, such as the ARPANET backbone system.

CHARACTERISTICS OF SOFTWARE FOR EMBEDDED COMPUTER SYSTEMS

The characteristics of software for embedded computer systems, as opposed to that of scientific or business ap- plications, are as follows:

Intertask Communication

Processes occur in parallel rather than sequential. These processes must be able to speak to one another and exchange information. Such capabilities are miss- ing from existing commonly used languages. Intertask communication is often done in assembler language in- serts even when other portions of the code are in an

HOL.

Real-Time Control

The processes require a man-machine interaction. This type of interaction is not found in existing widely used

HOLS.

Exception Handling

These processes cannot stop when some exceptional sit- uation, such as an arithmetic overflow occurs. The lan-

guage must be able to specify a recovery action for such situations.

Unique I/O Control

Z/O is not with the usual disks, tapes, typewriters, and printers. Input is often from sensors and output is often control information to a mechanical device.

EXISTING SITUATION IN 1975

The situation existing in 1975 can be summarized as

follows:

a. A diversity of programming languages existed. b. Languages were ill-suited to their applications. c. Languages did not support modern programming

methodologies.

In addition it was soon recognized that it is not suf- ficient to simply have a standard language and a com- piler. What was needed was a new concept for the de- velopment of software that managed such software during the entire life cycle of such software. It was nec-

essary to define an integrated software environment and a set of software tools which included not only the com- piler but also the editors, documentation aids, program development aids, and libraries which allowed one to build an engineering discipline and put software devel- opment on an equal scientific basis with other engineer-

ing activities. If DOD failed to develop such a facility, it would

mean that software development would continue to be treated as an art, with little basis for predicting soft-

ware costs and time durations. The consequence of such a situation is frequent occurrence of late, erroneous, and costly software.

THE Ada CONCEPT

Consequently when DOD developed the new program- ming language Ada, the Ada concept did not stop at the development of a programming language. The Ada concept included the following: (a) the Ada Program- ming Language and (b) the Ada Programming Support Environment (APSE).

A programming support environment is part of each Ada compiler effort currently being sponsored by DOD and coordinated through the Ada Joint Program Office (AJPO).

INITIAL DOD DIRECTION ON LANGUAGE STANDARDIZATION IN 1976

A DOD Directive issued in April 1976, DODD 5000.29, directed that DOD-approved languages be used in fu- ture defense system projects. This provision was not ret-

roactive to systems currently in use or under develop- ment. Exceptions were permitted on an individual basis, with each DOD component developing its own waiver process.

The directive further required a control agent for each DOD-approved language. It was recognized that it was not enough for a language to be simply specified as a standard language. A control agent was required for each standard language to assure that the use of a lan- guage and of the compilers for a language was consis- tent with the definition of the language.

The Management Steering Committee for Embed-

ded Computer Resources (MSC-ECR) was estab- lished under the Deputy Undersecretary of Defense for Acquisition Management to correct problems in the management of computer based systems and to imple- ment this directive. The HOLWG which was already in existence became a committee of the MSC-ECR.

In November 1976, DOD Instruction (DoDI) 5000.3 1, established seven approved HOLS, FORTRAN,

COBOL, JOVIAL-J3, JOVIAL-.!73, TACPOL, CMS-2, SPL-I.

Ada Programming Language Standardization

Of the seven languages, two were already American National Standards Institute (ANSI) standards and control facilities were already in existence (FORTRAN and COBOL). Two (CMS-2 and SPL-1) were Navy lan- guages and the Navy was designated the control agent. The two dialects of JOVIAL were under control of the Air Force, and TACPOL was under control of the Army.

DoDI 5000.31 is currently being revised to include Ada. In future revisions, as Ada becomes the standard for all DOD embedded applications, the service lan- guages are to be phased out. It should be noted that the services have an extremely large investment in these languages, so that this phasing out will be a gradual process. DOD systems tend to be long lived, and it will not be practical to retrofit Ada to all existing software in current DOD systems.

Eventually DoDI 5000.31 may contain three lan- guages, Ada, FORTRAN, and COBOL. There is no plan to currently use Ada to replace the scientific applications now programmed in FORTRAN or the business applica- tions which now use COBOL. It is considered that Ada could be used for most applications currently using FORTRAN, but it will require a substantial investment in library software before the business data processing which is now programmed in COBOL could be as easily programmed in Ada.

EMPHASIS ON THE DEVELOPMENT OF FULL Ada

Ada means FULL Ada. Subsets and Supersets are pro- hibited. This is one facet of the Ada standardization program which has generated much comments. There has been pressure to define subsets of Ada, particularly for small machines, on the grounds that full Ada will be impractical on such hardware. Such definition has been resisted for the following reasons:

Enhanced program portability is desired. Program portability has been one of the prime benefits ex- pected from language standardization. Subsets tend to reduce such portability. Extensibility features are within the Language. Many of the reasons for defining subsets in older languages are not valid in Ada. Ada contains a rich mix of features, as part of its generic capability. Such features make what is normally an extension in another language describable in Ada as a library package. Consequently, features are added through libraries rather than through extensions. It permits fewer, more widely used compilers. Sub- sets require subset compilers. Consequently, subsets breed additional compilers. This spreads the use of Ada over more compilers; consequently, each com- piler receives less use, and the latent errors are more slowly uncovered and corrected.

353

d. Local restrictions may be enforced by a preproces- sor. Local restrictions may be prescribed for the use of certain language constructs. These restrictions could be enforced by a preprocessor which would de- tect unauthorized constructs before invoking the compiler.

Presently, incomplete implementations of Ada are being offered as interim products by companies com- mitted to developing complete compilers. These com- panies are permitted to call such interim products Ada, provided a statement of each company’s commitment to a full Ada compiler is included in the advertising of such products.

Ada STANDARDIZATION PROGRAMS

The following is the approximate Ada standardization timetable:

a.

b.

DOD. Ada was established as Military Standard 18 15, on 10 December 1980. ANSI. A 6 month ANSI canvass was conducted be- tween April and October 198 1. This consisted of the development of a consensus for standardization of Ada by polling a list of 96 organizations. This list was compiled by the AJPO with the assistance of ANSI and was approved by ANSI.

Concurrent with the ANSI canvass a public review was held between July and September 1981. This pub- lic review is part of the ANSI canvass process and per- mits those not on the canvass list to comment on the proposed standard.

The comments developed during the ANSI canvass and public review were answered by the AJPO in Jan- uary 1982. Currently the AJPO in conjunction with the Ada design team and the group of reviewers known as the “Distinguished Reviewers” is in the process of re- vising the Ada manual in response to the comments re- ceived during the ANSI canvass. This revision is pri- marily an editorial revision, and corrects the minor manual and language ambiguities which have been un- covered since the manual was published in April 1980.

If the comments received during the canvass so dic- tate then ANSI can request a recanvass over a 2-month period.

The revised Ada manual was completed during the summer of 1982, and resubmitted to ANSI for ap- proval, with the 2-month recanvass.

It should be noted that the canvass method is not the normal method of establishing a language standard. Normally the language is given to the American Na- tional Standards Committee-X3 (ANSC-X3), which then sets up its own mechanism for controlling the stan- dard. Under the canvass method, DOD essentially deals

354

directly with ANSI, not ANSC-X3. ANSC-X3 is in an advisory role.

c. ZSO. An Experts Group (XG) under the Interna- tional Standards Organization (ISO) was proposed in September 198 1. One organizational meeting has been held; however, the group has not yet been for- mally constituted.

CONTROL OF THE Ada STANDARD

It is anticipated that the AJPO and ANSC-X3 will work together in developing the procedures for control- ling the Ada standard.

At the start of the Canvass period a draft proposal for a control organization was developed by DOD. This proposal called for the formation of an Ada Executive Committee which would have representation from the entire Ada community as well as DoD, and would be the Ada control board. The Ada Executive Committee would be assisted by a body of Ada experts called the Ada Council. The membership of the Ada Council would be international in scope. In the international standardization arena, the U.S. members of the Ada Council will form the U.S. “Technical Advisory Group” (TAG).

CONTROL OF THE Ada COMPILERS

It has been previously noted that all standard DOD lan- guages must have an appropriate control agent. The control agent for Ada is, of course, the Ada Joint Pro- gram Office (AJPO), with an important function of this office being the validation of Ada compilers. A capabil- ity for such validation is currently being developed. Pro- spective Ada compilers will be subjected to a set of tests consisting of a validation suite of approximately 1400 programs. This suite is being developed under contract to DOD.

Any compiler used on a DoD program will be re- quired to be certified before such use. The DOD has ob- tained a registered trademark on the term Ada as ap plied to a programming language. Through this trademark the AJPO intends to enforce restrictions on what may be called an Ada compiler. Compilers may not be called Ada compilers until they have passed the validation tests. It is the intention of the test suite to detect subsets, extensions, and full compliance with the Ada standard.

An Ada Implementors’ Guide is available as an aid to organizations now developing Ada compilers. This Guide has been developed by the organization devel- oping the validation capability. Although this guide is

Paul M. Cohen

not part of the official definition, implementors have found it useful.

The current status of the test suite is that a basic capability is available now for compiler implementors. A complete capability will be available after the up- dated Ada manual has been completed.

TIMELINESS OF Ada STANDARDIZATION

There has been some objections to the current Ada standardization effort on the grounds that standardi- zation of the language in its present form is premature. However, the current standardization effort is consid- ered appropriate for the following reasons:

It discourages subsets and supersets from prolifer- ating. Without a standard, people will feel free to make arbitrary changes in the language. Almost anything which resembles the Ada concept might be passed as Ada. Zt encourages the use of the language. People will be more encouraged to learn to use Ada when they are sure that what they are learning is the standard Ada. It supports the establishment of environmentaf tools. The Ada concept has been previously defined as con- sisting of the language and the environment. It will be difficult to define the environment and begin to develop tools for the environment before the stan- dard is established. It encourages the development of standard pack- ages. Successful use of Ada depends on the devel- opment and use of standard library packages. When one knows that such a package will be defined for the standard language there is more encouragement to develop such standard packages.

ECONOMICS OF Ada AS A STANDARD LANGUAGE

The initial savings that will be realized in using Ada as a standard language will be realized when the same compiler and the same language is used from program to program. There will be no need to develop and debug new compilers and retrain programmers to use new lan- guages. In the case of a compiler, the more it is used the more reliable it becomes.

The use of Ada will have little effect on the amount of resources used during the program development cycle. A reasonable strategy for using Ada during the program development cycle is to use essentially the same amount of resources as is now used, but instead of a gain in productivity strive for the development of

Ada Programming Language Standardization

“better” software. “Better” software is defined as soft- ware with the following properties:

Software which is more modular. Such software tends to be better structured, and hence easier to read. Software which is more easily maintained. More modular software is easier to maintain. The Ada concept will lead to less dependencies between soft- ware modules. Thus promulgation of errors from en- hancements to the program will be fewer, and con- sequently the software will be easier to maintain. Software in which there is an increased conjidence of being correct. The programming discipline imposed by Ada promotes less errors in the code. The basic building block in Ada is called a package. The pack- age structure of Ada and the rules which must be observed, aids in the compiler catching more of the errors than in existing systems.

355

d. Software with potential reusability. With the Ada concept one is more likely to find code already de- veloped which can be transported to the application. Studies show that software must be built to be trans- portable. Software which can be reused must be built to be reused.

THE BIG PAYOFF IN USING Ada

The program development phase is not where the big savings will take place with Ada. DOD systems tend to be long lived and subject to frequent changes and mod- ifications. Up to 80% of software costs are incurred after the software has been put into service. Ada can promote a programming style which leads to maintain- able software, and programmers should be trained to program in such a style. Consequently, it is in this pro- gram maintenance phase of the software life cycle where the big savings with Ada will take place.