Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

FESCA 2015 keynote

387 views

Published on

My keynote at FESCA 2015 on flexible analysis of software quality properties.

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

FESCA 2015 keynote

  1. 1. Building flexible analysis Modular formal specification of QoS and QoS analysis Steffen Zschaler, Francisco Duran, Antonio Moredo, Lucia Happe, Ralf Reussner, Javier Troya, Antonio Vallecillo, … 12 April, 2015
  2. 2. Models are Cool! 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 2 Understand what you need to build Abstract, abstract, abstract!
  3. 3. But no Free Lunch... • Need to build – Languages – Editors – Generators – Analysers • For every property • For every DSL 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 3
  4. 4. But no Free Lunch... • Need to build – Languages – Editors – Generators – Analysers • For every property • For every DSL 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 3
  5. 5. Building Analysers is Hard • Difficult to build – High complexity • Difficult to maintain – Extension with new properties is complex and dangerous • Difficult to use – Always need to know about everything in a workbench, even if not needed 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 4
  6. 6. A Better World... • Modularly package analysers – Flexible composition into arbitrary DSLs – Analyser only deals with property to be analysed – Construct language and tools for only the relevant properties • But keep safety – Ensure composition of base DSL and analyser is safe  semantic preservation 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 5
  7. 7. Plan of Attack • How do we get there? – Fundamental concepts for specifying and analysing system behaviour – Express properties independently of base behaviour – Flexible, but safe techniques for composition – Understand dimensions of modularity 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 6
  8. 8. Fundamental Concepts of Behaviour 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 7 init(); while (wait()) { if (...) { goUp(); } else { goDown(); } }
  9. 9. Fundamental Concepts of Behaviour 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 7 Init GoUp GoDown Wait P := Init.Q; Q := Wait.(GoUp|GoDown).Q init(); while (wait()) { if (...) { goUp(); } else { goDown(); } }
  10. 10. Fundamental Concepts of Behaviour 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 7 Init GoUp GoDown Wait P := Init.Q; Q := Wait.(GoUp|GoDown).Q init(); while (wait()) { if (...) { goUp(); } else { goDown(); } } Transition Systems
  11. 11. Capturing Properties • Clocks etc. – E.g., timed automata • History-determined variables – Abadi/Lamport’s TLA • Observers 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 8
  12. 12. History-Determined Variables in TLA • TLA: Temporal Logic of Actions – State: Set of variable values – Action: Predicate over changes of variable values – Specification: Set of actions that could be triggered at any point in time • History-determined variables – Variables whose values are determined by the past history of the specification – Adding these variables does not affect the underlying behaviour  Observe properties of the system 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 9
  13. 13. 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 10 Start’ = now ResponseTime’ = now - Start Idle F HandlingRequest F/T RequestArrival FinishRequest Idle T StartRequest
  14. 14. Modularity – 1st Try • We can in fact modularise this specification: 1. Specify ‘interface automaton’ (aka ‘context model’) 2. Specify property over context model 3. Map context model to specification of application 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 11
  15. 15. 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 12 Context model Service = Single Operation Idle F HandlingRequest F/T RequestArrival FinishRequest Idle T StartRequest
  16. 16. 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 13 Start’ = now ResponseTime’ = now - Start Idle F HandlingRequest F/T RequestArrival FinishRequest Idle T StartRequest
  17. 17. Mapping 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 14 Idle HandlingRequest RequestArrival FinishRequest RequestAvailable StartRequest Context Model
  18. 18. Mapping 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 14 Idle HandlingRequest RequestArrival FinishRequest RequestAvailable StartRequest Idle DoInc StartingIncrementReceivedIncrement FinishedIncrement val := val + 1 ReceivedGetValue StartingGetValue FinishedGetValueDoGetValue result := val Context Model Application Model
  19. 19. Mapping 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 14 Idle HandlingRequest RequestArrival FinishRequest RequestAvailable StartRequest Idle DoInc StartingIncrementReceivedIncrement FinishedIncrement val := val + 1 ReceivedGetValue StartingGetValue FinishedGetValueDoGetValue result := val Context Model Application Model
  20. 20. Assessment • Good modularity – Concerns are nicely separated – Can be independently specified 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 15
  21. 21. Assessment • Good modularity – Concerns are nicely separated – Can be independently specified • Bad reasoning – No modular reasoning – No guarantees for behaviour preservation – Very limited analytic capabilities • Essentially can only attempt proofs, but no simulations or model checking 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 15
  22. 22. Assessment • Good modularity – Concerns are nicely separated – Can be independently specified • Bad reasoning – No modular reasoning – No guarantees for behaviour preservation – Very limited analytic capabilities • Essentially can only attempt proofs, but no simulations or model checking 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 15 “It’s the formalism, stupid”
  23. 23. Semantics by Graph Rewriting 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
  24. 24. Semantics by Graph Rewriting 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
  25. 25. Semantics by Graph Rewriting 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
  26. 26. Semantics by Graph Rewriting 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
  27. 27. Non-functional Properties 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 17
  28. 28. Non-functional Properties 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 17
  29. 29. Non-functional Properties 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 17
  30. 30. Analysis Opportunities DSL models Defined by the user + Behavioral Model Structural Model Ecore (MOF) José E. Rivera, Francisco Durán and Antonio Vallecillo: On the Behavioral Semantics of Real-Time Domain Specific Visual Languages. In Rewriting Logic and Its Applications, LNCS 6381, pp. 174–190 12/04/2015
  31. 31. Analysis Opportunities DSL models Defined by the user + Behavioral Model Structural Model Ecore (MOF) Rewriting Logic Semantic Domain Transparent to the user Semantic Mappings Transparent to the user (Real-Time) Maude Simulation, reachability analysis, model checking José E. Rivera, Francisco Durán and Antonio Vallecillo: On the Behavioral Semantics of Real-Time Domain Specific Visual Languages. In Rewriting Logic and Its Applications, LNCS 6381, pp. 174–190 12/04/2015
  32. 32. Analysis Opportunities DSL models Defined by the user + Behavioral Model Structural Model Ecore (MOF) Rewriting Logic Semantic Domain Transparent to the user Semantic Mappings Transparent to the user (Real-Time) Maude Simulation, reachability analysis, model checking José E. Rivera, Francisco Durán and Antonio Vallecillo: On the Behavioral Semantics of Real-Time Domain Specific Visual Languages. In Rewriting Logic and Its Applications, LNCS 6381, pp. 174–190 12/04/2015 •Observer values after simulation give predictions, •(Probabilistic) Model checking can be used to verify satisfaction of NFPs
  33. 33. Modularity 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 19 MMResponseTime Server, Queue, Request
  34. 34. Modularity 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 19 MMResponseTime Server, Queue, Request
  35. 35. Weaving Languages 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20
  36. 36. Weaving Languages 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20
  37. 37. Weaving Languages 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20
  38. 38. Weaving Languages 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20
  39. 39. Weaving Languages (2) 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21
  40. 40. Weaving Languages (2) 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21
  41. 41. Weaving Languages (2) 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21
  42. 42. Weaving Languages (2) 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21
  43. 43. Sanity Conditions • Need to ensure that adding observers does not change behaviours Transformation step possible for model expressed in DSL  Step still possible in the same model expressed in DSL + Observers (possibly including appropriate observer objects) • For any legal model and transformation sequence 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 22 DSLMMDSL M DSL M
  44. 44. Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23 GTS0 GTS1 GTS2
  45. 45. Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23 GTS0 GTS1 GTS2 GTS Amalgamation
  46. 46. Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23 GTS0 GTS1 GTS2 GTS Behaviour reflecting Behaviour protecting Amalgamation
  47. 47. Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23 GTS0 GTS1 GTS2 GTS Behaviour reflecting Behaviour protecting Behaviour protecting Amalgamation
  48. 48. Flexibility • Amalgamation needs good structural match – Clan morphism between meta-models – Rule morphisms between individual rules • Neither is given for our example 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 24
  49. 49. No Clan Morphism 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 25
  50. 50. Cannot Establish Rule Morphism 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 26 Part produced is different from parts received
  51. 51. Flexibility (2) • These are technical issues – Don’t change what we mean by response time! – We want to be able to reuse our definitions in this context, too! – Need to be able to adapt the definitions 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 27
  52. 52. Flexible Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28
  53. 53. Flexible Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28 [GTS0]T [GTS1]T GTS’0 GTS’1 GTS family
  54. 54. Flexible Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28 [GTS0]T [GTS1]T GTS2 GTS’0 GTS’1 GTS’2 Derivations (cf. inter-modelling)
  55. 55. Flexible Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28 GTS’0 GTS’1 GTS’2
  56. 56. Flexible Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28 GTS GTS’0 GTS’1 GTS’2
  57. 57. Flexible Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28 GTS GTS’0 GTS’1 GTS’2 Behaviour reflecting Behaviour protecting
  58. 58. Flexible Safety 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28 GTS GTS’0 GTS’1 GTS’2 Behaviour reflecting Behaviour protecting Behaviour protecting
  59. 59. GTS Families • Enable definition of GTS variations 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 29 [GTS0]T
  60. 60. GTS Families • Enable definition of GTS variations 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 29 [GTS0]T GTS0 GTS1 GTS’1 GTS’’1 GTSn GTS’’nGTS’n GTS’’’1 ... ... ... titi ti ti ti ti ti ti =
  61. 61. GTS Families (2) • Example transformers: – Inheritance flattening – Inheritance unfolding – Introduce subclasses – Unbinding – Rule pattern duplication – Move association 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 30
  62. 62. GTS Families (2) • Example transformers: – Inheritance flattening – Inheritance unfolding – Introduce subclasses – Unbinding – Rule pattern duplication – Move association 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 30 Indicated through appropriate annotations
  63. 63. Response Time Family 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
  64. 64. Response Time Family ?[ ] [ ] ? 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
  65. 65. Response Time Family 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31 ?[ ] [ ] ?
  66. 66. Response Time Family 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31 ?[ ] [ ] ?  
  67. 67. Response Time Family   12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31 ?[ ] [ ] ?
  68. 68. Response Time Family 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31 ?[ ] [ ] ? 1 2 2 31 Introduce subclasses x2
  69. 69. Response Time Family 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31 1 2 2 31 1 1 2 2 Unfold Inheritance
  70. 70. Response Time Family 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31 1 1 2 2 1 2 in 0..1 out 0..1 2 31 Move Down Association x2
  71. 71. Response Time Family 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31 1 2 in 0..1 out 0..1 2 31 1 Duplicate Elements
  72. 72. Response Time Family 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31 1 2 in 0..1 out 0..1 2 31 1 2 Unbind
  73. 73. Response Time Family 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31 1 2 in 0..1 out 0..1 2 31 1 2 1 1 2 2 1 2 3 Unfold Inheritance
  74. 74. Clan Morphism 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 32 1 2 in 0..1 out 0..1 2 31
  75. 75. Can Establish Rule Morphism 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 33 1 2 1 1 2 2 1 2 3
  76. 76. Application to CBSE • Component architectures can be treated in this way: – Add token-based operational semantics to encode request control flow – Weave in observers as required – Analyse 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 34
  77. 77. Token meta-model 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 35
  78. 78. Creating new tokens (Workload semantics) 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 36
  79. 79. Creating new tokens (Workload semantics) 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 36
  80. 80. Moving tokens 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 37
  81. 81. Managing tokens 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 38 Calling a system operation: • Create a new CToken to traverse operation implementation
  82. 82. Managing tokens 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 38 Calling a system operation: • Create a new CToken to traverse operation implementation End of system-operation call: • Remove CToken • Set SToken to completed, so it can move on
  83. 83. Summary and Conclusion • Key ideas – Using observers to specify NFPs – Using rewriting-based semantics for ease of analysability – Defining GTS interfaces based on meta-model and rules – Using GTS morphisms • Enables amalgamation and category-theoretic proofs of semantic preservation – Using adaptation transformations to enable construction of morphisms 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 39
  84. 84. Outlook • Establish set of transformers – And give precise operational definitions • Fully establish semantic implications of GTS families • Identify other preservation properties • Do major case studies – Full PCM support would be nice 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 40

×