UML: My Part in Its Downfall
tratt.net
tratt.net
Not only was UML a graphical notation, it was a badly designed graphical notation. It attached semantic significance to symbols that were very similar in visual space. The poster child is the hollow diamond "arrowhead" versus the filled diamond. You have to have pretty sharp eyes to distinguish them, and there is absolutely no mnemonic value to these shapes.
Graphical notations can be useful. Feynman diagrams, for example. But UML was nothing but a hot mess from the beginning. Good riddance.
[UPDATE] When I was taught UML I was told that the first thing you do is produce a "use-case diagram". So I spent a lot of time drawing little stick figures. When I asked how this was supposed to be more useful than, oh, I don't know, just writing some fucking English text, I was reprimanded for not being a team player. Madness.
Then again, the bureaucrats of today call themselves "agilists" and fill your weeks and days with meetings after meetings, plannings, sync ups, etc.
Yes, planning ahead is good, but it is not end all, be all
In software that might look like a company where they have lots of teams experiment with lots of software and project management approaches across a wide variety of project types. This second order concern contrasts rather heavily with the first order concern of making and supporting software products.
Actually it is when faced with being exposed to a vacuum at −455 °F.
The root of all the blessings and curses of software.
> The reason graphical notation works for circuits is that circuits are actual physical things and so there is a natural correspondence between the graphical notation and the thing that notation describes.
This really just boils down to complexity and verbosity, so 'fundamentally' it has nothing to do with virtual nature of software. Hardware people lucked out (in this case) but as the semantics of components get more involved, so do the component notations:
https://www.electrical-symbols.com/electric-electronic-symbo...
(amplifier, cache? semantics of the cache? ...)
https://www.electrical-symbols.com/electric-electronic-symbo...
https://www.electrical-symbols.com/electronic-electrical-sym...
Right now it is unmanageable to do this for software. OP's write up actually mentioned the cause: they were trying to bootstrap UML with UML, defining 'semantics' using the core notation. This is the sort of 'elegant' approach that generally ends up getting buried under its own weight. So the question boils down to 'Is this complexity irreducible and open ended?'
Not sure about the reducible but am definitely bullish on it being 'closed'. [Software may lack physics, but it certainly has both form and structure.]
p.s. I think in isolation, specific aspects of software components can be [completely] described simply. For example, there are only so many ways bits can go in and out of a black box. Same for interaction patterns, there are a handful of modalities (such as caller, server, peer). Etc.
p.s.s:
Consider https://circuits-diy.com/wp-content/uploads/2020/01/push-but...
Will you still insist there is a 'natural correspondence' if I naively decide to run wires from DC to LA for a that 'circuit'?
Would it work? [spoiler: no, it won't]
No, it doesn't. Hardware really is fundamentally different from software because it is constrained by the laws of physics (and economics) in ways that software is not. So, for example, even complicated components tend to get fabricated in a way that the constituents are physically co-located with each other. That's why you can take a photo of an actual physical chip and draw boundaries around the various parts. Not only that, but those boundaries tend to be rectangles. So even complex hardware naturally lends itself to simple representations in 2-D space with intuitive mappings between the representation and the underlying (physical) reality. None of that is true for software.
Fundamentally (as significant to software), physics gets you Pauli Exclusion, relative time, distance, and of course energy (computational power). This has huge ramifications for software and why it resists becoming an 'engineering' field. But it does -not- imo preclude the possibility of effective and comprehensive notation for software definition.
p.s. since you are a lisper, you are already 1/2 way there to a universal modeling approach. I assume you would answer in affirmative to the question 'is there a viable universal textual notation for defining software?' with "Yes, it's called s-expression'. [In that case you would be] simply denying that a graphical analog can be developed. On that, consider the janky [early] attempts of everyone's ancestors in developing their alphabet/glpyh systems, currently in use.
The operative word being events. Hardware design is not about events, it's about putting the right kind of atom in the right place, which is a lot harder than moving some electrons from A to B at the right time.
It might be easier to understand as a flow diagram for a major industrial plant, functions and programs like robots and major machines.
This was, as the name implies, a dictionary that was the single source of truth for definitions of data items: meaning, representation, meaning of enumerated values, synonym and their business contexts, examples, caveats, etc.
Easily implemented as a single table in your database. Never done these days, although it would probably simplify learning a system quite a lot.
I claim that circuit diagram symbols aren’t particularly intuitive (e.g. the symbol for a resistor is just a longer wire? The symbol for a transistor is very non-obvious, I think. The symbol for a potentiometer is pretty difficult even if you know how one works.)
And another example of a visual representation that works well even though it is for something intangible is the kind of grammar diagram you can see in the SQLite documentation where terminal symbols are in rounded rectangles, non-terminal symbols in regular rectangles, and arrows indicate concatenation (I.e. production rules).
To be clear, I don’t want to disagree with your overall opinion that UML is bad or that the symbols are intuitive, and perhaps that is the reason that UML failed, but I think the reasoning about visual notations and the reasons they fail in general is faulty and I don’t think the answer is to find ever narrower definitions of the cases where visual notation systems don’t work.
Electric circuit notation could probably be improved. Same for math notation. But both of these are pretty deeply entrenched at this point. (I will note, however, that I am currently working on maintaining a chip design tool that describes circuits using S-expressions so the situation is not hopeless. :-)
There are graphical representations for the layout as well. But the text is primary.
But... I have used it for a few projects where I was starting from scratch, and I have to say they were some of the best and easiest projects I've ever delivered.
The act of designing the components, objects and interactions allowed me the time to think out many design problems and unanticipated interactions between the various elements and other systems I was interfacing with. Listing and adding the requirements of each stakeholder made my solution more complete and rounded for version 1.0. And since the design actually followed the implementation fairly closely (a rarity I know), it was one of the smoothest development experiences; and I had some fairly good documentation already produced that allowed me to explain to others how the system worked, and that gave them a step up when supporting it, or adding new features.
Also, since I'd spent the time doing some use cases and talking them through with stakeholders, the non-technical users and testers already had a good grasp of what was being built and how to test.
This was a fairly modest amount of UML documentation that I produced, as I see no value in designing every little detail up front, but that act of designing and thinking through the issues made these projects some of my smoothest deliveries ever. And to this day I've not seen a better successor to UML for picking out and describing bits of your solution. It sure beats the usual rush-to-code and iterate until it approximates that very often happens.
Sure. But you can do all that without UML. Text is perfectly adequate technology for planning ahead.
"This depends on that, this calls that, and then calls that external system via this interface..." and so on.
With a only text I would find that much harder to communicate. That's why I find diagrams much better - you can just jump in at any point and explain things in any order you like, usually with the aid of a pointing finger :-)
And yet you just did it:
"This depends on that, this calls that, and then calls that external system via this interface..."
I really don't see the salient difference between
this depends on that
this <-- that
English is linear in a way diagrams are not.
System1
sub-system1a
sub-system1b
System2
sub-system2a
sub-system2b
(Yes most programming languages use trees, it has some advantages. But most people program in excel anyway.)
What will you do when you need to describe a graph with (say) more than a thousand nodes? I hope you won't try to draw a picture of it.
Creating a graphical rendering of data is not what I was referring to when I spoke of drawing a picture. What I meant was actually drawing, i.e. using MacDraw or PowerPoint or a pencil and paper and drawing. Because that is what people mostly do when they use UML.
I work at Intel, so I can tell you with some authority that you are mistaken.
Graphs are reducible to lists of nodes and edges which are very linearizable.
That may not be the most useful form for comprehension, but linear forms are quite good for writing and storing. Visual notation is useful for presentation here, but IME quality is much lower in drawn diagrams than rendered-from-linearly-authored-text diagrams, which explains why most of my diagramming is done in a text editor (e.g., in Markdown+Mermaid) with visual preview.
netlists do a perfectly fine job of describing graphs
Diagrams are more efficient to drive the point home.
- it was over-engineered because model driven architecture people at some point got involved and there was this whole meta model that they came up with and unleashed some design by committee style processes on. This resulted in complex tools and companies like Rational Rose emerging; which promptly got acquired by IBM because they love complex stuff and the need for consulting that provides. I always joke that the wrong people got way too excited about this for the wrong reasons.
- it coincided with the emergence of agile software processes, which de-emphasized the creation of a lot of up front design documentation, which is a waterfall thing to do. And there simply was no need for it over the course of a single sprint. Some companies still create diagrams to document stuff but mostly that serves very little purpose other than box ticking. But basically as companies switched to scrum, kanban, extreme programming, etc. they stopped using design tools and started using wikis, issue trackers, git, etc. These days the only design tools that are used are UI design tools like Figma. Software design mostly happens on white boards. That may or may not involve some box and arrow diagrams. Mostly those are talking points rather than detailed designs with little relevance beyond the meeting they are used in. With remote development now common; even whiteboards are not used that much any more.
UML design tools are awful for their intended use. They are documentation tools and using them usually is a form of process bureaucracy: somebody insists on having diagrams. Usually not a software engineer. They are not useful as a design tool. Using them is fiddly and simply too slow. I can draft something on a whiteboard or on a bit of paper in seconds that would take a lot of time to do in a design tool. Instead of writing class diagrams, I'll actually stub out the classes and almost immediately start refactoring and renaming things; which is something that that UML tools don't support.
Most UML diagrams state the bleeding obvious in either way too little detail or way too much detail. Neither is very useful. Complete waste of time creating these diagrams usually. But sometimes useful to impress the non technical people (We have stuff! It's amazing! Here's a pretty slide for you to look at.). I usually just wing it and maybe once a year sit down and do some boxes and arrows so I can put it in a slide.
Not really. The first item and all the propaganda around it was a direct cause of the popularity of Agile. It wasn't a coincidence.
This first iteration can come in many forms. In the old days it was done in pseudocode and formal language on paper, aka the waterfall model. UML changed it to be symbols and arrows. With rapid prototyping it is actual working but buggy code. One can see the appeal of doing it in real code, your programmers don't have to learn a second language nor translate the first version from that design language to the computer language. People will say that code is too hard for the design part, but it's the design that's hard, not the code. The real danger is that your prototype will work well enough and you won't have the fortitude to throw it away. That's not a danger with a design document/diagram.
I don't consider that a "danger", I consider it a good outcome.
Seriously, I have put a lot of Common Lisp code into production and it just doesn't have these problems because of its ability to redefine classes on the fly. Combine that with an ORM that issues the right ALTER TABLE commands and all but the most radical design changes are completely turnkey, no stick figures needed.
I hadn't thought to critique the visual design of UML but it is just about impossible to pick up a UML diagram after a year of doing other things and remember the particular semantics of them above the whiteboard box-and-arrow level. So I think you're right and there's probably opportunity for someone who loves that kind of thing there.
Also I thought I was the only one who thought use-case diagrams were absolutely absurd. At the employer where I saw UML and got actually pretty good but brief training on it, we had a VB plug-in for Rose that would extract the text from them into... a Word document.
That said, UML statecharts are pretty great, the tools for them look OK though I've never done statechart design that way, and I appreciate seeing a sequence diagram for nontrivial protocols/exchanges/calling conventions.
This seems to be a limitation of class based OOD and the absence of free standing functions. There needs to be a place for code to exist which operates on disparate data types and structures. I’ve found that creating singletons that replace the word Manager/Utility with Lib doesn’t offend the sensibilities as much.
That's not necessarily a bad notion, though. It's pretty much the definition of a capability, which is an important concept when designing for modularity.
The most useful bits weren’t even that but more of a graphical representation of a data model. Data models are useful in describing interfaces between components but they’re useless in helping with the codification of business rules. My memories of the time are ones of contempt for those that thought the completed UML represented 80% of task completion and that all that was left was implementation “details”.
In the end, UML is fundamentally unimportant. I think having a strong opinion about it (either way) doesn’t make sense for this reason.
If university students are being taught that UML is a must-use tool, it doesn't really matter whether or not UML has some legitimate use cases, the base teaching is a big fat lie and the students would have been better off spending that time playing Candy Crush.
I can recommend Martin Fowler's "UML Distilled" for a pragmatic approach (ISBN 9780321193681).
Anyway, it caused by that status thing. Your teacher knew it, and you didn't yet. But he couldn't just tell you.
Having said that, UML had/has problems:
* People using it as a diagramming tool rather than a modeling tool.
* While many tools exist to create code from the model, there are very few UML tools that can create the model from code or true-up the model from code that had originally been created from the model and then subsequently modified,
* Many UML tools lack the ability to generate diagrams from the model, the model is essentially kept hidden from the user - which is a rather odd state of affairs for a modeling language. By hiding the model you also couldn't use UML to explore a code base.
* Encourages arguments over the mundane. Too many people got bogged down in the "dots and arrows" rather than focusing on the big picture. I suppose some people used that as an argument that they were being "productive."
It's not so much that the idea UML is garbage but rather the tooling typically leaves a lot to be desired. Enterprise Architect is the best I've seen and even it's far from perfect.
No, it isn't. It might have once aspired to be a modeling language, but it is not in point of actual fact a modeling language. The reason is, as you yourself point out, people use it to draw pictures, not to produce models. And the reason for that is that all of the tooling and pedagogy is centered around drawing pictures rather than producing models.
An artifact is the thing that people actually use it for. UML is a modeling language in the same sense that (say) a letter-opener is a weapon. You can use a letter-opener as a weapon, but because no one actually does, calling a letter opener a weapon rather than a tool for opening letters is kind of silly.
Anyway, for about the past 15 to 20 years the majority of UML changes have been to the model. As I said, the only tool I know of that's in alignment with modern UML modeling is Enterprise Architect.
Maybe some people realized this, but that realization is far from universal.
I challenge you to show me even a single introduction to UML on the web that shows an example of a model rather than a diagram.
1. This excellent article is all about UML's class modeling capabilities. UML has other useful capabilities.
2. Sequence diagrams are very useful. I've created plenty to document and teach complex interactions between various (micro-) services. But it simply never occurred to me that I would generate code from sequence diagrams. They're simply a way to capture and refine the stuff on a whiteboard.
3. The data-modeling tools supporting logical and physical models suffered from some of the same needless complexity as the attempts to codegen from UML. And from the ludicrous expense of the tools. Every place I worked had at most one license for those tools.
5. The code-navigation and code-completion features in modern IDEs implement some of the best parts of the UML codegen vision. Tell VS that a class implements a particular interface, and it offers to generate a skeleton of the necessary methods for you. Great. Look at a method declaration, and see at a glance that it's from a superclass. Also great.
6. I hope somebody, maybe the author, collects articles like this for a text to be used in software engineering teaching. Our trade needs some serious mid-career training. The military has the Army War College. We need the Software Wars College, to get a chance to think this stuff through.
7. PlantUML is a pretty good way of embedding UML in wikis and other online docs. "Pretty good" is good enough for most purposes.
I've always used the classic "bus timing diagram"[0] style of sequence diagramming. It's limited, but an excellent way to illustrate a parallel sequence.
[0] https://study.com/academy/lesson/bus-timing-diagrams-definit...
I can also see the value in UML class diagrams for complex OOP systems but for me personally, I can make do without them in the vast majority of cases. They are not as valuable to me as sequence diagrams.
The class diagrams were something I was taught heavily in college and haven't really used since then. Feels like it's just as easy to write down "this object has a one-to-many relationship to this object"
Sequence diagrams force you to think about the flow of control in a system.
When reviewing draft designs, I sometimes ask the author to convert a simple boxes-and-lines architecture diagram to a sequence diagram. It can be revealing.
Sequence diagrams, ERDs, state diagrams are all good things.
UML class diagrams were the worst though, mainly because the C++/Java world of inheritance of OO missed the entire point of OO, which was about the messages.
So people would create incredibly complicated diagrams to describe stupidly complicated class hierarchies. One company actually modelled "Money" as a subclass of "Currency" because it was going to have to handle the transition to Euros, but completely ignored the laws and regulations that the EU defined for how that conversion would happen, because it didn't fit their class hierarchy.
Yes diagrams are useful for documenting structure and behavior, but they're not good at being precise enough to describe those things to the point of generating code.
Also, all the CASE tool vendors of the 90s were trying desperately to maintain their relevance, so were bolting UML on the side of their tools, while bolting things like Zachman frameworks on top of them to appeal to the corporate object hierarchy.
It's too bound up with OOP, specifically C++ and Java. It is hard to represent entities that are not simple classes.
Things that are idiomatic (in 90s C++, cough) look very verbose. If you have a base class, a derived class, and an interface you have a lot of duplication. It makes things like polymorphism look needlessly complicated.
And finally, it is ugly and unintuitive. The inheritance arrow goes the wrong way. I know it is supposed to say "derived IS SUBCLASS OF base" and thus goes upwards, but in my mental model it is "you start with base, and then go to derived (get more specific)" so it should point down.
I want to know that action X will trigger N calls and those calls call service foo and bar, and that foo then calls out to its data store and eventually returns something and service bar calls services raz and quux and those each fist call a caching service before going to their data stores. All requests eventually return (in the happy path). Now, as a reviewer, I can quickly see what talks to what and why that call happens and I can ask more intelligent questions like what happens if a cache hit happens when the data store has been updated.
What do you prefer?
The fact that UML formalized them as a way to describe code tells you a lot about the standard's quality.
I tend to think of OOP as a way to rewrite 'if's now. When you have the same huge 'if' or 'switch' in a couple of places, you can usually rewrite it to use polymorphism, and it becomes clearer. But it is totally fine to use procedural or functional idioms most of the time.
I don't know the whole breadth of the actual standard UML, and I don't know anybody who does. When I say UML, I mean as practiced and not as written, and that means: Boxes for classes, methods below, various kinds of arrows that I have to look up. For sure there are good parts in the standard, but that is not really relevant here.
As the sibling comment says, sequence diagrams are usually more useful. Or state machine diagrams. Or a diagram showing data dependencies.
Without UML, such designs would be worse because they would be less documented: if you have a relatively concise class diagram in front of you it's easier to ponder about what each of the arrows and boxes means.
So in my mental model a derived class actively "points to" its base class. Likewise a child commit points to its parent/parents.
There's a high variability in that, especially when metaclasses get involved and inheritance is itself a protocol (and thus can be hooked into every which way).
I do agree with the rest of your comment though, to me it also makes a lot more sense for a derived class to point to its parent than the reverse.
That make sense - pretty much every language I've used that supports inheritance class definitions refer to the class (or classes) they extend rather than the other way about.
class Vehicle extendedBy Car, Truck
class Car
class Truck extendedBy Semi
class Semi
This would be almost as awesome as "comefrom"[1]
I want to see a graphical representation of my "business" entities, not a more verbose 2D representation of my source code.
I fully agree with UML being stuck in OO land, though, and I think that’s the actual problem. Lambdas don’t exist, or have to be verbosely represented as interfaces. Type-level programming doesn’t exist. Anything higher order is unrepresentable to begin with. You don’t have to use Haskell to run into those limits, modern C++ is enough, or Kotlin, or TypeScript. UML is basically useless if you’re doing anything more interesting than cranking out Java 1.4 era EJB boilerplate.
That is a high bar, I'm not sure if UML meets it (wouldn't know, don't use UML, not intuitive enough for me). But I think something like SQL's syntax meets it - nobody would design a language with that syntax in this day and age, experts have settled on not using garbled pseudo-English. The experts who think "VERB GLYPH ADPOSITION symbol" (ie, SELECT * FROM table) is the simplest way to represent relational algebra just don't exist. Anyone competent would use some other grammar.
Idiomatic is close.
Yes, the Command pattern is what I vaguely alluded to in my message. The thing is, using a lower-level representation in something that’s meant to be an abstraction of the actual code makes zero sense to me.
It seems to me UML shouldn't be dealing with this fine-grained level of detail. It seems like a wasteful effort. Either design high-level, or get down to actual programming.
Managers were overly fond of the class diagrams because they could understand them. And dividing work between programmers by class rather than by logical feature somehow made sense to them. I recall one manager spending way too much time arranging to print a huge UML diagram across multiple sheets of A4, taping it to the wall and then annotating it constantly by hand.
But knowing it can still be useful for simple sketches. Similarly dynamic dispatch is a really useful tool for particular cases when programming – used alongside other non-OO techniques. Our industry follows fads and fashions to an amazing extent but when things fall out of favour the baby goes out with the bathwater.
While saying "it isn't intuitive" is a bit of a simplification, I think there is something to the argument.
I wonder if that is the case. Many programming languages do seem intuitive in light of other programming languages and other formal notation like math. The ones that don't are the ones I struggle with more. If I'm reading a new language and I see an '=' I can assume either a comparison or assignment. If I see a '<', I can normally interpret it as less than. The more a language violates this, the less intuitive I consider it and the harder it is to read through it without familiarity. This even applies among non-intuitive paradigms. OOP isn't what I would consider intuitive out the box (but then is anything), but once you know two languages implementation of OOP you can measure a third language's implementation as being intuitive to the exist pattern or not.
My experience with UML is that it was wholly new. It was as intuitive as the first programming language a person would learn if they didn't know math notation, which given the rate new students to programming know math notation, is a level of unintuitive that even most programming languages wouldn't have even as a first time language. Add in that many are introduced it alongside OOP in general (at least that was my experience in college) and it is even less intuitive than that.
So to that extent, I think I can criticize it as being non-intuitive even with the comparison to programming languages.
Paradigms aren't supposed to be intuitive.
Anyway, "intuitive once you grasp the fundamental ideas" is normally called "idiomatic" in informatics. I will second the other comment on this thread pushing that term.
Absolutely nothing about computers is intuitive. The entire area of knowledge is composed of fundamental paradigms and their extensions. Those can be "simple" or "idiomatic", but intuition doesn't go anywhere near them.
From a code generation standpoint (e.g. cracking out EJB boilerplate), the concept of model-driven architecture is generally a flawed idea. Lack of lambda expressions isn't that significant in the face of ignoring the complexities of real systems.
I'm curious about the issues you've hit representing higher order types though - was this in a class-style diagram?
I started my career in the early 2000s in a big company on a big industrial project where several generations of contractors had already had their hands in. UML, rational rose, auto-generation of code that you had to manually correct, CORBA, manual tests, proprietary tooling...
It would take weeks to onboard newcomers, have them create unix account managed by some IT people in India so they could have access to the license of the proprietary point and click software to manage all this.
I think it was a time where decisions on tools were made by managers in the procurement teams. Selecting technology based on what they heard while golfing with their buddies or depending on kick backs they would get from providers.
Sorry, a little bit of a rant but to this day it still irks me to think how unproductive we were because of obvious bad choices. There is a silver lining though because during those years I learned more than any moments of my career. It taught me all the things that you definitely should not do if you want to be able to produce something useful at a reasonable cost. And one of them was to rely on UML for anything more than informally communicating simple designs with local team members.
Why on earth should I use class diagrams to generate scaffolding? What's the benefit?
No, I think the only sane use of UML is the other way around: Describe existing code in a human-friendly manner.
Yup, thats what I am working on since a few years.
Leaving out details can easily be solved with collapsing the code segments.
It seems some people wanted to turn this into a visual programming language instead, and thus kept adding details to the specification to make that possible. But it's not a very good visual programming language. Compare to something like Scratch, or Bubble or Unity ShaderGraph or Unreal Blueprints for examples of what actually usable (though still far from perfect) visual programming could look like.
The problem is, by adding all this detailed specification, they actually made UML worse as a product, because it actually makes it harder to use for the first use case, sketching, because suddenly the receiver has to have all this existing knowledge of the protocol to receive what's being communicated. Thankfully most people ignore all that and just stick with boxes and arrows and text, and it works just fine.
Another issue with UML is that people find it easy to conflate "UML" with "diagramming in general". Using diagrams to describe existing code can be useful. I'm not a big fan of it honestly but I can tell I'm probably in a minority, albeit a large one, that's fine. But once I'm not able to use UML tooling because I'm no longer building a diagram in the proscribed manner, why should the diagrams I'm producing be UML qua UML diagrams? I can draw boxes and lines without reference to the UML spec; I was before and I am after.
In fact I will plead guilty to opening the UML elements pane in several diagramming tools over the years and then just using the stuff in there as little more than graphical macros without regard for what UML thinks they are. Nobody has yet complained. Only one person even noticed it was the UML graphical vocabulary.
In the interests of not posting again, there's some discussion about the utility of sequence diagrams elsewhere. I also agree I've gotten value out of them... but I don't draw them with UML semantics. I just draw them. UML demands details I don't have, either due to not yet knowing them or simply being inapplicable in my domain, and it fails to capture things I really care about, so ad hoc diagramming it is. Ad hoc diagramming isn't really that big a problem. I think it's actually a perfectly acceptable solution to a complicated problem because diagramming isn't about the diagram itself, it's about communication, and building a jargon vocabulary as you go is not something we sadly do because we have no other choice, it's actually a good solution. It shouldn't be resisted. It is possible for it to run a little too willy-nilly but the solution to that is to reign it in, not instantly flip to the opposite extreme of the spectrum.
When you use UML, your goal should be to convey the overall architecture, the modeling of the domain, and some implementation details.
When the UML scene began all this "enterprise architect" MDA bullcrap, as this article elegantly describes, it got thrown out en masse. Rightfully so, but with the bathwater we also lost this industry-wide capability to draw software.
Text is great, and in parallel with UML's demise, the industry got amazing at succinct technical writing: the README.md in a github repo. But sometimes a picture really is worth a thousand words and I still miss it.
It's not clear that conversion from a high-level model to a platform-specific one should be a standardization concern, and maybe that's the "enterprise craziness" part that ultimately failed. But rigorously defined DSL's are not crazy; if anything, they're the only kind of "low code" that makes any sense at all.
I think the decline in UML started with the decline of Waterfall as more teams adopted Agile. To state it more generally, more teams adopted ways of working that had shorter feedback cycles (relative to Waterfall) and unfortunately UML diagrams get in the way of that since they are not testable or easily made into prototypes [1] that can be shown to the customer for quick feedback.
1: That didn't stop people from trying. Enterprise Architect from Sparx Systems readily comes to mind https://sparxsystems.com/
the teacher concluded the course with: "and this is UML, there is a high chance you will never see or use it again."
he was wrong, saw it a few times again.
he was right, never used it again.
Sadly, again and again, it is all destroyed by the client-facing people: "guys, the clients cant see the button can you make it yellow" and its infinite never ending variations, which make our job more akin to a jeweller because no amount of pre-code rationalization will prevent post-production resculpting.
Most expensive maybe, but "bravest" is surely something like spreadsheets or HTML.
It was a descriptive language, somehow useful to do nice charts, but the tools themselves were so bad the only reason devs used them is because of suspicious relationships between management and UML tool vendors...
> which make our job more akin to a jeweller because no amount of pre-code rationalization will prevent post-production resculpting.
Can I borrow that quote for my professional communications? This is so elegantly formulated.
Mind you - as most people using activity diagrams have never heard of Petri Nets they were a bit vague about what forks and joins actually mean and were using them as convenient ways to join multiple arrows together....
About UML specifically, I never understood the fixation on object orientation: the world looks relational to me !
Martin Fowler's take on this:
I agree with you and Fowler, sketches are probably a better use. When UML came about I think designs were largely developed before hand by architects/analysts and astronauts and given to developers to implement as is, but now they are better used to aid in documentation or spec out specific interactions/concepts that belong to a larger system.
Because the details get quickly outdated, since nobody will bother to update that UML everytime the code changes. And because if it's too complex, I could as well just read the code.
UML 2's concept of a core set of primitives that are used to build out a whole bunch of different kinds of diagrams was inspired. It was a shame that they didn't "just" do that.
That is because once you start trying to generate diagrams from code, or code from diagrams, you no longer are doing illustrations but are making accurate/constrained views of the system.
A class diagram built from running through C++ header files is often less useful than a textual table of the classes themselves. It is distinctly less useful than someone actually writing up a page or two of text to explain how the parts of the system are related.
UML shines when it is used to graphically illustrate such an explanation. Things like Model Driven Architecture were doomed because the complexities of the system still have to be created, whether in a set of text files or a set of 2d pictures. Once all of the informational complexities are there, there's no benefit to an illustration.
I find doing UML diagrams promotes the needs of other stakeholders earlier. Similar to how doing TDD winds up encouraging an architecture which is more testable, early UML diagrams (for me) tends to encourage a more explainable, domain-driven design.
I would say that the negative for UML is that it sometimes tends to promote more object-oriented designs, where internal concepts and external interfaces may be created and maintained with more formality than otherwise needed. That might just be conflating bad habits at the time where it was most popular, however.
Yes, I could create a class diagram as a PIM; press a button and create a PSM; and press another button and generate Java code. But the Java code had all sorts of holes in it that I had to fill in — and if I changed the model in any way, half of the code I'd written would no longer compile, let alone run correctly. In other words, OptimalJ automated the most trivial things, leaving all the hard work to the end user.
Unfortunately while MDA died, this same scheme is dominant today for OpenAPI definitions with exactly the same problems.
Like the story of the novelist who sat in on a university lecture on their book.
The intent of UML was to formalize and standardize the communication of all design aspects, from overall architecture to user interactions to class specifications so fine-grained, proponents assured us in the early 2000s that there would no longer be need for programmers because code generators will turn UML into working code that flawlessly implements the spec. This has the effect of constraining and constricting the design process itself to conform to something that will yield the desired UML artifacts, rather than letting designers communicate in a way that shows engineers how to build the product they want.
And also: use cases diagram is very useful. Thinking in terms of actors is good.
UML could've been much more popular and useful. In the early/mid '90s, I worked on commercial full-cycle CASE tools for mil/aero/datacomm development, including a "meta-meta-model" to support that. (Sadly, I loved my engineering and R&D teams, but business realities of the larger company happened repeatedly, and many innovative products and teams disappeared.)
Later, in grad school, writing various software in Java, and no longer working for a CASE company, but having many methodologies up the wazoo, I wanted a way I could rapidly iterate between static object model diagrams and the code. With no good CASE solution available for that, and no time to solve CASE properly, I forgot about all my hard approaches to the hard problems, and just quickly kludged up something that did "80%" of what I wanted, with "0.000020%" of the effort. I used OMTool from Rumbaugh's GE ACC group for the diagram editing, and wrote a code generator in Emacs Lisp. https://www.neilvandyke.org/jomtool/
My feeling is that its decline was at the expense of the IDEs and another developer-centric tooling (not in the early days open source, but latterly), and not a bad thing. Too often the tools became the focus at the expense of both less abstracted solutions and the real business problem.
In a related field, process frameworks are today’s version of that problem.
While comments in code/tests, README.md etc. are a good way to explain the bits and pieces of our software, companies have various stakeholders (software engineers included) that can't affored the time to translate these primitive documentation formats so that they make sense.
Visual representation works the best, and I wish that UML would be elaborated as a sketching mean to communicate better with stakeholders, rather than being a part of an ambitious software-generation ecosystem.
What I like about text-based tools like plantuml/mermaid is the ability to see diffs in PR.
Other industry modeling tool use binary databases to represent the UML model and make it harder (i.e. need to use their specific diff visualizers, if available) to review changes of the design.
Maybe plantuml should be adopted and maintained. Unfortunately it is still stuck in a Java implementation...
IMO any kind of informal diagram helps. Even just some boxes with lines between them.
> First and foremost, group dynamics can develop in such a way that reasonable optimism turns into blind optimism and expressing doubts becomes a taboo. When that happens, it is easy for the group to drift towards extreme positions that guarantee the group's failure. The UML standardisation community became ever more invested in UML 2's success: at first, doubting views were dismissed as referencing trivial problems; eventually such views stopped being expressed at all. The community only talked about success, even when there was significant evidence that failure was the most likely outcome [11]. Similarly, QVT was the wrong idea at the wrong time, but people were so desperate for success that they chose to ignore fundamental problems.
Graphs are naturally useful, but UML quickly became a bad investment.
That said it was a time where projects were larger and communication was harder so the emphasis on large diagrams was probably enough of an improvement over potential chaos.
For other industries which include hardware and software which has a relationship between mistakes and high costs, then it is obvious that any documentation technique should be used to lower the cost.
It also starts like a mile-long freight train, and goes about a hundred yards. I have no idea what it's doing for the first five seconds, but it isn't compiling my diagram.
I've switched to using Pikchr, which has never met an abstraction and doesn't want to. It uses a Logoesque layout language, invented by Brian Kernighan as PIC, and reimplemented with improvements by D. Richard Hipp.
He uses it for all the railroad diagrams in the SQLite docs, as well as many more UML-like diagrams in the Fossil docs.
If you've found yourself cursing softly at PlantUML/Mermaid/dot, because the icons just won't go where you want them, I strongly recommend giving Pikchr a try. If you want to diagram something which was never contemplated by Booch and friends, there's no second choice.
When Jacobson (UML) merged with Booch, they went away, and the world became slightly darker.
He was ridiculing people who used templates to draw the class blobs exactly as shown in the book instead of just whipping out a closed form with a pencil or marker
It was a massive waste of time and energy.
Having said that, the sequence diagrams were quite useful.
>The deep flaws in this vision might be obvious to most readers, but the standardisation community, intentionally or not, trained itself over time to avoid thinking about them. The most glaring flaw is: where would "behaviour" (i.e. the nitty gritty details of what a program should do) be specified? UML class diagrams are fine for expressing program structure, but they don't tell you what a function should actually do.
Sounds like architecture astronauts: https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
Frankly, for a lot of systems some block diagrams and some notes on the relations between them suffice instead of a full class diagram. I do like to use the sequence diagram though for complex communications between systems.
I wonder if the current crop of low code tools learned from the whole UML story. Any chance things will be better this time?
I'm hoping that the (somewhat-fine) distinction between no-code and low-code is made with the same problems in mind, that is, an acknowledgement that code is quite often the best way of expressing the behaviour of a system.
Note: I’m using a subset non strict “uml”. Just to discuss software architectures or document designs.
However sometimes simple boxes and arrows are enough but at least uml prevents some ambiguity.
Note that UML 2 and MDE (model driven engineering) indeed failed. However some of the theoretic aspects still hold true today. Such as DSL languages written in a GPL language (react / Kotlin dsls / etc)
And off course SQL is explainable in MDE terms (sql is a dsl for querying)
Cool think is that these days new programming languages that are more functional oriented and cross platform solve the problem UML and MDE wanted to solve. These languages support dsls for example Kotlin.
It makes me think of posix, posix is a terrible standard. "why would they make a standard with so many weird edges and shapes?" the answer is that posix is fairly hard in the standardize what already exists department. and as such preforms a vital role in getting every one started on the same page.(personally I feel posix is a good place to start but you should not feel too bad when you need to stray from it)
See Also dictionaries: there are two types of dictionary. those that document the language as it is. and those that document the language as it should be.
I liked Enterprise Architect back then. I used it as a painting tool for documentation, after the work was done.
Maybe the fact that it was mostly an offline part of the developer workflow, i.e. people didn't commonly check UML diagrams into source control and use them as part of code-gen at build time, meant that it was easy to stop using it.
2) No organization pays for proper documentation. In waterfall requirements gathering always consumed 90% of the budget, then the next 90% was development, then the final 90% was QA. Then the release-beta-and-fix later. Agile may help a bit with communication of undocumented requirements and undocumented functionality fixing and maintenance, but it's not much.
To underline, companies don't pay for documentation, the documentation they DO generate in the BA -> programmer -> QA is vastly inferior to what's needed typically without extensive communication. Related: this is why outsourcing doesn't work well except in certain situations.
3) Therefore, every developer and every business analyst and every QA person, since they aren't paid for good docs, will avoid it. If an imposed software dev process is imposed by the gods of architecture, it will be resisted outright or by innumerable subtle ways (good people quit, make minimal (bad) docs but check the delivery list, etc).
4) what remains is point-to-point verbal and informal comms, and (actually high value meetings), which are very efficient but very very hard to capture into formal documentation. How many times is a ticket in various ticket tracking have its high value data in the COMMENTS on the ticket, and the body of the ticket is worthless? Overall I'd say it was over 50% of tickets were like that. Honestly, probably more like 80% for difficult tickets, and AT LEAST that captured the dialogue/information in some way, as opposed to Slack and meeting minutes.
5) UML also implies waterfall and "requirements are ready, finalized, and set in stone". I'm sure some UML zealot would disagree, but it does. But there are vanishingly small number of projects like that. What Agile does get right is an acceptance that software is a convergent evolutionary process / dialogue between business, business analysts, and developers. Notice the three tiers there, there are TWO levels of miscommunication, so Agile essentially accepts this while UML pretends it doesn't exist. QA is likely a third one, but they are the lowest on the totem pole.
Lately I have been able to generate diagrams after the fact for my Java projects. Jdeps provided dependency graph for whole project at package or class level in dot file format and then graph can be reduced and plotted by graphviz tools. Not as rigorous as UML or visio but still pretty good for logical understanding or finding cyclic dependencies in code.
If folks were compelled to write it down, it would be obvious what a mess they were making, but it's all inside people's heads, where it pretends to be coherent and "obvious". And no I don't think enterprise service bus stuff helps any...
Then, I had a lot of architects doing complicated UML diagrams that no-one understood, then had the pleasure of managing team of developers of MDA applications, and the code generation maintenance mess was dramatic, and nothing from that enormous plumbing made any of the "real" code easier.
Happy to see that my disdain of UML is actually shared by one of the creators.
At one point I was making an object loader and didn't understand what hashmaps and hashtables were. I was making mistakes, debugging constantly and the complexity grew over my head.
I sketched out a quick 'n dirty class diagram and how everything related. Whenever I got stuck or confused, I'd look at the class diagram. I'd see where I was and noted to myself what I already implemented and what still needed to be implemented. I also asked myself if I was stuck with a high level (UML) issue or more a low level issue (not understanding a certain datastructure).
That class diagram was my rock and emotional support in coding up that object loader. So UML does have its place: if it gets too complex, but you know the design, draw out a UML-like diagram (or other diagramming methods) and it'll allow you to not have the high level picture in mind: it's right behind you on the whiteboard.
Other than that, yea proper UML has never worked for me.
I don't see a lot of value in UML's standardizing +,-,#,~ as access specifiers, vs just using the relevant language keywords.
Generally, unless people are using CASE tools, I tend to see them draw non-conforming diagrams that just roughly resemble what the UML spec says, and that is almost always good enough.
Diagrams are good, but having to worry about N different type of arrow heads, if a line should be solid or dashed, semi-obscure access symbols, etc is not good. and strictly speaking if you are not concerned about those things you are not actually using UML.
The exception is that nobody can ever convince me that a UML-style usecase diagram is better than alternatives like user stories.
The problem was also that the prof was always modelling some accounting/business "problems" which we also had no idea/experience about. So it was about learning couple of things all at once with very fragmented information. It was a disaster of class, and turned me off out of both UML and OOP. The latter I'm still sour about.
Do love sequence diagrams though - the one thing I find truly useful.
If some came out "wrong" that probably says more about experience than anything else. Being able to effectively communicate your ideas with UML is a skill that takes some practise.
I guess it is a bit overengineered (and too closely tied to the OOP paradigm) if you were to treat it as an exact specification that has to be followed to the last dot on every project (or actually forced yourself to generate code from the diagrams), but with a more liberal attitude I still find it to be a very useful tool on occasions
Well, it would be useful for giving non-developer managers something to do.
I still find sequence diagrams useful in a big way.
XSD mostly served to make people believe that XML standards could, as the name suggests, be extended. If you just specify your extension XSD it will work, right?
In the real world it turns out that an extended XML standard is just another standard, it may look a bit like the old one, but nothing is going to save you from writing new logic if you want to support the new standard.
While there are surely a few oddballs out there who just want to make standards for the sake it, to most of us, JSON doesn't need any "features", it makes parsing and generating data blobs quick and easy, that is all it needs to do.
XSD is just a way to define schemas for XML documents. I don't know what you mean by "extended XML standard", but islands of one schema within another were not uncommon.
CORBA, not COBRA.
Does anybody have information why this shouldn't be the case?
I'm also looking at whether QVT will work for doing transformations between models.
I kind of like SysML, but where I've seen it on a large scale it has failed spectacularly. People spend their time trying to figure out how to model things and fiddling with the diagrams to make them look nice. Distributed work is hard because merging becomes unintuitive. I think it could work if one really committed and tried to figure out all the edge cases, but the types of people pushing it at my shop have never been interested in that.
Personally I tend to just use the SysML package for Visio and draw "SysML inspired" diagrams these days.
Our use case is to be able to create models, they are the deliverable. Merging is a problem for us too.
SysMLv2[1], which is work in progress, is more interesting because it separates itself from general domain-specific modelling techniques and tools by:
* Allowing definition of requirements
* Allowing modelling and checking of constraints/assertions
* Allowing modelling and execution of verification methods
* Allowing trade-off analysis where objects are instantiated differently to assess impacts
* Having the concept of concurrent/parallel states
* Having spatial, time and units concepts built in
* Allowing modelling with event triggers (e.g. when X happens, then the object's Y property increases by Z)
Graphical notations are still there but I doubt they will get much use. Instead, SysMLv2 introduces textual notations and I would expect this becomes the easiest notation to communicate with. Even for Object Process Methodology (OPM) which is frequently touted as being one of the better general purpose graphical (with parallel textual) modelling notations for readability, I always look at at the textual representation as it is easier to understand.
I think the intent is that SysMLv2 would allow you to specify requirements such as (completely made up scenario):
* [Site X] shall be located at [coordinates X]."
* [Site Y] shall be located at [coordinates Y]."
* A minimum of 15 [sites] shall be located in [territory X]."
* "Each [site] shall have a [line of sight path] to two or more other [sites]."
* "[Line of sight paths] between [sites] shall be calculated using [XYZ:2022 standard]."
* "Each [line of sight path] shall not exceed a length of 50000m."
* "For each [site] located in [territory X], [planning overlay X] shall not overlap."
* "For each [site] located in [territory Y], [planning overlay Y] shall not overlap."
* "Each [site] shall have a [chance of flooding] not exceeding {some metric}."
* "[Chance of flooding] for sites shall be calculated using [XYZ:2022 standard]."
You can then write many of these requirements as constraints/assertions in the textual notation and embed other languages within the SysMLv2 textual notation or call external software tools so that constraints/assertions can be calculated externally with external data, for example, GIS tools and data or historical records.
[1] https://raw.githubusercontent.com/Systems-Modeling/SysML-v2-...
Yep just me ok
https://en.wikipedia.org/wiki/Adolf_Hitler:_My_Part_in_His_D...
Specification has a fundamental tension between clarity and completeness. I don't believe it is possible to maximize both. As a specification becomes more specific, rigorous, and 'correct', it diminishes in understandability, due to the limits of our working memory. As a specification diminishes in clarity, it loses appeal with most audiences. See also the rise of JSON in reaction to XML.
This is the key tradeoff with UML. If the ultimate goal is to model a system, with platform-independence, at a level of detail sufficient to enable code generation, the specification and model representation will become complex, and the friction and overhead become too great for a typical corporate internal or external product, thus limiting the specification tool's adoption. The tool is no less valid, and can be useful for high-criticality areas, such as aerospace, or for academic exercises.
One should objectively analyze the tangible and intangible costs of UML against benefits and use something else if it provides a better outcome. Perhaps a 'UML-lite' approach, such as C4 [1] or PlantUML [2], is a better tradeoff on the completeness-clarity continuum for a given scenario.
Another interesting modeling framework is 'Object Process Methodology' (OPM) by Dov Dori [3].
The two aspects of OPM that stand out to me:
1. A focus on the model alone, maintaining understandability, and an effort to keep things simple. Information hiding techniques such as zooming are provided as a means to manage system complexity during the modeling process.
2. Instead of an ultimate promise to allow bidirectional translation from model to code, and code to model, the visual OPM representation has a textual counterpart, 'Object-Process Language' (OPL). With this facility one can translate from model to descriptive text, and vice-versa. Thus, one may read or define a model visually in diagram form, or as a series of sentences using a minimized set of English words that is also machine parseable.
Still we must recognize the tradeoffs: OPM may provide more clarity, but has less completeness. It won't round-trip with a code base, and it lacks modeling capabilities that can descend into an operation/process, e.g. one cannot model control flow concepts such as sequences, branches, loops, etc. Within the UML garden, concrete operation implementation can be specified in OCL, and the newer fUML can, in theory, reach down even further into operation specification.
[1] https://plantuml.com/ [2] https://en.wikipedia.org/wiki/C4_model [3] https://en.wikipedia.org/wiki/Object_Process_Methodology
I cannot fathom developing software without UML. How can you even design a system without diagrams? It's simply impossible.
There isn't one software component that my multiple teams at Amazon have designed that didn't use some diagrams from UML. And I'm sure you can say the same for any team in any FAANG.
Sure we aren't gonna do a class diagram the vast majority of the time, but there will almost always be some component diagram, sequence diagram, activity diagram, etc.
Some of the parts of UML are dead because they're not a good time investment, especially when working in Agile (class diagrams), but I'd argue that 90% of the people that say they never used UML after school have used it without realizing.
Just look at this thread, 100% of the responses are saying that UML = Class diagram.
Yet look at all the massively successful software written without any UML.
If you don't want to use, you are throwing away a "super power".
Communication is, perhaps, the hardest part in software engineering field, and UML removes a lot of the ambiguity by using icons that represents a lot, replacing pages and pages of documentation.
Furthermore, with a serious UML tool you can have traceability between everything, tying the problem to the final solution.
I don't care anymore if people/companies don't use it. I use it for myself. It's the tool to leverage my brain and make my life easier when controlling and managing all the information complexity I work with.
TIP: you don't draw everything, you draw only what is important, KISS (keep it simple) and chose the level of details you need. You can always add more later. Everything MUST have traceability, if not, it will be useless in some time. Ignore the tools that does not have this feature.