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

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. Models are Cool!
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 2
Understand what you need to build
Abstract, abstract, abstract!

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. 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. 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. 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. 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. Fundamental Concepts of
Behaviour
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 7
init();
while (wait()) {
if (...) {
goUp();
} else {
goDown();
}
}

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. 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. 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. 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. 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. 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. 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. 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. Mapping
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 14
Idle HandlingRequest
RequestArrival
FinishRequest
RequestAvailable
StartRequest
Context Model

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. 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. Assessment
• Good modularity
– Concerns are nicely separated
– Can be independently specified
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 15

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. 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. Semantics by Graph Rewriting
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16

24. Semantics by Graph Rewriting
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16

25. Semantics by Graph Rewriting
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16

26. Semantics by Graph Rewriting
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16

27. Non-functional Properties
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 17

28. Non-functional Properties
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 17

29. Non-functional Properties
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 17

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. 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. 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. Modularity
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 19
MMResponseTime Server, Queue,
Request

34. Modularity
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 19
MMResponseTime Server, Queue,
Request

35. Weaving Languages
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20

36. Weaving Languages
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20

37. Weaving Languages
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20

38. Weaving Languages
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20

39. Weaving Languages (2)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21

40. Weaving Languages (2)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21

41. Weaving Languages (2)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21

42. Weaving Languages (2)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21

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. Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23
GTS0
GTS1
GTS2

45. Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23
GTS0
GTS1
GTS2
GTS
Amalgamation

46. Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23
GTS0
GTS1
GTS2
GTS
Behaviour reflecting
Behaviour protecting
Amalgamation

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. 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. No Clan Morphism
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 25

50. Cannot Establish Rule
Morphism
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 26
Part produced is different from parts received

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. Flexible Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28

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. 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. Flexible Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28
GTS’0
GTS’1
GTS’2

56. Flexible Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28
GTS
GTS’0
GTS’1
GTS’2

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. 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. GTS Families
• Enable definition of GTS variations
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 29
[GTS0]T

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. 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. 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. Response Time Family
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31

64. Response Time Family
?[ ]
[ ]
?
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31

65. Response Time Family
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
?[ ]
[ ]
?

66. Response Time Family
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
?[ ]
[ ]
?



67. Response Time Family


12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
?[ ]
[ ]
?

68. Response Time Family
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
?[ ]
[ ]
?
1 2
2 31
Introduce subclasses x2

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. 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. 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. 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. 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. Clan Morphism
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 32
1 2
in 0..1
out 0..1
2 31

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. 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. Token meta-model
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 35

78. Creating new tokens
(Workload semantics)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 36

79. Creating new tokens
(Workload semantics)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 36

80. Moving tokens
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 37

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