3 Verwendete Notation

Die in diesem Buch gewählte Notation für Entwürfe besteht aus wenigen Symbolen. Das macht die Entwürfe leicht verständlich. Vor allem soll es Teams ermutigen, gemeinsam zu entwerfen. Wenn vor dem gemeinsamen Entwurf zunächst umfangreiche Symbolbibliotheken erlernt werden müssen, steht dies der Teamarbeit im Weg. Ferner ist durch die Verwendung weniger, einfacher Symbole kein Software-Werkzeug erforderlich: Papier und Stifte oder ein Whiteboard genügen völlig.

Die Notation besteht aus drei Symbolen für Funktionseinheiten sowie zwei unterschiedlichen Verbindungen. Mit einer der Verbindungen werden Abhängigkeiten zwischen zwei Funktionseinheiten notiert, mit der anderen Datenflüsse. Die überwiegende Anzahl der Beispiele im Buch benötigen lediglich die Abhängigkeitsverbindung. Im nächsten Kapitel Die Lösung am Beispiel finden Sie ein umfangreicheres Beispiel, in dem die Notation verwendet wird.

3.1 Funktionseinheiten

Funktionseinheiten können in drei Ausprägungen vorliegen, je nachdem zu welchem Aspekt der darin enthaltene Code gehört:

• Portal
• Adapter
• Logik

Als Aspekt wird hier eine Menge von zusammengehörigen Eigenschaften bezeichnet, die sich getrennt von einer anderen Menge von Eigenschaften verändern. Es dient der Verständlichkeit und somit der Evolvierbarkeit, wenn Aspekte in Softwaresystemen getrennt werden. Die drei Ausprägungen Portal, Adapter und Logik sind für drei so fundamental unterschiedliche Aspekte verantwortlich, dass es wichtig ist, diese schon im Entwurf anhand unterschiedlicher Symbole zu unterscheiden.

3.1.1 Portal

Ein Portal ist eine Funktionseinheit, deren Aufgabe die Interaktion mit dem Client ist. Der Begriff Client ist hier sehr weitgehend gemeint. Es kann damit ein Anwender bezeichnet sein, der mithilfe einer grafischen Benutzeroberfläche mit dem System interagiert. In dem Fall wäre das Portal vielleicht mit WPF oder WinForms realisiert. Im anderen Fall kann es aber auch ein Anwender mit einer Konsolenschnittstelle sein. Tatsache ist in beiden Fällen, dass das Portal von einem bestimmten API wie beispielsweise WPF, WinForms oder Console abhängt.

Eine andere Ausprägung von Client kann aber auch ein WebService sein. In dem Fall stellt die WebService Schnittstelle das Portal gegenüber dem Client dar. Hier ist das Portal dann von einem API wie beispielsweise WCF abhängig.

3.1.2 Adapter

Mit einem Adapter tritt das Softwaresystem mit seiner Umwelt in Kontakt. Auch hier besteht eine Abhängigkeit zu einem API. In der Regel ist ein Adapter von einem API abhängig, der sich um Ressourcen wie das Dateisystem, eine Datenbank, den Drucker, die Systemzeit, oder ähnliches kümmert. Wie auch das Portal dient der Adapter hier dazu, das Softwaresystem von der Umgebung zu kapseln. Im Gegensatz zum Portal ist beim Adapter jedoch das System der Client.

3.1.3 Logik

Der ganze Rest von Funktionseinheiten wird mit Logik bezeichnet. Dabei geht es in den meisten Fällen um die Geschäfts- oder Domänenlogik in Abgrenzung zu ganz allgemeiner Logik.

3.2 Abhängigkeiten

Abhängigkeiten zwischen Funktionseinheiten werden durch eine Verbindungslinie mit einem Kuller am einen Ende dargestellt. Der Kuller weist auf die Unabhängige Funktionseinheit. Die folgende Abbildung zeigt, dass A von B abhängig ist, bzw. umgekehrt, dass B von A unabhängig ist.

Abhängigkeit: A ist abhängig von B

3.3 Datenflüsse

In vielen Fällen ist es hilfreich, zu verstehen, welche Daten zwischen Funktionseinheiten fließen. Mit Flow Design steht sogar eine vollständige Entwurfsmethode zur Verfügung, die sich ganz deutlich auf Datenflüsse konzentriert. Im Kontext dieses Buches über Komponentenorientierung werden Datenflüsse eine eher untergeordnete Rolle spielen. Nichtsdestoweniger wird die Notation hier eingeführt, um sie an geeigneter Stelle einsetzen zu können.

Datenflüsse werden durch Pfeile symbolisiert. Dabei fließen die Daten in Pfeilrichtung. In der folgenden Abbildung fließen die Daten von A nach B.

Datenfluss: Daten X fließen von A nach B

Am Pfeil wird notiert, um welche Art von Daten es sich handelt.