Whiteboards and UML Diagrams
by Adrian Bühlmann
A whiteboard is a great tool for discussing ideas with others. I've been using them for several years to draw UML (or pre-UML) diagrams in team sessions.
The Poor Secretary
While being member of some architectural analysis and design group in a larger telecom project, one team member (the secretary) was assigned the job to copy the relevant diagrams by hand on overhead transparencies - a very boring job. Luckily, that assignment was a rotating one.
We did this until we could convince management to provide us with the luxury of a whiteboard that had a print-out function which printed the content of the board on kind of old-style fax-paper. Ok, that was in the last century, so there may be better ones now, I don't know.
We then copied those ugly fax-prints onto overhead transparencies using a photocopier and continued working onto the OHP until the diagrams were so scribbled over that they had to been "clean drawn".
After the team session had finished, the secretary had to enter the diagrams into a clumsy CASE tool, print them on overhead transparencies and bring them to the next team session.
Loosing a Lot of Time
We lost a lot of time with this whole procedure.
Discussing variants and sub-variants of sketched solutions on the whiteboard was particularly hard: print-out, erase and redraw. Reordering diagrams was also very hard. Even if the number of elements was never that high, the whole process was very slow and couldn't match the speed of flow of our ideas.
Furthermore, writing on a larger whiteboard is a bit difficult, because if you stand right in front of that white area while drawing, you are normally too close to the surface to see the diagram. So, sometimes, the person who was drawing had to take a step back in order to see what he was creating. Sometimes that problem caused errors or at least badly readable diagrams.
The CASE tool we were using then wasn't a big help either. Entering the diagrams was way too clumsy to do this in real time during the team session. And I haven't seen a CASE tool appearing on the scene in all those years that have passed since then, that would have met our speed requirements. And those generic drawing programs didn't catch up either.
So, now you know what motivated me to help create Cadifra UML Editor.
Ideas for a UML drawing Tool
I wanted to have a tool that is flexible enough to be used a bit like a drawing program, but knows enough UML to speed up the drawing of UML diagrams. The tool must allow diagrams to be in semantically illegal state, just a bit like when you enter program source code using an editor: the source isn't all the time in compilable state.
But the UML drawing tool can signal syntax errors: for example, if you detach an end of an association from a class in Cadifra UML Editor, the selection square of the detached end is drawn in red color (instead of the usual green).
The Dreaded Redraw Button
And of course, I wanted to have a rock solid working tool.
Everybody thinks that's an easy task, but I remember having seen lots of UML tools that have a "redraw" button. For what the hell do I need a redraw button?
The only reason for the existence of such a button is, that the programmers of those tools could not find an adequate architecture for their software that is able to produce a graphical representation which is always in sync with their model data.
If I need to have a redraw button and I have to use it, then the UML tool produced buggy graphical output and thus has one or more bugs. That's it.
Cadifra UML Editor does not have a redraw button, because it doesn't need it. Certainly, it has - yet uncovered - bugs. We all know that it is impossible to make a program of some minimal level of complexity free of bugs. But I know that our bugs will be on another level.
"This Operation cannot be undone"
And I wanted unlimited rock solid undo/redo without exceptions.
Maybe, you've seen one of those UML tools presenting you a dialog box reading "This operation cannot be undone" - not really calming, isn't it? So, if you do anything with such a tool, you never know whether that action can be undone or not. Such behavior is making me very nervous.
I don't know what the state of all other UML tools these days is, so my experience may be a bit outdated. But I'm sure, there are still tools out there which have their difficulties in that area, be it just that you have to hit the redraw button after some undo/redo.
Arrows piercing Boxes and Connectors going wild
I have seen lots of UML tools that produce printouts with arrows piercing boxes, or texts leaping out of boxes when changing the zoom factor.
While developing Cadifra UML Editor, we have learned, that it's not easy to avoid this kind of bugs.
Maybe, you're not so upset if you see such printouts as I am. But I think it's intolerable. We can fly to the moon and send satellites into orbit; shouldn't it be possible to avoid these kinds of lousy outputs?
Of course, there are generic drawing tools that do not have these kinds of problems. But they do not have deep built-in knowledge of UML, and as a result their behavior for drawing UML diagrams is needlessly clumsy, especially if you look at the behavior of connectors; There are drawing tools (and lots of UML tools) that drive me crazy with their connectors when moving boxes. You have to manually reshape distorted connectors - yet another time waster.
Conclusions
The point in all this is, that the UML tool must be so easy and reliable to use, that you can install it on a notebook computer and take that to the design meeting and enter your UML diagrams in real time into the UML diagram editor. If needed, you can use a beamer to project the screen of the notebook.
I think, sometimes people resort to whiteboards, because they have no adequate UML editor. With Cadifra UML Editor, we believe there are now far less reasons to resort to whiteboards or generic drawing tools.
I have nothing against whiteboards - they do have their merits. But they also have serious drawbacks that you should consider when using them. Don't forget: time is money.
And by the way: it was quite hard to make Cadifra UML Editor that easy to use. So that's the reason why it costs something. What you get in turn is saved time, less stress and good looking UML diagrams.