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
Models are Cool!
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 2
Understand what you need to build
Abstract, abstract, abstract!
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
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
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
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
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
Fundamental Concepts of
Behaviour
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 7
init();
while (wait()) {
if (...) {
goUp();
} else {
goDown();
}
}
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();
}
}
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
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
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
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
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
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
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
Mapping
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 14
Idle HandlingRequest
RequestArrival
FinishRequest
RequestAvailable
StartRequest
Context Model
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
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
Assessment
• Good modularity
– Concerns are nicely separated
– Can be independently specified
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 15
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
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”
Semantics by Graph Rewriting
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
Semantics by Graph Rewriting
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
Semantics by Graph Rewriting
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
Semantics by Graph Rewriting
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
Non-functional Properties
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 17
Non-functional Properties
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 17
Non-functional Properties
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 17
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
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
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
Modularity
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 19
MMResponseTime Server, Queue,
Request
Modularity
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 19
MMResponseTime Server, Queue,
Request
Weaving Languages
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20
Weaving Languages
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20
Weaving Languages
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20
Weaving Languages
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 20
Weaving Languages (2)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21
Weaving Languages (2)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21
Weaving Languages (2)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21
Weaving Languages (2)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 21
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
Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23
GTS0
GTS1
GTS2
Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23
GTS0
GTS1
GTS2
GTS
Amalgamation
Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23
GTS0
GTS1
GTS2
GTS
Behaviour reflecting
Behaviour protecting
Amalgamation
Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 23
GTS0
GTS1
GTS2
GTS
Behaviour reflecting
Behaviour protecting Behaviour protecting
Amalgamation
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
No Clan Morphism
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 25
Cannot Establish Rule
Morphism
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 26
Part produced is different from parts received
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
Flexible Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28
Flexible Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28
[GTS0]T
[GTS1]T
GTS’0
GTS’1
GTS family
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)
Flexible Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28
GTS’0
GTS’1
GTS’2
Flexible Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28
GTS
GTS’0
GTS’1
GTS’2
Flexible Safety
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 28
GTS
GTS’0
GTS’1
GTS’2
Behaviour reflecting
Behaviour protecting
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
GTS Families
• Enable definition of GTS variations
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 29
[GTS0]T
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
=
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
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
Response Time Family
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
Response Time Family
?[ ]
[ ]
?
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
Response Time Family
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
?[ ]
[ ]
?
Response Time Family
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
?[ ]
[ ]
?


Response Time Family


12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
?[ ]
[ ]
?
Response Time Family
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
?[ ]
[ ]
?
1 2
2 31
Introduce subclasses x2
Response Time Family
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 31
1 2
2 31
1 1 2
2
Unfold Inheritance
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
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
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
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
Clan Morphism
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 32
1 2
in 0..1
out 0..1
2 31
Can Establish Rule Morphism
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 33
1 2
1 1 2
2
1 2 3
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
Token meta-model
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 35
Creating new tokens
(Workload semantics)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 36
Creating new tokens
(Workload semantics)
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 36
Moving tokens
12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 37
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
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
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
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

FESCA 2015 keynote

  • 1.
    Building flexible analysis Modularformal 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 FreeLunch... • 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 FreeLunch... • 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 isHard • 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 • Clocksetc. – 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) SteffenZschaler, Francisco Duran, et al. 10 Start’ = now ResponseTime’ = now - Start Idle F HandlingRequest F/T RequestArrival FinishRequest Idle T StartRequest
  • 14.
    Modularity – 1stTry • 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) SteffenZschaler, 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) SteffenZschaler, 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) SteffenZschaler, Francisco Duran, et al. 14 Idle HandlingRequest RequestArrival FinishRequest RequestAvailable StartRequest Context Model
  • 18.
    Mapping 12/04/2015 (c) SteffenZschaler, 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) SteffenZschaler, 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 GraphRewriting 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
  • 24.
    Semantics by GraphRewriting 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
  • 25.
    Semantics by GraphRewriting 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 16
  • 26.
    Semantics by GraphRewriting 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 Definedby 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 Definedby 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 Definedby 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) SteffenZschaler, Francisco Duran, et al. 19 MMResponseTime Server, Queue, Request
  • 34.
    Modularity 12/04/2015 (c) SteffenZschaler, 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 • Needto 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) SteffenZschaler, Francisco Duran, et al. 23 GTS0 GTS1 GTS2
  • 45.
    Safety 12/04/2015 (c) SteffenZschaler, Francisco Duran, et al. 23 GTS0 GTS1 GTS2 GTS Amalgamation
  • 46.
    Safety 12/04/2015 (c) SteffenZschaler, Francisco Duran, et al. 23 GTS0 GTS1 GTS2 GTS Behaviour reflecting Behaviour protecting Amalgamation
  • 47.
    Safety 12/04/2015 (c) SteffenZschaler, Francisco Duran, et al. 23 GTS0 GTS1 GTS2 GTS Behaviour reflecting Behaviour protecting Behaviour protecting Amalgamation
  • 48.
    Flexibility • Amalgamation needsgood 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) • Theseare 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 • Enabledefinition of GTS variations 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 29 [GTS0]T
  • 60.
    GTS Families • Enabledefinition 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 RuleMorphism 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 (Workloadsemantics) 12/04/2015 (c) Steffen Zschaler, Francisco Duran, et al. 36
  • 79.
    Creating new tokens (Workloadsemantics) 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 setof 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

Editor's Notes

  • #4 L, E, G, we sort of know how to do efficiently (see, e.g., Xtext)
  • #5 L, E, G, we sort of know how to do efficiently (see, e.g., Xtext)
  • #6 PCM as an example
  • #18 Expressed as an implication between states, essentially forcing the two automata to run in sync
  • #19 Expressed as an implication between states, essentially forcing the two automata to run in sync
  • #20 Expressed as an implication between states, essentially forcing the two automata to run in sync
  • #21 The problems are lack of explicit structure in states (open-endedness) and the way in which state machines are combined, leading to problems with model checking etc.
  • #22 The problems are lack of explicit structure in states (open-endedness) and the way in which state machines are combined, leading to problems with model checking etc.
  • #23 The problems are lack of explicit structure in states (open-endedness) and the way in which state machines are combined, leading to problems with model checking etc.