Chapter 3 Section 6
COTS, Legacy Software, and Multi-Language Development
Ada 95 will allow PEOs and PMs to reduce project risk by incorporating
existing software of many kinds: reusable software written in both Ada and
other languages, COTS and GOTS software written in many languages, and a
project's existing legacy code. This will increase quality and reliability and
decrease project cost.
Of the many improvements that Ada 95 offers over Ada 83, Ada 95's ability to
work more easily with other programming languages is possibly the most
beneficial on a daily basis. Software development efforts in the next few
years will continue to demonstrate the recent trend toward the integration and
interfacing of multiple kinds of software, including legacy code from previous
development efforts, bindings to new COTS software, and the incorporation of
reusable software components. Invariably, this software will be written in
multiple languages, causing the modern developer to rely heavily on Ada's
ability to interface with other languages.
COTS BINDINGS
PEOs and PMs should initiate an effort to track their project's
current support services (e.g., database, GUI or operating system) and the
bindings that these services require. This information and the bindings should
be supplied to the contractor as a part of the desired development
environment.
Work is already under way or completed in the following binding categories:
- Graphical User Interfaces - Ada 95 bindings to Microsoft Windows
and Windows NT are already available from both Aetech and RR Software. The
Ada 95 Revision Team will be producing a set of standard bindings to the X-
Window System (X11R6) as a part of the Ada 95 revision effort. Work is under
way by Objective Systems Interface to create a set of Ada 95 bindings to the
new Fresco tool kit found in X11R6.
- Operating Systems - The Ada 95 Revision Team will be revising the
set of standard bindings to POSIX as a part of the Ada 95 revision effort. The
GNAT project is producing a set of bindings to the Mach operating system.
- Object Management - Objective Systems Interface is working to
create a set of Ada 95 bindings to the Object Management Group's Common Object
Request Broker Architecture (CORBA) specification, which will allow
interoperation among objects written in many languages.
- SQL Database Language - The Software Engineering Institute is
working to create Ada 95 bindings to the SQL2 language.
Since Ada 95 provides additional facilities that make bindings simpler and
easier to build, a large effort is under way to upgrade existing bindings and
create new ones in Ada 95. Some of these efforts have been directly sponsored
by the Ada 95 Project Office as a part of their language update. Other efforts
are the work of compiler vendors, third-party vendors, or user groups. Many of
these bindings will be available with Ada 95 compilers, while others will be
produced and sold or given away shortly thereafter. To gain these reuse
benefits, most projects will want to be users of these bindings, since
significant investment may be required in the creation effort.
The use of such common Ada 95 bindings will reduce project risk by ensuring
access to large amounts of COTS software. Reuse of COTS software not only
reduces risk but also increases the software's portability and reliability,
creating a positive net effect on the project's cost and schedule.
The Ada Information Clearinghouse publishes a handbook on available Ada
bindings and regularly updates its database of such products. ACM SIGAda's
Ada Bindings Working Group
(ABWG) is the primary source for technical interchange on bindings issues.
For more information, see Appendix A.
Multi-Language Software Development
PEOs and PMs should ensure that their development staff exploit Ada
95's improved abilities to interface with software written in multiple
languages. This will allow for the reuse of existing legacy software and COTS
software - thereby reducing project cost, accelerating the schedule, and
lowering risk.
Among the technological risks that must be overcome in supporting multiple
language development is getting two specific implementations of two different
languages to talk together, and preventing the loss of portability that
accompanies most solutions. Ada 95 reduces these risks by defining standard
interfaces to C, FORTRAN and COBOL within the language and by providing
enhanced primitives and support packages to smooth interfacing with other
languages. These newly redefined primitives capture 10 years of experience in
mixed language development and standardize the best practices of the Ada
industry.
Ada 95 directly supports the use of Ada routines as supporting
elements that can be called by other programming languages. It is now
possible to write single Ada 95 subprograms that may be called from other
languages.
This feature lowers the risk when Ada is used to provide specific
extended functionality to COTS products. Ada 83 was easily used to glue
together other COTS products and to call them. Ada 95 can now also be used to
create the supporting routines that tailor an application framework. This fits
easily into the model defined by 4GLs or by languages such as Visual Basic.
For many PEOs and PMs, portability, vendor independence, and
interoperability goals will be achieved through the use of "open systems"
standards such as the Defense Information Systems Agency (DISA) Technical
Architecture For Information Management (TAFIM). Achieving these goals will
lower risk, cost, and schedule for projects.
Ada 95 provides excellent technical support for open systems. The enhanced Ada
95 support for making use of bindings to other language Application
Programming Interfaces (APIs), and the existing strong support in Ada for
separating the interface to services from their implementation, contribute to
Ada's ability to support the open systems vision. Ada 95 will make it easy for
projects that wish to support "open systems" to do so.
To effectively use Ada 95 in an "open systems" effort, PM Offices
should determine the project's bindings needs. These needed bindings
should be mapped to the contents of the TAFIM and to the project's use of open
systems services.
The term "open systems" has become one of the more popular buzzwords of the 1990s,
and it has come to mean many things to many people. In this context, it is used to indicate
the use, by software developers, of accepted, standard interfaces to software services
(e.g., GUIs, operating systems and databases). This use helps to ensure that the project
software is portable and modifiable, because it is built using standard services. The
underlying services may be procured from more than one vendor, each of whom meets the
interface; may be changed without disrupting the software project; and allow for the
separation of project-specific software from general support services.
Each set of system services (e.g., GUI or operating system) is packaged
together. The project's software accesses this packaged set of services
through an API. If the set of services is written in a different programming
language, then an Ada binding to the API is needed to access the
services.
For more information about preserving one's investment in legacy software,
see the section on Upward Compatibility.
Previous Section - Software Development Methodologies
Next Section - The Adoption Process and Personnel Risks
Table of Contents