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

Modeling SPARK Systems with UML

Xavier Sautejeau

SigAda’05

© Sodius

2

Contents

• Rationale

• Mapping Overview

• Tool support

• Conclusion

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


5

UML Overview

• Description– (Mainly) graphical notation

• Usage– Model OO aspects of systems

• Further info– www.uml.org


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


7

Mapping overview

• Comparing UML and SPARK

• Mapping individual elements

• Mapping structure

• Evaluation criteria


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


9

Comparing UML and SPARKdifferences

• Goal– UML => modeling activities– SPARK => defect prevention

• Audience– UML => humans– SPARK => computer


10

Mapping individual elements

• "Natural" mapping of main concepts

• Customizing UML via profiles

• Enhancing the fit


11

Mapping elements"Natural" mapping


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


13

Mapping elementsCustomizing UML via profiles


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


A UML Model of the Stack class

Stack class operations properties

15




Implicit “this” parameter

passing mode in UML can only translate to “in”

or “in out” in SPARK

16



-- 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;


17

Mapping structure

• Declaration order considerations

• Composition rules


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)


19



package Stacks is


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



package Stacks is


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


• Inherent to SPARK Grammar– Built-in total ordering

• UML– Only partial ordering

• For elements of the same kind (e.g. attributes)


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


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


24

Tool support

• Evaluation criteria– Dedicated/customizable user interface– Generators/leveraging model data– Compensating UML limitations

• Implementation– Rhapsody in Ada (RiA)


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


26

Evaluation CriteriaLeveraging model data

• Generate– Code– Documentation– Make files– CM commands– …


27

Evaluation CriteriaCompensating UML limitations

• Via profiles• By offering more than a strictly UML

compliant CASE tool


28

Implementation on RiAUser interface

• « Model-oriented » and « Capture-oriented » styles– Annotation = dependencies + stereotypes +

tags– Annotation = tag

• Graphical(UML) vs Textual(SPARK)


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


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


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


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


33

Conclusion

• Exploitable mapping– native UML + Profile– Associated tooling

• Room for progression


34

A word of Thanks

Questions ?

Xavier Sautejeau

[email protected]

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

Documents

uml slide

mapping useful

uml overview description

spark differences goal

humans spark

spark transformation

modeling spark systems

spark systems profile