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.
Top comments (64)
UML is definitely worth learning, and there's a lot of good stuff in there when used sparingly. As others have said already, you need to watch that the diagrams don't become out of date when compared to the source code. Also, and I have no empirical evidence to back this up(*), very few people seem to use UML nowadays, so you have to take into account the potential learning curve of your team members. A couple of recommendations ... (1) ensure that everybody on your team understands the abstractions you are using on your diagrams (be careful with terms like "component", "module", "service", "subsystem", etc) and (2) ensure that every UML diagram has a key/legend to make the notation you are using explicit.
This is a pretty large topic, so a couple of starting points you might want to take a look at are my C4 model (this is an abstraction-first approach to diagramming; compatible with UML) and my Visualise, Document and Explore Your Software Architecture talk that looks at diagramming from a number of different perspectives.
(*) I've run diagramming workshops for over 10K people around the world, and most of what I see is "boxes and lines" rather than UML
Regarding empirical evidence, you may also have a look at my research :-)
sbaltes.github.io/projects/sketches/
Section 3.3.3 of my paper on "Sketches and Diagrams in Practice" describes that most sketches and diagrams in our study were rather informal and only 9% of them were classified as "pure" UML diagrams.
I've look on your research. I like your poster: Sketches and Diagrams in Practice very much. It would be great if you could attach it in this discussion. I think it mainly agrees with this discussion participants opinions :)
Thanks :-) I hope this works:
Thanks a lot I'll look at your research.
Hi and thank you for your replay. I aware that other developers which I'm working with should understand me and my language which is in that case UML. In my opinion the biggest advantage of UML is that it is understand by developers accross companies and technologies. I can send a diagram written in UML to 3rd parties and I will be understand (or I hope I'll be :)).
I'll look at C4 model and video from your presentation.
Thanks, you're welcome! Yes, the biggest advantage of UML is that it should be understood by people in different teams and organisations, but that hasn't turned out to be the case unfortunately. As with any notation, it's easy to create diagrams that are meaningless. I always point to these examples ... I'm sure they are "correct" UML, but I don't really understand what that diagram is saying, what the responsibilities of the "components" are, etc.
That's true that with UML we can easily create meaningless diagrams or diagrams which are only understandable for UML experts rather than regular developers. In general we should avoid that. I've been working with one architect which has created such a diagrams. They were hard to understand but I can in easy way generate C# classes based on those diagrams. That was quite comfortable :)
I've just seen your presentation on OpenSlava 2017. It was really nice and descriptive. I like the approach to treat diagrams as a map with a different level of details on it.
Things which I'll keep in my mind:
always add a legend to a diagram
I hate when people are using acronyms, symbols etc. which can be confusing and/or be interpreted in many of ways
create documentation which could be read in 1-2 hours to get an introduction into project
I agree that 1-2 hours should be enough to catch big picture, and should be enough for reader to know where to look in code for more details.
An extra thought. You said that 1 on 10 people knows UML. I'm just wondering how would a group consisting of 10 people who know UML handle with your exercise with diagram creation and interpretation. Would they be confused or would they read it slightly? It could be very interesting and funny experiment.
Once again thanks for your opinion in this discussion.
Thanks again, I'm glad you found the talk useful. :-)
Yes, I've run my diagramming workshop for teams that have told me they "use UML for everything", and surprisingly the diagrams they produced were the same confused collections of boxes and lines. These diagrams were not particularly UML either, although a few UML notational elements (e.g. interface "lollipops", or the "cup and ball", etc) are often thrown in for good measure. Although I ask groups to use pen and paper, some insist on using electronic tools because they "want to get the UML notation correct". This generally doesn't help either, because you get diagrams like this, which are just meaningless.
In summary, even when I work with teams that "use UML", after some discussion, it turns out that most of them only use class and sequence diagrams, which isn't sufficient for describing software architecture (IMHO, of course). I've seem a very small number of people take a "pure UML" approach to my diagramming workshop, but that tends to make matters worse because nobody else understands the notation being used.
A big problem here is that it's really hard to find a good set of example UML diagrams based upon a real case-study, so everybody's view of UML is wildly different. This again comes back to abstractions. If you can figure out what abstractions (and, therefore, levels of detail) you want to show, the rest falls into place easily. This is why the C4 model exists, and why it's an abstraction-first approach.
I am dearly interested what you think about the AUTOSAR specifications if you mind to take a quick look at them. I'll hold back my opinion on this until I've heard at least one educated judgement from someone else.
I've been pointed to AUTOSAR before, but I don't generally work in the automotive industry, so I'm not sure I can offer much in the way of an opinion about it. I hope there is a good amount of benefit given the specification is 270 pages though. :-)
Some other verticals have their own domain-specific modelling languages too; embedded software immediately springs to mind, where I've seen domain-specific "architecture description languages" used. In my experience, even these teams (and those creating comprehensive documentation for regulatory purposes) are seeking ways to improve their communication. For some, UML is a good fit. For others, not so much.
Sequence diagrams for interaction and activity flow diagrams for logic. The rest, not so much. Aside from that I also find use in ER and DFDs. One of the greatest uses is when I want to clarify things for myself.
I hear this same response from a lot of people. I think UML is a great attempt and standardizing modeling and diagrams. Its not perfect, and its huge, but I think worth learning especially in big complex software systems. If you give 10 developers a task to diagram something, and all 10 will have something different, some may be better than others. And you would have to learn what each of the 10's modeling shapes/components meant to that author, every time, instead of already knowing by learning and using UML once.
In big software systems in the enterprise. it makes a lot of sense to make a document/model/diagram that can be read by everyone, and is a proven way that works by software experts to describe or model something in that system using visual shapes/aid. And UML can be extended, its not perfect and doesn't always fit. But I definitely think its worth the time to learn and use, so everyone can be speaking the same language when it comes to modeling.
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.
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.
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.
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.
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.
In reality I believe that UML is rarely used in any workplace and I assume it is related to an agile environment vs a waterfall way of thinking. Waterfall encourages UML as you can spend days and weeks designing the whole project in diagrams and trying to explain every aspect in the application. On the other hand in an agile environment where the iterations are so fast you barely find the time to design uml diagrams and evaluate them as the requirements as constantly changing by the business stakeholders. The only place where I used UML in the past extensively was in a university.
What I find useful even in an agile environment is the use of sequence diagrams to understand the complexity of some systems. But class diagrams, I don't see them in any real project scenario whatsoever.
So we can assume that Agile is killing UML :) I'm just kidding. I agree that UML is useful when we're working in waterfall (as I had in my previous work).
Something I miss in Agile is that developers are forgetting about documentation creation at all. They are excusing himself
And on the end of a day we haven't any documentation.That approach is in my opinion wrong.
Yes, although it sounds very stereotypical, I see this all the time where "agile" teams don't have any documentation (often because they claim that the code is the documentation, which it isn't). This is simply a misinterpretation of the manifesto, and agile in general.
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:
UML was ultimately a flop. Back in the nineties and early 2000s people believed in things like model driven architectures and such things. You would go and develop diagrams primarily and then generate your software. Naive, I know (seen some excruciatingly misguided applications of MDA back in the day). Then agile happened, became the norm and stuff became iterative by default. People started focusing on shipping working software regularly rather than diagrams of software that don't survive the first round of refactoring (i.e. the next sprint) or any form of scrutiny by an actual developer. That's just not a thing in a rapidly evolving software project.
What's the point of having complex artifacts around that lack the ability to co-evolve with your software? There is none. End of story. Basically UML got demoted to something you scribble on a whiteboard or put in some documentation that never gets updated or appreciated. At best you get some generated UML straight from the source code for staring at if that makes you happy. It's an aspirational thing at best in most software projects and necessary but pointless bureaucracy in some places.
So, is UML relevant? Probably still a little bit for some. If you are going to draw any diagrams on a whiteboard, they might at least be as little UML-ish; why reinvent a new way of drawing the same stuff. At least being able to read/glance over the damn things is mildly useful, occassionally. Although, I must say it's been a while since I looked at a UML diagram and found them insightful/enlightening. That just doesn't happen to me a lot. I don't encounter them that often to begin with and when I do they tend to be either extremely high level or just documenting the bleedingly obvious either way.
I think there are a couple of issues with UML, that prevent it from being used more often:
I'm working on a tool named Sourcetrail, which takes lots ideas from UML, but puts them into a fully interactive user interface for source exploration. All diagrams are generated on the fly. Watch our intro video.
Thank you. Sourcetrail looks nice. Unfortunately this tool hasn't support for my main programming language which is C# :(
I want to avoid situation in which I'll send to my customer diagram written in tool he or she doesn't know and doesn't want to learn. But maybe I'm wrong.
"I was thinking that nowadays nobody uses UML in daily work."
Your manager is right, at every meeting / project I did ask the question: "do you use UML or BPMN ?" nearly anybody answers yes even in big corps where official methodoly requires documenation with UML diagrams :)
Bill Gates said: 'Banking Is Necessary, Banks Are Not' I would say 'Modeling is necessary, UML is not' ;) Unfortunately developers do modeling with Framework which is not a rational way to do, some part of Business Modeling are now even done by Graphics designer, which is not rational either.
So I have looked at some other fields I know because I'm an engineer I know the automation industry, they have a specification and modeling tool named grafcet that is very simple, and I'm experimenting with it for now, after many months, I'm now sure it can replace UML, BPMN and many more easily with both better mental mapping for Business and direct mapping with code for ANY programming language high level or low level like assembly.
I'm not a big user of it, but I find sequence diagrams to be a great help in keeping the (RoR) design focused on simple, well-named objects with clear responsibilities, and well-formed messages and data passing between them.
In a previous career as a data warehouse architect I was a big user of data flow diagrams -- they were all I needed for ETL documentation.