UML's promise was that that with detailed enough diagrams, writing code would be trivial or even could be automatically generated (there are UML tools that can generate code). It was developed during a time when there was a push to make Software Engineering a licensed profession. UML was going to be the "blueprints" of code, and software architects would develop UML diagrams similar to how building architects create blueprints for houses. But as it turned out, that was a false premise. The real blueprints for software ended up being the code itself. And the legacy of UML lives on in simpler boxes and arrow diagrams.
IBM used to push the adoption of their business process software for exactly the same reason. They imagined that "business process experts" use UML to construct the entire business process, and then the software (based on WebSphere Application Developer, an Eclipse-based IDE) will generate all the execution code, including deployment scripts. The irony is that the UML itself becomes more complex than code, and dozens of layers of exception trace were simply incomprehensible to engineers, let alone to "business process experts". To add insult to injury, IBM mandated generating tons of EJBs. Even thinking of that induces migraine.
P.S., It's surprising that those who advocate that UML is better than code didn't understand the essential complexity would not go away simply because we switched a language, as essential complexity lies in precisely specifying a system. Neither did they understand that that a programming language offers more powerful constructs and tools to manage complexity compared with UML.
> UML was going to be the "blueprints" of code, and software architects would develop UML diagrams similar to how building architects create blueprints for houses. But as it turned out, that was a false premise.
True. The blueprint is the code. The brick and mortar construction is done by compilers.
I used one of those tools at one point, Rational Rose.
It was possible to get it to generate code, as I recall it basically gave you stubs of classes and methods and you would then go and code the implementation of each method.
It seemed like it could save you some amount of effort at basic boilerplate stuff but at the cost of putting the same or more effort into the UML.
UML was the swan song of the classic waterfall SDLC gang. Agile and TDD came along and nobody looked back.
The thing is I found quite paradoxical (to stay polite) that you'd spend time drafting something that is not precise, not data to help you but just a document in a tool.
The model driven thing was nice but it was never good enough to actually help with code. It was also deeply rooted in the crippled Java days so full of verbose diagram representing overly verbose classes.
To hyperbole a bit, I'd rather spend time writing property based tests and a few types in haskell in a way.
I've always really disliked UML because it tries to strictly encode a whole lot of information into diagrams, which is way too rigid and opaque for me. My eyes just glaze over when I see UML.
I don't want to have to search "what does double arrow mean UML" in order to understand a proposal. I don't want an arrow to mean something that I couldn't learn somewhere else. I'd rather have a loose informal reference diagram alongside a couple paragraphs describing the system more formally. That way, the important information can be emphasized, the unnecessary information can be glossed over, and the diagram acts as a big-picture aide rather than some kind of formal semantic notation.
UML is a language or notation. It isn't dead and I consider it still useful because a standardized notation means you don't have to explain your notation again and again. Or worse you forget to explain the notation and people are confused what that arrow or box actually means.
The promise "that with detailed enough diagrams, writing code would be trivial or even could be automatically generated" was made by "model-driven something". The idea behind that gets reinvented often. The latest one is called No-Code or Low-Code.
I never understood the appeal of UML. Hardware design had been done almost entirely by schematics, but then in the mid 90s HDLs (Hardware Description Languages) and logic synthesis offered increased productivity for hardware designers. Now other than very highlevel block diagrams hardware design is almost completely textual. UML seemed like schematics for software and a step backward.
Completely agreed. As for why the code is the blue print - good code design requires the ability to switch between high level details (how do I structure these high-level components of the system) and super low level details (e.g. the application of a particular algorithm to a certain problem, or the various hacks and workarounds one often has to write when dealing with certain third party systems). The lower level details simply cannot be extrapolated from a high level structure.
I remember "Booch Blobs." The original system diagrammer was Grady Booch, and he used these little "clouds." I think Rational Ro$e used them. He ended up throwing in with Ivar Jacobsen, and they came up with UML (which Jacobsen started). More boring, but also more practical.
The funny thing (having lived through that time) was that while it was very trendy to pretend that construction was not a giant disaster most of the time from a planning, delay, cost overruns, etc. perspective - it was pretty clearly not the case even then if we’d looked even a little!
Like many things, the big promise was a fad, but we learned some valuable things out of all of it, and some still survive.
Software Engineering is a licensed profession in several countries.
In Portugal I cannot sign a legally bound countract with Eng. SoAndSo withouth having been licensed to do so.
Naturally plenty of people without such duties never do the final exam, however the universities where they studied had to be certified by enginnering order anyway.
> But as it turned out, that was a false premise. The real blueprints for software ended up being the code itself. And the legacy of UML lives on in simpler boxes and arrow diagrams.
IMO the bad rap UML gets is undeserved. The value of a detailed design in UML may be limited. But high level design elements like use case diagrams, sequence diagrams, activity diagrams - these are super useful.
Simpler "boxes and arrow diagrams" are fine but it's nice to have some consistency in the visual representation of these elements.
> It was developed during a time when there was a push to make Software Engineering a licensed profession
Regardless of the merits (or lack thereof) of the original push, I do want to see greater accountability and oversight of safety-critical systems and related, such as IoT systems - the idea of having a licensed/chartered engineer having to sign-off on a project (and so putting their personal professional reputation at stake) is something I support in the aftermath of things like Boeing's MCAS snafus - or the problems with Fujitsu's "Horizon" system - and so on.
I don't want occupational gatekeeping like we see with the AMA and the trope of licensed nail parlours, but we need to learn from how other engineering professions, like civil-engineering and aviation engineering, have all instituted a formal and legally-recognized sign-off process which I feel is sorely lacking in the entire software engineering industry.
The challenge is that when you're making enough detailed design ahead, you are back to waterfall so it's not really compatible with the agile methods of today.
I'm kind of missing something opposite. A tool that can draw a diagram out of the code, that by dropping some details but preserving important stuff like what objects travel through which fuctions, can give you better understanding of what architecture in your program/system do you actually have.
Because it might be different from the architecture you think you have and some bugs or opportunitues for improvement might be more easily spotted through this different lens.
It seems fundamentally obvious to me that this line of thinking is bogus. If you move enough of the complexity to UML diagrams of course the code will be simpler - because all the complexity is now in the UML diagrams.
That doesn't make the complexity go away, you have to do just as much work writing UML diagrams as you did writing code before, but now you're expressing your complexity in cumbersome visual designers rather than code.
If you're going to shift business logic/data from code to any other format you need to demonstrate that that other format is somehow better for representing that information, you can't just pretend that because it's not expressed in code any more you've gotten rid of it.
Indeed. The problem is not with the diagrams, so much, as with the requirement for people to draw them. The code is the source of truth and the only true representation of the program.
There is value in diagrams - but that value is highest when the diagrams are derived directly from code. That is why I am making https://appland.com/docs - get the benefit of interactive code diagrams, generated automatically from executing code (not just static analysis, which is too weak to handle the dynamic behavior of modern frameworks).
I use it exclusively during refactoring to try and spot coupling, or to figure out somebody else’s code with a sequence diagram. It’s handy for that. It would be weird to use it for up-front design but I guess you could
this is what I do... I have a UML document that describes the database schema and instead of autogenerating it, I run a compile-time check to verify that the UML is in sync with the schema.
Honestly, UML would have been awesome for backend architecture. Most backend architecture I see are logos next to boxes connected by arrows, which is fine for high-level but extremely difficult to automate
Part of the reason for this is that until you get to larger system components, changing the code is relatively cheap, so there's less need for a formal design.
wow, that is perfectly worded. In 2001 I spent a great deal of time making these UML diagrams for my boss. I didn't understand what this had to do with writing code. I hated it. Tried to argue it was pointless, lets just skip these and start writing code... and there was crickets
added:As an old person, there's no point in listening to me though. From where I sit, the main improvement over the last 40 years has been the widespread adoption of third party libraries. You'd be surprised at the things that had to be written from scratch. ...I just thought of another difference over time, the population of programming hobbyists who became professionals. It would kill me to write software for free.
The reason we stopped with UML and other front heavy planning methodologies is that what we planned was always wrong.
Software projects always used to go massively over budget, were delivered late, and usually didn't meet the customers requirements anyway.
It turns out that customers don't know what they want, or at least can't articulate it properly to business analysts.
By delivering early and often, we're not only releasing value to our customers early and often but we're getting feedback, allowing us and the customers to go on a journey of understanding their needs.
Also, it turns out that engineering teams know better how to develop a piece of software than architects.
We solve the complexity problems by breaking a project down into (as he says) "pizza team" size components and focus on defining the interfaces between those components, rather than go into the weeds of how information flows within the code. This leads to other complexities, of course, but they don't lead to the same sort of delivery problems that large, monolithic designs have.
All in all, a switch away from a design heavy approach has improved delivery, value to our customers, and enabled staff to be more productive.
I think the type of software that is being written has changed over time. In the past, companies had to write complete software that would be shipped on a CD - you cannot deliver an incomplete product and then change it later. Nowadays, majority of the software lives online and can be redeployed in a short time. Delivering early and often is possible now, but it wasn't in the past for majority of the projects.
Exactly this. You never know your problem domain as well as you think you do.
I always try to start a new project assuming everything could change. Paradoxically, this approach tends to produce the same net result as assuming nothing will change. If you have no idea how requirements will evolve over time, there's no point guessing. Just write the code needed for the first batch of requirements, and nothing else.
It is orders of magnitude easier to add a layer of abstraction to a simple system when new requirements demand it vs. remove a layer of abstraction later when you finally realize you don't need it. The latter is often impossible.
But what was perhaps lost along the way was communicating inner workings through something else than code.
I think UML and its likes still have immense value between developers and teams to communicate complex processes in a way that is easy to understand at a glance and facilitate shared understanding.
UML suffers from false precision. Nobody cares about most of the specific rules and grammar of the language because the output is designed to be generally readable by a lay audience. The time your spend making your diagram compliant with UML is better spent making and remaking good general diagrams.
Good riddance. UML is part of the infinite-complexity infinitely-layered culture around the Java language in the late 90's and early 00's. Where OO-supremacist "system architects" were trying to split software development into the first-class flying, conference-attending chosen few who could do modelling, and the unwashed masses who were to be replaceable, underpaid, be-glad-you-earn-more-than-minimum-wage outsourced code monkeys.
The UML specification is 796 pages[0]. It is amazing how humanity can take simple concepts like flow charts and inflate them into insane, hyper detailed legalistic rule books that almost no one understands or uses.
UML really died because modern software development is less like designing an aircraft than it is a research program to design a new kind of aircraft. To the programmer, the plafroms they are going to build on are so vast and complicated, that their behaviour is not fully known to the programmer. So to design a specific application, the programmer has to performa series of experiments on the platform to determine the manner in which it will have to be used to support the objectives of the application. When those experiments are complete, the programmer can then spend some time in design, but for the most part programming-in-the small is akin to conducting research and then doing a little desing. For large systems, someone has to do design, but the best way of doing such design is through whitepapers, and large scale experiments and possibly simulations and analysis. UML isn't particularly useful, beyond establishing a common vocabulary for diagrams -- a task that can be done more simply and informally.
I don't know about the rest of it, but sequence diagrams are alive and well and are basically in pretty much every design doc I write and read.
They are very very useful for letting people quickly gain a shared understanding for what a system is supposed to do (at a high level). They are extremely beneficial IME.
If you are designing a system and need other people to understand key parts of how it all hangs together (e.g. during review or implementation or maintenance) , and you are not using sequence diagrams, I'd urge you to strongly consider doing so.
In my experience, any attempt to describe/document/plan a system using UML inevitably turns into an outdated mess that no one is willing to waste time on updating. Eventually it becomes worse than useless since it contains objectively wrong information.
My personal experience is that system-level architecture diagrams are useful (i.e. which service/application talks to which service/database/message queue etc.) but code/class level ones are not. As to why - because the code tends to change a lot more often compared with the overall architecture of a platform. Requirements change (or requirements become better understood), code is refactored once the engineers get a better feel for the structure they are solving, new tools come along, etc. Code level diagrams have a habit of going out of date quickly, or (even worse) discouraging people from making useful changes based on new information.
To me, it seems that in their rush to criticize agile, the author failed to consider _why_ agile-like practices killed off UML.
I used to develop next-gen high-end OO CASE tools, and am big into systems analysis/design/etc., visual thinking and communication, etc.
A few random comments, on latest impressions of UML, while trying to get something done last week, but not a rigorous look UML...
I happened to skim parts of the UML spec (796-page PDF) last Thursday/Friday, having not seen UML in a while.
I appreciate all the goodness from various methodologists that was incorporated into UML. And, especially as a tools developer, I also appreciate the semi-formal metamodels, which have a few key uses, most of them for tools developers.
Unfortunately, the particular UML features I needed last Thu/Fri (for a cross-org high-level process&architecture model) didn't seem to be supported sufficiently well (or at all) by any of the first half-dozen UML tools I tried. (I tried open source, and then lightweight Web SaaS. People generally do that, maybe more SaaS first, and want to get started rapidly. I'm not going to casually install a huge closed CASE platform, without checking the SaaSes and open source.)
By Friday afternoon, finding all these tools hindered more than they helped, I said "fiddlesticks this barrier situation", and decided to just use our GSuite Draw. Although, on the surface, it appears to be pretty much 1980s shared-whiteboard simple drawing CSCW (with a little 1990 Visio diagramming innovations), I was able to express enough of what I needed without too much effort, and I was even able to reason from the diagram a little as I was manipulating it.
To make GSuite Draw viable for my immediate purpose of starting to work through a model, I did have to use a metamodel and notation that was easier to draw without special tool support, but it worked for this particular model.
I'd still use a specialized UML tool for the most familiar Rumbaugh-ian static object modeling. And, if the tool supported them well, I'd also use for Harel state modeling, maybe event traces, maybe Jacobson use case modeling, and some other UML ones (e.g., Activity Diagrams, especially with the object flows, not just flowchart control flows).
I wouldn't generalize much last week's experience, to adoption by developers in general, since I'm a fringe person who knows specific metamodel features that exist, which I want to select for a particular need -- rather than being a new person dropped in front of a particular kind of UML diagram, and told to start expressing my system in whatever terms it gives me.
I haven't done a rigorous survey of current method&tool practice and offerings, but I'm starting to form a suspicion that adoption and execution challenges for UML-ish things today are very similar to what they were 20 years ago. The markets certainly seem to have changed in some ways, but even some of those ways (e.g., more widespread framework reuse), were already being talked about for modeling 20 years ago.
UML is closely associated with Object Oriented programming. In the 2000s, OO programming was all the rage, and having a mental notebook of “design patterns” was considered the hallmark of a real software engineer.
Since then, OO has lost a lot of its luster, the languages most associated with it like Java and C++ are considered somewhat clunky and uncool. Functional programming took over as the “smart” paradigm to talk about, even if in practice most popular programming languages borrow a mix of imperative, OO, and functional features.
UML was also popular in a time when you could make a SQL database and just use that. The introduction of more database varieties complicates things.
Besides OO, UML was also strongly associated with “visual” programming done by non programmers. This paradigm is doomed to be reinvented and pushed as the next big thing every 3 years until eternity, which we currently see with whatever the latest no code trend is, but in the 2000s was associated with UML.
Finally, language independent data formats like JSON, Thrift, and protobufs got popular. Why make a UML diagram when I can just make the actual data structures then immediately have that as a binary format?
To the extent UML means “data modeling”, people still do that. But it became associate with a lot of cultural baggage, and most of that baggage was on the losing end of a lot of technology mindshare battles.
I don't agree with the posting. In my opinion, UML had rebirth in 2010s with the growth of popularity of PlantUML. See that PlantUML is referenced already in this thread, and to positive sentiments already expressed, I can add the notion that PlantUML fits much better, than most of earlier UML related software, for the purpose of network modelling. While original UML standard was not specifically designed for representing networks, PlantUML has network diagram type built-in. And extensibility of PlantUML allows to cover many use-cases beyond that. I imagine that with a certain amount of tenacity applied, it would be possible to create PlantUML library for "masala diagrams" as well.
Also, "agile" shops usually love that tool, since it requires minimal learning curve for any person on a team to start producing nice-looking diagrams.
You sketch out simple diagrams of major modules and how they interact.
That gives an understanding of what goes where and how things interact at high level.
You dont detail each function/attribute/call/... you'd go insane and it would be useless / you'd lose your readers time. (If they want this level of detail they can check the code)
It's also useful when doing new big features where you need approval/feedback/advice. One simple class like diagram to show how you structured your code is generally useful for people you present it to to understand what you want. Some use cases like sequence diagrams are also useful. Then you detail out further in whatever is agreed in the company.
Sometimes its useful to describe flows for really complicated bugs with a sketch like sequence diagrams to make sure you undetstand and found actual root cause and to show that.
There's quite a lot of hate in the comments for UML is seems. And while a lot of it is quite valid, I have to say that sometimes I miss _some_ of what UML could do, especially in form of documentation. Sometimes a simple sequence diagram is able to communicate the behavior of a system much clearer than 10's of pages of disjointed prose... Just my opinion.
In my view one of the biggest problems of UML was that it's ugly and not very intuitive. For a while I jumped on the UML bandwagon and developed a lot of diagrams of the various types. Turned out that even very experienced developers didn't understand them not even to mention less technical people.
Now I just draw a few boxes with arrows and usually get the message across.
UML as code generator also made for really neat demos but in practice the diagrams for complex systems were harder to read than the code.
If I had one wish it would be nice if there was a standard for embedding and editing diagrams in different software like Word or Powerpoint or the web. It seems you always end up copying/pasting stuff while often losing the original after a while.
I like the concept of 'Masala diagrams' that OP introduces - I've drawn these a lot, and the UML-trained part of me is always slightly uneasy that I'm combining (say) data and process flow on the same diagram, or that some of my boxes are physical machines and some are programs, etc. But the thing is, you shape your masala diagram to communicate whatever the thing is you want to communicate. You'd need 3 or 4 UML diagrams to cover the same thing, and no-one would really care that you'd bothered to keep to the conventions.
[+] [-] jdlyga|4 years ago|reply
[+] [-] hintymad|4 years ago|reply
P.S., It's surprising that those who advocate that UML is better than code didn't understand the essential complexity would not go away simply because we switched a language, as essential complexity lies in precisely specifying a system. Neither did they understand that that a programming language offers more powerful constructs and tools to manage complexity compared with UML.
[+] [-] mavelikara|4 years ago|reply
> UML was going to be the "blueprints" of code, and software architects would develop UML diagrams similar to how building architects create blueprints for houses. But as it turned out, that was a false premise.
True. The blueprint is the code. The brick and mortar construction is done by compilers.
[+] [-] throwawayboise|4 years ago|reply
It was possible to get it to generate code, as I recall it basically gave you stubs of classes and methods and you would then go and code the implementation of each method.
It seemed like it could save you some amount of effort at basic boilerplate stuff but at the cost of putting the same or more effort into the UML.
UML was the swan song of the classic waterfall SDLC gang. Agile and TDD came along and nobody looked back.
[+] [-] agumonkey|4 years ago|reply
The model driven thing was nice but it was never good enough to actually help with code. It was also deeply rooted in the crippled Java days so full of verbose diagram representing overly verbose classes.
To hyperbole a bit, I'd rather spend time writing property based tests and a few types in haskell in a way.
[+] [-] bccdee|4 years ago|reply
I don't want to have to search "what does double arrow mean UML" in order to understand a proposal. I don't want an arrow to mean something that I couldn't learn somewhere else. I'd rather have a loose informal reference diagram alongside a couple paragraphs describing the system more formally. That way, the important information can be emphasized, the unnecessary information can be glossed over, and the diagram acts as a big-picture aide rather than some kind of formal semantic notation.
[+] [-] Buttons840|4 years ago|reply
[+] [-] qznc|4 years ago|reply
The promise "that with detailed enough diagrams, writing code would be trivial or even could be automatically generated" was made by "model-driven something". The idea behind that gets reinvented often. The latest one is called No-Code or Low-Code.
[+] [-] UncleOxidant|4 years ago|reply
[+] [-] ch_123|4 years ago|reply
[+] [-] ChrisMarshallNY|4 years ago|reply
I use "pseudo-UML," as a "quick and dirty" diagrammer, but only when I want to do things like this: https://littlegreenviper.com/miscellany/swiftwater/the-curio...
I don't bother with the "official" definitions of UML. I kinda make it up as I go along.
[+] [-] lazide|4 years ago|reply
Like many things, the big promise was a fad, but we learned some valuable things out of all of it, and some still survive.
[+] [-] pjmlp|4 years ago|reply
In Portugal I cannot sign a legally bound countract with Eng. SoAndSo withouth having been licensed to do so.
Naturally plenty of people without such duties never do the final exam, however the universities where they studied had to be certified by enginnering order anyway.
[+] [-] wyldfire|4 years ago|reply
IMO the bad rap UML gets is undeserved. The value of a detailed design in UML may be limited. But high level design elements like use case diagrams, sequence diagrams, activity diagrams - these are super useful.
Simpler "boxes and arrow diagrams" are fine but it's nice to have some consistency in the visual representation of these elements.
[+] [-] DaiPlusPlus|4 years ago|reply
Regardless of the merits (or lack thereof) of the original push, I do want to see greater accountability and oversight of safety-critical systems and related, such as IoT systems - the idea of having a licensed/chartered engineer having to sign-off on a project (and so putting their personal professional reputation at stake) is something I support in the aftermath of things like Boeing's MCAS snafus - or the problems with Fujitsu's "Horizon" system - and so on.
I don't want occupational gatekeeping like we see with the AMA and the trope of licensed nail parlours, but we need to learn from how other engineering professions, like civil-engineering and aviation engineering, have all instituted a formal and legally-recognized sign-off process which I feel is sorely lacking in the entire software engineering industry.
[+] [-] segmondy|4 years ago|reply
[+] [-] scotty79|4 years ago|reply
Because it might be different from the architecture you think you have and some bugs or opportunitues for improvement might be more easily spotted through this different lens.
[+] [-] p1necone|4 years ago|reply
That doesn't make the complexity go away, you have to do just as much work writing UML diagrams as you did writing code before, but now you're expressing your complexity in cumbersome visual designers rather than code.
If you're going to shift business logic/data from code to any other format you need to demonstrate that that other format is somehow better for representing that information, you can't just pretend that because it's not expressed in code any more you've gotten rid of it.
[+] [-] professoretc|4 years ago|reply
Ironically, a lot of documentation systems now do the opposite: take your code and produce UML diagrams from it.
[+] [-] kgilpin|4 years ago|reply
There is value in diagrams - but that value is highest when the diagrams are derived directly from code. That is why I am making https://appland.com/docs - get the benefit of interactive code diagrams, generated automatically from executing code (not just static analysis, which is too weak to handle the dynamic behavior of modern frameworks).
[+] [-] gentleman11|4 years ago|reply
[+] [-] ryanmarsh|4 years ago|reply
I couldn’t have summarized it better than you just did. Thank you.
[+] [-] dnautics|4 years ago|reply
[+] [-] nunez|4 years ago|reply
[+] [-] dehrmann|4 years ago|reply
[+] [-] andrewfromx|4 years ago|reply
[+] [-] kingsuper20|4 years ago|reply
Here's one that enabled some people to work a rich vein for a while.
https://en.wikipedia.org/wiki/Shlaer-Mellor_method
added:As an old person, there's no point in listening to me though. From where I sit, the main improvement over the last 40 years has been the widespread adoption of third party libraries. You'd be surprised at the things that had to be written from scratch. ...I just thought of another difference over time, the population of programming hobbyists who became professionals. It would kill me to write software for free.
[+] [-] disordinary|4 years ago|reply
Software projects always used to go massively over budget, were delivered late, and usually didn't meet the customers requirements anyway.
It turns out that customers don't know what they want, or at least can't articulate it properly to business analysts.
By delivering early and often, we're not only releasing value to our customers early and often but we're getting feedback, allowing us and the customers to go on a journey of understanding their needs.
Also, it turns out that engineering teams know better how to develop a piece of software than architects.
We solve the complexity problems by breaking a project down into (as he says) "pizza team" size components and focus on defining the interfaces between those components, rather than go into the weeds of how information flows within the code. This leads to other complexities, of course, but they don't lead to the same sort of delivery problems that large, monolithic designs have.
All in all, a switch away from a design heavy approach has improved delivery, value to our customers, and enabled staff to be more productive.
[+] [-] FinanceAnon|4 years ago|reply
[+] [-] suzzer99|4 years ago|reply
I always try to start a new project assuming everything could change. Paradoxically, this approach tends to produce the same net result as assuming nothing will change. If you have no idea how requirements will evolve over time, there's no point guessing. Just write the code needed for the first batch of requirements, and nothing else.
It is orders of magnitude easier to add a layer of abstraction to a simple system when new requirements demand it vs. remove a layer of abstraction later when you finally realize you don't need it. The latter is often impossible.
[+] [-] Oddskar|4 years ago|reply
I think UML and its likes still have immense value between developers and teams to communicate complex processes in a way that is easy to understand at a glance and facilitate shared understanding.
[+] [-] emperorcezar|4 years ago|reply
I feel like this is still the case under "Agile"
[+] [-] darkerside|4 years ago|reply
[+] [-] zorked|4 years ago|reply
[+] [-] bryik|4 years ago|reply
0 - https://www.omg.org/spec/UML/2.5.1/PDF
[+] [-] azeirah|4 years ago|reply
[+] [-] sumanthvepa|4 years ago|reply
[+] [-] mattlondon|4 years ago|reply
They are very very useful for letting people quickly gain a shared understanding for what a system is supposed to do (at a high level). They are extremely beneficial IME.
If you are designing a system and need other people to understand key parts of how it all hangs together (e.g. during review or implementation or maintenance) , and you are not using sequence diagrams, I'd urge you to strongly consider doing so.
[+] [-] ncann|4 years ago|reply
[+] [-] ch_123|4 years ago|reply
To me, it seems that in their rush to criticize agile, the author failed to consider _why_ agile-like practices killed off UML.
[+] [-] neilv|4 years ago|reply
A few random comments, on latest impressions of UML, while trying to get something done last week, but not a rigorous look UML...
I happened to skim parts of the UML spec (796-page PDF) last Thursday/Friday, having not seen UML in a while.
I appreciate all the goodness from various methodologists that was incorporated into UML. And, especially as a tools developer, I also appreciate the semi-formal metamodels, which have a few key uses, most of them for tools developers.
Unfortunately, the particular UML features I needed last Thu/Fri (for a cross-org high-level process&architecture model) didn't seem to be supported sufficiently well (or at all) by any of the first half-dozen UML tools I tried. (I tried open source, and then lightweight Web SaaS. People generally do that, maybe more SaaS first, and want to get started rapidly. I'm not going to casually install a huge closed CASE platform, without checking the SaaSes and open source.)
By Friday afternoon, finding all these tools hindered more than they helped, I said "fiddlesticks this barrier situation", and decided to just use our GSuite Draw. Although, on the surface, it appears to be pretty much 1980s shared-whiteboard simple drawing CSCW (with a little 1990 Visio diagramming innovations), I was able to express enough of what I needed without too much effort, and I was even able to reason from the diagram a little as I was manipulating it.
To make GSuite Draw viable for my immediate purpose of starting to work through a model, I did have to use a metamodel and notation that was easier to draw without special tool support, but it worked for this particular model.
I'd still use a specialized UML tool for the most familiar Rumbaugh-ian static object modeling. And, if the tool supported them well, I'd also use for Harel state modeling, maybe event traces, maybe Jacobson use case modeling, and some other UML ones (e.g., Activity Diagrams, especially with the object flows, not just flowchart control flows).
I wouldn't generalize much last week's experience, to adoption by developers in general, since I'm a fringe person who knows specific metamodel features that exist, which I want to select for a particular need -- rather than being a new person dropped in front of a particular kind of UML diagram, and told to start expressing my system in whatever terms it gives me.
I haven't done a rigorous survey of current method&tool practice and offerings, but I'm starting to form a suspicion that adoption and execution challenges for UML-ish things today are very similar to what they were 20 years ago. The markets certainly seem to have changed in some ways, but even some of those ways (e.g., more widespread framework reuse), were already being talked about for modeling 20 years ago.
[+] [-] haolez|4 years ago|reply
- Sequence Diagram: great for understanding distributed workflows
- State Diagram: state machines are wonderful tools and having a standard for representing them is a win, IMHO
- Parametric Diagram[0] (SysML): feels like Class Diagrams for functional programming
[0] https://sysml.org/sysml-faq/what-is-parametric-diagram.html
[+] [-] waprin|4 years ago|reply
Since then, OO has lost a lot of its luster, the languages most associated with it like Java and C++ are considered somewhat clunky and uncool. Functional programming took over as the “smart” paradigm to talk about, even if in practice most popular programming languages borrow a mix of imperative, OO, and functional features.
UML was also popular in a time when you could make a SQL database and just use that. The introduction of more database varieties complicates things.
Besides OO, UML was also strongly associated with “visual” programming done by non programmers. This paradigm is doomed to be reinvented and pushed as the next big thing every 3 years until eternity, which we currently see with whatever the latest no code trend is, but in the 2000s was associated with UML.
Finally, language independent data formats like JSON, Thrift, and protobufs got popular. Why make a UML diagram when I can just make the actual data structures then immediately have that as a binary format?
To the extent UML means “data modeling”, people still do that. But it became associate with a lot of cultural baggage, and most of that baggage was on the losing end of a lot of technology mindshare battles.
[+] [-] perfect_kiss|4 years ago|reply
[+] [-] adriancr|4 years ago|reply
You sketch out simple diagrams of major modules and how they interact.
That gives an understanding of what goes where and how things interact at high level.
You dont detail each function/attribute/call/... you'd go insane and it would be useless / you'd lose your readers time. (If they want this level of detail they can check the code)
It's also useful when doing new big features where you need approval/feedback/advice. One simple class like diagram to show how you structured your code is generally useful for people you present it to to understand what you want. Some use cases like sequence diagrams are also useful. Then you detail out further in whatever is agreed in the company.
Sometimes its useful to describe flows for really complicated bugs with a sketch like sequence diagrams to make sure you undetstand and found actual root cause and to show that.
[+] [-] seattle_spring|4 years ago|reply
[+] [-] rytis|4 years ago|reply
[+] [-] spaetzleesser|4 years ago|reply
Now I just draw a few boxes with arrows and usually get the message across.
UML as code generator also made for really neat demos but in practice the diagrams for complex systems were harder to read than the code.
If I had one wish it would be nice if there was a standard for embedding and editing diagrams in different software like Word or Powerpoint or the web. It seems you always end up copying/pasting stuff while often losing the original after a while.
[+] [-] thomasfl|4 years ago|reply
https://en.wikipedia.org/wiki/Sequence_diagram
[+] [-] codeulike|4 years ago|reply