I've had less success with component diagrams to represent our systems because the layout engine in PlantUML is (or used to be) quite limited. This resulted in diagrams that didn't communicate the system as well as if I manually drew boxes and lines.
There is a fantastic plugin for Jetbrains IDEs that generates the diagrams in real time which is great for fast feedback, and can be used for driving out diagrams while presenting video calls.
Overall, my conclusion is that you can pick the parts that are useful to you and the people you communicate ideas with.
group sys {
one -down-> two
}That's exactly how I use it!
> We make extensive use of sequence diagrams using PlantUML at my work. We don't rigorously adhere to the correct UML arrow types and so on, instead preferring it as a fast way to clearly communicate data flow over time. The fact that it's in a text format means it can be conveniently edited and stored in source control.
Similar situation, Github now supports rendering Mermaid (https://github.blog/2022-02-14-include-diagrams-markdown-fil...) but I'm yet to give it a try.
People often find that level of documentation a bit redundant if you have access to the code, but if you're pressed for time and the diagrams actually describe the crucial parts it can be a huge timesaver when you have to fix something in a 10 year old component.
To me, I have saw considerable performance improvements when sharing sequence diagrams to devs that are not very familiar with a project or its domain.
Unfortunately, sometimes it is complicated to understand when a diagram is worth it because while an experienced dev can find something obvious, an less experienced one can struggle on that for a while.
EDIT: I forgot mentioning that these diagrams were super helpful when presenting solutions to technical customers/partners, instead of preparing a PoC, we could just create the diagrams to explain the proposal flows.
I frequently draw simplified architecture and data/entity diagrams that tend to be "mostly" UML.
Generally on a whiteboard while discussing design/architecture - rarely do they end up as permanent artifacts/documentation.
--
Pure UML is pretty rare in my experience, and most likely used only in very strict environment that don't change often (security, airplanes,...).
UML concepts and diagrams however are extremely useful to collaborate on complex systems or flows. However people don't tend to make good diagrams, unless they're very restrictive. I find that sequence diagrams are usually the ones with the best quality out there because you have to adhere to a strict (and rather simple) représentation.
For things that are not flows-like I would recommend using the C4 Model https://c4model.com/ :
- It provides a simple and constrained way to describe systems and their interactions.
- The first two levels are the most useful IMO as they provide a lot of information, while being rather static over time. Level 3 and 4 typically require frequent changes as your code evolves.