THE ADA COMPUTER PROGRAMMING LANGUAGE

1. ORIGINS OF ADA

In the early 1970s the US Department of Defence (probably the largest user of computers in the world), conducted a study into the cost of developing and maintaining programs. During this study it emerged that over 450 languages were in use to develop software for the department. As a result (and in response to the software crisis) the department set up a working group (c1975) to identify a single programming language that would meet all the department's software needs. The aim was standardise on a single language, particularly with respect to real-time embedded systems. However, no existing language met the desired requirements. Consequently, to further its ends the Department organised an international design competition to develop a programming language that would meet the requirements. This was won by a group from CII-Honeywell Bull of France headed by Jean Ichbiah. Ichbiah's language was called "Green", however, the language in its final form was called Ada after Ada, Countess of Lovelace, who worked on Babbage's Analytical Engine and is considered by many to be the first programmer.

Ada was originally standardised by ANSI (American National Standards Institute) in 1983. ISO (International Standards Organisation) released an equivalent standard in 1987. Ada was recently revised to add some new capabilities (by a small team led by Tucker Taft); this revision is called `Ada 9X' or `Ada 95'.

Ada continues to receive support from the US Department of Defence, and as long as this continues its wide usage will be assured. There is U.S. legislation mandating Ada's use in Department of Defence software development projects (with various exceptions and waiver provisions). The strongest criticism of the language is Tony Hoare's ACM Turing Lecture entitled "The Emperor's Old Clothes" (Hoare 1981), in which he suggests that Ada is far too big and complex. The designers of Ada have subsequently retorted with a statement to the effect that real world problems are big and complex!

2. ANATOMY OF AN ADA PROGRAM

Below is a frame work for simple Ada programs.

with ... ;
use ... ;

procedure PROGRAM_NAME is
        <DATA_DECLARATION>
begin
        <CODE STATEMENT>
end PROGRAM_NAME;

Bold text indicates reserved words that have a special meaning. Note that when writing your own programs it is not necessary to emphasis different words in this way.

In Ada a program consists of a procedure. The procedure commences with the reserved word procedure and ends with the reserved word end. Good programming practice dictates that the end word be followed by a repeat of the procedure name. Statements are generally terminated by a semicolon (;). The with reserved word is used to introduce the library files, referred to as packages in Ada, to be "linked in". The use reserved word tells the compiler to search in the library files for any special program statements that we might want to include in our source code, for example to achieve terminal input and output. The procedure itself comprises two parts - a head and a body. The head contains details of the data declarations required by the procedure, and the body the code statements.

3. EXAMPLE PROBLEM SUM AND PRODUCT

3.1. Requirements

To build a program that takes two integers (X and Y) as input, and outputs their sum and product.

3.2 Design

We will commence the design process with a top down analysis of the problem. To this end we can identify the operations illustrated by the following hierarchical problem breakdown.

At the highest level we have a single top level operation whose purpose is to combine the lower level procedures. At the second level (level 2) we can identify three distinct operations:

1. Input values for X and Y
2. Calculate and output sum
3. Calculate and output procedure

A single procedure will be sufficient to implement these operations. We will call the procedure SUM_AND_PROD. It is usually useful to list the procedures that a program is going to use together with a brief description of what each procedure is intended to accomplish and the nature of the data items to be used. The latter is best achieved using a tabular format. Thus:

1. SUM_AND_PROD (top level procedure): Input data, and calculate and output sum.

   NAME	USAGE	TYPE	RANGE
   X_VALUE	Input argument	INTEGER	Default
   Y_VALUE	Input argument	INTEGER	Default

Having identified the operations required to address a problem and the nature of the procedures the next stage is to design the algorithms whereby the procedures can be realised. We will do this using a Nassi-Shneiderman chart. An appropriate algorithm is presented in the N-S chart to the right. This design includes two variables X_VALUE and Y_VALUE. Both are integers. Note, in the N-S chart the procedure is entered at the top and exited from the bottom. The design comprises four distinct operations.

3.3. Implementation

Implementation is a direct, uncomplicated, encoding of the design given in the N-S chart.

-- SUM AND PRODUCT
-- 15 August 1997
-- Frans Coenen
-- Dept Computer Science, University of Liverpool

with CS_IO;
use CS_IO;

procedure SUM_AND_PROD is
        X_VALUE, Y_VALUE: INTEGER;
begin
        PUT_LINE("Give two whole numbers! ");
        GET(X_VALUE);
        GET(Y_VALUE);
-- Calculate sum
        PUT("The sum of the numbers is: ");
        PUT(X_VALUE+Y_VALUE);
        NEW_LINE;
-- Calculate product
        PUT("The product of the numbers is: ");
        PUT(X_VALUE*Y_VALUE);
        NEW_LINE;
end SUM_AND_PROD;

With respect to the implementation given above the following should be noted:

• The compound symbol -- (double hyphen) introduces a comment. Everything written after it on the same line is ignored by the compiler. It is good practice to include a (commented) header at the top of our program giving at least the program's title (indicating what it does), the authors name and date (in some cases it is also appropriate to give a version number).
• The code uses the library package CS_IO (Computer Science Input Output). This is a non-standard package developed within the department of Computer Science at the University of Liverpool. The package contains library procedures to support (amongst other things) numeric input and output from and to the screen (terminal). For example GET (get input from the screen) and PUT (output to the screen).
• The declaration section defines the data items to be used by the program (the ingredients). In the above case we have two integers X_VALUE and Y_VALUE. Note that it is considered poor programming practice to use single letter variable names as it is often unclear as to what a single letter name represents.
• Ada data item names must acknowledge the following rules:
  • A name comprises a sequence of characters
  • The number of characters can be at least 200 (according to the standard), although a sensible maximum is in the region of 32.
  • A name must always commence with an alphabetic character
  • Remaining characters can be alpha-numeric characters or the underscore character with the provisos that:
    • More than one underscore character cannot be used in sequence.
    • A name cannot end on an underscore character.
  • Unlike some other languages (e.g. Algol) blank spaces are not allowed.
• Always use clear names within a program and do not be afraid to use long names.
• The bracketed data following the PUT_LINE, GET and PUT procedure names are parameters or arguments for those procedure. Note: Ada procedures can have zero, one or more parameters.
• Text contained between double quotes is referred to as a text string. When used as a parameter for PUT_LINE (or PUT) it will appear on the screen in exactly the same way as it is included in the source code (but without the quotes).
• PUT_LINE outputs its parameter, which must be a text string, to the screen and includes a carriage return (new line) at the end.
• In the case of GET the parameter is assigned a value (obtained from the screen). Note that before the input can be "got" we must first type it to the screen via the keyboard.
• PUT outputs its parameter to the screen, but (unlike PUT_LINE) does not include a carriage return at the end of the output. The parameter my be a text string or an expression. In the case of the latter this is first evaluated and the result produced as output.
• NEW_LINE (which has no parameters) causes a new line to be started in the output to the screen.
• We should include program comments in our code (preceded by the comment symbol, '--'). Comments facilitate program understandability. It is considered bad practice not to use comments, however, they should not be over-used as this causes a program to become cluttered.
• The method of organising the appearance of a program by indenting parts of the text also facilitates ease of reading. You should always use indenting.
  

  3.4. Testing

  TEST CASE		EXPECTED RESULT
  X_VALUE	Y_VALUE	SUM	PRODUCT
  0	0	0	0
  0	12	12	0
  0	-12	-12	0
  4	0	4	0
  4	12	16	48
  4	-12	-8	-48
  -4	0	-4	0
  -4	12	8	-48
  -4	-12	-16	48

  The above is a fairly straightforward procedure and thus very little testing is required. Given an arithmetic statement it is always a good idea to test the effect that negative, positive and zero sample values will have on the outcome. In this case there are two numeric inputs, we should therefore test every negative, positive and zero combination. We do this by generating a set of test cases, nine in total (3x3=9), as illustrated in the table to the right. The actual values (4 and 12) have been chosen simply because they seem to represent realistic inputs (in the absence of any information to the contrary).

  
  

  Example Problem Sum and Product Report.

  
  

  4. COMPILING ADA PROGRAMS

  Given the above source code we must (1) compile it, and (2) link it, to produce a load module (i.e. an executable program). The source code must be contained in a file with the postfix .ada. In addition it is normal practice to name the file with the same name as the (top level) procedure name used in the program, thus sum_and_prod.ada would be a suitable name for the above source code. To invoke the Ada compiler we issue the following command:

  $ ICC sum_and_prod.ada

  The ICC command triggers both compilation and linking therefore we do not need to issue a separate "link" command. ICC produces several files:

  1. A load module or executable file with the same name a the procedure name (e.g. sum_and_prod).
  2. A listing file (.lst) which contains details of errors encountered during compilation (e.g. sum_and_prod.lst).
  3. A debug archive file (.dar) to allow for the application of "debugging" tools (e.g. sum_and_prod.dar).
  4. A file called Alink.opt which contains details of the linking operation.
  5. A set of object files (.o) and other compilation data files contained in a directory called Adadir.
  
  

  ---

  Created and maintained by Frans Coenen. Last updated 11 October 1999