PETRI NETS GROUP PROJECT

REPORT 1
Edwin Chung
Tim Kimber
Ben Kirby
Will Master
Matthew Worthington
Supervisor: Dr W. Knottenbelt
Submission Date: 26 January 2007

1
Contents
1 Introduction 4
1.1 Petri Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 PIPE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Project Development . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Software Integrity under Multiple Developers . . . . . . . 4
1.2.3 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Specification 5
2.1 Bug Fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Immediate transitions are not given any preference over
timed transitions . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Simultaneous firing of tokens via the same channel . . . . 6
2.1.3 Random null pointer exception generated while saving af-
ter running an analysis module . . . . . . . . . . . . . . . 6
2.1.4 Infinite while (!(isEmptySet(chj))) loop in the invariant
analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.5 Null pointer exception . . . . . . . . . . . . . . . . . . . 6
2.1.6 Border of an annotation . . . . . . . . . . . . . . . . . . . 6
2.2 Code refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Scope of work . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Additional changes . . . . . . . . . . . . . . . . . . . . . 8
2.2.4 Anticipated outcome . . . . . . . . . . . . . . . . . . . . 9
2.2.5 Note on testing . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Testing Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4 Documentation . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Reachability Graph Functionality . . . . . . . . . . . . . . . . . 15
2.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.4 Documentation . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Additional Zoom Functionality . . . . . . . . . . . . . . . . . . . 19
2.5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 Anticipated outcome . . . . . . . . . . . . . . . . . . . . 19
2.5.3 Scope of work . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Specification for improving options functionality and usability . . 22

2
3 Responsibilities 22
3.1 Will Master (tm106) - Team Leader . . . . . . . . . . . . . . . . 22
3.2 Ben Kirby (bmk06) - Team Secretary . . . . . . . . . . . . . . . . 23
3.3 Edwin Chung (xsc02) . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Tim Kimber (tk106) . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Matthew Worthington (mjw106) . . . . . . . . . . . . . . . . . . 23

4 Schedule 23

5 Conclusion 25

3
1 Introduction
1.1 Petri Nets
Petri nets are a popular graphical way of modelling concurrent
systems such as communications protocols, multiprocessor comput-
ers and a growing variety of real world scenarios. With Petri nets it
is possible to assess the correctness of systems - for example by ver-
ifying that the system cannot deadlock or result in buffer overflows.
Stochastic Petri nets extend ordinary Petri nets by incorporating
time. This allows designers to use the same formalism to reason both
about the correctness and the performance of systems.

Although there are many Petri net tools available (please refer
to website1 ), in the majority of cases the actual functionality of the
software is limited to the imagination of the programmer. PIPE2
attempts to break these limitations through the construction of a
Petri net editor and animator capable of supporting the arbitrary
run-time extension of its analysis which would be powered by user-
designed modules.

1.2 PIPE2
1.2.1 Project Development
The Platform Independent Petri net Editor (PIPE2) is an open
source framework for Petri net research. The project is an ongoing
development sustained by the continuous collaboration of successive
years of Imperial College London Computer Science students and the
open source community at large. Due to the fact that the software
has remained open source, contributions to this project have come
from all four corners of the globe. The development is being pushed
forward through the use of the Java platform and updates are moni-
tored through the use of CVS and specifically for Imperial students,
Eclipse (an open source windows development enviroment).

1.2.2 Software Integrity under Multiple Developers

CVS (Concurrent Versions System) is a tool used by many software
developers to manage changes within their source code tree. CVS
provides the means to store not only the current version of a piece of
source code, but a record of all changes (and who made those changes)
that have occurred to that source code.
1 http://www.informatik.uni-hamburg.de/TGI/PetriNets/

4
 Therefore, it was a logical step for the initial developers to manage
this project under CVS and has made version control much simplified.
Through Eclipse, this group is continuing in their footsteps making
the minor releases throughout the projects life cycle straightforward
and therefore highly beneficial.

1.2.3 Outlook
Over the last five years the project has come in leaps and bounds
through the dedicated effort of small groups of students for short
periods and a few developers that have continually pushed its lim-
its. Nevertheless, as a result of the fluctuating levels of activity sur-
rounding the project and the constantly evolving group of software
developers, the code remains imperfect.

Some of these imperfections result from such a diverse group of

contributors developing a single piece of software which naturally
leads to shortfalls in the object orientated division of code. This will
hopefully be addressed this year through a focused remodelling/re-
factoring of the code. Likewise, the rapid development from so many
angles means that comprehensive testing packages simply have not
been developed. Therefore, these issues will form a key part of this
year’s Petri net group project in an attempt to safeguard the soft-
ware’s future development.

Nevertheless, as a group we feel strongly that future proofing the

software is far from the only foot print we would like to leave behind.
We have therefore decided that to focus simultaneously on three key
areas: fixing the outstanding bugs in the inherited version of the soft-
ware, providing zoom functionality and introducing the reachability
graph.

2 Specification
2.1 Bug Fixes
2.1.1 Immediate transitions are not given any preference over timed
transitions
2.1.1.1 Description

Immediate transitions are used to model activities that consume

negligible units of time when compared to other activities (timed
transitions) present in the model, e.g. bus arbitration compared with
bus use, therefore they should be given precedence over timed transi-
tions. However, this was not observed in the simulation of our model,

5
thus this problem has to be rectified to allow true representation of
the modelled system.

2.1.2 Simultaneous firing of tokens via the same channel

2.1.2.1 Description

When an extra token is added to P0 in GSPN sample net 3, both

tokens at P0 will be destroyed and recreated at P1 when T0 fires.
Only one token should be destroyed at P0 and recreated at P1 when
T0 fires since the weight of the arc connecting P0 to T0 and T0 to
P1 are both one.

2.1.3 Random null pointer exception generated while saving after

running an analysis module
2.1.4 Infinite while (!(isEmptySet(chj))) loop in the invariant anal-
ysis
2.1.5 Null pointer exception
2.1.5.1 Description

Error generated when you cancelled the creation of an arc while

it is still connected to a target.

2.1.6 Border of an annotation

2.1.6.1 Description

The border is not redrawn when its has been disabled.

2.2 Code refactoring

2.2.1 Motivation
Following analysis of the code and communication with the most
active of external contributors to the PIPE2 project, it has become
apparent that there is a strong need to make changes to the code of
the PIPE2 application to correct aspects of the system’s structure.
PIPE2 generally works well for most of the modelling and analysis
tasks required of it, and over the last two iterations - 2003/2004’s
MSc group project and 2004/2005’s MSc individual project - a wide
range of useful functionality has been added. As the code base has
expanded, its complexity has increased and there are clearly some
major inefficiencies in the management of data, repetition of common
processes and a lack of logical separation between classes providing
different functionality. While this undoubtedly reduces the efficiency

6
of the application to some extent, the unnecessarily complex code,
which in places fails to adhere to principles of object oriented design,
means that over time it will become increasingly difficult to under-
stand and extend the application.

We hope that by addressing many of these problems at this stage,

it will be much easier for future generations to extend the application,
ensuring its viability in the longer term.

Refactoring can be defined as the process of changing a software

system so that the external behavior is not significantly altered, yet
internal structure is improved. Refactoring is the process of taking
an object design and rearranging it in various ways to make the de-
sign more flexible and/or reusable. This broad definition accurately
describes the range of changes the team plans to make; our docu-
mentation will therefore use the term to describe this part of the
development work.

2.2.2 Scope of work

A number of key areas have been identified.
• The DataLayer class has many methods to manage the properties of the
data layer (what transitions, places and arcs are part of the data model)
as well as a lot of XML-oriented code to import a data model or to create
an XML file to preserve a model.
We plan to separate out all of the XML code from the DataLayer class
and create classes to manage the importing and exporting of XML files. A
DataLayerFactory class will be written to process an existing XML file as
input and create a DataLayer containing the proper model (currently the
DataLayer class uses its constructor to build a DataLayer object from a
stored XML file, or uses the method loadPNML). A DataLayerWriter class
will output the description of the model to an XML file (this is currently
done using the savePNML method in the DataLayer class).
• The DataLayer class has many methods that are used in the analysis mod-
ules (typically getting matrices or Petri net objects (these include, Place
and Transition objects, arcs and annotations), or the status of transitions
for a Petri net - i.e. which transitions are enabled for firing). However,
only a limited number of events change the model enough that there is
impact to the analysis. For example, when a model is created from an
XML file, the incidence matrices can be created once and reused until the
user changes the number of tokens at a place, or changes the number of
kinds of arcs, places or transitions. Aside from iterative simulation, all of
the analysis modules run on data that is static as far as the structure goes,
yet the analysis routines are all written to keep generating the incidence

7
 matrices repeatedly.
We will investigate ways of reducing unnecessary updates to the data
model used in the analysis modules, perhaps by developing methods which
can monitor when an impactful change has been made to a Petri net and
flag this up to the analysis module, which will only then update the model
(or parts of the model) it is using for the analysis.
• The code supports finding multiple methods in a Module if they have a
single parameter with a DataLayer object. There should always be one
called "run", since that is required to support the Module Interface. But,
if other methods are defined, they are also located and added to the tree.
Is this behavior exploited? If we can get rid of this feature, the calling of
the run method can be much simplified. (Without using reflection.)
• There is a lot of wasted effort in the initialisation code in general. Many
copies of the DataLayer object are created. The code also instantiates
each of the Module classes twice. We will log and remove all instances
of unnecessary initialisation using unit testing to ensure there is no wider
impact across the application.
• PIPE2 currently does not use the generics feature introduced in J2SE
5. Generics can provide several advantages: cleaner code, because fewer
casts are required; there is less ambiguity between containers, so code re-
views are simpler; and it offers the flexibility of dynamic binding, with
the advantage of static type-checking (and compiler-detected errors are
less expensive to repair than those detected at run time). PIPE2 invokes
numerous collections (ArrayLists of Place and Transition objects in par-
ticular), so introducing generics could significantly improve the code.
We intend to identify any areas which could benefit from this treatment
and implement generics.
• There is considerable inefficiency in how data is managed. For example,
the DataLayer keeps ArrayLists of Place and Transition objects, which
are generated by the analysis modules. There are numerous places where
arrays are generated only because the length of the array is required,
whereas a method which only returns the length of the array require much
less overhead. In some cases, an array is called to get its length, then a
few lines of code later, another copy of the array is generated. It would
be more efficient to call the array once, get it’s length locally, then use
it as required. We would aim to look into the management of data, par-
ticularly in the analysis modules and the DataLayer class, and eliminate
these inefficiencies wherever possible.

2.2.3 Additional changes

It’s expected that during the course of making the changes above,
and investigating other functionality we’re planning to add, further

8
areas are likely to be identified where refactoring will be useful. While
we recognise the potential problems of straying too far from the initial
specification, we may extend or alter the specification if we find issues
that we feel are important to address, and estimate that we have
enough time remaining to make the changes.

2.2.4 Anticipated outcome

The changes will be largely invisible to the average user, although
we would expect at least a slight performance increase (for example,
from the final bullet point above, because there should be a reduc-
tion in unnecessary copying of matrices and other data). The most
important outcome, however, would be that the simplification and
increased elegance of the code would make it substantially easier for
future developers to understand the application’s structure, and to
edit and extend it without impacting existing functionality.

An improvement in the understandability of the code is not some-

thing that can be easily measured; however, it’s clearly important
that the team is able to provide some indication of the outcome of
changes made. In addition to the qualitative analysis of the code
(such as desciption of the refactoring work, and before and after UML
diagrams) there are metrics which could help quantify our effort.
• CAP
CAP is a Code Analysis Plugin developed for the Eclipse IDE2 . It provides
a range of metrics which aim to show the degree of dependency within
an application. Since a reduction in coupling is a primary objective of
refactoring, this could give a useful measurement of our succcess in this
area.
One key measurement provided by CAP is the number of dependencies
each package and each class has. We will monitor how these figures change
as the code base is changed over the course of the project. CAP also
provides a range of more complex measurements. We may include these
if we feel they provide any useful insights into the way the internals of the
application are changing as the refactorings are applied.
• Application profiling and Performance benchmarking:
Many of the changes aim to remove inefficiencies in the management of
data: preventing unnecessary generation of arrays or multiple instanti-
ation of objects, for example. As a result of making these changes, we
may expect to see some increase in the performance of the application, as
measured by application performance.
TPTP (Test and Performance Tools Platform)3 is an Eclipse foundation
2 ref: http://cap.xore.de/
3 ref: www.eclipse.org/tptp

9
 top-level project that includes a range of tools that can be used to profile
Java applications. TPTP provides a comprehensive suite of open source
performance-testing and profiling tools, including integrated application
monitoring, testing, tracing and profiling functionalities, and static-code
analysis tools.
Profiling an application typically involves observing how the application
copes under stress. A common way of doing this is to run a set of tests (for
example, JUnit tests) on a deployed application and use profiling tools to
record the application’s behavior. Metrics are produced including mem-
ory usage (how many objects are being created, and how big they are),
execution statistics (where did the application spend most of its time?),
and test coverage (how much of the code was actually executed during the
tests).
As well as providing quantitative analysis of the PIPE2 application before
and after refactoring, TPTP should help identify areas that need atten-
tion. For example, using TPTP, it’s possible to identify the percentage
of methods called in a class, which may bring to light any redundant
functionality.
• Cyclomatic complexity:
Cyclomatic complexity is a measure of path complexity. By counting the
distinct paths through a method, this integer-based metric aptly depicts
method complexity. In fact, various studies over the years have deter-
mined that methods having a cyclomatic complexity (or CC) greater than
10 have a higher risk of defects.
A few open source tools available to Java developers can report on cy-
clomatic complexity. One such tool is JavaNCSS, which determines the
length of methods and classes by examining Java source files. What’s
more, this tool also gathers the cyclomatic complexity of every method in
a code base.
• NCSS:
NCSS stands for Non Commenting Source Statements. An NCSS score
is equivalent to counting ’;’ and ’{’ characters in Java source files. This
gives a basic but potentially valid measuremet of code complexity which
may be worth documenting on a class by class basis. Of course, with
additional functionality being added to PIPE2, it is unfair to compare
the NCSS score for the entire application before and after the team’s
work. JavaNCSS (see c above) provides NCSS measurements in addition
to cyclomatic complexity.

2.2.5 Note on testing

The main aim of refactoring is to improve the quality of the code
without affecting functionality. As each refactoring is made, we will
be using the test suite that we’ve developed to ensure this is the case.
This means there will be no distinct testing period at the end of the

10
refactoring work - testing will be incorporated into each individual
change and carried out with every update that’s committed to CVS.

2.3 Testing Suite

2.3.1 Motivation
PIPE2 is a very successful application (though not perfect, see 2.1
- Bug Fixes). However, having been developed in three bursts within
the assessed project setting, it has evolved a rather impenetrable code
base. We, the fourth generation of PIPE2 developers are faced with a
tricky task just to understand how the application works. As earlier
project reports acknowledge, design principles are scarce, with many
classes being tightly coupled and lacking well-defined responsibilities
(see Refactoring). User interface code is mingled with business logic,
which in turn mixes with data loading and saving.

The second problem the tangled code gives rise to, having gained a
working appreciation of PIPE2, is making changes without breaking
the existing functionality. It seems unavoidable that new bugs would
be introduced. At best this would slow down development while
these bugs are tracked down and fixed. At worst, if a bug occurs in
a function that is logically remote from the story being developed,
it may go entirely unnoticed. This is highly undesirable, especially
given that PIPE2 is an open source project with people in the Petri
nets world who both use it and sometimes get involved in further
development.

To address these issues of code complexity and maintainability we

propose to introduce an automated testing framework to the project
(currently no tests exist within PIPE2). A well written suite of auto-
mated tests would allow developers to refactor and add to the code
with confidence that new bugs were being kept to a minimum. Over
time, this should allow faster, better designed improvements to the
application. Another important benefit of automated testing and a
continously integrated build is that testing and bug fixing is spread
over the life of the project, rather than being concentrated into the
period just before release.

2.3.2 Concept
The test suite should contain two types of test: high-level func-
tional tests and unit tests.

2.3.2.1 Functional Tests

11
 The functional tests should exercise the application at the user
interface level, without making any assumptions about the underlying
implementation.

As an example, consider the user activity of adding a new place

to a Petri net in PIPE2. This involves two actions:
1. Change to Add Place mode
2. Click on the drawing area at the location you want to add the place.

A functional test to confirm that this works, must determine that

the sequence of actions:

Click button Place mode -> Click drawing area at (x,y)

results in a circle appearing at (x,y), with a text label. This cannot

be proved by checking whether some sort of Place object has been
created within the code. Finding such an object may or may not mean
that the circle is visible, so the test is invalid. It also ties the test to
the implementation, so that a change in the code which removes the
particular Place object being checked will cause the test to fail, even
though the circle may still be being drawn just as the user wants. The
functional tests then should only concern themselves with changes to
the user interface components.

Running functional tests can be time consuming since the user

interface actions are extremely slow in comparison to most of the
underlying data processing. Therefore, it is important to keep test
scripts to a sensible length and only include those actions that are
essential to test the function in question.

2.3.2.2 Unit Tests

12
 Unit tests should exercise the code at the class level. Ideally all
non-trivial (non ’getter’ or ’setter’ methods) should have a test writ-
ten to check their correct operation. The test class should instantiate
a copy of the class under test, call the relevant methods and check
the output. Just as for the functional tests the unit tests should be
independent of the implementation within the class, only checking
the interface. Also, every test should be independent of every other
one, so all tests should ’clean up behind themselves’ and not assume
anything about the outcome of a previous test.

2.3.2.3 Test Coverage

The first priority in terms of coverage is to write functional tests

for all core user functionality. This will provide the main ’safety net’
to catch bugs that break the application in a serious way. The first
task will be to generate a list of all the functionality that needs to
be tested. Test coverage can then be measured agaist this list. The
target is to achieve 100% coverage of core functionality. An extension
to the functional testing would be to review the granularity of the
tests and add more detailed ones if they would be useful.

Second priority, but still fairly essential, will be to write unit tests
for all new classes and all revised methods within existing classes. i.e.
unit test all code that we ’touch’ as we go along. Third priority, and
quite a luxury item, would be to write unit tests for as much of the
remaining code as possible, starting at a high level of logical abstrac-
tion and then going into finer granularity. Tools exist to analyse unit
test coverage and we will investigate using one of these to provide a
measure of progress.

2.3.2.4 Testing and CVS Commits

The PIPE2 code base is managed within a CVS repository. In

order to keep the code as free from bugs as possible, developers should
be sure to test their working copy thoroughly before committing to
the repository. In the early stages of the project, this will have to
take the form of manual testing of the main functionality. As the
test suite is built up though, the automated testing can take on more
and more of this responsibility. It will be important for developers to
incoporate a test run into their update-edit-test-commit cycle, and be
sure their code passes all the tests before submitting their changes.

2.3.3 Technologies
2.3.3.1 JUnit

13
 The test suite will be built using the familiar JUnit open source
library (http://JUnit.sourceforge.net). JUnit provides test and test-
suite classes that can be extended to test specific application classes.
The JUnit test runner provides detailed information about any failed
tests and what caused the failure.

2.3.3.2 Abbot

Tests requiring behaviour of GUI components to be checked will

be written using another open source tool, Abbot4 . The Abbot li-
brary extends the functionality of the java.awt.robot class to provide
means of directly controlling GUI components, and asserting the out-
come of user actions. Abbot tests can also be written as xml scripts,
and Abbot comes with a script editor tool which can record actions
directly from the application under test.

2.3.3.3 Ant

A possible extension to the PIPE2 testing would be to provide

an Apache Ant5 build script for PIPE2. Running the test suite and
the build using Ant would allow greater flexibility (e.g. separating
functional and unit test runs would be trivial, as would setting up
HTML reports of the test results). An Ant build script would also
provide PIPE2 developers who prefer not to work in Eclipse (the
recommended IDE) with a straightforward way of building, running,
testing and documenting the application.

2.3.4 Documentation
The main documentation to be produced will be:
• A description of the essentials of the framework, and how and when to
run the tests
• The functional test list, and coverage

• The unit test coverage

It is worth noting that the tests themselves will provide a valu-

able form of docmentation for the application. The test suite should
provide a concise set of examples of how each part of the code should
work, highlighting important edge cases. In this regard, clear failure
messages and well named tests are important.
4 http://abbot.sourceforge.net
5 http://ant.apache.org/

14
2.3.5 Summary
2.3.5.1 Essentials
• User functionality catalogue
• 100% Functional test coverage
• 85% Unit test coverage within new classes

2.3.5.2 Possible Extensions

• Unit testing of existing classes
• Ant build script

2.4 Reachability Graph Functionality

2.4.1 Motivation
The reachability graph is an obvious extension of the work that
has already been done on state space analysis and would naturally
complement the information provided on boundedness, safeness and
deadlocks. The reachability graph, a commonly sought after tool
when analysing the behaviour of a stochastic system modelled with
Petri nets, provides a visual representation of all the net’s possible
firing sequences. The states therefore represent the current state of
the nodes and the transitions between them indicate particular (sin-
gle/multi) transitions firing. The example above clearly illustrates
the close relationship between the net and the graph, while empha-
sising that each presents and emphasises different aspects of that
same information.

The graph’s description immediately signals interesting obstacles

and some obvious limitations. First, time and memory requirements
for exploring a reachability graph will be at least proportional to
the number of reachable markings, implying that we shall have to
restrict the graph to moderately small sized nets. Unbounded nets
will theoretically have infinite state spaces which cannot be repre-
sented in a complete state space model. This will introduce the need
for states that represent unbounded locations in the net, transform-
ing our reachability graph into coverability tree. Deadlocks must be
treated if we establish goal states in depth searches of state space.
The tip of the ice-berg suggests this should be an interesting chal-
lenge.

15
2.4.2 Concept
The following steps broadly outline the development route of this
new aspect of the software.

2.4.2.1 Select Algorithm

First key stage is a sensible choice of algorithm, dozens of which

have already been clearly defined and documented ranging from sim-
ply breadth searches to heuristic, cyclic and linear temporal logic
explorations of the state space. Attention will be focused on algo-
rithms which take advantage of the relative small size of the nets
(10,000 node limit) which PIPE2 imposes on the user for possible
speed and memory advantages. Incorporating both unbounded and
bounded nets into the same state space algorithm is also of primary
importance, hence attempting to maximise the potential scope with
which it would be capable of finding viable solutions to the question
of both reachability and converability.

2.4.2.2 Implementation of Search

Implementing the state space generator within the data layer of

PIPE2 and carring out at least preliminary tests to ascertain its com-
plete integration and viability both in terms of time constraints and
correctness will be a key stage in this specifications lifecycle. With the
GUI requiring minimum modifications under the state space analysis
option, undivided attention may be placed on securing a fast, reliable
and efficient generator.

2.4.2.3 Translation of Representation

16
 Translate the initial representation of the code into the .dot for-
mat that can then take advantage of Graphviz’s engine. This stage
should require a parsing of the data structure produced in the pre-
vious stage into a format that can be imported and manipulated via
Graphviz. The dot format employed in Graphviz is fairly explicit and
basic representation of both the state names and corresponding tran-
sitions which naturally can incorporate general labelling. Therefore
in the development of the previous stage, data structure choices will
be made both based on efficient information storing as well as the
necessities of the subsequent conversion.

2.4.2.4 Incorporate Graphics

Graphviz and Grappa, an adopted Java plug-in, will be incorpo-

rated under the GNU licience for providing the means of straight-
forward integration of the generated reachability graph. This will
provide the means of generating a graphical representation of the
reachability graph within the state space analysis GUI of PIPE2. The
graph will be formatted in Graphviz style which is both clear and of-
fers an automated means of drawing bubble diagrams well suited to
state space representation.

2.4.2.5 Additional Analysis Figures

The reachability graph will extend the tangible data with which
the user may evaluate a particular net. This will include performance
figures outlining average token numbers and firing rates for individual
states. These figures will offer the user additional information with
which more insightful judgements may be made with respect to the
current Petri net.

2.4.2.6 Testing

With the introduction of any new features to a piece of software,

exhaustive testing will be required although this will naturally overlap
with the general test libraries that are also in development. The
testing classes will be developed hand in hand with functionality and
will remain in the petri testing libraries for future developers.

2.4.3 Technologies
2.4.3.1 Graphviz

17
 Graphviz is a powerful open source software capable of represent-
ing structural information as abstract graphs and networks. It uses
a basic text format input (.doc files) to generate various format out-
put files which can be immediately integrated and simply displayed
through the PIPE2 GUI. It should be noted though that this will not
permit manipulation of the actual graph or tree. Nevertheless, this
an area of mounting interest and shall be kept in mind throughout
the development.

2.4.3.2 Grappa

Grappa provides a substantial library of Java classes which are

already able to take advantage of Graphviz’s tools and in additional
provides some useful graph manipulation functions. Nevertheless, it
should be noted that its inclusion has been problematic for a number
of developers and therefore is being treated with some distance.

2.4.4 Documentation
Documentation will be produced outlining:

• User guide for the newly introduced functionality

• Limitations of the product
• Potential future improvements/developments

2.4.5 Summary
The development of reachability graphs as an extension for PIPE2’s
functionality is an important piece of the jigsaw puzzle. The PIPE2
user base is rapidly expanding and it is fundamental that developers
responsed to the various needs of the users. This particular arm of
the development is capable of both taking advantage of the current
analysis techniques in place while providing the user with additional
information and insight into the net in question.

2.4.5.1 Essentials
• Fully working Reachability Graph
• Additional Functions

2.4.5.2 Possible Extensions

• search optimisation under various scenarios

18
 • a state space representation that provides interaction options similar to
those offered for the petri net which offers interesting possibilities for mod-
ification and regeneration of a new net but is beyond the scope of this years
development.

2.5 Additional Zoom Functionality

2.5.1 Motivation
The PIPE2 application allows users to draw large and complicated
Petri nets - a particular example is the Courier Protocol example net -
and such nets can stretch beyond the size of the application’s viewing
pane. Currently, the only way to view the parts of the net that are
off-screen is to scroll around the pane. However, users would benefit
from (and, indeed, have suggested) the addition of a zoom function.

Zooming out would allow users to more easily get an overview of

the model. Zooming in would be benificial when looking at sections
of the net in detail, or to examine a particularly complicated section
of the net, for example containing multiple crossing arcs.

2.5.2 Anticipated outcome

A functional and tested zoom function should be fully integrated
into the PIPE2 GUI. Users will be able to zoom in on sections of the
model by up to 400% and zoom out to a minimum of 20%. Users will
also be able to zoom to ’Fit Page’, meaning the model will be scaled
to fill the viewing pane. These values and options have been chosen
as they appear to be standard on many applications.

There will be several ways of choosing and applying the magnifi-

cation. Firstly, new buttons will be added to the toolbar.

19
 These example buttons are taken from Abobe Acrobat. From the
left, they represent:
• Zoom In: clicking this zooms in by 20%
• Zoom Percentage: user can specify magnification to zoom to by typing
or selecting a value from the option selectbox. Values will be in sensible
increments (see dropdown graphic below) with an option for ’Fit Page’
• Zoom Out: clicking this zooms out by 20%
• Zoom Select: works like ’Select’. Cursor becomes ’target’ when in drawing
pane, and user can click and drag a box on the pane to select a section of
the model to Zoom into. Selection zooms to fit page or to a maximum of
400%

All zoom options apart from Fit Page and Zoom Select will zoom
on the co-ordinates at the centre of the model currently filling the
drawing pane. Zoom Select will zoom on the co-ordinates at the
centre of the selection box. Fit Page will zoom on the centre of the
entire model to the nearest 1% so that it fills the current size of the
drawing pane.

Users will also be able to select a Zoom magnification from the

application’s dropdown menu. This will look similar to the following
graphic:

After selecting a zoom magnification, the Petri net or selection of

it will be redrawn in the main drawing pane of the application. The
graphics and text of the model will have been redrawn to the scale
determined by the magnification rate. The aim is that users will still
be able to create and delete Petri net objects, animate their model

20
and scroll around it at any magnification. All other functionality
must remain the same.

The Help functionality will be updated with information on how

to use the Zoom function.

2.5.3 Scope of work

The modifications to the source code should be able to be achieved
using the packages currently used, specifically the Graphics and Graph-
ics2D classes of the AWT package. Indeed, some comments and data
members in the code seem to suggest that some work has already been
done by previous project teams on functionality to iteratively redraw
the Petri net model to a different scale, using the scale() method of
Graphics2D and a bespoke repaint() method. The first task will be
to determine what exactly has been done and can be used, to ensure
no code is duplicated.

At the outset it appears that much of the work for this function-
ality will involve augmenting classes within the pipe.dataLayer and
pipe.gui packages, which are used to paint the objects of the Petri net
in the drawing pane according to user input. New classes will also
need to be added to handle Zoom actions. So the next task will be
to study the current process for drawing objects in the application
and the current UML diagram, and then determine what additional
classes and methods need to be added. The team member will have
to determine how to achieve the following:
• when a zoom magnification is selected, each object in the net is redrawn
to the correct scale, and the view centred on the correct co- ordinates
• any new objects created with that magnification selected are drawn to the
scale previously selected
• the new buttons are created in the toolbar and clicking them initiates the
correct action. Relevant Alt text should also be added
• the new dropdown options are added to the dropdown menu and clicking
them initiates the correct action

An updated UML diagram will be designed in the process of de-

termining these changes. Once the design is complete, the new UML
diagram can be used as a template to start coding. Coding will be
done in Eclipse 3.2, so that ideally the new test suites.

21
2.6 Specification for improving options functionality and
usability
Many options that would be useful to specify are defined all over
the code and cannot be changed dynamically. We plan to implement
a single properties file with all of the options in it. These options
could include:
• arcs curved / straight by default
• colours of active transitions (red is difficult to see for some users)

• annotations text size, font, colour

• whether grid markings are included in exported files by default

It would also be much easier if this single file had a series of en-
tries starting with "module.class.whatever" that defined the analysis
classes to load. For normal use within Eclipse, we intend to have the
options file within the normal src directory structure. For people who
want more flexibility (normally running from a jar file, for example),
we could enable a parameter on the main class that contains the lo-
cation of the option file, making it possible to override the defaults
stored in a jar file. This would give us a single Properties object that
could be widely available.

Additionally, it would be appealling to extend the GUI to incor-

porate this, i.e. a preferences dialogue box opened via the menu or a
button.

3 Responsibilities
3.1 Will Master (tm106) - Team Leader
Will has spent time investigating the refactoring of the PIPE2
application. The resulting part of the specification is based on input
from Dave Patterson (a software engineer working in the US who
has a good knowledge of the PIPE2 application, and is an active
commenter and contributor to the project).

Will has also looked into a number of Eclipse plug-ins which can
measure performance and provide indications of the complexity of
Java applications. This should help us to quantify the effectiveness
of the refactoring work the group plans to undertake.

22
3.2 Ben Kirby (bmk06) - Team Secretary
Ben has so far spent time investigating the addition of zoom func-
tionality to the application, examining existing code and deciding on
what new functionality should be introduced. Ben will continue to
work on this, and will also be refactoring code along with the rest of
the team.

Ben is also responsible for producing agendas and minutes of team

meetings when necessary, and compiling the group logbook.

3.3 Edwin Chung (xsc02)

Edwin has spent time finding out how to gain access to the official
PIPE2 website so it can be updated in the future. He has also looked
into existing bugs documentations and external contributions mainly
from Dave Patterson and Pere Bonet. As Pere has not been using
sourceforge CVS repository, Edwin has done some research on how to
incorporate his code and resolve any incompatibilities with the latest
version of PIPE2. Details can be found in the bug fix and integrating
other contributions sections respectively

3.4 Tim Kimber (tk106)

Tim has investigated and set up a testing framework for PIPE2.
Testing in PIPE2 is intended to provide a stable platform for revisions
and additions to the code to be based on, and promote good design.
Tim will also be working on some of the refactoring tasks and on the
zoom functionality.

3.5 Matthew Worthington (mjw106)

Matthew has investigated and set up an online wiki for the group
outlining the development of the project (http://pipe2.pbwiki.com/
with password: ”imperial”). He has researched reachability graphs
and coverability trees with particular focus on the various algorithms,
and has tested possible graphical interfacing libraries/packages, as-
sessing their feasibility with respect to PIPE2. Finally, Matthew has
put together this report based on individual contributions for core
specifications.

4 Schedule
The group has put together a fairly comprehensive and individ-
ually detailed framework in which the major milestones of PIPE2’s
yearly development have been lain down. Estimations of the time

23
24
commitments necessary have been made based on the research car-
ried out up to this point, as well as past project development experi-
ence. The schedule not only incorporates research and development,
but sets aside significant time for both testing and the compiling of
the intermediate and final reports. Naturally, one is obliged to accept
that potential complications and/or new routes may come to light in
the weeks ahead. Although these cannot be anticipated, this group
has taken the necessary steps in setting out a suitable schedule which
both allows for these obstacles and provides the flexibility for incor-
porating essential objectives that are feasible within the constraints
of the project’s own specifications.

5 Conclusion
As the development of PIPE2 enters another year, one looks to its
future with both a sense of expectation and urgency. The overhaul
and additional functionality that have been proposed by this year’s
group are both a requirement for the longevity of the program itself,
as well as a long awaited response to the requirements of worldwide
users. It is the group’s belief that this years specifications closely
parallel both logical development path of this software package while
simultaneously incorporating specific areas of key interests individual
members and developers alike.

Having smoothly transitioned through the intial investigative stage

of this project, the group as a whole feels excited and confident about
the challenges that lie ahead. Both the scope and depth of the work
offers interesting avenues which we believe can be comprehensively
explored in the time frame imposed.

25