UML-Komponentendiagramme

Ein Komponentendiagramm beschreibt ein System als austauschbare Teile. Eine Komponente in UML ist nicht irgendeine Klasse - sie ist eine Einheit mit definierter Grenze, die sich im Prinzip gegen eine andere Implementierung derselben Verträge austauschen ließe, ohne dass die Umgebung es bemerkt.

In dieser Definition liegt der ganze Wert. Das Diagramm zwingt Sie, zu jedem Teil genau zwei Dinge aufzuschreiben: was es anbietet und was es benötigt. Diese beiden Listen sind der Vertrag des Teils mit dem Rest des Systems, und sie sind genau das, was man bei der Planung einer Migration, beim Zuschnitt einer Neuentwicklung oder bei der Frage, ob eine Servicegrenze richtig liegt, tatsächlich braucht.

Die Form Kugel und Pfanne (ball and socket) ist die kompakte und die, die die meisten Werkzeuge standardmäßig zeichnen: ein Lolli an einer Komponente ist eine angebotene Schnittstelle, eine Halbschale eine benötigte, und eine Kugel in einer Pfanne sind beide zusammengesteckt. Es ist dieselbe Information wie die Pfeile oben, auf weniger Platz. Nehmen Sie, was Ihre Leser leichter finden; bleiben Sie innerhalb eines Diagramms konsistent.

Jedes Zeichen, das diese Diagrammart tragen kann - beide Schnittstellennotationen, Assembly- und Delegationskonnektoren, Ports und die vier lohnenden Stereotypen - steht in Komponentendiagramm-Symbolen.

An dieser Frage bleibt jedes erste Komponentendiagramm hängen, und die Spezifikation hilft nicht: UML sagt, eine Komponente sei eine austauschbare Einheit mit definiertem Vertrag, und überlässt die Größe ganz Ihnen. Für einen Standard ist das die richtige Antwort und am Whiteboard eine nutzlose, also hier die Arbeitsregel.

Eine Komponente ist, was Sie ausschreiben könnten. Können Sie sich vorstellen, einem anderen Team die Listen der angebotenen und benötigten Schnittstellen zu geben und zu sagen „baut das, wir schauen nicht hinein“, ist es eine Komponente. Würde diese Übergabe ein Gespräch über Interna erfordern, liegt die Grenze falsch - und das ist der Befund, kein Zeichenproblem, das man umgehen müsste.

In der Praxis landet das meist auf einer dieser Ebenen, und welche es ist, sagt Ihnen, wozu das Diagramm dient.

• Ein bereitstellbarer Service. Ein Repository, eine Pipeline, eine Rufbereitschaft. Die häufigste Antwort bei allem aus dem letzten Jahrzehnt und die Ebene, auf der es sich lohnt, das Diagramm im Repository zu halten.
• Eine Bibliothek oder ein Modul. Innerhalb einer Bereitstellungseinheit, wenn über interne Struktur gestritten wird - welches Paket von welchem abhängen darf. Hier sagt ein Paketdiagramm oft dasselbe billiger.
• Ein ganzes System. Das Mainframe, das CRM, der Zahlungsdienstleister. Die Ebene für ein Kontextdiagramm, wo es darum geht, wovon Sie abhängen, nicht wie es gebaut ist.

Zwei dieser Ebenen auf einem Diagramm zu mischen ist der Fehler, der die wuchernden Komponentendiagramme erzeugt, an die sich Leute erinnern. Ein Bild mit drei Microservices, einer Hilfsbibliothek und „SAP“ sind drei übereinandergelegte Diagramme, und kein Leser erkennt, welche Kästen gleichrangig sind.

Die nützlichste Lesetechnik ist, eine Komponente mit der Hand zuzudecken. Was übrig bleibt, ist ihr Vertrag: die Schnittstellen, die an ihr hingen. Können Sie diese Liste einem anderen Team geben und sagen „baut etwas, das das erfüllt“, tut das Diagramm seine Arbeit. Können Sie das nicht - würde ein Austausch Wissen erfordern, das nicht gezeichnet ist - liegt die Grenze falsch, und das ist es wert, vor dem Versuch zu wissen.

Die zweite Technik ist, den benötigten Schnittstellen zu folgen. Jede ist eine Abhängigkeit, die jemand erfüllen muss, und ein Zyklus in diesem Graphen ist ein echtes Architekturproblem, das ein Komponentendiagramm sofort sichtbar macht.

Beide Techniken sieht man leichter angewandt als beschrieben. Fünf Diagramme von Systemen, an denen Sie vermutlich gearbeitet haben - ein gemeinsamer Katalog, Ports und Adapter, eine Altsystemablösung, ein Plugin-Host und ein Zyklus - sind in Komponentendiagramm-Beispielen durchgearbeitet, jedes mit dem Streit, den es schlichtet.

Fünf Diagrammarten sind Rechtecke, die mit Linien verbunden sind, und der Unterschied liegt ausschließlich darin, was ein Rechteck ist. Die falsche zu wählen ist hier der teuerste verfügbare Fehler, denn das Diagramm sieht gut aus und beantwortet eine Frage, die niemand gestellt hat.

Am häufigsten kommt Komponente gegen Verteilung auf, und ausgesprochen ist die Trennung sauber: eine Komponente ist eine logische Einheit, ein Knoten eine physische. Eine Komponente kann auf vierzig Knoten laufen; ein Knoten kann ein Dutzend Komponenten beherbergen. Sobald ein Kasten auf Ihrem Komponentendiagramm eine Region, eine Instanzzahl oder einen Hostnamen bekommt, ist er keine Komponente mehr und das Diagramm ist still zu zweien geworden.

Wer C4 kennt: dessen Container-Diagramm liegt fast genau dort, wo ein Komponentendiagramm auf Service-Ebene liegt, und dessen eigene „Komponenten“-Ebene liegt eine Stufe tiefer, als UML es üblicherweise meint. Die Vokabulare decken sich nicht - schreiben Sie also aufs Diagramm, welches Sie verwenden; diese eine Legendenzeile verhindert die meisten Streitigkeiten.

Komponentendiagramme altern gut, was ungewöhnlich ist. Schnittstellen ändern sich weit langsamer als der Code dahinter, ein eingechecktes Komponentendiagramm bleibt also viel länger wahr als ein Klassendiagramm desselben Systems - und lohnt entsprechend mehr, gepflegt zu werden.

1. Komponenten, die in Wahrheit Klassen sind. Lässt es sich nicht plausibel eigenständig austauschen, ist es keine Komponente. Nehmen Sie ein Klassendiagramm.
2. Nur angebotene Schnittstellen gezeichnet. Die benötigten tragen die Abhängigkeitsinformation, und das ist die nützlichere Hälfte.
3. Pfeile zwischen Komponenten ohne Schnittstelle. Ein nackter Pfeil sagt „hängt irgendwie ab“, und genau das soll dieses Diagramm präzisieren.
4. Verteilung hineingemischt. Server, Regionen und Container gehören auf ein Verteilungsdiagramm.
5. Schnittstellen nach dem Anbieter benannt. ILedger ist in Ordnung, solange es ein Ledger gibt; sobald zwei Implementierungen denkbar sind, benennen Sie den Vertrag nach der Fähigkeit, nicht nach dem aktuellen Lieferanten.