4 ms·

What UML (class diagrams) never really got, is that in order to be simpler, you generally have to leave out details. But that means you cannot generate code fro

What UML (class diagrams) never really got, is that in order to be simpler, you generally have to leave out details. But that means you cannot generate code from a class diagram unless it basically is the code. Why on earth should I use class diagrams to generate scaffolding? What's the benefit? No, I think the only sane use of UML is the other way around: Describe existing code in a human-friendly manner.

hutzlibu 4y ago
"But that means you cannot generate code from a class diagram unless it basically is the code." Yup, thats what I am working on since a few years. Leaving out details can easily be solved with collapsing the code segments.
m12k 4y ago
Exactly. The sane use-case for UML is as a visual aid to help one human to communicate something they know about some code to another human being. It's a visual summary of something. For this purpose "boxes and circles with lines and arrows between them, and text in or next to them" is fine. We don't even need different arrowheads to differentiate "owns"/"consists of"/"inherits from" - a piece of text next to the arrow that says "inherits" is fine (if actually needed and not obvious from the context). Heck, different arrows can mean "inherits from", "displays data from" and "sends a network request to" all within the same diagram, and most humans will pick up on that just fine It seems some people wanted to turn this into a visual programming language instead, and thus kept adding details to the specification to make that possible. But it's not a very good visual programming language. Compare to something like Scratch, or Bubble or Unity ShaderGraph or Unreal Blueprints for examples of what actually usable (though still far from perfect) visual programming could look like. The problem is, by adding all this detailed specification, they actually made UML worse as a product, because it actually makes it harder to use for the first use case, sketching, because suddenly the receiver has to have all this existing knowledge of the protocol to receive what's being communicated. Thankfully most people ignore all that and just stick with boxes and arrows and text, and it works just fine.
jerf 4y ago
You've said in a nutshell another of my issues with "visual programming will solve everything". If you take any non-trivial code base, or generally any non-trivial algorithm, and you have to express it all visually, the result is a useless mess. Another issue with UML is that people find it easy to conflate "UML" with "diagramming in general". Using diagrams to describe existing code can be useful. I'm not a big fan of it honestly but I can tell I'm probably in a minority, albeit a large one, that's fine. But once I'm not able to use UML tooling because I'm no longer building a diagram in the proscribed manner, why should the diagrams I'm producing be UML qua UML diagrams? I can draw boxes and lines without reference to the UML spec; I was before and I am after. In fact I will plead guilty to opening the UML elements pane in several diagramming tools over the years and then just using the stuff in there as little more than graphical macros without regard for what UML thinks they are. Nobody has yet complained. Only one person even noticed it was the UML graphical vocabulary. In the interests of not posting again, there's some discussion about the utility of sequence diagrams elsewhere. I also agree I've gotten value out of them... but I don't draw them with UML semantics. I just draw them. UML demands details I don't have, either due to not yet knowing them or simply being inapplicable in my domain, and it fails to capture things I really care about, so ad hoc diagramming it is. Ad hoc diagramming isn't really that big a problem. I think it's actually a perfectly acceptable solution to a complicated problem because diagramming isn't about the diagram itself, it's about communication, and building a jargon vocabulary as you go is not something we sadly do because we have no other choice, it's actually a good solution. It shouldn't be resisted. It is possible for it to run a little too willy-nilly but the solution to that is to reign it in, not instantly flip to the opposite extreme of the spectrum.
forinti 4y ago
You don't have to use UML with the intention of generating code from it and you can use different levels of detail according to your needs. When you use UML, your goal should be to convey the overall architecture, the modeling of the domain, and some implementation details.
cxr 4y ago
See "Software Diagrams Aren’t Always Correct and That’s OK" <https://wirfs-brock.com/allen/posts/1018 https://wirfs-brock.com/allen/posts/1018>
cryptonector 4y ago
I agree. A schema language that can be used to codegen has to be very rich, and uses of it have to be very detailed. UML mostly only found a niche in writing docs, in which case it would be better to generate the UML from sources, which then requires having access to ASTs or alike. It's no wonder that UML is mostly hand-coded and only for docs, in which case UML is a bit heavy-duty.

hutzlibu 4y ago

"But that means you cannot generate code from a class diagram unless it basically is the code." Yup, thats what I am working on since a few years. Leaving out details can easily be solved with collapsing the code segments.

m12k 4y ago

Exactly. The sane use-case for UML is as a visual aid to help one human to communicate something they know about some code to another human being. It's a visual summary of something. For this purpose "boxes and circles with lines and arrows between them, and text in or next to them" is fine. We don't even need different arrowheads to differentiate "owns"/"consists of"/"inherits from" - a piece of text next to the arrow that says "inherits" is fine (if actually needed and not obvious from the context). Heck, different arrows can mean "inherits from", "displays data from" and "sends a network request to" all within the same diagram, and most humans will pick up on that just fine It seems some people wanted to turn this into a visual programming language instead, and thus kept adding details to the specification to make that possible. But it's not a very good visual programming language. Compare to something like Scratch, or Bubble or Unity ShaderGraph or Unreal Blueprints for examples of what actually usable (though still far from perfect) visual programming could look like. The problem is, by adding all this detailed specification, they actually made UML worse as a product, because it actually makes it harder to use for the first use case, sketching, because suddenly the receiver has to have all this existing knowledge of the protocol to receive what's being communicated. Thankfully most people ignore all that and just stick with boxes and arrows and text, and it works just fine.

jerf 4y ago

You've said in a nutshell another of my issues with "visual programming will solve everything". If you take any non-trivial code base, or generally any non-trivial algorithm, and you have to express it all visually, the result is a useless mess. Another issue with UML is that people find it easy to conflate "UML" with "diagramming in general". Using diagrams to describe existing code can be useful. I'm not a big fan of it honestly but I can tell I'm probably in a minority, albeit a large one, that's fine. But once I'm not able to use UML tooling because I'm no longer building a diagram in the proscribed manner, why should the diagrams I'm producing be UML qua UML diagrams? I can draw boxes and lines without reference to the UML spec; I was before and I am after. In fact I will plead guilty to opening the UML elements pane in several diagramming tools over the years and then just using the stuff in there as little more than graphical macros without regard for what UML thinks they are. Nobody has yet complained. Only one person even noticed it was the UML graphical vocabulary. In the interests of not posting again, there's some discussion about the utility of sequence diagrams elsewhere. I also agree I've gotten value out of them... but I don't draw them with UML semantics. I just draw them. UML demands details I don't have, either due to not yet knowing them or simply being inapplicable in my domain, and it fails to capture things I really care about, so ad hoc diagramming it is. Ad hoc diagramming isn't really that big a problem. I think it's actually a perfectly acceptable solution to a complicated problem because diagramming isn't about the diagram itself, it's about communication, and building a jargon vocabulary as you go is not something we sadly do because we have no other choice, it's actually a good solution. It shouldn't be resisted. It is possible for it to run a little too willy-nilly but the solution to that is to reign it in, not instantly flip to the opposite extreme of the spectrum.

forinti 4y ago

You don't have to use UML with the intention of generating code from it and you can use different levels of detail according to your needs. When you use UML, your goal should be to convey the overall architecture, the modeling of the domain, and some implementation details.

cxr 4y ago

See "Software Diagrams Aren’t Always Correct and That’s OK" <https://wirfs-brock.com/allen/posts/1018 https://wirfs-brock.com/allen/posts/1018>

cryptonector 4y ago

I agree. A schema language that can be used to codegen has to be very rich, and uses of it have to be very detailed. UML mostly only found a niche in writing docs, in which case it would be better to generate the UML from sources, which then requires having access to ASTs or alike. It's no wonder that UML is mostly hand-coded and only for docs, in which case UML is a bit heavy-duty.