Why another UML tool?

TL;DR: Developers use UML diagrams mainly for sketching or conceptual drawings. Yet, most UML tools do not support this workflow as they are too complex to use or their diagram options are too generic. Instead, an easy-to-use conceptual designer with minimal UML functionality would provide real value to most users.

Welcome to this first entry in the UMLBoard blog!

I felt it might be a good idea to begin by sharing some ideas that led to the development of UMLBoard. In this first post, I will shed some light on why I think there is still room for a new UML tool.

The mismatch between users and tools

The promises made when UML was introduced were huge: It should be nothing less than a standardized way to formally describe the architectural model of even larger software systems. The model-driven development paradigm even promised to generate code directly from the model. No tedious learning of programming languages or frameworks. Just define your model, press a button, and your software is ready.


Except it never worked that way.


I don’t want to write about the pitfalls of UML, as others have done this already extensively (see here for example). Instead, I’d rather focus on how developers use UML today and what features tools would have to provide to help them do so.

What users really need from UML

Considering a study from 2013 ¹, most developers who use UML do this on a conceptual level apart from the strict UML specification. These results are supported by another study ² in which the authors concluded that most drawings used by software developers were often informal. However, individual UML elements were used occasionally. Actually, this is even such an everyday use case for UML that Martin Fowler created a term for it: uml-as-a-sketch.

But it should also be mentioned that in the first study, a majority of participants did not use UML at all. The main reason here was that, compared to its complexity, it did not provide enough benefit to justify the required resources.

Assuming from these studies that there are still some developers who use UML, we can get an impression of which diagrams are most often used by looking at another survey ³:

And here, it seems that Class Diagrams are the clear winner, as they are used most often and provide developers the newest information.

Interestingly, almost none of the interviewed developers used UML in the initially intended model-first development approach. Honestly, I’m not surprised - I once worked in a company with a model-driven development process, and even changing a simple class attribute took a disproportionate amount of time. Especially setting up the modeling framework for generating the source code took me one or two days. And strangely, after one week, I had to do it again because somehow an underlying library became incompatible with the current model - but these are just my two cents…

So, based on the studies, we can sum up how developers are using UML diagrams in their daily work:

Summary: How Developers use UML diagrams

Since we know what developers expect from a UML tool, let’s see what they often get instead.

What UML tools provide instead

Regarding the large amount of available UML tools, giving a complete overview would be out of scope here. Still, I will at least try to organize the tools into different categories, making it easier to check their benefits or disadvantages.

1. Full-Blown UML Designers

If you’ve ever worked in a company with a model-first philosophy, chances are high that you came across one of these. While they often support many UML diagrams and features (like code generation or round-trip engineering), they are sometimes challenging to master because of their complexity. Don’t believe me? Take a look at this screenshot:

Sure, this screenshot from IBM Rational might be a bit outdated, but current tools don’t look that different.

pro:

con:

2. The More Generic Drawing Approach

This category is about online design tools like draw.io or Lucidchart, often with support for collaborations.

While they are perfect for sketching or conceptual drawings, they have a limitation regarding concrete UML class diagrams: They don’t understand their semantics. For example, suppose you have a class A with a property that references another type B, and you change B’s name. In that case, changes usually are not propagated throughout your diagram. Instead, you have to update everything manually. This might not be a problem for smaller diagrams but can become tedious for larger ones.

pro:

con:

3. Pure Text-Based Tools with Auto-Layout

The tools of this section are similar to the previous ones, with the difference that their interface is purely text-based. For example, yuml.me or PlantUML (or also Mermaid) each use a textual domain-specific-language for defining the diagram content.

Since the diagram layout is calculated automatically, you can focus entirely on describing your idea and skip the tiresome manual adjustment of your boxes’ positions. If you’re familiar with the text format, I bet you’re even faster with editing than using a drawing tool.

pro:

con:

To sum up, there are drawing tools that understand UML (at least to a certain degree), but these are often too complex for drawing simple concepts. And on the other side, we have the more generic designers (either with an interactive or textual user interface), which are well suited for creating sketches. Still, they lack some of the minimum UML features like updating references or validating connections.

The ideal tool would have to be a combination of both - and that’s exactly the point why UMLBoard was born.

Do one thing and do it well

One rule to follow when having limited resources (as side-projects usually have) is to focus only on the features that provide the most benefit. Everything that is not really needed or too complicated should be stripped away.

UMLBoard attempts to adhere to this strategy by focusing on conceptual drawings and essential support for UML semantics but leaving out all the heavy UML stuff.

From all 14 types of UML diagrams, I picked UML class diagrams as they provide the most benefit. Still, users can choose to add freeform text elements anytime if they wish to create more informal diagrams.

Also, all editing happens inline, so users don’t have to click through several modal dialogs to change a specific diagram element. The textual interface is similar to pure text-based designers, allowing users to add or edit members just by typing without any dialog interaction.

To reduce complexity further, UMLBoard implements just a basic set of UML rules and, where possible, tries to translate these rules into more accessible forms. For example, suppose you draw a connection between two classes. It then suggests you the possible types of relations in an understandable way.

But why hand-drawn?

That is quite easy to answer: Because anybody loves hand-drawn sketches!

I remember getting the idea for the hand-drawn look after a presentation where I used the whiteboard effect of Enterprise Architect to give my UML diagrams a bit of a sketchy look. The first question after my talk was: Thanks for the presentation, but how did you draw these cool diagrams?

Interestingly, nobody asked me about the architectural concepts I described with my diagrams…

But besides aesthetics, this hand-drawn effect also has a real purpose: According to research, developers commonly use whiteboards for communicating ideas ². Therefore, giving the tool a whiteboard and sketchy look supports the conceptual idea behind the drawings and provides developers with a familiar context. It also underlines that these drawings are just concepts, and one should not focus on the details.

All in All

I believe there is always a niche for an idea or application that serves users’ needs but has not been filled sufficiently by existing tools. Finding this opportunity might require research, but it’s easier if one is in the same situation as your customers, making it much easier to understand their demands.

By creating UMLBoard, I tried to fill this gap for UML designers by providing an easy way to create conceptual sketches and still support a minimum UML functionality that is fine enough for most cases.

Sure, in the beginning, I had to make compromises, like focusing on a single type of UML diagram and skipping other valuable drawing elements. However, these are all things that can still be added in the future.



So, what’s your opinion? Do you use UML or any kind of drawing in your daily work, and if yes, what features are you missing from your current tools?

Please share your thoughts in the comments or tell me on X @umlboard