3 ms·

So you have an issue with class diagrams, not UML.

by iLoveOncall 4y ago

rzzzt 4y ago
Why is making the distinction important here?
- cassianoleal 4y ago
  Not GP but probably because of all the other UML diagram types, which are not bound to OOP at all.
- iLoveOncall 4y ago
  Because class diagrams are not even 10% of UML, and they are the most useless part of UML.
  - Joker_vD 4y ago
    They, however, a) were pretty much the only actual UML's innovation: other things like sequence diagram have existed long before; b) had most emphasis put on them.
    - rzzzt 4y ago
      I'd say it's getting a wide audience agree on a common method of notation. I have a Java book from 1999-2000 which uses OMT (all right, OMT's object diagrams) as its main representation. Not too far off from UML class diagrams, as it is also considered a historical predecessor, but still enough to make me consult the legend time to time.
littlecranky67 4y ago
Sequence diagrams are not particularly helpful with JavaScript and alike and agree with parent OP that its too strictly tied to C++/Java. They are just not intuitive with async/await and function composition. Yes, one can always do "mental translation" to translate those into the diagram and vice versa, but just not helpful. Now one would argue that you model "more abstract processes" with them, but there are better modelling languages for business and network processes.
- sethammons 4y ago
  If I were reviewing a system design, yes, with js, I'd still like a sequence diagram. I'd just indicate that ordering may not be exact between certain bands of requests. I model concurrent systems all the time in sequence (ish) diagrams. I want to know that action X will trigger N calls and those calls call service foo and bar, and that foo then calls out to its data store and eventually returns something and service bar calls services raz and quux and those each fist call a caching service before going to their data stores. All requests eventually return (in the happy path). Now, as a reviewer, I can quickly see what talks to what and why that call happens and I can ask more intelligent questions like what happens if a cache hit happens when the data store has been updated. What do you prefer?
- marcosdumay 4y ago
  Sequence diagrams are particularly useful for protocols, and not so for code in any language. The fact that UML formalized them as a way to describe code tells you a lot about the standard's quality.
captainmuon 4y ago
Well, I take issue with most formalized diagrams that represent code elements, rather than "business" entities. It leads to a kind of thinking that is wrong IMO, where you mechanically represent every business object by a class, say Customer and Employee. I tend to think of OOP as a way to rewrite 'if's now. When you have the same huge 'if' or 'switch' in a couple of places, you can usually rewrite it to use polymorphism, and it becomes clearer. But it is totally fine to use procedural or functional idioms most of the time. I don't know the whole breadth of the actual standard UML, and I don't know anybody who does. When I say UML, I mean as practiced and not as written, and that means: Boxes for classes, methods below, various kinds of arrows that I have to look up. For sure there are good parts in the standard, but that is not really relevant here. As the sibling comment says, sequence diagrams are usually more useful. Or state machine diagrams. Or a diagram showing data dependencies.
- HelloNurse 4y ago
  Then you are not complaining about UML, but about the old school bad OO designs that UML is meant to support (along with old school good OO designs). Without UML, such designs would be worse because they would be less documented: if you have a relatively concise class diagram in front of you it's easier to ponder about what each of the arrows and boxes means.

So you have an issue with class diagrams, not UML.

rzzzt 4y ago

Why is making the distinction important here?

cassianoleal 4y ago
Not GP but probably because of all the other UML diagram types, which are not bound to OOP at all.
iLoveOncall 4y ago
Because class diagrams are not even 10% of UML, and they are the most useless part of UML.
- Joker_vD 4y ago
  They, however, a) were pretty much the only actual UML's innovation: other things like sequence diagram have existed long before; b) had most emphasis put on them.
  - rzzzt 4y ago
    I'd say it's getting a wide audience agree on a common method of notation. I have a Java book from 1999-2000 which uses OMT (all right, OMT's object diagrams) as its main representation. Not too far off from UML class diagrams, as it is also considered a historical predecessor, but still enough to make me consult the legend time to time.

littlecranky67 4y ago

Sequence diagrams are not particularly helpful with JavaScript and alike and agree with parent OP that its too strictly tied to C++/Java. They are just not intuitive with async/await and function composition. Yes, one can always do "mental translation" to translate those into the diagram and vice versa, but just not helpful. Now one would argue that you model "more abstract processes" with them, but there are better modelling languages for business and network processes.

sethammons 4y ago
If I were reviewing a system design, yes, with js, I'd still like a sequence diagram. I'd just indicate that ordering may not be exact between certain bands of requests. I model concurrent systems all the time in sequence (ish) diagrams. I want to know that action X will trigger N calls and those calls call service foo and bar, and that foo then calls out to its data store and eventually returns something and service bar calls services raz and quux and those each fist call a caching service before going to their data stores. All requests eventually return (in the happy path). Now, as a reviewer, I can quickly see what talks to what and why that call happens and I can ask more intelligent questions like what happens if a cache hit happens when the data store has been updated. What do you prefer?
marcosdumay 4y ago
Sequence diagrams are particularly useful for protocols, and not so for code in any language. The fact that UML formalized them as a way to describe code tells you a lot about the standard's quality.

captainmuon 4y ago

Well, I take issue with most formalized diagrams that represent code elements, rather than "business" entities. It leads to a kind of thinking that is wrong IMO, where you mechanically represent every business object by a class, say Customer and Employee. I tend to think of OOP as a way to rewrite 'if's now. When you have the same huge 'if' or 'switch' in a couple of places, you can usually rewrite it to use polymorphism, and it becomes clearer. But it is totally fine to use procedural or functional idioms most of the time. I don't know the whole breadth of the actual standard UML, and I don't know anybody who does. When I say UML, I mean as practiced and not as written, and that means: Boxes for classes, methods below, various kinds of arrows that I have to look up. For sure there are good parts in the standard, but that is not really relevant here. As the sibling comment says, sequence diagrams are usually more useful. Or state machine diagrams. Or a diagram showing data dependencies.

HelloNurse 4y ago
Then you are not complaining about UML, but about the old school bad OO designs that UML is meant to support (along with old school good OO designs). Without UML, such designs would be worse because they would be less documented: if you have a relatively concise class diagram in front of you it's easier to ponder about what each of the arrows and boxes means.