The Petri Net Tools Neptun and Poseidon Carlo Simon, Hanno Ridder, Thomas Marx 15/97
Fachberichte INFORMATIK
Universitat Koblenz-Landau Institut fur Informatik, Rheinau 1, D-56075 Koblenz E-mail:
[email protected], WWW: http://www.uni-koblenz.de/fb4/
The Petri Net Tools Neptun and Poseidon Carlo Simon, Hanno Ridder, and Thomas Marx Department of Computer Science University of Koblenz-Landau Germany email: fsimon,ridder,
[email protected] May 1997 Abstract In the last years the team around Prof. Lautenbach at the university of Koblenz-Landau, department Koblenz, institute for software engineering, developed the Petri net tool NEPTUN. A half year ago, the decision had fallen to reorganize this very complex software and to split it thematically into several packages. From these considerations, a second Petri net tool, named POSEIDON, was developed by the team. Both programs, NEPTUN and POSEIDON, are characterized by a homogeneous architecture. This architecture is topic of the present technical report. Chapter 1 gives a historical survey of the development of the two programs and motivates the architecture. Chapter 2 explains the structure of data and modules in general while chapter 3 describes how to extend the program by new components by means of a program module for simulating Petri nets. Chapter 4 explains how to use the data structure of NEPTUN and POSEIDON for own implementations. Chapter 5 presents the documentation of the programs. Chapter 6 contains an outlook.
1 History The Petri net tool NEPTUN (NEt ProtoTyping UNit), that is developed by the team around Prof. Kurt Lautenbach, was planned as a experimental tool from its beginning. One aim was to built an environment for testing new algorithms for analyzing Petri nets. Also, as many as possible known algorithms for analyzing nets should be implemented in this environment ([Hilc92, Alkan92, Erni93, Klufer93, Muhr95, Schl95]). Another aim that was pursued by the development of NEPTUN was to built a framework for testing new applications for Petri nets. Here, the main focus was set on the development of database applications with Petri nets ([Wipp92, Ernst92, Thuy92, Neub94, Simon96, Dhaeze96, Schw97]). 1
The CASE-tool which resulted from the considerations mentioned above o ered a large number of various functionalities. First, we had to consider several editor functionalities: Editors for di erent net classes had to be developed, of course. Here, we had to consider that nets can be re ned and organized in a hierarchy using an underlying hierarchical concept. In order to be able to assign a type to places in Pr/T-nets and DataLog nets ([DahLau91a, DahLau91b, Dahr94]) rst speci cation components ([Mase91, Marx92, Derk93]) and later an editor was developed for OM diagrams. Another editor became necessary for designing APRIL-diagrams1 and animations ([Schw97]). We also had to enable the users of NEPTUN to organize these di erent kinds of diagrams in projects so that the development of a project browser became necessary. Pr/T-net algorithms for the computation of T-invariants have been implemented and for S/Tnets in addition algorithms for the computation of S-invariants, deadlocks, and traps. The results of these computations can be immediately visualized in the tool ([Hilc92, Klufer93, Muhr95, Schl95]). Furthermore, algorithms for proving net speci cations of S/T-nets and Pr/T-nets were developed. They make use of an ecient representation of reachability sets using ordered natural decision diagrams and structural properties of the analyzed nets. The algorithms were implemented as independent programs, however, they use the data structure of NEPTUN and can be applied to nets, that are edited with NEPTUN2 ([LauRid95]). With the aid of NEPTUN, a new software development method was investigated called NetCASE ([Dahr94, Marx95, Marx97]). It makes use of APRIL diagrams that were mentioned above to describe the context around the application. Data processing nets and system navigation nets, both based on Pr/T-nets, are used as a programming language for database applications ([Simon96]). One of the basic ideas of NetCASE is that the APRIL diagrams, which are the result of the requirements analysis of the software to be developed, are translated by a semi automatic step into data processing and system navigation nets. Consequently, the results of the so-called early stages of software development can be transfered seamlessly into program speci cations and need not be interpreted while writing the speci cation of the program, as one has to do in the case of other methods. Since our program speci cation is based on Petri nets, which are at the same time the programming language, a smooth transition is realized here between the program speci cation and the program itself. The data processing and system navigation nets are translated into INFORMIX-4GL and Java for having a platform independent software; the algorithms for translating APRIL diagrams into the net classes mentioned above are under construction. Because of the dynamic properties of Petri nets they can be regarded as an alive blueprint of the modeled system. In order to pro t from this special property of nets, tools based on Petri nets must contain simulators. In NEPTUN, simulators for S/T-nets, Pr/T-nets, and DataLog nets were implemented as well as for data processing and system navigation nets. However, for the implementation of these simulators no homogeneous structure has taken into APRIL is an acronym for animated programming illustration. APRIL diagrams are nets of channels and agencies that can be used to sketch scenarios and buisness processes. For APRIL diagrams no ring rule is de ned, however, animations can be de ned for APRIL diagrams and visualized by the tool described here. 2 The integration of the algorithms is planned. 1
2
consideration3 ([Ernst92, Derk93, Simon96, Deck96, Wilke96]). All in all, NEPTUN evolved into two directions, since it was planned as a experimental tool: On the one hand, it was used as a tool for work with Petri nets and as a practical base for the further development of net theory, and on the other hand, it served as a tool for programming database applications with Petri nets. Exactly from this variety of possibilities a problem occured: Developers of database applications are not necessarily interested in traditional net theory, and vice versa, net theoreticians are not necessarily interested in the development of database applications. Consequently, it was decided to develop two applications separated thematically from each other, but making use of the algorithms that have already been developed. We decided NEPTUN to support the development of database applications with Petri nets. POSEIDON was planned as an open Petri net tool. The following chapter describes the architecture of the two tools. I want to point out that the extensive programming and detailed solutions of the architecture were achieved by students who have worked in our team or on their study and master's thesis.
2 The architecture of NEPTUN and POSEIDON NEPTUN and POSEIDON show many common characteristics. Here, the data structure of both tools is to be mentioned rst and is explained in sections 2.1 and 2.2. In addition, editors, simulators, and analysis components are required by both. Such (large) parts of both programs are called program modules in the following. A module contains a user interface with speci c functionality. For example, editors require draw canvases as well as functions for drawing, analysis components require a user interface to do the analysis and to present the results. A method was developed to construct NEPTUN and POSEIDON from modules. This method allows to integrate di erent modules into both programs. The concept for the integration of modules into a program is explained in section 2.3. In section 2.4 will be explained, how attributes, added to the data structure, can be stored into and loaded from project les. Finally, in section 2.5 the graphical user interface of both programs is explained.
2.1 The basic data structure
In both programs, a data structure is required for the representation of graphs since we understand Petri nets, OM-diagrams, and APRIL-diagrams as attributed graphs with directed arcs. This graph representation is reasonable for these di erent modelling languages in CASE tools, since they all must make use of the models structure, from the editor on to the analysis component. The reason for this was that the simulators have been developed by several and independend study and master's theses and from di erent points of view and objectives. 3
3
Figure 1 shows the data structure for graphs and its specialization with respect to Petri nets, OM-, and APRIL-diagrams. We distinguish graphs for nets, OM-, and APRIL-diagrams. A graph consists of a set of vertices (Vertex) and edges (Edge). Every vertex can have several incoming and outgoing arcs. Since arcs are directed, incoming and outgoing arcs can be distinguished by roles (Start and End). Transitions (Transition) in nets and classes (Class) in OM-diagrams are special kinds of vertices, edges (Flow) in nets and associations (Association) in OM-diagrams are special kinds of edges. Project
Graph
Net
OM
APRIL
Socket
Start
Connection
Vertex
Edge
Port
Supervertex
End
Transition
Class
...
Flow
Association
...
Supertransition
Figure 1: Data structure for graphs Complex models (Project) consist of a set of graphs which are connected with each other. The connection of the graphs is realized by means of super arcs (Connection) with which vertices of di erent graphs are connected with each other. A vertex which is re ned is called a supervertex (Supervertex). In such a way, supertransitions (Supertransition) are re ned in NEPTUN and POSEIDON by nets. Since re nements are directed also here di erent roles (Socket and Port) for the vertices involved in the connections have to be distinguished.
4
2.2 Expanding the data structure using categories
The data structure for graphs as described above, must be extendable for di erent elds of application. For example, gure 2 shows that the editor module must know the coordinates of the vertices. Similarly, the simulator module must know for a transition, whether it is activated. However, these information are unimportant for the respective module. Simulator isActivated ()
Editor
(x, y)
Graph
Figure 2: Examples for categories In the programs NEPTUN and POSEIDON, a mechanism is implemented for expanding the data structure according to such di erent points of view. The extension of a class by attributes and methods using this mechanism is called category. Several categories can be assigned to every class. If an object of such a class is created, memory is also allocated for its categories. In addition, the class and its categories are connected to each other. An object of such a class can access the attributes and methods of its corresponding categories by a standard method. The other way round, every object of a category can identify its class using another standard method. Here, meta information is necessary for describing the structure of classes and categories in NEPTUN and POSEIDON. This meta information is organized in the programs as shown in the data model of gure 3. According to this, every class implemented in NEPTUN or POSEIDON for administration of project information inherits from BaseClass; the categories inherit from BaseCat. To every object of BaseClass several objects of BaseCat can be assigned. Meta information is stored in the classes ClassDesc and CatDesc. For the administration of this information, we bene t from the circumstance that several classes and categories can be described in the same manner. Categories allow to seperate the views on di erent modules. Particularly, this is helpful with regard to the module concept explained in the following, since adding a module to the programs 5
BaseClass
ClassDesc
BaseCat
CatDesc
Figure 3: Meta-information for categories NEPTUN or POSEIDON does not only require its interface information, but also information about its view on the data structure.
2.3 The module concept
NEPTUN and POSEIDON have many common functional characteristics besides the data structure. For example, editors are required by both. Other functionalities, as for instance the analysis of nets or the translation from data processing and system navigation nets to Java programs are implemented only in one program. So, we consider NEPTUN and POSEIDON as sets of modules, with many modules employed by both. In order to bene t from this point of view, a data structure for the administration of modules was created. Figure 4 shows a part of this data structure. All modules inherit from the class BaseModule. In this class, a mechanism for modules is implemented to send messages to each other module. This mechanism is of central importance, if one wants to construct programs out of several modules according to the scheme described here. For instance the main module (MainModule) uses this mechanism in the initialization routine: It sends messages to all modules it knows. All who answer to him are part of the current con guration, de nitely. Also it can be concluded that the remaining modules are not a part of the current con guration. The project graph, the data structure for the administration of a project, is implemented in the class ProjectModule. Objects of the GraphProviderModule are used to administrate the information for a single graph of a project. This data structure is, according to Petri nets, OM-, and APRIL-diagrams, specialized into the classes NetModule, OMDModule, and APRILModule, respectively. While running the programs NEPTUN and POSEIDON, one can change between di erent modes. Today, the edit, simulate, and analyze modes are implemented. According to the mode the appearance and behavior of the user interface change for the graphs currently edited in NEPTUN or POSEIDON. Thus, for example the concrete appearance and behavior is realized for the edit mode in the classes NetEditModule, OMDEditModule, and APRILEditModule.
6
BaseModule
MainModule
GraphProviderModule
ProjectModule
NetModule
OMDModule
APRILModule
EditModule
NetEditModule
ModeModule
SimModule
OMDEditModule
APRILEditModule
...
. . .
Figure 4: Data structure for the administration of the modules
2.4 Persistence
Loading and saving projects is directly supported by the architecture of NEPTUN and POSEIDON. The mechanisms necessary for this are already implemented in the classes BaseClass and BaseCat, introduced in section 2.2. If the attributes of a class or a category have to be stored and loaded afterwards, the class or the category just have to be specializations of the classes BaseClass or BaseCat, respectively. In this specialization the inherited methods doLoad and doSave or the inherited method doSave and a constructor for loading have to be overwritten. In section 4.4 an examplary implementation is given. For more information on persistence, we recommend as a subsequent literature [Josu94]. The concept for loading and saving, as it is implemented in NEPTUN and POSEIDON, follows the persistence concept given here.
2.5 The user interface
Figure 5 shows the project browser of NEPTUN. Its "look and feel" corresponds to all the other elements of the user interface of the two programs. In the left upper corner of the window, the window identi er is displayed. The create buttons are arranged below. If a create 7
button is pressed, new nets, OM-, and APRIL-diagrams can be created in the project browser, respectively. The action buttons are arranged below the create buttons. They can be used for loading and saving the project or for opening the options window. The print button and buttons for cut/copy/paste-operations are arranged above the draw canvans. The zoom factor slider is next to them. Between the slider used for setting the zoom factor and the help button, the mode toolbar is arranged. With its aid, one can adjust the mode in which one wants to work with the programs NEPTUN or POSEIDON. The modes editing, simulating, and analyzing are implemented in both programs already.
Figure 5: The user-interface of the project browser Figure 6 shows the net editor. The net editor is identical in NEPTUN and POSEIDON. It contains the same graphical elements as the project browser. The di erence between the project browser and the net editor is that in the net editor create buttons are used for creating new vertices and edges in nets. Action buttons can be used for parsing the inscriptions of edges and transitions or to open the options window. The action bar above the draw canvas is almost unchanged, compared to the project browser. Since the net editor can presently be operated in only one mode, correspondingly only one mode is o ered in the mode toolbar. In both programs all further windows are built up in the same manner, even for the modes simulating and analyzing.
8
Figure 6: The user-interface of the net editor
3 The simulator In the previous chapter, we explained the module concept of NEPTUN and POSEIDON in general. Now we show by means of the simulator module, in which way new components are added to the programs. The simulator module is implemented as a general simulator that is free from speci cs forced by a special net class. The simulators for special net classes are derived from this general simulator. This approach supports the reuse of large parts of the program and o ers a framework, in which POSEIDON can be extended by new simulators in a homogeneous way. A central concept of net simulators is, that the activation of transitions depends on the marking of the places in their pre- and postsets. Moreover, in higher net classes activations are possible under di erent bindings of the involved variables. By a hierarchy concept with which supertransitions are re ned by nets, several instances of places and transitions may exist; these have to be distinguished. Besides the ring rule, ring strategies also play an important role in simulators. A possible strategy is that the user selects the transition to re next from the set of activated transitions. However, the next transition can also be selected by chance or the selection can occur after rules like for example the compliance with a given synchrony distance. In addition to these theoretical aspects, aspects of the user interface of all simulators can already be considered in the architecture of a general simulator. 9
3.1 Adding the simulate mode to the program
Figure 7 shows how the class SimModule from gure 4 can be re ned for the simulator. Here, a special feature, which can occur while simulating, is to be considered in the architecture: In a project, nets of di erent net classes can be combined. For example, S/T-nets may be combined with time nets. However, the appearance and behavior of the simulator depends on the simulated net class. If we want to simulate a project in which di erent net classes are combined, an individual behavior for each net in the project during a simulation must be supported. For this purpose, we associate objects of the class PNSimulator with objects of the class SimModule. An object of the class PNSimulator implements the behavior of a single net of the project. The object of the class SimModule only has the task to transmit events assigned to the simulator as a whole to the corresponding objects of the class PNSimulator. ModeModule
SimModule
STSimulator
PNSimulator
PrTSimulator
...
Figure 7: Structure for adding a simulator to the program Figure 7 shows, that the implementation of the class PNSimulator must be specialized for the di erent net classes.
3.2 Simulating in accordance to strategies At the beginning of this chapter we explained that a Petri net simulator must support di erent ring strategies. Therefore, the selection of the transition to be red next is achieved by a scheduler that can be specialized in accordance with the di erent strategies. The selection of transitions by chance is implemented as the most general case in the class BaseScheduler. This is specialized in accordance with the net classes supported in the program, that is for example the STScheduler or the PrTScheduler. The realization of the di erent ring strategies for a single net class occurs below this level of re nement. Figure 8 shows the architecture for this structure where the STSchedulder is specialized by the strategy Interactive. In this case, the class Interactive implements that the user selects the next transition to be red. 10
BaseScheduler
STScheduler
PrTScheduler
PNSimulator
...
... Interactive
...
Figure 8: Adding a strategy component to the program Since the selection of the transition to be red next by chance is already implemented in the class BaseScheduler, this strategy is usable for every net class as a default strategy, consequently. Naturally, there are many links between the scheduler BaseScheduler and the class SimModule, especially when the user decides which transition is to be red next. In section 3.4 the link between the scheduler and the data structure for the administration of the markings will be explained.
3.3 The ring rule and connections in hierarchical nets
In Petri nets, the state of a net is modi ed by ring transitions. Therefore, the ring rule should be implemented as a component of the data structure of transitions. BaseCat
SimPlaceCat
STPlaceCat
PrTPlaceCat
SimTransitionCat
SimSupertransitionCat
...
...
...
Figure 9: Simulator categories for places and transitions 11
Figure 9 shows that we have de ned simulator categories for transitions and supertransitions; within them the ring rule is implemented. The category SimTransitionCat modi es the marking of the net and the category SimSupertransitionCat highlights supertransitions during the simulation, while there are activated transitions in their re nements. The data structure for the administration of the markings, especially in a net hierarchy, as well as its link to transitions is given in the next section. Furthermore, the categories for places, transitions, and supertransitions o er services for displaying these vertices in the draw canvas while POSEIDON or NEPTUN are simulating. These services have to consider, that transitions might be activated and places might be marked. Because this representations vary from net class to net class, further specializations are required. This is illustrated in gure 9. Here the categories STPlaceCat and PrTPlaceCat are specializations of the category SimPlaceCat.
3.4 Markings and activations
Since our simulator should be able to simulate net hierarchies, a data structure had to be implemented to administrate the di erent instances of nets in this hierarchy. Here, several instances of a net can exist, because a net can be a re nement of several supertransitions. Such a nets place can be marked in one instance and can be unmarked in the other one. Similar applies for transitions. They can be activated in one instance, but inactivated in another one. Figure 10 shows the data structure for the administration of the net instances. Accordingly, a net instance (NetInstance) is given by an aggregation of its place, transition, and supertransition instances (PlaceInstance, TransitionInstance, SupertransitionInstance). Since nets in a hierarchy are linked in NEPTUN and POSEIDON by places, these places must have identical markings in all the di erent instances. To avoid redundancies, if several places are coupled together, the marking should be stored only in the data structure of one place. This should be the place of the net in the highest level of the net hierarchy; the place instances of all other places involved in the link should only refer to this instance. By the re nement of the class PlaceInstance to the classes NormalInstance, SocketInstance, PortInstance, and SocketPortInstance, as shown in gure 10, such a data structure can be implemented. If furthermore the access to the marking of a place instance is encapsulated, this non-redundant data structure can be concealed completely from programmers who must work with this net instances. The information, which place instance is coupled with which other place instance is administrated by the association attributed with the roles port and socket. In higher net classes, the calculation, under which bindings of variables a transition can re, is sometimes extensive. Such calculations, which determine how the ring of a transition would alter the marking of its pre- and post-set, should therefore not be performed completely for all nets of the net hierarchy each time a transition res; it would be better to create a data structure in order to bu er the results of former calculations. This bu ering is implemented in the class BaseDelta, that is exemplaryly re ned in gure 10 by the classes STDelta and PrTDelta. Since in general a transition can re under di erent variable bindings and therefore can alter the marking of its pre- and post-set in several ways, to every object of the class 12
TransitionInstance several objects of the class BaseDelta can be assigned; to every object of the class BaseDelta several objects of the class PlaceInstance can be assigned, because usually several places are elements of the pre- and post-set of a transition.
Specializations of the general scheduler BaseScheduler introduced in section 3.2 use the information of objects of the class BaseDelta to select the transition to re next; gure 10 simpli es this by just showing the link between the classes BaseScheduler and BaseDelta. By this architecture, it can be considered easily that in higher net classes transitions can re under di erent variable bindings. NetInstance
[port]
PlaceInstance
NormalInstance
SocketInstance
TransitionInstance
[socket]
SupertransitionInstance
PortInstance
SocketPortInstance BaseScheduler
BaseDelta
STDelta
PrTDelta
...
Figure 10: Net instances for the administration of markings and activations In net hierarchies supertransitions become re ned by nets. By the association between the classes SupertransitionInstance and NetInstance, the information is administrated, which speci c instance of a supertransition is re nded by which speci c net instance. 13
Finally, gure 11 shows that to all categories of places, transitions, and supertransitions (SimPlaceCat, SimTransitionCat, and SimSupertransitionCat) all corresponding instances (PlaceInstance, TransitionInstance, and SupertransitionInstance) are associated. SimPlaceCat
SimTransitionCat
SimSupertransitionCat
PlaceInstance
TransitionInstance
SupertransitionInstance
Figure 11: Associations between net instances and simulator categories
3.5 The architecture of the simulator NetInstance
[port]
PlaceInstance
TransitionInstance
SupertransitionInstance
SimTransitionCat
SimSupertransitionCat
[socket]
SimPlaceCat
BaseDelta PNSimulator
BaseScheduler
SimModule
Figure 12: The general simulator Figure 12 gives an overall view of the architecture of the simulator. In this gure, especially the associations between the components of the simulator explained before are shown. We dispensed 14
with showing inheritence in this diagram, since it was subject of the previous sections. Except for the association between the classes SimModule and NetInstance, all associations of gure 12 were already explained in the previous sections. This remaining association assigns to every simulator an uppermost net instance in the net hierarchy.
4 Using the data structure The data structure of NEPTUN and POSEIDON aims to o er the possibility to easily develop and check new algorithms for the analysis of Petri nets. Especially, to combine the data structure of both programs with standard software, for instance such for solving homogeneous linear equation systems, seems to be very interesting. For analyzing nets with user de ned algorithms, the nets can be edited and stored with one of the two programs NEPTUN or POSEIDON. Then they are loaded by the user de ned programs and the analysis is carried out. Since functions for loading and saving nets are an integral part of the data structure, the user can concentrate on the analysis problem. We demonstrate by means of some sample programs, in which way the data structure of NEPTUN and POSEIDON can be used for programming one's own algorithms. We assume, that we have an account poseidon in our testing environment. The les poseidon.a and link.o, in which the data structure of the two programs NEPTUN and POSEIDON is implemented, can be found in the directory /home/poseidon/lib, and in the directory /home/poseidon/include the include les required for the data structure are stored. Figure 13 shows a Makefile by means of which a sample program with the name netout.c can be compiled. This Makefile can be used as a pattern for writing own Makefiles. HOMEPATH = /home/poseidon
n
INCLPATHS = -I. -I$(HOMEPATH)/include
n
LIBRARIES = $(HOMEPATH)/lib/link.o $(HOMEPATH)/lib/poseidon.a CC = CC CPPFLAGS += $(INCLPATHS) CFLAGS += -g LDLIBS += -lm -lrwtool
netout: netout.o $(LIBRARIES) $(LINK.c) netout.o $(LIBRARIES) -o netout $(LDLIBS)
Figure 13:
Makefile
for a testing environment 15
The sample program in gure 14 shows a pattern, in which way algorithms for the analysis of Petri nets can be implemented using the data structure explained here. First, in the example a project with the name Project.prj is loaded. Afterwards, the program searches in the projects list of all graphs for a net with the name Net1, and if such a net exists the analysis algorithm implemented in the program is applied to this. " "
"
#include Graph.h #include Net.h #include #include
"
int main() String path = /home/poseidon ; String projectName = Project.prj ; String netName = Net1 ;
f
"
"
"
" "
"
// Load project ifstream input(path + / + projectName); if (!input) baseError( File open ); Project project = Project::loadFrom(input);
""
"
"
// Search for net BaseGraph graph = project->first graph(); while (! (graph->isMemberOf( Net::desc()) && graph->name == netName)) graph = project->next graph(graph); if (!graph) baseError( Net not found ); Net net = (Net)graph;
"
"
// Analyze net
g
Analyze net and show results
Figure 14: A pattern for using the data structure
4.1 Sample program: Displaying a net
The sample program in gure 15 displays the vertices and edges of a net on the screen. Here, the macros Forall places and Forall transitions are used to traverse all places and transitions of the net, respectively. The access to the attributes of the classes, as for example name, are usually not encapsulated. 16
The documentation of all methods and attributes of the data structure can be found in the internet (http://www.uni-koblenz.de/poseidon/). According to the scheme of the sample program in gure 15 and with the aid of this documentation, nets edited by NEPTUN or POSEIDON may be transformed into those data structures required for user de ned analysis algorithms. :::
Includes necessary for loading nets : : :
int main()
f
:::
Load project and search for the net : : :
// Display the net Place place; Forall places(net, place) cout start vertex(); Vertex end = edge->end vertex(); cout
