Purpose - two purposes: to allow the model to be converted into java code and updated either in java or in the model; to allow some java code to be converted into a model.
The java things are located in
org.argouml.language.java
.
The Java subsystem is a Loadable subsystem. See Section 4.6, “Loadable subsystems”.
The package org.argouml.uml.reveng is supposed to hold those classes that are common to all RE packages. At the moment this is the Import class which is mainly responsible to recognize directories, get their content and parse every known source file in them. These are only java files at the moment, but there might be other languages like C++ in the future. With this concept you could mix several languages within a project. The DiagramInterface is used to visualize generated NSUML meta-model objects then.
The package org.argouml.uml.reveng.java holds the Java specific parts of the current RE code. C++ RE might go to org.argouml.uml.reveng.cc, or so...
It's an Antlr (http://www.antlr.org) grammar, based on the Antlr Java parser example. The main difference is the missing AST (Abstract Syntax Tree) generation and tree-parser. So the original example generates an AST (a treelike data structure) and then traverses this tree, while the ArgoUML code parses the source file and generates NSUML objects directly from the sources. This was done to avoid the memory usage of an AST and the frequent GC while parsing many source files.
The *context classes hold the current context for a package, class etc. When the required information for an object is available, the corresponding NSUML object is created and passed to the DiagramInterface to visualize it.
The classes in org.argouml.uml.diagram.static_structure.layout.* hold the Class diagram layout code. No layout for other diagram types yet. It's based on a ranking scheme for classes and interfaces. The rank of a class/interface depends on the total number of (direct or indirect) super-classes. So if class B extends A (with rank(A)=0), then rank(B)=1. If C extends B, then rank(C)=2 since it has 2 super-classes A,B. An implemented interface is treated similar to a extended class. The objects are placed in rows then, that depend on their rank. rank(0)=1st row. rank(1) =2nd row (below the 1st one) etc. Example:
In the next diagram, a link goes to an object that is not in the row above:
In this case, insert virtual objects which are linked to the actual target and link to them:
The objects are sorted within their row then to minimize crossing links between them. Compute the average value of the vertical positions of all linked objects in the row above. Example: we have 2 ranks, 0 and 1, with 3 classes each:
A B C : rank 0
D E F : rank 1
We give the super-classes an index in their rank (assuming that they are already sorted):
A:0, B:1, C:2
D, E, F have the following links (A, B, C could be interfaces, so I allow links to multiple super-classes here):
D -> C
E -> A and C
F -> A and B
Compute the average value of the indexes:
D = 2 (C has index 2 / 1 link)
E = 0 + 2 / 2 = 1 (A=0, C=2 divide by 2 links)
F = 0 + 1 / 2 = 0.5 (A=0, B=1, 2 links)
Then sort the subclasses by that value:
F(is 0.5), E(is 1), D(is 2)
So the placement is:
A B C
(here are the links, but I can hardly paint them as ASCIIs)
F E D