Ada and sof t ware engi neeri ng

F. Terry Baker
Displaying soft ware engineering
techni ques in t he evolutionary
Ada programming language
F
or the first 20 years after
the electronic computer
was invented, developing
software for it was pri-
marily an ad hoc pro-
cess. However, programs somehow
got written generally because
capacities of the early machines were
so small that it was easy to remember
most of the details about any pro-
gram. In those rare cases where large
program systems were required, the
difficulties in getting them operational
are legendary.
During the 196Os, when larger
machines were introduced, organiza-
tions began to develop complex pro-
gram systems instead of simple in-
dividual programs. During this
period, software acquired a bad im-
age. The general perception was that
the software components of large
systems were too costly, always late
and usually inadequate. Also during
this period, the fundamental reason as
to why software development was so
difficult emerged. The reason was
simple: Software systems had become
so large and complex that they were
out of intellectual control. Neither
designers, developers, por managers
were able to interrelate all the details
for which they were responsible. Once
the reason was articulated, it became
obvious that the same principles of
organization and management, suc-
cessfully used in other fields, could be
applied to software development as
well.
Technical and management im-
provements were introduced at a rapid
rate. Both were based on partitioning
the process into smaller, better-
defined units and organizing them in-
to standard structures. The software
development process as a whole was
divided into a number of phases. Each
phase could be comprehended and
managed as a unit with well-specified
interfaces to its predecessors and suc-
cessors. Software systems were them-
selves partitioned into subsystems and
procedures. Furthermore, E. W.
Dijkstr noted that even the design of
individual procedures could be struc-
tured to simplify the process and to
expand the scope of intellectual con-
trol of an individual programmer.
Similar ideas were applied to data
structuring by C.A.R. Hoare. Struc-
turing of software systems based on
principles of information hiding and
encapsulation was recommended by
D. L. Parnas. By the mid-70s, these
and other ideas were tested and ac-
cepted well enough to talk for the fiist
time about software development as
an engineering discipline. Thus, the
term software engineering
emerged.
Software engineering
There is no universally accepted
definition of software engineering.
But, if weaccept that engineering in
general is the application of scientific
principles and methods to solve real
world problems, it follows that soft-
ware engineering is the application of
computer science principles and
methods to solve real world computa-
tional problems. Some of these prin-
ciples and methods have been in ex-
istence for years, others have been
identified more recently. Let us begin
by summarizing some of the key ideas
which designers and developers
adopted even before software
engineering was an identifiable
discipline.
Two of these key ideas are structur-
ing and modularizing. Since wecan-
not maintain intellectual control over
monolithic systems, we must ap-
proach them by the divide and con-
quer principle; they must be de-
signed and developed as structures of
smaller units. A good structured
design should ensure that each unit
performs a single function or supports
a single major unit of data. These
modules are organized into structures
in such a way that each depends on
other modules as little as possible. In
order to minimize misunderstandings
over how to manipulate data, a data
object should be able to assume any
of a set of prescribed values but be
manipulated only by a set of pre-
scribed operations. This is the idea of
strong typing. Finally when wecon-
struct large systems, it has proved
more effective to build them top-
down, by beginning with the software
units which govern the flow of con-
trol and data, and working toward the
units which provide the detailed func-
tions and operations on data.
These ideas were the foundation of
software engineering. However other
ideas have proved equally valuable.
Some of the most important are in-
formation hiding, encapsulation,
separation of concerns, abstraction,
verification, and reusability.
The advent of Ada
Unfortunately, the languages of the
mid- 1970s were generally inadequate
to support the emerging principles of
software engineering. The languages
used most heavily, Fortran and
COBOL, were older languages with
almost no structuring capability.
Newer languages, such as PL/l,
Algol, J OVIAL, C and Pascal, sup-
ported control structures and data
structures well but were inadequate
for all but the lowest-level structures
in a software program.
The need to support software
engineering principles coincided with
the realization by the U.S. Depart-
ment of Defense (DoD) that the
systems (it was buying) desperately
needed a standard language suited for
developing large-scale, real-time,
embedded systems. (Embedded
systems are those which are com-
ponents of other systems; an engine
FEBRUARY 1988 0278-664818810002-0009$01 .OO 0 1988 I EEE 9
structure would have to use the
operations provided by the encap-
sulated units.
Ada provides a useful means for
encapsulation, termed a package. It
enables us to place together a group
of related procedures and data to ex-
plicitly determine what aspects of the
collection will be visible to a user
who needs them; and to identify what
aspects will be hidden from the
user. Fig. 3 illustrates a stack package
based on our earlier approach.
Abstraction and verification
The specification part of an Ada
package, illustrated in the preceding
section, contains the interface infor-
mation needed by a user of the
package. In other words, it tells a
user what information in what form
is needed by the package, the names
of the operations it performs, and
what will be returned from those
operations. While the names of the
operations may suggest what they do,
users ultimately need a specification
of the behavior of the operations as
well. We can do this by providing
users with an abstraction of the
behavior. Although the real behavior
may be quite complex, wecan usual-
ly find a simpler way to describe it
which gives users everything they
need to know to use it.
In this case, suppose for the mo-
ment that we have no idea of the
behavior expected from a stack.
However, we are familiar with the
concept of a list. (A list is an ordered
sequence of elements. Wecan add an
element to its front, remove an ele-
ment from its front, and test if there
are any elements in it.) Figure 4 uses
comments embedded in the package
construct to give a complete
specification for the bchavior of the
stack by using the list as an abstract
model.
Now, if wewant to know exactly
what happens in any given situation,
we can refer to this model-based
specification. Furthermore, when the
design for the package body is com-
plete, wecan use this specification to
verify that the design is correct. In
other words, we can use formal
methods to rigorously compare the
design to the specification. Thus we
ensure that the design performs
precisely as the specification claims
it does under all circumstances.
Reusability
At this point, we have an integer
stack which can hold up to 100
elements. This may suffice for our
Fi g. 3. An Encapsulated Ada Integer Stack: Whi l e the data and operations are i den-
ti cal t o those in Fig. 2, they have been encapsulated i nto a package.
Fi g. 4. An Ada Integer Stack with speci fi cati on: Abstract model speci fi cati ons have
been added t o the package usi ng a l i st model for the stack.
FEBRUARY 1 988 11
immediate needs, but having put in-
to it the effort to incorporate soft-
ware engineering principles, we
would like to make it reusable. To do
this, we would like to remove the
limitations on the type of elements
which can be stacked and the fixed
size limit.
To support generalization and
reusability, Ada supports the concept
of generic program units. By identi-
fying in the specification of the pro-
gram unit which parameters are to be
considered to be changeable at com-
pile time, wecan enable users to take
a general-purpose unit and tailor it to
their needs. In our case, wemake the
element type and the stack size limit
into so-called generic parameters.
Thus, our stack example becomes
that shown in Fig. 5.
The main changes wecan seein the
package are the addition of the
generic clause in front of the earlier
version, and the replacement of the
specific type and value previously
used with the generic parameters. The
use of the keyword private with the
Element type declaration indicates
that a user can provide for virtually
any type of elements to be stacked.
The value of 50 which is included in
the declaration of MaxSize is a
default value which will apply if no
maximum is declared by a user. The
comments which specify the behavior
of the operations have also been
changed to reflect the increased
generality, as has the stack packages
identifier.
To use such a generic package, a
user must instantiate it for a given
combination of Element and Max-
Size. This is done by a declaration
such as:
package MyStack i s new
General S tack( E 1ementType =>
Character, MaxSize =>10);
which would create a stack package
capable of stacking up to ten
characters. Instantiation takes the
generic package template and creates
from it a specific package specialized
to the users needs. The creator of a
generic package does need to ensure
that the package supports the
generality its specification proclaims.
However, the mechanics of turning
a specific package into a generic one
are actually quite simple.
Summary
We have taken some real design
challenges of incorporating good
software engineering principles into
a software unit and shown how they
generic
-Generic Parameters
type ElementType is private;
MaxSize: in Integer : =50;
package Generalstack is
-Abstract Model Data
- type StackList is list of ElementType;
- abstract model type StackType is
- record
- StackData: StackList;
-
- end record;
-Type Declarations
Membercount: Integer range O..MaxSize : =O;
type StackType is private;
type StatusValues is (empty, full, OK);
-Operations
- Push Element onto StackName
-
-
If StackName.MemberCount =MaxSize, return Status : =full;
Else add Element to the head of StackName.StackData, add one to
StackName.MemberCount and return Status : =OK.
StackName: in out StackType; Status: out StatusValues);
-Pop StackName into Element
- If StackName.MemberCount =0, then return Status :=empty;
- Else remove the head of StackName.StackData,return it as Element,
procedure Push(E1ement: in ElementType;
subtract one from StackName.MemberCount and return Status :=OK.
procedure Pop(StackName: in out StackType;
Element: out Element Type; Status: out StatusValues);
private
-Stack Representation
type StackArray is array(1 ..loo) of ElementType;
type StackType is
record
end record;
StackData: StackArray;
Stacklndex: Integer range O..MaxSize : =0;
end Generalstack;
Fig. 5. A Generic Ada Stack: By providing an element type and a maximum stack size,
a user may create a tailored stack package from this generic one.
can be met through use of standard
Ada constructs. Many such problems
are difficult to solve using earlier
languages. At best they are dealt with
stylistic conventions which may make
communication among designers and
programmers easier, but do nothing
to enable language processors to find
errors and inconsistencies. As was
implied earlier, when software
systems grow in size, it is exactly such
problems of scale which lead us to
lose intellectual control over design
and development.
While Ada addresses these and
other software engineering-related
problems, it is not a panacea.
Regardless of the power of a
language, the biggest challenges fac-
ing software engineers are those of
selecting the most appropriate struc-
ture and components for a system.
While a good language helps in recor-
ding these decisions, it does not make
them for us.
Read more about i t
J . G. P. Barnes, Programming in
Ada, 2nd ed. Reading, MA:
Addison-Wesley, 1984.
G. Booch, Software Engineering
With Ada, 2nd ed. New York:
Benjamin/Cummings, 1987.
0.-J . Dahl, E. W. Dijkstra, and
C. A. R. Hoare, Structured Pro-
gramming. New York: Academic,
1972.
D. L. Parnas, On the criteria to
be used in decomposing systems in-
to modules, Communications of
the ACM, vol. 15, no. 12, pp.
1053-1058, Dec. 1972.
D. C. St. Clair, Ada: a new pro-
gramming language, IEEE
Potentials, vol. 4, no. 4, pp. 26-29,
Oct. 1985.
About the author
F. Terry Baker is with the Federal
Systems Division of the IBM Cor-
poration in Bethesda, Maryland 0
12 IEEE POTENTIALS