1 / 16

Petri Nets

June 26, 2000. Petri Nets. Invented by Carl Adam Petri in 1962 Concurrent systems with timing problems Synchronization, race problem, deadlock A petri net consists of four parts: A finite set of places P = {p 1 , p 2 , …, p n } n  0

jonah-clements
Download Presentation

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. June 26, 2000 Petri Nets • Invented by Carl Adam Petri in 1962 • Concurrent systems with timing problems • Synchronization, race problem, deadlock • A petri net consists of four parts: • A finite set of places P = {p1, p2, …, pn} n 0 • A finite set of transitions T = {t1, t2, …, tm} m 0; P and T are disjoint • An input function I: T  P; a mapping fromtransitions to bags of places • An output function O: T  P; a mapping fromtransitions to bags of places • Figure 10.16

  2. Petri Nets (2) • Marking • Assignment of tokens to places • M: P  {0, 1, 2, …, } • Figure 10.17 • Enabled transitions - ready to fire • The number of tokens is not conserved • Non-deterministic - if more than one transition is able to fire, then any one of them may be fired • A marked Petri net is a 5-tuple (P, T, I, O, M) • Extension to Petri net • Inhibitor arc (Figure 10.20) • In general, a transition is enabled if there is at least one token on each of its (normal) input arcs and no tokens on any of its inhibitor input arcs.

  3. Petri Nets (3) • Elevator Problem • n elevators - An elevator is represented as a token • m floors - Each floor is represented as a place Ff • A token in a place denotes that an elevator is at floor f • First constraint • Each elevator has a set of m buttons, one for each floor. These illuminate when pressed and cause the elevator to visit the corresponding floor. The illumination is canceled when the corresponding floor is visited by the elevator. • New places are included to model the constraint • EBf - A place; a token in EBf denotes that the elevator button for floor f is illuminated. • Figure 10.21 • In classical Petri net theory, transitions are instantaneous • Therefore, timed Petri nets are introduced [Coolahan and Roussopoulos, 1983]

  4. Petri Nets (4) • Second constraint • Each floor, except the first floor and top floor, has two buttons, one to request an up-elevator and one to request a down-elevator. These buttons illuminate when pressed. The illumination is canceled when an elevator visits the floor and then moves in the desired direction. • New places are included to model the constraint • FBfu and FBfd - a token in FBfu (or FBfd) denotes that the floor button for requesting up-elevator (or down-elevator) in floor f is illuminated. • Figure 10.22

  5. Z • Major components of a Z specification • Given set, data types, and constants • State definition (state schema) • Initial state • Operations (operation schema) • Give Sets • A method of introducing new types and is used when the internal structure of the elements is irrelevant • [Button, Elevator] - the set of buttons and the set of elevators • Schema • A schema may be used to describe some part of the state or an operation on the state. • The name of the schema has global scope; its variables have local scope

  6. Z (2) • A schema can be presented in two different forms: • horizontal form • vertical form Figure 10.24

  7. Z (3) • State schema (for specifying states) • Group together all the relevant information that belongs to a state description • A state is just a collection of sets and objects and some predicates defined on those things • Figure 10.24 • Initial state • Describes the state when the system is first turned on • Button_Init = [Button_State’|pushed’ = ] • Operation schemas • Describes the effects (in terms of the state change) of operations • Figure 10.25 • The precondition must be true before the operation can be invoked (is applicable) • (x) However, if the operation is invoked without the precondition being satisfied, unspecified (an therefore unpredictable) results can occur.

  8. Comparison of Specification Techniques • Figure 10.27

  9. Testing During the Specification Phase • Walkthroughs and inspection • Will discuss later when we go to Chapter 5 if time is available

  10. -------------- REFUNDS -------------- Data Dictionary REFUNDS Process REFUNDS Case Tools For The Specification Phase • A graphical tool for DFD, Petri Net, ER diagram … • A data dictionary. • The above two tools should be integrated so that any change made to a data component is automatically reflected in the corresponding part of the specification.

  11. Chapter 11: Object-oriented Analysis • A well-designed object with high cohesion and low coupling models all aspects of one physical entity • The details of how this is implemented are hidden • Objects are essentially independent units with a well-defined interface • Objects are easily and safely maintainable, the chance of regression fault is reduced • Objects are reusable which is further enhanced by inheritance • Better for large scale product by combining the fundamental building blocks of software than structured paradigm

  12. Three steps of Object-oriented Analysis • OOA consists of three main steps [Schach] • Use case modeling • Use case diagram and associated scenarios • Function perspective • Class modeling • Determine the classes and their attributes • Determine the interrelationships between the classes • Class diagram • Data perspective • Dynamic modeling • Determine the actions performed by or to each class or subclasses • State diagram (Statechart diagram in UML) • Behavioral perspective (or dynamic)

  13. Use-Case Modeling • A use case describes the functionality of the product to be constructed. • A scenario is a specific instance of an use case. • Use case diagram - Figure 11.1 • Actors - external entities, not necessarily human beings • A normal scenario - Figure 11.2 • Withdraw cash • An abnormal scenario - Figure 11.3 • Attempt to withdraw cash over the daily limit

  14. Class Modeling • Extracting classes and their associated attributes • Difficult to get it right the first time • Methods are assigned to classes during the OO design (OOD) phase • How to determine classes? • Deduce from the scenarios • CRC cards (when the developers have domain expertise) • Noun extraction (for developers without domain expertise) • Object selection criteria • Object elimination criteria

  15. Dynamic Modeling • Produce a state diagram for each class with non-trivial behavior • One-elevator Elevator Controller - Figure 11.6 • Compare Figure 11.2 with 11.6 (Use scenarios to test the state diagram)

  16. UML Outline • “Software Architecture and the UML” by Grady Booch • http://www.rational.com/uml/

More Related