Algorithmen und Werkzeuge für Petrinetze

Transkript

1 Tagungsband des 18. Workshops Algorithmen und Werkzeuge für Petrinetze AWPN und 30. September 2011 in Hagen

2 Vorwort Der Workshop Algorithmen und Werkzeuge für Petrinetze (AWPN 2011) dient zum achtzehnten Mal der deutschsprachigen Petrinetz-Gemeinschaft als fachliches Austauschforum. Veranstalter ist die Fachgruppe Petrinetze und verwandte Systemmodelle der Gesellschaft für Informatik (GI). Veranstaltungsort ist in diesem Jahr am 29. und 30. September der Lehrstuhl für Softwaretechnik und Theorie der Programmierung der FernUniversität in Hagen. Der vorliegende Bericht enthält die Beiträge des Workshops. Alle Beiträge wurden auf ihre Relevanz hinsichtlich der AWPN-Workshop-Reihe geprüft, ohne dass eine formale Begutachtung erfolgte. Weitere Informationen zum Workshop finden sich unter Hagen, September 2011 Robin Bergenthum

3 Inhaltsverzeichniss Towards Unit Testing for Java Reference Nets Lawrence Cabac, Michael Duvigneau, Daniel Moldt, Matthias Wester-Ebbinghaus 1 Simplifying Mined Process Models: An Approach Based on Unfoldings Dirk Fahland 7 Bereitstellung eines Synchronisationsmechanismus für MULAN basierte Agenten Julia Fix, Michael Duvigneau, Daniel Moldt 8 Modellierung verschränkter Zustände zur Indikation unvollständiger Planbarkeit von Auktionsverhandlungen Christian Flender 15 Atomic Fragments of Petri Nets Monika Heiner, Harro Wimmel, Karsten Wolf 21 MuPSi - interaktive Erstellung und Simulation von Transitionsschritten in Petrinetzen Thomas Irgang, Andreas Harrer, Robin Bergenthum 26 Data under control Niels Lohmann, Karsten Wolf 34 Generierung allgemeiner partieller Sprachen und effiziente Synthese von Petrinetz-Modellen Robert Lorenz, Christoph Etzel, Dan Zecha, 41 Decomposing Petri Net State Spaces Christian Stahl 49 Approaching the Integration of Agents and Workflows Thomas Wagner, Daniel Moldt 55 Complexity of Universal Inhibitor Petri Net Dmitry Zaitsev 62

4 Towards Unit Testing for Java Reference Nets Lawrence Cabac, Michael Duvigneau, Daniel Moldt and Matthias Wester-Ebbinghaus Department of Computer Science, TGI, University of Hamburg Abstract. When using high-level Petri nets in a software engineering context as source code mixed with Java classes, verification of the whole system is impossible. We present net components that are designed to test the behavior of Petri nets under development. In a second step, the execution of these test components is automated and integrated into the unit testing framework JUnit. As the paper presents work in progress, it concludes with a discussion of open questions concerning conceptual and implementation issues. Keywords: high-level Petri nets, reference nets, testing, verification, JUnit, Renew 1 Introduction In software engineering it is necessary to ensure the intended behavior of the software under development. In order to fix bugs as early as possible and to prevent new bugs from entering the model in further development, the software should be checked after every modification. With verification and testing, two approaches compete on how to accomplish this task. While verification offers complete coverage of the analyzed system and reliable proof of properties, the overhead for formal specification (often in a different language than is used for the source code) and the feasability of computation are its major drawbacks. In contrast, testing (see [7]) uses the same language and is well tailorable to check the important use cases of the system without consuming too many resources, but it cannot provide a complete proof. Automated testing becomes increasingly popular as it integrates well with the build process of complex software systems. In the context of the PAOSE approach (Petri net-based agent-oriented software engineering) high-level Petri nets the Java reference nets are used equally to other source code, such as Java code and declarative descriptions (XML, SL). The basis for modeling and execution of the Petri nets is provided by the tool Renew [6]. With Petri nets as source code, we get the formal specification for free, and there are many well known methods available for verification. In [3], the possibility to verify nets via the Lola tool has been added to Renew. However, as many Java reference nets are used in combination with Java objects and implement functionality for Java classes, we are not able to verify the complete system. Moreover, reference nets with net instance creation are Turing complete and thus undecidable (see [5]). 1

5 Thus, testing Petri net models is becoming an increasingly interesting alternative to verification. During PAOSE development, we already provide an integration of automated unit tests during the build process for Java source code using the JUnit framework [4]. But the Java reference net-based parts of the code are not covered by the testing framework. It is therefore desirable to be able to specify tests for Petri net code, to run these tests automatically, and to include the test results in the JUnit reports for Java code. Here we present the first steps towards an extension for the unit testing framework in order to allow to define and automatically run unit tests for single page reference nets. In Section 2, we develop a technique to specify tests within the Petri net code using dedicated net components. These tests can be executed manually by the developer in the editor and simulation engine Renew. In Section 3, we tackle the technical part of the integration of the automated Petri net tests in a JUnit execution run. The modifications that are necessary to allow automated execution of the Petri net test components are also described in Section 3. The paper concludes with a discussion of open questions in Section 4. 2 Manually Testing Reference Nets In multi-agent applications according to our Mulan framework ( the behavior of agents is determined by reference nets that are either protocol nets (for ongoing conversations with other agents) or decision components (for agent-internal decision processes). Both types of reference nets offer specific synchronous channel interfaces where normally the surrounding agent net submits / receives data. Along these interfaces, we offer net components with the specific purpose to test protocol nets and decision components in isolation, which means without having to setup a surrounding agent environment. Figure 1 shows an example of an agent s decision component. It is part of a chat agent where the agent receives user input from a Web interface and interacts with other chat agents accordingly. The net is processed from left to right. In the upper part of the net, the request of a user for updating the list of its chat partners is processed. Here, we concentrate on the lower part, where the input of a user for sending a chat message to other users is processed. 1 The parts of the net that are emphasized by the red circles are interface transitions, where normally data is transmitted to and from the surrounding agent net: (1.) calling the decision component with the user s chat message, (2.) receiving information concerning to which other agents to forward this message, (3.) getting the finish/return notification. Figure 2 zooms into the lower part of the decision component where the test components are. Instead of the surrounding agent net, now these components take care of interacting with the synchronous channel interfaces of the decision component. On the left hand side of Figure 2 the data for the handling of one 1 Note that it is not important to be able to read the net in its details. The net is, however, the executable implementation of the WebChat agent s DC. 2

6 Fig. 1. A reference net including test elements. Fig. 2. Test components for the given net including annotation for unit tests. call of a chat message is set up (test setup). On the right hand side are test components that simulate the message handling call (1.), the delivering of message forwarding information (2.) and the finishing/return of the decision component call (3.). This simulation of the environment done in the test setup allows to test the behavior of the decision component net in isolation. In fact, this is quite similar to the setup of JUnit test cases. The transitions with orange fill color and red line color are transitions that have to be fired manually by a user. As Renew allows a user to inspect the data resting on places of a reference net during simulation, the user can easily and comfortably monitor and control the run of a test case for the current decision component in focus (or analogously, the protocol net). 3

7 While this kind of manual testing of protocol nets and decision components is very useful for the development and debugging stages of a multi-agent application, it is also necessary to have automated testing facilities for an already quite stable application. Therefore, we have integrated the control of reference net test runs into the Java Unit Test framework. 3 Integration and Automation of Tests The extension to the unit testing frame work to test reference nets has to solve some conceptual and technical problems. The major obstacle is the fact that reference nets (such as all Petri nets) have to run in a simulator (sometimes called virtual machine). This means that the net cannot be executed directly by a framework such as JUnit. Instead JUnit has to provide an simulation environment that includes the Petri net simulator. This prevents the test cases from directly accessing (testing) functionality provided by the Petri nets. Due to the nature of reference nets being nets-within-nets usually reference nets are executed within a net system. In order to test one net the surrounding environment has to be simulated too. It is actually a common requirement of unit tests that they have to provide the testing setup. Several possible approaches to overcome the mentioned obstacles are outlined in the following. They are described by the system that takes the initial control of the testing process. Renew in JUnit The test is set up, run, and controlled by JUnit. Renew s Simulator is started by the unit test case and the net execution is controlled by the test case as well. For this direct access of the nets interface has to be provided to JUnit. Also, due to the plugin based architecture of Renew and the numerous class loaders and net loaders responsible for the loading of source code artifacts the manual setup (configuration) is rather extensive. JUnit in Renew The simulation is setup and controlled by Renew and its plugin architecture. The simulation can be started and a unit test can be executed on the simulated net. Such an extension to Renew can be easily realized as Renew plugin. However, the test framework, the test control and the reporting has to be provided by the implementation making this rather extensive. The test cases have to be provided in a form that is native to Renew. Although Java test cases would be possible to implement in this version as well, the advantages of using Renew as the foundation were diminished. The natural way would be to define the test cases as reference nets as well. This however and the technical aspects do not integrate well with the JUnit testing framework. Hybrid It seems a mix of both approaches has its advantages. The setup of the simulation environment and the control is handled by JUnit while the net specific setup and test case is provided as net specification. In our first step we have opted for a hybrid approach. In fact, we are reusing the manual test cases, which have been outlined in Section 2. However, these 4

8 manual testing components are designed for a semi-automatic interactive testing of the net. 2 In order to be able to control the (Petri net) test cases from JUnit we need to provide an access to the net instance and its elements. We have opted for a light weight annotation of net elements. Thus, the test case is still executable in the manual execution. Only the triggering of manual transitions ) and checking of results ) have to be amended manually. However, still JUnit has to provide an extensive technical setup configuration in order to be able to access the simulation and the involved elements. This is not presented here. 4 Conclusion In this work we present a possibility to test reference nets as unit tests integrated in the test framework of JUnit. The chosen approach combines Petri net test cases that have been designed originally for the manual (or semi-automatic) testing on the bases of testing net components with a JUnit integration that automatizes and controls the simulator and the execution of the test case. We outline the possibilities of the technical integration as well as present an example that illustrates the approach in the context of PAOSE. The presented approach are the first steps towards a testing framework for reference nets. These first steps lead directly to several insights and questions in this context. Testing vs. Verification It seems that is certain settings testing net systems can have some advantages. If the formalism is to powerful. If the designed models are too complex for current verification techniques. In an incremental approach of modeling, where the whole system is not (yet) verifiable. Concurrency and Nondeterminism Obviously the testing of nondeterministic and concurrent behavior are challenging. Here we have provided a purely sequential approach. Further investigation into these topics have to be made. Technical Integration An integration of a highly developed framework, such as JUnit reduces implementation expenses. However, the overhead of the simulation setup in addition to the test setup in combination with the poor inter-language controlability of the tests shows the need for a higher integration of the testing framework into the native language reference nets and virtual machine Renew. Test Suites In order to easily use the testing framework, we need to improve on the integration into the build process. In application development especially those parts that are prone to rapid change and likely to be changed by different developers should be included in test suites that define the desired behavior of the developed system. Reporting Since there is a gap between the execution of the Java testing framework and the execution of the Petri net simulation it is not possible to report on error cases that result from the net execution. 2 The execution of the tests during normal execution of the net are prevented by using non-spontaneous manual transitions. 5

9 Coverage The isolated reference nets are tested against their interfaces. This means that the interior of the process, between calling of a Petri net process and the observation of a possible result, are not subject to the test. In this setting the question how much of the actually designed Petri net model is checked in terms of net elements and also in terms of possible paths cannot be answered. In order to be able to report the coverage of the test suite, it seems that another approach has to be chosen. Although the approach seems still quite experimental, we can still conclude that the approach has its merits. Nevertheless, there is still much work to be done. The complexity of the writing of the tests and its time consumption has to be reduced. The testing net components have to be improved and tailored for the combined purpose: semi-automatic and unit testing. In the long term, an integration of a unit testing framework within Renew as a plugin is envisioned. References 1. L. Cabac. Net components: Concepts, tool, praxis. In D. Moldt, editor, Petri Nets and Software Engineering, International Workshop, PNSE 09. Proceedings, Technical Reports Université Paris 13, pages 17 33, 99, avenue Jean-Baptiste Clément, Villetaneuse, June Université Paris L. Cabac. Modeling Petri Net-Based Multi-Agent Applications, volume 5 of Agent Technology Theory and Applications. Logos Verlag, Berlin, M. Hewelt, T. Wagner, and L. Cabac. Integrating verification into the PAOSE approach. In M. Duvigneau, D. Moldt, and K. Hiraishi, editors, Petri Nets and Software Engineering. International Workshop PNSE 11, Newcastle upon Tyne, UK, June Proceedings, volume 723 of CEUR Workshop Proceedings, pages CEUR-WS.org, June JUnit O. Kummer. Referenznetze. Logos Verlag, Berlin, O. Kummer, F. Wienberg, M. Duvigneau, and L. Cabac. Renew the Reference Net Workshop. Available at: Aug Release G. J. Myers. The art of software testing. Wiley & Sons, Hoboken, NJ, 2 edition,

10 P_39 P_1 P_38 P_14 P_13 P_40 P_30 P_34 P_8 P_36 P_7 P_11 P_10 P_6 P_9 P_32 P_22 P_15 P_25 P_5 P_19 P_4 P_21 P_18 P_3 P_33 P_26 P_20 P_12 P_24 P_27 P_28 P_37 P_29 P_17 P_35 P_23 P_2 P_31 P_16 P_6 P_14 P_25 P_13 P_10 P_38 P_26 P_9 P_17 Simplifying Mined Process Models: An Approach Based on Unfoldings Extended Abstract Dirk Fahland Eindhoven University of Technology, The Netherlands Process discovery is the problem of (automatically) discovering a process model that describes process executions that have been observed in an actual information system (IS). Input for process discovery is a collection of traces recorded by the IS in an event log. Each trace describes the life-cycle of a process instance (often referred to as case). Output is a process model that is able to reproduce these traces. The automated discovery of process models based on event logs helps to jump-start process improvement efforts and provides an objective up-to-date process description. However, if the behavior recorded in an event log also comprises low-frequent or exceptional behavior, existing process mining algorithms 1 tend to produce overly complex process models as illustrated in Figure 1 (left). Generally, process models discovered using process mining tend to be complex and have problems balancing between overfitting and underfitting. Overfitting models are not general enough while underfitting models allow for too much behavior. We presents a post-processing approach to simplify discovered process models while controlling the balance between overfitting and underfitting. The discovered process model, expressed in terms of a Petri net, is unfolded into a branching process using the event log. Subsequently, the resulting branching process is folded into a simpler process model capturing the desired behavior. Classical net reduction techniques (i.e., removing places) allow to simplify the model structure further while allowing to control process model generalization. Figure 1 (right) shows the result of this simplification procedure. We will finally highlight some more applications of the idea of unfolding a model, operating on the unfolding structure, and folding the unfolding back to a process model. 1 see Wil M.P. van der Aalst: Process Mining: Discovery, Conformance and Enhancement of Business Processes. Springer (2011) Fig. 1. Hospital patient treatment process after process mining (left) and after subsequent simplification using the approach presented in this talk (right). 7

11 Bereitstellung eines Synchronisationsmechanismus für Mulan-basierte Agenten Julia Fix, Michael Duvigneau, Daniel Moldt Universität Hamburg, Fachbereich Informatik Zusammenfassung Im Bereich der Emotionsmodellierung existieren bisher überwiegend sequentielle Modellierungstechniken. Eine auf agentenorientierten Petrinetzen basierende Referenzarchitektur für Emotionsmodellierung EMulan liefert eine konzeptionelle Trennung von kognitiven Emotionsmodellen in rationale und emotionale Bestandteile. Diese Bestandteile sind jedoch für die korrekte Darstellung des Verhaltens wieder zu synchronisieren. Die bisherige Mulan-Architektur sah in den konkreten Umsetzungen mittels Capa lediglich asynchrone Kommunikation vor. In diesem Papier wird daher ein Synchronisationsmechanismus vorgestellt, der es erlaubt, Agenten innerhalb einer Plattform zu synchronisieren. Dabei wird eine tiefe Synchronisation bereitgestellt. Über den spezifischen Anwendungsbereich hinaus kann diese Technik nun in allen Mulan-Umgebungen verwendet werden. 1 Einleitung und Motivation Im Rahmen der Arbeit an einem analytischen Referenzmodell zur Modellierung und Entwurf von emotionalen Agentenarchitekturen, das auf Basis von der Petrinetz-basierten Agentenarchitektur Mulan entwickelt wird (EMulan) [3], wurde die Notwendigkeit der konzeptionellen Erweiterung von derzeitigen Mulan-Architektur um einen Synchronisationsmechanismus deutlich. Als eine der Anforderungen an das Referenzmodell für die Emotionsmodellierung wurde die Möglichkeit der konzeptionellen Trennung bei der Repräsentation rationaler / kognitiver und emotionaler Prozesse definiert. Diese Anforderung basiert auf den neurophysiologischen Untersuchungsergebnissen, die besagen, dass emotionale und kognitive Verarbeitungsprozesse nach der Wahrnehmung eines Stimulus parallel ablaufen und sich gegenseitig ergänzen [8]. Die explizite Trennung in rationale und emotionale Modellkomponenten soll im Referenzmodell in erster Linie den Forschungszwecken dienen: Zum einen ermöglicht sie die explizite Darstellung und Erforschung der Wechselwirkungen dieser zwei Mechanismen; zum anderen ist dadurch die Auswertung des Potentials der Emotion für die Optimierung der (zur Zeit meist rationalen) (Multi-) Agentenarchitekturen möglich. Es handelt sich also um eine rein analytische Trennung, die vor allem auf die konzeptuelle Abgrenzung und Analyse der zugrundeliegenden komplementären Prozesse abzielt. Kognition und Emotion werden jedoch hierbei als zwei komplementäre und aufeinanderbezogene Systemsichten betrachtet, die in natürlichen intelligenten Systemen oft nicht klar voneinander abgegrenzt werden können. Deshalb müssen diese zwei Sichten wieder zusammengefügt werden können, wobei das Referenzmodell als Modellierungstechnik die technische Möglichkeit für eine solche Synchronisation bieten soll. Obwohl die meisten psychologischen Emotionstheorien ausschließlich sequentielle Aussagen über die Ausgestaltung des Emotionsgenerierungsprozesses machen, geben einige einschätzungstheoretische Beschreibungen Hinweise darauf, dass diese sequentielle Betrachtung nur deshalb gewählt wurde, weil es keine andere Darstellungsmöglichkeit für die einzelnen 8

12 Prozessschritte bei der herkömmlichen textuellen Beschreibung geben kann (z. B. [4], [9], [7], [11]). An dieser Stelle bieten Petrinetze eine ausdrucksstarke Darstellungsmöglichkeit: Durch Nebenläufigkeit, Faltungsmechanismus und weitere Netzeigenschaften kann man parallel verlaufende Prozesse problemlos in einem Modell darstellen, verlustfrei Modelle / Modellteile auffalten und eine Separierung von Modellteilen vornehmen, die man z. B. durch synchrone Kanäle in natürlicher Weise wieder integrieren kann. Es ist hierbei anzumerken, dass sequentielle (Teil-)Modelle unverändert in den nebenläufigen Formalismus übernommen werden können. Interessanterweise werden aufgrund der sequentiellen Betrachtungsweise bisher kaum Synchronisationen von Teilmodellen betrachtet; wenn, dann wird dies implizit durch Kopplungen von Modellen erfasst. Diese Kopplung oder Synchronisation lässt sich bisher nicht über Mulan-Agenten modellieren, da diese ausschließlich asynchron kommunizieren. In [2] bzw. [3] wurden die verschiedenen Möglichkeit der Kopplung der Modellkomponenten von EMulan-Architektur informal diskutiert. In diesem Papier wird ein detaillierterer Vorschlag vorgestellt, der eine Synchronisation auf Agentenebene ermöglicht. Dazu wird zunächst die Mulan-Architektur erläutert, die hier um einen synchronen Kommunikationsmechanismus erweitert wird. Dann wird die Realisierung der technischen, ausführbaren Synchronisation von Agenten erläutert. Der Beitrag schließt mit einer Diskussion der Ergebnisse und einem Ausblick. 2 Die petrinetzbasierte Multiagentenarchitektur Mulan Die Multiagentenarchitektur Mulan (Multi-Agent Nets) (siehe [6,10]) ist ein allgemeines Rahmenwerk zur Darstellung von Multiagentensystemen mit Hilfe der Referenznetze. Die technische Plattform Capa fügt sich in das Rahmenwerk ein, um Mulan-Agenten eine rechnerübergreifende Kommunikationsinfrastruktur gemäß den FIPA-Spezifikationen zu bieten (vgl. [1]). Die Kombination Mulan/Capa wird seit vielen Jahren zur Darstellung, Implementierung und Simulation von verteilten Agenten angewendet. Abbildung 1 zeigt die konventionelle Mulan-Architektur mit den vier Hierarchiestufen Multi-Agentensystem, Agentenplattform, Agent und Protokoll, sowie die zur Bereitstellung des Synchronisationsmechanismus im Rahmen dieser Arbeit vorgenommenen Erweiterungen bzw. Anpassungen (farblich hervorgehoben). Im Folgenden wird zuerst die konventionelle Mulan-Architektur kurz beschrieben. Diese Beschreibung basiert im Kern auf [5]; für die ausführliche Darstellung siehe [10]. Anschließend wird im Abschnitt 3 auf die neuen Elemente und ihre Rolle für die Synchronisationsmodellierung eingegangen. In der Abbildung wurde die MAS-Architektur in Mulan vereinfacht dargestellt, z.b. wurden einige Anschriften sowie alle synchronen Kanäle weggelassen. Links oben ist die Architektur des Agentensystems dargestellt. Der gestrichelte Pfeil bedeutet die vergrößerte Darstellung einer Marke, also der Plattform. Die Plattform enthält Agenten(-netze), die auf der zentralen Stelle agents liegen. Die Transitionen stellen Dienste der Plattform dar: Agenten können von der Plattform erzeugt (Transition new) und wieder gelöscht (Transition destroy) werden. Die Plattform ermöglicht die Migration der Agenten, sowie ihre Kommunikation sowohl mit den Agenten auf der Plattform (Transition internal communication), als auch mit externen Agenten (Transition external communication). Eine weitere Vergrößerung, diesmal der Agentenmarke, zeigt das Agentennetz. Ein Agent kommuniziert mit seiner Umwelt mittels Nachrichten, die er als Input von außen bekommt und verarbeitet oder ggf. verschickt. Er kann so über die Plattform mit anderen Agenten 9

13 Abbildung 1. Abstrakte Multiagentenarchitektur Mulan aus [5]; modifiziert und um einen synchronen Kanal erweitert kommunizieren. Die Transitionen incoming und outgoing sind die einzigen Schnittstellen des Agenten zu dem Rest des Agentensystems, alle anderen Aktivitäten sind in seinem Inneren gekapselt. Die Verhaltensweisen eines Agenten werden durch Protokolle modelliert, die als Marken an der Stelle protocols vorliegen. Die Wahl der Protokolle (also der auszuführenden Verhaltensweisen) ist die zentrale Aktivität eines Agenten. Die Protokolle können proaktiv (Transition pro) oder reaktiv (Transition re) ausgewählt werden. Mit dem Schalten der Transition pro kann ein Protokoll, also eine Verhaltensweise, ohne Input von außen gestartet werden, z.b. als Folge agenteninternen Deliberationsprozesse. Die Transition re schaltet nur als Reaktion auf eine von außen ankommende Nachricht. Nach der Abarbeitung werden die Protokolle, d.h. die abgeschlossenen Verhaltensweisen abgezogen (Transition stop). Protokolle sind spezielle Referenznetze, deren Schnittstelle eindeutig durch das Agentennetz vorgegeben ist. Ein Protokoll (rechts unten) steuert den Agenten von innen und kommuniziert mit anderen Agenten über Transitionen, die der Agent dem Protokoll als Dienst anbietet: Nachrichteneingang und -ausgang (Transitionen in und out). Protokolle implementieren das Agentenverhalten und können sowohl einfache serielle Abläufe, als auch komplexe dynamische Workflows darstellen. Die EMulan-Rahmenwerk ([3]) entsteht durch die Entfaltung der emotionalen Prozesse, die in Mulan implizit berücksichtigt wurden, in eine getrennte Architektur, wobei zu jeder Mulan-Ebene eine korrespondierende Komponente des EMulan-Rahmenwerks in Beziehung gesetzt wird. Damit stellt die (EMulan)-Architektur eine spezielle Sicht auf das System dar, in die insbesondere emotionale Prozess bzw. Verhaltensaspekte ausgegliedert werden, während rationale / kognitive Verhaltenskomponenten quasi weiterhin in der Mulan-Architektur verbleiben. 10

14 3 Mulan-Erweiterungen für die Modellierung synchroner Prozesse Bei der Betrachtung der psychologischen Emotionstheorien in [4], [9], [7] und [11] wurden bisher nur sequentielle Beschreibungen des Einschätzungsprozesses vorgefunden. Die Modellierung dieser Theorien erfordert deshalb grundsätzlich keine synchrone Kopplung innerhalb des Einschätzungsmodells. Für die Umsetzung von mehreren Emotionstheorien innerhalb eines Modells bzw. für die Parallelisierung von Einschätzungen im Emotionsgenerierungsprozess wird die Möglichkeit der synchronen Modellierung interessant. Diese soll hier durch die entsprechende Erweiterung des Mulan-Modells zur Verfügung gestellt werden. 3.1 Technische Erweiterung Durch die Auffaltung der Mulan-Architektur im EMulan-Referenzmodell entsteht eine Art Schattenarchitektur zu Mulan, so dass jede Architekturebene nun konzeptionell durch zwei getrennte symmetrische Agentenmodelle dargestellt wird. Damit diese ausdrucksstark synchronisiert werden können, ist das Referenzmodell auf jeder Ebene entsprechend zu erweitern. Als ersten Schritt erweitern wir die Mulan-Ebenen von der Platform bis herunter zum Agentenprotokoll, so dass die Synchronisation von Agenten innerhalb einer Plattform möglich wird. Die grundlegende Idee ist dabei, die Schnittstelle des Agenten zur Plattform, welche bisher aus zwei für asynchrone Kommunikation genutzten Kanälen besteht, um einen weiteren Kanal für synchrone Kommunikation zu ergänzen. Auf Plattformebene wird die Dienstleistung Interne Kommunikation an die erweiterte Schnittstelle angepasst, so dass sie sowohl synchrone als auch asynchrone Kommunikation unterstützt. 1 Auf Agentenseite wird eine dritte Schnittstellentransition für den synchronen Kommunikationskanal in das Modell integriert. Da die Verhaltenssteuerung des Agenten im Wesentlichen auf der Ebene der Protokolle geschieht, muss dieser Kanal zu den Protokollinstanzen durchgereicht werden. Die neuen Transitionen und ihre Verbindung sind in Abbildung 1 im Agentennetz farblich hervorgehoben. Die gepunktete Verbindung zwischen den beiden beteiligten Transitionen symbolisiert zunächst einen fest verdrahteten synchronen Kanal (quasi eine permanente Verschmelzung der beiden Transitionen). Diese Verbindung kann in verfeinerten Versionen des Modells durch ein Unternetz weiter ausgestaltet werden, um dem Agentennetz eine Kontrolle über die Kommunikationsmöglichkeiten seiner Protokolle einzuräumen. Auf der Ebene der Protokollnetze wird ebenfalls ein neuer Kanal in die Schnittstelle eingefügt. Neben start und stop (Protokoll-Lebenszyklussteuerung), in und out (asynchrone Kommunikation) sowie access und exchange (Agenten-interner Informationsfluss) steht nun ein Kanal inout für synchrone Kommunikation zur Verfügung. Dieser Kanal nimmt zum einen Meta-Informationen über die angestrebte Interaktion auf, insbesondere Angaben zum intendierten Partner. Zum anderen bietet er einen frei unifizierbaren Parameter, über welchen die kommunizierenden Protokolle beliebige Daten in beide Richtungen austauschen können. Die Synchronisation von Kontrollfluss und Information zwischen den Interaktionspartnern wird somit vollständig durch die Bindungssuche des zugrunde liegenden Petrinetz-Simulators hergestellt. 1 Die Transition Interne Kommunikation des Mulan-Modells war de facto schon immer eine synchrone Verschmelzung der Ein- und Ausgabekanäle beider Kommunikationspartner, die Asynchronizität wurde auf Agentenseite sichergestellt. In der technischen Capa-Plattform wurde die interne Kommunikation hingegen tatsächlich asynchron implementiert. Hier besteht die Ergänzung darin, die synchrone Transition des Mulan-Modells zusätzlich zu übernehmen. 11

15 consumer address :start() START (IN) :in(p) > > consumer address aid [find consumer] :access(wb) wb:ask("consume",aidvts) action aid=(agentidentifier) aidvts.iterator().next() (bei mehreren moeglichen Consumer nehmen wir einfach den ersten) > product obj > cons action obj = "Tisch"; action cons = new Consume(); action cons.setproduct(obj.tostring()); [produce product] consumer address aid > cons > :out(p2) p2 p2 OUT action p2=sl0creator.createactionrequest( aid, cons) [send offer] product > aid obj > :inout(aid,"handover",[obj, cash]); guard cash > 10; IN/OUT [handover] cash money > :stop() > STOP Abbildung 2. Protokoll des Produzenten mit synchronem Kanal; neue Netzkomponente In Abbildung 2 ist am rechten Ende an der Spitze des Dreiecks die Verwendung des Kanals auf der Ebene der Protokollnetze zu erkennen (das Beispiel wird im folgenden Abschnitt näher erläutert). Die endgültige Form der Netzkomponente steht noch nicht fest. Derzeit ist die Synchronisationstransition separat vom Kontrollfluss angeordnet. Die zusätzlichen Netzelemente sind jedoch modellierungstechnisch nicht notwendig, so dass die Netzkomponente auch so einfach wie die Stop-Transition gestaltet werden könnte. Eventuell sind für verschiedene Arten der synchronen Bearbeitung unterschiedliche Netzkomponenten sinnvoll, um die unterschiedlichen Möglichkeiten des Datentransfers zu ermöglichen. 3.2 Anwendungsbeispiel Zur Illustration der Technik wird das einfache Erzeuger-Verbraucher-Beispiel um eine synchrone Produktübergabe ergänzt. Dieses Beispiel stammt zwar nicht aus dem EMulan- Kontext, ist dafür aber leichter zu erklären. Beteiligt sind zwei Agenten, ein Erzeuger und ein Verbraucher. Der Erzeuger benachrichtigt (asynchron) den Verbraucher, dass er ein Produkt erzeugt hat. Anschließend tauschen beide Agenten synchron das Produkt gegen Geld. producer address producer address :in(p) money 15 aid cash :inout(aid,"handover",[obj, cash]); guard obj.tostring().equals(cons.getproduct()); obj :start() START ( IN ) p p aid offer msg. cons action cons = Consume.fromAclMessage(p); action aid = p.getsender(); > offer msg. cons IN/OUT > > [handover] product offer msg. obj cons consume action JOptionPane.showMessageDialog( null, "Consumed: "+obj + "\ndescribed as: " + cons.getproduct()); > > :stop() > STOP Abbildung 3. Protokoll des Konsumenten mit synchronem Kanal; neue Netzkomponente Das Protokollnetz des Erzeugers ist in Abbildung 2 zu sehen, das Protokollnetz des Verbrauchers in Abbildung 3. Die mit rechtwinkligen Dreiecken hinterlegten Netzkomponenten implementieren die asynchrone Kommunikation. Die spitzeren gleichwinkligen Dreiecke 12

16 kennzeichnen die synchrone Kommunikation. Die Synchronisation findet jeweils an der Transition an der Spitze statt. Der dritte, frei unifizierbare Parameter wird in beiden Protokollnetzen durch ein zweistelliges Tupel belegt, so dass der Erzeuger sein Produkt an die erste Position und der Verbraucher sein Geld an die zweite Position unifizieren kann. Beide Protokollnetze stellen über einen guard an der Transition sicher, dass die Synchronisation nur stattfinden kann, wenn der Interaktionspartner Objekte gemäß Vereinbarung am Kanal bereitstellt. Wenn die Synchronisation erfolgreich ist, schalten beide Transitionen atomar unter Beteiligung der vermittelnden Infrastrukturtransitionen des Agenten und der Plattform. 4 Diskussion In der aktuellen Agentenforschung wird durch die Modellierung von emotionale Mechanismen innerhalb eines Agentensystems versucht, die Aspekte der Verteilung, Interaktion, Adaptivität und Autonomie mit Hilfe emotionaler Komponenten bzw. Mechanismen zu optimieren (s. [12] für eine Übersicht). Nebenläufigkeit wurde bisher aber nicht als wichtige Modellierungsperspektive angesehen. Um rationale und emotionale Modellkomponenten des EMulan-Referenzmodells wieder zusammenzuführen, muss das Referenzmodell um ein Synchronisationsmechanismus erweitert werden. Hier leistet diese Arbeit jetzt einen Beitrag, indem nach der informaler Darstellung jetzt die vollständige operationale Semantik mittels Referenznetzen für den Mulan-Kontext aufgezeigt wird. Der hier für EMulan präsentierte Synchronisationsmechnismus erweitert auch Mulan um eine synchrone Schnittstelle. Während Agenten ihre Autonomie dadurch behalten, dass sie die Protokolle selbstständig starten können, wird wie bisher für die asynchronen Protokolle eine statische Realisierung auf der Agentenebene implementiert. Hier könnte eine weitere Flexibilisierung durch die Einführung einer vermittelnden Stelle erreicht werden. Die bisher in Abbildung 1 dargestellte gestrichelte Linie würde dann durch eine Stelle mit dem vermittelnden Netz, das die jeweiligen Zugriffe auf die synchronen Protokolle auf spezifische Art erlaubt, ausgestattet werden. Die Behandlung von Parametern ist ein weiterer Aspekt, der bzgl. der Synchronisation von Bedeutung ist. Durch die bi-direktionale Kommunikation, die zudem durch die Schaltregel bzw. den Simulator realisiert wird, können beliebig komplexe (synchrone) Funktionen realisiert werden. Was in diesem Beitrag nicht gelöst wird, ist die Plattform-übergreifende Synchronisation. Diese erfordert eine wesentlich komplexere Lösung, wobei es für die aktuell möglichen Implementierungen von Modellen keine realistische Lösung im verteilten Fall gibt. Örtlich verteilte Plattformen müssen also mit einer anderen Art der Synchronisation ausgestattet werden. Die hier vorgestellte Lösung liefert aber für die EMulan- und Mulan/Capa-Umgebungen eine sehr ausdrucksstarke und leistungsfähige Erweiterung. 5 Zusammenfassung und Ausblick Nebenläufigkeit in emotionstheoretischen Modellen, die für die Informatik aufbereitet wurden, gab es bisher kaum. Damit es gelingt, komplexe Sachverhalte analytisch sauber zu trennen, ist eine separate Modellierung der unterschiedlichen Sachverhalte notwendig. Die Trennung von Emotionstheorien in rationale und emotionale Bestandteile für die kognitiven Gesamtmodelle ist ein gutes Beispiel dafür. Trotz dieser Trennung sind die Modelle aber weiterhin inhaltlich zu synchronisieren. Dies lässt sich für einfache Abläufe durch entsprechende Interaktionen, basierend auf Nachrichtenaustausch oft realisieren. Komplexe Interaktionen, die wechselseitige Abhängigkeiten beinhalten und die von außen als eine gemeinsame Aktion betrachtet werden sollen, erfordern das ausdrucksstärkere Konzept der Synchronisation. 13

17 In diesem Beitrag wurde für die engere Kopplung von Modellen, insbesondere von petrinetzbasierten Agentensystemen, die ausdrucksstärkere Synchronisation über synchrone Kanäle dargestellt. Damit lassen sich für die in [3] vorgestellte EMulan Architektur die zuvor analytisch getrennten rationalen Bestandteile mit denen der emotionalen Bestandteile der kognitiven Theorien wieder vollständig und effizient integrieren. Diese Modellierung kann in Prinzip für jede Art der (Mulan) Modellierung verwendet werden. Sie ist nicht auf die Anwendungsdomäne der Emotionstheorien beschränkt. Jegliche zu synchronisierende Agenten können mittels dieses Verfahrens modelliert werden. Insbesondere wurde hier eine technische Umsetzung für die Capa-Umgebung vorgestellt. Andere Agentenmodelle können von dem hier vorgestellten Verfahren wichtige Anregungen für eine synchrone Architekturerweiterung übernehmen. Literatur 1. Michael Duvigneau, Daniel Moldt, and Heiko Rölke. Concurrent architecture for a multi-agent platform. In Fausto Giunchiglia, James Odell, and Gerhard Weiß, editors, Agent-Oriented Software Engineering III. Third International Workshop, Agent-oriented Software Engineering (AOSE) 2002, Bologna, Italy, July Revised Papers and Invited Contributions, volume 2585 of Lecture Notes in Computer Science, pages 59 72, Berlin Heidelberg New York, Springer-Verlag. 2. Julia Fix and Daniel Moldt. Modelling emotions in multi-agent systems based on Petri-net modelling technique. In D. Reichardt, P. Levi, and J.-J. Chr. Meyer, editors, Emotion and Computing Current Research and Future Impact. 1st Workshop at KI 2006, Bremen, Germany. Proceedings, pages University of Bremen, Julia Fix and Daniel Moldt. A reference architecture for modelling of emotional agent systems. In Lars Braubach, Wiebke van der Hoek, Paolo Petta, and Alexander Pokahr, editors, Multiagent System Technologies. 7th German Conference, MATES 2009, Hamburg, Germany, September 9-11, Proceedings, volume 5774 of Lecture Notes in Artificial Intelligence, pages , Berlin Heidelberg New York, September Springer-Verlag. 4. N. H. Frijda. The Emotions. Cambridge: Cambridge University Press, Michael Köhler, Daniel Moldt, and Heiko Rölke. Modelling mobility and mobile agents using nets within nets. In Wil van der Aalst and Eike Best, editors, Proceedings of the 24th International Conference on Application and Theory of Petri Nets 2003 (ICATPN 2003), volume 2679 of Lecture Notes in Computer Science, pages Springer-Verlag, Michael Köhler and Heiko Rölke. Towards a unified approach for modeling and verification of multi agent systems. In Daniel Moldt, editor, Proceedings of the Workshop on Modelling of Objects, Components, and Agents (MOCA 01), pages University of Aarhus, Department of Computer Science, August Published as DAIMI PB: Workshop Proceedings Modelling of Objects, Components, and Agents; Aarhus, Denmark, August 27-28, number R.S. Lazarus. Emotion and adaptation. Oxford University Press, New York, J.E. LeDoux. Emotion circuits in the brain. Annual Review of Neuroscience, 23: , A. Ortony, G. L. Clore, and A. Collins. The Cognitive Structure of Emotions. Cambridge University Press, Cambridge, Heiko Rölke. Modellierung von Agenten und Multiagentensystemen Grundlagen und Anwendungen, volume 2 of Agent Technology Theory and Applications. Logos Verlag, Berlin, K. R. Scherer. Appraisal theory. Handbook of Cognition and Emotion. Wiley, Chichester, R. Trappl, P. Petta, and S. Payr. Emotions in Humans and Artifacts. MIT Press, Cambridge/Massachusetts,

18 Modellierung verschränkter Zustände zur Indikation unvollständiger Planbarkeit von Auktionsverhandlungen Christian Flender Abteilung Telematik Institut für Informatik und Gesellschaft Albert-Ludwigs-Universität Freiburg Abstract. Die Planung von Geschäftsprozessen als gedankliche oder modellierte Vorwegnahme zukünftiger Entscheidungen und Handlungen ist oft mit Unsicherheit behaftet. So stellt sich beispielsweise der tatsächliche Ausgang eines Auktionsprozesses oder die Anzahl der Gebote innerhalb einer Auktionsverhandlung erst zum Zeitpunkt der Durchführung heraus. Petrinetze eignen sich aufgrund ihrer intuitiven Notation und formalen Präzison zur Veranschaulichung und gedanklichen Vorwegnahme der Koordination von Auktionstransaktionen wie Gebot abgeben oder Zuschlag erteilen. Hinsichtlich der Planung von Eigenschaftsausprägungen wie Höhe und Anzahl von Geboten fehlt es zur Entwurfszeit allerdings an Information. Folglich gibt es Zustände in Geschäftsprozessen, die aufgrund einer zeitlichen Überlapppung von Planung und Durchführung - dem Ausführungskontext - nur unvollständig planbar oder modellierbar sind. Trotz Mangel an gedanklicher Vorwegnahme lässt sich formal auf Zustände, die mit ihrem Ausführungskontext verschränkt sind, hinweisen und somit das Ungewisse greifen. Am Beispiel des Petrinetzes einer englischen Auktion wird gezeigt, wie Kontrollfluss als Ausführungskontext eines State-Context-Property (SCoP) Systems interpretiert werden kann und somit verschränkte Zustände zur Entwurfszeit im Auktionsmodell Eingang finden. Keywords: Petrinetze, Auktionen, State-Context-Property Systeme 1 Einführung In einer utopischen Welt frei von unvorhersagbaren Ereignissen wie der Verschuldung ganzer Staaten, der Umwerfung autoritärer Systeme oder dem Einbruch des globalen Finanzmarktes, können Geschäfts- und Geschäftsprozessmodelle vollständig antizipiert werden. Sie sind somit sicher. Sind Umweltbedingungen dagegen ungewiss, wie es viele Meldungen dieser Tage belegen, treten Zustandsänderungen ein, die nicht oder nur unvollständig geplant werden konnten. Entsprechend halten viele Einflussfaktoren zu Entwurfszeit keinen Einzug in Geschäfts- und Geschäftsprozessmodelle, d.h. in die gedankliche Vorwegnahme 15

19 oder den modellhaften Entwurf von zukünftigen Ereignissen, Entscheidungen und Handlungen der betrieblichen Praxis. Dies gilt auch für Geschäftsmodelle der digitalen Wirtschaft wie der Zusammenbruch der New Economy oder der immense Erfolg diverser Internetunternehmen verdeutlicht. Auktionen sind eine Unternehmensstrategie der digitalen Wirtschaft [1]. Mittels Preisindividualisierung zielen Auktionen darauf ab, die Zahlungsbereitschaft von Kunden oder Bietern auszureizen. Petrinetze eignen sich zur Modellierung von Auktionsverhandlungen und somit zur Antizipierung von Effekten der Preisindividualisierung. Auktionen folgen einem Verhandlungsprotokoll, welches die Verhandlungsbeziehungen bzw. die logische Abfolge von Transaktionen wie Gebot abgeben oder Zuschlag erteilen, regelt. Folglich sind Verhandlungsprotokolle die gedankliche Vorwegnahme oder der modellhafte Entwurf vom zukünftigen Verhalten der Auktionsteilnehmer. Hinsichtlich der Planung dieses Verhaltens und davon abhängiger Ausprägungen wie Höhe und Anzahl von Geboten fehlt es zur Entwurfszeit allerdings an Information. Folglich gibt es Zustände in Auktionsverhandlungen, die aufgrund einer zeitlichen Überlapppung von Planung und Durchführung - dem Ausführungskontext - nur unvollständig planbar oder modellierbar sind. Wirklichkeitsgetreue Modelle können somit nicht vollständig antizipieren, wie sich Bieter und Auktionator letztendlich verhalten werden, z.b. bietet überhaupt jemand, wird die Auktion abgebrochen, oder ist der Auktionserlös überproportional hoch? Trotz Mangel an gedanklicher Vorwegnahme lässt sich formal auf Zustände, die mit ihrem Ausführungskontext verschränkt sind, hinweisen und somit das Ungewisse greifen bzw. darstellen. Im Folgenden soll dies am Beispiel des Petrinetzes einer englischen Auktion verdeutlicht und mittels State-Context-Property (SCoP) Systemen formalisiert werden. 2 Unvollständige Planbarkeit am Beispiel einer englischen Auktion Im Rahmen einer englischen Auktion werden ausgehend von einem Mindestgebot des Auktionators iterativ Gebote von Bietern abgegeben. Der Höchstbietende erhält den Zuschlag vom Auktionator. Zeitliche Planung und Durchführung der Verhandlung überlappen, d.h. Eigenschaften wie Höhe und Anzahl der Gebote werden abhängig vom Ausführungskontext instanziert und liegen somit nicht schon zur Entwurfszeit vor. Die Eigenschaften Anzahl und Höhe des Konzeptes Gebot sind somit kontextabhängig. Die möglichen Transaktionspfade - also die sequentielle Folge geschalteter Übergänge im Petrinetz - konstituieren diesen Kontext. Abbildung 1 zeigt das vereinfachte Verhandlungsprotokoll einer englischen Auktion in Petrinetz-Notation. Zu Anfang wird die Höhe des Mindestgebotes vom Auktionator festgelegt. Daraufhin darf ein Bieter sein erstes Gebot abgeben. Im Kontext der Transaktion Mindestgebot abgeben wird somit das Konzept Gebot instanziert und auf einen Initialwert gesetzt. Zum ersten Gebot - der ersten Aktivierung der Transaktion Akzeptanz bekunden - wird die Eigenschaft Anzahl inkremen- 16

20 tiert. Folglich ändert sich die Bedeutung des Konzeptes Gebot kontextabhängig mit jeder weiteren Transaktion, die auf seine Eigenschaften einwirkt. Entscheidend ist an dieser Stelle nun die Betrachtung von Punkten im Kontrollfluss (XOR-Verknüpfungen), die im Gegensatz zu festverdrahteten, sequentiellen Transaktionen wie Mindestgebot abgeben einer nichtvertauschbaren Entscheidung bedürfen. Nichtvertauschbare (oder nichtkommutative) Entscheidungen und Handlungen finden sich sowohl im Alltag als auch in der Quantenphysik [2] und sind dadurch gekennzeichnet, dass Zustände vor der Entscheidung oder Handlung im allgemeinen nicht identisch sind mit Zuständen nach der Entscheidung oder Handlung. Bezogen auf Abbildung 1 befindet sich die Auktionsverhandlung nach einer Transaktion Akzeptanz bekunden nicht entweder in einem Zustand, der zur Transaktion Gebotserhöung abgeben oder zur Transaktion Zuschlag erteilen führt, sondern in einem potentiellen Zustand (in der Quantenphysik Superposition genannt), in dem sowohl der eine als auch der andere Folgezustand möglich ist. Entsprechend sind alternative Transaktionspfade, die vor der Entscheidung t 3 oder t 4 stehen, nicht alternativ sondern komplementär zu betrachten. Fig. 1. Petrinetz einer englischen Auktion. Ausgehend von einem Mindestgebot werden iterativ Gebote abgegeben. Der Höchstbietende erhält den Zuschlag. Zeitliche Planung und Durchführung der Verhandlung überlappen, d.h. Anzahl und Höhe der Gebote sowie Ausgang der Auktion sind zur Entwurfszeit ungewiss. Abhängig vom Ausführungskontext - der sequentiellen Folge geschalteter Übergänge im Petrinetz - ändert sich die Bedeutung des Konzeptes Gebot. Verschränkte Zustände sind nun eng verknüpft mit der Komplementarität von Transaktionspfaden. Während Komplementarität alternative Transaktionspfade gleichberechtigt nebeneinander stellt, kennzeichnet Verschränkung einen ganzheitlichen, nichtseparierbaren Zustand der Auktionsverhandlung und indiziert somit die unvollständige Planbarkeit der Auktion. Ist ein Zustand im 17

21 Kontext komplementärer Transaktionspfade situiert, lässt sich dieser nicht auf Zustände im Kontext der alternativen Transaktionspfade reduzieren und somit auch nicht exklusiv Akteuren zuordnen, von denen Transaktionen ausgehen. Da der Zustand der Auktion vor Entscheidung (Handlung) nicht dem Zustand nach Entscheidung (Handlung) gleicht, überlappen Planung und Durchführung zeitlich, so dass erst zum Zeitpunkt der Ausführung ein konkreter Pfad vorgefunden und somit die Ganzheit - oder Nichtseparierbarkeit - des verschränkten Zustandes aufgelöst wird. Entscheidend ist, dass verschränkte Zustände im Kontext komplementärer Transaktionspfade stehen und somit nicht identisch mit der Vereinigung der einzelnen Zustände sind, die sich im Kontext der alternativen Transaktionspfade nach Entscheidung (Handlung) vorfinden könnten. Um nun verschränkte Zustände im Auktionsprotokoll so päzise wie möglich zu veranschaulichen, werden im nächsten Abschnitt Transaktionspfade im Petrinetz als Ausführungskontexte in einem State-Context-Property (SCoP) System ausgelegt. Vorbereitend darauf listet Tabelle 1 die Ausführungskontexte der englischen Auktion in Abbildung 1. Die möglichen Transaktionspfade t 1,...,t n - also die sequentielle Folge geschalteter Übergänge im Petrinetz - konstituieren den Ausführungskontext e. Ausführungskontext e Transaktionspfad t 1,...,t n e 1 t 1 e 2 t 1,t 2 e 3 t 1,t 2,t 3 e 4 t 1,t 2,t 4 e 5 t 1,t 2,t 3,t 2 e 6 t 1,t 2,t 3,t 2,t 3 e 7 t 1,t 2,t 3,t 2,t 4 e n t 1,t 2,t 3,t 2,t 3,t 2,...,t n Table 1. Ausführungskontext der englischen Auktion in Abbildung 1. Die möglichen Transaktionspfade t 1,...,t n - also die sequentielle Folge geschalteter Übergänge im Petrinetz - konstituieren den Ausführungskontext e. Alternative Transaktionspfade wie e 3 oder e 4 sind dabei als komplementär zu betrachten. Der Zustand eines Gebotes vor der Entscheidung für e 3 oder e 4 ist nicht identisch mit dem Zustand nach der Entscheidung. Somit lässt sich ein Gebot im Kontext e 3 oder e 4 nicht reduzieren auf einen Gebotszustand in e 3 oder einen Gebotszustand in e 4. 3 Verschränktheit als Indikator unvollständiger Planbarkeit State-Context-Property (SCoP) Systeme ermöglichen die Modellierung kontextsensitiver, komplementärer und verschränkter Phänomene [3][4]. Im Zentrum dieser 18

22 Systeme stehen Konzepte im Sinne sprachlicher Bedeutungszusammenhänge (z.b. Gebot, Auftrag, Zuschlag, Kunde, Rechnung, etc.), wie sie auch in der Datenmodellierung wirtschaftsinformatischer Systeme von elementarer Bedeutung sind (siehe z.b. [5]). Ein Konzept ist definiert als ein 5-Tuple S = (Σ, M, L, ν, µ). Σ ist eine Menge an Zuständen eines Konzeptes, M ist die algebraische Struktur eines Verbandes bzw. die halbgeordnete Menge an Kontextelementen bzw. Transaktionspfaden. Der Verband L ist eine halbgeordnete Menge an Eigenschaften wie Höhe oder Anzahl des Konzeptes Gebot. Die Funktion ν liefert einen Wahrscheinlickeitswert, der besagt wie typisch eine Eigenschaft für ein Konzept in einem Kontext e ist. Die Wahrscheinlichkeit, dass ein Zustand in einem Kontext in einen Folgezustand eines anderen Kontext wechselt, beschreibt die Funktion µ. Zur Veranschaulichung verschränkter Zustände als Indikator für unvollständige Planbarkeit von Auktionsverhandlungen wird im Folgenden näher auf die Struktur der Kontextmenge M eingegangen 1. Für alle Transaktionspfade {e i } i I, e i M existiert ein Infimum (grösste untere Schranke) und ein Supremum (kleinste obere Schranke). Infima sind logische UND-Verknüpfungen von Ausführungskontexten e i M. i I : i I e i M (1) Für ein Infimum gilt: Es gibt einen Ausführungskontext f M : f e j, so dass j I f i I e i. Infima stehen für Ausführungskontexte, die sequentiell oder parallel Einfluss auf Zustände und Eigenschaften von Konzepten ausüben. Dagegen sind Suprema logische ODER-Verknüpfungen von Ausführungskontexten e i M. i I : i I e i M (2) Für ein Supremum gilt: Es gibt einen Ausführungskontext f M : f e j, so dass j I f i I e i. Suprema stehen für Ausführungskontexte, die komplementär nebeneinander stehen. Bezogen auf Abbildung 1 befindet sich die Auktionsverhandlung nach einer Transaktion Akzeptanz bekunden nicht entweder in einem Zustand, der zur Transaktion Gebotserhöung abgeben oder zur Transaktion Zuschlag erteilen führt, sondern in einem Supremum Kontext, in dem sowohl der eine als auch der andere Folgezustand möglich ist. Die nichtkommutative Operation λ repräsentiert nun eine Entscheidung oder Handlung, indem sie einen Ausführungskontext e auf eine Untermenge der Potenzmenge von Σ abbildet und somit eine Menge aktualisierter Zustände zurückliefert. Aktualisiert ist hier als Gegensatz zu möglich oder potenziell zu verstehen. Folglich liefert λ nie einen Zustand im Supremum, da dieser ja die möglichen Ausführungskontexte repräsentiert unter denen sich z.b. ein Gebot potenziell ändern kann. Sehr wohl aber reduziert oder aktualisiert λ einen Zustand im Supremum zu einem Zustand im Kontext seiner möglichen Ausführungen. Da dieser Vorgang nichtkommutativ, der gelieferte Zustand also nicht identisch mit 1 Für eine ausführlichere Einführung in SCoP sei auf [3][4][5] verwiesen. 19

23 dem Zustand vor der Operation ist, überlappen sich Planung und Durchführung an diesem Punkt zeitlich. λ : M P (Σ) (3) Suprema und Infima Ausführungskontexte unterscheiden sich formal in der Ordnung, die zwischen Transaktionspfaden existiert. Für zwei Transaktionspfade e und f gilt, dass wenn e stärker oder gleich f ist, dann sind aktualisierte Zustände unter e eine Teilmenge der Zustände unter f. Formal gilt, dass e f λ(e) λ(f). Zum Beispiel ist nach Abbildung 1 e 1 e 2 λ(e 1 ) λ(e 2 ). Die Eigenschaft Höhe des Konzeptes Gebot im Kontext e 2 - der Wert des ersten Gebotes - setzt voraus, dass ein Mindestgebot im Kontext e 1 - der Wert des Mindestgebotes - gesetzt wurde. i I λ(e i ) = λ( i I e i ) (4) Die Schnittmenge der aktualisierten Zustände in den Ausführungskontexten e i ist somit identisch mit der Aktualisierung des Zustandes im Ausführungskontext der UND-verknüpften Transaktionspfade e i. Diese Ordnung gilt allerdings nicht für Suprema Ausführungskontexte, da Zustände hier gleichberechtigt nebeneinander - also komplementär zueinander - stehen. Deshalb ist die Vereinigung der aktualisierten Zustände in den Ausführungskontexten e i nur eine Teilmenge der Aktualisierung des Zustandes im Ausführungskontext der ODER-verknüpften Transaktionspfade e i. i I λ(e i ) λ( i I e i ) (5) Bezogen auf Abbildung 1 befindet sich die Auktionsverhandlung nach einer Transaktion Akzeptanz bekunden nicht entweder in einem Zustand z, der zur Transaktion Gebotserhöung abgeben oder zur Transaktion Zuschlag erteilen führt - z / λ(e 3 ) λ(e 4 ) -, sondern im verschränkten Zustand z λ(e 3 e 4 ), welcher somit nicht reduzierbar auf die einzelnen Akteure und die von ihnen ausgehenden Transaktionen ist. Somit findet unvollständige Planbarkeit formal Eingang im Auktionsmodell und erhöht die Wirklichkeitstreue des Petrinetzes. References 1. Müller, G., Eymann, T., Kreutzer, M.: Telematik-und Kommunikationssysteme in der vernetzten Wirtschaft. Oldenbourg Wissenschaftsverlag (2002) 2. Atmanspacher, H.: Quantenphysik und Quantenalltag. In: Die Welt im Bild: Weltentwürfe in Kunst, Literatur und Wissenschaft seit der Frühen Neuzeit. Fink, Paderborn (2010) Aerts, D., Gabora, L.: A State-Context-Property model of concepts and their combinations I: The structure of the sets of contexts and properties. Kybernetes 34(1&2) (2005) Aerts, D., Gabora, L.: A State-Context-Property model of concepts and their combinations II: A Hilbert space representation. Kybernetes 34(1&2) (2005) Flender, C., Kitto, K., Bruza, P.: Beyond Ontology in Information Systems. In Bruza, P., ed.: Proceedings of QI 2009, Saarbrücken, Germany, March 25-27, Volume 5494 of LNAI., Springer (2009)

24 Atomic Fragments of Petri Nets Extended Abstract Monika Heiner 1, Harro Wimmel 2, and Karsten Wolf 2 1 Brunel University Uxbridge/London, on sabbatical leave from Brandenburgische Technische Universität Cottbus Institut für Informatik 2 Universität Rostock Institut für Informatik Abstract. An atomic fragment of a Petri net is a maximal set of places or a maximal set of transitions such that the nodes in the set cannot be distinguished by any invariant and they induce a connected subnet. Atomic fragments are quite useful in understanding models, e.g. in biochemical reaction networks. We introduce a technique based on linear programming that efficiently finds the atomic fragments. 1 Introduction Consider a place/transition net N with is incidence matrix C. Let a place invariant i be an (integer) solution of the system ic = 0 and a transition invariant an (integer) solution j of Cj = 0. Let an invariant be semipositive iff all its entries are greater or equal to 0. In this paper, we consider a relation between nodes of the net that is induced by its invariants. For two places (or two transitions) x and y, let x y iff, for all semipositive place (transition, resp.) invariants i, i(x) = 0 if and only if i(y) = 0. This relation is obviously an equivalence. It is moreover evident that equivalent nodes must have a close functional connection. This is even more true if equivalent nodes are close to each other in the net topology. So let an atomic fragment of the net be a maximal set A of nodes of the same type such all nodes in A are pairwise equivalent (in the aforementioned sense) and connected (i.e. there is an undirected path between each pair of nodes in A that only passes nodes in A and nodes of the opposite type). Indeed, atomic fragments can be a useful tool for understanding models. This extended abstract is organised as follows. In Sect. 2, we briefly discuss the use of atomic fragments in a biochemical setting. Then, in Sect 3, we present our approach for computing atomic fragments. Finally, we report on an implementation and initial experiments in Sect Background Petri nets represent a natural choice for modeling and analyzing biochemical networks as both share the bipartite and concurrent paradigm. Places usually 21

25 model species, or any kind of chemical compounds, e.g. proteins or proteins complexes, playing the role of precursors, products, or enzymes of chemical reactions. Complementary, transitions may stand for any kind of chemical reactions, e.g. association, dissociation, phosphorylation, or dephosphorylation, transforming precursors into products, possibly controlled by enzymes. The arcs go from precursors to reactions (ingoing arcs), and from reactions to products (outgoing arcs), while arc weights reflect known stoichiometry. Opposite to technical networks, biochemical networks tend to be very dense and apparently unstructured making the understanding of the full network of interactions difficult and, therefore, error-prone. Getting a survey on the current state of knowledge about a particular pathway requires a lot of reading and search through data bases, including the creative interpretation of various graphical representations. These pieces of separate understanding are then assembled to get a comprehensive as well as consistent knowledge representation. The transformation from an informal to a formal model involves the resolution of any ambiguities, which must not necessarily happen in the right way. Therefore, the next step in a sound model-based technology should be devoted to model validation. Place and transition invariants are a popular validation technique for technical as well as biochemical networks. One approach of acquiring a deeper understanding of the network behavior consists in understanding all its basic executions, which correspond to the minimal transition invariants. Another approach which has been proposed in [Hei09] goes one step further by looking for invariants-induced connected subnetwork defining a partition the atomic fragments 3. Atomic fragments permit a structured representation of invariants by network coarsening, and the automatically derived hierarchical representation of a given network supports its comprehension. Most remarkably, the approach requires static analysis only. Consequently, it can also be applied to unbounded systems. In this paper we discuss the efficient computation of atomic fragments. For more details and examples demonstrating the hierarchical structuring principle see [Hei09]. 3 Computation Consider first the implementation of the equivalence with respect to the invariants. Staying close to the definition, we can check the equivalence of x and y by considering two linear programming (LP) problems: Ci = 0, i 0, 0, i(x) > 0, i(y) = 0 and Ci = 0, i 0, i(x) = 0, i(y) > 0. Feasibility of either of the two systems means that x and y are not equivalent while nonfeasibility of both systems proves x and y to be equivalent. Being based on an equivalence, atomic fragments partition the set of all nodes of the net. Consequently, we can use Tarjan s Union/Find data structure 3 called abstract dependent transition sets in [Hei09] 22

26 [Tar75] for managing the fragments. This means that the test for equivalence needs only be performed for pairs of nodes in different fragments. If the test reveals equivalence, the two fragments can be unified. The adjacency criterion can be implemented by checking only for equivalence of two nodes x and y that are in different fragments and are adjacent (i.e. there is a node z such that {x, y} z z. For increasing efficiency, we also use a dual partition of the nodes that is initially set to a singleton set consisting of all nodes. Whenever one of the considered LP problems returns with a solution i, we split every set in this partition into those nodes x where i(x) > 0 and those where i(x) = 0. This way, we converge to our final solution both bottom-up and top-down. Additionally, we tried to reduce that number of calls to an LP solver by considering the net topology. If there is a z such that z = {x} and z = {y} then x and y must be equivalent. Generalizing this pattern, x and y are also equivalent if there is a z such that z = {x}, y z, and all nodes in z are equivalent. Dually, x and y are equivalent if there is a z such that z = {x}, y z, and all nodes in z are equivalent. Furthermore it is clear that nodes adjacent to nodes with empty preset or empty postset are not covered by any invariant. The complexity of our implementation is best assessed in terms of the number of calls to an LP solver as all other efforts are negligible. We distinguish between successful calls (i.e. calls yielding equivalence) and unsuccessful calls (i.. calls yielding non-equivalence). Let n be the number of nodes of the considered type and f be the number of resulting fragments. Each successful call is actually the result of two calls to an LP solver. Upon each such call, two fragments are unified. Initially, we have n singleton fragments. That is, the number of successful calls to an LP solver is 2(n f) which is linear in n in worst case. Unsuccessful calls need to be considered for each pair of resulting fragments. Observe that unsuccessful calls remain valid even if the compared fragments change: Let x F 1, y F 2 and x y. If F 1 is later on unified with F 3 and F 2 with F 4, we know without an additional test that F 1 F 3 cannot be unified with F 2 F 4. Thus, we have f(f 1) 2 unsuccessful instances requiring up to f(f 1) calls to an LP solver. IN consequence, depending on the ration between the number of nodes and the number of resulting fragments, the number of calls to an LP solver is between linear and quadratic in the number of nodes of the net. In face of the well-known fact that integer LP solving is NP-complete, we have proposed a solution that can be executed in polynomial space. This is a clear advantage compared to the naive solution of the problem which consists of enumerating the (up to exponentially many) minimal semipositive invariants and to subsequently partition the set of nodes. Furthermore, our solution has an excellent potential for multicore or distributed implementation since the various LP problems can be solved independently. Last but not least, the present day technology for LP solving is quite advanced and not necessarily a blocker for practically relevant problem instances. 23

27 4 Tool and Experiments Our approach is implemented in the tool Petia freely available at the web page The tool is open source and available under an AGPL license. The tool reads a net, generates the various LP problems and ships them to the publicly available lp solver lp-solve [BEN]. Then it records the results in the two mentioned partitions and finally outputs the final partition. Some initial experiments have been conducted on a Macbook Pro with 2.2 GHz. For the n dining philosophers in the standard scenario (P Hn), nets have 5n places and 4n transitions. Atomic fragments are all singletons, so a quadratic number of LP problems needs to be solved. Petia runs 2 seconds for P H100, 200 seconds for P H500, and almost 30 minutes for P H1000. For a data access protocol where processes can concurrently read and exclusively write to a data item (DATA n for n processes), atomic fragments are again all singletons. Petia solves the partition in 9 seconds for 100 processes and almost 2 minutes for 200 processes. Additionally, we checked 1386 business process models with up to some 200 places and transitions (refer to [FFK + 11] for more information on the models. These models have only few nontrivial classes, several models (typically acyclic ones) end up with a single class consisting of all nodes. Run time for a single model is not measurable Processing of the whole model library takes less than 10 seconds. Currently we are in the process in applying Petia to our benchmark collection of biochemical networks. 5 Conclusion We presented a method for determining the atomic fragments of a Petri net which can be used as a tool for better understanding a model and gaining new insights by hierarchical structuring. This structuring technique is especially helpful for analyzing biochemically interpreted Petri nets, where it supports model validation of biochemical reaction systems reflecting current comprehension and assumptions of what has been designed by natural evolution. The proposed method requires only polynomial space, compared to an exponential naive solution. The prototype is efficient enough to solve academic problems beyond 1000 nodes and real-life problems. The method has an excellent potential for speed-up through parallel computing. The various LP problems can be solved independently, and almost no substantial data traffic is required between the processes. Thus, we conclude that the method is applicable for routine use. References [BEN] M. Berkelaar, K. Eikland, and P. Notebaert. lpsolve: Open source (mixed integer) linear programming system. Technical report, Eindhoven University of Technology. 24

28 [FFK + 11] Dirk Fahland, Cédric Favre, Jana Koehler, Niels Lohmann, Hagen Völzer, and Karsten Wolf. Analysis on demand: Instantaneous soundness checking of industrial business process models. Data Knowl. Eng., 70(5): , [Hei09] M Heiner. Understanding Network Behaviour by Structured Representations of Transition Invariants A Petri Net Perspective on Systems and Synthetic Biology, pages Natural Computing Series. Springer, [Tar75] R.E. Tarjam. Efficiency of a good but not linear set union algorithm. Journal of the ACM, 22(2): ,

29 MuPSi - interaktive Erstellung und Simulation von Transitionsschritten in Petrinetzen Thomas Irgang 1, Andreas Harrer 1, Robin Bergenthum 2 1 Lehrstuhl für Angewandte Informatik, Kath. Universität Eichstätt {thomas.irgang,andreas.harrer}@ku-eichstaett.de 2 Lehrgebiet Softwaretechnik und Theorie der Programmierung, FernUni Hagen robin.bergenthum@fernuni-hagen.de Zusammenfassung Petrinetze eignen sich besonders zur Modellierung von Systemen die nebenläufiges Verhalten aufweisen. Um die Erstellung von Petrinetzen zu unterstützen existieren zahlreiche Editoren. Fast alle Editoren bieten die Möglichkeit erstellte Netze durchzuspielen d.h. zu simulieren. Dazu können im Petrinetz einzelne aktivierte Transitionen von Benutzer ausgewählt und geschaltet werden, jedoch wird das potentielle gleichzeitige Schalten mehrerer Transitionen aufgrund der limitierten Nutzerinteraktion konventioneller Benutzeroberflächen mit einem Fokus nicht unterstützt. In dieser Arbeit wird ein Petrinetz-Simulator vorgestellt, welcher sich neben dieser üblichen sequentiellen Ausführung von Transitionen auf die Ausführung von Transitionsschritten, d.h. Multimengen von Transitionen, spezialisiert. Erst durch Simulation von Transitionsschritten lässt sich das wahre Verhalten eines nebenläufigen Systems testen und begreifen. 1 Einleitung Petrinetze besitzen eine eindeutige formale Semantik und eine einfache grafische Darstellung. Damit sind sie in vielen Anwendungsbereichen z.b. im Softwareengineering, in der Geschäftsprozessmodellierung, im Hardwaredesign oder in der Kontrollersynthese eine beliebte Wahl zur integrierten Modellierung von Systemen. Dies gilt umso mehr, wenn Nebenläufigkeit in den zu modellierenden Systemen eine Rolle spielt. Um das Erstellen von Petrinetzen zu unterstützen, existieren zahlreiche Petrinetz- Editoren welche sich je nach Anwendungsgebiet unterscheiden. VipTool [3,1] spezialisiert sich auf die Halbordnungssemantik von Petrinetzen. CPN Tools [5] betrachtet eine Erweiterung von Petrinetzen, die sogenannten gefärbten Petrinetze. WoPeD [4] wurde speziell für die Lehre entwickelt. Jeder dieser Editoren bietet dabei die Möglichkeit Petrinetze sequentiell zu simulieren, d.h. jeweils genau eine aktivierte Transition zu schalten. Für ein Petrinetz berechnet ein Editor zunächst die Menge aller aktivierten Transitionen und hebt diese für Benutzer hervor. Nun kann der Benutzer eine dieser Transitionen auswählen und schalten. Damit ändert sich der Zustand des Netzes und die Menge aller aktivierten Transitionen wird neu berechnet. Dieses sogenannte Markenspiel ist eine sehr einfache aber sehr intuitive Art ein erstelltes Petrinetz zu testen und zu begreifen. 26

30 Diese Durchspielen von Petrinetzen beschränkt sich dabei aber ausschließlich auf das sequenzielle Verhalten eines Petrinetzes. Dies stellt eine starke Einschränkung dar, wenn man das nebenläufige Verhalten eines Systems modellieren und dann simulieren will. Der in diesem Papier vorgestellte Simulator MuPSi (Multitouch PetrinetzSimulator) hebt diese Einschränkung auf, indem er das Schalten von Transitionsschritten, Multimengen von Transitionen, für die Simulation erlaubt. Ein Transitionsschritt kann schalten, wenn alle Transitionen des Schrittes gleichzeitig ausgeführt werden können. Dabei werden für die Eingabe von Transitionsschritten verschiedene Interaktionsmöglichkeiten unterstützt, so dass sich das Tool sowohl für den Einsatz an einem Desktop-Rechner als auch in einer Multitouch-Umgebung eignet. Multitouch-Umgebungen werden durch die Entwicklung und zunehmende Verbreitung von Smartphones und Tablet Computern immer populärer. Die Möglichkeit mehrere Pointer in einem Programm zu steuern erlaubt es mehrere Transitionen in einem Netz gleichzeitig auszuwählen und dann gleichzeitig zueinander zu schalten. Zu diesem Zweck haben wir, wie in 5 skizziert, einen Multitouch-Tisch konstruiert auf dem mit Hilfe von MuPSi im Mehrbenutzer-Betrieb ein geladenes Netz verteilt durchgespielt werden kann. Wird eine Menge von Transitionen gleichzeitig geschaltet und ist ein nebenläufiges Schalten dieser Menge nicht möglich, so unterstützt MuPSi das Erkennen und Auflösen dieses Konfliktes. Abbildung 1. MuPSi auf einem Multitouch-Tisch Das nächste Kapitel befasst sich mit der Darstellung aktivierter Transitionsschritte in Petrinetzen. Dazu werden verschiedene Möglichkeiten die in einem Petrinetz aktivierte Transitionsschritte anzuzeigen diskutiert. Dabei ist es besonders wichtig die Benutzer auf mögliche Konflikte im Petrinetz aufmerksam zu machen. Danach werden kurz die - in MuPSi implementierten - verschiedenen Möglichkeiten Transitionsschritte 27

31 einzugeben vorgestellt. In Kapitel 3 wird die Implementierung von MuPSi beschrieben bevor in Kapitel 4 ein kurzer Ausblick gegeben wird. 2 Darstellung aktivierter Transitionsschritte in Petrinetzen Petrinetze besitzen zwei verschiedene Arten von Knoten: Transitionen und Stellen. Stellen können durch Marken markiert sein und die Verteilung von Marken über alle Stellen des Netzes ergibt den Zustand des Petrinetzes. Transitionen sind über gerichtete Kanten, welche gewichtet sein können, mit den Stellen verbunden. Damit eine Transition in einem Petrinetz schalten kann muss jede Stelle von der eine Kante zu dieser Transition führt mindestens so viele Marken besitzen wie das Gewicht der jeweiligen Kante beträgt. Bei Schalten einer Transition wird genau diese Anzahl an Marken aus jeder Stelle im Vorbereich der Transition konsumiert und die Transition erzeugt Marken in den Stellen zu denen Kanten von der Transition aus hinführen. Wieder gibt das Gewicht der Kante an wie viele Marken jeweils produziert werden. Jede Transition, bei der die Stellen vor ihr genügend Marken besitzen, ist aktiviert. Petrinetz-Simulatoren unterstützen den Benutzer beim Simulieren von Petrinetzen indem sie aktivierte Transitionen meist grün und nicht aktivierte Transitionen rot oder gar nicht einfärben. Erlaubt man das Schalten von Transitionsschritten d.h. einer Multimenge von Transitionen, muss die Markenanzahl auf den Stellen vor den Transitionen für das Schalten aller Transitionen gleichzeitig reichen. So kommt es, dass Transitionen in einem Schritt schalten und in einem anderen Schritt, in einer anderen Multimenge von Transitionen, nicht schalten können. Die strikte Einteilung in aktivierte und nicht aktivierte Transitionen ist bei dieser Schrittsemantik nicht mehr möglich. Werden sonst in Editoren aktivierte Transitionen grün und nicht aktivierte Transitionen rot gefärbt, so erweitern wir im MuPSi das Farbschema um die Farbe gelb. Rot sind im MuPSi hierbei wieder Transitionen die nicht aktiviert sind d.h.die Markierung des Petrinetzes reicht nicht aus, auch wenn diese Transition im nächsten Transitionsschritt alleine schalten würde. Alle anderen Transitionen werden gelb oder grün gefärbt. Gelbe Transitionen weisen darauf hin, dass Ihr Schalten durch das gleichzeitige Schalten anderer Transitionen gefährdet ist. Das Ziel ist es, dass grün eingefärbte Transitionen geringere Konfliktwahrscheinlichkeit symbolisieren und damit im Petrinetz schalten können auch wenn sie mit anderen Transitionen im gleichen Schritt ausgewählt werden. Im Folgenden werden die verschiedenen in MuPSi implementierten Möglichkeiten Transitionsschritte mit und ohne Konfliktpotential hervorzuheben beschrieben. Strukturelle Konflikte zwischen Transitionen. Die wohl einfachsten zwei Ansätze die Menge aller in einem Netz aktivierten Transitionen aufzuteilen so dass grün gefärbte Transitionen wenig und gelb gefärbte Transitionen viel Konfliktpotential anzeigen, ist eine einfache strukturelle Analyse des Petrinetzes. Der erste Ansatz ist unabhängig von der aktuellen Markierung und die Idee ist es, dass eine aktivierte Transition im nächsten Schritt mindestens einmal schalten kann, wenn vor ihr keine Stelle existiert, die sie sich mit einer anderen Transition teil. Falls so eine verzweigte Stelle existiert, kann das nebenläufige Ausführen von den Transitionen hinter dieser Stelle zu Konflikten führen, wenn die Markenzahl der Stelle nicht für das Schalten aller Transitionen reicht. 28

32 Dies ist ein recht einfaches Verfahren das aber den Vorteil hat, dass die Einteilung in gelbe und grüne Transitionen nur ein einziges mal berechnet werden muss. Zur Laufzeit der Simulation kommt diese Lösung ohne zusätzlichen Rechenaufwand aus, da jede Transition, wenn sie aktiviert ist, immer nur gelb oder grün markiert wird. Diese Einteilung lässt sich durch etwas mehr Rechenaufwand jedoch noch leicht verfeinern. Geht man davon aus, dass man nicht aktivierte Transitionen nicht für den nächsten Schritt auswählen kann, so können diese im nächsten Schritt auch nicht zu Konflikten führen. Eine Transition wird grün markiert, wenn sie aktiviert ist und sich vor ihr keine Stelle befindet die sie sich mit einer aktivierten Transition teilt. Abbildung 2. Strukturelle Konflikte zwischen aktivierten Transitionen. Die Färbung von drei Transitionen links nach dem ersten, rechts nach dem zweiten Ansatz. Die Menge der grün gefärbten Transitionen ist bei dem zweiten Ansatz größer oder gleich der Menge der grün gefärbten Transitionen aus dem ersten Ansatz, allerdings müssen nach jedem Schaltvorgang aktivierte Transitionen neu in gelbe und grüne unterteilt werden. Für beide Ansätze gilt, dass jede Menge grün gefärbter Transitionen und einer gelb gefärbten Transition immer schalten kann. Enthält eine Menge zwei oder mehr gelbe Transitionen kann es vorkommen, dass dieser Transitionsschritt nicht schalten kann, obwohl jede Transition für sich ausführbar wäre. Konflikte zwischen Transitionen. Um die Menge der grünen Transitionen noch zu vergrößern, können wir neben der rein strukturellen Betrachtung die aktuelle Markierung des Netzes stärker berücksichtigen. Die Idee ist es Transitionen grün einzufärben, wenn zwar ein struktureller Konflikt zwischen aktivierten Transitionen besteht, aber die Markierung vor diesen Transitionen für das nebenläufige Schalten aller dieser Transitionen reicht. Für diesen dritten Ansatz wird zuerst versucht die Menge aller aktivierten Transitionen einmal in einem Transitionsschritt zu schaltet. Existieren dabei Stellen in denen die Markenzahl dazu nicht reicht werden alle aktivierten Transitionen hinter dieser Stelle gelbe gefärbt. Die restlichen aktivierten Transitionen werden grün. Wieder gilt nun, dass jede Menge grün gefärbter Transitionen und einer zusätzlichen gelb gefärbten Transition immer schalten kann. Die Menge der grün gefärbten Transitionen ist weiter gewachsen, was gleichzeitig bedeutet, dass ein nebenläufiges Schalten mehr als einer gelben Transition mit gemeinsamen Stellen vor diesen Transi- 29

33 Abbildung 3. Konflikte zwischen aktivierten Transitionen. Die Färbung von zwei Transitionen links nach dem zweiten, rechts nach dem dritten Ansatz. tionen oft zu einem Konflikt führt. Allerdings muss noch etwas mehr Rechenaufwand betrieben werden, um nach jedem Schritt die Menge der grün gefärbten Transitionen neu zu berechnen. Konflikte zwischen Transitionen bei begrenzter Selbstnebenläufigkeit. Im vierten und fünften Ansatz wollen wir zusätzlich Selbstnebenläufigkeit von Transitionen betrachten. Bisher haben wir uns nur um Konflikte gekümmert die entstehen wenn man eine Menge von Transitionen schalten will. Im nächsten Schritt wollen wir auch das Schalten von Multimengen mit einbeziehen. Dieses kann man erreichen indem man sich eine Schranke für die Selbstnebenläufigkeit vorgibt. Sich solch eine Schranke vorzugeben ist sinnvoll, da beliebig oft nebenläufig zu sich selbst nur Transitionen schalten können die hinter gar keiner Stelle liegen. Im folgenden sei also n diese Schranke. Im vierten Ansatz testet man die Multimenge von Transitionen, die jede aktivierte Transition n mal enthält. Wie bei Ansatz Nummer drei werden Transitionen hinter Stellen die diesen Schritt nicht erlauben gelb gefärbt und alle anderen aktivierten Transitionen grün. Durch diesen Ansatz lässt sich sicherstellen, dass man eine Multimenge aus nur grünen Transitionen schalten kann, wenn jede Transition maximal n mal enthalten ist. Wählt man als obere Grenze n die Zahl 1 so ergibt sich genau der dritte Ansatz. Auch ist klar, dass die Anzahl von grünen Transitionen mit wachsenden n abnimmt. Der komplexeste und fünfte im MuPSi berücksichtigte Ansatz verwendet die Berechnung aller maximalen Schritte des Petrinetzes in einer Markierung. Erst berechnet man ausgehend von der aktuellen Markierung des Petrinetzes die Menge aller maximalen Schritte. Wenn eine Transition mindestens n mal in allen maximalen Schritten enthalten ist, so kann sie sicher n mal im nächsten Transitionsschritt schalten. Hier unterscheidet sich die Aussage doch erheblich zu den vorherigen Ansätzen. Erstens kann man wieder jede Multimenge grüner Transitionen schalten, falls jede maximal n mal enthalten ist, zweitens bekommen wir nun aber zusätzlich, dass man in jeder Multimenge (bestehend aus gelben und grünen Transitionen) welche schalten kann die Anzahl jeder grünen Transition auf n erhöhen kann, ohne das es dadurch zu einem Konflikt kommen kann - der entstehende Schritt bleibt schaltbar. 30

34 Abbildung 4. Konflikte zwischen Transitionen bei begrenzter Selbstnebenläufigkeit und in maximalen Schritten 3 Eingabe von Transitionsschritten Sind alle Transitionen im Petrinetz von MuPSi gefärbt, ist es an dem Benutzer die gewünschten Transitionen zu Schritten zusammenzufassen und zu schalten. Je nach Anwendungsszenario eignen sich verschiedene Eingabemethoden für die Eingabe von Transitionsschritten. Ein mögliches Szenario ist zum Beispiel der Betrieb auf einem normalen Desktop-Rechner, ein anderes wäre der Mehrbenutzerbetrieb auf einem Multitouch-Tisch. Im MuPSi Tool werden daher grundsätzlich verschiedene Eingabemethoden unterstützt. Manueller Takt: Die erste und einfachste Möglichkeit ist die Verwendung eines manuellen Takts. Dabei werden die Transitionen so lange durch Anklicken gesammelt bis explizit der Schaltvorgang ausgelöst wird. Ein Nachteil dieser Eingabemethode ist, dass sie sich eher für den Einzelnutzerbetrieb eignet, der große Vorteil ist jedoch, dass ohne Zeitdruck Transitionsschritte gebaut und dann geschalten werden können. Diese Methode eignet sich somit besonders gut, wenn ein Petrinetz gezielt am PC simuliert werden soll. Feste Zeitscheibe als Takt: Will man verhindern, dass ein Schalten einer Transition manuell ausgelöst werden muss, so verwendet MuPSi ein feste Zeitscheibe nach deren Ablauf alle in der Zeitscheibe ausgewählten Transitionen geschaltet werden, sofern dies möglich ist. Dies bedeutet, dass über ein bestimmtes Zeitintervall, zum Beispiel drei Sekunden, Transitionen gesammelt werden und diese am Ende der Zeitscheibe nebenläufig zueinander geschaltet werden, bevor die Sammlung von neuem beginnt. Diese Eingabemethode eignet sich sowohl für die Simulation durch einen Benutzer am PC als auch für die kollaborative Benutzung auf einem Multitouch-Tisch. Gleitender Takt: Eine etwas flexiblerer Ansatz als die Verwendung einer fester Zeitscheibe, die ohne einen manuellen Takt auskommt, ist der sogenannte gleitende Takt. Dabei wird beim Drücken einer Transition ein kurzer Countdown gestartet, z.b. zwei Sekunden, bei dem, falls in diesem Zeitraum eine weitere Transition gedrückt wird, diese dem Transitionsschritt hinzugefügt und der Countdown von Neuem gestartet wird. Dies geschieht solange bis der Countdown verstreicht, ohne dass eine neue Transition hinzugefügt wird. Dann werden alle so gesammelten Transitionen geschaltet. Diese 31

35 Eingabemethode eignet sich sowohl für den Multitouch-Tisch als auch für die Benutzung am PC. Üblicherweise wird das Zeitintervall für den Einzelbetrieb größer gewählt als im Mehrbenutzerbetrieb, da man berücksichtigen muss, dass der Zeitraum, in dem Transitionen gesammelt werden, bei mehreren aktiven Benutzern an einem Multitouch- Tisch durch fortwährenden Neustart des Countdowns sehr lange werden könnte. Takten durch Festhalten: Die letzte und wohl eleganteste Möglichkeit, Transitionsschritte einzugeben, benutzt das Festhalten eines Bedienelements, ähnlich wie die shift lock- oder Feststellen-Taste bei Computertastaturen. In MuPSi bedeutet das, dass zwischen dem Drücken und Loslassen einer Transition unterschieden wird. Solange eine Transition gedrückt ist, werden Transitionen der Multimenge hinzugefügt. Diese Eingabemethode eignet sich natürlich nur für die Benutzung an einem Multitouch-Gerät [2] und war der eigentliche Anstoß MuPSi zu entwickeln. Im Einbenutzer-Betrieb kann man z.b. eine Transition gedrückt halten und dann mit der zweiten Hand weitere Transitionen zum Schritt hinzufügen. Will man eine Transition selbstnebenläufig in einem Schritt schalten, hält man andere Transitionen gedrückt und tippt dann mehrfach in die Transition oder hält die Transition selber gedrückt und tippt mit einem zweiten Pointer zusätzlich an, bis man die gewünschte Anzahl erreicht hat. Im Mehrbenutzer-Betrieb werden Transitionen zu einem Schritt zusammengefasst, wenn sie gleichzeitig von Benutzern betätigt werden. Somit können Petrinetz verteilt simuliert werden, ohne dass das Schalten von Transitionen in eine Sequenz gebracht werden muss. Nebenläufiges Verhalten des Petrinetzes kann somit live getestet werden. 4 Implementierung MuPSi wird zur Zeit im Zuge einer Diplomarbeit des Erstautors an der KU Eichstätt implementiert. Es ist sowohl als Plug-In unter VipTool, als auch als Stand-alone- Version verwendbar. Optimiert ist es für die Benutzung auf einem Multitouch-Gerät. MuPSi wird in Java implementiert und wird bald als Download auf der VipTool-Seite ( ernuni hagen.de/sttp/f orschung/vip_tool.shtml) verfügbar sein. 5 Zusammenfassung und Ausblick In dieser Arbeit wurde das Tool MuPSi vorgestellt. Es ist ein für den Betrieb auf einem Multitouch-Gerät optimierter Simulator für Petrinetze, der neben der üblichen sequentiellen Ausführung von Petrinetzen zusätzlich die Ausführung von Transitionsschritten realisiert. Nur so ist ein einfaches Durchspielen und Testen nebenläufigen Schaltens eines Petrinetzes überhaupt möglich. Diskutiert wurden verschiedene Möglichkeiten den Benutzern aktivierte Transitionsschritte anzuzeigen und somit auch auf mögliche Konflikte im zu simulierenden Petrinetz aufmerksam zu machen. Ein zweiter wichtiger Punkt war die Möglichkeit, MuPSi je nach Einsatzgebiet in verschiedenen Modi zu betreiben, was die mögliche Eingabe von Transitionsschritten durch den Benutzer betrifft. Nach der vollständigen Implementierung von MuPSi werden wir uns auf den Aspekt der Konfliktauflösung konzentrieren. Was passiert, wenn im Mehrbenutzerbetrieb ein 32

36 Abbildung 5. Bild von MuPSi. Transitionsschritt verteilt ausgewählt wird, der nicht nebenläufig schalten kann? Da MuPSi besonders in der Lehre eingesetzt werden soll, wäre hier neben einem einfachen Nicht-Ausführen des gesamten Schrittes, ein gezieltes Feedback an alle Nutzer wünschenswert, welches auch Möglichkeiten aufzeigt, den Konflikt zu beheben. Literatur 1. R. Bergenthum. Algorithmen zur Verifikation von halbgeordneten Petrinetz-Abläufen: Implementierung und Anwendungen. Master s thesis, Katholische Universität Eichstätt-Ingolstadt, M. Burmester, F. Koller, and C. Höflacher. Touch it, move it, scale it - multitouch. Technical report, HDM Stuttgart, J. Desel, G. Juhás, R. Lorenz, and C. Neumair. Modelling and Validation with Viptool. In W.M.P. van der Aalst; A.H.M. ter Hofstede; M. Weske, editor, Business Process Management, volume 2678 of Lecture Notes in Computer Science, pages Springer, T. Freytag. Woped workflow petri net designer. In ATPN, K. Jensen, L. Kristensen, and L. Wells. Coloured petri nets and cpn tools for modelling and validation of concurrent systems. International Journal on Software Tools for Technology Transfer (STTT)9(3-4), pages ,

37 Data under control Niels Lohmann and Karsten Wolf Universität Rostock, Institut für Informatik, Rostock, Germany {niels.lohmann, Abstract. Controllability is a fundamental sanity check for open systems such as services. Existing approaches to check controllability consider Petri net models in which data aspects are usually neglected or abstracted from. This paper investigates controllability of algebraic Petri nets and sketches a symbolic analysis approach. 1 Introduction The paradigm of service-oriented computing advocates replacing large monolithic systems by a composition of loosely coupled components, called services. The behavior of services can be faithfully modeled with open nets [7], a class of Petri nets with dedicated interface places. Composition of services then boils down to gluing these interface places. Controllability [12] is a fundamental sanity check for open nets. An open net N is controllable iff there exists another open net M (called partner of N) such that their composition N M can always reach a distinguished final marking. Controllability of N can be verified constructively by synthesizing such a partner M. So far, partner synthesis has only been investigated for uncolored open nets. Apart from obvious advantages such as decidability and efficient implementations [6], this has the drawback that data can only be modeled to a very limited extend. In this paper, we study controllability of algebraic open nets; that is, an extension of open nets with an algebraic specification. To reason about the behavior of an algebraic open net N, its algebraic specification needs to be interpreted. This results in a family of colored open nets that share the structure of N, but provide concrete semantics for the symbols used in the specification. Partner synthesis for colored open nets may unfortunately be undecidable [8], as infinite color domains may yield infinite state systems. Alternatively, symbolic methods treat the algebraic specification syntactically and replace interpreting by term rewriting and equivalence checks. Similar to parametrized reachability graphs for algebraic nets [4,11], we introduce a parametrized partner synthesis approach for algebraic open nets. The rest of this paper is organized as follows. The next section introduces algebraic open nets and related concepts in terms of an example we use throughout this paper. Because of space constraints, we refrain from a formal definition and refer to standard literature for Petri nets and algebraic specifications [10]. Section 3 sketches partner synthesis for algebraic open nets and its application to the running example. Section 4 discusses related approaches. Section 5 concludes the paper and describes open issues with this approach. 34

38 a D x p 1 t 1 var x: D x C C p 4 t 4 var y: D y y D b SPECIFICATION S; SORT D, C; OPN f : D! D; :! C; (a) specification S p 2 t 2 p 3 x x var x, y : D C d t 3 C C p 5 y y t 5 f(y) var x, y : D D f(x) C t 6 p 7 p 6 (b) algebraic open net N C c e Fig. 1. Running example 2 Algebraic open nets An algebraic open net extends an open net with an algebraic specification, consisting of an signature (containing sorts and operations), variables, and a set of equations. For this paper, we consider the specification S, cf. Fig. 1(a). We distinguish a sort for data (D) and a sort for the control flow (C) of the service. For the latter sort, we are only interested in the constant symbol which has the role of standard black tokens. Other values of C are not used. The unary function f is used to exemplify the treatment of terms. In this example, we do not employ a set of equations. The specification then is linked to an open net by annotating places with sorts, transitions with variable declarations, and arcs with multiterms; Figure 1(b) depicts an example. This algebraic open net may concurrently receive two messages of sort D from the channels a and b, respectively. Then, f(v) is sent to channel c where v is nondeterministically chosen to be either the value that was received from channel a (t 2 ) or from channel b (t 5 ). Depending on this choice, a message of sort C is expected from either channel d or e. To reach the final marking [p 7. ], a partner service M apparently has to be able to deduce the choice of N from the value sent to channel c. This in turn depends on the operation f as well as the values that were initially sent from M to channel a and b. In the remainder of this paper, we show an algebraic partner can be synthesized together with a set of constraints that also need to be satisfied by any interpretation. 35

39 3 Symbolic partner synthesis 3.1 Partner synthesis in a nutshell We begin with a description of the partner synthesis approach for open nets without algebraic specification [12]. This approach bases on the fact that the behavior of an open net can only be influenced indirectly by sending and receiving messages the concrete marking of the open net cannot be observed. As a consequence, a partner can only make assumptions on the actual marking of the open net. These assumptions are formalized by a set of markings that cannot be distinguished by the partner. The synthesis approach uses these sets as states of the partner and therefore synthesizes an automaton rather than a Petri net model. This automaton can be translated into a Petri net employing region theory [2] in a later step. Each of the partner s transition is labeled by a communication event:!a and?a for sending a message to and receiving a message from channel a, respectively. In a postprocessing step, states that contain markings from which no final marking can be reached are iteratively removed. Unless all states are removed, we can conclude controllability of the open net. The termination of this approach can be shown in case of bounded behavior of the open net and the restriction to a bounded number of messages that may be pending at all times. Under these assumptions, the number of marking set is finite. The interested reader is referred to [12] for a detailed description and formalization. 3.2 Symbolic synthesis This paper aims at extending the synthesis toward algebraic open nets. Thereby, we follow a symbolic approach. This means that we refrain from enumerating the concrete data sets, but replace concrete data values (e. g., for messages) by variables and calculate with these variables. As a result, we need to cope with parametrized markings. This brings three challenges. First, the equality of markings and marking sets is more difficult to check. Rather than comparing multisets, we need to compare multiterms. Such equivalence checks may yield high worst-case complexity or may be even undecidable. Second, we need to be able to express dependencies between different states. A final marking may, for example, only be reachable for a certain constellation of data values. Such a constellation needs to be expressed in terms of constraints. In addition, states that violate these constraints need to be removed. Third, the origin of the data plays an important role. Whereas the environment has control over messages values that are sent to the service, it only has indirect influence on the values that are received. This limited scope of action needs to be taken into account to avoid spurious and unrealizable synthesized partners. 36

40 [p 1.,p 4. ] q 0 q 2 q 1 [p 1.,p 4.,a.v 1,b.v 2 ] [p 2.v 1,p 4.,b.v 2 ] [p 1.,p 5.v 2,a.v 1 ] [p 2.v 1,p 5.v 2 ] [p 3.,c.f(v 1 )] [p 6.,c.f(v 2 )] [p 1.,p 4.,a.v 1 ] [p 2.v 1,p 4. ]!b.v 2?c.v 3!a.v 1!b.v 7 [p 1.,p 4.,b.v 7 ] [p 1,p 5.v 7 ]?c.v 10!a.v 8 q 7 [p 1.,p 4.,a.v 8,b.v 7 ] [p 2.v 8,p 4.,b.v 7 ] [p 1.,p 5.v 7,a.v 8 ] [p 2.v 8,p 5.v 7 ] [p 3.,c.f(v 8 )] [p 6.,c.f(v 7 )] q 8?c.v?c.v5?c.v 6?c.v 11 4?c.v 12?c.v9 q 4 q 3 [p 6. ]!e. [p 6.,e. ] [p 7. ] VAR v 1,...,v 12 : [p 3. ]!d. [p 3.,d. ] [p 7. ] D EQUIVALENCES: v 3 f(v 1 ) v 5 6 f(v 1 ) v 3 f(v 2 ) v 4 f(v 1 ) v 4 6 f(v 2 ) v 5 f(v 2 ) v 6 6 f(v 1 ) v 6 6 f(v 2 ) q 5 q 6 v 9 f(v 7 ) v 9 f(v 8 ) v 10 f(v 7 ) v 10 6 f(v 8 ) q 13 v 11 6 f(v 7 ) v 11 f(v 8 ) v 12 6 f(v 7 ) v 12 6 f(v 8 )!d. [p 3.,d. ] [p 6.,d. ] [p 7. ]!e. [p 3. ] [p 6. ] q 9!e. [p 3.,e. ] [p 6.,e. ] [p 7. ] q 10 q 11!d. [p 3.,d.,e. ] [p 6.,d.,e. ] [p 7.,d. ] [p 7.,e. ] q 12 Fig. 2. Symbolic partner synthesis To synthesize a partner for the open net N (cf. Fig. 1(b)) while taking the above mentioned challenges into account, we proceed as follows. We discuss the symbolic partner synthesis approach in terms of the example depicted in Fig. 2. Variables. Whenever a data value is produced or consumed, we introduce a fresh variable (typed with the appropriate sort) and use it as placeholder in the marking sets. As an example, consider the transition labeled!a.v 1 reaching the state q 1 in which the value v 1 is used in two markings. This value corresponds to the value that would be bound to variable x when firing transition t 1 in the algebraic open net N (cf. Fig. 1(b)). We see that after sending a message with value v 2 to channel b, these values are also used as arguments for the function f in state q 2. 37

41 Equivalences. Consider the state q 2 that contains the markings [p 3., c.f(v 1 )] and [p 6., c.f(v 2 )]. These markings model the outcome of the conflict between transition t 2 and t 5. This conflict is not visible to the environment of N. Conclusions about the current marking of N depend on assumptions on the relationship between the two values f(v 1 ) and f(v 2 ) on channel c. This yields four different successor states: 1. A value v 3 is received which is equivalent to both values. Consequently, the environment cannot derive the outcome of the choice and in state q 3 it remains unknown whether p 3 or p 6 is marked. As each marking requires a different continuation (i. e., sending a message to channel c or d) the final marking cannot be safely reached. As a result, the gray shaded states are removed meaning that N cannot be controlled if f(v 1 ) and f(v 2 ) are equivalent. 2. A value v 4 is received that is equivalent only to f(v 1 ). In this case, state q 5 is reached and the environment can be sure that only p 3 is marked and sending a message to channel d reaches the final marking. 3. Analogous to the previous case for value v 5 which is equivalent to f(v 2 ). 4. A value v 6 is received that is neither equivalent to f(v 1 ) nor to f(v 2 ). This situation cannot occur and an empty state q 13 is reached. The resulting equivalences follow straightforwardly from a case distinction. Constraints. After removing the gray states q 9 q 12, the final marking [p 7. ] is always reachable. Consequently, N is controllable and Fig. 3 depicts a partner. It is annotated with constraints that not only express the equivalences we derived earlier, but that also formulate the restrictions that follow from the origin of the message values: The values v 1 and v 2 can be freely chosen by the environment as long as it is guaranteed that they can be distinguished after applying function f. This is formalized by according quantification of the variables. To summarize, N is controllable for every interpretation of the specification S such that the constraints are satisfiable. An example would be interpreting D as the set of integers and f as the function f(x) = 2x for all x Z. Then the constraints are satisfied by any distinct pair of integers as 2x 2y for all x y. 4 Related work The introduction of fresh variable names is motivated by a compiler technique called static single assignment form [1]. Moser et al. [9] extended this technique to also cope with concurrency and derived data dependencies in WS-BPEL processes. This extension was later used to restructure WS-BPEL processes before translating them into uncolored open nets [3]. A similar approach is also followed by Lohmann et al. [5]. To the best of our knowledge, the presented partner synthesis in this paper is the only approach in which data is treated symbolically. 38

42 q 0!a.v 1!b.v 7 q 1 q 7!b.v 2!a.v 8 q 1 q 2?c.v 4 q 8?c.v 5 q 3!e. q 4?c.v 10?c.v 11 q 5!d. q 6 CONSTRAINTS: 9v 1, v 2 2 D : 8v 4 2 D : v 4 f(v 1 ) ^ v 4 6 f(v 2 ) 9v 1, v 2 2 D : 8v 5 2 D : v 5 6 f(v 1 ) ^ v 5 f(v 2 ) 9v 7, v 8 2 D : 8v 10 2 D : v 10 f(v 7 ) ^ v 10 6 f(v 8 ) 9v 7, v 8 2 D : 8v 11 2 D : v 11 6 f(v 7 ) ^ v 11 f(v 8 ) Fig. 3. Symbolic partner for the open net N 5 Open issues and concluding remarks This paper sketched a symbolic partner synthesis approach for algebraic open nets which extends the idea of parametrized reachability graphs. We showed the principal application in terms of a running example. Even this small example demonstrated some arising challenges that need to be studied in future work. In Fig. 2, we can see that state q 2 and q 8 yield the same successor states. In fact, these two states only differ in the order in which the environment sent the messages a and b. Whereas it would be easy to proof equivalence of these states in this example, a generic method deserves further attention. In particular, the folding of cyclic behavior is a challenging tasks, because the equivalence of markings containing different terms needs to be shown. Existing results in the area of parametrized reachability graphs seem to be a promising starting point to tackle such problems. Acknowledgments. The authors thank Christoph Wagner for inspiration on the running example. References 1. Alpern, B., Wegman, M.N., Zadeck, F.K.: Detecting equality of variables in programs. In: POPL pp (1988) 2. Badouel, E., Darondeau, P.: Theory of regions. In: Advanced Course on Petri Nets. pp LNCS 1491, Springer (1996) 3. Heinze, T.S., Amme, W., Moser, S.: Process restructuring in the presence of messagedependent variables. In: ICSOC 2010 Workshops. pp LNCS 6568, Springer (2010) 39

43 4. Lindquist, M.: Parameterized reachability trees for predicate/transition nets. In: PETRI NETS. pp LNCS 674, Springer (1991) 5. Lohmann, N., Massuthe, P., Stahl, C., Weinberg, D.: Analyzing interacting WS- BPEL processes using flexible model generation. Data Knowl. Eng. 64(1), (2008) 6. Lohmann, N., Weinberg, D.: Wendy: A tool to synthesize partners for services. In: PETRI NETS pp LNCS 6128, Springer (2010) 7. Massuthe, P., Reisig, W., Schmidt, K.: An operating guideline approach to the SOA. Annals of Mathematics, Computing & Teleinformatics 1(3), (2005) 8. Massuthe, P., Serebrenik, A., Sidorova, N., Wolf, K.: Can I find a partner? Undecidablity of partner existence for open nets. Inf. Process. Lett. 108(6), (2008) 9. Moser, S., Martens, A., Görlach, K., Amme, W., Godlinski, A.: Advanced verification of distributed WS-BPEL business processes incorporating CSSA-based data flow analysis. In: IEEE SCC pp IEEE Computer Society (2007) 10. Reisig, W.: Petri nets and algebraic specifications. Theor. Comput. Sci. 80(1), 1 34 (1991) 11. Schmidt, K.: Parameterized reachability trees for algebraic Petri nets. In: PETRI NETS. pp LNCS 935, Springer (1995) 12. Wolf, K.: Does my service have partners? LNCS T. Petri Nets and Other Models of Concurrency 5460(2), (2009) 40

44 SYNOPS Generierung allgemeiner partieller Sprachen und effiziente Synthese von Petrinetz-Modellen Robert Lorenz, Christoph Etzel, Dan Zecha Fakultät für Angewandte Informatik Universität Augsburg 26. September 2011 In dieser Arbeit präsentieren wir ein Kommandozeilentool für die einfache Generierung allgemeiner partieller Sprachen und die effiziente Synthese von Petrinetz-Modellen aus solchen Sprachen. Das Tool dient der prototypischen Implementierung und Evaluierung der in der Verlängerungsphase des DFG-Projekts SYNOPS entwickelten Algeorithmen. 1 Einleitung Die in der ersten Phase des DFG-Projekts Synthese von Petrinetzen aus Szenarien (SYNOPS) [1] bis 2010 entwickelten Algorithmen wurden größtenteils prototypisch im grafischen Editor VIPTOOL [2, 3] am Lehrstuhl für Angewandte Informatik der Katholischen Universität Eichstätt-Ingolstadt für Evaluierungszwecke implementiert. Mittlerweile ist das VIPTOOL an die Feruniversität in Hagen ungezogen. Das Projekt SYNOPS wurde bis 2012 verlängert und wird aktuell an der Lehrprofessur für Informatik der Universität Augsburg bearbeitet. Aus diesem Grund wird aktuell an dieser Lehrprofessur für Informatik das Kommandozeilentool SYNOPS entwickelt. In ihm sollen die in der Verlängerungsphase des Projekts SYNOPS entwickelten Algeorithmen prototypisch implementiert werden. Die in Kürze zu dem gleichnamigen Vortrag beim Advanced Course on Petri Nets (ACPN) 2010 erscheinende Publikation Models from Scenarios [4] enthält erste neue Ergebnisse der Verlängerungsphase: 41

45 - Eine termbasierte Darstellung unendlicher Mengen von Abläufen, welcher bisherige Darstellungen [5] stark verallgemeinert. Das Tool SYNOPS implementiert die Generierung solcher Mengen über Eingabe von Termen über Kommandozeile oder aus Textdateien. - Verschiedene Darstellungen eines Ablaufs mit unterschiedlicher Semantik: Zusätzlich zu beschrifteten partiellen Ordnungen und deren Erweiterung zu beschrifteten geschichteten Ordnungen jetzt auch deren nicht zwangsläufig transitiv abgeschlossene Varianten. SYNOPS unterstützt alle vier Darstellungen durch geeignete Datenstrukturen. - Verschiedene regionen-basierte Synthesealgorithmen ausgehend von den angesprochenen Termen, welche sich aus den in [6] beschriebenen möglichen Kombinationen verschiedener Typen von Regionen (Transitions- oder Markenfluss-Region), verschiedener endlicher Repräsentationen der Menge aller Regionen (Basis- oder Separations-Repräsentation) und verschiedener Petrinetz-Klassen (Stellen/Transitions-, Bedingungs/Ereignis- oder Inhibitornetze) als Ziel der Syntheseverfahren ergeben. Bisher wurden in SYNOPS die Synthese von Stellen-/Transitions-Netzen aus endlichen Mengen von beschrifteten partiellen Ordnungen und von azyklischen gerichteten Graphen unter Benutzung der Separations-Repräsentation von Markenfluss-Regionen implementiert. Aktuell werden diese Verfahren einerseits auf beschriftete geschichtete Ordnungen und Inhibitornetze, andererseits auf unendliche Mengen von Abläufen verallgemeinert. Im Kapitel 2 wird die Architektur und das Kommandozeileninterface des Tools vorgestellt, in Kapitel 3 werden kurz die bereits implementierten Synthesealgorithmen beschrieben. 2 Architektur und Funktionalität 2.1 Überblick Der Aufbau des Tools orientiert sich an einem klassischen Drei-Schichten-Modell: - Benutzereingaben nimmt das System über ein Kommandozeileninterface (CLI) entgegen. Die textbassierte Eingabe wird durch die Möglichkeit der graphischen Ausgabe einzelner Graphen erweitert. Durch lose Kopplung des Benutzerinterfaces mit dem Kern-System ist in Zukunft ein schneller und unkomplizierter Austausch desselben ohne weiteres möglich. - Datentypen und Grundfunktionalität sind in einer Logikschicht (SynCore) gekapselt und nur über eine Fassade (SynShell) ansprechbar. Dies erleichert lose Kopplung und den Austausch und das Hinzufügen einzelner Komponenten. SynCore übernimmt neben der Speicherverwaltung für Objekte auch die wichtigsten Funktionalitäten zum Erzeugen, Freigeben und Verwalten von Objekten. 2 42

46 - Zur konsistenten Speicherung von Petrinetzen bietet sich der XML-Standard PNML an, welcher das System als dritter Teil komplettiert. Abläufe können in Textdateien gespeichert und aus ihnen geladen werden. Abbildung 1: System-Architektur. Abbildung 1 gibt einen Überblick über die Architektur. Da eine umfassende Veränderung der Kernfunktionalität zukünftig nicht mehr vorgesehen ist, werden Synthesealgorithmen über ein Plug-in System als dynamische Bibliotheken an den Kern angeschlossen, wobei sämtliche Kommunikation über die SynShell-Fassade abgewickelt wird. Die Fassade implementiert Interfaces, die ein solches Plug-in System unterstützen und damit eine Anpassung des Interfaces an einen neuen Algorithmus überflüssig machen. 2.2 Logikschicht SynCore Ein Ablauf besteht aus einer Menge von mit Namen beschrifteten Ereignissen sowie gerichteten Kanten zwischen den Ereignissen und kann durch vier verschiedene kausale Strukturen mit unterschiedlicher Semantik repräsentiert werden: - Gerichtete kreisfreie Graphen (Klasse DAG): Hier steht jede gerichtete Kante für eine direkte kausale Abhängigkeit zwischen den verbundenen Ereignissen. - Gerichtete kreisfreie Graphen erweitert um sog. nicht später als -Kanten zwischen Ereignissen (Klasse SDAG). Eine nicht später als -Beziehung zwischen zwei Ereignissen lässt deren gleichzeitiges und der sequentielles Eintreten in einer der beiden möglichen Richtungen zu. Durch nicht später als -Zyklen lassen sich synchrone Ereignisse modellieren, welche nur gleichzeitig eintreten können. - Beschriftete partielle Ordungen (Klasse LPO): Das sind transitiv abgeschlossene DAGs. Eine Kante repräsentiert hier eine früher als -Beziehung zwischen Ereignissen. - Beschriftete geschichtete Ordnungen (Klasse LSO): Das sind transitiv abgeschlossene SDAGs. 3 43