Komponentendiagramm-Beispiele

Jedes Diagramm unten benutzt dieselben drei Marken, und wer sie lesen kann, kann alle fünf lesen: eine Komponente ist ein Kasten mit dem Stecker-Icon, eine «interface» ist ein Kasten, der einen Vertrag benennt, und die Pfeile sagen, auf welcher Seite dieses Vertrags jede Komponente steht. Ein gestrichelter Pfeil mit hohlem Dreieck heißt ich implementiere das. Ein schlichter gestrichelter Pfeil heißt ich brauche das. Der volle Satz steht in den Komponentendiagramm-Symbolen, und die Überlegung hinter der Notation im Leitfaden zum Komponentendiagramm.

Sie sind danach geordnet, wie oft die Form auftaucht, nicht nach Komplexität. Jedes benennt die Frage, die es klärt, denn ein Komponentendiagramm, das nichts klärt, ist die häufigste und nutzloseste Art: fünf Kästen, fünf Pfeile und keine Aussage, der jemand widersprechen könnte.

Die Abbildung oben in diesem Artikel. Eine Web-Storefront und eine mobile App brauchen beide Produktdaten; ein Katalogdienst liefert sie. Die Schnittstelle ist einmal gezeichnet, zwischen ihnen.

Dieser eine Kasten ist der ganze Sinn des Beispiels. Bevor es ihn gab, hatten die beiden Clients zwei verschiedene Vorstellungen davon, was „der Katalog“ zurückgibt, und der Unterschied wohnte in dem, der als zweiter geschrieben wurde. ICatalog zu benennen erzwingt die Frage, was der Vertrag eigentlich ist, und ist er einmal benannt, ist eine Änderung daran sichtbar eine Änderung für zwei Konsumenten statt einer Bearbeitung eines Dienstes.

Lesen Sie die Pfeile und achten Sie darauf, was der Ordering core nicht berührt. Er hängt nicht von HTTP ab und nicht von PostgreSQL. Er realisiert einen Vertrag und benötigt einen anderen, und beides sind Kästen, die ihm irgendwer hätte reichen können.

Das ist die Form, die Leute mit hexagonaler Architektur, Ports und Adaptern oder Clean Architecture meinen, und ein Komponentendiagramm ist der billigste Weg zu prüfen, ob eine Codebasis sie wirklich hat. Zeigt der Kernkasten mit einem Pfeil auf eine Datenbankkomponente statt auf eine Schnittstelle, ist das Muster Wunschdenken: irgendetwas in der Mitte importiert den Treiber.

Das ist das Diagramm, das man vor einer Ablösung zeichnet, nicht danach. Die Aussage, die es macht, ist präzise und prüfbar: alles, was der Bestelldienst von der Abrechnung braucht, steckt in IBilling, also lässt sich eine zweite Implementierung dieser Schnittstelle einwechseln, ohne dass der Bestelldienst sich ändert.

Es ist auch der schnellste Weg herauszufinden, dass die Aussage falsch ist. Sagt jemand „der neue Dienst kann keine Rechnungs-PDFs“, dann waren Rechnungs-PDFs Teil des Vertrags und fehlen in der Schnittstelle, und das Diagramm war falsch, bevor die Migration es war. Dieses Gespräch kostet zehn Minuten am Whiteboard und drei Monate in Produktion.

Ist die alte Implementierung weg, löschen Sie sie aus dem Diagramm. Ein Komponentendiagramm, das zwei Jahre nach der Abschaltung noch den Mainframe zeigt, ist der Grund, warum Leute den Diagrammen nicht mehr trauen.

Topologisch ist das Beispiel drei mit einer dritten Implementierung, und bei dieser Ähnlichkeit lohnt es sich zu verweilen: Austauschbarkeit und Erweiterbarkeit sind dieselbe Zeichnung. Was sich unterscheidet, ist die Absicht. In einer Migration ist die zusätzliche Realisierung vorübergehend; in einer Plugin-Architektur ist sie das Produkt.

Die Lesetechnik, die sich hier auszahlt, ist, die rechte Spalte mit der Hand abzudecken. Was bleibt - der Host und IExporter- ist alles, was die Autorin eines vierten Exporters wissen muss. Verlangt die Antwort auf „kann ich meinen eigenen Exporter schreiben?“ das Lesen des Host-Quelltexts, ist die Schnittstelle unterspezifiziert, und das Diagramm hat Ihnen das gerade gesagt.

Zwei Dienste, jeder realisiert einen Vertrag, den der andere benötigt. Nichts hier ist illegales UML und nichts auf dem Diagramm ist falsch - die Zeichnung ist ein zutreffendes Bild eines Systems, das schwierig werden wird, und genau das soll ein Diagramm sagen können.

Ein Zyklus zwischen Komponenten heißt, dass keine für sich verstanden werden kann: kein unabhängiges Deployment, kein Test in Isolation ohne Stub der anderen, und ein Ersatz einer von beiden muss einen Vertrag erfüllen, von dem die andere gleichzeitig abhängt. Auf einem Klassendiagramm ist ein Zyklus ein Geruch; zwischen deploybaren Einheiten ist er ein Terminrisiko.

Die üblichen Abhilfen sind auf demselben Bild sichtbar. Verschieben Sie, was Shipping braucht, aus IOrders in ein Ereignis, das der Orders-Dienst publiziert, damit der Pfeil einseitig wird. Oder ziehen Sie den gemeinsamen Teil in eine dritte Komponente, von der beide abhängen, was den Zyklus in ein Zusammenlaufen verwandelt und Sie zurück zu Beispiel eins bringt.

Um eines davon gegen Ihr eigenes System zu zeichnen, steht die Schritt-für-Schritt-Fassung in wie man ein Komponentendiagramm zeichnet. Für den Ort, an dem diese Komponenten laufen, statt für das, was sie einander versprechen, ist ein Verteilungsdiagramm zuständig.