1

CO-OPN: Concurrent CO-OPN: Concurrent Object-Oriented Petri NetsObject-Oriented Petri Nets

Giovanna Di Marzo Serugendo

University of Geneva, Switzerland

(Courtesy of Didier Buchs, EPFL, Switzerland)

Lisbon, 11th September 2002

2

Contents

CO-OPN Synchronised Petri Nets Contexts

Semantics

Simulator / Prototyping

CO-OPN Framework

3

CO-OPN Specification Language

CO-OPN: Concurrent Object-Oriented Petri Nets

Data Structures = Algebraic Abstract Data Types

Concurrency (Intra- Inter-), Control = Algebraic Petri Nets

Modularity = Object orientation with strict encapsulation

Dynamicity = References, Object Creation

Communication = Synchronisation between Objects

Distribution = Contexts = Units + Localisation + Migration information

CO-OPN = Data Structures + Petri Nets + Object Orientation + Contexts

4

CO-OPN: Why?

Development of embedded systems

Use of a formal notation Suitable for formal verification Suitable for code generation

Test the prototype behaviour in the target execution environment

A formal notation : CO-OPN (graphical, textual)

5

Synchronised Petri Nets

MethodMethodSynchronisation

move(t) with O2.put(t) put(r)

O1 O2

p1 p2

t

t1t3

t2

r

s

processing Transition

Objects

6

Synchronised Petri Nets

move(t) with O2.put(t) put(r)

O1 O2

p1 p2

t

t1t3

t2

r

s

processing

t2X

7

Controller

DD Components Controller DC - Drink Container MB - Money Box SB,RB - Buttons LCD - Display SP - Service Person

Context: Drinks Distributor Controller

2.90

1

2

3

SPaddDrink d

addContainer d price p

DCgiveDrink d

SB

selectDrink d

returnCoinsRB

LCD

display m

MB

insertCoin c

takeCoinsreturnCoins

8

CO-OPN Component Model

DrinksDispenser

adddrink_:drink

cancel

selectDrink_:drinkinsertCoin_:coin

addcontainer_price_:drink,money

displayAmount_:moneyreturnMoney giveDrink_:drink

Methods (provided services, incoming signals, …)

Gates (required services, outgoing signals, …)

9

CO-OPN Component Model

Classes - encapsulated Petri Nets

addContainer_:drink

addDrink_:drink

containers:PhysicalDrinksContainers

takeDrink_:drink

returnMoney

Controller

giveDrink_:drinkdisplayAmount_:money

takeMoney

insertCoin_:coin selectDrink_:drink

cancel

insertCoin_:coin

takeCoins

returnCoins

moneyBox:PhysicalMoneyBox

DrinksDispenser

displayAmount_:moneyreturnMoney giveDrink_:drink

adddrink_:drink

cancel

selectDrink_:drinkinsertCoin_:coin

addcontainer_price_:drink,money

Contexts - coordination entities, hierarchical Synchronization - coordinate activities of components

10

Semantics of CO-OPN Synchronization

Transactional

DrinksDispenser

containers:PhysicalDrinksContainers

addContainer_:drinkaddDrink_:drink

takeDrink_:drink

insertCoin_:coin

takeCoins

returnCoins

displayAmount_:moneyreturnMoney giveDrink_:drink

adddrink_:drink

cancel

selectDrink_:drinkinsertCoin_:coin

Controller

giveDrink_:drink

returnMoney

displayAmount_:moneytakeMoney

insertCoin_:coin selectDrink_:drink

cancel

addcontainer_price_:drink,money

moneyBox:PhysicalMoneyBox

11

How an Object Works?

CentralUnit

takeMoney_:money

distribute_: drink

addContainer_price_:drink, money

addDrink _ : drink

container _ price _

distribute d

c, p

this.takeMoney p

(1)

c.dispenseDrink d

(2)

addContainerdprice p

c,p

c.init d

addDrink dc, p

c.addDrink d

distribute dtakeMoney p .. c.dispenseDrink d ::

container c price p -> container c price p;

distribute colatakeMoney p .. c.dispenseDrink cola ::

container c price p -> container c price p;

distribute colatakeMoney p .. colaContainer.dispenseDrink cola ::

container colaContainer price p -> container colaContainer price p;

distribute colatakeMoney 1.50 .. colaContainer.dispenseDrink cola ::

container colaContainer price 1.50 -> container colaContainer price 1.50;

distribute colatakeMoney 1.50 .. colaContainer.dispenseDrink cola ::

container colaContainer price 1.50 -> container colaContainer price 1.50;

(container colaContainer price 1.50) +(container milkContainer price 1.10)

12

Coffee

machine

Model of the Coffee machine

OfficeEXTERNAL WORLD

join

quit

13

Global Model based on contexts

OfficeEXTERNAL WORLD

join

quit

Coffee

machine

Agenda

Coffee machine

vicinity

14

Semantics

Labelled Transition System

Non-Determinism Same Method has two or more possible behaviours Choice is made among several firable methods

Concurrency/Parallelism Parallel firing of methods

Synchronisation Transactional Semantics (all or nothing)

15

Simulator

Simulation obtained from a specification CO-OPN -> Prolog (Javalog) Transformation implemented in Java Portable simulation

Close to original semantics

Prolog expressive power (pattern matching, backtracking)

16

Prototyping

Program Generation from a Specification CO-OPN -> Java Implemented in Java Restricted Semantics

Operational aspects Term-rewriting Logical evaluation with backtracking Petri-Nets execution Implementation of Atomicity and Transactions

Architectural aspects Java Beans architecture Integration in asynchronous systems

17

Using the Generated Code for prototyping

Simulation and animation GUI, Java Applets

Prototyping Real Equipment Physical Model of Real Equipment (Lift with Lego RCX)

2.90

Controller.java

Specific Interface

18

CO-OPN to Java Translation: methods

Context ControllerMethod insertCoin _ : coin;Gate distribute _ : drink;

Controller c = new Controller();

try{

CoopnTransaction T = new CoopnTransaction();

c.insertCoin(T,coinVariable);

T.commit();

}catch(MethodNotFirableException e){}

Java

CO

-OPN

19

CO-OPN to Java Translation: gates

Context ControllerMethod insertCoin _ : coin;Gate distribute _ : drink;

Controller c = new Controller();

c.addDistributeListener(new DistributeListener(){

public void distribute(DistributeEvent e){

e.getDrink();

...

}

});

Java

CO

-OPN

20

Prototyping

Close to intuition CO-OPN Contexts -> Java Beans CO-OPN Classes -> Java Classes CO-OPN Objects -> Java Objects Gate activity -> Java event Context migration -> use of proxies + pattern matching for

references

Differences Non-Deterministic choice among several behaviours of the

same method Non-Deterministic choice among several firable methods => Non-Deterministic Java Transactional semantics for methods Explicit Parallelism

21

Formal Modeling of Distributed complex systems

Oracle

OK! NOK!

Verification ofimplementations

Heterogeneous Prototype generation

Implementation model

Manual implementation

Execution environnement

CO-OPN Framework

Test setselections

Hypothesis

Specification

Validation

Refinement

22

Formal Modelling of Distributed complex systems

CO-OPN Framework

Formal Semantics:- Abstract - Operational

Real-Time Synchronised Petri Nets

Subtyping:- Strong (classes)- Weak (observational)

23

Modelling of distributed complex systems

Distributed Systems Concurrency Localization Dynamics Synchronization

Structured Approach System level Component level Object level

Life cycle Refinements -> links with design Requirements Elicitation ex. use case

24

Links to CO-OPN

CO-OPN http://lglww.epfl.ch/Conform/home_page.html

CO-OPNTools and papers http://lglww.epfl.ch/Conform/CoopnTools

CO-OPN Running examples (Lift, Philosophers) http://lglww.epfl.ch/Conform/Examples/index.html

25

Modelling of the Drink Distributor

Controller Model: unconstrained behaviour Infinite Money Box Infinite Drink Containers

=> Infinite State Space - General Properties

Physical Equipment Model: adds specific constraints Capacity of Money Box Capacity of Drink Containers Additional constraints on “system protocol”

=> Finite State Space - Specific Properties

26

Modelling UC Systems

Shadow objects

Exemple of philosophers Forks Philosophers Table Dynamic join/quit of philosophers

JUSTICE

VIRTUAL

REAL

27

Two state machine

Class TwoStateMachine;

Interface

    Use     BlackTokens;

    Type        tsm;

    Methods

        One - To - Two;

        Two - To - One;

Body

    Places

        one _ ,two _ : blackToken;

    Initial

        one @;

    Axioms

        One - To - Two:: one @ -> two @;

        Two - To - One:: two @ -> one @;

End TwoStateMachine;

Two Sta teMachine

One - To - Tw o

T wo - To - On e

one _@

tw o _

@

@

@

@

28

Behaviors - simulation

{coop nD efau ltContext[]}

{ coopnD efau ltContext[<Ftsm:{o ne @} , - >]}

{coo pnDefaultCon text[<Ftsm:{tw o @} , - >]}

(Ftsm . Create, - )

(Ftsm . O ne - T o - T wo , - )(Ftsm . Tw o - To - One, - )

29

Philosophers

Class Philosopher;

Inherit TwoStateMachine;

    Rename

        One - To - Two -> GoEating;

        Two - To - One -> goThinking;

        tsm -> philosopher;

End Philosopher;

30

Philosophers table

Class StaticPhTable;

Interface

    Use

        Philosopher;    Fork;    Naturals;

    Type

        staticPhTable;

    Object

        theTable : staticPhTable;

    Methods

        eat;

        think;

        step;

31

Philosophers table

Body

  Objects

    P1,P2,P3 : philosopher;   F1,F2,F3 : fork;

  Place

    _ left _ right _ : fork philosopher fork;

  Initial    F3 left P3 right F2;  F2 left P2 right F1;  F1 left P1 right F3;

  Axioms

    eat With ((p . GoEating)//(leftFork.Taken)//(rightFork.Taken)::

    leftFork left p right rightFork->leftFork left p right rightFork;

    think With ((p.goThinking)//(leftFork.Left))//(rightFork . Left)::

    leftFork left p right rightFork->leftFork left p right rightFork;

    this = Self =>   step With this . eat::        ->;

    this = Self =>  step With this . think::      ->;

    Where

        p : philosopher;

        f, leftFork, rightFork : fork;

        n : natural;  this : staticPhTable;

End StaticPhTable;

32

Axioms - eat

eat With 

((p . GoEating)//(leftFork.Taken)//(rightFork.Taken)::

  leftFork left p right rightFork ->leftFork left p right rightFork;

Event

Synchro

PostconditionPrecondition

Choose p , leftFork et rightFork

Unification

33

philosopher table- classes

Philosopher

GoE ating

goThink ing

one _

@

two _goTh inking

Fo rk

Taken

L eft

one _

@

tw o _Left

StaticPhTable

eatthink

step

_ left _ right _F3, P3, F2 , F2, P2, F1 , F1, P1, F3

p . G oEatingleftFork . T aken

righ tFork . Taken

p . goThink ingleftFo rk . Left

rightFork . Left

step

this = Self

this . eat

s tep

th is = Self

th is . think

34

Dynamic building of the tableClass PhTable;

Interface

    Use   Philosopher;   Fork;   Naturals;

    Type   phTable;

    Object   IkeaTable : phTable;

    Methods

        placePhilosophers _ : natural;    eat;   think;   step ;

Body

    Method

(::This internal method (not visible from other classes) recur sively fills the table with the desired number of philosophers and and forksThe left fork of the first philosopher (third arg ument) becomes the right fork of the last one.The right fork o f previous philosopher is given by the second argument.

:)   init _ _ _ : natural fork fork;

    Place

        _ left _ right _ : fork philosopher fork;

35

    Axioms

      init 0 leftFork firstFork With (p . Create)::

          -> leftFork left p right firstFork;

      this = Self =>

      init (succ n) leftFork firstFork With 

        ((p.Create)..(f.Create))..(this.init n f firstFork)::

          -> leftFork left p right f;

(::placePhilosophers create the left fork of the first philoso pher (which is also the right fork of the last philosopher)

Uses recursive method init to fill the table.:)

        this = Self =>

      placePhilosophers n With (f.Create)..(this.init n f f)::

          ->;

    Where

        p : philosopher; f : fork;

        leftFork : fork;   firstFork : fork;  f2 : fork;

        n : natural;

        this : phTable;

End PhTable;

36

Dynamic building of the table n>0 this = Self =>

      placePhilosophers n With (f.Create)..(this.init n f f)::

          ->;

Init n f f

f

37

Dynamic building of the table(inductive case)

  init (succ n) leftFork firstFork With 

        ((p.Create)..(f.Create))..(this.init n f firstFork)::

          -> leftFork left p right f;

Init n leftfork firstfork

f

leftfork

p

38

Dynamic building of the table (base case)

 init 0 leftFork firstFork With (p . Create)::

          -> leftFork left p right firstFork;

      this = Self =>

Init 0 leftfork firstfork

leftfork

firstfork

39

Observing the state

 ‘eat’ operation sequence

‘think’ operation sequence

=> Knowledge of the number of ‘philo’

40

Join and quit the table

join With (p . Create) . . (f . Create)::

leftFork left p1 right f1,

f1 left p2 right f2 ->

leftFork left p1 right f1,

f1 left p right f,

f left p2 right f2;

quit:: leftFork left p1 right f1,

f1 left p right f,

f left p2 right f2 ->

leftFork left p1 right f1,

f1 left p2 right f2;

41

Join the table at the right moment

join With ((LeftFork.Taken..LeftFork.Left)..

(f2.Taken..f2.Left)..)

(p . Create) . . (f . Create)::

leftFork left p1 right f1,

f1 left p2 right f2 ->

leftFork left p1 right f1,

f1 left p right f,

f left p2 right f2;

42

Philosopher behavior

43

Contexts

TABLEEXTERNAL WORLD

Give a Static (dynamic?) view of the topology of localities Philosophers are not ‘created’ when entering the table !, they are

discovered ! Object migration from adjacent context (the external world)

join

quit

44

Join and quit the table and discovering thephilosopher shadow object (same for forks)Join(id) With p.alive(id).. join(p)::

->;

Join(id) With !p.alive(p).. p.create(id)..join(p)::

->;

quit With quit(p)::

->;

join(p)::

leftFork left p1 right f1,

f1 left p2 right f2 ->

leftFork left p1 right f1,

f1 left p right f,

f left p2 right f2;

quit(p):: leftFork left p1 right f1,

f1 left p right f,

f left p2 right f2 ->

leftFork left p1 right f1,

f1 left p2 right f2;