It is easy to account for UML's lack of long-term success: it sucked. The so-called Universal Modeling Language, was not universal, nor was it a language. It was a graphical notation for describing code written in a particular paradigm that was fashionable at the time. The biggest problem with UML is the same as the problem with any graphical notation: the symbols it used did not have any lexicographic order, and so if you encountered a symbol whose meaning you did not know there was no way to look it up. You had to either climb the whole learning curve yourself or consult someone who had. This provided social status to those who had the knowledge, completely independent of the actual value that the notation provided. That was the main basis for UML's popularity as far as I could tell. Far more effort was put into teaching UML than was ever put into actually using it, at least where I worked at the time (NASA).
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.
A lot of harsh words for UML, and it's not something I use myself much anymore.
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.
Well, I can pick up a piece of paper with classes, or a sequence diagram and external systems, and then tell the story from many perspectives to another person.
"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 :-)
> But trees are trivially linarizable. What will you do when you need to describe a graph, when there's some direct relationships between sub-systems?
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.
And what exactly is the "it" that you "feed to graphviz"?
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.
The problem with text is that it takes a lot of writing to describe complex interactions and the reader checks out somewhere in the first quarter of your prose.
Diagrams are more efficient to drive the point home.
Readers check out with those, too. I've found that's largely because everyone has a slightly different perspective on what something means, ergo everyone's always talking slightly past everyone else and the discussion doesn't amount to anything. It takes a very skilled learner to say "I'm shelving my idea so I can understand yours." And it takes a very skilled teacher to simulate a learner's brain with their own. Diagrams don't solve this problem, in fact, no tool does.
Text is okay, but describing a graph is difficult and not as intuitive as a diagram. This doesn't mean UML is needed for the diagram, however the alternative is a semantically weak ad hoc diagram, and I'm not a fan of UML even though have plenty of experience, I agree that UML basically had good intentions for a real problem, poorly executed.
I think there is a distinction between UML as per the 1000-page spec vs drawing some class diagrams with lines in-between that makes sense to you. Visual representations are very useful, as most of us are orders of magnitude better/faster with images than with text. I also like to scratch in the planning phase something that might resemble UML from far, but I think that is strictly different from it.
UML was bound to OO design methodologies that really didn't work that well (any time you have a vaguely specified component with "manager" in its name it is likely someone was following one of them and, usually, an example of Conway's law). It was also bound to CASE tools that few could afford, fewer could master, and that I've never seen used well, so I couldn't say if they worked or not. And then, of course, Agile happened and designing anything became uncool and unpopular.
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.
> any time you have a vaguely specified component with "manager" in its name
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.
Yes - to be clear, the limitation is the notion in the methodologies (not necessarily the underlying language) that any time something has to happen, an object does it. Should it be this object? No, it should be a different object. What should we call it? Yes, I was making a funny about Conway's law, but that's the point you shrug and say "call it pointAToPointBConnectionManager".
> the notion in the methodologies (not necessarily the underlying language) that any time something has to happen, an object does it.
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.
Being graphical is probably not sufficient for a notation to fail; electrical circuit diagrams were/are a successful notation even though there is no obvious lexicographic ordering of the symbols.
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. A line in a circuit diagram means that there are two physical things located in physical space with a physical wire going between them. There is no such natural correspondence for software because software does not exist in physical space.
I feel like you’re weaselling out of your earlier statement a bit. In your top comment you talk about it being hard to look up symbols. I point out that you need to look up symbols for circuit diagrams and you say that actually one doesn’t need to look them up because they are actually intuitive and you invent a new criterion for diagrams to fail so that circuit diagrams can pass through but UML cannot.
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.
Fair points all. A few nits though: the symbol for a resistor is not "just a longer wire", it's a zig-zag shape, and IMHO the symbol for a potentiometer is pretty intuitive. And yes, SQL's syntax diagrams work well. But I think the reason they work well is that they aren't trying to describe software, they are trying to describe (the structure of) a certain kind of text and text is spatial.
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. :-)
By using names and references to those names. In the circuit modeling language I am working on the nodes in the graphs are components and the connections between them are signals. Both are first-class entities. They all get assigned unique names which end up being fairly complicated but which you hardly ever have to refer to directly because you are almost always dealing with them at some level of abstract hierarchy where there is a simple name by which they can be referred and the rest of the true global name is implied. This allows you produce a complete description of a chip, i.e. a graph with billions of nodes, using text that is orders of magnitude smaller. And as a bonus you can automatically compile that text down to a physical layout that allows you to actually fabricate the chip.
There are graphical representations for the layout as well. But the text is primary.
Another aspect is that in software, the code is actually the design. So a diagram that only approximates the design is not so useful as it is in electrical engineering where there still MUST BE a completely accurate design or the project fails.
The key part of the Data Flow Diagramming method (as I was taught it, anyway) was not graphical: the Data Dictionary.
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.
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:
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.
> This really just boils down to complexity and verbosity
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.
One can get lost talking about such details. It is a fact that the act of programming is a very elaborate means of modeling physical events. In fact we can simply map language->compiler->machine-code->physical-device and note that our programs in language x are in fact obscure models directing physical devices.
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.
> programming is a very elaborate means of modeling physical events
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.
Excellent example of how a notation can succeed and fail at the same time. Electric symbols are used as a programming language in the plc sector and fail horrible when programs accumulate ever more complexity.
It more or less unified a few notations that were already quite common or at least similar enough. There were two problems that it had:
- 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.
UML, together with the "Rational" (yuck) tools were the culmination of the "bureaucracy driven development" where producing paperwork was more important than actually shipping the darn thing
There is something to say for design and long term (old fashioned) waterfall. Imagine starting building a rocket today to deliver a satellite to a specific location in space tomorrow. The just ship it paradigm has its place making web apps and smart phone app doo-dads, but that's about it.
I think the difference is in what is trying to be produced. Musk has said that his goal is to build a rocket factory, i.e. SpaceX is trying to produce lots of rockets, not a few rockets.
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.
I think they all boil down to basically the same thing. In order to build a complex system you need to build it twice. The first time you will make mistakes that are difficult and expensive to fix and you need to tell yourself that it is ok to throw it away.
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.
No, it's a huge danger. It means you have a product that you will be pressured to be put into production, but it is saddled with technical debt and will likely become a huge hassle to maintain. Your second version will come as a painful set of patches against a mostly running system that is increasingly complex because it has to work around old bugs and design misfeatures.
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.
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”.
I honestly don’t think it was that bad. They should have just kept it to class and sequence diagrams however. As the author states, adding all of this unnecessary standardization around things no one uses was pretty ridiculous. Also various people clearly took things too far with laughable round tripping tools.
In the end, UML is fundamentally unimportant. I think having a strong opinion about it (either way) doesn’t make sense for this reason.
The problem is that UML was forced upon a lot of people who basically didn't need it. At some point simply saying "Meh, it is not for me" doesn't cut it, you have to actually fight back to prevent the brain rot that the marketing is causing.
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.
Activity diagrams can be very useful as well, and you can mix and match various UML elements in them, it's a very flexible visual language. Also state
diagrams, of course, as a sibling already noted.
I can recommend Martin Fowler's "UML Distilled" for a pragmatic approach (ISBN 9780321193681).
UML is a modeling language, not a "graphical notation", and I want to put emphasis on the model. The model could be represented graphically but the whole point was (or should have been) to capture the model.
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.
I would say the opposite is true - UML started off as a diagramming tool and then people realized the value wasn't in the diagrams but in the models. Most of the tooling however view UML as a set of standardized diagrams - which is just about worthless.
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.
Also uml has difficulties in modeling event driven architectures, things like promises, functors and streaming lambda futures become an entangled mess when described in uml.
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.