Designing notations for use in tools

Tools make available a whole range of facilities for viewing, navigating and manipulating models through diagrams, which are not available when using paper or a whiteboard. Unfortunately, these facilities can not always be exploited if they are not taken into account when the notation is designed: there is a difference between designing a notation to be used in a tool and one to be used on paper.

 

Some of the facilities available in a tool which are not available on paper:

• Expand/collapse. The use of expand collapse buttons to show/hide detail inside shapes, descendants in tree layouts of node-line diagrams, and so on.
• Zoom in/out. The ability to focus in on one area of a diagram revealing all the detail, or zoom out just to see the diagram at various scales.
• Navigation. The ability to navigate around a diagram, or between diagrams, by clicking on a link, using scroll bars, searching, and so on.
• (Virtually) No limit on paper size (though limited screen size). Paper is physically limited in size, so one is forced to split a diagram over multiple sheets, there is no choice. In contrast, there can be a very large virtual diagram in a tool, even if one only has a screen sized window to look at it. But the screen is not such a limitation, if combined with expand/collapse, zoom, and great navigation facilities.
• Automatic construction/layout of diagrams. The ability to construct a diagram just from model information (the user doesn't have to draw any shapes explicitly at all), and/or the ability to layout shapes on a diagram surface. The best diagram is one which is created and (intuitively) laid out completely automatically.
• Explorer. Provides a tree view on a model, which can be as simple as an alphabetical list of all the elements in the underlying model, possible categorized by their type. The explorer can provide an index into models, which provides a valuable aid to navigation in many cases.
• Properties window. A grid which allows you to view and edit detailed information about the selected element.
• Tooltips. Little popups that appear when you hover over symbols in a diagram. They can be used to reveal detailed information that otherwise can remain hidden.
• Forms. An alternative way of viewing and editing detailed information about the model, selected elements or element.

To see how designing a notation for use in a tool can lead to different results than if the focus is paper or whiteboard use, let's take a look at two well-known notations. UML class diagrams and UML state machines. The former, I would argue, has not been well designed for use in a tool; whereas the latter benefits from features which can be exploited in a tool.

 

Class diagrams. A common use of class diagrams is to reverse engineer the diagram from code. This helps to understand and communicate designs reflected in code. Industrial scale programs have hundreds of classes; frameworks even more. Ideally, one would like a tool to create readable and intuitive diagrams automatically from code. However, the design of the notation mitigates against this. Top of my list of problems is the fact that the design of associations, with labels at each end, precludes channeling on lines, where channeling allows many lines to join a node at the same endpoint (inheritance arrows are often channeled to join the superclass shape at the same point). Because labels are placed at the ends of association lines, each line has to touch a class shape at a different end point in order to display the labels. This exacerbates line crossing and often means that class nodes need to be much larger than they ought to be, making diagrams less compact than they ought to be and much harder to achieve a good layout automatically.

 

State Machines. State machines can get large with many levels of nesting. This problem can be mitigated using zoom facilities, by a control that allows one to expand/collapse the inside of a state or a link that launches the nested state machine in a new window. As transitions can cross state boundaries, using any of these facilities means that you'll need to distinguish between when a transition (represented by an arrow) is sourced/targeted on a state nested inside and currently hidden from view, or on the state whose inside has been collapsed. This distinction requires a new piece of notation. In UML 1.5, the notation of stubbed transitions (transitions sourced or targeted on a small solid bar) was introduced to distinguish between a transition which touched a boundary and one which crossed it. Interestingly, in UML 2 this notation has been replaced by notation for entry/exit points. In this scheme, one can interrupt a transition crossing the boundary of a state by directing it through an entry or exit point drawn on the edge of the state. This is the state machine equivalent of page continuation symbols that one gets with flowcharts. However, it can be used to assist with expand/collapse in a tool: collapsing the inside of a state, leaves the entry/exit point visible, so one can still see the difference between transitions which cross the boundary and those which don't. In one sense, this isn't quite as flexible a solution as the solid bar notation, as, for expand/collapse to work in all cases, it requires all transitions that cross a boundary to be interrupted by an entry/exit point. I guess, a tool could introduce them and remove them as needed, but I must confess that I prefer the stubbed transition notation for the expand/collapse purpose - seems more natural somehow.

 

To conclude, designing a notation for use in a tool can lead to different decisions than if the focus is on paper or whiteboard use. However, much as we might like to think that a notation will only be used in a tool, there will always be times when we need to see or create it on paper or a whiteboard, and this has to be balanced against the desire to take advantage of what tools can offer. For example, it is always a good idea to incorporate symbols to support 'page continuation', which will make it easier to provide automated assistance for cutting a large virtual diagram into page-sized chunks (and, as we have seen, such symbols can also support other facilities like expand/collapse). And it is always worth considering whether the notation is sketchable. If not, it may be possible to define a simplified version which is. For example, one could provide alternatives for sophisticated shapes or symbols, that look great in tool, but are very hard to use when sketching.

Comments

• Anonymous
  July 13, 2004
  The problem with design tools is that they do not let a number of people "gather around" and interact (actively) with the design process. Design is best done in groups; and I've always found design tools to be too inhibiting. Perhaps some of work being done at UNC on Facetop will change that.
• Anonymous
  July 13, 2004
  Hal, I agree that gathering round the whiteboard is a great way to feed the creative process. I do it all the time. The notations I tend to use for this purpose are often made up, bastardizations or simplifications of well-known notations, whatever helps with communication really. (And I made the point in the article that whatever notation you design, it should always be possible to produce a version of it amenable to sketching). In my experience the creative design bit around the whiteboard is the fun 5%. That design then has to be turned into something more precise. If you're producing OO code, and your designs round the whiteboard have been OO designs then you can probably go and enter the code directly. Of course, if you then want to compare the designs to what was on the whiteboard or communicate back to other team members (without needing them to wade through the code) then it would be good to be able to extract the diagrams from the code. Then a notation which facilitated the automatic creation of readable diagrams from code would be of benefit, I would have thought. And the same tool can be used to help you understand all that framework code, by creating diagrams directly off it. Or you might like to enter the diagram directly into the tool, and have it generate the (skeleton) code. But you won't want to do this, if the notation has been designed in such a way that it makes the tool difficult to use. So I'm not excluding the use of whiteboards, I'm just saying that if you do want to use tools (and I hope I've provided some convincing reasons for wanting to) then you'll get better tools if the notation is designed with that in mind. Finally, if you like to work in teams, you might also consider pair modeling in front of a tool, just like XP enthusiasts encourage pair programming.
• Anonymous
  July 13, 2004
  And here's the URL to facetop that Hal mentions: http://research.unc.edu/endeavors/spr2004/facetop.html