Concurrent software systems are growing increasingly large and complex; the risks associated with poor design and architectural choices are increasing as well. Building executable prototypes can help identify problems early and Colored Petri Nets are well suited to this purpose. This paper presents an approach to modeling reusable threadsafe passive entity objects in Colored Petri Nets, including public, private and static members, plus encapsulation and object composition.
Concurrent software systems are growing increasingly large and complex.
Consequently, the risks associated with poor design and architectural choices are
increasing as well. Assembling executable models can help to identify problems
early, and Colored Petri Nets (CPN) [
In spite of the fact that failure is increasingly expensive [
CPNs routinely depict concurrent software systems as tokens moving through
a series of operations (transitions), sequentially or navigating control structures,
analogous to dynamic flow charts. This paper introduces an approach to
modeling thread-safe objects, with an emphasis on object-oriented properties, such
as information hiding, providing a public interface of operations, and reusability
using CPN Tools [
This paper is organized as follows: Section 2 discusses related work, Section 3 introduces the modeling approach and Section 4 provides validation. Section 5 discusses conclusions and future work. 2
There is much literature devoted to the analysis of concurrent software with CPNs, and some related to object modeling.
Bauskar and Mikolajczak modeled objects using CPN’s hierarchical
capabilities [
This paper focuses on combining a number of object-oriented properties while modeling concurrent objects, such as information hiding, providing a public interface of operations, static variables and operations, and reusability, as well as modeling threads-of-control by which a client can animate passive entity objects as needed. 3
Constructed n a
a1 Person() setAge() age INT a ctrl a
n CPNs are not inherently object-oriented; however, the language primitives allow for almost infinite flexibility. To the extent that visual structure aids in conveying a designer’s intent, the following conventions, illustrated in Figure 1, are utilized for object modeling. The behavior otherwise modeled in Figure 1 is discussed in more detail in the next subsection. Input and Output Parameters are depicted across the bottom of their class diagrams, grouped by operation, and indicated by a double-line, as opposed to a single line. This includes threads-of-control, which determine the sequence in which modeled operations execute. Placing tokens into the input places, and retrieving tokens from the output places, is the means by which clients communicate with objects.
Operations comprising a class’ public interface are represented as transitions just above, and connected by arcs to, their respective inputs and outputs. Modeling operations as transitions works well for multiple reasons: transitions perform conversions, and CPN Tools’ hierarchical capabilities facilitate the creation of reusable objects that effectively enforce communication through the defined public interface and otherwise prevent access to an object’s non-public members. Instance Variables are depicted as places in the space above the public interface operations, or as objects as described herein, and are maintained by the public operations or by other internal functions. 3.2
Concurrency: No two operations can simultaneously access an object’s values. No operation can execute until the constructor has been initially executed. Furthermore, the constructor cannot re-execute after the object is created. Encapsulation: When used, a Person object’s data elements and functionality are encapsulated within the object, providing the client with only indirect access through the defined public operations. An example Employee object is depicted in the uppermost region of Figure 2.
Reusability: Any number of Person objects may be used within a CPN. 3.3
Figure 2 represents an Employee class definition, which features a composed object (Person1), a static variable (employeeCount) and associated static accessor method (getCount()), and a meta-variable (lock) used for synchronization. Employee also includes a constructor (Employee()) and a toString() operation. Given the relative complexity of this example, representing an operation with a single transition is insufficient. Treating these as atomic actions would result in the thread-of-control being released to the client prematurely, and potentially cause concurrency issues. Therefore, an inbound transition fires to initiate the behavior sequence, and a return transition fires when the process is complete, releasing the thread-of-control and return values at the appropriate time.
For simplicity, a minimal number of operations have been modeled; however, more could easily be added. For example, setAge() and setName() could be added, and connected to the otherwise unused equivalents in Person1.
CTRL
GA in INT setAge
In CTRL GA
out c+1 c ctrl c
ctrl
GC Num GC In in Emp's Outout CTRLOut INT CTRL n
ctrl
C'tor Employee In Age
INT
C'tor Employee In Name
STRING
E E In in Outout CTRL CTRL
Person Person1
CTRL emp ID INT lock
GN CTRL out setName STRING
In
GinN CTRL TS in id person TS toString out STRING ctrl str
CTRL
ctrl toString() toString
Return ctrl
ctrl
TSe TSe toString
In in Outout Employee
CTRL CTRL OutSTRING
str^" ID:"
^INT.mkstr(id)
Concurrency: The Employee class employs a more explicit locking mechanism.
When the constructor executes, a token is moved to the lock place. To ensure
mutually exclusive access, each instance-method must acquire the lock before
executing and return it when finished [
Reusability: Any number of Employee objects may be used within a CPN; additionally, each Employee object also re-uses a Person object. Static Behavior: The employeeCount place is effectively made static by defining it as a fusion place, facilitated by CPN Tools. Its initial marking is zero (simulating an initialized value), and is incremented each time an instance of Employee’s constructor is invoked. The value in the fusion place is shared by all instances of Employee; therefore, invoking the getCount() method in any instance of Employee will return the same value. 4
The limited length of this short paper permits only a brief description of the
validation carried out; however, tests were conducted to determine that each
modeled object’s operations execute correctly and that the synchronization
considerations ensure that there is no detrimental conflict for shared data. A unit
testing approach was employed, because it offers “the most effective means to
test individual software components for boundary value behavior" [
Person
TestPerson ageIn nameIn iPn oPut INT STRING CTRL CTRL a n ctrl
Create
Person 1 ToC ctrl a n CTRL setup Age setup
Name 25 INT "JohnDoe" STRING
CTRL INT CTRL CTRL STRING ctrl a ctrl n CTRL
in CTRL STRING CTRL n ctrl ctrl Invoke setAge ctrl sIentNvoakmee ctrl
ctrl Invoke toString a new Age 50 INT n
"JaneDoe" new Name
STRING
For clarity, the object under test, including the input and output places associated with its public operations, is depicted with bolder lines. The elements otherwise associated with the testing operations are depicted normally. Test Scenario: From left to right in Figure 3, a Person object is created, after which the setAge() and setName() operations are invoked. Finally, the toString() operation is invoked in order to observe the expected output. 5
Objects can be effectively modeled with CPNs, as shown in the examples above. The unit tests conducted confirm that they perform as expected. Modeling single- and multithreaded active objects is the logical next direction related to this short paper. Modeling inheritance would pose an interesting challenge as well.
This work is part of a larger project to model concurrent distributed applications and middleware. The ultimate goal of the overarching research effort is to provide a suite of executable architectural components and communications templates for a variety of software design patterns.