7 ms·

I also find sequence diagrams to be the most useful, but disagree that the rest of UML is useless. Class, component, package, activity and state machine diagram

by imiric 3y ago

I also find sequence diagrams to be the most useful, but disagree that the rest of UML is useless. Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. So we saw no need for these visual design tools to model the entire system, since we ended up changing the design during the lifetime of the project anyway. The drawback of this, of course, is that with the Agile approach these diagrams never end up being made, so developers are left to assemble their own mental model of the system, which hurts the overall comprehension. Most developers IME actively reject these diagrams because they are quickly outdated, or require constant changes to keep up to date, which is true, but this is not unlike documentation, comments, and a myriad other things that needs to be synced with the code. Yet sequence diagrams are useful in a wide variety of use cases, and let's face it, they're the easiest ones to comprehend, and are even understandable by a non-technical audience. In contrast to the other UML diagram types that have strange notations and the information is more densely packed.

kazinator 3y ago
> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. I completely agree with you. It's a good way for other people to present information, for me to look at. I just won't do it myself. It's not only me; and that's why it's dead. I won't do it because the first thing that comes to mind is how it will go out of date in a month, and have to be maintained to stay accurate. Maybe in the not-too-distant future we will have AI grokking large code bases and cranking out accurate, useful, UML diagrams out of it. All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey.
- slowmovintarget 3y ago
  I'll draw those diagrams... on a whiteboard, sans boxes (Tufte). Great for point-in-time communication, less useful as specifications.
- lemmsjid 3y ago
  I've taken a throwaway approach to diagramming, where I'll produce them more or less on demand for a meeting or presentation, but not think of them as an enduring artifact. PlantUML is my friend here because I can knock out ugly but gets-the-point-across diagrams in 30 minutes before a meeting and check them into source control, so I can then take the bones of older diagrams and rework them for a fresh meeting. I used to whiteboard for this, but that hasn't carried over well in the remote world. What I miss about whiteboarding though is that you can tell a story as you draw, so whoever's viewing can watch something unfold from a blank slate while I'm walking them through the history of whatever system we're describing. That said, I can make a PlantUML diagram much more correct than a whiteboard. All that said I too would love for more of that to be automated increasingly through AI. And I suppose it should make sense conceptually, because for me the value of a crafted diagram over an automated one is that no one really wants to look at the insane ERD of an OLTP database or a production object model. They want the digestible high level vision of the important bits, or the bits that are relevant to the conversation taking place. So it's a summarization problem. How to get the right data to produce a correct summary is interesting--I'm sure if I look there's a dozen papers to read on a similar subject :).
  - 4lejandrito 3y ago
    For whiteboarding remotely I use https://excalidraw.com https://excalidraw.com. I use it exactly for your use case. I’ve told live stories with it.
    - theK 3y ago
      excalidraw is great especially the paid product. One of the cases of a very good open core business plan. I hope they do well.
      - lemmsjid 3y ago
        Thank you, I'm going to give that a try!
  - theK 3y ago
- agumonkey 3y ago
  surprisingly, for average crowds, who usually describe stuff in fluffy text, UML-like diagrams suddenly feel like going from VB5 to python3
- starlust2 3y ago
  > Maybe in the not-too-distant future we will have AI grokking large code bases and cranking out accurate, useful, UML diagrams out of it. > All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey. I spent a bit of time prototyping this recently. It's definitely possible. Rational Rose also had the capability to generate diagrams from code though. I don't remember how good it was at the task though. Was Rational Rose just a very bad implementation? I find the hate in this chat strange because diagrams are incredibly useful when working through complex problems* and then conveying that information to other engineers. My experience over 20+ years is that a huge portion of engineers can't grok complex problems from code alone. *Most of my projects are optimizing billion+ row databases, micro-service architectures, and various other scaling challenges.
  - bluGill 3y ago
    The problem isn't generating UML from code, the problem is generating useful UML from code. Where those boxes are in relation to each other matters. You can't just randomly throw boxes and lines on the page, you need to arrange them so that boxes that we can tell what things are related by how close they are to each other. Automatic UML doesn't capture that. Sometime you have complexity in code that needs tobe hidden by default. I don't care about rare error cases most of the time, but automatic UML can't know what is the complexity needed for rare cases and what is complexity you need to show the junior on the first day.. related to this when i'm interested in one error path how do you hide the others? Then the real killer of both. Next week there is a minor requirement change (new features we always knew were coming and planned for even), and now the code changed. UML doesn't follow that. Either you generate UML and have the above problems. Or you manually update UML in theory, but in practice just let it slide as the week after you know something else will change and you don't nees it today anyway.
    - imiric 3y ago
      > Or you manually update UML in theory, but in practice just let it slide as the week after you know something else will change and you don't nees it today anyway. I've heard this argument many times, but how is it different from keeping documentation, comments, tests, or the issue tracker up to date? They all require some discipline, but if the team finds value in any of these things, they would make an effort to keep them synchronized with the code. Besides, I suggest not falling in the trap of having formal design documents early on in the project's lifetime. Rather start with informal diagrams and sketches, and once the design has mostly settled, switch to something like UML. This would mean it wouldn't require changes every other week. As for automatically generating, and dynamically arranging diagrams, this is more up to the generating tool than UML. These tools are still stuck using decades old technology at this point AFAIA, but there's no reason that a smarter tool couldn't do the things you mention.
- ngc248 3y ago
  True, though nowadays I use PlantUML (https://plantuml.com/ https://plantuml.com/) which is a DSL using which we can create all kinds of UML diagrams. If any changes are to be made I just need to make the incremental changes using the DSL and regenerate the images. It has been very helpful.
cubefox 3y ago
People who say "UML is useless" basically say "diagrams are useless". Which obviously isn't true. The alternative to UML is everyone inventing their own "diagram language" when they want to visualize something. Moreover, I think comparing different UML diagrams can also be enlightening for university students. E.g. state machine digrams look quite similar to activity diagrams, but the former emphasize states and the latter actions. And class diagrams let you learn the connection between class structures of OOP languages and database structures. UML lets you visually learn the abstract higher level concepts without having to rely on irrelevant specifics of practical implementations, or just on dry theoretical text.
- auggierose 3y ago
  The nice thing about visual stuff is that it is self-explanatory. Instead of needing to read a book about UML first, maybe just use some prose in addition to your diagrams, and you don't need UML at all then. That's also more flexibel.
  - bigbillheck 3y ago
    > it is self-explanatory It most certainly is not.
    - deleted 3y ago
      [deleted]
- IshKebab 3y ago
  > everyone inventing their own "diagram language" This is clearly better than UML. UML is full of shorthands that nobody remembers. That's worse than people making labelled custom diagrams. Here's an example: https://buck2.build/docs/concepts/concept_map/ https://buck2.build/docs/concepts/concept_map/ Imagine how much worse that would be with UML arrows.
  - cubefox 3y ago
    That concept map example is only a loose association of ideas, where the nodes aren't of the same type (e.g. event, state, class etc), or sorted into types, and apparently included quite arbitrarily. Mind maps are similarly loose. UML is for when you want more precise diagrams about a fixed subject matter. I agree on the "shorthands", like empty/filled arrows, that people may not know. But there isn't much alternative to such shorthands other than leaving them out completely, which wouldn't be an advantage. In diagrams some information is either conveyed succinctly or not at all. The "alternative" is a block of text instead of a diagram.
Kwpolska 3y ago
Class diagrams feel pointless to me, this information works better as code, and how do you draw a class diagram with more than 10 classes and keep it readable?
- prepend 3y ago
  I think class diagrams are a good way to visually display classes and hierarchy. If I have a package or module that has 10 classes and I want to show inheritance, properties, and methods I think it’s easier to show the class diagram then hand someone 10+ source files. Also, class diagrams are more useful when you can’t give out source. That being said, I think you can autogenerate class diagrams from code so it’s not like you should spend a lot of time making them.
- johannes1234321 3y ago
  If you use class diagrams to show the "truth" you are in painland in my experience. However I sometimes find them useful to extract key parts of the system and showing their interaction. Cutting away many attributes, many helper classes, many other things. That can lead to pictures which are quick to grasp and then allow further digging based on code.
- holoduke 3y ago
  Maybe before you actually start writing code its nice to create some domain diagrams which you can convert to class diagrams. Saves a ton of time. And you have good discussions about the general high level workings of an architecture. Can be done on a whiteboard. Make some pics and start coding.
  - radicalbyte 3y ago
    Assuming that you're using a modern IDE: it is an order of magnitude quicker to model the domain (classes + attributes) in code and project them as diagrams, say with graphvis. High level boxes are great for thinking about systems but the key there is abstraction - minimal viable level of detail..
    - 3y ago
lesuorac 3y ago
> The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. I dunno, whenever I heard people say they're doing Agile all I see is them doing Waterfall without documentation.
- bluGill 3y ago
  How is that worse than waterfall with outdated documentation which is what we had before.
  - sfn42 3y ago
    "we are lazy assholes who can't keep docs up to date, therefore docs are useless" Is essentially the argument i see over and over again. And every time i start a new project and that project has docs or uml or whatever I appreciate it. Even if it is a bit out of date, it's way better than nothing. In my opinion, every project should have a readme file with instructions for running the project locally, and ideally also a high level visual representation of the system. It should be separated into sub systems/modules for separate functionality and each module could have it's own set of readme and high level visuals. In addition, modules should have small coupling points, typically interfaces and these should have documentation comments describing what they do, inputs, outputs etc. APIs should have something like a swagger doc.
    - hitchstory 3y ago
      It's not a question of laziness. People just need to use better tools to generate docs and fail CI if the implementation and docs diverge. I used to hear people say the same thing about laziness about code style before reformatting/linting tools became standard.
      - sfn42 3y ago
        > It's not a question of laziness, it's just that people don't do it so you need automated tools to do it for them Sounds a lot like laziness to me. It may be more accurate to say it's because people don't care. I've seen projects full of typos. Ive seen projects where basically everything had been duplicated not once but twice because they wanted a slightly different version of the same website so instead of adding some configuration or otherwise finding a reasonable solution for it they just went and copied hundreds of files and prefixed their names before making a couple minor changes and leaving the mess for someone else to discover. No mention anywhere of the fact that this had been done, nor why. These are the actions of people who don't give a shit. Whatever problems they create are someone else's problems. The way i see it, if you care about your work you'll make sure the code is readable, well documented and so on. If you don't, you won't.
johnyzee 3y ago
> Most developers IME actively reject these diagrams because they are quickly outdated, or require constant changes to keep up to date Plans are useless, but planning is indispensable. The act of diagramming things up front is useful to get you thinking about the problem space and come up with the outline of a solution. After that, keeping the initial design documents up-to-date is optional, and often might not be necessary.
- imiric 3y ago
  I think about it the other way around, actually. During the prototyping phase diagrams do help, but they're usually sketches written on paper or whiteboard. You don't want to waste time with tools and strict specifications to design perfect diagrams, mostly because the design will change frequently, and you don't want your tools getting in the way. Later on, once the design has settled down and maybe once development has started, those initial diagrams are mostly worthless, but you _do_ want neat and professionally done design documents that describe the system. This allows you to share them with coworkers, and quickly onboard other developers to the project. Hopefully by then the design won't change frequently, which would make updating these a chore.
codalan 3y ago
UML was (and still is) really useful when embarking on a greenfield design. Most people I've worked with know some basic UML notation, so when it comes to whiteboarding and refining the design, it makes sense to go with that. In terms of artifacts for future maintainers? Maybe not as helpful. As previous posters have mentioned, the diagrams go stale very quickly if the engineering department isn't disciplined about keeping documentation up to date. But this is true for any documentation. Some diagrams (class and activity, in particular) are less valuable as time passes. I can get the idea of the class structure by just looking at the code itself. The class diagram just ends up being a stale representation of the code. It is unfortunate that UML has developed a reputation as being overly complex. Now I see more ad-hoc diagrams being created, with whatever notation/symbols make sense to author, rather than using a common diagram system that can be read by many.
jameshart 3y ago
Sequence diagrams are the only bit of UML that also applies to distributed systems. And everything today is a distributed system.
agumonkey 3y ago
to me seq diagrams are .. too sequential, my brain needs a protocol / graph proof like formalism to see things more globally.
BerislavLopac 3y ago
> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually They're not bad, but the C4 model is a much better approach to high level modelling (while you can still use class diagrams on the lowest level). https://c4model.com/ https://c4model.com/
phoehne 3y ago
We also moved to framework heavy development where you write classes that plug into frameworks. So a POJO here and a POJO there… (everywhere a POJO) that are managed by a framework and exist only to extend the framework are marginally useful. A UML class diagram for a Spring Batch transformer that’s cobbled together from an existing CSV reader component, just isn’t that interesting or necessary.
Vox_Leone 3y ago
Maybe UML can find a new life with ChatGPT. Maybe it can fulfill the promise of generating code out of diagrams. UML seems like a fine way to organize prompts.
- kmerroll 3y ago
  Excellent comment and while maybe not UML, something like it is likely to emerge for exactly that purpose.
collyw 3y ago
Does anyone else find the agile way of doing things just ends up with lots of increments and no big picture of how the system should be or where it should be going? There also seems to be a with with waterfall that it's a one way process and you can't do iterations.
rewmie 3y ago
> The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. So we saw no need for these visual design tools to model the entire system, since we ended up changing the design during the lifetime of the project anyway. It wasn't also visual design tools that Agile killed. Agile killed design documentation altogether. With Agile, today's problems are addressed on tomorrow's sprint, and changes in software architecture take place only in the code. Any effort to document the system architecture in any remotely rigorous way is quickly deprecated, and teams simply don't waste time maintaining something that might already be deprecated once they finish editing the document.

by imiric 3y ago

kazinator 3y ago

> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually. I completely agree with you. It's a good way for other people to present information, for me to look at. I just won't do it myself. It's not only me; and that's why it's dead. I won't do it because the first thing that comes to mind is how it will go out of date in a month, and have to be maintained to stay accurate. Maybe in the not-too-distant future we will have AI grokking large code bases and cranking out accurate, useful, UML diagrams out of it. All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey.

slowmovintarget 3y ago
I'll draw those diagrams... on a whiteboard, sans boxes (Tufte). Great for point-in-time communication, less useful as specifications.
lemmsjid 3y ago
I've taken a throwaway approach to diagramming, where I'll produce them more or less on demand for a meeting or presentation, but not think of them as an enduring artifact. PlantUML is my friend here because I can knock out ugly but gets-the-point-across diagrams in 30 minutes before a meeting and check them into source control, so I can then take the bones of older diagrams and rework them for a fresh meeting. I used to whiteboard for this, but that hasn't carried over well in the remote world. What I miss about whiteboarding though is that you can tell a story as you draw, so whoever's viewing can watch something unfold from a blank slate while I'm walking them through the history of whatever system we're describing. That said, I can make a PlantUML diagram much more correct than a whiteboard. All that said I too would love for more of that to be automated increasingly through AI. And I suppose it should make sense conceptually, because for me the value of a crafted diagram over an automated one is that no one really wants to look at the insane ERD of an OLTP database or a production object model. They want the digestible high level vision of the important bits, or the bits that are relevant to the conversation taking place. So it's a summarization problem. How to get the right data to produce a correct summary is interesting--I'm sure if I look there's a dozen papers to read on a similar subject :).
- 4lejandrito 3y ago
  For whiteboarding remotely I use https://excalidraw.com https://excalidraw.com. I use it exactly for your use case. I’ve told live stories with it.
  - theK 3y ago
    excalidraw is great especially the paid product. One of the cases of a very good open core business plan. I hope they do well.
    - lemmsjid 3y ago
      Thank you, I'm going to give that a try!
- theK 3y ago
agumonkey 3y ago
surprisingly, for average crowds, who usually describe stuff in fluffy text, UML-like diagrams suddenly feel like going from VB5 to python3
starlust2 3y ago
> Maybe in the not-too-distant future we will have AI grokking large code bases and cranking out accurate, useful, UML diagrams out of it. > All those diagrams, when they are complete, correct and up-to-date, do convey what they are supposed to convey. I spent a bit of time prototyping this recently. It's definitely possible. Rational Rose also had the capability to generate diagrams from code though. I don't remember how good it was at the task though. Was Rational Rose just a very bad implementation? I find the hate in this chat strange because diagrams are incredibly useful when working through complex problems* and then conveying that information to other engineers. My experience over 20+ years is that a huge portion of engineers can't grok complex problems from code alone. *Most of my projects are optimizing billion+ row databases, micro-service architectures, and various other scaling challenges.
- bluGill 3y ago
  The problem isn't generating UML from code, the problem is generating useful UML from code. Where those boxes are in relation to each other matters. You can't just randomly throw boxes and lines on the page, you need to arrange them so that boxes that we can tell what things are related by how close they are to each other. Automatic UML doesn't capture that. Sometime you have complexity in code that needs tobe hidden by default. I don't care about rare error cases most of the time, but automatic UML can't know what is the complexity needed for rare cases and what is complexity you need to show the junior on the first day.. related to this when i'm interested in one error path how do you hide the others? Then the real killer of both. Next week there is a minor requirement change (new features we always knew were coming and planned for even), and now the code changed. UML doesn't follow that. Either you generate UML and have the above problems. Or you manually update UML in theory, but in practice just let it slide as the week after you know something else will change and you don't nees it today anyway.
  - imiric 3y ago
    > Or you manually update UML in theory, but in practice just let it slide as the week after you know something else will change and you don't nees it today anyway. I've heard this argument many times, but how is it different from keeping documentation, comments, tests, or the issue tracker up to date? They all require some discipline, but if the team finds value in any of these things, they would make an effort to keep them synchronized with the code. Besides, I suggest not falling in the trap of having formal design documents early on in the project's lifetime. Rather start with informal diagrams and sketches, and once the design has mostly settled, switch to something like UML. This would mean it wouldn't require changes every other week. As for automatically generating, and dynamically arranging diagrams, this is more up to the generating tool than UML. These tools are still stuck using decades old technology at this point AFAIA, but there's no reason that a smarter tool couldn't do the things you mention.
ngc248 3y ago
True, though nowadays I use PlantUML (https://plantuml.com/ https://plantuml.com/) which is a DSL using which we can create all kinds of UML diagrams. If any changes are to be made I just need to make the incremental changes using the DSL and regenerate the images. It has been very helpful.

cubefox 3y ago

People who say "UML is useless" basically say "diagrams are useless". Which obviously isn't true. The alternative to UML is everyone inventing their own "diagram language" when they want to visualize something. Moreover, I think comparing different UML diagrams can also be enlightening for university students. E.g. state machine digrams look quite similar to activity diagrams, but the former emphasize states and the latter actions. And class diagrams let you learn the connection between class structures of OOP languages and database structures. UML lets you visually learn the abstract higher level concepts without having to rely on irrelevant specifics of practical implementations, or just on dry theoretical text.

auggierose 3y ago
The nice thing about visual stuff is that it is self-explanatory. Instead of needing to read a book about UML first, maybe just use some prose in addition to your diagrams, and you don't need UML at all then. That's also more flexibel.
- bigbillheck 3y ago
  > it is self-explanatory It most certainly is not.
  - deleted 3y ago
    [deleted]
IshKebab 3y ago
> everyone inventing their own "diagram language" This is clearly better than UML. UML is full of shorthands that nobody remembers. That's worse than people making labelled custom diagrams. Here's an example: https://buck2.build/docs/concepts/concept_map/ https://buck2.build/docs/concepts/concept_map/ Imagine how much worse that would be with UML arrows.
- cubefox 3y ago
  That concept map example is only a loose association of ideas, where the nodes aren't of the same type (e.g. event, state, class etc), or sorted into types, and apparently included quite arbitrarily. Mind maps are similarly loose. UML is for when you want more precise diagrams about a fixed subject matter. I agree on the "shorthands", like empty/filled arrows, that people may not know. But there isn't much alternative to such shorthands other than leaving them out completely, which wouldn't be an advantage. In diagrams some information is either conveyed succinctly or not at all. The "alternative" is a block of text instead of a diagram.

Kwpolska 3y ago

Class diagrams feel pointless to me, this information works better as code, and how do you draw a class diagram with more than 10 classes and keep it readable?

prepend 3y ago
I think class diagrams are a good way to visually display classes and hierarchy. If I have a package or module that has 10 classes and I want to show inheritance, properties, and methods I think it’s easier to show the class diagram then hand someone 10+ source files. Also, class diagrams are more useful when you can’t give out source. That being said, I think you can autogenerate class diagrams from code so it’s not like you should spend a lot of time making them.
johannes1234321 3y ago
If you use class diagrams to show the "truth" you are in painland in my experience. However I sometimes find them useful to extract key parts of the system and showing their interaction. Cutting away many attributes, many helper classes, many other things. That can lead to pictures which are quick to grasp and then allow further digging based on code.
holoduke 3y ago
Maybe before you actually start writing code its nice to create some domain diagrams which you can convert to class diagrams. Saves a ton of time. And you have good discussions about the general high level workings of an architecture. Can be done on a whiteboard. Make some pics and start coding.
- radicalbyte 3y ago
  Assuming that you're using a modern IDE: it is an order of magnitude quicker to model the domain (classes + attributes) in code and project them as diagrams, say with graphvis. High level boxes are great for thinking about systems but the key there is abstraction - minimal viable level of detail..
  - 3y ago

lesuorac 3y ago

> The only reason the other diagram types fell out of favor is because of the development methodology change starting in the early 2000s. The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. I dunno, whenever I heard people say they're doing Agile all I see is them doing Waterfall without documentation.

bluGill 3y ago
How is that worse than waterfall with outdated documentation which is what we had before.
- sfn42 3y ago
  "we are lazy assholes who can't keep docs up to date, therefore docs are useless" Is essentially the argument i see over and over again. And every time i start a new project and that project has docs or uml or whatever I appreciate it. Even if it is a bit out of date, it's way better than nothing. In my opinion, every project should have a readme file with instructions for running the project locally, and ideally also a high level visual representation of the system. It should be separated into sub systems/modules for separate functionality and each module could have it's own set of readme and high level visuals. In addition, modules should have small coupling points, typically interfaces and these should have documentation comments describing what they do, inputs, outputs etc. APIs should have something like a swagger doc.
  - hitchstory 3y ago
    It's not a question of laziness. People just need to use better tools to generate docs and fail CI if the implementation and docs diverge. I used to hear people say the same thing about laziness about code style before reformatting/linting tools became standard.
    - sfn42 3y ago
      > It's not a question of laziness, it's just that people don't do it so you need automated tools to do it for them Sounds a lot like laziness to me. It may be more accurate to say it's because people don't care. I've seen projects full of typos. Ive seen projects where basically everything had been duplicated not once but twice because they wanted a slightly different version of the same website so instead of adding some configuration or otherwise finding a reasonable solution for it they just went and copied hundreds of files and prefixed their names before making a couple minor changes and leaving the mess for someone else to discover. No mention anywhere of the fact that this had been done, nor why. These are the actions of people who don't give a shit. Whatever problems they create are someone else's problems. The way i see it, if you care about your work you'll make sure the code is readable, well documented and so on. If you don't, you won't.

johnyzee 3y ago

> Most developers IME actively reject these diagrams because they are quickly outdated, or require constant changes to keep up to date Plans are useless, but planning is indispensable. The act of diagramming things up front is useful to get you thinking about the problem space and come up with the outline of a solution. After that, keeping the initial design documents up-to-date is optional, and often might not be necessary.

imiric 3y ago
I think about it the other way around, actually. During the prototyping phase diagrams do help, but they're usually sketches written on paper or whiteboard. You don't want to waste time with tools and strict specifications to design perfect diagrams, mostly because the design will change frequently, and you don't want your tools getting in the way. Later on, once the design has settled down and maybe once development has started, those initial diagrams are mostly worthless, but you _do_ want neat and professionally done design documents that describe the system. This allows you to share them with coworkers, and quickly onboard other developers to the project. Hopefully by then the design won't change frequently, which would make updating these a chore.

codalan 3y ago

UML was (and still is) really useful when embarking on a greenfield design. Most people I've worked with know some basic UML notation, so when it comes to whiteboarding and refining the design, it makes sense to go with that. In terms of artifacts for future maintainers? Maybe not as helpful. As previous posters have mentioned, the diagrams go stale very quickly if the engineering department isn't disciplined about keeping documentation up to date. But this is true for any documentation. Some diagrams (class and activity, in particular) are less valuable as time passes. I can get the idea of the class structure by just looking at the code itself. The class diagram just ends up being a stale representation of the code. It is unfortunate that UML has developed a reputation as being overly complex. Now I see more ad-hoc diagrams being created, with whatever notation/symbols make sense to author, rather than using a common diagram system that can be read by many.

jameshart 3y ago

Sequence diagrams are the only bit of UML that also applies to distributed systems. And everything today is a distributed system.

agumonkey 3y ago

to me seq diagrams are .. too sequential, my brain needs a protocol / graph proof like formalism to see things more globally.

BerislavLopac 3y ago

> Class, component, package, activity and state machine diagrams are all useful ways to model the structure and behavior of a system visually They're not bad, but the C4 model is a much better approach to high level modelling (while you can still use class diagrams on the lowest level). https://c4model.com/ https://c4model.com/

phoehne 3y ago

We also moved to framework heavy development where you write classes that plug into frameworks. So a POJO here and a POJO there… (everywhere a POJO) that are managed by a framework and exist only to extend the framework are marginally useful. A UML class diagram for a Spring Batch transformer that’s cobbled together from an existing CSV reader component, just isn’t that interesting or necessary.

Vox_Leone 3y ago

Maybe UML can find a new life with ChatGPT. Maybe it can fulfill the promise of generating code out of diagrams. UML seems like a fine way to organize prompts.

kmerroll 3y ago
Excellent comment and while maybe not UML, something like it is likely to emerge for exactly that purpose.

collyw 3y ago

Does anyone else find the agile way of doing things just ends up with lots of increments and no big picture of how the system should be or where it should be going? There also seems to be a with with waterfall that it's a one way process and you can't do iterations.

rewmie 3y ago

> The industry started rejecting Waterfall, early design and system architects, in favor of Agile, just-in-time design and empowering developers. So we saw no need for these visual design tools to model the entire system, since we ended up changing the design during the lifetime of the project anyway. It wasn't also visual design tools that Agile killed. Agile killed design documentation altogether. With Agile, today's problems are addressed on tomorrow's sprint, and changes in software architecture take place only in the code. Any effort to document the system architecture in any remotely rigorous way is quickly deprecated, and teams simply don't waste time maintaining something that might already be deprecated once they finish editing the document.