Erweiterung einer Entwicklungsumgebung zur flexiblen Definition ...

Erweiterung einer Entwicklungsumgebung 

zur flexiblen Definition, Verwaltung 

und Visualisierung von Entwurfsmustern 

und deren Dokumentation 

Diplomarbeit 

zur Erlangung des akademischen Grades eines 

Magisters der Sozial- und Wirtschaftswissenschaften 

Vorgelegt an der 

Johannes Kepler Universität Linz 

Eingereicht bei 

a. Univ.-Prof. Dr. Johannes Sametinger 

(Arbeitsgruppe Software Engineering 

am Institut für Wirtschaftsinformatik) 

Andreas Wöckl (9755009) 

Seebach 5 

A-4560 Kirchdorf an der Krems 

8. Oktober 2002

Andreas Wöckl Diplomarbeit Software Engineering 2002 I 

Eidesstattliche Erklärung 

Ich erkläre an Eides statt, dass ich die Diplomarbeit mit dem Titel "Erweiterung einer 

Entwicklungsumgebung zur flexiblen Definition, Verwaltung und Visualisierung von 

Entwurfsmustern und deren Dokumentation" selbstständig und ohne fremde Hilfe 

verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und alle 

den benutzten Quellen wörtlich oder sinngemäß entnommenen Stellen als solche 

kenntlich gemacht habe. 

Linz, den 8. Oktober 2002 

Andreas Wöckl

Andreas Wöckl Diplomarbeit Software Engineering 2002 II 

Inhaltsverzeichnis 

1 EINLEITUNG ...................................................................................................... 1 

1.1 Motivation ................................................................................................. 1 

1.2 Überblick................................................................................................... 2 

1.3 Gliederung................................................................................................. 3 

1.4 Schreibweise.............................................................................................. 4 

2 ENTWURFSMUSTER ........................................................................................ 5 

2.1 Definition .................................................................................................. 5 

2.1.1 Basiselemente................................................................................ 5 

2.1.2 Bestandteile................................................................................... 6 

2.2 Vorteile...................................................................................................... 8 

2.3 Nachteile.................................................................................................... 9 

2.4 Einteilung ................................................................................................ 10 

2.4.1 Buschmann.................................................................................. 10 

2.4.2 Gamma........................................................................................ 11 

2.4.3 Pree.............................................................................................. 12 

2.5 Programmiersprachen.............................................................................. 13 

2.6 Anti-Entwurfsmuster............................................................................... 14 

2.7 Zusammenfassung................................................................................... 15 

3 ERWEITERUNG DER ENTWICKLUNGSUMGEBUNG ECLIPSE.............. 16 

3.1 Exkurs: XML........................................................................................... 16 

3.1.1 Einführung .................................................................................. 16 

3.1.2 XML-Schema.............................................................................. 18 

3.1.3 Einsatz bei PSE-Admin............................................................... 20 

3.2 Eclipse ..................................................................................................... 20 

3.3 Plugins..................................................................................................... 21 

3.4 Inbetriebnahme von PSE-Admin ............................................................ 24 

3.4.1 Pfadstruktur................................................................................. 24 

3.4.2 Benötigte Komponenten ............................................................. 25 

3.4.3 Globale Konfigurationsdatei ....................................................... 26 


4 PSE-D - DEFINITION VON ENTWURFSMUSTERN.................................... 28 

4.1 Beispiel: Abstract Factory....................................................................... 28 

4.2 Rollen ...................................................................................................... 30

Andreas Wöckl Diplomarbeit Software Engineering 2002 III 

4.3 Struktur der Musterverwaltung ............................................................... 32 

4.4 Entwurfsziele........................................................................................... 33 

4.5 Allgemeine Beschreibung ....................................................................... 33 

4.5.1 Schema........................................................................................ 34 

4.5.2 Definition .................................................................................... 36 

4.6 Rollenbeschreibung................................................................................. 40 

4.6.1 Schema........................................................................................ 40 

4.6.2 Definition .................................................................................... 42 


5 PSE-D – IMPLEMENTIERUNGSBESCHREIBUNG...................................... 45 

5.1 Programmierschnittstellen....................................................................... 45 

5.1.1 Interne Datenstruktur .................................................................. 45 

5.1.2 Datenzugriff ................................................................................ 48 

5.1.3 Anwendungsbeispiel ................................................................... 49 

5.2 Initialisierung der Datenstruktur ............................................................. 54 


6 PSE-V - DARSTELLUNG VON ENTWURFSMUSTERN ............................. 58 

6.1 Struktur.................................................................................................... 58 

6.2 Entwurfsziele........................................................................................... 58 

6.3 Bedienung................................................................................................ 59 


7 PSE-V-IMPLEMENTIERUNGSBESCHREIBUNG......................................... 64 

7.1 Struktur.................................................................................................... 64 

7.2 Pakete ...................................................................................................... 65 

7.2.1 pattern.base.html ......................................................................... 65 

7.2.2 pattern.base.system ..................................................................... 66 

7.2.3 pattern.base.treeview................................................................... 66 

7.2.4 pattern.base.htmlview ................................................................. 67 

7.3 Ausgewählte Details................................................................................ 68 

7.3.1 Exkurs: XML-API's .................................................................... 68 

7.3.2 Zugriff auf globale Konfigurationsdatei ..................................... 71 

7.3.3 Zugriff auf Plugin-Eigeschaften.................................................. 73 


8 VERGLEICHBARE WERKZEUGE ................................................................. 75 

8.1 PBE.......................................................................................................... 75 

8.1.1 Aufbau der Musterdefinition....................................................... 76 

8.1.2 Initiales Codefragment................................................................ 76 

8.1.3 Variable Codeteile....................................................................... 77 

8.1.4 Parameter .................................................................................... 78

Andreas Wöckl Diplomarbeit Software Engineering 2002 IV 

8.1.5 Ausdrücke ................................................................................... 79 

8.1.6 Codeblöcke und Bedingungen .................................................... 81 

8.1.7 Einfügemarken ............................................................................ 81 

8.1.8 Verwaltung und Dokumentation................................................. 82 

8.2 FRED....................................................................................................... 82 

8.2.1 Rollen.......................................................................................... 82 

8.2.2 Einschränkungen......................................................................... 84 

8.2.3 Schablonen.................................................................................. 84 

8.2.4 Beispieldefinition Abstract Factory ............................................ 85 

8.2.5 Verwaltung und Dokumentation................................................. 87 

8.3 Vergleich ................................................................................................. 88 

8.3.1 Kriterien ...................................................................................... 88 

8.3.2 Ergebnisse ................................................................................... 90 


9 ZUSAMMENFASSUNG UND AUSBLICK .................................................... 93 


9.2 Ausblick .................................................................................................. 94 

ANHANG A: GLOSSAR ............................................................................................ 96 

ANHANG B: LITERATURVERZEICHNIS .............................................................. 99

Andreas Wöckl Diplomarbeit Software Engineering 2002 V 

Abbildungsverzeichnis 

Abbildung 1: Struktur von PSE...................................................................................... 2 

Abbildung 2: Beispiel für XML-Dokument [Kappel 2001a, 23]................................. 17 

Abbildung 3: Struktur von Eclipse [Eclipse 2002b, 10] .............................................. 21 

Abbildung 4: Aufbau plugin.xml von PSE-Admin...................................................... 22 

Abbildung 5: runtime-Elemente von plugin.xml ......................................................... 22 

Abbildung 6: requires-Elemente von plugin.xml......................................................... 22 

Abbildung 7: extension-Element von plugin.xml ........................................................ 23 

Abbildung 8: Schema für globale Konfigurationsdatei ............................................... 26 

Abbildung 9: Werte der globalen Konfigurationsdatei................................................ 27 

Abbildung 10: Allgemeine Architektur von Abstract Factory [Gamma 1995, 88] ..... 29 

Abbildung 11: Beispielarchitektur bei Anwendung von Abstract Factory.................. 30 

Abbildung 12: Struktur der Musterverwaltung von PSE-D......................................... 32 

Abbildung 13: Schema für allgemeinen Beschreibungsteil......................................... 34 

Abbildung 14: Allgemeine Beschreibung von Abstract Factory................................. 36 

Abbildung 15: Kategoriebeispiel 1 .............................................................................. 37 



Abbildung 18: Zusätzliches Kategorieelement ............................................................ 38 

Abbildung 19: HTML-Dokumentation für Abstract Factory....................................... 39 

Abbildung 20: XML-Schema der Rollenbeschreibung................................................ 41 

Abbildung 21: Rollenbeschreibung von Abstract Factory (1/2).................................. 42 

Abbildung 22: Rollenbeschreibung von Abstract Factory (2/2).................................. 43 

Abbildung 23: Klassendiagramm Datenstruktur von PSE-D ...................................... 46 

Abbildung 24: Klassendiagramm Datenzugriff von PSE-D ........................................ 48 

Abbildung 25: Kategoriedefinition Abstract Factory .................................................. 50

Andreas Wöckl Diplomarbeit Software Engineering 2002 VI 

Abbildung 26: Kategoriedefinition Interceptor............................................................ 50 

Abbildung 27: Kategoriedefinition Observer............................................................... 50 

Abbildung 28: Objektstruktur nach Ausführung von Quellcode 2 .............................. 51 




Abbildung 32: Struktur von PSE-V ............................................................................. 58 

Abbildung 33: Auswahl von Views ............................................................................. 59 

Abbildung 34: Menüpunkt "Other" bei der Auswahl von Views ................................ 60 

Abbildung 35: View "Pattern Navigator" .................................................................... 61 

Abbildung 36: Dokumentation für Adapter dargestellt in "Pattern Browser" ............. 62 

Abbildung 37: Aufbau Implementierung von PSE-V.................................................. 64 

Abbildung 38: Konzept einer XML-API [Kappel 2001c, 4] ....................................... 69 

Abbildung 39: PBE-Definition von Entwurfsmustern [Delta 2002b, 6] ..................... 76

Andreas Wöckl Diplomarbeit Software Engineering 2002 VII 

Tabellenverzeichnis 

Tabelle 1: Teilergebnis Evaluierung Softwareprojekte [Pomberger 1998, 1.4] .......... 15 

Tabelle 2: Pfadstruktur PSE-Admin ............................................................................ 24 

Tabelle 3: Benötigte Dateien PSE-Admin ................................................................... 25 

Tabelle 4: Eigenschaften der Rolle AbstractProduct ................................................... 31 

Tabelle 5: Elemente des XML-Schemas...................................................................... 35 

Tabelle 6: Beispiel für description Element................................................................. 40 

Tabelle 7: Zusatzfunktionalitäten von PatternDescription........................................... 47 

Tabelle 8: Zugriffsmethoden von PatternAdmin ......................................................... 49 

Tabelle 9: Administrationsmethoden von PatternAdmin............................................. 49 

Tabelle 10: Methoden für die Musterinitialisierung .................................................... 55 

Tabelle 11: Parameterwerte für Abstract Factory........................................................ 78 

Tabelle 12: Operatoren von PBE [Delta 2002b, 13].................................................... 80 

Tabelle 13: Beispielmethoden von PBE [Delta 2002b, 14] ......................................... 80 

Tabelle 14: Beispiele f. Rollentypen von FRED-Mustern [Viljaama 2001, 53].......... 82 

Tabelle 15: Kardinalitäten von FRED-Mustern [Viljaama 2002, 54] ......................... 83 

Tabelle 16: Einschränkungen für Rollen [Viljaama 2002, 55] .................................... 84 

Tabelle 17: Beispielschablonen von FRED [Viljaama 2001, 56]................................ 84 

Tabelle 18: Beispielfunktionen von FRED [Viljaama 2001, 56]................................. 85 

Tabelle 19: Gesamtergebnis des Vergleichs ................................................................ 90

Andreas Wöckl Diplomarbeit Software Engineering 2002 VIII 

Quellcodeverzeichnis 

Quellcode 1: Generierter Code für AbstractFactory.................................................... 43 

Quellcode 2: Abarbeitung über PatternInfo-Liste........................................................ 50 

Quellcode 3: Abarbeitung über PatternCategory-Liste (1/3)....................................... 52 



Quellcode 6: Methode initialize() ................................................................................ 55 

Quellcode 7: Globale Deklarationen............................................................................ 71 

Quellcode 8: Methode fillHashtable().......................................................................... 71 

Quellcode 9: Methode getValue()................................................................................ 72 

Quellcode 10: Zugriff auf plugin.properties ................................................................ 73 

Quellcode 11: Initiales Codefragment für Abstract Factory........................................ 77 

Quellcode 12: Definition variabler Codeteile für Abstract Factory............................. 78 

Quellcode 13: Ergebniscode nach Anwendung des Entwurfsmusters......................... 79 

Quellcode 14: Ergebniscode bei Verwendung eines Verknüpfungsoperators............. 79 

Quellcode 15: Ergebniscode bei Entfernen der Leerzeichen ....................................... 80 

Quellcode 16: Ergebniscode bei wiederholbarem Codeblock ..................................... 81 

Quellcode 17: Beispieldefinition für FRED-Muster [Viljaama 2001, 54]................... 83 

Quellcode 18: FRED-Definition von Abstract Factory ............................................... 86

Andreas Wöckl Diplomarbeit Software Engineering 2002 IX 

Kurzfassung 

Entwurfsmuster stellen ein bewährtes Konzept zur Entwicklung objektorientierter 

Softwaresysteme dar. Sie kapseln das Wissen erfahrener Programmierer und stellen 

damit Lösungsvorschläge für grundlegende Entwurfsprobleme zur Verfügung. Um 

mit Entwurfsmustern werkzeugunterstützt zu arbeiten, ist es zuerst erforderlich, diese 

zu definieren und adäquat zu verwalten. Eine flexible, programmiersprachenunabhängige 

Definition der Muster ist dabei wünschenswert. Auch die Dokumentation der 

Entwurfsmuster sollte in beliebigen Formaten und Strukturen wählbar sein. 

Für diesen Zweck wurde als Erweiterung der Entwicklungsumgebung Eclipse das 

Werkzeug PSE-Base entwickelt, das Teil eines Gesamtwerkzeuges zur Unterstützung 

der Arbeit mit Entwurfsmustern (PSE – Pattern Support for Eclipse) ist. PSE-Base 

besteht aus zwei Teilen: PSE-D (Pattern Support for Eclipse – Definition) zur Definition 

und Verwaltung der Muster und deren Dokumentation und PSE-V (Pattern 

Support for Eclipse – Visualisation) zur Navigation durch die interne Muster-Infrastruktur 

und zur Darstellung der Dokumentation. 

Diese Arbeit beschreibt den Aufbau, die Architektur, die Funktionalität und die Implementierung 

der Komponenten von PSE-Base. Den Abschluss bildet eine Beschreibung 

vergleichbarer Werkzeuge und eine Gegenüberstellung anhand verschiedener 

Kriterien.

Einleitung 1 

1 Einleitung 

Dieses Kapitel gibt eine Einleitung in diese Arbeit. Sie umfasst die Motivation, einen 

Überblick über das entwickelte Werkzeug, eine Gliederung und die Beschreibung der 

Schreibweise, die in dieser Arbeit verwendet wird. 

1.1 Motivation 

Bei der Entwicklung von objektorientierten Softwaresystemen werden häufig Muster 

von Problemlösungen verwendet, um einen flexiblen und eleganten Aufbau und damit 

auch die Wiederverwendbarkeit des Systems zu gewährleisten. Um diese Problemlösungen 

auch anderen Entwicklern zur Verfügung zu stellen, wurde das Konzept der 

Entwurfsmuster entwickelt. Sie stellen Lösungsvorschläge für bestimmte grundlegende 

Entwurfsprobleme dar und sind beim Aufbau einer flexiblen und wiederverwendbaren 

Systemarchitektur hilfreich. 

Entwurfsmuster bieten Unterstützung beim Entwurfsprozess und der Evaluierung bestehender 

Softwaresysteme. Bei der Evaluierung liegt es im Interesse des Entwicklers, 

bestehende Systeme auf die Verwendung von Entwurfsmustern zu untersuchen, um 

sich ein Bild über die Architektur zu machen. Diese so gewonnenen Informationen 

können bei einer Weiterentwicklung wertvoll sein. Um das Arbeiten mit Entwurfsmustern 

zu erleichtern, ist die Verwendung von Werkzeugen sinnvoll. Sie sollen die 

flexible Definition und Verwaltung, vor allem aber die Anwendung der Entwurfsmuster 

unterstützen. Die meisten derzeit existierenden Werkzeuge sind sogenannte 

stand alone Lösungen, d. h. die Integration in eine Entwicklungsumgebung fehlt. 

Das Ziel dieser Diplomarbeit ist die Entwicklung eines Werkzeuges zur flexiblen 

Definition, Verwaltung und Visualisierung von Entwurfsmustern und deren Dokumentation 

auf der Basis von XML. Dieses Werkzeug soll als Erweiterung der Entwicklungsumgebung 

Eclipse [Eclipse 2002a] entwickelt werden und Funktionalitäten 

für zwei Benutzergruppen bieten: Zum einen für Entwickler, die die vorhandenen 

Muster und deren Dokumentation betrachten und zum anderen für Werkzeugentwickler, 

die über Schnittstellen auf diese Datenstruktur zugreifen.

Einleitung 2 

1.2 Überblick 

Das entwickelte Werkzeug setzt sich aus verschiedenen Komponenten zusammen, die 

in Abbildung 1 illustriert werden. 

PSE 

PSE-Base 

PSE-Application 

PSE-D 

PSE-V 

Abbildung 1: Struktur von PSE 

Diese Arbeit beschränkt sich auf die Beschreibung von PSE-Base, das verantwortlich 

ist für die Definition, Verwaltung und Visualisierung von Entwurfsmustern und deren 

Dokumentation. PSE-Base ist Teil eines Gesamtwerkzeuges zur Unterstützung der 

Entwicklung mit Entwurfsmustern mit dem Namen PSE (Pattern Support for Eclipse). 

PSE wurde als Erweiterung der Entwicklungsumgebung Eclipse entwickelt. Ein Teil 

zur Anwendung von Entwurfsmustern (PSE-Application) wird in einer weiteren 

Diplomarbeit "Erweiterung einer Programmierumgebung zur Unterstützung patternbasierter 

Softwareentwicklung" [Mayr-Kern 2002] vorgestellt. PSE-Base besteht aus 

den Komponenten PSE-D (Pattern Support for Eclipse – Definition) und PSE-V 

(Pattern Support for Eclipse – Visualisation). PSE-D ist verantwortlich für die Definition 

und Verwaltung der Muster und deren Dokumentation, PSE-V für die Visualisierung 

der Musternavigation und der Dokumentation.

Einleitung 3 

1.3 Gliederung 

Diese Diplomarbeit ist in folgende Kapitel gegliedert: 

Kapitel 2 – Entwurfsmuster gibt eine allgemeine Einführung in Entwurfsmuster und in 

die Vor- bzw. Nachteile bei deren Verwendung. Weiters wird der genaue Aufbau von 

Entwurfsmustern erläutert. 

Kapitel 3 - Erweiterung der Entwicklungsumgebung Eclipse – erläutert das Konzept 

und die Erweiterungsmöglichkeiten der Entwicklungsumgebung Eclipse. Zusätzlich 

ist eine Einführung in XML und die genaue Inbetriebnahme von PSE-Base Teil dieses 

Kapitels. 

Kapitel 4 - PSE-D - Definition von Entwurfsmustern - beschreibt die Definition und 

Verwaltung von Entwurfsmustern sowie deren Dokumentation. 

Kapitel 5 - PSE-D – Implementierungsbeschreibung gewährt Einblick in die 

Implementierung von PSE-D. Weiters werden die Programmierschnittstellen für den 

Zugriff auf die verwalteten Muster beschrieben. 

Kaptiel 6 - PSE-V - Darstellung von Entwurfsmustern beschreibt die Bedienung des 

entwickelten Werkzeuges zur Visualisierung der durch PSE-D definierten Muster- 

Infrastruktur. 

Kapitel 7 – PSE-V-Implementierungsbeschreibung legt den Aufbau der Implementierung 

von PSE-V dar und beschreibt ausgewählte Implementierungsdetails. 

Kapitel 8 - Vergleichbare Werkzeuge beschreibt zwei weitere Werkzeuge zur 

Musterunterstützung und führt anhand verschiedener Kriterien einen Vergleich durch. 

Kapitel 9 - Zusammenfassung und Ausblick fasst die Erkenntnisse dieser Arbeit 

zusammen und gibt einen Ausblick über Erweiterungsmöglichkeiten von PSE-Base.

Einleitung 4 

1.4 Schreibweise 

Wörtliche Zitate, explizite Wertangaben sowie Pfade werden unter Hochkomma gestellt. 

Beispiel: "Die Betrachtungsweise beeinflusst die Auffassung was ein Muster ist und 

was nicht.", "e:\eclipse\patternFiles" 

Fachbegriffe sowie Verweise auf Stellen in diesem Dokument und die Titel im 

Literaturverzeichnis werden kursiv geschrieben. 

Beispiel: siehe Kapitel 2 

Für Quellcodebeispiele (alle in der Programmiersprache Java), XML- und HTML- 

Beispiele wird Courier New, Schriftgröße 10, Schriftfarbe dunkelgrau verwendet: 

Beispiel: public class AbstractFactory{} 

Die Darstellung von Klassendiagrammen orientiert sich am UML-Standard [OMG 

2002]. 

Beispiel: 

«interface» 

Schnittstellenname 

+methode_öffentlich() 

Klassenname 

+methode_öffentlich() 

Grundsätzlich werden deutsche Begriffe verwendet, da jedoch die Implementierung 

und die Benutzerdokumentation in Englisch vorliegen, werden zur Beschreibung 

dieser Teile auch englische Begriffe eingesetzt. Dies gilt auch für die Bezeichnungen, 

der in der Literatur vorhandenen Entwurfsmuster.

Entwurfsmuster 5 

2 Entwurfsmuster 

In diesem Kapitel werden die Grundlagen von Entwurfsmustern beschrieben. Es wird 

dargelegt, welche Arten von Mustern man in der Literatur vorfindet und welche Vorbzw. 

Nachteile die Verwendung mit sich bringt. Weiters wird begründet, warum sie in 

der objektorientierten Softwareentwicklung eine so große Rolle spielen. Zumal die 

Verwendung von PSE-D auf die Definition und Verwaltung von Entwurfsmustern 

zielt, wird auch der genaue Aufbau eines solchen erörtert. Den Abschluss dieses Kapitels 

bildet die Diskussion der Programmiersprachenunabhängigkeit von Mustern und 

eine kurze Einführung in den Begriff der Anti-Entwurfsmuster. 

2.1 Definition 

Chistopher Alexander definiert den Begriff Muster folgendermaßen: "Jedes Muster 

beschreibt zunächst ein in unserer Umwelt immer wieder auftretendes Problem, beschreibt 

dann den Kern der Lösung dieses Problems, und zwar so, dass man diese Lösung 

millionenfach anwenden kann, ohne sich je zu wiederholen" [Alexander 1995, 

X]. Obwohl Alexander von Mustern in Gebäuden und Städten spricht, gilt seine 

Definition auch für Entwurfsmuster in der Softwareentwicklung. Der Ausgangspunkt 

ist immer ein Problem, für das eine Lösung in einem bestimmten Umfeld gesucht 

wird, mit dem Ziel, diese Lösung so allgemein wie möglich zu halten, um sie in den 

verschiedensten ähnlichen Ausgangssituationen wieder einsetzen zu können. 

2.1.1 Basiselemente 

Laut [Gamma 1995, 3] besteht ein Entwurfsmuster aus den folgenden vier allgemeinen 

Basiselementen: 

Mustername 

Der Name eines Musters soll helfen, das Problem, seine Lösung und Konsequenzen in 

einem oder zwei Wörter grob zu beschreiben. Durch die sorgfältige Vergabe von passenden 

Namen bildet sich mit der Zeit ein gut wiederverwendbares Entwurfsvokabular. 

Entwickler, die dieses Vokabular verwenden, können damit Softwaresysteme auf 

einer höheren Abstraktionsebene entwerfen. Auch das Dokumentieren solcher Systeme 

und der Erfahrungsaustausch mit anderen Entwicklern wird durch einen gemein-


samen Sprachschatz erleichtert. Bei der Entwicklung neuer Entwurfsmuster sollte daher 

erhöhte Aufmerksamkeit auf die Vergabe der Namen gelegt werden. 

Problem 

Jedem Entwurfsmuster liegt ein Problem zugrunde. Erst mit der Beschreibung des 

Problems und des ihm zugrunde liegendem Kontexts wird die Anwendung des 

Musters ersichtlich. Die Beschreibung kann spezielle Entwurfsprobleme wie die Repräsentation 

von Algorithmen oder Objekten betreffen, oder aber auch inflexible Klassen- 

und Objektstrukturen aufzeigen. Manchmal enthält die Problembeschreibung 

einige Bedingungen die zutreffen müssen, um das Muster anzuwenden. 

Lösung 

Die Lösung beschreibt die Entwurfselemente, ihre Verbindungen und Abhängigkeiten 

zueinander, die zur Problemlösung verwendet werden können. Sie beschreibt keinen 

konkreten Entwurf und keine spezielle Implementierung, da ein Muster wie eine 

Schablone, anwendbar in den verschiedensten Situationen, verwendet werden soll. Ein 

Muster bietet eine Lösung auf einer höheren Abstraktionsebene. Es beschreibt wie 

eine allgemeine Anordnung von Klassen und Objekten ein Problem lösen kann. 

Konsequenzen 

Die Konsequenzen zeigen die Vor- und Nachteile bei Anwendung eines Musters auf. 

Es ist wichtig, die Auswirkungen auf Flexibilität, Erweiterbarkeit und Portabilität eines 

Softwaresystems zu verstehen, denn nur die Auseinandersetzung mit den Konsequenzen 

erlaubt die Auswahl geeigneter Entwurfsalternativen. 

2.1.2 Bestandteile 

Neben der Definition eines Entwurfmusters ist für die Entwicklung einer Datenstruktur 

vor allem auch der genaue Aufbau wichtig. [Gamma 1995, 6-7] beschreibt eine 

Systematik, laut der ein Entwurfsmuster aus folgenden 14 Teilen besteht: 

1. Name: Die Vergabe eines sprechenden Namens ist einer der wichtigsten Aspekte 

bei der Definition eines Musters. Um ein gutes Entwurfsvokabular zu 

entwickeln, sollte dieser sorgfältig gewählt werden 

2. Klassifizierung: Zeigt, ob ein Muster eher Klassen oder Objekte zur Problemlösung 

verwendet. Klassenmuster befassen sich mit den Beziehungen 

von Klassen und deren Subklassen, die durch Vererbung erzielt werden. Sie 

stellen daher statische Strukturen (zur Laufzeit gebunden) dar. Objektmuster 

arbeiten mit den Beziehungen von Objekten (Komposition), die zur Laufzeit


geändert werden können. Sie werden daher als dynamische Strukturen bezeichnet. 

3. Absicht: Die Absicht sollte in einer kurzen Aussage folgende Fragen beantworten: 

Was macht das Entwurfsmuster? Was ist seine Absicht? Welches 

spezielle Entwurfsproblem spricht es an? 

4. Bekannt als: Andere bekannte Namen für das Entwurfsmuster. 

5. Motivation: Enthält eine detaillierte Beschreibung des Entwurfsproblems 

und wie das Zusammenspiel von Klassen und Objekten dieses Problem lösen 

kann. 

6. Anwendbarkeit: Befasst sich mit der Frage, in welchen Situationen das 

Muster anwendbar ist und wie man diese Situationen erkennt. 

7. Struktur: Eine graphische Repräsentation der Klassen in OMT-Notation 

(Object Modeling Technique) [Rumbaugh 1991]. Da die Weiterentwicklung 

von OMT – UML (Unified Modeling Language) erst im November 1997 

[Kappel 2001a] anerkannt wurde (nach der Veröffentlichung von [Gamma 

1995]!), ist sinngemäß auch eine Repräsentation der Klassen in UML zulässig. 

8. Rollen: Klassen und/oder Objekte inklusive deren Abhängigkeiten, die zur 

Lösung des Entwurfsproblems benötigt werden. 

9. Kollaboration: Zeigt, wie die Rollen bei der Problemlösung zusammenarbeiten. 

10. Konsequenzen: Beschreiben die Vor- bzw. Nachteile bei Anwendung des 

Entwurfsmusters. Weiters zeigen sie strukturelle Auswirkungen auf das zu 

entwickelnde Softwaresystem auf. 

11. Implementierung: Gibt Hinweise, welche Programmiertechniken verwendet 

werden sollen, bzw. welche Gefahren bei der Anwendung falscher Techniken 

auftreten können. Die Implementierung beschäftigt sich auch mit programmiersprachenabhängigen 

Details. 

12. Beispielcode: Besteht aus Codeteilen einer beliebigen Programmiersprache, 

die dem Entwickler eine Möglichkeit zur Implementierung des Musters aufzeigen 

sollen.


13. Bekannte Anwendungen: Zeigt Beispiele zur Verwendung dieses Musters 

in realen Softwaresystemen. Empfohlen wird, zumindest zwei Beispiele aus 

verschiedenen Anwendungsgebieten darzulegen. 

14. Ähnliche Muster: Gibt an, welche Muster einen ähnlichen Aufbau haben, 

bzw. mit verwendet werden sollen. 

2.2 Vorteile 

Entwurfsmuster sollen helfen, den Entwurf von Softwaresystemen zu verbessern bzw. 

flexibler zu gestalten. Welche speziellen Vorteile bringt daher die Anwendung von 

Mustern mit sich? In [Chambers 2000, 278] werden vier wesentliche extrahiert: 

Wiederverwendung des Entwurfs 

Unter Wiederverwendung versteht man normalerweise der vermehrten Einsatz des 

gleichen Quellcodes. Die Wiederverwendung des Entwurfs ist jedoch um einiges 

mächtiger und bringt oft die des Quellcodes mit sich. Der Vorteil liegt in der höheren 

Abstraktionsebene des Entwurfs, durch die entworfene Komponenten in den verschiedensten 

Situationen wieder einsetzbar sind. Dadurch wird der Aufbau einer flexibleren 

Architektur und somit die Wiederverwendung von Komponenten in anderen Systemen 

unterstützt. 

Einführung eines allgemein gültigen Entwurfsvokabulars 

Wie schwierig wäre es wohl für Entwickler, über Softwarearchitektur zu diskutieren, 

ohne bekannte Begriffe wie z. B: stack oder hash table verwenden zu können. Ohne 

dieses Vokabular müssten Entwickler jedes Mal viel Zeit aufwenden, um ihre Datenstrukturen, 

Algorithmen usw. zu erklären. Durch die Verwendung allseits bekannter 

Begriffe bleibt ihnen diese Zeit erspart. Sinngemäß ist es auch leichter, über eine Architektur 

zu diskutieren, wenn Definitionen wie Abstract Factory, Builder oder Composite, 

um nur einige Muster zu nennen, vielen Entwicklern ein Begriff sind. Ein allgemein 

bekanntes Entwurfsvokabular erleichtert somit die Kommunikation zwischen 

Softwareentwicklern. 

Verbesserung der Dokumentation 

Eine präzise Dokumentation der im Softwaresystem verwendeten Entwurfsmuster 

kann Entwicklern helfen, sich leichter einen Überblick über die Architektur zu verschaffen, 

auch wenn die verwendeten Muster vorher noch unbekannt waren.


Restrukturierung von Softwaresystemen 

Systeme, die mit Hilfe von Entwurfmustern entwickelt wurden, erleichtern ihre Restrukturierung 

oder Transformation in Systeme anderer Anwendungsgebiete. Dieser 

Effekt wird durch die Wiederverwendbarkeit der entwickelten Komponenten erzielt. 

Entwurfsmuster spielen somit eine große Rolle bei der Entwicklung von Softwaresystemen. 

Ihr größter Vorteil ist wohl, dass sie das Wissen von erfahrenen Programmierern 

kapseln und es somit anderen zu Verfügung stellen [Agerbo 1998, 134]. Je 

mehr Entwickler dieses Wissen verwenden und in ihre Systemarchitektur einbauen, 

desto flexibler und wiederverwendbarer werden diese Systeme. 

2.3 Nachteile 

Obwohl Entwurfsmuster einige überzeugende Vorteile aufweisen, bringt ihre Anwendung 

auch Nachteile mit sich. [Helm 1995, 339-340] identifiziert folgende: 

Naive Anwendung 

Entwurfsmuster können zu einer überschwänglichen und naiven Anwendung animieren. 

Einige Entwickler sind bei der Konzeption ihrer Systeme nur mehr darauf bedacht, 

möglichst viele Muster ohne Rücksicht auf positive und negative Effekte einzusetzen. 

Sie bedenken nicht, dass Muster nicht alle Probleme lösen können und dass 

zur Anwendung ein Auseinandersetzen mit den positiven und negativen Auswirkungen 

nötig ist. 

Kluft zwischen Analyse und Umsetzung 

Vor der Anwendung eines Entwurfsmusters muss dessen Vorschlag zur Problemlösung 

analysiert werden. Nur so kann die Verwendung das zu entwickelnde System 

flexibler gestalten. Oft erkennt man jedoch bei der Analyse, dass ein Muster zwar ungefähr 

in der beschriebenen Form verwendet werden kann, jedoch einige Adaptierungen 

für den Einsatz im System erfordert. Diese Kluft bei der Umsetzung entsteht 

durch den allgemeinen Problemlösungscharakter von Entwurfsmustern. 

Abstimmung mit anderen Ansätzen 

Das Abstimmen eines musterbasierten Systems mit einem durch objektorientierte 

Entwurfsmethoden entwickeltem System ist schwierig. Entwurfsmuster stützen sich 

auf bereits fundiertes Wissen; Entwurfsmethoden beschäftigen sich hingegen mehr 

mit den einzelnen Schritten von der Analyse bis zum fertigen Entwurf. Dieser Unterschied 

in den Ansätzen erschwert einen Abstimmprozess.


Unsicherheit in der Anwendung 

Bei der Entwicklung eines Systems ist es oft nicht eindeutig, ob ein bzw. welches 

Muster angewendet werden kann, da eine konkrete Formulierung eines Entwurfsproblems 

in den Anfangsphasen häufig nicht möglich ist. Erst im weiteren Entwicklungsprozess 

werden die Probleme und somit auch die Möglichkeiten zur Musteranwendung 

klarer. 

Diese Nachteile sollten bei der Anwendung von Entwurfsmustern berücksichtigt werden, 

um negative Auswirkungen auf das zu entwickelnde System zu vermeiden. 

2.4 Einteilung 

Nach der Definition von Entwurfsmustern und deren Bestandteilen stellt sich nun die 

Frage, welche derzeit in der Literatur existieren und in welche Kategorien diese einteilbar 

sind. Laut [Gamma 1995, 3] ist das Empfinden einer Problemlösung als Muster 

subjektiv, daher ist es nicht einfach, eine Einteilung für sie zu finden. In den folgenden 

Abschnitten werden drei Ansätze zur Einteilung von Entwurfsmustern vorgestellt. 

2.4.1 Buschmann 

Die Autoren von [Buschmann 2000] identifizieren die vier folgenden Kategorien von 

Entwurfsmustern: 

Dienstzugriffs- und Konfigurationsmuster 

Diese Kategorie umfasst vier Muster zur effektiven Entwicklung von Programmierschnittstellen 

(application programming interfaces – API's), um Dienste und Komponenten 

in alleinstehenden, aber auch vor allem in Netzwerksystemen zu konfigurieren. 

Die Notwendigkeit solcher Muster begründet sich im heterogenen Charakter von 

Netzwerksystemen, da hier spezielle Mechanismen entwickelt werden müssen, um die 

einzelnen Dienste und Komponenten zu adressieren und zu konfigurieren. 

Beispiel: Das Muster Interceptor erlaubt es, Frameworks 1 mit beliebigen zusätzlichen 

Diensten zu versehen, z. B. ein Framework zur Entwicklung von Netzwerk- 

1 Ein Framework ist eine Ansammlung von Klassen, welche einen abstrakten Entwurf für Lösungen zu 

einer Familie verwandter Probleme enthalten. Der Programmierer muss nur Codes schreiben, wenn er 

das Verhalten des Framework verändern oder erweitern will [Freiberg 2002].


komponenten mit zusätzlichen Diensten wie Logging und Transaktionskontrolle. 

Ereignisbasierende Muster 

Muster zur Entwicklung ereignisbasierender Systeme sind vor allem im Netzwerkbereich 

anzusiedeln. Sie unterstützen das Initialisieren, Empfangen, Verschicken und 

Verarbeiten von Ereignissen und haben dadurch in der netzwerkbasierenden Softwareentwicklung 

einen hohen Stellenwert erhalten. 

Beispiel: Reactor kann verwendet werden, um Anfragen mehrerer Klienten an eine 

Anwendung zu steuern. 

Synchronisationsmuster 

Diese Muster unterstützen das Sperren von Objekten in Multi-Prozess-Systemen. Das 

Entwickeln solcher Systeme ist um einiges aufwendiger als das Entwickeln sequentieller, 

da die Objekte von mehreren Prozessen bearbeitet und verändert werden können. 

Ein ausgeklügeltes Sperrverfahren ist daher zur Realisierung notwendig. 

Beispiel: Das Muster Strategized Locking ist zuständig für die Steuerung des Synchronisationsmechanismus 

kritischer Sektionen einer Komponente. 

Gleichzeitigkeitsmuster 

Muster dieser Kategorie beschäftigen sich mit der Entwicklung einer Architektur, die 

das reibungslose Zusammenspiel mehrerer Prozesse garantiert. Diese hat starken Einfluss 

auf die Performanz von Multi-Prozess-Systemen. 

Beispiel: Monitor Objekt synchronisiert die Ausführung gleichzeitig aufgerufener 

Methoden innerhalb eines Objektes und garantiert somit, dass zu einem 

Zeitpunkt immer nur eine Methode ausgeführt wird. 

2.4.2 Gamma 

Die in [Gamma 1995] identifizierten Kategorien gliedern sich in folgende Bereiche: 

Erzeugungsmuster 

Erzeugungsmuster sind verantwortlich für die Abstraktion des Instanzierungsprozesses. 

Sie befassen sich mit der Erzeugung von Objekten und helfen dabei, ein System 

unabhängig davon zu machen, wie seine Objekte erzeugt, zusammengesetzt und repräsentiert 

werden. Erzielt wird dies durch ein Verstecken des Instanzierungsprozesses. 

Erzeugungsmuster ermöglichen dadurch zu bestimmen, welche Objekte wer, wann 

und wie erzeugt.


Beispiel: Mit dem Muster Abstract Factory wird eine Schnittstelle bereitgestellt, um 

verwandte Objekte ohne deren genauere Spezifikation zu erzeugen. Eine 

Anwendung arbeitet nur mit den Schnittstellen, daher können Komponenten 

beliebig ausgetauscht werden. 

Strukturmuster 

Strukturmuster beschäftigen sich mit dem Problem, wie Klassen und Objekte zusammenarbeiten 

müssen, um größere Strukturen zu formen. Klassenmuster verwenden 

Vererbung für den Aufbau von Strukturen, Objektmuster die Komposition von Objekten. 

Der Vorteil bei Objektmustern liegt in der Konfigurierbarkeit zur Laufzeit, 

womit sie variabler als statische Konstruktionen sind. 

Beispiel: Das Objektmuster Composite ermöglicht es Teil-Ganzes Hierachien abzubilden, 

wobei ein Teilobjekt genauso wie eine Komposition von Objekten 

behandelt werden kann, z. B. ein Grafikeditor, wo die Bearbeitung einzelner 

Bilder genau wie die einer Gruppierung von Bildern abläuft. 

Verhaltensmuster 

Verhaltensmuster beschäftigen sich mit Algorithmen und der Zuweisung von Zuständigkeiten 

zu Objekten. Sie befassen sich nicht nur mit der Struktur von Klassen und 

Objekten, sondern auch mit deren Interaktion. 

Beispiel: Mit dem Muster Observer können Abhängigkeiten unter Objekten definiert 

werden, sodass beim Ändern des Status eines Objektes alle abhängigen Objekte 

benachrichtigt werden und ebenfalls ihren eigenen Status ändern können. 

2.4.3 Pree 

Wolfgang Pree behandelt in [Pree 1994] folgende drei Kategorien von Entwurfsmustern: 

Objektorientierte Muster 

Objektorientierte Muster befassen sich mit dem Zusammenwirken von Klassen und 

Objekten. 

Beispiel: Das Muster ItemDescriptor definiert, wie Abhängigkeiten unter Objekten 

allgemein verwirklicht werden können. Observer ist somit als eine Erweiterung 

von ItemDescriptor anzusehen.


Codemuster 

Codemuster stellen Problemlösungen dar, die nur einer Programmiersprache zugeordnet 

werden können. Sie sind also nicht allgemein für alle Sprachen verwendbar, sondern 

spezialisieren sich auf eine Problemlösung für eine bestimmte Programmiersprache. 

Beispiel: Pree stellt ein C++-Codemuster aus [Coplien 1992] vor, dass statische Deklaration 

von Variablen der dynamischen Bindung vorzieht. Ein expliziter 

Name für das Muster wird dabei nicht vergeben. 

Framework-Adaptierungsmuster 

Diese Muster befassen sich mit Problemlösungen für die Adaptierung von Frameworks. 

Bei der Entwicklung von Softwaresystemen bilden oft Frameworks die Basis 

und werden je nach Anforderungen modifiziert und adaptiert. Adaptierungsmuster 

unterstützen genau diesen Prozess. 

Beispiel: Pree beschreibt ein Muster zur Generierung von Dokumenten mit dem Grafik-Framework 

ET++, vergibt jedoch keinen expliziten Namen für das Entwurfsmuster. 

Diese drei Ansätze zeigen einige Möglichkeiten zur Kategorisierung von Entwurfsmustern, 

wobei einige Unterschiede festgestellt werden können. Gamma geht mit seinen 

Kategorien Erzeugungsmuster, Strukturmuster und Verhaltensmuster auf die verschiedenen 

Arten von Entwurfsmustern ein. Buschmann ist mit seiner Kategorisierung 

im Netzwerkbereich anzusiedeln und unterscheidet innerhalb dieses Bereiches nach 

Kategorien. Pree bezieht im Gegensatz zu den anderen beiden auch Codemuster in 

seine Kategorisierung ein, fasst hingegen jedoch alle objektorientierten Muster zu 

einer Kategorie zusammen. 

Im weiteren Verlauf dieser Arbeit wird der Ansatz von [Gamma 1995] als Basis und 

Richtlinie für die Entwicklung des Werkzeuges PSE-Base angesehen, zumal dieser in 

der Literatur am häufigsten erwähnt wird und auch für die Entwicklung einer Datenstruktur 

am sinnvollsten erscheint. 

2.5 Programmiersprachen 

Wie in Abschnitt 2.4 ersichtlich, gibt es nicht nur allgemein gültige, sondern auch programmiersprachenabhängige 

Entwurfsmuster, z. B. Codemuster von [Pree 1994]. 

Damit stellt sich die Frage nach den Spracheigenschaften von Entwurfsmustern. Sol-


len sie für jede objektorientierte Programmiersprache gültig sein, oder sich auf die 

Anwendung in einer Sprache beschränken? [Agerbo 1998, 135-136] identifiziert bei 

einer Programmiersprachenabhängigkeit folgende Nachteile: 

‣ Die Kommunikation bzw. Diskussion der Muster über die Grenzen von Programmiersprachen 

hinaus wird zwangsläufig komplizierter. 

‣ Wenn das gleiche Muster unter verschiedenen Namen in verschiedenen Programmiersprachen 

existiert, fällt es schwerer diese miteinander zu vergleichen, 

da die verwendete Programmiersprache auch einen Einfluss auf die 

Verwendung des Musters hat. 

‣ Entwickler sind gezwungen eine Reihe neuer Entwurfsmuster zu lernen, sofern 

sie mit einer anderen Programmiersprache konfrontiert werden. 

‣ Sprachabhängige Muster können mit der Zeit fehlende Möglichkeiten in der 

Programmiersprache verschleiern. Bspw. wird in Java Mehrfachvererbung 

nicht unterstützt, lässt sich jedoch durch geschickten Entwurf nachbilden. 

Entwurfsmuster sollten generell sprachunabhängig sein. [Agerbo 1998, 136] führt zur 

Abgrenzung den Begriff Fundamentale Entwurfsmuster für jene Muster ein, die in 

allen gängigen objektorientierten Programmiersprachen verwendet werden können. 

Alle anderen werden unter dem Begriff Sprachabhängige Entwurfsmuster zusammengefasst. 

Eine genaue Zuordnung von Mustern zu diesen Bereichen wird von ihm jedoch 

nicht vorgenommen. 

2.6 Anti-Entwurfsmuster 

In den vorigen Abschnitten wurde erläutert, was Entwurfsmuster sind, welche Vorteile 

sie haben, wie man sie einteilt usw. Bei der Recherche nach Entwurfsmustern wird 

man zwangsläufig aber auch auf den Begriff Anti-Entwurfsmuster stoßen. Diese zeigen 

Wege, wie man von einer Problemdefinition zu einer schlechten Lösung gelangt 

[Anti Pattern 2002]. Anti-Entwurfsmuster besitzen laut [McCormick 1998] die folgenden 

Eigenschaften: 

‣ Anti-Entwurfsmuster sind negative Lösungen, die mehr Probleme aufdecken 

als sie lösen können. 

‣ Sie sind eine natürliche Erweiterung zu gewöhnlichen Entwurfsmustern.


‣ Anti-Entwurfsmuster überbrücken durch ihre Problemlösungen die Kluft 

zwischen den Software-Architekturkonzepten und der Implementierung. 

‣ Das Verstehen der Anti-Entwurfsmuster stattet uns mit dem nötigen Wissen 

aus, sie zu vermeiden, oder aus deren negativen Problemlösungen heraus 

wieder zu einer positiven Lösung zu gelangen. 

Obwohl nach der Definition der Eigenschaften der Anti-Entwurfsmuster der Eindruck 

entsteht, dass diese eigentlich nur zur Abschreckung dienen und daher von Entwicklern 

vermieden werden sollten, können sie dennoch bei der Entwicklung von Softwaresystemen 

hilfreich sein. Tabelle 1 zeigt bspw. ein Teilergebnis einer Studie über 

den Erfolg von Softwareprojekten, in der nur ein geringer Anteil der Projekte termintreu 

bzw. kostentreu abgeschlossen wurde. 

(Plan-) Termintreue abgeschlossen 2 von 16 

(Plan-) Kostentreue abgeschlossen 1 von 16 (max. Abweichung 4,5) 

Tabelle 1: Teilergebnis Evaluierung Softwareprojekte [Pomberger 1998, 1.4] 

Die in diesen Projekten begangenen Fehler sind sehr wertvoll, indem sie uns aufzeigen, 

mit welchen Vorgehensweisen und Problemlösungsverfahren man auf keinen Fall 

die gesetzten Ziele (in diesem Fall Termin- und Kostentreue) erreicht. Diese Fehler 

gilt es zu analysieren und in Zukunft zu vermeiden. Der Prozess der Analyse kann als 

"Studie von Anti-Entwurfsmustern" angesehen werden. 

2.7 Zusammenfassung 

Dieses Kapitel beschäftigte sich mit einer Einführung in Entwurfsmuster. Es zeigte 

auf, dass sich die Verwendung vor allem auf die Flexibilität, Wiederverwendbarkeit 

und Portabilität positiv auswirkt. Weiters wurden Ansätze zur Kategorisierung der 

Entwurfsmuster erläutert, wobei sich herausstellte, dass in der Literatur die Kategorisierung 

nach verschiedenen Gesichtspunkten vorgenommen wird. Bei der Diskussion 

der Programmiersprachenunabhängigkeit wurde festgestellt, dass bei Bindung an eine 

Sprache einige Nachteile auftreten. Den Abschluss bildete eine Einführung in Anti- 

Entwurfsmuster, die dabei helfen sollen, aus schlechten Problemlösungen zu lernen 

und begangenen Fehler in Zukunft zu vermeiden.

Erweiterung der Entwicklungsumgebung Eclipse 16 

3 Erweiterung der Entwicklungsumgebung 

Eclipse 

In diesem Kapitel werden das Konzept und die Erweiterungsmöglichkeiten der Entwicklungsumgebung 

Eclipse [Eclipse 2002a] vorgestellt. Da PSE-Admin als Erweiterung 

von Eclipse implementiert wurde, ist auch eine Beschreibung der Inbetriebnahme 

Teil dieses Kapitels. 

Den Beginn bildet jedoch ein Exkurs über Teilbereiche des XML-Standards, da die 

Konfiguration von PSE-Admin und die Verwaltung der Entwurfsmuster in XML vorgenommen 

werden müssen. 

3.1 Exkurs: XML 

In diesem Exkurs werden die für PSE-Admin relevanten Teilbereiche des XML-Standards 

[W3C 2002a] kurz vorgestellt. Folgende Abschnitte sind die wichtigsten Elemente 

aus den Quellen [Kappel 2001a] (Einführung) und [Kappel 2001b] (XML- 

Schema), da diese Literatur einen einfachen, leicht verständlichen und ausreichenden 

Überblick über die benötigte Materie gibt. 

3.1.1 Einführung 

Bis zur Entwicklung von XML (eXtensible Markup Language) galt HTML (Hypertext 

Markup Language) [W3C 2002b] als der Standard zur Beschreibung von Hypertextdokumenten 

im World Wide Web. Folgende Einschränkungen von HTML führten 

jedoch dazu, eine weitere Alternative zur Beschreibung von Dokumenten zu entwickeln: 

‣ HTML hat eine beschränkte Anzahl von vordefinierten Tags 2 . 

‣ Die Tags vermischen Layout-Aspekte mit Struktur- und Inhaltsaspekten. 

Vor allem die fehlende Abgrenzung vom Layout zum Inhalt führte dazu, einen alternativen 

Standard zu entwickeln, bei dem nicht das Aussehen eines Dokumentes, 

2 Ein Tag ist ein Identifizierungskennzeichen. Bspw. identifiziert der Tag in HTML einen Absatz, 

oder den Beginn einer Fett-Schreibweise.


sondern die Strukturinformation im Vordergrund steht. XML-Dokumente sind zwar 

ähnlich aufgebaut wie HTML-Dokumente (Tags, Attribute, usw.) spezialisieren sich 

jedoch auf die Beschreibung von Struktur und Inhalt. 

Folgende Merkmale sind für XML signifikant: 

‣ Erweiterbarkeit: Tags und Attribute können neu definiert und benannt 

werden. 

‣ Strukturierbarkeit: Tags können beliebig komplex geschachtelt werden. 

‣ Selbstbeschreibendes Format: Tags im XML-Dokument beschreiben 

Struktur und Semantik des Inhalts. 

‣ Validierbarkeit: XML-Dokumente können eine Beschreibung ihrer 

Grammatik aufweisen (DTD, XML-Schema) und gegenüber dieser geprüft 

werden. 

‣ Layoutunabhängigkeit: Trennung von Inhalt und Layout. 

‣ Semistrukturiertheit: Inhalt kann auch nicht-strukturierte Teile aufweisen, 

d. h. nicht jeder Inhalt muss von einem Tag umschlossen sein. 

Aufgrund dieser Merkmale ergeben sich die verschiedensten Anwendungsgebiete für 

XML wie z. B. Datenaustausch, Multi-Delivery (ein und derselbe Inhalt kann auf verschiedenen 

Endgeräten unterschiedlich präsentiert werden) und intelligente Suche 

(statt einfacher Schlagwortsuche auch strukturbasierte Suche in Dokumenten möglich). 

Um eine Vorstellung eines XML-Dokumentes zu erhalten wird mit Abbildung 2 

mit dem Aufbau eines Handy-Kataloges die XML-Syntax kurz erläutert. 

Wurzelelement 

Elementname 

Subelement 

Elementinhalt 

 

 

 

 

 

 

141g 

50 

400 

 

 

... 

 

 

... 

 

Prolog 

Kommentar 

Attribut 

Attributwert 

Abbildung 2: Beispiel für XML-Dokument [Kappel 2001a, 23]


Durch diese Definition eines Handykataloges wird die Struktur von XML schnell ersichtlich, 

da sie einen ähnlichen Aufbau wie HTML aufweist. Auch ein XML-Dokument 

besteht aus mehreren Tags, welche die Element- bzw. Attributwerte ausdrücken. 

Folgende Unterschiede kann man jedoch im Gegensatz zu HTML feststellen: 

‣ Jedes Element (z. B. Hersteller aus Abbildung 2) muss mit einem Tag 

abgeschlossen werden. Bspw. benötigt der Start-Tag einen 

End-Tag . Nicht abgeschlossene Tags wie in HTML 

gibt es nicht. 

‣ Elemente dürfen sich nicht überlappen. Folgende Überlappung von Tags in 

HTML-Syntax kann man in XML nicht nachbilden, wobei zur besseren 

Darstellung die durch die Tags hervorgerufenen HTML-Formatierungen 

auch in diesem Dokument ersichtlich sind: 

Text fettText fett und kursiv Text nur kursiv 

Text normal. 

In XML müsste der Start-Tag vorher mit einem End-Tag abgeschlossen 

werden, bevor der End-Tag verwendet werden kann. 

‣ Leere Elemente können in Kurzform angeschrieben werden. Bspw. kann der 

Ausdruck durch 

vereinfacht werden. Leer ist ein Element, 

wenn zwischen Start- und End-Tag keine Werte auftreten. 

‣ Attributwerte müssen unter Anführungszeichen oder Hochkomma gesetzt 

werden: oder 

Nach dieser Einführung wird ersichtlich, dass sich XML vor allem auf das Beschreiben 

des Dokumentinhaltes und nicht auf das Layout spezialisiert. Da für das Verständnis 

dieser Arbeit nur ein Teil des XML-Standards erläutert wurde, können weitere 

Details auf [W3C 2002a] nachgelesen werden. 

3.1.2 XML-Schema 

Im vorigen Abschnitt wurde unter anderem erwähnt, dass sich XML für den Datenaustausch 

gut eignet. Ohne XML verläuft ein Austausch von Daten bspw. über DBMS 

(Datenbankmanagementsysteme), wobei die Daten hauptsächlich in Tabellen (ausgenommen 

objektorientierte oder objektrelationale Datenbanken) abgespeichert sind.


Für einen reibungslosen Datenaustausch ist daher eine Einigung der Austauschpartner 

auf eine gemeinsame Tabellenstruktur notwendig. 

Auch bei XML-Dokumenten ist eine Vorgabe der Datenstruktur sinnvoll. Vor der 

Entwicklung von XML-Schema galt die DTD (Document Type Definition) als Standard 

für die Festlegung einer Struktur für XML-Dokumente. Da DTDs schon als veraltert 

gelten und bei weitem nicht die Möglichkeiten von XML-Schema bieten, werden 

sie in dieser Arbeit nicht gesondert behandelt. 

Der neueste Standard zur Definition einer Struktur für XML-Dokumente heißt XML- 

Schema. Ein XML-Schema definiert genau wie die Tabellen eines DBMS, welcher 

Inhalt erlaubt ist. Die Definitionen werden in ASCII-Dateien mit der Endung ".xsd" 

abgelegt. Auf ein XML-Schema basierende XML-Dokumente müssen somit einer 

vorgeschriebenen Struktur entsprechen. Für die Erstellung solcher Dokumente wird 

die Verwendung eines XML-Editors mit Schema-Unterstützung (z. B. XMLSpy 

[Altova 2002]) empfohlen, denn nur durch Validierung des Dokumentes kann eine 

Konsistenz der Daten sichergestellt werden. 

Die folgenden Punkte zeigen die wichtigsten Deklarationsmöglichkeiten von XML- 

Schema auf. Die Anwendungsmöglichkeiten werden in Kapitel 3.5 bei der Definition 

der Schemata für die Entwurfsmuster ersichtlich. Eine vollständige Dokumentation 

(inklusive der Syntax) kann auf [W3C 2002c] nachgelesen werden. 

‣ Vordefinierte Datentypen: Es existieren eine Reihe von vordefinierten Datentypen, 

mit denen der Wertebereich eines Elementes oder eines Attributes 

festgelegt werden kann. Alle vordefinierten Typen werden mit einer Präfix 

"xsd:" angesprochen, z. B. xsd:string, xsd:float und xsd:integer. 

‣ Einfache benutzerdefinierte Datentypen: Um einen einfachen 

benutzerdefinierten Datentyp zu definieren, leitet man von einem vordefinierten 

ab und verändert dessen Wertebereich. Somit ist es z. B: möglich 

Minimal- und Maximalwerte festzusetzen, Listen anzulegen und Zeichenketten 

zu beschränken. 

‣ Komplexe benutzerdefinierte Datentypen: Mit komplexen Datentypen 

können Elemente und Attribute bei der Typdeklaration beliebig tief geschachtelt 

werden. Ein Typ für das Element aus 

Abbildung 2 hat bspw. komplexen Charakter.


‣ Elemente und Attribute: Elemente und Attribute können als global (von 

überall im Schema referenzierbar) oder als lokal (nur in einer Typdeklaration 

referenzierbar) definiert werden. 

‣ Schlüssel: Genau wie in DBMS die Primärschlüssel bei den Tabellen gibt es 

in XML-Schema die Möglichkeit, Elemente, Attribute oder Kombinationen 

von beiden als Schlüssel zu deklarieren, um somit in gewissen Fällen die 

Eindeutigkeit sicherzustellen. 

XML-Schemata werden häufig verwendet, um komplexere Datenstrukturen zu modellieren. 

Durch deren sorgfältige Definition und Verwendung können somit Inkonsistenzen 

in XML-Dokumenten vermieden werden. 

3.1.3 Einsatz bei PSE-Admin 

Bei PSE-Admin wurde XML in den folgenden Bereichen eingesetzt: 

‣ Musterdefinition: Die Beschreibung von Entwurfsmustern erfolgt anhand 

von XML-Dokumenten, siehe Abschnitt 4.5.2 und 4.6.2. 

‣ Strukturdefinition: Alle XML-Dokumente, die zur Beschreibung von Entwurfsmustern 

eingesetzt werden, müssen einer festgelegten Struktur folgen, 

die mit XML-Schemata definiert wurde, siehe Abschnitt 4.5.1 und 4.6.1. 

3.2 Eclipse 

Eclipse [Eclipse 2002a] wurde als offene Plattform zur Integration von Werkzeugen 

von einer Gemeinschaft von Werkzeuganbietern (z. B: IBM, Borland, Rational Software, 

SUSE) unter der CPL-Lizenz (Common Public License) entwickelt. CPL ermöglicht 

eine Aneignung von gebührenfreien Quellcode und eine weltweite Verteilung 

der Rechte. Diese Lizenzart erlaubt Entwicklern auch das Erstellen und Vertreiben 

von Anwendungen, die auf Eclipse Quellcode basieren. Die Eclipse Plattform 

stellt somit den Werkzeugentwicklern höchste Flexibilität und Kontrolle über ihre 

Softwaretechnologie zur Verfügung. 

Abbildung 3 zeigt die Struktur von Eclipse, mit der die vorher erwähnte Offenheit des 

Systems erreicht wird.


Abbildung 3: Struktur von Eclipse [Eclipse 2002b, 10] 

Die Eclipse Plattform setzt auf einer Java Virtual Machine auf, d. h. die Implementierung 

erfolgte in der Programmiersprache Java. Auf ihr basieren die Java Entwicklungswerkzeuge 

(JDT – Java Development Tools), die als Erweiterung der Plattform 

entwickelt wurden. Diese Entwicklungswerkzeuge umfassen Editoren, Dateiverwaltung, 

Debug-Werkzeuge usw. Eine Erweiterung von Eclipse wird als Plugin bezeichnet. 

Die letzte Stufe in Abbildung 3 stellt die integrierte Plugin-Entwicklungsumgebung 

(PDE - Plugin Development Environment) dar, mit deren Hilfe die Entwicklung 

von Plugins erleichtert wird. 

3.3 Plugins 

Ein Plugin ist eine Erweiterung der Entwicklungsumgebung Eclipse, die an den verschiedensten 

Stellen stattfinden kann. Diese Stellen werden definiert durch sogenannte 

Extension Points. Die Definition von Extension Points sowie aller anderen Eigenschaften 

von Plugins erfolgt in einer Beschreibungsdatei "plugin.xml", die für jedes 

Plugin vorhanden sein muss. Der Begriff Erweiterung muss in Eclipse sehr weitläufig 

betrachtet werden. So kann sowohl ein HTML-Editor als auch eine Aktion zur Generierung 

von ".zip"-Dateien als Plugin integriert werden. 

Im "plugin.xml" werden alle Eigenschaften von Plugins definiert. Abbildung 4 zeigt 

den Aufbau des "plugin.xml" von PSE-Admin.


Abbildung 4: Aufbau plugin.xml von PSE-Admin 

class 

Gibt an, welche Klasse die Erweiterung von AbstractUIPlugin aus dem Eclipse 

Paket org.eclipse.ui.plugin ist, die zur Ausführung eines Plugins benötigt wird. 

runtime 

Das Element runtime definiert, welche Bibliotheken zur Laufzeit benötigt werden. Im 

Falle von PSE-Admin sind dies vier ".jar"-Dateien, die in den library-Elementen 

aufgelistet sind (siehe Abbildung 5) und auf der gleichen Ebene im Dateisystem wie 

"plugin.xml" liegen müssen. 

Abbildung 5: runtime-Elemente von plugin.xml 

requires 

Legt fest, welche Plugins zur Ausführung benötigt werden. Diese werden in den 

import-Elementen definiert. Für PSE-Admin werden zwei weitere Plugins benötigt, 

die in Abbildung 6 definiert sind. 

Abbildung 6: requires-Elemente von plugin.xml 

extension 

Die Datei "plugin.xml" kann mehrere extension-Elemente enthalten, in denen festgelegt 

wird, aus welchen Teilen das Plugin besteht und an welcher Stelle es in der


Entwicklungsumgebung aktiv werden soll. Bei PSE-Admin wird ein extension-Element 

verwendet, dessen Struktur in Abbildung 7 ersichtlich ist. 

Abbildung 7: extension-Element von plugin.xml 

Die Subelemente von extension haben folgende Bedeutung: 

‣ point: Der Wert "org.eclipse.ui.views" bedeutet, dass die Komponenten dieses 

Plugins als View verwendet werden. Eine View ist ein frei positionierbares 

Fenster in Eclipse, dass eine gewisse Aufgabe erfüllt und über einen 

speziellen Menüpunkt aktiviert werden kann. 

‣ category: Gibt an, in welche Kategorie(en) die Views eingeordnet werden 

können. Der Wert "pattern" für das Element id dient zur Sicherstellung der 

Eindeutigkeit und wird für die Referenzierung durch die view-Elemente benötigt. 

Je extension-Element können mehrere Kategorien definiert werden. 

‣ view: Zur Festlegung der vorhandenen Views ist es notwendig, diese mit 

den folgenden Subelementen genauer zu definieren: 

o name: Name der View – erscheint in Eclipse in einem Menüpunkt, der 

die Auswahl der vorhandenen Views erlaubt. 

o icon: Bild, dass bei der Auswahl von Views vor dem Text angezeigt 

wird. 

o category: Definiert die Kategoriezugehörigkeit dieser View. Der Wert 

in category muss einem Wert des Elementes id (bei PSE-Admin ist 

dies nur "pattern") entsprechen. Die Kategoriezuordnung ist genau wie 

die Vergabe eines Namens wichtig für den Menüpunkt zur Auswahl 

der vorhandenen Views.


o class: Erweiterung der Klasse org.eclipse.ui.views.ViewPart, die 

vorhanden sein muss, um eine View in einem Plugin zu verwenden. Bei 

PSE-Admin ist liegt diese Klasse in der Bibliothek pattern.jar. 

o id: Eindeutiger Name für die View. Meistens verwendet man den Klassennamen, 

da dieser in Verbindung mit der Paketangabe sicher eindeutig 

ist. 

Für die Anwendung von PSE-Admin reichen diese Elementdefinitionen. Im 

"plugin.xml" können jedoch bei anderen Anwendungsgebieten weit mehr Konfigurationen 

vorgenommen werden, die in [Eclipse 2002b] nachgelesen werden können. 

3.4 Inbetriebnahme von PSE-Admin 

Für die Inbetriebnahme von PSE-Admin müssen noch einige Komponenten installiert 

bzw. Werte in Konfigurationsdateien gesetzt werden. Diese Punkte werden in den 

folgenden Abschnitten behandelt. 

3.4.1 Pfadstruktur 

Der Einsatz von PSE-Admin erfordert eine gewisse Pfadstruktur, da alle Eclipse- 

Plugins und auch die verwalteten Muster in einem vordefinierten Verzeichnis liegen 

müssen. Daher werden für den weiteren Verlauf dieser Arbeit einige Platzhalter für 

Pfade in Tabelle 2 eingeführt. 

Platzhalter 

ECLIPSE_ROOT 

PLUGIN_ROOT 

PATTERN_ROOT 

Beispielpfad 

"e:\eclipse\" 

"e:\eclipse\plugins\" 

"e:\eclipse\patternFiles\" 

Tabelle 2: Pfadstruktur PSE-Admin 

ECLIPSE_ROOT gibt das Installationsverzeichnis der Entwicklungsumgebung 

Eclipse an. Als Beispielpfad wurde "e:\eclipse\" gewählt. Das Plugin-Verzeichnis ist 

immer das Unterverzeichnis "\plugins\" unter dem Installationsverzeichnis. Gemäß 

Tabelle 2 ist dies der Pfad "e:\eclipse\plugins\" für den PLUGIN_ROOT als Platzhalter 

verwendet wird. 

Die Verwaltung und Definition von Entwurfsmustern mit PSE-Admin erfordert eine 

zusätzliche Pfadstruktur. Wichtig ist hierbei vor allem ein Wurzelverzeichnis für die


Verwaltung der Muster anzugeben, z. B: "e:\eclipse\patternFiles\". Als Platzhalter für 

das Wurzelverzeichnis wird PATTERN_ROOT verwendet. Für jedes Entwurfsmuster 

das verwaltet werden soll, muss weiters ein Verzeichnis unter PATTERN_ROOT mit 

dem jeweiligen Namen angelegt werden. Bei dem Muster Abstract Factory lautet ein 

vollständiger Pfad daher "e:\eclipse\patternFiles\Abstract Factory". Alle Beschreibungs- 

und Dokumentationsdateien des Musters müssen in diesem Ordner liegen. 

Welche Dateien für eine Definition eines Entwurfsmusters notwendig sind wird in 

Abschnitt 4.5.2 und 4.6.2 erläutert. 

Neben diesen Verzeichnissen werden auch noch einige Dateien laut Tabelle 3 

benötigt. 

Datei 

pattern_configuration.xml 

config_file_description.xsd 

pattern_general.xsd 

pattern_implementation.xsd 

Pfad 

ECLIPSE_ROOT 

ECLIPSE_ROOT 

PATTERN_ROOT 

PATTERN_ROOT 

Tabelle 3: Benötigte Dateien PSE-Admin 

"pattern_configuration.xml" dient zur Konfiguration von PSE-Admin und wird ebenso 

wie sein XML-Schema "config_file_description.xsd" in Abschnitt 3.4.3 näher behandelt. 

"pattern_general.xsd" und "pattern_implementation.xsd" sind XML-Schemata, 

welche die Definition der Entwurfsmuster regeln. Sie werden in den Abschnitten 4.5.1 

und 4.6.1 erläutert. 

3.4.2 Benötigte Komponenten 

Für die Verwendung von PSE-Admin werden folgende Komponenten benötigt: 

‣ Entwicklungsumgebung Eclipse: Diese, derzeit für die Programmierung 

mit Java konzipierte Umgebung ist bei [Eclipse 2002a] kostenlos erhältlich 

und bildet den Rahmen für die Anwendung von PSE-Admin. 

‣ Java Runtime Environment (JRE): Da Eclipse in Java implementiert ist, 

wird eine Java Virtual Machine benötigt, mit der in Java entwickelte Programme 

ausgeführt werden können. Diese wird bspw. durch eine Java Runtime 

Environment [Sun 2002b] installiert. Empfohlen werden alle Versionen 

ab 1.3.1.


‣ PSE-Admin-Plugin: Das PSE-Admin-Plugin muss in den Pfad 

PLUGIN_ROOT kopiert werden. Nach der Initialisierung durch das Starten 

von Eclipse kann PSE-Admin verwendet werden. 

Da bei der Entwicklung von PSE-Admin Komponenten des Betriebssystems Windows 

verwendet wurden (siehe Abschnitt 7.2.4), ist PSE-Admin auf jedem Windows- 

Betriebssystem mit installierter Java Virtual Machine und Entwicklungsumgebung 

Eclipse einsetzbar. 

3.4.3 Globale Konfigurationsdatei 

PSE-Admin benötigt eine globale Konfigurationsdatei mit dem Namen 

"pattern_configuration.xml", in dem einige Werte eingetragen werden müssen. Jeder 

dieser Werte hat einem ihm zugewiesenem Schlüssel, um die Eindeutigkeit zu gewährleisten. 

Die Definition dieser Datei und dessen XML-Schema wird in den folgenden 

zwei Abschnitten erläutert. 

Schema 

Das Schema trägt den Namen "config_file_description.xsd" und hat im Verzeichnis 

ECLIPSE_ROOT zu liegen. Seine Struktur wird in Abbildung 8 ersichtlich. 

Abbildung 8: Schema für globale Konfigurationsdatei 

Das Wurzelelement configFile hat den Typ ConfigFileType und besteht somit aus 

null bis unendlich vielen configKey-Elementen. ConfigKey besteht wiederum aus 

einem Element key (Schlüsselbegriff vom Typ xsd:string) und value (Wert vom 

Typ xsd:string). 

Definition 

Abbildung 9 zeigt die Werte, die in der globalen Konfigurationsdatei gesetzt werden 

müssen. Diese muss das in Abbildung 8 vorgestellte XML-Schema referenzieren.


Abbildung 9: Werte der globalen Konfigurationsdatei 

Die Werte in der Konfigurationsdatei haben folgenden Bedeutung: 

‣ "patternRoot": Gibt das Wurzelverzeichnis für die Entwurfmuster an. 

‣ "language": Legt die aktuell verwendete Programmiersprache fest. Da mit 

PSE-Admin Entwurfsmuster in verschiedenen Programmiersprachen verwaltet 

werden können, muss festgelegt werden, mit welcher Sprache das 

System arbeiten soll. 

‣ "logFile": Gibt an, in welche Datei mitprotokolliert werden soll. 


Dieses Kapitel befasste sich mit dem Konzept und den Erweiterungsmöglichkeiten 

(Plugins) der Entwicklungsumgebung Eclipse. Jedes Plugin benötigt eine Beschreibungsdatei 

"plugin.xml", die anhand PSE-Admin erläutert wurde. Den Abschluss bildete 

eine Beschreibung der Inbetriebnahme von PSE-Admin, wobei mit einem XML- 

Exkurs zu Beginn dieses Kapitels die notwendigen Grundlagen geschaffen wurden.

PSE-D - Definition von Entwurfsmustern 28 

4 PSE-D - Definition von Entwurfsmustern 

PSE-D wurde für die flexible Definition und Verwaltung von Entwurfsmustern und 

deren Dokumentation entwickelt. Der Aufbau einer Muster-Infrastruktur laut PSE-D 

bildet die Basis für die Anwendung des Werkzeuges PSE-V (siehe Kapitel 6), mit 

dessen Hilfe die Visualisierung der verwalteten Muster und deren Dokumentation 

ermöglicht wird. Auch PSE-Application verwendet über Programmierschnittstellen 

(siehe Abschnitt 5.1)die durch PSE-D definierte Datenstruktur. 

Dieses Kapitel legt die Struktur und die genaue Definition der Entwurfsmuster dar, die 

mit Hilfe des Beispielmusters Abstract Factory erläutert wird. Weiters wird der besondere 

Stellenwert der Rollen von Mustern hervorgehoben. 

4.1 Beispiel: Abstract Factory 

Das Muster Abstract Factory bietet eine Schnittstelle zum Erzeugen von verwandten 

oder voneinander abhängigen Objekten, ohne Kenntnis ihrer konkreten Klasse. Ein 

Beispiel für eine Anwendung ist ein System mit grafischer Benutzerschnittstelle, das 

mehrere look and feels 3 (z. B. vom Betriebsystem Windows und Apple-Macintosh) 

unterstützen soll. Für diesen Zweck ist es notwendig, die grafischen Komponenten 

austauschbar zu gestalten, ohne dass der Rest der Implementierung geändert werden 

muss. Abbildung 10 illustriert die allgemeine Architektur von Abstract Factory. 

3 Als look and feel wird das Aussehen und Verhalten einer Anwendung bezeichnet.


«interface» 

AbstractFactory 

Client 

+createAbstractProductA() 

+createAbstractProductB() 

«interface» 

AbstractProductA 

ProductA1 

ProductA2 

ConcreteFactory1 

ConcreteFactory2 





«interface» 

AbstractProductB 

ProductB1 

ProductB2 

Abbildung 10: Allgemeine Architektur von Abstract Factory [Gamma 1995, 88] 

Für die Anwendung des Musters sind folgende Rollen relevant: 

‣ AbstractFactory: Definiert eine Schnittstelle für die Erzeugung abstrakter 

Produkte. 

‣ ConcreteFactory: Implementiert die Schnittstellen von AbstractFactory 

um Produkte zu erzeugen. 

‣ AbstractProduct: Definiert eine Schnittstelle für ein Produkt. 

‣ Product: Implementiert die Schnittstellen von AbstractProduct und wird 

von ConcreteFactory erzeugt. Product repräsentiert damit ein konkretes 

Produkt (bspw. ein Fenster von Windows). 

‣ Client: Verwendet nur die Schnittstellen, die in AbstractFactory und 

AbstractProduct definiert wurden. 

Bei Verwendung dieses Musters für die Unterstützung mehrerer look and feels gestaltet 

sich die konkrete Architektur gemäß Abbildung 11.


«interface» 

WidgetFactory 

Client 

+createWindow() 

+createScrollbar() 

«interface» 

Window 

WindowsWindow 

MacWindow 

WindowsFactory 

MacFactory 


+createScrollBar() 


+createScrollBar() 

«interface» 

ScrollBar 

WindowsScrollBar 

MacScrollBar 

Abbildung 11: Beispielarchitektur bei Anwendung von Abstract Factory 

WidgetFactory definiert die Schnittstellen mit der die implementierenden Klassen 

WindowsFactory und MacFactory die look and feel Komponenten instanzieren. Diese 

werden durch die Schnittstellen Window und ScrollBar identifiziert. Eine Klasse 

WindowsWindow implementiert bspw. das Aussehen und Verhalten eines Fensters des 

Betriebssystem Windows und eine Klasse MacWindow jenes von Apple-Macintosh. 

Eine Anwendung (Klasse Client) arbeitet nur mit den Methoden in den Schnittstellen 

und braucht sich nicht um die Instanzierung der Komponenten kümmern. Somit 

können diese ohne weiteres ausgetauscht werden, ohne dass die Implementierung von 

Client geändert werden muss. 

4.2 Rollen 

Rollen wurden schon im Abschnitt 2.1.2 kurz erwähnt, da sie jedoch in der weiteren 

Arbeit vor allem bei der Definition der Entwurfsmuster wichtig sind, werden ihre Eigenschaften 

noch einmal gesondert behandelt. 

Laut [Gamma 1995] sind Rollen Klassen und/oder Objekte, die für die Lösung eines 

Entwurfsproblems notwendig sind. Beim Muster Abstract Factory sind dies fünf Rollen, 

die in geeigneter Art und Weise zusammenspielen, um das Problem der anonymen 

Objektinstanzierung zu lösen (siehe Abbildung 10). Bei einer Anwendung eines


Entwurfsmusters müssen verschiedene Klassen die Rollen des Musters spielen. In 

Abbildung 11 spielt bspw. die Klasse Window die Rolle AbstractProduct. 

Laut [Gamma 1995] hat jede Rolle einen Namen und eine kurze Beschreibung ihrer 

Aufgabe. Für die Entwicklung von PSE-Admin wurde der Rollenbegriff um die Eigenschaften 

Typ, Codekopf, Codekörper und Häufigkeit erweitert. Folgende Eigenschaften 

sind gemäß PSE-Admin einer Rolle zuordenbar: 

1. Name: Bei der Wahl des Namens gelten dieselben Richtlinien wie bei den 

Namen für Muster – sprechende Namen erleichtern die Wiederverwendung. 

2. Beschreibung: Legt die Aufgabe der Rolle bei Anwendung des Musters dar. 

3. Typ: Beschreibt die Art der Rolle. Sie kann eine Klasse ("class"), eine 

Schnittstelle ("interface"), eine Methode ("method") oder eine Variable 

("variable") sein. 

4. Codekopf: Besteht bei den Typen "class" und "interface" aus einer 

Klassendefinition und bei den Typen "method" und "variable" aus einer 

Methoden- bzw. Variablendefinition. 

5. Codekörper: Der Codekörper zeigt eine konkrete Beispielimplementierung 

der Rolle. Bei einem Typ "variable" entfällt er, da eine Rolle dieses Typs bereits 

im Codekopf die Definition bzw. Initialisierung erhält. 

6. Häufigkeit: Gibt an, wie oft eine Rolle bei der Anwendung des Musters auftreten 

kann. Mögliche Werte sind "*" für 0-n-maliges Vorkommen, ganze 

Zahlen und Kombinationen ("1..*, "1..2" usw.). 

Die Rolle AbstractProduct des Musters AbstractFactory hat laut PSE-Admin bspw. 

folgende die Eigenschaften gemäß Tabelle 4. 

Eigenschaft 

Name 

Beschreibung 

Typ 

Codekopf 

Ausprägung 

AbstractProduct 

Definiert eine Schnittstelle für ein Produkt 

interface 

public interface AbstractProduct{} 

Codekörper 

Häufigkeit 1 

Tabelle 4: Eigenschaften der Rolle AbstractProduct


AbstractProduct ist eine Schnittstelle, daher erhält sie den Typ "interface". Der 

Codekopf zeigt eine leere Klassendefinition. Die Eigenschaft Codekörper bleibt noch 

leer, da im voraus keine Aussagen über die Methoden eines Produktes getroffen werden 

können. Als Häufigkeit wurde "1" festgelegt, damit kann bei der Anwendung des 

Musters nur eine Klasse diese Rolle spielen. 

Durch diese Erweiterung des Rollenbegriffs können schon bei der Definition konkrete 

Richtlinien und Einschränkungen für die Anwendung eines Entwurfsmusters gegeben 

werden. 

4.3 Struktur der Musterverwaltung 

Die Definition eines Entwurfsmusters gliedert sich in eine allgemeine und eine oder 

mehrere implementierungsspezifische Beschreibung(en), in der die Rollen des 

Musters definiert werden. Im weiteren Verlauf dieser Arbeit wird daher auch das Synonym 

Rollenbeschreibung für den implementierungsspezifischen Teil verwendet. Das 

Hauptziel bei der Entwicklung von PSE-D war die Trennung dieser beiden Teile, um 

für ein Muster mehrere Rollenbeschreibungen verwalten zu können. Der Aufbau eines 

Entwurfsmusters kann daher laut PSE-D eine Struktur gemäß Abbildung 12 aufweisen. 

Rollenbeschreibung 

Java (XML) 

folgt 

allgemeine 

Beschreibung (XML) 

verweist 

XML-Schema f. 


folgt 

folgt 

XML-Schema f. allg. 

Beschreibung 


C++ (XML) 

Abbildung 12: Struktur der Musterverwaltung von PSE-D 

Die allgemeine Beschreibung wird ebenso wie die Rollenbeschreibungen in XML- 

Dokumenten abgelegt. Beide haben je einem XML-Schema zu entsprechen, in dem 

der Aufbau der Beschreibungsdateien festgelegt wird. Eine allgemeine Definition 

kann auf mehrere Rollenbeschreibungen verweisen, somit kann ein Muster in mehre-


ren Programmiersprachen verwaltet werden. In Abbildung 12 verweist eine allgemeine 

Beschreibung auf zwei Rollenbeschreibungen (Java und C++). 

4.4 Entwurfsziele 

Bei der Entwicklung von PSE-D wurden folgenden Entwurfsziele verfolgt: 

‣ Flexibilität bei Definition und Verwaltung: Es muss möglich sein, die in 

der Literatur derzeit beschriebenen Entwurfsmuster im System abzulegen, 

aber auch neue zu definieren. Entwickler erhalten damit die Möglichkeit, 

sich eigene Problemlösungen als Muster zu verwalten. 

‣ Flexibilität der Dokumentation: Die Dokumentation der Muster muss in 

HTML- oder gewöhnlichen ASCII-Dateien, aber auch direkt in der allgemeinen 

Beschreibungsdatei (siehe Abschnitt 4.5.2) erfolgen können. Eine 

freie Definition der Bestandteile ist zusätzlich erforderlich. 

‣ Progammiersprachenunabhängigkeit: Entwurfsmuster müssen im System 

in verschiedenen Programmiersprachen verwaltet werden können. 

Der genaue Aufbau der Entwurfsmuster wird in den folgenden Abschnitten erläutert. 

4.5 Allgemeine Beschreibung 

Eine allgemeine Beschreibung muss exakt einmal für jedes Entwurfsmuster existieren 

und legt folgenden Eigenschaften fest: 

‣ Name 

‣ Klassifizierung 

‣ Kategoriezugehörigkeit 

‣ Aufbau der Dokumentation 

‣ Anzahl und Art der Rollenbeschreibungen 

Sie wird in einem XML-Dokument abgespeichert, das ein globales, einmal im System 

vorhandenes XML-Schema referenziert.


4.5.1 Schema 

Jede allgemeine Beschreibung muss einem XML-Schema entsprechen. Dieses 

Schema wird in einer Datei mit dem Namen "pattern_general.xsd" (siehe Abschnitt 

3.4.1) abgespeichert. Seine Struktur wird in Abbildung 13 dargestellt. 

Abbildung 13: Schema für allgemeinen Beschreibungsteil 

Jedes XML-Schema benötigt ein Wurzelelement, dass alle anderen enthält. In 

Abbildung 13 lautet der Name dieses Elementes pattern und hat den Typ 

PatternType, der aus folgenden Elementen besteht: 

name 

Gibt den Namen des Musters an. Die Kardinalität dieses Elementes ist "1", da der 

Name des Musters innerhalb der Beschreibungsdatei eindeutig sein muss (keine Kardinalitätsangabe 

beim Element bedeutet Kardinalität "1"). Der Typ ist xsd:string 

(Zeichenkette). 

classification 

Zeigt die Klassifizierung des Musters. Es gibt Objektmuster und Klassenmuster (siehe 

Abschnitt 2.1.2). Der Elementtyp ist daher eine Liste mit den Werten "class" und 

"object". Da ein Muster auch beide Klassifizierungen aufweisen kann, wurde eine 

Kardinalität "1..2" festgelegt.


description 

Jedes Muster kann null bis unendlich viele Beschreibungen enthalten. Ein 

description-Element hat den Typ DescriptionType, der aus den folgenden Subelementen 

besteht (Ein konkretes Anwendungsbeispiel folgt im nächsten Abschnitt): 

‣ headerName: Name des Beschreibungselementes vom Typ xsd:string. 

‣ headerType: Typ des Beschreibungselementes. Der Typ ist eine Liste mit 

den Werten "overview", "detail" und "category". Der Wert "category" ist 

zuständig für die Kategoriedefinition, die Werte "detail" und "overview" für 

den Dokumentationsaufbau des Musters. 

‣ content: Inhalt des Beschreibungselementes vom Typ xsd:string. 

‣ contentType: Typ des Inhalts. contentType ist eine Liste mit den Werten 

"file" und "text". Beim Wert "text" für contentType wird der Inhalt des 

Elementes content (ASCII-Text im XML-Dokument) verwendet. Beim 

Wert "file" enthält das Element content den Namen einer Datei. Damit 

wird der Inhalt für das Beschreibungselement aus dieser Datei entnommen, 

wobei diese im aktuellen Verzeichnis des Entwurfsmusters liegen muss. 

implementation 

Ein Entwurfsmuster benötigt zumindest eine Rollenbeschreibung, deren Lokalisierung 

in diesem Element definiert wird. Der Typ von implementation ist xsd:string. 

Tabelle 5 fasst die Elemente des XML-Schemas kurz zusammen. 

Element Typ Kurzbeschreibung 

name xsd:string Name des Musters 


Liste mit den Werten "class" und 

"object" 

Klassifizierung des Musters 

description Komplexer geschachtelter Datentyp Beschreibung des Musters 

headerName xsd:string Name des Beschreibungselementes 

headerType 

Liste mit den Werten "overview", 

"detail" und "category" 

Typ des Beschreibungselementes 

content xsd:string Inhalt des Beschreibungselementes 

contentType 

Liste mit den Werten "file" und 

text" 

Typ des Inhalts 

implementation xsd:string Lokalisierung der Rollenbeschreibung 

Tabelle 5: Elemente des XML-Schemas


4.5.2 Definition 

Die genaue Definition der allgemeinen Beschreibung eines Entwurfsmusters hat in 

einem XML-Dokument mit dem Namen "manifest.xml" zu erfolgen. Dieses Dokument 

muss wie in Abschnitt 3.4.1 beschrieben in dem Verzeichnis des Musters liegen. 

Eine vollständige Pfadangabe lautet daher bspw. "e:\eclipse\patternFiles\Abstract 

Factory\manifest.xml" lauten. Für die Erstellung der XML-Definitionen wird ein gängiger 

XML-Editor mit XML-Schema Unterstützung empfohlen, z. B. XMLSpy 

[Altova 2002]. 

Um die Struktur der allgemeinen Beschreibung zu erläutern, wird das vorher beschriebene 

Muster Abstract Factory verwendet. Abbildung 14 zeigt die allgemeine 

Beschreibungsdatei von Abstract Factory, deren Struktur genau dem im vorigen Abschnitt 

beschriebenem XML-Schema entsprechen muss. Das Wurzelelement pattern 

wird dabei aus Gründen der Übersichtlichkeit der Abbildung nicht dargestellt! 

Abbildung 14: Allgemeine Beschreibung von Abstract Factory 

name 

Der Name des Musters lautet Abstract Factory. Da die allgemeine Beschreibung für 

jedes Entwurfsmuster in einem XML-Dokument "manifest.xml" abgespeichert ist und 

die Bezeichnung dieser Datei keine Rückschlüsse auf den Namen des Musters zulässt, 

dient dieses Element zur Identifikation des Musters.



Abstract Factory ist ein Objektmuster. Es verwendet hauptsächlich Objekte und deren 

Beziehungen zur Problemlösung. 

description 

Die Definition von Abstract Factory besteht unter anderem aus 13 description-Elementen, 

wobei eines für die Kategoriezugehörigkeit (Typ "category") und 12 für den 

Aufbau der Dokumentation verantwortlich sind (Typ "detail" und "overview"). 

implementation 

Der Wert "java" dieses Elementes setzt voraus, dass eine Rollenbeschreibung für dieses 

Muster in einem Dokument "java.xml" existiert, das auf der selben Ebene wie 

"manifest.xml" liegen muss. 

Durch den geschickten Einsatz von description-Elementen ergeben sich verschiedenste 

Möglichkeiten, die am besten durch eine Aufgliederung in die Beschreibungstypen 

(headerType) ersichtlich werden. Für die folgenden Abbildungen wurde zur 

Vereinfachung mit nur einem Muster im System (Abstract Factory) gearbeitet. 

category 

Der Typ "category" ist zuständig für die Kategoriezuordnung des Entwurfsmusters 

und damit auch für die Repräsentation in der Navigationsstruktur. Das erste 

description-Element aus Abbildung 14 (headerName "Gamma") ergibt eine Navigation 

laut Abbildung 15. Als Wurzelknoten wird immer der Wert "Categories" verwendet. 

Abbildung 15: Kategoriebeispiel 1 

Abstract Factory wird somit als Teil der Kategorie "Creational Patterns" dargestellt, 

die wiederum eine Unterkategorie von "Gamma" ist. 

Um eine einstufige Kategoriezuordnung zu erzwingen, muss man den Wert "Gamma" 

aus Abbildung 14 auf den Wert "Creational Patterns" ändern. Damit haben beide Elemente 

denselben Wert, womit eine Einstufigkeit erzwungen wird. Das Ergebnis präsentiert 

sich in Abbildung 16.



Um eine Zuordnung eines Musters zu verschiedenen Kategorien zu erreichen (siehe 

Abbildung 17), muss man ein zusätzliches Kategorieelement in die allgemeine 

Beschreibungsdatei integrieren. Abbildung 18 gibt hierfür ein konkretes Beispiel. 


Abbildung 18: Zusätzliches Kategorieelement 

Das Muster ist bei dieser Art der Definition in beiden Kategoriebäumen dargestellt, 

wobei die Dokumentation nur einmal existiert. Eine Zuordnung zu mehreren Kategorien 

erscheint jedoch häufig als sinnvoll. 

Mit diesen Definitionarten ist es möglich, auf zwei Ebenen verschiedenste Kategoriezuordnungen 

für ein Muster zu definieren. 

overview und detail 

Diese beiden Ausprägungen definieren, wie sich die Dokumentation des Musters zusammensetzt. 

Aus den einzelnen Bausteinen wird zur Laufzeit von PSE-V eine 

Gesamtdokumentation im HTML-Format mit dem Namen des Musters erstellt (z. B: 

"Abstract Factory.html"), die sich gemäß Definition laut Abbildung 14 für das Muster 

Abstract Factory in Abbildung 19 darstellt.


Abbildung 19: HTML-Dokumentation für Abstract Factory 

Der Aufbau der Dokumentation erfolgt nach den folgenden Richtlinien: 

Für den Seitenkopf wird ein Inhaltsverzeichnis generiert. Hat ein description-Element 

in "manifest.xml" den Wert "oveview", so befindet sich dieser Teil der Dokumentation 

im Überblicksbereich (gekennzeichnet durch "Overview"). Mit "detail"


befindet er sich im Detailbereich (gekennzeichnet durch "Detail"). Aus allen 

description-Elementen mit einem dieser beiden Werte wird die Gesamtdokumentation 

des Musters erstellt, wobei der Inhalt entweder direkt aus "manifest.xml" (beim 

Wert "text" für contentType) oder aus der referenzierten Datei entnommen wird 

(beim Wert "file" für contentType). Referenziert werden können alle Dateien im 

ASCII-Format, empfohlen wird jedoch HTML, da auch die Gesamtdokumentation 

dieses Format erhält. 

Tabelle 6 zeigt ein Beispiel für ein descriptionElement aus Abbildung 14. 

Element 

headerName 

headerType 

content 

contentType 

Wert 

"Motivation" 

"detail" 

"motivation.html" 

"file" 

Tabelle 6: Beispiel für description Element 

Wichtig bei diesem Teil der Beschreibung ist, dass in der HTML-Datei 

"motivation.html” am Beginn keine Überschrift definiert ist, da diese dynamisch aus 

dem Element headerName entnommen wird. Weiters dürfen auch keine HTML-Überschriften 

(,, usw.) verwendet werden, da diese die Struktur der Gesamtdokumentation 

verfälschen. 

Der Aufbau der Dokumentation folgt derzeit dem Vorschlag von [Gamma 1995, 6-7], 

den Benutzern ist es aber freigestellt, sich einen eigenen Aufbau zu definieren. 

4.6 Rollenbeschreibung 

Die Rollenbeschreibung legt die implementierungsspezifischen Details eines Entwurfsmusters 

fest, indem die Rollen des Musters genau definiert werden. Je Muster 

können mehrere Rollenbeschreibungen (z. B. für jede Programmiersprache eine) verwaltet 

werden, wobei jede ein globales XML-Schema referenzieren muss. 

4.6.1 Schema 

Die Rollenbeschreibung eines Entwurfsmusters muss einem XML-Schema mit der 

Struktur gemäß Abbildung 20 entsprechen. Dieses Schema wird in einer Datei mit 

dem Namen "pattern_implementation.xsd" (siehe Abschnitt 3.4.1) abgespeichert.


Abbildung 20: XML-Schema der Rollenbeschreibung 

Das Wurzelelement implementation hat den Typ LanguageType, der aus folgenden 

Elementen besteht: 

language 

Gibt an, für welche Programmiersprache die Beschreibungsdatei gilt. Die Kardinalität 

dieses Elementes ist "1", da eine Rollenbeschreibung nur für eine Programmiersprache 

gültig sein kann. Der Typ dieses Elementes ist xsd:string. 

role 

Jedes Muster kann verschiedene Rollen (muss aber zumindest eine) haben. Die Subelemente 

von role (Typ RoleType) sind jene Eigenschaften, die in Abschnitt 4.2 

identifiziert wurden. Sie gliedern sich folgendermaßen: 

‣ roleName: Name der Rolle vom Typ xsd:string. 

‣ roleDescription: Beschreibung der Rolle vom Typ xsd:string. 

‣ typeOfRole: Typ der Rolle. Dieses Element ist eine Liste mit den Werten 

"class", "interface", "method" und "variable". 

‣ codeHeader: Codekopf der Rolle vom Typ xsd:string. 

‣ codeBody: Codekörper der Rolle vom Typ xsd:string. Hat das Element 

typeOfRole den Wert "variable", so entfällt dieser.


‣ cardinality: Kardinalität der Rolle vom Typ xsd:string. Mögliche Werte 

sind "*" für 0-n-maliges Vorkommen, ganze Zahlen und Kombinationen 

("1..*, "1..2" usw.). 

Alle Subelemente bis auf codeBody müssen genau einmal auftreten, zumal nicht jede 

Rolle über einen Codekörper verfügen muss. 

4.6.2 Definition 

Im XML-Dokument von Abbildung 14 wurde festgelegt, dass es eine Rollenbeschreibung 

(Element implementation) im Dokument "java.xml" gibt. Dieser Teil ist notwendig, 

um die Entwurfsmuster mit PSE-Application [Mayr-Kern 2002] anzuwenden, 

da dieses Werkzeug auf die von PSE-D zur Verfügung gestellten Schnittstellen zugreift 

(siehe Abschnitt 5.1) und damit die Informationen über die verwalteten 

Entwurfsmuster verwendet. 

Genau wie die allgemeine Beschreibung muss auch die Rollenbeschreibung ein XML- 

Schema (siehe Abschnitt 4.6.1) referenzieren, um die Konsistenz der Daten sicher zu 

stellen. Abbildung 21 und Abbildung 22 zeigen die Rollenbeschreibung für das Entwurfsmuster 

Abstract Factory, wobei diese zur besseren Übersichtlichkeit in zwei 

Abbildungen geteilt wurde (bei der Definition mit XMLSpy ist keine Zweiteilung 

erforderlich). 

Abbildung 21: Rollenbeschreibung von Abstract Factory (1/2) 

Das Element language gibt an, für welche Programmiersprache diese Rollenbeschreibung 

gilt. Weiters wird für jede der fünf Rollen der Name (roleName), eine 

kurze Beschreibung (roleDescription) und der Typ (typeOfRole) festgelegt.


Abbildung 22: Rollenbeschreibung von Abstract Factory (2/2) 

Für jede Rolle muss weiters ein Element codeHeader mit dem Codekopf und 

cardinality mit der Kardinalität definiert werden. Ein Codekörper (codeBody) wird 

nicht zwingend vorgeschrieben. 

Bei der Rolle AbstractFactory enthält das Element codeHeader den Wert "public 

interface $AbstractFactory${}". Das Zeichen "$" wird als Schlüsselzeichen für 

PSE-Application verwendet und hat folgenden Zweck: 

Bei der Anwendung eines Musters kann sich ein Benutzer entscheiden für die Rolle 

AbstractFactory einen anderen Namen (z. B. "WidgetFactory") zu wählen. Bei 

Vergabe dieses Namens wird somit folgender Quellcode für den Codekopf generiert: 

public interface WidgetFactory {} 

Alle Rollennamen (Element roleName), können somit bei der Anwendung durch eigene 

Werte ersetzt werden. Verweist eine Rolle in den Elementen codeHeader oder 

codeBody mit dem Zeichen "$" auf einen Rollennamen, so wird auch dieser durch den 

neuen Wert ersetzt. Entscheidet sich ein Benutzer bspw. den Namen "Window" für die 

Rolle AbstractProduct zu vergeben, so wird der Code public Window 

createWindow(); für den Codekörper von AbstractFactory generiert. Der gesamte 

Quellcode für die Rolle AbstractFactory wird aus codeHeader und codeBody zusammengesetzt 

und ist in Quellcode 1 ersichtlich. 

1 public interface WidgetFactory { 

2 public Window createWindow(); 

3 } 

Quellcode 1: Generierter Code für AbstractFactory


Der Codekopf umschließt bei der Anwendung den Codekörper. Analog gestaltet sich 

die Anwendung von Rollen des Typs "class" und "method". Lediglich bei einer Variable 

entfällt der Codekörper. 

Durch diese Vorgehensweise wird ein flexibles Anwenden von Entwurfsmustern ermöglicht, 

zumal alle variablen Codeteile deklariert und durch die Vergabe von Rollennamen 

mit Werten belegt werden können. 

Für die Erweiterung von Abstract Factory um eine Rollenbeschreibung für z. B. C++, 

müssen folgende Schritte vorgenommen werden: 

1. Hinzufügen eines Elementes implementation mit den Wert "C++" in der 

allgemeinen Beschreibungsdatei "manifest.xml". 

2. Erstellen einer Implementierungsbeschreibung im Dokument "C++.xml" mit 

den Definitionen für die Rollen gemäß C++ Syntax. 

Derzeit wird nur die Verwaltung der Muster in mehreren Programmiersprachen unterstützt. 

PSE-Application bietet eine Implementierung zur Anwendung von Entwurfsmustern 

mit Java-Rollenbeschreibungen, für andere Sprachen fehlen jedoch noch die 

nötigen Werkzeuge. 


Dieses Kapitel behandelte die Definition und Verwaltung von Entwurfsmustern und 

deren Dokumentation. Es wurde festgestellt, dass eine Aufteilung der Definition in 

einen allgemeinen und eine oder mehrere implementierungsspezifische Beschreibungsteil(e) 

ein Verwalten von Mustern in mehreren Programmiersprachen erlaubt. 

Diese Beschreibungen werden in XML-Dokumenten angelegt, die alle auf XML- 

Schemata, in denen die Datenstruktur festgelegt ist, verweisen müssen. Die Dokumentation 

von Mustern kann direkt in die allgemeine Beschreibungsdatei geschrieben 

oder in ASCII-Dateien ausgelagert werden, wobei mit dem Werkzeug PSE-V zur 

Laufzeit eine Gesamtdokumentation im HTML-Format erzeugt wird. Die Teile der 

Dokumentation sind dabei frei definierbar. 

Mit dieser Vorgehensweise wird eine freie, flexible und programmiersprachenunabhängige 

Definition und Verwaltung von Entwurfsmustern ermöglicht.

PSE-D – Implementierungsbeschreibung 45 

5 PSE-D – Implementierungsbeschreibung 

Dieses Kapitel beschreibt die Implementierung von PSE-D. Da ein Großteil der Implementierung 

die zur Verfügung gestellten Programmierschnittstellen für den Zugriff 

auf die verwalteten Entwurfsmuster betrifft, liegt der Schwerpunkt in diesem Kapitel 

auch in der genauen Beschreibung dieser Schnittstellen. Ein Anwendungsbeispiel soll 

dabei den konkreten Zugriff auf die interne Datenstruktur erläutern. Den Abschluss 

bildet die Beschreibung der Initialisierung der Datenstruktur. 

Die für die Implementierung von PSE-D verantwortlichen Klassen befinden sich ausschließlich 

im Paket pattern.base.datatype, daher wurde auf eine Darstellung der 

Architektur verzichtet. 

5.1 Programmierschnittstellen 

PSE-D bietet für bspw. andere Werkzeughersteller die Möglichkeit, auf die verwalteten 

Entwurfsmuster über Programmierschnittstellen zuzugreifen. Dafür ist die Repräsentation 

der Muster in einer internen Datenstruktur notwendig. Diese Struktur, die 

Möglichkeiten des Zugriffs und ein detailliertes Anwendungsbeispiel sind Gegenstand 

der folgenden Abschnitte. 

5.1.1 Interne Datenstruktur 

Die Entwurfsmuster werden bei PSE-D auf der Basis von XML im Dateisystem verwaltet. 

Um mittels Schnittstellen auf diese Struktur zuzugreifen, ist eine Klassenepräsentation 

dieser Muster notwendig, die in Abbildung 23 dargestellt ist.


PatternAdmin 

+clear() 

+getPatternCategoryList() 

+getPatternInfoList() 

+getPatternContainer() 

1 * 

PatternContainer 

PatternCategory 

PatternInfo 



+setPatternCategoryList() 

+setPatternInfoList() 

RoleNotAvailableException 

* 

1 * 

1 

+addCategory() 

+getCategory() 

+getCategoryList() 

+getName() 


+removeCategory() 

+setName() 


1 

* 

1 

1 * 


+getClassificationList() 

+getDescriptionList() 

+getName() 

+getPattern() 

+setCategoryList() 

+setClassificationList() 

+setDescriptionList() 

+setName() 

+setPattern() 

1 

1 

* 

PatternRole 

Pattern 

PatternDescription 

+getCardinality() 

+setCardinality() 

+getCodeBody() 

+setCodeBody() 

+getCodeHeader() 

+setCodeHeader() 

+getDescription() 

+setDescription() 

+getName() 

+setName() 

+getType() 

+setType() 

+getClassRoleList() 

+getInterfaceRoleList() 

+getLanguage() 

+getName() 

+getMethodRoleList() 

+getRole() 

+getRoleList() 

+getVariableRoleList() 

+setName() 

+setLanguage() 

+getContent() 

+getContentType() 

+getHeaderName() 

+getHeaderType() 

+isCategory() 

+isDetailed() 

+isFile() 

+isPartOfOverview() 

+setContent() 

+setContentType() 

+setHeaderName() 

+setHeaderType() 

Abbildung 23: Klassendiagramm Datenstruktur von PSE-D 

Die Klasse PatternAdmin ist zuständig für den Zugriff auf die interne Datenstrukur. 

Sie wird gesondert in Abschnitt 0 beschrieben. Die anderen Klassen haben folgende 

Bedeutung: 


PatternContainer stellt das Wurzelobjekt der internen Musterdatenstruktur dar. Ein 

Objekt dieser Klasse enthält eine Liste der vorhandenen PatternCategory- und 

PatternInfo-Objekte. Mit einem PatternContainer-Objekt kann der Einstieg in die 

Struktur somit von zwei verschiedenen Punkten erfolgen.



Ein Objekt der Klasse PatternCategory verwaltet den Namen einer Kategorie und 

eine Liste aller Objekte vom Typ PatternInfo, die dieser Kategorie angehören. Zumal 

Kategoriezuordnungen auf maximal zwei Ebenen erfolgen können (siehe 

Abschnitt 4.5.2) ist die Verwaltung einer zusätzlichen Liste von PatternCategory- 

Objekten erforderlich. Um diese Kindobjekte hinzuzufügen bzw. wieder zu entfernen, 

stehen die Methoden addCategory() und removeCategory() zur Verfügung. Um ein 

Kindobjekt per Namen zu erhalten, kann die Methode getCategory() verwendet 

werden. 

PatternInfo 

Die Klasse PatternInfo kapselt den allgemeinen und den implementierungsspezifischen 

Beschreibungsteil eines Entwurfsmusters. Sie enthält den Namen des Musters, 

eine Liste der Klassifizierungen und eine Liste von PatternDescription-Objekten 

zur Repräsentation der allgemeinen Beschreibung. Ein Objekt vom Typ Pattern ist 

für den Implementierungsteil zuständig. Weiters wird eine Liste von 

PatternCategory-Objekten verwaltet, welche die Kategorien des Musters enthält. 

Für alle Eigenschaften wurden wieder get- und set-Methoden implementiert. 


Ein Objekt der Klasse PatternDescription repräsentiert ein description-Element 

gemäß der allgemeinen Beschreibungsdatei "manifest.xml". Neben Methoden für den 

Zugriff und die Bearbeitung der Subelemente von description stehen weiter Methoden 

zur Verfügung die in Tabelle 7 dargestellt sind. 

Methode 

isCategory() 

isPartOfOveview () 

isDetailed() 

hasPath() 

Beschreibung 

Überpüft, ob ein Beschreibungselement eine Kategorie ist. 

Gibt an, ob ein Beschreibungselement Teil des Überblicks ist. 

Gibt an, ob ein Beschreibungselement Teil der Detailbeschreibung ist. 

Zeigt, ob der Inhalt des Beschreibungselementes in einer externen 

Datei liegt oder direkt aus der Beschreibungsdatei entnommen werden 

kann. 

Tabelle 7: Zusatzfunktionalitäten von PatternDescription 

Diese Methoden sind für die Kategoriezuordnung und die Erstellung der Musterdokumentation 

notwendig.


Pattern 

Mit der Klasse Pattern wird der implementierungsspezifische Beschreibungsteil eines 

Entwurfsmusters abgebildet. Sie enthält eine Liste der zugeordneten Rollen, den 

Namen und die Programmiersprache des Musters. Um eine spezielle Rolle zu erhalten, 

wurde die Methode getRole() implementiert, die bei Anfrage eines Rollennamens 

ein Objekt der Klasse PatternRole zurückliefert. Existiert die angeforderte 

Rolle nicht, so wird eine Ausnahme vom Typ RoleNotAvailableException geworfen. 

Weiters existieren get- bzw. set-Methoden, um Listen von Rollen eines speziellen 

Typs zu erhalten bzw. zu setzten (z. B. eine Liste aller Rollen vom Typ "class" à 

getClassRoleList()). Um alle Rollen zu erhalten, kann die Methode 

getRoleList() verwendet werden. 

PatternRole 

Die Klasse PatternRole repräsentiert eine Rolle eines Entwurfsmusters mit allen laut 

Abschnitt 4.2 identifizierten Eigenschaften und liefert somit die bei der Anwendung 

erforderlichen Werte. Für den Zugriff bzw. die Bearbeitung der Eigenschaften existieren 

get- und set-Methoden. 

5.1.2 Datenzugriff 

Der Datenzugriff auf die interne Muster-Infrastruktur erfolgt über die Klasse 

PatternAdmin. Die Struktur des Zugriffs wird in Abbildung 24 ersichtlich. 

PatternAdmin 

+clear() 



+getPatternContainer() 

1 1 

1 

1 

* 




+setPatternCategoryList() 



+addCategory() 

+getCategory() 


+getName() 


+removeCategory() 

+setName() 


* 

PatternInfo 


+getDescriptionList() 

+getName() 

+getPattern() 

+setCategoryList() 

+setDescriptionList() 

+setName() 

+setPattern() 

Abbildung 24: Klassendiagramm Datenzugriff von PSE-D


PatternAdmin 

Die Klasse PatternAdmin stellt einige Zugriffsmethoden zur Verfügung, die in 

Tabelle 8 dargestellt sind. 

Methode 

getPatternCategoryList() 

getPatternInfoList() 

getPatternContainer() 

Beschreibung 

Liefert eine Liste aller im System vorhandenen PatternCategory- 

Objekte. 

Liefert eine Liste aller im System vorhandenen PatternInfo- 

Objekte. 

Liefert ein PatternContainer-Objekt, welches Listen der vorhandenen 

PatternCategory- und PatternInfo-Objekte verwaltet. 

Tabelle 8: Zugriffsmethoden von PatternAdmin 

Weiters wurden noch einige Administrationsmethoden integriert, die in Tabelle 9 

ersichtlich sind. 

Methode 

clear() 

getPatternPath() 

Beschreibung 

Löscht die aktuelle interne Datenstruktur. Diese Methode wird benötigt, 

wenn sich in den Beschreibungsdateien oder in der Dokumentation 

der Inhalt geändert hat und dadurch Navigation und Visualisierung 

neu initialisiert werden müssen. 

Liefert den aktuellen Wert für PATTERN_ROOT. Dieser Wert wird 

aus der globalen Konfigurationsdatei "pattern_configuration.xml" 

entnommen, siehe Abschnitt 3.4.3. 

Tabelle 9: Administrationsmethoden von PatternAdmin 

Mit diesen Schnittstellen wird Entwicklern ermöglicht, die interne Datenstruktur in 

ihren Anwendungen weiter zu verwenden. Die Voraussetzung dafür ist jedoch eine 

genaue und sorgfältige Definition der Entwurfsmuster. 

5.1.3 Anwendungsbeispiel 

Zum besseren Verständnis der Schnittstellen werden in diesem Kapitel einige Beispiele 

zu deren Verwendung dargelegt. Da vor allem die variable Gestaltung der Kategoriezuordnung 

viele Möglichkeiten bietet, wird auf diesen Anwendungsbereich ein 

erhöhtes Augenmerk gelegt. Für die folgenden Beispiele wurden die drei Muster 

Abstract Factory, Interceptor und Observer angelegt, deren Kategoriedefinitionen in 

Abbildung 25 - Abbildung 27 dargestellt sind.


Abbildung 25: Kategoriedefinition Abstract Factory 

Abbildung 26: Kategoriedefinition Interceptor 

Abbildung 27: Kategoriedefinition Observer 

Anhand verschiedener Codebeispiele wird im folgenden der Zugriff auf die interne 

Datenstruktur erläutert. Als Ausgabefunktion wird dabei die Methode 

println()verwendet. 

1 PatternContainer container = PatternAdmin.getPatternContainer(); 

2 PatternInfo info = 

3 (PatternInfo)container.getPatternInfoList().get(0); 

4 println(info.getName()); // Ausgabe von "Abstract Factory" 

5 Pattern pat = info.getPattern(); 

6 PatternRole role = (PatternRole) pat.getRoleList().get(1); 

7 println(role.getRoleName()); // Ausgabe von "AbstractProduct" 

8 PatternDescription desc = (PatternDescription) 

9 info.getDescriptionList().get(0); 

10 println(desc.getHeaderName() // Ausgabe von "Gamma" 

Quellcode 2: Abarbeitung über PatternInfo-Liste 

Bei Ausführung von Quellcode 2 ergibt sich eine Objektstruktur, die in Abbildung 28 

dargestellt ist. Zusätzlich wurden die bei den Ausgaben mit println() betroffenen 

Objekte gekennzeichnet.



PatternInfo 

(Abstract Factory) 

PatternInfo 

(Interceptor) 

PatternInfo 

(Observer) 

Pattern 


(Gamma) 


(Intent) 

… 

PatternRole 

(AbstractFactory) 

PatternRole 

(AbstractProduct) 

… 

Abbildung 28: Objektstruktur nach Ausführung von Quellcode 2 

Mit den Codezeilen 2 und 3 holt man sich aus einem PatternContainer-Objekt das 

erste PatternInfo-Objekt (Index 0) aus der Liste. Da die Entwurfsmuster alphabetisch 

sortiert werden, ist dies das Objekt für das Muster Abstract Factory. 

info.getPattern() wird das Pattern-Objekt zurückgegeben, welches eine Liste 

von PatternRole-Objekten verwaltet, die mit der Methode getRoleList() (Zeile 6) 

erhältlich ist. Diese Objekte enthalten die für die Anwendung des Entwurfsmusters 

notwendigen Informationen. Die Abfrage eines PatternDescription-Elementes in 

den Zeilen 8 und 9 erfolgt nach dem gleichen Schema. Im Beispiel wird das erste entnommen 

und dessen Name ("Gamma") ausgegeben. 

Um das PatternInfo-Objekt des zweiten Muster (Index 1) zu erhalten müssen folgende 

Codezeilen ausgeführt werden: 

PatternInfo info = 

(PatternInfo)container.getPatternInfoList().get(1); 

Beim ersten Codebeispiel war der Ausgangspunkt eine Liste aller vorhandenen Entwurfsmuster. 

Eine andere Variante ist, die Abarbeitung über eine Liste der vorhandenen 

Kategorien zu starten. Zum besseren Verständnis des Aufbaus der Kategorien 

werden für dieses Beispiel drei Codeblöcke verwendet, die zusammenhängend betrachtet 

werden müssen. 

Mit


// Hauptkategorie 


2 PatternCategory cat1 = (PatternCategory) 

3 container.getPatternCategoryList().get(1); 

4 println(cat1.getName()); // Ausgabe von "Gamma” 

5 PatternInfo info1 = (PatternInfo) 

6 cat1.getPatternInfoList().get(0); 

7 println(info1.getName()); // Ausgabe von "Abstract Factory” 

8 PatternInfo info2 = (PatternInfo) ' 


10 println(info2.getName()); // Ausgabe von "Observer” 

Quellcode 3: Abarbeitung über PatternCategory-Liste (1/3) 

Quellcode 3 hat nach Ausführung eine Objekstruktur gemäß Abbildung 29 zur Folge. 



(Buschmann) 


(Gamma) 

PatternInfo 


PatternInfo 

(Observer) 


Die Codezeilen 2 und 3 holen sich aus dem PatternContainer-Objekt das zweite 

PatternCategory-Objekt, dessen Name "Gamma" ist (das erste ist aufgrund der alphabetischen 

Reihenfolge "Buschmann"). Das erste PatternInfo-Objekt aus der 

Kategorie "Gamma" ist jenes von Abstract Factory, das zweite jenes des Musters 

Observer. 

// Subkategorie 1 





5 cat1.getCategoryList().get(0); 

6 println(cat2.getName()); // Ausgabe von "Behavioral Patterns” 

7 PatternInfo info = (PatternInfo) 


9 println(info.getName()); // Ausgabe von "Observer" 


Quellcode 4 hat das Ziel, das erste PatternInfo-Objekt der ersten Subkategorie von 

"Gamma" auszugeben. Die Objekstruktur wird in Abbildung 30 ersichtlich.




(Buschmann) 


(Gamma) 


(Behavioral Patterns) 


(Creational Patterns) 

PatternInfo 

(Observer) 


Mit den Codezeilen 4 und 5 erhält man das erste Subkategorie-Objekt ("Behavioral 

Patterns") aus der Kategorie "Gamma". Diese Kategorie hat genau ein PatternInfo- 

Objekt – jenes von Observer. 

// Subkategorie 2 





5 cat1.getCategoryList().get(1); 

6 println(cat2.getName()); // Ausgabe von "Creational Patterns” 

7 PatternInfo info = (PatternInfo) 


9 println(info.getName() // Ausgabe von "Abstract Factory” 


In Quellcode 5 wird die Abarbeitung der Datenstruktur über die zweite Subkategorie 

von "Gamma" dargestellt. Die Objekstruktur nach Ausführung dieses Quellcodes ist 

in Abbildung 31 dargestellt.




(Buschmann) 


(Gamma) 


(Behavioral Patterns) 


(Creational Patterns) 

PatternInfo 



Die zweite Subkategorie von "Gamma" lautet "Creational Patterns" und hat ein 

PatternInfo-Objekt mit dem Namen Abstract Factory. 

Die Hauptkategorie "Gamma" verwaltet also zwei PatternInfo-Objekte und ihre 

Subkategorien "Behavioral Patterns" und "Creational Patterns" jeweils nur eines, was 

genau der Definition der Kategorien laut Abbildung 25 bis Abbildung 27 entspricht. 

5.2 Initialisierung der Datenstruktur 

Abschnitt 5.1 befasste sich mit der Klassenrepräsentation der Entwurfsmuster und den 

Zugriffsmethoden auf diese. Die Initialisierung dieser internen Muster-Infrastruktur 

wird in diesem Abschnitt näher erläutert. 

Die Initialisierung der Datenstruktur erfolgt in der Klasse PatternAdmin mit der Methode 

initialize(), die in Quellcode 6 inklusive der notwendigen globalen 

Variablendeklarationen dargestellt ist. Folgende Methoden aus Tabelle 10, deren 

Implementierung nicht dargestellt ist, werden zusätzlich benötigt. 

Methode 

getDirectories(path) 

getPatternCategoryList 

(directory,info) 

Beschreibung 

Liefert eine Liste aller Verzeichnisse unter path zurück. 

Liefert für ein Muster (identifiziert über directory, da für jedes ein 

Verzeichnis angelegt sein muss) eine Liste passender PatternCategory- 

Objekte zurück. Bspw. liefert diese Methode für Abstract Factory eine 

Liste mit den Kategorien "Gamma" und "Creational Patterns".


hasImplementation 

(directory) 

getClassificationList 

(directory) 

getDescriptionList 

(directory) 

initializeCategories() 

Überprüft, ob für ein Muster eine Implementierungsbeschreibung mit dem 

Wert in "pattern_configuration.xml" (siehe Abschnitt 3.4.3) vorliegt. 

Liefert eine Liste der Klassifizierungen des Musters. 

Liefert eine Liste aller PatternDescription-Objekte, die zu diesem 

Muster gehören. 

Ruft von jedem PatternCategory-Objekt in der Variable 

patternCategoryTable die Methode initialize() auf und bewirkt 

damit eine Neuinitialisierung der Objekte. 

Tabelle 10: Methoden für die Musterinitialisierung 

1 private static Hashtable patternInfoTable = new Hashtable(); 

2 private static Hashtable patternCategoryTable = new Hashtable(); 

3 private static void initialize() throws ConfigFileException, 

IOException, JDOMException { 

4 List directories = getDirectories(getPatternPath()); 

5 Iterator it = directories.iterator(); 

6 boolean changed = false; 

7 while (it.hasNext()) { 

8 String directory = (String) it.next(); 

9 File f = new File(getPatternPath() + directory + 

10 File.separator + PatternAdmin.MANIFEST); 

11 if (f.exists()) { 

12 if (patternInfoTable.get(directory)==null) { 

13 PatternInfo info = new PatternInfo(directory); 

14 info.setCategoryList(getPatternCategoryList 

15 (directory,info)); 

16 if (hasImplementation(directory)) { 

17 info.setPattern(new Pattern(directory, 

18 ConfigFile.getValue(LANGUAGE))); 

19 } 

20 info.setClassificationList( 

21 getClassificationList(directory)); 

22 info.setDescriptionList( 

23 getDescriptionList(directory)); 

24 patternInfoTable.put(directory, info); 

25 changed = true; 

26 } 

27 } 

28 } 

29 if (changed) { 

30 initializeCategories(); 

31 } 

32 } 

33 } 

34 } 

Quellcode 6: Methode initialize() 

Die beiden globalen Variablen patternInfoTable und patternCategoryTable 

(Zeilen 1 und 2) werden verwendet, um alle vorhandenen PatternInfo- sowie 

PatternCategory-Objekte abzuspeichern. Es wurden dafür Objekte vom Typ 

Hashtable verwendet, da diese eine komfortable Verwaltung von Schlüsseln (Zei-


chenketten) und dazugehörigen Wertobjekten zur Verfügung stellen. Weiters haben 

Hashtable-Objekte eine Methode get(), die über Definition eines Schlüssels ein 

passendes Wertobjekt oder null liefern, was bei herkömmlicher Listenverwaltung, z. 

B. mit Objekten vom Typ java.util.List, nicht der Fall ist. 

Die Methode intialize() hat das Ziel alle Verzeichnisse unter dem Wurzelverzeichnis 

der Muster (PATTERN_ROOT) nach einer allgemeinen Beschreibungsdatei 

"manifest.xml" zu durchsuchen, und bei Auffinden die Musterinitialisierung vorzunehmen. 

In Zeile 4 aus Quellcode 6 wird eine Liste dieser Verzeichnisse mit dem Methodenaufruf 

getDirectories(getPatternPath()) zurückgeliefert. Diese werden in 

einer Schleife abgearbeitet, wobei überprüft wird, ob eine Datei "manifest.xml" in 

dem Verzeichnis existiert (Zeile 11). Ist dies der Fall, so wird in Zeile 12 abgefragt, ob 

dieses Muster schon einmal initialisiert wurde und somit schon in der globalen Variable 

patternInfoTable gespeichert ist. Wenn nicht, wird ein neues PatternInfo- 

Objekt angelegt und in den Zeilen 14 und 15 mit einer Liste der passenden 

PatternCategory-Objekte versehen. 

Sofern für das Muster eine Implementierungsbeschreibung existiert wird ein Objekt 

der Klasse Pattern angelegt, welches im Konstruktor 4 die Initalisierung der 

Rollenbeschreibung (PatternRole-Objekte) vornimmt. Weiters werden noch eine 

Liste der Klassifizierungen (Zeilen 20 und 21) und eine Liste der Beschreibungen 

(PatternDescription-Objekte, Zeilen 22 und 23) für die Initialisierung benötigt. 

Danach wird das neu angelegte PatternInfo-Objekt zu der Variable 

patternInfoTable hinzugefügt, damit es nicht ein zweites mal initialisiert wird. Die 

Variable changed indiziert, dass bei einem Wert true ein neues PatternInfo hinzugefügt 

wurde und sich somit alle PatternCategory-Objekte neu initialisieren müssen 

(Zeile 30), damit alle Zuordnungen stimmen. 

Egal welcher Einstiegspunkt in die interne Datenstruktur gewählt wird (PatternInfo- 

Liste oder PatternCategory-Liste), die Methode initialize() wird, sofern die 

Initialisierung noch nicht erfolgte, vorher aufgerufen. 

4 Ein Konstruktor ist eine Methode, die beim Anlegen eines Objektes aufgerufen wird.



In diesem Kapitel wurden die Implementierung von PSE-D vorgestellt. Diese besteht 

zu einem Großteil aus Programmierschnittstellen mit deren Hilfe andere Anwendungen 

auf die verwaltete Muster-Infrastruktur zugreifen können. Die Klasse 

PatternAdmin stellt dabei die Methoden für den Zugriff zur Verfügung. Die Repräsentation 

der Datenstruktur übernehmen die Klassen PatternContainer, 

PatternCategory, PatternInfo, PatternDescription, Pattern und 

PatternRole. Weiters wurde mit einem Anwendungsbeispiel die konkrete Verwendung 

der Schnittstellen vorgestellt. Den Abschluss bildete eine Beschreibung der Initialisierung 

der internen Datenstruktur.

PSE-V - Darstellung von Entwurfsmustern 58 

6 PSE-V - Darstellung von 

Entwurfsmustern 

PSE-V ermöglicht als Erweiterung der Entwicklungsumgebung Eclipse die Navigation 

durch die im System verwalteten Muster und die Visualisierung deren Dokumentation. 

Voraussetzung für die Anwendung ist eine genaue Definition der Entwurfsmuster 

und deren Dokumentation laut PSE-D, da PSE-V auf die zur Verfügung 

gestellten Programmierschnittstellen zugreift, um Daten über die Muster zu erhalten. 

Dieses Kapitel befasst sich mit der Struktur, den Entwurfszielen und der Bedienung 

von PSE-V. 

6.1 Struktur 

PSE-V besteht aus einem Teil zur Musternavigation ("Pattern Navigator") und einem 

Teil zur Darstellung der HTML-Dokumentation ("Pattern Browser"). Diese beiden 

Komponenten wurden als Views implementiert (siehe Abschnitt 3.3). Die Anwendung 

von Views wird in Abschnitt 6.3 näher erläutert. Abbildung 32 illustriert die Struktur 

von PSE-V. 

Pattern Navigator 

(Musternavigation) 

steuert 

Pattern Browser 

(Darstellung Dokumentation) 

Abbildung 32: Struktur von PSE-V 

In "Pattern Navigator" können die im System vorhandenen Entwurfsmuster ausgewählt 

werden. Die Auswahl eines Musters bewirkt die Ansteuerung und Darstellung 

der generierten HTML-Dokumentation in "Pattern Browser". 

6.2 Entwurfsziele 

Bei der Entwicklung von PSE-V wurden folgende Entwurfsziele verfolgt: 

‣ Integration in eine Entwicklungsumgebung: Derzeit existieren bereits einige 

Werkzeuge, die das Verwalten und die Anwendung von Entwurfsmustern 

unterstützen, z. B: Pattern by Example [Delta 2002a]. Die meisten davon 

sind jedoch nicht in eine Entwicklungsumgebung integriert. Der Vorteil


einer Integration liegt in der Konsistenz der Benutzerführung, da ein eingebettetes 

Werkzeug genau dem look and feel der Umgebung angepasst werden 

kann. 

‣ Übersichtliche Darstellung: Die verwalteten Entwurfsmuster und deren 

Dokumentation sollen in einer übersichtlichen Art und Weise dargestellt 

werden. Daher wurde zur Navigation eine Baumstruktur und für die Dokumentation 

das HTML-Format gewählt. 

6.3 Bedienung 

Die Erklärung der Bedienung von PSE-V bezieht sich auf die Version 2.0 der Entwicklungsumgebung 

Eclipse. Da die Komponenten von PSE-V ("Pattern Navigator" 

und "Pattern Browser") als Views implementiert wurden, müssen sie mit einem Menübefehl 

von Eclipse gestartet werden. Abbildung 33 und Abbildung 34 illustrieren das 

Öffnen der benötigten Views. 

Abbildung 33: Auswahl von Views


Abbildung 34: Menüpunkt "Other" bei der Auswahl von Views 

Mit dem Menüpunkt "Window à Show View à Other" können unter der Kategorie 

"Design Patterns" (Abbildung 34) die für PSE-V relevanten Views "Pattern Navigator" 

und "Pattern Browser" ausgewählt werden. Abbildung 33 zeigt die Standardviews von 

Eclipse, welche die allgemeinen Aufgaben der Entwicklungsumgebung übernehmen. 

Mit dem Menüpunkt "Window à Customize Perspective" ist eine Konfiguration dieser 

Ansicht möglich, um weitere Views in die Standardansicht zu übernehmen. 

Nach Auswahl von "Pattern Navigator" präsentiert sich eine beispielhafte Musterdefinition 

laut Abbildung 35. Es wurden zu diesem Zweck 12 Entwurfsmuster aus den 

verschiedensten Kategorien definiert.


Abbildung 35: View "Pattern Navigator" 

Mit dieser Darstellung ist eine komfortable Navigation durch die verwalteten Muster 

möglich. Ändert sich etwas an der Struktur der XML-Beschreibungsdateien oder dem 

Inhalt der Dokumentation, so erneuert ein Klick auf den Button mit den Symbol die 

Struktur der Navigation und die Dokumentation. Die weiteren Symbole sind für das 

Navigieren innerhalb des Baumes hilfreich bzw. das "X" zum Schließen der View. 

Alle diese Möglichkeiten (außer das Schließen) stehen auch in einem Kontextmenü 

bei Klicken der rechten Maustaste zur Verfügung. 

Um eine Musterdokumentation zu betrachten, genügt die Auswahl eines Musters in 

der Navigation. Dadurch wird die generierte Dokumentation in "Pattern Browser" 

sichtbar. Abbildung 36 illustriert die Verwendung bei Auswahl des Musters Adapter.


Abbildung 36: Dokumentation für Adapter dargestellt in "Pattern Browser"


Anwendung von Entwurfsmustern 

Neben dem Betrachten der Dokumentation liegt vor allem die Anwendung der Entwurfsmuster 

im Interesse eines Benutzers. Bei der Anwendung soll konkreter Quellcode 

erzeugt werden, der in den zu entwickelnden Systemen verwendet werden kann. 

Für diesen Zweck wurde ebenfalls für die Entwicklungsumgebung Eclipse das Werkzeug 

PSE-Application entwickelt, das eingehend in [Mayr-Kern 2002] beschrieben 

wird. Dieses Werkzeug verwendet die von PSE-D zur Verfügung gestellten Schnittstellen, 

um auf die interne Datenstruktur zuzugreifen. 


Dieses Kapitel beschäftigte sich mit der Beschreibung des Werkzeuges PSE-V zur 

Visualisierung von Entwurfsmustern und deren Dokumentation. PSE-V verwendet 

dabei die von PSE-D zur Verfügung gestellten Programmierschnittstellen. Es wurde 

dargelegt, welche Entwurfsziele bei der Entwicklung von PSE-V verfolgt wurden und 

aus welchen Komponenten das Werkzeug besteht. Bei der Bedienung von PSE-V 

können über eine Baumnavigation einzelne Muster ausgewählt werden, deren Dokumentation 

daraufhin in einem eigenem Fenster dargestellt wird.

PSE-V-Implementierungsbeschreibung 64 

7 PSE-V-Implementierungsbeschreibung 

PSE-V ist eine Erweiterung der Entwicklungsumgebung Eclipse, die in Java implementiert 

wurde. Somit musste die Entwicklung von PSE-V ebenfalls in Java vorgenommen 

werden. Dieses Kapitel zeigt den Aufbau der Implementierung, legt deren 

Architektur dar und beschreibt die einzelnen Teile. Den Abschluss bilden einige ausgewählte 

Implementierungsdetails. 

7.1 Struktur 

Die Implementierung von PSE-V gliedert sich in vier Pakete und die Klasse 

BasePlugin (siehe Abbildung 37). Alle Teile tragen dabei den Präfix pattern.base 

und werden daher in der weiteren Arbeit auch mit ihrem vollen Namen wie z. B. 

pattern.base.html oder pattern.base.BasePlugin angesprochen. Da 

BasePlugin eine allgemeine Aufgabe erfüllt, wurde auf eine Zuordnung zu einem der 

Detailpakete verzichtet. 

treeview 

+ViewContentProvider 

+TreeObject 

+TreeParent 

+ViewLabelProvider 

+PatternTreeView 

system 

+Debug 

+ConfigFileException 

+ConfigFile 

+Log 

+PatternComparator 

htmlview 

+PatternWebBrowser 

+PatternBrowserView 

+HTMLTag 

+PatternDoku 

html 

AbstractUIPlugin 

BasePlugin 

Abbildung 37: Aufbau Implementierung von PSE-V


pattern.base.BasePlugin 

Jedes Plugin benötigt eine Klasse, die AbstractUIPlugin aus dem Eclipse-Paket 

org.eclipse.ui.plugin erweitert. BasePlugin übernimmt diese Funktion und 

ermöglicht damit die Anwendung von "PatternNavigator" und "PatternBrowser". Sie 

initialisiert die verwendeten Bilder und Schriften und stellt weiters eine Methode für 

den Zugriff auf die Eigenschaften von Plugins zur Verfügung (siehe Abschnitt 7.3.3). 

pattern.base.system 

Diese Paket ist zuständig für allgemeine Aufgaben. Es stellt unter anderem Funktionalitäten 

für den Zugriff auf die globale Konfigurationsdatei 

"pattern_configuration.xml" und für die Protokollierung zur Verfügung. 

pattern.base.html 

Die Klassen in diesem Paket generieren die HTML-Dokumentation und die Musternavigation 

gemäß Definition in den XML-Beschreibungsdateien. 

pattern.base.treeview 

Dieses Paket ist verantwortlich für den Aufbau der View "Pattern Navigator", welche 

die Musternavigation ermöglicht. Es verwendet dafür unter anderem Methoden der 

Klasse pattern.base.html.PatternDoku. 

pattern.base.htmlview 

Die Klassen in diesem Paket werden verwendet, um die View "Pattern Browser" zur 

Darstellung der HTML-Dokumentation zu generieren. 

7.2 Pakete 

Die folgenden Abschnitte erläutern die Aufgaben und die Zusammenarbeit der einzelnen 

Pakete. 

7.2.1 pattern.base.html 

Dieses Paket ist zuständig für die Generierung der Musternavigation und der HTML- 

Dokumentation. Die folgenden Klassen spielen dabei eine Rolle: 

PatternDoku 

Die statische Klasse PatternDoku liefert über eine öffentliche Methode das Wurzelelement 

der Navigation zurück. Beim Aufruf dieser Methode wird das Verzeichnis 

PATTERN_ROOT nach Unterverzeichnissen mit einer Beschreibungsdatei


"manifest.xml" durchsucht. Ist diese Datei vorhanden (ein Muster ist somit identifiziert), 

so werden folgende Aufgaben durchgeführt: 

‣ Aufnahme dieses Musters in die Navigation anhand der Kategoriedefinition(en) 

in "manifest.xml". 

‣ Generieren der HTML-Gesamtdokumentation des Entwurfsmusters aus den 

einzelnen Dokumentationsteilen. Diese trägt den Namen des Musters (z. B: 

"Abstract Factory.html"). 

HTMLTag 

Diese Klasse enthält einige Konstanten für HTML-Code zum Aufbau der Dokumentation. 

7.2.2 pattern.base.system 

Das Paket pattern.base.system wird für allgemeine Systemaufgaben verwendet 

und besteht aus den folgenden Klassen: 

ConfigFile 

ConfigFile ist eine statische Klasse, die Lesezugriff auf Werte in der globalen Konfigurationsdatei 

"pattern_configuration.xml" erlaubt. 

ConfigFileException 

Diese Klasse wird für die Ausnahmebehandlung verwendet, falls mit ConfigFile ein 

falscher Schlüsselwert abgefragt wurde. 

Debug 

Wird für Testausgaben bei der Entwicklung verwendet. 

Log 

Protokolliert in eine mit der Konfigurationsdatei "pattern_configuration.xml" definierte 

Datei (Schlüssel "patternLog"). 

PatternComparator 

Wird für die Sortierung der Entwurfsmuster benötigt. 

7.2.3 pattern.base.treeview 

Das Paket pattern.base.treeview wird für die Darstellung der Musternavigation 

verwendet. Diese wird durch ein Objekt der Klasse TreeView aus dem Eclipse-Paket 

org.eclipse.jface.viewers repräsentiert, das folgende Klassen benötigt:


TreeObject 

Ein Objekt dieser Klasse repräsentiert ein Muster im Navigationsbaum. Es enthält 

einen Pfad für eine HTML-Datei mit dem die Dokumentation angesteuert werden 

kann. Bei Auswahl eines Musters wird dieser Wert zurückgeliefert und in der View 

"Pattern Browser" die passende Dokumentation angesteuert und dargestellt. 

TreeParent 

Objekte dieses Typs sind Erweiterungen der Klasse TreeObject und repräsentieren 

eine Kategorie im Navigationsbaum. Ein TreeParent-Objekt kann mehrere 

TreeObject-Objekte verwalten und damit beliebige hierachische Strukturen aufbauen. 

Auch das Wurzelobjekt der Navigation ist vom Typ TreeParent. 

ViewContentProvider 

Ein Objekt der Klasse ViewContentProvider ist zuständig für den Inhalt der 

TreeView. Es liefert mit Hilfe der Klasse pattern.base.html.PatternDoku das 

Wurzelobjekt der Navigation. 

ViewLabelProvider 

Mit der Klasse ViewLabelProvider wird das Aussehen des TreeView-Objektes 

festgelegt. Es bestimmt die Darstellung der Bildsymbole und des Textes der Navigationselemente. 

PatternTreeView 

Die Klasse PatternTreeView ist eine Erweiterung von ViewPart aus dem Paket 

org.eclipse.ui.part und stellt die Hauptkomponente der View "Pattern Navigator" 

dar. Beim Starten von "Pattern Navigator" über das Eclipse-Menü wird ein Objekt 

dieser Klasse angelegt, das die Navigation und sämtliche Menüs initialisiert. 

7.2.4 pattern.base.htmlview 

Die Klassen aus dem Paket pattern.base.htmlview sind zuständig für den Aufbau 

der View "Pattern Browser" zur Visualisierung der Musterdokumentation. Sie sind 

Erweiterungen von Beispielimplementierungen aus dem Eclipse-Paket 

org.eclipse.swt.examples.ole.win32, die mit Hilfe von Windows-Komponenten 

einen HTML-Browser aufbauen.


PatternWebBrowser 

Ein Objekt der Klasse PatternWebBrowser kapselt die Funktionalitäten eines HTML- 

Browsers 5 , der in der Klasse PatternBrowserView verwendet wird. Es stellt dabei die 

verschiedensten Methoden zur Verfügung, um die gewohnten Funktionalitäten von 

herkömmlichen HTML-Browsern nachzubilden, z. B. Vorwärtsnavigation, Rückwärtsnavigation 

und Aktualisierung. 

PatternBrowserView 

Diese Klasse ist als Erweiterung von org.eclipse.ui.part.ViewPart die Hauptkomponente 

von "Pattern Browser". Sie enthält eine Instanz von 

PatternWebBrowser. Diese liefert zwar die Methoden, die man von HTML-Browsern 

gewohnt ist, jedoch nicht die grafischen Elemente (Buttons, Textfeld für URL- 

Eingabe usw.). Daher ist auch die Initialisierung der Benutzerschnittstelle eine Aufgabe 

von PatternBrowserView. 

7.3 Ausgewählte Details 

Dieser Abschnitt befasst sich mit einigen ausgewählten Implementierungsdetails von 

PSE-V. Da bei der Entwicklung vor allem der Zugriff auf XML eine große Rolle 

spielte, werden mit einem Exkurs über XML-Programmierschnittstellen (API's – application 

programming interfaces) die Zugriffsmöglichkeiten kurz erläutert. 

7.3.1 Exkurs: XML-API's 

Mit der Entwicklung von XML wurden auch nach und nach einige Werkzeuge entwickelt. 

Für diese Werkzeuge mussten Möglichkeiten geschaffen werden, um XML-Dokumente 

zu lesen bzw. zu schreiben. Um eine einheitliche Schnittstelle für den Zugriff 

auf XML-Dokumente zu gewährleisten, wurden einige API's entwickelt, von denen 

die bekanntesten kurz vorgestellt werden. Genauere Details können in [Kappel 2001c] 

nachgelesen werden. 

Das Konzept einer XML-API wird in Abbildung 38 ersichtlich. 

5 

Ein HTML-Browser ist ein Werkzeug zur Darstellung von Dateien, die im HTML-Format 

abgespeichert wurden.


Anwender 

benutzt 

Anwendung 

API 

interagiert 

mit 

Parser 

liest 

XML-Dokument 

DTD/XML-Schema 

Abbildung 38: Konzept einer XML-API [Kappel 2001c, 4] 

Die Anwendung kommuniziert mit dem Parser mittels vordefinierter Schnittstelle 

(API), wobei der Parser genau diese API implementieren muss. Der Parser liest vom 

XML-Dokument die Daten ein, prüft diese (falls vorhanden) anhand einer DTD oder 

einem XML-Schema und sendet sie an die Anwendung, die sie ihrerseits verarbeitet. 

Durch dieses Konzept ist es möglich Komponenten in einem Softwaresystem ohne 

größeren Aufwand auszutauschen. 

Die bekanntesten derzeit existierenden XML-APIs sind DOM, SAX und JAXP die im 

folgenden kurz erläutert werden. 

DOM 

DOM (Document Object Model) wurde vom W3C [W3C 2002d] entwickelt und definiert 

die logische Struktur eines XML-Dokumentes in Form eines Baumes. Es ermöglicht 

das Lesen, Verändern und Erstellen dieser Dokumente und legt keine spezielle 

Programmiersprache für die Verwendung fest. Folgende Vor- bzw. Nachteile ergeben 

sich bei Verwendung von DOM: 

+ W3C Standard, der von vielen Parsern implementiert ist. 

+ Einfache Bearbeitung von XML-Dokumenten. 

+ Bietet auch die Möglichkeit, XML-Dokumente zu manipulieren. 

− 

Hoher Speicherbedarf bei großen XML-Dokumenten.


− 

− 

Hohe Geschwindigkeitsverluste bei großen XML-Dokumenten. 

Nicht für Streaming 6 geeignet, da das Parsen erst möglich ist, wenn das Dokument 

vollständig geladen wurde. 

SAX 

SAX (Simple API for XML) wurde von Megginson Technologies [Megginson 2002] 

entwickelt und ermöglicht nur das Lesen von XML-Dokumenten. Es erstellt keine 

interne Repräsentation des Dokumentes, sondern arbeitet auf der Basis von Ereignissen, 

wobei jeder Knoten in einem XML-Dokument ein Ereignis auslöst, welches von 

der Anwendung abgefangen und verarbeitet wird. Die Schnittstellen wurden für Java 

spezifiziert, sind jedoch auch schon in mehreren anderen Programmiersprachen umgesetzt. 

Folgende Vor- bzw. Nachteile ergeben sich bei der Anwendung von SAX: 

+ Sehr gut für Streaming-Anwendungen geeignet, da SAX das XML-Dokument 

verarbeitet, bevor es vollständig übertragen wird. 

+ Daher auch bei großen XML-Dokumenten schnell und speicherplatzsparend. 

− 

Bietet keine Möglichkeit XML-Dokumente zu bearbeiten. 

JAXP 

JAXP (Java API for XML Processing) wurde von Sun [Sun 2002a] entwickelt und 

stellt eine Abstraktionsebene für SAX- und DOM-Parser dar. Der Entwickler spricht 

die Parser über die JAXP-Schnittstellen an, wobei dieser entweder DOM oder SAX 

verwendet. Somit ist es möglich, die Parser ohne Aufwand auszuwechseln. Die Verwendung 

von JAXP bringt folgende Vor- bzw. Nachteile mit sich: 

+ Entwickeln von Applikationen unabhängig von den verwendeten Parsern. 

+ Parserwechsel ohne Codeänderung der Anwendung. 

− 

− 

Nur in Java umgesetzt. 

Noch junge Technologie. 

6 Internettechnologie, die erlaubt Audio- oder Video-Dateien bereits während dem Herunterladen 

anzuhören bzw. anzusehen. Man spricht daher auch von Echtzeitübertragungen, da Daten ohne größere 

Zeitverschiebung wiedergegeben werden [Glossar 2002].


Grundsätzlich sollte die Wahl der geeigneten API nach Abwägung der Vor- und 

Nachteile erfolgen, wobei der Grundsatz gilt, bei zeitkritischen Anwendungen SAX 

und bei Anwendungen zur XML-Manipulation DOM zu verwenden. 

Einsatz bei PSE-V 

Für den Zugriff auf die XML-Dokumente wurde JDOM [JDOM 2002], eine Java- 

Implementierung von DOM verwendet. DOM eignet sich wegen der internen Baumstruktur 

besonders gut für PSE-V. Zumal die von PSE-D verwalteten XML-Beschreibungen 

nicht speicherintensiv sind, machen sich auch die Nachteile von DOM nicht 

bemerkbar. 

7.3.2 Zugriff auf globale Konfigurationsdatei 

Ein Zugriff auf XML-Dokumente ist mit JDOM im Schreib- und im Lesemodus möglich, 

wobei bei PSE-V nur lesend zugegriffen wird. Die folgenden Codebeispiele zeigen 

die Verwendung von JDOM beim Zugriff auf die globale Konfigurationsdatei 

"pattern_configuration.xml" und haben das Ziel den Wert für das Element value mit 

den Schlüssel "patternRoot" zu ermitteln. Dieser Wert ist laut Abbildung 9 

"e:\eclipse\patternFiles\". 

1 private static final String CONFIG_FILE = 

2 "pattern_configuration.xml" 

3 private static final String KEY = "key"; 

4 private static final String VALUE = "value"; 

5 private Hashtable allValues(); 

Quellcode 7: Globale Deklarationen 

1 private static void fillHashtable() throws JDOMException { 

2 allValues = new Hashtable(); 

3 DOMBuilder builder = new DOMBuilder(); 

4 Document doc = builder.build(new File(CONFIG_FILE)); 

5 Element root = doc.getRootElement(); // Wurzelelement 

6 List elementList = root.getChildren(); 

7 for (int i=0; i


Quellcode 7 zeigt die globalen Deklaraktionen, die für den Zugriff nötig sind. In 

Quellcode 8 wird in der Methode fillHashtable()zuerst eine globale Variable 

allValues angelegt, in der alle Schlüssel mit ihren Werten verwaltet werden sollen. 

Dann wird ein Objekt der Klasse DOMBuilder angelegt, um die Konfigurationsdatei 

mit der Methode build() (Zeile 4) in ein Objekt vom Typ Document einzulesen. Das 

gesamte XML-Dokument wird nach Aufruf dieser Methode in der Variable doc repräsentiert. 

Mit root = doc.getRootElement() erhält man das Wurzelelement 

configFile aus Abbildung 9. Die Methode getChildren() gibt eine Liste vom Typ 

List aus dem Paket com.sun.java.collections zurück, in der alle Subelemente (in 

diesem Fall configKey-Elemente) aufgelistet sind. Mit dem Durchlaufen der Liste 

(Zeilen 7-14) wird die Variable allValues initialisert, wobei die Methoden 

getChild() und getText() verwendet werden, um ein Element bzw. dessen Inhalt 

zu erhalten. 

Verwendet wird fillHashtable() von der Methode getValue(), deren Implementierung 

in Quellcode 9 dargestellt ist. 

1 public static String getValue(String key) { 

2 if (allValues == null) { 

3 try { 

4 fillHashtable(); // Initialisierung 

5 }catch (JDOMException e) { 

6 // Keine Initialisierung möglich 

7 allValues = null; 

8 throw new ConfigFileException(e.toString()); 

9 } 

10 } 

11 Object o = allValues.get(key); 

12 if (o!=null) { 

13 return (String) o; 

14 } else { 

15 throw new ConfigFileException(" the element with the 

16 name " + key + " could not be found!"); 

17 } 

18 } 

Quellcode 9: Methode getValue() 

getValue() versucht in Zeile 4 die Variable allValues mit der Methode 

fillHashtable() zu initialisieren. Falls dies aufgrund eines Fehlers im XML-Dokument 

nicht gelingt, so wird eine Instanz von ConfigFileException mit der Beschreibung 

des Fehlers geworfen. Bei einer erfolgreichen Initialisierung wird versucht, das 

Objekt für den Schlüsselwert in der Variable key aus der Hashtable allValues zu 

entnehmen (Zeile 11). Ist dieser nicht in der Konfigurationsdatei enthalten, so wird 

wiederum mit einer Instanz der Klasse ConfigFileException eine entsprechende


Fehlermeldung in der Ausnahmenbehandlung zurückgeliefert. Ansonsten wird das 

Objekt in eine Zeichenkette umgewandelt und zurückgegeben. 

Diese beiden Methoden sind in der statischen Klasse ConfigFile implementiert. Ein 

Aufruf, um den Wert für den Schlüssel "patternRoot" zu erhalten lautet somit 

ConfigFile.getValue("patternRoot"). JDOM ermöglicht weiters den Zugriff auf 

Attribute von Elementen, das Erzeugen neuer Elemente usw. Die vollständige Dokumentation 

der Einsatzmöglichkeiten von JDOM kann auf [JDOM 2002] nachgelesen 

werden. 

7.3.3 Zugriff auf Plugin-Eigeschaften 

Eine ASCII-Datei "plugin.properties", die auf derselben Ebene wie "plugin.xml" liegen 

muss, ermöglicht eine dynamische Konfiguration von Plugins ohne Änderung des 

Quellcodes. Der Aufbau der Datei hat in der Art "Schlüssel = Wert" zu erfolgen. Das 

"plugin.properties" von PSE-V hat bspw. unter anderem folgende Einträge: 

browser.Back.text = Backward 

browser.Back.tooltip = Surf to previously Viewed Web site 

browser.Forward.text = Forward 

browser.Forward.tooltip = Surf to next Viewed Web site 

Den Zugriff auf die Werte ermöglichen zwei Methoden der Klasse 

pattern.base.BasePlugin, deren Implementierung in Quellcode 10 dargestellt ist. 

1 private BasePlugin plugin; 

2 private ResourceBundle resourceBundle; 

3 public BasePlugin(IPluginDescriptor descriptor) { 

4 super(descriptor); 

5 plugin = this; 

6 // Initialisierung 

7 resourceBundle = descriptor.getResourceBundle(); 

8 } 

9 public static String getResourceString(String key) { 

10 try { 

11 return resourceBundle.getString(key); 

12 } catch (MissingResourceException e) { 

13 return key; 

14 } catch (NullPointerException e) { 

15 return "!_" + key + "_!"; 

16 } 

17 } 

Quellcode 10: Zugriff auf plugin.properties 

Der Konstruktur von BasePlugin initialisiert die Variable resourceBundle mit der 

ein Zugriff auf "plugin.properties" ermöglicht wird (Zeile 4). Diese hat eine Methode


getString(), die den angeforderten Wert für einen definierten Schlüssel zurückliefert. 

Ein Aufruf mit dem Wert "browser.Back.text" liefert daher "Backward". Ein Aufruf 

von "browser.Back.tex" liefert "!_browser.Back.tex_!", da kein Wert für diesen 

Schlüssel gefunden werden kann (Ausnahmebehandlung der Zeilen 14 -17). Ist bei der 

Initialisierung der Variable resourceBundle ein Fehler passiert (z. B: keine Datei 

"plugin.properties" vorhanden), so wird in der Ausnahmebehandlung der Zeilen 12 

und 13 der angeforderte Schlüssel zurückgeliefert. 

Alle grafischen Benutzerschnittstellen von "Pattern Browser" erhalten ihre Bezeichnung 

durch die Werte in "plugin.properties". Somit ist es bspw. möglich, ohne Änderung 

von Quellcode die Sprache von Englisch auf Deutsch umzustellen. 


Dieses Kapitel befasste sich mit der Implementierung des Werkzeuges PSE-V, dessen 

Architektur sich aus vier Java-Paketen und der Klasse BasePlugin zusammensetzt. 

Jedes dieser Pakete ist für bestimmte Aufgaben zuständig, die durch die Beschreibung 

der darin enthaltenen Klassen erläutert wurde. Bei den Implementierungsdetails wurde 

der Zugriff auf XML und die Eigenschaften von Plugins anhand konkreten Codebeispielen 

aufgezeigt.

Vergleichbare Werkzeuge 75 

8 Vergleichbare Werkzeuge 

In diesem Kapitel werden zwei mit PSE-Base vergleichbare Werkzeuge vorgestellt: 

PBE (Pattern By Example) und FRED (FRamework Editor for Java). Da sich diese 

Arbeit mit der Definition, Verwaltung und Visualisierung von Entwurfsmustern beschäftigt, 

werden auch nur die für diese Punkte relevanten Teilbereiche der Werkzeuge 

mit Hilfe des Beispielmusters Abstract Factory aus Abschnitt 4.1 erläutert. Teilweise 

sind für das Verständnis der Definition jedoch auch Querverbindungen zur Anwendung 

der definierten Muster notwendig. 

Die Auswahl von PBE und FRED begründet sich anhand folgender Punkte: 

‣ Verfügbarkeit: Jedes dieser Werkzeuge war zumindest als Demoversion 

verfügbar, womit die Funktionalitäten direkt erprobt werden konnten. 

‣ Ausreichende Dokumentation: Für jedes Werkzeug war eine umfassende 

Dokumentation vorhanden. 

‣ Verschiedene Ansätze: FRED orientiert sich genauso wie PSE-D an den 

Rollen von Entwurfsmustern. PBE ignoriert Rollen und definiert die Muster 

indem es einem bestehendem Quellcode gewisse Eigenschaften zuweist. 

Durch den Vergleich der Werkzeuge werden die Vor- und Nachteile dieser 

verschiedenen Ansätze ersichtlich. 

[Paulisch 1996, 99] erläutert kurz einige weitere Werkzeuge zur Unterstützung der 

Softwareentwicklung mit Entwurfsmuster, von denen jedoch keines für den Vergleich 

herangezogen wurde, da bei keinem eine ausreichende Dokumentation und eine voll 

funktionsfähige Demoversion vorhanden war. 

8.1 PBE 

PBE wurde von der Delta Software Technologie Group [Delta 2002a] zur Unterstützung 

der Programmierung mit Entwurfsmustern entwickelt. Das Ziel von PBE ist die 

flexible Definition und Verwaltung von Entwurfsmustern die durch Parametrisierung 

angewandt werden können, um somit den gewünschten Quellcode zu erzeugen. Die 

folgenden Abschnitte konzentrieren sich auf die Beschreibung der Definition und 

Verwaltung der Entwurfsmuster und deren Dokumentation anhand PBE, wobei als


Basis das Benutzerhandbuch [Delta 2002b] und eigene Erkenntnisse durch Evaluierung 

des Werkzeuges dienen. 

8.1.1 Aufbau der Musterdefinition 

Bei der Definition von Entwurfsmustern werden auf Basis eines Codefragments einzelne 

Codeteile als variabel definiert, die dann bei der Anwendung die ihnen zugewiesenen 

Werte erhalten. PBE orientiert sich somit nicht an den Rollen von Mustern, 

sondern definiert deren Eigenschaften direkt im Quellcode. Diese so festgelegten 

Muster können in verschiedenen Programmiersprachen abgelegt werden. Abbildung 

39 zeigt die grundsätzliche Vorgehensweise bei der Definition. 

Parameter 

Ausdrücke 

variable Codeteile 

Initiales 

Codefragment 

Ein Codefragment stellt den Ausgangspunkt für die Definition eines Musters dar. Der 

Code kann mit Hilfe des Werkzeuges aus einer Quellcode-Datei (z. B. ".java", ".cpp") 

importiert, aber auch manuell geschrieben werden. Quellcode 11 zeigt ein vereinfach- 

Codemuster- 

Datei 

Einfügemarken 

Codeblöcke 

Bedingungen 

Abbildung 39: PBE-Definition von Entwurfsmustern [Delta 2002b, 6] 

Ausgangspunkt einer jeden Musterdefinition ist ein initiales Codefragment, das mit 

verschiedenen Komponenten (Parameter, variable Codeteile, Einfügemarken usw.) 

konfiguriert wird, um schließlich die fertige Codemuster-Datei abzubilden. In den 

nachfolgenden Abschnitten wird jeder Teil der Musterdefinition genauer erläutert. 

8.1.2 Initiales Codefragment


tes initiales Codefragment wie es zur Definition des Musters Abstract Factory verwendet 

werden kann. 

1 public interface AbstractFactory { 

2 public AbstractProduct createAbstractProduct(); 

3 } 

4 public class ConcreteFactory implements AbstractFactory { 

5 public AbstractProduct createAbstractProduct(){ 

6 return new Product(); 

7 } 

8 } 

9 public class AbstractProduct {} 

10 public class Product implements AbstractProduct {} 

11 public class Client {} 

Quellcode 11: Initiales Codefragment für Abstract Factory 

Die Deklarationen in Quellcode 11 bilden die Struktur des Musters Abstract Factory 

aus Abbildung 10 nach. Ein Vergleich mit Abbildung 21 und Abbildung 22 zeigt, dass 

auch PSE-D in den einzelnen Rollen, abgesehen von den Identifizierungszeichen "$", 

diesen Code verwendet. Bei PSE-D ist er jedoch in den Codekopf und Codekörper der 

Rolle aufgeteilt. 

8.1.3 Variable Codeteile 

Bei der Definition des Musters müssen im Codefragment alle variablen Teile gekennzeichnet 

werden, die bei der Anwendung neue Werte erhalten sollen. In Quellcode 11 

werden folgende Codeteile als variabel definiert: 

‣ AbstractFactory (Zeilen 1 und 4) 

‣ ConcreteFactory (Zeile 4) 

‣ AbstractProduct (Zeilen 5, 9 und 10) 

‣ Product (Zeile 10) 

‣ Client (Zeile 11) 

Wichtig ist, dass jedes Auftreten der Codeteile als variabel definiert wird. Quellcode 

12 zeigt das Ergebnis der Definition.


1 public interface AbstractFactory { 

2 public AbstractProduct createAbstractProduct(); 

3 } 

4 public class ConcreteFactory implements AbstractFactory { 

5 public AbstractProduct createAbstractProduct(){ 

6 return new Product(); 

7 } 

8 } 

9 public class AbstractProduct {} 

10 public class Product implements AbstractProduct {} 


Quellcode 12: Definition variabler Codeteile für Abstract Factory 

Nur durch ein konsequentes Definieren der variablen Codeteile kann sichergestellt 

werden, dass bei der Anwendung jeder variable Codeteil durch die neu vergebenen 

Werte ersetzt wird. 

8.1.4 Parameter 

Für die Zuweisung eines Wertes bei der Anwendung wird je variablem Codeteil ein 

Parameter benötigt. Dieser kann mit einem Standardwert belegt werden, der bei der 

Anwendung des Musters automatisch vergeben wird, aber auch überschrieben werden 

kann. Tabelle 11 illustiert die Vergabe von Parameternamen und Werten für die Codeteile, 

die bei der Anwendung des Musters zum Ergebniscode laut Quellcode 13 führen. 

Variabler Codeteil Parameter Parameterwert bei Anwendung 

AbstractFactory aFactory "WidgetFactory" 

ConcreteFactory cFactory "MacFactory" 

AbstractProduct aProduct "Window" 

Product cProduct "MacWindow" 

Client client "Client" 

Tabelle 11: Parameterwerte für Abstract Factory




3 } 

4 public class MacFactory implements WidgetFactory{ 

5 public Window createWindow(){ 

6 return new MacWindow(); 

7 } 

8 } 

9 public class Window {} 

10 public class MacWindow implements Window{} 


Quellcode 13: Ergebniscode nach Anwendung des Entwurfsmusters 

Alle variablen Codeteile werden durch die Werte in den Parametern bei der Anwendung 

ersetzt. Dieser Quellcode kann nun kopiert und zur Entwicklung weiterverwendet 

werden. 

8.1.5 Ausdrücke 

Eine Besonderheit bei der Definition der Muster stellen Ausdrücke dar. Mit ihnen ist 

es möglich, komplexere Bedingungen bei der Musterdefinition zu formulieren. Für 

diesen Zweck können eine Reihe gängiger Operatoren und Methoden bei der Erstellung 

verwendet werden, die im folgenden mit einigen Beispielen illustriert werden. 

Verwendung eines Präfixes mit dem Operator "&" 

Die Definition des Ausdrucks "Simple" & aFactory beim variablen Codeteil 

AbstractFactory generiert bei der Anwendung des Musters mit dem Wert 

"WidgetFactory" für den Parameter aFactory ein Ergebnis laut Quellcode 14. 

1 public interface SimpleWidgetFactory { 


3 } 

Quellcode 14: Ergebniscode bei Verwendung eines Verknüpfungsoperators 

Das Ergebnis ist somit eine Verknüpfung von "Simple" und des Wertes, den der Parameter 

aFactory enthält. Der Verknüpfungsoperator kann z. B. eingesetzt werden, 

wenn ein Teil eines variablen Codeteils bekannt ist (wird fix beim Ausdruck hinterlegt), 

der Rest jedoch erst bei der Anwendung eingesetzt wird.


Entfernen von Leerzeichen 

Eine Definition eines Ausdrucks Trim(aFactory) bei AbstractFactory generiert 

bei der Anwendung mit dem Wert " Widget Factory " für den Parameter aFactory ein 

Ergebnis laut Quellcode 15. 



3 } 

Quellcode 15: Ergebniscode bei Entfernen der Leerzeichen 

Die Funktion Trim(str) schneidet aus der Zeichenkette str sämtliche Leerzeichen 

heraus. In diesem Fall wird der Wert " Widget Factory " in "WidgetFactory" umgewandelt. 

Diese Funktion kann bspw. zur vorbeugenden Fehlervermeidung verwendet 

werden, da unbeabsichtigte Leerzeichen bei der Anwendung des Musters kein 

Problem mehr darstellen. 

Die Operatoren und einige Beispielmethoden von PBE sind in Tabelle 12 und 

Tabelle 13 aufgelistet. 

Operator 

Beschreibung 

? : Ternärer If-Operator 

OR, AND, NOT 

Logische Operatoren 

=, , , = Relationale Operatoren 

+, -, &, *, &, /, MOD Arithmetische Operatoren 

Tabelle 12: Operatoren von PBE [Delta 2002b, 13] 

Methode 

LCase(str) 

Len(str) 

Trim(str) 

Beschreibung 

Wandelt das Argument str in Kleinbuchstaben 

um. 

Liefert die Länge des Argumentes str. 

Liefert das Argument str ohne Leerzeichen 

zurück. 

Tabelle 13: Beispielmethoden von PBE [Delta 2002b, 14] 

Eine genaue Auflistung aller zur Verfügung stehenden Methoden kann in [Delta 

2002b] nachgelesen werden.


8.1.6 Codeblöcke und Bedingungen 

Codeblöcke bieten die Gelegenheit, größere Codeteile an gewisse Bedingungen zu 

knüpfen. Im Quellcode 11 kann man den Teil public class Client(){} (Zeile 11) 

als Codeblock definieren und von einem Parameter createClient abhängig machen. 

Dieser Parameter dient damit als Bedingung und regelt, dass bspw. bei einem Wert 

"ja" des Parameters der Codeblock bei der Anwendung des Musters eingeblendet, 

ansonsten ausgeblendet wird. Bei den Codeblöcken wird zwischen optionalen und 

wiederholbaren unterschieden. Optionale Codeblöcke regeln über Parametersteuerung 

das Ein- bzw. Ausblenden von Code. Bei wiederholbaren kann zusätzlich noch bei der 

Anwendung definiert werden, wie oft der Codeblock im Ergebniscode erscheinen soll. 

Beim Muster Abstract Factory kann ein wiederholbarer Codeblock verwendet werden, 

um in einem Schritt für den variablen Codeteil AbstractProduct (siehe Quellcode 

11, Zeile 9) mehrere Ausprägungen bei der Anwendung zu erhalten. Daher wurde der 

Teil public class AbstractProduct{} als wiederholbarer Codeblock definiert. 

Das Besondere bei den wiederholbaren Codeblöcken ist, dass bei der Anwendung für 

jeden Parameter innerhalb des Codeblocks mehrere Instanzen definiert werden können. 

Bei Anwendung des Musters mit den beiden Instanzen "Window" und 

"ScrollBar" für den Parameter aProduct (gebunden an den variablen Codeteil 

AbstractProduct) ergibt sich folgender Ergebniscode: 

public class Window{} 

public class ScrollBar{} 

Quellcode 16: Ergebniscode bei wiederholbarem Codeblock 

Für jeden variablen Codeteil wird bei der Anwendung der jeweilige Instanzwert eingetragen 

und damit in diesem Fall zwei Codesequenzen erzeugt. Durch geschicktes 

Definieren der Codeblöcke können somit mit einer relativ schlanken Musterdefinition 

variable Quellcodeausprägungen realisiert werden. 

8.1.7 Einfügemarken 

Durch das Setzen von Einfügemarken werden Stellen im Code definiert, an denen der 

Benutzer eigene Methoden implementieren soll. Diese Stellen sind jedoch nur eine 

Richtlinie, zumal es ohne weiteres möglich ist, den gesamten Quellcode unabhängig 

der Beachtung der Einfügemarken zu bearbeiten.


8.1.8 Verwaltung und Dokumentation 

Das mit den verschiedenen Elementen festgelegte Entwurfsmuster kann als Codemuster-Datei 

mit der Endung ".pdef" abgespeichert und jederzeit aufgerufen und verändert 

werden. Als Dokumentation können je Muster kurze Beschreibungen im 

ASCII-Format gemäß der Struktur aus [Gamma 1995, 6-7] integriert werden. 

8.2 FRED 

FRED (FRamework Editor for Java) wurde in der ersten Version 1997 an der Universität 

Tampere zur Generierung und Nutzung von Java-Frameworks entworfen [Hakala 

1997] und ist derzeit in der Version 1.3 erhältlich [Tampere 2002]. Die Entwickler 

erkannten, dass die Anwendung von Entwurfsmustern den Aufbau von Frameworks 

flexibler gestalten lässt und integrierten daher das Werkzeug Pattern Editor zur Definition 

und Verwendung von Mustern. Mit diesen sogenannten FRED-Mustern können 

dann Frameworks modelliert werden. FRED bietet weiters die Unterstützung, von 

Frameworks Anwendungen abzuleiten, wobei durch die FRED-Muster schon Beispielcode, 

Einschränkungen, Schablonen usw. für die Anwendung definiert werden 

können. Die folgenden Abschnitte konzentrieren sich auf die Beschreibung der Definition 

und Verwaltung der FRED-Muster, wobei als Basis die Arbeit von [Viljamaa 

2002] und eigene Erkenntnisse durch Evaluierung des Werkzeuges dienen. 

8.2.1 Rollen 

FRED-Muster bestehen aus verschiedenen Rollen. Eine Rolle spezifiziert, wie bei der 

Anwendung des Musters Quellcode generiert wird. Eine angewandte Rolle wird im 

folgenden als "Instanz" bezeichnet. Die wichtigsten Rollenarten von FRED-Mustern 

sind in Tabelle 14 ersichtlich. 

Typ 

ClassClause 

MethodClause 

ExceptionClause 

FieldClause 

Code snippet 

Beschreibung 

Klassen und Schnittstellen 

Methoden 

Exceptions, die von einer Methode oder einem Konstruktor geworfen 

werden 

Felder (Variablen) 

Codekörper 

Tabelle 14: Beispiele f. Rollentypen von FRED-Mustern [Viljaama 2001, 53]


Jede Rolle hat eine Kardinalität, die bestimmt, wie oft sie bei der Anwendung instanziert 

werden kann. Tabelle 15 zeigt die für FRED-Muster zulässigen Kardinalitäten. 

Kardinalität 

Beschreibung 

0..1 0 oder 1 

1 Exakt 1 

0..* 0 oder mehr 

1..* 1 oder mehr 

Tabelle 15: Kardinalitäten von FRED-Mustern [Viljaama 2002, 54] 

Die Kardinalitäten sind von zwei Faktoren abhängig, die mit der Beispieldefinition 

eines Musters in Quellcode 17 ersichtlich werden. Die genaue Notation wird in später 

in einem Beispiel noch näher erläutert. 

1 class role AbstractFactory 1{ 

2 method role createAbstractProduct {} 

3 } 

4 class role ConcreteFactory 1..* [x: AbstractFactory] { 

5 inheritance x 

6 taskTitle: "Subclass "; 

7 } 

Subrolle 

Quellcode 17: Beispieldefinition für FRED-Muster [Viljaama 2001, 54] 

Ist eine Rolle Teil einer anderen (Subrolle), so ist ihre Kardinalität relativ zu der übergeordneten 

zu sehen. Bei einer Anwendung des Musters tritt z. B. die Methodenrolle 

createAbstractProduct (Zeile 2) mit der Kardinalität 1 (keine Angabe bedeutet die 

Kardinalität "1") genauso oft wie die Klassenrolle AbstractFactory auf. Hat die 

Methodenrolle jedoch eine Kardinalität von "1..*", so können je Instanz von 

AbstractFactory ein oder mehrere Instanzen von createAbstractProduct existieren. 

Abhängigkeiten 

Die Kardinalität von abhängigen Rollen verhält sich ähnlich wie bei den Subrollen. 

Laut Quellcode 17 hängt die Klassenrolle ConcreteFactory (Kardinalität "1..*") von 

der Klassenrolle AbstractFactory mit einer Abhängigkeit "x" ab (Zeile 4). Bei einer 

Anwendung des Musters können somit je Instanz von AbstractFactory eine oder 

mehrere Instanzen von ConcreteFactory angelegt werden.


8.2.2 Einschränkungen 

Neben Abhängigkeiten kann man für Rollen auch Einschränkungen (Constraints) definieren. 

Sie werden für die Sicherstellung der Codegültigkeit bei der Anwendung 

eines Musters verwendet. Tabelle 16 zeigt vordefinierte Einschränkungen, die für eine 

Definition von FRED-Mustern verwendet werden können. 

Constraint Beschreibung Anzuwenden für Rollentyp 

inheritance Erzwungene Vererbung Klassenrollen 

overriding 

returnType 

Erzwungenes Überschreiben 

von Methoden 

Erzwungener Rückgabetyp bei 

Methoden 

Methodenrollen 

Methodenrollen 

type Erzwungener Typ Parameter-, Exception- und Feldrollen 

Tabelle 16: Einschränkungen für Rollen [Viljaama 2002, 55] 

Ein Beispiel für eine Einschränkung ist das Schlüsselwort inheritance in Quellcode 

17, Zeile 5. Es bedeutet, dass bei Anwendung des Musters eine Instanz der Rolle 

ConcreteFactory von einer Instanz der Rolle AbstractFactory erben bzw. diese 

implementieren muss. Bei einer Verletzung der Einschränkung wird der Benutzer auf 

den Fehler hingewiesen und muss diesen korrigieren. 

8.2.3 Schablonen 

Mit Schablonen (Templates) ist es möglich, Standardwerte für Rollen zu definieren 

oder eine Hilfestellung für dessen Anwendung bereitzustellen. Einige vordefinierte 

Schablonen von FRED sind in Tabelle 17 ersichtlich. Beginnt eine Schablone mit 

default, so wird sie zur Codegenerierung eingesetzt. taskTitle und 

taskDescription werden bspw. für die Bereitstellung von Hilfetexten verwendet. 

Template Beschreibung Anzuwenden für Rollentyp 

defaultImplementation 

defaultKind 

Standardimplementierung für 

Methoden und Konstruktoren 

Standardwert für Klassenrollen 

("interface" oder "class") 

Methoden- und Konstrukturrollen 

Klassenrollen 

defaultName Standardname für Rollen Alle Rollentypen 

taskDescription Beschreibung für Benutzer Alle Rollentypen 

taskTitle Titel der Rolle Alle Rollentypen 

Tabelle 17: Beispielschablonen von FRED [Viljaama 2001, 56]


Ein Beispiel für eine Schablone ist die Definition taskTitle: "Subclass 

" in Quellcode 17, Zeile 6. Es verweist mit dem Ausdruck in der Spitzklammer 

auf die Abhängigkeit "x", die festlegt, dass ConcreteFactory von 

AbstractFactory erben bzw. diese implementieren muss. Der Ausdruck ".name" 

nach "x" ist eine Hilfsfunktion, die den Namen einer Rolleninstanz zurückliefert. Vergibt 

man nun bei der Anwendung des Musters für die Rolle AbstractFactory den 

Wert "WidgetFactory", so erscheint als Hilfetext bei der Instanzierung von 

ConcreteFactory der Ausdruck "Subclass WidgetFactory". Somit ist sofort ersichtlich, 

dass eine Subklasse von "WidgetFactory" generiert werden muss. Mit dieser 

Methodik kann Benutzern bei der Anwendung von Mustern eine wertvolle Hilfestellung 

gegeben werden. Tabelle 18 zeigt einige Hilfsfunktionen und deren Funktionalität. 

Funktion 

class 

name 

parent 

self 

Beschreibung 

Gibt den Klassennamen der Rolleninstanz zurück 

Gibt den Namen der Rolleninstanz zurück 

Gibt den Namen der (falls vorhanden) umschließenden Rolle zurück 

Verweist auf die eigenen Rolleninstanz 

Tabelle 18: Beispielfunktionen von FRED [Viljaama 2001, 56] 

8.2.4 Beispieldefinition Abstract Factory 

Die Definition eines Entwurfsmusters erfolgt mit dem integrierten FRED-Werkzeug 

Pattern Editor. Eine Beschreibung von Pattern Editor ist nicht Teil dieser Arbeit, 

kann jedoch in [Viljamaa 2001] nachgelesen werden. Quellcode 18 zeigt die Notation 

der Definition von Abstract Factory.


1 pattern AbstractFactory; 

2 class role AbstractFactory{ 

3 description: "Declares an interface for operations that 

4 create abstract product objects."; 

5 defaultKind: "interface"; 

6 method role createAbstractProduct [p: AbstractProduct] { 

7 returnType: p; 

8 defaultName: "create""; 

9 description: "Method for creating ."; 

10 } 

11 } 

12 class role AbstractProduct{ 

13 description: "Declares an interface for a type of product 

14 object"; 

15 defaultKind: "interface"; 

16 } 

17 class role ConcreteFactory 1..* [f: AbstractFactory] { 

18 defaultName: "Concrete"; 

19 inheritance: f; 

20 description: "Implements the operations to create concrete 

21 product 

22 objects. Implements the interface."; 

23 method role createAbstractProduct 

24 [cp: f.createAbstractProduct] { 

25 defaultName: ""; 

26 overriding: cp; 

27 } 

28 } 

29 class role Product 1..* [p: AbstractProduct] { 

30 defaultName: "Concrete"; 

31 inheritance: p; 

32 description: "Defines a product object to be created by the 

33 corresponding concrete factory. Implements the 

34 interface."; 

35 } 

Quellcode 18: FRED-Definition von Abstract Factory 

Die Klassenrolle AbstractFactory (Zeilen 2-11) hat die Kardinalität "1", somit muss 

von ihr genau eine Instanz erzeugt werden. Die Schablone defaultKind gibt den 

Standardtyp von AbstractFactory an - in diesem Fall "interface". Mit defaultName 

wird bei Anwendung des Musters ein Standardwert vergeben. Der Ausdruck "" 

gibt den aktuellen Namen von "p" zurück. Der Standardwert bei Vergabe des Namens 

"Window" für die Rolle AbstractProduct ist daher "createWindow". Auch die 

Schablone description erhält dynamisch den Hilfetext. Die Methodenrolle 

createAbstractProduct (Zeilen 6-10) bildet die Schnittstelle zur Objekterzeugung. 

Sie hat eine Abhängigkeit "p" von der Klassenrolle AbstractProduct. Aufgrund dieser 

Abhängigkeit muss für jede Instanz der Rolle AbstractProduct eine Instanz von 

createAbstractProduct existieren.


Die Klassenrolle AbstractProduct (Zeilen 12-16) definiert die Schnittstellen für die 

Instanzen der Rolle Product. Sie wird von AbstractFactory und Product in den 

Zeilen 6 und 29 über Abhängigkeiten referenziert. 

Die Klassenrolle ConcreteFactory (Zeilen 17-28) repräsentiert die implementierenden 

Klassen von AbstractFactory. Sie ist durch den Ausdruck [f: 

AbstractFactory] in Zeile 17 von AbstractFactory abhängig und enthält weiters 

eine Schablone für den Standardnamen und für die Beschreibung. Mit inheritance: 

f; aus Zeile 19 wird das Ableiten von der Klassenrolle AbstractFactory erzwungen. 

Eine Methodenrolle createAbstractProduct (Zeilen 23-27) wurde als Subrolle für 

ConcreteFactory zur Spezifikation der Objekterzeugung eingeführt. Sie besitzt in 

Zeile 24 die Abhängigkeit "cp" von der Methodenrolle createAbstractProduct 

("f" ist die Abhängigkeit von AbstractFactory). Die Einschränkung overriding 

bestimmt, dass sie die Instanz der Methodenrolle createAbstractProduct aus 

AbstractFactory überschreiben muss. Weiters wurde eine Schablone für einen Standardnamen 

eingeführt, die den Wert der Instanz createAbstractProduct von 

AbstractFactory liefert. 

Die Klassenrolle Product (Zeilen 29-35) definiert die Subklassen von 

AbstractProduct. Daher hat sie eine Abhängigkeit "p" (Zeile 29), die auf 

AbstractProduct verweist. Durch die Kardinalität "1..*" können ein oder mehrere 

Instanzen von Product je Instanz von AbstractProduct erzeugt werden. Durch den 

Wert inheritance "p" aus Zeile 31 muss Product von AbstractProduct erben. 

Weiters existiert eine Schablone description zur Generierung des Hilfetextes. Der 

Ausdruck "" gibt dabei den Klassennamen der Rolleninstanz von 

AbstractProduct zurück. 

Mit dieser Methodik ist es möglich, verschiedenste Musterstrukturen und deren Verhalten 

zu modellieren. Für Abstract Factory kann man bspw. noch mit Rollen vom 

Typ "code snippet" die einzelnen Methodenkörper genau ausformulieren. Für eine 

genauere Definition der Möglichkeiten bzw. der Bedienung des Werkzeuges sei auf 

die Quellen [Tampere 2002] und [Viljamaa 2001] verwiesen. 

8.2.5 Verwaltung und Dokumentation 

FRED-Muster können als Datei mit der Endung ".pat" abgespeichert und jederzeit 

wieder aufgerufen und neu konfiguriert werden. Zur Dokumentation benutzt FRED 

das HTML-Format. Für jedes Muster können verschiedene HTML-Dateien definiert


werden, die zusammen die Gesamtdokumentation bilden. Weiters ist es auch möglich 

für Rollen eine HTML-Dokumentation in die Schablonen taskDescription und 

taskTitle zu integrieren. Visualisiert wird die Dokumentation mit einem integrierten 

HTML-Browser. 

8.3 Vergleich 

Nachfolgender Vergleich von PBE, FRED und PSE-Base soll die Unterschiede und 

Gemeinsamkeiten der Werkzeuge aufdecken und durch eine Gegenüberstellung die 

Stärken bzw. Schwächen ermitteln. 

8.3.1 Kriterien 

Die Kriterien für den Vergleich wurden anhand verschiedener in der Literatur gefundenen 

Anforderungen und eigenen Erfahrungen zusammengestellt. Sie gliedern sich in 

folgende Punkte: 

Kategorisierung 

Unter Kategorisierung versteht man die Möglichkeiten zur Einteilung von Entwurfsmustern 

in Kategorien. Diese gestalten das Arbeiten mit Mustern übersichtlicher. Die 

Ausprägungen für dieses Kriterium sind "gut integriert", "mittelmäßig integriert" und 

"nicht integriert". 

Flexibilität der Definition 

Als Flexibilität werden die Möglichkeiten zur Musterdefinition verstanden. Eine hohe 

Flexibilität erlaubt die programmiersprachenunabhängige Verwaltung der in der Literatur 

vorhandenen und eigenen Muster [Meijers 1996, 58]. Weiters sind für eine hohe 

Flexibilität auch Funktionalitäten für Musterdefinitionen komplexerer Art notwendig. 

Diese umfassen bspw. Bedingungen, Schablonen, Hilfetexte und Einschränkungen. 

Die Ausprägungen reichen von "hoch" über "mittel" bis "niedrig". 

Flexibilität der Dokumentation 

Die Dokumentation ist ein wichtiger Bestandteil, um dem Benutzer die Möglichkeiten 

der Anwendung eines bestimmten Musters aufzuzeigen. Bei einer hohen Flexibilität 

werden verschiedene ASCII-Dokumentationsformate unterstützt und keine Struktur 

festgelegt. Eine niedrige beschränkt sich auf ein vorgegebenes Format und eine fixierte 

Struktur. Die Ausprägungen reichen daher von "hoch" über "mittel" bis "niedrig".


Suchfunktionalitäten 

Bei der Suche nach Entwurfsmustern sind laut [Greene 2002, 2] folgende Suchmodi 

relevant: 

‣ Suche nach Schlüsselwörtern: Durchsuchen nach gewissen Schlüsselwörtern, 

die vorher für das Muster definiert wurden. 

‣ Volltextsuche: Durchsuchen der gesamten Musterdefinition anhand eingegebener 

Suchbegriffe. 

‣ Erweiterte Suche: Durchsuchen bestimmter Teilbereiche eines Musters wie 

z. B. "Motivation" oder "Konsequenzen". 

Die Ausprägungen für dieses Kriterium sind "reichlich vorhanden", "mittelmäßig vorhanden" 

und "nicht vorhanden". 

Komplexität 

Die Komplexität gibt an, wie aufwendig die Definition eines Musters ist. Da die drei 

Werkzeuge große Unterschiede in den Ansätzen und der Werkzeugunterstützung aufweisen 

(bspw. definiert PBE die Entwurfsmuster durch Parametrisierung direkt im 

Quellcode und nicht wie PSE-Admin und FRED über Rollen), erfolgt die Bewertung 

durch eine subjektive Einschätzung, wobei die Ausprägungen von "hoch" über "mittel" 

bis "niedrig" reichen. 

Verwaltung 

Die Verwaltung zeigt, in welcher Weise die definierten Entwurfsmuster im System 

abgelegt werden. Eine fixe Einteilung der Ausprägungen ist dabei nicht möglich. 

Visualisierung 

Dieses Kriterium zeigt, wie gut die Visualisierung der Entwurfsmuster und deren 

Dokumentation aufbereitet wurde. Eine adäquate Aufbereitung verbessert die 

Navigation und gibt dem Benutzer einen besseren Überblick über die Muster [Yacoub 

1999, 3]. Die Ausprägungen sind "gut aufbereitet", "mittel aufbereitet" und "schlecht 

aufbereitet".


8.3.2 Ergebnisse 

Tabelle 19 illustriert die gesammelten Ergebnisse des Vergleichs. Da bei allen Kriterien 

bis auf "Verwaltung" drei verschiedene Ausprägungen möglich sind, wird zur 

besseren Übersichtlichkeit folgende Skala zur Darstellung der Ergebnisse verwendet: 

‣ + für die beste Wertung. 

‣ +ο für eine Wertung zwischen + und ο. 

‣ ο für eine durchschnittliche Wertung. 

‣ ο- für eine Wertung zwischen ο und -. 

‣ - für eine schlechte Wertung. 

Vergleichskriterium PBE FRED PSE-Base 

Kategorisierung − − + 

Flexibilität d. Definition +ο + ο 

Flexibilität d. Dokumentation − +ο + 

Suchfunktionalitäten − − − 

Komplexität + ο + 

Verwaltung 

ASCII-Dateien 

(".pdef") 

ASCII-Dateien 

(".pat") 

ASCII-Dateien 

(".xml") 

Visualisierung − ο + 

Tabelle 19: Gesamtergebnis des Vergleichs 

Kategorisierung 

Bei PBE und FRED ist eine Kategorisierung der Entwurfsmuster nicht integriert. PSE- 

Base hingegen unterstützt den Aufbau von Kategoriehierachien auf maximal zwei 

Ebenen. Weiters ist die Zuordnung von einem Muster auf mehrere Kategorien möglich. 

Flexibilität der Definition 

Alle drei Werkzeuge erlauben eine flexible und programmiersprachenunabhängige 

Definition von Entwurfsmustern. Entwickler können somit mit diesen Werkzeugen 

auch eigene Problemlösungsverfahren als Muster definieren. Für komplexere Musterdefinition 

sind hingegen nur FRED und PBE geeignet, da in PSE-Base keine Funktionalitäten 

für diesen Bereich integriert sind. FRED erlaubt dem Benutzer mit der Anwendung 

von Schablonen, Einschränkungen, Zusatzmethoden usw. Muster auf ver-


schiedenste Art und Weise zu definieren bzw. einzuschränken. Weiters wird auch die 

Generierung dynamischer Hilfetexte unterstützt. Daher sind mit FRED äußerst mächtige 

Musterdefinitionen möglich. PBE bietet mit dem Einsatz von optionalen und wiederholbaren 

Codeblöcken, sowie mit Ausdrücken einige Möglichkeiten für komplexere 

Definitionen, erreicht jedoch nicht die Mächtigkeit von FRED. 

Flexibilität der Dokumentation 

Mit PBE ist nur eine Dokumentation gemäß der Struktur aus [Gamma 1995, 6-7] 

möglich. Das Format ist auf gewöhnlichen ASCII-Text beschränkt. Eine umfangreiche 

und übersichtliche Dokumentation mit Bildern und Formatierungen ist somit nicht 

möglich. 

FRED erlaubt den Aufbau einer Dokumentation im HTML-Format, wobei die Struktur 

nicht vorgegeben ist. Verschiedene, einem Muster zugeordnete HTML-Dateien, 

bilden die Gesamtdokumentation, die mit einem integrierten Browser dargestellt werden 

kann. 

PSE-Base schreibt weder eine Struktur noch ein ASCII-Format vor. Empfohlen wird 

jedoch das HTML-Format, zumal zur Laufzeit eine HTML-Gesamtdokumentation mit 

Inhaltsverzeichnis aus den einzelnen Dokumentationsteilen erstellt wird. Der Inhalt 

dieser Teile kann direkt in der allgemeinen Beschreibungsdatei ("manifest.xml") eines 

Musters oder in ASCII-Dateien (z. B. ".html", ".txt") liegen. 

Suchfunktionalitäten 

Keines der drei Werkzeuge bietet Funktionalitäten für die Suche nach Entwurfsmuster 

an. 

Komplexität 

Die subjektive Einschätzung der Komplexität erfolgte durch eine Beispieldefinition 

von Abstract Factory mit allen drei Werkzeugen. Dabei war eine Definition des 

Musters mit PBE und PSE-Base relativ schnell und komfortabel umzusetzen. 

FRED benötigt hingegen auch bei einfachen Mustern eine komplexere Struktur, um 

eine Basis für die vielen Funktionalitäten zu ermöglichen, auch wenn diese nicht verwendet 

werden. Aus diesem Grund gestaltete sich die Definition von Abstract Factory 

bei FRED aufwendiger. 

Verwaltung 

Alle drei Werkzeuge verwalten die Entwurfsmuster anhand ASCII-Dateien mit verschiedenen 

Endungen.


Visualisierung 

PBE erlaubt weder die Visualisierung der vorhandenen Entwurfsmuster noch eine 

geeignete Darstellung der Dokumentation. Die verwalteten Muster werden nur durch 

ein Durchsuchen des Dateisystems, in dem sie mit der Endung ".pdef" abgelegt sind, 

ersichtlich. Die Dokumentation ist gewöhnlicher ASCII-Text, der in Tabellenform 

dargestellt wird. 

Bei FRED erfolgt die Visualisierung der Muster genau wie in PBE anhand des Dateisystems. 

Für die Darstellung der Dokumentation kann ein integrierter HTML-Browser 

verwendet werden. 

PSE-Base visualisiert die verwalteten Entwurfsmuster und deren Kategorien in einer 

Baumstruktur. Die Dokumentation wird durch eine Selektion eines Musters angesteuert 

und in einem eigenem HTML-Browser ("Pattern Browser" von PSE-V) dargestellt. 


In diesem Kapitel wurden zwei weitere Werkzeuge zur Definition und Verwaltung 

von Entwurfsmustern und deren Dokumentation vorgestellt. Diese beiden und PSE- 

Base wurden anhand verschiedener Kriterien miteinander verglichen. 

Bei allen drei wird ein hohes Augenmerk auf die Definition von Entwurfsmustern 

gelegt. Jeder der Ansätze erlaubt eine flexible und programmiersprachenunabhängige 

Verwaltung der Muster. Sehr mächtige Musterdefinition sind jedoch nur mit PBE, vor 

allem aber mit FRED durch viele Zusatzfunktionalitäten möglich. PSE-Base bietet in 

diesem Bereich keine Unterstützung an. 

Bei der Dokumentation erlaubt nur PSE-Base eine zufriedenstellende Definition der 

Dokumentationsteile. Auch die Integration der Kategorisierung bzw. der Aufbau der 

Visualisierung wurde nur von PSE-Base gut gelöst. Die beiden anderen Ansätze weisen 

in diesen Punkten einige Mängel auf. Keines der drei Werkzeuge bietet Funktionalitäten 

für die Suche innerhalb der verwalteten Entwurfsmuster an, was bei einem 

umfangreicheren Musterkatalog ein erheblicher Nachteil ist. 

Der Vergleich der Verwaltung und Definition der Entwurfsmuster und deren Dokumentation 

kann nicht die gesamten Vor- und Nachteile der jeweiligen Werkzeuge aufzeigen, 

da für diesen Zweck auch ein Vergleich der Anwendung von Enwurfsmustern 

notwendig ist. Mehr Aufschluss gibt daher eine Gegenüberstellung des Anwendungsbereiches 

der Werkzeuge wie er in [Mayr-Kern 2002] durchgeführt wurde.

Zusammenfassung und Ausblick 93 

9 Zusammenfassung und Ausblick 

Dieses Kapitel fasst die Erkenntnisse dieser Arbeit zusammen und gibt einen Ausblick 

auf die Erweiterungsmöglichkeiten von PSE-Base. 


In dieser Arbeit wurde ein Werkzeug zur flexiblen Definition, Verwaltung und Visualisierung 

von Entwurfsmustern und deren Dokumentation vorgestellt. Dieses Werkzeug 

(PSE-Base) besteht aus den Teilen PSE-D (Definition und Verwaltung) und 

PSE-V (Visualisierung) und ist Teil eines Gesamtwerkzeuges zur Unterstützung der 

Softwareentwicklung mit Entwurfsmustern (PSE). Alle Komponenten von PSE wurden 

mit Java entwickelt und sind eine Erweiterung der Entwicklungsumgebung 

Eclipse. 

Entwurfsmuster stellen Lösungsvorschläge für bestimmte grundlegende Entwurfsprobleme 

dar und sind beim Aufbau einer flexiblen und wiederverwendbaren Systemarchitektur 

hilfreich. Sie haben in der objektorientierten Softwareentwicklung einen 

hohen Stellenwert erhalten und werden daher häufig werkzeugunterstützt bei der Entwicklung 

oder Transformation von Softwaresystemen verwendet. 

PSE-D beschreibt eine Vorgehensweise zur flexiblen Definition und Verwaltung von 

Entwurfsmustern und deren Dokumentation auf der Basis von XML. Laut PSE-D 

gliedert sich ein Muster in einen allgemeinen und einen oder mehrere implementierungsspezifische 

Beschreibungsteil(e). Damit wird eine programmiersprachenunabhängige 

Verwaltung der Entwurfsmuster unterstützt. Für die Dokumentation der 

Muster ist eine freie Struktur und ein beliebiges ASCII-Format wählbar. Diese können 

mit ihren Dokumentationsteilen in einem frei wählbarem Verzeichnis verwaltet werden, 

wobei für jedes Muster ein Unterverzeichnis mit seinem Namen existieren muss. 

Neben der Verwaltung und Definition ist vor allen der Zugriff auf die interne Datenstruktur 

für andere Anwendungen wichtig. Für diesen Zweck werden von PSE-D Programmierschnittstellen 

bereitgestellt, mit denen man Zugriff auf die interne Muster- 

Infrastruktur erhält. Diese wird durch mehrere Java-Klassen abgebildet, die den allgemeinen 

und den/die implementierungsspezifischen Beschreibungsteil(e) der Muster 

kapseln.


Für die Visualisierung der verwalteten Entwurfsmuster und deren Dokumentation 

wurde das Werkzeug PSE-V entwickelt. Durch die Integration von PSE-V in die Entwicklungsumgebung 

Eclipse werden dessen Komponenten (die Views "Pattern Navigator" 

und "Pattern Browser") über eigene Menübefehle von Eclipse gestartet. 

"Pattern Navigator" generiert dabei beim Starten die Musternavigation in Form einer 

Baumstruktur, wobei zur besseren Übersichtlichkeit die Muster je nach Kategoriezugehörigkeit 

gruppiert werden. Die Dokumentation wird von "Pattern Browser" visualisiert 

und lässt sich über die Selektion eines Musters in "Pattern Navigator" ansteuern. 

PSE-V ermöglicht somit einen komfortablen Überblick über die verwalteten 

Muster und deren Aufbau. 

Die Implementierung von PSE-V wurde in mehrere Pakete mit verschiedenen Aufgabengebieten 

eingeteilt. Da die Verwaltung der Muster und die Konfiguration des 

Werkzeuges in XML erfolgt, wurde der Zugriff auf diese Dokumente in einem Anwendungsbeispiel 

erläutert. 

Neben PSE-Base existieren natürlich auch weitere Werkzeuge, die sich unter anderem 

mit der Definition und Verwaltung von Entwurfsmustern beschäftigen. Daher wurde 

eine Musterdefinition anhand zweier vergleichbarer Werkzeuge (PBE und FRED) 

erläutert. Durch einen abschließenden Vergleich aller drei Werkzeuge anhand verschiedener 

Kriterien wurden die Stärken bzw. Schwächen herausgearbeitet und damit 

mögliche Ansatzpunkte für eine Verbesserung aufgedeckt. 

9.2 Ausblick 

Obwohl mit PSE-Admin eine flexible Definition und Verwaltung von Entwurfsmustern 

und deren Dokumentation möglich ist, sind doch einige Ansatzpunkte gegeben, 

an denen eine Weiterentwicklung die Qualität des Werkzeuges verbessert. 

Definition auf einer höheren Abstraktionsebene 

Die Definition der Beschreibungsdateien für die Entwurfsmuster erfolgt auf der Basis 

von XML. Da jedes XML-Dokument auf ein XML-Schema verweisen muss, wird ein 

XML-Editor mit Schema-Unterstützung zur Definition empfohlen, um die Konsistenz 

der Daten sicherzustellen. Ein in Eclipse integriertes Werkzeug zur Definition der 

Muster auf einer höheren Abstraktionsebene ohne XML-Vorkenntnisse zu benötigen, 

ist aufgrund der Konsistenz der Benutzerführung besser als die direkte Bearbeitung 

der XML-Dokumente.


Integration von Suchfunktionalitäten: 

Eine Integration verschiedenster Suchfunktionalitäten (Stichwortsuche, Volltextsuche 

usw.) gestaltet eine Verwaltung eines umfangreichen Musterkataloges einfacher und 

erspart dem Benutzer Zeit bei der Suche nach gewissen Eigenschaften von Mustern. 

Integration von Funktionalitäten für komplexere Definitionen 

Derzeit sind keine Funktionalitäten wie bspw. Einschränkungen, Ausdrücke, Schablonen 

und dynamische Hilfetexte vorgesehen. Ein selektives Angebot in diesem Bereich 

kann dem Benutzer beim Entwerfen seiner Entwurfsmuster in vielen Anwendungsbereichen 

eine Hilfestellung bieten. 

Eine Weiterentwicklung von PSE-Admin in den angesprochenen Punkten kann 

Entwicklern in Zukunft verhelfen, Entwurfsmuster und deren Dokumentation noch 

komfortabler zu definieren und zu verwalten.

Anhang A: Glossar 96 

Anhang A: Glossar 

ASCII-Format (American Standard Code for Information Interchange) 

Format, dass Zeichen mit einem Zahlencode aus 7 (Standard ASCII-Zeichensatz) oder 

8 Bit (erweiterter Zeichensatz mit Sonderzeichen) definiert. 

CPL (Common Public License) 

Lizenz, die gebührenfreien Quelltext und weltweite Vergabe der Rechte ermöglicht. 

DTD (Document Type Definition) 

Vorgänger von XML-Schema zur Definition einer Struktur von XML-Dokumenten. 

Gilt als veraltert und weist weniger Möglichkeiten wie XML-Schema auf. 

Eclipse 

Von einem Konsortium verschiedener Softwareunternehmen entwickelte kostenlose 

Java-Entwicklungsumgebung. Der große Vorteil von Eclipse ist die Erweiterbarkeit 

durch Plugins und der freie Zugang auf den Quellcode der Umgebung [Eclipse 

2002a]. 

Framework 

Ansammlung von Klassen, welche einen abstrakten Entwurf für Lösungen zu einer 

Familie verwandter Probleme enthalten. Der Programmierer muss nur Codes schreiben, 

wenn er das Verhalten des Framework verändern oder erweitern will [Freiberg 

2002]. 

HTML-Browser 

Werkzeug zur Darstellung von Dateien, die im HTML-Format abgespeichert sind. 

Bekannte HTML-Browser sind "Microsoft Internet Explorer" und "Netscape Navigator". 

Java Virtual Machine 

Wird für die Ausführung von Java-Programmen benötigt und muss auf dem zur Ausführung 

bestimmten Betriebssystem installiert werden. Durch die Java Virtual 

Machine sind Java-Programme nicht an ein bestimmtes Betriebssystem gebunden. 

look and feel 

Bezeichnung des Verhaltens und Aussehens einer Anwendung. Bei PSE war die Eingliederung 

in die Entwicklungsumgebung Eclipse ein Ziel, um damit dem Werkzeug


das look and feel von Eclipse zu verleihen und dadurch konsistente Benutzerführung 

zu ermöglichen. 

Pattern Navigator 

Teil von PSE-V, der für die Darstellung der Musternavigation zuständig ist. 

Pattern Browser 

Teil von PSE-V, der für die Darstellung der HTML-Dokumentation der Muster zuständig 

ist. 

Plugin 

Erweiterungsmöglichkeit von Eclipse. Jede Erweiterung von Eclipse trägt die Bezeichnung 

Plugin. 

PSE (Pattern Support for Eclipse) 

Werkzeug zur Unterstützung der Softwareentwicklung mit Hilfe von Entwurfsmustern, 

das als Erweiterung der Entwicklungsumgebung Eclipse konzipiert wurde. Besteht 

aus den Teilen PSE-Base und PSE-Application. 

PSE-Application 

Werkzeug zur Anwendung von Entwurfsmustern. Teil von PSE. 

PSE-Base 

Werkzeug zur Definition, Verwaltung und Visualisierung von Entwurfsmustern und 

deren Dokumentation. Besteht aus den Teilen PSE-D (Definition) und PSE-V (Visualisierung) 

und ist Teil von PSE. 

PSE-D (Pattern Support for Eclipse – Definition) 

Werkzeug zur Definition und Verwaltung von Entwurfsmustern und deren Dokumentation 

auf der Basis von XML. Stellt weiters Schnittstellen für den Zugriff auf die 

interne Muster-Infrastruktur zur Verfügung und wird daher von PSE-V und PSE-Application 

verwendet. 

PSE-V (Pattern Support for Eclipse – Visualisation) 

Werkzeug zur Visualisierung der durch PSE-D verwalteten Muster-Infrastruktur. Es 

unterstützt die Baumnavigation durch die verwalteten Entwurfsmuster, die je nach 

ihrer Kategoriezugehörigkeit dargestellt werden. Durch Selektion eines Musters wird 

dessen Dokumentation dargestellt. 

Streaming 

Internettechnologie, die erlaubt Audio- oder Video-Dateien bereits während dem Herunterladen 

anzuhören bzw. anzusehen. Man spricht daher auch von Echtzeitübertra-


gungen, da Daten ohne größere Zeitverschiebung wiedergegeben werden [Glossar 

2002]. 

View 

Ein in Eclipse frei positionierbares Fester, dass eine gewisse Aufgabe erfüllt. Teil eines 

Plugin. 

XML (eXtensible Markup Language) 

Ein vom W3C entwickelter Standard zur strukturierten Darstellung von Daten in 

ASCII-Dokumenten mit der Endung ".xml". XML trennt das Layout vom Inhalt der 

Dokumente. 

XML-Schema 

Nachfolger der DTD. Ermöglicht für XML-Dokumente die Struktur deren Inhalt vorzuschreiben 

und kann aufgrund seiner Flexibilität auch für komplexere Modellierungen 

verwendet werden.

Anhang B: Literaturverzeichnis 99 

Anhang B: Literaturverzeichnis 

[Agerbo 1998] 

[Alexander 1995] 

[Altova 2002] 

[Anti Pattern 2002] 

[Buschmann 2000] 

[Chambers 2000] 

[Coplien 1992] 

[Delta 2002a] 

E. Agerbo, A. Cornils, How to preserve the benefits 

of Design Patterns, Conference on Object-oriented 

programming systems, languages, and applications 

in Vancouver, British Columbia, Canada, 

ACM-Press, 1998 

C. Alexander, S. Ishikawa, M. Silverstein, Eine 

Muster-Sprache, Löcker Verlag, 1995 

Altova Gmbh, XMLSpy, XML-Editor, Online im 

Internet: URL: http://www.xmlspy.com [Stand 

16.7.2002] 

Tu Graz, Anti Pattern, Online im Internet: URL: 

http://xarch.tu-graz.ac.at/autocad/wiki/AntiPattern 

[Stand 11.7.2002] 

F. Buschmann, H. Rohnert, M. Stal, D. Schmidth, 

Pattern Oriented Software Architecture Vol. 2, 

John Wiley and Sons Ltd, Chichester, UK, 2000 

C. Chambers, B. Harrison, J. Vlissides, A Debate 

on Language and Tool Support for Design Patterns, 

27th ACM SIGPLAN-SIGACT symposium 

on Principles of programming languages, ACM- 

Press, 2000 

J. O. Coplien, Advanced C++ Programming Styles 

and Idioms, Massachusetts, Addison-Wesley, 1992 

Delta Software Technology Group, Pattern by 

Example, Werkzeug zur Unterstützung der Programmierung 

mit Entwurfsmustern, Online im Internet: 

URL: http://www.delta-softwaretechnology.com 

[Stand 18.7.2002]


[Delta 2002b] 

[Eclipse 2002a] 

[Eclipse 2002b] 

[Freiberg 2002] 

[Gamma 1995] 

[Glossar 2002] 

[Greene 2002] 

[Helm 1995] 

[JDOM 2002] 

[Kappel 2001a] 

Delta Software Technology Group, Pattern by 

Example-Manual, Online im Internet: URL: 

http://www.delta-software-technology.com [Stand 

18.7.2002] 

Eclipse Consortium, Entwicklungsumgebung 

Eclipse 2.0, Online im Internet: URL: 

http://www.eclipse.org [Stand 12.7.2002] 

Eclipse Consortium, Eclipse project briefing 

materials, Online im Internet: URL: 

http://www.eclipse.org/eclipse/index.html [Stand: 

24. 9. 2002] 

TU-Freiberg, Begriffsdefinitionen, Online im Internet: 

URL: http://www.informatik.tu-freiberg.de/ 

forschung/bpaframe/bpaframe.htm [Stand 

25.7.2002] 

E. Gamma, R. Helm, R. Johnson, J. Vlissides, 

Design Patterns – Elements of Reusable Object- 

Oriented Software, Addison-Wesley, 1995 

Online Glossar/Lexikon, Online im Internet: URL: 

http://www.glossar.de [Stand 26.8.2002] 

S. L. Greene, P. Matchen, L. Jones, Patterns in 

Pracice: A Workshop for UI Designers, IBM 2002 

R. Helm, Patterns in Practice, Conference on Object-oriented 

programming systems, languages and 

applications in Austin, Texas, USA, ACM-Press, 

1995 

JDOM – XML-API, Online im Internet: URL: 

http://www.jdom.org 

G. Kappel, E. Kapsammer, W. Retschitzegger, 

XML-Grundlagen, Vorlesungsskript Spezielle Fragen 

aus IS – Modellierung von Web-Applikationen, 

Universität Linz, 2001


[Kappel 2001b] 

[Kappel 2001c] 

[Mayr-Kern 2002] 

[McCormick 1998] 

[Megginson 2002] 

[Meijers 1996] 

[OMG 2002] 

[Paulisch 1996] 

[Pomberger 1998] 


XML-Schema, Vorlesungsskript Spezielle Fragen 

aus IS – Modellierung von Web-Applikationen, 

Universität Linz, 2001 


XML-API's, Vorlesungsskript Spezielle Fragen aus 

IS – Modellierung von Web-Applikationen, Universität 

Linz, 2001 

I. Mayr-Kern, Erweiterung einer Programmierumgebung 

zur Unterstützung pattern-basierter 

Softwareentwicklung, Diplomarbeit an der Johannes 

Kepler Universität Linz, 2002 

H. W. McCormick, AntiPatterns Refactoring Software 

Architectures and Projects in Crisis, Online 

im Internet: URL: http://www.antipatterns.com/ 

briefing/sld003.htm[Stand: 11.7.2002] 

Megginson Technologies, SAX – Simple API for 

XML, Online im Internet: URL: 

http://www.saxproject.org/[Stand 16.7.2002] 

Marco Meijers, Tool Support For Object Oriented 

Design Patterns, Master Thesis at the Department 

of Computer Science, Utrecht University, 1996 

Object Management Group, OMG Unified Modeling 

Language Specification V1.4, Online im Internet: 

URL: http://www.omg.org/ technology/ 

documents/formal/uml.htm [Stand: 10.7.2002] 

F. Paulisch, Tool Support for Software Architecture, 

SIGSOFT 96 Workshop, San Francisco CA 

USA, ACM 1996 

G. Pomberger, Methoden und Werkzeuge für das 

Software Engineering, Vorlesungsskript Software 

Engineering, Universität Linz, 1998


[Pree 1994] 

[Rumbaugh 1991] 

[Sun 2002a] 

[Sun 2002b] 

[Tampere 2002] 

[Viljaama 2001] 

[W3C 2002a] 

[W3C 2002b] 

[W3C 2002c] 

[W3C 2002d] 

W. Pree, Design Patterns for Object-Oriented Software 

Development, Addison-Wesley, 1994 

J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, 

W. Lorenson, Object-Oriented Modeling and Design, 

Prentice Hall, Englewood Cliffs, New York, 

1991 

Sun Microsystems Inc, JAXP – Java API for XML 

Processing, Online im Internet: URL: 

http://java.sun.com/xml/jaxp/index.html [Stand 

16.7.2002] 

Sun Microsystems Inc., JRE 1.3.1 -Java Runtime 

Environment, Online im Internet: URL: 

http://java.sun.com/j2se/1.3/download.html [Stand 

17.7.2002] 

Universität Tampere, FRED-Framework Editor for 

JAVA, Online im Internet: URL: 

http://practise.cs.tut.fi/fred/download.html [Stand: 

7.8.2002] 

A. Viljaama, Pattern Based Framework Annotation 

and Adaption, University of Helsinki, Department 

of Computer Science, Licentiate Thesis, Report C- 

2001-52, Helsinki, Juni 2001 

W3C, XML-Standard, Online im Internet: URL: 

http://www.w3.org/XML/ [Stand 16.7.2002] 

W3C, HTML-Standard, Online im Internet: URL: 

http://www.w3.org/MarkUp/, [Stand 16.7.2002] 

W3C, XML-Schema-Standard, Online im Internet: 

URL: http://www.w3.org/XML/Schema/ [Stand: 

16.7.2002] 

W3C, Document Object Model, Online im Internet: 

URL: http://www.w3.org/DOM/ [Stand 16.7.2002]


[Yacoub 1999] 

S. M. Yacoub, H. M. Ammar, Tool Support for 

Developing Pattern-Oriented Architectures, Computer 

Science and Electrical Engineering Dept. 

West Virginia University, USA, 1999

Erweiterung einer Entwicklungsumgebung zur flexiblen Definition ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?