This page is for anyone who wants to understand the basic implementation concepts behind the UML modeling tool ArgoUML. You should know Java and UML a little bit to understand everything here. For the authors of this page, it sometimes might be hard to keep things understandable, especially for the super-experts among them, so please help by adding comments like "Argh I'm bailing out here!" or "WHAT?" in big bold letters, so that others can fix it. If you feel guilty for only adding such nasty todos, you can in return fix some typos or beautify this page a little bit. ;-)
So, let's have fun! (hopefully)
ArgoUML is a tool for graphically designing UML models. So, after saving your work you'd expect that whatever you designed is stored somewhere (in a file), so you can later continue working on it. But what entities are created under the hood that make up your UML design? Basically two things:
- the model
- the diagrams
Next let's see what these two consist of in more detail, and how they are handled inside ArgoUML. As a first step, see if you can understand this: the model is a set of nonvisual entities with relations between each other, while the diagrams are just views or visualizations of the entities in the model. Can you get an imagination? (If not, then maybe put some marking comment here.) Let's describe the model a little bit more in the next section.
The UML model
If you strip all visual aspects from your UML design, you end up with (UML specific) entities that are nothing more than just a bunch of objects somewhere in memory. They are instances of all the know elements of UML, like: classes, associations, actors, lifelines, states and so on. In Java it is expected that for each elemets there exists a class that can be instantiated in order to create a concrete model element. Now look at you own UML design projects and think about which pieces could be elements, or more precisely, instances of some standart UML model element class like classes, associations, operations and so on. You are beginning to look behind the scenes!
In UML, there is a given set of such model elements. Their names, purpose, properties and relations to other elements are described in the UML superstructure specification. Note that it makes absolutely sense to define these things without mentioning any graphical representation (although the specification contains hints for the graphical notation)!
What would you expect for a tool like ArgoUML that allows to work with UML models consisting of model element instances? Sure, it needs to have a set of classes representing all possible model elements, just ready to be instatiated by the modeling user! Since there are so many different UML elements, and all their properties and semantics need to be carefully implemented, you can imagine that this is a tedious task. But luckily, there are vendors that offer this work for free, ready to be integrated in ArgoUML. We say that their packages include the UML metamodel, because it's a model of all possible UML models, or we speak of a UML model repository, because in addition of the UML metamodel implementation all the handling of changes, change notifications and persistence is also included. I really hope that you have a clear imagination of it now.
ArgoUML currently has two UML model repositories included: Netbeans MDR (which conforms to the UML 1.4 specification) and eclipse UML2 (which conforms to the UML 2.2 superstructure specification). Both have different APIs for manipulating the model, so ArgoUML needs to encapsulate them both behind an own API, which we call the model subsystem. This has the advantage that in every place in ArgoUML, and also in all modules for ArgoUML, we deal with one model API only, and this gives ArgoUML the flexibility to change the concrete UML model repository at any time theoretically.
Note that at this point you perspective on UML might have dramatically changed: UML no longer is 'the graphics' where only experts understand that there is something more behind it. Now you are the expert that can easily think of a UML model without requiring any diagram. But what would this be worth without a graphical visualization?
An UML diagram is a collection of graphical elements in a plane. This is still incomplete, because this also holds for any non-UML drawing. Now what make it an UML diagram, are these two things:
- each graphical element can have a reference to a (nongraphical) UML element
- the appearance of such a graphical element should conform to the UML specification
And that's it! Let's discuss some conclusions from that. If a graphical element (e.g. a rectangle) references a model element (e.g. an instance of the UML class implementing Java class in the UML model repository), then it is said that the rectangle is a graphical representation of an UML class instance. Can a model element be represented by more than one graphical element? Yes, for example in different diagrams (currently ArgoUML doesn't like more then one graphical representation of the same model element on the same diagram, but the UML specification doesn't restrict this). As a conclusion, you can have different views on (overlapping part of) your model in different diagrams! Finally, can there be graphical elements that do not represent any model element? Yes. You can enrich your UML diagrams with any further graphics as much as you like!
It should have become clear that the UML model has no knowledge of the diagrams, so we can say that we have a unidirectional dependency from the diagrams to the UML model. Of course, you'd expect to see the diagrams change when the model is changed. This is handled by events to not introduce a dependency cycle: the model subsystem fires events, and the diagram subsystem listens to them and updates the diagrams accordingly. Wow, you are becoming an expert! (Otherwise: ASK!)
Finally a note on the implementation of the graphics support. ArgoUML currently uses a graphics framework that encapsulates all the handling of the graphics: GEF (on the Tigris site, not to be confused with the eclipse GEF project). Of course, there is now knowledge about UML elements and their visualizations, so ArgoUML has a diagram subsystem that uses GEF and handles everything we mentioned above like model events, references to model elements, and the look of UML elements.
When looking at ArgoUML with the background knowledge about models and diagrams, one starts thinking which parts deal with the model or model elements, which other parts address the diagrams, which parts work with both or even with none of them (these parts do exist!). Distinguishing between model and diagram gains a much deeper understanding on how ArgoUML works than just viewing this tool as some graphical editor! Let's first go through the for most obvious parts with this new perspective.
The explorer pane
The details pane
The property pane
The todo pane