There are lots of reasons for using UML (or, more generally, trying to draw diagrams of the software you are building). But one key reason that I think gets overlooked is as an aid to discussion.
In the real world, this is where UML meets the whiteboard and software developers can gather round and augment their discussion with pointing and gesticulating. There’s a lot of power in that, and a common diagram often means common understanding.
And for me the whiteboard or napkin still reigns supreme. Why is this?
Big Box UML
Lots of UML environments are kitchen sink affairs (Rational Rose, Enterprise Architect) and focus on round-trip engineering and such forth – so they struggle with or overlook the use case I’m talking about above.
Personally, I am not sold on forward engineering (that is, turning a diagram into code). But reverse engineering diagrams from the living code seems like a worthwhile exercise, as they can give you a higher level view of the software (much like street maps are useful as they give you a higher level view of what’s on the ground). A particular kind of map can also pick out certain aspects that might be otherwise hidden, and show you just those.
But in any case, these tools do a really atrocious job of presenting the UML diagram to you, and there is usually lots of manual work required to get the diagrams looking good. Here’s an example from Geert Belleken’s blog:
A really ugly UML diagram
A Tedious Job
Here are some things you have to do to make a diagram look readable:
- Make sure the class boxes are the right size to contain their methods and properties. Which gets harder as the model changes, and it throws out the positions of all the elements you’ve placed.
- Make sure the connections don’t overlap one another, as far as possible otherwise your diagram turns into a spaghetti tangle of lines everywhere.
- Try and route your connections in the right direction. So that inheritance flows up the page.
- Make sure your links are orthogonal That is, going horizonally or vertically, not diagonally.
But doing all of these things to make your diagram readable is hard, tedious work. Then, when the code changes, the diagram needs to change too. And it’s someone’s job to update it. Or, it doesn’t get updated, and it becomes stale. The new guy trying to pick up what’s going on has to rely on old diagrams that are six months out-of-date.
(Aside: Geert Bellekens writes an excellent blog post describing these factors using Enterprise Architect here).
A Quick Summary
So we can’t collaborate in real time better than using the whiteboard, because getting a diagram to look good requires all the tedious positioning-work.
On the other hand, using a tool makes the diagrams more persistent, but that is of no benefit if they get stale and need to be redrawn anyway.
Whiteboards vs Tools
Kite9
Kite9 is my attempt to fix this problem, though it’s taking a long time to get right. It has a simple drag-and-drop interface, allowing you to put together diagrams faster than using a whiteboard, but at no cost to legibility. The diagrams are ready for the board meeting as soon as you’ve finished drawing them.
You have enough control over the layout and rendering of the diagrams to make them look the way you want, but all the leg work is done for you.
Kite9 can lay out various UML diagrams and flowcharts quite happily. It is definitely a shorter route to whiteboard-style UML than using one of the big box tools like Rational Rose. And once mastered it’s quicker and simpler than using Gliffy or UMLet any other position-based editor.
Kite9 is free to use and runs in the browser. Go on, try it out. Hopefully, it will rekindle your interest in diagram-based communication.
Alternatively, take a look at this short video which shows it in action:
Here are some examples from the Gallery section of this website:
Class Diagram (Click image to enlarge)
Use Case Diagram (Click image to enlarge)
Upshot
Because Kite9 makes it a cinch to draw good looking UML diagrams, it finally enables real-time better-than-the-whiteboard collaboration. So instead of continually taking your customers new versions of diagrams to look at and agree to, work with them and produce the final diagrams in real time.
Save yourself all the tedious back-and-forth and get it right first time.
Where is Kite9 Going Next?
So, Kite9 currently addresses the “Whiteboard” use case, described above. But as soon as you have a reliable engine for laying out diagrams for you, many other possibilities open up.
Ideally, tools should be able to reverse engineer perfectly readable views of your project based on the source code. That is, creating high-level “maps” of the project, highlighting different aspects. If these diagrams were created automatically as needed, there would never be a problem with them going stale.
Here are some ideas of how Kite9 might evolve to do that:
Collaborative, Persistent, Joined Up Diagramming
One of the central ideas behind Kite9 is that both people and processes can contribute diagrams to projects. People can use the Kite9 Designer, running in the browser to build analysis diagrams or documentation. Processes create some XML to describe a diagram, and use the Kite9 Web Service to get it drawn.
For example, on a software project:
- A build tool could generate some diagrams of the software being built
- A business analyst could generate some diagrams of how the software should work
- A Developer can inspect and diff the diagrams and track changes automatically.
Entities would be shared across diagrams. When something changes name in one diagram, it should automatically update other diagrams that reference it. Coupled with version control and tool support to track changes to the diagrams over time, I believe we will finally arrive at the functionality required to provide the high level maps of software products.
(Note: you can already get diagrams based on your Java code. Other languages will follow)
Stylistic Freedom
Kite9 demonstrates some stylesheet functionality right now, in that you can change the stylesheet of your diagram. However, in the near future it will use Cascading Style Sheets (CSS) more fully. This will mean that anyone can develop a palette of symbols to use in Kite9, for another purpose.
You will be able to combine stylesheets together just like on a web page. This will mean you can mix some UML stylesheets, say, with a stylesheet defining your company’s branding and colour scheme.
Wrapping Up
Kite9 is at the stage where it proves that automatic layout can work, can look good and can save time. But I need some keen diagrammers to use Kite9 and help take it forward. Is anything hard to do? What do people need it to do? What is missing?
Go on, try it out and let me know.
