Hi All!
I'd like to know your opinion on whether UML is still needed in developer's daily work.
If you're curious why I'm asking about UML please read paragraph below.
Background
I'd like to share with you why I've started thinking about usefulness of UML in everyday life.
I always knew "something" about an UML. I mean I know how to read and write basic diagrams. I'm personally that UML is very useful and I regret that I used it so rarely. I've read some books about solution designing with UML but you know that theoretical knowledge without practice began to be out of date.
So I've decided to take part in UML training. In my company I need to receive consent from my supervisor to take part in a training which has place during working hours. So I wrote an email to my supervisor (which is non technical) and asked him for consent. After few days I met him next to coffee machine I reminded him about my email. He told me:
I didn't forgot about your email. I'd like to ensure that you really want to take part in this training. I was thinking that nowadays nobody uses UML in daily work.
I was a little confused. In the same time my colleague (which is a developer too) started laughing and said:
Nobody uses UML.
That was a shock for me.
In my previous job every architect or designer used UML. I was working with UML too. I started to convince them why I'm thinking that UML is handy. Finally I received a consent to take part in this training :) and I hope the training will take place (minimum number of participant is required to start it).
My opinion
As you can guess after lecture of previous paragraph I'm a big enthusiastic of UML. I think that UML if very useful in any kind of projects and especially in "big" projects they are something that you must have. I my opinion sequence diagrams help understand communication between two or more systems, use case diagrams are helpful to show all product's functionalities and plan future work, component diagram describes system's architecture and shows us a big picture, etc. These are just a few examples of using UML in daily work. I wish I could use UML more often.
In my opinion UML is a basic tool when you're working as a software architect. I wish I would be an architect so I'll learn UML anyway.
What is your opinion about UM? Is UML nowadays useless or useful? UML has become obsolete or just developers forget about it? Or maybe they exists some alternatives to UML which are more trendy and developers friendly?
I encourage you to share your opinion. Thanks in advance.
Oldest comments (64)
Hi, Rafal.
It's a good subject to discuss. I've some opinions about it:
I think UML is a good way to understand complex domains and software architectures. It provides a fast and top-down vision of the problem. However, I don't like it for documentations, class modeling or other complex and variable operations that needs to be maintained. Programmers don't like to maintain documentation, diagrams or any other artifact that isn't the code base.
I like to use UML for fast operations, for example, when i'm working on a complex task and I need to understand an implemantion that needs to be refactored.
I hope this helps.
First thank you that you as an author of first comment :) and yes your comment is very helpful.
I'm the same opinion as you that UML can help with splitting complex task into smaller. In my opinion it's easier and faster to detect come issues with UML. It'll save developer's time in the future.
I agree that creating and updating documentation in UML is painful. I think that depending on details level we should use UML or unit tests and comments in code as documentation. (By the way I'm a big fan of unit tests). As an example, interactions between two system or system components, architecture of used in system components should be done in UML but implementation details should be documented via a unit tests and comments in code.
Agreed.
I use UML diagrams for top-level documentation, like to show how systems are related to each other. And I find it much more practical to document low-level stuff with the code side by side, in the form of unit tests and code comments, because this way its easier to find the documentation when you need it most and more convenient to update. I do use UML diagrams for low-level stuff on the occasions I need to discuss really complex logic with my colleagues before coding starts.
And for databases, I always design the database on ER diagrams before writing the necessary migration queries, because it is easier to visualise how different DB designs might affect read/write efficiencies.
I think all software professionals should learn to read and write UML diagrams. But when and where they will find it appropriate to use is subjective to the nature of the project (outsourced vs. in-house, waterfall vs. agile, cost of installation / updates) and their team culture. Traditional software delivery business models would favour the use UML diagram more.
Regarding the point of maintaining both the documentation and the UML diagrams, aren't there program which will autogenerate/update the UML based on code changes? As well as generate the entire "scaffolding" of classes and functions specified by the UML (can't remember that right word… boilerplate code?)?
If yes, do they work in practice, or are they more trouble than the benefit they provide?
In my previous work I was using Enterprise Architect (EA). This tool has ability both to generate code based on UML class diagram and to generate class diagram based on written code. My team went even further and one of us has written a custom plugin to EA which produce documentation based on defined template. Generated in such a way documents were sending to our customers and subcontractors.
Documentation was generated fully automatically. It looked nice and its update was super easy. I only needed to update documentation in code. Unfortunately this plugin didn't apply to behavior diagrams. Of course developer needed remember to update documentation in code and generate the documentation.
I definitely use UML when drafting a design for code. It's good to be able to get constructive feedback on the code before actually writing it!
Thanks for your opinion.
I totally agree that founding a issue on early phase will save a lot of time and money. There is a huge amount of articles describing that:
Constructive feedback is always invaluable and it will improve our code/architecture/thinking :)
I've almost never used UML but now I feel like I should start
UML has always been on my TODO list.
I've decided that it is the right time to take it from my list, learned it and use it.
Of course I'm encouraging you to start use UML :+1:
In over 20 years of professional programming, UML was relevant for about 6 weeks of that time for me. (and never in production). I've implemented, designed, maintained or otherwise built successful products and services without ever needing UML.
Are you saying in 20 years you have never found it necessary to model or communicate system designs with diagrams or that you have not used UML as the standard for such diagrams?
Used flowcharts, boxes with arrows, post its. Salt cellars. Sequence diagrams. Good old fashioned collaboration. Not UML.
All of which are covered by UML
The answer for every question of this type is always "Yes, this stuff seems dead, but it has actually found a niche somewhere". And then there's the thing with programming. "Is it worth the while to know ?" begs the answer "Yep, if you've got infinite time and swap jobs often you might find yourself in a situation where it might prove useful".
However, there is always a limited budget for learning new stuff and university courses and syllabi are also limited, so you have to optimize for the most frequent technology, that being probably *not using UML but agile technologies such as Kanban or SCRUM. So
In my daily work I'm using scrum methodology. I think it's great but I'm still missing UML :( In my opinion it is hard to come into project especially big one due to lack of big picture of it. I agree that working on particular features which are well defined is easy and it doesn't required UML, but it was hard to me to understand how all things are working all together.Personally I think that a diagram (not necessarily created in UML) would be in this situation very helpful.
i was taught uml at school, and With my 1 year experience in software engineering,I usually use it to design class diagrams and uses cases diagrams !!
But i realy like the class diagram because i Use to for building databases structure of an app using ORM frameworks.
I had UML at university too. To be honest I regret that I weren't listen carefully during UML lessons on my studies. But I'm thinking now is time to fix my inattention :)
I've been using several UML tools (Rational Rose, Together and Enterprise Architect) and I agree with you 100%. Class diagrams are a must to understand a complex hierarchy at a first glance, it's just so much harder just by reading the code. Sequence diagrams are fine if the algorithms are not very complex. Use case are probably the less useful. You're right that these days few people do not like them, I guess it's all the agile hype and "code is the documentation". If UML did not exist, another graphical notation should. As they say, a picture is worth one thousand words.
I like this:
a good indisputable argument in this discussion.
I still see jobs on Cobol or other technologies, so probably there are ppl still using it. UML has an overhead and a small scope, but I like diagrams in general:
As long as diagrams are deemed an effective way of communicating a system design, it makes sense that there are standardized conventions for drawing them.
The problem is that UML does seem to have a bad rep. I think UML is often conflated with just class diagrams or seen as being too "enterprisey" and developers don't realize it's value in the right context.
I've the same opinion. Most of people which are complaining on UML simply didn't work with it.
The biggest problem with UML is that it focuses on codifying relationships and attributes, rather than on making diagrams that are easy to understand at a glance. If I have to train people to read and decode my diagrams, they lose most of their value. This "hidden legend" separates me from my audience and furthers the stereotype of the Architect living in his own little world.
Instead of trying to pack a ton of information into a single diagram, I prefer to have multiple simple diagrams. Present the big picture in one diagram, then zoom in on a specific area or relationship to provide more depth in another diagram.
I do think that being trained on diagramming is worth it, and having a standard can make for better quality training, but assuming that all engineers will have been trained is folly.