1 / 21

Consistency in UML and B multi-views specifications

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,

dory
Download Presentation

Consistency in UML and B multi-views specifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. 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 eUID(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

  10. 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

  11. 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

  12. 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

  13. 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 TUB 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(TUB(SpecUML)) = ID(SpecB) ? IFM 2005, Eindhoven, The Netherlands

  14. 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(TUB(SpecUML)) = ID(SpecB) ? IFM 2005, Eindhoven, The Netherlands

  15. 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 TUB(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

  16. 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 TUB(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

  17. 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 ) TUB(TrainR) Operator’s correctness is TrainR* a refinement of Train ? IFM 2005, Eindhoven, The Netherlands

  18. 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 TUB(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

  19. 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

  20. 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

  21. The End Questions? IFM 2005, Eindhoven, The Netherlands

More Related