Unterstützung modellgetriebenerEntwicklungsprozesse - Fujaba

Sven Kulle242 913

Betreut von Dipl.-Inf. Ulrike Ranger

Zusammenfassung

Diese Seminararbeit beschreibt die visuelle Programmierung mit dem CASE-Werkzeug Fujaba. In Fujaba können Softwarearchitekturen und deren Imple-mentierungen entworfen werden. Die Entwicklung findet zum Großteil auf vi-suelle Weise statt, wozu dem Entwickler unterschiedliche UML-Diagrammezur Verfügung stehen. In einem weiteren Schritt kann der Entwickler aus denspezifizierten Diagrammen mittels Fujaba Java Quellcode erzeugen. Es ist wei-terhin möglich, Fujaba durch Plugins zu erweitern. Diese Arbeit stellt einKomponenten-Plugin für Fujaba vor. Das Komponentendiagramm des Plug-ins stellt einzelne Komponenten, ihre Schnittstellen und die Abhängigkeitenzwischen den Schnittstellen dar.

Inhaltsverzeichnis

1 Motivation 8-3

2 Komponenten 8-4

2.1 Ziel der komponentenbasierten Softwareentwicklung . . . . . . 8-5

2.2 Anforderungen und Eigenschaften von Softwarekomponenten . 8-5

2.3 Komponentenmodelle . . . . . . . . . . . . . . . . . . . . . . . 8-7

3 Beispielszenario 8-8

4 Fujaba 8-9

4.1 Klassendiagramme . . . . . . . . . . . . . . . . . . . . . . . . 8-11

4.2 Aktivitätsdiagramme . . . . . . . . . . . . . . . . . . . . . . . 8-13

4.3 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17

4.4 Weitere Diagramme und Funktionalitäten . . . . . . . . . . . . 8-19

5 Spezifikation von Komponenten 8-20

5.1 Spezifikation und Verwendung von Komponenten . . . . . . . . 8-20

5.2 Fujaba und das JavaBean Modell . . . . . . . . . . . . . . . . . 8-22

6 Zusammenfassung 8-23

1 MOTIVATION 8 – Fujaba

1 Motivation

Fujaba ist ein CASE-Werkzeug. “Computer-Aided-Software-Engineering“-Werk-zeuge unterstützen den Softwareentwicklungsprozeß vor allem in der Entwick-lungsphaseEntwurf. Der Entwickler kann zur Spezifizierung der Softwarear-chitektur und ggf. zur Spezifizierung der Implementierung auf visuelle Nota-tionsmöglichkeiten des CASE-Werkzeugs zurückgreifen. Meist nutzen CASE-Werkzeuge UML-Diagramme zur Modellierung des Softwaresystems, einige nut-zen aber auch SA/SD bzw. ERM/SERM. Einige CASE-Werkzeuge können nichtnur zur Spezifizierung des Softwaresystems genutzt werden. Sie bieten die Mög-lichkeit, aus der Spezifizierung des Softwaresystems Quellcode zu generieren. Ei-ne Übersicht über gängige CASE-Werkzeuge und deren Notationen findet sich in[15].

Visuelle Programmierung, d.h. Quellcode aus visuell erstellten Diagrammen zugenerieren, ist bei einfachen oder sehr spezifischen Anwendungen eine echteAlternative zur textuellen Programmierung. Die visuelle Programmierung bie-tet verschiedene Vorteile, z.B. abstrahiert sie von einer konkreten Programmier-sprache wie C++ oder Java. Anhand der verschiedenen Diagramme eines CASE-Werkzeugs, kann sich der Entwickler relativ schnell und leicht einen Überblicküber das Softwaresystem verschaffen. Weiterhin läßt sich beispielsweise UMLals visuelle Programmiersprache leichter erlernen als textuelle Programmierspra-chen. So sind auch nicht Fachleute in der Lage, mit Hilfe von ausdrucksstarkenvisuellen Modellierungssprachen Software bzw. Teile eines Softwaresystems zuverstehen und zu entwickeln.

Fujaba unterstützt den Entwickler sowohl bei dem Entwurf der Softwarearchitek-tur als auch bei dessen Implementierung. Es nutzt zur Modellierung der Struk-tur und des Verhaltens der Software UML-Diagramme. In einem weiteren Schrittkann Fujaba aus diesen Diagrammen Java Quellcode erzeugen. Es lässt sich inso-fern in das SeminarthemaUnterstützung modellgetriebener Entwicklungsprozes-seeinordnen, da die Software nicht mit einer herkömmlichen Programmierspra-che, wie z.B. Java sondern aus einem Modell (UML-Diagramme) heraus gene-riert wird. Die automatische Generierung der Software aus UML-Diagrammen hatnach [14] den Vorteil, daß bei fehlerfreier Quellcode-Generierung die Korrektheitder Implementierung in Hinsicht auf die Spezifikation garantiert werden kann. Fu-jaba kann durch Plugins [3] erweitert werden. DasRealtimeStatechartPlugin derFujaba Real-Time Tool Suite[3] stellt ein RealtimeStatechart-Diagramm bereit.Die Fujaba Tool Suite Reverse Engineering[3] besitzt ein Plugin zur Spezifizie-rung vondesign patterns. Ein Plugin für die Darstellung von Softwarekomponen-ten (Komponentendiagramm) wird in dieser Arbeit vorgestellt.

8-3

8 – Fujaba 2 KOMPONENTEN

In der heutigen Softwareentwicklung werden häufig Softwarekomponenten ent-wickelt und eingesetzt [7]. Softwarekomponenten sind wiederverwendbare Soft-warebausteine bzw. Teile einer Software, die eine gewisse Funktionalität anbieten.Softwarekomponenten werden häufig durch UML-Komponenten-Diagramme vi-suell dargestellt. Weiterhin gibt es visuelle Entwicklungswerkzeuge, wie denBe-an Builder[9], die die Entwicklung von Softwaresysteme durch Kombination undVerbindung von Instanzen von Softwarekomponenten ermöglichen. Die Entwick-lung findet ausschließlich visuell statt. Soweit Softwarekomponenten die Angabevon Eigenschaftsparametern erlauben, kann die Funktionalität bzw. das Verhal-ten der Komponente verfeinert und den Wünschen des Nutzers angepasst werden.Benutzer eines Softwaresystems können durch die Eigenschaftsparameter einerSchaltflächen-Softwarekomponente beispielsweise die Farbe der Schaltfläche ih-ren Vorstellungen anpassen. Ein Beispiel zur Erstellung eines komplexen Softwa-resystems mittels Softwarekomponenten findet sich in [1]. In diesem Beispiel wirdeine Softwarekomponente entwickelt, die die Ergebnisse eines Meßinstrumentesauf dem PC visuell darstellt. Die Softwarekomponente in diesem Beispiel bestehtausschließlich aus der visuellen Repräsentation der gemessen Daten, d.h. der ei-gentliche Meßvorgang findet nicht in dieser Softwarekomponente statt. Softwa-rekomponenten abstrahieren noch einmal von Programmiersprachen im üblichenSinn, da der Zugriff auf die gekapselten Funktionen nur über eine Schnittstellemöglich ist. Sie wirken sich vereinfachend auf den Entwicklungsprozeß aus.

Diese Seminararbeit beschreibt die Erstellung eines Softwaresystems mit demCASE-Werkzeug Fujaba. In der Diplomarbeit [14] wurde ein Plugin zur Spezi-fizierung von Softwarekomponenten entwickelt, welches in 5.1 vorgestellt wird.

Die Arbeit gliedert sich wie folgt: Kapitel 2 ist eine Einführung in Softwarekom-ponenten. Kapitel 3 beschreibt das Beispielszenario dieser Arbeit. Es handelt sichhierbei um ein Mancala-Spiel. Kapitel 4 stellt die Entwicklung einer Softwarear-chitektur und deren Implementierung mit dem CASE-Werkzeug Fujaba vor. Bei-spiele und Erläuterungen dieses Kapitels beziehen sich auf das Beispielszenario.Das Kapitel 5 beschäftigt sich mit der Spezifizierung von Softwarekomponentenin Fujaba. In Kapitel 6 werden die wichtigsten Aspekte der Seminararbeit zusam-mengefasst.

2 Komponenten

Dieses Kapitel erläutert den Begriff der Softwarekomponenten. Es werden ver-schiedene Definitionen für Softwarekomponenten vorgestellt, sowie als Beispieldas JavaBeans-Komponentenmodell erläutert.

8-4

2.1 Ziel der komponentenbasierten Softwareentwicklung 8 – Fujaba

2.1 Ziel der komponentenbasierten Softwareentwicklung

[1] vergleicht Softwarekomponenten mit Halbfabrikaten aus der industriellen Pro-duktion. Dort ist es üblich, Halbfabrikate bzw. Zwischenprodukte von verschiede-nen Herstellern zu beziehen und in einem eigenen Produktionsschritt zusammenzu setzen. Dies kann aus mehreren Gründen von Vorteil sein. Beispielsweise kanndie eigene Entwicklung und Produktion eines Halbfabrikats extrem aufwendigund kostenintensiv sein, so daß sich der Einkauf von einem spezialisierten Her-steller lohnt.

Übertragen auf die Softwareentwicklung bedeutet dies, daß Softwaresystememit Hilfe von vorgefertigten Softwarebausteinen bzw. Softwarekomponenten ent-wickelt werden können. Die Komponenten können wie Halbfabrikate von spe-zialisierten Softwareunternehmen eingekauft und genutzt werden. Für die Soft-wareentwicklung bringt dies eine erhebliche Verbesserung in Bezug auf dieEnt-wicklungszeitund -kosten, sowie dieWiederverwendungvon Softwareteilen. DieFunktionalität von eingekauften oder vorhandenen Komponenten muß nicht neuentworfen und entwickelt werden. Komponenten lösen ein spezielles Problem.Existiert eine Lösung, so muß für das selbe Problem in einem anderen Software-system die Lösung nicht nochmal gefunden werden. Der Entwickler kann auf diebereits vorhandene Komponente zurückgreifen. Ein weiterer Vorteil der Software-komponenten liegt in deren Austauschbarkeit. Nutzt ein Softwareentwickler einebestimmte Komponente, so kann er diese durch eine Komponente eines anderenHerstellers austauschen, sofern diese die selbe Grundfunktionalität und Schnitt-stelle bietet. Die leichte Austauschbarkeit von Komponenten wird durch Schnitt-stellen erreicht. Schnittstellen abstrahieren von der Realisierung einer Komponen-te und definieren eindeutig den Zugriff auf die Funktionalität der Komponente.

2.2 Anforderungen und Eigenschaften von Softwarekompo-nenten

Obwohl das Ziel der komponentenbasierten Softwareentwicklung eindeutig ist,existiert für den Begriff der Softwarekomponenten keine eindeutige Definition.[1] versteht unter einer Komponente folgendes:

„[...] eine Komponente (component) ist ein abgeschlossener, bi-närer Software-Baustein, der eine anwendungsorientierte, semanti-sche zusammengehörende Funktionalität besitzt, die nach außen überSchnittstellen zur Verfügung gestellt wird. Beim Entwurf [...] wurdeauf hohe Wiederverwendung Wert gelegt.“

8-5

8 – Fujaba 2 KOMPONENTEN

Im Vergleich dazu definiert [13] Softwarekomponenten folgendermaßen:

„A software component is a unit of composition with contractuallyspecified interfaces and explicit context dependencies only. A softwa-re component can be deployed independently and is subject to com-position by third parties.“

Es lassen sich noch eine Reihe weiterer Definitionen für Softwarekomponentenfinden. Es ist festzuhalten, daß die Definitionen für Softwarekomponenten eherallgemeinen Charakter haben. Der interne Aufbau von Komponenten ist nicht fest-gelegt. Die wesentlichen Aspekte der Definitionen können wie folgt zusammen-gefasst werden: Softwarekomponenten stellen kein Softwaresystem für sich dar,sie sind viel mehr als Teilsystem zu betrachten. Komponenten bilden Lösungenfür spezielle Probleme und stellen wesentlich mehr Funktionalität zur Verfügungals eine Klasse aus der OO-Programmierung. In komplexen Softwaresystemenmüssen häufig Probleme gelöst werden, für die bereits Lösungen in Form vonunterschiedlichen Softwarekomponenten existieren.

Weiterhin ist die Kombination d.h. Komposition von Komponenten möglich.Komponenten werden i.d.R. nicht alleine genutzt, sondern in einer Komponen-tenumgebung betrieben. Das heißt, daß Softwaresysteme nicht nur eine einzi-ge Softwarekomponente benutzen, sondern meist mehrere Softwarekomponenten.Softwarekomponenten können untereinander Abhängigkeiten besitzen. Beispiels-weise kann zur Ausführung einer Softwarekomponente A eine Softwarekompo-nente B benötigt werden. Der Schnittstellenbegriff ist ein wichtiger Aspekt in Be-zug auf Komponenten. Sämtliche Funktionalität einer Komponente wird über eineExportschnittstelle gekapselt und anderen Komponenten zur Verfügung gestellt.Ein Aufruf einer Methode, die nicht in der Exportschnittstelle der Komponen-te aufgeführt wird, ist nicht möglich. Auch das Erweitern einer Komponente istnicht möglich. Komponenten sind alsBlackboxaufzufassen, deren Implementie-rung dem Benutzer verborgen bleibt.

Der Aspekt der Verteilung, also eine verteilte Anwendung die auf mehreren Rech-nern oder Prozessoren läuft, ist auch bei dem Entwurf und der Nutzung von Kom-ponenten wichtig. Es gibt heute viele Anwendungsteile die nicht zentral auf ei-nem Rechner laufen, sondern z.B. über das Internet verteilt auf anderen Rechnernbetrieben werden. Soll eine verteilte Anwendung bestehend aus Softwarekompo-nente entwickelt werden, so müssen Softwarekomponenten entsprechende Me-chanismen bereitstellen, so daß sie miteinander kommunizieren können. Durchdie Kapselung der Funktionalität und den Begriff der Schnittstelle werden dieKomponenten zu unabhängigen Softwarebausteinen, die relativ unkompliziert alsTeilsystem genutzt werden können.

8-6

2.3 Komponentenmodelle 8 – Fujaba

2.3 Komponentenmodelle

Aus dem Aspekt der Verteilung können zwei unterschiedliche Arten von Kompo-nentenmodellen abgeleitet werden. Zum einen gibt es Komponentenmodelle, dieKonzepte wie Persistenz, Nebenläufigkeit und Verteilung umsetzen und dem Ent-wickler entsprechende Unterstützung bieten. Komponentenmodelle die sich fürdie genannten Aspekte anbieten sind:

• COM+ von Microsoft [5]

• Enterprise JavaBeans von Sun [10]

• CORBA-Modell der OMG [6]

Nutzt ein Entwickler solch ein Komponentenmodell und entwickelt eine verteil-te Software, so kann er sich rein auf die Anwendungslogik konzentrieren undbraucht nicht selbst die genannten Konzepte zu implementieren.

Zum anderen gibt es Komponentenmodelle, die die oben genannten Konzeptenicht umsetzen. Diese Modelle sind von ihrem Aufbau her einfacher und eignensich für den Entwurf von Software, die nur auf einem Rechner betrieben wird. Esbieten sich folgende Komponentenmodelle an:

• JavaBeans von Sun [11]

• COM/ActiveX von Microsoft [5]

Als Beispiel wird hier das JavaBean-Modell als ein einfaches Komponentenmo-dell vorgestellt. Sun definiert JavaBeans wie folgt:

„A Java Bean is a reusable software component that can be manipu-lated visually in a builder tool.“ [12]

JavaBeans sind wiederverwendbare Softwarebausteine, die in einem Werkzeugvisuell miteinander kombiniert werden können, um Softwaresysteme zu entwer-fen. Damit das JavaBean-Modell die obige Definition optimal unterstützen kann,müssen einige Regeln beachtet werden. So wird z.B. die Exportschnittstelle derJavaBeans, die über die Funktionalität und die Eigenschaften sowie Ereignisseder JavaBean Auskunft gibt, lediglich durch Namenskonventionen erstellt. Aufder Homepage [11] kann nachgelesen werden, inwiefern die Namenskonventi-on beachtet werden muß. Als Beispiel sei hier erwähnt, daß für private Attribute

8-7

8 – Fujaba 3 BEISPIELSZENARIO

einer Klasse eineget- und set-Methode implementiert werden muß. Durch Ein-halten der Namenskonventionen können Entwicklungswerkzeuge Auskunft überdie JavaBean erhalten. Dazu durchsuchen sie die Java Klassen der Softwarekom-ponente nach Methoden und Attributen. Öffentliche Methoden werden beispiels-weise durch das Entwicklungswerkzeug erkannt und dem Benutzer der Softwa-rekomponente zur Verfügung gestellt. Nicht öffentliche Methoden bleiben demBenutzer hingegen verborgen. Andere Komponentenmodelle nutzen hierfür eineSchnittstellenbeschreibungssprache (interface definition language) und erzeugeneine Schnittstellendatei, über die Entwicklungswerkzeuge und Entwickler an diegewünschten Informationen gelangen. Die Fähigkeit der JavaBeans Informatio-nen nach Außen zu geben wird alsIntrospektionbezeichnet.

Neben der Introspektion bieten JavaBeans auch die Möglichkeit an, nachträglicheAnpassungen vorzunehmen. Beispielsweise können einfache Eigenschaften wieBalkenfarbe oder Beschriftung einer Schaltfläche in einem gewissen Rahmen vomNutzer der Softwarekomponente geändert werden. Neben diesen einfachen Ei-genschaften unterstützen JavaBeans noch indizierte Eigenschaften, gebundene Ei-genschaften und Eigenschaften mit Nebenbedingungen. Gebundene Eigenschaf-ten werden genutzt, um mit Hilfe desObserver-Patternsexternen BeobachternÄnderungen von Attributwerten mitzuteilen. Am Beispiel des Meßinstrumentesaus Kapitel 1 bedeutet dies, daß die Softwarekomponente zur visuellen Reprä-sentation von Meßdaten sich als Beobachter (Observer) bei dem Meßinstrumentanmelden kann. Sobald das Meßinstrument neue Messungen vornimmt kann esdie Ergebnisse seinenObservernmitteilen. DieObserverwerden so automatischüber Neuerungen informiert. Bei Eigenschaften mit Nebenbedingung können dieObserverein Veto einlegen und so die Änderung der Eigenschaft verhindern. In-dizierte Eigenschaften sind zusammengesetzte Datentypen, wie z.B.ListenoderArrays. In solchen Datenstrukturen werden mehrere Werte in einer Eigenschaftgespeichert. Der Zugriff auf einzelne Daten erfolgt über einen Index.

3 Beispielszenario

Das Beispielszenario dieser Arbeit basiert auf einem Fujaba Tutorial, das auf derInternetseite [2] zur Verfügung steht. Das Tutorial beschreibt die Entwicklung ei-nes Mancala Spiels mit Fujaba. Bei dem Spiel handelt es sich um ein einfachesBrettspiel, das von zwei Spielern gespielt wird. Die genauen Regeln und der Auf-bau des Spiels können aus dem Tutorial entnommen werden. Die Entwicklung desSpiels mit Fujaba ist auf Grund des einfachen Spielprinzips leicht.

8-8

4 FUJABA 8 – Fujaba

Abbildung 1: Spielaufbau

Das Spiel läßt sich wie folgt beschreiben: Jeder der beiden Spieler hat vor sichsechs normale Spielsteinbehälter stehen. Rechts von diesen sechs Behältern be-findet sich der siebte Spielsteinbehälter, es ist der sog. Kalaha Behälter. In jedemder sechs normalen Behälter befinden sich zu Beginn des Spiels jeweils sechsSpielsteine. Der Spieler, der den ersten Zug macht, wählt einen beliebigen ei-genen Spielsteinbehälter, außer dem Kalaha Behälter, und nimmt alle Spielsteineheraus. Danach verteilt er sie jeweils einzeln der Reihe nach rechts auf die anderenBehälter inklusive seines Kalaha Behälters, jedoch nicht in den Kalaha Behälterdes Gegners. Wird der letzte Spielstein in einen seiner eigenen Behälter gelegt, soist der Spieler nochmal an der Reihe. Ist der Behälter zusätzlich leer, so wird derSpielstein aus diesem Behälter und alle Spielsteine aus dem gegenüberliegendenBehälter des Spielgegners in den eigenen Kalaha Behälter gelegt. Das Spiel endet,wenn ein Spieler keine Spielsteine mehr in seinen Behältern, außer dem KalahaBehälter, hat und somit keinen Spielzug machen kann. Sieger ist der Spieler, deram meisten Spielsteine in seinem Kalaha Behälter hat.

4 Fujaba

Das Akronym Fujaba steht für „From Uml to JavaAnd BackAgain“. Fujaba istein CASE-Werkzeug das Entwickler während des Softwareentwicklungsprozes-ses unterstützt. Der Entwickler kann u.a. die Softwarearchitektur und deren Imple-mentierung mit UML Klassendiagrammen und den Fujaba Aktivitätsdiagrammenspezifizieren, die eine Kombination aus UML Kollaborations- und Aktivitätsdia-grammen darstellen. Fujaba kann anhand dieser Spezifikationen Java Quellcodegenerieren.

Fujaba wird von der „Fujaba Development Group“ der Universität Paderborn inZusammenarbeit mit anderen Universitäten entwickelt. Nach [4] wurde die ur-sprüngliche Implementierung 1997 von drei Studenten in einer gemeinsamen Di-plomarbeit begonnen. Fujaba ist in der Programmiersprache Java geschrieben und

8-9

8 – Fujaba 4 FUJABA

Abbildung 2: Fujaba - Oberfläche

somit plattformunabhängig. Auf [3] steht Fujaba zum Download bereit. Außer-dem findet sich dort weitere Literatur zu Fujaba.

Fujaba basiert intern auf Graphtransformationssystemen. Das Datenmodell, beste-hend aus Klassen und Assoziationen, stellt ein Typsystem eines Graphen dar. Fu-jaba kann auf diesen Graphen (Instanz des Modells) Transformationen ausführen,um Änderungen an der Objektstruktur vorzunehmen. Durch Graphtransformatio-nen können so auch Objekte zur Laufzeit erzeugt oder gelöscht werden. Fujabanutzt Graphen, da diese sich besonders gut zur Darstellung der Objektstruktur ei-genen. Durch die eindeutige Semantik lassen sich Änderungen gut modellieren.Auch die Quellcode-Generierung wird durch die eindeutige Graphsemantik er-möglicht. Weiterhin wird daran gearbeitet, daß Fujaba UML Diagramme aus JavaQuellcode generieren kann [16].

Die Oberfläche von Fujaba sieht wie in Abbildung 2 aus. Im oberen Bereich be-findet sich eine Menü- und Symbolleiste, über die alle Funktionen von Fujabaerreicht werden.1© zeigt die Editorfläche, in der alle Eingaben zum Erstellenvon Diagrammen vorgenommen werden. Die Bedienung von Fujaba findet zumgroßen Teil auf visuelle Weise statt. Auf der linken Seite der Editorfläche werdenVerknüpfungen zu den meist genutzten Funktionen dargestellt. Diese sind jeweilsvon der gewählten Diagrammart abhängig.2© stellt die vom Entwickler erstell-

8-10

4.1 Klassendiagramme 8 – Fujaba

ten Diagramme in einer Übersicht dar. Der Entwickler kann sich so schnell einenÜberblick über seine erstellten Diagramme verschaffen. Wählt er ein Diagrammin dieser Übersicht aus, so wird dieses auf der Editorfläche dargestellt.

In den nächsten beiden Abschnitten werden die wichtigsten Merkmale vonKlassen- und Aktivitätsdiagrammen und deren Erstellung mit Fujaba erläutert.

4.1 Klassendiagramme

Mit Fujaba Klassendiagrammen, wie in Abbildung 3, wird die statische Struktur,d.h. die Architektur eines Softwaresystems dargestellt. Fujaba Klassendiagram-me entsprechen den UML Klassendiagrammen. Klassendiagramme bestehen ausKlassenundAssoziationen. Klassen werden, wie in der UML üblich, durch Recht-ecke dargestellt. Sie sind in drei Abschnitte unterteilt. Im oberen Abschnitt stehtder Klassenname und die Stereotypen. Im mittleren Abschnitt werden die Klas-senattribute festgelegt. Im unteren Abschnitt werden die Methoden der Klasseaufgelistet. Die Sichtbarkeiten der Klassenattribute und Methoden werden durchandere Symbole als in der UML üblich dargestellt.

Entwickler können zur Definition von Attributen nicht nur deren Datentyp undSichtbarkeiten festlegen, sondern auch mit welchem Anfangswert diese initiali-siert werden. Percheckboxkann der Entwickler auswählen, ob bei einer späterenCodegenerierungget- bzw. set-Methoden für das Attribut automatisch angelegtwerden sollen. Weiterhin kann ein Attribut alsfinal, staticund transientmarkiertwerden.Final Attribute sind Wertkonstanten und können zur Laufzeit nicht ge-ändert werden. Attribute, die alsstaticmarkiert sind, sind für alle Objekte dieserKlasse gleich.Transientbedeutet, daß diese Attribute beim serialisieren nicht be-achtet werden. Sie werden also nicht persistent gespeichert.

Zur Spezifizierung der Methodensignatur kann der Entwickler neben der Sicht-barkeit und dem Rückgabetyp auch eine Liste von Parametern angeben. Metho-den können ebenfalls mit einer zusätzlichen Information, wie z.B.final, versehenwerden. Auch hier ist die Bedeutung dieser zusätzlichen Informationen wie beiden Attributen zu verstehen.

Beispielhaft ist die Klasse zur Modellierung des Spielfeldes in Abbildung 3 dar-gestellt. In dieser Klasse sind die beiden AttributebeginnerNrund turn angelegt.Das AttributbeginnerNrgibt den Spieler an, der den ersten Spielzug machen darf.turn zählt die gespielten Runden. Beide Attribute sind vom TypIntegerund besit-zen die Sichtbarkeitpublic.

8-11

8 – Fujaba 4 FUJABA

Abbildung 3: Darstellung der Klasse Board

Zur Prüfung, ob der letzte Spielstein in einen leeren Behälter gelegt wurde undsomit alle Spielsteine des entsprechenden Behälters des Spielgegners eingenom-men werden dürfen, dient die MethodecheckAndDoPitCapture(). Die MethodeisFinished()prüft, ob das Spiel beendet ist. Der Rückgabewert der Methode isteinBooleanWert.checkAndDoPitCaptureist eine Hilfsmethode, sie ist daher mitder Sichtbarkeitprivateversehen.makeMove(pitId:Integer)führt einen Spielzugaus, dazu wird ihr als Parameter der gewählte Spielsteinbehälter übergeben.setup-Board(numberOfPits:Integer, numberOfBeans:Integer)initialisiert das Spielfeld.Die Anzahl der Spielsteine pro Spielsteinbehälter und die Anzahl der Spielstein-behälter werden als Parameter übergeben. Alle Methoden bis aufcheckAndDoPit-Capturebesitzen die Sichtbarkeitpublic.

Neben der Generalisierung bzw. Spezialisierung einer Klasse kann zwischen zweiKlassen auch eine Assoziation bestehen. In Abbildung 4 existiert eine Generalisie-rung zwischen der KlassePlayerPitund der KlassePit. Allgemein beschreibt eineAssoziation eine Verbindung zwischen zwei Klassen. Diese kann unterschiedlicheAusprägungen haben. Es gibt einfache (gerichtete/ungerichtete) Assoziationen so-wie die aus der UML bekannte Aggregation und Komposition. DieAggregationund Kompositiondrücken eineTeile-Ganzes-Beziehung aus. Bei der Aggregati-on existieren dieTeileauch unabhängig vomGanzen. Die Komposition hingegenbedeutet, das dieTeilenur solange existieren, wie auch dasGanzeexistiert. Nach[4] setzt Fujaba allerdings Kompositionen bei der Codegenerierung als einfacheAssoziation um.

Assoziationen können genauer spezifiziert werden, u.a. mit Kardinalitäten, Rol-lennamen und Bedingungen. Bedingungen drücken eine bestimmte Ordnung aufassoziierten Instanzen aus. Die Bedingungordereddrückt z.B. aus, daß es ein er-stes und ein letztes Element gibt. Bezüglich der Kardinalitäten von Assoziationensagt [4] weiter: „In Fujaba findet keine Überprüfung statt, ob die Kardinalitätenzur Laufzeit verletzt werden, das heißt mehr Instanzen assoziiert werden als in derKardinalität angegeben.In Abbildung 4 existiert eine Kompositionsbeziehung zwischen einem Spielstein

8-12

4.2 Aktivitätsdiagramme 8 – Fujaba

Abbildung 4: in pit-Kompositionsbeziehung zwischenPit-Klasse undBean-Klasse

(Bean) und einem Behälter für Spielsteine (pit). Die Kompositionsbeziehung istan der ausgefüllten Raute der Verbindung zu erkennen. An den jeweiligen Endender Assoziation sind Kardinalitäten angegeben. Die Assoziation drückt also dieBeziehung zwischen Spielsteinbehältern und Spielsteinen aus. Einem Spielstein-behälter können beliebig viele (0..n) Spielsteine zugeordnet werden. Die Kompo-sition drückt weiterhin aus, daß durch löschen einesPit-Objektes alle assoziiertenBean-Objekte auch gelöscht werden.

Das komplette Klassendiagramm des Beispielszenarios enthält neben einigen wei-teren Kompositionen einfache Assoziationen, Implementierungen (Einbindungvon interfaces) und die Generalisierungen. Dasinterface MancalaServerRemo-te besitzt die beiden Stereotypen«interface»und«RemoteInterface»sowie einenKommentar. Stereotypen beschreiben den Verwendungszweck der Klasse.«inter-face»drückt beispielsweise aus, das es sich bei dieser Klasse um ein Interfacehandelt.StaticMethoden werden in Fujaba durch einen unterstrichenen Metho-dennamen dargestellt.

4.2 Aktivitätsdiagramme

Klassendiagramme dienen zur Spezifizierung der statischen Struktur eines Soft-waresystems. Methoden werden in diesem Diagramm nur durch ihre Signatur de-finiert. Eine genaue Spezifizierung findet mit den Fujaba Aktivitätsdiagrammenstatt. Sie sind nach [4] eine Mischung aus UML Aktivitätsdiagrammen und UMLKollaborationsdiagrammen und beschreiben die Dynamik eines Softwaresystems.

4.2.1 Kontrollfluß von Methoden

Zur Beschreibung des Kontrollflusses einer Methode stehen dem Entwickler sog.Aktivitäten zur Verfügung, die er durch Transitionen verbindet. Aktivitäten kön-nen z.B.story patterns, vgl. Abschnitt 4.2.2 oderstatementAktivitäten sein. Wäh-rendstory patternsTransformationen auf dem Datenmodell visuell modellieren,wird in statementAktivitäten expliziter Java Quellcode festgehalten. Der Kon-

8-13

8 – Fujaba 4 FUJABA

Abbildung 5: Klassendiagramm des Beispielszenarios

trollfluß beginnt in einem eindeutig festgelegten Startknoten und endet in einemEndknoten. Endknoten können beliebig oft vorkommen. In Fujaba können Tran-sitionen mit Bedingungen versehen werden. Die folgende Liste gibt einen Über-blick:

• none: Standardfall, eine Transition ohne Bedingung.

• success: Drückt aus, daß die Aktivität über diese Transition verlassen wird,wenn sie gültig ausgeführt wurde.

• failure: Der Kontrollfluß läuft über diese Transition, falls die Aktivität nichtgültig ausgeführt werden konnte.

• each time: Mit dieser Bedingung werden Schleifen modelliert. Zu jedemgefundenen Matching einerfor eachAktivität werden bestimmte Operatio-nen ausgeeführt, die über die ausgehendeeach timeTransition spezifiziertsind. Fujaba geht dabei iterativ vor, d.h. es wird ein Matching bestimmt, undfür dieses die Operationen ausgeführt. Im Anschluß daran wird das nächste

8-14

4.2 Aktivitätsdiagramme 8 – Fujaba

Abbildung 6: Beispiel eines Aktivitätsdiagramms

Matching gefunden und bearbeitet. Dies erfolgt solange, bis kein Matchingmehr gefunden werden kann.

• end (for all): Nach allen Iterationen einerfor eachAktivität verläßt der Kon-trollfluß diese über dieend (for all)Transistion.

• else: Der Kontrollfluß läuft über diese Transition, falls keine von der glei-chen Aktivität ausgehende Transition, die mit einer logischen Bedingungversehen ist, erfüllt werden kann.

• boolean expression: Der Kontrollfluß läuft nur über diese Transition, fallsdie Boolean Bedingung eingehalten werden kann.

Die Abbildung 6 zeigt ein mögliches Aktivitätsdiagramm. In dem Diagramm exi-stieren neben dem Startknoten zwei Endknoten sowie die verschiedenen Aktivitä-ten. Die Raute kann für Verzweigungen innerhalb des Diagramms genutzt werden.

4.2.2 Story Patterns

Story patternsstellen Änderungen an der Objektstruktur dar. Damit es erfolg-reich ausgeführt wird, muß zunächst eine Belegung auf der Objektstruktur ge-

8-15

8 – Fujaba 4 FUJABA

sucht werden, die dasstory patternerfüllt. Die modellierten Änderungen müssendann auf der gefunden Objektstruktur ausgeführt werden können. Fujaba unter-scheidet zwischengebundenenundungebundenenObjekten. Gebundene Objektereferenzieren ein eindeutiges Objekt im Laufzeitgraphen, das z.B. durch Parame-terübergabe bekannt ist. Häufig wird dasthisObjekt benutzt. Es stellt die Referenzauf die aufgerufene Instanz dar und ist immer verfügbar. Ungebundene Objektewerden lediglich durch einen Namen und einen Datentyp angegeben. Sie werdengebunden, sobald eine entsprechende Objektbelegung im Laufzeitgraphen gefun-den wurde.

Objekte der Aktivität werden durch Rechtecke symbolisiert, die horizontal geteiltsind. In der oberen Hälfte wird bei ungebundenen Objekten der Name und der Typdes Objektes vermerkt. Bei gebundenen Objekten wird nur der Name vermerkt. Inder unteren Hälfte werden Attributänderungen bzw. -anforderungen notiert. Ob-jekte werden durch Kanten (links) miteinander verbunden.Links symbolisierendie Bedingung, daß zwei Objekte innerhalb der Objektstruktur existieren und mit-einander assoziiert sind.

Objekte der Aktivität können durchModifier undConstraintsnäher beschriebenwerden.Modifiergeben an, ob ein Objekt neu erstellt bzw. ein vorhandenes Objektgelöscht werden soll.Constraintssind Bedingungen an Objekte. Sie lassen sichlaut Fujaba-Dokumentation [8] wie folgt beschreiben:

• None: Fujaba überprüft das modellierte Objekt desstory patternsund alleObjekte, die über einenlink mit diesem in Verbindung stehen auf Durch-führbarkeit. Tritt dabei ein Fehler auf, wird dasstory patternüber einefai-lure-Transition verlassen. Tritt kein Fehler auf, so wird dasstory patternüber einesuccess-Transition verlassen.

• Optional: Optionalelinksbzw. optionale Knoten müssen während der Aus-führung desstory patternsnicht existieren. So kann z.B. sehr einfach mo-delliert werden: Falls einlink existiert, so soll dieser gelöscht werden.

• Negative: In Fujaba können Modellierungselemente auch negativ verwendetwerden. Wenn einlink als negativ gekennzeichnet ist, überprüft Fujaba, obzwischen den beiden angrenzenden Objekten keinlink des entsprechendenTyps besteht. Falls derlink doch bestehen sollte, wird dasstory patternüberdie failure Transition verlassen. Auch Knoten können als negativ markiertwerden, so daß diese bei der Ausführung desstory patternsnicht existie-ren dürfen. Abbildung 7 zeigt dazu ein Ausschnitt aus einem Aktivitätsdia-gramm des Beispielszenarios. Hier ist das gebundene Player Objektaktive-Playerüber die negativecontrolled byKante mit dem noch ungebundenen

8-16

4.3 Beispiele 8 – Fujaba

Abbildung 7: Beispiel eines negativen links

VictoryPit ObjektpassivePlayersKalahaverbunden. Dieses Muster drücktaus, das ein Siegerbehälter gesucht wird, der nicht dem aktiven Spieler ge-hört. Es ist also der Siegerbehälter des Gegners gemeint. In einem Matchingdes Musters existiert somit keine Verbindung zwischen dem aktiven Spielerund dem gefundenen Siegerbehälter.

• Set: Bei dem Objekt der Aktivität handelt es sich um eine Menge von Ob-jekten. Auf alle Objekte der Menge werden die in demstory patternmodel-lierten Änderungen ausgeführt.

4.3 Beispiele

Es folgt ein Beispiel, wie Fujaba Aktivitätsdiagrammen genutzt werden können,um auf einer Objektstruktur Objekte und deren Beziehungen zueinander zu su-chen bzw. zu prüfen. Dazu wird die MethodeisFinished():Booleander KlasseBoard, wie in Abbdilung 8 zu sehen implementiert.isFinishedprüft, ob das Spielbeendet ist. Änderungen an der Objektstruktur sind dazu nicht erforderlich. DasSpiel ist beendet, falls der aktive Spieler keine Spielsteine mehr besitzt. Die Prü-fung findet daher folgendermaßen statt: Der Kontrollfluß der Methode beginnt imStartknoten, der über eine Transition mit einemstory patternverbunden ist. Dasstory patternsucht eine Konfiguration auf der Objektstruktur, die eindeutig bele-gen kann, ob das Spiel beendet ist. Der Ablauf desstory patternsgliedert sich indrei Schritte.

Zuerst wird der aktive Spieler gesucht und gebunden. Dies geschieht durch die „isactive“ Kante zwischen dem gebundenthis Objekt und dem ungebunden Spieler-Objekt activePlayer. Da die entsprechendeis activeAssoziation im Klassendia-gramm zwischen derBoardKlasse und derPlayerKlasse eine 1:1 Beziehung ist,kann Fujaba eindeutig entscheiden, welcher der beiden Spieler der aktive Spielerist.

8-17

8 – Fujaba 4 FUJABA

Abbildung 8: Aktivitätsdiagramm der Methode isFinished()

Im zweiten Schritt werden alle Spielsteinbehälter (oneOfHisPits) vom TypPlayer-Pit des aktiven Spielers auf ihren Inhalt überprüft. Der Kalaha Behälter vom TypVictoryPit ist von der Prüfung ausgeschlossen. Es werden hierfür zunächst zweiweitere Objekte gesucht: DasoneOfHisPitsObjekt und dasaSingleBeanObjekt.Beide Objekte sind nicht gebunden. Zur Suche deroneOfHisPitswird die con-trolled byKante zwischenactivePlayerundoneOfHisPitsgenutzt (vgl. Klassen-diagramm). Im ersten Schritt wurde bereits der aktive Spieler gebunden, so daßdie Kante zwischen demactivePlayerObjekt und demoneOfHisPitsObjekt sichauf den aktiven Spieler bezieht. DasoneOfHisPitsObjekt ist ungebunden, d.h.es wird ein beliebigesOneOfHisPitObjekte, das dem aktiven Spieler gehört, ge-bunden. Fujaba arbeitet bei der Suche nach Objekten nichtdeterministisch, d.h.der Entwickler kann nicht vorhersagen welches Objekt gefunden und gebundenwird. Für das nun gebundene Objekt wird durch diein pit Kante einBeanObjektgesucht, so daßaSingleBeangebunden werden kann.

Der dritte und letzte Schritt ist der wichtigste, denn er bestimmt, ob das Spielbeendet ist. Wird im zweiten Schritt zu keinemoneOfHisPitsObjekt einBeangefunden, so kann dasstory patternnicht erfüllt werden. Es gibt also keine Ob-jektbelegung, die dasstory patternerfüllt. Das bedeutet mit anderen Worten, daßder aktive Spieler keinen Spielsteinbehälter hat, in dem sich ein Spielstein befin-

8-18

4.4 Weitere Diagramme und Funktionalitäten 8 – Fujaba

Abbildung 9: Ausschnitt aus setupBoard: Initialisierung des Spielfeldes

det. Das Spiel ist somit beendet. Der Kontrollfluß verläßt dasstory patternüberdie failure-Transition in dentrue-Endknoten. Falls im zweiten Schritt eine gültigeObjektbelegung gefunden wurde, so bedeutet dies, daß der aktive Spiele minde-stens einen Spielstein in einem seiner Spielsteinbehälter (außer Kalaha) hat. DasSpiel ist noch nicht beendet. Dasstory patternwird über diesuccessTransition indenfalse-Endknoten verlassen.

Fujaba ist nicht nur in der Lage, auf Objektstrukturen zu suchen, sondern auchObjekte zu löschen bzw. zu erstellen. Zu beachten ist, daß Objekte nicht direktgelöscht werden. In Java werden Objekte durch dengarbage collectorautoma-tisch gelöscht. Zum Entfernen eines Objekts wird dies aufnull gesetzt.

Die Abbildung 9 zeigt einen Ausschnitt aus der MethodesetupBoard, die zur In-itialisierung des Spielfeldes dient. Nach dem Aufruf der Methode läuft der Kon-trollfluß in das dargestelltestory pattern. In diesemstory patternwerden die bei-den Spieler Objekteplayer1undplayer2vom TypPlayererzeugt. Beide Objektesind jeweils über einetakes part inKante mit demthisObjekt assoziiert. Dassto-ry patternerzeugt nicht nur die beiden Objekte, sondern auch die Assoziationenzwischen den Spieler Objekten und demthis Objekt. Objekte die in einemstorypatternerzeugt werden, sind zum einen grün markiert und zum anderen mit demWort createversehen. Objekte die gelöscht werden, sind rot markiert und mit demWort destroyversehen.

4.4 Weitere Diagramme und Funktionalitäten

Neben den vorgestellten Klassen- und Aktivitätsdiagrammen kann Fujaba durchPlugins um zusätzliche Diagramme und Funktionalität erweitert werden. Pluginskönnen über einen Fujaba Menüpunkt ausgesucht und installiert werden. Nacherfolgreicher Installation erscheinen die zusätzlichen Diagramme im Menüpunkt

8-19

8 – Fujaba 5 SPEZIFIKATION VON KOMPONENTEN

Diagrams. Auf [3] gibt es Fujabaversionen mit bereits integrierten Plugins. Sobietet die Real-Time Version von Fujaba laut [3] u.a.component diagrams, Real-time coordination patternsundReal-Time Statechartsan.

5 Spezifikation von Komponenten

Die Erstellung von Softwaresystemen mittels Fujaba wurde im vorherigen Kapitelbeschrieben. Es reichen bereits Klassendiagramme und Aktivitätsdiagramme aus,um ein Softwaresystem visuell zu entwerfen und Java Quellcode zu generieren.Es bietet sich ferner an, daß Entwickler Softwaresysteme mit Fujaba entwickeln,die sich Komponententechnologie zu Nutze machen.

Komponententechnologie bedeutet zum einen, daß Entwickler in Fujaba Kom-ponenten spezifizieren können. Ein beliebiges Komponentenmodell kann jedochnicht genutzt werden, da Fujaba nur Java Quellcode erzeugen kann. In Frage kom-men somit nur solche Komponentenmodelle, die auf der Programmiersprache Javabasieren, wie das JavaBean Modell. Es ist ein einfaches und leicht umzusetzendesKomponentenmodell.

Zum anderen ist mit Komponententechnologie folgendes gemeint: Entwicklernutzen zur Entwicklung eines Softwaresystems fertige Softwarekomponenten.Das Softwaresystem besteht aus einer Komposition von ausgewählten Software-komponenten (Komponentenumgebung). Es ist dabei unwichtig, ob diese vorhermit Fujaba spezifiziert oder von einem Dritt-Entwickler zur Verfügung gestelltworden sind. In einem Komponentendiagramm werden die Softwarekomponen-ten visuell repräsentiert. Entwickler können in diesem Diagramm Softwarekom-ponenten anpassen und miteinander verbinden.

5.1 Spezifikation und Verwendung von Komponenten

In diesem Abschnitt wird geprüft, inwiefern Fujaba Komponententechnologie un-terstützt. Die aktuelle Version von Fujaba (Version 5) unterstützt nicht die Ent-wicklung von Softwaresystemen mittels Softwarekomponenten. Es existiert kei-ne Diagrammart, in der fertige Softwarekomponenten geladen und miteinanderkombiniert werden können. Erweiterte Versionen von Fujaba, beispielsweise dieFujaba Real-Time Version, bieten ebenfalls nicht die Möglichkeit an, bereits ent-wickelte Softwarekomponenten zu nutzen.

8-20

5.1 Spezifikation und Verwendung von Komponenten 8 – Fujaba

Komponententechnologie umfaßt jedoch nicht nur die Nutzung von Softwarekom-ponenten zur Entwicklung von Softwaresystemen, sondern auch die Spezifizie-rung von Softwarekomponenten. Es stellt sich die Frage, ob Fujaba zur Spezifi-zierung und Entwicklung von Softwarekomponenten genutzt werden kann.

Die Diplomarbeit [14] beschäftigt sich mit der Entwicklung und Nutzung vonSoftwarekomponenten mit Fujaba. Erläuterungen in dieser Arbeit werden anhandeines Beispielszenarios verdeutlicht. Bei dem Beispielszenario handelt es sich umein komponentenbasiertes Versionierungs- und Konfigurationssystem.

Im Verlauf der Diplomarbeit wird die Softwarekomponente zumcheckinvonQuellcode (Checkin-Dienst) entworfen. Die spezifizierte Komponente wird in einKomponentendiagramm eingebettet und die Planung des Betriebs dieser Kompo-nente wird vorgenommen. Das Komponentendiagramm stellt Softwarekomponen-ten und ihre Verbindung untereinander dar.Komponenten, angebotene Schnittstel-len, benutzte SchnittstellenundKantenkönnen genutzt werden, um ein Kompo-nentendiagramm zu entwerfen. Planung des Betriebs der Komponente bedeutet,daß das Zusammenspiel der unterschiedlichen Komponenten, aus denen das Soft-waresystem besteht, betrachtet wird. Es soll möglich sein, aus diesem Diagrammzusätzlichen Quellcode zu generieren. Dieser Quellcode ist nötig, um die einzel-nen Komponenten zu verbinden.

Als Komponentenmodellen standen unter anderem Web-Services, Enterprise Ja-vaBeans und Jini zur Auswahl. Aus Gründen, wie Fehlertoleranz etc., hat sich derVerfasser für das Jini Modell entschieden. Entscheidend ist, daß bei dem späterenEntwurf der Checkin-Dienst Komponente, diese mit Fujaba spezifiziert wurde.Zur Spezifizierung dercheckin-Komponente wurden Klassendiagramme, Aktivi-tätsdiagramme und Zustandsdiagramme genutzt. Zur Einbettung der Komponen-te in ein Komponentendiagramm und zur Planung des Betriebs der Komponentewurde ein Plugin für Fujaba entwickelt. Die Softwarekomponente kann jedochnicht sofort genutzt werden. Hierzu sind noch einige Schritte erforderlich. Derdurch Fujaba generierte Quelltext muß mit dem BuildTool-Werkzeug [14] kom-piliert und in mehrere jar-Archive aufgeteilt werden. Außerdem benötigen JiniDienste eine XML Beschreibung der Komponente. Diese kann nicht mit Fujabaerzeugt werden, sondern muß manuell erstellt werden.

Das bereits erwähnte Plugin, zur Darstellung und Beschreibung der Konfigura-tion von Komponenten in Fujaba, steht leider nicht zum öffentlichen Downloadbereit. Auf der Website [3] lassen sich bezüglich des Plugins auch keine Hinweisefinden. Die vorliegende Version des Plugins befindet sich leider in einem nichtbrauchbaren Zustand. Fujaba bietet zwar das Komponentendiagramm an, diesesist aber nicht vollständig dokumentiert. So fehlt neben der Dokumentation auchBeschriftungen von Symbolen etc. Weiterhin bietet das Diagramm nicht die Fä-

8-21

8 – Fujaba 5 SPEZIFIKATION VON KOMPONENTEN

higkeit, fertige Softwarekomponenten zu Nutzen und damit ein Softwaresystemzu entwickeln.

Als Fazit kann festgehalten werden, daß Fujaba bisher nicht in der Lage ist, mitfertigen Softwarekomponenten ein neues Softwaresystem zu entwickeln. Die Spe-zifizierung von einzelnen Softwarekomponenten beschränkt sich auf Komponen-tenmodelle, die auf der Programmiersprache Java basieren. Das Jini Modell, läßtsich zum größten Teil mit Fujaba umsetzen. Die Spezifizierung des Quellcodeskann mit Fujaba vorgenommen werden. Die Kompilierung der Quelltexte, dasanschließende Packen und die Beschreibung der Jini Komponente wurde manuellvorgenommen. Fujaba kann in diesem Bereich noch verbessert werden, so daß dieSpezifizierung einer Jini Komponente komplett in Fujaba vorgenommen werdenkann.

5.2 Fujaba und das JavaBean Modell

Im Vergleich zum Jini Komponentenmodell ist das JavaBean Komponentenmodellleichter umzusetzen. Die wesentlichen Unterschiede ergeben sich aus Erstellungder Schnittstelle und der eigentlichen Umsetzung des Modells. Jini Komponen-ten benötigen eine XML-Schnittstellendatei, währen bei JavaBean Komponentendie Schnittstelle allein durch die Einhaltung der Namenskonvention erstellt wird.Auch die Umsetzung des JavaBean Modells ergibt sich im wesentlichen aus derEinhaltung der Namenskonvention. So lassen sich bereits einfache Java Klassenin eine JavaBean Komponente wandeln. Die Spezifikation von JavaBean Kompo-nenten mit Fujaba ist leider nur eingeschränkt möglich. Es sind teilweise Ände-rungen am generierten Quellcode erforderlich. Im folgenden werden Negativbei-spiele aufgeführt, die verdeutlichen, daß Fujaba die Entwicklung von JavaBeanKomponenten nicht optimal unterstützt.

Probleme entstehen bereits durch einfache Assoziationen zwischen zwei Klassen.Die Introspektion wird durch get- und set- Methoden sowie deren Sichtbarkeit ge-steuert. Die Methodennamen werden durch Fujaba zwar konform zur JavaBeanKonvention erzeugt, jedoch lassen sich von assoziierten Klassen die Sichtbarkei-ten für die get- und set- Methoden nicht getrennt festlegen. Ein Eingriff in dengenerierten Quellcode ist daher erforderlich, sofern der Entwickler verschiedeneSichtbarkeiten für die Methoden benötigt. Weitere Probleme entstehen durch ge-bundene Attribute [11]. Nach [1] müssen für gebundene Attribute Operationenzum Verwalten vonPropertyChangeListenerObjekte implementiert werden.

• public void addPropertyChangeListener(PropertyChangeListener x)

8-22

6 ZUSAMMENFASSUNG 8 – Fujaba

• public void removePropertyChangeListener(PropertyChangeListener x)

Fujaba bietet während der Erstellung von Attributen keine Möglichkeit an, dieseals gebundene Attribute zu erzeugen, so daß eine entsprechendePropertyChangeUnterstützung für die Attribute erzeugt wird. Auch hier ist ein Eingriff in denQuellcode erforderlich.

Diese einfachen Beispiele machen bereits deutlich, das auch das JavaBean Modellnicht ohne weiteres mit Fujaba umgesetzt werden kann. Änderungen im generier-ten Quellcode bzw. die Angabe von Java Quellcode in Fujaba, widersprechen dereigentlichen Idee von Fujaba, nämlich visuell zu entwickeln. Die Entwicklung ei-nes JavaBean-Plugins bietet sich an. Das Plugin kann Dialogfelder, wie z.B. denAttribut-Editor entsprechend ändern und die Codegenerierung anpassen. So wäreein Eingriff in den generierten Code nicht mehr nötig.

6 Zusammenfassung

Fujaba kann zur Entwicklung von Softwaresystemen genutzt werden. Es eignetsich im Allgemeinen gut zur Änderung von Objektstrukturen sowie für spezi-fische Probleme, die gut durch visuelle Programmierung gelöst werden können.Das UML Klassendiagramm ist leicht erstellt und bietet dem Entwickler einen gu-ten Überblick. Änderungen an der Softwarearchitektur können später bequem amUML Klassendiagramm vorgenommen und durch die Codegenerierung umgesetztwerden. Kleine bzw. nicht allzu komplexe Methoden können ebenfalls leicht mitdem Aktivitätsdiagramm entwickelt werden. Sind die Methoden sehr komplex, soverringert sich der Vorteil der visuellen Programmierung. Sehr große Diagrammesind nicht automatisch leicht lesbar oder leicht zu verstehen. Hier bietet es sichan, die Methoden direkt in Java zu implementieren. Ein weiterer Grund, komple-xe Methoden direkt in Java zu programmieren ist, daß die Codegenerierung vonFujaba nicht gut dokumentiert ist. Probleme entstehen auch, wenn nur ein Teileines Softwareprojektes mit Fujaba erstellt wird. Ist der Entwickler gezwungendirekt auf Methoden des generierten Quellcodes zu zugreifen, beispielsweise aufeinen durch Fujaba automatisch erzeugten Iterator einer Attributmenge, so gibt dieFujaba Dokumentation keine Hinweise, wie diese bezeichnet werden. Es ist dannmühsam, im generierten Quellcode nachzusehen und nachzuvollziehen, wie dieseheißen. Weiterhin findet für Java Quellcode, der im Aktivitätsdiagramm benutztwird, keine Syntaxprüfung statt.

Fujaba unterstützt die Spezifikation und die Nutzung von Komponenten nurschlecht. Das heißt, die Entwicklung von Softwaresystemen durch Softwarekom-

8-23

8 – Fujaba 6 ZUSAMMENFASSUNG

ponenten ist bisher überhaupt nicht mit Fujaba möglich. Komponentenmodelle,die nicht auf der Programmiersprache Java basieren, lassen sich mit Fujaba garnicht umsetzen. Für die restlichen Komponentenmodelle muß jeweils einzeln ge-prüft werden, ob und wie diese durch Fujaba unterstützt werden. Jini Komponen-ten können mit Fujaba spezifiziert werden, [14]. Die Kompilierung des Quellco-des und das Packen injar Archive wurde manuell vorgenommen. Das JavaBeanModell kann mit Fujaba nur eingeschränkt umgesetzt werden. Eventuelle Anpas-sungen am Quellcode sind erforderlich. Plugins können sowohl auf den Fujaba-Editor als auch auf die Codegenrierung Einfluß nehmen. Es bietet sich daher an,daß Fujaba durch entsprechende Plugins erweitert wird, so daß beispielsweise dasJavaBean Modell vollständig umgesetzt werden kann.

8-24

LITERATUR 8 – Fujaba

Literatur

[1] BALZERT, HELMUT: Lehrbuch der Software-Technik 1. SpektrumAkademischer Verlag, 2001. ISBN: 3-8274-0480-0.

[2] DOTOR, ALEXANDER: Fujaba Tutorial: Creating a Mancala-Game withFujaba. Universität Bayreuth, Lehrstuhl für Angewandte Informatik I,2006.http://www.se.eecs.uni-kassel.de/~fujabawiki/index.php/User_Documentation .

[3] FUJABA-WEBSITE. Zuletzt besucht: Januar 2007.http://www.fujaba.de/ .

[4] M EISEN, TOBIAS: Fujaba. Seminararbeit, RWTH Aachen, Lehrstuhl fürInformatik 3, 2005.

[5] M ICROSOFT, COM. Zuletzt besucht: Dezember 2006.http://www.microsoft.com/com/default.mspx .

[6] OBJECTMANAGEMENTGROUP. Zuletzt besucht: Dezember 2006.http://www.omg.org/ .

[7] SCHWICHTENBERG, HOLGER: Markt der Softwarekomponenten undKomponentenmodelle. Zuletzt besucht: Dezember 2006.http://www.dotnetframework.de/komponenten/markt/default.aspx .

[8] SCHÄFER, PROF. DR. W.: Fujaba Dokumentation. Universität Paderborn,Fachbereich 17, Arbeitsgruppe Softwaretechnik, 2002.http://ai4.inf.uni-bayreuth.de/export/sites/default/Documents/ai4_de/Projects/Informatik_Wettbewerb/Schuljahr_0607/Fujaba-Doku.pdf .

[9] SUNM ICROSYSTEMS, BEANBUILDER. Zuletzt besucht: Januar 2007.https://bean-builder.dev.java.net/ .

[10] SUNM ICROSYSTEMS, ENTERPRISEJAVA BEANS. Zuletzt besucht:Dezember 2006.http://java.sun.com/products/ejb/ .

[11] SUNM ICROSYSTEMS, JAVA BEAN. Zuletzt besucht: Dezember 2006.http://java.sun.com/products/javabeans/ .

[12] SUNM ICROSYSTEMS, JAVA BEANSPECIFICATION. Zuletzt besucht:Dezember 2006.http://java.sun.com/products/javabeans/docs/spec.html .

8-25

http://www.se.eecs.uni-kassel.de/~fujabawiki/index.php/User_Documentation http://www.se.eecs.uni-kassel.de/~fujabawiki/index.php/User_Documentation http://www.fujaba.de/ http://www.microsoft.com/com/default.mspx http://www.omg.org/ http://www.dotnetframework.de/komponenten/markt/default.aspx http://www.dotnetframework.de/komponenten/markt/default.aspx http://ai4.inf.uni-bayreuth.de/export/sites/default/Documents/ai4_de/Projects/Informatik_Wettbewerb/Schuljahr_0607/Fujaba-Doku.pdf http://ai4.inf.uni-bayreuth.de/export/sites/default/Documents/ai4_de/Projects/Informatik_Wettbewerb/Schuljahr_0607/Fujaba-Doku.pdf http://ai4.inf.uni-bayreuth.de/export/sites/default/Documents/ai4_de/Projects/Informatik_Wettbewerb/Schuljahr_0607/Fujaba-Doku.pdf https://bean-builder.dev.java.net/ http://java.sun.com/products/ejb/ http://java.sun.com/products/javabeans/ http://java.sun.com/products/javabeans/docs/spec.html http://java.sun.com/products/javabeans/docs/spec.html

8 – Fujaba LITERATUR

[13] SZYPERSKI, CLEMENS: Component Software: Beyond Object-OrientedProgramming. Addison-Wesley, 2002. ISBN:0-201-74572-0.

[14] TICHY, MATTHIAS: Durchgängige Unterstützung für Entwurf,Implementierung und Betrieb von Komponenten in offenenSoftwarearchitekturen mittels UML. Diplomarbeit, Universität Paderborn,Fachbereich 17, Arbeitsgruppe Softwaretechnik, 2002.

[15] WIKIPEDIA -EINTRAG, CASE-WERKZEUGE. Zuletzt besucht: Dezember2006.http://de.wikipedia.org/wiki/Computer-Aided_Software_Engineering .

[16] WIKIPEDIA -EINTRAG, FUJABA. Zuletzt besucht: Dezember 2006.http://de.wikipedia.org/wiki/Fujaba .

8-26

http://de.wikipedia.org/wiki/Computer-Aided_Software_Engineering http://de.wikipedia.org/wiki/Computer-Aided_Software_Engineering http://de.wikipedia.org/wiki/Fujaba

MotivationKomponentenZiel der komponentenbasierten SoftwareentwicklungAnforderungen und Eigenschaften von SoftwarekomponentenKomponentenmodelle

BeispielszenarioFujabaKlassendiagrammeAktivitätsdiagrammeBeispieleWeitere Diagramme und Funktionalitäten

Spezifikation von KomponentenSpezifikation und Verwendung von KomponentenFujaba und das JavaBean Modell

Zusammenfassung