However, I have one major gripe with Plant UML. About 3-4 years ago, my local install started showing memorial plaques for people who died in a terrorist attack in Paris . While this attack was undoubtedly a horrible event, I still feel it is deeply unprofessional to include stuff like that in a program, and it makes me lose all trust in the developers. If they had just added a memorial section in the program, it would have been fine. However, for every error generating a diagram, Plant UML would show a popup window with a picture and a text in memory of that person.
This is similar to what the Notepad++ developer(s) did back in 2013-ish where they had a memorial build into a new release of the program. On startup, Notepad++ would write (literally type it out) some message into the default empty document .
It might be a bit harsh. But in my mind, if the developers of these programs can be so influenced as to push this onto their unsuspecting users, I feel they have misused my trust. It makes me think: "What are they going to put into it next? Malware? Perhaps watermark the output with a statement?"
Since these events, I have avoided Notepad++ entirely and been reluctant to use Plant UML, but used it out of necessity.
It's a really big jump to say people who honor the dead with their software are going to insert malware in it next.
Use or don't use whatever you like, it's free and open source, but this seems like a pretty terrible reason to avoid otherwise great software.
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.
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.
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.
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.
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.
After what felt like endless googling it is what I decided to spend some time with, haven't had time to do much yet so can't say how it performs for me but the idea and execution really resonates with me.
Not fully-featured yet but what I'd like to eventually do is set it up in a similar way to the mermaidjs editor . They encode the entire diagram in the url. That makes it really easy to link to from markdown documents and has the nice benefit that the diagram is immutable for a given url so you don't need a backend to store anything.
I recently discovered you can draw a whole Gantt chart just by describing the activities in natural-ish language.
It's kind of amazing though, it has one of the highest ratios of utility to presentation (as in, it works great and it looks horrible) of any tool I know.
Gitlab has support for it built-in, and so do many Markdown editors (https://marknoteapp.com/).
Recently I see a lot general statements on HN like "UML is dead" which I think is not the case. Especially in complex, data-heavy projects it's a great way to visualize how things work -- if kept up-to-date and precise.
I appreciate the C4 diagrams specified in UML for software developers ( https://c4model.com/ )
And all the diagrams that are downloadable ( eg. For Azure : https://github.com/plantuml-stdlib/Azure-PlantUML , AWS : https://github.com/awslabs/aws-icons-for-plantuml , GCP : https://github.com/davidholsgrove/gcp-icons-for-plantuml , ... and so much more)
There was also a thread about Plant UML in 2019 with 48 comments: https://news.ycombinator.com/item?id=21426793
I notice most programmer/engineer types don’t have this hangup. I’ve always felt the same about IDEs with the (what I call) “millions of tiny buttons” design.
For my data modeling I ended up going with a tool called Lucidchart.
Now I have discovered PlantUml.
It is nice because you write,
and the display is automatically done.
And the display is mostly always perfect.
maybe that's a pro?
The problem with UML was it was far too specific. The aim was to just about generate the whole program code using charts which isn't what anyone needed.
Are those supposed to be thrown out after first or second release?
> The aim was to just about generate the whole program code using charts
That wasn't the aim of UML.
Any model (including UML) serves two main purposes: to create system design and to document that design.