Why UML “Really” Died
buttondown.email
buttondown.email
1. It seems that almost everyone commenting has seen only bad uses of UML. Even before UML, there've always been people who used modeling tools without understanding them, there've always during OO era been people who really only wanted to see a class inheritance hierarchy, and knowing when to use the models and when to code or do other things is an art like much of the rest of software development. We've got a lot of people writing one-star Amazon Customer Reviews for a screwdriver, who've never seen a screwdriver used properly, and only know hammering.
2. When I try to use particular models and views of UML myself, the documentation and tooling I find in the time available borders on unusable, and I end up improvising what I need. Given that I know a lot of the influencing methodologies, and I've even developed tools myself, if this now looks like crazy enterprise sales&consulting cash cow nonsense to me, then I can't be surprised if other effective software engineers are turned off by what they see. But that's sad, because the value is there, just obfuscated.
And I'm not even being quite as flippant as it sounds about communism here. Communist economic planning relies on accurate central planning, which we've learned the hard way is essentially impossible at the scale of a nation state. In the same way, UML assumes you can meaningfully model a complex computer program in advance, which tends to fall flat back in reality where requirements are poorly understood and evolve continuously.
One can model in UML anything between a bunch of classes, to a state machine to subsystems and entire systems.
One can model architectures in advance or after the fact. One can model while brainstorming or when discussing a design with another developer on the whiteboard.
So what are the good uses?
>When I try to use particular models and views of UML myself, the documentation and tooling I find in the time available borders on unusable
That's kind of a sign, dont you think? Tools that programmers love and find useful tend to get improved.
I got my start in a shop whose CTO was a big believer in UML. I can tell you unequivocally that software processes from that era, while providing some useful lessons, were a result of the 90s software engineering Zeitgeist, which included these major aspects:
1) Non-technical management was still regularly involved in the management of software engineering and engineers needed to explain “Here’s how we will do X” to laypersons
2) Object Oriented programming was at the peak of its hype cycle, but most of the software development workforce had a superficial understanding of it at best. UML allowed you to explore a problem in an object oriented manner before writing any code and gave more OO-savvy engineers the ability to communicate these concepts to other developers who had no hands-on experience writing object oriented code.
3) The “style” of object oriented programming advocated back then would probably get your hand slapped during any modern code review… even by relatively junior developers.
4) Lots of software development practices we take for granted today were not universal: source control, fast build turn-arounds, automated testing. Likewise, because software was delivered via physical media and your ability to distribute patches was far more challenging the whole process was fundamentally more conservative.
So to bring this full circle, what changed since UML’s heyday?
1) Software engineering as an institution matured to the point where almost the entire management chain will typically know not just how to code but actually ship software (seed stage startups are an exception here)
2) Object Oriented programming hype has died down. It turns out it wasn’t the productivity boon we imagined (garbage collection and open source libraries did more for us)
3) Stronger and more robust type systems, Functional programming concepts, and unit testing methodologies are used to mitigate defects
4) Turn-around time to distribute a fix for a production defect is measured in minutes or hours - not weeks or months.
5) Things like CI/CD exist which would’ve made a 90s developers head spin.
Other developers who never wrote object oriented code.
And while the hype for 2 may have died down, it did so because OOP became the mainstream. Which means that more documentation not less is needed.
3 is not related to UML. UML is a design and documentation language, it’s not pertinent to mitigating defects.
4 is also inapplicable. UML is once again not a QA technique.
5 is also inapplicable for the same reasons as above.
Honestly it looks like you listed more or less five random things which changed since UML’s heyday…
> Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints...
Okay.
But yeah I feel the office manager bit, that hits close to home.
What about for interpreted languages?
People bemoaning the "death" of UML mean the specific and formal standards of notation, many of which were not relevant or even applicable to software.
The general diagramming is still heavily used in software development, and despite their claims I disagree with the author's assertion that everyone uses incompatible notation.
One team tried to use it within their project. Together helpfully would delete a bunch of code when someone decided to start over fresh on a diagram. The lesson Together taught me was, sometimes optimizing/automating part of a process is just a bad idea.
IMHO, UML worked best when you actually built diagrams to show a relationship or part of a process, rather than treating it as some sort of generated view of the system. A full class diagram for any non-trivial system is a bird's nest. A full sequence diagram conveys nothing to the reader that the code itself wouldn't.
There's a reason most repair manuals are illustrated with more than a single exploded view of the full car.
Also - Rational was very much trying to break waterfall by going solidly toward more cyclic processes. It was just geared to be a very formal (but adaptable) model. I would argue that Agile was actually still part of an evolutionary chain from RUP - but 'sold' in an entirely different manner.
Nothing in UML is lightweight. As you mentioned there are rules and diagram types to learn.
> Developers are not the people who should draw UML
Maybe not UML but developers should draw more. Diagrams are a great way to communicate architectures, data flow, abstractions, etc. I would save many hours if diagrams where available instead of having to read code.
That was certainly not the original premise of UML. Booch et al came up with a grand idea «once you have UML, you will never have to write the code again and our tools (Rational Software) will generate your applications for you from the UML diagrams where everything is an object».
UML took ages in evolution and development, it was a collection of seemingly unrelated (or loosely related at best) diagramming approaches that, in practice, was rarely used in its entirety due to:
1. Being incomplete or lacking altogether in early stages of its evolution;
2. Being very heavy-weight and prohibitevely expensive tools (Rational Rose, doh!) from one vendor;
3. Generated code was bloated at best or did not work at worst and required substantial amounts of manual fixing up.
There are a few useful parts in the UML universe, though. Sequence and ER diagrams are useful today, class diagrams can have some occasional limited value – to understand legacy frameworks and systems but are nearly never appropriate for describing new data models. Component diagrams are generally useful but almost no-one can read and understand them anymore. And cross-system, end-to-end business process view centric, interactions are much easier to represent with simple, BPMN-style, swimlane diagrams – the business crowd also finds them easy to read and comprehend.
UML, as a whole, was moribund from the beginning.
Booch goes on to state:
> The UML was originally designed to be a language for visualizing and reasoning about a system […]
Which system, an existing one or the one being designed? Most existing systems don't have the extensive UML diagramming that supplements the system documentation, so if we are going to use UML to reverse engineer an existing system, the UML diagrams are nearly guaranteed to be incomplete and miss a crucial aspect of the system or a few. Booch actually confesses in being a reverse engineering aficionado:
> I have always been a fan of reverse engineering notation from code.
If we are using UML to reason about a system being designed, the UML diagramming and coding are disjoint activities undertaken by distinct people: architects or designers produce UML diagrams and software engineers interpret them. The interpretation is always a subjective affair and is nearly guaranteed to diverge from the diagrams at some point. Booch goes on to attest the same further down the thread:
> The code is the truth, but not the whole truth.
So, Rational Software had Rational Rose that generated the code from UML diagrams in an attempt to bridge the gap (but not as an attempt to be a visual programming language) between the design in UML and the interpretation of the design by a human being, and that did not work.
It felt super academic and "Thoughtworks"ish and Javaish and made software development boring instead of dynamic and fun.
Glad its gone.
And what are you going to do, ask during the interview if the company uses UML? I mean who doesn’t use a little UML in a mid to big software company?
Seems safer just to accept that one will come in contact with it and prepare for that day. I use it to document designs quite a lot myself.
I've used mermaid and plant UML and both seem to powerful enough for my use cases, especially when used in conjunction with the preview mode in VS Code.
It's not like UML was based on bad ideas. There were just too many cases where the added value was less than the added cost. But when a diagram does add net value it's great to have conventions already.
If UML tooling had just focused on diagrams, I would not revile UML.
Sequence diagrams are useful, but the UML version with a vertical diagram with horizontal lines optimizes for the least necessary use cases; also, the UML one has no space for the participants states.
Use cases diagrams are useful, but the UML version just wastes all the space and takes all the useful information out (well, it keeps the actors, could be worse).
Class diagrams aren't very useful at all, and when you need them you don't need the formality that is the main point of UML.
And finally, the UML designers failed to include any data transformation diagram, because they really did only think in procedural terms.
What alternative sequence diagrams are there? Because you are right, we always twist them to include supposedly-orthogonal aspects such as state or actors.
Specifically for sequence diagrams, it's common to replace those lines with bars where you can annotate the state, and it is common to have actors instead of endpoints defining the bars. But if you are relying too heavily on those two, it may be interesting to look at process diagrams (but not strictly BPMN).
I haven’t seen Mermaid, I’ll look it up. PlantUML and the live preview in VSCode is one of my favorite things though, I don’t know how I got along without it when planning hierarchical state machines.
I do remember a phase where I used TogetherJ extensively as a full round-trip UML tool. It very nearly worked to the point where I could edit things on the UML diagram and the dive into edit the individual classes and methods in code.
PlantUML has done a lot to help with this for our team. The slowly evolving convention of embedding PlantUML/Mermaid into Markdown and / or code comments is starting to enable a more maintainable / agile way of doing this. In particular have found Znai recently as a nice tool that brings all of this together along with code extraction to make nice "user manuals" comprised of documentation in markdown format and code comments.
ER diagrams are great for presenting a database schema (just don't get too hung up the exact arrow you're using!) When I start a new major project, one of the first things I do is an ERD. You don't need every field (column, attribute...), but the tables (entities, objects, collections, whatever you want to call it...) and their relationships are pretty important.
After some years working, it's clear it's useful in some capacity but it's easy to overdo it (like require every detail of the system to be in those formats) or misuse it (sequence diagram improperly documenting async flows).
I find it's easier to think of these data as cartesian product of a bunch of tuple. Even having table in my imagination is confusing!
If anything it would be great to see more emphasis on this, most engineers I know spend as much time planning, communicating, organising and reporting on work as they do sitting in front of an IDE.
Also, everyone I know uses sequence diagrams and ER diagrams fairly often when things get too complicated for handwaving.
I too used boolean algebra simplifications for refactoring legacy code base that had lots of nightmare if/else once.
They seem like a tool to fix mistake that shouldn't be there in the first place with otherwise methods.
I don't mind if the class called like "Software Project Planing"
The interface influences the implementation and the implementation details influences the interface.
Similarly, the whole influences the unit, and the unit influences the whole.
You can only design working software if it takes into account both directions, software design has to simultaneously take into account top/down and bottom/up concerns.
I think people realized this, and so when you start, it makes more sense to only have a rough top/down draft of the design, since once you implement you'll need to refactor the design anyways from the concerns that appeared from the implementation details.
UML therefore became a waste of time, since half of it would change anyways by the time the project shipped.
It still happens today without UML, it's just moved from flow diagrams to powerpoint and word presentations.
One important part of UML is the layout. Every week I.made a minor tweak to how the boxes were on the page so things looked nice. Every few months a larger change to layout.
Since then I've been to a lot of places where people ask for UML, but since there is no way to synchronize the code and UML the UML is left to rot. We could keep it up to date and i'd love it, but that means one full time graphical person for every two developers. I don't think UML is worth it unless it is the code.
A few years later I co-wrote a UML for Java Developers book. Then for years at work I just sparingly used my favorite Sequence Diagrams and a few Class Diagrams - nothing else. In the last 20 years I have just used Sequence Diagrams, and I still like those.
Pardon something off-topic, but I would appreciate opinions on this: since we are talking about tidy old fashioned practices vs. agile development, I used to hate full on code reviews, but I enjoyed and thought the lighter weight practice of code walkthroughs or even just having two people read through a code module and fill in a questions form. The author(s) answer the questions, everyone talks a bit, and in the end, reviewing a perhaps 500 line module might take up a total of 3 hours of engineering time - and more people understand more of the system that they are working on if this is done frequently with many combinations of people.
The method and tool by Jacobson and colleagues was actually called Objectory, not OOSE (the latter is the name of a german consulting company which pubished their own method called OOSE more than two decades ago).
Objectory as a method and tool was excellent, especially for analysis and design. Rose (the Rational tool) might have looked prettier than the Objectory tool but couldn't do much more than diagram drawing. Unfortunately the Objectory tool vanished after they bought it. UML and RUP have suffered the same fate as all methods. After a certain time in evolution, people have forgotten the original intentions and concepts, watered them down beyond recognition or diverted them from their intended purpose, and instead only formalistic but useless rites are practiced, which is commonly referred to as cargo cult. The same fate will happen to Agile (or it has already happened).
To this day I still use OOSE notation when sketching a design, I alwas thought UML was a step down.
So we went back to whiteboarding and mostly doing top-down design (using decomposition to get down to actual data flow), and we got our products out the door.
In the meantime those books took up space on my shelf and ended up being more for impressing people who walked into my cubicle (remember cubicles?).
Now in my home office two of the three are makeshift monitor stands. I'm finally going to try to dispose of them somehow without harming the environment. I think they're recyclable.
For example, Class diagrams, sequence diagrams -> useful for debugging or for implementation, but very bad for product specifications. If the Product person could write class diagrams, they could probably just implement the system themselves. On the other hand, if a programmer was given a class diagram, they'd still need to figure out if the design/diagram was correct to solve the problem they're given.
On the other hand, a couple of market-tecture (architecture/systems diagram but made easy to understand to even sales people) was drawn, with some useful descriptions of what the whole system did, people/teams can be assigned to fill out the details, and measure their performance against the constrained problem.
In whiteboard examples, most people tend to come up with their own “dialect” of UML relational graphs anyway. Not to mention the ease of defining skeleton classes.
UML is too trivial to be a standard, feels like a byproduct of the 90s OOP craze.
As long as it gets the point across, who cares?
But you don't need a 750 page (really) standard creating a formal specification of this syntax.
Just in case people don't know just how formal the specification is, here's part of the explanation of event dispatching:
As discussed in sub clause 13.2.3, a Behavior execution
always has an associated context object (which may be the
execution itself). A context object mediates the handling
of Event occurrences for all of its associated Behavior
executions. When an Event occurrence is recognized by a
context object, it may have an immediate effect or it may
be saved for later triggered effect. An immediate effect
is manifested by direct invocation of a Behavior as determined
by the Event, such as the invocation of the method of a
BehavioralFeature (see sub clause 13.2.3). A triggered effect
is manifested by the storage of the occurrence in the event
pool of the object and the later consumption of the occurrence
by an ongoing Behavior execution that reaches a Trigger that
matches the Event corresponding to the occurrence in the poolWhat did die is insane approach preached by fanatics in Rational. Now we have the same situation with Agile / SCRUM. I hope this abomination (the way it is being forced down everyone's throat) suffer the same fate. The other related subjects are / were - everything has to be, OOP, OOP sucks, let everything be pure functions and other crap like this.
Luckily I've avoided all the propaganda and sticking to "the only true religion" never mind that new new one would come out every other year
I think that this is also part of the reason why there has been a shift away from design patterns (e.g. Gang of Four, Patterns of Enterprise Application Architecture): the training that it required to be a proficient software engineer 20 years ago isn't the same as it is now.
No StackOverflow, no YouTube, a lot of documentation still on paper, etc.
So you'd get a CS degree, read, learn, and apply the knowledge.
That formula has inverted.
Nowadays, you can build and learn along the way. Watch a tutorial and learn "just-in-time". But this also means that there's really no reason to get into complex topics like modeling, "formal" diagramming, and even design patterns.
There is no such shift. Design patterns are ubiquitous and more popular than ever. Some frameworks explicitly base their added value on providing a specific design pattern.
A design pattern is a higher level construct. It makes absolutely no sense to claim that there's a shift away from higher level constructs when the whole point of programming is using a lower-level programming language to implement higher-level abstractions that implement our requirements.
For example, you will find plenty of classes with names like "StuffFactory", implementing the "factory" design pattern, even though you may not need a factory in the first place.
Design patterns still exist, and will always exist, but there I feel there is less of a tendency to use mindlessly use everything from the book.
This assertion makes no sense. A factory is just a function whose responsibility is to instantiate an object. The GoF book then presents two types of factories that fit a specific problem domain.
Is this irrational hatred of design patterns so irrational that even leads people to advocate they do not need to instantiate objects?
Technically, "new" is a factory, but that's not what I mean, what I mean is a class that is named xxxFactory, that has a method that take something as a parameter and returns an object based on some parameter. Or even worse, the xxxFactory is an abstract class for the "real" factory, with names like "Abstract" and "Concrete".
Of course, design patterns are useful, they don't come out of nowhere. And I think it is essential for developers above a certain level to know them, and recognize them by name.
The issue I have with what I called "design pattern fetishism" is that:
- Design patterns are typical solutions to typical problems. What some developers don't get is that if you don't have the problem, you don't need the solution. Most design patterns are about adding levels of indirection "the right way", which is sometimes necessary, but indirection has a cost, in performance, in clarity, and in development effort, don't do it if you don't need to. And I agree that it takes experience to know when you need to, that's why I think abusing design patterns is mostly the result of well meaning, well educated, but inexperienced developers.
- Naming objects with their design pattern sometimes makes sense, but in other cases, I think it is a bit like Hungarian notation. You often end up with bloated names describing how you implemented a solution rather than what the thing really is. Again, not a clear cut thing, and naming things is hard, but I find some correlation between code full of design pattern names and hard to follow code (even though what the code is doing is not that complex).
- Side note: singletons are global variables and shall be treated as such.
Never seen so many Helper and Util classes with static methods dangling around. Basically no thought at all given to design patterns.
Design patterns are of course still a thing and very common in core libraries, but majority of the devs I've worked with over the last year (across 3 startups building full stack) would be lost if I started talking about Visitor and Chain of Responsibility.
No. Design patterns are higher level programming constructs. The need to use and discuss things in terms of higher level constructs does no arise midway through. Or do backend developers only start to talk about controllers and views and dependency injection and singletons after Product changes their mind on something? Absolutely not.
> Startups don't have that yet and think getting to market is more important than staying in the market for long.
This personal assertion makes no sense at all, and casts doubt on whether you have any idea of what a design pattern is. Your comment reads as a a stream of cliches tied together that have no meaning.
In part it does. You can hack things up quick without thinking intentionally about higher level constructs and it will all work. When you want to maintain your code for years, then you need to get those constructs in the right place as an intentional act. Sometimes you will put in the right design pattern anyway, but often you won't have them in. Note that this is about the discussion and intentional decision to use patterns. You will of course use design patterns - the difference is getting the right ones in the right place. That takes experience and upfront thinking of a type that startups often do not allow time for.
It may well be correct for a startup to not allow time to think about the right patterns overall. It is a decision that will come to haunt them if all goes well, but they got to market sooner. If thing don't go well (a common case), it was less money spent finding that out.
Today, there are promotions and aggressive business fighting of formalization within our field. People who slow down and plan out systems have been weeded out of organizations. People who make things and "ship" quickly are rewarded.
This has been the same with quality control in software, and even goes down to bad developers refusing to unit test.
Time to being promoted has shortened as well. Now it's not unusual for a dev to be a senior within 2-3 years. Lead in 5. That's just the start of their career. I haven't heard the last time that the title "Jr" was used.
> Build and learn along the way
It's always been that way but you had a lot more oversight from people that were much more senior.
Citation needed.
I see, use and teach design patterns every day, and I work with Data Scientists.
> That formula has inverted.
> Nowadays, you can build and learn along the way.
People's opinions by now differ byt a huge amount whether this is a good or bad/dangerous trend.
Edit: shoutout to https://plantuml.com/ for making me the coolest kid on any new team.
I find many software engineers, including myself, have a hard time communicating coherently and specifically the detail of their plans, in my years as a SWE in the fun-startup-space I've enjoyed working. There are ambiguities embedded in many design challenges, and they interfere with
UML has been a great way to talk about parameters, data flow, and ownership. I use it for bits and bobs of the conversation, and to help break down problems for distributing the work amongst team members. I don't pre-plan entire projects with UML, though that could be influenced more by business-requirements than the pros and cons of UML.
That being said, UML isn't horrible, it's just fundamentally unimportant.
However I think that it will return in some form at some point - software as a craft is incredibly young compared to for example construction AND "everything old is new again" is incredibly popular in this field of work ;)
I'm not sold on the idea of capturing an entire design within SysML, but using it instead as a diagram format with defined semantics for situations where group discussion or communication with third-parties calls for some graphical aids. I think as long as you're not trying to make executable models, do code-generation, or replace a formal specification tool like TLA+, there is real value in it. The documentation and training ecosystem around it is pretty decent, as well. The SysML books I've read have all been way more pragmatic and grounded in actual engineering practice of building systems from many components sourced elsewhere, for which design capture is necessarily incomplete.
For my use, there is a sweet-spot for "models" spanning only a handful of diagrams (5-10) where any drawing software with SysML templates will do. The dedicated modeling tools like EA or Cameo become relevant once you're trying to keep model elements consistent across a large number of diagrams. Draw.io is free so the whole team can use it, and the the lack of model representation keeps diagram count low and not over-specified.
Cool products, btw.
But most active tooling and education for UML was always CASE-oriented, which was way too heavyweight for such a small org. I would use more "UML for sketch" tooling - like OmniGraffle with good (internal) stencils - which allowed for iterative improvement to the diagrams. I actually switched from Linux to Mac for OmniGraffle. Invariably the UML tooling of the day was too cumbersome, because it was geared toward making more formal models from the outset.
It is the UML sketching which I have kept throughout my career, and lamented that as CASE died, there hasn't been anything else to supply baseline education nor has there been any evolution (or simplification, or unification.)
I suspect creating such things just isn't that attractive without the CASE money being there.
Use-case diagrams should be used more.
Class diagrams are good to reveal poor OOP designs.
Of course it is still useful to communicate an idea, but so is a diagram or an MVP (maybe with some formal guarantees from the type system or a TLA-like "proof")
https://news.ycombinator.com/item?id=26956298
Also interesting is the linked post:
UML was associated with big upfront design, and basically died with "Agile." Why design anything when you can fix it in the next sprint?
I haven't been in a single decent team that didn't use UML to some extent for designing components.
I just don't see how you could do a design review with your team without using UML.
Another methodology pitfall (in general, not just UML) was working with other humans. It's just so hard to get everyone onto the same page.
Just one tiny facet of UML are use cases.
I love the book Applying Use Cases: A Practical Guide. Short, precise, actionable, repeatable. It's basically just a recipe. Almost too easy.
TLDR: All architecture must be tied back to use cases.
No brainer, right?
My company did a lot of continuing education. So we all read Applying Use Cases, have multiple bookclub style discussions, try to use the methodology during a project kickoff (bridge from requirements analysis to high level design).
Holy shit. You'd think we all had read different books. There was no shared understanding for any of the concepts, how to proceed. All normal pedantry (defining "use case", arguing over system vs user, correct level of abstraction, questioning the requirements). Plus the new arguments about tracing "use cases" to "architecture".
FWIW, that was the effort that broke me. After a few years of being a methodology warrior, I just gave up. At work, I want to ship code, not debate philosophy with bozos.
I still use various OOA/D techniques and skills I've acquired. But only for my own benefit. Either I'm in a position to just tell people how it's gonna be. Or I keep my mouth shut.
Fortunately, XP and Agile popped up. Enthralled all the poseurs and PHBs. Leaving me (and my teams) alone to just focus on shipping product.
I also find such diagrams useful in an engineering setting when explaining a codebase or design decision to teammates.
Either way, didn't know UML died, visio still supports it right?
I had to google : it is actually about Unified Modeling Language diagrams of object classes and their relationships. I guess nobody who uses UML diagrams ever thinks of UML as an acronym?
I've grown to somewhat respect it to a point as a formal way of documenting a system, but goodness no, would I never ever design a system with such cruel intent.
A coworker demoed some Rational product to us back in the day. It was very impressive, creating class diagrams from existing code. It was also an incomprehensible mess of nodes and edges.
https://www.theonion.com/sun-chips-abandons-biodegradable-ba...
"Are you kidding me? I crafted my entire freshman year persona around being the 'Sun Chips Asshole.'"
PAUL KENEMORE • STUDENT
And CASE! The low/no code of the 80s!
How the mighty have fallen. Important things to bear in mind when considering this era's silver bullets...
Excessive use of visual jargon, and changing standards combine to make everybody a lay person, even those versed in a particular version of UML when confronted with a different version.
And if you're going to omit those details, then do you really need a standard for your adhoc boxes and arrows diagram?
I feel like you need a reference implementation for almost any spec out there for it to remain consistent, like a tool that everyone might use for working with UML or whatever. For example, have a look at BPMN, which has https://bpmn.io/ without which it would be another spec that many wouldn't care about.
Of course, the tools actually need to be good, because I've seen too many bad Eclipse based pieces of software, like for 4EM modeling or other approaches that never really took off in the real world, outside of niche contexts. It might be a case of model driven development feeling pretty useless, unless it actually helps you develop the solution with minimal friction.
A good example of this are ER diagrams in MySQL Workbench! For example, consider the following, what I've sometimes done:
- open MySQL Workbench
- reverse engineer an existing DB, get an ER model
- alter the model as necessary (add tables, change columns etc.)
- use the forward engineering/synchronization tools to get DDL that could be applied to DB
- execute or alter as necessary beforehand
- open draw.io
- open a manually drawn ER diagram of the DB from local/shared disk
- compare against DB schema manually, possibly fix parts that have changed in the DB since last diagram update
- alter the model as necessary, using regular drawing elements and text (with lot of it being more like working in Paint)
- once happy with this "documentation" and it looks good, manually write all of the SQL that's needed for migrations
- execute the SQL
If you want something like UML or any other modeling approach to be popular, I'd argue that you'd need something like the following:
java2uml --in-package src/java/main/dev.kronis/sales_app_2022/products --out-model products.uml
"MadeUpSoft UML Studio" > File > Open > products.uml
... do your changes
"MadeUpSoft UML Studio" > File > Save
uml2java --in-model products.uml --out-package src/java/main/dev.kronis/sales_app_2022/products
For example: • knowing where the partial indexes are and what their defined subset is
• domain types, their base type, and their defined subset
• row-level access policies
• trigger order, dependencies, and dependents (I think auto-generated sequence diagrams would do wonders here)
• table partitioning hierarchy
• constraint info or at least an identifiable visible marker for CHECK and EXCLUSION constraints
• marking computed columns and materialized views
• association between functions/procedures and the relations they read/write from in addition to cataloging pure functions
• notation when a view is updatable
• users/groups/roles and a view into the resources each have access to the system
That's off the top of my head. I'm sure others can think of more. I realize these aren't trivial asks, but great tools rarely are. The existing ERD generators I've seen like MySQLWorkbench are good for basic bootstrapping or strictly the database users. I want to see more for the DB admin/developer cohort. I want a Javadoc+PlantUML for databases.