UML has gone out of fashion. Google Trends shows a continuous decline in interest over the last 15 years. Don’t grab a trumpet and join the jazz funeral. Take a rest and learn from listening to UML. It is worth the effort.
Within this article, I will show how you can capitalize on using component diagrams to improve your software architecture.
How I am using UML
My preferred way of using UML is to create a few diagrams as part of a software architecture document. This document has two main purposes:
- [Guidance] It is a guideline for the development activities with a few rules to be followed. Thus it has some regulatory content.
- [Documentation] It acts as the main entry point for understanding the system. It documents major design decisions, e.g., regarding the decomposition or the scheduling concept.
Each UML diagram addresses the aspects as defined by the diagram’s type (component diagram, state machine, activity diagram, etc.). All diagrams together act as spotlights which are distributed over the landscape of the system. From a variety of viewpoints, they are illuminating the areas that need guidance or explanation.
As a software architect, select the places for these spotlights wisely. Search for the dark places…
