Petri Nets and Other Models of Concurrency - ICATPN 2006: 27th International Conference on Applications and Theory of Petri Nets and Other Models of ... (Lecture Notes in Computer Science, 4024) 3540346996, 9783540346999

Citation preview

Lecture Notes in Computer Science Commenced Publication in 1973 Founding and Former Series Editors: Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board David Hutchison Lancaster University, UK Takeo Kanade Carnegie Mellon University, Pittsburgh, PA, USA Josef Kittler University of Surrey, Guildford, UK Jon M. Kleinberg Cornell University, Ithaca, NY, USA Friedemann Mattern ETH Zurich, Switzerland John C. Mitchell Stanford University, CA, USA Moni Naor Weizmann Institute of Science, Rehovot, Israel Oscar Nierstrasz University of Bern, Switzerland C. Pandu Rangan Indian Institute of Technology, Madras, India Bernhard Steffen University of Dortmund, Germany Madhu Sudan Massachusetts Institute of Technology, MA, USA Demetri Terzopoulos University of California, Los Angeles, CA, USA Doug Tygar University of California, Berkeley, CA, USA Moshe Y. Vardi Rice University, Houston, TX, USA Gerhard Weikum Max-Planck Institute of Computer Science, Saarbruecken, Germany

4024

Susanna Donatelli P.S. Thiagarajan (Eds.)

Petri Nets and Other Models of Concurrency – ICATPN 2006 27th International Conference onApplications and Theory of Petri Nets and Other Models of Concurrency Turku, Finland, June 26-30, 2006 Proceedings

13

Volume Editors Susanna Donatelli Università degli Studi di Torino, Dipartimento di Informatica Corso Svizzera 185, 10149 Torino, Italy E-mail: [email protected] P.S. Thiagarajan National University of Singapore, School of Computing 3 Science Drive 2, Singapore 117543, Singapore E-mail: [email protected]

Library of Congress Control Number: 2006926657 CR Subject Classification (1998): F.1-3, C.1-2, G.2.2, D.2, D.4, J.4 LNCS Sublibrary: SL 1 – Theoretical Computer Science and General Issues ISSN ISBN-10 ISBN-13

0302-9743 3-540-34699-6 Springer Berlin Heidelberg New York 978-3-540-34699-9 Springer Berlin Heidelberg New York

This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer. Violations are liable to prosecution under the German Copyright Law. Springer is a part of Springer Science+Business Media springer.com © Springer-Verlag Berlin Heidelberg 2006 Printed in Germany Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India Printed on acid-free paper SPIN: 11767589 06/3142 543210

Preface

This volume consists of the proceedings of the 27th International Conference on Applications and Theory of Petri Nets and Other Models of Concurrency (ICATPN 2006). This series of conferences provides a forum for presenting the current state of research on Petri nets and related approaches to concurrent systems. Both applications and theoretical developments are represented. Shorter presentations introducing novel tools or substantial enhancements to existing tools are also encouraged. Further, a range of invited talks that survey related domains are presented. ICATPN 2006 was co-located with the 6th International Conference on Applications of Concurrency to System Design (ACSD 2006). The two conferences had common satellite events and invited speakers as well as coordinated programs to enable participants to benefit from both conferences. The ICATPN 2006 conference — as well as ACSD 2006 — was organized by the Department of Computer Science, ˚ Abo Academi University, Turku, Finland. We would like to heartily thank the Organizing Committee, chaired by Johan Lilius, for the considerable effort invested to bring off the two conferences smoothly. Detailed information about ICATPN 2006 and the related events can be found at http://www.cs.abo.fi/atpn2006/. This year we received 93 submissions from authors from 26 different countries. The Program Committee selected 22 contributions classified as: theory papers (10 accepted), application and theory papers (3 accepted), application papers (3 accepted) and tool papers (6 accepted). We thank all the authors who submitted papers. We wish to thank the Program Committee members and other reviewers (whose names appear on page VII) for their careful and timely evaluation of the submissions before the Program Committee meeting in Turin, Italy. Special thanks are due to Martin Karusseit, University of Dortmund, for his technical support with the Online Conference Service. Finally, we wish to express our gratitude to the four invited speakers, Ralf-Johan Back, Javier Campos, Ekkart Kindler and Jianli Xu, who chose to have their papers appear in this volume. As usual, the Springer LNCS Team provided high quality support in the preparation of this volume. Last but not least, our heartfelt thanks are due to Phan Thi Xuan Linh and Yang Shaofa who put in a great deal of work toward the compilation of these proceedings.

April 2006

Susanna Donatelli and P.S. Thiagarajan

Organization

Steering Committee Wil van der Aalst, The Netherlands Jonathan Billington, Australia J¨ org Desel, Germany Susanna Donatelli, Italy Serge Haddad, France Kurt Jensen, Denmark (chair) H.C.M. Kleijn, The Netherlands Maciej Koutny, UK

Sadatoshi Kumagai, Japan Tadao Murata, USA Carl Adam Petri, Germany (honorary member) Lucia Pomello, Italy Wolfgang Reisig, Germany Grzegorz Rozenberg, The Netherlands Manuel Silva, Spain

Organizing Committee Jerker Bj¨ orkqvist Robert Gyllenberg Tiina Haanila

Johan Lilius (chair) Lionel Morel Xinrong Zhou

Tool Demonstration Jerker Bj¨ orkqvist (chair)

Program Committee Jonathan Billington, Australia Didier Buchs, Switzerland Nadia Busi, Italy Gianfranco Ciardo, USA Jose Manuel Colom, Spain Philippe Darondeau, France Susanna Donatelli, Italy (co-chair, applications) Giuliana Franceschinis, Italy Boudewijn Haverkort, The Netherlands Xudong He, USA Kees M. van Hee, The Netherlands Monika Heiner, Germany Jane Hillston, UK Kunihiko Hiraishi, Japan

Petr Janˇcar, Czech Republic Gabriel Juh´ as, Germany Maciej Koutny, UK Lars Michael Kristensen, Denmark Johan Lilius, Finland Madhavan Mukund, India Wojciech Penczek, Poland Laure Petrucci, France Lucia Pomello, Italy Laura Recalde, Spain Karsten Schmidt, Germany P.S. Thiagarajan, Singapore (co-chair, theory) Toshimitsu Ushio, Japan Rudiger Valk, Germany Francois Vernadat, France

VIII

Organization

Referees Slim Abdellatif Baver Acu Alessandra Agostini Alessandro Aldini Ashok Argent-Katwala Eric Badouel Kamel Barkaoui Marek Bednarczyk Simona Bernardi Luca Bernardinello G´erard Berthelot Bernard Berthomieu Jerker Bj¨ orkqvist Jean-Paul Bodeveix Luciano Bononi Jeremy Bradley Roberto Bruni Benoit Caillaud Ang Chen Christine Choppy Lucia Cloth Salem Derisavi Raymond Devillers Jean Fanchon Carlo Ferigato Mamoun Filali Jana Flochova Blaise Genest Stephen Gilmore

Andreas Glausch Monika Heiner Keijo Heljanko Lo¨ıc H´elou¨et Jarle Hulaas David Hurzeler Wojtek Jamroga Agata Janowska Pawel Janowski Jorge Julvez Victor Khomenko Hanna Klaudel Jetty Kleijn Fabrice Kordon Matthias Kuntz Sebastien Lafond Niels Lohmann Marco Loregian Robert Lorenz Roberto Lucchi Levi Lucio Matteo Magnani Cristian Mahulea Jose M. Martinez Peter Massuthe Hiroshi Matsuno Sebastian Mauser Samia Mazouz Jos´e Merseguer

Toshiyuki Miyamoto Madhavan Mukund Wojciech Nabialek Igor Nai Fovino Atsushi Ohta Luca Padovani Wieslaw Pawlowski Luis Pedro Elisabeth Pelz Giovanni Michele Pinna Denis Poitrenaud Agata P´ olrola Franck Pommereau Ivan Porres Wolfgang Reisig Anne Remke Matteo Risoldi Diego Rodriguez Christian Stahl Tatsuya Suzuki Maciej Szreter Shigemasa Takai Dragos Truscan Kohkichi Tsuji Robert Valette Enrico Vicario Jozef Winkowski Satoshi Yamane Gianluigi Zavattaro

Table of Contents

Invited Papers Invariant Based Programming Ralph-Johan Back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

On the Integration of UML and Petri Nets in Software Development Javier Campos, Jos´e Merseguer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

Component Tools: Integrating Petri Nets with Other Formal Methods Ekkart Kindler, Vladimir Rubin, Robert Wagner . . . . . . . . . . . . . . . . . . .

37

Using Colored Petri Nets and Tools to Support Mobile Terminal and Network Software Development Jianli Xu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

Full Papers Compensation in Workflow Nets Baver Acu, Wolfgang Reisig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

The Synthesis Problem of Netcharts Nicolas Baudru, R´emi Morin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

Non-sequential Behaviour of Dynamic Nets Roberto Bruni, Hern´ an Melgratti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Complete Finite Prefixes of Symbolic Unfoldings of Safe Time Petri Nets Thomas Chatain, Claude Jard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 On the Computation of Stubborn Sets of Colored Petri Nets Sami Evangelista, Jean-Fran¸cois Pradat-Peyre . . . . . . . . . . . . . . . . . . . . . 146 On the Construction of Pullbacks for Safe Petri Nets Eric Fabre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 From Petri Nets to Differential Equations - An Integrative Approach for Biochemical Network Analysis David Gilbert, Monika Heiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 How Expressive Are Petri Net Schemata? Andreas Glausch, Wolfgang Reisig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

X

Table of Contents

A New Approach to the Evaluation of Non Markovian Stochastic Petri Nets Serge Haddad, Lynda Mokdad, Patrice Moreaux . . . . . . . . . . . . . . . . . . . 221 Nested Nets for Adaptive Systems Kees M. van Hee, Irina A. Lomazova, Olivia Oanea, Alexander Serebrenik, Natalia Sidorova, Marc Voorhoeve . . . . . . . . . . . . 241 Analyzing Software Performance and Energy Consumption of Embedded Systems by Probabilistic Modeling: An Approach Based on Coloured Petri Nets Meuse N.O. Junior, Silvino Neto, Paulo Maciel, Ricardo Lima, Angelo Ribeiro, Raimundo Barreto, Eduardo Tavares, Frederico Braga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Infinite Process Semantics of Inhibitor Nets H.C.M. Kleijn, M. Koutny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Towards Synthesis of Petri Nets from Scenarios Robert Lorenz, Gabriel Juh´ as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302 Designing Reversibility-Enforcing Supervisors of Polynomial Complexity for Bounded Petri Nets Through the Theory of Regions Spyros A. Reveliotis, Jin Young Choi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 On the Step Explosion Problem Stephan Roch, Karsten Schmidt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 Prospective Analysis of Cooperative Provision of Industrial Services Using Coloured Petri Nets Katrin Winkelmann, Holger Luczak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

Tool Papers Can I Execute My Scenario in Your Net? VipTool Tells You! Robin Bergenthum, J¨ org Desel, Gabriel Juh´ as, Robert Lorenz . . . . . . . . 381 Exhost-PIPE: PIPE Extended for Two Classes of Monitoring Petri Nets Olivier Bonnet-Torr`es, Patrice Domenech, Charles Lesire, Catherine Tessier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 ArgoSPE: Model-Based Software Performance Engineering Elena G´ omez-Mart´ınez, Jos´e Merseguer . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Table of Contents

XI

Petriweb: A Repository for Petri Nets R. Goud, Kees M. van Hee, R.D.J. Post, J.M.E.M. van der Werf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411 Geist3D, a Simulation Tool for Geometry-Driven Petri Nets Jochen Stier, Jens Jahnke, Hausi M¨ uller . . . . . . . . . . . . . . . . . . . . . . . . . . 421 The BRITNeY Suite Animation Tool Michael Westergaard, Kristian Bisgaard Lassen . . . . . . . . . . . . . . . . . . . . 431 Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Invariant Based Programming Ralph-Johan Back Abo Akademi University, Turku, Finland [email protected] www.abo.fi/~backrj Abstract. Program verification is usually done by adding specifications and invariants to the program and then proving that the verification conditions are all true. This makes program verification an alternative to or a complement to testing. We study here an another approach to program construction, which we refer to as invariant based programming, where we start by formulating the specifications and the internal loop invariants for the program, before we write the program code itself. The correctness of the code is then easy to check at the same time as one is constructing it. In this approach, program verification becomes a complement to coding rather than to testing. The purpose is to produce programs and software that are correct by construction. We present a new kind of diagrams, nested invariant diagrams, where program specifications and invariants (rather than the control) provide the main organizing structure. Nesting of invariants provide an extension hierarchy that allows us to express the invariants in a very compact manner. We study the feasibility of formulating specifications and loop invariants before the code itself has been written. We propose that a systematic use of figures, in combination with a rough idea of the intended behavior of the algorithm, makes it rather straightforward to formulate the invariants needed for the program, to construct the code around these invariants and to check that the resulting program is indeed correct.

1

Introduction

Program construction proceeds through a sequence of rather well-established steps: Requirement analysis (understand the problem domain and work out a specification of the problem), design (work out an overall structure for the program), implementation (code the program in the chosen programming language), testing (check that the program works as intended), debugging (correct the errors that testing has revealed), and documentation (provide a report on the program for users, for maintenance and as a basis for later extensions and modifications). Figure 1 illustrates the traditional design-implement-test-debug cycle and the feedback loops in it. Testing increases our confidence in the correctness of the program, but does not prove its correctness. To establish correctness, we need a precise mathematical specification of what the program is intended to do, and a mathematical proof that the implementation satisfies the specification. This kind of software verification is both difficult and time consuming, and is presently not considered S. Donatelli and P.S. Thiagarajan (Eds.): ICATPN 2006, LNCS 4024, pp. 1–18, 2006. c Springer-Verlag Berlin Heidelberg 2006 

2

R.-J. Back Requirement analyzis

Design

Implementation

Testing

Debugging

Documentation

Fig. 1. The programming process

cost effective in practice. Moreover, verification would not replace testing in the above work flow, because most programs are not correct to start with, and need to be debugged before one can even attempt to verify them. This is one reason why modern verification tools like ESC Java [13], JML [6] and Spec# [5] are focused more on debugging than on complete verification of program correctness. Verifying a simple program is usually broken down in the following steps: 1. 2. 3. 4.

provide the pre- and postconditions for the program, provide the necessary loop invariants for the program, compute the verification conditions for the program, and check that each verification condition is indeed true.

Each of these steps have their own difficulties. Formulating pre- and postconditions requires that we have some formal or semi-formal theory of the problem domain. It can also be difficult to identify all the conditions implied by the informal problem statement. The loop invariants must be inferred from the code, and they are often quite difficult to formulate and to make complete enough so that the verification conditions can be proved. Computing verification conditions can be tedious by hand, but this step can be easily automated. Finally, proving that the verification conditions are correct can sometimes be difficult, but for most parts it is quite straightforward. The verification conditions usually consist of a large number of rather trivial lemmas that an automatic theorem prover can verify (provided it has a good understanding of the domain theory). The rest of the lemmas are more difficult, and have to be proved by hand or by an interactive theorem prover with some help and guidance from the user. The work flow above is known as a posteriori verification of software, and is known to be cumbersome. An alternative approach, originally propagated by Dijkstra, is therefore to construct the program and the correctness proof hand in hand. This is known as the correct by construction approach to verification [7]. In other words, verification is done in the coding step rather than after (or as part

Invariant Based Programming

3

of) the testing step. This means that each subunit of the program is specified before it is coded, and it is checked for correctness immediately after it has been written. Writing pre- and postconditions for the program explicitly, as well as loop invariants, is a considerably help in understanding the program and avoids a large number of errors from being introduced in the first place. Combined with stepwise refinement [8], this approach allows the reliable construction of quite large programs. In this paper, we will propose to move correctness concerns to an even earlier place, to the design phase and immediately following the requirement analysis. This means that not only pre- and postconditions but also loop invariants (and class invariants in object-oriented systems) are written before the code itself is written, as a continuation of the design. This will require that the invariants are expressed in the framework and language of the design phase (figures, formulas, texts and diagrams), rather than in the framework and language of the coding phase (a programming language). We refer to this approach as invariant based programming. The idea itself is not new, similar ideas were proposed in the 70’s by John Reynolds, Martin van Emden, and myself, in different forms and variations. Dijkstra’s later work on program construction also points in this direction [9], he emphasizes the formulation of a loop invariant as a central step in deriving the program code. Basic for all these approaches is that the loop invariants are formulated before the program code is written. Eric Hehner was working along similar lines, but chose relations rather than predicates as the basic construct. Figure 2 illustrates the differences in work flow between these three approaches.

Program code

Pre/postconditions

Loop invariants

Pre/postconditions Program code

Loop invariants

Loop invariants

Verification conditions A posteriori proof

Pre/postconditions

Program code

Verification conditions Dijkstra’s approach

Verification Invariant based programming

Fig. 2. Three different approaches to verification

The idea that program code should be enhanced with program invariants is a repeating theme in software engineering. It becomes particularly pressing to include program invariants when we want to provide mechanized support for program verification, because synthesizing program invariants from the code seems to be too hard to mechanize efficiently. The idea that the program invariants should be formulated before the code itself is written has not, however, received much attention.

4

R.-J. Back

Reynolds original approach [16] was to consider a program as a transition diagram, where the invariants were the nodes and program statements were transitions between the nodes. Invariants become program labels in the code, and the transitions between invariants are implemented with goto’s. Reynolds starts by formulating the invariants hand in hand with the transitions between the invariants. The need to formulate invariants early on also highlights the problem of describing the invariants in an intuitive way. For this purpose, Reynolds proposes a visual way of describing properties of arrays. Reynolds work served as the basis for my own early attempt at invariant based programming, where I studied the method in case studies, and proposed multiple-exit statements as programming construct for invariant based programming [2, 3, 4]. Van Emden considered programming as just a way of writing verification conditions [17]. Hehner’s approach is in spirit very similar to invariant based programming, but comes with different building blocks [12]. He describes imperative programs using tail recursion. This means that he is calling parameterless recursive procedures rather than jumping to labels. Semantically, he is working with inputoutput specifications (relations) rather than with invariants (predicates). This approach nicely supports stepwise refinement in a non-structured programming language, but the basic paradigm for constructing programs is different from invariant based programming. I hope to show in this paper that, by a collection of proper enhancements to these early ideas on invariant based programming, it is possible to construct programs that are proved correct with approximately the same amount of work that we today spend on programs that are just tested for correctness. The main issues that we will tackle in the sequel are: – what is a suitable notation for writing invariant based programs, – what is a suitable methodology for constructing invariant based programs (in particular, how do find the invariants before the code has been written), – how do we check the correctness of invariant based programs, and – what are the specific challenges and opportunities with invariant based programming. We will address each of these issues in the remaining sections of this paper.

2

Nested Invariant Diagrams

The traditional programming approach requires that the program code is kept as simple and intuitive as possible. The programmer has to have a good understanding of the structure of the code and on how the code works, because he understands the code in terms of its possible execution sequences. This is the motivation for the structured programming principle [8], which emphasize single-entry-single-exit control structures in order to keep the code simple and disciplined. This makes it easier to build, understand, extend and modify the code.

Invariant Based Programming

5

When one tries to make the program code as simple as possible, there is a danger that the invariants become more complicated. This is because the invariant has to fit the code, and there is no guarantee that simple code leads to simple invariants. Essentially, we have two possible ways of structuring the program, using either control or invariants as the primary structure and the other as the secondary structure, which is adapted to the primary structure. These two structures need not coincide. When we are constructing invariants first, then we should focus on structuring the invariants so that they are as simple as possible to build, understand, extend and modify. We will look at this issue next. Consider the simple summation program in Figure 3, described as a flowchart. The program adds up the first n integers, and shows the result in the variable sum.

k,s:=0,0

k:=k+1; s:=s+k

F

k=n T

Fig. 3. Simple flowchart

Figure 4 shows the same program on the left, but we now added the pre- and postconditions and the loop invariant. Let us introduce the term situation for a condition that describes a collection of states. Here, the precondition, the postcondition and the loop invariant are all situations. We notice that a termination function is also needed, to show that the computation does not loop forever. The program on the right in the same figure is also equivalent to the previous one, but now we have deemphasized the program statements by writing them as annotations on the arrows between the situations. We write both the condition for traversing an arrow (the guard [g]) and the effect of traversing the arrow (an assignment statement ) on the arrow. We are looking for a way to impose some structure on the situations described here. A situation describes a set of states (the set of states that satisfies the condition for the situation). The typical thing that we do with a situation is that we strengthen it by adding new constraints. This means that we identify a subset of the original situation where the new constraints are satisfied. Thinking of situations as sets of states, we can use Venn diagrams to describe this strengthening of situations. Figure 5 shows this nesting of situations for our example program. We have here omitted conditions that are implicit because of nesting. For instance, n ≥ 0 is written only once in the outermost situation, but it will hold in all nested situations. The situations are thus expressed more concisely with nesting. The diagram also shows more clearly how the different situations are related.

6

R.-J. Back

n, sum : integer n>=0

n, sum : integer n>=0 k,s:=0,0

k,s:=0,0 k:=k+1:s:=s+k

k: integer n>=0 0