PETRI NETS GROUP PROJECT FINAL REPORT

Edwin Chung Tim Kimber Ben Kirby

Thomas Master Matthew Worthington

Supervisor: Dr W. Knottenbelt Submission Date: 19th March 2007

Contents

I INTRODUCTION AND PLANNING 5

1 Introduction 61.1 Petri nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 PIPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Developing the Specification, Planning and Project manage­ment 82.1 Working with an Active Open Source Application . . . . . . . . . 82.2 Familiarisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Arriving at the Specification . . . . . . . . . . . . . . . . . . . . . 92.4 Managing Project Tasks and Resources . . . . . . . . . . . . . . 102.5 Development Environment . . . . . . . . . . . . . . . . . . . . . . 112.6 Development Approach . . . . . . . . . . . . . . . . . . . . . . . 11

II DEVELOPMENT 12

3 Refactoring and Code Clean Up 133.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Bug Fixing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Integration of External Contributions . . . . . . . . . . . . . . . 143.4 Code Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4.1 XML and DataLayer Division . . . . . . . . . . . . . . . . 153.4.2 Matrix Instantiation . . . . . . . . . . . . . . . . . . . . . 163.4.3 Reflection and Class Loading . . . . . . . . . . . . . . . . 173.4.4 Data Mismanagement . . . . . . . . . . . . . . . . . . . . 183.4.5 Evalution of refactoring . . . . . . . . . . . . . . . . . . . 19

4 Zoom Functionality 214.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 Existing PIPE code . . . . . . . . . . . . . . . . . . . . . 214.2.2 Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.3 Successful Approaches to Zoom Implementation . . . . . 22

4.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.1 Design Decisions . . . . . . . . . . . . . . . . . . . . . . . 244.3.2 Geometrical Approach . . . . . . . . . . . . . . . . . . . . 244.3.3 Code Architecture . . . . . . . . . . . . . . . . . . . . . . 25

4.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4.1 PlaceTransitionObjects . . . . . . . . . . . . . . . . . . . 274.4.2 Arcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4.3 Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2

4.4.4 AnnotionNotes . . . . . . . . . . . . . . . . . . . . . . . . 284.4.5 Updating the JScrollPane . . . . . . . . . . . . . . . . . . 284.4.6 Click and Drag . . . . . . . . . . . . . . . . . . . . . . . . 294.4.7 User Interface to Zoom Functionality . . . . . . . . . . . . 30

4.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.5.1 Differences from the Specification . . . . . . . . . . . . . . 334.5.2 Key Metrics ­ Usability and Reliability . . . . . . . . . . . 34

5 Reachability Graph Functionality 345.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1.1 Background on Reachability . . . . . . . . . . . . . . . . . 375.1.2 Background on generating state space[12] . . . . . . . . . 38

5.2 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.1 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.1 Graphviz, Grappa and C . . . . . . . . . . . . . . . . . . 415.3.2 Code Architecture . . . . . . . . . . . . . . . . . . . . . . 42

5.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.4.1 Steady State Algorithm . . . . . . . . . . . . . . . . . . . 425.4.2 Random Access Files and Input Streams . . . . . . . . . . 46

5.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.5.1 Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.5.2 Dot File Formatting . . . . . . . . . . . . . . . . . . . . . 485.5.3 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . 485.5.4 Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.6 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6 Testing 516.1 Library Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2 Implementation of Testing Framework . . . . . . . . . . . . . . . 526.3 Petri­Net Specific Testing . . . . . . . . . . . . . . . . . . . . . . 536.4 Evaluation: Test Coverage . . . . . . . . . . . . . . . . . . . . . . 53

III EVALUATION AND CONCLUSIONS 55

7 Evaluation and learnings 56

8 Effectiveness of Scheduling and Group Organisation 57

9 Future Directions 579.1 Hierarchical Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . 579.2 Copy and Paste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619.3 Undo and Redo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3

Acknowledgements: Thanks to Dave Patterson for offering insight and ad­vice; to John Mocenigo at AT&T for allowing use of AT&T’s hosted GraphVizservice during project development; and to Dr William Knottenbelt for his sup­port as project supervisor.

4

Part I

INTRODUCTION ANDPLANNING

5

1 IntroductionThe aim of this project was to enhance an existing piece of software written fora 2002/3 MSc Conversion group project[3], and subsequently extended by MScstudents in 2003/4[1] and 2004/5[2]. The application, PIPE (Platform Inde­pendent Petri net Editor), is a Java­based editing and analysis system for Petrinets. It has been improved by eradicating bugs, refactoring code to make it moreefficient and understandable, and by adding two major pieces of functionality.

1.1 Petri netsPetri nets are a formalism for modelling concurrent systems, first defined by CarlAdam Petri in 1962. They allow correctness of concurrent systems to be verifiedusing well­defined, provable mathematical techniques and allow the behaviourof a system to be expressed both graphically and algebraically. They supportthe natural expression of such concepts as synchronisation and communicationbetween processes. The ability they provide to visualise the structure of asystem promotes greater intuitive understanding of what is being modelled.Petri nets have since been extended and augmented with additional behaviours,most notably with the addition of time data to produce Generalised StochasticPetri nets (GSPNs).

Petri nets are used in areas including software design, engineering and dataanalysis.

The building blocks of a Petri net are places, transitions, arcs and tokens.Places model conditions or objects. Places may contain tokens, which representthe value of the condition or object. Transitions model activities, which changethe value of conditions or objects. For example, firing a transition may destroy atoken at one place and create a token at another place. The interconnectednessof places and transitions is represented using arcs. Each arc has one and onlyone source, and one and only one target. If the source is a place, the targetmust be a transition, and vice versa.

A Petri net may or may not meet certain key criteria, which can providecrucial information about the correctness of the system it is modelling. Thereachability of a Petri net describes the possible states that can exist. Thiscould tell us, for example, whether the doors in a lift might open while the liftis moving. The liveness of a Net indicates whether transitions between differentstates are possible. A Net may, for example, reach a situation of deadlock, whereno transitions are enabled, or livelock, where a subset of transitions only areenabled and the system is stuck in a cycle. Finally, a Petri net that is boundedis known to stay within certain quantifiable limits; for example, in a 3­boundedNet we know that no Place will cotain more than 3 tokens. Unbounded systemsare obviously unpredictable and seldom if ever desirable, so Petri nets providea powerful tool to mathematically verify that a system is bounded.

6

Figure 1: Dijkstra’s Dining Philosopher’s problem

7

1.2 PIPEThe figure above shows a Petri net representing Dijkstra’s well­known DiningPhilosopher’s problem[4]. Places are shown by circles and transitions by rectan­gles, connected by directional arcs. The odd­numbered central places representthe forks ­ shared resources which each philosopher requires two of in order toeat. In its initial state, all even­numbered transitions are enabled and equallylikely to fire. If, for example, T2 was to fire, the tokens at P7, P8 and P9 wouldbe destroyed, and a token at P10 would be generated by transition T2. Thiswould have the effect of removing two resources (forks) from the central pool,thus limiting access by the other philosophers. If T3 were then to fire, the tokenat P10 would be destroyed and tokens at P7, P8 and P9 would be generating,returning the system to its initial state. This Petri net is bounded and safe(i.e. each place can contain no more than one token); however it is possible toreach a state of deadlock (indeed, this is the issue that the Dining Philosophersproblem serves to illustrate).

2 Developing the Specification, Planning and Projectmanagement

2.1 Working with an Active Open Source ApplicationPIPE has been downloaded over 7200 times and is in use around the world. Itis an active open source project on Sourceforge[5], with a number of contrib­utors, regularly reported bugs and a features wishlist. This implies a certainlevel of responsibility: much of our specification was based upon user feedback,and a substantial amount of time was spent cleaning up code (debugging andrefactoring) ­ not the most glamorous work but something we understood to beimportant to the longer term viability of the project. Working on a real­worldproject also meant that we had to ensure that any changes to the application’sfunctionality didn’t impact existing code or introduce subtle bugs; therefore thefirst thing we did was to introduce a suite of automated unit and functionaltests which could be run at any time to ensure that key parts of the applicationwere working as they should.

2.2 FamiliarisationMost major updates to the application have been made on an annual basis bygroups of students, who then left Imperial College. This meant that there weresome issues with continuation of knowledge: new groups come to work on PIPEwith no prior knowledge of the application, yet the previous year’s developers,who had come to understand the PIPE’s design and inner workings quite inti­mately, had by this point moved on. Even detailed documentation left in theannual reports and in source code comments provides no substitute for face­to­face interaction. Therefore, before any actual development work could begin,

8

a substantial amount of time was spent becoming familiar with the applica­tion. This involved studying code, reading what documentation was available,communicating with contributors to the PIPE project beyond Imperial College,generating UML diagrams for the software, and then attempting to fix bugs (seesection 3.2).

2.3 Arriving at the SpecificationThe final specification was based on a number of inputs:

The group’s own experiences investigating the application and learning•Petri net theory led us to suggest a number of improvements. At this stageit was difficult to judge how hard these would be to incorporate, and somewere clearly beyond the scope of this project. One idea that remained,however, and deemed achievable, was to incorporate zoom functionality, tomake it possible to see the structure of larger nets in full, without havingto scroll the screen.

Dr. Knottenbelt has overseen PIPE’s development for several years and•is the main point of contact for many PIPE users and contributors; hisopinions were therefore highly valuable in deciding which direction to take.One piece of functionality suggested was to offer generation of reachabilitygraphs which would show the possible states a Petri net could achieve andthe transitions between them.

The team had been in ongoing contact with David Patterson, the most•active of PIPE’s external contributors. David uses PIPE regularly andhad many good ideas about how it could be improved. Much of the refac­toring work was proposed by him, and he had also suggested that zoomfunctionality would considerably improve PIPE’s usability when workingwith larger Nets.

The key areas identified for this year’s work therefore were: refactoring andcode clean­up; incorporation of a module that would allow users to generatereachability graphs; and adding zoom functionality.

Additionally, to address the issues of code complexity and maintainability weproposed to introduce an automated testing framework to the project (at thisstage no tests existed within PIPE2). A well written suite of automated testswould allow developers to refactor and add to the code with confidence thatnew bugs were being kept to a minimum. Over time, this should allow faster,better designed improvements to the application. Another important benefit ofautomated testing and a continously integrated build is that testing and bugfixing is spread over the life of the project, rather than being concentrated intothe period just before release. Testing is described fully in section Finally, weconsidered the possibility of improving options functionality. Many options thatwould be useful to specify were defined all over the code and could not bechanged dynamically. A single properties file with all of the options (such as

9

the colour of active transitions and the size of annotation text) would improvePIPE’s usability.

2.4 Managing Project Tasks and ResourcesThese areas were investigated in the early stages of the project in order todetermine their feasibility and to produce estimates for the amount of workrequired. Each team member investigated a different part of the specificationin order to establish what steps he thought would need to be taken, how longwould be required and what possible complications might arise. The group thendiscussed which team members would be suited to different tasks. The teamof five students expected to contribute around 12­14 hours of work per weekeach. With this information, the initial schedule was drawn up (using MicrosoftProject 2003), shown below as a Gantt chart.

10

The chart features key milestones of completing reports and making releasesof the application. The Gantt chart was updated at intervals as the project pro­gressed, making it possible to see whether tasks were being completed on time.The effectiveness of group organisation and project management is discussed inthe Evaluation section.

2.5 Development EnvironmentIt was agreed that a consistent coding environment across the group would bebest to enable easier transfer of code and project specifications. PIPE wasoriginally written using Borland’s JBuilder, which is proprietary commercialsoftware unavailable to the group. Of the available free IDEs, the open­sourceEclipse was chosen because:

It is free•It is well supported under Windows, Linux and Mac OS•It has a highly mature Java environment•It has native support for CVS•It was easily able to import the existing code tree and compile it•

Concurrent Version System (CVS) support was especially important becausePIPE is already published on SourceForge2, a popular Open Source communitywebsite, with a CVS repository and some useful issue tracking facilities. CVSenables several people to work on the code at the same time, and then to committheir changes to the repository, which determines if there are any potentialconflicts. Eclipse extends this by allowing line­by­line resolution of conflictingsource changes and easy access to all CVS features such as previous revisioncomparisons and committal annotations. This proved to be a valuable resource,also allowing group members to work on the code from their home computersas well as University machines.

2.6 Development ApproachNo particular established development methodology was strictly adhered to.However, the approach borrowed to some extent from agile methods. Updateswere committed as regularly as possible, with three separate fully­functional re­leases (versions 2.1, 2.2 and 3.0) made during the project. Regular face­to­facecommunication took precedence over written documents (though submitted re­ports 1 and 2 meant that we had a detailed initial specification and an indicationof progress mid­way through development): the group had a scheduled weeklymeeting but three or four additional ad hoc meetings typically took place everyweek, either the whole group or teams of two or three who were working onspecific areas.

11

Part II

DEVELOPMENT

12

3 Refactoring and Code Clean Up

3.1 IntroductionThe decision to develop PIPE within the framework of the open source com­munity has yielded substantial benefits to the application as a whole and tothe user base in general. The direction and focus of the application’s softwaredevelopment has often been driven by user demand for specific functionality.This has enabled the software to evolve into a highly usable and diverse toolsetfor creating and analysing Petri nets. It successfully addresses the requirementsand obligations of real world users who stress the system on a daily basis. Nev­ertheless, as a result of the demand orientated approach to development andthe dynamic nature of the core group of developers over the last five years (con­stantly changing on a yearly basis), the code itself rather than its functionalityhas become a fundamental concern of the developers. In order to sustain longterm projects, one of the key issues is building a sturdy foundation on whichfuture generations of coders can naturally develop viable extensions. Unfortu­nately, this has not been a priority and over the last couple of years a certainamount of inefficiency has slowly crept into the code base. As a natural conse­quence of the project’s rapid expansion, some of these inefficiencies are causednot by individual modules but rather by the complexity introduced as a result ofmultifarious interaction between classes. In addition, the lack of a clear develop­ment strategy from the outset has resulted in poor management of data and anunnecessary repetition of common processes. Understandably, as separate yearsof developers implement increasing levels of functionality, the logical separationthat usually exists between classes has become indistinct and has negativelyimpacted the application’s efficiency. Mostly, this part of the work involved therefactoring described in section 3.4. However, before this could take place, therewere some outstanding bugs which needed attention, and some code which hadbeen modified by a developer working in isolation (outside the CVS system)needed to be integrated.

3.2 Bug FixingA number of bugs had been identified at the outset of the project. While aninitial period of bug­fixing had been scheduled, in practice bug fixing was moreopportunistic. ­Dave Patterson, an active user and contributor to the PIPEproject, provided fixes for several bugs (immediate transitions not being givenpriority of timed transitions; simultaneous firing of tokens via the same channel;random null pointer exception generated while saving after running an analysismodule).

Tim fixed one of the bugs listed in the original report (Infinite while•(!(isEmptySet(chj))) loop in the invariant analysis).

During the course of his refactoring work, Edwin discovered and fixed•four bugs including one posted by Tim (it was causing animation to freeze

13

halfway while stepping back through a long firing sequence). Edwin man­aged to fix it by modifying the code in several places to resolve the discrep­ancies between the count int variable and the firedTransitions arrayList,which are used to play back the firing sequence. There was a bug whereusers were not prompted to save when they added or removed tokens fromthe net. Edwin fixed the problem by adding a code in the setCurrentMark­ing() method in the Place class so that it will set the netChanged to truewhenever its number of tokens is altered. There was a problem whereusers could still step forward a previous firing sequence after it had beenreset (e.g. toggling off and on the animation mode). This was resolvedby changing the code in the GuiFrame class so that it resets the fired­Transitions array list and the counter in the Animator class. Finally, theanimation didn’t playback the way it was expected to when the firing se­quence has been altered i.e. firing a transition in the middle of the firingsequence. Edwin found out that the problem was due to the applicationtrying to simulate the original firing sequence which was still in memory.He changed the code in the animator class so that whenever the firing se­quence is altered, all successive stored transitions in the previous sequenceare pruned. He also made corresponding changes in the AnimationHistoryclass so that the correct firing sequence is displayed.

One of the unfortunate truths for any development team working on re­•vamping a particular code base is that some errors will be inherited fromthe original code. One such instance was a particularly obscure problemrelating to the saving of Petri nets. At some point during the constructionof a net, the core representation of the net was becoming corrupted andthis naturally led to a plethora of unexpected behaviour and errors. Thefirst signs of this problem were raised when nets that had been worked onfor extensive time were causing a null pointer exception when attempt­ing to be saved. With focussed testing the group realised that this wasonly the tip of the iceberg, and that should the exception be generated, avariety of unexpected behaviour was observed throughout the entire appli­cation. This was eventually tracked back to a problem with the manner inwhich objects were being created according to mouse presses and releases.Changes made by Matt to the manner in which the object handler dealtwith events within the container which resolved many of the related issues.Finding a solution was far simpler than finding the cause, highlighting theneed for well­designed exception handling.

3.3 Integration of External ContributionsAs shown from the Gantt charts, from 25th January to 3rd February, Edwinworked on integrating external contributions into the project. He managed toincorporate all the bug fixes from all external contributors in the recent releaseof PIPE v2.1. However, after evaluating the code by external contributor PereBonet, the group decided that it was in its best interest to leave the integration

14

of new functionalities including cut and paste, redo and undo etc to the end ofthe project, if time permits. This was mainly due to time constraints and thepossibility that Pere’s code would introduce conflicting changes to the work weset out to do. We have created a separate branch on the CVS server to facilitatethe merging of the two versions in the future.

3.4 Code RefactoringCode refactoring had been identified as a major part of the initial specification.The first report described six key areas where there was obscure or inefficientcode. Most of the team was scheduled to spend a substantial part of this firstperiod working on refactoring. All listed issues were addressed successfully andupdates have been posted to CVS, with the exception of introducing Generics ­this area was examined and confirmed as a possibility but following advice fromDr Knottenbelt, the team has decided for the time being to maintain backwardscompatibility with Java 1.4. Each area of refactoring is described again belowtogether with the details of how it has been addressed and an evaluation of theoutcome.

3.4.1 XML and DataLayer Division

3.4.1.1 Problem The DataLayer class had many methods to manage theproperties of the data layer (what transitions, places and arcs are part of thedata model) as well as a lot of code to import a data model from, or exportit to, an XML file. We planned to separate out all of the XML code from theDataLayer class and create classes to manage the importing and exporting ofXML files. A DataLayerFactory class would be written to process an existingXML file as input and create a DataLayer. A DataLayerWriter class wouldoutput the description of the model to an XML file (originally done using thesavePNML method in the DataLayer class).

3.4.1.2 Solution In order to solve the problem, Ben spent time investigat­ing the existing code and identifying the methods that dealt with saving andloading. He then determined how best these could be abstracted to differentclasses. In order to better understand the code and possible solutions, he spenttime investigating the handling of exceptions in Java, and also the use of cer­tain design patterns, as suggested by team mates, such as the ’Factory’ and’Builder’ patterns. The saving functionality was easier to abstract, as the Data­Layer object doesn’t have to to be manipulated. The method savePNML, andthe methods createPlaceElement, createAnnotationElement, createArcElement,createArcPoint and createTransitionElement, which are used to create the ele­ments in the XML Document object, were all abstracted to a DataLayerWriterclass, along with the necessary imports. savePNML now takes in the Data­Layer object to save, and the other methods examine this when building theDocument. Ben then changed the call to savePNML in the saveNet methodof the GuiFrame class, so that a DataLayerWriter object is created, and the

15

method called from this. The loading functionality was more difficult to ab­stract, as the code for loadPNML involved parsing and transforming an XMLfile, cycling through its elements, determining their nature (Place, Transition,etc) and then adding the necessary attribute to the DataLayer object. Thislast piece of functionality was difficult, and seemingly inappropriate, to per­form in a class other than DataLayer itself, as the data members and methodsneeded are private. A first attempt was to abstract all the necessary methodsfrom Data­ Layer, however these methods are needed in order to add to a Petrinet model when using the application, and so would have to be duplicated. Asuggestion from a team mate was to implement an interface containing thesemethods. However upon discussion it was decided that this would increase thecoupling between classes, and would also leave the problem of a class tryingto modify the private data members of another, which seems especially inap­propriate when the object in question is actually being created. Therefore Bendecided to split the functionality of loadPNML. The actions concerning XMLwere removed to a separate class PNMLTransformer, which includes the func­tion transformPNML. This takes the filename of the XML file and parses andtransforms the file, creating a Document object, which is then passed back to themethod’s call ­ in the DataLayer constructor. A separate method in DataLayer,createFromPNML, was then written, which takes this Document and uses theDataLayer class’s original methods for modifying a net model to create the onedescribed in the XML file. All the getDOM methods were also abstracted tothe PNMLTransformer class as these involve the use of XML and returning adocument. Finally, Ben modified the create­ NewTab method in GuiFrame sothat instead of calling loadPNML from the present DataLayer object, a newinstance of PNMLTransformer was created, and the methods called appropri­ately. The second abstracted class was called PNMLTransformer rather thanDataLayerFactory as initially anticipated because Ben felt the new class didn’tfit the standard ’Factory’ pattern, in that it didn’t involve a condition and thena call to build an object, but rather was just a class concerned with the parsingand transformation of XML files.

3.4.1.3 Evaluation The final outcome is that the DataLayer class nolonger deals with XML, as outlined in the refactoring brief. All imports toXML related packages have been removed. Comments have been added andmethod and class documentation updated. All exceptions are still dealt with.Much of the original code remains intact, and the application still passes thetests of the functional suite.

3.4.2 Matrix Instantiation

3.4.2.1 Problem The DataLayer class had many methods that were usedin the analysis modules (typically getting matrices or Petri net objects (theseinclude, Place and Transition objects, arcs and annotations), or the status oftransitions for a Petri net ­ i.e. which transitions are enabled for firing). How­ever, only a limited number of events changed the model enough that there

16

was impact to the analysis. For example, when a model was created from anXML file, the incidence matrices could be created once and reused until the userchanged the number of tokens at a place, or changed the number or kinds ofarcs, places or transitions. Aside from iterative simulation, all of the analysismodules ran on data that was static as far as the structure goes, yet the analysisroutines were all written to keep generating the incidence matrices repeatedly.We investigated ways of reducing unnecessary updates to the data model usedin the analysis modules, perhaps by developing methods which could monitorwhen an impactful change has been made to a Petri net and flag this up tothe analysis module, which would only then update the model (or parts of themodel) it is using for the analysis.

3.4.2.2 Solution Edwin addressed this issue, refactoring the code to makeit more speed and memory efficient. He added a new matrixChanged Booleanattribute to the matrix object and modified the code so that matrices are onlyrecreated when they have been altered.

3.4.2.3 Evaulation Comparing the modified code with the original code,it can be shown that the number of times the createMatrix method is called isreduced by half when the GSPN, invariant and incident markup analyses wereperformed on the Petri net.

3.4.3 Reflection and Class Loading

The Module Manager is responsible for core elements of the software’s function­ality. It is accountable for the integration of many of the major developmentsand expansions that have been introduced over the last couple of years. Inher­ently, it acts as a form of plug­in manager for the PIPE application, offering thenecessary structure to permit foreign modules to be incorporated into the pro­gram. As a result, it was one of the key areas of the code that was scrutinisedduring the refactoring phase. The first issue Matt addressed was a problemwith the actual manner in which reflection was being used to incorporate for­eign modules with unknown methods into the application. The code initiallyused reflection to discover all methods of a foreign module and build them intoa tree structure for future use. Using Java Swing and reflection technology, allmethods were added to a JTree as nodes (default mutable tree nodes), creatinga means of controlling and displaying a set of hierarchical data as an outline.The structure made each new module rapidly and readily accessible via the treeview Swing left hand side of the GUI. Since only the ’run’ method of these mod­ules is required to populate the drop down menu within the main PIPE GUI,and to effectively enable the running of that module, we decided to removeall other reflected methods and simply process each module by only loading asingle method. The work around the module loaders naturally led to a closerexamination of the method used to load modules as a whole into the PIPE ap­plication. Despite the fact that most of the code was in place for stand alonedynamic runtime loading of modules, information relating to module file paths

17

was hard coded into property files (the configuration files). The properties werethen streamed out of the files providing the classes with both a correct nameand file path to the actual ".class" files. Each class was then loaded via theModuleLoader and the ExtFileManager using a custom classloader that fell un­der the hierarchy of the urlClassloader. The methods of these classes were thenused to populate the "available module" tree at runtime.

This seemed to contradict the idea of pluggable modules which could sim­ply be dropped into the module folder upon completion and be immediatelyintegrated into the project. It also introduced complications should modules beeither moved or renamed. Changes would involve updating each of the individualproperty files for all the modules. Modifying the getModuleClasses/getModuleDir,Matt made this loading more pluggable, so that the class names and paths wereno longer hard coded but truly dynamic. By recursively searching through themodules directory and sub directories and filtering the results through an exten­sion filter, it was possible to load all the classes from that particular directoryregardless of the contents, picking up only modules that successfully imple­mented the module interface. The ModuleLoader class was changed to reflectthis different approach and a getClassName method dealt with generating Classnames. Thus modules can now be dropped into the module folder and simplyincorporated into the build without the need for modifying configuration files.

3.4.4 Data Mismanagement

3.4.4.1 Problem There was considerable inefficiency in how data is man­aged. For example, the DataLayer kept ArrayLists of Place and Transitionobjects, which were generated by the analysis modules. There were numerousplaces where arrays were generated only because the length of the array wasrequired, whereas a method which only returns the length of the array requiresmuch less overhead. In some cases, an array was called to get its length, thena few lines of code later, another copy of the array was generated. It wouldbe more efficient to call the array once, get its length locally, then use it asrequired. We aimed to look into the management of data, particularly in theanalysis modules and the DataLayer class, and eliminate these inefficiencieswherever possible.

3.4.4.2 Solution Will identified numerous instances where arrays were be­ing created in order to facilitate basic parts of the analysis. This was particu­larly prevalent in the Classification class, and also the GSPN class which extendsClassification. The initial solution was to introduce local placeholders within theClassification class, one for Place arrays and one for Transition arrays. Thesewere set up so that on the first attempt to access, a copy was made; this copywas then used for subsequent accesses by analysis modules. Although this didn’tproduce any perceptible issues when the application was run, it turned out thatthe changes were causing a test to fail. The test had been written by Edwinto ensure some basic requirements of Petri nets were being met. Will thereforeused an alternative method to prevent unnecessary creation of arrays ­ methods

18

were written to get the counts of elements in the Place and Transition arraysused by modules. Since so much of the inefficient code involved creating arraysjust to then get their length, this should significantly improve the efficiency ofthe code. The new methods were added in the DataLayer class, and a total of23 references in five different classes were updated to take advantage of the newmethods.

3.4.4.3 Evaluation A functional test script was developed which openeda basic Petri net, then ran the Classification, GSPN and State Space analysismodules on the Net. Using TPTP profiling[10] it can be seen that the new get­PlacesCount method is called 36 times and the getTransitionsCount is called 47times. Correspondingly, while the old version of PIPE called the method get­Places(Place[]) 41 times and the method getTransitions(Transition[]) 105 timesduring this test, the new version calls getPlaces(Place[]) 3 times and getTransi­tions(Transition[]) 58 times. This clearly represents a substantial reduction inthe number of array instantiations thanks to the refactored code.

3.4.5 Evalution of refactoring

While the individual refactorings were clearly successful in increasing the usabil­ity and efficiency of the application, it was also desirable to show quantitativelythat the refactoring had improved application performance. To this end, the ap­plication was profiled before and after refactoring (it was possible to downloadthe code base at different date points via CVS). TPTP (Test and PerformanceTools Platform)[10] is an Eclipse foundation top­level project that includes arange of tools that can be used to profile Java applications. Profiling tookplace using a range of functional tests simulating various uses of PIPE (open­ing, closing and editing nets and subjecting them to a variety of analyses); itwas then possible to see how memory usage and execution statistics differed.Secondly, the Eclipse metrics plugin was used. This provides detailed informa­tion about Java packages and classes including afferent vs. efferent coupling(i.e. instability). It also measures McCabe cyclomatic complexity[11], an indi­cation of method complexity arrived at by counting the number of distinct pathsthrough methods. The group hoped that the refactored code would show someimprovement on these measures. There were a number of differences betweenthe profiles, but regrettably it wasn’t possible to show significant and consistentimprovements in performance of the new code over the old. According to somemeasures (e.g. overall execution time), the newer code base showed marginallyimproved performance. However, on others there was no change or a slightworsening of performance. Similarly, on measures of instability and complex­ity, the results were mixed and certainly not conclusive. It had perhaps beenwishful thinking that the changes made would generate significant quantifiableimprovements to the application’s overall performance considering its size andcomplexity. The individual improvements, justified above, were certainly sig­nificant however, and should lead to more efficient and more easily understoodcode for future generations of PIPE developers.

19

20

Figure 2: DataLayer class before and after refactoring. References in bracketsrefer to refactorings described above

Figure 3: The DataLayerWriter class which now contains methods for saving aPetri Net to an XML file.

4 Zoom Functionality

4.1 IntroductionAs outlined in the specification of the zoom function, the idea was to add thisfeature to PIPE to give users greater flexibility in working with their Petri nets.At a functional level, what one would want from zoom is fairly obvious. So,when planning the work, possibly the most important considerations to keep inmind regarded avoiding unwanted side effects of adding zoom. In particular,use of the zoom function should not:

Affect the integrity of the Petri net diagram•Affect or disable any other drawing functionality available to the user•Alter the behaviour of the net on animation or the results of analysis•Make any change to the file representation of the Petri net•

So, it was important to get a good understanding of how the visualisation ofthe nets worked, how the data model of the net interacted with the on screenview, and to design and integrate the zoom feature carefully into the existingcode.

4.2 Research4.2.1 Existing PIPE code

The existing version of PIPE was run in debug mode, using the Eclipse IDE, todetermine the way changes and additions to the Petri net diagram are carriedout. The case of adding a new place to the net was chosen as a simple exampleto look at. Single stepping through the code and recording the flow of controlenabled the UML sequence diagram in Figure 4.1 to be produced. The diagramshows that, although PIPE does not follow the MVC pattern fully by separat­ing the model and the view of a place into separate classes, it does separatethe interactions the Place object is involved in. At the top of the diagram the

21

newly created Place object is added to a DataLayer object which is responsiblefor providing information when analyses are run, or the net is saved to file. Inthe lower half of the diagram the Place is added to a GuiView object which isthe on­screen component that displays the Petri net. From this we were able toestablish that most of our work would need to look at the representation of thenet by the GuiView, and the interactions between the user and the GuiView.The only point to be addressed on the model side would be to ensure that thex and y values of each component provided to the DataLayer, and subsequentlysaved to file, were not affected by the current zoom.

4.2.2 Swing

The GUI components used in PIPE are part of the Java Swing library, and soseveral of the Java Tutorial pages related to Swing were looked at as part ofour research. The most important information we found related to the layout ofcomponents within a container[6], and transforming shapes and images[7]. Lay­ing out components within a container in Java is controlled by a LayoutManagerobject, which pulls, pushes, stretches and squeezes components into a particularoverall layout, e.g. a grid of cells where the components are all forced to be thesame size. In fact, PIPE bypasses this system by setting the LayoutManagerof the GuiView container to null and delegating positioning and sizing to eachindividual component. They achieve this using pixel measurements, relative tothe top left corner of the parent GuiView in the case of positioning. Scaling (ortranslating, shearing or rotating) can be applied to graphics in Java using theJava.awt.geom.AffineTransform class. An AffineTransform object can be passedto the Graphics2D object that shapes and images are painted into, causing thegraphics to be transformed in some chosen fashion. In our case, we would cre­ate an AffineTransform and use its scale() method to set the degree of zoom wewant to apply to the shapes of the Petri net.

4.2.3 Successful Approaches to Zoom Implementation

Some searching was carried out to try to find descriptions of successful imple­mentations of zoom in Java Swing applications, or possibly even class librariesthat we could look to integrate. This search was not very fruitful. Some opensource zoom libraries do exist, in particular Piccolo developed at the Universityof Maryland[8]. While it is very impressive, with classes representing cameras,lenses etc., integrating something like Piccolo would have meant replacing thecurrent PIPE net element classes entirely. We felt this was unnecessary. Nodescriptions of general approaches or patterns for zoom were found.

22

Figure 4: UML Sequence diagram for adding a new place to the Petri Net. ThePlace is registered with both a DataLayer and a GuiView.

23

Figure 5: Zooming from the centre out

4.3 Design4.3.1 Design Decisions

We posed the following questions when thinking about how zoom would work:

Which elements of the net should be affected by zoom?•Answer: The position of all elements will be affected, but text labels will•not be resized. Changing the size of text will make it unreadably small orobtrusively large fairly quickly and will not enhance the diagram.

Will a saved net always be opened at 100% zoom?•Answer: Yes. Zoom values are not part of the file data, and so a net will•always be saved and reopened as though it were at 100%.

Can multiple nets open in different tabs be shown at different zooms?•Answer: Yes. Zooming a net in one tab should not affect the others.•

4.3.2 Geometrical Approach

The strategy for transforming the geometry of the net went through two itera­tions. Initially, a two­step approach was envisaged. First, the position of eachcomponent relative to the centre of the current diagram would be calculated,then this position would be scaled, see Fig. 4.2.

As shown in the figure, this would result in some components having negativex or y values with respect to the parent panel, so the second step would be totranslate the components back into the visible area. Initially, it was thought it

24

Figure 6: Zooming from the container origin. The diagram is subsequentlyscrolled, so that it appears as though the screen is zooming in on the centralpoint.

would be necessary to use these two steps to achieve the correct expansion ofthe diagram around the central point. However, once implementation began itwas realised that this was very complicated to get right. Furthermore, simplymultiplying all the normal x and y coordinates by the zoom factor, and thenscrolling to the correct point was equivalent to the more complicated approach,and achieved exactly what we wanted. See Fig. 4.3.

4.3.3 Code Architecture

At the code level, the design of the zoom function had three main parts. Firstly,a new class ZoomController would be added to the pipe.gui package which wouldbe responsible for keeping track of the zoom value of a GuiView, and provideservices to objects needing to zoom. Secondly, since different elements in thediagram would need to act differently when a zoom occurred (Places scale andtranslate, ArcPoints and text elements translate only etc.) a new interface,Zoomable, was introduced. Zoomable contains one method, zoomUpdate(),which each class would implement according to its own particular behaviour.This then enables the GuiView to treat all relevant components as Zoomable ob­jects, and simply tell them to zoomUpdate(). Finally, a new class ZoomActionwas also created, within the GuiFrame class, with a standard actionPerformed()method to initiate the zoom. A high­level sequence diagram for the planned im­plementation of a zoom event is shown in Fig. 4.4.

25

Figure 7: Sequence diagram for zoom. The GuiView makes a zoomUpdate()call on all its Zoomable components, and the ZoomController is queried for thecurrent settings.

26

Figure 8: UML class diagram showing the relationships between GuiView andsome of the Zoomable and non­Zoomable components it may contain. Notall classes derived from PetriNetObject are shown. Several others, like Arc, didnot need to implement Zoomable, so it was decided not to make PetriNetObjectZoomable itself.

4.4 Implementation4.4.1 PlaceTransitionObjects

Places and Transitions in PIPE both derive from PlaceTransitionObject andmuch of the implementation, including the zoomUpdate() method was done atthe superclass level. Firstly, two new variables, locationX and locationY wereadded to the class to store the ’real’ coordinates of the object, i.e. with no zoom.These variables are only updated if the object is actually selected and moved bythe user, not if it moves as the result of a zoom. Next, zoomUpdate() was im­plemented to query for the current zoom value and update the size and locationof the object accordingly. An AffineTransform for the current zoom is obtainedfrom the ZoomController and used to transform the component’s shape. Thechallenges encountered were updating the ’clickable’ area of the objects and anyarcs connected to them. Mouse clicks did not initially register within the wholearea of the new zoomed components. We discovered that Places and Transitionshad overridden the contains(int x, int y) method of JComponent. This methoddefines the area within which the component responds to mouse clicks, and sohad to be altered to reflect the zoomed size. Finally, the objects carefully calcu­late the points at which any arcs attach to them. For a Place this is a point on

27

its circumference. For the Transition we found that an AffineTransform was al­ready being used to calculate the points (to allow for rotation of the transition)and so we were simply able to concatenate this with our own AffineTransformto produce the zoomed result.

4.4.2 Arcs

In fact we did not implement zoom in the arcs themselves, but rather in theArcPathPoint class. The Arc simply joins up its constituent points to createitself. In the same way as for PlaceTransitionObjects, a variable was added tothe class to store the ’real’ location of the point, independent of the on­screen,zoomed position.

4.4.3 Labels

NameLabels are the names of Transition or Place objects, and this informationis stored in the pnName NameLabel variable inherited from PetriNetObject. Inthe first iteration of the zoom process, these labels were not updating when theobject was zoomed and moved position. To remedy this, a call to the pnNamevariable’s setLocation() method was added to the updateBounds() method ofPlaceTransitionObject, which is called to update the object as part of the zoom.The new, zoomed coordinates are passed in, along with the height offset of theobject, and the result is that the label is repositioned with the newly zoomedobject.

4.4.4 AnnotionNotes

The AnnotationNote objects inherit from PetriNetObject like everything else,but because their text still had to be legible, we decided not to change theirsize. Therefore the effect of the zoom simply had to be a translation from onecoordinate to another. As with other objects, variables were added to the classto store the original coordinates of the object, so that these could be used forsaving/loading. The zoomUpdate() method was also added, which gets the cur­rent ZoomController (if not null), calculates the new zoomed coordinates usingthe original coordinates of the object, and then uses the original setLocation()method to repaint the object. This updates all aspects of it, including it’sdraggable points, so no further work was needed.

4.4.5 Updating the JScrollPane

After successfully zooming a net so that the objects’ size and relative positionare correct, the next task was to ensure that the view pane changed accordingly.The specification dictates that the zoomed view will appear to remain centred onthe same part of the net as before. The first challenge, however, was to resize theentire pane to fit the new net, if larger. As previously mentioned, we encounterednumerous difficulties with this. The container PIPE uses is a JScrollPane, whichcreates and updates the viewport and scrollbars automatically, but the pane only

28

recognises it needs to ’grow’ if it is updated and it’s child components are offthe bottom and/or right­hand side of the pane. However, once we decided tozoom the objects’ distance from the top left corner of the pane, rather thanthe centre of the view, it meant that the net was effectively always growing outto the right and down. The pane can then be resized by calling the existingmethod updatePreferredSize(), which iterates over the net objects and sets thesize of the pane accordingly. Originally, PIPE only extended the pane if objectswere created on the very edge of it. We decided it was easier to continue todraw a net if the pane increased whenever an object was within 100 pixels ofthe edge. This way, there’s always plenty of space to scroll to and add the nextobject, meaning the application is more usable.

When the JScrollPane enlarges, scrollbars are added and updated automat­ically. However, the viewport remains the same. Therefore, the next challengewas to reposition the viewport so that it appears to be centred on the samecoordinates as before ­ as detailed in the specification. The scrollbars are cre­ated automatically as children of the JScrollPane, and can be explicitly altered.We first experimented with moving the scrollbars to certain values in order tomove the viewport and change which section of the net was visible. However, wesoon discovered it was easier to modify the JViewPort component of the panedirectly. We added code to the actionPerformed() method of ZoomAction tostore the coordinates of the top left­hand corner of the viewport pre­zoom. Incase this was itself a zoomed perspective, we convert these to what they wouldbe without any zoom. The zoom process then goes ahead, and after the paneis enlarged if necessary, we calculate the coordinates of the new viewport. Theend result is that the model appears to have been zoomed around the centrepoint of the previous view. The scrollbars update automatically.

4.4.6 Click and Drag

During the implementation phase the idea to be able to ’click and drag’ thePetri net came up. This is a feature that often goes alongside zoom, and thedecision was taken to promote this over the zoom select function. Briefly, theuser turns on the "drag mode" by clicking a button on the tool bar, and isthen able to click anywhere in the diagram and drag that point across thescreen, causing the whole net to scroll. Click and drag was implemented bymaking a few fairly simple changes. Firstly, an extra mode constant was addedto the pipe.gui.Constants class, with a button to activate it. Secondly, themouseDragged() method was implemented in the nested MouseHandler class ofGuiView. The algorithm used to produce the drag effect is as follows:

Let point p be the top left corner of the visible area•if Xdragged_to > Xdragged_from then p.x = p.x + (width of visible•area)

if Ydragged_to > Ydragged_from then p.y = p.y + (height of visible•area)

29

Figure 9: Proposed buttons for zoom

Figure 10: Final buttons for zoom

translate p by ((Xdragged_from ­ Xdragged_to), (Ydragged_from ­ Ydragged_to)).•scroll point p into the visible area•

The scrollRectToVisible() method of Java.awt.Component is provided for ex­actly this purpose and gives a pleasant, smooth scroll (especially when comparedto the author’s initial attempts to reposition the scroll bars manually!).

4.4.7 User Interface to Zoom Functionality

The original specification detailed that the zoom functionality should be ac­tioned by the user via several buttons and menu items from the View dropdownmenu. The anticipated buttons were as follows:

The final application looks like this:The Zoom Select functionality was omitted in favour of the Click and Drag

tool, as mentioned above, but the other functionality is all present. Icons inkeeping with the look and feel of PIPE were sourced [9] and added to the GUItoolbar for the incremental Zoom In and Zoom Out. The original specificationdictates that clicking either of these buttons will result in a zoom of 20%, how­ever we felt it was more useful to reduce this increment to 10%, as the buttonswould mostly be used for zooming in small amounts to refine a larger, previouszoom, probably made using the selection box or dropdown menu. The zoomselection box for the toolbar was created as a JComboBox. In order to tailor itto the correct size, several of its mutator methods are called when the GUI isset up, so these were abstracted to a separate addZoomComboBox() method.The specification dictates that the options in the box range from 20 to 100%,with increments of 20, with 150, 300 and 400% also available. This has beenchanged to a range of 40 ­200%, with increments of 20%, plus 300, 350 and400 percent, so as to give the user more choice. All these selectable options arealso used for the Zoom dropdown menu under View, so they are declared as

30

Figure 11: Proposed dropdown menu for zoom

the constant String array zoomExamples within GuiFrame. The combobox isalso set as editable, meaning the user can input their own value. A JComboBoxcan be associated with an action, but each individual selection within it cannot.Therefore a generic zoom action of type ZoomAction was initialised, and asso­ciated to the box. The specific item selected has to be determined in the actionhandler. The other way of actioning a zoom is via the dropdown menu. In thespecification this was to look like this:

However in the final implementation, the number of selections has beenincreased, as with the selection box on the toolbar, and looks like this:

Unlike the JComboBox, each item of the dropdown menu has to be associ­ated with an action. However, rather than initialise new ZoomActions for eachitem, each one is associated with the generic zoom action, as with the selectionbox.

So, with the interface created, a user can click on any of these items toaction a zoom. The degree of zoom they have selected is then extracted fromthe created action in the actionPerformed() method of ZoomAction. If the

31

Figure 12: Final dropdown menu for zoom

32

incremental Zoom In or Zoom Out buttons have been clicked, the name of theaction created will reflect this, and so zoomIn() or zoomOut() can be calledin ZoomController. These methods increment or decrement the controller’spercent by 10 and use this to set the scale of the controllers Transform variable.If the name of the action is just Zoom, then it could have been created viaeither the dropdown menu or the toolbar selection box. Therefore ZoomActionchecks the source of the action as well, and extracts the text of the selected itemappropriately. However, as the selection box can accept any user input, and theexample percentages themselves contain the ’%’ character, some validation isnecessary before the information can be passed to the ZoomController. If eitherof these conditions are violated, then the selection box is blanked out and theZoomAction aborted. The validated string is then parsed to an integer andpassed to the ZoomController’s setZoom() method, which modifies the percentand Transform accordingly.

It was decided that the selection box should update whenever a ZoomAc­tion was completed, regardless of the source of the action. To this end, theupdateZoomCombo() method was created, which is called after the percentagezoom of ZoomController has been altered and sets the selection box text to thisvalue. We soon discovered a problem with our original implementation of this,however; the method to set the selection box text also fires the newly selecteditem as well. This meant that each zoom was in fact being actioned twice ­highly inefficient! To solve this, we updated updateZoomCombo() so that theActionListener on the box is removed before the item is selected, and then addedagain afterwards, so no action is fired.

4.5 EvaluationOverall, we feel that the development of zoom functionality has been a success.The key objectives outlined in the original specification were as follows:

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 dropdownoptions are added to the dropdown menu and clicking them initiates thecorrect action

All of these objectives have been met. However, the method of implementationand some smaller details do differ from what was outlined in the spec.

4.5.1 Differences from the Specification

4.5.1.1 Implementation The development process detailed in the originalspec was largely followed; our initial research focused greatly on how the original

33

PIPE application drew objects. However, the suggestion that certain existing,unused data members were related to scaling and redrawing object and couldbe used as part of a zoom functionality proved to be incorrect. However, thisallowed us to design the implementation from scratch, following MVC conceptsand good object­orientated practices.

The specification did not provide a detailed plan of how the functionalitywould be implemented. It specified that the Graphics and Graphics2D classesof the AWT package would be sufficient to achieve zoom, and this was the case,although AffineTransform was also needed. However it didn’t mention exactlywhat classes or would be created, or whether an interface would be used, so wesimply used its open­ended instruction that much of the work would concernthe Datalayer and Gui packages as the start point of our research.

4.5.1.2 Functionality Details Perhaps the most obvious deviation fromthe outcome anticipated in the spec was the eventual omission of the ZoomSelect functionality. This was omitted as we felt that it was an unnecessary em­bellishment of the zoom functions we had previously created. The drag functionwas implemented instead, which we feel is far more useful. It isn’t simply an­other way of zooming the net, it is a separate tool which adds new functionalityand increases usability in every view.

4.5.2 Key Metrics ­ Usability and Reliability

Zoom was added at the suggestion of a user, and the key objective was to allowthe information contained in large, complicated nets to be more easily gleaned,both by allowing users to focus in on certain sections and also to zoom out fora comprehensive overview of the whole model. We feel that our functionalitymeets this objective, and increases the usability of the application greatly ­especially when coupled with the related Drag functionality. The icons usedmatch the look and feel of the original product, and the zoom functionalityworks intuitively.

Reliability is also key for users, and we have completed rigorous user testingto establish that the zoom functions effectively in different scenarios ­ differentviews, panes, object types, net designs. Functional tests have also been addedto the suite to reinforce this testing, and aid future development.

5 Reachability Graph Functionality

5.1 MotivationWhen entering the arena of open source software development, the task of iden­tifying key areas of the code that require development and expansion can oftenbe daunting. One attempts to identify areas that have either been entirely over­looked by previous teams of coders or underexploited in terms of generating themaximum level of functionality to the end user. As a team the idea of extending

34

Figure 13: Representation of the relation between a Petri Net and its Reacha­bility Graph

the analysis side of the application was both an interesting avenue to exploreand potentially quiet rewarding.

The reachability graph was an obvious extension of the work that had al­ready been done on state space analysis and would naturally complement theinformation provided on boundedness, safeness and deadlocks. The reachabil­ity graph, a commonly sought after tool when analysing the behaviour of astochastic system modelled with Petri Nets, provide a visual representation ofall the Net’s possible firing sequences. The states therefore represented the cur­rent state of the nodes and the transitions between them indicated particular(single/multi) transitions firing. The example below clearly illustrates the closerelationship between the Net and the Graph, while reinforcing the fact that eachpresents and emphasises different aspects of that same body of information.

The graph is a useful tool for finding erroneous behaviour of a system e.g. wecan use it to determine whether using semaphore will prevent the simultaneousaccess of the data protected by the semaphore.

If the data is simultaneously accessed by both processes, the above Petrinet will assume a state whose markings = (|start of p1|, |access by p1|, |endof p1|, |semaphore|, |start of p2|, |access by p2|, |end of p2|) = (0,1,0,0,0,1,0).However, this state is not present is the reachability graph generated in figure 2,this proves that using semaphore will allow mutual exclusive access of the dataprotected by the data. In addition to this, there are many other uses for thegraph e.g. it can be used to determine whether the net can result in deadlock,the net is bounded etc.

35

Figure 14: PIPE Petri net representation of a two process semaphore

Figure 15: Reachability graph generated by the above Petri net. Note that S3,S4, S5, S6, and S7 are in red and represent the vanishing states.

36

5.1.1 Background on Reachability

A Petri net is not static, its markings can evolve dynamically by transitionfirings which destroy and create tokens. The reachability graph of a Petri netis a graph representation of these firing sequences. The graph is directed whosenodes represent reachability states S and edges represent transitions betweentwo such states; if there is an edge connecting S1 to S2, it can also be saidthat S2 is directly reachable from S1. It is also a multigraph as multiple edgesbetween nodes are allowed as it is possible for two transitions to be enabled inthe same marking and produce the same state change.

37

5.1.2 Background on generating state space[12]

38

5.2 ResearchThe research carried out prior to the development of the Reachability Modulewas of key importance to both ascertain the requirements of the general usersin terms of desired functionality and simultaneously investigate potential imple­mentation strategies. In terms of the general user, the needs were fairly basicand easily pinpointed due to feasibility constraints and actual beneficial gainsprovided by the extension itself. The user requirements of the module weretherefore as follows:

Graphical representation of the reachability graph via an additional mod­•ule.

Inclusion of information within the graph in terms of both state numbers•and transition explanations.

Limitation of reachability graph search space in terms of number of ex­•plored states, hence enforcing an upper limit constraint on graph’s beyondwhich both viability and actual additional information obtainable from thegraph become minimal.

In contrast with the user requirements, the potential implementation strategieswere both numerous and extremely varied in approach. The key disputableareas were as follows:

The manner in which we obtained the state space information.•The methods through which we transformed this data into its graphical•representation (this was going to be a flat bitmap graph according to thespecification).

Initial research focused on new algorithms that would perform the analysis onthe Petri net and generate its corresponding reachability graph data. However,it became obvious that completely overhauling the algorithms implemented inthe GSPN Analysis module would both be cumbersome and provide only min­imal gains in terms of efficiency. Additionally, the objective of this part of theproject was not to rework other modules but rather increase the overall func­tionality of the software package. Therefore we pushed this design choice infavour of manipulating implemented algorithms in order to obtain the requiredoutput. The second stage of the implementation research was highly centred ontechnologies that would enable us to represent data in a graphical format. Inparticular, the challenge was to find open source viable solutions to the problemof automating the graph drawing process.

5.2.1 Technologies

The need for a graph visualisation package was immediately apparent from theoutset of this module’s development. The research focused on graph visualiza­tion techniques which enable structural information to be represented as dia­grams of abstract graphs and networks. More importantly though this process

39

Figure 16: Example of Graphviz engine generating automated graph layout

needed to include automated graph drawing. This would tackle the fundamentalproblem of obtaining a graph layout algorithm capable of determining optimumpositioning of the elements of the graph.

5.2.1.1 Graphviz Research into the area of automated graph construc­tion and available packages led us towards the open source community, whichpromised to yield solutions that might be readily integrated into the PIPE appli­cation. Graphviz was highlighted as the dominant open source software capableof representing structural information as abstract graphs and networks. Someof the key elements which made this package so attractive were that it imple­mented a wide range of image formats including JPEG and interactive graphbrowser images, as well as supporting many leading layout formats.

Nevertheless the integration could not be done in a completely straightfor­ward manner due to the fact that Graphviz is coded in C which would breakdown the platform independent nature of the PIPE application, or at leastthis particular module’s independence. Therefore, we extended our research to­wards Java extensions that would provide the link between the functionality ofGraphviz while maintaining the independency of the Java environment.

5.2.1.2 Grappa Developed by the research branch of AT&T, Grappa is agraph drawing package that may be regarded as a subset of Graphviz. The Javapackage provides methods for building, manipulating, traversing and displayinggraphs of nodes, edges and sub­graphs. It also includes methods for reading inand writing out graphs using the ’dot’ text format. Nevertheless, a fundamentalproblem remained in that it still required end users to install Graphviz on theirlocal machines.

5.2.1.3 Dot File Format The dot file format provided the necessary datastructure that would be needed to translate reachability graph information into

40

its graphical representation. Grappa was implemented using this format for anumber of logical reasons. The coding format of dot files is both user orientatedin terms of readability at its source level and also enables quite detailed con­trol over the manner in which Graphviz automates the layout algorithm. Theformat allows users to specify numerous fundamental properties of the graph inquestion, for example:

Node shape, colour and positioning (if the user requires fixed nodes)•Graph orientation in terms of direction ­ top to bottom, left to right, etc.•Detailed labelling both within nodes and between them ­ labels can be•fixed, can change visibility state depending on node selection or inter nodeselection, etc.

The format therefore seemed ideal for the level of control we required overthe actual structure of the resulting graph. Also, this format enables usersto significantly customize graphs and thus could help future developers extendthe functionality of the module through higher levels of user input in terms ofdesired graphical layouts. Once the dot file is constructed, it is then parsedby Graphviz to construct hierarchical or layered drawings of directed graphs.When dealing with the dot file format, the Graphviz layout algorithm directsedges in the same direction (top to bottom, or left to right) and then attemptsto avoid edge crossings and reduce edge length.

5.3 DesignHaving pinpointed the relevant technology that would be used to implement thenew reachability module, a number of design decision then needed to be takeninto consideration.

5.3.1 Graphviz, Grappa and C

One of the fundamental problems that needed to be addressed was the factthat although Grappa provided a Java port to the Graphviz application, itdid not provide a means of actually running the Graphviz application under aclosed Java environment. The end user would still need to install the Graphvizapplication in order to utilise the Grappa port. As Grappa is coded in C,this would require different compilations on different platforms. This naturallycontradicted the initial objectives of the PIPE application in that it was toremain platform independent.

The initial strategic approach to this problem was to export the necessaryelements of the Graphviz application into Java, reasoning that the cross codingfrom C to Java should be fairly straightforward considering the many similari­ties between the two code bases. Nevertheless, it rapidly became apparent thatthis task would be both incredibly time consuming and would require additionalextensive library translations. Hence, to make use of the Graphviz application

41

in its original form, we decided that hosting the application as a remote ser­vice for the PIPE application would be an acceptable compromise. By hostingGraphviz as a service, the PIPE application would remain platform independentyet would now include an additional constraint as it requires internet connec­tivity. Taking into consideration the fact this introduced only minor limitationson the application (given the extent of today’s internet access) we decided topush forward.

5.3.2 Code Architecture

At the code level, many of the decisions in terms of how to introduce the newmodule were predetermined by the manner in which the PIPE application hadbeen initially designed. We introduced a new class ReachabilityGraphGeneratorwhich implemented the Module interface ­ providing the means of rapidly ex­tending the application via its module management system. The user interfacewas implemented through a generic Abstract Window Toolkit container usingthe content pane of the JDialog object. The container was then populated withvarious Jcomponents to provide the user both with the ability to perform anal­ysis on the current net and Petri Net xml files saved outside of PIPE throughthe PetriNetChooserPanel. In addition, the user could recieve feedback via theResultsHTMLPane and are given a choice of to place the initial state at the headof the reachability graph by selecting the Checkbox. Finally a ButtonBar wasadded to the container which initiated the reachability analysis by performingamongst other tasks the calls to both the overloaded generate method withinthe StateSpaceGenerator class and to the generateDotFile. The first produceda reachability graph file (rgf) which held both the state and state transitioninformation corresponding to the net in question. The second translated thisinformation into its corresponding dot file format which could then be used byGraphviz to automate the graph layout.

5.4 Implementation5.4.1 Steady State Algorithm

The principle of the algorithm[12] used is pretty straightforward. It is a deepfirst search and will terminate only when the state space is finite. First, theinitial marking (M0) of the net is calculated and it is added to the state space.The transition enabling rule described in lemma 2 is then used to generate anarray of enabled transitions and the firing rule described in lemma 3 is used tocompute the set of states reachable from M0. In this way, new states can beiteratively added to the state space by selecting a state that is already presentin the state space, generating its reachable states and then inserting them to thestate space. In order to generate the smallest set of possible states as definedin lemma 1, it is necessary to keep a list of explored states so that a state thatis reachable by more than one state is only added once to the state space.

As the state space of the net increases exponentially with its size, specialconsiderations have to be taken in terms of the memory requirements and com­

42

Figure 17: Class diagram outlining of some of the structure and interactions ofthe Reachability module

putational intensiveness. Hence, a depth first search approach is chosen overa breadth first search approach. This is because the explored list, which willeventually contain all the states in the state space, is already very memory in­tensive; it will make it even more memory taxing if a breadth first approach isused. Besides, a depth first search approach confer another advantage in that itallows information on the transitions between the states to be recorded at thesame time, thereby reducing the computational time for generating the statespace.

5.4.1.1 Data Representation The most obvious data type to choose tostore state space is to use a queue because the states in the state space canbe thought as elements queuing to be processed, which in this case, waiting tohave their reachability states explored. Using queue will incur more overheadthan a primitive type, such as an array due to the continuous need to recastobjects back into their original types. However, the ease of programming andmaintainability of code it offers justifies the speed­space trade off since arraysin general used more space and incurred a higher initialisation overhead.

The computational and memory requirements of the explored states play aeven greater role ­ the explored state list will eventually contain all the statesin the state space and we potentially need to transverse through it for everynewly M’ generated to check whether it has already been added to the statespace. Hence, the hashing technique developed by Dr Knottenbelt[13] detailedin Nadeem’s report[14], is used store the state information. The technique canbe summarised into 2 steps:

1. A primary hash key h1 (s) is calculated to determine the row of the hash

43

Figure 18: UMLSequence diagram for generating a reachability graph from aPetri net.

44

Figure 19: Taken from p17 of Nadeem’s report summarising the hashingtechnique used to store states in the exploredstate list

table

2. A secondary hash key is calculated to get the data stored in the table,which contains only compressed state information, which is simply aninteger value, and not the full state description

Each row of the hash table contains a linked list whose elements are the singleinteger compressed state information.

As seen in the diagram above, the combined h1 and h2 key can be used asan identifier for a particular state and thus this information can be used insteadof full the state description to check whether a particular state has already beenadded to the state space. However, the combined h1 and h2 is not unique forevery state description; it is possible to generate the same hash key for twocompletely different states. This disadvantage is offset by the 25­fold decreasein the memory required to store each state.

In order for the graph to distinguish between vanishing and tangible states,the following rule is used to correctly categorise the states in the state space.

At a particular state S,

where ET = the set of enabled transitions containing transitions that satisfythe enabling rule 2, IT = the set of immediate transitions and VS = set ofvanishing states

45

To generate a directed reachability graph, a list of states reachable by thecurrent state needs to be recorded. This is achieved by the use of the arcListEle­ment object created by Nadeem to store rate information between two states.An extra attribute is added so that it can hold transitions information, namelythe transition number responsible for the change of state observed. Once thisinformation has been recorded, it can be taken out of the list, thus a stack ischosen over a normal list to store this information together with this list ofreachable states that haven’t been added to the arcListElement.

All the above information is output into two separate records, the staterecord and the transition record. Markings of the state and the Boolean isTan­gible attribute are stored in the state record. The connections between the statesand the fired transition number are stored in the transition record. Knowinghow the state space can explode exponentially with the complexity of the net,a random access file is used to output this information despite this sacrificing alittle computational speed, as accessing information from a random access filewill be slower than accessing information from a sequential access file. The mainreason for using a random access file is the fact that it enables you to write theinformation anywhere in the file. By creating an offset for the location wherethe transition records are stored in the file, it is possible to store both the staterecord and transition record simultaneously as soon as they have been calcu­lated. This reduces the memory requirement of the output operation by half,because if a normal sequential access file is used, a complete list of state recordsand transition records has to be created before writing to the file; otherwise itwill not be possible to retrieve the information orderly later on.

5.4.2 Random Access Files and Input Streams

One of the major considerations prior to implementing this method was the factthat in order to make use of the Grappa port to Graphviz, it was necessary tosolve the problem of data passing from this method to the att.grappa.parser.When an instance of the Parser class is constructed, it takes as arguments anInputStream which should contain the necessary dot file information. Unfor­tunately in Java, the random access files are not part of the input and outputstream hierarchy, instead implementing the DataInput and DataOuput inter­face. It is therefore impossible to simply assign a random access file to an inputstream.

It was therefore necessary to determine a method by which we could obtainthe data from the random access file, convert that same data into the dot fileformat, and save it in such a manner that it was accessible via an input stream.The solution came in the form of a circular buffer Class[15], which effectivelyconnected input and output streams to a single buffer. The data converted todot file format could then be placed on the output stream of the buffer. Thebuffer would then contain the necessary data which could now be accessed viathe input stream also attached to the buffer, which was effectively passed intothe att.grappa.parser object constructor.

46

Figure 20: Java IO class hierarchy (http://Java.sun.com/)

5.4.2.1 Converting to Dot Format Through the use of circular buffersthe actual conversion of the reachability graph file to a dot file was rudimentary.Having researched the dot file format, the states and transitions were parsed intothe output stream of the circular buffer. Choices were made at this point torepresent the graph in a top down format, with nodes (the states) as circlesand depending on whether or not they were tangible they were drawn in blackor red. The labels on the states were simplified to Sx, where x was an integer,therefore producing a clearly graph. Nevertheless, we also wanted to includeinformation on how each state corresponded to a particular instance of the PetriNet in question. Therefore, we included information in the form of a pop upbox which became visible when you selected a particular state. The informationdescribed the instance of the Petri Net which resulted in the instantiation ofthat particular state. In addition, we also included the same form of labels ontransitions from one state to another indicating the transition from state t0 tot1.

5.4.2.2 Grappa Interfacing The final stage of the implementation re­quired research into the manner in which Grappa both received, processed andthen returned the graphical representation of the data itself. The first stagerequired constructing a Parser object which read in the input stream. Fromthe parser object it was possible to instantiate a graph object via the getGraphmethod, which was then used to construct the GraphFrame. The construct­GraphFrame method established a URL connection with the remote server pro­viding the necessary resources (http://www.research.att.com/~john/cgi­bin/format­graph) which was then able to use the Graphviz installed remotely to determinean appropriate layout for the graph data using the dot algorithms.

5.4.2.3 Modification to the Grappa Interface Some small modificationswere made to the Grappa interface in order to maximise both usability andunderstanding for the end user. The most significant of these were an additiontext box at the bottom of the interface outlining the various options and manners

47

through which the user could interact with the reachability graph. These optionsinclude but are not limited to deleting states, zooming, saving and acquiringadditional information when hovering over states or transitions.

5.5 EvaluationThe following three criteria are examined to test the correctness of the reacha­bility graph, as opposed to its modelling accuracy:

5.5.1 Quality

Two main factors are being considered here ­ the GUI and human­computerinteraction (HCI). The interface should be aesthetically pleasing and blend inwith the rest of the modules. It should also be intuitive (user­friendly) andfunctionally relevant. Visualising the graph should assist the users with un­derstanding the state space of the net. Appropriate colour coding, labels andinformative legends should be used to aid the use and visualisation of the graph.

A dialog box was chosen as the interface to display information and getinput from users because it conforms to the appearance of the other modules.The main drawback of this dialog box is its inflexibility as a top­level containerand its modality, which effectively blocks all interaction between other windowsunless it has been closed. This created a lot of problems for us in getting thegraph JFrame window to interact with the user without having to close themodule window. After testing several methods, we managed to get the graphwindow to pop up on top of the module window and allow the users to interactwith the graph window before having to first close the module windows. Thismakes the module more user­friendly as users can now generate multiple graphsfrom a single module window and they do not have to close the module windowfirst before they can interact with the graph window.

5.5.2 Dot File Formatting

Overall, the interface is very easy to use even for someone who is not familiarwith computers as the graph can be generated by just one click of the button.The appearance of the module window is almost identical to the other modulesas it is created exactly the same way as the rest of the modules. The use ofcolour coding, labels and informative legend allow users with basic knowledgeof Petri nets to intuitively interpret the graph. Functionally relevant optionslike print, zoom etc. are introduced to cater for the needs of an average user,aiding him/her in his/her graph interpretation.

5.5.3 Robustness

The module should be able to handle invalid file inputs. A limit should be setfor the maximum number of nodes on the graph:

48

1. To ensure that the graph can be generated within a reasonable amount oftime

2. To prevent an average user from running into memory problems due tothe explosion of the state space

3. To ensure the quality of the graph ­ it would be pointless to create thegraph if it is going to be a mesh and users cannot intuitively interpret it

The module should always reliably produce the same graph for any two identicalnets. Any exceptions should be handled gracefully.

The main tool used in accessing the robustness and correctness of the moduleis the test suite developed during its implementation. Details of the tests canbe found below.

5.5.3.1 Regression Testing The reachability module is closely coupledwith the GSPN analysis module. This is because a number of existing func­tions and objects were overloaded/extended to achieve optimal code efficiencyand maintainability of the code. Hence, regression testing was used to ensurethat the reachability module was implemented without any disruption to theGSPN analysis module. A GSPN analysis test suite was written prior to theimplementation of the reachability module. It tests several functions used inthe analysis. These tests were run regularly when a new feature or optimisationis added or an existing method is modified. These tests prove to be invaluablein identifying subtle errors and inconsistency of data.

5.5.3.2 Unit Testing Unit testing was employed during the implementa­tion of the module to validate the correctness of each function. These testshelped to ensure correct output and graceful handling of exceptions and in­valid/incomplete parameters inputs.

It is essential to check that the correct state space is generated and the rightresult is passed onto the dot file generation function, otherwise it will lead tothe generation of an inaccurate reachability graph. The integrity of the statespace generated is checked as follows in the StateSpaceGeneratorTest:

1. Check that the state space generated by our algorithm have equal or morestates than the set of tangible states generated by Nadeem’s algorithm[14]as the set of tangible states is a subset of the set of reachability states.

2. If the state space contains only tangible states, the state space generatedshould be equivalent to the set of tangible states generated by Nadeem’salgorithm[14].

3. Check for uniqueness of the states in the state space as the state spacegenerated should contain the least number of states as defined in equation1, thus there should be no replication of states in the state space.

49

The state space data is exported out via a random access file. State informa­tion and transition information are represented as state records and transitionrecords in the file. Therefore, to check that the right information is passedfrom the state space generation function to the dot file generation function, itis important to access the integrity of the functions in the state record andtransition record class. These functions are tested in the StateRecordTest andTransitionRecordTest, which literally tests whether the original data is modifiedin anyway after it has been written and read on the other end.

Having verified the integrity of the state space generator, it was then neces­sary to begin testing on the actual reachability module. This part of the testingrequired verification of the dot file generator algorithm as well as the grappaport. Two fundamental authentication steps were necessary to achieve this:

1. Verify whether the data received from the state space generator was cor­rectly translated into the dot file format ­ carried out by the reachability­GraphGeneratorTest.

2. Check the actual reachability graph for correct number of states and tran­sitions following the dot file parsing and subsequent graph generationthrough the grappa engine.

Having checked the major functionality of the module, one final test (ModuleM­anagerTest) was implemented to verify the module was correctly loaded via themodule manager. This naturally overlapped with tests that had been writtento asses the refactoring of the module loading classes and were therefore usedfor dual testing.

Having verified the integrity of the state space generator, it was then neces­sary to begin testing on the actual reachability module. This part of the testingrequired verification of the dot file generator algorithm as well as the grappaport. Two fundamental authentication steps were necessary to achieve this:

1. Verify whether the data received from the state space generator was cor­rectly translated into the dot file format ­ carried out by the reachability­GraphGeneratorTest.

2. Check the actual reachability graph for correct number of states and tran­sitions following the dot file parsing and subsequent graph generationthrough the grappa engine.

Having checked the major functionality of the module, one final test (ModuleM­anagerTest) was implemented to verify the module was correctly loaded via themodule manager. This naturally overlapped with tests that had been writtento asses the refactoring of the module loading classes and were therefore usedfor dual testing.

After the module had been implemented, we tested it rigorously. We are ableto demonstrate that we are able to reproduce the same graph with fidelity foreach example nets. During the testing phase, we also found that the maximum

50

number of nodes the graph can represent without obscuring its visualisationand interpretation to be around 400, hence, we have set that as the limit forthe module.

5.5.4 Efficiency

Generation of a graph with less than 100 nodes should be moderately fast butit is acceptable for graphs with greater than 1000 nodes to be generated lessquickly.

On average, we have determined that it takes less than a second to generategraph with less than 15 nodes and about 10 seconds to generate a graph with100 nodes. Out of the 10 seconds, the steady state generation only took ap­proximately 0.1 second; most of the time is spent on transmitting the dot file tothe remote server at http://www.research.att.com/~john/cgi­bin/format­graphand waiting for its response. If speed is an issue, users can always download acopy of Graphviz and invoke the remote call locally. This will reduce the timetaken for graph generation by 10­fold.

5.6 ImprovementsAs in all software development projects, a number of possible improvementsmight have been made both to the method of solving the problem and themanner in which the method was implemented. Hindsight naturally makessome of the short falls more apparent although given the time constraints of theproject we feel that the objectives of this module have been achieved.

Nevertheless, there are some improvements that we would like to suggest.In our view the core change that could be made to this module is the imple­mentation of Graphviz hosting at Imperial College. This would provide longterm stability for the module and remove our reliability on the hosting of a nec­essary service via a third party (AT&T). Nevertheless, this was placed on thelist of future recommendations for two reasons. First, this problem is simpleto solve given the necessary time and not fundamental to the module in themedium term, and therefore was not seen as a critical area to leave as a futureimprovement. Secondly, during the course of the project we were able to con­tact the individual running the service at AT&T and received confirmation thatfor the foreseeable future the service would remain available ­ thus providing aminimum guarantee towards the future proofing of the application.

6 TestingA testing framework was implemented using the junit and Abbot open sourcelibraries as outlined in the specification document.

51

Figure 21: UML class diagram of Pipe test framework

6.1 Library IntegrationThe project folder structure was divided into separate application and testingtrees to keep the two types of code apart and allow construction of releases with­out having to sift out test classes. The junit and Abbot code was downloadedinto a test/lib directory and added to the classpath.

6.2 Implementation of Testing FrameworkThe main classes of the testing framework are shown in Figure 6.1. At thetop of the diagram, pipe.AllTests contains references to a collection of classesthat test specific functions, and provides a way to run the full test suite.Each of the testing classes inherits from junit.framework.TestCase. TestCaseprovides the ability to execute the test and supplies various assertion meth­ods that throw an exception if the conditions of the test are broken. Thejunit test runner then collates the results of the tests and displays detailsof any failures. Some PIPE test classes, such as GSPNAnalysisTestinherit directly from TestCase. They collect all the information they needdirectly from the classes under test, in this case the outcome of running aGSPN analysis on some of the example net files. The Abbot library buildson junit to provide extra services for testing the GUI parts of the applica­tion. The junit.extensions.abbot.ComponentTestFixture class has methods tosearch through a GUI hierarchy and locate components, and others to generatebutton, mouse and menu clicks. So, our pipe.gui.GuiFrameTest class is derivedfrom ComponentTestFixture to give it access to these facilities, which are thenused to exercise the main application buttons and menus. A third type of test

52

is made possible by the junit.extensions.abbot.ScriptFixture class, which is thebasis for test scripts written in xml. We derived pipe.gui.FunctionalScriptsTestfrom ScriptFixture and generated a series of scripts to test the main GUI­levelfunctionality of PIPE as thoroughly as we could. The xml test scripts are gen­erated with the help of a script editing tool that is provided with the Abbotpackage. This tool generates xml references to GUI components that allowthe Abbot classes to identify them correctly, and records user actions directlyfrom the application, so that they can be written into the script and playedback. These action steps are then interleaved with assertions which generateexceptions if they are broken, following the same pattern as the other tests.

6.3 Petri­Net Specific TestingThere were several challenges in implementing meaningful tests for PIPE,

mostly related to the script style tests. Firstly, the Abbot classes must be ableto determine exactly which component is being referenced for each action duringa test. They have certain default ways of doing this, looking first at the typeand then at the text a component displays. In the case of some components,such as the Arcs in PIPE, these defaults are not discriminating enough to beable to separate multiple instances. It was therefore necessary to derive a newclass, ArcTester, from the Abbot ComponentTester class and add it to theabbot.extensions.tester package. ArcTester overrides the deriveTag() method,which generates a unique string for each instance of the class being tested.Secondly, the library classes provide a good range of methods to test things suchas the size and location of components, whether certain sequences of actions arepossible, and whether components such as the PIPE Places and Transitionsare added and deleted correctly. However, we also wanted to test things suchas the correct behaviour of a net when it is animated and a particular firingsequence is applied. To do this required extending the testing capabilities sothat we could determine which transitions were enabled at any given time, andfollow the progress of tokens around the net. The scripting mechanism allowsarbitrary calls to the Java code from within the script, so we added methodsto FunctionalScriptTest to accept a reference to a component in the net beingtested and analyse it. To determine the state of the place or transition it is thennecessary to analyse its graphics context to see what image is being portrayedto the user. FunctionalScriptTest does this by creating a new BufferedImageand painting a copy of the place or transition into it. The pixels of the newimage are then checked to verify the colour of the transition (red for enabled)or the image is cut up to count the number of tokens present in a place.

6.4 Evaluation: Test CoverageWe planned to focus our efforts on testing as much of the high­level functionalityas possible, and believe that we have achieved a good outcome. The four xmltest scripts cover 41 individual functions, as described in the Functional TestDirectory (Appendix A). In addition to this, 20 unit tests have been written,

53

some covering the analysis modules that were worked on by the team, and otherstesting some of the GUI classes in a more method­specific way than the scriptedtests.

54

Part III

EVALUATION ANDCONCLUSIONS

55

7 Evaluation and learningsThe group is satisfied that in most cases the tasks it set out to do have beenachieved beyond the level specified.Refactoring of the application was to some extent continued as we worked onadding new functionality and fixing existing bugs, so was somewhat more thor­ough than initially expected. Having said that though, the group felt thatprogress with the refactoring was at times frustrating due to a lack of familiar­ity with the code, with Java and with working on collaboratively on a softwareproject. It is generally agreed that the refactoring might have gone further hadit been done towards the end of development, but of course this could havesacrificed the quality of new functionality that was added to PIPE.The original specification for reachability graph functionality included the gen­eration of flat bitmap images from a supplied DOT­formatted; however, byincorporating the Grappa code it was possible to offer highly interactive graphsto the users, including zoom in and out, scale­to­fit and tool tip (additional in­formation displayed on mouse hover) functionality. Users can reposition nodesand specify layout prioirities.The group is very happy with the quality of the zoom functionality: the featureof being able to drag Nets smoothly across the page is particularly effective, andsomething which wan’t specified initially. It was however chosen as a substitutefor the initially proposed fit to page functionality, so was a case of adaptingthe specification to better suit perceived users’ needs rather than simply addingextra features to the specification.One task which wasn’t completed was the updating of options functionality,which had been specified in the original document and scheduled for the finalweek of the project. We had seen this as a ’nice­to­have’ feature and in the endthe team chose to ensure the main new pieces of functionality were effective andthoroughly tested rather than take something on and run the risk of incorporat­ing a feature we wouldn’t have had time to test. This is certainly functionalitywe would recommend for future generations of PIPE developers.For most of the team, this was the first time they had taken on an existing livedevelopment project. This led us to slightly underestimate the time requiredto gain a good understanding of the application. The presence of bugs andunwieldy code was a legacy of previous contributors. Becoming familiar withPIPE’s code base and its idiosyncratic and in places sub­optimal design was attimes frustrating but was undoubtedly a useful experience, and of course some­thing professional developers working on large­scale projects face on a regularbasis. We therefore consider this to have been a valuable experience, and willmake appropriate allowances for becoming familiar with future coding projects.

56

8 Effectiveness of Scheduling and Group Organ­isation

The Gantt charts on the following pages show the scheduling and status of tasksat the outset, midpoint and end of the project. Task completion fitted remark­ably closely with the planned timings. For the two major pieces of functionalitythe group split into two teams, and we had agreed that if necessary, resourcescould be moved from one task to the other. However, this proved unnecessary,so we stuck to the original plan.

The group had taken time at the outset to understand each other’s areas ofexpertise and interests; task allocation was to some extent influenced by theseand we feel that this led to each member working as effectively as possible.

Emphasising face­to­face communication over detailed written documenta­tion meant that we had flexibility and could respond rapidly to unexpecteddevelopments. Nonetheless, the initial schedule was successfully adhered andit would certainly be wrong to suggest that there was any lack of discipline ororganisation as a result of our approach.

9 Future DirectionsThere are many potential improvements that could still be made to PIPE. Wewould hope that future development continues to be guided by users. Somepossible areas are listed below.

9.1 Hierarchical NetsHierarchical nets are a useful way of building complex nets by representing com­mon sections by a ’black box’ with inputs and outputs, which can be expandedto show the contained sub­net. This was anticipated to be handled by definingan additional Petri net object type, which would be an interface object. Suchan interface would be a source or destination for arcs in a sub­net, providingthe location for inputs and outputs with the enclosing net. An additional objectwould then be used to represent a sub­net, providing input and output locationscorresponding to the interfaces in the sub­net. The sub­net could be edited bydouble­clicking on this representative object, which would open the sub­net ina new tab. PIPE would not require substantial changes to support this, asdemonstrated by the number of new net objects added and the improved abilityto deal with multiple tabs. The demand for it is questionable, as there seemto be few significantly large common net sections, and it is probably easier todraw nets without hiding sections since this may lead to errors. There are alsoissues regarding how such nets would be animated.

57

58

Figure 22: Initial specification schedule

59

Figure 23: Schedule: 15/02/07

60

Figure 24: Schedule: 19/03/07

9.2 Copy and PasteThe ability to cut, copy and paste individual net elements, or entire sectionsof the net, was suggested as a useful feature. It was decided that, due to thehighly specific nature of the data, it would not be necessary to use the globalsystem clipboard, but instead a local mechanism could be used. The anticipatedimplementation was to extend all net objects with serialisation functions, allow­ing them to save and load themselves concisely to and from a memory stream,including dealing with links between objects. This memory stream could thenhold an arbitrary number of objects, which could be recreated in other nets orelsewhere within the same net. However, this serialisation functionality wouldhave to be complete, with implementation in all net objects, for it to be useful.Due to the length of time for which some net objects, particularly arcs, hadnon­final internal representations, it was not possible to implement this withenough time to be sure of completion.

9.3 Undo and RedoThe serialisation of objects would also simplify the ability to undo and redotheir creation and modification, as a traversable history of changes could bemaintained with the addition of some container objects for some group actionssuch as paste and group deletion. As such, it was an extension of copy andpaste and to be implemented after it.

References[1] http://pipe2.sourceforge.net/documents/PIPE2 Final Report.pdf

[2] http://pipe2.sourceforge.net/documents/PIPE2­Report­20050814.pdf

[3] http://pipe2.sourceforge.net/documents/PIPE­Report.pdf

[4] Dijkstra, E.W.: Hierarchical Ordering of Sequential Processes. Acta Infor­matica 1 (1971) 115­138

[5] http://sourceforge.net/projects/pipe2/

[6] http://Java.sun.com/docs/books/tutorial/uiSwing/layout/index.html

[7] http://Java.sun.com/docs/books/tutorial/2d/advanced/transforming.html

[8] http://www.cs.umd.edu/hcil/jazz/index.shtml

[9] http://www.famfamfam.com

[10] http://www.eclipse.org/tptp/

[11] http://www­128.ibm.com/developerworks/Java/library/j­cq03316/

61

[12] M. Ajome Marsan et. al. (1995). Modelling with Generalized StochasticPetri Nets (John Wiley and Sons, 1995, West Sussex)

[13] W.J. Knottenbelt Generalised Markovian Analysis of Timed TransitionSystems MSc thesis, University of Cape Town, June 1996

[14] http://pipe2.sourceforge.net/documents/PIPE2­Report­20050814.pdf p14­19 [last accessed 15/3/07]

[15] http://ostermiller.org/utils/CircularBuffer.html

62