Hacker News Reader

Comment by cubefox | Hacker News Reader

People who say "UML is useless" basically say "diagrams are useless". Which obviously isn't true. The alternative to UML is everyone inventing their own "diagram language" when they want to visualize something.

Moreover, I think comparing different UML diagrams can also be enlightening for university students. E.g. state machine digrams look quite similar to activity diagrams, but the former emphasize states and the latter actions. And class diagrams let you learn the connection between class structures of OOP languages and database structures.

UML lets you visually learn the abstract higher level concepts without having to rely on irrelevant specifics of practical implementations, or just on dry theoretical text.

View on HN

> everyone inventing their own "diagram language"

This is clearly better than UML. UML is full of shorthands that nobody remembers. That's worse than people making labelled custom diagrams.

Here's an example:

https://buck2.build/docs/concepts/concept_map/

Imagine how much worse that would be with UML arrows.

That concept map example is only a loose association of ideas, where the nodes aren't of the same type (e.g. event, state, class etc), or sorted into types, and apparently included quite arbitrarily. Mind maps are similarly loose. UML is for when you want more precise diagrams about a fixed subject matter.

I agree on the "shorthands", like empty/filled arrows, that people may not know. But there isn't much alternative to such shorthands other than leaving them out completely, which wouldn't be an advantage. In diagrams some information is either conveyed succinctly or not at all. The "alternative" is a block of text instead of a diagram.

That's heavy backpedaling from your earlier

> People who say "UML is useless" basically say "diagrams are useless".

Well, if you only allow concept maps and mind maps, then I guess, yes, you don't actually say (all) diagrams are useless. But you are pretty close.

Not exactly related, but this concept map looks amazingly similar to a semantic ontology. RDF/OWL may not be the easiest encoding, but is quite capable in organizing very large concept schemes.

UML as a projection is fine and a valuable tool.

Starting with UML to describe a set of classes or - worse yet - an entire system is lunacy and a massive red flag.

What's wrong with describing some classes first with a UML diagram?

Nothing wrong, but code is already formal enough that you don't need a formal visual language (UML is not just a bunch of diagrams, it's a formal language). So yeah, a bit of drawing might help to understand, a few ideas from UML might help, but it's not like it is super necessary.

As said, the sequence diagram is a real plus because sequence information is not very well expressed by code, so that diagram has much added value.

I personnaly find UML hard to use becaues if you want to communicate your ideas precisely, you have to know much of its formalism and most often, people who read your drawings don't master its intricacies, so communication quality is no good...

> code is already formal enough that you don't need a formal visual language

Code can be formal enough but in reality it is almost never formal enough. Many constraints can be expressed imperatively (eg. someone validates the number of related objects in the create view) and in unexpected places (across repositories and libraries and maybe not even in code but in some stored procedure). And then it is all in flux and can go away the moment you change your stack.

I don't know if UML is perfectly flexible (maybe?) but its sure benefit is a source of truth that does not depend on your implementation.

The fact that it doesn’t provide any benefit or make things particularly simpler than describing them in code and projecting them to UML if you need a visual diagram. Also, the fact that it is particularly counterproductive if I’m not coding in a pure class-based OOP language, since it presupposes that the solution is centered on class-based OOP.

There a diagrams that are useful before coding, but most of them aren’t part of UML, which is a product of the simultaneous highwater of class-based-OOP-is-everything and pre-Agile industrial software development methodologies, and (except for some isolated bits) poorly fit to anything else.

> Starting with UML to describe a set of classes or - worse yet - an entire system is lunacy and a massive red flag.

I don't think this is right or a well founded opinion. The whole point of any diagram language, including UML, is to provide the means to describe software projects in different views, including class diagrams but also component and system diagrams.

What do you think is the whole point of a modeling language?

> What do you think is the whole point of a modeling language?

Not building an entire system down to class level which is what it is all too often used for (in my experience exclusively by people who have never and cannot code).

It's inefficient, doesn't play well with Software Engineering (diff, version control etc..) and is a relic of the past.

Keep the classes in code, project that into a diagram for the few occasions that is actually needed, and stick to a simplified tool like C4 (https://c4model.com) for your architectural views. Sprinkle some sequence diagrams in too to help describe the key data flows (they're handy next to C4).

Why use C4 over UML? Because the vast majority of the audience don't even know what UML is. So keep it extremely simple and include a key / guide to any of the (few) shapes or colors you use so that it's completely self contained.

The vast majority of UML belongs to be put into the Indiana Jones storage facility along with other archaic ideas such as Function Points / Function Point Analysis.

> Not building an entire system down to class level (...)

That was never the point of modeling languages.

Your baseless assumption is even more absurd when you factor in the fact that modeling languages even express runtime behavior, componente, and packaging.

The main problem with these mindless attacks on modeling languages in general and UML in particular is that the bulk of their retractors clearly knows nothing nor has any direct contact with them, or how they are used in the real world. Their arguments are nothing more than poorly thought through strawmen. Your comment fits well.

> Why use C4 over UML?

See, this is a telltale sign you know nothing about what you're commenting on. Not only is C4 a modelling language like UML but it also covers the exact same responsibilities and features of UML. C4's main selling point is advocating for the representation multiple points of view, and UML is a standard specification to express all the points of view you see fit in a coherent and rational way. There is no C4 vs UML. They have both the exact same design goals and usecases.

I think you are making the mistake of assuming that because something is an important motivation for a class of things, it must also be a good use for every instance of that class.

Sometimes motivations are misguided, and sometimes instances aren’t well fit for major motivations of their broader class.

> (...) it must also be a good use for every instance of that class.

You, and OP, failed to present a single argument supporting the thesis that modeling languages in general, and UML in particular, are "lunacy and a massive red flag."

> Sometimes motivations are misguided (...)

Not only did you failed to support anything in the original anti-diagram rant, now you also tried to support generalizations with hypothetical corner cases involving misuses, which is an absurd argument to make.

So not only do you have zero substance for show with regards to the original anti-UML rant, you also resort to using vague, unsubstantiated strawmen.

This is to be expected. Like many discussions involving technical aspects, generally detractors come from positions of opinionated ignorance.

> You, and OP, failed to present a single argument supporting the thesis that modeling languages in general, and UML in particular, are “lunacy and a massive red flag.”

I failed to support that thesis because I never endorsed it. Pointing out a flaw in a counterargument is not endorsing the argument it is deployed against.

The nice thing about visual stuff is that it is self-explanatory. Instead of needing to read a book about UML first, maybe just use some prose in addition to your diagrams, and you don't need UML at all then. That's also more flexibel.

> it is self-explanatory

It most certainly is not.

The superior alternative is drawing a diagram on a piece of paper to exercise the mind and show to collaborators, and never setting foot anywhere close to the UML tarpit.

There are other types of diagrams beyond what UML formalizes. For example, Data Flow diagrams can be very helpful, but they don't exist in UML (Component, Composite Structure, and Activity diagrams all have similarities with Data Flow diagrams, but none are really a great fit).

Reply on news.ycombinator.com