Bei der Softwareerstellung braucht man oft Diagramme. Eine Strategie ist, sie wie den Quellcode zu verwalten.

Diagramme und Code

Ich mag gute Mal-, Zeichen und Designprogramme und ich würde sie viel lieber verwenden, als das, was ich gleich beschreibe. Leider haben sich die Systeme, mit denen heute Programme und Dokumentation erstellt werden sich in eine Richtung entwickelt, die die Verwendung von Zeichnungen in den Fromaten von gängiger Designsoftware wie Visio und Draw oft sehr unpraktisch macht. Es hätte Wege gegeben, dies zu vermeiden, aber dafür ist der Anwendungsfall offenbar den meisten nicht wichtig genug gewesen.

Immer öfter sind mir in den letzten Jahren Formate begegnet, bei denen Text in Diagramme umgewandelt wird. Dabei sind die Formate mal eher abstrakte Beschreibungen (wie bei PlantUml), oft sind sie aber auch nahe an dem, was man bei Commodore-Anwendern damals PETSCII nannte. Zwar werden im letzteren Fall nicht Schriften und Grafikzeichen benutzt um die Diagramme darzustellen, aber das Eingabeformat ähnelt einem ASCII-Bild anstatt einer abstrakten Beschreibung.

Die Erben der Grafikzeichen

Die Geschichte, wie es zu den Zeichen für »Box Drawing« und »Block Elements« (U+2500 bis U+259F) gekommen ist, kann ich leider nicht vollständig referieren. In der Anfangszeit der Terminals mit Bildschirm wurden unterschiedliche Methoden verwendet, um zu dieser Art von Ergebnissen zu kommen. Aber 1981 war den meisten Herstellern klar, dass Grafikmodi noch zu langsam und speicherhungrig waren und man viele Elemente einfach wie Buchstaben benutzen konnte und diese auch meist die gleichen waren.

So ganz passt dieser einleitende Absatz aber nicht, denn die generierten Grafiken sind oft keine 1:1-Abbildungen des Grundrasters der Vorgabe, wenn man zum Beispiel Goat benutzt. Letzteres Format hat den Vorteil, dass es hier im Blog integriert ist. Ich kann es also ohne weitere Vorbereitungen, Grafikdateien, etc. benutzen.

Eines meiner vielen Seitenprojekte ist ein Oberon Compiler (mehr dazu in einem späteren Artikel). Und als Beführworter von Beispielen aus dem realen Leben kann ich jetzt ein Diagramm aus diesen Bemühungen verwenden.

Aber das sieht wirklich nicht so gut aus!

In gewisser Weise haben die Textformate für Diagramme ähnliche Stärken wie TeX oder Markdown. Eine Büro- oder Autorensoftware hat viele Funktionen, die man bei diesen einfachen Textformaten nicht bekommt. Beispielsweise sind die Silbentrennung und die Rechtschreibkorrektur - insbesondere für Deutsch - nur mit größerem Aufwand in einem Emacs oder Vim aktivierbar.

Hier ein Ausschnitt aus dem Text, der zum Diagramm gehört:

1   '----'   '----------'   '--' .-----.                     
2             .-----------------+ ELSIF |<-----------------. 
3            |                   '-----'       .-.          |
4            v                         .------+ ; |<----.   ^
5            |                        |        '-'       |  |
6   .-----.  |   .----------.   .--.  |   .-----------.  |  |
7->| WHILE +->'->| Ausdruck +->| DO +->'->| Anweisung +-'--'-
8   '-----'      '----------'   '--'      '-----------'      

Es ist aber nicht nur so, dass es ziemlich kniffig war, dieses Diagramm mit der Tastatur zu zeichnen. Auch musste ich tricksen, um die Interpunktionszeichen zu realisieren: einige Zeichen habe ich durch andere Unicode-Zeichen ersetzt, die ähnlich genug aussehen. Das Ergebnis ist eher funktional als schön.

Bevor ich diese Fassung erstellt habe, habe ich dieses Diagramm mit LibreOffice Draw gezeichnet, was leider auch deutlich hinter meinen Vorstellungen zurückbleibt. Insbesondere finde ich die fehlenden Kurven und bei den Pfeilen problematisch. Imerhin kann ich hier zusammengehörige Sprachelemente farblich kennzeichnen, was bei Goat nicht geht.

Am liebsten hätte ich wohl eine Oberon-Version des bekannten Pascal-Posters, das Steve Jobs bei einem Künstler namens Tom Kamifuji in Auftrag gab, nachdem Jeff Raskin eine Version gezeigt hatte. Hier mal ein Ausschnitt daraus:

Genau genommen stammt dieser Ausschnitt aus der Hand von Dana Sibera (@nanoraptor.danamania.com), die mit Bildern des Originalposters eine Digitalversion erstellt hat. (Natürlich will ich für mein »Poster« sinnvollere Farbzuordungen und geometrisch stimmigere Formen.)

Graph-Beschreibungen

DOT, PlantUML und Mermaid sind auf einer höheren Abstraktionsebene angeordnet und ich benutze sie beruflich gelegentlich.

In VisualStudio Code (bzw. Codium) habe ich viele Erweiterungen installiert, die Diagramme in diesen Formaten halb-automatisch anzeigen. Richtig integriert sind sie nicht, aber es ist schon vergleichsweise komfortabel. Auf GitHub/GitLab Servern werden solche Diagramme häufig automatisch angezeigt. Auf Codeberg (Frogejo) habe ich es noch nicht getestet.

Ein Beispiel: Die Import-Hierarchie des Compilers aktuell so beschrieben:

 1graph BT
 2U(Umgebung) --> G
 3U --> S
 4S(Scanner) --> P(Parser) 
 5B(Bezeichner) --> G
 6F(Fehler) --> S
 7P --> A(Gobo)
 8L(Sprache) --> B
 9G(Generator) --> A
10B --> S

Im Ergebnis sieht das dann so aus:

(Ja, aktuell heißt der Compiler »Gobo«.)

Auch für Diagramme, die einen Syntaxgraphen darstellen gibt es automatische Generatoren wie diesen, bei denen die Syntax in EBNF angegeben werden kann. Die Ergebnisse sind nicht schlecht, aber auch nicht all zu sehr nach meinem Geschmack.

TL;DR (Fazit)

Vorteile von Textformaten

• Die Bearebeitung der Diagramme ist bei abstrakteren Formaten schneller durchfühbar, aber nicht bei Konkretformaten.
• Git kann Änderungen in den Diagrammen leichter erkennen, obwohl diese dann bei den meisten Formaten im Diff nicht mehr gut für Menschen lesbar sind.
• Diagramme können direkt in Quellcodekommentaren stehen und somit ist es leichter, sie aktuell zu halten und zu verhindern, dass Programm und Diagramm etwas unterschiedliches beschreiben.

Nachteile von Textformaten

• Die Diagramme können optisch nicht so ansprechend gestaltet werden.
• Differenzierungsmerkmale wie Farben und Schrifstile sind Mangelware.
• Reine Textprogramme (Editoren) sind im Funktionsumfang nicht gut ausgestattet, um Grafik zu bearbeiten.
• Es fehlt die schnelle Hand/Auge-Korrelation. Einige Positionierungen dauern daher sehr viel länger.

Zurück