Nomnoml: UML-Diagramme mit Textsyntax zeichnen

• Ein Tool, mit dem sich UML-Diagramme wie Code schreiben lassen; wenn die Textsyntax links bearbeitet wird, ändert sich auch das gerenderte Diagramm
• Unterstützt verschiedene Diagrammelemente und Beziehungslinien, darunter Klassen, Komponenten, Flussdiagramme, Use Cases sowie Datenbanken und Tabellen
• Bearbeitungsinhalte werden im Browser in localStorage gespeichert und können beim nächsten Besuch erhalten bleiben, eine Speicherung ist jedoch nicht garantiert
• Die Canvas kann im rechten Drittel per Ziehen und Scrollen verschoben und vergrößert/verkleinert werden, und der Editor unterstützt teilweise das Keymapping von Sublime Text
• Mit #-Direktiven und .-Style-Direktiven lassen sich Schriftart, Ausrichtung, Abstände, Farben, Linienformen und benutzerdefinierte Klassifikator-Stile anpassen

---

Diagramme mit Textsyntax erstellen

• Nomnoml ist ein Tool zum Erstellen und Rendern von Diagrammen mit einer textbasierten Syntax

• Beziehungslinien-Notation

  • association, dependency, generalization, implementation, composition, aggregation, ball and socket, note, hidden usw. können verwendet werden
  • Beispiel: [Car]->[Engine]
  • Beispiel: [Car] +-> 0..* [RustPatch]
  • Beispiel: [Car]o->[Manufacturer]
  • Beispiel: [Car]<:-[Pickup]

• Unterstützte Klassifikatoren

  • Klassendiagramme unterstützen neben der Standardklasse auch abstract, instance, reference, package, frame
  • In Komponentendiagrammen können die Notationen socket und lollipop verwendet werden
  • Als Flussdiagramm-Elemente gibt es start, end, state, choice, sync, input, sender, receiver, transceiver
  • Use-Case-Diagramme unterstützen actor und usecase
  • Weitere Elemente sind note, label, hidden, database, pipe, table
    • Ein Tabellenbeispiel hat die Form [<table>Fruits| Apples | 17 || Oranges | 4711]

Bearbeitung, Direktiven und Styles

• // am Zeilenanfang wird als Kommentar behandelt
  • // mitten in der Zeile ist jedoch kein Kommentar, wie in [not //commented]
• Mit dem Attribut id lassen sich zwei Knoten mit demselben Anzeigenamen zu unterschiedlichen Knoten machen
  • Beispiel: [<actor id=a>User], [<actor id=b>User], [a] -- [b]

• Layout und Rendering mit #-Direktiven anpassen

  • #import: filename
  • #direction: down | right
  • #edges: hard | rounded
  • #background: transparent
  • #font, #fontSize, #spacing, #padding, #stroke, #fill, #zoom
  • #ranker: network-simplex | tight-tree | longest-path

• Klassifikator-Stile mit .-Direktiven definieren

  • Beispiel: #.box: fill=#8f8 dashed
  • Beispiel: #.blob: visual=ellipse title=bold
  • Es können Schlüssel/Werte wie fill, stroke, align, direction, visual verwendet werden
  • Textstile für Titel und Inhalt lassen sich angeben, etwa title=left,italic,bold und body=center,italic,bold
  • Zu den Anwendungsbeispielen gehören Schriftartänderungen, kompakte Layouts, das Erstellen von Tabellen, benutzerdefinierte Styles und die Aufteilung auf mehrere Dateien
  • Für die Aufteilung auf mehrere Dateien wird die Form #import: blobby_styles verwendet
  • Änderungen im Editor werden im Browser in localStorage gespeichert, und die Canvas kann im rechten Drittel per Ziehen und Scrollen verschoben sowie vergrößert/verkleinert werden
  • Der Editor unterstützt teilweise das Keymapping von Sublime Text, und Nomnoml wird auf GitHub gehostet

[GN⁺]

Meinungen auf Hacker News

• GitHub-Link: https://github.com/skanaar/nomnoml

• Anfangs war ich ziemlich verwirrt, und erst als ich den About-Button gefunden hatte, habe ich es verstanden.
  Vielleicht hatte ich einfach Glück im Leben, dass ich UML nicht auf einen Blick erkenne. Zuerst dachte ich, es ginge um die Erklärung einer Art Fake-Piraten-Sprech-Syntax.

  • UML erkennt man daran, dass jede Menge Pfeilstile vorkommen, an die sich niemand erinnert. Ich bin mir zu etwa 90 % sicher, dass das der Hauptgrund ist, warum sich UML nie breit durchgesetzt hat.
    Viel besser finde ich solche Ansätze, die anerkennen, dass niemand 10 verschiedene Pfeilarten auswendig lernt, nur um gelegentlich ein UML-Diagramm zu lesen: https://buck2.build/docs/concepts/concept_map/
  • Streng genommen scheint das hier kein Standard-UML zu sein.
    Allerdings gilt das für ziemlich viele Tools, die den Begriff „UML“ verwenden, und in der Praxis braucht man oft etwas weniger Präzises und weniger Weitschweifiges als theoretisches UML.

• Früher gab es eine Open-Source-Website, die Tools für „Text zu Diagramm“ verglich: https://text-to-diagram.com/
  nomnoml steht nicht auf der Liste.

  • Die Seite wurde von den D2-Maintainern erstellt und kann daher voreingenommen sein, aber ich finde trotzdem, dass die D2-Syntax in dieser Kategorie, auch im Vergleich zu nomnoml, am zugänglichsten ist.
    [1]: https://d2lang.com/

• Ich mag Nomnoml. In letzter Zeit nutze ich es in einem browserbasierten Personal-Knowledge-Management(PKM)-Projekt, an dem ich arbeite, um hierarchische Tag-Strukturen zu visualisieren.
  Das Layout sieht meist ziemlich sauber aus. Beispiel: https://imgbox.com/9A1mDyNv

• Bei Mobile müsste offenbar nachgebessert werden. Als ich es auf dem Handy geöffnet habe, wurde das Diagramm über den Editor gezeichnet, sodass ich den Editor nicht benutzen konnte.

  • Das ist nur das Verhalten der nomnoml-Demo-Website. Sie ist so aufgebaut, dass sie zeigt, wie sich das gerenderte UML-Diagramm in Echtzeit ändert, wenn man den Text bearbeitet.
    Die darunterliegende JavaScript-Bibliothek kann direkt in ein HTML-Canvas oder aus einem Node.js-Programm nach SVG rendern und lässt sich bei Bedarf auch über die Kommandozeile ausführen.

• Ich habe früher ein paar Tools mit nomnoml gebaut, darunter Kontrollflussgraphen und Abhängigkeitsgraphen für GPU-Assembly-Code.
  Es hat mir wirklich gut gefallen, aber schade war, dass es keine zuverlässige Möglichkeit gab, bestimmte Elemente nah beieinander zu platzieren. Bei sehr großen Diagrammen trifft es manchmal schlechte Entscheidungen, und dann wird es unübersichtlich.
  Auch wenn die Dokumentation nicht vollständig ist, lässt sich der Code recht leicht anpassen, sodass ich Tooltips beim Darüberfahren mit der Maus und Links von bestimmten Kästen zu anderen Diagrammen hinein-hacken konnte. Ich bin dankbar, dass so ein gutes Tool Open Source ist.

• Ein gutes Layout zu bekommen, hängt zu stark von der Reihenfolge der Definitionen ab. Bei großen Diagrammen kann das für Nutzer schwer zu lösen sein, bei kleinen Diagrammen wirkt es aber in Ordnung.
  Wenn man zum Beispiel dasselbe Piratenbeispiel in anderer Reihenfolge schreibt, ist es zwar gültig, ergibt aber ein unschönes Layout.

  • Das Problem bei solchen Tools ist, dass man, selbst wenn man in der Dokumentation irgendwie ein gutes Layout hinbekommt, sofort wieder damit kämpfen muss, sobald man etwas hinzufügt, löscht oder ändert.
    Ich habe einige dieser codebasierten Diagramm-Produkte ausprobiert, weil ich von einer Welt träume, in der technische Dokumentation samt Diagrammen Teil des Projekt-Source-Codes ist. Aber es war schwer, ein akzeptables Layout zu bekommen – erst recht für externe Veröffentlichungen, aber auch für interne Zwecke.
    Diese Frustration führt meist zu zwei schlechten Ergebnissen: Entweder werden die Diagramme unlesbar, oder sie werden nicht mehr gepflegt.
    Ehrlich gesagt ist auch die Vorstellung, Dokumentation beim Check-in im Code Review zu prüfen, fast schon ein Mythos. Diffs solcher Dokumente sind sehr schwer zu verstehen, und ohne sie zu rendern und das Ergebnis anzusehen, lässt sich kaum sinnvoll überprüfen, ob die Dokumentation stimmt.
    Das ist die Art Problem, bei der ich mir wirklich wünsche, dass es gut gelöst würde, und vielleicht gilt es eines Tages als gelöst.
  • Korrektur: Ich dachte, die Anordnung erfolge von oben nach unten, aber das stimmt nicht; die Reihenfolge wird anders bestimmt.
    Vergleicht man die ursprüngliche Pirate-Tabelle mit der Pirate-Tabelle aus dem Parent-Kommentar, ist oben und unten vertauscht. Selbst wenn man beard und parrot zuerst in der gewünschten Anzeigereihenfolge definiert, erscheinen sie weiterhin vertauscht.
  • Man bräuchte noch ein weiteres Tool, das die Permutation der Sätze optimiert, sodass es im resultierenden Diagramm möglichst wenige Überlappungen gibt.
  • Dieses Piratenbeispiel hilft beim Verständnis nicht besonders. Ich frage mich, ob es eine Möglichkeit gibt, diese durcheinandergewürfelten Wörter sinnvoll anzuordnen.

• Sieht gut aus und wirkt deutlich besser als PlantUML-Klassendiagramme.
  [0]: https://plantuml.com/class-diagram

  • Kann sein. Aber statt noch einen weiteren fragmentierten Standard zu schaffen, frage ich mich, ob man nicht den Standardstil eines bereits recht gut unterstützten Standards hübscher machen könnte.
  • PlantUML unterstützt Sequenzdiagramme, eine der Diagrammarten, die ich am häufigsten verwende. Leider unterstützt nomnoml sie nicht.

• Erinnert mich an graphviz.