Der IBM-Prototyp

Universität-Gesamthochschule Siegen

Bei IBM hat sich im letzten Jahr eine Gruppe von Entwicklern Gedanken gemacht, wie ein Werkzeug zur Integration von Entwurfsmustern in den Entwicklungsprozeß aussehen könnte. Herausgekommen ist dabei ein Prototyp, der größtenteils aus schon entwickelten Komponenten besteht und bereits in einem hausinternen Intranet im Einsatz erprobt werden konnte. Die eingesetzten Komponenten sind der Mosaic-Browser, ein PERL-Interpreter und der COGENT-Interpreter – doch dazu später mehr.

Das Konzept

Der Grundgedanke, den man mit diesem Werkzeug verfolgt, lautet: Wie kann man dem Anwender die Erstellung von Source-Code aus einem Entwurfsmuster vereinfachen oder sogar komplett aus der Hand nehmen? Das in GoF-Entwurfsmustern enthaltene Code-Beispiel ist üblicherweise erst nach einem Verfeinerungsschritt einsetzbar, den der Entwickler bisher selbst leisten mußte. Manche Entwickler empfinden diesen Schritt als schwierig, für andere ist er zwar einfach zu vollziehen, jedoch empfinden sie es als ärgerlich, wenn sie ihn mehrfach durchführen müssen, da kleinere Design-Änderungen den bereits erstellten Code entbehrlich machen und eine Re-Implementierung erfordern. Das Werkzeug soll dem Entwickler eben diese Tätigkeit abnehmen; er muß dazu vor der Code-Generierung nur einige notwendige Informationen spendieren. Budinsky spricht hier von dem Hinzufügen sogenannter Benutzer-spezifischer Informationen und globaler Generierungs-Vorgaben.

Um Code generieren zu können, muß man dem Entwickler zunächst einen Katalog von Entwurfsmustern anbieten, aus dem er Muster wählen kann. Man hat sich dazu entschlossen, die Muster in HTML zu präsentieren. Die GoF-Muster legen eine solche Vorgehensweise nahe, denn sie enthalten textuelle Beschreibungen, Diagramme und Verweise auf andere Muster – alles Elemente, die sich prima in HTML erstellen lassen. Ein solches HTML-Muster besteht nun aus einer Seite für jeden Muster-Abschnitt, die den Text und ggf. die Diagramme eines Muster-Abschnitts aus dem Buch wiedergibt.

Positiver Nebeneffekt: Durch die Verwendung von HTML lassen sich die textuellen Verweise auf andere Muster im Abschnitt Verwandte Muster in Hypertext-Links wandeln, womit diese Muster per Mausklick erreichbar werden. Dieses Konzept wurde noch an weiteren Stellen umgesetzt; so kann man von jeder Seite eines Musters nicht nur alle anderen Abschnitte erreichen, sondern auch zu den Seiten eines beliebigen anderen Musters wechseln.

Anschauen kann man sich die Seite mit jedem beliebigen Browser, wobei Budinsky offenbar den bekannten Mosaic-Browser favorisiert. Auf diese Weise ersparten sich die Entwickler eine Menge Arbeit, konnten sie doch auf eine bestehende und erprobte Anwendung zurückgreifen und mußten nicht "das Rad neu erfinden".

Die Code-Generierung

Es gibt jedoch einen gravierenden Unterschied zum originalen Aufbau der Muster: Zu den Muster-Abschnitten wurde ein Code-Generation-Abschnitt hinzugefügt, der ebenfalls eine eigene Seite in Anspruch nimmt. Dort findet sich unter der Bezeichnung Goal eine Auswahlliste (siehe Abbildung 2.1, alle Darstellungen des Werkzeugs wurden [8] entnommen), von der verschiedene Aktionen gestartet werden können.

Abbildung 2-1: Auswahlliste Goal

Unter dieser befinden sich Eingabemöglichkeiten z. B. für die Bezeichner von Klassen, die zum Muster gehören. Dies ist eine erste Möglichkeit, Anwender-spezifische Informationen für die Code-Generierung anzugeben. Weitere Angaben kann man machen, wenn man in der Auswahlliste Choose implementation trade-offs auswählt. Für das Muster Composite erhält man beispielsweise die Seite, die Abbildung 2-2 zeigt.

Abbildung 2-2: Vorgaben für Implementierung

Hier können Vorgaben bzgl. der Implementierung gemacht werden, wie etwa die Verwendung einer Datenstruktur Liste anstatt Feld. Wählt man die Option Choose generation options aus der Auswahlliste, so kann man globale Vorgaben für die Code-Generierung angeben, die unabhängig vom gerade ausgewählten Muster beachtet werden. Dazu zählen Angaben wie die Beschränkung der Dateinamen auf das DOS-typische 8+3 Format oder auch die Angabe einer selbstgeschriebenen Funktion main( ), die bei der Generierung mit eingebaut wird, so daß der erzeugte Code gleich ausprobiert werden kann. Auch läßt sich hier über die letzte Option der Liste ein Beispiel anzeigen.

Die beiden ersten Optionen in der Liste sind Generate declarations und Generate implementations mit denen die eigentliche Code-Generierung gestartet wird. Während die erste Option das C++-typische Headerfile mit den Deklarationen der Klassen und Methoden erzeugt, generiert letztere die dazugehörigen ausprogrammierten Methoden. Das Ergebnis wird im Browser angezeigt und kann über die Save As... Funktion vom Anwender gespeichert werden. Zur Verwendung des Codes ist dann das manuelle Einfügen in ein Projekt erforderlich.

Die Architektur

Soweit ein kurzer Überblick über Ausrichtung, Funktionsumfang und Bedienung des Werkzeugs, es folgt ein Blick unter die Oberfläche, der die zugrundeliegende Architektur enthüllt.

Die Abbildung 2-3 skizziert die Komponenten und ihr Zusammenwirken. Der WWW-Browser Mosaic nimmt dabei eine Schlüsselposition ein, da er die Schnittstelle zwischen dem Anwender und dem eigentlichen Werkzeug darstellt, das aus den beiden Interpretern sowie einer Reihe von Skripten besteht. Der Browser kann die in HTML Form abgelegten Muster anzeigen und erlaubt das Navigieren in diesem Muster-Katalog.

Abbildung 2-3: Zusammenwirken der Komponenten

Jedoch ermöglicht die HTML Spezifikation nicht das Generieren von neuen Seiten oder das Modifizieren bereits geladener Seiten als Reaktion auf die Eingaben eines Benutzers. Möchte man lediglich in den Mustern blättern, stellt dies kein Problem dar. Aber sobald der Benutzer den Code-Generation-Abschnitt eines Musters aufruft, wird die Darstellung abhängig von den Vorgaben, die er macht bzw. im Vorfeld (z. B. durch globale Vorgaben) gemacht hat. Es ist nicht sinnvoll, für alle möglichen Variationen von Benutzereingaben eine statische HTML Seite zu generieren und auf Bedarf zu präsentieren – hier ist eine flexiblere Lösung erforderlich.

Dies wird durch Verwendung eines PERL-Interpreters erreicht, der über das CGI (Common Gateway Interface) angesteuert wird. Hier existiert für jedes Muster ein Skript, das die Vorgaben des Benutzers zur Generierung einer passenden HTML Seite verwendet, welche an den Browser zurückgegeben und von ihm angezeigt wird. Eine solche Vorgehensweise hat einen weiteren Vorteil: Es ist nun möglich, die Vorgaben eines Benutzers auf der Server-Seite zu speichern. Bevor der Benutzer eigene Vorgaben macht, präsentiert ihm das Werkzeug die Seiten aufgrund von Default-Vorgaben. Werden die Vorgaben von einem Benutzer geändert, so speichert der PERL-Interpreter sie in einer Datei, die bei der ersten Anmeldung des Benutzers erzeugt wurde. Bei einem späteren Besuch der Seiten findet der Benutzer alle von ihm getätigten Vorgaben wieder und muß sie nicht mühevoll aufs neue eingeben.

Um nun aber wirklich zu einem Muster Source-Code zu generieren ist noch ein weiterer Interpreter notwendig: Der schon vor einiger Zeit bei IBM entwickelte Interpreter COGENT (COde GENeration Template) ist ein Code Generator, der aufgrund von Skripten, welche die Bezeichnung Code Generation Descriptions tragen, Source-Code generieren kann. Dabei ist die Erzeugung nicht von einer konkreten Sprache abhängig. Möchte man anstatt C++ im folgenden Smalltalk verwenden, so müssen lediglich die Code Generation Descriptions modifiziert werden – nicht aber der Interpreter selbst.

Startet der Benutzer die Code Generierung, so wird zunächst wieder der PERL-Interpreter mit einem speziellen Skript aufgerufen. Anhand der Vorgaben des Benutzers wird durch den PERL-Interpreter ein passendes Skript für den COGENT-Interpreter ausgesucht und der Interpreter mit diesem Skript gestartet. Das Ergebnis wird schließlich in HTML gefaßt und an den Browser zur Darstellung übergeben. Der Benutzer kann jetzt den erzeugten Source-Code begutachten und bei Gefallen auf seinem Rechner speichern.

Bisher wurde noch eine Eigenschaft außer Acht gelassen: der Q&A-Link, der sich auf jeder HTML-Seite befindet. Mit einem Klick auf ihn kann der Benutzer die Entwickler des Werkzeugs kontaktieren und ihnen auf diese Weise eine Frage stellen. Die Antwort, die er dann erhält, kann aus Text, Diagrammen oder Hypertext-Links bestehen.

Die Zusammensetzung des Werkzeugs aus den drei Komponenten User Interface (ein beliebiger Browser beim Anwender), Mapper (ein PERL-Interpreter auf der Server-Seite) und Code Generator (der COGENT-Interpreter, ebenfalls auf der Server-Seite) bringt einige Vorteile, aber auch verschiedene Nachteile mit sich. Diese werden abschließend in Kapitel 4 gegenübergestellt, in dem auch der Prototyp der Universität Utrecht kritisch unter die Lupe genommen wird.

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