ArgoUML 0.30

It looks like ArgoUML 0.30 is now available for download. I look forward to testing it out. This is another step toward UML 2 compliance with open source software modeling tools.

ArgoUML Proof Of Concept

It has been a while in the making but the ArgoUML modeling tool has made available a development version of the 0.30.0 release. What is interesting here is that this development release, 0.29.1, will provide limited UML 2 support. Up until now there has only been UML 1.4 support in ArgoUML.

The ArgoUML software package has been around for quite some time and is relatively stable. The major roadblock for large scale ArgoUML adoption has been the lack of UML 2 support. The problem is that UML 2 has been the standard for many years now. The newer modeling constructs are gaining in popularity and if a tool doesn't support them, it is difficult to justify using it even if it has a great user interface with many other features.

The development version of ArgoUML that provides limited UML 2 support can be downloaded and used. It should not, however, be used in a production environment as is the case with any development release of any software. The model subsystem to use is specified by command-line arguments. No word on whether the UML 1.4 model will still be supported when ArgoUML 0.30.0 is released.

Colour as a visual cue in UML diagrams

I've been using ArgoUML quite often lately to produce some UML diagrams. One thing I've been experimenting with that I haven't done before is using colour as a visual queue within my diagrams. ArgoUML is one of the open source modeling tools I use that supports colour in the element canvas.

For instance, consider the following class element.



This is just a simplistic BlogEntry class. We're not so much concerned with the actual class definition here as much as we are with the presentation. The image about is taken from the default colour scheme in ArgoUML. What if for some reason I wanted to change the colour of this class to green? This is easy in ArgoUML. Simply select the class element and click the Presentation tab. You'll notice there are both fill and line colour fields for element colours. Generally, you will not want to touch the line colour. The line colour defaults to black which means you should stick to light fill colours. In our case, we want to change the fill colour to green, afterward, we end up with the following.



As you can see, this presentation of the class stands out much better than the first. I'm not sure if that is because of the colour green, or simply because it contrasts with the surrounding colour, white. One feature I have noticed that is missing from the ArgoUML presentation repertoire, is the lack of ability to change the colour of class attributes and operations. For instance, if I select and attribute or operation, the Presentation tab becomes disabled. I think this would really come in handy when discussing a particular aspect for a class. Even better, if an API documentation generator were able to user this type of image generation for specific method documentation pages. However, this is a long way off I think.

I've only shown a single element and how a simple change in colour can enhance the visual aspect of the idea you are trying to model. Things start to get more interesting when you start to add a visual colour distinction between element types. For instance, consider the following where I place my BlogEntry class into a package.



There are two elements here, a class and a package. Although the UML defines different notation for different element types, the colour distinction makes for easier reading.

One final example. If we have a new element within the package and we want do emphasize one element more so than the other, are best bet is to do so with colour.



Here, we only have two elements within the package. The fact that they are coloured differently makes it clear that they are different ideas. However, be careful with elements that contain several sub-elements. You are creating a model not a rainbow and rainbows will only make understanding more difficult when it comes to software.

ArgoUML doesn't support abstraction dependencies.

In the UML, an abstraction relationship shows that one element is an abstraction on another. This is rendered as a dependency relationship stereotyped as abstraction. This is not an available stereotype for dependency elements in ArgoUML 2.6. The abstraction dependency doesn't necessarily need to be attached to the dependency directly.

The UML defines three predefined stereotypes in which the abstraction stereotype is attached to. These are derive, refine, and trace. However, when modeling dependencies, these stereotypes aren't available either.

So, if you have a need to specify these types of dependencies in your models, I wouldn't recommend ArgoUML (although I would recommend it for other UML modeling purposes). In fact, I don't even think Umbrello or Gaphor will get this right.