3 ms·

Controversial opinion incoming ... The people who should use UML are too lazy to learn it and instead draw weak abstractions in PowerPoint or C4. Those people

by flarg 4y ago

Controversial opinion incoming ... The people who should use UML are too lazy to learn it and instead draw weak abstractions in PowerPoint or C4. Those people are business analysts/requirement engineers/product owners. The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping. Wireframes do the same thing. But not one PO can resist writing reams of non descriptive text and drawing impossible data flows. Developers are not the people who should draw UML.

ok_dad 4y ago
Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints and also become the office manager once the building is done.
- zx8080 4y ago
  > Developers are not the people who should draw UML. > Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints... Okay.
- somat 4y ago
  The code is the blueprints. The running program is the site. Under this metaphor the construction engineer is the compiler. But yeah I feel the office manager bit, that hits close to home.
  - xboxnolifes 4y ago
    Code may be the blueprint for the program, but UML is still the blueprint for the code.
  - cma 4y ago
    > Under this metaphor the construction engineer is the compiler. What about for interpreted languages?
    - ipaddr 4y ago
      They become the parser
olliej 4y ago
No, UML was not about, nor enabled, lightweight prototyping, the exact opposite. Formal UML as taught and "used" was king of the waterfall and was largely presented as, and definitely taught as, a "design the architecture of your software, then write the code" model. Hence CASE tools - my universities software engineering courses used a product called Together, and Together maintained _live_ updated UML, but the more important (to those teaching UML) feature was that when creating or changing the UML the code would be updated. People bemoaning the "death" of UML mean the specific and formal standards of notation, many of which were not relevant or even applicable to software. The general diagramming is still heavily used in software development, and despite their claims I disagree with the author's assertion that everyone uses incompatible notation.
- swader999 4y ago
  Yeah it felt like in UML was shoved down our throats by tool vendors like Rational Rose. The dream of models generating code and systems.
- Gigachad 4y ago
  I remember using an IDE which would auto generate these kinds of diagrams and for more than the most basic hello world app, the diagram would be this massive spaghetti where you have to zoom way in to see anything.
- dwaite 4y ago
  Together was a UML-as-code tool, and I never saw how you could deploy a working system using it. We used it for a while, having entire separate 'code' projects to maintain artifacts. One team tried to use it within their project. Together helpfully would delete a bunch of code when someone decided to start over fresh on a diagram. The lesson Together taught me was, sometimes optimizing/automating part of a process is just a bad idea. IMHO, UML worked best when you actually built diagrams to show a relationship or part of a process, rather than treating it as some sort of generated view of the system. A full class diagram for any non-trivial system is a bird's nest. A full sequence diagram conveys nothing to the reader that the code itself wouldn't. There's a reason most repair manuals are illustrated with more than a single exploded view of the full car. Also - Rational was very much trying to break waterfall by going solidly toward more cyclic processes. It was just geared to be a very formal (but adaptable) model. I would argue that Agile was actually still part of an evolutionary chain from RUP - but 'sold' in an entirely different manner.
mdmglr 4y ago
> The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping. Nothing in UML is lightweight. As you mentioned there are rules and diagram types to learn. > Developers are not the people who should draw UML Maybe not UML but developers should draw more. Diagrams are a great way to communicate architectures, data flow, abstractions, etc. I would save many hours if diagrams where available instead of having to read code.
inkyoto 4y ago
> The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping. That was certainly not the original premise of UML. Booch et al came up with a grand idea «once you have UML, you will never have to write the code again and our tools (Rational Software) will generate your applications for you from the UML diagrams where everything is an object». UML took ages in evolution and development, it was a collection of seemingly unrelated (or loosely related at best) diagramming approaches that, in practice, was rarely used in its entirety due to: 1. Being incomplete or lacking altogether in early stages of its evolution; 2. Being very heavy-weight and prohibitevely expensive tools (Rational Rose, doh!) from one vendor; 3. Generated code was bloated at best or did not work at worst and required substantial amounts of manual fixing up. Most importantly, UML was initially focused on interactions taking place within a single isolated system whereas the industry had already started moving towards a distributed application interaction model. There are a few useful parts in the UML universe, though. Sequence and ER diagrams are useful today, class diagrams can have some occasional limited value – to understand legacy frameworks and systems but are nearly never appropriate for describing new data models. Component diagrams are generally useful but almost no-one can read and understand them anymore. And cross-system, end-to-end business process view centric, interactions are much easier to represent with simple, BPMN-style, swimlane diagrams – the business crowd also finds them easy to read and comprehend. UML, as a whole, was moribund from the beginning.
- andrewflnr 4y ago
  Uh, Grady Booch begs to differ. https://twitter.com/Grady_Booch/status/1388930413280727042?s=20&t=h1JTOY0uacko2ISG5kSapw https://twitter.com/Grady_Booch/status/1388930413280727042?s...
  - inkyoto 4y ago
    Ha, an interesting link, thanks. It comes off as an attempt to atone for former sins and a rather not very convincing one (not to me, personally, anyway). Booch goes on to state: > The UML was originally designed to be a language for visualizing and reasoning about a system […] Which system, an existing one or the one being designed? Most existing systems don't have the extensive UML diagramming that supplements the system documentation, so if we are going to use UML to reverse engineer an existing system, the UML diagrams are nearly guaranteed to be incomplete and miss a crucial aspect of the system or a few. Booch actually confesses in being a reverse engineering aficionado: > I have always been a fan of reverse engineering notation from code. If we are using UML to reason about a system being designed, the UML diagramming and coding are disjoint activities undertaken by distinct people: architects or designers produce UML diagrams and software engineers interpret them. The interpretation is always a subjective affair and is nearly guaranteed to diverge from the diagrams at some point. Booch goes on to attest the same further down the thread: > The code is the truth, but not the whole truth. So, Rational Software had Rational Rose that generated the code from UML diagrams in an attempt to bridge the gap (but not as an attempt to be a visual programming language) between the design in UML and the interpretation of the design by a human being, and that did not work.

by flarg 4y ago

ok_dad 4y ago

Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints and also become the office manager once the building is done.

zx8080 4y ago
> Developers are not the people who should draw UML. > Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints... Okay.
somat 4y ago
The code is the blueprints. The running program is the site. Under this metaphor the construction engineer is the compiler. But yeah I feel the office manager bit, that hits close to home.
- xboxnolifes 4y ago
  Code may be the blueprint for the program, but UML is still the blueprint for the code.
- cma 4y ago
  > Under this metaphor the construction engineer is the compiler. What about for interpreted languages?
  - ipaddr 4y ago
    They become the parser

olliej 4y ago

No, UML was not about, nor enabled, lightweight prototyping, the exact opposite. Formal UML as taught and "used" was king of the waterfall and was largely presented as, and definitely taught as, a "design the architecture of your software, then write the code" model. Hence CASE tools - my universities software engineering courses used a product called Together, and Together maintained _live_ updated UML, but the more important (to those teaching UML) feature was that when creating or changing the UML the code would be updated. People bemoaning the "death" of UML mean the specific and formal standards of notation, many of which were not relevant or even applicable to software. The general diagramming is still heavily used in software development, and despite their claims I disagree with the author's assertion that everyone uses incompatible notation.

swader999 4y ago
Yeah it felt like in UML was shoved down our throats by tool vendors like Rational Rose. The dream of models generating code and systems.
Gigachad 4y ago
I remember using an IDE which would auto generate these kinds of diagrams and for more than the most basic hello world app, the diagram would be this massive spaghetti where you have to zoom way in to see anything.
dwaite 4y ago
Together was a UML-as-code tool, and I never saw how you could deploy a working system using it. We used it for a while, having entire separate 'code' projects to maintain artifacts. One team tried to use it within their project. Together helpfully would delete a bunch of code when someone decided to start over fresh on a diagram. The lesson Together taught me was, sometimes optimizing/automating part of a process is just a bad idea. IMHO, UML worked best when you actually built diagrams to show a relationship or part of a process, rather than treating it as some sort of generated view of the system. A full class diagram for any non-trivial system is a bird's nest. A full sequence diagram conveys nothing to the reader that the code itself wouldn't. There's a reason most repair manuals are illustrated with more than a single exploded view of the full car. Also - Rational was very much trying to break waterfall by going solidly toward more cyclic processes. It was just geared to be a very formal (but adaptable) model. I would argue that Agile was actually still part of an evolutionary chain from RUP - but 'sold' in an entirely different manner.

mdmglr 4y ago

> The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping. Nothing in UML is lightweight. As you mentioned there are rules and diagram types to learn. > Developers are not the people who should draw UML Maybe not UML but developers should draw more. Diagrams are a great way to communicate architectures, data flow, abstractions, etc. I would save many hours if diagrams where available instead of having to read code.

inkyoto 4y ago

> The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping. That was certainly not the original premise of UML. Booch et al came up with a grand idea «once you have UML, you will never have to write the code again and our tools (Rational Software) will generate your applications for you from the UML diagrams where everything is an object». UML took ages in evolution and development, it was a collection of seemingly unrelated (or loosely related at best) diagramming approaches that, in practice, was rarely used in its entirety due to: 1. Being incomplete or lacking altogether in early stages of its evolution; 2. Being very heavy-weight and prohibitevely expensive tools (Rational Rose, doh!) from one vendor; 3. Generated code was bloated at best or did not work at worst and required substantial amounts of manual fixing up. Most importantly, UML was initially focused on interactions taking place within a single isolated system whereas the industry had already started moving towards a distributed application interaction model. There are a few useful parts in the UML universe, though. Sequence and ER diagrams are useful today, class diagrams can have some occasional limited value – to understand legacy frameworks and systems but are nearly never appropriate for describing new data models. Component diagrams are generally useful but almost no-one can read and understand them anymore. And cross-system, end-to-end business process view centric, interactions are much easier to represent with simple, BPMN-style, swimlane diagrams – the business crowd also finds them easy to read and comprehend. UML, as a whole, was moribund from the beginning.

andrewflnr 4y ago
Uh, Grady Booch begs to differ. https://twitter.com/Grady_Booch/status/1388930413280727042?s=20&t=h1JTOY0uacko2ISG5kSapw https://twitter.com/Grady_Booch/status/1388930413280727042?s...
- inkyoto 4y ago
  Ha, an interesting link, thanks. It comes off as an attempt to atone for former sins and a rather not very convincing one (not to me, personally, anyway). Booch goes on to state: > The UML was originally designed to be a language for visualizing and reasoning about a system […] Which system, an existing one or the one being designed? Most existing systems don't have the extensive UML diagramming that supplements the system documentation, so if we are going to use UML to reverse engineer an existing system, the UML diagrams are nearly guaranteed to be incomplete and miss a crucial aspect of the system or a few. Booch actually confesses in being a reverse engineering aficionado: > I have always been a fan of reverse engineering notation from code. If we are using UML to reason about a system being designed, the UML diagramming and coding are disjoint activities undertaken by distinct people: architects or designers produce UML diagrams and software engineers interpret them. The interpretation is always a subjective affair and is nearly guaranteed to diverge from the diagrams at some point. Booch goes on to attest the same further down the thread: > The code is the truth, but not the whole truth. So, Rational Software had Rational Rose that generated the code from UML diagrams in an attempt to bridge the gap (but not as an attempt to be a visual programming language) between the design in UML and the interpretation of the design by a human being, and that did not work.