The "real reason"? MSFT was making too much money selling developer tools. If you automate app creation from specs (totally doable with UML for most CRUD apps), then it would have greatly impacted Microsoft's revenue.
UML has died, because any attempt to build an application automatically from UML led to endless discussions about association vs. composition and generalization vs. implementation.
Nah. The real reason was that framework evolution outpaced the ability of Model Driven Architecture tools to adapt to changing technology.
I know, I used to work on one such MDA tool. It first started with the assumption that you want to generate a J2EE application. By the time the code generation was "good" Spring and Hibernate came along and simplified things to the point that it was easier and faster to "just code."
Turning UML into executable code could be done in one of two ways. Transform one high-level model into an implementation-specific model and generate code from that, or, create a UML VM that could run the models directly.
The latter would have been the correct solution, and still would be more complicated than it's worth.
Use UML for communication. It's still good at that.
Many companies tried to automate app creation like that. The entire CASE industry mentioned in the article was working on that.
Not one of them produced anything worth using. It was nothing to do with Microsoft.
The real reason that UML died is that it was a solution in search of a problem that it could actually solve. It was one that had a lot of appeal for people, so it took longer to die than it should have. But it died because in practice, it was largely useless.
The point about CASE is that there was a whole segment of the industry focused on addressing this problem, and it basically went nowhere.
Today there are a zillion CRUD generator tools, most of which don't use UML. It's not difficult. Many people who've worked on CRUD apps have probably written some autogeneration thing themselves at some point. Automating some boilerplate code generation doesn't solve any challenging problem in software development.
Can't tell if you're joking but one of the selling points of Microsofts paid versions of Visual Studio used to be good support for writing classes using UML. Microsoft is the O.g low-code company spending most of the 00s making people do things in diagrams and form builders of different kinds.
they do. MSFT does not have monopoly on software. they compete with others. and have incentive to make life easier for their customers ... to destroy competitors
You base this theory on...? Because I worked at MSFT at the height of the UML craze, in the Developer Tools division to boot, and the "DevDiv must make money"[0] mandate didn't come down until after the industry had collectively decided to move on from UML. Additionally, who do you think was going to stand ready to sell you the tool that "automate(s) app creation from specs"? Ever see a copy of VS 2003-ish?
Conspiracy theories are fun, but the "real" reason is in one of the several articles floating around HN that past few days. Mainly, it was a disorganized mess that no one was going to build tools for. Then IBM got hold of it, then...
[0] Previously it was, "we don't care if it makes money as long as it supports the Windows platform", hence the "developers, developers, developers" from Ballmer that folks like to dunk on. I was a grunt in DevDiv, so take it all with a grain of salt.
The money motivation isn’t that relevant but there’s some truth here. I used to work for a CASE tool company and I have long attributed their decline to the rise of IDEs and other programmer productivity tools. And not a bad thing either.
It died because big tech companies realized that their real customers are reserve banks; big tech companies are being paid for job creation, not product development. UML allows companies to build high quality software faster so it destroys jobs.
UML has never done anything of the kind. I've never read any case studies outside of marketing that claimed that UML increased software quality in any concrete and measurable way.
That may be true, I’m just saying even jf it did, that wouldn't make it a job killer but a job enabler. The whole reason computing is a growing field is it keeps inventing ways to multiply its own output. If that caused the field to shrink, the progressive move from punch cards to IDEs would have destroyed the field.
The kind of software which creates more jobs is not what I would call 'quality software'. Quality software gives people more free time, it doesn't consume more time.
The fact that most people can't see the difference today is disturbing. It's a sign that we are trapped in an inefficiency mindset. We're always looking to solve problems in ways which create more problems instead of solving problems once and for all and then focusing on different problems.
UML is still taught in universities here in france. It's like the mafia of abstraction-oriented, ivory tower developer who just explain the software but never write code.
I guess one upside is that developers know how to make diagrams. Which is good.
A simple diagram with components and how they communicate is pretty explanatory if you want a bird's eye view.
UML seems to try to be too specific and detailed when it comes to relationships, inheritances, hierarchies, etc but it's often just unnecessary, because every language/API/framework have their own way of dealing with details.
Not to mention that UML is often poorly specified and developers will not really respect the UML spec. It's like math, there are dialects. Programming language are better just because they have a proper parser that will verify correctness.
It's hard to understand why one would verify the correctness of an UML diagram.
But knowing the difference and being able to draw more or less accurate high-level sequence/flow/component diagram is vital skill for skilled developer.
>> Programming language are better just because
Programming language is usually poor choice for explaining design of system
I was taught "UML" at university (UK, 10 years ago). I say "UML" because while that was the name given, we probably only had a few hours on it in my entire degree, and it was essentially boxes and arrows, with class names and methods, and the basics of sequence diagrams.
I think it was valuable. I suspect many engineers use simple diagrams in notebooks on a regular basis, and by introducing it very early in the degree it gave us another tool to help think about the code we were writing.
It wasn't actually UML, but I think it's a good thing to cover at the beginning of a course.
> programmers use “die” to mean “decline in relative marketshare”, not absolute marketshare. Lots of thot leaders bemoan how few devs understand really low-level systems anymore, but there are more kernel hackers in total than there were 30 years ago. They’re just a lower percentage of all developers.
UML is dying though. I remember being grilled during job interviews on OOP design questions with UML and all those obscure details. I hate it. But now even the embedded world is more about API contracts with system designs and data stores.
Very informal boxes and arrows with random annotations have proven far more effective than a fully specified visual language.
Yeah. API contracts are real (and sometimes even formalized to one or another degree with TLA+, IDLs like WSDL, and various other tools); UML was a fraud: https://news.ycombinator.com/item?id=26959307
Plenty of English spelling simply doesn't make sense, "thought" is a good example of that. I'm ambivalent on vigilante spelling reforms, will have to think about it more. :-D
Typoing "thought leader" as a way to poke fun at them was deliberate, typoing it in a way that's also slang for a prostitute was completely unintentional and something I wouldn't have done if I knew. Changed it to something else for that reason.
I always thought it was slang for a woman who wasn't ashamed of her own sexuality, but of course people (not you specifically) would manage to turn that into a pejorative :/
If that was a quote it seems to have been edited. Anyway it seems to be a common spelling among a few people I met in Singapore, maybe due to this (now renamed) chain, or maybe the spelling preceded it.
It's cost/benefit as far as kernel hackers vs. low-level systems devs. To get a job writing at a kernel level at a commercial company, you need what? A masters degree, at least, plus experience? Minimum, to even be considered. A decent dev job, you bang it out using a high level language and move into a management position and are making more than that kernel dev position, anyways.
That "hacker" who has studied the kernel, knows that if you can compromise the kernel and gain root, all the other programs fall because your password keychain will be exposed, and no one keeps track of their own passwords anymore. Hackers don't need a resume or interview and references as a barrier for entry, it's a skills test.
I sound like I'm romanticizing the "hacker", but I wouldn't want to be one. If you get caught, these days, you're hosed. Not to mention, a lot of them are state sponsored from not very nice states, so to speak.
When was that? I remember evaluating it in the late nineties. I was fascinated by the idea of roundtripping UML-generated C++ code but it took so much effort to generate the code I wanted I gave up quickly.
'Culture Shifts' is the relevant bit. Orgs that realize a month's worth of planning to save a week's worth of dev work have realized UML isn't useful to them. Orgs that haven't don't think it goes far enough.
Let's not confuse the basic notation with the tooling and priesthood that grew up alongside it. Much like "Agile" there's still value in the small.
Hashing out a class diagram that shows how the domain entities relate to each other can still be pivotal in communicating the intended information model in a design. Pre-pandemic, this would involve words, lines, and cardinalities on a whiteboard (boxes optional).
Nowadays, a quick domain entity diagram in Whimsical does the trick.
A sequence diagram can quickly communicate an expected interaction pattern. The point is not to specify anything up front. The point of UML was always to serve first as a communication tool. Have commonly understood pictorial notations that let you talk about the software you're building.
When it was first invented, UML was aimed at "Unifying" how we diagram things. First, for books, and for the patterns movement. Even the heavy-weight Rational Unified Process was intended to be used in an iterative fashion. But it was constructed from a consulting mindset where you have intermediate steps of review and approval.
Blaming UML for the heavy-handed process where "thou shalt specify everything in advance" is like blaming the English language for that crappy novel you wasted your time on.
UML still has a place, IMHO, but only in that it helps you get over a few speed bumps on the way to helping your team produce working software.
> When it was first invented, UML was aimed at "Unifying" how we diagram things.
See but “unifying how we diagram things” isn’t a problem that needs to be solved. A good diagram on a whiteboard is more art than science. It is also something that is intentionally as low of fidelity as possible because you might blow it away and do something entirely different.
There doesn’t need any “standard” for how to do adhoc diagrams.
The minute you add “formal standard” to the process it gets slower when you want it to be even faster. If my whiteboard diagram had to adhere to UML... I wouldn’t bother.
> In his book on Business Object Notation, Bertrand Meyer lists twenty-six competing methods. I remember reading documents that listed over fifty, but I can’t seem to find them again so it might be a false memory.
I also distinctly remember how difficult it was to learn from other's designs. Back then, there was no Stack Overflow or Google. Developers like me obsessed over the latest books (like this new Design Patterns book, have you heard about it?!?)
It isn't a problem today because that's not how design ideas get communicated anymore. You have blog posts, and GitHub repos with examples and Markdown. This is better. But in the mid to late 90s, UML really helped.
Disclaimer: I was on many of those OMG committees for Model Driven Architecture and UML back in its heyday. I've also sat in Sushi restaurants after conference proceedings during dinner with some of the people mentioned in the article. The talk was of how we were going to change the industry. I smile to think of how things moved on without our dreams. :)
> There doesn’t need any “standard” for how to do adhoc diagrams.
Oh yes there does.
I have seen people makeup ad hoc notation during an ad hoc diagram and then get confused by what it means orthe meaning shifts during the diagram. No, we have a standardised language. You wouldn't want blueprints with ad hoc units. "14 snails thick, and 3 rabbit-seconds in length which we indicate with an underlined star"
You don't need a standard for ad-hoc whiteboard diagrams or expositional figures. You're comparing apples and oranges because what you are talking about needing this level of precision in is more "blueprints", not ad-hoc diagrams.
And, while it's my opinion only, blueprints for software are best written in prose. For C++ for example, I think the best language to use is concise, precise, well written, C++. And so on.
Just to point out - you've listed two diagram types. There are 14.
Of those two (which are the only two I've heard called out by their name in any business context), I've not seen consistent notation. Sometimes it's a problem, sometimes it isn't, but invariably what is more important is the conversation happening alongside the diagram; the diagram by itself is not a useful artifact, just like the slides to a (good) presentation, by themselves, are not useful.
Component diagrams, state charts, and activity diagrams also still appear in some of my whiteboard sketches. They are useful in specific contexts, but we use them far less often.
The last time I drew a use case diagram, it was in jest.
So most if not all of UML's diagrams can show up in -some- form when conveying information. Just, no one remembers the UML, and certainly no one thinks "Ah-hah. A (diagram type) would be useful here. I shall draw one in accordance with all outlined UML conventions".
No, but when I'm drawing diagrams and realize I need to show that this relationship is different to that one, I think "Ah-hah. I will use the UML arrow notation instead of inventing something incoherent as I go".
> Traditional enterprises were the dominant software employers in the 1990’s, meaning that tech trends likely reflected their interests. That would be a good explanation for UML’s initial rise. Over the past two decades, though, software culture shifted progressively towards large tech-first companies and startups. Neither, historically, was the target audience of CASE vendors. Over time traditional enterprise starts borrowing from tech and startups vs the other way around, leading to the progressive decline of CASE in its extant niches.
This I think was the real thrust of the argument. While UML's death may be exaggerated in many corners of the corporate world, so too is its life in representing our industry as a whole.
Sequence diagrams are very useful. Flow charts and state diagrams are also useful but less so in my experience.
If your inheritance structure is so complicated that you need a class diagram, you are probably in for pain... But class diagrams do their job for sure.
I find UML useful as post-coding documentation. After you figured out how things work, you UML diagram your code to help explain the complicated parts.
UML is also useful for talking with coworkers. As a 'sketch' don't try to get everything right, but coworkers often need to know what your plans are if they are to find work that won't conflict with your plan.
I think another UML post was talking about sketch 'masala' graphs (throw everything into a touchy feely graphic that really doesn't say much). Being absolutely vague and nontechnical is an advantage in some cases, but not useful to engineers. UML, for all of it's faults, is precisely defined. Every symbol means something.
I think there's only one kind of diagram that in UML that doesn't have a clear predecessor: the activity diagram. There's a reason it's called the Unified Modelling Language, after all.
The point of UML was never to "invent" new diagrams. The point was to unify all diagrams so that your arrows in one visual-language are compatible with the arrows in another visual-language.
In my view, Statecharts have been the most useful UML diagrams, since it is possible to represent complex behaviour in it, even more than Sequence Diagrams. Their unlimited nesting, and capability to "remember", etc makes them quite useful.
I love Harel statecharts. They are a useful formalism that maps easily to code for a wide range of practical solutions. The key innovation is embedded states.
That said, the formalism does not say much about error handling. This is where state machines can get really hairy, in much the same way that throw/catch gets nasty in any non-trivial system.
I still handwavily use one concept of class diagrams, letting arrows point at something that it depends on, without caring about the style of arrow, for sure I don't draw dashed arrows. It doesn't even have to be classes, could be a function calling another function, or a library depending another.
Yeah, sequence diagrams are the only ones I really like. Sometimes I auto-generate a UML class diagram from my code for a slide but I always have to trim out excess stuff I'm not interested in and usually add some annotations to make it say what I want.
> UML, for all of it's faults, is precisely defined. Every symbol means something.
That's another fault, in my opinion. I'd rather have a vague high-level diagram with a write-up that rigorously describes all the invariants and structure than have a really semantic diagram which is meant to stand alone.
I think software structure is too complex to model with anything less powerful than natural language — that's why we add comments into code to explain the things that even the code itself doesn't make obvious.
I think the only one who retired during the early decline was Rumbaugh; as one person told me, "he got out while the going was good." Grady Booch left modeling later. Ivar Jacobson is still around, though now he pitches his Essence framework. I always got the feeling he was the least "amigo" of the three, which makes sense given he joined due to a hostile takeover.
UML never died because it never lived. It was always a zombie kept alive by Rational Software doing a really good job of generating enough hype, and market share, to sell to IBM for $3.1 billion.
Since Rational was sold in 2003, UML has just been lurching from one generation of engineers to another shouting 'braaaiiins'.
Trying to discuss UML objectively without the context of who was selling what at the time is pointless. It was never a good enough method to live beyond being kept on life support by the marketers.
Back then, anything that could be used to increase a manager's department budget could be the basis for a business. There was a job, "System Analyst", whose output was supposed to be stuff like that. Programmers were supposed to just code what the diagrams System Analysts produced said, and not try to think.
There is still an ISO Standard for regular flowcharts, and lots of DoD contracts require delivery of ISO Standard Flowcharts, so there are tools to automatically generate flowcharts from source code, which are printed out, delivered, and dropped in file drawers in dusty warehouses.
Every five or ten years ISO issues a new Flowchart Standard. It has been suggested that they issue a Standard that says any old blank sheet of paper meets the Standard, to save a lot of money on printing them out and storing them. It hasn't happened yet.
It would not be surprising if there were a zombie ISO UML Standard, and contracts requiring software be delivered with conforming UML.
The problem is system analyst is a useful job only if they don't have to worry about all the details of the helpers and incidental data field and can focus on the high level parts that matter. In the mean time programmers need to add those little helper classes as implementation details, and they instead of to spend a week doing some formal request to the system analyst for something that could be done in an hour if they were allowed to think. And of course programmers have to think anyway.
Maybe I’m getting primed to be eaten by zombies by saying this, but I think UML was trying to do something valuable.
A tool which could create visual diagrams for logic flow and abstraction would be amazing. After parsing a large project, many people create a mental map which feels quite close to some sort of visual diagram. If someone could figure out how to represent those models visually, I think it’d be a lot easier to identify good abstractions for a problem and its likely evolution vs bad abstractions for a problem and its likely evolution.
The problem is keeping those diagrams correct. I've worked where the UML was the code, and it worked because the visual models were up to date. Every monday I'd print on poster sized paper the latest models to paste on my cube wall. They were good enough for the rest of the week, but by the next week there were different enough as to be worthless.
I've never seen UML actually work anyplace else. Either the models are out of date, or they are only up to date because you force people to go back to maintain the models after the code is working. This latter of course fails, why would management want to pay someone do maintain models when not only is the code working (well at least partially) for the testers, but the person who is assigned to do it doesn't want to.
What were the advantages and disadvantages of programming in UML rather than, for example, Java or Python? In https://news.ycombinator.com/item?id=26959307 I blasted it as "a fraud" because of clearly exaggerated claims made for its power that went far beyond anything available; how did its power compare in practice to other programming languages?
Another Turing complete language. The one I used compiled to unreadable c++. It was easier to see the big picture because all the models were visible. However in the end it is all syntax.
One problem is that there are many such visualizations, each of which has its own advantages and disadvantages for specific purposes. Visual syntaxes also scale very badly with increasing complexity, so it's very unlikely that a "large project" could be usefully represented by a handful of diagrams. UML seemed to have very clear problems due to both of these issues.
I think the fact that there’s no underlying physical object might be the bigger problem. Mechanical and electrical diagrams seem to scale quite well with complexity. They’ll get cluttered/you might need to break them into pieces, but they’re still intelligible and seem much easier to keep accurate and useful than most software diagrams.
The problem wasn't the idea, a visual diagram for logic flow is a good idea but your IDE can do that from your code better than the over-engineered idea of UML. UML had another problem, it reversed the way programmers work. As a programmer you start with a rough sketch (hand drawn diagrams and/or some prototype code) and iterate through that along with the client until you have what they want. UML (at least the way it was taught in my university) assumed that the client knew exactly what he wanted and that as a developer you could get your system designed perfectly on a diagram before writing a single line of code. When you tried to translate that into code you realized that your design wasn't as good as you thought, you had to make changes and doing that required going through a lot of bureaucracy (and change requests) that only served to hinder your progress. The automatic code generation promised by Rational wasn't as good as promised, it was close to useless and their software and UML basically expected you to program in enterprise Java, trying to fit a less enterprise OO language there was pure pain and resulted in very messy designs.
UML isn't taught that way any more. It's still mandatory in programming courses and waterfall(ish) programming projects, but it's also emphasized that iteration with clients is a good thing if you can do it, that the clients don't actually know that they want, that you're unlikely to get your software right the first time, and that 90% of software projects end up failing anyway.
And it's not like this hasn't been tried with varying degrees of success prior to UML (IDEF/IDSS, IORL, even arguably arguably CORBA, etc.)- it just happened to get a lot more traction, and waste countless billions on worthless busywork.
Objects sound like a good idea, and set the propeller-beanied programmer geeks (especially the academic ones who can't deal with the real world anyway) all aflutter, but really aren't worth the trouble in practice.
The claim that the method was not useful seemed a little too generic. Depends on what was meant by “method”, but I took that to mean a method of software development and communication that uses lots of abstract detailed visual diagrams. I don’t think that whole idea should be abandoned because UML had problems.
I wholeheartedly agree. UML never really lived, and I will say the reason is that it doesn't solve a problem that needs solving.
It's supposed to be a universal (visual) language. Two problems, in the real world the way it was used and, more often than not, misused it was far from universal. I mean that deployment diagram is really kinda of more of an object diagram or class diagram, except for wait why are you using the open arrows there??? What? Guess what? I can draw things in visio too. If I want to describe a sequence, I can draw a timeline or sequence diagram-like without any ritually specialized visual nomenclature. And it would be a lot more universally understood because nobody really knows the fine details of UML in the first place.
The fact that what I mean by arrows and boxes is unique to the situation and not a standard does not in any way reduce my ability to describe and communicate a design with arrows and boxes. Communicating a design via words, language, OR graphics is an art and it is not helped by a crude "universal" visual nomenclature that is in reality widely misused.
Secondly, nomenclature isn't the problem in the first place. Design is. Communication of the design is too. UML is more of a hindrance to these than a benefit. It's like the difference between a fine art portrait and an Identikit in the hands of a random wage slave with bad taste.
1. Developers don't pay the kind of money they once did for development tools. Many don't pay anything at all. Those that do pay money typically only pay for an IDE (JetBrains or something like that).
2. The lack of financial incentive from (1) makes it so we haven't seen and likely will never see a round-trip UML tool - which is what's badly-needed to make UML an actual productive tool. The article mentions this. That's really too bad because such a tool would be worth its weight in gold - but good luck getting anyone to pay for it.
That's just where we are at the moment as an industry. Worse is better. Especially if worse is free (as in beer).
I disagree with the premise, because the major tech companies are so good about releasing open source developer tools.
For example a unit testing framework is a really important developer tool. And we have great unit testing frameworks because Google has the firepower to invest in Googletest for its internal developers, then released Googletest to the world.
If UML was really productivity enhancing, I'm pretty sure Google would be using it. Even if it had to build it from scratch, a 1% improvement in developer productivity would easily amortize their cost to build a fantastic, open source UML tool.
Meh. The industry has spent the past 15 years preaching "emergent architecture and design." The fear of BUFD (big, up-front design) has shifted the pendulum to the opposite extreme: little or minimal design. So here we are. I still think there's a lot we can do with CASE (computer-aided software engineering) - just not in the way we envisioned in the 80s and 90s.
> I still think there's a lot we can do with CASE (computer-aided software engineering)
I'm pretty biased towards minimal upfront design. At least of the formal variety. But I'd like to make sure I'm not missing some low hanging fruit for easy improvements. Do you have any recommended reading for what you're talking about w.r.t. to CASE?
No - the industry abandoned CASE in the 90's and the pendulum swung back the other way. I worked for a company in the early 90's that bought into case hard. I never thought CASE was about the tool writing all your code - but they sure did! What a nightmare! I'd like to see CASE used to capture big-picture items, major information flows, configuration management handling and the like. I'd like to see UML diagrams dynamically generated from the underlying model. Utilize a query language to allow me to select a class and see what all it derives from and see what it interacts with - graphically. It's another way of interacting with a code base. That's the stuff I'd like to see us get to.
A "round-trip UML tool" is actually impossible, except for in very limited circumstances.
UML itself doesn't provide enough detail to completely develop the code, and the code doesn't provide enough model hints to completely develop the UML.
When there is enough detail, the diagrams become unreadable and the code becomes unmaintainable.
So every "round-trip" details are lost. People have been trying to solve this problem generally for 40 years. It's a lost cause.
When I left the UML world 15 years ago what was being worked on was the model. Not everything in the model has to be expressed in the diagram(s) - that simply makes the diagrams unusable. The problem is UML "grew up" being diagram-based, which can't be round-tripped. Too many people rejected the model approach and the two factors I identified were then able to kill it.
I asked my kids (all software engineers) this same question about a year ago. My daughter said it was because class diagrams became too complicated for uml.
I used to use uml class diagrams when coming up to speed on a new framework. I tried to do this recently and it was a nightmare.
I used to use sequence diagrams for my own code - but that is difficult to derive from someone else's code.
This was actually more enlightening than I expected... Ultimately, I think it comes down to:
"...software culture shifted progressively towards large tech-first companies and startups. Neither, historically, was the target audience of CASE vendors."
I still use it, just a few minutes ago actually. If there's a process that goes over multiple threads or actors, it's nice to have a sequence (?, that one with lanes). If there's a process that has distinct ways to change states it's nice to make a state diagram. Also you might like to have a diagram about your database before you build your database. Or one of those classic decision trees that everybody uses even outside of software.
I use a database diagram before I do anything in a new project all the time myself. It's a good way to start thinking about any data-heavy project. Inevitably there will be things I didn't consider and have to add while implementing but it's still a great first step.
I'll even draw them on paper sometimes (it's just squares with types and column names inside and arrows pointing to keys on other tables, mostly).
I worked for a company that was making a large CASE tool way back when and even at the time it felt like nonsense.
Internally it never even crossed our minds to use it as a means of building the tools themselves. I remember bringing this up at one point during a company meeting and the CEO glowered at me like I was pointing out some inconstancy in religious theology. He spun some web of garbage about why it wasn't appropriate for our specific needs. I was young and realized only afterward that it was just not something you were supposed to mention there.
It was actually fun to work on for a while and we sold a lot of product, but it eventually dried up along with the rest of that part of the industry.
You'd've thought so. Persisted to SQL-Server. Early 2000s, so totally impractical.
The CTO cofounder was not impressed by the UI guy asking out loud what every one was thinking.
The fancy pants UI I was tasked to create wasn't even backed by a query language or path expressions. So dumb.
I stayed just long enough to find another gig.
PS- I did storyboard and wireframed a novel UI which resolved the graph visualization "paradox" (aka "focus+context"). It'd be perfect for neo4j & Cypher. I always thought I'd eventually circle back, if only to see if the idea had legs. Oh well.
I still see UML as a blueprint in my industry (safety critical software), MagicDraw is one tool rising in prominence, Enterprise Architect is another. I definitely have seen a decline in UML for code generation. (I forget if the tools I mention have code generator capability but I generally don’t see them used if they do)
Interestingly I have seen a steady uptake in model driven development with code generation but it tends to be in tools like SCADE or Simulink, tools that are not directly object oriented but are more traditionally model oriented (code generation wise I believe these both generate C code).
I think one problem with UML as code generation is that the relationship between the model and the code can be constraining and many domain experts do not think in terms of classes and objects.
By the way, I do like the concept of UML as generating a code shell that gets filled in and modified, anyone have any open source recommendations for that? Preferably something that can integrate with Java and Spring
Safety critical software is about limiting the available software constructs to known safe ones (eg the MISRA standard) and adopting techniques and tooling like TLA+ that can be used to prove correct behavior.
Things like FMECA etc are techniques for safe software (and hardware).
Diagrams don't replace that. OOP as a technique (at least stuff about classes and inheritance and polymorphism) doesn't replace that.
OOP in terms of objects and messaging, with state machines are certainly part of safety software development.
The leftover CASE tools like Enterprise Architect are now basically documentation engines and have very little to do with the actual software development process.
Some of the resistance I have encountered from developers and engineering managers to writing sequence diagrams has been because it makes it harder for them to bullshit about what their code does, how it does it, and how complex (or not) it really is.
When you put an abstraction over something its parts can be replacable and in non-growth oriented development cultures this is what people try to avoid. Essentially, resistance to abstraction is often resistance to being managed.
More charitably, sometimes it’s impossible to accurately sequence events until you’ve tried implementing a thing, especially so when a 3rd party is involved.
We use a vendor’s API that’s very well documented, and if you asked me to chart how we’d use it based on those docs, it would be very straightforward. In reality, we (only halfway) joke that this vendor puts the “eventual” in “eventual consistency”. Like no kidding, it’s often up to 5 minutes between PUTting an object and being able to GET it back. This doesn’t violate any of their API docs at all, but you tend to think of CRUD apps as being either synchronous or having latencies of a second or two. This vendor never claimed to have be that way but I kind of assumed it, which is 100% my fault but still a bit understandable I think.
So the actual sequence doc is much more complex with several stages of polling cycles. In fact, it's really a linearization of what's actually implemented as a state machine. If a PM had held me to a simple, linear sequence diagram, they'd be upset that what I delivered didn't look at all like what I'd promised, but that's because we didn't know everything important in advance and we didn't know that we didn't know that. Lessons learned, huh?
I don’t mind diagrams for documenting what was actually done so the next maintainer can understand why things are a certain ways. I would enormously resist being made to write code to satisfy them in most contexts.
> We use a vendor’s API that’s very well documented, and if you asked me to chart how we’d use it based on those docs, it would be very straightforward. In reality, we (only halfway) joke that this vendor puts the “eventual” in “eventual consistency”. Like no kidding, it’s often up to 5 minutes between PUTting an object and being able to GET it back. This doesn’t violate any of their API docs at all, but you tend to think of CRUD apps as being either synchronous or having latencies of a second or two. This vendor never claimed to have be that way but I kind of assumed it, which is 100% my fault but still a bit understandable I think.
Funnily enough, dealing with a similar vendor is how I got my start with formal methods. Except in addition to 5+ minute latencies, if you sent a second PUT request during that time they _would start randomly deleting data._ Good times, good times.
However, the skill of being able to black-box a process is not distributed evenly. "Something goes in, something comes out" is simpler, and yet it requires a mental parallelism that we often don't realize can be more sophisticated than using domain knowledge to serially sound out individual concrete steps and conditions until you find a way to close the conceptual loop.
Architects and PM's take flak for not being technical enough because it's generally true that the map is not the territory. But having been there, it can be like watching engineers run a maze without a map, and refusing to either accept a map of the maze, or share a map with anyone else.
It's BFS vs. DFS, and they are approapriate for different types of problems. UML in totality is not always helpful, but the most powerful aspects of it can be disruptive to team anti-patterns, and I think this is part of why it has lost a lot of traction.
> it’s impossible to accurately sequence events until you’ve tried implementing a thing
In a general sense it's impossible to accurately model a thing until you've implemented it. All models wrong. Some models are useful. But doing the modelling, in the form of creating a sequence diagram, can be part of the process of going from idea to working code.
Managers like knowing what the code will do. The trouble is, compilers also like knowing what the code will do, and as soon as they know, it's time for delivery, and delaying while the boss catches up doesn't seem acceptable. How can managers find out what the code does ahead of delivery? There's only one way: managers have to ask to see the code before the compiler does.
UML as "Language to depict diagrams + set of tools on top of it + unified process and all the waterfall-ish bureaucracy around it" - yeah, sure, it's dead in the sense barely anyone uses it in such form.
UML as "Language to depict diagrams" - not so sure, I use component, state and sequence diagrams all the time (in both interview and main job settings).
> prominent people from the early days, including Grady Booch, Bertrand Meyer, and Ed Seidewitz
What does Bertrand Meyer have to do with the history of UML?
> they bought Jacobson’s consulting company and phased out OOSE.
Objectory was a much better tool than Rational Rose; never understood, why they killed it. The most useful features of UML and RUP came from Objectory (Rose only had clouds and arrows at that time).
> The Reasons
The given reasons are not very convincing. I would rather say that once again an originally good idea was blown up to such an extent that only the cargo cult league was completely satisfied with it, and everyone else realized that once again the wrong problem was being solved with a lot of effort.
> What does Bertrand Meyer have to do with the history of UML?
Good question! While he wasn't involved with the standardization of it, he was one of the first major opponents, primarily because 1) was already a giant in OOP methodology, and 2) had a competing notation (BON). Also he was a real big stickler about "it's not really OOP if you're not using EIFFEL (tee em)". So he had a lot of firsthand knowledge of the early controversies and arguments and stuff.
I guess Objectory etc. was better suited for statemachine like systems like telephone systems. I.e. the tool is better at Ericsson where it was originally used than IBM.
No, it was general purpose and the direct predecessor of the initial UML and RUP versions. Here is a summary in case you're interested: https://www.ivarjacobson.com/publications/books/object-orien.... Objectory was the name of the method, the tool and the company as well. The tool supported the whole development process with fully cross-referenced model versions for each phase, model integrated editors with a kind of transclusion (see https://en.wikipedia.org/wiki/Transclusion), and a very powerful document generator; even round-trip engineering was supported. Unfortunately the tool vanished when Rational both them and you barely can find anything about it on the web.
Transclusion (yes I had to look it up) I feel would be an interesting property in development and the "auto complete" type of transclusion always feels like a hack.
I wonder how structured software engineering feels like in a big project. Everywhere I have been involved, there were no structure what so ever on the technical level, just process on features and resources.
I once asked Jacobson whether he would release the source code; unfortunately he wasn't able to do so; maybe the IP owners will change their minds some day (as others did with their outdated software).
> Transclusion
I rarely see implementations of it. Some years ago I built a tool which shares a small subset of features with Objectory (so the transcluding links between items); here is the link in case you're interested: https://github.com/rochus-keller/CrossLine.
I wonder if git had a part in it. That UML doesn't have a good textual format, or really any standard file format, means it really doesn't play well with git. I remember IBM/Rational had some kind of diff & merge tool for UML, but it was horrible.
It has a standard format, it's just unpleasant. (XMI is not for writing by hand.)
There were other textual serializations in the various OMG standards. But you're representing a graph, which never works properly with line-oriented merge tools.
If you mean XMI that's XML indeed. But merely it using XML doesn't begin to describe its insanity. It has metamodels, meta-metamodels, ..., all described in OMG's "MOF", starting from the idea that OO principles somehow pass as formal method or logical framework, and ends in "Extreme UML", posing decision problems with unknown complexity/feasibility/decidability left and right.
It's truly junior OOP zealotry going beyond its comfort zone. What's particular bad IMHO is that OMG/IBM managed to undermine completely unrelated and useful BPM modelling standards into the dead end that was UML, taking those down along with the nonsensical XMI, MOF, EMF, GEF.
I mean, over my career,
I’ve seen plenty of flow charts, sequence diagrams, boxes-connected-by-arrows drawings and such. I’ve yet to encounter anybody whose actually done a formal “by the book” UML diagram.
They are just too formal for real world use. Auto generated ones provide both too much information and too little information to be useful. I’ve never encountered human generated ones. Probably because they too rigid.
Maybe the problem with UML is it just didn’t solve any real world problem. Perhaps diagrams created by humans to be consumed by humans don’t need a formal spec. There is just too much variation to capture in such a spec.
At least I think. Again, I’ve ever encountered a by the book UML diagram in my entire career. I’ve encountered plenty of informal diagrams though.
I spent quite a bit of time in corporate America in the early 2000's and saw a lot of UML being thrown around. I don't think anyone actually used any of the diagrams, but they were certainly required by the "process".
Fun fact, one guy on the team built hundreds of pages of documentation (mostly automated) including UML diagrams. We usually only used 1 or 2 pages of it downstream. He was famous for giving time back to the project. Come to think of it, maybe building in buffers in the project was his role the entire time and I just didn't realize it.
Personally, I've always thought that "too complex" was the most essential reason. To really get the intended value out of UML (as opposed to, say, cell phone pictures of ad-hoc whiteboard flowcharts), you need to put a lot of time into learning all its intricacies. Doing it right is a specialized skill, enough so that you probably need to commit a single person to maintaining the UML diagrams if you want things to remain coherent.
But that's a problem right there. Smaller teams can't afford to commit a person to fiddling with flowcharts like that, and, even on larger teams, the need to communicate with that person in order to make sure the charts stay up to date is a large effort. When I was at a Global 500 company, we had regular meetings with the UML folks where we'd go over the charts, they'd explain what everything meant - none of the developers had sufficient UML expertise to independently understand the diagrams beyond a rudimentary level - we'd explain where things had drifted away from the spec, and back and forth we'd go until it all settled out.
And I don't know what purpose all of that effort served, aside from satisfying a rule that had been passed down from above. Developers never went back and referred to these diagrams. Like I said, we couldn't really understand them, so it was quicker, easier, and more accurate to just read the code or talk to each other.
Managers were even less able to understand them, and knew that they were only accurate up to the last UML sync-up, which means they wouldn't cover work in progress, which is almost always the thing they're currently looking to understand. So they'd talk to developers. And maybe we'd have a meeting to bring each other to speed on how it all works and how that's working out, and how it needs to change. And maybe, during that meeting, we'd draw an ad-hoc diagram on the whiteboard while we talk. And maybe, if everyone thought it was sufficiently useful, we'd leave it up there and write "don't erase" next to it. And the fact that there was no formal specification of the visual language turned out not to matter, in the end, because the diagram never needed to be a formal specification in the first place; it was just a mnemonic device to help everyone remember what was discussed in the design meeting.
CASE never met its goals. It was yet another silver bullet in the software industry that has been ongoing since the IBM 360.
People point at NASA's software engineering as the gold standard, but what NASA shows is something that Charles Eames said "Design is about constraints".
NASA's software environments are all about constraints. Mission constraints, hardware constraints, environmental constraints, all lead to software that is beautifully written and maintained within those constraints.
The rest of the software world has tried to reproduce the process without understand the constraints. CASE, CMMI, Agile-with-a-capital-A, all are attempts by businesses to standardize and commoditize software development.
But software is about abstraction. We layer concepts on top of concrete hardware, then layer on top of that.
CASE didn't work because the layers were in the wrong places and of the wrong things. UML was an extension of that. It was based on expecting software development to be like engineering and manufacturing, which are oriented towards components and commodification, not layers.
Indeed. I think most engineers would LOVE to have the kinds of constraints on their software that NASA has. The reason our code trends toward big balls of mud is that the requirements are ill-defined and constantly changing.
Welcome to the real world. As you point out, NASA lives in Wonderland by comparison. Good software handles real-world issues and changes without continual fundamental architectural redesigns. 95% of the bad software I've seen has been a result of not understanding one of two things, (which are really the same): 1) What the software needs to do to function in the real world, and 2) what the people who use the software need to do and how they think about their environment and the problems they need solved. It sounds trite, but in almost all cases, this really is all that separates great software from unbearably horrible software, and the astute observer will note that this has far more to do with understanding people than it does computers....
I don't disagree with you, but I don't think the responsibility lies primarily with the engineer. Especially in large orgs, you have armies of people whose job is ostensibly to understand the needs of the people their team serves, yet they continually fail to do so.
I'd argue as well that type systems in the extremely popular programming languages make it difficult to reduce the surface area of your problem appropriately as well.
Some more fringe languages make significant strides in this with dependent types.
The burden is much higher on tests than it needs to be because we can't express these constraints in code well enough.
Arguably components are layers of sorts, but in hardware layers are expensive, in software layers are cheap.
The constraints and costs are mostly around the long term maintaince rather than manufacturing. I think if compiling and distributing software had some meaningful cost associated with it software would be very different.
CASE is a label for a set of tools that augment software development. Its not a "goal", it changes and morphs over time.
Every major computer and software house would develop something useful that would inevitably attempt to extend itself to control the entire software development life-cycle of activity. Even clients either pledged allegiance (vendor lock-in) or created their own Frankenstein SDLC mutations. All of this thrashing was used to insulate themselves from new or alternative ideas. And with the advent of personal computers all that stuff began a rapid entropy. All the "exclusive" iconic notations were in free fall.
And with that free fall, the realization that every diagram was tightly coupled to the next and that every neglected update to any diagram corrupted everything to follow - a big ball of systems design mud debt that was more cost effective to jettison than remedy. Couple that with the timely corporate reorganizations and layoffs and a perfect storm of costly obsolescence eliminated any taste to do that [UML-ish systems capture] again.
This never precluded the usefulness of subject diagramming at all but the costly CASE tool overhead simply evaporated except in low accountability government environments or deep pocket goliaths.
OTOH, CASE in an uncredited way still thrives in smart IDEs and Dev/Ops utilities that constrain the opportunity for non-conformant code to get deployed. Broader design issues remain.
CASE, in fact, did theoretically work. In practical, sustainable terms it could not.
The more accurate failure is in the attempt to create an iconic notation that could ever be broadly disseminated and practiced confidently in the eclectic and unpredictable programming community.
Which is why sketch UML is popular. It looks like UML if you squint and gets the important reasons to use UML on a whiteboard. Then after everyone agrees you erase the whiteboard.
Sure, but you also take notes of the features, constraints, and invariants that were discussed. At the end of the meeting, instead of having a diagram which acts as a rigid spec, you have a set of notes and diagrams which informally describe the problem space, the proposed solutions, the benefits, the drawbacks, and any important details. And that's more useful and more flexible than UML.
200 comments
[ 3.8 ms ] story [ 263 ms ] threadI know, I used to work on one such MDA tool. It first started with the assumption that you want to generate a J2EE application. By the time the code generation was "good" Spring and Hibernate came along and simplified things to the point that it was easier and faster to "just code."
Turning UML into executable code could be done in one of two ways. Transform one high-level model into an implementation-specific model and generate code from that, or, create a UML VM that could run the models directly.
The latter would have been the correct solution, and still would be more complicated than it's worth.
Use UML for communication. It's still good at that.
The real reason that UML died is that it was a solution in search of a problem that it could actually solve. It was one that had a lot of appeal for people, so it took longer to die than it should have. But it died because in practice, it was largely useless.
UML is awesome IMHO and I've used it on every CRUD app that I've built. I am saddened about it's lack of widespread use.
Today there are a zillion CRUD generator tools, most of which don't use UML. It's not difficult. Many people who've worked on CRUD apps have probably written some autogeneration thing themselves at some point. Automating some boilerplate code generation doesn't solve any challenging problem in software development.
Conspiracy theories are fun, but the "real" reason is in one of the several articles floating around HN that past few days. Mainly, it was a disorganized mess that no one was going to build tools for. Then IBM got hold of it, then...
[0] Previously it was, "we don't care if it makes money as long as it supports the Windows platform", hence the "developers, developers, developers" from Ballmer that folks like to dunk on. I was a grunt in DevDiv, so take it all with a grain of salt.
> stand ready to sell you the tool
There are a few - they've never been from MSFT
Multiplying per-worker output in a field whose output isn’t limited by capital or raw materials doesn’t destroy jobs, it creates them.
That may be true, I’m just saying even jf it did, that wouldn't make it a job killer but a job enabler. The whole reason computing is a growing field is it keeps inventing ways to multiply its own output. If that caused the field to shrink, the progressive move from punch cards to IDEs would have destroyed the field.
The fact that most people can't see the difference today is disturbing. It's a sign that we are trapped in an inefficiency mindset. We're always looking to solve problems in ways which create more problems instead of solving problems once and for all and then focusing on different problems.
I guess one upside is that developers know how to make diagrams. Which is good.
A simple diagram with components and how they communicate is pretty explanatory if you want a bird's eye view.
UML seems to try to be too specific and detailed when it comes to relationships, inheritances, hierarchies, etc but it's often just unnecessary, because every language/API/framework have their own way of dealing with details.
Not to mention that UML is often poorly specified and developers will not really respect the UML spec. It's like math, there are dialects. Programming language are better just because they have a proper parser that will verify correctness.
It's hard to understand why one would verify the correctness of an UML diagram.
But knowing the difference and being able to draw more or less accurate high-level sequence/flow/component diagram is vital skill for skilled developer.
>> Programming language are better just because Programming language is usually poor choice for explaining design of system
I think it was valuable. I suspect many engineers use simple diagrams in notebooks on a regular basis, and by introducing it very early in the degree it gave us another tool to help think about the code we were writing.
It wasn't actually UML, but I think it's a good thing to cover at the beginning of a course.
Same thing with design patterns: they won't solve all your problems but give engineers a common vocabulary.
This is such a great point!
Very informal boxes and arrows with random annotations have proven far more effective than a fully specified visual language.
(original): Given how well-written the rest of the article is, I have to believe that's deliberate.
https://www.asiaone.com/digital/after-years-online-ridicule-...
That "hacker" who has studied the kernel, knows that if you can compromise the kernel and gain root, all the other programs fall because your password keychain will be exposed, and no one keeps track of their own passwords anymore. Hackers don't need a resume or interview and references as a barrier for entry, it's a skills test.
I sound like I'm romanticizing the "hacker", but I wouldn't want to be one. If you get caught, these days, you're hosed. Not to mention, a lot of them are state sponsored from not very nice states, so to speak.
Hashing out a class diagram that shows how the domain entities relate to each other can still be pivotal in communicating the intended information model in a design. Pre-pandemic, this would involve words, lines, and cardinalities on a whiteboard (boxes optional).
Nowadays, a quick domain entity diagram in Whimsical does the trick.
A sequence diagram can quickly communicate an expected interaction pattern. The point is not to specify anything up front. The point of UML was always to serve first as a communication tool. Have commonly understood pictorial notations that let you talk about the software you're building.
When it was first invented, UML was aimed at "Unifying" how we diagram things. First, for books, and for the patterns movement. Even the heavy-weight Rational Unified Process was intended to be used in an iterative fashion. But it was constructed from a consulting mindset where you have intermediate steps of review and approval.
Blaming UML for the heavy-handed process where "thou shalt specify everything in advance" is like blaming the English language for that crappy novel you wasted your time on.
UML still has a place, IMHO, but only in that it helps you get over a few speed bumps on the way to helping your team produce working software.
See but “unifying how we diagram things” isn’t a problem that needs to be solved. A good diagram on a whiteboard is more art than science. It is also something that is intentionally as low of fidelity as possible because you might blow it away and do something entirely different.
There doesn’t need any “standard” for how to do adhoc diagrams.
The minute you add “formal standard” to the process it gets slower when you want it to be even faster. If my whiteboard diagram had to adhere to UML... I wouldn’t bother.
From the article:
> In his book on Business Object Notation, Bertrand Meyer lists twenty-six competing methods. I remember reading documents that listed over fifty, but I can’t seem to find them again so it might be a false memory.
I also distinctly remember how difficult it was to learn from other's designs. Back then, there was no Stack Overflow or Google. Developers like me obsessed over the latest books (like this new Design Patterns book, have you heard about it?!?)
It isn't a problem today because that's not how design ideas get communicated anymore. You have blog posts, and GitHub repos with examples and Markdown. This is better. But in the mid to late 90s, UML really helped.
Disclaimer: I was on many of those OMG committees for Model Driven Architecture and UML back in its heyday. I've also sat in Sushi restaurants after conference proceedings during dinner with some of the people mentioned in the article. The talk was of how we were going to change the industry. I smile to think of how things moved on without our dreams. :)
Oh yes there does.
I have seen people makeup ad hoc notation during an ad hoc diagram and then get confused by what it means orthe meaning shifts during the diagram. No, we have a standardised language. You wouldn't want blueprints with ad hoc units. "14 snails thick, and 3 rabbit-seconds in length which we indicate with an underlined star"
And, while it's my opinion only, blueprints for software are best written in prose. For C++ for example, I think the best language to use is concise, precise, well written, C++. And so on.
Of those two (which are the only two I've heard called out by their name in any business context), I've not seen consistent notation. Sometimes it's a problem, sometimes it isn't, but invariably what is more important is the conversation happening alongside the diagram; the diagram by itself is not a useful artifact, just like the slides to a (good) presentation, by themselves, are not useful.
The last time I drew a use case diagram, it was in jest.
This I think was the real thrust of the argument. While UML's death may be exaggerated in many corners of the corporate world, so too is its life in representing our industry as a whole.
If your inheritance structure is so complicated that you need a class diagram, you are probably in for pain... But class diagrams do their job for sure.
I find UML useful as post-coding documentation. After you figured out how things work, you UML diagram your code to help explain the complicated parts.
UML is also useful for talking with coworkers. As a 'sketch' don't try to get everything right, but coworkers often need to know what your plans are if they are to find work that won't conflict with your plan.
I think another UML post was talking about sketch 'masala' graphs (throw everything into a touchy feely graphic that really doesn't say much). Being absolutely vague and nontechnical is an advantage in some cases, but not useful to engineers. UML, for all of it's faults, is precisely defined. Every symbol means something.
[1] https://news.ycombinator.com/item?id=26956728
This misses the point of UML, entirely. The point is not that diagramming was invented, it was that it was standardized.
So you don't have to spend half your meeting discussing just exactly what this particular arrow between these two boxes means.
That said, the formalism does not say much about error handling. This is where state machines can get really hairy, in much the same way that throw/catch gets nasty in any non-trivial system.
That's another fault, in my opinion. I'd rather have a vague high-level diagram with a write-up that rigorously describes all the invariants and structure than have a really semantic diagram which is meant to stand alone.
I think software structure is too complex to model with anything less powerful than natural language — that's why we add comments into code to explain the things that even the code itself doesn't make obvious.
I ended up doing the coding, and using a tool that generated the UML from it, so that I could make it nicer.
> Code first, design later "they" said
Ah, ops... :)
Since Rational was sold in 2003, UML has just been lurching from one generation of engineers to another shouting 'braaaiiins'.
Trying to discuss UML objectively without the context of who was selling what at the time is pointless. It was never a good enough method to live beyond being kept on life support by the marketers.
Back then, anything that could be used to increase a manager's department budget could be the basis for a business. There was a job, "System Analyst", whose output was supposed to be stuff like that. Programmers were supposed to just code what the diagrams System Analysts produced said, and not try to think.
There is still an ISO Standard for regular flowcharts, and lots of DoD contracts require delivery of ISO Standard Flowcharts, so there are tools to automatically generate flowcharts from source code, which are printed out, delivered, and dropped in file drawers in dusty warehouses.
Every five or ten years ISO issues a new Flowchart Standard. It has been suggested that they issue a Standard that says any old blank sheet of paper meets the Standard, to save a lot of money on printing them out and storing them. It hasn't happened yet.
It would not be surprising if there were a zombie ISO UML Standard, and contracts requiring software be delivered with conforming UML.
A tool which could create visual diagrams for logic flow and abstraction would be amazing. After parsing a large project, many people create a mental map which feels quite close to some sort of visual diagram. If someone could figure out how to represent those models visually, I think it’d be a lot easier to identify good abstractions for a problem and its likely evolution vs bad abstractions for a problem and its likely evolution.
I've never seen UML actually work anyplace else. Either the models are out of date, or they are only up to date because you force people to go back to maintain the models after the code is working. This latter of course fails, why would management want to pay someone do maintain models when not only is the code working (well at least partially) for the testers, but the person who is assigned to do it doesn't want to.
So? Doesn't mean that it was actually doing anything useful 99.99% of the time.
It's supposed to be a universal (visual) language. Two problems, in the real world the way it was used and, more often than not, misused it was far from universal. I mean that deployment diagram is really kinda of more of an object diagram or class diagram, except for wait why are you using the open arrows there??? What? Guess what? I can draw things in visio too. If I want to describe a sequence, I can draw a timeline or sequence diagram-like without any ritually specialized visual nomenclature. And it would be a lot more universally understood because nobody really knows the fine details of UML in the first place.
The fact that what I mean by arrows and boxes is unique to the situation and not a standard does not in any way reduce my ability to describe and communicate a design with arrows and boxes. Communicating a design via words, language, OR graphics is an art and it is not helped by a crude "universal" visual nomenclature that is in reality widely misused.
Secondly, nomenclature isn't the problem in the first place. Design is. Communication of the design is too. UML is more of a hindrance to these than a benefit. It's like the difference between a fine art portrait and an Identikit in the hands of a random wage slave with bad taste.
1. Developers don't pay the kind of money they once did for development tools. Many don't pay anything at all. Those that do pay money typically only pay for an IDE (JetBrains or something like that).
2. The lack of financial incentive from (1) makes it so we haven't seen and likely will never see a round-trip UML tool - which is what's badly-needed to make UML an actual productive tool. The article mentions this. That's really too bad because such a tool would be worth its weight in gold - but good luck getting anyone to pay for it.
That's just where we are at the moment as an industry. Worse is better. Especially if worse is free (as in beer).
For example a unit testing framework is a really important developer tool. And we have great unit testing frameworks because Google has the firepower to invest in Googletest for its internal developers, then released Googletest to the world.
If UML was really productivity enhancing, I'm pretty sure Google would be using it. Even if it had to build it from scratch, a 1% improvement in developer productivity would easily amortize their cost to build a fantastic, open source UML tool.
I'm pretty biased towards minimal upfront design. At least of the formal variety. But I'd like to make sure I'm not missing some low hanging fruit for easy improvements. Do you have any recommended reading for what you're talking about w.r.t. to CASE?
UML itself doesn't provide enough detail to completely develop the code, and the code doesn't provide enough model hints to completely develop the UML.
When there is enough detail, the diagrams become unreadable and the code becomes unmaintainable.
So every "round-trip" details are lost. People have been trying to solve this problem generally for 40 years. It's a lost cause.
I used to use uml class diagrams when coming up to speed on a new framework. I tried to do this recently and it was a nightmare.
I used to use sequence diagrams for my own code - but that is difficult to derive from someone else's code.
I'll even draw them on paper sometimes (it's just squares with types and column names inside and arrows pointing to keys on other tables, mostly).
Internally it never even crossed our minds to use it as a means of building the tools themselves. I remember bringing this up at one point during a company meeting and the CEO glowered at me like I was pointing out some inconstancy in religious theology. He spun some web of garbage about why it wasn't appropriate for our specific needs. I was young and realized only afterward that it was just not something you were supposed to mention there.
It was actually fun to work on for a while and we sold a lot of product, but it eventually dried up along with the rest of that part of the industry.
I wonder if this was the case everywhere in the company.
Obviously, this doesn't apply to everything, but that's definitely a smell for product-market fit.
> I was young and realized only afterward...
If I could give young me any single piece of advice, it'd be "OMG STFU. Just smile and cash the check."
The CTO cofounder was not impressed by the UI guy asking out loud what every one was thinking.
The fancy pants UI I was tasked to create wasn't even backed by a query language or path expressions. So dumb.
I stayed just long enough to find another gig.
PS- I did storyboard and wireframed a novel UI which resolved the graph visualization "paradox" (aka "focus+context"). It'd be perfect for neo4j & Cypher. I always thought I'd eventually circle back, if only to see if the idea had legs. Oh well.
Eating one's own dog food was not part of the road map.
Interestingly I have seen a steady uptake in model driven development with code generation but it tends to be in tools like SCADE or Simulink, tools that are not directly object oriented but are more traditionally model oriented (code generation wise I believe these both generate C code).
I think one problem with UML as code generation is that the relationship between the model and the code can be constraining and many domain experts do not think in terms of classes and objects.
By the way, I do like the concept of UML as generating a code shell that gets filled in and modified, anyone have any open source recommendations for that? Preferably something that can integrate with Java and Spring
Things like FMECA etc are techniques for safe software (and hardware).
Diagrams don't replace that. OOP as a technique (at least stuff about classes and inheritance and polymorphism) doesn't replace that.
OOP in terms of objects and messaging, with state machines are certainly part of safety software development.
The leftover CASE tools like Enterprise Architect are now basically documentation engines and have very little to do with the actual software development process.
When you put an abstraction over something its parts can be replacable and in non-growth oriented development cultures this is what people try to avoid. Essentially, resistance to abstraction is often resistance to being managed.
We use a vendor’s API that’s very well documented, and if you asked me to chart how we’d use it based on those docs, it would be very straightforward. In reality, we (only halfway) joke that this vendor puts the “eventual” in “eventual consistency”. Like no kidding, it’s often up to 5 minutes between PUTting an object and being able to GET it back. This doesn’t violate any of their API docs at all, but you tend to think of CRUD apps as being either synchronous or having latencies of a second or two. This vendor never claimed to have be that way but I kind of assumed it, which is 100% my fault but still a bit understandable I think.
So the actual sequence doc is much more complex with several stages of polling cycles. In fact, it's really a linearization of what's actually implemented as a state machine. If a PM had held me to a simple, linear sequence diagram, they'd be upset that what I delivered didn't look at all like what I'd promised, but that's because we didn't know everything important in advance and we didn't know that we didn't know that. Lessons learned, huh?
I don’t mind diagrams for documenting what was actually done so the next maintainer can understand why things are a certain ways. I would enormously resist being made to write code to satisfy them in most contexts.
Funnily enough, dealing with a similar vendor is how I got my start with formal methods. Except in addition to 5+ minute latencies, if you sent a second PUT request during that time they _would start randomly deleting data._ Good times, good times.
This one triggered conversations along the lines of “how hard would it be to replace that vendor with a Django app, really?”
However, the skill of being able to black-box a process is not distributed evenly. "Something goes in, something comes out" is simpler, and yet it requires a mental parallelism that we often don't realize can be more sophisticated than using domain knowledge to serially sound out individual concrete steps and conditions until you find a way to close the conceptual loop.
Architects and PM's take flak for not being technical enough because it's generally true that the map is not the territory. But having been there, it can be like watching engineers run a maze without a map, and refusing to either accept a map of the maze, or share a map with anyone else.
It's BFS vs. DFS, and they are approapriate for different types of problems. UML in totality is not always helpful, but the most powerful aspects of it can be disruptive to team anti-patterns, and I think this is part of why it has lost a lot of traction.
In a general sense it's impossible to accurately model a thing until you've implemented it. All models wrong. Some models are useful. But doing the modelling, in the form of creating a sequence diagram, can be part of the process of going from idea to working code.
UML as "Language to depict diagrams" - not so sure, I use component, state and sequence diagrams all the time (in both interview and main job settings).
What does Bertrand Meyer have to do with the history of UML?
> they bought Jacobson’s consulting company and phased out OOSE.
Objectory was a much better tool than Rational Rose; never understood, why they killed it. The most useful features of UML and RUP came from Objectory (Rose only had clouds and arrows at that time).
> The Reasons
The given reasons are not very convincing. I would rather say that once again an originally good idea was blown up to such an extent that only the cargo cult league was completely satisfied with it, and everyone else realized that once again the wrong problem was being solved with a lot of effort.
Good question! While he wasn't involved with the standardization of it, he was one of the first major opponents, primarily because 1) was already a giant in OOP methodology, and 2) had a competing notation (BON). Also he was a real big stickler about "it's not really OOP if you're not using EIFFEL (tee em)". So he had a lot of firsthand knowledge of the early controversies and arguments and stuff.
Transclusion (yes I had to look it up) I feel would be an interesting property in development and the "auto complete" type of transclusion always feels like a hack.
I wonder how structured software engineering feels like in a big project. Everywhere I have been involved, there were no structure what so ever on the technical level, just process on features and resources.
I once asked Jacobson whether he would release the source code; unfortunately he wasn't able to do so; maybe the IP owners will change their minds some day (as others did with their outdated software).
> Transclusion
I rarely see implementations of it. Some years ago I built a tool which shares a small subset of features with Objectory (so the transcluding links between items); here is the link in case you're interested: https://github.com/rochus-keller/CrossLine.
There were other textual serializations in the various OMG standards. But you're representing a graph, which never works properly with line-oriented merge tools.
It's truly junior OOP zealotry going beyond its comfort zone. What's particular bad IMHO is that OMG/IBM managed to undermine completely unrelated and useful BPM modelling standards into the dead end that was UML, taking those down along with the nonsensical XMI, MOF, EMF, GEF.
We did have a course on Object Oriented Databases, which would obviously take over the world.
Except they didn't. And CORBA.
They are just too formal for real world use. Auto generated ones provide both too much information and too little information to be useful. I’ve never encountered human generated ones. Probably because they too rigid.
Maybe the problem with UML is it just didn’t solve any real world problem. Perhaps diagrams created by humans to be consumed by humans don’t need a formal spec. There is just too much variation to capture in such a spec.
At least I think. Again, I’ve ever encountered a by the book UML diagram in my entire career. I’ve encountered plenty of informal diagrams though.
Fun fact, one guy on the team built hundreds of pages of documentation (mostly automated) including UML diagrams. We usually only used 1 or 2 pages of it downstream. He was famous for giving time back to the project. Come to think of it, maybe building in buffers in the project was his role the entire time and I just didn't realize it.
Personally, I've always thought that "too complex" was the most essential reason. To really get the intended value out of UML (as opposed to, say, cell phone pictures of ad-hoc whiteboard flowcharts), you need to put a lot of time into learning all its intricacies. Doing it right is a specialized skill, enough so that you probably need to commit a single person to maintaining the UML diagrams if you want things to remain coherent.
But that's a problem right there. Smaller teams can't afford to commit a person to fiddling with flowcharts like that, and, even on larger teams, the need to communicate with that person in order to make sure the charts stay up to date is a large effort. When I was at a Global 500 company, we had regular meetings with the UML folks where we'd go over the charts, they'd explain what everything meant - none of the developers had sufficient UML expertise to independently understand the diagrams beyond a rudimentary level - we'd explain where things had drifted away from the spec, and back and forth we'd go until it all settled out.
And I don't know what purpose all of that effort served, aside from satisfying a rule that had been passed down from above. Developers never went back and referred to these diagrams. Like I said, we couldn't really understand them, so it was quicker, easier, and more accurate to just read the code or talk to each other.
Managers were even less able to understand them, and knew that they were only accurate up to the last UML sync-up, which means they wouldn't cover work in progress, which is almost always the thing they're currently looking to understand. So they'd talk to developers. And maybe we'd have a meeting to bring each other to speed on how it all works and how that's working out, and how it needs to change. And maybe, during that meeting, we'd draw an ad-hoc diagram on the whiteboard while we talk. And maybe, if everyone thought it was sufficiently useful, we'd leave it up there and write "don't erase" next to it. And the fact that there was no formal specification of the visual language turned out not to matter, in the end, because the diagram never needed to be a formal specification in the first place; it was just a mnemonic device to help everyone remember what was discussed in the design meeting.
People point at NASA's software engineering as the gold standard, but what NASA shows is something that Charles Eames said "Design is about constraints".
NASA's software environments are all about constraints. Mission constraints, hardware constraints, environmental constraints, all lead to software that is beautifully written and maintained within those constraints.
The rest of the software world has tried to reproduce the process without understand the constraints. CASE, CMMI, Agile-with-a-capital-A, all are attempts by businesses to standardize and commoditize software development.
But software is about abstraction. We layer concepts on top of concrete hardware, then layer on top of that.
CASE didn't work because the layers were in the wrong places and of the wrong things. UML was an extension of that. It was based on expecting software development to be like engineering and manufacturing, which are oriented towards components and commodification, not layers.
Indeed. I think most engineers would LOVE to have the kinds of constraints on their software that NASA has. The reason our code trends toward big balls of mud is that the requirements are ill-defined and constantly changing.
Some more fringe languages make significant strides in this with dependent types.
The burden is much higher on tests than it needs to be because we can't express these constraints in code well enough.
The constraints and costs are mostly around the long term maintaince rather than manufacturing. I think if compiling and distributing software had some meaningful cost associated with it software would be very different.
CASE is a label for a set of tools that augment software development. Its not a "goal", it changes and morphs over time.
Every major computer and software house would develop something useful that would inevitably attempt to extend itself to control the entire software development life-cycle of activity. Even clients either pledged allegiance (vendor lock-in) or created their own Frankenstein SDLC mutations. All of this thrashing was used to insulate themselves from new or alternative ideas. And with the advent of personal computers all that stuff began a rapid entropy. All the "exclusive" iconic notations were in free fall.
And with that free fall, the realization that every diagram was tightly coupled to the next and that every neglected update to any diagram corrupted everything to follow - a big ball of systems design mud debt that was more cost effective to jettison than remedy. Couple that with the timely corporate reorganizations and layoffs and a perfect storm of costly obsolescence eliminated any taste to do that [UML-ish systems capture] again.
This never precluded the usefulness of subject diagramming at all but the costly CASE tool overhead simply evaporated except in low accountability government environments or deep pocket goliaths.
OTOH, CASE in an uncredited way still thrives in smart IDEs and Dev/Ops utilities that constrain the opportunity for non-conformant code to get deployed. Broader design issues remain.
CASE, in fact, did theoretically work. In practical, sustainable terms it could not.
The more accurate failure is in the attempt to create an iconic notation that could ever be broadly disseminated and practiced confidently in the eclectic and unpredictable programming community.