Siegen Universität-Gesamthochschule
Siegen
| Uni-GH Siegen | FB Elektrotechnik und Informatik | UniPlaner |
Abschließend werden nun beide Prototypen kritisch beleuchtet. Was spricht jeweils für die beiden Konzepte, was dagegen? Wie sieht es mit der Praxistauglichkeit aus? Welcher Ansatz hat das höchste Entwicklungs-Potential? Die Antworten finden sich in der folgenden Auseinandersetzung mit den Prototypen. Mit Verweisen auf ähnliche Arbeiten zum Thema "Werkzeugunterstützung für Entwurfsmuster" endet das Kapitel.
Betrachtet man das Entwurfsmuster-Werkzeug aus dem Hause IBM einmal kritisch, so ist zunächst festzustellen, daß es sich um einen Prototypen handelt, der schon sehr weit gereift ist und schon erfolgreich einsetzbar ist. Interessant ist, daß die Anwender den Prototypen bereits einsetzen können, während dieser von seinen Entwicklern noch weiter ausgebaut wird. Außer dem Browser, der ein beliebiger Standard-HTML-Browser sein muß, befindet sich keine Komponente auf dem Rechner des Anwenders. So kann am Prototypen weitergearbeitet werden und der Anwender profitiert sofort von Änderungen und Erweiterungen. Für die Entwickler ergibt sich die Möglichkeit, vom Anwender sofort ein Feedback über die Weiterentwicklung des Prototypen zu erhalten. Überhaupt ist das System sehr flexibel, denn Modifikationen können schnell getätigt werden und betreffen jeweils nur kleine, überschaubare Bereiche des Systems. Schließlich verläßt man sich im wesentlichen auf bereits ausgiebig erprobte Komponenten.
Für den Benutzer ist das "Spielen" mit dem Werkzeug sehr interessant. Er kann verfolgen, wie auf Knopfdruck aus den abstrakten Konzepten Source-Code entsteht und sieht, wie die Veränderung der Parameter sich auf die Code-Generierung auswirkt. Durch die Möglichkeit, eine main()-Funktion anzugeben, kann er den erzeugten Code gleich ausprobieren und dann in sein Projekt einbinden.
Das Einbinden des Codes muß allerdings auf wenig elegante Art und Weise geschehen: durch Cut&Paste. Der Code wird im HTML-Browser ausgeschnitten und in ein bestehendes Projekt kopiert bzw. aus dem Browser heraus gespeichert, um dann als separate Datei zur Verfügung zu stehen. Diese Vorgehensweise setzt voraus, daß der Benutzer weiß, was er ausschneiden und wo er es einfügen muß. Außerdem ist es nötig, den Code nach einer Änderung wieder erneut im Projekt einzufügen – eine automatische Aktualisierung ist nicht möglich, da Werkzeug und Projektumgebung voneinander getrennt sind.
Für dieses Problem existiert bisher noch keine Lösung – aber die Autoren nennen ein Ansatz: Das Werkzeug könnte jeweils eine Core Klasse und eine Core Unterklasse erzeugen. Die Core Klasse enthält dann den erstellten Code und die Core Unterklasse erbt zunächst nur die Eigenschaften dieser Core Klasse. Der Benutzer arbeitet dann mit der Core Unterklasse und macht hier seine individuellen Anpassungen und Erweiterungen. Möchte er die Code-Generierung noch einmal durchlaufen, dann überschreibt er die alte Core Klasse mit dem neu generierten Code. Seine Änderungen bleiben jetzt erhalten, da er weiterhin mit der Core Unterklasse arbeitet, die jetzt aber "automatisch" den neu erzeugten Code des Werkzeugs benutzt.
Die Flexibilität hat noch weitere Grenzen: Durch die Verwendung von HTML muß man eine Anzahl von Einschränkungen hinnehmen, wie z. B. die fehlende Unterstützung für Drag&Drop oder eben die fehlende Möglichkeit, geladene Seiten im Browser aufgrund von Benutzeraktionen zu modifizieren. Auch können keine "Settings" auf der Seite des Benutzers gespeichert werden, da dies in HTML nicht vorgesehen ist. Die Benutzung des Common Gateway Interfaces ist ein üblicher Weg, um einigen dieser Schwächen zu begegnen, aber besser bzw. eleganter wäre eine Unterstützung durch die Sprache selbst. So steht man vor der Frage, ob es nicht besser wäre, eine andere, leistungsfähigere Sprache zu benutzen. Für HTML spricht jedoch ganz klar die Verbreitung und somit die Möglichkeit, viele Benutzer zu erreichen.
Derzeit beschränkt sich das Werkzeug eindeutig auf das Erstellen von Source-Code aus Entwurfsmustern. Eine Hilfe für die Phasen Analyse, Design und Dokumentation oder für das Debugging der Anwendung ist noch nicht gegeben.
Da hat man sich an der Universität Utrecht eindeutig mehr vorgenommen. Deren Prototyp ist als vollwertiges CASE-Tool konzipiert, daß dem Anwender sowohl während der Arbeit am Design als auch bei der Implementierung wertvolle Dienste vollbringen soll. Auch Re-Engineering Aufgaben, die Dokumentationsaspekte mit einbeziehen, werden durch das Werkzeug bereitgestellt.
Der derzeit abgedeckte Entwurfsmuster-Katalog ist mit zwölf GoF-Mustern noch sehr klein, kann aber leicht erweitert werden. Man ist bei diesem Werkzeug nicht so sehr von der Größe des Entwurfsmuster-Kataloges abhängig, denn die Musterunterstützung ist nur ein Teil des Werkzeugs, dessen Benutzung dem Anwender nahegelegt wird, ihm aber nicht aufgezwungen wird. Die Autoren hielten die Erstellung von Anwendungen ausschließlich aus dem Inhalt eines solchen Kataloges grundsätzlich nicht für praktikabel.
Die Funktionen, die bisher angeboten werden, sind schon sehr vielversprechend. Gerade das Binden von Design-Elementen an die Elemente eines Musters und die damit mögliche Fehlererkennung und –behandlung sind Eigenschaften, welche den Einsatz von Entwurfsmustern in der Software-Entwicklung stark unterstützen. Das Werkzeug ist dadurch u. a. in der Lage, viele Fehler des Anwenders zu erkennen und zu beheben bzw. eine Behandlungsart vorzuschlagen. Diese Funktionalität ist von großem Nutzen, um meist unbeabsichtigte Verletzungen einer Musterinstanz zu vermeiden.
Als größte Leistung der Entwickler ist sicherlich das Datenmodell zu nennen, das eine solide Grundlage für die darauf arbeitenden Werkzeuge darstellt. Aufgrund seiner Flexibilität kann es relativ problemlos erweitert werden, um zukünftige Funktionen zu ermöglichen.
Es gibt aber einige "Baustellen", an denen noch viel Arbeit investiert werden muß. Die Fähigkeiten des OMT-Werkzeugs müssen bzgl. Handhabung und Funktionalität noch stark erweitert werden, wenn man an die Leistung kommerzieller Werkzeuge anknüpfen möchte. Aber vor allem an den Werkzeugen Fragment Browser und Fragment Inspector ist noch einiges zu tun. Möchte man diese Werkzeuge bei einem Projekt einsetzen, so wird man schnell an die Grenzen ihrer Leistungsfähigkeit stoßen. Schon kleinere Projekte ergeben sehr große Graphen. Man wird sehr schnell die Übersicht über das Aufkommen an Klassen, Mustern etc. verlieren, wenn die einzige Abstraktionsmöglichkeit für die Entwurfsmuster-Ebene durch diese beiden Werkzeuge gegeben ist. Auch ihre Handhabung ist derzeit noch recht umständlich.
Für die Zukunft hat man sich vorgenommen, die Funktionalität des Prototypen stark zu erweitern. Die Verbesserung der Darstellungsmöglichkeiten des OMT-Werkzeugs ist nur ein Projekt. Zusätzlich will man die Gewinnung von Design-Informationen aus Programmen verbessern, welche in das System eingeladen wurden. Derzeit werden nur die Informationen angezeigt, die direkt aus dem Smalltalk Code entnommen werden können.
Eine Erweiterung auf die Sprachen C++ und Java ist ebenfalls angedacht. Sehr interessant klingt auch das Vorhaben, Vorkommnisse von Mustern in Programmen automatisch zu erkennen. Die Entwickler geben allerdings an, daß dieses Vorhaben sehr schwierig zu realisieren ist, da z. B. viele Informationen eines Musters bei der Umsetzung in Source-Code verloren gehen und es somit schwierig wird, innerhalb eines Stück Codes ein Mustervorkommen zu finden.
Zusammenfassend läßt sich feststellen, daß die Entwickler der beiden Prototypen sich unterschiedlich hohe Ziele gesteckt haben und beide Gruppen zur Erreichung dieser Ziele noch eine Menge Arbeit vor sich haben. Das Werkzeug der Budinsky-Gruppe beschränkt sich alleine auf die Entwurfsmuster-Ebene. Der Benutzer kann bei seiner Projektarbeit die Software als zusätzliches Werkzeug neben seiner gewohnten Entwicklungsumgebung einsetzen. Man muß allerdings feststellen, daß der Erfolg des Werkzeugs stark von der Größe des zugehörigen Muster-Kataloges abhängig ist. Bisher sind nur wenige Muster aus dem GoF-Buch eingearbeitet worden, aber die Entwicklung einer Software, nur aus den vorhandenen Mustern, würde eine Zahl von Entwurfsmustern erfordern, die weit über den Umfang des GoF-Buches hinausgeht. Fraglich, ob sich das umsetzen läßt. Dennoch stellt das Werkzeug in seiner Form eine – wenn auch noch kleine – Bereicherung für die Software-Entwicklung dar.
Der weitaus umfangreichere Ansatz der Utrechter verfügt derzeit über eine deutlich geringere Anwendbarkeit, steht aber auf einer sehr soliden Basis, die ein hohes Entwicklungspotential besitzt. Die Ausarbeitung des einheitlichen Datenmodells hat offensichtlich eine Menge Arbeit bereitet und dient jetzt als Grundlage für die darauf aufbauenden Entwicklungen. Hier kann eine Software-Entwicklungsumgebung entstehen, welche die bisherigen von anderen CASE-Werkzeugen umgesetzten Konzepte übernimmt und darüber hinaus eine nahtlose Integration von Entwurfsmustern schafft.
Das Musterkonzept hat sich erfolgreich durchgesetzt und wurde auf breiter Front angenommen. Aber die Entwicklung von Entwurfsmuster-Werkzeugen steht noch ganz am Anfang. Die beiden vorgestellten Ansätze sehen jedoch schon recht vielversprechend aus und lassen auf leistungsfähige Werkzeuge hoffen, welche dann Entwurfsmuster in Zukunft als festen Bestandteil in die Software-Entwicklung integrieren. Den Autoren von [4] ist dies ein erklärtes Ziel:
We want to introduce patterns as first-class
citizens
in an integrated OO development environment.
Die bisherige Entwicklungsarbeit der Utrechter basiert u. a. auf den Arbeiten von Marco Meijers über Werkzeugunterstützung für Entwurfsmuster (siehe [11]) und der Arbeit von Pieter van Winsen (siehe [12]), der sich mit der Anwendbarkeit von Objektorientierten Entwurfsmustern im Re-Engineering von Software beschäftigt hat.
Ebenfalls von Interesse sind die Code Patterns, die von der Firma Quintessoft propagiert werden. Beim Code Navigator for C++ handelt es sich um ein Werkzeug, das den Einsatz von speziellen Mustern erlaubt, die aber eher auf einer konzeptionell unteren Ebene anzusiedeln sind. So erreicht man beispielsweise durch Anwendung des Canonical Class Code Pattern auf eine Klasse, daß diese Klasse einen Standard-Konstruktor, einen Copy-Konstruktor, einen virtuellen Destruktor und einen Zuweisungs-Operator bekommt. Das System läßt sich durch Hinzufügen von eigenen Code Patterns beliebig erweitern.
Die Firma Code Farms hat einen anderen Ansatz gewählt. Sie stellt dem Anwender eine Pattern Template Bibliothek zur Verfügung, die aus speziellen C++-Templates besteht. Diese parametrierten Klassen implementieren einige der GoF-Muster. Der Anwender kann Ausprägungen eines Muster erzeugen, indem er bei der Instanziierung einige Parameter angibt und so das Muster für einen Anwendungsfall anpaßt.
Interessant sind in diesem Zusammenhang noch die folgenden Arbeiten, die im Gegensatz zu [4] und [8] den Dokumentationsaspekt von Entwurfsmustern in den Vordergrund stellen. In [5] beschreiben die Autoren, wie Entwurfsmuster nachträglich zur Dokumentation von großen Frameworks eingesetzt werden können. Der Beitrag [6] behandelt die Möglichkeiten der Software-Dokumentation durch den konsequenten Einsatz von Entwurfsmustern während der Design-Phase. Dieses Konzept wird anhand eines konkreten Projekts vorgestellt, das in Zusammenarbeit mit der SAP AG durchgeführt wurde.
[Titel][Vorwort][Inhalt][Kapitel 1][Kapitel 2][Kapitel 3][Kapitel 4][Literatur]
© Wintersemester 97/98 by Sascha Meyer