Contents
This page is for anyone who wants to understand the basic implementation concepts behind the UML modeling tool ArgoUML. The introduction below assumes a basic understanding of Java and UML. It's sometimes hard for the authors of this page to keep things understandable for beginners, 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, in return you can fix some typos or beautify this page a little bit. ;-)
So, let's have fun! (hopefully)
A conceptual overview
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 non-visual entities with relations between each other, while the diagrams are just views or visualizations of the entities in the model. Hopefully this will give you the basic idea. (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 known elements of UML, like: classes, associations, actors, lifelines, states and so on. In Java it is expected that for each element there exists a class that can be instantiated in order to create a concrete model element. Now look at your own UML design projects and think about which pieces could be such elements, or more precisely, instances of some standard UML model element class like classes, associations, operations and so on. By doing so, 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 sense to define these things without mentioning any graphical representation (although the specification contains hints for the graphical notation)!
From a programming point of view, 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 instantiated by the modelling 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 (using XMI files by the way) is also included. Hopefully, 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 all places in ArgoUML, and also in all modules for ArgoUML, we deal with one model API only, and theoretically, this gives ArgoUML the flexibility to change the concrete UML model repository at any time.
The diagrams
Note that at this point your perspective on UML might have dramatically changed: UML is no longer 'the graphics' where only experts understand that there is something more behind it. Now you are the expert who can 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, but this is also true for any non-UML drawing. What makes it an UML diagram, are the following 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 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 than 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 parts of) your model in different diagrams! Additionally, 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 of the diagrams on 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 no knowledge about UML elements and their visualizations in it, so ArgoUML has a diagram subsystem that uses GEF and handles everything we mentioned above like model events, references to model elements, persistence (in PGML files), and the look of UML elements.
The diagrams are stored in PGML files, which is separate from the storing of the UML model in an XMI file. This explains why an ArgoUML project contains one XMI file and many PGML files (one for each diagram), all included in one zipped '.zargo' file. Unzip it and have a look!
Mapping this to the ArgoUML GUI
When looking at ArgoUML with the background knowledge about models and diagrams, one starts thinking about which parts deal with the model or model elements, which other parts address the diagrams, and which parts work with both or even with none of them (these parts do exist!). Distinguishing between the model and the diagram gains a much deeper understanding on how ArgoUML works than just viewing this tool as some graphical editor! Let's go through the four most obvious parts with this new perspective.
The explorer pane
All the modelling work can be represented by a tree, because both the UML model and the diagrams use the concept of ownership: an entity can own a set of entities, that can be owners again and so on. The explorer pane visualizes all this in a tree, so it contains all project data: UML model elements and diagrams. There is a filtering of unnecessary details to prevent the tree from becoming unusable, so don't expect to see everything here. Filtering and ordering is configurable in so called perspectives. But the main point here is: in the explorer pane you find both model and diagram stuff!
The editing pane
The editing pane is the displaying area for diagrams. Easy. So, if you consider everything that is written above, you'll understand that you can only find the various graphical representations of your UML model here: diagrams only!
The details pane
The only place that is required to absolutely show everything in detail is, well... the details pane. On various tabs you can see every single property and relation for a selected model element. Also, you can change all available aspects of the currently selected diagram element. Finally, the space here is used for additional stuff like modelling wizards that don't fit elsewhere. Bottom line: here you find model and diagram data.
The todo pane
The todo pane is a good example that inside ArgoUML there is more than just UML models and diagrams: the todo lists, generated by the critics subsystem based on a list of configurable design critics. We will not deal with this on this page.
Apply your knowledge now!
How can the writing above help you for further developing ArgoUML? This section gives some easy to follow steps for various tasks.
...