Pairwise Comparative Map is written in the Java (1.1) programming language. A fair amount of work went in to the object modeling and an attempt at giving a brief overview of the internal workings or organisation is given here. Please note that JGL Arrays were used for most of the data structures.

Data Engine

PCM works on the basis that the data engine (or underlying data structure) is the most important part of the program- the graphics layer is completely separated from the data engine and is reasonably superficial compared to the storing and processing of the data. This allows you to rework the graphics very easily without disturbing the underlying 'database' too much. For example, half way through the project it was decided to arrange the locus labels differently on the PCM, (to the way they are now). This was a major graphical change but was achieved in a few hours due to the underlying design. A class called PairwiseCanvas is responsible for coordinating the processing of data and this occurs mostly in the data engine objects themselves. PairwiseCanvas eventually paints representations of all these data objects on itself in various colours.

The data engine of PCM is broken down in to a number of hierarchical classes. The lowest level class is called PairwiseLocus. This represents a locus or point on a map and encapsulates the data that this has associated with it- a locus name, a position on a map and the database class from which it was obtained (used to get back to the datum object). The next level up in the hierarchy is the PairwiseMap class. This represents a collection of PairwiseLocus objects arranged in to the linear genetic concept of a map. This also encapsulates the necessary data to describe a map- it has a map title, units, an array of PairwiseLocus objects, extents of the map (the from and to points of the map) and also some data to enable the user to get back to the database objects. The data level above PairwiseMap is PairwiseComparativeMapData. This holds all the data necessary to create a PCM- it contains one or two PairwiseMap objects and an instance of a class called PairwiseHomologys. This class holds all the information required to describe the homologies between the two classes.

Homologies

Although the pairwise homologies look very rigidly specified in the data file, the data implementation of the concept 'homology' is rather more flexible and simple. You can think of the homology relationships as a series of buckets with the names of loci in them. A bucket must have at least two locus names in it and a locus name on a PairwiseMap can only be in one bucket. This information is actually stored in the class PairwiseHomology as a two-dimensional array- there is an array of arrays holding LocusNoAndMap objects. The LocusNoAndMap class holds a string corresponding to the name of a locus and a boolean variable corresponding whether it's on the map that starts out on the LHS or on the RHS.

When the data is being parsed from the PCM file, each DATA line is broken in half. The parser tries to make a PairwiseLocus object from each half and if successful, a relationship or bucket can be created. If one of those loci is encountered again, the locus on the other side of the line (which is the new one) is put in the same bucket.

When a click occurs on the PairwiseCanvas object, it finds out whether the click corresponds to a locus being highlighted. If so, the program then takes the name of the locus and the side of the PCM that it's on and sees if it exists in any of the homology buckets. If so, every PairwiseLocus in that bucket gets highlighted. (Again highlighting works on a data system whereby a boolean variable in PairwiseLocus called highlighted gets turned on and off- the paint method looks at this variable and changes colour if necessary when painting). This system is represented in the diagram below:

The next time a click comes in to the PairwiseCanvas, the first thing that has to be done is to unhighlight all the highlighted loci!

That's the whole data structure! A diagram of the arrangement of classes and those that implement them is shown below.

PairwiseComparativeMap

The class PairwiseComparativeMap extends the Java class Panel. It has a scrollbar on it's right hand side, a panel at the bottom with a number of buttons on it and a PairwiseCanvas object in the centre. When you create a PairwiseComparativeMap with no data file, the scrollbars and buttons etc. are painted but nothing happens in the PairwiseCanvas until an addData method is called with the name of the file to parse. This generates an instance of the class PCM_FileParser which goes through the PCM file and automatically creates all the data objects talked about so far, eventually returning a PairwiseComparativeMapData object. (This would otherwise be a very complicated process.) A new instance of PairwiseCanvas is made and the data object is passed to it.

The encapsulation of the data in such a structure makes the processing of a lot of data very simple. For example, the canvas needs to know the length of the longest locus label on each map. A method was created in PairwiseMap that accesses each of it's PairwiseLocus objects and and finds out the length of each label. An integer corresponding to the maximum length of the labels is returned. All the canvas has to do is call this method once on each of it's PairwiseMap objects. This is much easier than creating such a method in the canvas class- everything is packaged away much more securely and was generally found to be a very robust way of programming such a component.

Painting

The internal workings of PairwiseCanvas had to change quite drastically three-quarters of the way through the project. At the time, all the rectangles, lines and strings that make up a PCM were being drawn directly on to the canvas without any further processing. The problem was that as you are able to stretch out the maps to be tens of thousands of pixels long, huge memory-heavy canvases of metre-squared sizes were being created! The answer was to adopt a vector graphics system.

Three new classes were created: Line, ScreenString and PairwiseRectangle. These held all the information (plus a little more) needed to describe the location and contents of each different type of 'component'. A vastly complicated set of methods for drawing all these components directly on the canvas had already been written so instead of drawing them, an object was created for each line, string or rectangle and stored in one of three arrays.

The concept of the PCM viewport was then conceived. The viewport is the rectangular area of the PCM that you can see. So for example if the map was stretched out to be 10,000 pixels long, the viewport would only be something like 800 pixels in height. When it came to painting time, each object was extracted from the arrays and a special set of algorithms that had been written were used to draw only the bits of these components that were actually on screen. This meant that even though the map might be stretched out to be a huge size, only a compact little Graphics object is created.

The result of all this was a huge increase in the performance of the time taken to paint the map when scrolling. One of the reasons that the paint method took a lot of time before, was that a lot of data processing had to be done whilst taking in to account of things like which map was on which side, whether each map was flipped, running through the algorithms for drawing the scale bars etc. In the new vector graphics system, when you scroll the map the same arrays of lines etc. are used so there's minimum processing to each repaint- no access to the actual data objects is necessary! It is only when the user swaps the maps, inverts a map, resizes a map etc. that this complicated method has to be called again.

ŠJeremy Dickson, October 1998.