PlantUML is a nice tool for small diagrams/teams/projects but it doesn't scale to big projects at all. I'm in an automotive project and we had tried to jump from Enterprise Architect to the puml and the latter one failed very quickly.
We realized it's just impossible to handle in a reasonable way hundreds of diagrams from different teams who have to show/maintain cross-component dependencies independently. Puml isn't designed for that at all. Another limitation of puml we faced: there is no way to control the position and layout of elements on diagrams. With complex diagrams, you'll quickly get a total mess and if you are lucky to manage how to get finalized nice diagram then any tiny element added later will ruin the whole diagram since puml decided to reposition everything.
Just wanted to share our experience. Yep, we are still using it for small generic diagrams to quickly depict some concepts as well as for sequence diagrams but never for documenting complicated component/class relations.
Using PlantUML for UML is akin to using Visio for UML. It is a diagramming tool and can make great diagrams. However, it is not a modelling tool. It can't track relationships between diagram elements and metadata about those elements, other than the metadata that can be extracted from the diagram.
I've used PlantUML on past projects, but almost always in conjunction with a separate program that stored data in a SQLite db and then generated PlantUML on command.
An example of something similar I am working on as a side project is using JQL to query all the issues in JIRA targeting a specific fix version, then generate the graphviz dot notation to create a hierarchical stoplight chart showing issue decomposition, issue id, issue status, and POC for an issue.
Thanks for sharing this. If I may ask, would Ilograph (diagramming tool I made) alleviate the two issues you've raised? It aims to show cross-cutting dependencies via perspectives, and has an interactive layout to make complex perspectives easier to read. It's definitely a "long term" diagram solution, as opposed to quick sketches. Would love to know how close it gets to the mark.
I've seen you mention it before. At first glance it seems interesting and I definitely agree that having multiple perspectives available to view and explore the model of a complex system is key.
It reminds me of https://structurizr.com/ which builds upon the C4 model for visualizing architecture.
Using these tools successfully is also a question of the goal: are we using them to model and plan up-front or are we visualizing the status quo (for onboarding, change analysis or other purposes). If it's the latter then you need to investigate how to (partly) derive the model from the single source of truth - your code base of applications and infrastructure. Otherwise there is a strong likelyhood of the model diverging from the truth and thus losing its value.
> We realized it's just impossible to handle in a reasonable way hundreds of diagrams
Do you mean you update PlantUML source files by hand in order to follow software changes, instead of generating them from a real model or from a reverse engineering tool?
> there is no way to control the position and layout of elements on diagrams
This is a feature: there is no way to waste time fiddling with diagram layout, and you can tell that to the cheapskates who made you switch from Enterprise Architect to PlantUML.
If you want a "finalized nice diagram", and you should need it infrequently, use a proper vector graphics editor and omit details (e.g. unimportant class members) to reduce churn and editing effort in general.
> Do you mean you update PlantUML source files by hand in order to follow software changes, instead of generating them from a real model or from a reverse engineering tool?
Sorry, I didn't explain it clearly enough. In our project, it's not only about components/classes. We have architectural documentation which describes a high-level architecture of the whole project: services, deployments, interfaces, devices, middlewares, files, virtualized environments, databases, and their relations across different domains and software clusters so it's not possible to generate diagrams for such things.
>> there is no way to control the position and layout of elements on diagrams
> This is a feature: there is no way to waste time fiddling with diagram layout
Yep, I understand but... As I just said, when a project is big, and it has a big architectural document that describes different software clusters, their relations, deployments, and so on, then it's totally unacceptable when all teams on each sprint/release are getting such an important document with brand-new diagrams because of "that feature" since some new architectural piece was added to the diagrams.
> you can tell that to the cheapskates who made you switch from Enterprise Architect to PlantUML.
After all, we didn't make a full switch to puml. We are still using both. There were some problems with the Enterprise Architect so lead architects decided to check how puml will play in that role but they quickly rejected the idea after the evaluation of pros/cons. We are still allowed in our project to use puml to depict high-level architectural parts but I personally gave up after numerous attempts to get nice-looking diagrams.
We realized it's just impossible to handle in a reasonable way hundreds of diagrams from different teams who have to show/maintain cross-component dependencies independently. Puml isn't designed for that at all. Another limitation of puml we faced: there is no way to control the position and layout of elements on diagrams. With complex diagrams, you'll quickly get a total mess and if you are lucky to manage how to get finalized nice diagram then any tiny element added later will ruin the whole diagram since puml decided to reposition everything.
Just wanted to share our experience. Yep, we are still using it for small generic diagrams to quickly depict some concepts as well as for sequence diagrams but never for documenting complicated component/class relations.