Two Ways to Visualize Method Invocations

Analogy making lies at the heart of object-oriented software development. Developers make analogies to objects in the domain of interest to yield software objects. It is this concept of classes and instances of these classes that make object orientation such a powerful paradigm. When designing object-oriented software, it is sometimes helpful to visualize more than one abstraction for any given solution. As any developer knows, there are several ways to implement a given solution. The act of visualizing different approaches to these abstractions will often yield something in between. The same idea can be applied to understanding and designing the behavioral aspects of software objects. Designing of the behavior of software objects equates to building methods for those objects and how these methods are invoked. There is more than one way to visualize these method invocations.

Method invocations can be visualized as the sending of a message. In this abstraction, the instance that makes the invocation can be thought of as the sender. The instance that implements the method can be though of as the receiver. The method name and method parameters can collectively be thought of as the message. This approach is illustrated below.



An alternative way to visualize method invocations is as the publishing of an event. In the event publishing abstraction, the instance that implements the method can be thought of as the subscriber. The instance that invokes the method can be thought of as the publisher. The method name and the method parameters can collectively be thought of as the event. This approach, not all that different from the first, is illustrated below.



Which approach is the right one? Either. Since this is simply an abstraction visualization strategy, the right approach is the one that yields the better code, and thus, the better software. However, some developers may find the message method invocation visualization approach to be more useful when designing single, one-time method invocations. The event method invocation visualization might prove more useful when designing a polymorphic method invocation over a set of instances.

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.

Future of visual modeling

Andrew Watson has a white paper about the past, present, and future of visual modeling. What I find interesting in this paper is the strength and solidity the MOF has given the other modeling standards offered by the OMG. For example, the SysML and BPMN standards both use MOF as their foundation.

The paper also gives some interesting statistics for development projects that derive at least some of their code directly from models. Good read.

Activity diagram expansion regions

Activity diagrams are essential to UML modeling. The represent the atomic actions in a software system, usually implemented by some method. One problem in earlier UML activity diagrams was the lack of expressiveness in modeling iterations or loops. Modeling simple looping constructs was pretty straight-forward.



Here, we have a simple command input loop that will continue retrieving user input until an exit command is issued.

This get more complicated when iterating through a set. For example.



Here, we are modeling an iteration through a set. This activity diagram is much more complex than the previous diagram. The real drawback here is that we are showing more of the looping construct here than anything else. This defeats the purpose of the UML; to visually show the problem you are trying to solve. In most cases, iterating through a set is a trivial task and is does not need to be modeled. In the example, we want to show that we are doing something to each element in the set.

Expansion regions solve this trivial looping construct problem. They are a modeling element used in activity diagrams that wrap-around all actions that take place per set element.

Since all the open source tools I use don't support this UML element (I haven't found one that does), advanced UML has a nice example of what expansion regions look like.