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 2001
Inhaltsverzeichnis 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 2
Kapitel 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 3
Architekten 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. 4
In 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. 5
Kapitel 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. 8
Kapitel 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 10
structure 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 11
structure 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). 12
Name 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. 13
Name 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 14
Absract 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. 15
Kapitel 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 16
Fü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. 17
Kapitel 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. 19
Sie können auch lesen