Stefan Zörner
07.07.2026
PlantUML ist ein ausgereifter Vertreter des Diagrams-as-Code-Ansatzes. Aber nicht frei von Kritik. In diesem Beitrag unterziehe ich einige Aussagen zum verbreiteten Tool einem Faktencheck.
Jedes Entwicklungsteam, das sich mit Docs-as-Code beschäftigt, stellt sich irgendwann die Frage, wie es mit Diagrammen umgeht. Eine naheliegende Lösung sind Werkzeuge, die Bilder aus textuellen Beschreibungen generieren. So lassen sich nicht nur die primär schriftlichen Inhalte einer Dokumentation wie Konzepte oder Architekturentscheidungen gut in der Versionsverwaltung unterbringen. Sondern auch die zugehörigen Abbildungen. Hier kommt bei vielen PlantUML ins Spiel.
Was ist PlantUML?
Mythos 1: PlantUML ist ein UML-Tool
Mythos 2: PlantUML-Diagramme sehen altbacken aus
Mythos 3: PlantUML braucht Graphviz zum Arbeiten
Mythos 4: Beim Layout von Diagrammen gibt es keine Kontrolle
Mythos 5: PlantUML unterstützt kein C4
Mythos 6: Heute nimmt jeder Mermaid. PlantUML ist tot
Zusammenfassung und Fazit
PlantUML generiert aus Quelltexten im eigenen Format (Datei-Endung *.puml) u.a. UML-Diagramme. Die Syntax ist schnell erlernt, ein Kontextdiagramm für eine imaginäre Auktionsplattform mit zwei User-Gruppen und zwei Fremdsystemen lässt sich in PlantUML zum Beispiel so beschreiben:
@startuml
left to right direction
actor Mitglied
actor "Back-Office-MA" as BackOffice
component AuktionX <<system>> as System
rectangle Bezahlsystem <<extern>> as Bezahl
rectangle Betrugserkennung <<extern>> as Betrug
Mitglied -- System: via Web\n/ App
BackOffice -- System
System -- Bezahl
System -- Betrug
@enduml
PlantUML erzeugt aus dieser Textdatei folgendes Diagramm (siehe Abb.1). Das kann per Kommandozeile erfolgen, oder auch eingebettet zum Beispiel mit geeignetem Plugin in eine Wiki-Seite.
Zum Kennenlernen und Experimentieren stellt PlantUML auch einen Online-Server bereit. Quelltexte aus einem Textformular landen on-the-fly als Diagramme auf der gleichen Webseite. Das Beispiel von oben könnt Ihr hier direkt ausprobieren und verändern.
PlantUML ist seit langem bei vielen Entwicklungsteams im Einsatz. Das verwundert kaum, denn …
Gleichwohl gilt PlantUML als etwas sperrig, und in jüngerer Zeit drängeln sich Alternativen in den Vordergrund. Im Folgenden diskutiere ich sechs Aussagen, die ich im Zusammenhang mit PlantUML des Öfteren höre. Teilweise von Verfechtern, teilweise von Kritikern von PlantUML. Mythos? Wahrheit? Irgendwo in der Mitte?
Diese Aussage läge nahe, weil UML im Namen steckt. Allerdings sprechen UML-Puristen hier von einem Missverständnis, verwehren sich mitunter vehement dagegen. Warum eigentlich?
UML steht für Unified Modeling Language und ist eine durch die Object Management Group standardisierte Notation zur Beschreibung von Softwaresystemen. Der entscheidende Punkt ist das “M”. Die Kernidee ist ein Modell, einzelne Diagramme bilden Sichten darauf. Bei einem “richtigen” UML-Tool wie zum Beispiel Enterprise Architect wirkt sich die Umbenennung eines Modellelementes (z.B. einer Komponente) automatisch auf alle Diagramme aus, in denen diese Komponente vorkommt. UML stellt also die Konsistenz der Diagramme sicher. Manche Leute sehen dies als stärkstes Argument für UML. Wobei es gewichtiger wird, je mehr Diagramme im Spiel sind.
Und genau das ist ein Aspekt, den PlantUML so nicht leistet. Wenn ich die Diagramme in separaten Quelltext-Dateien beschreibe, muss ich mich um Konsistenz selber kümmern. Es gibt kein zugrundeliegendes Modell. Auch die korrekte Verwendung der UML innerhalb eines einzelnen Diagrammes prüft PlantUML, anders als klassische UML-Werkzeuge, nicht.
Ein weiterer Punkt: PlantUML kann mehr als nur UML-Diagramme darstellen. Im Leistungsumfang sind zum Beispiel Archimate, Erweiterte Backus-Naur-Form (EBNF), Mindmaps und Wireframes für UI-Mockups. Gleichzeitig unterstützt PlantUML zwar viele der immerhin 14 UML-Diagrammtypen, aber nicht alle, oder zumindest nicht vollständig. Es fehlen z.B. das Kommunikations- und das Kompositionsstrukturdiagramm.
Schlussendlich lässt sich sagen: Die Gleichung PlantUML == UML passt nicht. PlantUML ist kein UML-Tool im klassischen Sinne. Es kann mehr als UML, beherrscht die UML aber nicht komplett.
Dieses Vorurteil hält sich hartnäckig und stammt aus einer Zeit, als PlantUML-Diagramme standardmäßig wirklich nicht so schön aussahen. Immer Geschmackssache natürlich, zur Illustration in Abb. 2 als kleine Zeitreise ein einfaches Kontextdiagramm, gerendert mit einer fast 10 Jahre alten PlantUML-Version. In der Eingabe habe ich die Kurzschreibweisen für Komponenten (eckige Klammern) und Akteure (Doppelpunkte) benutzt.
Unansehnlich sind in meinen Augen vor allem die Farben in klassischer Rational-Rose-Anmutung (gelb und pink). UML muss aus meiner Sicht schwarz-weiß sein. Die alte Komponenten-Notation der UML 1 wirkt ebenfalls altertümlich, UML-Version 2.0 erschien übrigens 2005. In Summe sieht das Ganze sehr nach Ende der 90er-Jahre aus. Aber auch schon 2016 konnte man in PlantUML mit sogenannten Skin-Parametern Einfluss auf das Aussehen der Diagramme nehmen, wie das Beispiel in Abb. 3, gerendert mit der gleichen alten PlantUML-Version, zeigt.
2026 sieht es bzgl. Anpassungsmöglichkeiten in PlantUML noch besser aus. Neben den Skin-Parametern gibt es seit geraumer Zeit sogenannte Themes, die auf einen Schlag sehr großen Einfluss auf Farben, Fonts, etc. nehmen. Die Galerie bietet einen bunten Strauß an Möglichkeiten. Das plain-Theme trifft meinen Geschmack aber mit Abstand am besten. UML, wie es sein muss: schwarz auf weiß, keine Schatten oder Schnörkel.
Unter dem Strich kann man sich immer noch darüber streiten, ob PlantUML optisch viel hermacht. Zwingend altbacken sehen die Diagramme aber schon lange nicht mehr aus. Es ist eine Frage der Konfiguration. Und selbst mit den Standardeinstellungen sind die Resultate mit der aktuellen Version funktional und vorzeigbar.
Die Graphviz-Software nimmt die textuelle Beschreibung eines Graphen (Knoten und Kanten) in einer spezifischen Syntax (DOT) als Eingabe und liefert eine Visualisierung davon z.B. in PNG oder PDF. Daher auch der Name: “Graph Visualization”.
Graphviz und PlantUML ähneln sich also, ersteres hat allerdings den Fokus auf Graphen und ist nochmals um einiges älter als PlantUML. Es geht auf Arbeiten bei AT&T Labs Research Anfang der 90er Jahre zurück, ist in C geschrieben und ebenfalls Open Source. DOT steht dabei angeblich für “DAG of tomorrow”, DAG (“Directed Acyclic Graph”) wiederum verweist auf noch frühere Tools. Graphviz findet viele Anwendungen vor allem im technisch-wissenschaftlichen Umfeld.
PlantUML ist in Java geschrieben und lässt seit jeher Graphviz im Hintergrund werkeln. Vereinfacht: PlantUML überführt die Inhalte der Eingabedatei in einem Zwischenschritt in DOT und nutzt im Hintergrund die dot-Binary von Graphviz zum Layout, etwa zur Berechnung von Knotenkoordinaten. Beim Arbeiten mit PlantUML bleibt das unsichtbar, außer es gibt Probleme im Zusammenspiel zwischen den beiden Tools. Etwa, wenn Graphviz nicht installiert ist, oder PlantUML das dot-Binary aus einem anderen Grund nicht findet.
Unter der Haube durchläuft die Eingabe in PlantUML eine Processing Pipeline, und Graphviz kommt als Layout Engine im entsprechenden Schritt zum Einsatz. Das allerdings nicht immer, denn bei bestimmten Diagrammtypen nutzt PlantUML Graphviz bzw. DOT gar nicht, zum Beispiel bei den in Entwicklungsteams überaus beliebten Sequenzdiagrammen. Genauer: PlantUML nutzt Graphviz bei Usecase-, Klassen-, Objekt-, Komponenten-, Deployment- und Zustandsdiagrammen. Bei allen anderen nicht.
Tatsächlich gilt diese Konstellation seit jeher als Ärgernis, da neben PlantUML mit Graphviz noch ein weiteres Programm installiert sein muss, und der Java-Prozess von PlantUML bei jedem Diagramm einen externen Prozess startet. Das PlantUML-Team betrachtet die Abhängigkeit von Graphviz als technische Schulden und arbeitet schon länger daran, sie loszuwerden. Ziel ist eine rein in Java entwickelte und damit portablere Lösung. Eine Schlüsselrolle hierbei übernimmt Smetana, ein PlantUML-interner Graphviz-Port in Java.
Smetana statt Graphviz lässt sich per “!pragma layout smetana” in der Eingabedatei auswählen, oder auch per Kommandozeilen-Schalter “-Playout=smetana”. Damit umgeht man die Abhängigkeit, wobei Smetana einzelne Features von Graphviz (noch) nicht unterstützt, und die Diagramme nicht zwingend 100% pixelgenau gleich aussehen, wie Abb. 6 zeigt. Smetana gilt bis heute als experimentell.
Wenn PlantUML keine Abhängigkeit zu Graphviz mehr besäße, wäre es portabler und leichter zu integrieren. Doch die Hürde von Java bleibt, Mermaid als reine JavaScript-Lösung hat im Browser leichteres Spiel. PlantUML adressiert das Thema mittlerweile dank TeaVM und Viz.js selbst, siehe PlantUML JS Editors.
Was die Bewertung der Aussage angeht: PlantUML kann heute ohne Graphviz werkeln, gleichwohl ist Graphviz noch immer das Default-Layout für viele Diagramme.
PlantUML erlaubt durch Hinweise im Quelltext Einfluss auf die Anordnung der Elemente. So lässt sich mit einer Richtungsangabe in Beziehungen (z.B. “-down->”) steuern, wo das Tool die Zielelemente platziert. Über die Anzahl der Bindestriche in Verbindungen ("–>") kann man Ebenen festlegen, in denen Dinge landen. Abb. 7 zeigt einfache Beispiele.
Und es geht noch mehr. So lässt sich eine generelle Anordnung festlegen wie im Beispiel ganz oben in diesem Beitrag (“left to right direction”). Über Hinweise zur Gruppierung (z.B. “together”) und versteckte Verbindungen ("-[hidden]-") lässt sich das Layout ebenfalls beeinflussen.
Bei feineren Formatierungsfragen hat das Ganze Grenzen. Eine pixelgenaue Platzierung von Elementen z.B. über eine Koordinatenangabe ist nicht vorgesehen. Und es erfordert in der Abb. 1 schon ein paar Tricks, um die Rechtecke der beiden Fremdsysteme gleich breit zu kriegen.
Aus meiner Sicht ist der Witz beim Generieren von Diagrammen, dass mir das Tool das Zeichnen abnimmt. Ich zähle die Elemente auf, das Tool liefert ein Bild. Das spart mir viel Zeit. Ich sehe regelmäßig Entwicklungsteams, die sich abmühen im “Verhandeln” mit PlantUML über Größen und Anordnungen.
PlantUML-Layout, das mehr Aufwand machen würde als Zeichnen in draw.io, ist ein Warnsignal.
So gesehen gibt uns PlantUML nicht die volle Kontrolle über das Layout in Diagrammen, aber aus meiner Sicht sind einfache Quelltexte eher im Sinne von Diagrams-as-Code als feine Attributierung zur genauen Positionierung. Im Extremfall verliert Ihr den größten Vorteil. Wenn Ihr Diagramme wirklich zeichnen wollt, nehmt lieber draw.io, Excalidraw o.ä. … Für liebevoll handgelayoutete Schaubilder ist PlantUML nicht gedacht.
C4 steht für “Context, Containers, Components, Code”. Als Alternative zur UML durch die Arbeiten von Simon Brown bekannt geworden, erfreut es sich großer Beliebtheit. C4 verdrängt UML und informelle Notationen für Diagramme (aka “Boxes and Lines”) in vielen Unternehmen und Organisationen. Simon bietet für seine C4-Notation mit Structurizr ein eigenes Tooling in Diagrams-as-Code-Manier an.
Die Aussage, dass PlantUML die C4-Notation nicht unterstützt, rührt vielleicht daher, dass es nicht PlantC4 heißt. Tatsächlich funktioniert es durchaus vorzeigbar, wenn man entsprechende Erweiterungen benutzt, konkret C4-PlantUML.
Da das C4-Modell Kontextdiagramme beinhaltet (das erste C), lässt sich das Beispiel von oben gut nachbilden. Der folgende Quelltext nutzt die C4-Erweiterung aus der Standardbibliothek von PlantUML sowie die deutsche Lokalisierung, damit die Legende sprachlich passt. Auf der C4-PlantUML-Seite finden sich Beispiele für die anderen Cs (Container-Diagramm, Component-Diagramm …).
@startuml
!theme C4Language_german from https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/themes
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml
LAYOUT_LEFT_RIGHT()
Person(mitglied, "Mitglied")
Person(backoffice, "Back-Office-MA")
System(auktionx, "AuktionX")
System_Ext(bezahl, "Bezahlsystem")
System_Ext(betrug, "Betrugserkennung")
Rel(mitglied, auktionx, "via Web / App")
Rel(backoffice, auktionx, "")
Rel(auktionx, bezahl, "")
Rel(auktionx, betrug, "")
SHOW_LEGEND()
@enduml
Als Ergebnis produziert PlantUML das Diagramm in Abb. 8. Es zeigt die für C4 typische blaue Anmutung, die Bibliothek bietet einiges an Anpassungsmöglichkeiten (siehe Dokumentation).
Ob das toll aussieht, ist Geschmackssache. Der größte Unterschied zwischen Structurizr und PlantUML beim Einsatz mit C4 ist ohnehin ein anderer. Während PlantUML Diagramm-basiert ist, nutzt Structurizr ähnlich wie die UML ein gemeinsames Modell für die Diagramme. Umbenennungen von Elementen schlagen sich daher beispielsweise überall nieder.
So gesehen unterstützt PlantUML die C4-Notation, hat aber ähnliche Einschränkungen bzgl. Konsistenz wie bei der UML, siehe dazu auch Mythos 1: PlantUML ist ein UML-Tool.
Mermaid erzeugt ähnlich wie Graphviz und PlantUML Diagramme aus textuellen Beschreibungen. Das Beispiel vom Beginn dieses Artikels lässt sich in Mermaid z.B. so nachbilden:
flowchart LR
Mitglied([fa:fa-user Mitglied])
BackOffice([fa:fa-user Back-Office-MA])
System[«system»\nAuktionX]
Bezahl[«extern»\nBezahlsystem]
Betrug[«extern»\nBetrugserkennung]
Mitglied ---|via Web<br/>/ App| System
BackOffice --- System
System --- Bezahl
System --- Betrug
Mermaid stellt es wie in Abb. 9 dar, wobei ich das PNG dort per Kommandozeile erzeugt habe. Wenn Ihr im Editor mit dem Quelltext herumspielen und live die Veränderungen sehen wollt, könnt Ihr dies z.B. mit dem Live-Editor von Mermaid tun.
Während Graphviz in der Programmiersprache C realisiert ist und PlantUML in Java, ist Mermaid JavaScript-basiert. Daher lassen sich die Diagramme auch Client-seitig im Browser rendern und anzeigen. Das vereinfacht die Integration in Wikis oder dynamische Webseiten verglichen mit z.B. Graphviz und auch PlantUML erheblich. Dort müssen die Diagramme in der Regel vorab und/oder server-seitig gerendert werden.
Dieser Umstand macht Mermaid zum Liebling in AI-Chat-Interfaces. Claude & Co. betten diese Diagramme schon länger problemlos in ihre Dialoge ein. Der Screenshot in Abb. 10 illustriert dies mit Open WebUI und einem lokalen Modell (im konkreten Fall gemma4:31b von Google).
AI-Dokumentationsgeneratoren wie DeepWiki und dessen “Nachbauten” setzen ebenfalls gern auf Mermaid, um Diagramme zu zeigen. LLMs sind mit Mermaid tendenziell vertrauter als mit PlantUML, da sie mit riesigen Mengen GitHub-/Markdown-Inhalten trainiert wurden, die Mermaid enthalten. GitHub unterstützt Mermaid nativ seit 2022.
Der Leistungsumfang von Mermaid ist mit dem von PlantUML durchaus vergleichbar. Mermaid ist zwar nicht explizit eine UML-Lösung, es unterstützt aber zum Beispiel Sequenzdiagramme.
Unser letzter Mythos hält der Prüfung nur zur Hälfte stand. Mermaid ist tatsächlich zum De-facto-Standard für Diagramme in Git-Repos und Dokumentation geworden. Es rendert nativ z.B. in GitHub, GitLab und Azure DevOps und zählt über 88.000 GitHub-Sterne (Stand Juli 2026). 2023 landete es im “Adopt”-Ring des Thoughtworks Technology Radar. “Jeder nimmt Mermaid” ist zugespitzt, aber der Trend stimmt.
Notably, [Mermaid is] supported natively in popular source code repositories such as GitHub and GitLab, enabling the embedding of and easy updates to Mermaid diagrams in the middle of Markdown documentation.
(Thoughtworks Technology Radar, 2023)
Tot ist PlantUML dagegen nicht. Mit der aktuellen Version v1.2026.6 (Juni 2026), monatlichen Releases und neuen Features wie Chart-Diagrammen und einem MCP-Server für AI-Tools ist die Entwicklung weiterhin sehr aktiv.
Viele Projekte nutzen übrigens sowohl Mermaid als auch PlantUML. Letzteres dann insbesondere für UML-Diagramme in der generierten Dokumentation, zum Beispiel als PDF. Mermaid in der Kommandozeile ist auch nicht frei von Tücken. Es benötigt immerhin Zugriff auf einen Chrome-Browser (headless).
Sechs Aussagen, sechs Mal genauer hingeschaut. Die folgende Tabelle fasst das Ganze nochmal zusammen.
| # | Aussage | Urteil |
|---|---|---|
| 1 | PlantUML ist ein UML-Tool | Mythos. PlantUML kann mehr als UML, beherrscht die UML aber nicht komplett und hat kein Modell dahinter. |
| 2 | PlantUML-Diagramme sehen altbacken aus | Mythos. Oder zumindest überholt. Mit Skin-Parametern und Themes ist es eher eine Konfigurationsfrage. |
| 3 | PlantUML braucht Graphviz zum Arbeiten | Teils wahr. Es geht auch ohne (Stichwort Smetana), Graphviz ist aber weiterhin Default für viele Diagrammtypen. |
| 4 | Beim Layout von Diagrammen gibt es keine Kontrolle | Teils wahr. PlantUML bietet Einfluss, aber keine pixelgenaue Kontrolle. Das ist allerdings ganz im Sinne von Diagrams-as-Code. |
| 5 | PlantUML unterstützt kein C4 | Mythos. C4-PlantUML unterstützt die Notation, ein gemeinsames Modell wie bei Structurizr fehlt allerdings (wie bei UML auch). |
| 6 | Heute nimmt jeder Mermaid. PlantUML ist tot | Teils wahr. Mermaid ist ob des Client-seitigen Renderings im Browser der neue De-facto-Standard, PlantUML aber noch sehr lebendig. |
Wie haltet Ihr es in Zukunft mit PlantUML? Wer Diagramme direkt in GitHub, GitLab oder Wikis rendern möchte, fährt mit Mermaid sehr bequem. Wer UML-nahe Diagramme in generierter Dokumentation benötigt, etwa als PDF aus dem Build heraus, ist bei PlantUML meines Erachtens auch weiterhin gut aufgehoben. Und wer Konsistenz über viele Diagramme hinweg sucht, also ein echtes Modell, sollte sich Structurizr oder vielleicht sogar “richtiges” UML ansehen. Die Kombination mehrerer Tools im selben Vorhaben ist meiner Erfahrung nach gelebte Praxis.