[For the PDF version of this reply, the figures or diagrams are interactive and dynamic.]
Net Elements and Annotations: A General-Purpose Visual Programming Language
I use graphics to organize JavaScript™ programs that use the Acrobat®/JavaScript API. Each graphic object represents a Petri Net element (place, transition, input or output) or represents more than one Petri Net element. Each graphic object is actually an annotation of the corresponding net element. However, if every graphic object maps to one and only one net element it may be used to generate the net element. And if a graphic object maps to more than one net element and the mapping is well-defined then it may also be used to generate the net elements. Standard Petri Net elements are represented by certain types of graphics: a circle is a place, a square or rectangle or line is a transition, an arrow from a circle to a square is an input and an arrow from a square to a circle is an output. Furthermore, a net element that is represented by a standard graphics has a set of de-facto standard annotations associated with it.
[The types of annotations in a "Standard Petri Net" are found in the PDF version of this reply.]
Carl Adam Petri described most of these ideas (including the types of annotations in a "Standard Petri Net" in his doctoral dissertation (Petri, 1966). He also applied the net elements and annotations to the description of several logic circuits, such as Figure 6.
Benefits and Challenges
A visual programing language may help a computer programmer develop computer programs (Menzies, 2002).
I have at least three reasons why I find net elements and annotations useful (advantages?).
Firs reason. The process logic can be created one element at a time. This means that a net can be extended by adding elements to the existing net (Petri, 1966). For example, a model of a controller can be divided into internal and external components. The internal component regulates the system. The external component interfaces with the environment by accepting input from the environment. Figure 1 is a Petri Net model of the internal component. It is possible to add a Petri Net model of the external component to the Petri Net model of the internal component by adding the appropriate places and transition (Figure 2).
Figure 1 A Petri Net Model of an Internal Component of a Controller (Halloway, Krogh and Giua, 1997)
Figure 2 A Petri Net Model of an Internal and External Components of a Controller (Halloway, Krogh and Giua, 1997)
Second reason. The codes associated with each net element can come from more than one “programming language” (Petri, 1973). They can come from a computer language such as JavaScript, COBOL, ADA and an assembly language. They can come from a Mathematical language such as algebraic symbols. They can come from prose encoded in English, German, French, Greek, Tagalog, Chinese, etc. Thus it may be used as a basis for communication and collaboration throughout the software or system development life cycle; and among different users, developers and stakeholders (Petri, 1973).
Third reason. It is possible to focus on certain graphics objects in the net and to write out the code or logic annotations for the related graphics objects. Consider a Petri Net model of a card game in Figure 3. If the arrow for the input P7 T4 is a standard graphics for an input in a Place/Transition Net and if m_7 is the mark for the place P7 then the logic annotation for updating the mark of the input place is m_7=m_7-1. If s_9^- is the status of the input then the logic annotation for updating the status of the input is s_9^-=((m_7<1) ?false:true).
Figure 3 A Petri Net model of a card game
I have at least three reason why I find the application of Petri Nets challenging (disadvantages?)
If there are too many graphics objects then it would be difficult to create or to read the net. The difficulty may be mitigated by taking a subset of the graphics and represent them using one, two or three graphics symbol (Noe, 1973; Petri, 1966). For example, if the Petri Net model of a card game in Figure 3 is considered to have too many graphic objects in the diagram, it is possible to combine some of the graphics and still maintain enough information to map the diagram into a computer program. Consider Figure 4, a Petri Net model of the same game found in Figure 3 with high-level graphics (Chionglo, 2016a).
Figure 4 A Petri Net Model of a Card Game using High-Level Graphics (Chionglo, 2016a)
In another example, the external components of the controller in Figure 2 can be combined to create a more concise graphic representation as shown in Figure 5.
Figure 5 A Petri Net Model of a Controller with High-Level Graphics for External Components
Finally, a mutually exclusive set of places or a mutually exclusive set of transitions may also be represented using a high-level graphics object (Chionglo, 2015).
Second reason. Even with standard graphics, it can be challenging to draw and position graphics especially if one expects the final diagram to be user- or reader-friendly. Some of the decisions for making a user- or reader-friendly diagram include: the proper layout of graphics objects, the appropriate dimensions of the canvas and shapes, the curvature of arrows, the type of arrow heads, the size and font of text, and the choice of colours for graphics and text.
Third reason. It is easy to create annotations of net elements in an orderly manner because every annotation is directly or indirectly related to a net element. However displaying every annotation along with the graphics of every net element may not be a good idea because there could be too much information presented in the diagram. For example, consider a diagram of a Petri Net model of a logic circuit which includes references to all property and logic annotations (Figure 6). [The original model included a test condition for the status of for every output (figure 31 on page 78 of (Petri, 1966)); the test condition was omitted here because it is equivalent to the original model for the given initial marking. Thus every output has one logic annotation for computing the mark of the output place.]
Figure 6 A Place/Transition Net with annotations – based on figure 31 page 78 of an English translation of Petri’s dissertation (1966)
One way to mitigate this challenge would be to identify the types of annotations used in the model, and to define graphics objects that include annotations of these types (Petri, 1966). Thus when a Petri Net diagram is composed of graphics objects from the definitions, the interpretation of these objects should include the “invisible” annotations. Figure 7 should be interpreted as a Standard Petri Net (see Annotations of a Standard Petri Net for the definitions); therefore, the logic annotation may be omitted from the diagram.
Figure 7 A Place/Transition Net – based on figure 31 page 78 of an English translation of Petri’s dissertation (1966)
Another way to mitigate this challenge would be to use form views of the annotations to complement or supplement the diagram(s) (Chionglo, 2016b; 2014). The views may be further divided into smaller views, and each view can be displayed and hidden.
References
Chionglo, J. F. (2016a). A Reply to “How to design a state flow for a react/redux flashcard game?” at Stack Overflow. Available at https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow.
Chionglo, J. F. (2016b). Two form views of a Petri Net. Available at http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf.
Chionglo, J. F. (2015). Reducing the number of net element graphics in a Petri Net diagram using high-level graphics. Available at http://www.aespen.ca/AEnswers/WjTpY1429533268.
Chionglo, J. F. (2014). Net Elements and Annotations for Computer Programming: Computations and Interactions in PDF. Available at https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF.
Halloway, L. E.; Krogh, B. H. and Giua, A. (1997). A survey of Petri Net methods for controlled discrete event systems [electronic version]. Discrete Event Dynamic Systems: Theory and Applications, Vol. 7. Boston: Kluwer Academic Publishers, pp. 151 – 190.
Menzies, T. (2002). Evaluation issues for visual programming languages. In S. K. Chang (Ed). Handbook of Software Engineering & Knowledge Engineering, Vol. 2 Emerging Technologies. World Scientific Publishing co. Pte. Ltd., pp. 93 – 101.
Noe, J. D. and Nutt, G. J. (1973). “Macro E-Nets for Representation of Parallel Systems”, IEEE Transactions on Computers, vol. C-22, No. 8, Aug. 1973, pp. 718 – 727.
Petri, C. A. (1973). Concepts of Net Theory. In Mathematical Foundations of Computer Science: Proc. of Symposium and Summer School, High Tatras, Sep. 3 – 8, 1973, pages 137 – 146. Math. Inst. of the Slovak Acad. of Sciences, 1973.
Petri, C. A. (1966). Communication with Automota [trans. C.F. Greene, Jr.]. Supplement I to Technical Report RADC-TR-65-377 (Volume I). Griffiss Air Force Base, NY: Rome Air Development Center, Research and Technology Division, Air Force Systems Command, Griffiss Air Force Base. Retrieved Aug. 31, 2011 from http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf.
