FESCA 2015 keynote

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

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

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

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

Fundamental Concepts of
Behaviour
init();
while (wait()) {
if (...) {
goUp();
} else {
goDown();
}
}

Behaviour
Init GoUp
GoDown
Wait
P := Init.Q;
Q := Wait.(GoUp|GoDown).Q
init();
while (wait()) {
if (...) {
goUp();
} else {
goDown();
}
}

Behaviour
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

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

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

Context model
Service = Single Operation
Idle
F
HandlingRequest
F/T
RequestArrival
FinishRequest
Idle
T
StartRequest

Start’ = now
ResponseTime’ = now - Start
Idle
F
HandlingRequest
F/T
RequestArrival
FinishRequest Idle
T
StartRequest

Mapping
Idle HandlingRequest
RequestArrival
FinishRequest
RequestAvailable
StartRequest
Context Model

Mapping
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

Assessment
• Good modularity
• 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

Assessment
• Good modularity
• 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
“It’s the formalism, stupid”

Semantics by Graph Rewriting

Non-functional Properties

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

DSL models
Defined by the user
+
Behavioral
Model
Structural
Model
Ecore (MOF)
Rewriting Logic
Semantic Domain
Transparent to the user
Semantic Mappings
(Real-Time) Maude
Simulation, reachability analysis, model checking
12/04/2015

DSL models
Defined by the user
+
Behavioral
Model
Structural
Model
Ecore (MOF)
Rewriting Logic
Semantic Domain
Semantic Mappings
(Real-Time) Maude
Simulation, reachability analysis, model checking
12/04/2015
•Observer values after simulation give predictions,
•(Probabilistic) Model checking can be used to
verify satisfaction of NFPs

Modularity
MMResponseTime Server, Queue,
Request

Weaving Languages

Weaving Languages (2)

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
DSLMMDSL M
DSL
M

Safety
GTS0
GTS1
GTS2

Safety
GTS0
GTS1
GTS2
GTS
Amalgamation

Safety
GTS0
GTS1
GTS2
GTS
Behaviour reflecting
Behaviour protecting
Amalgamation

Safety
GTS0
GTS1
GTS2
GTS
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

No Clan Morphism

Cannot Establish Rule
Morphism
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

Flexible Safety

Flexible Safety
[GTS0]T
[GTS1]T
GTS’0
GTS’1
GTS family

Flexible Safety
[GTS0]T
[GTS1]T
GTS2
GTS’0
GTS’1
GTS’2
Derivations
(cf. inter-modelling)

Flexible Safety
GTS’0
GTS’1
GTS’2

Flexible Safety
GTS
GTS’0
GTS’1
GTS’2

GTS Families
• Enable definition of GTS variations
[GTS0]T

GTS Families
• Enable definition of GTS variations
[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

GTS Families (2)
• Example transformers:
– Inheritance flattening
– Inheritance unfolding
– Introduce subclasses
– Unbinding
– Rule pattern duplication
– Move association
Indicated through
appropriate annotations

Response Time Family

?[ ]
[ ]
?

?[ ]
[ ]
?





?[ ]
[ ]
?

?[ ]
[ ]
?
1 2
2 31
Introduce subclasses x2

1 2
2 31
1 1 2
2
Unfold Inheritance

1 1 2
2
1 2
in 0..1
out 0..1
2 31
Move Down Association x2

1 2
in 0..1
out 0..1
2 31
1
Duplicate Elements

1 2
in 0..1
out 0..1
2 31
1 2
Unbind

1 2
in 0..1
out 0..1
2 31
1 2
1 1 2
2
1 2 3
Unfold Inheritance

Clan Morphism
1 2
in 0..1
out 0..1
2 31

Can Establish Rule Morphism
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

Token meta-model

Creating new tokens
(Workload semantics)

Moving tokens

Managing tokens
Calling a system operation:
• Create a new CToken to traverse operation
implementation

Managing tokens
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

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

FESCA 2015 keynote

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (9)

Similaire à FESCA 2015 keynote

Similaire à FESCA 2015 keynote (20)

Dernier

Dernier (20)

FESCA 2015 keynote

Notes de l'éditeur