1 co-opn: concurrent object-oriented petri nets giovanna di marzo serugendo university of geneva,...
TRANSCRIPT
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
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)
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;
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;