6 ms·

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

• 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.
    • the_af 4y ago
      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.
    • ehutch79 4y ago
      Good, keep them distracted and out of the way.
  • RockingGoodNite 4y ago
    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 4y ago
      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 4y ago
        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 4y ago
        >> 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 °F.
    • marcosdumay 4y ago
      Yep, imagine building a rocket without ever making prototypes.
      • RockingGoodNite 4y ago
        I agree and nothing about waterfall denied making prototypes, ever. We all know modern agile is nothing more than mini-waterfalls anyway.
• dan-robertson 4y ago
  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 4y ago
    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 4y ago
    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 4y ago
      > 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-symbols/amplifier-circuits-symbols.htm https://www.electrical-symbols.com/electric-electronic-symbo... (amplifier, cache? semantics of the cache? ...) https://www.electrical-symbols.com/electric-electronic-symbols/electrical-symbols.htm https://www.electrical-symbols.com/electric-electronic-symbo... https://www.electrical-symbols.com/electronic-electrical-symbols/table-electronic-symbols.htm 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-button-led-circuit.png 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]
• another2another 4y ago
  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.
  • lisper 4y ago
    > 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.
    • another2another 4y ago
      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 :-)
• jillesvangurp 4y ago
  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 4y ago
    > 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.
• gggghhghgh 4y ago
• jandrese 4y ago
  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 4y ago
    > 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 4y ago
      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 4y ago
        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.
• buescher 4y ago
  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 4y ago
    > 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 4y ago
      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".
      • 4y ago
• rwoerz 4y ago
  The U in UML stands for unified not universal.
  • lisper 4y ago
    I stand corrected. (Though UML didn't seem particularly unified to me either.)
• 0x445442 4y ago
  > 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 4y ago
  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.
  • narag 4y ago
    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 4y ago
      Harel statecharts date to the 80s.
    • marcosdumay 4y ago
      All of the UML diagrams are some formalization of older ideas.
  • NohatCoder 4y ago
    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.
  • layer8 4y ago
    Activity diagrams can be very useful as well, and you can mix and match various UML elements in them, it's a very flexible visual language. Also state diagrams, of course, as a sibling already noted. I can recommend Martin Fowler's "UML Distilled" for a pragmatic approach (ISBN 9780321193681).
• avereveard 4y ago
  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.
• marcosdumay 4y ago
  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.
• taylodl 4y ago
  UML is a modeling language, not a "graphical notation", and I want to put emphasis on the model. The model could be represented graphically but the whole point was (or should have been) to capture the model. Having said that, UML had/has problems: * People using it as a diagramming tool rather than a modeling tool. * While many tools exist to create code from the model, there are very few UML tools that can create the model from code or true-up the model from code that had originally been created from the model and then subsequently modified, * Many UML tools lack the ability to generate diagrams from the model, the model is essentially kept hidden from the user - which is a rather odd state of affairs for a modeling language. By hiding the model you also couldn't use UML to explore a code base. * Encourages arguments over the mundane. Too many people got bogged down in the "dots and arrows" rather than focusing on the big picture. I suppose some people used that as an argument that they were being "productive." It's not so much that the idea UML is garbage but rather the tooling typically leaves a lot to be desired. Enterprise Architect is the best I've seen and even it's far from perfect.
  • lisper 4y ago
    > UML is a modeling language No, it isn't. It might have once aspired to be a modeling language, but it is not in point of actual fact a modeling language. The reason is, as you yourself point out, people use it to draw pictures, not to produce models. And the reason for that is that all of the tooling and pedagogy is centered around drawing pictures rather than producing models. An artifact is the thing that people actually use it for. UML is a modeling language in the same sense that (say) a letter-opener is a weapon. You can use a letter-opener as a weapon, but because no one actually does, calling a letter opener a weapon rather than a tool for opening letters is kind of silly.
    • taylodl 4y ago
      I would say the opposite is true - UML started off as a diagramming tool and then people realized the value wasn't in the diagrams but in the models. Most of the tooling however view UML as a set of standardized diagrams - which is just about worthless. Anyway, for about the past 15 to 20 years the majority of UML changes have been to the model. As I said, the only tool I know of that's in alignment with modern UML modeling is Enterprise Architect.