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.
Some random observations from an old-timer developer.
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 love sequence diagrams. They are essential for designing complex event-driven system where there are a lot of asynchronous operations. I often use them to make sense of and/or prevent race conditions.
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.
I still willingly make sequence diagrams to fully document what is happening in a complex system or architecture. I find them to be very useful to get everybody on the same page for the "order of events".
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.
I can relate. It's an essential communication tool. When discussing asynchronous events with a colleague, there is a point in the discussion when it becomes almost impossible to explain it in words and you really need something like a sequence diagram to communicate accurately.
> 2. Sequence diagrams are very useful. I've created plenty to document and teach complex interactions between various (micro-) services.
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.
Been through all the silver bullets of the last 30 years, and the UML round-trip craze of the late 90s/early 00s were the worst.
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 corporateobject 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.
Not being intuitive isn’t the strongest argument against specialized notation. Programming languages aren’t intuitive either, yet we learned them. The rationale is that the arrow goes into the direction the #include or import would go. So it shows logical dependencies — both caller and implementer depend on the interface — and you can quickly see if there’s a dependency in the wrong direction somewhere.
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.
I think we need a slightly more specialised word than 'intuitive' and we don't have it. Something that has the flavour of ">80% of experts use one of [set] mental models, and this thing doesn't capture the essence of any of them".
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.
Even with Java 1.4 the obvious mapping of class diagrams to data structures made for terrible data structures. You end up with an interconnected maze of objects that is totally inefficient for the algorithms. The mess typically included redundant, bidirectional and cyclic links between objects and where an object's only purpose is to be a list of another type of object, someone ends up writing a more limited wrapper around std::list/Collection/whatever.
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.
>Programming languages aren’t intuitive either, yet we learned them.
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.
> OOP isn't what I would consider intuitive out the box
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.
> 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
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?
Doesn't UML have metaclasses, that could be used for type-level stuff? First-class functions should probably be represented via the Command pattern, which is ultimately a kind of defunctionalization (i.e. it's what high-level functions get compiled down to in actual code).
> i.e. it's what high-level functions get compiled down to in actual code
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.
I wonder, if you spend so much time writing fine-grained UML, aren't you already sort of programming? If so, wouldn't that time be better spent with an actual programming language with all the ergonomics and features you need?
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.
IMO the arrows point to the right direction, in a sense that in my mental model arrows are typically owned by the pointer, not the pointee. The pointees are typically unaware of what points to them. A base class "doesn't know" what its derived classes are. Likewise a git commit doesn't know it's descendants either.
So in my mental model a derived class actively "points to" its base class. Likewise a child commit points to its parent/parents.
> A base class "doesn't know" what its derived classes are.
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.
"derived class actively "points to" its base class"
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.
A "this is not intuitive" argument can be made about every formalised system and is not interesting: It will always be true for someone, no matter what you do. Get used to it being otherwise, then it will not bother you anymore.
When it is a visual notation and the main purpose is that it is supposed to aid you in thinking, then I think being "intuitive" is one of the most important features.
I want to see a graphical representation of my "business" entities, not a more verbose 2D representation of my source code.
I hadn't heard of CRC Cards before, but after a google search, I'm realizing that I've definitely written something similar while whiteboarding an idea. Thanks for the tip.
Well, I take issue with most formalized diagrams that represent code elements, rather than "business" entities. It leads to a kind of thinking that is wrong IMO, where you mechanically represent every business object by a class, say Customer and Employee.
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.
Then you are not complaining about UML, but about the old school bad OO designs that UML is meant to support (along with old school good OO designs).
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.
Sequence diagrams are not particularly helpful with JavaScript and alike and agree with parent OP that its too strictly tied to C++/Java. They are just not intuitive with async/await and function composition. Yes, one can always do "mental translation" to translate those into the diagram and vice versa, but just not helpful. Now one would argue that you model "more abstract processes" with them, but there are better modelling languages for business and network processes.
If I were reviewing a system design, yes, with js, I'd still like a sequence diagram. I'd just indicate that ordering may not be exact between certain bands of requests. I model concurrent systems all the time in sequence (ish) diagrams.
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.
They, however, a) were pretty much the only actual UML's innovation: other things like sequence diagram have existed long before; b) had most emphasis put on them.
I'd say it's getting a wide audience agree on a common method of notation. I have a Java book from 1999-2000 which uses OMT (all right, OMT's object diagrams) as its main representation. Not too far off from UML class diagrams, as it is also considered a historical predecessor, but still enough to make me consult the legend time to time.
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.
What UML (class diagrams) never really got, is that in order to be simpler, you generally have to leave out details. But that means you cannot generate code from a class diagram unless it basically is the code.
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.
You've said in a nutshell another of my issues with "visual programming will solve everything". If you take any non-trivial code base, or generally any non-trivial algorithm, and you have to express it all visually, the result is a useless mess.
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.
Exactly. The sane use-case for UML is as a visual aid to help one human to communicate something they know about some code to another human being. It's a visual summary of something. For this purpose "boxes and circles with lines and arrows between them, and text in or next to them" is fine. We don't even need different arrowheads to differentiate "owns"/"consists of"/"inherits from" - a piece of text next to the arrow that says "inherits" is fine (if actually needed and not obvious from the context). Heck, different arrows can mean "inherits from", "displays data from" and "sends a network request to" all within the same diagram, and most humans will pick up on that just fine
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.
I agree. A schema language that can be used to codegen has to be very rich, and uses of it have to be very detailed. UML mostly only found a niche in writing docs, in which case it would be better to generate the UML from sources, which then requires having access to ASTs or alike. It's no wonder that UML is mostly hand-coded and only for docs, in which case UML is a bit heavy-duty.
I still miss UML class diagrams being widely understood. At the peak of its popularity, you could go into a room with just about _any_ programmer, draw boxes and arrows on the whiteboard and everybody understood. People knew which arrow was composition, which was inheritance, which way the dependencies flowed etc. UML pictures made it easy to design modular software - just make sure all the arrows point in roughly the same direction and you're set.
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.
> 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.
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/
A former colleague of mine held an opinion which I still strongly agree with, that the most productive use of these diagrams was during conversation, on a whiteboard. ( https://www.websequencediagrams.com/ is the next best thing)
This is my sentiment exactly. Now in it’s place we have bespoke diagrams where the meaning of lines, arrows and their directions vary from person to person and you need to ask the author to explain their convention before you can understand the diagram without assumptions.
At its core, MDA is just the notion that UML (or some other graphical notation, for that matter) should be able to express Domain Specific Languages (DSL's).
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.
This idea we could work as little ants on a factory chain still persists to this day, but UML was the bravest most expensive attempt at "no-code" industrialization they've attempted.
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.
It wasn't even "no-code" since you actually had to write the implementation. Yahoo Pipes was more no code than UML (I dearly miss that service).
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.
UML had activity diagrams as its own pipe-like notation for low-level code. Not sure whether it was widely used, though. Also in general, conveying high-level data models might be more of a priority than implementations.
I've only ever seen activity diagrams used by business analysts to capture system dynamic behaviour at a very high level.
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....
In spite of all the hate against formal models, most of the problems I have encountered in the last twenty years are much easier to solve when the problem-solving conversation uses a model as common object. Conceptual data model (I love Merise), process with swimlanes, state machines... Nothing new and still extremely useful.
About UML specifically, I never understood the fixation on object orientation: the world looks relational to me !
My main problem with UML is that it actually makes most sense in selective sketches rather than exhaustive blueprints and if you creating a informal sketch the details of the diagram syntax are pretty much irrelevant.
Why is that a problem? You don't have to use all of a programming language for it to be useful. UML is just trying to "unify" a bunch of useful diagramming under a common umbrella.
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.
Its not a problem for developers but arguably a problem with anything like UML - which perhaps explains why it has failed to really take off in the way that a lot of people 20 years agoreally expected.
Agree. The UML should only quickly explain the general idea, not the details.
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.
It is very useful to illustrate a facet of a system - how four components interact, how something is meant to be deployed, the state machine used to make certain decisions, network communication, and so on.
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.
My university SE class was during those heady days of MDA, and my opinion, nicely summed up in this article, hasn't changed one bit:
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.
Oh wow, thank you for the reminder. I started work consulting on a project recently where the team is using protobufs and grpc. While they aren't directly changing the generated files, they aren't keeping them appropriately gapped. I knew this problem had been around since forever, but I couldn't remember where I'd seen it covered. This is exactly the pattern I had in mind but couldn't remember. I hope that I can help the team overcome some difficulties by discussing this with them.
IMO this works for RPCs, ORMs, and certain event streaming architectures but not REST APIs beyond some trivial cases. As soon as you might want separate middleware processors but the same terminal handler it starts breaking down.
> [10] Astonishingly, people in the small UML community associated my name with QVT for years afterwards. Though not always. In about 2012, I remember an important Professor who heard me mention QVT explain to me what the text actually meant — quoting text at me which I had written, and which did not mean what they thought it meant! I tried not to laugh.
Like the story of the novelist who sat in on a university lecture on their book.
UML failed because it was yet another attempt to "solve the software crisis", and the "software crisis", which never goes away, is this: Writing software defies the Taylorist conceit that competence should be vested at the organizational, not individual, level. Delivering good software stubbornly depends on people who are good at what they do; and if you apply the corporate favored technique of throwing a bunch of mediocre people together and forcing them to apply a standardized process laughingly called "best practice", expecting them to turn into top performers, you will be sorely disappointed and will not deliver good software. This has turned out to be a major bummer for middle managers, as good programmers are hard to find and often command higher salaries than said managers are willing to pay.
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.
I may not be an orthodox user of UML, but I like it. Especially sequence diagrams, but also classes. I like it in the AMDD fashion: quick sketches to show only important parts of a system (or part of it). Using it to generate classes or from classes is pointless to me: it must be an artifact in itself, choosing the right colors and symmetries to better represent what you're trying to convey that may not be obvious from the code, such that a bird eye view of a system or an interaction between systems, or parts of a system. Like many I was taught it, but I wasn't aware of its popularity or lack of it. I've used it and found it useful when stumbling upon it for something I have forgotten the inner workings of.
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.
I wish that the lessons from UML would one day lead to the a less ambitious modeling toolkit. What we need are ways to _communicate_ our design, not automate it.
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.
There's a place for UML in the README.md; as some other commenters have pointed out, UML works much better as a sketching tool than as a total definition of a software system. A couple of quick class diagrams at the top level (probably generated using something like https://plantuml.com/) might provide a better communication model than text.
Yes plantuml is still my go-to visual design tool, whenever I feel information is missing, and I actually prefer it over mermaid (which has been integrated in github markdown), which I found very lacking.
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...
You can still use UML for sketching. The free Doxygen tool even supports reverse engineering of UML class diagrams from (possibly annotated) source code.
On a side note: Why are there almost no VIEWERS for Markdown? Every project has a readme.md, which everyone ends up reading in a text viewer with all the formatting markers all over the place. WTF?
I've drawn up UML (or close-to-UML) class diagrams in the past while trying to understand large, unfamiliar C++ codebases while new to a project. While they were painful to make (especially by hand), they provided a nice map that could be pointed to while asking questions in meetings with those who knew the code. The making of the diagrams were an exercise that definitely gave me a better understanding of the class relationships that I would have taken longer to learn otherwise. Beyond the initial exercise, I didn't find them very useful in the longer term.
This conclusion hits home for me, ringing true with very different sorts of fields.
> 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.
I was in university 2004 to 2009. We had a total of 3 UML classes. A whole semester of wasted time. The professor that pushed this got "promoted" to a non teaching role after us. Everyone with some programming experience saw UML as a complete waste of time. The people pushing it at the time had no actual use-case just pie in the sky dreams of autogenerated software. It was doomed to fail.
UML problem was cultural too. It's a crowd who valued too much heavy tooling (if not bloat). The more, the better (just like early java days)
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.
UML isn't dead, it just went to bother someone else. All the rage in Systems Engineering these days is Model Based Systems Engineering (MBSE). At the heart of MBSE? SysML, which is "defined as an extension of a subset of the Unified Modeling Language (UML) using UML's profile mechanism."(https://en.wikipedia.org/wiki/Systems_Modeling_Language)
Documentation in general got the knife in the back. This has nothing to do with UML I believe. The cost for refactoring pure software is very low so any mistake can quickly be corrected.
I would still insist UML be taught at universities just to open the mind of the students to possibilities.
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.
I learned UML in university, in 2018/19. Nobody liked it, but it made for a practical way for professors to give us class definitions in a language-agnostic way. All the classes about learning to use UML were otherwise universally hated (because not giving us the class definitions in UML was thus vague) and besides toying with a UML to java converter once, i've never touched it again and i don't think any of my classmates have either.
Wow, I'm surprised they're still teaching it! I learned it in university in 2007 or so and found it utterly useless and outdated even back then. I don't think I've ever seen it used outside that class.
I teach OOP at a large reputable university, and I use UML every step of the way. For all the hate it gets, it's still the best thing for documenting and describing relationships in OO systems.
I've done a few diagrams in PlantUML, which were better than nothing, and better than using a vector editor and doing it by hand, but there's a constant low-level frustration. One, if the authors didn't think of something, you can't do it, and two, if the layout engine makes bad decisions, it's truly tedious to instruct it otherwise.
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.
UML always seemed to me to be a solution seeking a problem. I never had a problem with someone drawing a bunch of circles, boxes, and arrows on a whiteboard (that would not be erased until the project was done). That approach tended to have more detail where needed and less where not needed.
Booch told us in a class that the blobs were there because
(A) he could not draw a box on a whiteboard
(B) at this stage of development, there are no crisp understandings anyway so there's no point in making crisp corners.
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
I spent a good couple of years working with UML and related tech and products (especially from the Rational suite). Besides the fact that I hated it, a big personal gripe I had with it was that noone looked at the UML after the initial review. Ever. We generated the diagrams to fulfill some outdated legal requirement (Sarbanes-Oxley, I think?) for getting listed on a particular stock exchange, but other than that they literally served 0 purpose.
It was a massive waste of time and energy.
Having said that, the sequence diagrams were quite useful.
> By the time I had become involved in things, most of the nuance in the MDA text I quoted above had disappeared. It was largely taken as a given that only the most talented people in an organisation would be involved in the creation of PIMs; a cadre of second-class citizens would then have to engage in the drudgery of creating a PSM from a PIM; and no-one would need to worry about the code generated from the PSM.
>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.
I used it a bit when it was still built into Visual Studio. You could even let VS generate some boilerplate class definitions, but it was never accurate and complete enough to use.
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 the early 2000s as a consultant I had the job of designing and building a new e-commerce site on top of an existing green screen system. Java was an obvious choice and I found a tool to design UML diagrams which would spit out Java code with empty methods. Some of the developers were new to Java but these templates kept everyone on course. Worked like a dream.
While UML as a sketch had some use, it was a very predictable disaster when people tried to use it to automate away the 'coders'. It automated 5% trivial work that bothered nobody, while getting in the way when things got medium hard.
I wonder if the current crop of low code tools learned from the whole UML story. Any chance things will be better this time?
Diagrams are good for representing structure, and inherently less good at representing behaviour (as mentioned in the article). I recall that in the early 2000s some UML tool venders were pushing "round-trip automation" as a way of tackling this problem; basically you'd model your business domain with some class diagrams, generate some boilerplate code, write code for the actual behaviour and then the tool would magically suck all the behaviour logic back into the diagram. It sort of worked, for a couple of passes, until the tool failed to capture the precise semantics of some perfectly valid code (which was probably inevitable).
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.
Still use subset of UML often: class diagrams, state diagrams and sequence diagram. Exactly the things that were used before uml and that uml 1.0 standardized.
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.
"when standardisation moves from "standardise what already exists" to "standardise things that we think would be good but don't yet exist" it enters dangerous territory."
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.
UML became a kind of cult. There were Gurus and a Priesthood doing specification. Writing Code Generators was a cottage industry. The plebs should fill out the details.
I liked Enterprise Architect back then. I used it as a painting tool for documentation, after the work was done.
The author mentioned that UML peaked in 2000. I started a job in the IBM software group three years later, just a couple of months after IBM acquired Rational. I don't recall anyone using UML during my time at IBM, even though we had free access to the entire Rational suite. We did eventually use Eclipse Modeling Framework for modeling and code-gen, but not through visual UML diagramming. It's fascinating that UML lost relevance so quickly.
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.
1) UML is documentation. Quibble about inputs or formalization ... whatever, it's documentation
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.
Sounds to me like they wanted to standardise something they didn't even have a working implementation of! There is a difference between invention and standardisation, and it is usually not done by the same kind of people.
So many great comments here about UML tools. I also had the misfortune of using them. I agree that details of classes internals was rather intrusive info to digram out. And instead of helping it actively harmed system understanding.
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.
What I'd really like to see is better standardization on network interface diagramming. Many organizations are doing just fine and well as far as the programming goes, but their undocumented network relationships are utter spaghetti, with zigzagging microservices going bananas in every direction.
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...
Back in the day, I really liked the idea of standardizing class diagrams, but it became quite complicated at some point.
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.
When I was learning how to program, I programmed a graphics engine. It was about 10K lines of code, my first 10K in a single project.
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.
'Proper' UML not working for you is the entire problem. UML had some good ideas, but none of those good ideas are unique to UML. Drawing things and the relationships between things is awesome.
I've used UML to communicate certain things about code. Class or sequence diagrams are great tools to explain code structure or workflow. Of course it's not very frequent that I need to use them, but they're still useful.
Sure, but were those diagrams even conforming UML? And should they be?
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.
It was definitely a waste of my student time. I had to take the class on my second year and spent a semester learning UML because the professor was all into it. We've just heard about OOP at that time, the biggest achievement was being good at Delphi, most of the class had trouble writing a hello world in any language.
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.
I've worked with two engineers, at a FAANG, who could not function without UML diagramming and generating their code. Both were 100% convinced that the only way anybody could write working systems was UML. So my teams got very little from those SWEs because nobody was willing to boil the ocean redesigning everything around UML code generation. They have together collected at least $3m in salary, bonus and equity over the last decade.
I remember being in scrums that used UML to generate code in the 00's. We just didn't wake up from the scrum delusions as quickly. I had read the agile manifesto, so when a manager told me as a young engineer that we were going to do agile I was momentarily overjoyed at the prospect of focusing on getting code working rather than our process or our UML tools... Then he showed me our new process, and I still had no choice in my tooling. So I said goodbye to that job. Sadly scrum has been harder to escape than UML.
I remember doing an exercise where a class that had just learned UML were asked to all specify the same design in it. Every diagram was completely different and many were just "wrong". It's like a language without any syntax checking. Come to think of it it also needs something along the lines of a unit test.
Do love sequence diagrams though - the one thing I find truly useful.
Most classes are only going to teach you how to sketch UML diagrams. If you were told to create diagrams conforming to a particular UML spec they would all look very similar.
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.
shame, I remember learning it felt quite nice, to have a well thought-out toolkit to structure and/or share your ideas about certain aspects of a software. I still use it now for those purposes sometimes, in a quite 'free-form' manner on paper or on a whiteboard (so not sticking to the exact conventions of filled or hollow shapes everywhere, which I've also long forgotten, but using the basic pattern of eg a class or sequence diagram to communicate the point that I want to make about my idea, or to just develop an idea by myself).
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
After reading this, and having minimal exposure to UML even during the late 90s and early 2000s, it strikes me just how many acronyms are needed to describe the ecosystem around UML. Perhaps the requirement of so much institutional knowledge led to its fall? I see correlation in that regard with web development today.
TogetherSoft's Together did a pretty good job of the round-tripping, with the primary focus on the coding editor but diagrams when you needed them. It kept the two in sync very well. Used that around 2003 IIRC. They got bought by Borland and then spun off.
No one has yet mentioned that the Design Patterns uses UML to elucidate its patterns. I think those diagrams work due to their limited scope. I hope those I have drawn with similar limits have helped others understand my and even their own designs.
Modeling != diagramming. The fixation on drawing the system model was one root of the problem in my opinion. Also, xml for the meta model is a great way to dissuade people from building tools to consume the model.
XML, XSD, XSLT, and the rest of that stack was actually useful. Overengineered and verbose, but useful - enough so, in fact, that the JSON ecosystem still hasn't fully caught up on standardizing the same feature set.
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.
XSLT (or rather XPath, and even more so XQuery FLWOR) have very expressive ways to walk the tree while filtering/mapping/folding data - much more so than JS over JSON.
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.
Back around 2006 the consulting company I worked had internal team go all in on a developing framework around MDA and Java. Sales would offer it to a client as a way to validate the model and interactions and then generate all the code. Even for basic CRUD app there was so much left out of generated code and was too easy to get the code and model out of sync. I came in late on a project to help solve performance issues. That short stint gave me more insight into that world than I ever wanted.
I'm working in a project that uses SysML, an extension of the ISO standards group that originally developed it. There are problems in that none of the tools for it are compatible with each other but it works if everyone uses the same one.
I'm also looking at whether QVT will work for doing transformations between models.
An open source tool is also desperately needed imo.
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.
My view on SysMLv1 is that domain-specific modelling techniques or tools are almost always far superior, and SysMLv1 therefore becomes a burden as you have to use the other techniques or tools anyway, and SysMLv1 doesn't have much to offer on top.
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.
For C Code UML is sort of moot. UML shines outlining object oriented designs and transactions. Management loves it along with Power Point and large conference rooms. I don't know who in their right mind think that is possible or useful to standardize software documentation. Except the README or its fancy cousing README.md of course. That's standard. ;)
did anything succeed UML without the bloat and problems? I liked UML in principle but it just never was very useful to me beyond drawing boxes and arrows and the occasional sequence diagram.
UML is a tool like any other: one should understand the tradeoffs and make an objective decision as to whether it is useful and appropriate for a specific organization and scenario.
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.
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.
Working for decades in this industry, I have not find a better way of managing a huge amount of complexity than 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.
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.
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
and (Or is it this --> that? Or this --<> that? this --<>* that? I can never remember.)English is linear in a way diagrams are not.
(Yes most programming languages use trees, it has some advantages. But most people program in excel anyway.)
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.
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.
https://plantuml.com/
Diagrams are more efficient to drive the point home.
netlists do a perfectly fine job of describing graphs
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.
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.
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.
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 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.
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.
Then again, the bureaucrats of today call themselves "agilists" and fill your weeks and days with meetings after meetings, plannings, sync ups, etc.
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.
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).
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.
Anyway, it caused by that status thing. Your teacher knew it, and you didn't yet. But he couldn't just tell you.
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 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.
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...
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 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.
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?
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.
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]
[1] https://en.wikipedia.org/wiki/COMEFROM
I want to see a graphical representation of my "business" entities, not a more verbose 2D representation of my source code.
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.
The fact that UML formalized them as a way to describe code tells you a lot about the standard's quality.
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?
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.
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.
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.
When you use UML, your goal should be to convey the overall architecture, the modeling of the domain, and some implementation details.
Yup, thats what I am working on since a few years.
Leaving out details can easily be solved with collapsing the code segments.
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.
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/
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.
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:
https://martinfowler.com/bliki/UmlAsSketch.html
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.
[0] https://en.wikipedia.org/wiki/Booch_method
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.