1. Modeling SPARK Systems with UML Xavier Sautejeau SigAda’05 © Sodius

2. 2 Contents Rationale Mapping Overview Tool support Conclusion

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

4. 4 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/sparkadawww.praxis-his.com/sparkada Rationale - Mapping Overview - Tool Support - Conclusion

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

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

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

8. 8 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

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

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

11. 11 Mapping elements "Natural" mapping Rationale - Mapping Overview - Tool Support - Conclusion SPARK constructUML model element PackageClass | Package Operation VariableAttribute AnnotationConstraint | Dependency | TaggedValue | Stereotype Some possible equivalences from SPARK to UML

12. 12 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

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

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

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

16. 16 Mapping elements Enhancing the fit Rationale - Mapping Overview - Tool Support - Conclusion -- partial specification of the Stack class package Stacks is type Stack is private; procedure Clear(S: out Stack); --# derives S from ; 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; Stack class operations properties

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

18. 18 Mapping structure declaration order A definition –“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

19. 19 Mapping structure declaration order Rationale - Mapping Overview - Tool Support - Conclusion 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;

20. 20 Mapping structure declaration order Rationale - Mapping Overview - Tool Support - Conclusion 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; This type declaration depends on the “Stack_Size” constant declaration How do you represent this declaration order dependency in UML ?

21. 21 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

22. 22 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

23. 23 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

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

25. 25 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

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

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

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

29. 29 Implementation on RiA 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

30. 30 Implementation on RiA 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

31. 31 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

32. 32 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

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

34. 34 A word of Thanks

35. Questions ? Xavier Sautejeau xsautejeau@sodius.com