java code generation from formal models: the co-opn framework

Java Code Generation from Formal Models

The CO-OPN Framework

Ang Chen, Matteo Risoldi, Didier BuchsSystem Modeling and Verification Group

University of Geneva, Switzerland{ang.chen, matteo.risoldi, didier.buchs}@cui.unige.ch

PrinciplesandPracticesofProgramminginJavaSept.05-07,2007Lisbon,Portugal

PPPJ2007,Sept.05-07,Lisbon,Portugal SMVGroup,UniversityofGeneva,Switzerland

Objective of this tutorial

• Present a framework to develop concurrent, transactional systems and applications from high-level concurrent models to executable Java code

• Show the advantages of model-based development with formal models such as Petri nets:

• Precise semantics, non-ambiguity

• Platform independent

• Automatic model checking, test, and code generation (model transformation)

2


Outline

• Part I: Manage Concurrency with Petri Nets

• Petri nets for concurrent modeling

• From PN models to concurrent Java programs

• Part II: Concurrent Object-Oriented Petri Nets

• Modeling transactional systems with CO-OPN

• CO-OPN code generation framework

• Conclusion

3

Part I:Manage Concurrency with

Petri Nets

4


Concurrent System• The world is concurrent

• Autonomous: the system runs independently from others

• Reactive (or interactive): it reacts to external events and actions

• Parallel: things (events, actions) happen in parallel

• Example: distributed computers, control system (e.g. aircraft), workflow

• In computer science, concurrency means resources sharing which may cause race conditions

5


Java Concurrency Utilities (JSR 166)

• Tasks scheduling, e.g. Executor

• Concurrent collections

• Atomic variables

• Semaphores, barriers, latches, exchangers

• Locks

Threads

Data Structures

Synchronizers

6


Why Formal Models?

• Concurrent and distributed systems are complex, difficult to develop and manage

• To ensure the safety of critical systems, e.g. prove that the system can operate without failures before implementation

• Widely used formal methods: relational algebra in DB, boolean algebra in circuit design, Finite State Machines in many systems ...

7


Petri Net: Definition

• A Petri net is a directed bipartite graph (P, T, F, M):

• P is a finite set of places

• T is a finite set of transitions

• P and T are disjoint, (P∩T =Φ)

• F⊆(P×T)∪(T×P) is the flow relation

• Marking M is the distribution of tokens in the PN

• Token is defined according to the type of PN

8


Petri Nets: Basic Notations

Transition Place Flow(Arc)

Token

A transition is enabled when sufficient tokens are available from its input places.A transition consumes its pre-set tokens and produces post-set tokens.

9


PN: Concurrency

T1P1 P3

T2P2 P4

T1 and T2 are concurrent and independent

Simultaneously enabled and firable transitions are called concurrent

10


PN: Concurrency

T1

T2

P1

T1 and T2 are simultaneously enabled,but they have a conflict on P1

Interleaving

11


PN: Concurrency

T1

T2

P1

T1 and T2 are simultaneously enabled,but they have a conflict on P1

The can be fired concurrentlyonly when sufficient resources are available in P1 (e.g. >=2 tokens)

12


PN: Join

• When a transition has multiple incoming flow

T3 is not enabled until both T1 and T2 have terminated. Also called barrier, join point, rendez-vous

T1 P1

P3

P2T2

T3

13


PN: Split

• When a transition has multiple outgoing flow

T1 P2

P3

P1

Also called fork or parallel splite.g. creating new threads, parallel tasks

14


PN: Non-determinism

• When a place has multiple outgoing flow

Consumer 1

resourcecontainer

Producer Consumer 2

Consumer 3

?

15


Petri Nets: Modeling• Different PN formalisms propose different constraints for

place, token, and firing rules.

• Petri net models and their properties are independent of the application domain

• For a concrete application domain, an operational semantics or interpretation is needed for the PN formalism

This is a deadlock-free PN

What is the meaning of each place, transition, token, and flow?

16


Petri Net: Modeling

• For example, in workflow and manufacturing systems, we use:

• Transitions to represent tasks; places to represent steps

• Tokens to represent documents and physical objects

receiveorder

schedule

shippingschedule

productionschedule

collectpayment

order

payment

invoice

sendinvoice

createinvoice

An E-Commerce Workflow17


Petri Nets: Applications

RailwayNetwork

Telephony System Communication

Protocol

Petri NetsTheory

Control SystemDistributed

System

Workflow

We will apply the Place/Transition Nets for the problem of concurrent programming

Concurrent Programming

18


Place/Transition Net

• Tokens are indistinguishable

• The marking of a place is represented by an integer n≥0, the number of tokens in the place

• The incoming arcs increase the value of n

• The outgoing arcs of a place decrease the value of n

01210

19


Place/Transition Net

• For concurrent systems, each place can be seen as a semaphore and each transition can be seen as a process

Process A Process Bsemaphore

2acquire

release

acquire

release

release acquire

20


PN in Concurrent Programming: Rules

• Rule 1: Each transition is a schedulable task which tries to consume resources from its input flow

• Rule 2: Simultaneously enabled transitions are concurrent or in conflict

• Rule 3: The task is hanged if the necessary resources are not available

• Rule 4: The task is eligible to run if it is enabled (acquired all necessary resources)

TP1 P2

while(true) {if (all pre-tokens are ready) {

P1.take() ...P2.put() ...

} else suspend();}

21


PN in Concurrent Programming: Rules

• Rule 5: The acquisition of resources is sequential and transactional, i.e. the taken resources are released in case of failure

• Rule 6: The output flow of a transition will produce or release resources to the corresponding places, it is also sequential and transactional

Conflicts on multiple resources may imply deadlocks during sequential execution:

T3 is holding P1 and waiting on P2 T4 is holding P2 and waiting on P1

Thus, a transition should release its taken resources in case of failure.

T3

T4

P1

P2

P3

P4

22


Translate Places toJava Classes

• A place can be:

• a synchronizer, e.g. Lock, Semaphore

• or a concurrent data structure, e.g. BlockingQueue, Atomic variable

• The access to places is concurrent

public class P implements InFlow, OutFlow { public void InFlowAction(){ // method of InFlow // e.g. l.unlock(), semaphore.release(), queue.give()... } public void outFlowAction(){ // method of OutFlow // e.g. l.lock(), semaphore.acquire(), queue.take() ... }}

inFlowAction() outFlowAction()P

23


Translate Transitionsto Java Class

• A transition can be:

• Autonomous(e.g. thread): it tries to fire whenever possible

• Event-Driven: it fires when someone calls it

public class T implements Runnable { public void fire(){ // event-driven // consume input resources if there are, e.g. P1.outFlowAction()

// produce output resources if there are, e.g. P2.inFlowAction() } public void run(){ // autonomous

while(true) { ... fire(); ... } }}

T

24


Queue with capacity 2

Example: Place as BlockingQueue

producer consumer

put take

outFlowAction: take

inFlowAction: put

Tool PNML2Java: Generate multi-threads Java program from Place/Transition Net

25


Translation of PN to Java Concurrent Program

Petri Nets JavaAutonomous transition Runnable Class

Event-Driven transition Class Method

Place Lock, Semaphore, BlockingQueue, Synchronized Channel ...

Token Thread-safe data and resources

Deadlock-free PN Deadlock-free program

26


Dining Philosophers

• 5 philosophers sitting around the table with 5 forks

• each philosopher passes time for thinking and eating

• in order to eat, he or she should have the left-side fork and the right-side fork in hands

• after eating, the two forks are released

• Deadlocked when each philosopher is holding one fork and waiting for the other one and nobody releases a fork

27


Statement I

“If all the philosophers are leftie* or all of them are rightie, the system has

deadlock”

Is it true?

How to prove it? Manually or automatically?

28

*A leftie takes the left fork first, then the right fork; the contrary for a rightie.


A Philosopher (Leftie)

Thinking

Eating

GoThinking

Left Fork Right Fork

Take Left

Take Right

While(true) {TakeLeft();TakeRight();eating ...GoThinking();

}

29


Thinking

Eating

GoThinking

Take Left

Take Right

Thinking

Eating

GoThinking

Take Left

Take

Right

Thinking

Eating

GoThinking

Take Left

Take

Right

Thinking

Eating

GoThinking

Take Left

Take RightTh

inking

Eating

GoTh

inking

Take Left

Take Righ

t

Fork 0

Fork 1

Fork 2

Fork 3

Fork 4

Philosopher 0

Philosopher 1 Philosopher 2

Philosopher 3

Philosopher 4

PN: 5 leftie at the table

Deadlock found with PN model-checking.

The shortest path to deadlock is given.

Tool used: Platform Independent Petri net Editorhttp://pipe2.sourceforge.net/

30


Statement II

“It will be deadlock-free if there are at least one leftie and at least one rightie at

the table”

Is it true?

How to prove it?

31


PN: 1 rightie + 4 leftie at the table

Philosopher 0 is a rightie

Deadlock-free proved by PN model-checking

Thinking

Eating

GoThinking

Take Left

Take Right

Thinking

Eating

GoThinking

Take Left

Take

Right

Thinking

Eating

GoThinking

Take Left

Take

Right

Thinking

Eating

GoThinking

Take Left

Take RightTh

inking

Eating

GoTh

inking

Take Righ

t

Take Left

Fork 0

Fork 1

Fork 2

Fork 3

Fork 4

Philosopher 0

Philosopher 1 Philosopher 2

Philosopher 3

Philosopher 4

32


Statement II

“If only 4 philosophers are allowed at the table at a time, deadlock is

impossible”

Is it true?

How to prove it?

33


More Statements

“If a philosopher takes the two forks at the same time, deadlock is impossible”

Are these statements true?

Build the PN models and verify them!

“If the philosophers can communicate with each other and ...”

34


Part I: Summary• PN for concurrent programming:

1. Use Petri net to design concurrent programs: threads, semaphores, locks, channels. Do model checking for liveness, deadlock-freedom, fairness etc.

2. Generate project skeleton from the correct PN model

3. Implement the functionalities of threads without thinking about concurrency

• This principle only works with Place/Transition Nets

• What is still missing: encapsulation, transactional behavior, system coordination

35

Part II:Concurrent Object-Oriented Petri Net

36


CO-OPNConcurrent Object-Oriented Petri Nets

• OO modeling language based on Petri Nets

• Algebraic Abstract data types

• Concurrency, transactionality

• Can generate Java code

37


CO-OPN Modules

• Classes - encapsulate a Petri Net - have methods and gates (events)

Producer

produce

produce

ready

give

r

r

Class Producer;Interface

Methodsproduce;

Gatesgive;

BodyPlaces

ready[...]End Producer;

38


CO-OPN Modules

• Contexts - instantiate and coordinate objects

P

produce

produce

ready

give

r

r

C

use consumedr

ProducerConsumerSystem

produce

Context ProducerConsumerSystem;Interface

Methodsproduce;

[...]Body

ObjectsP: Producer;C: Consumer;

Axiomsproduce with P.produce;P.give with C.use;

[...]End ProducerConsumerSystem;

39


CO-OPN Modules

• ADT (Abstract algebraic Data Types) - define data types (primitive + structured)

• Generators

• Operations

• Theorems

• Algebraic definition of data

ADT Booleans;Interface

Generatorstrue:->boolean;false:->boolean;

Operations_ and _: boolean, boolean -> boolean;

[...]Axioms

true and b = b;false and b = false;

[...]End Booleans;

40


produce

CO-OPN

P B C

produce

produce

take

get

put use

consume

ProducerConsumerSystem

consume

ready available consumed

give out

r

rr r r

get

41


CO-OPN Axiom syntax in brief

Condition => transition with event :: pre -> post ;

ConditionAny boolean expression evaluated on tokens,

parameters, values...

TransitionA method call or an event

EventOne or more method calls or events

PrePrecondition of the transition,

evaluated on tokens in the places

PostPostcondition of the transition,

evaluated on tokens in the places

Ex.=> produce with give :: ready t -> ready t ;

Producer

produce

produce

ready

givet

t

42


CO-OPN Transactions Operators

Parallel // : m1//m2, m1 and m2 occur simultaneously, i.e. concurrent access of resources

Sequence .. : m1..m2, m2 occurs after the success of m1

Alternative + : m1 + m2, m1 or m2 can have success (nondeterministic)

Ex: => m with m1//m2:: ->;

• ACID* Properties respected

*Atomicity, Consistency, Isolation, Durability

43


CO-OPN Transactions

transition with event1 .. (event2 // event3)

What happens to transition, event1 and event2 if something in event3 fails?

44


CO-OPN Transactions

• Transactional semantics: firing a transaction results in either:

• success: at least one solution found

• failure: no solution found

• A solution is a resource allocation plan for the transaction

• Try to achieve "success" plan, until no more plans are possible

45


CO-OPN Transactions

superMarket

buyFood

meatEmpl cheeseEmpl

.. ..

buyMeat buyBrie buyGruyère

success scenarioM:meat C:cheese

E1 E2 E3

=> buyFood with M.buyMeat .. (C.buyBrie .. C.buyGruyère) :: -> ;=> buyMeat :: meatEmpl E1 -> meatEmpl E1;=> buyBrie :: cheeseEmpl E2 -> cheeseEmpl E2;=> buyGruyère :: cheeseEmpl E3 -> cheeseEmpl E3;

E1E2 E3

46


CO-OPN Transactions

superMarket

buyFood

meatEmpl cheeseEmpl

.. //

buyMeat buyBrie buyGruyère

failure scenarioM:meat C:cheese

E1 E2 E3

=> buyFood with M.buyMeat .. (C.buyBrie // C.buyGruyère) :: -> ;=> buyMeat :: meatEmpl E1 -> meatEmpl E1;=> buyBrie :: cheeseEmpl E2 -> cheeseEmpl E2;=> buyGruyère :: cheeseEmpl E3 -> cheeseEmpl E3;

E1E2 E3

47


CO-OPN example

The roller coasterproblem

48


The roller coaster(single car)

• 5 passengers,1 car

• The passengers repeatedly wait to take rides in the car, which can hold 4 passengers

• The car can go around the tracks only when it is full.

49



• Passengers cannot board until the car has invoked load()

• The car cannot depart until 4 passengers are onboard

• Passengers cannot unboard until the car has invoked unload()

board()unboard()

passenger

load()unload()run()

passengers: intcar

enters

50



Object diagram

Passenger state machine

Car state machine

passengers=0c: car

p1: passenger

p2: passenger

p3: passenger

p4: passenger

p5: passenger

boardedoffboard

board

unboard

loadingunloading

running

load[passengers=0]

run[passengers=5]

unload

51


The roller coaster (in CO-OPN)

C

rollercoaster

p1:passenger

wantToExit

board

offboard

board

boarded

unboard

wantToEnter

unboard

p2:passenger

wantToExit

board

offboard

board

boarded

unboard

wantToEnter

unboard

p5:passenger

wantToExit

board

offboard

board

boarded

unboard

wantToEnter

unboard

[...]

unload

c:car

run

0

runningunloading

passengers

exit enter

load

run[n=4]

load[n=0]

unload

nn

nn

exit[n>0]

enter[n<4]

nn-1 n+1

nloading

runload

unload

unboard _ board _

52


Demo

53


CO-OPN InterfaceMethods

Gates

✦ The visible part of a module, as Java interface✦ Provided Services (incoming signals): Methods✦ Requested Services (outgoing signals): Gate✦ Services can have parameters, specified by its signature

54


Car: Interface

Generated Java Class

public class Car { // the methods may throw the // runtime exception “MethodNotFirableException”

public void load() { // codes for axioms ... }; public void unload() { // codes for axioms... };public void run() { // codes for axioms ... };

}

Car

load unload

run

CO-OPN ModuleInterface

Methodsload, unload, run

BodyAxioms

load:: ......

55


Integration of Prototype

Car car=new Car(...);try {

CoopnTransaction T=new CoopnTransaction();car.load(T);T.commit();

} catch (CoopnMethodNotFirableException e) {System.out.println(“Car loading fails”);

}

Create a Car object and try to call its load() method

56


CO-OPN to Java Translation

• Names preserved if possible

• Modular structure preserved

• CO-OPN Module ⇒ Java classes

• Component architecture preserved

• CO-OPN Methods ⇒ Java methods

• CO-OPN Gates ⇒ Java Events

• Weird aspects hidden as possible

• non-determinism, atomicity, backtracking ...

57


Example of backtracking and non-determinism

0,1,2 1,2,3

out_ _: natural, natural

m_: natural

x yx+y=z?

P1 P2 Initial marking: P1{0,1,2}, P2{1,2,3}(x+y)=z :: m z with this.out x y :: P1 x, P2 y ->The token selection is nondeterministic

Method m z will trigger the gate out x y and output the tokens which satisfy the condition: x+y=z

Possible solutions:m 3 with out (0,3) or (1,2) or (2,1)m 2 with out (0,2) or (1,1)

58


Axiom TranslationCondition :: method with sync. :: pre -> post

(x+y)=z :: m z with this.out x y :: P1 x, P2 y ->Example:

0,1,2 1,2,3

out_ _: natural, natural

m_: natural

x yx+y=z?

P1 P2

z = 3;for (x: tokens in P1){

for (y: tokens in P2){if (x+y==z) { // check guard condition

SaveStackState();this.out(x,y);return;

}}

}throws new NotFirableException();

Variable binding when calling “m 3”:

59


Axiom Evaluation Strategy

Bind variables with input parameters

Bind variables with available pre-tokens

incoming call

Check guard conditions

all variables are bound

try nextbinding

guard not OK

Call synchronized transactions

guard OK

CommitProduce post tokens

sync.succeeds no

binding possible

Failed

sync. fails

60


Transaction TreeAn example of COOPN transaction tree

Places

P_: natural, P1_: natural , P2_: natural

Initial

P 0, P1 0, P2 0;

Methods

m, m1, m2, m3, m4, m5, m6

Gates

g1_: natural, g2_: natural

m with m1 // m2 :: P x -> P x

m1 with m3 .. m4 :: P1 x, P1 x+1

m2 with m5 + m6 :: P1 x, P1 x+2

m3 :: P1 x -> P1 x+3

m4 :: P1 x -> P1 x+4

m5 with g1 x :: P2 x -> P2 x+5

m6 with g2 x :: P2 x -> P2 x+6

m

with

//

m1 m2

m3 m4

m5 m6

with

..

with

+

with with

g1_ g2_

allocation order

61


Eligibility of Tokens during Transactions

• During the exploration of the transaction tree, the rules to determinate the eligibility of token are:

• All reserved tokens are not eligible

• Tokens produced by the simultaneous transactions are not eligible, e.g. With and //

• Free tokens produced by precedent sequential transactions are eligible

• E.g. in seq1..(sim1//sim2), tokens produced by seq1 are eligible for transaction sim1 and sim2. However, sim1 and sim2 may have concurrent access of the tokens.

62


CO-OPN Runtime Architecture

User Application

Java Platform and APIs

OtherComponents

The generated code can be annotated by

CO-OPN specifications

Concurrency and Transactionality are managed

here!

CO-OPN Runtime Classes

GeneratedCode with Annotations

63


The CO-OPN Prototyping Framework

Real-world

ProblemFormal Model

Description

Modeling

Prototype Adaptation and Integration

Code Generation

Executable Prototype

UserApplication

Component Component

DevelopmentRefinement

Model Checking

Verification

Test

Test Generation

64


The CO-OPN Prototyping Framework

• Modeling - Verification - Prototyping - Integration

• From model to implementation

Modeling Verification

Code Generation

Adaptation &Integration

Prototype

Model

65


Conclusion

• Formal models with rich expressive power provide facilities for model-driven development for:

• test generation and model checking

• automatic code generation

• rapid system prototyping

• incremental, iterative development

• Cost effective for safety-critical systems

66

Thank you.Question time.

67


Backup slides

68


Life-Cycle of Tokens

ReservedFreeproduce consume

reserve

rollback

Operationally, PN transitions uses the 2 phases commit protocol to

avoid deadlocks

T3

T4

P1

P2

P3

P4

69


CO-OPN to Java Translation

• Declarative Language ⇒ Imperative Language

• Operational aspects

• Logical term evaluation (e.g. conditions) and backtracking

• Implementation of atomicity and nested transactions

• Event-driven execution & simulation

• Architectural aspects

• Service-oriented architecture: interface, methods, gates

• Reusable & substitutable components

70


Tokens Stamping

• There are 4 kinds of tokens in the system

• Free initial tokens

• Reserved initial tokens

• Free intermediate tokens

• Reserved intermediate tokens

71


Token Life-Cycle in Transactions

<free, initial>

<free, produced>

<reserved, initial>

<reserved, produced>

removedabort

reserve

abortcommit

abort reservecommit

initial tokens

produced tokens during the transaction

72

java code generation from formal models: the co-opn framework

Education