When tasked with the job of designing a new software system, one of the first questions some people ask relates to the tooling that they should use. Such discussions usually focus around the Unified Modelling Language (UML) and whether their organisation has any licenses for some of the more well-known UML tools.
There are many types of UML tool
Unfortunately this isn’t an easy question to answer because there are lots of commercial and open source tools that can help you to do software architecture and design, all tending to approach the problem from a different perspective. At a high-level, they can be categorised as follows.
1. Diagrams only: There are many standalone UML tools and plug-ins for major IDEs that let you sketch simple UML diagrams. These are really useful if you want to be in control of your diagrams and what they portray but it’s easy for such diagrams to get out of date with reality over time. Microsoft Visio or OmniGraffle with UML templates installed are good starting points if you have access to them.
2. Reverse engineering: There are standalone UML tools and IDE plug-ins that allow you to create UML diagrams from code. This is great because you can quickly get the code and diagrams in sync, but often these diagrams become cluttered quickly because they typically include all of the detail (e.g. every property, method and relationship) by default.
3. Round-trip engineering: Many reverse engineering tools also allow you to do round-trip engineering, where changes made to the model are reflected in the code and vice versa. Again, this helps keeps code and diagrams in sync.
4. Model-driven: There are a few model-driven architecture (MDA) tools that let you drive the implementation of a software system from the model itself, usually by annotating the diagrams with desired characteristics and behaviours using languages such as Executable UML (xUML) or Object Constraint Language (OCL). These tools can offer a full end-to-end solution but you do need to follow a different and often rigid development process in order to benefit from them.
You don’t need a UML tool 158
The simplest thing that could possibly work
Even this short summary of the categories of tools available makes for an overwhelming number of options. Rational Software Architect? Visio? PowerPoint? OmniGraffle? WebSe-quenceDiagrams.com? Which do you pick?!
The thing is though, you don’t need a UML tool in order to architect and design software.
I’ve conducted a number of informal polls during my conference talks over the past few years and only 10-20% of the audience said that they regularly used UML in their day to day work.
Often a blank sheet of paper, flip chart or whiteboard together with a set of sticky notes or index cards is all you need, particularly when you have a group of people who want to undertake the design process in a collaborative way. Have you ever tried to get three or four people collaborating around a laptop screen?
Agile methods have been using this low-tech approach for capturing user stories, story walls and Kanban boards for a while now. In many cases, it’s the simplest thing that could possibly work but nothing beats the pure visibility of having lots of stuff stuck to a whiteboard in the middle of your office. Unlike a Microsoft Project plan, nobody can resist walking past and having a look at all those sticky notes still in the “To do” column.
From a software design perspective, using a similarly low-tech approach frees you from worrying about the complexities of using the tooling and bending formal notation, instead letting you focus on the creative task of designing software. Simply start by sketching out the big pictureand work down to lower levels of detail where necessary. Just remember that you need to explicitly think about things like traceability between levels of abstraction, conventions and consistency if you don’t use a tool. For example, UML arrows have meaning and without a key it might not be obvious whether your freehand arrows are pointing towards dependencies or showing the direction that data flows. You can always record your designs in a more formal way using a UML tool later if you need to do so.
Uses for UML
The main reason for using informal boxes and lines diagrams over UML to visualise software architecture is that, in my opinion, UML isn’t often a good fit for what I want to communicate.
The information presented on my context, container and component diagrams can be achieved with a mix of use case, component and deployment diagrams but I personally don’t find that the resulting diagrams are as easy to interpret given the notation. MyC4 approach for visualising software architectures might not make use of UML then, but I still do use it on the software projects that I work on.
You don’t need a UML tool 159 The tools surrounding UML allow it to be used in a number of ways, including fully fledged comprehensive models with their associated repositories through to diagrams that are reverse engineered from existing code. UML can also be used as a simple diagramming notation, either sketched on a whiteboard or within tools such as Microsoft Visio or OmniGraffle that have installable UML templates. Here’s a summary of what I use UML for:
• Processes and workflows: If I’m building software that automates a process or is very workflow based, I’ll often draw a simple UML activity diagram to represent it. UML activity diagrams seem to be ignored by many people but I find that the simple flow chart style of notation works well for a broad range of audiences.
• Runtime behaviour: MyC4approach is really only focussed on visualising the static structure of a software system, but often it’s useful to present the system from a runtime perspective. UML sequence and collaboration diagrams are usually used to show how a number of classes collaborate at runtime to implement a particular user story, use case, feature, etc. These diagrams are still very useful even if you’re not doing design down to the class level. Instead of showing a collection of collaborating classes, you can show collaborating containers or components instead.
• Domain model: I’ll use a UML class diagram if I want to visualise a domain model, with the resulting diagrams typically only showing the most important attributes and relationships. I usually hide the method compartment of all classes on such diagrams.
• Patterns and principles: I’ll often need to explain how patterns or principles are implemented within the codebase (e.g. in theCodesection of a software guidebook), and a UML class diagram is the obvious way to do this. My advice here is keep the diagram simple and don’t feel pressured into showing every last tiny piece of detail.
• State charts: UML state diagrams are a great way to visualise a state machine and the notation is fairly straightforward. Again, I find that people tend to forget UML state diagrams exist.
• Deployment: A UML deployment diagram can be a useful way to show how your containers or components are deployed. Often such a diagram is better presented as an informal boxes and lines diagram, but the option is there.
There is no silver bullet
Forget expensive tools. More often than not; a blank sheet of paper, flip chart or whiteboard is all you need, particularly when you have a group of people that want to undertake the design process in a collaborative way. Unfortunately there’s no silver bullet when it comes to design tools though because everybody and every organisation works in a different way. Once
You don’t need a UML tool 160 you’re confident that you understand how to approach software architecture and design, only then is it time to start looking at software tools to help improve the design process.
The use of UML doesn’t need to be an “adopt all or nothing” choice. A few well placed UML diagrams can really help you to present the more complex and detailed elements of a software system. If you’re unfamiliar with UML, perhaps now is a good opportunity to make yourself aware of the various diagrams that are available. You don’t need UML tools to do architecture and design, but they do have their uses. You don’t need to use every type of diagram though!