3
Rationale
• SPARK Overview
• UML Overview
• Why is a mapping useful ?
Rationale - Mapping Overview - Tool Support - Conclusion
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/sparkada
Rationale - Mapping Overview - Tool Support - Conclusion
5
UML Overview
• Description– (Mainly) graphical notation
• Usage– Model OO aspects of systems
• Further info– www.uml.org
Rationale - Mapping Overview - Tool Support - Conclusion
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
Mapping overview
• Comparing UML and SPARK
• Mapping individual elements
• Mapping structure
• Evaluation criteria
Rationale - Mapping Overview - Tool Support - Conclusion
8
Comparing UML and SPARKsimilarities
• 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
Comparing UML and SPARKdifferences
• Goal– UML => modeling activities– SPARK => defect prevention
• Audience– UML => humans– SPARK => computer
Rationale - Mapping Overview - Tool Support - Conclusion
10
Mapping individual elements
• "Natural" mapping of main concepts
• Customizing UML via profiles
• Enhancing the fit
Rationale - Mapping Overview - Tool Support - Conclusion
11
Mapping elements"Natural" mapping
Rationale - Mapping Overview - Tool Support - Conclusion
SPARK construct UML model element
Package Class | Package
Operation Operation
Variable Attribute
Annotation Constraint | Dependency | TaggedValue | Stereotype
Some possible equivalences from SPARK to UML
12
Mapping elementsCustomizing 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
Mapping elementsCustomizing UML via profiles
Rationale - Mapping Overview - Tool Support - Conclusion
Profile element(s)
[kind]
SPARK construct UML construct
<<Proof>>
[stereotype]
Proof type | Proof Operation
Type | Operation
OwnMode
[tagged value, Enum (None, In, Out)]
Own variable mode Attribute
globalSpec, globalBody
[tagged value, String]
Global annotation(s) Operation
<<Global>>
[stereotype]
Global annotation(s) Dependency
( from operation to attribute)
SPARK Profile Candidate Elements
14
Mapping elementsEnhancing the fit
Rationale - Mapping Overview - Tool Support - Conclusion
A UML Model of the Stack class
Stack class operations properties
15
Mapping elementsEnhancing 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
Mapping elementsEnhancing 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
Mapping structure
• Declaration order considerations
• Composition rules
Rationale - Mapping Overview - Tool Support - Conclusion
18
Mapping structuredeclaration 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
Mapping structuredeclaration 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
Mapping structuredeclaration 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
Mapping structuredeclaration 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
Mapping structurecomposition 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
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
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
Evaluation Criteriadedicated 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
Evaluation CriteriaLeveraging model data
• Generate– Code– Documentation– Make files– CM commands– …
Rationale - Mapping Overview - Tool Support - Conclusion
27
Evaluation CriteriaCompensating UML limitations
• Via profiles• By offering more than a strictly UML
compliant CASE tool
Rationale - Mapping Overview - Tool Support - Conclusion
28
Implementation on RiAUser 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
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
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
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
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
Conclusion
• Exploitable mapping– native UML + Profile– Associated tooling
• Room for progression
Rationale - Mapping Overview - Tool Support - Conclusion