Why UML “Really” Died(buttondown.email)
buttondown.email
Why UML “Really” Died
https://buttondown.email/hillelwayne/archive/why-uml-really-died/
128 comments
This argument sounds very much like "the problem is not communism, all those countries just weren't doing real communism".
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.
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.
I think the most coherent argument for failure is the limited automated feedback between real code and the uml
No, why would you think that?
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.
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.
It's not very conceptual too. Changing / altering database design (migration) of a production database is .. hmm like I'm not going to mess with those relations. Adding, deleting completely, is ok.
The central planning problem isthought by some modern socialists to be solved: https://jacobin.com/2019/03/economic-planning-walmart-democr...
I don't know enough about communism to make analogies there. I do know that there are successful uses of screwdrivers, and that a screwdriver makes an ineffective and dangerous hammer.
>It seems that almost everyone commenting has seen only bad uses of UML.
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.
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.
> Ernesto Garbarino says that UML was killed by decreasing standards among programmers: “Agile was the assassin and user stories were her deadly, poisonous arrow heads (pun intended).”
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.
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.
I agree that there is a clear upwards trajectory for improvements. When I was a teenager in 1964, I had access to a teletype hooked up to a remote server on the east coast that supported BASIC. I used punched cards at my first real job, although they later bought me a Xerox 1108 Lisp Machine. After the Lisp Machine I felt like things sort of went down hill. I love git compared to cvs and svn. I don’t like using Jira unless there is someone dedicated and skilled at relieving developers of some of the Agile cruft. I love cloud platforms like GCP, AWS, and Azure. I like continuous integration, Kubernetes, etc., if someone else sets everything up (+1000 for having skilled dev ops people on a team).
1 may be true at some companies, but it’s by far not the case for the great majority of software companies. Furthermore, while it’s nice if managers are broadly familiar with software engineering, it doesn’t bring any benefits for them to code or ship software. On the contrary, they’re more likely to annoy the actual people doing those tasks.
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…
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…
Controversial opinion incoming ... The people who should use UML are too lazy to learn it and instead draw weak abstractions in PowerPoint or C4. Those people are business analysts/requirement engineers/product owners. The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping. Wireframes do the same thing. But not one PO can resist writing reams of non descriptive text and drawing impossible data flows. Developers are not the people who should draw UML.
No, UML was not about, nor enabled, lightweight prototyping, the exact opposite. Formal UML as taught and "used" was king of the waterfall and was largely presented as, and definitely taught as, a "design the architecture of your software, then write the code" model. Hence CASE tools - my universities software engineering courses used a product called Together, and Together maintained _live_ updated UML, but the more important (to those teaching UML) feature was that when creating or changing the UML the code would be updated.
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.
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.
Together was a UML-as-code tool, and I never saw how you could deploy a working system using it. We used it for a while, having entire separate 'code' projects to maintain artifacts.
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.
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.
Yeah it felt like in
UML was shoved down our throats by tool vendors like Rational Rose. The dream of models generating code and systems.
I remember using an IDE which would auto generate these kinds of diagrams and for more than the most basic hello world app, the diagram would be this massive spaghetti where you have to zoom way in to see anything.
Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints and also become the office manager once the building is done.
The code is the blueprints. The running program is the site. Under this metaphor the construction engineer is the compiler.
But yeah I feel the office manager bit, that hits close to home.
But yeah I feel the office manager bit, that hits close to home.
Code may be the blueprint for the program, but UML is still the blueprint for the code.
> Developers are not the people who should draw UML.
> Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints...
Okay.
> Imagine telling a site construction engineer that not only does he have to manage the construction, but he has to develop the blueprints...
Okay.
> The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping.
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.
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.
> The true value of UML is that it reduces ambiguity and constrains risk through lightweight prototyping.
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:
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.
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.
Uh, Grady Booch begs to differ. https://twitter.com/Grady_Booch/status/1388930413280727042?s...
Ha, an interesting link, thanks. It comes off as an attempt to atone for former sins and a rather not very convincing one (not to me, personally, anyway).
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.
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.
I hated UML because it felt like someone "very important" had issued a commandment from that unless you did software with UML then you were DOING IT WRONG (spoken in a booming voice from the sky).
It felt super academic and "Thoughtworks"ish and Javaish and made software development boring instead of dynamic and fun.
Glad its gone.
It felt super academic and "Thoughtworks"ish and Javaish and made software development boring instead of dynamic and fun.
Glad its gone.
It’s not gone, it’s out there waiting for unsuspecting developers to pounce on.
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.
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.
29athrowaway(2)
UML may be dead but I still use sequence diagrams. They're great for visualising complex code and systems, especially if you're new to a system and are trying to gain an understanding the flow of data.
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.
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.
Sequence diagrams are great. Any time there's a multi-stage interaction with multiple independent pieces involved, they're hard to beat for communication.
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.
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.
Entity relationship models are good, but people will disagree whether they are 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.
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.
I’m intrigued by the fact that there exists alternatives to UML’s diagrams?
What alternative sequence diagrams are there? Because you are right, we always twist them to include supposedly-orthogonal aspects such as state or actors.
What alternative sequence diagrams are there? Because you are right, we always twist them to include supposedly-orthogonal aspects such as state or actors.
"Alternatives" imply on a formal definition, with strict semantics. IAFAIK, there is no such thing. But most of those kinds of diagram existed before UML, and are designed in very different ways on different contexts.
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).
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).
Oh, mermaid looks nice! I hadn’t seen it before. Thanks for mentioning it.
If UML tooling had just focused on diagrams, I would not revile UML.
If UML tooling had just focused on diagrams, I would not revile UML.
> 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.
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 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 think statecharts are even more useful than sequence diagrams in documenting behaviour. Statecharts are turing complete, and succinctly visually encode complex behaviour that is going to take reams of text to desribe. Harel et al have done serious, rigourous work in developing statecharts.
Was messing with mermaid and state diagrams only today. I don't use UML as a whole but some of the diagrams are really useful.
I think the biggest one is the "rot" problem. Software iterations have gotten faster (in general, not just due to agile) and it just seems pointless documenting things separately with diagrams when so often they have a short lifetime of accuracy. Then, not having a good text representation means it
does not play nicely with version control which compounds it all (how can you
get the right version of the diagram for the specific software). It did not help at all that
the UML tools were typically expensive so only the ivory tower architects would have them
so most of the team couldn't actually edit the UML.
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.
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.
[Rant] The class in university I hate the most is "Software Engineering" because it doesn't sound like engineering at all. They taught UML, Waterfall, Sequence, ER Diagram, and all useless stuff that I never use within 10 years in software industry.
I would like to offer the dissenting opinion that it's good to send cs students out into the world with the idea that "software planning, management and communication exists, and there are a variety of approaches to it" - even if what's actually used is not taught (partly because good approaches are a genuine commercial advantage and things change fast).
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.
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.
> 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"
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"
Sequence diagrams are very useful for APIs and understanding protocols between systems.
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.
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.
I think statecharts are even more useful than sequence diagrams in documenting behaviour. Statecharts are Turing complete, and succinctly visually encode complex behaviour that is going to take reams of text to describe. Harel et al have done serious, rigourous work in developing statechart.
Yes but it seems the order is taught is important. Without actual industry experience, it never occurred to me it could be useful.
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).
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).
As I remember ORM / NIAM diagram is more superior that it can turn into 5NF in one go (or two .. can't remember exactly)
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!
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!
[deleted]
Same experience here. Never saw the point of any of this ephemeral stuff being taught in classes.
I think the issues with UML and any technique of top/down design is that it doesn't recognize the bidirectional influence of design.
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.
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.
I worked briefly for a place that generated code from UML. The code itself was ugly C++, but I never looked at it so who cares. Every week the first thing I did was print out the UML on large paper and paste it on my wall. It was nice to see everything on my wall like that, but just one week of one programmer time and what was on the wall was already obsolete in some critical way.
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.
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.
I agree with your point, but I don't know that I'd blame UML for that, I'd blame people.
It still happens today without UML, it's just moved from flow diagrams to powerpoint and word presentations.
It still happens today without UML, it's just moved from flow diagrams to powerpoint and word presentations.
Good article, nails a lot of stuff. Before UML, Grady Booch sent me a rough manuscript of his future book Object-Oriented Analysis and Design. I used his diagram style in a C++ book I wrote for McGraw-Hill (I don’t think my book was very good, in retrospect, but the diagrams were nice).
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.
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.
> they bought Jacobson’s consulting company and phased out OOSE
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).
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).
Object-Oriented Software Engineering is the title of Jacobson's 1992 book describing a reduced tool-less version of Objectory that was referred to as OOSE. ISBN 0-201-54435-0
To this day I still use OOSE notation when sketching a design, I alwas thought UML was a step down.
To this day I still use OOSE notation when sketching a design, I alwas thought UML was a step down.
You're right, the book does not present Objectory, just the fundamental ideas. But RUP was the continuation of the "Rational Objectory Process", which was Objectory gradually using UML instead of the original diagrams. The fellow referred to Jacobson's consulting company and RUP and UML, not Jacobson's text book. I still have the original Objectory documentation, and even asked Jacobson many years ago whether they could open source the Objectory tool, but unfortunately that didn't happen yet (at least not to my knowledge).
Peer pressure led me to purchase The Unified Software Development Process, The Unified Modeling Language User Guide, and Fundamentals of Object Oriented Design in UML, and while I tried to read them and understand what they were trying to accomplish, I realized that putting ideas and concepts and flows into formal diagrams with rules to argue with others really wasn't getting me or my group anywhere.
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.
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.
Some UML diagrams are still super useful. The real problem is that the parts of the ecosystem is over engineered and targeted to the wrong audience.
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.
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.
UML is too formal for the quick and dirty world of low profile software projects.
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?
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?
You're definitely right about that. Most people think of UML as a notation for relationships between components, and it's useful to have a syntax that people can agree on so it's clear what you're drawing on the whiteboard.
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:
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 poolI use ER diagrams, Sequence diagrams, State machines, Use case diagrams etc during planning design stages and find it really helpful to capture business processes / requirements and turn those down to a rough design. Except trivial cases (of which I admit we have plenty) thinking before piling up code has great value.
What 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
What 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
> Over the past two decades, though, software culture shifted progressively towards large tech-first companies and startups.
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.
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.
> I think that this is also part of the reason why there has been a shift away from 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.
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.
I work at a startup with former Amazon engineers in the mid 20's and early 30's.
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.
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.
Design patterns make the most sense after a few requirement changes. Startups don't have that yet and think getting to market is more important than staying in the market for long.
> Design patterns make the most sense after a few requirement changes.
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.
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.
> 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
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.
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.
I think that we may be shifting away from is a particular form of design pattern fetishism: abusing design patterns from the "gang of four", by their name, usually in Java.
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.
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.
> 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.
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?
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?
You can instantiate objects with a simple "new", you don't always need the extra level of indirection the factory class provides.
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.
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.
The point of using it by the book is that we can talk about it with a common nomenclature.
That's backwards, the point of the GoF book was to document common patterns employed across teams. There was never any intent that you use a design pattern so you can talk about it, that's backwards.
The point of documenting what is in common use so we can talk about it. If we don't talk about it then we don't need documentation.
It's not just the resources we have today, in yesteryear we had the MSDN that had an annual subscription and release, we had more books etc.
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.
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.
> 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.
People's opinions by now differ byt a huge amount whether this is a good or bad/dangerous trend.
> 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.
UML is not dead, I use UML diagramming all the time. As with anything, you want to be judicious in your use of it.
Edit: shoutout to https://plantuml.com/ for making me the coolest kid on any new team.
Edit: shoutout to https://plantuml.com/ for making me the coolest kid on any new team.
Seconded! You can have my PlantUML when you pry it from my cold, dead hands. Once I was shown diagram source you can diff between revisions, I was sold.
It is useful, and can be overused.
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.
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.
The industry has always wanted to have a small number of smart people creating designs which can be handed down to a large number of dumber people to implement. We can't seem to accept that it doesn't work that way.
That being said, UML isn't horrible, it's just fundamentally unimportant.
That being said, UML isn't horrible, it's just fundamentally unimportant.
When UML concept was introduced to me at university I was astonished by it and thought that it's really brilliant - I perceived it as parallel concept to construction and architectural blueprints. I noticed how it helped to plan software development, spot hidden issues, missing functionality, revisit functional requirements with general design of software before even trying to write any code - it also was obvious for me that it is a tool for people with a lot of experience under the belt, aware of best practices, possibilities, common pitfalls etc.
I really liked whole concept, I'm sad that it isn't common practice now - probably just too expensive to do instead of just bashing keyboard buttons and stitching together some libraries
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 ;)
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 ;)
Despite being mostly a subset of UML, SysML is a more cohesive and useful design and modeling tool. Unlike UML, I've actually used SysML on real embedded systems projects and like it. It lends itself well to model refinement, wheras UML encourages Big Design Up Front.
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.
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.
What tool did you end up using for SysML?
Currently, I'm not currently working in a dedicated modeling tool at all - just draw.io. We started with Enterprise Architect from SparxSystems - it's a bit janky and covers a lot stuff beyond SysML, but it works fine. Cameo Systems Modeler is good too - it omits the non-SysML garbage that the other platforms include, and has the best Model-to-Html rendering I have seen, but was double the cost of EA so did not use it for work. The open source tools, Modelio etc. were all a broken waste of time.
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.
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.
If only it was dead. It's still alive and kicking in military development environments pushed down from above by management.
If you can't break down your systems model into a subset of inputs, outputs, and domains (which can be broken down even further to whatever degree of complexity necessary), someone probably doesn't fully understand their system very well. Yeah, UML is chunky, but the ability to identify the high-level goals of a system allows you be be focused on how those systems should behave and the rest is just meeting that spec reliably (or within whatever margin of error is determined to be appropriate). If things are truly inter-dependent, the ability to identify risk points as a high, abstracted level is invaluable.
We did quite well back in the day with the "UML as blueprints" approach, and I personally felt that for new complex systems that mapping between various diagrams and the use cases helped greatly in clarifying a larger OO system before we started writing code. I felt creating diagrams and getting consensus at the start of iterations made us significantly more productive and produced better results.
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.
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.
Sequence diagrams are still widely used.
Use-case diagrams should be used more.
Class diagrams are good to reveal poor OOP designs.
Use-case diagrams should be used more.
Class diagrams are good to reveal poor OOP designs.
IMO UML died because it was too coupled to OOP (maps directly to objects/classes) and it is (like most visual languages) a more verbose version of the textual version (probably Java classes/interfaces).
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")
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")
Posted 1 year ago:
https://news.ycombinator.com/item?id=26956298
Also interesting is the linked post:
https://news.ycombinator.com/item?id=26934577
https://news.ycombinator.com/item?id=26956298
Also interesting is the linked post:
https://news.ycombinator.com/item?id=26934577
I find some aspects of UML, mainly sequence diagrams, useful. Other aspects, like class diagrams, not so much. Plain old boxes-and-line drawings are usually enough.
UML was associated with big upfront design, and basically died with "Agile." Why design anything when you can fix it in the next sprint?
UML was associated with big upfront design, and basically died with "Agile." Why design anything when you can fix it in the next sprint?
People that think UML is dead are people that work in companies with terrible engineering practices.
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.
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.
Many great points made, both the OC and in these comments.
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.
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 still find it helpful to use UML diagrams in a classroom setting when describing a project codebase at a high level. For example, this slide diagrams some classes used in a Scheme interpreter:
https://inst.eecs.berkeley.edu/~cs61a/sp22/assets/slides/30-...
(Generated with PynSource)
I also find such diagrams useful in an engineering setting when explaining a codebase or design decision to teammates.
I also find such diagrams useful in an engineering setting when explaining a codebase or design decision to teammates.
Would a short description of UML at top hurt. Here I am trying to figure out how thid related to user mode linux. I stopped mid way and had to read comments.
Either way, didn't know UML died, visio still supports it right?
Either way, didn't know UML died, visio still supports it right?
Same. User Mode Linux was my guess; the first paragragh of the article was enought to tell me that was wrong but gave no hint of what the acronym might mean, not even broadly.
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 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?
UML came up a few times during my CS program years ago. I found it kind of infuriating at the time since it just seemed to be an idea vacuum cleaner that sucked up so many different diagramming ideas into one place and stuck somebody else's name on it -- plagiarism at an enterprise level.
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.
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.
We had a ton of formal modeling classes back in college, but about the only two concepts that stuck with me and still being used when we need to document something are the UML sequence diagrams and a somewhat less known IDEF0 activity diagrams - https://en.m.wikipedia.org/wiki/IDEF0
One thing that changed was just scale. Many visual representations of information are great, up until a certain complexity, and then people can't tell what they're looking at.
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.
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.
Meh UML was always the Sun Chips of the software world.
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
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
Ah, UML. You were positioned to replace programming altogether in the early 2000s. We were told there would be no need for programmers when you can just turn a crank and get Java generated from UML diagrams.
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...
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...
I think IDEs killed UML. You can look at a model and understand a system, then try to translate that to a code base, and try not to lose anything in the translation. Or you can just use an IDE and find all these things that UML tells you directly on the code base, and do no translations.
I considered the explanation was simply that diagrams created in UML are unreadable to lay persons.
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.
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.
They are pretty trivial to understand.
I agree with him. They always had like 5 different types of arrow that had various easily forgettable meanings.
Not just forgettable, but vastly different meanings. And these meanings have changed between versions. You really have to get close to the spec to grok what is actually being conveyed.
The devil is in the details - if you have to understand the details like the right arrows for relationship types and visibility modifiers, then it gets much less trivial.
And if you're going to omit those details, then do you really need a standard for your adhoc boxes and arrows diagram?
And if you're going to omit those details, then do you really need a standard for your adhoc boxes and arrows diagram?
You can add a legend at the side of the diagram, problem solved.
UML conflated system modeling with diagramming and focused too much on the diagramming.
[deleted]
UML statecharts are great, but I’ve not yet used them end-to-end and I’m not mourning the passing of UML-driven OO methodologies.
Just take a picture of the whiteboard with your phone and upload to jira.
I do miss the Booch cloud diagrams, they brought a bit of whimsy to OOD.
How do you explain an architecture to other developers?
It died because it's stupid and useless.
> I wouldn’t expect two teams in different companies, one in California and the other in New York, to use similar notations unless someone was deliberately keeping them in sync.
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:
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:
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
Wholeheartedly agree about the need for better and bidirectional tools. That said, while I appreciate MySQLWorkbench and its ERD generation skills, I have never seen anything sufficiently powerful to document the features in a more feature-rich database like Postgres.
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.
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.
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.