The Unified Modeling Language (UML) was adopted as a standard by the OMG in 1997, almost 20 years ago. But despite its longevity, I’m continually surprised at few organizations actually use it.
Code is the ultimate model for software, but it is like the trees of a forest. You can see a couple, but only few people can see the entire forest by just looking at the code. For the rest of us, diagrams are the way to see the forest, and UML is the standard for diagrams.
They say, “A picture is worth a thousand words“, and this is true for code; even on a large monitor you can only see so many lines of code. Every other engineering discipline has diagrams for complex systems, e.g. design diagrams for airplanes, blueprints for buildings. In fact, the diagrams need to be created and approved BEFORE the airplane or building is created.
Contrast that with software where UML diagrams are rarely produced, or if they are produced, they are produced as an after thought. The irony is that the people pushing to build the architecture quickly say that there is no time to make diagrams, but they are the first people to complain when the architecture sucks. UML is key to planning (see Not planning is for losers).
I think this happens because developers, like all people, are focused on what they can see and touch right now. It is easier to try to code a GUI interaction or tackle database update problems than it is to work at an abstract level through the interactions that are taking place from GUI to database.
Yet this is where all the architecture is. Good architecture makes all the difference in medium and large systems. Architecture is the glue that holds the software components in place and defines communication through the structure. If you don’t plan the layers and modules of the system then you will continually be making compromises later on.
In particular, medium to large projects (>10,000 function points) are at a very high risk of failure if you don’t consider the architectural issues. Considering only 3 out of 10 software projects are successful only a fool would skip planning the architecture (see Failed? You get what you deserve!)
Good diagrams, in particular UML, allow you to abstract away all the low level details of an implementation and let you focus on planning the architecture. This higher level planning leads to better architecture and therefore better extensibility and maintainability of software.
If you are a good coder then you will make a quantum leap in your ability to tackle large problems by being able to work through abstractions at a higher level. How often do we find ourselves unable to implement simple features simply because the architecture doesn’t support it?
Well the architecture doesn’t support it because we spend very little time developing the blueprint for the architecture of the system.
UML diagrams need to be produced at two levels:
- the analysis or ‘what’ level
- the design or ‘how’ level
Analysis UML diagrams (class, sequence, collaboration) should be produced early in the project and support all the requirements. Ideally you use a requirements methodology that allows you to trace easily from the requirements onto the diagrams.
Analysis diagrams do not have implementation classes on them, i.e. no vendor specific classes. The goal is to identify how the high level concepts (user, warehouse, product, etc) relate to each other.
These analysis level UML diagrams will help you to identify gaps in the requirements before moving to design. This way you can send your BAs and product managers back to collect missing requirements when you identify missing elements before you get too far down the road.
Once the analysis diagrams validate that the requirements are relatively complete and consistent, then you can create design diagrams with the implementation classes. In general the analysis diagrams are one to many to the design diagrams.
Since you have validated the architecture at the analysis level, you can now do the design level without worrying about compromising the architectural integrity. Once the design level is complete you can code without compromising the design level.
When well done the analysis UML, design UML, and code are all in sync. Good software is properly planned and executed from the top down. It is mentally tougher to create software this way, but the alternative is continuous patches and never ending bug-fix cycles.
So remember the following example from Covey’s The 7 Principles of Highly Effective People:
You enter a clearing where a man is furiously sawing at a large log, but he is not making any progress. You notice that the saw is dull and is unable to cut the wood, so you say, “Hey, if you sharpen the saw then you will saw the log faster”. To which the man replies, “I don’t have time, I’m too busy sawing the log”.
Don’t be the guy sawing with a dull
UML is the tool to sharpen the saw, it does take time to learn and apply, but you will save yourself much more time and be much more successful.
Bibliography
- Covey, Stephen. The 7 Habits of Highly Effective People
- OMG, Unified Modeling Language™ (UML®) Resource Page
| Reference: | Not using UML on Projects is Fatal from our JCG partner Dalip Mahal at the Accelerated Development blog. |
I agree with the importance of good documentation, but there is a serious flaw in every workflow which includes UML diagrams I have ever seen: diagrams simply get outdated in time, because there is no practical way of keeping them in sync with the code (I know there are tools, but I have never seen them work even decently). Only a few very high level diagrams are still valid after a few months of development. It is also very difficult and very time wasting to produce diagrams with enough detail to be a complete guide for development, in particular when… Read more »
I agree with your comment. The article does little to support the “fatal” click-bait title and does not address the shortcomings of UML for different types of software projects. Adding to your arguments, the usage of UML is more relevant to monolithic projects. Good luck with using UML for more complex architectures spanning multiple languages, REST-services and non-OO approaches.
I understand that design level UML diagrams are harder to maintain because the implementation is changing. Most design level UML diagrams are used to plan out the code and may not be all that useful once the implementation has been decided. However, if the high level (analysis) diagrams are changing frequently during development then this is a sign that the requirements are shifting quite strongly due to a poor requirements process or insufficient time was put into building out the architecture. If either the requirements or architecture process is broken then the problem isn’t the UML diagrams :-) But keeping… Read more »
there are IDE plugins that update UML diagrams and also auto create images, you can also start with the diagrams and create classes.
All is true: UML makes your design better and yes, its not easy to create good diagrams.
To my opinion, UML diagrams, even if not 100% accurate, are much better than comprehensive documents. In particular when working on large & complex projects.
The article talks about development phase but, what about maintenance of the project and knowledge transfer to another team? Diagrams helps in both.
and BTW, Agile is a UML enemy.
Making good diagrams takes practice, if people used UML (or any other diagramming technique) frequently then it would be easy to make diagrams.
But developers only make diagrams once in a while, so they never develop true expertise. Most of the teams that I have trained would complain that the process was too slow. But they stopped complaining after 2 months when it became second nature.
As for UML being an Agile enemy, I’ve set up Scrum in two companies, one Fortune 500 and one start-up where we used UML extensively with a 2 week sprint cycle :-)
I have been a Technical Business Analyst for almost 20 years. I have worked with a wide range of domains both large in the horizontal dimension (big but easy), and in the vertical dimension (technically challenging). I have seen the results of not giving the design phase enough importance. Those companies that allow more time for design, using patterns, all with UML, invariably end-up with much better quality systems; easier to maintain, beautifully coded. Time spent in the design phase is translated in shorter times in development. Corrections in the early design are inexpensive and quicker to implement. Corrections once… Read more »
I’m afraid I have to agree UML isn’t “it” yet — However this UML discussion reminds me of the oft’ quoted: “the map is not the territory” UML is a visual (OO) language, and there are tools around to translate between language and UML with things like XMI, etc. They are not ‘universally accessible’ in the way something line VI, Notepad++, etc. Keeping diagrams and code in sync. is critical. You are better off with a tool to generate UML from code than to try to invest time in maintaining diagrams manually. Also, having a “layout” and “formatting” adjunct for… Read more »
Can you suggest a good resource that evaluates requirements methodologies? Do you have an opinion on which strategies work best, particularly with regard to architecture.