Modeling of high-level Petri nets requires continuous modifications to adapt to requirements changes. This ultimately leads to structural problems in models. Experiences from software engineering can be used to alter and improve Petri net models, especially if they are used as executables. In this contribution, we show how to apply refactoring to reference net models. For this purpose, we introduce bad smells found in reference nets and refactorings that fix the underlying problems. We present a refactoring tool that supports selected refactorings and is integrated into the Petri net editor and simulator Renew. We discuss how the results can be applied to other types of high-level Petri nets.
Refactoring is used in software development with textual programing languages and UML (Unified Modeling Language) modeling to improve software or model quality. It incrementally changes structure while retaining behavior. There is demand for such techniques because both software development and systems modeling require continuous changes that lead to declining software or model quality which is recognizable in shape of bad smells. Further reasons to refactor include preparation for future changes and enforcement of good practices.
High-level Petri nets combine Petri net modeling with textual programming. (Java) reference nets are high-level Petri nets that give up parts of the verifiability of Petri nets in exchange for the power of Java inscriptions and the capability to use nets as tokens. It is worth improving reference net models since they are executable and not only used for throw-away prototyping, but also in production software. Therefore, refactoring should be applied to reference nets.
In this paper, we give an overview of refactoring for reference nets. We describe a tool that supports our proposal on how to improve Petri net models without changing behavior. It is integrated into Renew and supports selected reference net refactorings.
Section 2 introduces reference nets, refactoring and bad smells. In Section 3, we discuss exemplary bad smells in reference net models. We compile initial classification criteria for reference net refactorings in Section 4. Section 5 is an excerpt of a first refactorings catalog. We describe a tool that supports a subset of the refactorings in Section 6. Finally, we present related work in Section 7 and discuss a generalization of our experiences in Section 8. 2
In this section, reference nets and refactoring are introduced.
2.1
Reference nets [
Inscriptions In Renew, places, transitions, and arcs can carry inscriptions. The inscription language is based on Java. Statically typed nets contain a declaration node in which all variables used in the net are declared with a type.
Inscriptions are evaluated during simulation. Unification is used to find a
variable assignment that satisfies expressions on transitions and arcs, as well as
types on places and in the declaration node. A transition is activated if such an
assignment was found. Renew’s unification algorithm is described by Kummer
[13, Sec. 14.2].
1 Reference net and Java reference net are mostly used as synonyms.
Synchronous Channels Channels for synchronous two-way communication in
colored Petri nets were introduced by Christensen and Damgaard Hansen [
Connection to Java Renew’s inscription language allows method calls to external Java classes. To call a net from Java, the net needs a stub class that translates method calls to channel calls. Stub classes are compiled to Java classes that provide not only the methods but also a constructor for net instances. Virtual Places A virtual place is a reference to a place within the same net, marked with a double outline. Virtual places can improve net readability as they can be used instead of long or crossing arcs. However, when using virtual places, a place’s preset and postset may not be identifiable at first sight. This can conceal dependencies within nets.
Net Components Net components [
Fowler defines the noun refactoring as “a change made to the internal structure
of software to make it easier to understand and cheaper to modify without
changing its observable behavior” [7, p. 53]. When used as a verb form (derived from
to refactor ), refactoring means applying refactorings. Thompson’s definition in
the context of functional programming is similar: “Refactoring is the process of
improving the design of existing programs without changing their
functionality” [
Both of the terms structure and behavior need further examination in this
context. Structure is not only dependent on the software itself but also on
documentation or features of the development environment that influence
programmers’ perceptions. It can thus be considered “dynamic” [
Software behavior often cannot be entirely expressed in terms of input/output
equivalence. When a Petri net of the program’s observable behavior at a sensible
granularity is considered, its reachability graph is an additional behavior
representation. Beyond that, behavior is heavily context-dependent: e.g. in real-time
systems, execution time constraints need to be preserved; in embedded systems,
energy and memory consumption play an important role [
Fixing programming errors is not refactoring as it purposely changes behavior. Program optimization preserves behavior but often worsens maintainability in exchange for performance improvements.
Refactoring is typically supported by software tools. 2.3
Bad smells (or code smells ) are symptoms of structural problems in software
artifacts that indicate refactoring opportunities. While the metaphor was
popularized by Fowler and Beck [7, Ch. 4], a general effort to create maintainable
code and eliminate bad practices predates them, e.g. Dijkstra’s “Go to Statement
Considered Harmful” [
Bad smells are no precise criteria. Fowler and Beck find human intuition to trump metrics [7, p. 75] but many development environments today emit warnings when presumed bad smells are found. 3
Our initial approach to collecting bad smells was applying Fowler’s and Beck’s bad smells for object-oriented software [7, Ch. 3] to reference nets2. Classes in object-oriented software loosely correspond to net patterns; objects correspond to net instances; methods correspond to net sections delimited by uplinks or downlinks to synchronous channels (subroutines ).
Then, we examined nets developed by students for occurrences of the initial set and searched for additional net-specific smells. If a net section raised questions in code reviews and its functionality had to be clarified, it possibly hinted at a bad smell.
A key advantage of high-level Petri nets when compared to pure textual
programming is their intuitive graphical representation. A common property
of many bad smells in Petri nets is that they worsen readability and thereby
reduce this advantage. We assume that net components that are based on [
In the following subsections, we present three exemplary bad smells that
occur in reference nets along with refactorings that can be applied to fix the
underlying problems.
2 This section and the following sections describe results of Max Friedrich’s bachelor
thesis [
Duplicated Code is the first bad smell for object-oriented software described by Fowler and Beck [7, p. 76]. It makes software hard to modify. They recommend unifying duplicated code, e.g. by extracting it into a method.
In high-level Petri nets, net structure and textual inscriptions contribute to functionality. The smell can be applied to both of them.
Since net elements can be arbitrarily arranged, duplicated net structure does
not have to be immediately recognizable. Net structure (and inscriptions, if the
structure consists of a single transition) can be extracted into subroutines with
Extract Subroutine [
Large Class [7, p. 78] is a bad smell in object-oriented software. Classes should only have a single responsibility and therefore be reasonably small. Large classes are harder to navigate and understand. They complicate change because a developer has to consider a whole class when making changes. Besides, large classes often contain hidden duplicate structures.
Large Class can be applied to nets as Large Net. Multiple boxes that mark related net sections often indicate that a net is too large. A rule of thumb says that a net should fit onto one screen page. Additionally, large nets have a negative effect on team productivity. Since there is no merge tool for reference nets under version control, only one developer should work on one net at a time.
Extract Net [
Murata describes how low-level Petri nets can be used to model data flow computations [17, p. 545]. In high-level Petri nets, it is possible to create data flow models that perform computations, since tokens can contain data. Thus, it seems natural to concentrate on data flow when creating high-level Petri net models, disregarding control flow. A net’s marking then implicitly contains control flow. In reference nets, control flow is further divided into all net instances’ markings as nets can arbitrarily interact with each other by means of synchronous channels. Unclear control flow can occur even when using net components because many nets need custom structures that are not covered by available components.
Explicating control flow is often worthwhile to improve readability. This especially applies when a large number of data tokens is involved or control flow is further concealed by virtual places and synchronous channels. Besides, explicit control flow tokens are useful in debugging to pin down a failure location.
Introduce Control Flow Place (Section 5.1) explicates control flow.
We propose the criteria featured in Table 1 to classify refactorings for reference nets. The attributes Number of nets, Net features, and Associated classes can be further summarized by the term Scope, as they describe the artifacts and structures that are impacted by a refactoring. Validation refers to the program life cycle phase in which the success of a refactoring’s application can be determined. When structures that depend on unification are modified, validation takes place at run time since unification is only available in this phase. The list of possible values for Purpose contains exemplary entries for maintainability improvement refactorings.
All criteria are orthogonal. For Net features, Associated classes, and Purpose, a refactoring may have more than one value.
Attribute
Possible values Number of nets single, multiple Net features inscriptions, net structure, name Associated classes none, Java classes, stub classes Validation compile time, run time Purpose enhance readability, enforce good practices, change interface, . . .
In refactoring catalogs, refactorings are typically divided into chapters of
related refactorings but not explicitly classified [
In this section, we describe three exemplary refactorings for reference nets.
Roughly following Fowler’s format [7, Ch. 5], each refactoring is presented with
a descriptive name, a short introduction, step-by-step instructions for manual
application (mechanics ), and an example. In addition, we classify each
refactoring by the criteria compiled in Section 1. The mechanics are purposely explained
in small steps. As manual application of refactorings is nevertheless error-prone,
a refactoring tool, as described in Section 6, could assume the responsibility of
performing the mechanics. Additional refactorings can be found in [
Adding an extra place between sequential transitions to explicate control flow can often significantly enhance readability.
Attribute Number of nets Net features
Value single net structure Associated classes none Validation Purpose run time enhance readability
Example In Figure 2, let queryWebService(·), webServiceSuccess(·), and webServiceFailure(·) be channels with each one uplink and only the depicted downlinks on transitions a, b, and c. The uplinks to webServiceSuccess(·) and webServiceFailure(·) belong to transitions that will only be activated if queryWebService(·) fired before. webServiceSuccess(·) and webServiceFailure(·) are alternative returns, i.e. if one of them fires, the other one is dead. Therefore, the transitions a, b, and c in the example are sequential in such a way that a is before b; a is before c; b and c are mutually exclusive.
In the first step, a place is added between a and b. Since b and c are alternatives, an extra arc is added to ensure that control flow tokens are consumed. Now, a single place explicates control flow between a, b, and c. If a channel name does not describe the channel’s purpose, it should be changed. This refactoring is similar to Rename method for object-oriented software [7, p. 273].
– Check if the new channel name is already used in the system. If it is and the channels could be mixed up (by developers as well as in simulation), choose a new name or perform these steps for the other channel. – Across all nets in the system, find all transitions with uplinks or downlinks to the channel. (In general, this step is not trivial since uplinks and downlinks are bound to channels at runtime using unification.) – For each transition with an uplink or downlink to the channel, copy the transition with all arcs and inscriptions and change the channel name3. 3 For channels with few uplinks and downlinks, the steps of copying transitions and adding extra places can reasonably be omitted. The channel names are then changed in-place. – Optionally, add one extra place to each of the original transitions’ postsets to check if the transitions fired. (Firings are observable because they produce tokens in the extra place.) – Change the channel name in all stub classes that refer to the channel. – Test the system. – Remove the original transitions and the extra places, then realign the new transitions to restore readability.
Example Figure 3 shows the net account [14, Fig. 3.18] in which the channel deposit(·) is to be renamed to store(·). Two transitions with references to the channel have been detected in the net. They are copied with their respective preset and postset, then the channel name is changed. Extra places are added after the original transitions. This process is repeated in other nets with references to the channel. After testing and ensuring that the channel with the old name is not used anymore, the original transitions with their incoming arcs and the extra places can be deleted. 5.3
When the name of a variable does not describe its contents, it should be changed. A specific characteristic of variable names in reference nets is that they should be short yet expressive to keep inscriptions short. A name like s for a string can be appropriate if there is only one variable of this type in the net section. Variable names can be reused throughout a net because the scope of a name is only one transition.
The refactoring can be applied to all occurrences of a variable name or to a part of them, e.g. when a general name is specified in only one net section. We describe only the variant in which all occurrences are replaced.
Classification See Table 4. If the net is statically typed, it can be determined at compile time if all occurrences of the old name were removed and if there were no typing errors. However, the syntax check cannot detect if an occurrence of the old name was accidentally removed or replaced with a different declared name. That is why the refactoring’s validation phase is run time.
Attribute
Value Number of nets single Net features inscriptions Associated classes none Validation run time
Purpose enhance readability – If the net is statically typed, add a declaration for the new name to the declaration node. – Replace all occurrences of the variable name in transition and arc inscriptions with the new name. – Run a syntax check and test the system. – If the net is statically typed, remove the old name’s declaration in the declaration node. Then run a syntax check and test again.
5.4
Table 5 shows the bad smells and refactorings from [
Application of Rename Synchronous Channel (Section 5.2) is guided by a wizard user interface. Since uplinks and downlinks are bound to channels at runtime, the refactoring cannot be executed without additional user input to select uplinks and downlinks that will be replaced. Figure 4 shows the refactoring’s application in the net account [14, Fig. 3.18]. Again, deposit(·) is to be renamed to store(·).
A user selects a transition with an uplink or downlink inscription in the editor and starts the refactoring by clicking a menu item or using a keyboard shortcut. In the first wizard step, the user enters the new channel name and selects the nets that will be searched for uplinks and downlinks to channels with the original channel name and number of parameters. The second step shows a table in which uplink and downlink matches can be marked for refactoring. The uplink or downlink from which the refactoring was started is always selected. Clicking a “Show” buttons reveals an uplink or downlink in its net pattern. The last step previews the changes in all nets but can still be undone. Net patterns are not saved until the wizard sequence is completed.
In the current implementation, the refactoring skips the steps of copying transitions and extra places since it can be sure that all possible matching uplinks and downlinks were offered to the user. References to channsls in stub classes are not yet included in the search. 6.2
Rename Variable (in the variant in which all references of a variable name are replaced; see Section 5.3) only spans one net and does not require fine-grained user input like Rename Synchronous Channel ’s match selection. In testing, we discovered that a wizard based implementation carried too much interaction overhead. Therefore, we experimented with an implementation based on inline text entry with live preview of changes.
An application of Rename Variable is shown in Figure 5. In a statically typed variant of account [14, Fig. 3.18], the variable amount is to be renamed to dollars. The refactoring can be started via a menu item or keyboard shortcut when an inscription containing a variable name is selected. In statically typed nets, the refactoring can also be started when no inscription is selected, offering all declared variables for renaming. After the variable selection, the inscription or declaration node changes into a mode where only the variable name can be edited. Other inscriptions containing the name are selected to clarify the refactoring’s impacts. As soon as the user starts typing a new name, all references are changed. Invalid names are declined with a red bordered input box. When a valid name is entered, pressing Ctrl+Return or clicking outside the text field finishes the refactoring.
If the net is statically typed, the refactoring modifies the variable declaration in-place and skips the steps of adding and removing extra declarations since it can be sure that all references were found. 6.3
In this section, the refactoring tool described in Section 6 is evaluated according to Fowler’s criteria for refactoring tools [7, pp. 400–406].
Technical Criteria The technical criteria are Program Database, Parse Trees, and Accuracy. The refactoring tool does not have a program database, as searching through reference nets is reasonably fast, even when many nets are involved. 1. Selecting the variable to rename
2. Inline editing started 3. Entered invalid name (keyword do)
4. Entered valid name However, much bigger systems are imaginable, in which case a database should be added to the tool.
Renew uses a JavaCC 4 generated parser to compile inscription strings into
executable objects. It does not emit parse trees and discards token position
information after parsing. Only in case of a syntax exception, token position
information is returned by the parser in terms of a token object attached to the
Java exception. Quickfix [
Accuracy is guaranteed for refactorings with compile time validation. For other refactorings, additional user input is required, which places the responsibility for correctly selecting matches that will be edited on the developer. Practical Criteria Speed, Undo, and Integrated with Tools constitute the practical criteria. Both searching through nets and editing nets is fast. By selecting a sensible search range, the developer can speed up search. Inline text editing with live preview of changes proved to be valuable in the Rename Variable implementation, as it makes changes instantly visible, which also contributes to speed. 4 https://javacc.java.net Undo support is provided in both implemented refactorings. The refactoring tool is well integrated into the Petri net editor Renew. 7
Sunyé et al. [
Models can be considered as graphs, which suggests that graph
transformation techniques can be used to refactor models. This has been explored in detail
for UML. Ehrig et al. [
Berthelot introduces Petri net transformations that preserve classical
properties, such as boundedness and liveness [
A first step to obtaining a better understanding on how to generalize refactoring could be adding support for more refactorings to the refactoring tool described in Section 6. In addition to reference nets, Renew supports other net types such as Feature Structure nets and Workflow nets, which require specific examinations regarding refactoring.
An analysis tool that detects presumed bad smells could be helpful in working with legacy nets. While smells like Large Net and Duplicated Inscription are easily spotted by assigning metrics (e.g. any net with more than 50 places and transitions could be considered a Large Net ), in-depth analysis is hard because reference nets are Turing complete. At first, a subset of reference nets could be considered for such a tool, before extending it to reference nets and including heuristics to detect bad smells. IDEs like IntelliJ IDEA5 tackle this problem by analyzing compiler output and defining properties and changes on higher levels of abstraction.
Other Petri net editors support net classes that implement a different set
of concepts with specific constructs. Each construct requires analysis for
refactoring, e.g. hierarchical transitions in CPN Tools6. Beside, different inscription
languages like C++, ML, or Lisp require different refactorings, even the latter
two functional languages [
After introducing reference nets and refactoring in Section 2, we describe three bad smells that occur in reference nets in Section 3. Two of the smells are applications of smells in object-oriented software to reference nets, while Unclear Control Flow is specific to nets. A solution for Unclear Control Flow is provided in Section 5, along with two renaming refactorings. The refactorings are classified according to criteria presented in Section 4. The renaming refactorings are supported by the refactoring tool for Renew that is described and evaluated in Section 6. We present related contributions in Section 7 and finally discuss the results in Section 8.
Refactoring cannot only be applied to reference nets and Renew, but also to other modeling techniques and tools. Future research should try to formalize refactoring to a sensible degree, putting a stronger focus on semantic aspects.