whiteboardvstool.png

Kite9 and UML

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 bad UML Diagram

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.

Integrating Kite9

Kite9 has been designed with integration in mind, and is pretty easy to integrate anywhere. Here are some notes concerning how to do that.

Graphical Integration

Assuming you have some graphics in your application at the moment, how would Kite9 integrate with those? Here are some ideas:

Vertex Shapes

Kite9 uses Java2D to render it’s diagrams, but it speaks SVG via the magic of Batik. What this means is we allow you to define your shapes using SVG outlines or Java2D primitives, so, anything goes. If this isn’t the format you’re after, then maybe we can find a library to manage the conversion. (For example, Kite9 produces PDF happily using the iText library.)

Connection Shapes

Kite9 uses a Java2D brush definition, or some SVG attributes define what a connection should look like. We’re open to other ideas if you have them.

Stylesheets

It is easy to style Kite9 diagrams with different colours and fonts. Take a look around the Gallery for some examples.

Software Integration

If you’re building a web application, you will be laughing with Kite9: we have some Javascript libraries that you can pull in and use to render your layouts within your application. Then it’s just a case of adding behaviours to the web elements to enable your application functionality. But maybe your software is written in .net, Ruby, Pascal or something. Is this going to be a problem? (Kite9 is Java under the covers.) The answer is almost certainly no. Providing you can re-describe your layout using some XML, Kite9 can use it’s knowledge of your shapes to build the layout and tell you where everything should go and how big it is. If you are worried that Kite9 won’t integrate with your project, then please come and talk with us – either use the contact form, email or tweet and we can discuss it. We’d love to hear from you.

Much More

Please come and talk to us about integrating Kite9 into your software – we’d love to talk. And make sure you try out the Kite9 Designer, used to make these videos, so you can try out some layouts for yourself.