Tartan-Architektur – Muster dokumentieren

Was macht ein Schotte mit einer Kerze vor dem Spiegel? Er feiert den 2. Advent! Zu den Dingen, die jeder sofort mit Schottland in Verbindung bringt, gehören neben der angeblichen Sparsamkeit natürlich die bunt gewebten Karos [1]. Fraser, MacLeod, Campbell … – Jeder Clan hat seine eigenen Farben; Familien- oder Regimentszugehörigkeit wird durch das Tragen des gleichen Tartans signalisiert. Wer das Muster kennt, sieht sofort: Das ist ein MacDonald!

Auch in der Softwareentwicklung sind Muster (neudeutsch Pattern) sehr verbreitet; wir finden sie auf vielen Ebenen. Es gibt Analyse-, Architektur- und Entwurfsmuster, um nur einige Kategorien zu nennen. Gerade letztere (Design Patterns) haben einen hohen Bekanntheitsgrad und zählen zum Rüstzeug eines jeden, der objektorientierte Software entwirft. Mit Ihnen lassen sich nicht nur – falls angemessen – gute Lösungen reproduzieren. Die Kernidee der Lösung lässt sich mit dem Namen des Musters auch sehr effizient kommunizieren. Das setzt allerdings voraus, dass der Kommunikationspartner das Muster kennt. Aber auch dann sieht man im Klassendiagramm nicht sofort: Das ist ein Decorator! Unsere Entwürfe tragen keine Karos. Wie dokumentiert man also die Verwendung eines Softwaremusters?

Entwurfmuster werden auf der Ebene von Klassen und Schnittstellen eingesetzt. Die Dokumentation sollte eben dort erfolgen, und die einfachste Art, den Einsatz eines Musters gut kenntlich zu machen, ist ihn im Namen der Modellelemente zu verankern. Diese Technik ist auch bei der Benamsung in der Biologie sehr verbreitet. Was unterscheidet ein Hauspferd von einem Zebra? Klar, vor allem das einprägsame Muster. Was liegt also näher, als ein Merkmal, mit dem man eine Art erkennen kann, gleich im Namen zu benutzen? Die Tüpfelhyäne hat im Gegensatz zur Streifenhyäne Tüpfel, das Streifenhörnchen ebenfalls Streifen (wie das Zebra, das besser Streifenpferd heißen sollte). Auch wer noch nie einen Blaupunktrochen gesehen hatte – der Name transportiert bereits Information über das markante Äußere – man hat eine grobe Vorstellung. Teilweise werden auch Verhaltensmuster eingesetzt – besonders schön: Rückenschwimmender Kongowels. Die Verwendung von Mustern in Namen setzt auf den hohen Wiedererkennungswert, den diese haben.

Unter Ausnutzung des selben Effektes ist es bei einigen Entwurfsmustern ebenfalls hilfreich und auch sehr üblich, sie als Bestandteil im Namen beteiligter Klassen zu verwenden. Die Java-Klassenbibliothek zum Beispiel enthält nicht umsonst ca. 100 Elemente mit der Endung „Factory“. Auch bei Klassen wie DocumentBuilder (aus javax.xml.parsers) oder WebSphereDataSourceAdapter aus dem Spring Framework wird im Namen der Gebrauch eines Patterns angezeigt.

Das Benamsen mit Musteranteil ist nicht immer angebracht, und auch nicht immer so leicht möglich. Bei etwas umfangreicheren Mustern etwa spielen viele beteiligte Klassen mit, und nehmen unterschiedliche Rollen ein. Ab und an werden Muster in einem Entwurf kombiniert.

Für Entwurfsmuster bietet die UML eine reizvolle Möglichkeit, das Zusammenspiel von Klassen in Form eines Musters durch spezielle Modellelemente darzustellen. Zunächst wird das Muster als sogenannte Collaboration eingeführt, anschließend kann dessen Vorkommen (Collaboration Occurrence) im Entwurf verankert werden. Abbildung 1 zeigt als Ausschnitt eines Entwurfes ein entsprechendes Klassendiagramm. Die Musterverwendung wird als Ellipse dargestellt, und mit den beteiligten Klassen verbunden. An die Linien sind die Rollennamen, wie sie im Muster eingeführt wurden, notiert. Das Dokumentieren des Einsatzes von Entwurfsmustern lässt sich damit prima bewerkstelligen.

Abb. 1: Kennzeichnen des Einsatzes von Mustern in der UML2

Wie sieht es bei der Verwendung von Mustern anderer Kategorien oder Abstraktionslevel aus, vor allem bei Architekturmustern? Generell sollten Sie den Gebrauch eines Musters auf der Ebene dokumentieren, auf der es wirkt. Die Mittel dazu sind die gleichen wie bei Entwurfsmustern. Bei der Bildung von Schichten [2] kennt jeder die Benutzung des Namensteils „Layer“, etwa bei Persistence Layer. Auch andere Architekturmuster sind beliebte Namensgeber, wie Interceptor [3] oder Broker [2]. Und auch hier können Sie in entsprechenden Diagrammen die Verwendung analog zu den Entwurfsmustern „taggen“. Da Architekturmuster strukturbildend für das Gesamtsystem sind, macht es Sinn ihren Einsatz zu dokumentieren und im Team geeignet zu kommunizieren. Oft erfolgt dies in Form einer Architekturentscheidung [4]; die Verwendung spiegelt sich auch in den Sichten wider, allen voran in der Bausteinsicht.

Denn was passiert, wenn der Einsatz eines Architekturmusters nicht dokumentiert wird? Oder besser: Welche Gefahren birgt es, wenn die Verwendung nicht im Team bekannt ist? Zunächst einmal vergeben Sie die Chance, dass sich die Architektur Dritten rasch erschließt. Vor allem aber könnten Teammitglieder oder später Wartungskräfte aus Unkenntnis gegen die Architektur verstoßen. Die ursprüngliche Intention und Konsistenz geht dann verloren, und das System endet als Flickenteppich. Von „Es kann nur einen (Entwurf) geben“ keine Spur.

Links & Literatur

[1] Tartans of Scotland, http://www.tartans.scotland.net
[2] Buschmann et al., “Pattern-Oriented Software Architecture 1”, Wiley & Sons, 1996
[3] Buschmann et al., “Pattern-Oriented Software Architecture 2”, Wiley & Sons, 2000
[4] S. Zörner, “Historisch gewachsen? - Entscheidungen festhalten”, Java Magazin 4/2009

Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
“Tartan-Architektur – Muster dokumentieren”, Java Magazin, 08/2009, 2 Seiten, S. 69
(mit freundlicher Genehmigung)