June 5, 2013
Design and Analysis Design and Analysis ofof Distributed Interacting SystemsDistributed Interacting Systems
OrganizationProf. Dr. Joel Greenyer
2
Oral Exams
• Oral exams take place be between the August 13 and 15• We will assign slots to students between 9.00 and 12.00 or
14.00 and 17.00
• Please send us an email by August 1st and state– which of the days you prefer– whether you prefer the morning or afternoon– which times are impossible for you
• Please contact me soon if you require an exam outside of this period
June 5, 2013
Design and Analysis Design and Analysis ofof Distributed Interacting SystemsDistributed Interacting Systems
Lecture 8 – LTL Model Checking SummaryProf. Dr. Joel Greenyer
4
Last time: LTL-to-GBA: Example
• Example: φ = a U b
offoffoffq0
a∧b q1
a, b, φ
q2
a, ¬b, φ
q3
¬a, b, φ
a∧¬b
¬a∧b
q4
a, ¬b,¬φ
q5
¬a, ¬b,¬φ
a∧b
¬a∧b
a∧¬b¬a∧¬b
a∧¬b
¬a∧¬b
¬a∧b
a∧¬b
a∧¬b
a∧b
here the acceptance
condition is {F1} with
F1 = {q
1, q
3, q
4, q
5}
5
Last time: GBA to BA (De-Generalization)
• Every GBA can be translated to a regular BA that accepts the same language
• For a GBA = (Q, Σ, T, I, {F1, …, F
n}) we construct a
BA = (Q × {0, …, k}, Σ, T', I × {0}, F × {k})with ((q, x), σ, (q', y)) ∈ T' if (q, σ, q') ∈ T and– if q ∈ F
i and x = i - 1 then y = i,
– if x = k then y = 0,– x = y otherwise
• Example:
offoffoffq1
a
b
q2
a
b
F1 = {q
1},
F2 = {q
1, q
2}
offoffoffq1,0 q
2,0
offoffoffq1,1 q
2,1
offoffoffq1,2 q
2,2
ab
ab
b
b aa
ab
ab
6
Summary LTL Model Checking, Complexity
• Calculate of cl(φ)/cs(φ): Ο(|φ|), |φ| is # of operators in φ
• Create B¬φ
: Ο(2|φ|)
• Create BM: Ο(|M|), |M| is the number of states and transitions
of Kripke Structure M.
• Create BM ⊗ B
¬φ: Ο(|M| × 2|φ|)
• Check BM ⊗ B
¬φ emptiness: linear, i.e. Ο(|M| × 2|φ|)
➔ Hence, overall complexity is linear in size of the model, but exponential in the size of the formula.
•
What we need:1. Checking emptyness of the language accepted by a BA2. Product construction for BAs3. Represent KS as BA4. Represent LTL formula as BA
M ⊨ φiff L(M) ⊆ L(φ)iff L(M) ∩ ((2AP)ω \ L(φ)) = ∅iff L(M) ∩ L(¬φ) = ∅iff L(B
M ⊗ B
¬φ) = ∅
7
Verification in the Development Process
• How do we envision formal verification methods to be used in practice?– LTS and Promela are not modeling/programming
languages that are used in practice...– Temporal Logics are difficult to write/understand
by many software engineers, even experts
• Alternative:– check C or Java programs directly
• for C: CBMC, BLAST, ...; for Java: Java Pathfinder, BANDERA, …• check properties specified in program code or temporal logics
– model-based software development• use adequate models (UML+extensions, DSLs) for the design• transform models to the input for a model-checker• generate runnable code from the models
G (φ U ψ)
8
Model-based Software Development and Formal Verification
GQ6 informal requirementsand domain knowlesge
assert(...);
formalized specification
design model, andlater implementationmodel
code
formalize
public void run(){ ...;}
design
no more bugs→ generate code
could be different models for different development stages, e.g. platform-independent, later platform-specific
9
Model-based Software Development and Formal Verification
GQ6 informal requirementsand domain knowledge
assert(...);
formalized specification
design model, andlater implementationmodel
code
formalize
public void run(){ ...;}
design
no more bugs→ generate code
Model-based software development:Goal: Provide engineers with adequate languages to describe their system/software.
adequate language: can capture all relevant information, unambiguous, understandable, suited for the development task, machine-processable
Models
10
Model-based Software Development and Formal Verification
GQ6 informal requirementsand domain knowledge
assert(...);
formalized specification
design model, andlater implementationmodel
code
formalize
public void run(){ ...;}
design
no more bugs→ generate code
chan ts2c =...
[]!a || b;[]<> a;
model for MC
specificationfor MC
Model Checker (MC)
fix bugs
transform
transform
check
11
Example of Transformation: SDL to Promela
• SDL (Specification and Description Language) to Promela:– see [1] Vlaovič, B.; Vreže, A.; Brezočnik, Z. & Kapus, T. Automated generation of Promela model from SDL
specification, Computer Standards & Interfaces 29, 449 – 461, 2007.
– see Vreže, A.; Vlaovič, B. & Brezočnik, Z. Sdl2pml – Tool for automated generation of Promela model from SDL specification Computer Standards & Interfaces 31, 779 - 786, 2009.
– see also Stephan Kleuker: Formale Modelle der Softwareentwicklung: Model-Checking, Verifikation, Analyse und Simulation. Vieweg+Teubner Verlag, 2009.
(you don't need to understand this diagram)
figure from [1]
12
Example of Transformation: Realtime Statecharts to Uppaal
• Realtime Statecharts: Timed extension of Statecharts (with clock variables that increase over time)
– see Hirsch, M. Effizientes Model Checking von UML-RT Modellen und Realtime Statecharts mit UPPAAL, Diplomarbeit, Uni Paderborn, 2004.
(you don't need to understand this diagram)
13
When is the system “correct”?
• Correct:– system does what the
stakeholders want it to do– it does not do what
the stakeholders do notwant it to do
• Is the system really correctwhen model checking returns true?– requirements may be incorrectly formalized– domain knowledge could be overly optimistic
or incorrectly formalized– bugs in the specification/model transformations– bugs in the code generator– bugs in the model checker
GQ6 informal requirementsand domain knowledge
assert(...);
formalized specification
design model, andlater implementationmodel
code
formalize
public void run(){ ...;}
design
no more bugs→ generate code
chan ts2c =...
[]!a || b;[]<> a;
model for MC
specificationfor MC
Model Checker (MC)
fix bugs
transform
transform
check
must bevalidated!
June 5, 2013
Design and Analysis of Design and Analysis of Distributed Interacting SystemsDistributed Interacting Systems
Lecture 8 – Live Sequence Charts (LSCs)Prof. Dr. Joel Greenyer
15
Note: Also the specification may be incorrect
GQ6 informal requirementsand domain knowledge
assert(...);
formalized specification
design model, andlater implementationmodel
code
formalize
public void run(){ ...;}
design
no more bugs→ generate code
chan ts2c =...
[]!a || b;[]<> a;
model for MC
specificationfor MC
Model Checker (MC)
fix bugs
transform
transform
check
Model-checking may also reveal that the specification must be fixed! → then long and costly iterations required!
16
What is an adequate language to specify?
GQ6 informal requirementsand domain knowledge
assert(...);
formalized specification
design model, andlater implementationmodel
code
formalize
public void run(){ ...;}
design
no more bugs→ generate code
Model-based software development:
What would be an adequate language to specify distributed, interacting systems?
temproal logic? natural language? Büchi Automata? LTS? C? Java? Activity diagrams? Process algebra? use case diagrams? interaction diagrams? graph transformations? …? combinations of ...?
17
Idea: Play-In / Play-Out
• Idea: “Play with the system and tell it what to do in certain cases”– called “Play-In” of behavior– record “rules” that can be executed later via “Play-Out”
• Example: Coffee machine– “when I insert a coin and press
'coffee', then the machine shoulddispense a cup of coffee”
– “when I insert a coin and press'tea' then...”
– “when I press coffee and thecoffee bean container is empty, the service lamp must light up and no coffee must be dispensed”
teacoffee
cancel
out of order
coffee machine
user
18
Live Sequence Charts – Informal Introduction
• Example: Coffee machine– “when I insert a coin and press
'coffee', then the machine shoulddispense a cup of coffee”
• Live Sequence Chart (LSC)
teacoffee
cancel
out of order
coffee machine
user
insert coin
:CoffeeMachine
LSC DispenseCoffee
coffee pressed
dispense coffee
“Prechart”
“Main Chart”: Sequence of events that must be satisfied if the prechart is satisfied.
19
Live Sequence Charts – Informal Introduction
• Example: Coffee machine– “when I press coffee and the
coffee bean container is empty, the service lamp must light up and no coffee must be dispensed”
• Live Sequence Chart (LSC)
teacoffee
cancel
out of order
coffee machine
user
insert coin
:CoffeeMachine
LSC SeriveLampOnWhenCoffeeBeansEmpty
coffee pressed
service light on
beansempty
dispense coffeeforbidden
forbidden events: something must not happen while the scenario is “active”
20
Come Let's Play
• Harel, D. & Marelly, R. Come, Let's Play: Scenario-Based Programming Using LSCs and the Play-Engine, Springer-Verlag, 2003(http://www.wisdom.weizmann.ac.il/~playbook/)
(also free PDF of the book available)
• Harel, D. Can Programming be Liberated, Period? IEEE Computer Society 41:1, 2008(http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingProgramming.pdf)
• Harel, D.; Marron, A. & Weiss G., Behavioral Programming, Comm. ACM 55:7, 90-100, 2012(http://www.wisdom.weizmann.ac.il/~harel/papers/Behavioral%20programming%20.pdf)
read!
21
Play-Engine
• Tool and many interesting examples:– Bakery oven
figure from Harel, D. & Marelly, R. Come, Let's Play: Scenario-Based Programming Using LSCs and the Play-Engine
22
Play-Engine
• Tool and many interesting examples:– Cell Phone
figure from Harel, D. & Marelly, R. Come, Let's Play: Scenario-Based Programming Using LSCs and the Play-Engine
23
Play-Engine
• Tool and many interesting examples:– Calculator
figure from Harel, D. & Marelly, R. Come, Let's Play: Scenario-Based Programming Using LSCs and the Play-Engine
24
PlayGo
• Recent new version of the tool
see http://www.weizmann.ac.il/mediawiki/playgo/index.php/Main_Page
25
Play-In / Play-Out – Critical Thoughts
• (+) Play-In seems useful especially to describe the interactions of a user with an interface
• (-) Play-in difficult when there are more and more exceptions– manual modification of the LSCs necessary
• (+) LSCs are (relatively) intuitive for expressing many kinds of properties (what may, must (not) happen, loops, choice, ...)
• (-) There can be many unforeseen “overlappings” and contradictions between different scenarios– but this can also be the case when we use e.g. temporal logic –
it is an inherent problem of the requirements
• (+) Play-out can help to analyze the behavior emerging from the combination of different scenarios and check for contradictions
26
Modal Sequence Diagrams (MSDs)
• Developed by D. Harel and S. Maoz as a formal interpretation of UML Sequence Diagrams
• Based on the concepts of LSCs– a bit different: no prechart– formalizing especially assert and negate constructs in UML SDs
• Supported by ScenarioTools– with a slightly modified
semantics– which we will introduce
in the following
see Harel, D. & Maoz, S. Assert and negate revisited: Modal semantics for UML sequence diagrams, Software and Systems Modeling (SoSyM), Springer-Verlag, vol. 7, pp. 237-252, 2008
ScenarioTools.org
27
Modal Sequence Diagrams (MSDs)
• Continued in Lecture 9• (All slides hereafter were not covered in the lecture; a more
systematic introduction to MSDs was given in Lecture 9)
28
Modal Sequence Diagrams (MSDs)
• An MSD specification consists of– a set of objects, called the object system
• a subset of objects are system objects, the remaining objects are environment objects
– objects can exchange messages• a message is identified by the sending object, a message name,
the receiving object• we consider only synchronous messages: sending and receiving
is one event, also called message event
– The set of all message is the alphabet, Σ– a set of MSDs; there are two kinds of MSDs
• existential MSDs: describe runs of a system that must be possible• universal MSDs: properties that must be satisfied by all runs
– a subset of MSDs can be assumption MSDs, the remaining MSDs are called requirement MSDs
29
Modal Sequence Diagrams (MSDs)
• Example: Production Cell
ArmA
ArmBplates leave systemon deposit belt
blanks enter systemon feed belt
TableSensor
PressController
ts:TableSensor
a:ArmA
b:ArmB
p:Pressc:Controller
system object
environment object
object system:
30
Modal Sequence Diagrams (MSDs)
• A Modal Sequence Diagram (MSD)– Each lifeline represents an object in the object system
• In universal MSDs, message can have– an execution kind: monitored or executed– a temperature: hot or cold
can be “violated”
hotcoldmonitored
executed
must not be “violated” (safety)may happen
must eventually happen (liveness)
the semantics will become clearer in a few moments...
31
Universal MSD – Semantics by Example
can be “violated”
hotcoldmonitored
executed
must not be “violated” (safety)may happen
must eventually happen (liveness)
blankArrived
c:Controller
pickUp
arrivedAtPress
ArmATransportBlankToPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
ArmA
ArmB
TableSensor
PressController
32
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
ts:TableSensor a:ArmA
cut
ArmATransportBlankToPress
Universal MSD – Semantics by Example
ArmA
ArmB
TableSensor
PressController
• If a message occurs in the system that can be unified with the first message in an MSD, an active copy of the MSD (also called active MSD) is created.– a message in the system can be unified with a message in an
MSD if the message names are equal and the source/target objects are represented by the source/target lifeline
• The cut remembers which MSD messages were unified
blankArrived
33
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/e
ArmA
ArmB
TableSensor
PressController
• If the cut is in front of a message on its sending an receiving lifeline, the message is enabled– if an executed message is enabled, the cut is executed,
otherwise it is monitored– if a hot message is enabled, the cut is hot, otherwise it is cold
ArmATransportBlankToPress
blankArrived
34
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/e
ArmA
ArmB
TableSensor
PressController
• If a message occurs that can be unified with an enabled message, the cut progresses
ArmATransportBlankToPress
blankArrived
35
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/e
ArmA
ArmB
TableSensor
PressController
• If a message occurs that can be unified with an enabled message, the cut progresses
ArmATransportBlankToPress
pickUp
36
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/m
ArmA
ArmB
TableSensor
PressController
• If a message occurs that can be unified with an enabled message, the cut progresses
ArmATransportBlankToPress
moveToPress
37
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/e
ArmA
ArmB
TableSensor
PressController
• If a message occurs that can be unified with an enabled message, the cut progresses
ArmATransportBlankToPress
arrivedAtPress
38
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/e
• If a message occurs that can be unified with an enabled message, the cut progresses
ArmATransportBlankToPress
ArmA
ArmB
TableSensor
PressController
releaseBlank
39
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/m
• If a message occurs that can be unified with an enabled message, the cut progresses
ArmATransportBlankToPress
ArmA
ArmB
TableSensor
PressController
moveToTable
40
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
ArmA
ArmB
TableSensor
PressController
• If a message occurs that can be unified with an enabled message, the cut progresses
• The active MSD terminates when the cut progressed beyond the last message
ArmATransportBlankToPress
arrivedAtTable
41
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
ArmA
ArmB
TableSensor
PressController
• If a message occurs that can be unified with a message in an active MSD that is not currently enabled, this is a violation– violations are allowed in a cold cut, then then active MSD
terminates. This is called a cold violation.– violations are forbidden in a hot cut: safety violation
ArmATransportBlankToPress
blankArrived
h/m
42
Universal MSD – Semantics by Example
blankArrived
c:Controller
pickUp
arrivedAtPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/e
ArmA
ArmB
TableSensor
PressController
• An active MSD must not remain forever in an executed cut– liveness violation
• An active MSD may remain forever in a monitored cut
ArmATransportBlankToPress
pickUp
message event must eventually occur
43
Universal MSD – Iterative vs. Invariant Semantics
• If the first message of an MSD appears also later in the diagram, there may be multiple active copies of this MSD– invariant semantics
• There is also an interpretation of MSDs where only one active MSD copy of an MSD is allowed– iterative semantics
m1
a:A b:B
m2
m1
m3
m1
a:A b:B
m2
m1
m3
m1
a:A b:B
m2
m1
m3
invariant interpretation:
run: m1, m2, m1, ...
44
Universal MSD – Iterative vs. Invariant Semantics
• If the first message of an MSD appears also later in the diagram, there may be multiple active copies of this MSD– invariant semantics
• There is also an interpretation of MSDs where only one active MSD copy of an MSD is allowed– iterative semantics
m1
a:A b:B
m2
m1
m3
m1
a:A b:B
m2
m1
m3
iterative interpretation:
run: m1, m2, m1, ...
45
Concurrently Active MSDs
releaseBlank
c:Controller
PressPlateAfterArmAReleasesBlankPlate
press
pickUp
a:ArmA p:Press b:ArmB
pressingFinished
blankArrived
c:Controller
pickUp
arrivedAtPress
ArmATransportBlankToPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/e
46
Concurrently Active MSDs
releaseBlank
c:Controller
PressPlateAfterArmAReleasesBlankPlate
press
pickUp
a:ArmA p:Press b:ArmB
pressingFinished
h/e
blankArrived
c:Controller
pickUp
arrivedAtPress
ArmATransportBlankToPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/e
47
Concurrently Active MSDs
releaseBlank
c:Controller
PressPlateAfterArmAReleasesBlankPlate
press
pickUp
a:ArmA p:Press b:ArmB
pressingFinished
h/e
blankArrived
c:Controller
pickUp
arrivedAtPress
ArmATransportBlankToPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/m
48
Concurrently Active MSDs
releaseBlank
c:Controller
PressPlateAfterArmAReleasesBlankPlate
press
pickUp
a:ArmA p:Press b:ArmB
pressingFinished
h/m
blankArrived
c:Controller
pickUp
arrivedAtPress
ArmATransportBlankToPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/m
49
Concurrently Active MSDs
blankArrived
c:Controller
pickUp
arrivedAtPress
ArmATransportBlankToPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/m
releaseBlank
c:Controller
PressPlateAfterArmAReleasesBlankPlate
press
pickUp
a:ArmA p:Press b:ArmB
pressingFinished h/e
50
Concurrently Active MSDs
blankArrived
c:Controller
pickUp
arrivedAtPress
ArmATransportBlankToPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
h/m
releaseBlank
c:Controller
PressPlateAfterArmAReleasesBlankPlate
press
pickUp
a:ArmA p:Press b:ArmB
pressingFinished
51
Concurrently Active MSDs
blankArrived
c:Controller
pickUp
arrivedAtPress
ArmATransportBlankToPress
moveToPress
releaseBlank
moveToTable
arrivedAtTable
ts:TableSensor a:ArmA
releaseBlank
c:Controller
PressPlateAfterArmAReleasesBlankPlate
press
pickUp
a:ArmA p:Press b:ArmB
pressingFinished