High Integrity Ada in a UML and C world

1. High Integrity Ada in a UML and C world Peter Amey, Neil White Presented by Liping Cai

2. Overview • The disciplined use of UML and UML tools • Validation of the Ada Model • The auto-generation of semantically-equivalent c source code • Deliverable and Traceability • Conclusions

3. The Disciplined use of UML • Define a Design Approach • Use INFORMED to design (part of ) system • Capture the design in UML, including component contracts (in the form of SPARK annotations); • Use SPARK Ada semantics to get early validation of the (partial) system design • Complete components, using SPARK Ada semantics to ensure contracts are met.

4. The Disciplined use of UML • Define semantics • An ambiguous design is worse than no design • One-to-one mapping between the statics aspects of our UML model and SPARK Ada. • Balance static and behavioral aspects. • Extending UML with Stereotypes • Sterotypes allow new UML elements to de defined. • Tagged values are simple “name=value” pairs that can be added to any element to give extra information • Constraints are semantic restrictions can clearly represented by a text expression.

5. The Disciplined use of UML • Strenthening Contracts • Extended UML model to include SPARK annotations and used these to tighten the specification of the operation contracts. • Example

6. The Disciplined use of UML • Tool Support and SPARK Ada Code Generation • Since an unambiguous mapping set up between UML and SPARK Ada code, it is easy to generate a the SPARK Ada code from the UML model and generate a UML model from SPARK Ada Code. • When generating code, generate code structure, not behavior. • Physically enter the bodies of SPARK subprogram directly into UML model to keep everything in one place.

7. package Colour ADT is type RGB Value is range 0 .. 500; type Colour is private; procedure Swap(A : in out Colour; B : in out Colour); --# derives A from B & B from A ; -- information flow contract -- Other operations here ... private type Colour Components is ( Red, Green, Blue); type Colour is array (Colour Components) of RGB Value; end Colour ADT; package body Colour ADT is procedure Swap(A : in out Colour; B : in out Colour); is Temp : Colour; begin -- hand-written implementation Temp := A; A := B; B := Temp; end Swap; Other operations here ... end Colour ADT;

8. Validation of the Ada Model • Static Analysis • The program is well-formed • The program actually is a correct implementation of its specification • Steps • The custom templates produce a skeletal framework for the design expressed in UML. • This framework is ensured to be syntactically legal SPARK. • The generated packages and subprogram specifications are annotated with a chosen level of SPARK annotations obtained from information embedded in the UML model. • Use SPARK examiner repeatedly to check it against the embedded annotation.

9. Validation of the Ada Model • Formal Verification • Provide formal pre and post-condition predicates for the operations contained in UML and use the proof capabilities of the examiner to show that the UML specification and intermediate SPARK Ada model correspond. • Dynamic testing • Host-based testing: Direct compilation of th eSPARK model with an Ada compiler • Target-based testing: generating C, compiling and testing it.

10. Generating C • Involves more than just translating Ada statements to C. • Need to add run-time checks and exception raising • Need to consider evaluation order dependencies and parameter passing dependencies • A form of a Ada compiler: AdaMagic compiler • Translation is very transparent and traceable • Generated code meets standards

12. Generating C • The flat name space requires that the SPARK Ada package name is used as a prefix; • All types are equally visible, because C has no concept of a private type; • The constrained type RGB Value is now an unsigned short; • The array index type is an enumeration in the Ada, but needs to be converted to a natural here; • The exported parameters are passed as pointers; • The array assignments in the body of Swap have become lower level memory moves, because C doesn’t support whole-array assignment.

13. Deliverables and Traceability • A UML model; • An intermediate SPARK Ada model with evidence that it is well-formed and free from run-time errors. • Proof-based evidence that the SPARK implements the required behaviour. • Host testing results; • Target-based test results; • Object code verification based on tracing the SPARK to the C and the C to the object code; • “Linear” documentation generated from the UML model. • Deliverable C source code which is easily traceable to the intermediate SPARK model.

14. Conclusion • It is possible to reconcile diverse expectations. • The crucial and novel elments: • The use of Ada as an exact intermediate representation between UML and C. • The recognition that it is much easier to generate “safe” and accurate C from a semantically exact and error-free SPARK model than it is to write C and then demonstrate that it has the necessary properties of safety and accuracy. • Ada can be seen as a compliable design language rather than just a plain and simple programming language.