Patterns and model transformation tools for designing Contractual State Machines Lishan Harbird Submitted for the degree of Doctor of Philosophy University of York Department of Computer Science December 2011 Dedication To Kevin Harbird Abstract Design methods for reactive systems may start with an abstract description of a proposed solution, which can be expressed in both an operational and declarative style. Typically these descriptions are then incrementally elaborated into executable programs. The aim of this research is to put this ad hoc design method on to a more systematic footing, thus helping engineers produce more reliable and robust systems. This is accomplished by providing a rigorous engineering process supported by engineer-friendly tools based on the application of refinement and refactoring patterns for Contractual State Machines. Contractual State Machines (CoSta) are a simplified form of statecharts extended with temporal logic-based declarative specifications. A refinement pattern is an abstract way of representing a common type of refinement frequently required during the stepwise design of a system. Tool support is provided for system design and pattern application and is integrated with model checking technology for formal verification. To demonstrate the viability of the approach the new refinement and refactoring patterns are applied to the design of a system through a case study. iii Contents Abstract iii List of figures vii List of tables xiii Acknowledgements xvii Declaration xix 1 Introduction 1 1.1 Motivation . 3 1.2 Contributions . 6 1.3 Thesis structure . 10 2 Research context 13 2.1 Introduction . 13 2.2 Reactive systems . 13 2.3 Concurrency . 14 2.4 Validation and verification . 16 2.5 Statecharts . 17 2.6 Tool support . 20 2.7 Contracts . 22 2.8 Patterns . 25 2.9 Refactoring . 26 2.10 Refinement . 27 2.11 Model-driven engineering (MDE) . 28 2.12 Eclipse-based development tools for MDE . 30 v Contents 2.13 Contractual State Machines (CoSta) . 36 2.14 Related work . 52 2.15 Summary . 58 3 Analysis and hypothesis 61 3.1 Introduction . 61 3.2 Research hypothesis . 63 3.3 Approach . 65 3.4 Research scope . 66 3.5 Contributions . 67 3.6 Contrast with existing approaches . 69 3.7 Summary . 70 4 Basic refinement and refactoring patterns 71 4.1 Introduction . 71 4.2 Systematic approach . 95 4.3 Basic patterns . 108 4.4 Conclusions . 133 5 Further refinement and refactoring patterns 135 5.1 Introduction . 135 5.2 Further patterns . 136 5.3 General patterns . 149 5.4 Omitted patterns . 150 5.5 Summary . 152 6 Tool support and implementation 153 6.1 Introduction . 154 6.2 Prototyping the modelling tool . 157 6.3 Summary . 175 7 Validation and evaluation 177 7.1 Introduction . 177 7.2 The case study . 177 7.3 The docking system . 178 vi Contents 7.4 Design of the docking system version 1 . 180 7.5 Design of the docking system version 2 . 185 7.6 Evaluation of results . 236 7.7 Conclusions . 241 8 Conclusions and further work 243 8.1 Introduction . 243 8.2 Review findings . 243 8.3 Further work . 247 8.4 Summary . 253 Appendix 255 A Implementation 255 A.1 Contractual State Machine metamodel . 255 A.2 EMFtext parser for the contract language . 256 A.3 EMFtext parser for the transition label language . 261 A.4 EWL wizards for refinement patterns . 266 B CoSta contract language 281 B.1 Summary of contract operators . 281 C Case study - the docking system 297 C.1 Refinement of the ShipReq component . 297 D Additional patterns 347 D.1 Patterns for CoSta contracts . 347 D.2 Patterns for mixed designs . 350 Abbreviations 353 Bibliography 357 vii List of Figures 2.1 Stopwatch chart . 19 2.2 The architecture of Epsilon . 33 2.3 Contractual State Machine syntactic model . 40 2.4 Example Contractual State Machine model . 44 2.5 The design strategy . 47 2.6 Synchronising concurrent processes . 49 2.7 Mutual exclusion . 51 4.1 Simple synchronising concurrent processes . 73 4.2 Conjunction Introduction applied to create two conjunction states . 74 4.3 Conjunction Introduction applied to contract A . 75 4.4 Enable is applied to contract A1, Disable is applied to contract A2 . 76 4.5 Pattern Conjunction Elimination is applied to state with contract A . 77 4.6 Pattern Unfold Always is applied to contract B . 78 4.7 Pattern Conjunction Introduction is applied to contract B . 79 4.8 Pattern If is applied to contracts B1 and B2 . 80 4.9 Pattern Unfold Unless is applied to contract B3 . 81 4.10 Pattern Conjunction Introduction is applied to contract B3 . 82 4.11 Pattern Conjunction Introduction is applied to contract B5 . 83 4.12 Enable, Disable and If are applied to introduce transition 'Out . 84 4.13 Pattern Strengthen Contract is applied to B9 and B10 . 85 4.14 Pattern Conjunction elimination is applied to B6, B7 and B8 . 86 4.15 Pattern Unfold Unless is applied to B9 . 87 4.16 Pattern If is applied to B4 . 88 4.17 Pattern Strengthen Contract is applied to B9 and B12 . 89 4.18 Pattern Conjunction Elimination is applied to B1 and B2 . 90 ix List of Figures 4.19 Pattern Flatten Hierarchy is applied to B7 . 91 4.20 Contract A2 refined into same model as that for B1 . 92 4.21 Pattern Conjunction Elimination is applied to A and B . 93 4.22 Pattern Flatten Hierarchy is applied to state with contract A . 94 4.23 Pattern Reroute is applied to state with contract A3 . 95 4.24 Conjunction introduction . 96 4.25 Introduce conjunction states for each conjunct in the contract . 97 4.26 Equal . 97 4.27 Conjuncts refined to equivalent designs representing the common behaviour 98 4.28 The duplicate conjunction states are eliminated . 98 4.29 Strengthen contract . 110 4.30 Merge conjunct . 112 4.31 If combine actions . 114 4.32 Unfold Always . 115 4.33 Unfold Unless . 116 4.34 Unfold Within k . 117 4.35 Disable . 118 4.36 Conjunction introduction . 120 4.37 Remove a composite superstate . 122 4.38 Combine transitions . 123 4.39 Combine states . 124 4.40 Equal . ..