Chapter 3 Section 3
Upward Compatibility Risks

Risk Assessment
Risk Mitigation

Ada 95 is highly upward compatible with Ada 83; PEOs and PMs will be able to preserve their investment in Ada 83 software when transitioning to Ada 95. Nevertheless, some risks exist, as explained in this section. PEOs, PMs, and their developers and/or contractors will be able to mitigate these risks using actions defined in this section.

Risk Assessment

Issue: How Upward Compatible is Ada 95?

The brief answer to this question is - very compatible! Ada 95 is almost a strict superset of the Ada 83 language. However, it should be noted that there a few areas where upward incompatibilities cannot be avoided. For example, to add new capabilities such as object-oriented programming and improved real-time programming it was necessary to introduce new keywords into the language. These keywords will make some Ada 83 programs incompatible with Ada 95. Fortunately, it is possible to automatically detect this kind of upward incompatibility by running the source code through an Ada 95 compiler. Fixes can be made using automated tools.

Based on current analysis of Ada 83 and existing Ada 95 programs, it is expected that a majority of existing Ada 83 programs will not have to be significantly altered; the most common incompatibilities will be detected when the software is recompiled with an Ada 95 compiler. Based on early Ada 95 experiences, there are five upward incompatibilities that most organizations need to be aware of:

New reserved words - Ada 95 has six new reserved words. Any Ada 83 program that uses these as identifiers is an illegal Ada 95 program. All Ada 95 compilers will diagnose this problem. It is straightforward to use an editor's Search and Replace function or to write a script to change all of the identifiers into ones that do not conflict with the keywords.
Type Character has 256 values - Ada 95 will allow the use of international characters by using the ISO Latin-1 character set (a superset of the common ASCII characters). A few programs that depend on the fact that Ada 83's type character has 128 values will be affected by this change. The ISO Working Group maintaining Ada has already allowed this change in Ada 83. An Ada 95 compiler will not be able to automatically detect all cases of this problem. Peer inspection and automated tools should be used to help diagnose this situation.
Generic Parameters - Ada 95 differentiates between two cases of generic instantiations; Ada 83 does not. This change will require that some Ada 95 programs add the characters "(< >)" to some code. Ada 95 compilers will automatically detect this situation, and the change is very straightforward. This change will detect some previously undetected errors and will increase the portability of some Ada 83 software.
Library Package Bodies - In Ada 95, it is now illegal to supply a body to a package that does not require one. This change eliminates a class of subtle errors that can occur in Ada 83 where a package specification - but not the body - can be recompiled, and the error goes undetected. This will automatically be detected by Ada 95 compilers.
Numeric Error - In Ada 95, this exception has been changed to be a renaming of Constraint_Error. This is consistent with several official clarifications of the standard since 1983. This will, however, create a few situations where old code must be slightly modified to ensure that both exceptions are used consistently. An Ada 95 compiler will detect these situations automatically.

Beyond these major upward incompatibilities there are approximately 25 "pathological cases" that, while technically upward incompatibilities, are highly unlikely to occur in actual systems. Most organizations will never encounter these and they can safely be the worry of only the chief technical leader for the development project and not the PEO or PM.

The most important upward compatibility issues have been summarized on a one-page flyer that is available from AdaIC. More comprehensive details can be found in the document Ada 95 Upward Compatibility Guide V6.0. For more information, see Appendix A.

Risk Mitigation

Issue: What Should Be Done to Assess the Upward Compatibility of Existing Ada 83 Software?

One of the first actions that PEOs and PMs must take, even prior to first Ada 95 adoption, is to ensure that contractor/developers working on Ada 83 development activities produce software that is upwardly compatible with Ada 95. Existing Ada 83 code should also be evaluated.

Supplement the contractor/developer's internal peer reviews with a step to assess the upward compatibility of the project's software. (This review should consist of both manual and automated checks.)
Supplement formal Government software reviews with a step that reviews the status of all code for Ada 95 upward compatibility.

Emphasis in these reviews should be on the cost-effective placement of all Ada 83 software currently under review into three categories. (Most Ada 83 software will fall into categories 1 or 2.)

Ada 83/Ada 95

Compatible

2) Potentially Compatible - This software contains one or more simple incompatibilities but can be made Ada 83/Ada 95 compatible using a combination of automated and manual means.

3) Vendor or Application Specific Implementation - Software in this category is not Ada 95 compatible and it would not be cost effective to make this software Ada 83/Ada 95 compatible. For example, the software in question might make use of a vendor-specific run-time extension that has been replaced by a standard Ada 95 feature. Additionally, if the software is maintained by another organization, then it may remain Ada 83-specific until its owners migrate it to Ada 95. Software in this category will typically be scheduled for future re-engineering into Ada 95. Projects may encounter similar problems when porting Ada 83 code from vendor to vendor.

Eventually, projects moving to Ada 95 will begin to encounter a fourth category of software:

Ada 95 Only

Once the software under review has been categorized, the PEO and PM staff must then determine the disposition of "potentially compatible" software. If funds become available and the payback is judged sufficient, the software should be revised to make it upwardly compatible. Typically this will be done as part of the project that creates the "potentially compatible" Ada 83 software. However, if the current project is resource constrained, then the software should be scheduled for upgrade either as a separate project or as category 3, "Vendor or Application Specific Implementation".

Issue: How Do I Preserve My Investment in Software Written in Ada 83?

Ada 95 software needs no special effort to integrate, communicate with or call Ada 83 software. In most cases, by simply compiling the Ada 83 software along with new Ada 95 code, the Ada 83 code is immediately available for reuse in the new Ada 95 environment. PEOs and PMs should, therefore, ensure that the Ada 83 code is upwardly compatible (see the previous section). Ada 95 is not a new language, it is an incremental improvement on Ada 83.

Current evidence suggests that the majority of Ada 83 software will be upwardly compatible and will run unchanged when compiled by an Ada 95 compiler. Of the fraction that is incompatible, the majority can be made upwardly compatible by using simple automated tools such as text editors, shell scripts or ".com" and ".bat" files. PEOs and PMs should expect to continue using existing Ada 83 software both during and after their transition to Ada 95.

Issue: How Do I Maximize My Existing Investment in Ada 83 Tools?

PEOs and PMs should expect to make use of their existing investment in Ada 83 tools.

Continue to Use Ada 83 Tools Where Appropriate - During the process of Ada 95 adoption, PEOs and PMs must consider two kinds of software: Ada 83/Ada 95 compatible software and Ada 95 only software. Ada 83/Ada 95 compatible software is both upwardly and downwardly compatible and may be processed with both Ada 83 and Ada 95 tools. Ada 95 only software makes use of new Ada 95 features and may only be processed with Ada 95 tools. By maximizing the use of Ada 83/Ada 95 compatible software, PEOs and PMs can continue to make use of their existing Ada 83 tools during the transition period. As Ada 95 only software becomes dominant (i.e., as projects begin to make significant use of Ada 95), then projects can incrementally increase the Ada 95 toolsets and support.
Upgrade to "next version" Ada 95 tools -Since Ada 95 is an incremental upgrade and not a new language, tool vendors are building on their Ada 83 toolsets and experience. As a result, some tool vendors are offering Ada 95 capabilities in the new versions of their Ada 83 tools, making Ada 95 capabilities available under the standard maintenance license for the product. Therefore, projects that have paid for maintenance or support may be able to migrate to Ada 95 technology at a very low cost and with no loss of their investment in Ada 83 tools and environments. PEOs and PMs should contact tool vendors directly.

Issue: How Do I Preserve My Investment in Legacy Software that Was Not Written in Ada 83?

Ada 95 has been designed to help projects continue to get maximum use from their legacy software as they incrementally migrate to their new language, environment and/or platforms.

When transitioning from one language to another, it is necessary to preserve the organization's investment in software that was written in the previous language(s) - legacy software. PEOs and PMs are not expected to convert all of their legacy software to Ada 95, this is neither necessary nor cost effective. Developers should exploit Ada 95 features to interface their new Ada 95 software with the existing legacy code. This will permit incremental upgrades and enhancements to be written in Ada 95, minimizing cost and project risk.

Ada 95 developers have several kinds of support for interfacing with legacy code:

"Pragma Interface" has been enhanced in Ada 95 to allow developers greater control over the names generated by the programming environment.
Ada 95 now defines standard interfaces to C, FORTRAN, and COBOL within the core standard. These packages help developers to more quickly create interfaces to language-specific code by supplying standard types and conversion routines. Compilers may provide any of the three packages. If provided, they must conform to the standards definition.
Ada 95 also provides enhanced interfacing primitives to smooth the interface with other languages such as JOVIAL, CMS-2, and assembly languages.

PEOs and PMs should remember that it is still up to the vendors to provide support for each particular compiler's language calling conventions. To ensure that a project can interface with a specific language or compiler, project staff should check with their Ada compiler vendor.

To maximize the use of legacy code within new software development or re-engineering efforts, projects should:

Examine the legacy software to determine the areas of maximum stability.

Make these areas available to the new system through "wrappers". A wrapper is a layer of software (a binding) that allows the new Ada 95 code to call on the old software (regardless of the language it was written in or the platform on which it runs). This new software layer will allow the project to make use of the legacy system until it is replaced.
When it is cost effective, replace the old legacy code with new software; the wrapper layer serves to insulate the new Ada 95 code and ensure stability. The old legacy code can be replaced with new Ada 95 code with little or no disruption.

Ada 95, with its language interfacing features, is ideally positioned as a technology to help preserve a group's investment in legacy software and minimize the risk of transition.

For more information see the section on COTS, Legacy Software, and Multi-Language Software Development.

Previous Section - Tools and Environment Related Risks

Next Section - Technology Transfer Related Risks

Table of Contents

Chapter 3 Section 3 Upward Compatibility Risks