1 / 44

CO-OPN: Concurrent Object-Oriented Petri Nets

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. Contents. CO-OPN Synchronised Petri Nets Contexts Semantics Simulator / Prototyping CO-OPN Framework.

fraley
Download Presentation

CO-OPN: Concurrent Object-Oriented Petri Nets

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Method Synchronisation Method Transition Objects Synchronised Petri Nets move(t) with O2.put(t) put(r) r processing t s t1 t2 t3 p1 p2 O1 O2

  6. X t2 Synchronised Petri Nets move(t) with O2.put(t) put(r) r processing t s t1 t2 t3 p1 p2 O1 O2

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

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

  9. insertCoin_:coin selectDrink_:drink DrinksDispenser insertCoin_:coin selectDrink_:drink addcontainer_price_:drink,money cancel Controller cancel adddrink_:drink displayAmount_:money giveDrink_:drink takeMoney addDrink_:drink returnMoney addContainer_:drink insertCoin_:coin returnCoins takeCoins takeDrink_:drink moneyBox:PhysicalMoneyBox containers:PhysicalDrinksContainers displayAmount_:money returnMoney giveDrink_:drink 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 moneyBox:PhysicalMoneyBox containers:PhysicalDrinksContainers displayAmount_:money returnMoney giveDrink_:drink

  11. How an Object Works? distribute d takeMoney p .. c.dispenseDrink d :: container c price p -> container c price p; distribute cola takeMoney 1.50 .. colaContainer.dispenseDrink cola :: container colaContainer price 1.50 -> container colaContainer price 1.50; distribute cola takeMoney p .. colaContainer.dispenseDrink cola :: container colaContainer price p -> container colaContainer price p; distribute cola takeMoney p .. c.dispenseDrink cola :: container c price p -> container c price p; distribute cola takeMoney 1.50 .. colaContainer.dispenseDrink cola :: container colaContainer price 1.50 -> 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. Coffee machine 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 -> 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. 2.90 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. Controller c = new Controller(); try{ CoopnTransaction T = new CoopnTransaction(); c.insertCoin(T,coinVariable); T.commit(); }catch(MethodNotFirableException e){} Java CO-OPN to Java Translation: methods Context Controller Method insertCoin _ : coin; Gate distribute _ : drink; CO-OPN

  19. Controller c = new Controller(); c.addDistributeListener(new DistributeListener(){ public void distribute(DistributeEvent e){ e.getDrink(); ... } }); Java CO-OPN to Java Translation: gates Context Controller Method insertCoin _ : coin; Gate distribute _ : drink; 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 Hypothesis Implementation model Test set selections Heterogeneous Prototype generation • Refinement Manual implementation Specification Validation Oracle Verification of implementations OK! Execution environnement NOK! CO-OPN Framework

  22. Formal Modelling of Distributed complex systems Formal Semantics: - Abstract - Operational Subtyping: - Strong (classes) - Weak (observational) Real-Time Synchronised Petri Nets 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 -> 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;

  28. Behaviors - simulation

  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. Event Synchro Unification Precondition Choose p , leftFork et rightFork Postcondition Axioms - eat eat With  ((p . GoEating)//(leftFork.Taken)//(rightFork.Taken)::   leftFork left p right rightFork ->leftFork 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;   think;   step ; Body     Method (::This internal method (not visible from other classes) recur sivelyfills 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)::           ->; 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 firstFork)::           -> 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)::           -> leftFork left p right firstFork;       this = Self => firstfork leftfork Init 0 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 • 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(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; Join and quit the table and discovering thephilosopher shadow object (same for forks)

More Related