Case Tools Unterstützung für Design Pattern - Universität Paderborn

Die Seite wird erstellt Georg Neubauer
 
WEITER LESEN
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