Some keep arguing that UML is overly complex. They keep looking for “simpler” solutions.
But we never need all the details covered by UML in a single project. You’ll usually end up using only four or five diagram types.
You create use case diagrams to allow non-technical people to understand how you imagine the system.
Then, you identify the main entities and the relationships between them. These are your class diagrams.
As an architect, you need to explain certain behavioral aspects of your system. So, you draw the sequence diagrams, activity diagrams, and state diagrams.
In the end, you’ll have the most important questions answered. And developers won’t keep bothering you with questions like “should this method be async?” or “do we have an error handling strategy?”.
Creating these diagrams is part of the standard, battle-proven object-oriented software design process. Do we have to follow this approach? Well, we could do ad-hoc development. But then be prepared to answer a lot of questions.
Developers will come to you looking for clarifications.
– Hey, Mr. Architect, should we throw an exception here? Or rather return an error?
– Do we need a network controller interface? Or will a class do it?
– How should I handle failures in this particular use case?
– What’s the sales order object’s state if the user kills the app while it has unsaved changes?
You can use UML to address all of these questions.
And you don’t need to know the entire UML standard by heart. Based on my experience, knowing some UML is actually better than knowing all the details. I worked with UML experts who made me understand what “paralysis by analysis” means.
The bottom line:
Don’t get lost in the details.
My course UML and Object-Oriented Design Foundations discusses the fundamentals of object orientation, and delves into UML, the communication standard every software engineer needs to know.