Читать книгу Dojos für Entwickler - Stefan Lieser - Страница 26

Bei dieser Übung ging der Kern der Anwendung relativ leicht von der Hand. Die eigentliche Herausforderung lag in der dynamischen Benutzerschnittstelle. Jeder Datentyp verlangt andere Oberflächenelemente. Und der Anwender will seine Daten individuell strukturieren können.

Auch bei dieser Aufgabe zeigte sich wieder, wie wichtig es ist, sich vor der Implementierung ein paar Gedanken zur Architektur zu machen. Der erste Gedanke, das Erzeugen der Daten vom Speichern zu trennen, liegt auf der Hand und wurde in der Aufgabenstellung schon erwähnt. Doch wie geht man generell vor, wenn für eine Aufgabenstellung eine Architektur entworfen werden soll? Ganz einfach: Man malt den „kleinen König". Den gibt es immer, denn er ist schließlich derjenige, der die Anforderungen formuliert hat. Er ist der Grund dafür, dass das System überhaupt gebaut wird. Das zu implementierende System als Ganzes kann man auch sofort hinmalen. Damit liegt man nie verkehrt. Es ergibt sich damit das in Abbildung 1 gezeigte Bild.

[Abb. 1] SystemUmweltDiagramm, Version 1.

Das Diagramm nennt sich System-Um-welt-Diagramm, da es das System in seiner Umwelt zeigt. In der Umwelt des Systems gibt es immer mindestens einen Client, den kleinen König, der das System bedient. Bei manchen Systemen mag es mehrere unterschiedliche Clients geben, das spielt für den Testdatengenerator jedoch keine Rolle. Die zweite Kategorie von Elementen in der Umwelt stellen Ressourcen dar. Diese liegen außerhalb des zu erstellenden Systems und sollten daher in das System-Umwelt-Dia-gramm aufgenommen werden, denn unser System ist von diesen Ressourcen abhängig. Im Fall des Testdatengenerators sind als Ressourcen in der Umwelt CSV-Dateien und Datenbanken denkbar. Irgendwo müssen die generierten Testdaten schließlich hin. Folglich ergänze ich das System-Um-welt-Diagramm um diese Ressourcen. Das Ergebnis ist in Abbildung 2 zu sehen.

Komponente

Eine Komponente ist eine binäre Funktionseinheit mit separatem Kontrakt:

Binär bedeutet hier, dass die Komponente an den Verwendungsstellen binär referenziert wird. Es wird also bei der Verwendung keine Referenz auf das entsprechende Visual-Studio-Projekt gesetzt, sondern eine Referenz auf die erzeugte Assembly. Separater Kontrakt bedeutet, dass das Interface für die Komponente in einer eigenen Assembly abgelegt ist und nicht in der Assembly liegt, in welcher die Komponente implementiert ist. Daraus folgt, dass eine Komponente immer aus mindestens zwei Assemblies besteht, nämlich einer für den Kontrakt und einer für die Implementierung. Und natürlich gehören Tests dazu - also besteht jede Komponente aus mindestens drei Projekten.

[Abb. 2] System-Umwelt-Diagramm, Version 2.

Wer nun glaubt, ein solches Diagramm sei ein Taschenspielertrick, um Zeit zu schinden, ohne Nutzen für den Architekturentwurf, der irrt. Denn aus diesem Bild wird bereits deutlich, welche Komponenten mindestens entstehen müssen. Den Begriff Komponente verwende ich hier mit einer festen Bedeutung, siehe dazu die Erläuterungen im Kasten.

Der Kern des Systems sollte gegenüber der Umwelt abgeschirmt werden, weil das System die Umwelt nicht kontrollieren kann. Die Umwelt kann sich verändern. Es können etwa neue Clients hinzukommen oder auch zusätzliche Ressourcen. Folglich müssen auf der Umrandung des Systems Komponenten entstehen, die den Kern des Systems über definierte Schnittstellen gegenüber der Umwelt isolieren. Andernfalls würde der Kern des Systems immer wieder von Änderungen in der Umwelt betroffen sein und wäre damit sehr anfällig. Und darin liegt die Bedeutung des System-Umwelt-Diagramms: Es zeigt, welche Komponenten das System von der Umwelt abschirmen.

Für Clients, die das System verwenden, bezeichnen wir die Komponente, über welche der Client mit dem System interagiert, als Portal. In Abhängigkeitsdiagrammen werden Portale immer als Quadrate dargestellt. Die Interaktion des Systems mit Ressourcen erfolgt über Adapter. Diese werden durch Dreiecke symbolisiert. Im konkreten Fall des Testdatengenerators können wir aufgrund des System-Umwelt-Diagramms also schon vier Komponenten identifizieren, siehe Abbildung 3:

 Portal,

 CSV-Adapter,

 Datenbank-Adapter,

 Testdatengenerator.

[Abb. 3] System-Umwelt-Komponenten.

Die Komponenten sollten normalerweise allerdings nicht im System-Umwelt-Diagramm eingezeichnet werden, weil dort sonst zwei Belange vermischt werden. Es soll hier nur gezeigt werden, dass sich Portal und Adapter immer sofort aus dem Sys-tem-Umwelt-Diagramm ergeben. Aus dem in Abbildung 3 gezeigten Diagramm lässt sich das in Abbildung 4 gezeigte Abhängigkeitsdiagramm ableiten.

[Abb. 4] Abhängigkeitsdiagramm.