6 ms·
My issues with UML: It's too bound up with OOP, specifically C++ and Java. It is hard to represent entities that are not simple classes. Things that are idiom
by captainmuon 4y ago
My issues with UML:
It's too bound up with OOP, specifically C++ and Java. It is hard to represent entities that are not simple classes.
Things that are idiomatic (in 90s C++, cough) look very verbose. If you have a base class, a derived class, and an interface you have a lot of duplication. It makes things like polymorphism look needlessly complicated.
And finally, it is ugly and unintuitive. The inheritance arrow goes the wrong way. I know it is supposed to say "derived IS SUBCLASS OF base" and thus goes upwards, but in my mental model it is "you start with base, and then go to derived (get more specific)" so it should point down.
- theflyingelvis 4y agoExcellent summary.
- iLoveOncall 4y agoSo you have an issue with class diagrams, not UML.
- rzzzt 4y agoWhy is making the distinction important here?
- cassianoleal 4y agoNot GP but probably because of all the other UML diagram types, which are not bound to OOP at all.
- iLoveOncall 4y agoBecause class diagrams are not even 10% of UML, and they are the most useless part of UML.
- Joker_vD 4y agoThey, 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 agoI'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 agoSequence 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 agoIf 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 agoSequence 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 agoWell, 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 agoThen 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.
- daitangio 4y agoYes I agree. My two cents: try CRC Cards, which are a simpler abstraction and give most of what is needed.
- gkhartman 4y agoI hadn't heard of CRC Cards before, but after a google search, I'm realizing that I've definitely written something similar while whiteboarding an idea. Thanks for the tip.
- planede 4y agoIMO the arrows point to the right direction, in a sense that in my mental model arrows are typically owned by the pointer, not the pointee. The pointees are typically unaware of what points to them. A base class "doesn't know" what its derived classes are. Likewise a git commit doesn't know it's descendants either. So in my mental model a derived class actively "points to" its base class. Likewise a child commit points to its parent/parents.
- masklinn 4y ago> A base class "doesn't know" what its derived classes are. There's a high variability in that, especially when metaclasses get involved and inheritance is itself a protocol (and thus can be hooked into every which way). I do agree with the rest of your comment though, to me it also makes a lot more sense for a derived class to point to its parent than the reverse.
- arethuza 4y ago"derived class actively "points to" its base class" That make sense - pretty much every language I've used that supports inheritance class definitions refer to the class (or classes) they extend rather than the other way about.
- Ensorceled 4y agoI like it ... class Vehicle extendedBy Car, Truck class Car class Truck extendedBy Semi class Semi This would be almost as awesome as "comefrom"[1] [1] https://en.wikipedia.org/wiki/COMEFROM https://en.wikipedia.org/wiki/COMEFROM
- fhars 4y agoLooks like sealed classes in Java https://www.baeldung.com/java-sealed-classes-interfaces https://www.baeldung.com/java-sealed-classes-interfaces
- zozbot234 4y agoYou could use a generic Vehicle<T: VehicleType>, with Vehicle<Car>, Vehicle<Truck>, Vehicle<Semi> implementing specialized interfaces.
- krageon 4y agoA "this is not intuitive" argument can be made about every formalised system and is not interesting: It will always be true for someone, no matter what you do. Get used to it being otherwise, then it will not bother you anymore.
- deleted 4y ago[deleted]
- captainmuon 4y agoWhen it is a visual notation and the main purpose is that it is supposed to aid you in thinking, then I think being "intuitive" is one of the most important features. I want to see a graphical representation of my "business" entities, not a more verbose 2D representation of my source code.
- michaelcampbell 4y agoSimilarly "readability". "Everything is hard to read until you learn to read it." -- Rich Hickey
- codeflo 4y agoNot being intuitive isn’t the strongest argument against specialized notation. Programming languages aren’t intuitive either, yet we learned them. The rationale is that the arrow goes into the direction the #include or import would go. So it shows logical dependencies — both caller and implementer depend on the interface — and you can quickly see if there’s a dependency in the wrong direction somewhere. I fully agree with UML being stuck in OO land, though, and I think that’s the actual problem. Lambdas don’t exist, or have to be verbosely represented as interfaces. Type-level programming doesn’t exist. Anything higher order is unrepresentable to begin with. You don’t have to use Haskell to run into those limits, modern C++ is enough, or Kotlin, or TypeScript. UML is basically useless if you’re doing anything more interesting than cranking out Java 1.4 era EJB boilerplate.
- roenxi 4y agoI think we need a slightly more specialised word than 'intuitive' and we don't have it. Something that has the flavour of ">80% of experts use one of [set] mental models, and this thing doesn't capture the essence of any of them". That is a high bar, I'm not sure if UML meets it (wouldn't know, don't use UML, not intuitive enough for me). But I think something like SQL's syntax meets it - nobody would design a language with that syntax in this day and age, experts have settled on not using garbled pseudo-English. The experts who think "VERB GLYPH ADPOSITION symbol" (ie, SELECT * FROM table) is the simplest way to represent relational algebra just don't exist. Anyone competent would use some other grammar.
- criddell 4y ago> I think we need a slightly more specialised word than 'intuitive' and we don't have it. Idiomatic is close.
- zozbot234 4y agoDoesn't UML have metaclasses, that could be used for type-level stuff? First-class functions should probably be represented via the Command pattern, which is ultimately a kind of defunctionalization (i.e. it's what high-level functions get compiled down to in actual code).
- Veuxdo 4y agoIf it helps, use the term "superclass" instead of "base". Then it makes a little more sense to have it at the top.
- nuancebydefault 4y agoI tend to use parent and child classes. UML follows the family tree notation in that case.
- flarg 4y agoYeah, but then don't use UML. It's a Philips screwdriver in a world that doesn't only have Philips screws.