ifm 2005 consistency in uml and b multi-views specifications d. okalas ossami, j.-p. jacquot, j....
Post on 19-Dec-2015
213 views
TRANSCRIPT
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)
IFM 2005, Eindhoven, The Netherlands 3D. OKALAS OSSAMI
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.
IFM 2005, Eindhoven, The Netherlands 4D. OKALAS OSSAMI
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.
IFM 2005, Eindhoven, The Netherlands 5D. OKALAS OSSAMI
Overview
OperatorsDefinitionExample operator : Refine-Data
Consistency relation Operator’s application Verification of the operator’s correctness Conclusion and future work
IFM 2005, Eindhoven, The Netherlands 6D. OKALAS OSSAMI
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]*
IFM 2005, Eindhoven, The Netherlands 7D. OKALAS OSSAMI
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
IFM 2005, Eindhoven, The Netherlands 8D. OKALAS OSSAMI
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
IFM 2005, Eindhoven, The Netherlands 9D. OKALAS OSSAMI
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*
IFM 2005, Eindhoven, The Netherlands 10D. OKALAS OSSAMI
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()
IFM 2005, Eindhoven, The Netherlands 11D. OKALAS OSSAMI
Operators applicationOperator Consistency relation Case study Oper. application
MACHINE Types
…
END
MACHINE Train
…
VARIABLES train, pos, Ht
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
IFM 2005, Eindhoven, The Netherlands 12D. OKALAS OSSAMI
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
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
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.
IFM 2005, Eindhoven, The Netherlands 13D. OKALAS OSSAMI
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 Consistency relation Case study Oper. application Oper. Correctness
IFM 2005, Eindhoven, The Netherlands 14D. OKALAS OSSAMI
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
INVARIANT … posR train TSTATESR
/* <To Do J(pos, posR)>*/
INITIALISATION
ANY tt WHERE tt TRAIN tt {}
THEN train := tt || posR := tt {farR} END
OPERATIONS
arrive(tr) = PRE tr train posR(tr) = farR
THEN pos(tr) := nearR … END;
…
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
VARIABLES train, pos, Ht
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
Operator Consistency relation Case study Oper. application Oper. Correctness
IFM 2005, Eindhoven, The Netherlands 15D. OKALAS OSSAMI
Operator’s correctness
4. .(TU->B(SpecUML) |= SpecB |= )
?
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
arrive(tr) = PRE tr train posR(tr) = farR
THEN pos(tr) := nearR … END;
…
END
TUB(TrainR)
Produced by the Refine-Data operator
1. (posR train TSTATESR ) (posR trainR TSTATESR)
2. (TrainR ::= REFINEMENT ) (TrainR ::= MACHINE )
Operator Consistency relation Case study Oper. application Oper. Correctness
IFM 2005, Eindhoven, The Netherlands 16D. OKALAS OSSAMI
Operator’s correctness
?
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
arrive(tr) = PRE tr train posR(tr) = farR
THEN pos(tr) := nearR … END;
…
END
TUB(TrainR)
Produced by the Refine-Data operator
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*
Operator Consistency relation Case study Oper. application Oper. Correctness
IFM 2005, Eindhoven, The Netherlands 17D. OKALAS OSSAMI
Operator’s correctness
?
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
arrive(tr) = PRE tr train posR(tr) = farR
THEN pos(tr) := nearR … END;
…
END
TUB(TrainR)
Produced by the Refine-Data operator
2. (TrainR ::= REFINEMENT ) (TrainR ::= MACHINE )
is TrainR* a refinement of Train ?
Operator Consistency relation Case study Oper. application Oper. Correctness
IFM 2005, Eindhoven, The Netherlands 18D. OKALAS OSSAMI
Operator’s correctness
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
Operator Consistency relation Case study Oper. application Oper. Correctness
IFM 2005, Eindhoven, The Netherlands 19D. OKALAS OSSAMI
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
IFM 2005, Eindhoven, The Netherlands 20D. OKALAS OSSAMI
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
IFM 2005, Eindhoven, The Netherlands 21D. OKALAS OSSAMI
The End
Questions?