Die UML-Diagramme, die Architekten noch verwenden

Was UML ist und wo sie heute steht

Die Unified Modeling Language (UML) ist eine universelle grafische Sprache zur Beschreibung von Struktur und Verhalten von Software. Sie entstand Mitte der 1990er-Jahre bei Rational Software aus der Zusammenführung der Methoden von Grady Booch, James Rumbaugh und Ivar Jacobson und wurde 1997 von der Object Management Group (OMG), einem Industriekonsortium für Standards, als Standard übernommen. UML 2.0 (2005) war eine größere Überarbeitung. Die aktuelle Version ist UML 2.5.1, im Dezember 2017 von der OMG veröffentlicht; die frühere UML 2.4.1 wurde zudem von der ISO als ISO/IEC 19505 (2012) veröffentlicht. Die Spezifikation definiert vierzehn Diagrammtypen, unterteilt in Strukturdiagramme (etwa Klassen-, Komponenten- und Deployment-Diagramme) und Verhaltensdiagramme (etwa Aktivitäts-, Zustands- und Sequenzdiagramme).

Der Ruf der UML hat sich erheblich gewandelt. In den späten 1990er- und frühen 2000er-Jahren wurde sie als Grundlage der modellgetriebenen Entwicklung propagiert, bei der detaillierte Modelle in Code umgewandelt werden sollten. Dieser Anspruch ist außerhalb spezialisierter Domänen weitgehend gescheitert, und viele Teams verbinden UML mit schwergewichtigen Prozessen und Diagrammen, die niemand las. Als Marian Petre für eine auf der ICSE 2013 vorgestellte Studie 50 professionelle Softwareentwickler befragte, gaben 35 an, UML überhaupt nicht zu verwenden, und die meisten anderen nutzten sie selektiv und informell; die meisten Teams zeichnen informelle Kästen und Linien statt strikter UML. Dennoch bleibt eine Handvoll UML-Diagrammtypen das beste verfügbare Werkzeug für bestimmte Fragen, besonders für Fragen zum Verhalten über die Zeit, und ihre Notation ist weithin verständlich. Ein Architekt braucht nicht alle vierzehn Diagrammtypen, sondern vielleicht sechs, bewusst eingesetzt.

Dieser Abschnitt behandelt diese sechs, jeweils mit einem kleinen Beispiel aus der Essenslieferplattform, die das ganze Kapitel begleitet. Er setzt das C4-Vokabular aus Abschnitt 4.3 voraus; beide lassen sich gut kombinieren, mit C4 für den strukturellen Überblick und UML dort, wo sich Präzision bei Schnittstellen, Interaktionen oder Zuständen bezahlt macht.

Skizze, Bauplan oder Programmiersprache

Martin Fowlers UML Distilled (3. Auflage, Addison-Wesley, 2003) und seine Essays aus demselben Jahr unterscheiden drei Arten, UML zu verwenden, eine Einteilung, zu der Steve Mellor unabhängig gelangte. Als Skizze wird UML informell und selektiv verwendet, um Ideen zu vermitteln: auf einem Whiteboard, bevor Code geschrieben wird (Vorwärtsskizze), oder um einen Teil eines bestehenden Systems zu erklären (Rückwärtsskizze). Nur die wichtigen Elemente erscheinen, die Notation wird locker befolgt, und das Diagramm wird oft weggeworfen. Fowlers eigene Zusammenfassung lautet comprehensiveness is the enemy of comprehensibility (Vollständigkeit ist der Feind der Verständlichkeit).

Als Bauplan dient UML dazu, vollständige, präzise Modelle zu erstellen, die jemand anderes implementiert, oder die aus bestehendem Code generiert werden, um ihn vollständig zu dokumentieren; es geht um Vollständigkeit, und meist braucht man Werkzeuge. Als Programmiersprache ist das UML-Modell detailliert genug, um in ausführbaren Code kompiliert zu werden, das Ziel der Model-Driven Architecture (MDA). Dieser Modus überlebt in einigen Nischen im Embedded- und sicherheitskritischen Bereich, oft über spezialisierte Profile und Werkzeuge, hat sich aber nicht durchgesetzt.

Für Architekten ist der Skizzenmodus der Normalfall und der Bauplanmodus die Ausnahme. Die nützliche Frage zu jedem Diagramm lautet: Wer wird es lesen, und welche Entscheidung oder welches Verständnis unterstützt es? Ein Sequenzdiagramm, skizziert, um sich darauf zu einigen, wie Zahlungsfehler behandelt werden, ist wertvoll, auch wenn es die Hälfte der Notation ignoriert. Ein vollständiges, von Hand gepflegtes Klassenmodell eines Service mit 200 Klassen ist es meist nicht.

Komponentendiagramme: Teile und ihre Schnittstellen

Ein UML-Komponentendiagramm zeigt modulare Teile eines Systems und vor allem ihre Schnittstellen. Seine charakteristische Notation ist „Ball und Socket“: ein kleiner Kreis an einem Stiel (eine bereitgestellte Schnittstelle, die die Komponente anbietet) und ein Halbkreis (eine benötigte Schnittstelle, die jemand anderes bereitstellen muss). Sitzt ein Ball in einem Socket, sind die beiden Komponenten über diese Schnittstelle verbunden. Abhängigkeiten sind gestrichelte Pfeile, optional beschriftet mit einem Stereotyp wie «use».

Genau das interessiert Architekten, wenn sie Abhängigkeitsrichtung und Austauschbarkeit zeigen wollen. Im Beispiel hängt die Bestellkomponente nicht direkt vom Zahlungsanbieter ab; sie benötigt eine Schnittstelle PaymentPort, die ein separater Zahlungsadapter implementiert. Das ist das Denken in Abhängigkeitsumkehr und Ports and Adapters aus Kapitel 3, sichtbar gemacht: Einen anderen Zahlungsanbieter einzusetzen bedeutet, einen neuen Adapter zu schreiben, nicht die Bestellkomponente zu ändern. Ein C4-Komponentendiagramm kann dieselben Teile zeigen, unterscheidet aber nicht zwischen bereitgestellten und benötigten Schnittstellen.

Deployment-Diagramme: Knoten und Artefakte

Ein UML-Deployment-Diagramm zeigt die physische oder virtuelle Infrastruktur und was darauf läuft. Seine Elemente sind Knoten, als dreidimensionale Kästen gezeichnet, also Rechenressourcen: ein «device» wie ein Smartphone oder Server oder eine «executionEnvironment» wie ein Betriebssystem, eine Container-Laufzeit oder ein Kubernetes-Cluster; Knoten können verschachtelt sein. Artefakte, gezeichnet als Rechtecke mit einem Dokumentsymbol und dem Stereotyp «artifact», sind die physischen Dateien, die deployt werden: ein JAR, ein Container-Image, ein App-Bundle, eine Konfigurationsdatei. Linien zwischen Knoten sind Kommunikationspfade, beschriftet mit Protokollen.

Deployment-Diagramme sind Zuordnungssichten im Sinne des SEI (Abschnitt 4.2). Sie beantworten die Fragen des Betriebsteams: Wo läuft jeder Teil, wie viele Kopien, in welcher Region, welche Netzwerkpfade gibt es? Das Deployment-Diagramm von C4 deckt dasselbe Gebiet mit weniger formaler Notation ab; beides ist in Ordnung, solange es eines je wichtiger Umgebung gibt und es Replikate, Managed Services und Netzwerkgrenzen zeigt.

Sequenzdiagramme: wer wen in welcher Reihenfolge aufruft

Wenn Architekten nur ein einziges UML-Diagramm behalten, ist es meist das Sequenzdiagramm. Es zeigt, wie Beteiligte in einem Szenario über die Zeit interagieren. Die Beteiligten stehen oben nebeneinander, jeder mit einer gestrichelten senkrechten Lebenslinie; die Zeit läuft nach unten. Ein schmales Rechteck auf einer Lebenslinie, die Aktivierung (Ausführungsspezifikation), zeigt, wann dieser Beteiligte mit der Bearbeitung einer Nachricht beschäftigt ist.

Die Pfeilspitzen tragen Bedeutung. Eine synchrone Nachricht, bei der der Sender auf eine Antwort wartet, hat eine durchgezogene Linie und eine gefüllte Pfeilspitze. Eine Antwort hat eine gestrichelte Linie und eine offene Pfeilspitze. Eine asynchrone Nachricht, bei der der Sender weitermacht, ohne zu warten, hat eine durchgezogene Linie und eine offene Pfeilspitze. Das richtig darzustellen ist architektonisch wichtig: Ob der Bestellservice auf den Zahlungsanbieter wartet oder publiziert und weitermacht, bestimmt seine Latenz, seine Ausfallarten und seine Kopplung (siehe Abschnitt 0.6).

Kombinierte Fragmente ergänzen den Kontrollfluss: Ein Kasten mit der Beschriftung alt und mit Guards versehenen Abschnitten, getrennt durch eine gestrichelte Linie, zeigt Alternativen (if/else), opt zeigt einen optionalen Teil, loop eine Wiederholung und par parallele Abschnitte. Setzen Sie sie sparsam ein; ein Sequenzdiagramm mit verschachtelten Schleifen und Alternativen ist schlecht gezeichneter Code. Zeichnen Sie ein Diagramm je wichtigem Szenario, einschließlich der Fehlerszenarien, in denen das meiste architektonische Denken stattfindet.

Zustandsdiagramme: Lebenszyklen und Regeln

Viele Geschäftsobjekte haben einen Lebenszyklus: eine Bestellung, eine Zahlung, ein Abonnement, ein Versicherungsfall. Ein Zustandsdiagramm beschreibt ihn präzise. Zustände sind abgerundete Rechtecke; ein gefüllter Kreis markiert den Anfangs-Pseudozustand und ein Kreis mit Punkt (Bullseye) den Endzustand. Transitionen sind Pfeile, beschriftet mit event [guard] / action: dem Ereignis, das die Transition auslöst, einer optionalen Guard-Bedingung, die wahr sein muss, und einer optionalen Aktion, die unterwegs ausgeführt wird. Zustände können interne Verhaltensweisen haben, etwa entry / notify restaurant.

Zustandsautomaten sind öfter architekturrelevant, als man erwartet. Der folgende Bestelllebenszyklus wird von mehreren Services geteilt: Die Bestellung besitzt ihn, Disposition und Benachrichtigungen reagieren auf seine Transitionen, und das Supportpersonal kann einige davon auslösen. Sich in einem Diagramm auf die Zustände und die zulässigen Transitionen zu einigen, verhindert eine ganze Klasse von Bugs, bei denen ein Service eine Bestellung für storniert hält, während ein anderer einen Kurier losschickt. Das Diagramm legt auch Fragen offen, die Text verbirgt: Kann eine Bestellung storniert werden, wenn sie bereits in Zustellung ist? (Hier nein: Es gibt keine Transition von diesem Zustand nach Storniert.) Ist eine Erstattung eine Aktion an einer Transition oder ein eigener Lebenszyklus?

Aktivitätsdiagramme: Workflows und Parallelität

Ein Aktivitätsdiagramm ist ein Flussdiagramm mit präziser Semantik. Abgerundete Rechtecke sind Aktionen; Rauten sind Entscheidungen (mit Guards an den ausgehenden Flüssen) und Zusammenführungen; dicke Balken sind Gabelungen (Forks), die einen Fluss in parallele Flüsse aufteilen, und Vereinigungen (Joins), die auf alle eingehenden Flüsse warten, bevor es weitergeht. Partitionen, oft Swimlanes genannt, zeigen, wer oder was jede Aktion ausführt. Eine Schleife muss über eine Zusammenführungsraute zurückfließen: Zwei Flüsse, die direkt in eine Aktion gezeichnet werden, würden bedeuten, dass die Aktion wie ein Join auf beide wartet.

Architekten nutzen Aktivitätsdiagramme für Geschäftsprozesse und Workflows, die mehrere Teile eines Systems umspannen, besonders wo Parallelität und Verantwortung wichtig sind. Das Beispiel zeigt, dass Essenszubereitung und Kurierzuweisung parallel laufen, dass die Zuweisung so lange wiederholt wird, bis ein Kurier annimmt, und dass die Übergabe auf beides wartet. Das wirft sofort eine architektonische Frage auf: Was, wenn innerhalb von zwanzig Minuten kein Kurier annimmt, während das Essen fertig ist? Das Diagramm macht die Lücke sichtbar; die Antwort könnte eine Timeout-Transition, ein Kompensationsschritt oder eine Änderung am Bestelllebenszyklus sein. Langlaufende Workflows dieser Art werden oft als Sagas oder orchestrierte Workflows implementiert, behandelt in Kapitel 6.

Klassendiagramme, sparsam eingesetzt: das Domänenmodell

Das Klassendiagramm ist das bekannteste UML-Diagramm und dasjenige, das Architekten am sparsamsten einsetzen sollten. Jede Klasse eines Service von Hand zu zeichnen ist der Bauplanmodus in seiner am wenigsten nützlichen Form: Es ist binnen Wochen veraltet, und der Code sagt dasselbe präziser. Wo Klassendiagramme ihren Platz verdienen, ist das Domänenmodell: ein kleines Diagramm der zentralen Geschäftsbegriffe, ihrer Attribute und Beziehungen, über das Entwicklung, Produktmanagement und Fachexperten gemeinsam sprechen können. In der Begriffswelt des Domain-Driven Design (Kapitel 5) erfasst es die Ubiquitous Language eines Bounded Context.

Das Wesentliche ist überschaubar. Ein Klassenkasten hat einen Namen, Attribute und optional Operationen. Eine einfache Linie ist eine Assoziation, optional benannt, mit Multiplizitäten an jedem Ende (1, 0..1, 0..*, 1..*). Eine gefüllte Raute markiert eine Komposition: Die Teile gehören zu genau einem Ganzen und überleben es nicht, so wie Bestellpositionen zu einer Bestellung gehören. Ein hohles Dreieck markiert eine Generalisierung (Vererbung) und eine gestrichelte Linie mit offener Pfeilspitze eine Abhängigkeit. Multiplizitäten tragen echte Designentscheidungen: Order 1 to 0..1 Delivery besagt, dass eine Bestellung höchstens eine Lieferung hat, was ausschließt, eine große Bestellung auf zwei Kuriere aufzuteilen. Falls das Unternehmen das wollen könnte, ist das Diagramm der Ort, an dem die Frage auftaucht.

Wann UML zu viel ist und wann Präzision zählt

UML ist zu viel, wenn das Publikum sie nicht kennt und die Frage sie nicht braucht: Ein C4-Kontextdiagramm vermittelt Führungskräften mehr als ein UML-Anwendungsfalldiagramm, und eine Whiteboard-Skizze ist das richtige Werkzeug für eine Designdiskussion, die in einer Stunde vorbei ist. Sie ist zu viel, wenn Diagramme von Hand gepflegt werden, die man generieren könnte, und wenn strikte Notation in einer Skizze erzwungen wird, die dem Erkunden dient. Fowlers Beobachtung, dass die in UML 2 hinzugekommene Präzision vor allem den Nutzern von Bauplan und Programmiersprache dient und die Skizzierenden belastet, gilt nach wie vor.

Präzision zahlt sich aus, wenn Missverständnisse teuer sind. Schnittstellen zwischen Unternehmen sind der klarste Fall: Wenn das Essenslieferunternehmen einen Zahlungsanbieter oder das Bestellsystem einer großen Restaurantkette anbindet, baut jede Seite gegen die Beschreibung der anderen und entdeckt Unstimmigkeiten erst im Test oder in der Produktion. Ein präzises Sequenzdiagramm des Zahlungsablaufs, einschließlich Timeouts, Wiederholungen, Idempotenzschlüsseln und Webhooks, an die Schnittstellenspezifikation angehängt, ist eine günstige Versicherung. Regulierte und sicherheitskritische Branchen (Medizinprodukte, Bahn, Luftfahrt, Automobil, manche Finanzsysteme) verlangen oft eine Designdokumentation, die Prüfer von den Anforderungen bis zur Implementierung nachverfolgen können; formale UML oder ihr Verwandter aus dem Systems Engineering, SysML, ist dort verbreitet. Nebenläufigkeits- und Lebenszyklusregeln, die sich mehrere Teams teilen, wie die obigen Bestellzustände, profitieren von einer Notation, die jede Transition ausdrücklich verlangt. Und ausgelagerte oder verteilte Entwicklung, bei der die Umsetzenden den Autor eines Designs nicht ohne Weiteres fragen können, braucht Beschreibungen, die weniger Raum für Interpretation lassen.