Playing with Verification, Planning and Aspects

Unusual Methods for Running Scenario-Based Programs

David HarelThe Weizmann Institute of Science

Examples of reactive systems (H & Pnueli, ‘85)

command & control systems

telecommunication systems

avionics & aerospace systems

automotive systems

circuits & VLSI

medical instrumentation

interactive software

. . .. . . . . .

biological systems

commercial systems, health care,…

“Classical” approach

State-based

Intra-object

e.g., Statecharts (H, ‘84)

tool: Rhapsody (H&Gery,‘92)

Newer approach

Scenario-based

Inter-object

LSCs (Damm&H,‘98)

tool: Play-Engine (H&Marelly,’02)

Two dual ways to model reactivity

intra-object behavior(all pieces of stories given for

each relevant object)

This leads naturally to

implementation

inter-object behavior

(each story given for all relevant objects)

Can this be made powerful enough to be

the implementation

?

First, a quick introduction to LSCs, a visual formalism for

scenario-based programming

Most popular visual formalism for requirements:

Message Sequence Charts (MSCs) (CCITT ’92 and before)

(or “ UML Sequence Diagrams)”

Most popular language for formal requirements:

Temporal Logic (Pnueli ’74)

MSC for a quick-dial feature

Click

Click

Keyboard

Click(digit)

Retrieve(digit)

Call(number)

signal

signal not busy

Sent

number

Send Key

MSCs are usually used in practice for testing

As a language for behavioral requirements, they are extremely weak

in expressive power

Semantics is mere partial order on events

Hence, in principle, a system that does nothing at all (or one that does everything) satisfies all

MSCs!

They cannot say:

- under these conditions system must do this

- instance will send message

- message will arrive (within such and such time)

- this is not allowed to happen

- this condition must be true (otherwise abort)

. . .

. . .

. . .

may/must; can/always ;

fragmental and overlapping

scenarios ;

anti-scenarios; etc.

So we need a lot more than MSCs:

Live sequence charts (LSC’s)

“LSC’s: Breathing Life into

Message Sequence

Charts ”

(Damm & H, 1998)

A multi-modal extension of classical MSCs, with logical modalities

(universal/existential, hot/cold, etc.) and structure (subcharts, conditionals,

loops, etc.)

element mandatory

provisional

chart universal

all system runs satisfy chart

existential

at least one run satisfies

chart

A E

element mandatory

provisional

chart universal

all system runs satisfy chart

existential

at least one run satisfies chart

A E

location in chart

hot run of instance must progress beyond location

cold run of instance need not progress beyond

location

message hot

if message is sent it must be received

cold receipt of message is not guaranteed

condition hot condition must be met otherwise abort

cold if condition not met exit current (sub) chart

Basic form of a (universal) LSC

prechart (if)

main chart (then)

(similar to [a]b in dynamic logic)

• Subcharts

• Loops

• Cold conditions enable control structures

• Hot conditions enable anti-scenarios:

False

the forbidden scenario

LSC specification:

LS = M, pc, mod

Set of LSC’s

pc(m) is theprechart

mod(m) is mode of m:

A E

,

Chart m satisfied by system run r :

m existential:

m universal :

System S satisfies specification LS :existential . run . r m

universal . run . r m

.i r i m ‘

. ( ) ( )i r i pc m r i pc m m ‘ ‘

MmMm

SrSr

r m

S LS

inter-object behavior

(one story for all relevant objects)

Can this be made powerful enough to be

the implementation

?

Traditionally, scenario-based behavior was considered

unsuitable for execution, and therefore no good for

implementation

How do you execute a bunch of scenarios?

Work done with R. Marelly (’99-’03) • Extensive strengthening of the language

of LSCs (e.g., symbolic instances, time & real-like time, weighted choice, forbidden elements,…)

• Play-In (friendly & convenient capture)

• Play-Out (algorithm for execution)

• The Play-Engine: A full supporting tool

Basic idea behind play-out

• Play-out works like an over-obedient, but strictly minimalistic citizen, zealously

adhering to the Book of Rules.

• Universal charts drive the execution; relevant chart copies started and monitored continuously; instances & variables unified and bound on the fly.

(external event; step*; stable?) = superstep

• Hot stuff will be done, cold stuff might.

Play-engine can thus be viewed as a “universal reactive machine”.

At the very least, this provides many enhancements to the

conventional system development life-cycle

Such as…

• Convenient GUI-based method for specifying desired behavior

• Ability to execute requirements (actually, “executable use cases”)

• A “deep” kind of rapid prototyping and more solid starting point for design

• Rich language for test generation; execution-based testing (much work done on this in W. Damm’s group)

• Strong basis for synthesis and verification (both groups)

• and more . . .

But one can be more ambitious, and actually use

LSCs as the language for programming (and running)

the system!

Come, Let’s Play :Scenario-Based Programming Using LSCs

and the Play-Engine

D. Harel and R. Marelly

Springer, June 2003

(includes the Play-Engine software)

2003 book attempts to describe it all (including formal semantics: )

The problem with naïve play-out

• LSCs are inherently declarative and non-deterministic: They may give rise to different legal runs, even within supersteps, due to partial order within a chart, and multiple charts interleaving.

• The Play-Engine takes a practical approach: implements policies and heuristics to execute system runs, not controllable by the user (unless programmed explicitly into the LSCs).

This talk:Three unusual ways to address this

problem(using, respectively, hard-core CS, AI

techniques, and a very different programming paradigm) • Smart play-out (uses model-checking)

• Planned play-out (uses planning algorithms)

• Compilation (uses aspect-oriented programming)

I. Smart Play-out(with H. Kugler, A. Pnueli & R. Marelly, ‘02)

We apply powerful methods taken from program verification (model checking, to be precise) to help find the “correct” run or

identify inconsistencies

So we use verification, but not to prove or analyze programs. We use it to run them!

Mapping to a transition system

Variables:

- chart mi is active (in main

chart)

- Oj sends msg to Ok

- Ok receives msg from Oj

- Oj‘s location (0 . . . lmax )

Translation relation

Translation relation (cont.)

There is an active chart causing msg, and all active charts must agree on msg

Chart activation Chart is active when the prechart reaches maximal locations, and is deactivated when the main chart reaches maximal locations.

Final step

Ask the model checker to prove that at any time, at least one of the universal charts is still active:

If this is true, there is no way to proceed, but if it isn’t the model-checker finds a counter-

example, which is exactly a desired superstep!

The resulting sequence of events is then fed automatically to the Play-Engine for execution

A wonderful illustration of smart play-out

Being smart helps

II. Compilation via Aspects(with S. Maoz, ‘06)

We exploit the similarities between aspect-oriented programming and the inter-object

nature of LSCs, by compiling LSCs into AspectJ

“Scenario aspects” are used to coordinate the simultaneous monitoring and direct

execution of the LSCs.

• Each chart is compiled into a Scenario Aspect– Pointcuts capture message calls + context– Corresponding advice advances the cut state

• A central Coordinator aspect is built, containing– A single pointcut to “catch” all message calls– An advice that collects cut state information

from all active scenarios, and uses a strategy to choose the next method to execute

Actually, our compiler does not work on LSCs, but on a UML 2.0-complient variant, called MUSDs (H & Maoz, ‘06)

The resulting code follows the naïve play-out execution strategy, but we

are working on a mechanism for parameterizing strategies

public aspect MUSDAspectExample extends MUSDAspect { //... pointcut objAobjBmethodM1 (ClassA s, ClassB t):

call(void classB.methodM1())&& this(s) && target(t);

after (ClassA s, ClassB t): objAobjB1methodM1(s , t) {changeCutState(MUSDMethod.CLASSA_CLASSB_M1, s, t);}

//... private void changeCutState (int MUSDMethod, Object

sourceObject, Object targetObject) { //... switch (MUSDMethod) { case MUSDMethod.CLASSA_CLASSB_M1:

if (isInCut(0,0,0)) { objB1 = (ClassB)targetObject;

setCut(1,0,1); return;}if (isInCut(1,0,1)) { objB2 = (MemoryCard)targetObject;

setCut(1,1,2); if (!objB1.isFoo(objB2)) { setCut(2,2,3); return;

}}break;

case MUSDMethod.CLASSA_CLASSB_M2 ://...

} MUSDCompletion(); //... }//...}

objA:ClassA

Example

objB1:ClassB objB2:ClassB

methodM1()

methodM1()

methodM2()

methodM3()

!objB1.isFoo(objB2))

Sample scenario aspect

Compilation to AspectJ

We adapt a planning algorithm (specifically, Graphplan) to do what smart play-out does;

e.g., to plan and execute a superstep

However, here we are able to detect and generate all solutions, if so desired.

We’ve also set-up a user-guided exploration mechanism for traversing supersteps

III. Planned Play-out(with I. Segall, ‘06)

(ack: Orna K.)

Planning graph

Move (R1, R2)

Insert (B, R1)

Insert (A, R1)

At (A, R1)

At (B, R1)

At (Bag, R1)

In (A)

In (B)

At (Bag, R2)

At (A, R1)

At (B, R1)

At (Bag, R1)

PropositionsTime 1

Actions Time 1

Propositions time 2

Actions Time 2

Propositions time 3

Actions Time 3

Propositions time 4

Move (R1, R2)

Insert (B, R1)

Insert (A, R1)

At (A, R1)

At (B, R1)

At (Bag, R1)

In (A)

In (B)

At (Bag, R2)

Remove (B, R2)

Remove (A, R2)

At (A, R2)

At (B, R2)

In (A)

In (B)Proposition LevelsAction Levels

Propositions True at time 1Possible actions at time 1Precondition edges

Add edgesDelete edges

No-op edges

Result: Propositions possibly true at time 2

Mutual exclusions

• Mutex Actions: never chosen together in a timestep

• Mutex Propositions: never true together in a timestep

Mutex example

Move (R1, R2)

Insert (B, R1)

Insert (A, R1)

At (A, R1)

At (B, R1)

At (Bag, R1)

In (A)

In (B)

At (Bag, R2)

At (A, R1)

At (B, R1)

At (Bag, R1)

Move (R1, R2)

Insert (B, R1)

Insert (A, R1)

At (A, R1)

At (B, R1)

At (Bag, R1)

In (A)

In (B)

At (Bag, R2)

Remove (B, R2)

Remove (A, R2)

At (A, R2)

At (B, R2)

In (A)

In (B)

PropositionsTime 1

Actions Time 1

Propositions time 2

Actions Time 2

Propositions time 3

Actions Time 3

Propositions time 4

Interference AInterference BMutex PropositionsCompeting Needs

Plan extraction

Move (R1, R2)

Insert (B, R1)

Insert (A, R1)

At (A, R1)

At (B, R1)

At (Bag, R1)

In (A)

In (B)

At (Bag, R2)

At (A, R1)

At (B, R1)

At (Bag, R1)

Move (R1, R2)

Insert (B, R1)

Insert (A, R1)

At (A, R1)

At (B, R1)

At (Bag, R1)

In (A)

In (B)

At (Bag, R2)

Remove (B, R2)

Remove (A, R2)

At (A, R2)

At (B, R2)

In (A)

In (B)

PropositionsTime 1

Actions Time 1

Propositions time 2

Actions Time 2

Propositions time 3

Actions Time 3

Propositions time 4

Planned play-out

naïve smart

LSC featurenaïve

play-outcompilati

on to AspectJ

smart play-out

planned play-out

Execution strategy

Kernel (msgs +

conds) -variables in msgs

-if, choice, etc.

-loops

-multiple copies

-symbolic instances

-time (discrete)

-forbidden elements

-probabilistic choice

✓✓✓✓✓✓✓✓✓

✓✓✓✓

✓✓

✗✗

✗

hard

✓

✓

✗✗✗✓

✗

✗

✓✗

hard

hard

not bounde

d

Status of current Play-Engine implementation

✓✓✓✓✓✓✗

✗

easy

easy

✗ easy

++

The two smart methods exhibit rather severe time complexity

My feeling: some powerful idea, awaiting discovery, is needed to

help ease performance

Which of the methods will turn out to be best?

And what does “best” even mean?

The jury is still far from being in. Stay tuned…

Thank you for listening