CO-OPN: Concurrent Object-Oriented Petri Nets

1
CO-OPN Concurrent Object-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
move(t) with O2.put(t)
put(r)
r
processing
t
s
t1
t2
t3
p1
p2
O1
O2
6
Synchronised Petri Nets
move(t) with O2.put(t)
put(r)
r
processing
t
s
t1
t2
t3
p1
p2
O1
O2
7
Context Drinks Distributor Controller

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

2.90
8
CO-OPN Component Model

• Methods (provided services, incoming signals, )

• Gates (required services, outgoing signals, )

DrinksDispenser
9
CO-OPN Component Model

• Classes - encapsulated Petri Nets

• Contexts - coordination entities, hierarchical

• Synchronization - coordinate activities of
  components

10
Semantics of CO-OPN Synchronization

• Transactional

insertCoin_coin
selectDrink_drink
DrinksDispenser
addcontainer_price_drink,money
insertCoin_coin
selectDrink_drink
cancel
Controller
cancel
adddrink_drink
displayAmount_money
giveDrink_drink
takeMoney
addDrink_drink
addContainer_drink
returnMoney
insertCoin_coin
returnCoins
takeCoins
takeDrink_drink
moneyBoxPhysicalMoneyBox
containersPhysicalDrinksContainers
displayAmount_money
returnMoney
giveDrink_drink
11
How an Object Works?

• distribute d
• takeMoney p .. c.dispenseDrink d
• container c price p -gt container c price p

distribute cola takeMoney p .. c.dispenseDrink
cola container c price p -gt container c price
p
distribute cola takeMoney p .. colaContainer.dispe
nseDrink cola container colaContainer price p
-gt container colaContainer price p
distribute cola takeMoney 1.50 ..
colaContainer.dispenseDrink cola container
colaContainer price 1.50 -gt container
colaContainer price 1.50
distribute cola takeMoney 1.50 ..
colaContainer.dispenseDrink cola container
colaContainer price 1.50 -gt container
colaContainer price 1.50
distribute_ drink
CentralUnit
distribute d
c.init d
addContainer_price_ drink, money
addContainerdprice p
this.takeMoney p
c, p
takeMoney_money
(1)
c,p
c.addDrink d
(2)
addDrink _ drink
c, p
addDrink d
container _ price _
(container colaContainer price 1.50) (container
milkContainer price 1.10)
c.dispenseDrink d
12
Model of the Coffee machine
EXTERNAL WORLD
Office
Coffee machine
join
quit
13
Global Model based on contexts
Agenda
EXTERNAL WORLD
Office
join
Coffee machine vicinity
quit
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 -gt 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 -gt 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)

Specific Interface
Controller.java
18
CO-OPN to Java Translation methods

• Context Controller
• Method insertCoin _ coin
• Gate distribute _ drink

CO-OPN
19
CO-OPN to Java Translation gates

• Context Controller
• Method insertCoin _ coin
• Gate distribute _ drink

CO-OPN
20
Prototyping

• Close to intuition
• CO-OPN Contexts -gt Java Beans
• CO-OPN Classes -gt Java Classes
• CO-OPN Objects -gt Java Objects
• Gate activity -gt Java event
• Context migration -gt 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
• gt Non-Deterministic Java
• Transactional semantics for methods
• Explicit Parallelism

21
CO-OPN Framework
22
CO-OPN Framework
23
Modelling of distributed complex systems

• Distributed Systems
• Concurrency
• Localization
• Dynamics
• Synchronization
• Structured Approach
• System level
• Component level
• Object level
• Life cycle
• Refinements -gt 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
• gt Infinite State Space - General Properties
• Physical Equipment Model adds specific
  constraints
• Capacity of Money Box
• Capacity of Drink Containers
• Additional constraints on system protocol
• gt 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 _at_
•     Axioms
•         One - To - Two one _at_ -gt two _at_
•         Two - To - One two _at_ -gt one _at_
• End TwoStateMachine

28
Behaviors - simulation
29
Philosophers

• Class Philosopher
• Inherit TwoStateMachine
•     Rename
•         One - To - Two -gt GoEating
•         Two - To - One -gt goThinking
•         tsm -gt 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)//(r
  ightFork.Taken)
•     leftFork left p right rightFork-gtleftFork left
   p right rightFork
•     think With ((p.goThinking)//(leftFork.Left))//
  (rightFork . Left)
•     leftFork left p right rightFork-gtleftFork left
   p right rightFork
•     this  Self gt   step With this . eat       
   -gt
•     this  Self gt  step With this . think      
  -gt
•     Where
•         p  philosopher
•         f, leftFork, rightFork  fork
•         n  natural  this  staticPhTable
• End StaticPhTable

32
Axioms - eat

• eat With 
• ((p . GoEating)//(leftFork.Taken)//(rightFork.Take
  n)
•   leftFork left p right rightFork
  -gtleftFork left p right rightFork

33
philosopher table- classes
34
Dynamic building of the table

• Class PhTable
• Interface
•     Use   Philosopher   Fork   Naturals
•     Type   phTable
•     Object   IkeaTable  phTable
•     Methods
•         placePhilosophers _  natural    eat   t
  hink   step
• Body
•     Method
• (This internal method (not visible from other cl
  asses) recur sively fills the table with the desir
  ed number of philosophers and and forksThe left fo
  rk 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 th
  e second argument.
• )   init _ _ _  natural fork fork
•     Place
•         _ left _ right _  fork philosopher fork

35

•     Axioms
•       init 0 leftFork firstFork With (p . Create)
  
•           -gt leftFork left p right firstFork
•       this  Self gt
•       init (succ n) leftFork firstFork With 
•         ((p.Create)..(f.Create))..(this.init n f f
  irstFork)
•           -gt leftFork left p right f
• (placePhilosophers create the left fork of the f
  irst philoso pher (which is also the right fork of
   the last philosopher)
• Uses recursive method init to fill the table.)
•         this  Self gt
•       placePhilosophers n With (f.Create)..(this.i
  nit n f f)
•           -gt
•     Where
•         p  philosopher f  fork
•         leftFork  fork   firstFork  fork
   f2  fork
•         n  natural
•         this  phTable
• End PhTable

36
Dynamic building of the table ngt0

•  this  Self gt
•       placePhilosophers n With (f.Create)..(this.i
  nit n f f)
•           -gt

f
Init n f f
37
Dynamic building of the table(inductive case)

•   init (succ n) leftFork firstFork With 
•         ((p.Create)..(f.Create))..(this.init n f f
  irstFork)
•           -gt leftFork left p right f

f
p
leftfork
Init n leftfork firstfork
38
Dynamic building of the table (base case)

•  init 0 leftFork firstFork With (p . Create)
•           -gt leftFork left p right firstFork
•       this  Self gt

firstfork
leftfork
Init 0 leftfork firstfork
39
Observing the state

•  eat operation sequence
• think operation sequence
• gt 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 -gt
• 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 -gt
• 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 -gt
• leftFork left p1 right f1,
• f1 left p right f,
• f left p2 right f2

42
Philosopher behavior
43
Contexts

• 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)

EXTERNAL WORLD
TABLE
join
quit
44
Join and quit the table and discovering
thephilosopher shadow object (same for forks)

• Join(id) With p.alive(id).. join(p)
• -gt
• Join(id) With !p.alive(p).. p.create(id)..join(p)
  
• -gt
• quit With quit(p)
• -gt

• join(p)
• leftFork left p1 right f1,
• f1 left p2 right f2 -gt
• 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 -gt
• leftFork left p1 right f1,
• f1 left p2 right f2