FESCA 2015 keynote

Building flexible analysisModular 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


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();

}

}



Init GoUp

GoDown

Wait

P := Init.Q;

Q := Wait.(GoUp|GoDown).Q

init();

while (wait()) {

if (...) {

goUp();

} else {

goDown();

}

}



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’ = nowResponseTime’ = 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 modelService = Single Operation

Idle

F

HandlingRequest

F/T

RequestArrival

FinishRequestIdle

T

StartRequest


Start’ = nowResponseTime’ = now - Start

Idle

F

HandlingRequest

F/T

RequestArrival

FinishRequest Idle

T

StartRequest

Mapping


Idle HandlingRequest

RequestArrival

FinishRequest

RequestAvailable

StartRequestContext Model

Mapping



RequestArrival

FinishRequest

RequestAvailable

StartRequest

Idle

DoInc

StartingIncrementReceivedIncrement

FinishedIncrement

val := val + 1

ReceivedGetValue StartingGetValue

FinishedGetValueDoGetValue

result := val

Context Model

Application Model

Mapping



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 modelsDefined by the user

+Behavioral

Model

StructuralModel

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



+Behavioral

Model

StructuralModel

Ecore (MOF)

Rewriting LogicSemantic DomainTransparent to the user

Semantic MappingsTransparent to the user

(Real-Time) MaudeSimulation, reachability analysis, model checking


12/04/2015



+Behavioral

Model

StructuralModel

Ecore (MOF)

Rewriting LogicSemantic DomainTransparent to the user

Semantic MappingsTransparent to the user

(Real-Time) MaudeSimulation, reachability analysis, model checking


12/04/2015

•Observer values after simulation give predictions,• (Probabilistic) Model checking can be used toverify satisfaction of NFPs

Modularity


MMResponseTime Server, Queue,

Request

Modularity


MMResponseTime Server, Queue,

Request

Weaving Languages


Weaving Languages


Weaving Languages


Weaving Languages


Weaving Languages (2)








Sanity Conditions

• Need to ensure that adding observers

does not change behavioursTransformation 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 MDSL

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

Flexible Safety


GTS

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 22

Unfold Inheritance



1 1 22

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 22

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 22

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)


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


Engineering

FESCA 2015 keynote