Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CO-OPN: Concurrent Object-Oriented Petri Nets Giovanna Di Marzo Serugendo University of Geneva, Switzerland (Courtesy of Didier Buchs, EPFL, Switzerland)

Similar presentations


Presentation on theme: "1 CO-OPN: Concurrent Object-Oriented Petri Nets Giovanna Di Marzo Serugendo University of Geneva, Switzerland (Courtesy of Didier Buchs, EPFL, Switzerland)"— Presentation transcript:

1 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 2 Contents oCO-OPN l Synchronised Petri Nets l Contexts oSemantics oSimulator / Prototyping oCO-OPN Framework

3 3 CO-OPN Specification Language  CO-OPN: Concurrent Object-Oriented Petri Nets l Data Structures = Algebraic Abstract Data Types l Concurrency (Intra- Inter-), Control = Algebraic Petri Nets l Modularity = Object orientation with strict encapsulation l Dynamicity = References, Object Creation l Communication = Synchronisation between Objects l Distribution = Contexts = Units + Localisation + Migration information oCO-OPN = Data Structures + Petri Nets + Object Orientation + Contexts

4 4 CO-OPN: Why? oDevelopment of embedded systems oUse of a formal notation l Suitable for formal verification l Suitable for code generation oTest the prototype behaviour in the target execution environment oA formal notation : CO-OPN (graphical, textual)

5 5 Synchronised Petri Nets Method Synchronisation move(t) with O2.put(t) put(r) O1O2 p1p2 t t1 t3 t2 r s processing Transition Objects

6 6 Synchronised Petri Nets move(t) with O2.put(t) put(r) O1O2 p1p2 t t1 t3 t2 r s processing t2X

7 7 Controller oDD Components l Controller l DC - Drink Container l MB - Money Box l SB,RB - Buttons l LCD - Display l SP - Service Person Context: Drinks Distributor Controller 2.90 2 3 SP addDrink d addContainer d price p DC giveDrink d SB selectDrink d returnCoins RB LCD display m MB insertCoin c takeCoins returnCoins

8 8 CO-OPN Component Model DrinksDispenser adddrink_:drink cancel selectDrink_:drinkinsertCoin_:coin addcontainer_price_:drink,money displayAmount_:money returnMoney giveDrink_:drink l Methods (provided services, incoming signals, …) l Gates (required services, outgoing signals, …)

9 9 CO-OPN Component Model l Classes - encapsulated Petri Nets addContainer_:drink addDrink_:drink containers:PhysicalDrinksContainers takeDrink_:drink returnMoney Controller giveDrink_:drink displayAmount_:money takeMoney insertCoin_:coinselectDrink_:drink cancel insertCoin_:coin takeCoins returnCoins moneyBox:PhysicalMoneyBox DrinksDispenser displayAmount_:money returnMoney giveDrink_:drink adddrink_:drink cancel selectDrink_:drinkinsertCoin_:coin addcontainer_price_:drink,money l Contexts - coordination entities, hierarchical l Synchronization - coordinate activities of components

10 10 Semantics of CO-OPN Synchronization oTransactional DrinksDispenser containers:PhysicalDrinksContainers addContainer_:drink addDrink_:drink takeDrink_:drink insertCoin_:coin takeCoins returnCoins displayAmount_:money returnMoney giveDrink_:drink adddrink_:drink cancel selectDrink_:drink insertCoin_:coin Controller giveDrink_:drink returnMoney displayAmount_:money takeMoney insertCoin_:coinselectDrink_:drink cancel addcontainer_price_:drink,money moneyBox:PhysicalMoneyBox

11 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)(1) c. dispenseDrink d (2) addContainerdprice p c,p c.init d addDrink d c, p c.addDrink d distribute d takeMoney p.. c.dispenseDrink d :: container c price p -> container c price p; distribute cola takeMoney p.. c.dispenseDrink cola :: container c price p -> container c price p; distribute cola takeMoney p.. colaContainer.dispenseDrink cola :: container colaContainer price p -> container colaContainer price p; distribute cola takeMoney 1.50.. colaContainer.dispenseDrink cola :: container colaContainer price 1.50 -> container colaContainer price 1.50; distribute cola takeMoney 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 12 Coffee machine Model of the Coffee machine Office EXTERNAL WORLD join quit

13 13 Global Model based on contexts Office EXTERNAL WORLD join quit Coffee machine Agenda Coffee machine vicinity

14 14 Semantics oLabelled Transition System oNon-Determinism l Same Method has two or more possible behaviours l Choice is made among several firable methods oConcurrency/Parallelism l Parallel firing of methods oSynchronisation l Transactional Semantics (all or nothing)

15 15 Simulator oSimulation obtained from a specification l CO-OPN -> Prolog (Javalog) l Transformation implemented in Java l Portable simulation oClose to original semantics oProlog expressive power (pattern matching, backtracking)

16 16 Prototyping oProgram Generation from a Specification l CO-OPN -> Java l Implemented in Java l Restricted Semantics oOperational aspects l Term-rewriting l Logical evaluation with backtracking l Petri-Nets execution l Implementation of Atomicity and Transactions oArchitectural aspects l Java Beans architecture l Integration in asynchronous systems

17 17 Using the Generated Code for prototyping oSimulation and animation l GUI, Java Applets oPrototyping l Real Equipment l Physical Model of Real Equipment (Lift with Lego RCX) 2.90 Controller.java Specific Interface

18 18 CO-OPN to Java Translation: methods Context Controller Method 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 19 CO-OPN to Java Translation: gates Context Controller Method insertCoin _ : coin; Gate distribute _ : drink; Controller c = new Controller(); c.addDistributeListener(new DistributeListener(){ public void distribute(DistributeEvent e){ e.getDrink();... } }); Java CO-OPN

20 20 Prototyping oClose to intuition l CO-OPN Contexts -> Java Beans l CO-OPN Classes -> Java Classes l CO-OPN Objects -> Java Objects l Gate activity -> Java event l Context migration -> use of proxies + pattern matching for references oDifferences l Non-Deterministic choice among several behaviours of the same method l Non-Deterministic choice among several firable methods l => Non-Deterministic Java l Transactional semantics for methods l Explicit Parallelism

21 21 Formal Modeling of Distributed complex systems Oracle OK! NOK! Verification of implementations Heterogeneous Prototype generation Implementation model Manual implementation Execution environnement CO-OPN Framework Test set selections Hypothesis Specification Validation oRefineme nt

22 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 23 Modelling of distributed complex systems oDistributed Systems l Concurrency l Localization l Dynamics l Synchronization oStructured Approach l System level l Component level l Object level oLife cycle l Refinements -> links with design l Requirements Elicitation ex. use case

24 24 Links to CO-OPN oCO-OPN l http://lglww.epfl.ch/Conform/home_page.html oCO-OPNTools and papers l http://lglww.epfl.ch/Conform/CoopnTools oCO-OPN Running examples (Lift, Philosophers) l http://lglww.epfl.ch/Conform/Examples/index.html

25 25 Modelling of the Drink Distributor oController Model: unconstrained behaviour l Infinite Money Box l Infinite Drink Containers => Infinite State Space - General Properties oPhysical Equipment Model: adds specific constraints l Capacity of Money Box l Capacity of Drink Containers l Additional constraints on “system protocol” => Finite State Space - Specific Properties

26 26 Modelling UC Systems oShadow objects oExemple of philosophers l Forks l Philosophers l Table l Dynamic join/quit of philosophers JUSTICE VIRTUAL REAL

27 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;

28 28 Behaviors - simulation

29 29 Philosophers Class Philosopher; Inherit TwoStateMachine; Rename One - To - Two -> GoEating; Two - To - One -> goThinking; tsm -> philosopher; End Philosopher;

30 30 Philosophers table Class StaticPhTable; Interface Use Philosopher; Fork; Naturals; Type staticPhTable; Object theTable : staticPhTable; Methods eat; think; step;

31 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 32 Axioms - eat eat With ((p. GoEating)//(leftFork.Taken)//(rightFork.Taken):: leftFork left p right rightFork ->leftFork left p right rightFork; Event Synchro Postcondition Precondition Choose p, leftFork et rightFork Unification

33 33 philosopher table- classes

34 34 Dynamic building of the table Class 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 l eft 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 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 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 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 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 39 Observing the state o ‘eat’ operation sequence o‘think’ operation sequence => Knowledge of the number of ‘philo’

40 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 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 42 Philosopher behavior

43 43 Contexts TABLE EXTERNAL WORLD oGive a Static (dynamic?) view of the topology of localities oPhilosophers are not ‘created’ when entering the table !, they are discovered ! oObject migration from adjacent context (the external world) join quit

44 44 Join and quit the table and discovering the philosopher 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;


Download ppt "1 CO-OPN: Concurrent Object-Oriented Petri Nets Giovanna Di Marzo Serugendo University of Geneva, Switzerland (Courtesy of Didier Buchs, EPFL, Switzerland)"

Similar presentations


Ads by Google