4 ms·

it's not really UML, at least not standard conform I think through that's kinda true for a ton of tooling using the word "UML" and in many case you also somew

it's not really UML, at least not standard conform I think through that's kinda true for a ton of tooling using the word "UML" and in many case you also somewhat want something which is less precise (and verbose) then UML theoretically is

vidarh 3y ago
> and in many case you also somewhat want something which is less precise (and verbose) then UML theoretically is This tends to be "the" big problem with UML (and similar): Very few people care about, or have a reason to, stick 100% to UML. They want to "speak diagrams", and just like written or spoken language, our syntax and semantics is context dependent and dependent on the dialect and speech patterns and understanding of those we speak to. So the "UML" people learn is often a dialect of sorts closer or further from the formal grammar, and a lot of tools fail to take that into account and try to force you into conformity. We accept that for programming languages, yet we still use pseudo-code in all kinds of contexts, but diagrams are one step up - one of the things we "escape to" when writing formal code is too complex or we want to explain things to people who don't know or care about the details. There's a significant strain there between those conflicting goals of diagrams as communication, and the evolution of CASE tools that wants diagrams to be formal, that is much closer to how we deal with natural languages (people arguing over formal use vs. slang) than with programming languages, and it's fascinating.
- layer8 3y ago
  It’s a pity, because one benefit of UML would be that everyone speaks the same language. Before UML, there were many different modeling notations [0], and the goal with UML was to create a single interoperable unified language. This was successful insofar as it displaced the previous object modeling languages. However, it would be nice to have that benefit of a modeling lingua franca not only in modeling tools, but for casual usage as well. [0] https://en.wikipedia.org/wiki/Object-modeling_language https://en.wikipedia.org/wiki/Object-modeling_language
  - tannhaeuser 3y ago
    UML sucked so much, it took OOP down the drain along with it. Unfortunately, UML also had to contaminate nascent BPM modeling, by making BPMN a fscking "profile" of UML. I'll never forget the look of once motivated process modelers when they learned they need "stereotypes" and such - the result of their modeling was more like a psychoanalysis and beyond useless. Ever had to deal with RMI, EMF, MOF, and UML's weird and unsound meta-modelling "in itself" for exchanging model data modulo the worst of XML? To hell with it.
    - eru 3y ago
      OOP was never a good idea (apart maybe for GUIs), UML or not. What's BPM?
      - Qwertious 3y ago
        Business Process Modeling, according to wikipedia. https://en.wikipedia.org/wiki/Business_process_modeling https://en.wikipedia.org/wiki/Business_process_modeling
    - tut-urut-utut 3y ago
      So true, but had to downvote because of „fscking“.
  - vidarh 3y ago
    Yes, but the problem of this thinking is that when communicating we inherently look for shortcuts and shaping language to the context rather than sticking strictly to a grammar and a dictionary, and to be successful at defining a natural language (and that includes diagrams) you need to accept that the job is 90% describing reality and 10% trying to shape it. If that. UML has been reasonably successful where it described reality, or tried to gently shape things by proposing things that were close to how most people already did things. Much less so where it tried to prescribe a reality not aligned with how people communicates, or where it has not kept up with the way that has evolved. It'd be more successful at being a lingua franca if the focus was more on documenting how people actually use diagrams, and just provide gentle nudges in one or the other direction where use is inconsistent. I think this is also why so many people hate UML tooling - because it forces you to communicate in this strange dialect that is very different from how most of us communicate with diagrams, and that most people find awkward.

vidarh 3y ago

> and in many case you also somewhat want something which is less precise (and verbose) then UML theoretically is This tends to be "the" big problem with UML (and similar): Very few people care about, or have a reason to, stick 100% to UML. They want to "speak diagrams", and just like written or spoken language, our syntax and semantics is context dependent and dependent on the dialect and speech patterns and understanding of those we speak to. So the "UML" people learn is often a dialect of sorts closer or further from the formal grammar, and a lot of tools fail to take that into account and try to force you into conformity. We accept that for programming languages, yet we still use pseudo-code in all kinds of contexts, but diagrams are one step up - one of the things we "escape to" when writing formal code is too complex or we want to explain things to people who don't know or care about the details. There's a significant strain there between those conflicting goals of diagrams as communication, and the evolution of CASE tools that wants diagrams to be formal, that is much closer to how we deal with natural languages (people arguing over formal use vs. slang) than with programming languages, and it's fascinating.

layer8 3y ago
It’s a pity, because one benefit of UML would be that everyone speaks the same language. Before UML, there were many different modeling notations [0], and the goal with UML was to create a single interoperable unified language. This was successful insofar as it displaced the previous object modeling languages. However, it would be nice to have that benefit of a modeling lingua franca not only in modeling tools, but for casual usage as well. [0] https://en.wikipedia.org/wiki/Object-modeling_language https://en.wikipedia.org/wiki/Object-modeling_language
- tannhaeuser 3y ago
  UML sucked so much, it took OOP down the drain along with it. Unfortunately, UML also had to contaminate nascent BPM modeling, by making BPMN a fscking "profile" of UML. I'll never forget the look of once motivated process modelers when they learned they need "stereotypes" and such - the result of their modeling was more like a psychoanalysis and beyond useless. Ever had to deal with RMI, EMF, MOF, and UML's weird and unsound meta-modelling "in itself" for exchanging model data modulo the worst of XML? To hell with it.
  - eru 3y ago
    OOP was never a good idea (apart maybe for GUIs), UML or not. What's BPM?
    - Qwertious 3y ago
      Business Process Modeling, according to wikipedia. https://en.wikipedia.org/wiki/Business_process_modeling https://en.wikipedia.org/wiki/Business_process_modeling
  - tut-urut-utut 3y ago
    So true, but had to downvote because of „fscking“.
- vidarh 3y ago
  Yes, but the problem of this thinking is that when communicating we inherently look for shortcuts and shaping language to the context rather than sticking strictly to a grammar and a dictionary, and to be successful at defining a natural language (and that includes diagrams) you need to accept that the job is 90% describing reality and 10% trying to shape it. If that. UML has been reasonably successful where it described reality, or tried to gently shape things by proposing things that were close to how most people already did things. Much less so where it tried to prescribe a reality not aligned with how people communicates, or where it has not kept up with the way that has evolved. It'd be more successful at being a lingua franca if the focus was more on documenting how people actually use diagrams, and just provide gentle nudges in one or the other direction where use is inconsistent. I think this is also why so many people hate UML tooling - because it forces you to communicate in this strange dialect that is very different from how most of us communicate with diagrams, and that most people find awkward.