210 likes | 315 Views
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). UML : i ntuitive to use, architectural clearness, good for sharing understanding,
E N D
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
UML : • intuitive to use, • architectural clearness, • good for sharing understanding, • Stakeholders : Clients, users, specifiers, etc. • B : • precise description of models, • theorem proving, • Tools : BToolKit, aterlierB. MACHINE A SETS A_STATES = {s0, s1} VARIABLES state INVARIANT state AInstances ASTATES … END A Verification s1 s0 constraint MACHINE B … END B A Setting the context(1/2) Using several notations to specify software systems IFM 2005, Eindhoven, The Netherlands
Two main questions : MACHINE A … VARIABLES state INVARIANT state A ASTATES … END A s1 s0 MACHINE B … END constraint B A Setting the context (2/2) • How to help construction activities ? • Development operators: • make representations evolve while maintaining their mutual consistency • assist users during the development, • enable the definition of specific design strategies (refinement, etc.) • How to verify and ensure operators’s correctness ? • Consistency relation: • Condition under which the application operators leads to consistent representations. IFM 2005, Eindhoven, The Netherlands
The goal of the paper Objectives : • 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
Overview • Operators • Definition • Example operator : Refine-Data • Consistency relation • Operator’s application • Verification of the operator’s correctness • Conclusion and future work IFM 2005, Eindhoven, The Netherlands
OPERATOR_DEF ::= <O_UML, O_B> |OPERATOR_APP |OPERATOR_DEF[;OPERATOR_DEF] |IF <COND> THEN OPERATOR_DEF[;OPERATOR]* Development Operators : Definition Operator High level abstractions defining construction activities in an intuitive and language independent way [Souquières , N. 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> IFM 2005, Eindhoven, The Netherlands
A s1 si Ma MACHINEMa SETS S = {s1, si} … VARIABLES ma, v INVARIANT v ma S INITIALISATION … END v : S <<enumeration>> S +s1 +si Example operator : Refine-Data Operator Specifications can be developed in stepwise Operator : Refine-Data Description Replacement of some variables with more concrete ones Parameters 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) IFM 2005, Eindhoven, The Netherlands
Ma Defintion IF Ma ::= ( REFINEMENT MACHINE) v DATA(MA) S ::= (AbstractSet EnumeratedSet) THEN MACHINEMa SETS S = {s1, si} VARIABLES ma, v INVARIANT v ma S … END A O_UML O_B s1 si Ma AddClass(Mar); AddDependenct( Ma, Mar,<<refines>>); AddType(Sr, {sri,…,srj}); AddAttribute(Mar, vr) AddRefinement( Ma,Mar); AddSet(Sr, {sri,…,srj}); AddVariable(Mar, vr) J(v, vr) v : S <<enumeration>> S A +s1 +si si MACHINEMa REFINEMENTMar REFINESMa SETS Sr = {s1R, siR, sri, srj} VARIABLES ma, vr INVARIANT vr ma Sr /* <To Do J(v, vr) > */ END s1 Ma <<enumeration>> Sr Mar sri srj +s1R +siR sRi sRj vr : Sr S Example operator : Refine-Data Operator IFM 2005, Eindhoven, The Netherlands
Syntactic conformance : both specifications must be well-formed. 1.WF(SpecUML) WF(SpecB) SpecUML operator SpecB Local consistency : each specification must be consistent by itself 2. consistent(SpecUML) consistent(SpecB) TUML B Elements traceability : for any element eUID(SpecUML)for which there is a transformation ruleTto B [Meyer, Ledang, Laleau, Nguyen], there exists {eB}ID(SpecB)such that : {eB} = T(eU )}. 3.eU.(eU ID(SpecUML) {eB}, T.({eB} ID(SpecB) T TU->B T(eU) = {eB})) SpecB* 4. .(TU->B(SpecUML) |= SpecB |= ) Semantics preservation :any statement satisfying the semantic of SpecUMLmust also satisfy SpecB. MACHINEA SETS AInstances … END A Consistency relation Operator Consistency relation IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study MACHINETypes SETSOBJECTS CONSTANTS TRAIN,… PROPERTIES TRAIN OBJECTS … END Controler Train +Ht : Int +pos : TSTATES +arrive() +cross() Gate <<enumeration>> TSTATES +leave() MACHINETrain SEESTypes VARIABLEStrain, pos, Ht INVARIANTtrain TRAIN Ht train NAT pos train TSTATES INITIALISATION ANYtt WHEREtt TRAIN tt {} THENtrain := 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 +far +near +on Train arrive()/^Ctrl.enter(); Ht =0 near far cross()[Ht>2 Ht<5]/Ht =0 leave()[Ht>1 Ht<2]/^Ctrl.exit() on Operators application IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study Oper. application Controler MACHINETypes … END Train Refine-Data near near Gate <<enumeration>> TSTATES Parameters In Train, pos, near {crt_S, stop_S} Result (TrainR, posR, TSTATESR) far far MACHINETrain … VARIABLEStrain, pos, Ht INVARIANT… pos train TSTATES INITIALISATION … END on on Train Train MACHINETypes MACHINETrain Controler Train REFINEMENT TrainR REFINESTrain REFINESTSTATES = {farR, onR, nearR, crt_S, stop_S} … VARIABLESposR INVARIANTposR train TSTATESR /* <To Do J(pos, posR)>*/ INITIALISATION ANYtt WHEREtt TRAIN tt {} THENtrain := tt || posR := tt {farR} END OPERATIONS … END Gate J(pos, posR) TrainR TSTATES <<enumeration>> TSTATES TrainR nearR farR +posR : TSTATESR +farR +nearR +onR Crt_S Stop_S crt_S +arrive() … onR stop_S Operators application IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study Oper. application Oper. Correctness 1. WF(SpecUML) WF(SpecB) Realm of tools (syntax checking, abtract syntax, etc.) 2. consistent(SpecUML) consistent(SpecB) Realm of B support tools : verification is not directly accessible in UML. MACHINETypes MACHINETrain REFINEMENT TrainR REFINESTrain REFINESTSTATES = {farR, onR, nearR, crt_S, stop_S} … VARIABLESposR INVARIANT… posR train TSTATESR /* <To Do J(pos, posR)>*/ INITIALISATION ANYtt WHEREtt TRAIN tt {} THENtrain := tt || posR := tt {farR} END OPERATIONS arrive(tr) = PRE tr train posR(tr) = farR THEN pos(tr) := nearR … END; … END Operator’s correctness Does the Refine-Data operator produce correct representations ? IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study Oper. application Oper. Correctness Realm of UML to B transformation rules 3.eU.(eU ID(SpecUML) {eB}, T.({eB} ID(SpecB) T TU->B T(eU) = {eB})) MACHINETypes SETSOBJECTS CONSTANTSTRAIN, TRAINR PROPERTIES TRAIN OBJECTS TRAINR OBJECTS … END near far on Train Train J(pos, posR) TSTATES TUB TrainR <<enumeration>> TSTATES TrainR nearR farR +posR : TSTATESR +farR +nearR +onR Crt_S Stop_S crt_S +arrive() … onR stop_S Operator’s correctness Operator’s correctness ID(TUB(SpecUML)) = ID(SpecB) ? IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study Oper. application Oper. Correctness MACHINETypes SETSOBJECTS CONSTANTSTRAIN,… PROPERTIES TRAIN OBJECTS … END MACHINETypes SETSOBJECTS CONSTANTSTRAIN, TRAINR PROPERTIES TRAIN OBJECTS TRAINR OBJECTS … END MACHINETrain SEESTypes VARIABLEStrain, pos, Ht INVARIANTtrain TRAIN pos train TSTATES INITIALISATION ANYtt WHEREtt TRAIN tt {} THENtrain := 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 REFINEMENT TrainR REFINESTrain SETSTSTATES = {farR, onR, nearR, crt_S, stop_S} … VARIABLESposR INVARIANT… posR train TSTATESR /* <To Do J(pos, posR)>*/ INITIALISATION ANYtt WHEREtt TRAIN tt {} THENtrain := tt || posR := tt {farR} END OPERATIONS arrive(tr) = PRE tr train posR(tr) = farR THEN pos(tr) := nearR … END; … END Operator’s correctness Operator’s correctness ID(TUB(SpecUML)) = ID(SpecB) ? IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study Oper. application Oper. Correctness REFINEMENT TrainR REFINESTrain REFINESTSTATES = {farR, onR, nearR, crt_S, stop_S} … VARIABLESposR INVARIANT… posR train TSTATESR /* <To Do J(pos, posR)>*/ INITIALISATION ANYtt WHEREtt TRAIN tt {} THENtrain := tt || posR := tt {farR} END OPERATIONS arrive(tr) = PRE tr train posR(tr) = farR THEN pos(tr) := nearR … END; … END ? Produced by the Refine-Data operator TUB(TrainR) 1. (posR train TSTATESR ) (posR trainR TSTATESR) 2. (TrainR ::= REFINEMENT ) (TrainR ::= MACHINE ) Operator’s correctness 4. .(TU->B(SpecUML) |= SpecB |= ) IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study Oper. application Oper. Correctness REFINEMENT TrainR REFINESTrain REFINESTSTATES = {farR, onR, nearR, crt_S, stop_S} … VARIABLESposR INVARIANT… posR train TSTATESR /* <To Do J(pos, posR)>*/ INITIALISATION ANYtt WHEREtt TRAIN tt {} THENtrain := tt || posR := tt {farR} END OPERATIONS arrive(tr) = PRE tr train posR(tr) = farR THEN pos(tr) := nearR … END; … END ? Produced by the Refine-Data operator TUB(TrainR) 1. (posR train TSTATESR ) (posR* trainR TSTATESR) posR posR* train OBJECTS trainR OBJECTS Operator’s correctness TRAIN OBJECTS train TRAIN TRAINR OBJECTS trainR TRAINR IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study Oper. application Oper. Correctness REFINEMENT TrainR REFINESTrain REFINESTSTATES = {farR, onR, nearR, crt_S, stop_S} … VARIABLESposR INVARIANT… posR train TSTATESR /* <To Do J(pos, posR)>*/ INITIALISATION ANYtt WHEREtt TRAIN tt {} THENtrain := tt || posR := tt {farR} END OPERATIONS arrive(tr) = PRE tr train posR(tr) = farR THEN pos(tr) := nearR … END; … END ? Produced by the Refine-Data operator 2. (TrainR ::= REFINEMENT ) (TrainR ::= MACHINE ) TUB(TrainR) Operator’s correctness is TrainR* a refinement of Train ? IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study Oper. application Oper. Correctness Controler Train Gate near far on Train J(pos, posR) TSTATES : 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 TUB(TrainR) TrainR <<enumeration>> TSTATES TrainR nearR farR +posR : TSTATESR +farR +nearR +onR Crt_S Stop_S crt_S +arrive() … onR stop_S Operator’s correctness Conditions 1, 2, 3 and 4 = true Refine-Data is correct IFM 2005, Eindhoven, The Netherlands
Operator Consistency relation Case study Oper. application Oper. Correctness Conclusion & Future work 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 • users • as graphical documentation • specifiers • as formal documentation for mathematical verification • Consistency relation : • Provides minimal conditions for saying when an UML and B specifications can be considered consistent IFM 2005, Eindhoven, The Netherlands
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 IFM 2005, Eindhoven, The Netherlands
The End Questions? IFM 2005, Eindhoven, The Netherlands