b2aat6n

Testdaten automatisch generieren
Tückisches GUI
A
uch 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.
Das Diagramm nennt sich System-Umwelt-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-Diagramm
aufgenommen werden, denn unser
System ist von diesen Ressourcen abhän-
gig. 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-Umwelt-Diagramm
um diese Ressourcen. Das
Ergebnis ist in Abbildung 2 zu sehen.
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 wel-
LÖSUNG
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.
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. 1] System-
Umwelt-
Diagramm,
Version 1.
[Abb. 2] System-Umwelt-Diagramm, Version 2.
che 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.
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 System-Umwelt-Diagramm
ergeben. Aus dem
in Abbildung 3 gezeigten Diagramm lässt
sich das in Abbildung 4 gezeigte Abhängigkeitsdiagramm
ableiten.
Den Kern zerlegen
Nachdem ich diese Komponenten identifiziert
hatte, habe ich die Aufgabenstellung
www.dotnetpro.de dotnetpro.dojos.2011 15