Why UML “Really” Died
buttondown.email
buttondown.email
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.
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.
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.
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.
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.
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.
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'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.
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.
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.
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.
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.
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 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.
Obviously, this doesn't apply to everything, but that's definitely a smell for product-market fit.
I wonder if this was the case everywhere in the company.
I must say, the drawing (CASE) tools have always been missing even very basic elements of UML.
I learned UML in the year 2000 by reading the full "The Unified Modeling Language User Guide" book by Booch, Rumbaugh and Jacobson.
Every time I tried to create a diagram during the years, after envisioning how I would express the idea with UML I was blocked by the tool not supporting the notation elements I needed. Like for communication diagram the tool did not support the iteration notation for message numbers, only simple numbers (what tool was it? maybe even Rational Rose). Or qualified assignation (when association is a lookup by a key).
I adjusted to not expect much from the tools and I think I know how to use UML to create useful illustrations - just workaround the tool limitation with a comment or build the notation element from basic boxes or use a less descriptive notation then I wanted initially.
Not to say I used UML very much over the years, as I use it today I realize I forgot many things and need to refresh my memory.
However, I see sequence diagrams used all the time. From time to time I see other diagrams. The tools like plantuml as well as the online utilities like https://www.websequencediagrams.com/, https://swimlanes.io and https://sequencediagram.org are flourishing.
I guess one upside is that developers know how to make diagrams. Which is good.
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.
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
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.
In 2001 I was working as real-time/embedded software engineer in France, our project was still running on old hardware, mostly C and asm on 68k.
One day before the summer vacations we were asked to come and see a full-day presentation of the future.
The presentation was made by an other team, working with embedded Java for microchips and ATM, UML and Rational was at the center of everything.
It was so unreal I had a hard time staying calm.
It was the day I decided to switch career, and that I would quit on the spot if they forced us to use anything as awful as those "methods".
For many good reasons, including the rise of bottom-up hacker and startup culture, and the need for flexibility/iteration between the design and implementation, we've shifted to a paradigm where the architect is also usually the programmer, especially at the early stages of the software creation process. The architect themselves usually writes the core functionality of the software. This is true even at big modern tech companies.
Furthermore, "Software architect" is far less a distinct job description like it used to be, but now refers to the degree of responsibility an individual has for the software's structure and design, which usually correlated with experience and the project scope.
It backfired horribly once "Architects" realized how precise they had to be with these cheap teams.
I don't think this is true. The Architect-Programmer model precedes offshoring by decades, even if it was repurposed to facilitate offshoring.
It was the dominant model during the "Corporate IT" phase of the software industry (before the web/Internet took over), and was famously satirized in the classic movie Office Space and also in the Dilbert comics.
It has older roots in traditional corporate structures that strongly delineate "corporate" vs everyone else. The word "corporate" in office culture even used to mean "distant, out of touch bosses in luxury offices", and still kind of means that in industries with similarly stratified workforces.
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 assumption I think is sorta analogous to how we knew waterfall and even spiral were hard, and that many teams would need help to deliver successfully... then someone told those teams they don't have to work that hard, if they instead operated more like situated action reactive agents instead of planning ones... and then the default impression became that people who did waterfall/spiral must not have been as enlightened as ourselves, and we have nothing to learn from them. :)
I could yammer for hours on methods and tools, but I'm more passionate about other topics right now. I'll just quickly point out one barrier to uptake of UML...
One of the barriers to the modeling methodologies was that many people didn't know how to use them, and so presumably didn't see benefit. That they didn't get it was obvious when you'd see diagrams that were simply wrong, or that expressed no information other than being a not-very-helpful transliteration of code. And a lot of the examples people saw also had this problem.
A memorable epiphany I had was shortly after joining an R&D group for next-gen OO CASE. One of the senior people was describing some complicated unfamiliar thing we had to understand, and using an OMT diagram to do so, pointing to things on the diagram as he explained... and it clicked: I was understanding so much from a diagram, and we couldn't have gotten that from code.
I then learned all the other modeling things, and set about to design an approach to make it practical to use them all sorts of places (roundtrip, methodology flexibility, better HCI, etc.). Then business things happened, maybe because Rational was locking in an industry shift with what was turning into UML, and so I instead went to work on Web and HCI&AI hybrids.
Why bother? Skippy, the agile programmer, had already coded something up that happened to feature the end-users favorite color.
Eye candy always trumps rigor and deliberate modeling of components.
Formal notations didn't stand a chance.
That's why I whole-heartedly disagree with "At best you’ve got a cumbersome system that’s significantly worse than using a graphical editor" from the article. I'll take succinct text over your graphical editor any day of the week, and my colleagues agree with me.
Anyways. All hail plantuml ;)
Besides plantuml there's also the very similar mermaid which will work in gitlab markdown and show up in the browser.
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.
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.
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?”
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.
If any abstract box in your diagram can be arbitrarily complex, then it's not going to stay in that little box. It will develop tendrils into logging and error mechanisms, and start to find extra jobs it can do with extra connections to other components. Pretty soon the semantics of the box will be so complex that they can't be reproduced elsewhere, and you will have to use that box for all kinds of new tasks.
I imagine a database was, at one time, just a little box on someone's diagram. Now it's Oracle Spanner RAC Mongo Hadoop and must be used by every line of code in the world to get anything done. That's why a diagram is useless (EDIT: useless as a prescriptive language, but still useful as a descriptive language.).
The former is alive and well, after shedding a lot of the fiddly details and requirements that the bits of the diagram be expressed in low-level details. Case in point: association vs aggregation vs. composition in class diagrams. All three express a similar idea by having a line joining the two classes: this class and this other class work together. But for aggregation and composition, one end of the line is supposed to have a diamond. Which end? Should the diamond be open or closed? What about multiplicity? Which end of the line has the number? It depends, sometimes both.
But all that detail, while sometimes useful to people looking at the diagram, really only matters for the benighted folks who try to make their UML diagrams input into code generators.
Forget "UML is dying", accept that CASE tools will never be more than fancy and fiddly code generators, and use the general ideas around diagramming, including some UML syntax, as a way to communicate among team members and stakeholders who are sufficiently technical.
1. https://news.ycombinator.com/item?id=26934577
p.s. Don't use quotation marks for emphasis. Ever. It's wrong.
Iconic notations exist to describe all manner and form of reality and technical specification.
The first "goal" of UML was to eliminate and consolidate the free-range software development notations. And that was something that could have turned into something useful.
UML's attention turned to code generation and no-code paradigms that will take generations of refinement to ever be useful in complex environments. Diagramming notations were contorted to serve the goal of code generation instead of programmer utility.
The consequence was that programmers were denied anything personally useful about UML and instead were saddled with a soul-sucking, task master of a tool that never fulfilled the business community's no-code expectations. The kicker was that now the development staff needed to untangle the no-code, generated code to make it work. What's to like?
We still have diagramming tools that create and work with the useful parts of UML in reasonable ways, we just needed to jettison the no-code weight that was dragging the notation into dead ends.
> The other ambiguity is what we mean by UML. First of all, UML consists of over a dozen different diagram types. I still see people regularly use sequence diagrams. Second, there’s many different ways people use UML diagrams. Martin Fowler, a prominent figure in both the UML and Agile worlds, identifies three types of uses: sketching, blueprinting, and programming.
Then they talk explicitly about blueprinting.
It may be useful, but aside from sequence diagrams I rarely see anyone using it; its not just CASE that has died but the wider field of systematic analysis and modeling has declined in relative importance. Not having a good model of how it fits into short-iteration development workflows that eschew big upfront design seems to be the main cause.
And for what remains of that space, there are newer tools occupying some of it.
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).
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).
1. Doing sequence diagrams in Visio, sans any kind of plugin that understood them; cue realising you'd missed a bit out and having to do an awkward group-select and drag a load of gubbins down the page to make room, then finding you'd missed an arrow or something ....
2. CASE tools that promised round-trip engineering .... so my Hovercraft contains many Eels, and I have that in my nice UML diagram, but how is that going to translate into pre-generics Java and back again? Spoiler - it isn't
3. Being given a massive wad of UML diagrams by a client, but the author had actually done all the contains relations as if it was a data model diagram, so all the relations were backwards - i.e. Eel diamond-arrow Hovercraft, because that's how the foreign keys would be done. How to break this kindly ...
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... :)
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.
Attend OOPSLA '98. Spot break out session on Software Architecture. Featuring Grady Booch! Oh boy, I gotta go.
Finally work up courage to ask my hero Booch "What is 'Software Architecture'?"
Long, thoughtful pause. "'Software Architecture' is what Software Architects create."
Poof. Bubble popped.
FWIW, the Agile Methodology™ hype cycle is self same.
Much later, I stumbled apon (paraphrasing) "architecture is the set of visible design choices" from the economics book Design Rules: The Power of Modularity.
I long thought that book would become seminal, classic. Shows what I know.
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.
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.
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.
I wonder if there's a clear boundary beyond which visual formalisms are no longer effective? I'm reminded of visual proofs in mathematics, and their reputation for being unreliable and misleading. It would be cool if we could identify a subset of cases where visual formalisms were (nearly) as rigorous as lexicographic ones, but nevertheless more intuitive.
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.
The main reason I don't use UML more is that there really is no good UML diagramming software. It is either way too complex (tries to implement the whole UML "standard"), or else it is a general purpose drawing tool (you need to painstakingly connect arrows to boxes, etc)
UML was built for conference room whiteboards, and as a remote worker I haven't had a whiteboard in years.
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).
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.
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?
I don't know the current state of https://www.uml-lab.com/en/uml-lab/ because I left for other adventures, but if you are looking for a tool that can actually keep code and UML in sync give it a try.
I had no clue what I was doing so I gobbled it up. "So THIS is how you make software, ahaaaaaaa!"
After leaving CMG I have never, ever seen it used in the wild by any remotely successful company or team. I would say it is a clear red flag even.
Sequence diagrams are the only thing I sometimes use to get a grip on how APIs should talk to each other or how flows between integrations should be.
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.
Unlike what UML is trying to simulate, which is an architectural blueprint, a UML model of a system cannot be verified for correctness. But a blueprint can be verified; You can tell "that proposed bridge" will hold "so much traffic and wind" by studying the blueprint.
Most code is verified for correctness by human eyeballs. I think many of us underestimate how important the 'diff' is with respect to incremental reasoning, which we do more often than not to keep the costs down. Once in a while we 'audit' the system, considering the model as a whole, but more often than not we are thinking in terms of deltas versus previous expectations.
Whoever actually solves the visual diff problem, I would be happy to see nominated for a Turing award. It's that big of a hill to climb.
Has anyone had success with sites like https://sequencediagram.io/ or using "DrawIO" inside VScode?
Thinking about systems as state machines, sequences, entity relationships, etc is useful. But the rigid details of specific lines styles, arrow types, etc are very rarely used.
The main risk of UML is it can lead to overly complex designs - it is so easy to add another box and arrow, to make it match a GOF pattern, etc.
As for what we use here in practice today - pairing and talking out ideas sometimes with informal UML sketch, and test driven development.
I like process boxes with four sides.
Left side takes input, the right spits output.
Top side takes constraints, rules, or links to specs.
Bottom accepts triggering mechanism, temporal/sequential constraints, polling, and other controls.
Complex Processes get decomposed down to autonomous objects that can be programmed as desired.
Many of the stripped down existing iconic notations can be similarly instrumented to be useful. Be your own guru.
Use the syntax, don't get caught up in the tooling.
So I think what you're saying is that people want those diagrams to be on the informal side of the formal/informal divide, and UML tried to put them on the formal side. And that didn't work, because on the informal side, a diagram can communicate the general idea quickly. But on the formal side, diagrams are very tedious to produce in the detail required for a formal design, and even more tedious to edit to keep up to date as the design evolves.
UML died because diagrams work better for informal rather than formal communication. I think that explanation fits rather well.
That would be a great surprise indeed to mechanical engineers, chemical process plant engineers, electricians, analog circuit designers, machinists, architects, PureData livecoders in nightclubs, and many other groups of people. UML's problem wasn't that it was visual. UML's problem is that it was a fraud: https://news.ycombinator.com/item?id=26956298
A few boxes on a whiteboard and some lines usually is more than sufficient for many things.
I remember being invited by IBM to a round table with Grady Booch. The guy just mouthed platitudes worthy of an architecture astronaut, and utterly disconnected with reality.
It was Rational software pushing their process and CASE tools.
It was an awful, inefficient and bureaucratic process that made it easy to write contracts about deliverables while delivering mostly no actual value to the customers.
The minute sticky notes in swim lanes and informal diagramming were replced by heavyweight, middle-managers (-cough- "agile coach") - waterfall is back.
Rational is one factor of many that brought IBM to its knees -(WARP-OS2) being a contemporary.
I remember spending $1500k on a professional license circa 1999, and still think it was the best money I've ever spent on an IDE. Incredibly powerful for large-scale systems, and made large-scale, readable-code development fast.
The biggest UML proponents (sometimes including Rational) weren't promoting it for informal design sketching—for which it works well!—or even just blueprinting; they were promoting it for higher-level formal modeling and specification of system design and behavior, including especially software systems. Given such a formal model, the charlatans explained, you could find design errors earlier in the process and fix them before proceeding to implementation work, and you could rigorously verify that the system actually built fulfilled its requirements.
These are very useful properties, and clearly such model-driven development could save a great deal of time and money. The problem is that they have nothing to do with UML's actual capabilities; selling UML as a path to this utopia was just a lie. Things like TLA+, Alloy, Coq, Hypothesis, and even JUnit can sometimes deliver on some of those promises, but UML can't. Hillel Wayne explains why in this newsletter: UML never had the formal semantics necessary to deliver these properties; its implementations were buggy, incomplete, and unmaintained; and it also suffered from the same kind of specification drift that leads to out-of-date comments and useless unit tests in common practice.
So I think what happened is that some companies tried UML and the associated SEI CMM processes, found that the promises were a fraud, and abandoned those processes. Other companies saw that the companies in the first group were doing badly, so they tried other things. I seem to recall an ad (!) for Extreme Programming in Dr. Dobb's Journal about 20 years ago: it ridiculed SEI-style heavyweight processes with a cartoon of a sumo wrestler trying to run a marathon.
And some companies did adopt Extreme Programming, which does deliver on some of those promises, a little; XP hammers pretty hard on, among other things, simplifying your design, formalizing all your system's requirements with unit tests and acceptance tests (though of course these are not very rigorous), and constantly and automatically verifying the system's conformance to those tests. And 02003 is about when XP started to take off, inspiring the adoption of fraudulent methodologies like Scrum that promised XP's benefits without its costs†, much as UML promised the benefits of formal methods without their costs.
(XP is no panacea, of course; if you don't know how to design software, it can't produce a software design for you, and if you don't know how to program, it can't write the code for you, as UML proponents have frequently promised UML will do. XP's extremely weak formalization of requirements as pointwise automated tests just provides a feedback loop that tells you when you're digging yourself into a deeper hole and focuses your efforts, such as they are, on things that matter to the project. Today formal methods have advanced to the point that it's practical to do much better than XP, but that future is still not evenly distributed. Myself, I've barely managed to adopt Hypothesis, and productive use of Z3, TLA+, Coq, or even Alloy or miniKANREN is still beyond my skills.)
— ⁂ —
The kind of methodological swindle represented by Scrum and UML is not a new phenomenon. In 02005 I wrote '"Enterprise software" is a social, not technical, phenomenon', https://web.archive.org/web/20050812004045/http://lists.cano... reflecting on my experiences writing so-called "enterprise software" and how its institutional imperatives systematically eliminate the feedback loops necessary for software development to actually create economic value; and in 01988 Dijkstra wrote EWD 1036, "On the cruelty of really teaching computing science", https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E..., containing the memorable quote, 'Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".'
Dijkstra had been skewering this kind of stupidity for decades at that point‡, but as long as the technically incompetent desperately seek answers to "How to program if you cannot" instead of dedicating the necessary effort to improving themselves, there will be no shortage of scam artists offering sham solutions like (the exaggerated claims that sold) UML. When they are forced to compete in the marketplace their companies will gradually lose to competitors managed by less ignorant people—Google, Apple, and Microsoft have long since buried Excite, Commodore, and Ashton-Tate—but UML remains very popular among defense contractors, since their profits are not contingent on operational efficiency or even producing working products at all.
Let us hope that real formal methods are not tarnished by conflation with UML-style con jobs in the way that XP has been tarnished by conflation with Scrum.
______
† Scrum existed before 02003, and before 02001—Schwaber outlined it and named it in a 01995 paper that advocates a recognizable, if handwavy, version of that anti-intellectual abortion we call Scrum today—but essentially the Agile Manifesto in 02001 was a political strategy to hitch it to XP's rising star, and Scrum started to achieve significant adoption around 02005 as a result of that association.
‡ For example, in 01975 in EWD512 he commented, "Already many a large organisation is nearly crushed under the sheer weight of the illogical, unmastered complexity of its automatic data processing systems." EWD511 laments the lousy design of the 360 and IBM's attempts to promote it. EWD406, from 01973, contains further remarks on, especially, LANL and CDC after Cray's departure; EWD407 complains, "Simple souls have been made to believe that we have a retail shop in Philosopher’s Stones that, by magic, will cure all diseases," a theme that also appears in EWD406. In EWD483, in 01977, he thunders:
Shortly after World War II, when [the students this speech was originally given to] did not yet exist, my physics teacher drew our attention to the fact that we had had the Stone Age, then the Bronze Age, then the Iron Age, and then, in the Netherlands at least, the Golden Age—but that the 20th century would go down in history as the Age of Incompetence (after which it became the order of the day). More than a quarter of a century later, I would like to add a modest extra: it will be recorded in history as the Age of Fraud. This is the widespread phenomenon which the little whitewash artist refers to as "wishful thinking", but to the infidel eye it is no different from ordinary, vulgar deception, namely the deception that consists of the desire to do something, being replaced indiscriminately through faith, and then the pretense of being able to do that thing. … Long is the list of organizations that, after having begun a task for which the competence was lacking, either went bust or managed to save their lives by saddling society with their inferior product, thanks to chicanery.
This is a fairly precise description of Rational's business model, four years before the company was founded. (Corrections on the translation from Dutch would be appreciated; my Dutch skills are even worse than my miniKANREN skills.)
By definition, that task was never going to be an easy nor mutable exercise. If fraud existed it was in the marketing of the CASE tools UML was embedded in. The claims and expectations were wholly orthogonal to software engineering practice of that or any time.
If memory serves me correctly, mainframe commercial development projects routinely failed or required as much budget and time to complete at anticipated delivery as when they had initially started. The white-collar blame was assigned to the quality of development.
The push back legitimately was the assertion that requirements constantly changed (and how could they not?). The self-anointed gurus of the time responded by creating smoke and mirrors solutions that largely manifested themselves in exclusive, eclectic, and proprietary modeling languages. The predictable collapse of that circular firing squad set of methodologies spawned UML under the bastard thumb of IBM (Rational). Big investment means and meant exclusive, profit-driven ambitions, not fraud - self-serving, big money investment.
The client community was drowned in error rate charts, line-of-code (LOC) costs, and business baby-talk illustrations of before and after CASE development anticipated savings.
This form of techno-magic ponzi scheme is still being played Agile-wide. Once the client makes a sizable investment in the pixie dust they will never admit it was a waste of time and money.
And, just for the record, there were critics, sensible advocates, and sober analysts who were ignored, slandered, and whose careers were rougher had they not bothered.
Yes, that was the claim I intended to make. Thank you for saying it more clearly.
> smoke and mirrors solutions…proprietary modeling languages…predictable collapse…Big investment means and meant exclusive, profit-driven ambitions,
Yes, yes! I can see we totally agree!
> not fraud
Wait, doesn't that contradict the entire rest of your comment, including the immediately previous and following phrases, "profit-driven ambitions" and "self-serving, big money investment"? How can something both be a "smoke and mirrors" "self-serving" "Ponzi scheme" and also be "not fraud"?
It sounds like you agree with all my factual claims, adding supporting points of your own for them, but you think "fraud" is not the right word to use? Why not? My best guess at this point is that you don't know what the word "fraud" means.
Also, as a side note, I have no idea what this sentence is supposed to mean:
> By definition, that task was never going to be an easy nor mutable exercise.
CASE tools were/are no different. You and I have our concerns but P.T. Barnum reminds us, "there's a sucker born every minute!"
The task of unifying and consolidating all of the worthwhile details required in Iconic notation to truly capture the complexity of the thing was never going to be easy nor a finite goal. (e.g. it's a whack-a-mole exercise that doesn't end)
But quite honestly, we are on the same page. If you liken it to fraud - not my monkey, not my circus.
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
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.
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.
Multiplying per-worker output in a field whose output isn’t limited by capital or raw materials doesn’t destroy jobs, it creates them.
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.
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.