Muster und Werkzeuge

Universität-Gesamthochschule Siegen

Entwerfer setzen Entwurfsmuster ein, da sie von dem so konservierten Expertenwissen profitieren möchten. Der Mustereinsatz ist für sie mit einigen Vorteilen verbunden, von denen hier die wichtigsten genannt werden sollen. Aber es ergeben sich auch einige Probleme bei der Anwendung von Mustern. Diese sollen im folgenden erläutert werden. Schließlich werden zwei aktuelle Lösungsansätze vorgestellt, die sich der Problematik stellen.

Vorteile durch Entwurfsmuster

Wo liegen die Vorteile, die für einen Mustereinsatz sprechen? Nun, Muster verfolgen ganz allgemein den Gedanken der Wiederverwendung. Hier wird nicht nur Programmcode sondern vielmehr die Erfahrung von Experten wiederverwendet. Diese haben nach vielen Entwürfen für ein häufig auftretendes Problem eine gute Lösung gefunden, die sie schließlich in einem Muster festgehalten haben. Andere Entwickler können dann durch den Einsatz des Musters von dieser Erfahrung profitieren.

Wenn mehrere Entwickler mit Mustern arbeiten, entsteht zwischen ihnen ein gemeinsames Entwurfsmuster-Vokabular, das die Kommunikation zwischen den Entwicklern vereinfacht und fördert. Entwurfsmuster vereinfachen auch das Verständnis von Programmen. Entwickler können durch das Erkennen eines Musters im Design eines Programmes sofort einer ganzen Gruppe von Klassen (sogenannte Mini-Architektur) eine Bedeutung zuordnen und müssen nicht die Funktionsweise jeder einzelnen Klasse nachvollziehen, um auf die gemeinsam verwirklichte Funktion zu schließen.

Für Muster spricht auch die geradlinige Vorgehensweise bei ihrer Implementierung. Da Muster häufig OO-Konstrukte verwenden und mehr oder weniger detaillierte Code-Beispiele enthalten, ist die Übertragung des Musters in Programmcode für den Anwender zumeist gut nachvollziehbar. Er kann, geführt durch das Muster, den Code selbst erstellen und an seine Bedürfnisse anpassen.

Probleme bei der Anwendung

Doch etwas dämpft die Euphorie: Der Einsatz von Entwurfsmustern bedeutet derzeit für den Anwender reine "Handarbeit" – vorhandene CASE-Werkzeuge lassen ihn mit dem Wunsch nach Unterstützung völlig alleine! Die in den letzten Jahren von reinen "Malprogrammen" mit geringer Anwendbarkeit zu komplexen Werkzeugen weiterentwickelten Produkte kommen dem Wunsch nach Integration von Entwurfsmustern noch nicht nach.

Dabei hätte der Entwerfer Unterstützung nötig, denn das Benutzen von Mustern ist bei näherer Betrachtung mit einigen Handicaps verbunden, also gar nicht so einfach. Die Autoren von [4] identifizieren drei Schritte, die nacheinander vollzogen werden müssen, um ein Muster einzusetzen:

Zunächst muß ein Problem erkannt werden, dann kann für dieses Problem nach einem geeigneten Muster gesucht werden.
Das Muster muß in das bestehende Design integriert werden. Es müssen die Elemente (z. B. Klassen, Methoden etc.) im Design identifiziert werden, die eine Rolle in dem einzubringenden Muster spielen.
Durch die Verwendung eines Musters ergeben sich Constraints (deutsch: Beschränkungen) für das Design. Diese sollen sicherstellen, daß auch bei späteren Änderungen am Design das Muster noch korrekt angewendet wird.

Das Problem erkennen

Das Problem mag in vielen Fällen offensichtlich sein, eventuell braucht der Entwickler aber ein bestimmtes Maß an Erfahrung, um es zu erkennen. Hier kann ihm von einem Werkzeug nur schlecht geholfen werden. Nach der Aufdeckung des Problems gilt es ein Muster auszuwählen, das bei der Problemlösung behilflich ist. Doch die mittlerweile große Zahl von Entwurfsmustern macht es schwierig, den notwendigen Überblick über das vielseitige Angebot zu erlangen und zu behalten. Die Autoren von [2] taten gut daran, nur 23 Muster in ihren Katalog aufzunehmen. Diese relativ geringe Anzahl ermöglicht dem Leser den Überblick zu bekommen, so daß er gezielt im Buch nachschlagen kann, wenn er ein Muster anwenden möchte. Von den Autoren erhält er im Vorwort des Buches den Rat:

Denken Sie daran, daß dies kein Buch ist, das man einmal liest
und dann in ein Bücherregal stellt. Wir hoffen, daß Sie es immer
wieder aufschlagen werden, um sich in Ihren Entwürfen von ihm
inspirieren zu lassen.

In Zukunft wird es sicher noch mehr Muster für die verschiedensten Einsatzzwecke und Phasen in der Software-Entwicklung geben. Die fehlende Übersicht über das Angebot an Entwurfsmustern stellt aber nur ein Problem dar, daß dem Anwender den Einsatz von Mustern schon jetzt erschwert und noch weiter erschweren wird. Hier könnte ihm ein Werkzeug helfen, daß ihm einen Katalog von Mustern anbietet und ihm die Suche nach einem für sein Problem geeigneten Muster ermöglicht.

Das Muster umsetzen

Unterstützung durch ein Werkzeug brauchen Entwickler besonders bei der anschließenden Integration des Musters in sein Design. Für viele Entwickler ist es trotz des Beispiels-Codes, den viele Muster enthalten, schwierig, den Weg vom Muster zur ausprogrammierten Lösung zu beschreiten. Oft gibt es nicht die eine Möglichkeit zur Implementierung des Musters, sondern mehrere Möglichkeiten, deren Gestalt stark von den individuellen Vorgaben des Anwenders abhängig ist. Hat er eine Lösung ausgewählt, kann sie nach geringfügigen Änderungen am Design ungeeignet sein und er muß eine andere Lösung heranziehen. Das heißt, daß er das ins Design eingebrachte Muster unter Umständen wiederholt reimplementieren muß. Generell kann man sagen, daß Muster, die in ein Design eingebracht werden, dessen Architektur beeinflussen. Umgekehrt gilt aber auch: Die Architektur eines Designs beeinflußt die Art wie ein Muster angewendet wird.

Am einfachsten ist es, wenn alle Elemente des Designs für die Einbringung des Musters neu generiert werden können. Schwieriger wird es allerdings, wenn bereits vorhandene Elemente aus dem Design eine Rolle in dem neuen Muster übernehmen müssen – sicher die weit häufigere Situation. Diese Elemente erweitern dann ihre Verantwortung, was dokumentiert werden muß, damit sie bei späteren Änderungen am Design weiterhin ihre Rolle im Muster beibehalten. Eventuell müssen vorhandene Elemente an ihre neue Rolle im einzubringenden Muster angepaßt werden. Da grundsätzlich ein solches Element auch mehrere Rollen in verschiedenen Mustern spielen kann, könnten Änderungen dazu führen, daß ein vorher eingebrachtes Muster nicht mehr korrekt angewendet wird.

Die Constraints beachten

Um dies zu vermeiden bzw. zunächst einmal erkennen zu können, ist das Einbringen von Constraints notwendig. Diese Beschränkungen sollen definieren, wann ein Design einem Muster entspricht und wann nicht. Wird beispielsweise in der Klasse aConcreteSubject, die eine elementare Rolle im Observer Muster einnimmt, durch das Binden der Klasse an ein neues Muster eine Methode der Klasse verändert, so kann dies dazu führen, daß diese Klasse nicht mehr dem Observer Muster entspricht – solch drastische Auswirkungen könnten sich z. B. durch eine Veränderung der notify() Methode ergeben. Ohne Werkzeugunterstützung muß der Entwickler sich auf sein "geschultes Auge" verlassen und permanent das Design auf solche Fehler prüfen. Ein Werkzeug könnte diese Beschränkungen viel besser prüfen und auf ihre Einhaltung achten. Fehler könnten dem Entwickler mitgeteilt werden, damit er sie beheben kann – oder besser noch – vom Werkzeug automatisch korrigiert werden.

Mögliche Formen der Werkzeugunterstützung

Es ist an der Zeit dem Anwender Werkzeuge zur Hand zu geben, die Muster und ganz speziell Entwurfsmuster in den Entwicklungsprozeß integrieren und den Entwickler bei obigen Problemen unterstützen. Wie könnte nun eine zukünftige Werkzeugunterstützung für Entwurfsmuster aussehen? Welche Möglichkeiten gibt es, Muster in den Entwurfsprozeß zu integrieren? Diesen Fragen stellen sich derzeit zwei Prototypen, die eine solche Werkzeugunterstützung für Entwurfsmuster verwirklichen wollen. Man kann zwischen zwei Modellen unterscheiden:

Konzentration auf die Entwurfsmuster-Ebene: Der Entwickler kann Muster aus einem Katalog auswählen und sich nach Angabe verschiedener Parameter Code-Skelette vom Werkzeug bauen lassen. Diese kann er dann in sein Projekt integrieren.
Das Werkzeug unterstützt den Entwickler auf den Ebenen Entwurfsmuster, Design und Programmcode. Je nach gewählter Abstraktionsebene hat der Entwickler unterschiedliche Funktionen zur Auswahl, die auf einer gemeinsamen Datenmenge angewendet werden können. Zwischen den Sichten kann ohne Datenverlust gewechselt werden, da sich jeweils nur die Sichten auf die Daten und nicht die Daten selbst ändern.

Der erste Ansatz entstammt dem Forschungsteam um F. J. Budinsky, IBM. Dieser Ansatz ist sehr interessant, da hier mit verhältnismäßig geringem Entwicklungsaufwand ein brauchbares Werkzeug erstellt wurde. Das Tool hat allerdings einige offensichtliche Schwächen, wie z. B. die fehlende Integration in eine Software-Entwicklungsumgebung, überzeugt aber durchaus in einigen Belangen und besitzt schon einen recht hohen "Reifegrad".

Der andere Prototyp folgt dem zweiten Ansatz und wurde an der Utrecht Universität von Gerd Florijn und den Mitgliedern seiner Forschungsgruppe entwickelt. Der hier verfolgte, eher "ganzheitliche" Ansatz, stellt wesentlich höhere Anforderungen an das Werkzeug. Der Kern dieses Prototypen ist ein gemeinsames Datenmodell, das von verschiedenen spezialisierten Werkzeugen betrachtet und editiert werden kann.

Beide Ansätze werden nun im folgenden vorgestellt, wobei allerdings Details bzgl. ihrer Implementierung hier außen vor bleiben sollen. Die Autoren dieser Werkzeuge geben in ihren Veröffentlichungen [8, 4] einen tieferen Einblick in deren Aufbau.

[Titel][Vorwort][Inhalt][Kapitel 1][Kapitel 2][Kapitel 3][Kapitel 4][Literatur]