<--introduction ^--systems--^ 1D implementation-->

Masses and Springs


I'll now detail the foundation of my Masses-and-Springs library. As I've mentioned before, I've gone through this a number of times. I'm sure if I went back to my Software Engineering texts, I'd find the "correct' way of representing the problem, but I think I've done all right for now.

These are the major players in the system, usually represented by individual threads. Each of them is linked to the Javadoc-generated documentation for their associated classes.


Space is a collection of Masses and Springs. It is the container that is filled by the Collector, that is acted upon by the Physics, and is represented by the Viewer.


The base representation of a node. This might represent a host on a network, a webpage on a website, a person in a family tree or a file in a filesystem. Its value as a mass represents its "repulsiveness" to other Masses, allowing it to push more or less as needed. This can even be variable, so "popular" nodes push harder to keep the associated nodes further away (and thus more readable). Masses have dimensionality, and require a location in Space, thus having an associated Vector.


Vectors represent a location in space, whether a position on a line (in 1D space), on a plane (in 2D space) or in volume (in 3D space). While there are mathematical vectors available in Java libraries, I decided to implement my own for "completeness".


A Spring represents a relationship between two Masses. This might be a connection between two hosts on a network, a hyperlink on one webpage to another, a marriage or birth in a family tree or a file within a directory in a filesystem. Its value represents the "attractiveness" between the two Masses, perhaps to represent physical distance or latency in a network. Springs always connect exactly two Masses. They have no dimensionality themselves, but they should enforce that their two Masses are of the same dimension.


Collectors are the ones that get the data from an outside source and into a system. It might be a traceroute program, finding network links; a web crawler finding links between webpages on a website; a parser reading a genealogical datafile; or a filesystem reader traversing a directory structure. Once it has the data, it is responsible for inserting new Masses into Space, inserting new Springs, and/or possibly changing existing Masses and Springs, if data or relationships change.


Physics continuously applies rules to the Masses and Springs. This is tied closely to the Viewer, as it's usually the Viewer that has requirements on the distances that objects rest at within Space. All interaction between Masses and Masses, and Masses and Springs, happen here -- neither Masses nor Springs know how to interact with each other.


The final representation of the system is seen with the Viewer. Masses and Springs are repeatedly rendered as they are added in by the Collector and acted upon by the Physics. Viewers might allow user interaction, changing zooms, rotating space or pruning trees.


A few other classes make up the base of the system:


This is an extension of Space, but ensures that no Mass or Spring shares a name with another. If an attempt is made to add an item to UniqueSpace that has an existing name, the values of the original Mass or Spring or changed to the new object's.


An extension of UniqueSpace, this environment increases an Mass's mass every time a new Spring is connected to it. This makes popular Mass's repel other Masses with more force, thus making it easier to view the popular Mass amongst its connections.


An extension of Viewer for text-based output. Mainly used for testing purposes, though I suppose you could write a visualizer using the curses library if you really wanted to.


Another extension of Viewer, this provides the foundation for a graphical viewer.


More of a coding class than an implementation one, this exception is used when disparate dimensions are used together. Here is a JAR of the source for the abstract objects mentioned so far.
<--introduction ^--systems--^ 1D implementation-->
©2002-2017 Wayne Pearson