Ein Komponentendiagramm zeichnen

Bevor Sie irgendetwas zeichnen, schreiben Sie eine Liste. Nicht Ihrer Module, nicht Ihrer Ordner - der Teile des Systems, die man plausibel austauschen könnte: gekauft statt gebaut, von einem anderen Team neu geschrieben oder von jemand anderem betrieben.

Diese Frage ist der ganze Filter. Ein Ordner ist keine Komponente und eine Klasse auch nicht; ein Ding mit einer Grenze, das man einem Lieferanten übergeben könnte, schon. Das Reporting-System in diesem Artikel ergab vier: ein Dashboard, einen Scheduler, der Berichte über Nacht laufen lässt, den Report-Service selbst und einen Adapter, der mit dem Data Warehouse spricht.

Platzieren Sie die Teile und widerstehen Sie dem Verbinden. Jetzt Pfeile zu zeichnen heisst, sie zwischen Komponenten zu ziehen, und eine Linie vom Dashboard direkt zum Report-Service sagt nur „diese beiden sind irgendwie beteiligt“ - genau die Unschärfe, zu deren Beseitigung ein Komponentendiagramm existiert.

Das Layout ist hier dreissig Sekunden wert: Verbraucher auf die eine Seite, Anbieter auf die andere. Jedes Diagramm dieser Reihe ist von links nach rechts gezeichnet, mit Abhängigkeiten in eine Richtung, weil ein Leser die Richtung dann auf einen Blick prüft statt jeder Linie zu folgen.

Fragen Sie bei jedem Kasten, worauf sich jemand von aussen verlassen darf, und benennen Sie das. Hier IReports und IWarehouse - ein Vertrag pro Fähigkeit, nicht einer pro Verbraucher. Verbinden Sie ihn mit einer Realisierung: gestrichelte Linie, hohles Dreieck, auf die Schnittstelle zeigend.

In diesem Schritt passiert der eigentliche Entwurf, und genau ihn überspringen die Leute. Einen Vertrag zu benennen zwingt zur Entscheidung, was öffentlich ist, und der Streit, der folgt - „gehört der CSV-Export zu IReports oder nicht?“ - ist der Streit, den man führen sollte, bevor zwei Teams ihn im Code unterschiedlich beantworten.

Nun die zweite Hälfte, und die trägt die Information: welche Verträge braucht jede Komponente? Zeichnen Sie eine Abhängigkeit - gestrichelte Linie, offene Pfeilspitze - von der Komponente zur benötigten Schnittstelle. Das Ergebnis ist das Diagramm am Anfang dieses Artikels.

In dem Moment, in dem diese Pfeile landen, werden zwei Dinge sichtbar. Dashboard und Scheduler zeigen beide auf IReports, eine Änderung daran ist also sichtbar eine Änderung für zwei Verbraucher. Und der Report-Service zeigt auf IWarehouse statt auf den Adapter, der Adapter ist also austauschbar, ohne dass der Dienst es merkt - entweder war das Ihre Absicht, oder es ist eine Entdeckung, die man jetzt machen sollte.

Ein Komponentendiagramm ist fertig, wenn es diese übersteht. Sie dauern eine Minute, und jede hat öfter ein echtes Problem gefunden als sauber durchgelaufen zu sein.

1. Halten Sie einen Kasten mit der Hand zu. Was übrig bleibt - die daran hängenden Schnittstellen - ist die Spezifikation seines Ersatzes. Müsste ein Ersatz etwas wissen, das nicht auf dem Bildschirm steht, liegt die Grenze falsch.
2. Folgen Sie den Pfeilen auf der Suche nach einem Zyklus. Zwei Komponenten, die einander benötigen, lassen sich nicht unabhängig ausliefern, testen oder ersetzen. Das letzte der durchgearbeiteten Beispiele zeigt, wie das aussieht und wie man es aufbricht.
3. Prüfen Sie, dass jede Komponente mindestens eine Schnittstelle hat. Ein Kasten ohne alles ist entweder keine Komponente oder für dieses Diagramm nicht relevant.
4. Lesen Sie die Schnittstellennamen laut. Ist einer nach seinem aktuellen Anbieter statt nach seiner Fähigkeit benannt - IMainframeBilling statt IBilling -, steckt der Lieferant im Vertrag, und der Tausch, den das Diagramm verspricht, wird nicht so sauber wie er aussieht.

Die rechte Spalte ist keine Pedanterie über Diagrammarten. Jeder Punkt darauf macht das Bild grösser, ohne die Frage zu beantworten, für die das Diagramm gezeichnet wurde, und jeder gibt ihm einen zweiten Grund zu veralten: ein Komponentendiagramm übersteht einen Plattformwechsel unberührt, dieselbe Zeichnung mit zwei AWS-Regionen darauf nicht.

Ist die Zeichnung fertig, steht die Referenz zu jedem Zeichen darauf in Komponentendiagramm-Symbole, und die weitere Begründung, wann diese Diagrammart den Aufwand überhaupt lohnt, im Leitfaden zum Komponentendiagramm.