19 ms·

UML: My Part in Its Downfall

• morelisp 4y ago
  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 4y ago
    Allow me to introduce you to the "Generation Gap" design pattern. ["Pattern Hatching", John Vlissides, p85]
    • cratermoon 4y ago
      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.
    • morelisp 4y ago
      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.
• franze 4y ago
  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 4y ago
    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 4y ago
      > 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 4y ago
      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 4y ago
        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.
• theflyingelvis 4y ago
  I never found UML useful at all. A complete waste of time. YMMV.
  • mettamage 4y ago
    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 4y ago
      '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 4y ago
    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 4y ago
      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.
• danwee 4y ago
  Scrum is the UML of these days.
  • galangalalgol 4y ago
    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.
• captainmuon 4y ago
  My issues with UML: It's too bound up with OOP, specifically C++ and Java. It is hard to represent entities that are not simple classes. Things that are idiomatic (in 90s C++, cough) look very verbose. If you have a base class, a derived class, and an interface you have a lot of duplication. It makes things like polymorphism look needlessly complicated. And finally, it is ugly and unintuitive. The inheritance arrow goes the wrong way. I know it is supposed to say "derived IS SUBCLASS OF base" and thus goes upwards, but in my mental model it is "you start with base, and then go to derived (get more specific)" so it should point down.
  • theflyingelvis 4y ago
    Excellent summary.
  • iLoveOncall 4y ago
    So you have an issue with class diagrams, not UML.
    • rzzzt 4y ago
      Why is making the distinction important here?
      • cassianoleal 4y ago
        Not GP but probably because of all the other UML diagram types, which are not bound to OOP at all.
      • iLoveOncall 4y ago
        Because class diagrams are not even 10% of UML, and they are the most useless part of UML.
        • Joker_vD 4y ago
          They, however, a) were pretty much the only actual UML's innovation: other things like sequence diagram have existed long before; b) had most emphasis put on them.
• iLoveOncall 4y ago
  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 4y ago
    The bits of UML in use today are quite pale shadows of how they were (intended to be) used in the early 2000s.
  • deleted 4y ago
    [deleted]
  • chrisseaton 4y ago
    > I cannot fathom developing software without UML. Yet look at all the massively successful software written without any UML.
• skywal_l 4y ago
  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.
• hyperman1 4y ago
  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 4y ago
    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.
• skrebbel 4y ago
  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.
  • asp_hornet 4y ago
    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.
  • zozbot234 4y ago
    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.
  • ayewo 4y ago
    > 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/ https://sparxsystems.com/
• babas 4y ago
  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.
• tzahifadida 4y ago
  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.
• sebazzz 4y ago
  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.
• usgroup 4y ago
  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 4y ago
  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.
• manbash 4y ago
  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.
  • draazon 4y ago
    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/ https://plantuml.com/) might provide a better communication model than text.
    • manbash 4y ago
      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 4y ago
        It does have a very good VS Code plugin providing autocomplete and (somewhat laggy) diagram preview
  • nottorp 4y ago
    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.
• kown7 4y ago
  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 4y ago
    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 4y ago
      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 4y ago
        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.
  • dhx 4y ago
    My view on SysMLv1 is that domain-specific modelling techniques or tools are almost always far superior, and SysMLv1 therefore becomes a burden as you have to use the other techniques or tools anyway, and SysMLv1 doesn't have much to offer on top. SysMLv2[1], which is work in progress, is more interesting because it separates itself from general domain-specific modelling techniques and tools by: * Allowing definition of requirements * Allowing modelling and checking of constraints/assertions * Allowing modelling and execution of verification methods * Allowing trade-off analysis where objects are instantiated differently to assess impacts * Having the concept of concurrent/parallel states * Having spatial, time and units concepts built in * Allowing modelling with event triggers (e.g. when X happens, then the object's Y property increases by Z) Graphical notations are still there but I doubt they will get much use. Instead, SysMLv2 introduces textual notations and I would expect this becomes the easiest notation to communicate with. Even for Object Process Methodology (OPM) which is frequently touted as being one of the better general purpose graphical (with parallel textual) modelling notations for readability, I always look at at the textual representation as it is easier to understand. I think the intent is that SysMLv2 would allow you to specify requirements such as (completely made up scenario): * [Site X] shall be located at [coordinates X]." * [Site Y] shall be located at [coordinates Y]." * A minimum of 15 [sites] shall be located in [territory X]." * "Each [site] shall have a [line of sight path] to two or more other [sites]." * "[Line of sight paths] between [sites] shall be calculated using [XYZ:2022 standard]." * "Each [line of sight path] shall not exceed a length of 50000m." * "For each [site] located in [territory X], [planning overlay X] shall not overlap." * "For each [site] located in [territory Y], [planning overlay Y] shall not overlap." * "Each [site] shall have a [chance of flooding] not exceeding {some metric}." * "[Chance of flooding] for sites shall be calculated using [XYZ:2022 standard]." You can then write many of these requirements as constraints/assertions in the textual notation and embed other languages within the SysMLv2 textual notation or call external software tools so that constraints/assertions can be calculated externally with external data, for example, GIS tools and data or historical records. [1] https://raw.githubusercontent.com/Systems-Modeling/SysML-v2-Release/master/doc/Intro%20to%20the%20SysML%20v2%20Language-Textual%20Notation.pdf https://raw.githubusercontent.com/Systems-Modeling/SysML-v2-...
• arethuza 4y ago
  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 https://martinfowler.com/bliki/UmlAsSketch.html
  • pull_my_finger 4y ago
    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 4y ago
      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.
  • Double_a_92 4y ago
    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.
• agumonkey 4y ago
  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.
• peter_retief 4y ago
  I used to use UML for sketching out software projects, it worked well for that. I actually miss it sometimes.
• neilv 4y ago
  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/ https://www.neilvandyke.org/jomtool/
  • asplake 4y ago
    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.
• beardyw 4y ago
  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.
• neilv 4y ago
  > [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.
• liotier 4y ago
  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 4y ago
    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.
• OliverJones 4y ago
  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 4y ago
    > 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-definition-interpretation.html https://study.com/academy/lesson/bus-timing-diagrams-definit...
  • jongjong 4y ago
    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.
• andrew_ 4y ago
  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.
• choeger 4y ago
  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.
  • hutzlibu 4y ago
    "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.
  • m12k 4y ago
    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.
  • jerf 4y ago
    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.
• ChrisMarshallNY 4y ago
  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 https://en.wikipedia.org/wiki/Booch_method
  • readthenotes1 4y ago
    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
• tonetheman 4y ago
  While I do not miss UML at all. I still find sequence diagrams useful in a big way.
  • Joker_vD 4y ago
    Those pre-date UML by a lot, so no worries.
• fstark 4y ago
  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.
• t43562 4y ago
  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 4y ago
    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.
• johnvaluk 4y ago
  I'm tempted to try UML with GitHub Copilot to see if two wrongs make a right.
  • indymike 4y ago
    > 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.
• jeffrallen 4y ago
  Please don't tell me UML is dead, I'm just about to learn it to help with DO-178C compliance documentation.
• patwolf 4y ago
  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.
• auggierose 4y ago
  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.
• igtztorrero 4y ago
  Problem with UML is the same that this article, soo long and boring, times now need fast and easy.
• edpichler 4y ago
  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 4y ago
    UML diagrams are pretty useful. UML as a code generation tool and as a substitute for thoughtful design... not so much.
• lisper 4y ago
  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.
  • raverbashing 4y ago
    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
    • pestatije 4y ago
      Wow wow stop there...when did that ever become past tense? Nobody told the bureaucrats...they still doing it.
      • 4y ago
• throwawayfaang7 4y ago
  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.
• bluedino 4y ago
  Do Java job listings still mention UML as a requirement?
• samatman 4y ago
  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.
• rswail 4y ago
  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 4y ago
    I wish I could upvote this again.
• themoonisachees 4y ago
  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 4y ago
    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.
    • biofox 4y ago
      I teach OOP at a large reputable university, and I use UML every step of the way. For all the hate it gets, it's still the best thing for documenting and describing relationships in OO systems.
• ilitirit 4y ago
  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.
• harry8 4y ago
  Title reference for anyone who isn't already a fan of Spike Milligan https://en.wikipedia.org/wiki/Adolf_Hitler:_My_Part_in_His_Downfall https://en.wikipedia.org/wiki/Adolf_Hitler:_My_Part_in_His_D...
• jrochkind1 4y ago
  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.
• deleted 4y ago
  [deleted]
• mleo 4y ago
  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.
• RcouF1uZ4gsC 4y ago
  > 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-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
• javier_e06 4y ago
  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. ;)
• geodel 4y ago
  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.
• paphillips 4y ago
  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/ https://plantuml.com/ [2] https://en.wikipedia.org/wiki/C4_model https://en.wikipedia.org/wiki/C4_model [3] https://en.wikipedia.org/wiki/Object_Process_Methodology https://en.wikipedia.org/wiki/Object_Process_Methodology
• gumby 4y ago
  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.
• c7b 4y ago
  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
• bhk 4y ago
  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.
• lathiat 4y ago
  Am I the only one that defaults UML to User Mode Linux and not Universal Modelling Language? Yep just me ok
• dwaite 4y ago
  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.
• AtlasBarfed 4y ago
  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.
• stonemetal12 4y ago
  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.wikipedia.org/wiki/Systems_Modeling_Language https://en.wikipedia.org/wiki/Systems_Modeling_Language)
• hackandthink 4y ago
  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.
• darau1 4y ago
  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.
• TeeWEE 4y ago
  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.
• mgr86 4y ago
  Huge digression, but why are the headers indented?
• lowbloodsugar 4y ago
  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.
• somat 4y ago
  "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.
• pfdietz 4y ago
  > 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.
• fedeb95 4y ago
  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.
• kerblang 4y ago
  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...
• dqpb 4y ago
  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.
• dkackman11 4y ago
  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.
  • int_19h 4y ago
    XML, XSD, XSLT, and the rest of that stack was actually useful. Overengineered and verbose, but useful - enough so, in fact, that the JSON ecosystem still hasn't fully caught up on standardizing the same feature set.
    • NohatCoder 4y ago
      XSLT is just an inferior programming language. XSD mostly served to make people believe that XML standards could, as the name suggests, be extended. If you just specify your extension XSD it will work, right? In the real world it turns out that an extended XML standard is just another standard, it may look a bit like the old one, but nothing is going to save you from writing new logic if you want to support the new standard. While there are surely a few oddballs out there who just want to make standards for the sake it, to most of us, JSON doesn't need any "features", it makes parsing and generating data blobs quick and easy, that is all it needs to do.
      • int_19h 4y ago
        XSLT (or rather XPath, and even more so XQuery FLWOR) have very expressive ways to walk the tree while filtering/mapping/folding data - much more so than JS over JSON. XSD is just a way to define schemas for XML documents. I don't know what you mean by "extended XML standard", but islands of one schema within another were not uncommon.
• bitwize 4y ago
  UML failed because it was yet another attempt to "solve the software crisis", and the "software crisis", which never goes away, is this: Writing software defies the Taylorist conceit that competence should be vested at the organizational, not individual, level. Delivering good software stubbornly depends on people who are good at what they do; and if you apply the corporate favored technique of throwing a bunch of mediocre people together and forcing them to apply a standardized process laughingly called "best practice", expecting them to turn into top performers, you will be sorely disappointed and will not deliver good software. This has turned out to be a major bummer for middle managers, as good programmers are hard to find and often command higher salaries than said managers are willing to pay. The intent of UML was to formalize and standardize the communication of all design aspects, from overall architecture to user interactions to class specifications so fine-grained, proponents assured us in the early 2000s that there would no longer be need for programmers because code generators will turn UML into working code that flawlessly implements the spec. This has the effect of constraining and constricting the design process itself to conform to something that will yield the desired UML artifacts, rather than letting designers communicate in a way that shows engineers how to build the product they want.
• andrewgilmartin 4y ago
  No one has yet mentioned that the Design Patterns uses UML to elucidate its patterns. I think those diagrams work due to their limited scope. I hope those I have drawn with similar limits have helped others understand my and even their own designs.
• TedHerman 4y ago
  I wonder what happened with Harel's Statecharts - not about class modeling, but another graphical description.
• athom 4y ago
  My favorite part of this article is the liberal, and completely unironic scattering of the term 'OMG'.