consistency in uml and b multi-views specifications

IFM 2005

Consistency in UML and B multi-views specifications

D. OKALAS OSSAMI, J.-P. JACQUOT, J. SOUQUIERES{okalas, jacquot, souquieres}@loria.fr

LORIA (Lorraine Laboratory of IT Research and its Applications)

IFM 2005, Eindhoven, The Netherlands 2D. OKALAS OSSAMI

Using several notations to specify software systemsUsing several notations to specify software systemsUsing several notations to specify software systemsUsing several notations to specify software systems

A

s0s1

B

constraint

A

UML :intuitive to use,architectural clearness, good for sharing understanding,

Stakeholders : Clients, users, specifiers, etc.

MACHINE B

…

END

MACHINE A

SETS A_STATES = {s0, s1}

VARIABLES state

INVARIANT state AInstances ASTATES

…

END

Verification

B :precise description of models, theorem proving,

Tools : BToolKit, aterlierB.

Setting the context(1/2)


Setting the context (2/2)

How to help construction activities ?

How to verify and ensure operators’s correctness ?

Two main questions :Two main questions :Two main questions :Two main questions :

A

s0s1

B

constraint

A

MACHINE B

…

END

MACHINE A

…

VARIABLES state

INVARIANT state A ASTATES

…

END

Development operators : make representations evolve while maintaining their mutual consistencyassist users during the development, enable the definition of specific design strategies (refinement, etc.)

Consistency relation : Condition under which the application operators leads to consistent representations.


Objectives :Objectives :Objectives :Objectives :

The goal of the paper

give a generic-template to define operators

give a definition of the notion of consistency relation and some hints to verify it.


Overview

OperatorsDefinitionExample operator : Refine-Data

Consistency relation Operator’s application Verification of the operator’s correctness Conclusion and future work


Development Operators : DefinitionOperator

High level abstractions defining construction activities in an intuitive andHigh level abstractions defining construction activities in an intuitive and

language independent way [Souquières , language independent way [Souquières , N. Lévy and G.SmithN. Lévy and G.Smith]]

Operator : Operator_Name

Description <Desc>Parameters In <Param_Name : Type_PARAM> Result <Param_Name : Type_PARAM>

Application conditions Related to SpecB

<COND_B> Related to SpecUML <COND_UML>Definition context <context> <OPERATOR_DEF>Remain To Be Done

<To Do Next>

OPERATOR_DEF ::= <O_UML, O_B> |OPERATOR_APP

|OPERATOR_DEF[;OPERATOR_DEF] |IF <COND> THEN OPERATOR_DEF[;OPERATOR]*


Example operator : Refine-Data

Operator : Refine-Data Description Replacement of some variables with more concrete onesParameters In Ma : identifier v : identifier [si : state] [{sri,…,srj} : Pow(States)] Result Mar : identifier

vr : identifier[Sr : identifier]

Application conditions

Related to SpecB : Ma ::= MACHINE | REFINEMENT si S v DATA(Ma) sk.(sk {sRi,…,sRj} si /= sk)

Related to SpecUML : C.(C CLASS(SpecUML) c|-> Ma) a.(a ATTR(C) a |-> v) T.(T TYPE(SpecUML) T|-> S)

Specifications can be developed in stepwiseSpecifications can be developed in stepwise

s1si

A

Mav : S

+s1

+si

<<enumeration>>

S

MACHINE Ma

SETS

S = {s1, si}

…

VARIABLES

ma, v

INVARIANT

v ma S

INITIALISATION

…

END

Operator


Example operator : Refine-Data

DefintionIF Ma ::= ( REFINEMENT MACHINE) v DATA(MA) S ::= (AbstractSet EnumeratedSet)

THEN

AddRefinement(

Ma,Mar);

AddSet(Sr, {sri,…,srj});

AddVariable(Mar, vr)

AddClass(Mar);

AddDependenct(

Ma, Mar,<<refines>>);

AddType(Sr, {sri,…,srj});

AddAttribute(Mar, vr)

O_BO_UML

MACHINE Ma

SETS

S = {s1, si}

VARIABLES

ma, v

INVARIANT

v ma S

…

END

s1si

A

Mav : S

+s1

+si

<<enumeration>>

S

Ma

s1

A

Marvr : Sr

S

Ma

J(v, vr)

+s1R

+siR

sRi

sRj

<<enumeration>>

Sr

srisri srjsrj

si

REFINEMENT Mar

REFINES Ma

SETS

Sr = {s1R, siR, sri, srj}

VARIABLES

ma, vr

INVARIANT

vr ma Sr

/* <To Do J(v, vr) > */

END

MACHINE Ma

Operator


Consistency relation

1.WF(SpecUML) WF(SpecB)Syntactic conformance : both specifications must be well-formed.

2. consistent(SpecUML) consistent(SpecB)Local consistency : each specification must be consistent by itself

4. .(TU->B(SpecUML) |= SpecB |= )

Semantics preservation : any statement satisfying the semantic of SpecUML must also satisfy SpecB.

3.eU .(eU ID(SpecUML) {eB}, T.({eB} ID(SpecB) T TU->B T(eU) = {eB}))

Elements traceability : for any element eU ID(SpecUML) for which there is a transformation rule T to B [Meyer, Ledang, Laleau, Nguyen], there exists {eB} ID(SpecB) such that : {eB} = T(eU )}.

A MACHINE A

SETS AInstances

…

END

Operator Consistency relation

SpecUMLSpecUMLSpecUMLSpecUML SpecBSpecBSpecBSpecB

TUML B

operator

SpecB*SpecB*SpecB*SpecB*


Operators applicationOperator Consistency relation Case study

MACHINE Types

SETS OBJECTS

CONSTANTS TRAIN,…

PROPERTIES

TRAIN OBJECTS

…

END

MACHINE Train

SEES Types

VARIABLES train, pos, Ht

INVARIANT train TRAIN Ht train NAT pos train TSTATES

INITIALISATION

ANY tt

WHERE tt TRAIN tt {}

THEN train := tt || pos := tt {far} || Ht := tt {0} END

OPERATIONS

arrive(tr) =

PRE tr train pos(tr) = far

THEN pos(tr) := near || Ht(tr) := 0 || … END;

cross(tr) = …

leave(tr) = …

END

+Ht : Int

Controler

Gate

Train

+pos : TSTATES

+arrive()

+cross()

+leave()

+far

+near

+on

<<enumeration>>

TSTATES

farnear

Train

arrive()/^Ctrl.enter(); Ht =0

on

cross()[Ht>2 Ht<5]/Ht =0

leave()[Ht>1 Ht<2]/^Ctrl.exit()


Operators applicationOperator Consistency relation Case study Oper. application

MACHINE Types

…

END

MACHINE Train

…


INVARIANT … pos train TSTATES

INITIALISATION

…

END

Controler

Gate

Train

<<enumeration>>

TSTATES

Train

farnear

on

Parameters In Train, pos, near {crt_S, stop_S} Result (TrainR, posR, TSTATESR)

Refine-Data

REFINEMENT TrainR

REFINES Train

REFINES TSTATES = {farR, onR, nearR, crt_S, stop_S}

…

VARIABLES posR

INVARIANT posR train TSTATESR

/* <To Do J(pos, posR)>*/

INITIALISATION

ANY tt WHERE tt TRAIN tt {}

THEN train := tt ||

posR := tt {farR}

END

OPERATIONS

…

END

MACHINE Types MACHINE TrainControler

Gate

Train

TSTATES

farR

onR

TrainR

crt_S

stop_S

nearR

+farR

+nearR

+onR

Crt_S

Stop_S

<<enumeration>>

TSTATES

J(pos, posR)

TrainR

+posR : TSTATESR

+arrive()…

Train

farnear

on


Operator’s correctness

Does the Refine-Data operator produce correct representations ?Does the Refine-Data operator produce correct representations ?

1. WF(SpecUML) WF(SpecB)Realm of tools (syntax checking, abtract Realm of tools (syntax checking, abtract syntax, etc.syntax, etc.))

Operator Consistency relation Case study Oper. application Oper. Correctness

REFINEMENT TrainR

REFINES Train


…

VARIABLES posR

INVARIANT … posR train TSTATESR


INITIALISATION


THEN train := tt ||

posR := tt {farR}

END

OPERATIONS

arrive(tr) = PRE tr train posR(tr) = farR

THEN pos(tr) := nearR … END;

…

END

MACHINE Types MACHINE Train

2. consistent(SpecUML) consistent(SpecB) Realm of B support tools : verification is not Realm of B support tools : verification is not directly accessible in UML.directly accessible in UML.


Operator’s correctnessOperator’s correctness

Train

TSTATES

farR

onR

TrainR

crt_S

stop_S

nearR

+farR

+nearR

+onR

Crt_S

Stop_S

<<enumeration>>

TSTATES

J(pos, posR)

TrainR

+posR : TSTATESR

+arrive()…

Train

farnear

on

MACHINE Types

SETS OBJECTS

CONSTANTS TRAIN, TRAINR

PROPERTIES TRAIN OBJECTS TRAINR OBJECTS

…

END

TUB

ID(TUB(SpecUML)) = ID(SpecB) ?

3.eU .(eU ID(SpecUML) {eB}, T.({eB} ID(SpecB) T TU->B T(eU) = {eB}))

Realm of UML to B transformation rulesRealm of UML to B transformation rules



Operator’s correctnessOperator’s correctness

ID(TUB(SpecUML)) = ID(SpecB) ?

REFINEMENT TrainR

REFINES Train

SETS TSTATES = {farR, onR, nearR, crt_S, stop_S}

…

VARIABLES posR



INITIALISATION


THEN train := tt || posR := tt {farR} END

OPERATIONS



…

END

MACHINE Types

SETS OBJECTS

CONSTANTS TRAIN, TRAINR

PROPERTIES TRAIN OBJECTS TRAINR OBJECTS

…

END

MACHINE Types

SETS OBJECTS

CONSTANTS TRAIN,…

PROPERTIES TRAIN OBJECTS

…

END

MACHINE Train

SEES Types


INVARIANT train TRAIN pos train TSTATES

INITIALISATION

ANY tt

WHERE tt TRAIN tt {}

THEN train := tt ||

pos := tt {far} ||

Ht := tt {0}

END

OPERATIONS

arrive(tr) =

PRE tr train pos(tr) = far

THEN pos(tr) := near || Ht(tr) := 0 || … END;

END




4. .(TU->B(SpecUML) |= SpecB |= )

?

REFINEMENT TrainR

REFINES Train


…

VARIABLES posR



INITIALISATION



OPERATIONS



…

END

TUB(TrainR)

Produced by the Refine-Data operator

1. (posR train TSTATESR ) (posR trainR TSTATESR)

2. (TrainR ::= REFINEMENT ) (TrainR ::= MACHINE )




?

REFINEMENT TrainR

REFINES Train


…

VARIABLES posR



INITIALISATION



OPERATIONS



…

END

TUB(TrainR)


1. (posR train TSTATESR ) (posR* trainR TSTATESR)

TRAIN TRAIN OBJECTS OBJECTS train train TRAIN TRAIN TRAINR TRAINR OBJECTS OBJECTS trainR trainR TRAINR TRAINR

train OBJECTS OBJECTS trainR OBJECTS OBJECTS

posR posR*




?

REFINEMENT TrainR

REFINES Train


…

VARIABLES posR



INITIALISATION



OPERATIONS



…

END

TUB(TrainR)


2. (TrainR ::= REFINEMENT ) (TrainR ::= MACHINE )

is TrainR* a refinement of Train ?




TUB(TrainR)

Controler

Gate

Train

TSTATES

+farR

+nearR

+onR

Crt_S

Stop_S

<<enumeration>>

TSTATES

J(pos, posR)

TrainR

+posR : TSTATESR

+arrive()…

farR

onR

TrainR

crt_S

stop_S

nearR

Train

farnear

on

: abstraction function equivalent to B refinement and maps :

Each state sr of TrainR to a state (sr) of Train

Each event er of TrainR to an event (er) of Train and

Each transition tr of TrainR to a transition (tr) of Train

Conditions 1, 2, 3 and 4 = trueConditions 1, 2, 3 and 4 = true

Refine-Data is correctRefine-Data is correct



Conclusion

Operators : a flexible approach to Identify design issues Force us to think about design decisions more carefully

than about syntactical details Produce representations that can be useful for both

userso as graphical documentation

specifiers o as formal documentation for mathematical

verification Consistency relation :

Provides minimal conditions for saying when an UML and B specifications can be considered consistent

Operator Consistency relation Case study Oper. application Oper. Correctness Conclusion & Future work


Future Work

Experiments : first experiments with our prototype

ArgoUML+B/SmarTools let us optimist (modeling entities, data, operations, etc.)

experiments with more complex operators

Apply the approach on more case studies

Specify a library of useful operators

Operator Consistency relation Case study Oper. application Oper. Correctness Conclusion & Future work


The End

Questions?

consistency in uml and b multi-views specifications

Documents

okalas ossamisetting

okalas ossamiexample

okalas ossamithe goal

application operators

data operator

refinement of train

notion of consistency

result application conditions