I am developing y_petri in Ruby. Currently, YPetri can handle rendering (the YPetri::Net class has a #visualize method, using Graphviz to draw a network), but not the GUI editing that you seem to have in mind. FYI, firstly, editing the graphical interface in Petri nets is less important than it seems.
The data language used is Ruby itself (more precisely, an internal DSL written in Ruby).
The main problem with Petri nets is that there are too many of them. YPetri trying to become a universal Petri net network with 1 kind of places (arbitrary type of labeling) and 4 basic types of transitions (time / timeless x stoichiometric / non-stoichiometric). In addition, there is a transition of the fifth type, a destination transition, which replaces the marking of target places with the return value of its function. I believe that this can be used to describe any dynamic system in general, being as mean as I could do it.
Pure Petri arcs are understood as relations between transitions and places (they relate to transitions in y_petri . I found that it is useful to be able to express relations between Petri network nodes (places / transitions) as well, rather than just arcs. For this purpose I use the Ted Nelson ZZ structure (ZigZag) mainly as a replacement for the relational database .
As for modeling (pure Petri execution), general hybrid Petri nets do not have a faster simulation method than the implicit Euler method (which I call the pseudo Euler). This is due to the fact that the Petri network can be used to implement a Turing machine, for which it is impossible to provide general acceleration.
If you want to work in Ruby, you can describe the Petri network this way in the y_petri or y_nelson DSL code. I do not provide conversion to XML, because I do not consider it higher than the original DSL. You could write such an export procedure, but I recommend that you use DSL instead.
Boris Stitnicky
source share