Minutes of meeting 21 Jan 2002

Meeting opened 1.10pm

Present: Raphael Goldberg, Peter Howarth, Daniel Justice, Michelle Osmond, Zhu Tan, Aleksandar Trifunovic

What we've done since the last meeting

Only had the weekend since the last meeting, so:

• Alex: Looked further at invariant analysis stuff. Got algorithms, and references (see Links section).
• Raphael: Looked further into graph theory algorithms.
• Michelle: Implemented a simple Aquarium program to test JDOM in actual use, and Java2D as a possible way of drawing the graphics. Program reads in an XML file containing information on the aquarium, outputs to the console and draws a representation to a Swing window using Java2D drawing. (See Links section to try out the code/program.) It works fine in both Windows and Linux on the college machines (you need to download JDOM first).

Further discussion

Module Interface

Previous projects passed the information to modules as an XML file. This is simple, but has the disadvantage that there is no active link from the module to the main program.

The JDOM Document object contains all the information from the XML file in an easily navigable structure, as well as being the main data centre of the program, so it makes sense to pass the module a reference to this Document. The module can then parse the information into another form if convenient. It therefore provides the equivalent functionality to previous projects' methods.

In addition, using the JDOM Document means the module can also update the main Document if it needs to modify the representation, with any changes being reflected in the program.

It can add any elements to the Document that it likes, for example it could store a representation of its results, so that the PNML file would accumulate data about itself (not necessarily in the PNML language).

It can also access any elements, regardless of whether we, as the programmers of the main program, are expecting them to exist. Eg a module which can analyse nets with Inhibitor arcs, even though the main program may not recognise them.

GUI design

A prototype design was drawn up in the meeting (Daniel).

A multiple document interface (MDI) would be ideal - that is, one main program window, and internal windows within that (like Office 97 implementations of Word, Excel). Then we can open up subnets in separate windows while still being able to get at the main net, or even have different nets open. These nets/subnets may be sourced from the same or different .xml files.

Editor - keep to the standard Toolbar for each item, with extra buttons like Rotate, Subnet. Also a standard File, Open, Print etc Toolbar. Menus will provide the same functionality as the toolbars and more. Have a Modules menu. Maybe a Subnets menu, or maybe just a Subnet item(s) under an Insert menu.

View Source - it would be nice to allow access/viewing/editing of the PNML from the editor. Not prominently, as the idea is (usually) to hide the source, but nice to have the option.

Program design

Some confusion arose when considering the program structure with the data being held in a JDOM Document object, rather than our own custom class hierarchy. Where do we put the functions, eg for displaying graphics and performing simulations/animation? Two main possibilities:

• Data in JDOM Document, Object hierarchy with functionality in those parts of the program which need it. The Document would be the main data structure which all other parts of the program (modules, graphics, simulation) may access/modify. One centre of information - consistency. Also modularity and flexibility because components may be easily updated without affecting other areas. Takes advantage of existing official code for dealing with XML structures. Been considering this model so far. Possible ways of implementing graphics section include:
  • Brute force and ignorance - Draw net with Java2D, detect (x,y) of mouse click, search through all the objects in the net to find any which contain (x,y). Not a good approach.
  • Use an object hierarchy (with objects like Place, Transition etc) which is intended to represent the display, but gets its information from the Document object. So the data isn't stored in these Place, Transition etc objects, rather they contain a reference to the Element in the Document which they represent (and using that reference can get the information such as (x,y) or number of tokens). These objects would be subclasses of some useful existing Java class such as JLabel which allows MouseListeners to be assigned, and allows absolute positioning. Hence can write Listeners to deal with interactivity (eg clicking on a Place). How to deal with Simulation?
• Use JDOM or SAX to read in data to our own object hierarchy, which contains both data and functionality. Pass Document objects or the XML file to the modules. Follows the standard design we've been taught for designing a program from scratch - more control, can keep data and functions together. But modules don't need/want to access this hierarchy. Updating data between modules/main program, and extending capabilities of the program may be harder.

To investigate:

• Daniel: Finish off the JDOM summary
• Michelle: Try implementing the start of a Petri net editor using the movable-label idea.
• Tan: look at the other Object based idea.

Next meeting: Tuesday (22nd), 1pm in the common room.

Meeting closed 2:55pm