Top Banner
From Triggered Scenarios to Modal Transition System German Sibay
36
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Resg ph d_seminar2010_germansibay

From Triggered Scenarios to Modal Transition System

German Sibay

Page 2: Resg ph d_seminar2010_germansibay

Agenda

Motivation Previous Work Our Work Conclusion Future Work

Page 3: Resg ph d_seminar2010_germansibay

Motivation Software is everywhere

– Nuclear power stations

– Mobile phones

– Banking Design and development of software is

hard Models are key in engineering

(abstraction)

requirements

Behaviour Models

analysis

Page 4: Resg ph d_seminar2010_germansibay

Behaviour Models Pros

– Abstraction

– Build complexity: model < system

– Basis for (semi)automatic analysis techniques:

• Model checking

• Simulation

– Analysis of behaviour previous to construction

• Early detection

Cons

– Requires expertise

– Intra-agent behaviour specification

– Hard to build

Page 5: Resg ph d_seminar2010_germansibay

Behaviour ModelsPerception: cons > pros

Possible cause of low adoption by practitioners

Page 6: Resg ph d_seminar2010_germansibay

6

What do practitioners use?

Scenario notations, Use Cases Inter-agent specification Simple syntax Intuitive semantics MSC, UML Interaction Diagram

Actuator

User

Retrieve money

Pay Bills

Page 7: Resg ph d_seminar2010_germansibay

7

Scenario notations

pros:

– Easy syntax, intuitive semantic

– Popular among practitioners cons:

– Generally informal (no suitable for formal analysis)

– Example of execution (not comprehensive)

– Limited expressiveness

Page 8: Resg ph d_seminar2010_germansibay

Summary

requirements

Behaviour Models

analysis

Page 9: Resg ph d_seminar2010_germansibay

9

Proposal: Synthesis from Scenarios

synthesis

Behaviour Models

scenarios scenario notation

requirements

analysis

Page 10: Resg ph d_seminar2010_germansibay

10

Our Contribution

1. Novel Scenario Language with Trigger- Tree based semantics,

allows existential and universal with trigger

2. Synthesis algorithm for the new Language- Characterising all models

that satisfy the scenario

synthesis

Behaviour Models

scenario notation

Page 11: Resg ph d_seminar2010_germansibay

11

Scenario Language: Basic Chart

Example of execution (MSC, UML Seq. Diag.) Partial order semantics Defines a finite language of finite words

{ pwd verify verifying wait ok , pwd verify wait veryfing ok }

Page 12: Resg ph d_seminar2010_germansibay

12

Scenario Language with Prechart (or Trigger)

Live Sequence Chart (LSC):

– Existential Live Sequence Chart (eLSC)

•Example of a system run ≈ MSC

– Universal Live Sequence Chart (uLSC)

•Rule for all system runs ≈ Property

Page 13: Resg ph d_seminar2010_germansibay

13

Existential Live Sequence Chart (eLSC)

Trace based semantics:interaction described by the scenario must be present somewhere in the trace

A set of traces satisfy if at least one satisfies

Page 14: Resg ph d_seminar2010_germansibay

14

Universal Live Sequence Chart (uLSC)

Prechart

Mainchart

… pwd verify nok pwd verify nok pwd verify nok

x pwd verify ok …

Trace based semanticsEvery time the Prechart holds, the Mainchart must follow next

A set of traces satisfy if all satisfy

Page 15: Resg ph d_seminar2010_germansibay

15

Labelled Transition System (LTS) as a set of traces

A LTS defines a set of traces

LTS satisfy the scenario if its set of traces do it:

- uLSC: All traces satisfy the scenario - eLSC: At least one trace satisfy the

scenario

Page 16: Resg ph d_seminar2010_germansibay

16

Models and Scenarios

bdc dc(dc)∞ bc … x

0 1 2

.

.

.

A trace does not satisfy

the model does not satisfy the uLSC

uLSC

Page 17: Resg ph d_seminar2010_germansibay

17

Models and Scenarios

bdc dc(dc)∞ bc …

0 1 2

.

.

.

There is a trace that satisfies

the model satisfies the eLSC

eLSC

Page 18: Resg ph d_seminar2010_germansibay

18

New language: Motivation eLSC not very expressive.

Just an example of a user that logs in and retrieves money

Page 19: Resg ph d_seminar2010_germansibay

19

New language: Motivation uLSC may be too restrictive

… pwd verify wait verifying wait ok getBalance() … x

Every time the user logs in, must try to retrieve money (and succeed)

Page 20: Resg ph d_seminar2010_germansibay

20

Existential Triggered Scenario (eTS)

P

M

Execution tree based semantics:Every time the Trigger holds, there must exists an execution branch where the Mainchart holds next

Page 21: Resg ph d_seminar2010_germansibay

21

Does the model satisfy the eTS?Does its tree satify the eTS?

b

dc

Page 22: Resg ph d_seminar2010_germansibay

22

eTS: Summary Rule over entire system-to-be behaviour

Requires possibility of Mainchart when Prechart holds

Complementary to uLSCuLSC – LTL formula eTS - CTL formula

Semantics ≈ Use Cases with preconditions

Page 23: Resg ph d_seminar2010_germansibay

23

Universal Triggered Scenario (uTS)

P

M

Execution tree based semantics:Every time the Trigger holds, only the Mainchart can come next. Also every word in the Mainchart must be in at least one branch

Page 24: Resg ph d_seminar2010_germansibay

24

Universal Triggered Scenario (uTS)

Does this tree satify the uTS?

b

dcNO

Page 25: Resg ph d_seminar2010_germansibay

25

TS extension

Conditions in the Trigger: Fluent Propositional Logic formula

uuserLoggedIn

Page 26: Resg ph d_seminar2010_germansibay

26

Synthesis from TS

synthesis

TS

Behaviour model

Page 27: Resg ph d_seminar2010_germansibay

27

Synthesis from this eTS

d

c

b

Page 28: Resg ph d_seminar2010_germansibay

28

Synthesising a LTS Several LTS satisfy the scenario

Choosing one is taking an arbitrary decision

Choosing one that characterises them all (through simulation or trace inclusion) does not work

Page 29: Resg ph d_seminar2010_germansibay

29

Solution: synthesise a Modal Transition System (MTS)

Extend LTS with an extra set of transitions

Required or Must transitions

Possible or May transitions

An LTS L is an implementation of an MTS M if

– all required behaviour in M is in L, and

– all behaviour in L is possible in M

request?reply?

request

reply

request

reply

request

reply

request

reply

Page 30: Resg ph d_seminar2010_germansibay

30

MTS have a refinement relation: “more defined than”

MTS refinement preserves implementation

Solution: synthesise a MTS

request?reply?

Re

fin

ed+

-

request

reply

request

reply

Implementations (LTS)

request

reply

request

reply

request?reply?

Page 31: Resg ph d_seminar2010_germansibay

31

MTS refinement preserves scenarios

Refinements

TS

LTSs: Satisfy the scenario

Synthesis

satisfies

MTSCharacterises

LTSsthat satisfy the

TS

Page 32: Resg ph d_seminar2010_germansibay

32

Combining scenarios

Synthesised MTSs

Refinements

TS

Refinements

TS

Merge

Page 33: Resg ph d_seminar2010_germansibay

33

Combining properties and scenarios

Synthesised MTSs

Refinements

Refinements

FLTL property

Merge

TS

Page 34: Resg ph d_seminar2010_germansibay

34

Methodology

Synthesis

Feedback

Elaboration

Model Checking,Simulation,Animation

Validation

eTS

FLTL properties

uTS

Page 35: Resg ph d_seminar2010_germansibay

Summarising New scenario-based

language

– based on LSC with branching semantic

– TS have existential with trigger

– Existential Fits with Use Case w/Preconditions

MTS Synthesis algorithm– No arbitrary choice

of LTS

– Characterisation of all LTSs satisfying TS

– Allows evolution through refinement

– Allows integrating multiple sources (merge)

Applicable to other scenario notations

35

Page 36: Resg ph d_seminar2010_germansibay

Future Work Distributed

Synthesis– Problems of

composition of MTS (not complete)

– Distributed synthesis with trigger is tricky

Synthesise using scenarios and Architecture Diagrams

36