Modeling SPARK Systems with UML Xavier Sautejeau Sig

Modeling SPARK Systems with UML Xavier Sautejeau Sig. Ada’ 05 © Sodius

Contents • Rationale • Mapping Overview • Tool support • Conclusion 2

Rationale • SPARK Overview • UML Overview • Why is a mapping useful ? Rationale - Mapping Overview - Tool Support - Conclusion 3

SPARK Overview • Description – Programming language • Safe(r) Ada subset • Comments with added-value safety semantics • Usage – Save money on defect detection – « Correctness by construction » • Further info – www. praxis-his. com/sparkada Rationale - Mapping Overview - Tool Support - Conclusion 4

UML Overview • Description – (Mainly) graphical notation • Usage – Model OO aspects of systems • Further info – www. uml. org Rationale - Mapping Overview - Tool Support - Conclusion 5

Why is a mapping useful ? • Combining perspectives – OO focus – Safety focus Better architecture • Smoothening transitions between development phases – Automate UML to SPARK transformation through code generation rules Rationale - Mapping Overview - Tool Support - Conclusion 6

Mapping overview • • Comparing UML and SPARK Mapping individual elements Mapping structure Evaluation criteria Rationale - Mapping Overview - Tool Support - Conclusion 7

Comparing UML and SPARK similarities • Domain – Represent SW development concepts and their relations • Composition rules – SPARK Ada based on a formal grammar • Defines the authorized combinations of syntactical elements – UML based on a metamodel • Defines the authorized combinations of modeling concepts Rationale - Mapping Overview - Tool Support - Conclusion 8

Comparing UML and SPARK differences • Goal – UML => modeling activities – SPARK => defect prevention • Audience – UML => humans – SPARK => computer Rationale - Mapping Overview - Tool Support - Conclusion 9

Mapping individual elements • "Natural" mapping of main concepts • Customizing UML via profiles • Enhancing the fit Rationale - Mapping Overview - Tool Support - Conclusion 10

Mapping elements "Natural" mapping SPARK construct UML model element Package Class | Package Operation Variable Attribute Annotation Constraint | Dependency | Tagged. Value | Stereotype Some possible equivalences from SPARK to UML Rationale - Mapping Overview - Tool Support - Conclusion 11

Mapping elements Customizing UML via profiles • Native UML not rich enough to represent SPARK systems • Profile – set of stereotypes, tagged values and constraints – To bring additional descriptive power to the UML notation Rationale - Mapping Overview - Tool Support - Conclusion 12

Mapping elements Customizing UML via profiles Profile element(s) [kind] SPARK construct UML construct <<Proof>> [stereotype] Proof type | Proof Operation Type | Operation Own. Mode [tagged value, Enum (None, In, Out)] Own variable mode Attribute global. Spec, global. Body [tagged value, String] Global annotation(s) Operation <<Global>> [stereotype] Global annotation(s) Dependency ( from operation to attribute) SPARK Profile Candidate Elements Rationale - Mapping Overview - Tool Support - Conclusion 13

Mapping elements Enhancing the fit Stack class operations properties A UML Model of the Stack class Rationale - Mapping Overview - Tool Support - Conclusion 14

Mapping elements Enhancing the fit Implicit “this” parameter Stack class operations passing mode in properties UML can only translate to “in” or “in out” in SPARK Rationale - Mapping Overview - Tool Support - Conclusion 15

Mapping elements Enhancing the fit -- partial specification of the Stack class package Stacks is type Stack is private; procedure Clear(S: out Stack); --# derives S from ; Stack class operations properties procedure Pop (S : in out stack; X : out Integer); --# derives S, X from S; procedure Push (S : in out stack; X : in Integer); --# derives S from S, X; end Stacks; Rationale - Mapping Overview - Tool Support - Conclusion 16

Mapping structure • Declaration order considerations • Composition rules Rationale - Mapping Overview - Tool Support - Conclusion 17

Mapping structure • A definition declaration order – “A metamodel is an “abstract language” for describing different kinds of data; that is, a language without a concrete syntax or notation. " – OMG, Meta Object Facility, Version 1. 4 • In programming languages, concrete syntax is essential – for compilation – for static-analysis (core of SPARK) Rationale - Mapping Overview - Tool Support - Conclusion 18

Mapping structure declaration order package Stacks is type Stack is private; private Stack_Size : constant : = 100; type Pointer_Range is range 0. . Stack_Size; subtype Index_Range is Pointer_Range range 1. . Stack_Size; type Vector is array (Index_Range) of Integer; type Stack is record Stack_Vector: Vector; Stack_Pointer: Pointer_Range; end record; end Stacks; Rationale - Mapping Overview - Tool Support - Conclusion 19

Mapping structure declaration order package Stacks is type Stack is private; This type declaration depends on the “Stack_Size” constant declaration private Stack_Size : constant : = 100; type Pointer_Range is range 0. . Stack_Size; subtype Index_Range is Pointer_Range range 1. . Stack_Size; type Vector is array (Index_Range) of Integer; type Stack is record Stack_Vector: Vector; Stack_Pointer: Pointer_Range; end record; end Stacks; How do you represent this declaration order dependency in UML ? Rationale - Mapping Overview - Tool Support - Conclusion 20

Mapping structure declaration order • Inherent to SPARK Grammar – Built-in total ordering • UML – Only partial ordering • For elements of the same kind (e. g. attributes) Rationale - Mapping Overview - Tool Support - Conclusion 21

Mapping structure composition rules • Operations membership – Class members in UML – Package or other operation member or standalone in SPARK • Operation as a namespace – In SPARK/Ada – Not in UML • UML is class-centric Rationale - Mapping Overview - Tool Support - Conclusion 22

Evaluation criteria • No canonical mapping • Criteria are a combination of – Semantic proximity • E. g « UML constraint SPARK annotation » vs « UML tagged value SPARK annotation » – Workflow integration • process • people • tools Rationale - Mapping Overview - Tool Support - Conclusion 23

Tool support • Evaluation criteria – Dedicated/customizable user interface – Generators/leveraging model data – Compensating UML limitations • Implementation – Rhapsody in Ada (Ri. A) Rationale - Mapping Overview - Tool Support - Conclusion 24

Evaluation Criteria dedicated user interface • Writer/Input Perspective – Facilitate the modeling of SPARK aspects of a model • Reader/Output perspective – Highlight « SPARKness » of elements on diagrams Rationale - Mapping Overview - Tool Support - Conclusion 25

Evaluation Criteria Leveraging model data • Generate – Code – Documentation – Make files – CM commands –… Rationale - Mapping Overview - Tool Support - Conclusion 26

Evaluation Criteria Compensating UML limitations • Via profiles • By offering more than a strictly UML compliant CASE tool Rationale - Mapping Overview - Tool Support - Conclusion 27

Implementation on Ri. A User interface • « Model-oriented » and « Captureoriented » styles – Annotation = dependencies + stereotypes + tags – Annotation = tag • Graphical(UML) vs Textual(SPARK) Rationale - Mapping Overview - Tool Support - Conclusion 28

Implementation on Ri. A Code generator • UML Meta-Model based implementation – Rules-based generation engine – Flexible, but limited by the MM itself • Unusual approach for SPARK – Limit the amount of auto-generated code – To limit the information-flow – Enforces design based on conscious decisions from user Rationale - Mapping Overview - Tool Support - Conclusion 29

Implementation on Ri. A Interfacing with the examiner • Optimize user workflow • Integrate Examiner into Rhapsody – Generate examiner commands – Invoke directly from CASE tool – Redirect output • Error navigability Rationale - Mapping Overview - Tool Support - Conclusion 30

Conclusion • Concepts promoted by SPARK – Make Ada a better language – Are applicable across a large abstraction spectrum • From business logic domain (information flow analysis) • Down to implementation (proof annotations) – Are just as important as OO aspects Rationale - Mapping Overview - Tool Support - Conclusion 31

Conclusion • Static analysis integration in UML – Requires an evolution of the Meta Model • From a platform independent perspective – Information flow is applicable at a high level of abstraction • From a platform specific perspective – Proof relies on code and not on mere specs – Justified by current model driven practices • MDA technologies requalify some systems aspects as valuable modeling flow sources Rationale - Mapping Overview - Tool Support - Conclusion 32

Conclusion • Exploitable mapping – native UML + Profile – Associated tooling • Room for progression Rationale - Mapping Overview - Tool Support - Conclusion 33

A word of Thanks 34

Questions ? Xavier Sautejeau xsautejeau@sodius. com