SPARK (programming language)

From Wikipedia, the free encyclopedia

SPARK is a secure, formally-defined programming language designed to support the development of software used in applications where correct operation is vital either for reasons of safety or business integrity. There are versions of SPARK based on Ada 83 and Ada 95. The latest revision of the language, RavenSPARK, includes the Ravenscar Tasking Profile to support concurrency in high integrity applications. The formal, unambiguous definition of SPARK allows and encourages a variety of static analysis techniques to be applied to SPARK source code.

1 Technical overview
2 Tool support
3 Annotation examples
4 Verification Conditions
5 History
6 See also
7 References
8 External links

[edit] Technical overview

SPARK exploits the strengths of Ada while eliminating all its potential ambiguities and insecurities. A SPARK program has a precise meaning which is unaffected by the choice of Ada compiler and can never be erroneous (erroneous in the meaning as defined in the Ada Reference Manual). These desirable goals are achieved partly by omitting some of Ada's more problematic features (such as unrestricted tasking) and partly by introducing annotations or "formal comments" to capture the code designer's intentions.

The combination of these approaches allows SPARK to meet its design objectives which are:

rigorous definition
simple semantics
security
expressive power
verifiability
bounded resource requirements.

As SPARK is an annotated subset of Ada, programs written in SPARK can be compiled by any Ada compiler.

Subset of Ada means that not all Ada features may be used.

Annotated means that certain annotations in form of Ada comments (i.e. ignored by the Ada compiler) are evaluated by an additional tool called the SPARK Examiner.

[edit] Tool support

Praxis SPARK Toolset

Developer:	Praxis High Integrity Systems
Latest release:	7.31 / April 2006
OS:	GNU/Linux, MS Windows, OpenVMS, Solaris, Mac OS X
Use:	Programming language
License:	The Language Definition and Formal Semantics are freely available, with changes controlled by Praxis HIS. The SPARK Toolset is commercially licensed, with a limited version included in the book by John Barnes and available for download via http://www.sparkada.com
Website:	http://www.sparkada.com/

The SPARK Examiner (part of the SPARK Toolset available from Praxis High Integrity Systems) performs two kinds of static analysis. The first, made up of language conformance checks and flow analysis, checks that the program is "well-formed" and is consistent with the design information included in its annotations. This stage is extremely straightforward and can be readily incorporated into the coding phase of the development process. After these checks the source is known to be free from erroneous behaviour and free from conditional and unconditional data flow errors (e.g. use of uninitialised data) on a system-wide basis (including abstract state in package bodies).

The second, optional, kind of analysis is verification: showing by proof that the SPARK program has certain specified properties. The most straightforward is a proof that the code is exception free; this adds the Constraint_Error exception to the list of possible errors eliminated by SPARK. Proof can also be used to demonstrate, unequivocally, that the code maintains important safety or security properties or even to show its complete conformance with some suitable specification.

Full information on the static analysis techniques that may be performed using the SPARK Toolset is available online [1].

[edit] Annotation examples

Consider the Ada subprogram specification below:

procedure Increment (X : in out Counter_Type);

What does this subprogram actually do? In pure Ada, it could do virtually anything — it might increment the X by one or one thousand; or it might set some global counter to X and return the original value of the counter in X; or it might do absolutely nothing with X at all.

With SPARK, annotations are added to the code to provide additional information regarding what a subprogram actually does. For example, we may alter the above specification to say:

procedure Increment (X : in out Counter_Type);
--# derives X from X;

procedure Increment (X : in out Counter_Type);
--# global Count;
--# derives
--#   Count from Count, X &
--#   X from ;

This first of these specifications tells us that the Increment procedure does not update or read from any global variables and that the only data item used in calculating the new value of X is X itself. The second set of annotations tells us that Increment will use some global variable called "Count" in the same package as Increment and that the exported value of Count is dependent on the imported values of Count and X, but that exported value of X does not depend on any variables at all — it will be derived simply from constant data.

If the Examiner is then run on the specification and corresponding body of a subprogram, it will analyse the body of the subprogram to build up a model of the information flow. This model is then compared against that which has been specified by the annotations and any discrepancies reported to the user.

We can further extend these specifications by asserting various properties that either need to hold when a subprogram is called (preconditions) or that will hold once execution of the subprogram has completed (postconditions). For example, we could say the following:

procedure Increment (X : in out Counter_Type);
--# derives X from X;
--# pre X < Counter_Type'Last;
--# post X = X~ + 1;

This specification now says that not only is X only derived from itself, but that before Increment is called X must be strictly less than the last possible value of its type and that afterwards X will be equal to the initial value of X plus one — no more and no less.

[edit] Verification Conditions

The Examiner can be requested to generate a set of Verification Conditions or VCs. VCs are used to attempt to establish certain properties hold for a given subprogram. At a minimum, the Examiner will generate VCs attempting to establish that the following run-time errors cannot occur within a subprogram:

array index out of range
type range violation
division by zero
numerical overflow.

If a postcondition is added to the specification, the Examiner will also generate VCs that require the user to show that the postcondition will hold for all possible paths through the subprogram.

Discharging these proof obligations is performed using the SPADE Simplifier (an automated theorem prover) and the SPADE Proof Checker (a manual theorem prover, used for those VCs too thorny for the Simplifier to automatically discharge).

[edit] History

The first version of SPARK (based on Ada 83) was produced at the University of Southampton (with UK Ministry of Defence sponsorship) by Bernard Carré and Trevor Jennings. Subsequently the language was progressively extended and refined, first by Program Validation Limited and then by Praxis Critical Systems Limited. In 2004, Praxis Critical Systems Limited changed name to Praxis High Integrity Systems Limited.