Click on the links to see the full size diagrams.
You can also use the diagrams below. They are scaled down a bit but you can right click on a diagram and save it to your hard drive. Then use your favorite picture viewer.
Class diagram for tree and movement
The diagram focuses on the classes needed for wireframe models (trees of nodes and branches only) and movement through these. It shows:
- the Java packages;
- their classes;
- the relationships between the classes.
Every “use” or “use all” relationship corresponds
with a Java import statement.
Also, inheritance is used a few times, this is the Java extends
keyword.
And finally, two interfaces are implemented, this is the Java
implements keyword.
Class diagram for animation and surfaces
The diagram focuses on the additional classes needed for animation and sufaces. Unlike the previous diagram is does not show every single “use” relationship but rather it shows:
- the most relevant instance and static variables;
- the most relevant methods;
- the aggregation and inheritance relationships that build the structure of the animation and surfaces classes;
- the types used in those inheritance relationships that employ generics.
Sequence diagram for initialization
The diagram shows:
- how the Tree class creates two Node objects and a Branch object;
- how the Tree class calls three internal methods to determine several constants;
- how the Tree class calls the findRepresentation() method of a Screen object;
- how the Screen object calls the findScreenRepresentation() method of the Branch object;
- how the Tree class creates a MainWindow object which triggers the creation of all GUI components, for example a Frame object and a TreeCanvas object;
- how the MainWindow object calls the setVisible() method of the Frame object, which leads to the AWT calling the update() method of the TreeCanvas object;
- how the paint() method of the TreeCanvas object calls the getHasScreenRepresentation() method of the Branch object to check if there is a valid screen representation of the branch;
- if so, the paint() method calls two getters on the Branch object to get the calculated enhancement effects;
- and the paint() method calls four getters on the Branch object to retrieve the screen coordinates, after which the (wireframe) line can be drawn.
The lifeline of the Tree class is the main() method.
The diagram shows the creation of two Node objects and one Branch object but
of course the mechanism is the same all the time.
The paint() method is called by the update() method in the TreeCanvas
object. The latter is not called by our code but invoked by the AWT when
the Frame object is made visible.
Although the main() method in the Tree class finishes, the GUI components
live on because the AWT has its own thread.
Sequence diagram for user control
The diagram shows:
- how the ScreenControlMouseAdapter object, created during initialization, receives a MouseEvent in the mousePressed() method after the user presses a control button;
- the check that the left mouse button was pressed and that there is no ScreenControlRunner thread alive;
- how the ScreenControlMouseAdapter object creates a new ScreenControlRunner thread;
- how the ScreenControlMouseAdapter object passes the reference to the pressed button to the ScreenControlRunner object;
- how the ScreenControlMouseAdapter object starts the ScreenControlRunner thread;
- how the ScreenControlRunner thread causes the screen plane to move as long as it is not time to quit;
- how the ScreenControlRunner thread recalculates several vectors for each move;
- how the ScreenControlRunner thread calls the findRepresentation() method of the Screen object, compare with the initialization diagram;
- how the ScreenControlRunner thread calls the repaint() method of the TreeCanvas object, which leads to the AWT calling the update() method of the TreeCanvas object, compare with the initialization diagram;
- how the ScreenControlMouseAdapter object receives a MouseEvent in the mouseReleased() method after the user releases a control button;
- the check that the left mouse button was released and that the ScreenControlRunner thread is alive;
- how the ScreenControlMouseAdapter object effectively terminates the ScreenControlRunner thread by making it time to quit.
The ScreenControlRunner class implements the Runnable interface. This
thread is distinguished from the main thread by using blue instead of
yellow color (or a darker shade, for the color blind).
Note that this use of color is not an official UML visualization but it
works for me. The UML par
control operator seems awkward to use
here.
The Thread object will exist even after the ScreenControlRunner thread has
terminated but it will be garbage collected when the object reference
variable is assigned a new Thread object after the user presses another
control button.
State diagrams for parsing a tree file
The diagrams show a state machine which models the use case ‘Parse tree file’. The implementation of that use case forms a major part of the code that reads a tree from a file. See the Technical description of tree package, which is part of the documentation accessible from the documentation link on the home page.
The Tree Project is an ongoing project so the design may change in the future!