Case Tools Unterstützung für Design Pattern - Universität Paderborn
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Universität Paderborn
Fachbereich 17 – Mathematik/Informatik
Arbeitsgruppe Softwaretechnik
Prof. Dr. W. Schäfer
Warburger Str. 100
33098 Paderborn
Case Tools Unterstützung für Design Pattern
Seminarausarbeitung
im Rahmen der Projektgruppe
Entwicklung eines verteilten
multimedia Systems mit Hilfe
von Design Pattern
im Projekt
von
Vladislav Krasnyanskiy
Peter-Hille-Weg 11
33098 Paderborn
Paderborn, August 2001Inhaltsverzeichnis
Kapitel 1 Einleitung 3
Kapitel 2 Design Patterns 6
2.1 Was sind Design Patterns ? 6
2.2 Aufbau und Entwicklung eines Design Patterns 6
2.3 Design Pattern Erkennung im Quellcode 7
Kapitel 3 Textuelle und visuelle Programmiersprachen für Design Pattern 9
3.1 Textuelle Programmiersprache für Design Pattern (PaL) 9
3.1.1 Klassenstruktur 9
3.1.2 Wiederverwendbarkeit von Klassen 9
3.1.3 Beispiel 10
3.2 Visuelle Programmiersprache für Design Pattern (DPML) 12
3.2.1 Bestandteile 12
3.2.2 Instanzbildung und Realisierung 13
3.1.3 Beispiel 14
3.3 Gemeinsamkeiten und Unterschiede 15
Kapitel 4 Automatische Codegenerierung für Design Pattern 16
4.1 Systemarchitektur 16
4.2 Implementierung 17
Kapitel 5 Fujaba 18
Literatur 19
2Kapitel 1
Einleitung
Mit steigender Komplexität der Software, wird die Anzahl der beteiligten Entwickler größer.
Es wird in Teams entwickelt. Die Qualitätsanforderungen an Software steigen. Der Einsatz
von objektorientierten Sprachen war ein Schritt in Richtung der besseren Software. Die
heutzutage entwickelten Produkte müssen korrekt, zuverlässig, effizient, verständlich,
wartbar, robust und wiederverwendbar sein. Es wurden einige Modelle entwickelt, die nach
Meinung der Entwickler dieser Modelle, die Qualität der Software steigen würde. Das ist zum
Beispiel das sogenannte Wasserfallmodell [10] (siehe Abbildung 1). Der Kern des Modells
ist, dass der Entwicklungsprozess in Stufen aufgeteilt ist. Die einzelne Stufen sind:
Anforderungsanalyse, Entwurf, Implementierung, Test, Installation und Wartung.
Pflichtenheft
Anforderungsanalyse/
Validation
Systemarchitektur
Entwurf/Validation/Verifikation
Implementierung/
Verifikation
Programme
Beweise
Wartung Technische Handbücher Testpläne Test und
Installation Integration
Benutzerhandbuch Testergebnisse
Abbildung 1: Das Wasserfallmodell
Weitere Modelle findet man in [10]. Das Problem bei den Modellen ist, dass es erstens nicht
immer möglich den Ablauf strikt nach den Modellen zu richten, weil einige schon bearbeitete
Stufen wiederholt ausgeführt werden müssen. Das passiert zum Beispiel dann, wenn der
Kunde oder der Entwickler sich doch nicht so entschieden haben, wie es in ein paar Wochen
davor festgelegt worden ist. Zweitens sehen einige Firmen nicht die Notwendigkeit, dass
diese Modelle zur Qualitätsverbesserung führen. Eine weitere Methode bessere Produkte zu
entwickeln sind Design Pattern (deutsch: Entwurfsmuster). Es ist erkannt worden, dass einige
Probleme immer wieder entworfen werden müssen und dieser Entwurf bei verschiedenen
Entwicklern fast derselbe ist. Diese Lösungsvorschläge für ein und dasselbe Pattern werden
gesammelt und anderen zur Verfügung gestellt. Die Idee von Entwurfsmuster kam vom
3Architekten Christopher Alexander in 1977. Er erkannte, dass es einige Gebäudekomponenten
immer wieder entworfen werden müssen, obwohl alle Architekten wissen, was man zum
Beispiel unter einer Laube versteht. Dafür wird aber trotzdem Zeit investiert, die für andere
Entwurfskomponenten verwendet werden kann. Genau solche Probleme haben auch
Softwareentwickler. Die Idee, Design Pattern in objekt-orientierten Programmen zu
verwenden, ist zuerst 1987 bei Beck und Cunningham aufgetreten [11]. Sie haben eine Pattern
Sprache entwickelt, um Smalktalk-Anfängern den Einstieg in die Sprache zu erleichtern. In
der Folgezeit entstanden verschiedene Veröffentlichungen, die sich meist mit einzelnen
Pattern beschäftigten. 1994 ist das Buch “Design Pattern: Elements of Reusable Object-
Oriented Sofware” herausgegeben worden [2]. Hier wird unter anderem einen Katalog aus 23
Design Pattern vorgestellt. Design Pattern nach [2] können nach folgenden Kategorien
aufgeteilt werden:
Purpose
Creational Structural Behavioral
Scope Class Factory Method Adapter Interpreter
Template Method
Object Abstract Factory Adapter Chain of Responsibility
Builder Bridge Command
Prototype Composite Iterator
Singleton Decorator Mediator
Facade Memento
Proxy Flyweight
Observer
State
Strategy
Visitor
Abbildung 2: Design pattern space [2]
Die Design Pattern aus [2] sind im Quellcode verbreitet. Die Lösungsvarianten sind bekannt
und schon implementiert. Um Fehler bei neuen Implementierung zu vermeiden und dadurch
viel Zeit zu sparen, ist es vom Vorteil eine automatische Überführung von Design Pattern
anzubieten. Eine größtmögliche Toolunterstützung ist dabei von Vorteil.
In dieser Arbeit werden zwei Entwurfsmustersprachen (Pattern Languages) und die
automatische Codegenerierung vorgestellt.
In Kapitel 2 wird eine allgemeine Vorstellung über Design Pattern gegeben.
4In Kapitel 3 werden zwei Design Pattern Languages gegenüber gestellt.
In Kapitel 4 wird ein von IBM entwickeltes Werkzeug für automatische Codegenerierung
beschrieben.
In Kapitel 5 wird Fujaba und seine Design Pattern Unterstützung vorgestellt.
5Kapitel 2 Design Patterns 2.1 Was sind Design Patterns ? [7] Ein Design Pattern ist ein Gerüst zur Lösung eines Designproblems und verzichtet auf Implementierungsdetails. Es liefert legendlich einen Vorschlag zur Lösung eines Problems, nicht eine spezielle Lösung. Ein Design Pattern betrachtet ein Problem von einer höheren Abstraktionsebene. Das Produkt wird verständlicher und leichter zu warten. Für Entwickler liefern Design Pattern neben den bewährten Lösungsvorschlägen, ein gemeinsames Vokabular. Viele Produkte lassen sich sehr schwer warten, weil sie unverständlich geschrieben sind. Kaum ein Entwickler wird sich in einem Jahr erinnern, wieso er dies und jenes gemacht hat. Bei fremden Programmen ist noch schlimmer. Mit den Design Pattern lassen sich viele Verständnisprobleme aus dem Weg räumen. Es wird leichter über das Problem zu diskutieren. Es werden schneller Vor- und Nachteile eines Designs festgestellt. Die Qualität der Produkte steigt. Die Entwicklung wird schneller, weil die Designer Programme schon aus bekannten Lösungen zusammenstellen können. 2.2 Aufbau und Entwicklung eines Design Patterns [1] Der Entwurf mit Hilfe der Design Pattern hat obengenannten Vorteile. Aber wie sind die Design Pattern aufgebaut? Wo ist welche Information über die Pattern zu finden? In [2] sind folgende Bestandteile von Design Pattern vorgestellt: 6
Bestandteil Beschreibung
Name Ein eindeutiger Name
Intent Was macht das Pattern ? Wozu ist es da ?
Motivation Erläuterung der Designidee
Applicability typische Anwendungssituationen
Structure UML-Teildiagramm
Participants Kurzbeschreibung der beteiligten Bausteine
Collaborations Kurzbeschreibung der dynamischen Abläufe
Consequences Diskussion von Vor- und Nachteilen
Implementation Diskussion der Implementierung(svarianten)
Sample Code Implementierungs- und Anwendungsbeispiel
Known Uses bekannten Verwendungen
Related Patterns Querverweise zu anderen Pattern
Wenn man aber sein eigenes Design Pattern erstellen möchte sind folgende Teilaufgaben
wichtig:
1. Reflektion des Problems
2. Welche Struktur ist die Richtige ?
3. Motivation mit konkretem Beispiel
4. Was unterscheidet das neue Pattern von anderen und wie ergänzt es sich ?
5. Publikation des Patterns
6. Verbesserungen
7. Sammeln und Einbauen von Kommentaren
2.3 Design Pattern Erkennung im Quellcode
Design Pattern Erkennung spielt auch eine Rolle bei der Qualitätsbeurteilung der Software.
Pattern Erkennung ermöglicht Design- und Implementierungsvarianten von Design Pattern zu
finden. Pattern Erkennung ist eine Methode aus dem Quellcode Design Pattern zu erkennen.
Die Erkennung ist sehr schwierig, weil Design Pattern keine formale Definition aufweisen. Es
sind nur Designvorschläge, die keine konkrete Implementierung bieten. Zu einem Design
Pattern könnte viele Implementierungen vorhanden sein. In [9] und [7] sind einige Kriterien
aufgeführt, die man beachten muss, wenn man Pattern Erkennung vornehmen will,
insbesondere Tools zur Pattern-Erkennung schreiben möchte:
• Syntaktische Variationen: Bezeichnungen von Klassen und Datenstrukturen
können variieren. Ebenso können für die gleiche Semantik unterschiedliche
syntaktische Konstrukte vorhanden sein (zum Beispiel die Namen für
Methoden mit gleicher Semantik setAttr oder writeAttr)
• Variationen in der Implementierung: konkrete Designvarianten lassen sich
durch verschiedene Implementierungsvarianten realisieren. Jedes Design
Pattern hat mindestens eine Designvariante. Implementierungsvarianten
werden aus dem Verhalten abgeleitet. Einige Design Pattern haben mehrere
Implementierungsvarianten. Zum Beispiel das Design Pattern Composite hat
eine effiziente und eine saubere Implementierungsvariante [1].
• Delokalisierung: Design Pattern bestehen nicht immer aus
zusammenhängenden Komponenten, sie sind oft im ganzen Projekt verstreut.
• Nicht verwertbare Bauteile: Nicht alle Bauteile können Design Pattern
zugeordnet werden, welche dann ignoriert werden müssen.
7• Variation in der Organisation der Komponenten: Komponenten können in
unterschiedlicher Weise unterteilt sein. Zudem existieren verschiedene
Möglichkeiten, Daten in komplexe Datenstrukturen zu packen.
• Redundanz: Diverse Algorithmen, die zum Beispiel einen Wert berechen,
können unnötigerweise immer wieder aufgerufen werden, anstelle den Wert
zwischenzuspeichern.
Es ist auch wichtig dynamisches Verhalten von Objekten zu erkennen. Die meisten Ansätze
zur Design Pattern Erkennung erkennen nur den strukturellen Aufbau von Klassen und
Beziehungen.
8Kapitel 3
Textuelle und visuelle Programmiersprachen für Design Pattern
3.1 Textuelle Programmiersprache für Design Patterns (PaL)
PaL ist eine Eiffel-codeorientierte Design Pattern Sprache. Sie erlaubt Pattern aus Pattern zu
definieren. Das Programm wird zum Hauptpattern. Die Sprache ist formal definiert. Das
Programmmodel der PaL unterstützt Weitergabe und Reuse von Pattern. PaL basiert auf
einem Model, das Widerverwendbarkeit (englisch reusablity) und Zurückverfolgbarkeit
(englisch traceability) von Pattern erlaubt.
3.1.1 Klassenstruktur.
Design Pattern bestehen aus einer Menge von Klassen und sogenannten Features. PaL
unterstützt abstrakte Klassen, die mit dem Schlüsselwort structure beginnen. Von dieser
Klasse können konkrete Klassen abgeleitet werden. Ein Pattern hat folgende Form:
structure sid
[reuse ref1 and ... and ref n ] – reuse von structure
[creation mid1 , ..., mid m ] – Methoden für sid -Initialisation (min. make)
c1 ... ck -- Beschreibung den beteiligten Klassen
f1 ... f l --features
end
Die structure sid ist eine Klasse, die Klassen c1 ... ck mit ihren Attributen und Methoden
beinhaltet. In dem reuse –Teil werden alle Klassen aufgeführt, von denen geerbt wurde.
Die structure ohne reuse –Teil wird als flache structure (englisch flat structure) bezeichnet.
3.1.2 Wiederverwendbarkeit von Klassen.
In dem reuse-Teil von einer Klassenstruktur befinden sich alle von der Klasse (structure sid)
verwendbaren Klassen. Die gleichnamige ref i - und ci -Klassen werden miteinander
verschmolzen.
Jede ref i -Klasse sieht folgendermaßen aus:
[dominating] sid i [where ∆ ci ,1 ... ∆ ci ,ki ∆ f i ,1 ∆ fi ,li ]
Das optionale Schlüsselwort dominating besagt, welche Klasse bei Kollisionen genommen
werden muss. Unter Kollisionen werden hier gleichnamige Methoden, Klassen, etc.
verstanden. ∆ ci , j und ∆ fi , j sind Klassen und Features, die eine Kollisionen hatten. Jede ∆ ci , j
sieht folgendermaßen aus:
[dominating] class cid j ,q [from cid ′j ,q ] ∆ f j ,q ,1 ... ∆ f j ,q ,l end
j ,q
wobei cid j ,q als neuer und cid ′j ,q als originaler Name bezeichnet wird.
Jede ∆ fi , j sieht so aus:
9[dominating] feature fid [from fid ′ ]
Eine konkrete Klasse kann auch einige Methoden enthalten, die in der abstrakten Klasse nicht
definiert sind.
3.1.3 Beispiel
Das Beispiel ist das Design Pattern Abstract Factory. Das Pattern wird dann benutzt, wenn
man eine Menge von Produkten hat, die Unterklassen von einer Oberklasse sind. Man
deklariert dann eine Oberklasse Factory und leitet alle anderen Klassen davon ab. Zum
Beispiel will man ein GUI in verschiedenen Looks & Feels implementieren. Die Looks &
Feels sollen jeweils eine Scrollleiste, ein Menu und einen Knopf(e) haben. Die folgenden vier
Abbildungen zeigen, wie man so eine Abstract Factory in PaL realisieren kann.
structure GUIFactory
GUIFactory creation make
class GUIFactory
creation make
GUIFactory feature createScrollBar() is …
feature createMenu() is …
+createScrollBar():
ScrollBar feature createButton() is …
+createMenu(): end
Menu
+createButton(): class MetalFactory inherit
Button GUIFactory
creation make
feature createScrollBar() is…
feature createMenu() is …
MetalFactory SpaceFactory feature createButton() is …
end
+createScrollBar(): +createScrollBar(): class SpaceFactory inherit
MetalScrollBar SpaceScrollBar
+createMenu(): +createMenu(): GUIFactory
MetalMenu SpaceMenu creation make
+createButton(): +createButton():
MetalButton SpaceButton feature createScrollBar() is …
feature createMenu() is …
feature createButton() is …
end
make
end
Abbildung 3: structure GUIFactory
10structure ScrollBar
creation make
ScrollBar class ScrollBar
creation make
ScrollBar …
end
class Metal ScrollBar inherit
ScrollBar
creation make
…
MetalSrollBar SpaceScrollBar
end
class Space ScrollBar inherit
ScrollBar
make creation make
…
end
end
Abbildung 4: structure ScrollBar
structure Menu
Menu creation make
class Menu
creation make
Menu …
end
class MetalMenu inherit
Menu
creation make
MetalMenu SpaceMenu …
end
class SpaceMenu inherit
make Menu
creation make
…
end
end
Abbildung 5: structure Menu
11structure Button
Button creation make
class Button
creation make
Button …
end
class MetalButton inherit
Button
creation make
MetallButton SpaceButton …
end
class SpaceButton inherit
make Button
creation make
…
end
end
Abbildung 6: structure Button
3.2 Visuelle Programmiersprache für Design Pattern (DPML)
Die Design Pattern Modelling Language (DPML) ist eine visuelle Design Pattern Sprache,
die es einem Designer erlaubt visuell zu modellieren. Die Sprache definiert ein Metamodell
und die Notation dazu. DPML kann als selbständige Modellierungssprache oder zusammen
mit UML benutzt werden. Der Kern der Sprache ist ein Design Pattern Spezifikationsmodell,
das für die Beschreibung allgemeiner Design Pattern Strukturen verwandt wird. Das Modell
erlaubt es Komponenten (englisch participants) und Beziehungen dazwischen zu definieren.
Das Modell erlaubt auch jede Patterninstanz anzupassen. Es wird zunächst ein Oberpattern
definiert, von dem Patterninstanzen gebildet werden können.
3.2.1 Bestandteile
Ein Oberpattern besteht aus: Interfaces, Implementierungen, Methoden, Operationen und
Attributen (sehe Abbildung 7). Ein Interface repräsentiert ein Objekt, das eine Architektur
deklariert. Eine Implementierung ist ein Objekt, das eine Architektur definiert oder
implementiert. Implementierungen können aber keine Interfaces definieren. Eine Operation
deklariert einen Teil der Architektur. Eine Methode definiert einen Teil der Architektur oder
einen Teil der Implementierung. Attribute definieren Teile der Implementierung. Einfache
Bedingungen werden in Prosa beschrieben. Diese Bedingungen binden Objekte an einfache
Participants. Es gibt in DPML auch doppelte gerichtete Beziehungen zwischen zwei
Participants. Es sind die folgenden Beziehungstypen definiert: implements, extends, realises,
declared in, defined in und refers to. Der komplexeste Beziehungstyp ist extends. Extends
definiert eine Abbildung zwischen zwei Participantobjektmengen. Es gibt vier verschiedene
Abbildungen: zwischen jedem möglichen Paar von Objekten (* zu *); zwischen genau einem
und allen anderen (1 zu *); zwischen jedem Objekt in einer Menge, aber nicht unbedingt in
der anderen Menge(n zu m) und zwischen nur einem Paar von Objekten (1 zu 1).
12Name
Name Name
Implementierung
Interface Attribut
Name
Name Name
Name
Methode Interface mit gerichtete Beziehungen Operation
Dimensionen
{ einfache Beziehungen }
Abbildung 7: grundlegende DMPL-Notation
3.2.2 Instanzbildung und Realisierung
Das Instanzdiagramm (englisch Instantiation Diagram) wird mit einem Objektmodell
aufgebaut. Jede Patterninstanz wird von einem Oberpattern gebildet. Die Instanzen können
numeriert werden. Dabei wird jeder Instanz ein eigener Identifikationsnamen und ein eigenes
Instanzdiagramm zugewiesen und mit verschiedenen Objekten im Objektmodell verbunden.
Das Instanzdiagramm ist ähnlich zum Spezifikationsdiagramm. Die Symbole haben dieselbe
Form, sind aber gestrichelt oder gefärbt (siehe Abbildung 8). Sie werden Proxy- Elemente
genannt. Das sind Elemente, die ihre Participants und Beziehungen von den grundlegenden
Elementen erben, folglich nicht änderbar sind. Sie können nur durch die ihnen zu Grunde
liegenden Elemente verändert werden. Jedes Participant (reell oder proxy) hat einen
gebundenen Verweis zu einigen UML- Elementen. Participants, die keine Dimension haben,
können nur mit einfachen UML- Elementen verbunden werden. Die Namen zu denen
Participants Verweise haben, sind zu jedem Participantsymbol in dem Instanzdiagramm als
kursiver Text angehängt.
13Name Name
gebundene gebundene
Elemente
Elemente Name
Interface Proxy Methode Proxy gerichtete Proxy- Beziehungen
{einfache Proxy- Beziehung}
Abbildung 8 Instanzdiagrammnotation
3.2.3 Beispiel
Die nächsten zwei Abbildungen repräsentieren das Beispiel aus Abbildungen 3,4,5 und 6
(Abstract Factory) in DPML.
Absract
Factory
Declared_In
Implements
createOps concreteFactories
Realises Defined_In
Return Type
concreteCreateOps
Creates
Products Implements concreteProducts
Abbildung 9:Spezifikation von Abstract Factory in DPML
14Absract
Factory
GUIFactory
Declared_In Implements
ConcreteFactories
CreateOps
MetallFactory
CreateMenu SpaceFactory
createScrollBar
createButton
Realises Defined_In
ConcreteCreateOps
6 bound elements
Rerurn Type
Creates
Products
Menu ConcreteProducts
ScrollBar Implements 6 bound elements
Button
Abbildung 10: Instanzzierung von Abstract Factory in DPML
3.3 Gemeinsamkeiten und Unterschiede
Um Gemeinsamkeiten und Unterschiede zwischen PaL und DPML festzustellen, werden an
dieser Stelle Abbildungen 3, 4, 5 und 6 für PaL und 9 und 10 für DPML verglichen. Diese
Abbildungen repräsentieren dasselbe Beispiel, das Design Pattern Abstract Factory. Die
beiden Sprachen benutzen Design Pattern zum Modellieren, in diesem Beispiel Abstract
Factory. Sowohl PaL als auch DPML unterstützen Patterninstanziierung. In PaL ist die
Instanziierung sowohl graphisch als durch Eiffelcode möglich. In DPML ist nur graphische
Instanzbildung möglich, weil diese Sprache nur visuelle Elemente zur Verfügung stellt. PaL
und DPML unterstützen Vererbung. In PaL ist es graphisch und in Code zu sehen, in DPML
ist es nur graphisch möglich. In DPML erben die Elemente aus Instanzdiagramm von den
Elementen aus dem Oberpattern. Aus den obengenannten Abbildungen (3, 4, 5 und 6 für PaL
und 9 und 10 für DPML) ist es nicht zu entnehmen, dass PaL eine formale Beschreibung hat
und DPML nicht. Das kann man sich aber an der Spezifikationen der Sprachen
veranschaulichen. Es ist nicht zu übersehen, dass PaL nahtlos in die Programmierungssprache
Eiffel integrierbar ist. Die Spezifikation von DPML zeigt, dass diese Sprache mit oder ohne
UML benutzt werden kann. In dem Beispiel für PaL (Abbildungen 3,4,5 und 6) sieht man,
dass diese Sprache keine Beziehungen hat. In DPML (Abbildungen 9 und 10) kann man
Beziehungen an beschrifteten Pfeilen erkennen. Man sieht, dass PaL keine abstrakte
Repräsentation von Design Pattern bieten, nur konkrete. Das Design Pattern Abstract Factory
wird sofort konkret als GUIFactory vorgestellt. Bei DPML dagegen wird in der Spezifikation
(Abbildung 9) erst das Gerüst geschaffen und danach in dem Instanzdiagramm (Abbildung
10) weiter verfeinert.
15Kapitel 4
Automatische Codegenerierung für Design Pattern.
Das von IBM entwickelte Tool generiert zu einem gegebenen Pattern Klassendeklarationen,
die ein Pattern in C++ implementieren. Die Implementierung ist 1:1 aus [2] übernommen. Das
Tool benutzt einen Browser, wo man Ergebnisse sehen und verschiedene Eingaben machen
kann. Wenn ein Pattern ausgewählt wird, können alle seine Bestandteile angezeigt werden. Es
können zu jedem Pattern auch bekannten trade-offs ausgewählt werden. Zum Beispiel für das
Design Pattern Composite kann die effiziente oder die saubere Variante gewählt werden.
4.1 Systemarchitektur.
Die Entwickler haben zwei Zieltypen verfolgt: Entwickler- und Benutzerziele.
Entwicklerziele:
1. schnelle Modifikation von Komponenten, weil das Tool neu und experimentell ist.
Deshalb müssen Autoren das Tool so schnell wie möglich modifizieren können.
Sie haben keine Zeit, um viel zu implementieren und zu testen.
2. hohe Flexibilität. Kleine Funktionalitätsänderungen bedeuten wenig
Implementierungsarbeit. Grosse Veränderungen müssen umfassbar sein, um zum
Beispiel bei Programmiersprachenänderung nicht das ganze Programm
umgeschrieben werden muss.
3. einfache Spezifikation. Automatische Codegenerierung kann sehr schwierig sein,
besonders wenn nur einen Teil von Ausdrücken in gebräuchlichen
Programmierungssprache beschrieben ist. Die Autoren wollten aber eine hohe
Spezifikationsebene von Codegeneration ohne Flexibilitätsbegrenzung erreichen.
Benutzerziele:
1. das Tool soll als Entwicklerhilfe dienen. Das Tool muss leicht zu benutzen sein
und die generierte Code muss einsatzbereit sein. Der Benutzer muss also wenige
Veränderungen machen, um die Code in seinem Programm einsetzen zu können.
2. integrierte Design Pattern Eigenschaften. Das gesamte Material über Design
Pattern kann man nicht bis auf kleinste Detail wiesen, deshalb ist das ganze Buch
[2] in das Tool integriert, damit man beim Benutzen nicht jedes Mal ins Buch
nachschauen muss.
3. Benutzerrückkopplung. Da dieses Tool experimentell ist, ist es wichtig die
Rückkopplung vom Benutzer zu erhalten. Die Benutzer können auf Schwächen
und Stärken des Tools hinweisen.
Die Architektur besteht im Wesentlichen aus drei Teilen:
1. Presenter implementiert Benutzeroberfläche (Browser)
2. Code Generator implementiert die Pattern
3. Mapper spezifiziert wie der Presenter und der Code Generator miteinander
kooperieren
16Für jede der drei Komponenten gibt es eine Description, die die vorgesehenen Aufgaben
erledigt. Die Architektur ist so ausgelegt, dass Autoren jeder Zeit Änderungen an einer
Komponente vornehmen können, ohne alle anderen zu „berühren“.
4.2 Implementierung.
Sobald der Benutzer eine Eingabe in Code Generation Seite macht, wird sie sofort zu
Mapper per CGI übermittelt (Mapper ist ein Perlinterpreter). COGENT- Interpreter (COde
GENeration Template), das Code Generator bedient, bekommt das Perlscript. COGENT ist
die von den Autoren entwickelte, Codegenerationsbeschreibungssprache. Die Trennung
erlaubt, dass Mapper und Code Generator sich auf einem Server befinden und Presenter auf
einem Client.
Presenter ist einfach das in HTML codierte [2]. Mapper hat zwei Funktionen: Verbindung
der Benutzerschnittstellekomponenten zu COGENT (Übersetzung nach COGENT) und
Verarbeitung der Benutzeraktionen.
17Kapitel 5 Fujaba [7], [8] Fujaba ist ein in Java geschriebenes Werkzeug, das unter anderem UML, Story-Driven Modelling und Design Pattern unterstützt. Das Hauptteil von Fujaba ist die Java- Codegenerierung aus UML -Diagrammen und Generierung der Designdiagrammen aus bestehendem Java-Quellcode, sogenanntes Roundtrip Engineering [7]. Dabei sollen die Änderungen, die im Quellcode vorgenommen wurden, erkannt werden und sich im Design wiederspiegeln. Durch die Generierung wird zum einen der Programmieraufwand verringert und zum anderen wird auch die Konsistenz zwischen Spezifikation und Quellcode sichergestellt. Fujaba unterstützt Design Pattern im Forward- und Reengineering. Im Forward-Engineering Teil werden vier Design Pattern unterstützt. Im Reengineering Teil werden sieben Design Pattern aus [2] und andere Hilfspattern unterstützt. Die Design Pattern- Erkennung wird durch Maschinen, die jeweils für ein Pattern verantwortlich sind, umgesetzt. Um mit diesen Maschinen zu arbeiten, muss man wissen wie die interne Fujaba Struktur aufgebaut ist. Es ist erforderlich in Quellcode von Fujaba zu arbeiten. Es gibt hier keine Übersicht über die Abhängigkeit von Pattern untereinander. Dafür muss man sich auch den Code anschauen. Es gibt in Fujaba die Möglichkeit, bestehende Pattern bei einer neuen Definition zu verwenden, da bei gefundenen Pattern sogenannte Annotationen erzeugt werden, die an die Bestandsteile des Pattern angehängt werden und diese wiederum auffindbar sind. Die Design Pattern-Erkennung in Fujaba erfolgt auf dem UML-AST. Der UML-AST ist der abstrakter Syntaxbaum durch den alle UML- und Story-Diagramme und deren Sprachkonstrukte repräsentiert werden. Der UML-AST enthält alle Diagramme und Diagrammelemente. Dabei wird das Metamodell der UML adaptiert. Für die Erkennung ist die Klasse DPMasterEngine zuständig, die alle Aktionen steuert. Bei dieser Klassen müssen sich alle Design Pattern Maschinen anmelden. Die Erkennung von Design Pattern nach [2] erfolgt hauptsächlich auf einem Klassendiagramm, welches ein Objekt von einer Klasse des UML-AST ist. Hier werden für ein Design Pattern relevanten Objekte aus UML-AST im Diagramm gesucht und verglichen. Sobald alle relevanten Bestandsteile eines Patterns gefunden sind, wird eine Annotation erzeugt und mit gefundenem Bestandsteilen verbunden. Genaue Beschreibung des Vorgangs der Pattern-Erkennung, Beispiele und Programmaufbau findet man in [8] und in [7]. 18
Literatur
1. Prof. Dr. W. Schäfer Vorlesungsfolien „Entwurfsmuster“ WS 2000/2001
http://www.upb.de/fachbereich/AG/schaefer/ag_dt/SoftwareDesign/softwaredesign.html
2. E. Gamma, R. Helm, R. Johnson and J. Vlissides, “Design Pattern: Elements of
Reusable Object-Oriented Sofware”, Addison- Wesley Publishing Co., Reading,
MA (1995)
3. F.J Budinsky, M.A. Finnie, J.M. Vlissides and P.S. Yu “Automatic code
generation from design patterns”, IBM Systems Journal, 35(2), 1996
4. S. Bünning, P. Forbrig, T. Lämmel, N. Seemann „A Programming Language for
Design Patterns“. Universität Rostock, Fachbereich Informatik, D-18051 Rostock
5. D. Maplesden, J.Hosking and J. Grundy „A Visual Language for Design Pattern
Modelling and Instantion“. Department of Computer Science, University of
Auckland, Private Bag 92019 Auckland, New Zealand.
6. Design Pattern Home http://hillside.net/patterns/patterns.html
7. M. Palasdies “Design Pattern Spezifikation und Erkennung auf Basis von Story-
Diagrammen“, Diplomarbeit, Universität Paderborn, Paderborn, Mai 2001.
8. T. Fischer, J. Niere und L. Torunski „ Konzeption und Realisierung einer
integrierten Entwicklungsumgebung für UML, Java und Story-Driven-Modelling“,
Diplomarbeit, Universität Paderborn, Paderborn, Juli 1998.
9. L.M. Wills, “Automated program recognition by graph parsing”. PhD thesis, MIT,
Cambridge, Mass., 1992
10. C. Ghezzi, M. Jazayeri, D. Mandrioli „ Fundamentals of Software Engineering”,
Prentice Hall, 1991
11. W. Cunningham, K. Beck “Constracting Abstractions for Object-Oriented
Applications”. CR-87-25, Computer Research Laboratory, Tektronix, Inc.
19Sie können auch lesen
