DEV Community

Rafal Pienkowski
Rafal Pienkowski

Posted on

Do developers still need UML?

Hi All!

I'd like to know your opinion on whether UML is still needed in developer's daily work.

Image

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.

Image

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)

Collapse
 
simonbrown profile image
Simon Brown • Edited

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

Collapse
 
s_baltes profile image
Sebastian Baltes

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.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

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 :)

Thread Thread
 
s_baltes profile image
Sebastian Baltes

Thanks :-) I hope this works:

sse14-sketches-poster

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

Thanks a lot I'll look at your research.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

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.

Collapse
 
simonbrown profile image
Simon Brown • Edited

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.

Thread Thread
 
rafalpienkowski profile image
Rafal Pienkowski

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 :)

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

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.

Collapse
 
simonbrown profile image
Simon Brown • Edited

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.

Thread Thread
 
jasogamol profile image
Mark Piffer

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.

Thread Thread
 
simonbrown profile image
Simon Brown • Edited

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.

Collapse
 
stoft profile image
Rasmus Larsson

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.

Collapse
 
reid__klein profile image
Reid

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.

Collapse
 
gsvaldevieso profile image
Guilherme Soares Valdevieso

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.

Collapse
 
allanlrh profile image
AllanLRH

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?

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

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.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

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.

Collapse
 
shiling profile image
Shi Ling

I think that depending on details level we should use UML or unit tests and comments in code as documentation.

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.

Collapse
 
karlkfi profile image
Karl Isenberg

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.

Collapse
 
lluismf profile image
Lluís Josep Martínez

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.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski • Edited

I like this:

'A picture is worth one thousand words'

a good indisputable argument in this discussion.

Collapse
 
sdesyllas profile image
Spyros • Edited

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.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski • Edited

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

because we're working in Agile there is no need to have good documentation, we'll improve that in next spring etc.

And on the end of a day we haven't any documentation.That approach is in my opinion wrong.

Collapse
 
simonbrown profile image
Simon Brown

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.

Collapse
 
bgadrian profile image
Adrian B.G. • Edited

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:

  • for the initial planning of the project
  • after the first month, they should be auto generated from the code (if possible)
  • nowadays developers have to handle many more skills and technologies then just the coding, so we need other types of diagrams like AWS diagrams.
  • for the business side (flows)
Collapse
 
jillesvangurp profile image
Jilles van Gurp

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.

Collapse
 
egraether profile image
Eberhard Gräther

I think there are a couple of issues with UML, that prevent it from being used more often:

  • The diagrams were not designed to give you the whole picture of the software. They are great for illustrating certain aspects, but if you would like to model your whole code-base, it becomes too cumbersome.
  • UML was designed to be usable with just pen and paper. That's why it encodes lots of information only using draw-able shapes. You have to know what everything in the diagrams mean. There is a learning curve that lots of developers don't want to take.
  • UML was not designed for interactivity. You get all the information at once. There is by design no way to hide/filter information.

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.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

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.

Collapse
 
lepinekong profile image
lepinekong

"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.

Collapse
 
databasesponge profile image
MetaDave 🇪🇺

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.

Collapse
 
lwriemen profile image
Lee Riemenschneider

I've been coding in a subset of UML, xtUML, since 1993 when it was still known as Shlaer-Mellor modeling.
UML is much more useful when the diagrams are executable at the analysis level and directly translatable into code, but you have to understand what is worth modeling in UML and what is better left to existing code libraries or other tools. e.g., never try to model mathematical algorithms in UML, or modeling strncpy() isn't going to give you anything that strncpy doesn't already do.
One of the barriers to entry used to be the cost of the tools, but cheaper tools came along. Now the only xtUML tool being actively maintained is free and open source.
Much more information is available at xtuml.org. Tool download and training is available there.

Collapse
 
rainerwinkler profile image
Rainer Winkler • Edited

Hi Rafael,
my answer for developers is yes. I think we need tools that enable us to automatically generate and update visualizations of the code we work with. Doing this work by hand needs to much time and leads to too much errors.
We also need techniques to handle such diagrams as typical applications contain very many objects.
I find diagrams that show dependencies very helpful, but I did neither found the correct diagram for this in UML nor a tool I can use. Especially as I work with SAP ABAP.
After I learned from the Moose platform (moosetechnology.org/), I developed an extractor and a Software Exploration tool for everyday usage in my project, SAP2Moose and Moose2Model. The second can also be used for other languages. Generating a new diagram or updating an old diagram to changed coding takes currently a few minutes. This is much faster than for diagrams I made by hand, I often spend days for such diagrams.
After one year of development I use this tools now for a year in my concrete work as developer (not as architect). Before, I often felt lost in the coding and lost a lot of time searching or trying to remember where I am or where I was. This happens now much less of the time and especially in cases when I cannot use this tools.
There are not many Software Exploration Tools in active development currently, but I see a lot of potential in developing and using such tools, as they will become better and better over time.
Another example of a Software Exploration Tool is Sourcetrail, it can be used for Java, C and C++.
My impression is, that all this tools do not restrict themself to use UML for their diagrams. My impression is, that UML is powerful to design new software. But software exploration tools aim to support developers during their work in real code. Code which may be well developed, but too often this is not the case. I have the impression, that there is yet not enough understanding of how diagrams for this use cases should be made. I also see no urgent need for a standardization here, adding a legend should be enough for now.
Best regards,
Rainer
PS I evaluate currently to enhance the tool to be added to Eclipse and plan to keep it open for all languages

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

Thanks for your advice. I'll look closer to that tool in the nearest future.

Collapse
 
elmuerte profile image
Michiel Hendriks

1: UML is bad and should not be left in a room alone. 2: UML does not scale.

About 1, some UML diagrams (most notably class diagram) do offer a usable way to enhance a message. It should only be used as a supportive image to an explanation. UML is not good it communicating the message by itself, a lot of information is encoded (vaguely) in the diagrams. It is not well understood by all. It does not translate well into all environments. The danger of including an UML diagram is that people will not read the supportive texts, and thereby not implementing it correctly. But I still used UML because it is better than nothing.

As for 2, as your architecture starts to grow the usability and readability of all UML diagrams starts to drop rapidly. The result will be worse than it using UML to begin with.

Collapse
 
fergek profile image
Fernando Gekdyszman

Before standing my point, two things.

1) nowadays as a .net developer you can work first on your design projects, then you scaffold than into classes and then using code first and entity framework you have you db physical schema done as well, and this is so cool.

2) we are in a world where those who work on waterfall cannot think of coding without some sort of documented design (where I believe a unified criteria is so good to have) and people that after misunderstanding agile strive to avoid any kind of documentation.

Now, on my experience it depends on what you are working on. If I need to solve a simple problem with a CRUD, I will probably start writing code. Most likely to neither write a unit test for it. If I'm working in a (for example) calculation engine, I will definitely start with a class diagram. If I need to get in place a workflow that is hard to see, I will start with a sequence diagram. To my point: Design is something you do because you need to. I find senseless to do diagrams just because. When you do it in sessions, getting the team together looking for a solution for a hard-to-solve problem it will be also fun.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

I agree that we need to use dedicated tool for particular job. In my opinion UML isn't golden hammer but it can improve my work (I hope :)).

Be the way I like your example with Code First approach in Entity Framework.

Collapse
 
fergek profile image
Fernando Gekdyszman

Aligned with your thought. There's no silver bullet. We need to be smart enough to use it on our benefit and on leaving it aside when we have something better to use (expandable to frameworks, tools and methodologies ;) )

Collapse
 
philmander profile image
Phil Mander

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.

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

I've the same opinion. Most of people which are complaining on UML simply didn't work with it.