The potential effect of Ada on software engineering in the 1980's

ion One of the motivations for high order languages is to provide the programmer with abstractions which permit hi m to express his programs in a language closer to the domain of his application . For an extensive motivation fo r abstraction, see [7] . As do most other languages, Ada provides a mechanism for procedural abstraction . Parameterized procedures may be declared and invoked when needed with the actual parameters chosen from the context of the invocation . This is an abstraction which most programmers have learned to expect and which supports a rudimentary level o f decomposition . Ada also provides mechanisms for data abstraction through which new data types may be defined by th e programmer . This ability to define a type complements procedural abstraction in giving the programmer an ability to express his programs in the terms of his application domain . For instance, instead of treating the three states o f a system as an integer with values 1, 2, 3, the programmer may define a type STATE as an enumeration type wit h the more descriptive values READY, SUSPENDED, and EXECUTING . A complementary facility which supports abstraction is the ability to redefine (overload) operators . This facility enables the programmer to define operations such as "+" on the new data types he has defined so that he may express his programs in terms which would more likely be understood in the language of the application . Encapsulation Ada provides a means of encapsulating and naming a collection of entities in a package . The Ada package is a n extension of the intuitive concept of a package and provides the foundation for the logical organization of a program . The most obvious purpose of a package is to support modularization . There are three general ways in which this modularization may be employed . A package may provide a named collection of logically related objects to be used by other units . A package may also be used to group logically related subprograms which share internal data . Most importantly, a package may be used to define new types and the operations on those types complementin g the abstraction facilities to enable the programmer to extend the language, yet hide the implementation details o f the extension . For instance, suppose the application demanded the use of complex arithmetic . Instead of requiring the applications programmer to encode the real and imaginary components as separate variables, Ad a permits the definition of a new type COMPLEX and the ability to define operations such as "+," and PHAS E encapsulated into a package as shown in Figure 1 . The applications programmer can use these abstractions just a s though a complex type had been defined in the language . ACM SIGSOFT SOFTWARE ENGINEERING NOTES Vol 7 No 3, July 1982 Page 7 Information llidin g Through the use of packages and the limited and privatetype facilities, details of the implementation of interna l data structures may be hidden so that programmers may not "cleverly" exploit some implementation . Such cleve r exploitation has often resulted in perplexing errors when the internal detail of some data structure is changed . For instance, if a stack is implemented as an array, a clever programmer may improperly access any item in the stack . (This is improper because a stack is defined in such a way that only the top is accessible .) If the implementation i s later changed so that the stack is implemented as a linked list, the subprogram written by the "clever" programme r would no longer work . Such errors are extremely difficult to find because there is no obvious connection betwee n the changed data structure and the erroneous subprogram . Separation of Specification and Implementatio n The stack example illustrates how Ada permits the separation of the visible data structu re specification (stack) an d its allowed operations (push, pop) from the implementation representation (array, linked list) so that th e abstractions may not be violated . Separation of Logical and Physical Concern s The ability to define low level representation specifications permits the development of implementation specifi c code which might seem counter to good software engineering . However, when coupled with the informatio n hiding and abstraction facilities, representation'specifications permit the definition of "virtual" systems such as a virtual device handler in which only the specifics of the individual device type need be written . In this way the logical operations which must be performed may he conveniently separated from the low level physical concerns o f how a particular type is encoded .