[HN Gopher] UML: My Part in Its Downfall
___________________________________________________________________
UML: My Part in Its Downfall
Author : ltratt
Score : 207 points
Date : 2022-10-04 07:41 UTC (15 hours ago)
(HTM) web link (tratt.net)
(TXT) w3m dump (tratt.net)
| manbash wrote:
| I wish that the lessons from UML would one day lead to the a less
| ambitious modeling toolkit. What we need are ways to
| _communicate_ our design, not automate it.
|
| While comments in code/tests, README.md etc. are a good way to
| explain the bits and pieces of our software, companies have
| various stakeholders (software engineers included) that can't
| affored the time to translate these primitive documentation
| formats so that they make sense.
|
| Visual representation works the best, and I wish that UML would
| be elaborated as a sketching mean to communicate better with
| stakeholders, rather than being a part of an ambitious software-
| generation ecosystem.
| NonNefarious wrote:
| On a side note: Why are there almost no VIEWERS for Markdown?
| Every project has a readme.md, which everyone ends up reading
| in a text viewer with all the formatting markers all over the
| place. WTF?
| draazon wrote:
| There's a place for UML in the README.md; as some other
| commenters have pointed out, UML works much better as a
| sketching tool than as a total definition of a software system.
| A couple of quick class diagrams at the top level (probably
| generated using something like https://plantuml.com/) might
| provide a better communication model than text.
| manbash wrote:
| Yes plantuml is still my go-to visual design tool, whenever I
| feel information is missing, and I actually prefer it over
| mermaid (which has been integrated in github markdown), which
| I found very lacking.
|
| What I like about text-based tools like plantuml/mermaid is
| the ability to see diffs in PR.
|
| Other industry modeling tool use binary databases to
| represent the UML model and make it harder (i.e. need to use
| their specific diff visualizers, if available) to review
| changes of the design.
|
| Maybe plantuml should be adopted and maintained.
| Unfortunately it is still stuck in a Java implementation...
| bbkane wrote:
| It does have a very good VS Code plugin providing
| autocomplete and (somewhat laggy) diagram preview
| nottorp wrote:
| That would help but don't call it UML 3. No one will go near it
| then.
|
| IMO any kind of informal diagram helps. Even just some boxes
| with lines between them.
| zozbot234 wrote:
| You can still use UML for sketching. The free Doxygen tool even
| supports reverse engineering of UML class diagrams from
| (possibly annotated) source code.
| peter_retief wrote:
| I used to use UML for sketching out software projects, it worked
| well for that. I actually miss it sometimes.
| theflyingelvis wrote:
| I never found UML useful at all. A complete waste of time. YMMV.
| jq-r wrote:
| It was definitely a waste of my student time. I had to take the
| class on my second year and spent a semester learning UML
| because the professor was all into it. We've just heard about
| OOP at that time, the biggest achievement was being good at
| Delphi, most of the class had trouble writing a hello world in
| any language.
|
| The problem was also that the prof was always modelling some
| accounting/business "problems" which we also had no
| idea/experience about. So it was about learning couple of
| things all at once with very fragmented information. It was a
| disaster of class, and turned me off out of both UML and OOP.
| The latter I'm still sour about.
| mettamage wrote:
| When I was learning how to program, I programmed a graphics
| engine. It was about 10K lines of code, my first 10K in a
| single project.
|
| At one point I was making an object loader and didn't
| understand what hashmaps and hashtables were. I was making
| mistakes, debugging constantly and the complexity grew over my
| head.
|
| I sketched out a quick 'n dirty class diagram and how
| everything related. Whenever I got stuck or confused, I'd look
| at the class diagram. I'd see where I was and noted to myself
| what I already implemented and what still needed to be
| implemented. I also asked myself if I was stuck with a high
| level (UML) issue or more a low level issue (not understanding
| a certain datastructure).
|
| That class diagram was my rock and emotional support in coding
| up that object loader. So UML does have its place: if it gets
| too complex, but you know the design, draw out a UML-like
| diagram (or other diagramming methods) and it'll allow you to
| not have the high level picture in mind: it's right behind you
| on the whiteboard.
|
| Other than that, yea proper UML has never worked for me.
| bigDinosaur wrote:
| 'Proper' UML not working for you is the entire problem. UML
| had some good ideas, but none of those good ideas are unique
| to UML. Drawing things and the relationships between things
| is awesome.
| gjulianm wrote:
| I've used UML to communicate certain things about code. Class
| or sequence diagrams are great tools to explain code structure
| or workflow. Of course it's not very frequent that I need to
| use them, but they're still useful.
| jsmith45 wrote:
| Sure, but were those diagrams even conforming UML? And should
| they be?
|
| I don't see a lot of value in UML's standardizing +,-,#,~ as
| access specifiers, vs just using the relevant language
| keywords.
|
| Generally, unless people are using CASE tools, I tend to see
| them draw non-conforming diagrams that just roughly resemble
| what the UML spec says, and that is almost always good
| enough.
|
| Diagrams are good, but having to worry about N different type
| of arrow heads, if a line should be solid or dashed, semi-
| obscure access symbols, etc is not good. and strictly
| speaking if you are not concerned about those things you are
| not actually using UML.
|
| The exception is that nobody can ever convince me that a UML-
| style usecase diagram is better than alternatives like user
| stories.
| lisper wrote:
| It is easy to account for UML's lack of long-term success: it
| sucked. The so-called Universal Modeling Language, was not
| universal, nor was it a language. It was a _graphical notation_
| for describing code written in a particular paradigm that was
| fashionable at the time. The biggest problem with UML is the same
| as the problem with any graphical notation: the symbols it used
| did not have any lexicographic order, and so if you encountered a
| symbol whose meaning you did not know there was no way to look it
| up. You had to either climb the whole learning curve yourself or
| consult someone who had. This provided social status to those who
| had the knowledge, completely independent of the actual value
| that the notation provided. That was the main basis for UML 's
| popularity as far as I could tell. Far more effort was put into
| _teaching_ UML than was ever put into actually _using_ it, at
| least where I worked at the time (NASA).
|
| Not only was UML a graphical notation, it was a _badly designed_
| graphical notation. It attached semantic significance to symbols
| that were very similar in visual space. The poster child is the
| hollow diamond "arrowhead" versus the filled diamond. You have
| to have pretty sharp eyes to distinguish them, and there is
| absolutely no mnemonic value to these shapes.
|
| Graphical notations can be useful. Feynman diagrams, for example.
| But UML was nothing but a hot mess from the beginning. Good
| riddance.
|
| [UPDATE] When I was taught UML I was told that the first thing
| you do is produce a "use-case diagram". So I spent a lot of time
| drawing little stick figures. When I asked how this was supposed
| to be more useful than, oh, I don't know, just _writing some
| fucking English text_ , I was reprimanded for not being a team
| player. Madness.
| jandrese wrote:
| I think they all boil down to basically the same thing. In
| order to build a complex system you need to build it twice. The
| first time you will make mistakes that are difficult and
| expensive to fix and you need to tell yourself that it is ok to
| throw it away.
|
| This first iteration can come in many forms. In the old days it
| was done in pseudocode and formal language on paper, aka the
| waterfall model. UML changed it to be symbols and arrows. With
| rapid prototyping it is actual working but buggy code. One can
| see the appeal of doing it in real code, your programmers don't
| have to learn a second language nor translate the first version
| from that design language to the computer language. People will
| say that code is too hard for the design part, but it's the
| design that's hard, not the code. The real danger is that your
| prototype will work well enough and you won't have the
| fortitude to throw it away. That's not a danger with a design
| document/diagram.
| lisper wrote:
| > The real danger is that your prototype will work well
| enough
|
| I don't consider that a "danger", I consider it a good
| outcome.
| jandrese wrote:
| No, it's a huge danger. It means you have a product that
| you will be pressured to be put into production, but it is
| saddled with technical debt and will likely become a huge
| hassle to maintain. Your second version will come as a
| painful set of patches against a mostly running system that
| is increasingly complex because it has to work around old
| bugs and design misfeatures.
| lisper wrote:
| Not if you write it in Common Lisp.
|
| Seriously, I have put a lot of Common Lisp code into
| production and it just doesn't have these problems
| because of its ability to redefine classes on the fly.
| Combine that with an ORM that issues the right ALTER
| TABLE commands and all but the most radical design
| changes are completely turnkey, no stick figures needed.
| dan-robertson wrote:
| Being graphical is probably not sufficient for a notation to
| fail; electrical circuit diagrams were/are a successful
| notation even though there is no obvious lexicographic ordering
| of the symbols.
| qikInNdOutReply wrote:
| Excellent example of how a notation can succeed and fail at
| the same time. Electric symbols are used as a programming
| language in the plc sector and fail horrible when programs
| accumulate ever more complexity.
| lisper wrote:
| The reason graphical notation works for circuits is that
| _circuits are actual physical things_ and so there is a
| natural correspondence between the graphical notation and the
| thing that notation describes. A line in a circuit diagram
| means that there are two physical things located in physical
| space with a physical wire going between them. There is no
| such natural correspondence for software because software
| does not exist in physical space.
| eternalban wrote:
| > software does not exist in physical space
|
| The root of all the blessings and curses of software.
|
| > The reason graphical notation works for circuits is that
| circuits are actual physical things and so there is a
| natural correspondence between the graphical notation and
| the thing that notation describes.
|
| This really just boils down to complexity and verbosity, so
| 'fundamentally' it has nothing to do with virtual nature of
| software. Hardware people lucked out (in this case) but as
| the semantics of components get more involved, so do the
| component notations:
|
| https://www.electrical-symbols.com/electric-electronic-
| symbo...
|
| (amplifier, cache? semantics of the cache? ...)
|
| https://www.electrical-symbols.com/electric-electronic-
| symbo...
|
| https://www.electrical-symbols.com/electronic-electrical-
| sym...
|
| Right now it is unmanageable to do this for software. OP's
| write up actually mentioned the cause: they were trying to
| bootstrap UML with UML, defining 'semantics' using the core
| notation. This is the sort of 'elegant' approach that
| generally ends up getting buried under its own weight. So
| the question boils down to 'Is this complexity irreducible
| and open ended?'
|
| Not sure about the reducible but am definitely bullish on
| it being 'closed'. [Software may lack physics, but it
| certainly has both form and structure.]
|
| p.s. I think in isolation, specific aspects of software
| components can be [completely] described simply. For
| example, there are only so many ways bits can go in and out
| of a black box. Same for interaction patterns, there are a
| handful of modalities (such as caller, server, peer). Etc.
|
| p.s.s:
|
| Consider https://circuits-diy.com/wp-
| content/uploads/2020/01/push-but...
|
| Will you still insist there is a 'natural correspondence'
| if I naively decide to run wires from DC to LA for a that
| 'circuit'?
|
| Would it work? [spoiler: no, it won't]
| lisper wrote:
| > This really just boils down to complexity and verbosity
|
| No, it doesn't. Hardware really is fundamentally
| different from software because it is constrained by the
| laws of physics (and economics) in ways that software is
| not. So, for example, even complicated components tend to
| get fabricated in a way that the constituents are
| physically co-located with each other. That's why you can
| take a photo of an actual physical chip and draw
| boundaries around the various parts. Not only that, but
| those boundaries tend to be _rectangles_. So even complex
| hardware naturally lends itself to simple representations
| in 2-D space with intuitive mappings between the
| representation and the underlying (physical) reality.
| None of that is true for software.
| eternalban wrote:
| One can get lost talking about such details. It is a fact
| that the act of programming is a very elaborate means of
| modeling physical events. In fact we can simply map
| language->compiler->machine-code->physical-device and
| note that our programs in language x are in fact obscure
| models directing physical devices.
|
| Fundamentally (as significant to software), physics gets
| you _Pauli Exclusion_ , relative time, distance, and of
| course energy (computational power). This has huge
| ramifications for software and why it resists becoming an
| 'engineering' field. But it does -not- imo preclude the
| possibility of effective and comprehensive notation for
| software definition.
|
| p.s. since you are a lisper, you are already 1/2 way
| there to a universal modeling approach. I assume you
| would answer in affirmative to the question 'is there a
| viable universal textual notation for defining software?'
| with "Yes, it's called s-expression'. [In that case you
| would be] simply denying that a graphical analog can be
| developed. On that, consider the janky [early] attempts
| of everyone's ancestors in developing their
| alphabet/glpyh systems, currently in use.
| lisper wrote:
| > programming is a very elaborate means of modeling
| physical events
|
| The operative word being _events_. Hardware design is not
| about _events_ , it's about putting the right kind of
| atom in the right place, which is a lot harder than
| moving some electrons from A to B at the right time.
| mjevans wrote:
| Data Flow Diagram should be the model you think of. How
| does the data flow? Split apart and recombine?
|
| It might be easier to understand as a flow diagram for a
| major industrial plant, functions and programs like robots
| and major machines.
| tuatoru wrote:
| The key part of the Data Flow Diagramming method (as I
| was taught it, anyway) was not graphical: the Data
| Dictionary.
|
| This was, as the name implies, a dictionary that was the
| single source of truth for definitions of data items:
| meaning, representation, meaning of enumerated values,
| synonym and their business contexts, examples, caveats,
| etc.
|
| Easily implemented as a single table in your database.
| Never done these days, although it would probably
| simplify learning a system quite a lot.
| dan-robertson wrote:
| I feel like you're weaselling out of your earlier statement
| a bit. In your top comment you talk about it being hard to
| look up symbols. I point out that you need to look up
| symbols for circuit diagrams and you say that actually one
| doesn't need to look them up because they are actually
| intuitive and you invent a new criterion for diagrams to
| fail so that circuit diagrams can pass through but UML
| cannot.
|
| I claim that circuit diagram symbols aren't particularly
| intuitive (e.g. the symbol for a resistor is just a longer
| wire? The symbol for a transistor is very non-obvious, I
| think. The symbol for a potentiometer is pretty difficult
| even if you know how one works.)
|
| And another example of a visual representation that works
| well even though it is for something intangible is the kind
| of grammar diagram you can see in the SQLite documentation
| where terminal symbols are in rounded rectangles, non-
| terminal symbols in regular rectangles, and arrows indicate
| concatenation (I.e. production rules).
|
| To be clear, I don't want to disagree with your overall
| opinion that UML is bad or that the symbols are intuitive,
| and perhaps that is the reason that UML failed, but I think
| the reasoning about visual notations and the reasons they
| fail in general is faulty and I don't think the answer is
| to find ever narrower definitions of the cases where visual
| notation systems don't work.
| jeremyjh wrote:
| Another aspect is that in software, the code is actually
| the design. So a diagram that only approximates the design
| is not so useful as it is in electrical engineering where
| there still MUST BE a completely accurate design or the
| project fails.
| marcosdumay wrote:
| About your update, raise your hand who hasn't been in that
| situation.
|
| Anyway, it caused by that status thing. Your teacher knew it,
| and you didn't yet. But he couldn't just tell you.
| another2another wrote:
| A lot of harsh words for UML, and it's not something I use
| myself much anymore.
|
| _But_... I have used it for a few projects where I was
| starting from scratch, and I have to say they were some of the
| best and easiest projects I 've ever delivered.
|
| The act of designing the components, objects and interactions
| allowed me the time to think out many design problems and
| unanticipated interactions between the various elements and
| other systems I was interfacing with. Listing and adding the
| requirements of each stakeholder made my solution more complete
| and rounded for version 1.0. And since the design actually
| followed the implementation fairly closely (a rarity I know),
| it was one of the smoothest development experiences; and I had
| some fairly good documentation already produced that allowed me
| to explain to others how the system worked, and that gave them
| a step up when supporting it, or adding new features.
|
| Also, since I'd spent the time doing some use cases and talking
| them through with stakeholders, the non-technical users and
| testers already had a good grasp of what was being built and
| how to test.
|
| This was a fairly modest amount of UML documentation that I
| produced, as I see no value in designing every little detail up
| front, but that act of designing and thinking through the
| issues made these projects some of my smoothest deliveries
| ever. And to this day I've not seen a better successor to UML
| for picking out and describing bits of your solution. It sure
| beats the usual rush-to-code and iterate until it approximates
| that very often happens.
| marcosdumay wrote:
| You mean that the projects that you knew well enough to
| design before starting were easier than the ones you didn't?
| lisper wrote:
| > The act of designing the components, objects and
| interactions allowed me the time to think out many design
| problems and unanticipated interactions
|
| Sure. But you can do all that without UML. Text is perfectly
| adequate technology for planning ahead.
| captaincaveman wrote:
| Text is okay, but describing a graph is difficult and not
| as intuitive as a diagram. This doesn't mean UML is needed
| for the diagram, however the alternative is a semantically
| weak ad hoc diagram, and I'm not a fan of UML even though
| have plenty of experience, I agree that UML basically had
| good intentions for a real problem, poorly executed.
| somat wrote:
| and yet grafviz does it just fine.
|
| netlists do a perfectly fine job of describing graphs
| jimbobimbo wrote:
| The problem with text is that it takes a lot of writing to
| describe complex interactions and the reader checks out
| somewhere in the first quarter of your prose.
|
| Diagrams are more efficient to drive the point home.
| Rayhem wrote:
| Readers check out with those, too. I've found that's
| largely because everyone has a slightly different
| perspective on what something means, ergo everyone's
| always talking slightly past everyone else and the
| discussion doesn't amount to anything. It takes a very
| skilled learner to say "I'm shelving my idea so I can
| understand yours." And it takes a very skilled teacher to
| simulate a learner's brain with their own. Diagrams don't
| solve this problem, in fact, no tool does.
| mechanical_bear wrote:
| This is not a pure defense of UML, but text is not
| perfectly adequate. Visualizations do wonders for
| understanding that text can't touch.
| counttheforks wrote:
| This is why PlantUML is great. It is both text and a
| visualization.
|
| https://plantuml.com/
| another2another wrote:
| Well, I can pick up a piece of paper with classes, or a
| sequence diagram and external systems, and then tell the
| story from many perspectives to another person.
|
| "This depends on that, this calls that, and then calls that
| external system via this interface..." and so on.
|
| With a only text I would find that _much_ harder to
| communicate. That 's why I find diagrams much better - you
| can just jump in at any point and explain things in any
| order you like, usually with the aid of a pointing finger
| :-)
| lisper wrote:
| > With a only text I would find that much harder to
| communicate.
|
| And yet you just did it:
|
| "This depends on that, this calls that, and then calls
| that external system via this interface..."
|
| I really don't see the salient difference between
| this depends on that
|
| and this <-- that
|
| (Or is it this --> that? Or this --<> that? this --<>*
| that? I can never remember.)
| zmgsabst wrote:
| In my experience, the difference comes when you have many
| relationships which are organized into higher order
| relationships (eg, subsystems).
|
| English is linear in a way diagrams are not.
| lisper wrote:
| "Text" != "English". Text in general need not be linear,
| e.g.: System1 sub-system1a
| sub-system1b System2 sub-system2a
| sub-system2b
|
| (This is the reason indentation in programming languages
| is a thing.)
| rwoerz wrote:
| The U in UML stands for unified not universal.
| lisper wrote:
| I stand corrected. (Though UML didn't seem particularly
| unified to me either.)
| gggghhghgh wrote:
| raverbashing wrote:
| UML, together with the "Rational" (yuck) tools were the
| culmination of the "bureaucracy driven development" where
| producing paperwork was more important than actually shipping
| the darn thing
| RockingGoodNite wrote:
| There is something to say for design and long term (old
| fashioned) waterfall. Imagine starting building a rocket
| today to deliver a satellite to a specific location in space
| tomorrow. The just ship it paradigm has its place making web
| apps and smart phone app doo-dads, but that's about it.
| raverbashing wrote:
| Funny that you say that because SpaceX uses iterations to
| produce their rockets
|
| Yes, planning ahead is good, but it is not end all, be all
| youainti wrote:
| I think the difference is in what is trying to be
| produced. Musk has said that his goal is to build a
| rocket factory, i.e. SpaceX is trying to produce lots of
| rockets, not a few rockets.
|
| In software that might look like a company where they
| have lots of teams experiment with lots of software and
| project management approaches across a wide variety of
| project types. This second order concern contrasts rather
| heavily with the first order concern of making and
| supporting software products.
| RockingGoodNite wrote:
| >> Yes, planning ahead is good, but it is not end all, be
| all
|
| Actually it is when faced with being exposed to a vacuum
| at -455 degF.
| marcosdumay wrote:
| Yep, imagine building a rocket without ever making
| prototypes.
| RockingGoodNite wrote:
| I agree and nothing about waterfall denied making
| prototypes, ever. We all know modern agile is nothing
| more than mini-waterfalls anyway.
| pestatije wrote:
| Wow wow stop there...when did that ever become past tense?
| Nobody told the bureaucrats...they still doing it.
| ehutch79 wrote:
| Good, keep them distracted and out of the way.
| the_af wrote:
| Is RUP still seeing widespread use? Interesting. I hated it
| because of all the red tape.
|
| Then again, the bureaucrats of today call themselves
| "agilists" and fill your weeks and days with meetings after
| meetings, plannings, sync ups, etc.
| avereveard wrote:
| Also uml has difficulties in modeling event driven
| architectures, things like promises, functors and streaming
| lambda futures become an entangled mess when described in uml.
| 0x445442 wrote:
| > It was a graphical notation for describing code
|
| The most useful bits weren't even that but more of a graphical
| representation of a data model. Data models are useful in
| describing interfaces between components but they're useless in
| helping with the codification of business rules. My memories of
| the time are ones of contempt for those that thought the
| completed UML represented 80% of task completion and that all
| that was left was implementation "details".
| osigurdson wrote:
| I honestly don't think it was that bad. They should have just
| kept it to class and sequence diagrams however. As the author
| states, adding all of this unnecessary standardization around
| things no one uses was pretty ridiculous. Also various people
| clearly took things too far with laughable round tripping
| tools.
|
| In the end, UML is fundamentally unimportant. I think having a
| strong opinion about it (either way) doesn't make sense for
| this reason.
| NohatCoder wrote:
| The problem is that UML was forced upon a lot of people who
| basically didn't need it. At some point simply saying "Meh,
| it is not for me" doesn't cut it, you have to actually fight
| back to prevent the brain rot that the marketing is causing.
|
| If university students are being taught that UML is a must-
| use tool, it doesn't really matter whether or not UML has
| some legitimate use cases, the base teaching is a big fat lie
| and the students would have been better off spending that
| time playing Candy Crush.
| narag wrote:
| I remember state diagrams being very useful. But I'm not sure
| if it was much older than other UML artifacts and just
| "adopted" for completeness.
| buescher wrote:
| Harel statecharts date to the 80s.
| marcosdumay wrote:
| All of the UML diagrams are some formalization of older
| ideas.
| buescher wrote:
| UML was bound to OO design methodologies that really didn't
| work that well (any time you have a vaguely specified component
| with "manager" in its name it is likely someone was following
| one of them and, usually, an example of Conway's law). It was
| also bound to CASE tools that few could afford, fewer could
| master, and that I've never seen used well, so I couldn't say
| if they worked or not. And then, of course, Agile happened and
| designing anything became uncool and unpopular.
|
| I hadn't thought to critique the visual design of UML but it is
| just about impossible to pick up a UML diagram after a year of
| doing other things and remember the particular semantics of
| them above the whiteboard box-and-arrow level. So I think
| you're right and there's probably opportunity for someone who
| loves that kind of thing there.
|
| Also I thought I was the only one who thought use-case diagrams
| were absolutely absurd. At the employer where I saw UML and got
| actually pretty good but brief training on it, we had a VB
| plug-in for Rose that would extract the text from them into...
| a Word document.
|
| That said, UML statecharts are pretty great, the tools for them
| look OK though I've never done statechart design that way, and
| I appreciate seeing a sequence diagram for nontrivial
| protocols/exchanges/calling conventions.
| 0x445442 wrote:
| > any time you have a vaguely specified component with
| "manager" in its name
|
| This seems to be a limitation of class based OOD and the
| absence of free standing functions. There needs to be a place
| for code to exist which operates on disparate data types and
| structures. I've found that creating singletons that replace
| the word Manager/Utility with Lib doesn't offend the
| sensibilities as much.
| buescher wrote:
| Yes - to be clear, the limitation is the notion in the
| _methodologies_ (not necessarily the underlying language)
| that any time something has to happen, an object does it.
| Should it be this object? No, it should be a different
| object. What should we call it? Yes, I was making a funny
| about Conway 's law, but that's the point you shrug and say
| "call it pointAToPointBConnectionManager".
| zozbot234 wrote:
| > the notion in the methodologies (not necessarily the
| underlying language) that any time something has to
| happen, an object does it.
|
| That's not necessarily a bad notion, though. It's pretty
| much the definition of a capability, which is an
| important concept when designing for modularity.
| jillesvangurp wrote:
| It more or less unified a few notations that were already quite
| common or at least similar enough. There were two problems that
| it had:
|
| - it was over-engineered because model driven architecture
| people at some point got involved and there was this whole meta
| model that they came up with and unleashed some design by
| committee style processes on. This resulted in complex tools
| and companies like Rational Rose emerging; which promptly got
| acquired by IBM because they love complex stuff and the need
| for consulting that provides. I always joke that the wrong
| people got way too excited about this for the wrong reasons.
|
| - it coincided with the emergence of agile software processes,
| which de-emphasized the creation of a lot of up front design
| documentation, which is a waterfall thing to do. And there
| simply was no need for it over the course of a single sprint.
| Some companies still create diagrams to document stuff but
| mostly that serves very little purpose other than box ticking.
| But basically as companies switched to scrum, kanban, extreme
| programming, etc. they stopped using design tools and started
| using wikis, issue trackers, git, etc. These days the only
| design tools that are used are UI design tools like Figma.
| Software design mostly happens on white boards. That may or may
| not involve some box and arrow diagrams. Mostly those are
| talking points rather than detailed designs with little
| relevance beyond the meeting they are used in. With remote
| development now common; even whiteboards are not used that much
| any more.
|
| UML design tools are awful for their intended use. They are
| documentation tools and using them usually is a form of process
| bureaucracy: somebody insists on having diagrams. Usually not a
| software engineer. They are not useful as a design tool. Using
| them is fiddly and simply too slow. I can draft something on a
| whiteboard or on a bit of paper in seconds that would take a
| lot of time to do in a design tool. Instead of writing class
| diagrams, I'll actually stub out the classes and almost
| immediately start refactoring and renaming things; which is
| something that that UML tools don't support.
|
| Most UML diagrams state the bleeding obvious in either way too
| little detail or way too much detail. Neither is very useful.
| Complete waste of time creating these diagrams usually. But
| sometimes useful to impress the non technical people (We have
| stuff! It's amazing! Here's a pretty slide for you to look
| at.). I usually just wing it and maybe once a year sit down and
| do some boxes and arrows so I can put it in a slide.
| marcosdumay wrote:
| > it coincided with the emergence of agile software processes
|
| Not really. The first item and all the propaganda around it
| was a direct cause of the popularity of Agile. It wasn't a
| coincidence.
| jillesvangurp wrote:
| Not how I remember it. This stuff co-existed for a while.
| int_19h wrote:
| "Peak UML" was late 90s to early 00s. The Agile manifesto
| was written in 2001, right at that peak.
| danwee wrote:
| Scrum is the UML of these days.
| galangalalgol wrote:
| I remember being in scrums that used UML to generate code in
| the 00's. We just didn't wake up from the scrum delusions as
| quickly. I had read the agile manifesto, so when a manager told
| me as a young engineer that we were going to do agile I was
| momentarily overjoyed at the prospect of focusing on getting
| code working rather than our process or our UML tools... Then
| he showed me our new process, and I still had no choice in my
| tooling. So I said goodbye to that job. Sadly scrum has been
| harder to escape than UML.
| neilv wrote:
| This perspective is great.
|
| UML could've been much more popular and useful. In the early/mid
| '90s, I worked on commercial full-cycle CASE tools for
| mil/aero/datacomm development, including a "meta-meta-model" to
| support that. (Sadly, I loved my engineering and R&D teams, but
| business realities of the larger company happened repeatedly, and
| many innovative products and teams disappeared.)
|
| Later, in grad school, writing various software in Java, and no
| longer working for a CASE company, but having many methodologies
| up the wazoo, I wanted a way I could rapidly iterate between
| static object model diagrams and the code. With no good CASE
| solution available for that, and no time to solve CASE properly,
| I forgot about all my hard approaches to the hard problems, and
| just quickly kludged up something that did "80%" of what I
| wanted, with "0.000020%" of the effort. I used OMTool from
| Rumbaugh's GE ACC group for the diagram editing, and wrote a code
| generator in Emacs Lisp. https://www.neilvandyke.org/jomtool/
| asplake wrote:
| Similar background in metaCASE!
|
| My feeling is that its decline was at the expense of the IDEs
| and another developer-centric tooling (not in the early days
| open source, but latterly), and not a bad thing. Too often the
| tools became the focus at the expense of both less abstracted
| solutions and the real business problem.
|
| In a related field, process frameworks are today's version of
| that problem.
| andrew_ wrote:
| After reading this, and having minimal exposure to UML even
| during the late 90s and early 2000s, it strikes me just how many
| acronyms are needed to describe the ecosystem around UML. Perhaps
| the requirement of so much institutional knowledge led to its
| fall? I see correlation in that regard with web development
| today.
| dwaite wrote:
| It is very useful to illustrate a facet of a system - how four
| components interact, how something is meant to be deployed, the
| state machine used to make certain decisions, network
| communication, and so on.
|
| UML 2's concept of a core set of primitives that are used to
| build out a whole bunch of different kinds of diagrams was
| inspired. It was a shame that they didn't "just" do that.
|
| That is because once you start trying to generate diagrams from
| code, or code from diagrams, you no longer are doing
| illustrations but are making accurate/constrained views of the
| system.
|
| A class diagram built from running through C++ header files is
| often less useful than a textual table of the classes themselves.
| It is distinctly less useful than someone actually writing up a
| page or two of text to explain how the parts of the system are
| related.
|
| UML shines when it is used to graphically illustrate such an
| explanation. Things like Model Driven Architecture were doomed
| because the complexities of the system still have to be created,
| whether in a set of text files or a set of 2d pictures. Once all
| of the informational complexities are there, there's no benefit
| to an illustration.
|
| I find doing UML diagrams promotes the needs of other
| stakeholders earlier. Similar to how doing TDD winds up
| encouraging an architecture which is more testable, early UML
| diagrams (for me) tends to encourage a more explainable, domain-
| driven design.
|
| I would say that the negative for UML is that it sometimes tends
| to promote more object-oriented designs, where internal concepts
| and external interfaces may be created and maintained with more
| formality than otherwise needed. That might just be conflating
| bad habits at the time where it was most popular, however.
| beardyw wrote:
| I the early 2000s as a consultant I had the job of designing and
| building a new e-commerce site on top of an existing green screen
| system. Java was an obvious choice and I found a tool to design
| UML diagrams which would spit out Java code with empty methods.
| Some of the developers were new to Java but these templates kept
| everyone on course. Worked like a dream.
| bluedino wrote:
| Do Java job listings still mention UML as a requirement?
| AtlasBarfed wrote:
| 1) UML is documentation. Quibble about inputs or formalization
| ... whatever, it's documentation
|
| 2) No organization pays for proper documentation. In waterfall
| requirements gathering always consumed 90% of the budget, then
| the next 90% was development, then the final 90% was QA. Then the
| release-beta-and-fix later. Agile may help a bit with
| communication of undocumented requirements and undocumented
| functionality fixing and maintenance, but it's not much.
|
| To underline, companies don't pay for documentation, the
| documentation they DO generate in the BA -> programmer -> QA is
| vastly inferior to what's needed typically without extensive
| communication. Related: this is why outsourcing doesn't work well
| except in certain situations.
|
| 3) Therefore, every developer and every business analyst and
| every QA person, since they aren't paid for good docs, will avoid
| it. If an imposed software dev process is imposed by the gods of
| architecture, it will be resisted outright or by innumerable
| subtle ways (good people quit, make minimal (bad) docs but check
| the delivery list, etc).
|
| 4) what remains is point-to-point verbal and informal comms, and
| (actually high value meetings), which are very efficient but very
| very hard to capture into formal documentation. How many times is
| a ticket in various ticket tracking have its high value data in
| the COMMENTS on the ticket, and the body of the ticket is
| worthless? Overall I'd say it was over 50% of tickets were like
| that. Honestly, probably more like 80% for difficult tickets, and
| AT LEAST that captured the dialogue/information in some way, as
| opposed to Slack and meeting minutes.
|
| 5) UML also implies waterfall and "requirements are ready,
| finalized, and set in stone". I'm sure some UML zealot would
| disagree, but it does. But there are vanishingly small number of
| projects like that. What Agile does get right is an acceptance
| that software is a convergent evolutionary process / dialogue
| between business, business analysts, and developers. Notice the
| three tiers there, there are TWO levels of miscommunication, so
| Agile essentially accepts this while UML pretends it doesn't
| exist. QA is likely a third one, but they are the lowest on the
| totem pole.
| kown7 wrote:
| I feel the attempts to build SysML just have to go the same
| route.
|
| Does anybody have information why this shouldn't be the case?
| rjsw wrote:
| I'm working in a project that uses SysML, an extension of the
| ISO standards group that originally developed it. There are
| problems in that none of the tools for it are compatible with
| each other but it works if everyone uses the same one.
|
| I'm also looking at whether QVT will work for doing
| transformations between models.
| zppln wrote:
| An open source tool is also desperately needed imo.
|
| I kind of like SysML, but where I've seen it on a large scale
| it has failed spectacularly. People spend their time trying
| to figure out how to model things and fiddling with the
| diagrams to make them look nice. Distributed work is hard
| because merging becomes unintuitive. I think it could work if
| one really committed and tried to figure out all the edge
| cases, but the types of people pushing it at my shop have
| never been interested in that.
|
| Personally I tend to just use the SysML package for Visio and
| draw "SysML inspired" diagrams these days.
| rjsw wrote:
| Eclipse Papyrus is open source, I have been told that
| recent versions have gone off in a strange direction
| though.
|
| Our use case is to be able to create models, they are the
| deliverable. Merging is a problem for us too.
| arethuza wrote:
| My main problem with UML is that it actually makes most sense in
| selective sketches rather than exhaustive blueprints and if you
| creating a informal sketch the details of the diagram syntax are
| pretty much irrelevant.
|
| Martin Fowler's take on this:
|
| https://martinfowler.com/bliki/UmlAsSketch.html
| Double_a_92 wrote:
| Agree. The UML should only quickly explain the general idea,
| not the details.
|
| Because the details get quickly outdated, since nobody will
| bother to update that UML everytime the code changes. And
| because if it's too complex, I could as well just read the
| code.
| pull_my_finger wrote:
| Why is that a problem? You don't have to use all of a
| programming language for it to be useful. UML is just trying to
| "unify" a bunch of useful diagramming under a common umbrella.
|
| I agree with you and Fowler, sketches are probably a better
| use. When UML came about I think designs were largely developed
| before hand by architects/analysts and astronauts and given to
| developers to implement as is, but now they are better used to
| aid in documentation or spec out specific interactions/concepts
| that belong to a larger system.
| arethuza wrote:
| Its not a problem for developers but arguably a problem with
| anything like UML - which perhaps explains why it has failed
| to really take off in the way that a lot of people 20 years
| agoreally expected.
| bhk wrote:
| Code generation tools in this time frame were a great example of
| a mass delusion. Being the only same person in the room can be
| frustrating.
| paphillips wrote:
| UML is a tool like any other: one should understand the tradeoffs
| and make an objective decision as to whether it is useful and
| appropriate for a specific organization and scenario.
|
| Specification has a fundamental tension between clarity and
| completeness. I don't believe it is possible to maximize both. As
| a specification becomes more specific, rigorous, and 'correct',
| it diminishes in understandability, due to the limits of our
| working memory. As a specification diminishes in clarity, it
| loses appeal with most audiences. See also the rise of JSON in
| reaction to XML.
|
| This is the key tradeoff with UML. If the ultimate goal is to
| model a system, with platform-independence, at a level of detail
| sufficient to enable code generation, the specification and model
| representation will become complex, and the friction and overhead
| become too great for a typical corporate internal or external
| product, thus limiting the specification tool's adoption. The
| tool is no less valid, and can be useful for high-criticality
| areas, such as aerospace, or for academic exercises.
|
| One should objectively analyze the tangible and intangible costs
| of UML against benefits and use something else if it provides a
| better outcome. Perhaps a 'UML-lite' approach, such as C4 [1] or
| PlantUML [2], is a better tradeoff on the completeness-clarity
| continuum for a given scenario.
|
| Another interesting modeling framework is 'Object Process
| Methodology' (OPM) by Dov Dori [3].
|
| The two aspects of OPM that stand out to me:
|
| 1. A focus on the model alone, maintaining understandability, and
| an effort to keep things simple. Information hiding techniques
| such as zooming are provided as a means to manage system
| complexity during the modeling process.
|
| 2. Instead of an ultimate promise to allow bidirectional
| translation from model to code, and code to model, the visual OPM
| representation has a textual counterpart, 'Object-Process
| Language' (OPL). With this facility one can translate from model
| to descriptive text, and vice-versa. Thus, one may read or define
| a model visually in diagram form, or as a series of sentences
| using a minimized set of English words that is also machine
| parseable.
|
| Still we must recognize the tradeoffs: OPM may provide more
| clarity, but has less completeness. It won't round-trip with a
| code base, and it lacks modeling capabilities that can descend
| into an operation/process, e.g. one cannot model control flow
| concepts such as sequences, branches, loops, etc. Within the UML
| garden, concrete operation implementation can be specified in
| OCL, and the newer fUML can, in theory, reach down even further
| into operation specification.
|
| [1] https://plantuml.com/ [2]
| https://en.wikipedia.org/wiki/C4_model [3]
| https://en.wikipedia.org/wiki/Object_Process_Methodology
| t43562 wrote:
| I remember doing an exercise where a class that had just learned
| UML were asked to all specify the same design in it. Every
| diagram was completely different and many were just "wrong". It's
| like a language without any syntax checking. Come to think of it
| it also needs something along the lines of a unit test.
|
| Do love sequence diagrams though - the one thing I find truly
| useful.
| tjpnz wrote:
| Most classes are only going to teach you how to sketch UML
| diagrams. If you were told to create diagrams conforming to a
| particular UML spec they would all look very similar.
|
| If some came out "wrong" that probably says more about
| experience than anything else. Being able to effectively
| communicate your ideas with UML is a skill that takes some
| practise.
| jrochkind1 wrote:
| This conclusion hits home for me, ringing true with very
| different sorts of fields.
|
| > First and foremost, group dynamics can develop in such a way
| that reasonable optimism turns into blind optimism and expressing
| doubts becomes a taboo. When that happens, it is easy for the
| group to drift towards extreme positions that guarantee the
| group's failure. The UML standardisation community became ever
| more invested in UML 2's success: at first, doubting views were
| dismissed as referencing trivial problems; eventually such views
| stopped being expressed at all. The community only talked about
| success, even when there was significant evidence that failure
| was the most likely outcome [11]. Similarly, QVT was the wrong
| idea at the wrong time, but people were so desperate for success
| that they chose to ignore fundamental problems.
| javier_e06 wrote:
| For C Code UML is sort of moot. UML shines outlining object
| oriented designs and transactions. Management loves it along with
| Power Point and large conference rooms. I don't know who in their
| right mind think that is possible or useful to standardize
| software documentation. Except the README or its fancy cousing
| README.md of course. That's standard. ;)
| ilitirit wrote:
| I spent a good couple of years working with UML and related tech
| and products (especially from the Rational suite). Besides the
| fact that I hated it, a big personal gripe I had with it was that
| _noone looked at the UML after the initial review_. Ever. We
| generated the diagrams to fulfill some outdated legal requirement
| (Sarbanes-Oxley, I think?) for getting listed on a particular
| stock exchange, but other than that they literally served 0
| purpose.
|
| It was a massive waste of time and energy.
|
| Having said that, the sequence diagrams were quite useful.
| samatman wrote:
| I've done a few diagrams in PlantUML, which were better than
| nothing, and better than using a vector editor and doing it by
| hand, but there's a constant low-level frustration. One, if the
| authors didn't think of something, you can't do it, and two, if
| the layout engine makes bad decisions, it's truly tedious to
| instruct it otherwise.
|
| It also starts like a mile-long freight train, and goes about a
| hundred yards. I have no idea what it's doing for the first five
| seconds, but it isn't compiling my diagram.
|
| I've switched to using Pikchr, which has never met an abstraction
| and doesn't want to. It uses a Logoesque layout language,
| invented by Brian Kernighan as PIC, and reimplemented with
| improvements by D. Richard Hipp.
|
| He uses it for all the railroad diagrams in the SQLite docs, as
| well as many more UML-like diagrams in the Fossil docs.
|
| If you've found yourself cursing softly at PlantUML/Mermaid/dot,
| because the icons just _won 't go where you want them_, I
| strongly recommend giving Pikchr a try. If you want to diagram
| something which was never contemplated by Booch and friends,
| there's no second choice.
| captainmuon wrote:
| 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.
| codeflo wrote:
| Not 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.
| SkyBelow wrote:
| >Programming languages aren't intuitive either, yet we
| learned them.
|
| While saying "it isn't intuitive" is a bit of a
| simplification, I think there is something to the argument.
|
| I wonder if that is the case. Many programming languages do
| seem intuitive in light of other programming languages and
| other formal notation like math. The ones that don't are the
| ones I struggle with more. If I'm reading a new language and
| I see an '=' I can assume either a comparison or assignment.
| If I see a '<', I can normally interpret it as less than. The
| more a language violates this, the less intuitive I consider
| it and the harder it is to read through it without
| familiarity. This even applies among non-intuitive paradigms.
| OOP isn't what I would consider intuitive out the box (but
| then is anything), but once you know two languages
| implementation of OOP you can measure a third language's
| implementation as being intuitive to the exist pattern or
| not.
|
| My experience with UML is that it was wholly new. It was as
| intuitive as the first programming language a person would
| learn if they didn't know math notation, which given the rate
| new students to programming know math notation, is a level of
| unintuitive that even most programming languages wouldn't
| have even as a first time language. Add in that many are
| introduced it alongside OOP in general (at least that was my
| experience in college) and it is even less intuitive than
| that.
|
| So to that extent, I think I can criticize it as being non-
| intuitive even with the comparison to programming languages.
| marcosdumay wrote:
| > OOP isn't what I would consider intuitive out the box
|
| Paradigms aren't supposed to be intuitive.
|
| Anyway, "intuitive once you grasp the fundamental ideas" is
| normally called "idiomatic" in informatics. I will second
| the other comment on this thread pushing that term.
|
| Absolutely nothing about computers is intuitive. The entire
| area of knowledge is composed of fundamental paradigms and
| their extensions. Those can be "simple" or "idiomatic", but
| intuition doesn't go anywhere near them.
| opk wrote:
| Even with Java 1.4 the obvious mapping of class diagrams to
| data structures made for terrible data structures. You end up
| with an interconnected maze of objects that is totally
| inefficient for the algorithms. The mess typically included
| redundant, bidirectional and cyclic links between objects and
| where an object's only purpose is to be a list of another
| type of object, someone ends up writing a more limited
| wrapper around std::list/Collection/whatever.
|
| Managers were overly fond of the class diagrams because they
| could understand them. And dividing work between programmers
| by class rather than by logical feature somehow made sense to
| them. I recall one manager spending way too much time
| arranging to print a huge UML diagram across multiple sheets
| of A4, taping it to the wall and then annotating it
| constantly by hand.
|
| But knowing it can still be useful for simple sketches.
| Similarly dynamic dispatch is a really useful tool for
| particular cases when programming - used alongside other non-
| OO techniques. Our industry follows fads and fashions to an
| amazing extent but when things fall out of favour the baby
| goes out with the bathwater.
| dwaite wrote:
| > 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
|
| From a code generation standpoint (e.g. cracking out EJB
| boilerplate), the concept of model-driven architecture is
| generally a flawed idea. Lack of lambda expressions isn't
| that significant in the face of ignoring the complexities of
| real systems.
|
| I'm curious about the issues you've hit representing higher
| order types though - was this in a class-style diagram?
| roenxi wrote:
| I 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 wrote:
| > I think we need a slightly more specialised word than
| 'intuitive' and we don't have it.
|
| _Idiomatic_ is close.
| zozbot234 wrote:
| Doesn'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).
| codeflo wrote:
| > i.e. it's what high-level functions get compiled down to
| in actual code
|
| Yes, the Command pattern is what I vaguely alluded to in my
| message. The thing is, using a lower-level representation
| in something that's meant to be an _abstraction_ of the
| actual code makes zero sense to me.
| the_af wrote:
| I wonder, if you spend so much time writing fine-grained
| UML, aren't you already sort of programming? If so,
| wouldn't that time be better spent with an actual
| programming language with all the ergonomics and features
| you need?
|
| It seems to me UML shouldn't be dealing with this fine-
| grained level of detail. It seems like a wasteful effort.
| Either design high-level, or get down to actual
| programming.
| Veuxdo wrote:
| If it helps, use the term "superclass" instead of "base". Then
| it makes a little more sense to have it at the top.
| nuancebydefault wrote:
| I tend to use parent and child classes. UML follows the
| family tree notation in that case.
| theflyingelvis wrote:
| Excellent summary.
| iLoveOncall wrote:
| So you have an issue with class diagrams, not UML.
| captainmuon wrote:
| 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 wrote:
| 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.
| littlecranky67 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rzzzt wrote:
| Why is making the distinction important here?
| iLoveOncall wrote:
| Because class diagrams are not even 10% of UML, and they
| are the most useless part of UML.
| Joker_vD wrote:
| 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 wrote:
| 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.
| cassianoleal wrote:
| Not GP but probably because of all the other UML diagram
| types, which are not bound to OOP at all.
| daitangio wrote:
| Yes I agree. My two cents: try CRC Cards, which are a simpler
| abstraction and give most of what is needed.
| gkhartman wrote:
| I 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.
| flarg wrote:
| Yeah, but then don't use UML. It's a Philips screwdriver in a
| world that doesn't only have Philips screws.
| planede wrote:
| IMO 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.
| arethuza wrote:
| "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 wrote:
| I 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
| zozbot234 wrote:
| You could use a generic Vehicle<T: VehicleType>, with
| Vehicle<Car>, Vehicle<Truck>, Vehicle<Semi> implementing
| specialized interfaces.
| fhars wrote:
| Looks like sealed classes in Java
| https://www.baeldung.com/java-sealed-classes-interfaces
| masklinn wrote:
| > 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.
| krageon wrote:
| A "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.
| captainmuon wrote:
| When 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 wrote:
| Similarly "readability". "Everything is hard to read until
| you learn to read it." -- Rich Hickey
| [deleted]
| [deleted]
| kerblang wrote:
| What I'd really like to see is better standardization on network
| interface diagramming. Many organizations are doing just fine and
| well as far as the programming goes, but their undocumented
| network relationships are utter spaghetti, with zigzagging
| microservices going bananas in every direction.
|
| If folks were compelled to _write it down_ , it would be obvious
| what a mess they were making, but it's all inside people's heads,
| where it pretends to be coherent and "obvious". And no I don't
| think enterprise service bus stuff helps any...
| mgr86 wrote:
| Huge digression, but why are the headers indented?
| iLoveOncall wrote:
| UML is not dead at all.
|
| I cannot fathom developing software without UML. How can you even
| design a system without diagrams? It's simply impossible.
|
| There isn't one software component that my multiple teams at
| Amazon have designed that didn't use some diagrams from UML. And
| I'm sure you can say the same for any team in any FAANG.
|
| Sure we aren't gonna do a class diagram the vast majority of the
| time, but there will almost always be some component diagram,
| sequence diagram, activity diagram, etc.
|
| Some of the parts of UML are dead because they're not a good time
| investment, especially when working in Agile (class diagrams),
| but I'd argue that 90% of the people that say they never used UML
| after school have used it without realizing.
|
| Just look at this thread, 100% of the responses are saying that
| UML = Class diagram.
| sidlls wrote:
| The bits of UML in use today are quite pale shadows of how they
| were (intended to be) used in the early 2000s.
| [deleted]
| chrisseaton wrote:
| > I cannot fathom developing software without UML.
|
| Yet look at all the massively successful software written
| without any UML.
| skywal_l wrote:
| A little off-topic rant.
|
| I started my career in the early 2000s in a big company on a big
| industrial project where several generations of contractors had
| already had their hands in. UML, rational rose, auto-generation
| of code that you had to manually correct, CORBA, manual tests,
| proprietary tooling...
|
| It would take weeks to onboard newcomers, have them create unix
| account managed by some IT people in India so they could have
| access to the license of the proprietary point and click software
| to manage all this.
|
| I think it was a time where decisions on tools were made by
| managers in the procurement teams. Selecting technology based on
| what they heard while golfing with their buddies or depending on
| kick backs they would get from providers.
|
| Sorry, a little bit of a rant but to this day it still irks me to
| think how unproductive we were because of obvious bad choices.
| There is a silver lining though because during those years I
| learned more than any moments of my career. It taught me all the
| things that you definitely should not do if you want to be able
| to produce something useful at a reasonable cost. And one of them
| was to rely on UML for anything more than informally
| communicating simple designs with local team members.
| johnvaluk wrote:
| I'm tempted to try UML with GitHub Copilot to see if two wrongs
| make a right.
| indymike wrote:
| > I'm tempted to try UML with GitHub Copilot to see if two
| wrongs make a right.
|
| Well, it would be useful for giving non-developer managers
| something to do.
| neilv wrote:
| > _[10] Astonishingly, people in the small UML community
| associated my name with QVT for years afterwards. Though not
| always. In about 2012, I remember an important Professor who
| heard me mention QVT explain to me what the text actually meant
| -- quoting text at me which I had written, and which did not mean
| what they thought it meant! I tried not to laugh._
|
| Like the story of the novelist who sat in on a university lecture
| on their book.
| jeffrallen wrote:
| Please don't tell me UML is dead, I'm just about to learn it to
| help with DO-178C compliance documentation.
| mleo wrote:
| Back around 2006 the consulting company I worked had internal
| team go all in on a developing framework around MDA and Java.
| Sales would offer it to a client as a way to validate the model
| and interactions and then generate all the code. Even for basic
| CRUD app there was so much left out of generated code and was too
| easy to get the code and model out of sync. I came in late on a
| project to help solve performance issues. That short stint gave
| me more insight into that world than I ever wanted.
| hyperman1 wrote:
| While UML as a sketch had some use, it was a very predictable
| disaster when people tried to use it to automate away the
| 'coders'. It automated 5% trivial work that bothered nobody,
| while getting in the way when things got medium hard.
|
| I wonder if the current crop of low code tools learned from the
| whole UML story. Any chance things will be better this time?
| draazon wrote:
| Diagrams are good for representing structure, and inherently
| less good at representing behaviour (as mentioned in the
| article). I recall that in the early 2000s some UML tool
| venders were pushing "round-trip automation" as a way of
| tackling this problem; basically you'd model your business
| domain with some class diagrams, generate some boilerplate
| code, write code for the actual behaviour and then the tool
| would magically suck all the behaviour logic back into the
| diagram. It _sort of_ worked, for a couple of passes, until the
| tool failed to capture the precise semantics of some perfectly
| valid code (which was probably inevitable).
|
| I'm _hoping_ that the (somewhat-fine) distinction between no-
| code and low-code is made with the same problems in mind, that
| is, an acknowledgement that code is quite often the best way of
| expressing the behaviour of a system.
| throwawayfaang7 wrote:
| I've worked with two engineers, at a FAANG, who could not
| function without UML diagramming and generating their code. Both
| were 100% convinced that the only way anybody could write working
| systems was UML. So my teams got very little from those SWEs
| because nobody was willing to boil the ocean redesigning
| everything around UML code generation. They have together
| collected at least $3m in salary, bonus and equity over the last
| decade.
| skrebbel wrote:
| I still miss UML class diagrams being widely understood. At the
| peak of its popularity, you could go into a room with just about
| _any_ programmer, draw boxes and arrows on the whiteboard and
| everybody understood. People knew which arrow was composition,
| which was inheritance, which way the dependencies flowed etc. UML
| pictures made it easy to design modular software - just make sure
| all the arrows point in roughly the same direction and you're
| set.
|
| When the UML scene began all this "enterprise architect" MDA
| bullcrap, as this article elegantly describes, it got thrown out
| en masse. Rightfully so, but with the bathwater we also lost this
| industry-wide capability to draw software.
|
| Text is great, and in parallel with UML's demise, the industry
| got amazing at succinct technical writing: the README.md in a
| github repo. But sometimes a picture really is worth a thousand
| words and I still miss it.
| zozbot234 wrote:
| At its core, MDA is just the notion that UML (or some other
| graphical notation, for that matter) should be able to express
| Domain Specific Languages (DSL's).
|
| It's not clear that conversion from a high-level model to a
| platform-specific one should be a standardization concern, and
| maybe that's the "enterprise craziness" part that ultimately
| failed. But rigorously defined DSL's are not crazy; if
| anything, they're the only kind of "low code" that makes any
| sense at all.
| asp_hornet wrote:
| This is my sentiment exactly. Now in it's place we have bespoke
| diagrams where the meaning of lines, arrows and their
| directions vary from person to person and you need to ask the
| author to explain their convention before you can understand
| the diagram without assumptions.
| ayewo wrote:
| > _Text is great, and in parallel with UML 's demise, the
| industry got amazing at succinct technical writing: the
| README.md in a github repo. But sometimes a picture really is
| worth a thousand words and I still miss it._
|
| I think the decline in UML started with the decline of
| Waterfall as more teams adopted Agile. To state it more
| generally, more teams adopted ways of working that had shorter
| feedback cycles (relative to Waterfall) and unfortunately UML
| diagrams get in the way of that since they are not testable or
| easily made into prototypes [1] that can be shown to the
| customer for quick feedback.
|
| 1: That didn't stop people from trying. Enterprise Architect
| from Sparx Systems readily comes to mind
| https://sparxsystems.com/
| andylynch wrote:
| A former colleague of mine held an opinion which I still
| strongly agree with, that the most productive use of these
| diagrams was during conversation, on a whiteboard. (
| https://www.websequencediagrams.com/ is the next best thing)
| skrebbel wrote:
| Yep, exactly that. The moment people tried to run pictures is
| when it all broke down.
| babas wrote:
| I was in university 2004 to 2009. We had a total of 3 UML
| classes. A whole semester of wasted time. The professor that
| pushed this got "promoted" to a non teaching role after us.
| Everyone with some programming experience saw UML as a complete
| waste of time. The people pushing it at the time had no actual
| use-case just pie in the sky dreams of autogenerated software. It
| was doomed to fail.
| auggierose wrote:
| Sounds to me like they wanted to standardise something they
| didn't even have a working implementation of! There is a
| difference between invention and standardisation, and it is
| usually not done by the same kind of people.
| stonemetal12 wrote:
| UML isn't dead, it just went to bother someone else. All the rage
| in Systems Engineering these days is Model Based Systems
| Engineering (MBSE). At the heart of MBSE? SysML, which is
| "defined as an extension of a subset of the Unified Modeling
| Language (UML) using UML's profile mechanism."(https://en.wikiped
| ia.org/wiki/Systems_Modeling_Language)
| dqpb wrote:
| Modeling != diagramming. The fixation on drawing the system model
| was one root of the problem in my opinion. Also, xml for the meta
| model is a great way to dissuade people from building tools to
| consume the model.
| pfdietz wrote:
| > very strongly suspect that this reflects the active involvement
| of the OMG, whose pre-UML bread and butter had been standardising
| COBRA.
|
| CORBA, not COBRA.
| hackandthink wrote:
| UML became a kind of cult. There were Gurus and a Priesthood
| doing specification. Writing Code Generators was a cottage
| industry. The plebs should fill out the details.
|
| I liked Enterprise Architect back then. I used it as a painting
| tool for documentation, after the work was done.
| patwolf wrote:
| The author mentioned that UML peaked in 2000. I started a job in
| the IBM software group three years later, just a couple of months
| after IBM acquired Rational. I don't recall anyone using UML
| during my time at IBM, even though we had free access to the
| entire Rational suite. We did eventually use Eclipse Modeling
| Framework for modeling and code-gen, but not through visual UML
| diagramming. It's fascinating that UML lost relevance so quickly.
|
| Maybe the fact that it was mostly an offline part of the
| developer workflow, i.e. people didn't commonly check UML
| diagrams into source control and use them as part of code-gen at
| build time, meant that it was easy to stop using it.
| c7b wrote:
| shame, I remember learning it felt quite nice, to have a well
| thought-out toolkit to structure and/or share your ideas about
| certain aspects of a software. I still use it now for those
| purposes sometimes, in a quite 'free-form' manner on paper or on
| a whiteboard (so not sticking to the exact conventions of filled
| or hollow shapes everywhere, which I've also long forgotten, but
| using the basic pattern of eg a class or sequence diagram to
| communicate the point that I want to make about my idea, or to
| just develop an idea by myself).
|
| I guess it is a bit overengineered (and too closely tied to the
| OOP paradigm) if you were to treat it as an exact specification
| that has to be followed to the last dot on every project (or
| actually forced yourself to generate code from the diagrams), but
| with a more liberal attitude I still find it to be a very useful
| tool on occasions
| tzahifadida wrote:
| Documentation in general got the knife in the back. This has
| nothing to do with UML I believe. The cost for refactoring pure
| software is very low so any mistake can quickly be corrected. I
| would still insist UML be taught at universities just to open the
| mind of the students to possibilities.
|
| For other industries which include hardware and software which
| has a relationship between mistakes and high costs, then it is
| obvious that any documentation technique should be used to lower
| the cost.
| somat wrote:
| "when standardisation moves from "standardise what already
| exists" to "standardise things that we think would be good but
| don't yet exist" it enters dangerous territory."
|
| It makes me think of posix, posix is a terrible standard. "why
| would they make a standard with so many weird edges and shapes?"
| the answer is that posix is fairly hard in the standardize what
| already exists department. and as such preforms a vital role in
| getting every one started on the same page.(personally I feel
| posix is a good place to start but you should not feel too bad
| when you need to stray from it)
|
| See Also dictionaries: there are two types of dictionary. those
| that document the language as it is. and those that document the
| language as it should be.
| igtztorrero wrote:
| Problem with UML is the same that this article, soo long and
| boring, times now need fast and easy.
| dkackman11 wrote:
| You could search and replace UML with XML, MDA with XSD, and QVT
| with XSLT and this article would still accurately describe the
| early 2000's.
| agumonkey wrote:
| UML problem was cultural too. It's a crowd who valued too much
| heavy tooling (if not bloat). The more, the better (just like
| early java days)
|
| Graphs are naturally useful, but UML quickly became a bad
| investment.
|
| That said it was a time where projects were larger and
| communication was harder so the emphasis on large diagrams was
| probably enough of an improvement over potential chaos.
| lathiat wrote:
| Am I the only one that defaults UML to User Mode Linux and not
| Universal Modelling Language?
|
| Yep just me ok
| fedeb95 wrote:
| I may not be an orthodox user of UML, but I like it. Especially
| sequence diagrams, but also classes. I like it in the AMDD
| fashion: quick sketches to show only important parts of a system
| (or part of it). Using it to generate classes or from classes is
| pointless to me: it must be an artifact in itself, choosing the
| right colors and symmetries to better represent what you're
| trying to convey that may not be obvious from the code, such that
| a bird eye view of a system or an interaction between systems, or
| parts of a system. Like many I was taught it, but I wasn't aware
| of its popularity or lack of it. I've used it and found it useful
| when stumbling upon it for something I have forgotten the inner
| workings of.
|
| And also: use cases diagram is very useful. Thinking in terms of
| actors is good.
| rswail wrote:
| Been through all the silver bullets of the last 30 years, and the
| UML round-trip craze of the late 90s/early 00s were the worst.
|
| Sequence diagrams, ERDs, state diagrams are all good things.
|
| UML class diagrams were the worst though, mainly because the
| C++/Java world of inheritance of OO missed the entire point of
| OO, which was about the messages.
|
| So people would create incredibly complicated diagrams to
| describe stupidly complicated class hierarchies. One company
| actually modelled "Money" as a subclass of "Currency" because it
| was going to have to handle the transition to Euros, but
| completely ignored the laws and regulations that the EU defined
| for how that conversion would happen, because it didn't fit their
| class hierarchy.
|
| Yes diagrams are useful for documenting structure and behavior,
| but they're not good at being precise enough to describe those
| things to the point of generating code.
|
| Also, all the CASE tool vendors of the 90s were trying
| desperately to maintain their relevance, so were bolting UML on
| the side of their tools, while bolting things like Zachman
| frameworks on top of them to appeal to the _corporate_ _object_
| hierarchy.
| rendall wrote:
| I wish I could upvote this again.
| sebazzz wrote:
| I used it a bit when it was still built into Visual Studio. You
| could even let VS generate some boilerplate class definitions,
| but it was never accurate and complete enough to use.
|
| Frankly, for a lot of systems some block diagrams and some notes
| on the relations between them suffice instead of a full class
| diagram. I do like to use the sequence diagram though for complex
| communications between systems.
| choeger wrote:
| 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.
| forinti wrote:
| 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.
| hutzlibu wrote:
| "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.
| jerf wrote:
| 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.
| cxr wrote:
| See "Software Diagrams Aren't Always Correct and That's OK"
| <https://wirfs-brock.com/allen/posts/1018>
| cryptonector wrote:
| 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.
| m12k wrote:
| 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.
| lowbloodsugar wrote:
| TogetherSoft's Together did a pretty good job of the round-
| tripping, with the primary focus on the coding editor but
| diagrams when you needed them. It kept the two in sync very well.
| Used that around 2003 IIRC. They got bought by Borland and then
| spun off.
| ChrisMarshallNY wrote:
| I was always partial to "Booch Blobs"[0]. I used them frequently.
|
| When Jacobson (UML) merged with Booch, they went away, and the
| world became slightly darker.
|
| [0] https://en.wikipedia.org/wiki/Booch_method
| readthenotes1 wrote:
| Booch told us in a class that the blobs were there because (A)
| he could not draw a box on a whiteboard (B) at this stage of
| development, there are no crisp understandings anyway so
| there's no point in making crisp corners.
|
| He was ridiculing people who used templates to draw the class
| blobs exactly as shown in the book instead of just whipping out
| a closed form with a pencil or marker
| fstark wrote:
| Back in the day, I really liked the idea of standardizing class
| diagrams, but it became quite complicated at some point.
|
| Then, I had a lot of architects doing complicated UML diagrams
| that no-one understood, then had the pleasure of managing team of
| developers of MDA applications, and the code generation
| maintenance mess was dramatic, and nothing from that enormous
| plumbing made any of the "real" code easier.
|
| Happy to see that my disdain of UML is actually shared by one of
| the creators.
| harry8 wrote:
| Title reference for anyone who isn't already a fan of Spike
| Milligan
|
| https://en.wikipedia.org/wiki/Adolf_Hitler:_My_Part_in_His_D...
| usgroup wrote:
| did anything succeed UML without the bloat and problems? I liked
| UML in principle but it just never was very useful to me beyond
| drawing boxes and arrows and the occasional sequence diagram.
| gkhartman wrote:
| I've drawn up UML (or close-to-UML) class diagrams in the past
| while trying to understand large, unfamiliar C++ codebases while
| new to a project. While they were painful to make (especially by
| hand), they provided a nice map that could be pointed to while
| asking questions in meetings with those who knew the code. The
| making of the diagrams were an exercise that definitely gave me a
| better understanding of the class relationships that I would have
| taken longer to learn otherwise. Beyond the initial exercise, I
| didn't find them very useful in the longer term.
| gumby wrote:
| UML always seemed to me to be a solution seeking a problem. I
| never had a problem with someone drawing a bunch of circles,
| boxes, and arrows on a whiteboard (that would not be erased until
| the project was done). That approach tended to have more detail
| where needed and less where not needed.
| RcouF1uZ4gsC wrote:
| > By the time I had become involved in things, most of the nuance
| in the MDA text I quoted above had disappeared. It was largely
| taken as a given that only the most talented people in an
| organisation would be involved in the creation of PIMs; a cadre
| of second-class citizens would then have to engage in the
| drudgery of creating a PSM from a PIM; and no-one would need to
| worry about the code generated from the PSM.
|
| >The deep flaws in this vision might be obvious to most readers,
| but the standardisation community, intentionally or not, trained
| itself over time to avoid thinking about them. The most glaring
| flaw is: where would "behaviour" (i.e. the nitty gritty details
| of what a program should do) be specified? UML class diagrams are
| fine for expressing program structure, but they don't tell you
| what a function should actually do.
|
| Sounds like architecture astronauts:
| https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
| liotier wrote:
| In spite of all the hate against formal models, most of the
| problems I have encountered in the last twenty years are much
| easier to solve when the problem-solving conversation uses a
| model as common object. Conceptual data model (I love Merise),
| process with swimlanes, state machines... Nothing new and still
| extremely useful.
|
| About UML specifically, I never understood the fixation on object
| orientation: the world looks relational to me !
| NonNefarious wrote:
| It's not that different, but yes: I find that starting with a
| data model gets you a long way, forcing you to answer most of
| the important questions.
| edpichler wrote:
| Working for decades in this industry, I have not find a better
| way of managing a huge amount of complexity than UML.
|
| If you don't want to use, you are throwing away a "super power".
|
| Communication is, perhaps, the hardest part in software
| engineering field, and UML removes a lot of the ambiguity by
| using icons that represents a lot, replacing pages and pages of
| documentation.
|
| Furthermore, with a serious UML tool you can have traceability
| between everything, tying the problem to the final solution.
|
| I don't care anymore if people/companies don't use it. I use it
| for myself. It's the tool to leverage my brain and make my life
| easier when controlling and managing all the information
| complexity I work with.
|
| TIP: you don't draw everything, you draw only what is important,
| KISS (keep it simple) and chose the level of details you need.
| You can always add more later. Everything MUST have traceability,
| if not, it will be useless in some time. Ignore the tools that
| does not have this feature.
| indymike wrote:
| UML diagrams are pretty useful. UML as a code generation tool
| and as a substitute for thoughtful design... not so much.
| geodel wrote:
| So many great comments here about UML tools. I also had the
| misfortune of using them. I agree that details of classes
| internals was rather intrusive info to digram out. And instead of
| helping it actively harmed system understanding.
|
| Lately I have been able to generate diagrams after the fact for
| my Java projects. Jdeps provided dependency graph for whole
| project at package or class level in dot file format and then
| graph can be reduced and plotted by graphviz tools. Not as
| _rigorous_ as UML or visio but still pretty good for logical
| understanding or finding cyclic dependencies in code.
| morelisp wrote:
| My university SE class was during those heady days of MDA, and my
| opinion, nicely summed up in this article, hasn't changed one
| bit:
|
| _Yes, I could create a class diagram as a PIM; press a button
| and create a PSM; and press another button and generate Java
| code. But the Java code had all sorts of holes in it that I had
| to fill in -- and if I changed the model in any way, half of the
| code I 'd written would no longer compile, let alone run
| correctly. In other words, OptimalJ automated the most trivial
| things, leaving all the hard work to the end user._
|
| Unfortunately while MDA died, this same scheme is dominant today
| for OpenAPI definitions with exactly the same problems.
| mikro2nd wrote:
| Allow me to introduce you to the "Generation Gap" design
| pattern. ["Pattern Hatching", John Vlissides, p85]
| morelisp wrote:
| IMO this works for RPCs, ORMs, and certain event streaming
| architectures but not REST APIs beyond some trivial cases. As
| soon as you might want separate middleware processors but the
| same terminal handler it starts breaking down.
| cratermoon wrote:
| Oh wow, thank you for the reminder. I started work consulting
| on a project recently where the team is using protobufs and
| grpc. While they aren't directly changing the generated
| files, they aren't keeping them appropriately gapped. I knew
| this problem had been around since forever, but I couldn't
| remember where I'd seen it covered. This is exactly the
| pattern I had in mind but couldn't remember. I hope that I
| can help the team overcome some difficulties by discussing
| this with them.
| themoonisachees wrote:
| I learned UML in university, in 2018/19. Nobody liked it, but it
| made for a practical way for professors to give us class
| definitions in a language-agnostic way. All the classes about
| learning to use UML were otherwise universally hated (because not
| giving us the class definitions in UML was thus vague) and
| besides toying with a UML to java converter once, i've never
| touched it again and i don't think any of my classmates have
| either.
| coldpie wrote:
| Wow, I'm surprised they're still teaching it! I learned it in
| university in 2007 or so and found it utterly useless and
| outdated even back then. I don't think I've ever seen it used
| outside that class.
| tonetheman wrote:
| While I do not miss UML at all.
|
| I still find sequence diagrams useful in a big way.
| Joker_vD wrote:
| Those pre-date UML by a lot, so no worries.
| darau1 wrote:
| If UML is dead, I do hope there will be a replacement; I dread
| having to create diagrams in LucidChart again -- even if they're
| technically incorrect.
| franze wrote:
| UML was all the rage for corporate IT in the 00s, so I learned it
| at a damn expensive course.
|
| the teacher concluded the course with: "and this is UML, there is
| a high chance you will never see or use it again."
|
| he was wrong, saw it a few times again.
|
| he was right, never used it again.
| xwolfi wrote:
| This idea we could work as little ants on a factory chain still
| persists to this day, but UML was the bravest most expensive
| attempt at "no-code" industrialization they've attempted.
|
| Sadly, again and again, it is all destroyed by the client-
| facing people: "guys, the clients cant see the button can you
| make it yellow" and its infinite never ending variations, which
| make our job more akin to a jeweller because no amount of pre-
| code rationalization will prevent post-production resculpting.
| morelisp wrote:
| > UML was the bravest most expensive attempt at "no-code"
| industrialization they've attempted.
|
| Most expensive maybe, but "bravest" is surely something like
| spreadsheets or HTML.
| throw_m239339 wrote:
| It wasn't even "no-code" since you actually had to write the
| implementation. Yahoo Pipes was more no code than UML (I
| dearly miss that service).
|
| It was a descriptive language, somehow useful to do nice
| charts, but the tools themselves were so bad the only reason
| devs used them is because of suspicious relationships between
| management and UML tool vendors...
|
| > which make our job more akin to a jeweller because no
| amount of pre-code rationalization will prevent post-
| production resculpting.
|
| Can I borrow that quote for my professional communications?
| This is so elegantly formulated.
| zozbot234 wrote:
| UML had activity diagrams as its own pipe-like notation for
| low-level code. Not sure whether it was widely used,
| though. Also in general, conveying high-level data models
| might be more of a priority than implementations.
| arethuza wrote:
| I've only ever seen activity diagrams used by business
| analysts to capture system dynamic behaviour at a very
| high level.
|
| Mind you - as most people using activity diagrams have
| never heard of Petri Nets they were a bit vague about
| what forks and joins actually mean and were using them as
| convenient ways to join multiple arrows together....
| OliverJones wrote:
| Some random observations from an old-timer developer.
|
| 1. This excellent article is all about UML's class modeling
| capabilities. UML has other useful capabilities.
|
| 2. Sequence diagrams are very useful. I've created plenty to
| document and teach complex interactions between various (micro-)
| services. But it simply never occurred to me that I would
| generate code from sequence diagrams. They're simply a way to
| capture and refine the stuff on a whiteboard.
|
| 3. The data-modeling tools supporting logical and physical models
| suffered from some of the same needless complexity as the
| attempts to codegen from UML. And from the ludicrous expense of
| the tools. Every place I worked had at most one license for those
| tools.
|
| 5. The code-navigation and code-completion features in modern
| IDEs implement some of the best parts of the UML codegen vision.
| Tell VS that a class implements a particular interface, and it
| offers to generate a skeleton of the necessary methods for you.
| Great. Look at a method declaration, and see at a glance that
| it's from a superclass. Also great.
|
| 6. I hope somebody, maybe the author, collects articles like this
| for a text to be used in software engineering teaching. Our trade
| needs some serious mid-career training. The military has the Army
| War College. We need the Software Wars College, to get a chance
| to think this stuff through.
|
| 7. PlantUML is a pretty good way of embedding UML in wikis and
| other online docs. "Pretty good" is good enough for most
| purposes.
| ChrisMarshallNY wrote:
| _> 2. Sequence diagrams are very useful. I 've created plenty
| to document and teach complex interactions between various
| (micro-) services._
|
| I've always used the classic "bus timing diagram"[0] style of
| sequence diagramming. It's limited, but an excellent way to
| illustrate a parallel sequence.
|
| [0] https://study.com/academy/lesson/bus-timing-diagrams-
| definit...
| jongjong wrote:
| I love sequence diagrams. They are essential for designing
| complex event-driven system where there are a lot of
| asynchronous operations. I often use them to make sense of
| and/or prevent race conditions.
|
| I can also see the value in UML class diagrams for complex OOP
| systems but for me personally, I can make do without them in
| the vast majority of cases. They are not as valuable to me as
| sequence diagrams.
| RockingGoodNite wrote:
| I never liked UML but I agree time-sequence diagrams can be
| very helpful.
| frankosaurus wrote:
| +1
|
| Sequence diagrams force you to think about the flow of
| control in a system.
|
| When reviewing draft designs, I sometimes ask the author to
| convert a simple boxes-and-lines architecture diagram to a
| sequence diagram. It can be revealing.
| sylens wrote:
| I still willingly make sequence diagrams to fully document
| what is happening in a complex system or architecture. I find
| them to be very useful to get everybody on the same page for
| the "order of events".
|
| The class diagrams were something I was taught heavily in
| college and haven't really used since then. Feels like it's
| just as easy to write down "this object has a one-to-many
| relationship to this object"
| TeeWEE wrote:
| Still use subset of UML often: class diagrams, state diagrams and
| sequence diagram. Exactly the things that were used before uml
| and that uml 1.0 standardized.
|
| Note: I'm using a subset non strict "uml". Just to discuss
| software architectures or document designs.
|
| However sometimes simple boxes and arrows are enough but at least
| uml prevents some ambiguity.
|
| Note that UML 2 and MDE (model driven engineering) indeed failed.
| However some of the theoretic aspects still hold true today. Such
| as DSL languages written in a GPL language (react / Kotlin dsls /
| etc)
|
| And off course SQL is explainable in MDE terms (sql is a dsl for
| querying)
|
| Cool think is that these days new programming languages that are
| more functional oriented and cross platform solve the problem UML
| and MDE wanted to solve. These languages support dsls for example
| Kotlin.
___________________________________________________________________
(page generated 2022-10-04 23:02 UTC)