Studienarbeit Integration von Entwurfsmuster in ArgoUML - Rene... · und in [Sch02] ¨uberarbeiteten Pattern-Erweiterung f ¨ur Rational Rose. Der entwickelte Wizard stellt eine Portierung

g eg r ü n d et 1 4 1 9

Studienarbeit

Integration vonEntwurfsmuster in

ArgoUML

vorgelegt von

Rene Lindhorst

Betreuer:

Prof. Dr.–Ing. Peter Forbrig

Institut fur Informatik

Lehrstuhl Softwaretechnik

Universitat Rostock

Rostock, den 19. Dezember 2006

Inhaltsverzeichnis

1 Einleitung 1

1.1 Unified Modeling Language . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.2 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.3 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 ArgoUML 7

2.1 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Besonderheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Verwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 ArgoUML Erweitern 15

3.1 Modul-Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Modell-Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Internationalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Build-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 Besonderheiten und Richtlinien . . . . . . . . . . . . . . . . . . . . . . 19

4 ArgoUML Pattern-Wizard 23

4.1 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.1 Vorbereitungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.2 Erzeugen der Ant Konfigurationsdatei . . . . . . . . . . . . . . 23

4.1.3 Implementation der Hauptklasse des Moduls . . . . . . . . . . . 25

4.1.4 Aufbau der Benutzeroberflache . . . . . . . . . . . . . . . . . . 26

ii INHALTSVERZEICHNIS

4.1.5 Konzeption des Datenmodels . . . . . . . . . . . . . . . . . . . 28

4.2 Moglichkeiten des Pattern-Wizards . . . . . . . . . . . . . . . . . . . . 30

4.3 Beispielszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Schlussbemerkungen 35

5.1 Erweiterungsmoglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1 Design by Contract . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.2 Pattern-Kardinalitat . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.3 Integration der Entwurfsmuster-Bibliothek . . . . . . . . . . . . 36

5.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

A Anhang 39

A.1 Apache Ant Konfigurationsdatei (build.xml) . . . . . . . . . . . . . . . 39

A.2 Klassendiagramm des Datenmodels . . . . . . . . . . . . . . . . . . . . 45

Literaturverzeichnis 47

Abbildungsverzeichnis

1.1 Struktur des Singleton-Entwurfsmusters . . . . . . . . . . . . . . . . . 3

1.2 Struktur des Fassaden-Entwurfsmusters . . . . . . . . . . . . . . . . . . 4

1.3 Struktur des Beobachter-Entwurfsmusters . . . . . . . . . . . . . . . . 4

2.1 Benutzeroberflache von ArgoUML . . . . . . . . . . . . . . . . . . . . . 11

3.1 Wichtige Bestandteile des Modul-Subsystems . . . . . . . . . . . . . . . 16

3.2 Beispiel fur Factories und Helper . . . . . . . . . . . . . . . . . . . . . 17

4.1 Abhangigkeiten der Ant Targets . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Hauptklasse zum Aktivieren des Pattern-Wizards . . . . . . . . . . . . 26

4.3 GUI-Klassen des Pattern-Wizards . . . . . . . . . . . . . . . . . . . . . 27

4.4 Benutzeroberflache des Pattern-Wizards . . . . . . . . . . . . . . . . . 28

4.5 Kombination von Kapsel- und Befehlsobjekten . . . . . . . . . . . . . . 29

4.6 Komponenten-Tab des PatternWizards . . . . . . . . . . . . . . . . . . 30

4.7 Beziehungen-Tab des PatternWizards . . . . . . . . . . . . . . . . . . . 32

4.8 Wichtige Klassen des Uhrenbeispiels . . . . . . . . . . . . . . . . . . . 32

4.9 Uhrenbeispiel in Kombination mit Beobachter-Entwurfsmuster . . . . . 34

Kapitel 1

Einleitung

Durch den Einsatz der Unified Modeling Language (UML) und Computer Aided Soft-

ware Engineering (CASE) Tools in der Softwareentwicklung wird die Analyse und der

Entwurf von objektorientierten Anwendungen vereinfacht. Zusatzlich ermoglicht die

Nutzung von Entwurfsmustern (Design-Pattern) die Wiederverwendung von erfolgrei-

chen Entwurfen und verbessert die Flexibilitat des Entwurfs. Der Einsatz von Ent-

wurfsmustern wird jedoch nicht von allen CASE-Tools unterstutzt. So ist das Ziel

dieser Studienarbeit die Entwicklung eines Pattern-Wizards fur das Open Source Pro-

gramm ArgoUML. Der Wizard wird als eine Erweiterung, ein so genanntes Modul,

in ArgoUML eingebunden und soll die Integration von Entwurfsmustern in bestehen-

de Softwaresysteme erleichtern sowie den Entwurf neuer Anwendungen unter Nutzung

von Entwurfsmustern vereinfachen. Die Arbeit basiert auf der in [Man00] entwickelten

und in [Sch02] uberarbeiteten Pattern-Erweiterung fur Rational Rose. Der entwickelte

Wizard stellt eine Portierung und Weiterentwicklung dieser Erweiterung dar, wobei

besonderer Wert auf eine objektorientierte Programmierung und eine leichtere Nutz-

barkeit durch den Anwender gelegt wurde.

Die folgenden beiden Unterabschnitte geben eine kurze Einfuhrung in die Uni-

fied Modeling Language und Entwurfsmuster. Im nachsten Kapitel wird ArgoUML

ausfuhrlich erklart und in Kapitel 3 werden die fur die Entwicklung des Pattern-

Wizards wichtigsten internen Bestandteile von ArgoUML genauer betrachtet. Kapitel 4

beschreibt schließlich die Entwicklung des Pattern-Wizards und dessen Moglichkeiten.

Abgeschlossen wird das Kapitel mit einem kurzen Beispiel-Szenario, das die Funktions-

weise des Wizards noch einmal verdeutlichen soll. In den Schlussbemerkungen werden

Moglichkeiten zur Erweiterung des Pattern-Wizards besprochen.

2 1.1 Unified Modeling Language

1.1 Unified Modeling Language

Die UML ist eine international anerkannte grafische Notation zur Erstellung objekt-

orientierter Modelle fur die Analyse und den Entwurf von objektorientierter Software.

Wie in [Bal05] beschrieben, wurde sie von Grady Booch, Jim Rumbaugh und Ivar

Jacobson entwickelt und 1996 als Version 0.91 veroffentlicht. Ende 1997 wurde die wei-

terentwickelte Version 1.1 von der Object Management Group (OMG) als Standard

verabschiedet. Es folgten weitere Versionen mit einigen Verbesserungen. So etwa im

Mai 2002 die UML 1.4. Wesentliche Anderungen und Erweiterungen erfuhr die Nota-

tion jedoch erst mit der 2005 veroffentlichten UML 2.0.

Die UML erfreut sich aus verschiedenen Grunden großer Beliebtheit. Zum einen

konnen mit einer einheitlichen und verstandlichen Notation die verschiedensten Ele-

mente eines Softwaresystems visuell beschrieben werden. Zum anderen bildet sie eine

einfache Grundlage fur die Kommunikation zwischen den Entwicklern. In der UML gibt

es eine Vielzahl von Diagrammen fur die unterschiedlichsten Anwendungsgebiete. In

dieser Arbeit werden jedoch nur die Klassendiagramme benotigt. Sie dienen der Dar-

stellung von Klassen, mit ihren Attributen und Methoden, und der Beziehungen (As-

soziationen, Aggregationen, Kompositionen, etc.) zwischen ihnen. Fur weiterfuhrende

Informationen uber UML, die verfugbaren Diagramme und Notationselemente mochte

ich auf [ZGK04] und [Bal05] verweisen.

1.2 Entwurfsmuster

Ein Entwurfsmuster beschreibt mit einem gewissen Abstraktionsniveau eine Struktur

zur Losung eines allgemeinen objektorientierten Entwurfsproblems, wann es einsetzbar

ist und welche Folgen sein Einsatz hat. Neben einer Klassenstruktur werden auch die

innere Struktur der Klassen und die Schnittstellen beschrieben. Des Weiteren wird

mit Hilfe von Codefragmenten die Funktionsweise des Entwurfsmusters verdeutlicht.

Der Vorteil von Entwurfsmustern liegt u. a. in der Wiederverwendung von erfolgreich

eingesetzten Entwurfen und einer daraus resultierenden Verbesserung der Qualitat von

Entwurfsentscheidungen.

Das Standardwerk uber Entwurfsmuster ist [GHJV04] von Erich Gamma, Richard

Helm, Ralph Johnson und John Vlissides und wurde Ende 1994 in der ersten Auflage

veroffentlicht. Zu dieser Zeit war die Idee der Entwurfsmuster nicht mehr neu, aber es

enthielt den ersten umfangreichen Musterkatalog und hatte damit einen großen Anteil

an der starken Verbreitung von Entwurfsmustern in der Softwaretechnik. In diesem

Buch der”Gang of Four“ (GoF), wie die vier Autoren auch genannt werden, sind die

1 Einleitung 3

Entwurfsmuster in drei Kategorien eingeteilt. Es wird zwischen erzeugenden, struk-

turorientierten und verhaltensorientierten Mustern unterschieden. Erzeugungsmuster

beschaftigen sich mit der Objekterzeugung, Strukturmuster mit der Zusammenset-

zung von Klassen und Objekten und Verhaltensmuster mit der Zusammenarbeit und

Zustandigkeitsverteilung zwischen verschiedenen Klassen und Objekten. Diese drei Ka-

tegorien werden noch bezuglich ihres Gultigkeitsbereiches in klassenbasierte und ob-

jektbasierte Muster unterteilt, je nachdem ob sich ein Muster hauptsachlich auf Klassen

oder Objekte bezieht. Es sei erwahnt, dass es noch eine Vielzahl anderer Mustersamm-

lungen in Buchern wie [BMR+98] oder auf Internetseiten wie [Hil] gibt, bei denen auch

eine andere Klassifikation der Muster erfolgt.

Die Entwurfsmuster die im Verlauf dieser Studienarbeit Erwahnung finden, sollen

anschließend kurz beschrieben werden. Da es sich dabei ausnahmslos um Entwurfsmus-

ter der GoF handelt, stammen die Informationen dementsprechend aus [GHJV04].

1.2.1 Singleton

Beim Singleton handelt es sich um ein objektbasiertes Erzeugungsmuster das dafur

sorgt, dass eine Klasse maximal ein Exemplar besitzt. Ferner stellt dieses Muster einen

globalen Zugriffspunkt auf dieses Exemplar bereit. Die Singleton-Klasse selbst ist fur

die Verwaltung ihres einzigen Exemplars verantwortlich und kann so auf Befehle zum

erzeugen neuer Objekte mit ihrem Exemplar antworten.

Bild 1.1: Struktur des Singleton-Entwurfsmusters

1.2.2 Facade

Die Fassade (engl. Facade) ist ein objektbasiertes Strukturmuster und wird eingesetzt

um eine einheitliche Schnittstelle zur Funktionalitat eines Subsystems bereitzustellen.

Dies ist besonders hilfreich bei einem komplexen Subsystem, um dessen Benutzung

zu vereinfachen. Die Facade enthalt Informationen daruber welche Subsystemklasse

fur welche Anfragen zustandig ist und delegiert diese entsprechend an die zustandigen

4 1.2 Entwurfsmuster

Bild 1.2: Struktur des Fassaden-Entwurfsmusters

Subsystemobjekte. Die Subsystemklassen enthalten die eigentliche Funktionalitat und

bearbeiten die ihnen zugewiesenen Anfragen.

1.2.3 Observer

Das objektbasierte Verhaltensmuster Observer wird im deutschen auch als Beobach-

ter bezeichnet und dient dem Definieren einer 1-zu-n-Abhangigkeit zwischen Objek-

ten. Es bewirkt, dass sobald sich der Zustand eines Objektes andert, alle von ihm

abhangigen Objekte benachrichtig werden und sich automatisch aktualisieren. Mit

dem Beobachtermuster ist es somit moglich, die Konsistenz zwischen interagieren-

den Klassen sicherzustellen, ohne sie zu stark miteinander zu verzahnen. Bei Zu-

Bild 1.3: Struktur des Beobachter-Entwurfsmusters

standsanderungen des ConcreteSubject benachrichtigt es seine Observer woraufhin die

einzelnen ConcreteObserver-Objekte das Subjekt nach dessen Zustandsanderung be-

1 Einleitung 5

fragen. Der ConcreteObserver nutzt diese Daten dann um seinen eigenen Zustand an

den des ConcreteSubject anzupassen.

Kapitel 2

ArgoUML

ArgoUML ist ein Werkzeug, das den Softwareentwickler in der Analyse und beim

Entwurf von objektorientierten Anwendungen unterstutzt. Es unterscheidet sich in

einigen Bereichen von anderen kommerziellen CASE-Tools wie Together oder Rose.

ArgoUML ist Open Source und basiert auf vielen offenen Standards. Des Weiteren

ist es eine reine Java Anwendungen und setzt Ideen der Kognitionspsychologie (engl.

cognitive psychology) um. Auf diese Besonderheiten wird in folgenden Abschnitten

noch genauer eingegangen, zuerst wird jedoch ein Blick auf die Geschichte des

Projektes geworfen.

2.1 Entwicklung

ArgoUML wurde von einer kleinen Gruppe von Leuten unter der Fuhrung von Ph.D.

Jason Elliot Robbins als Forschungsprojekt der Universitat von Kalifonien in Irvine ent-

wickelt. Eine der Hauptziele Robins war es, wie er in einer E-Mail an die Entwickler-E-

Mail-Liste außerte:”

[. . . ] to help promote good software engineering practices broadly

throughout the industry, and to provide a basis on which more OOAD [Object Oriented

Analysis and Design] tools could be built“1.

Eine erste Version erschien 1998 und im Februar 1999 wurde ArgoUML als Open

Source Projekt veroffentlicht. Zu diesem Zeitpunkt hieß es noch Argo/UML und wurde

erst im November 2001 in ArgoUML umbenannt. Seit Januar 2000 wird das ArgoUML-

Projekt uber Tigris.org verwaltet. Dabei handelt es sich um eine mittelgroße Hosting-

Plattform, vergleichbar mit SourceForge.net oder BerliOS, die auf Open Source Ent-

wicklungswerkzeuge spezialisiert ist. Sie stellt die notige Infrastruktur wie Bug-Tracker,

1http://argouml.tigris.org/servlets/ReadMsg?list=dev&msgNo=20171 22.08.2006

http://argouml.tigris.org/servlets/ReadMsg?list=dev&msgNo=20171

8 2.2 Besonderheiten

E-Mail-Listen, Versionsverwaltung, Webspace etc. zur Verfugung. Bis Mitte 2001 wur-

de ArgoUML uber 100.000 mal von der Projekt-Homepage heruntergeladen und inzwi-

schen sind es durchschnittlich 30.000 Downloads pro Monat2.

Jason E. Robbins hat die Leitung des Projektes bereits vor einigen Jahren

abgegeben. Nachdem Toby Baier kurzzeitig verantwortlich war, hat Linus Tolke seit

Juni 2002 die Rolle des Projektleiters inne. Das Kernentwicklerteam von ArgoUML

bilden 32 Personen, die berechtigt sind Anderungen am Quellcode vorzunehmen.

Eine Vielzahl weiterer Entwickler leiten ihre Modifikationen bzw. Erweiterungen an

das Kernentwicklerteam weiter. Es gibt keine genauen Zahlen daruber wie viele es

sind, jedoch konnen die mehr als 300 Abonnenten der Entwickler-E-Mail-Liste als

Anhaltspunkt dienen.

2.2 Besonderheiten

ArgoUML steht unter der BSD-Lizenz und unterliegt somit so gut wie keinen Ein-

schrankungen bei den Nutzungsbedingungen. Das Programm steht jedem kostenlos

zur Verfugung und der Quellcode ist frei zuganglich um ihn zu uberprufen, an die

eigenen Bedurfnisse anzupassen und zu verbreiten. So gibt es auch verschiedene UML-

Werkzeuge die auf ArgoUML basieren, wie MyEclipse und Sygel. Auch Posseidon for

UML ist ein solche Werkzeug und wird seit Juni 2001 von der deutschen Firma Gent-

leware kommerziell als Closed Source vertrieben. Sie bieten verschiedene Versionen des

Tools mit unterschiedlicher Funktionalitat an. Darunter auch eine Community Edition

zur kostenlosen Nutzung. Gentleware bietet fur seine Produkte auch kommerziellen

Support, was fur viele Nutzer sehr wichtig ist. Jason E. Robbins hat sich zur Nut-

zung des ArgoUML Quellcodes als Basis fur andere CASE-Tools in einer E-Mail an die

Entwickler-E-Mail-Liste wie folgt geaußert:”

I am happy to see vendors create and sell

their own unique value-add[ed tools] and be rewarded for it. Encouraging more small

tool vendors is great for the industry in the long run.“3

Eine weitere Besonderheit sind die offenen Standards. Die Entwickler von ArgoUML

haben versucht, so viele wie moglich fur das Programm und seine Schnittstellen zu

nutzen. Der Hauptvorteil, der in der Verwendung von offenen Standards liegt, ist die

Interoperabilitat. So ist ArgoUML konform zum UML 1.4 Standard der Object Mana-

gement Group (OMG) und nutzt deren XML Metadata Interchange4 (XMI) Format

2http://argouml.tigris.org/downloadcount.html3http://argouml.tigris.org/servlets/ReadMsg?list=dev&msgNo=20171 22.08.20064http://www.omg.org/technology/documents/modeling spec catalog.htm

http://argouml.tigris.org/downloadcount.html

http://argouml.tigris.org/servlets/ReadMsg?list=dev&msgNo=20171

http://www.omg.org/technology/documents/modeling_spec_catalog.htm

2 ArgoUML 9

zum Speichern der Model-Informationen. XMI dient auch als Austauschformat zwi-

schen verschiedenen CASE-Tools. Somit ist es theoretisch moglich, das in ArgoUML

erzeugte Model in ein anderes Tool zu importieren. Jedoch enthalt die XMI Datei

keine Informationen uber die graphische Darstellung des Models (dies wurde erst in

der UML 2.0 Spezifikation erganzt), so dass die Layout-Informationen dabei verloren

gehen. ArgoUML speichert diese Informationen momentan fur jedes angelegte Dia-

gramm in einer extra Datei und nutzt dazu die Precision Graphics Markup Language

(PGML). Es ist geplant, die PGML durch die UML Diagram Interchange Specifikation

abzulosen, sobald ArgoUML die UML 2.0 Spezifikation umsetzt. Es ist auch moglich,

das Model aus einem anderen CASE-Tool in ArgoUML zu importieren. Dazu muss das

Modell im XMI-Format der Version 1.0, 1.1 oder 1.2 vorliegen, jedoch wurde auch in

diesem Fall die graphische Darstellung verloren gehen. Programme wie Meta Integra-

tion Model Bridge5 sind darauf spezialisiert Modelle zwischen unterschiedlichen Tools

zu konvertieren. So ist es z. B. moglich Modelle aus Rational Rose, welches keinen

XMI-Export beherrscht, in ein fur ArgoUML lesbares XMI-Format zu konvertieren.

ArgoUML verpackt die XMI-Datei zusammen mit den PGML-Dateien, einer Datei

(*.argo), die die Informationen uber das Projekt enthalt und einer weiteren Datei

(*.todo), die die vom Nutzer erstellten Prufkriterien enthalt, in einer so genannten

komprimierten ArgoUML-Projektdatei mit der Dateiendung”zargo“. Dabei handelt es

sich um ein normales zip-Archiv, das man dementsprechend nach einer Umbenennung

der Endung mit gangigen Packprogrammen wieder entpacken kann. Die in ArgoUML

erzeugten UML-Diagramme konnen auch als Grafiken exportiert werden. Zu diesem

Zweck werden die Formate Encapsulated PostScript (EPS), Graphic Interchange For-

mat (GIF), Portable Network Graphics (PNG), PostScript (PS) und Scalable Vector

Graphics (SVG) unterstutzt. Eine weitere Besonderheit von ArgoUML ist, dass es auch

die Object Constraint Language (OCL) unterstutzt. Dazu wird das an der Technischen

Universitat Dresden entwickelte Dresden OCL Toolkit6 verwendet.

Die Entscheidung ArgoUML in Java zu entwickeln, hat aufgrund der Interpretation

des Java-Bytecodes einen Geschwindigkeitsnachteil gegenuber kompilierten Program-

men. Jedoch wird dieser Unterschied durch die Leistungsfahigkeit moderner Computer

immer geringer. Der Einsatz von Java hat außerdem einen großen Vorteil. Das Pro-

gramm steht ohne Anpassungen allen gangigen Plattformen und somit allen potenti-

ellen Nutzern zur Verfugung. Des Weiteren ist es moglich, dass Programm als Java

Web Start (JWS) auf der Projekt-Homepage jedem Interessenten zum Ausprobieren

bereitzustellen. Somit kann ArgoUML getestet werden, ohne das Programm auf dem

5http://www.metaintegration.net/Products/MIMB/6http://dresden-ocl.sourceforge.net

http://www.metaintegration.net/Products/MIMB/

http://dresden-ocl.sourceforge.net

10 2.3 Verwendung

eigenen Computer zu installieren.

Eine andere Besonderheit von ArgoUML ist, dass es in 10 verschiedenen Sprachen,

u. a. sowohl in Englisch als auch in Deutsch, Russisch und Chinesisch verfugbar ist.

Die Standardsprache des Programms und auch der Community ist US-Englisch. Wenn

man ArgoUML das erste Mal startet und dies nicht uber die Kommandozeile mit dem

Parameter”-local <language>“ erfolgt (vgl.

”Command Line Options“ im Quickguide),

so startet es mit der”default locale“ des Computers. Sollte die Sprache nicht verfugbar

sein, so wird stattdessen die Standardsprache verwendet. Uber das Menu”Bearbeiten“

→”Einstellungen“ →

”Erscheinungsbild“ gelangt man zu einer Auswahlbox, durch die

man die Sprache festlegen kann, die ArgoUML ab dem nachsten Start nutzen soll.

Ein Hauptfokus von ArgoUML liegt in der Umsetzung der Ideen der Kognitions-

psychologie, um dem Entwickler bei der Konzeption objektorientierter Systeme zu un-

terstutzen. Die Theorie wird in der Ph.D. Dissertation von Jason E. Robbins [Rob99]

genauer beschrieben. Die so genannten”design critics“ laufen als asynchrone Prozes-

se, parallel zu ArgoUML im Hintergrund, um den UML Entwurf zu uberwachen und

dem Nutzer eine Vielzahl von nutzlichen Vorschlagen und Hinweisen anzubieten. So

wird der Nutzer z. B. darauf aufmerksam gemacht, dass er Klassennamen entgegen der

Konvention klein geschrieben hat oder noch kein Konstruktor definiert wurde. Eine

genaue Auflistung und Beschreibung der uberpruften Kriterien befindet sich im Nut-

zerhandbuch. ArgoUML geht aber noch einen Schritt weiter um den Nutzer optimal

zu unterstutzen. Zusatzlich zur Information uber erkannte Schwachstellen bzw. Fehler,

bietet das Programm auch einen Wizard um diese zu beheben. Es ist selbstverstandlich

auch moglich einzelne oder alle Kriterien zu deaktivieren bzw. eigene Prioritaten fur

sie festzulegen.

2.3 Verwendung

Um ArgoUML nutzen zu konnen, sind nur einige wenige Systemanforderungen zu

erfullen. Es wird ein Betriebssystem benotigt, das Java unterstutzt und es muss ei-

ne Java Runtime Evironment (JRE) oder ein Java Development Kit (JDK) ab Version

1.4 installiert sein. Das Programm selbst belegt etwa 10MB Speicherplatz auf der

Festplatte, nachdem man es von der Projekt-Homepage als ZIP-Archiv heruntergela-

den und entpackt hat. Abbildung 2.1 zeigt das ArgoUML Programmfenster in dem ein

leeres Projekt mit einem Klassendiagramm und einem Use-Case-Diagramm geoffnet

ist. Ein solches ArgoUML Projekt beinhaltet genau ein Model mit den zugehorigen

Diagramminformationen und mehreren Modellelementen, die die UML-Beschreibung

des zu modellierenden Systems bilden. Die Modellelemente konnen in einem oder meh-

2 ArgoUML 11

reren Diagrammen dargestellt werden. ArgoUML kann jedoch jeweils nur ein Projekt

zum Bearbeiten geoffnet haben.

Abbildung 2.1: Benutzeroberflache von ArgoUML

Die Benutzeroberflache von ArgoUML hat im oberen Bereich, wie bei Programmen

fur Windows und Linux ublich, ein Menu und darunter eine Toolbar. Die fur Mac

OS X angepasste und in ein .app-Paket verpackte Version stellt das Menu in der

Menuleiste am oberen Bildschirmrand dar, wie es unter OS X ublich ist. Der Bereich

unterhalb der Toolbar unterteilt sich in vier Teilbereiche und nimmt den Großteil des

Programmfensters in Anspruch. Oben links befindet sich der Explorer, der eine Baum-

struktur des erzeugten UML Models mit allen Diagrammen und Modellelementen zeigt

und somit eine zentrale Rolle bei allen Aktionen einnimmt. Die Elemente des Baumes

lassen sich nach verschiedenen Kriterien gruppieren und sortieren, um die Ansicht den

eigenen Bedurfnissen anzupassen. Rechts daneben liegt der Editierbereich, in dem

die Klassen und ihre Beziehungen modelliert werden. Durch Drag&Drop konnen dem

Diagramm Modellelemente vom Explorer hinzugefugt werden bzw. die Objekte eines

Diagramms umgeordnet werden. Der Editierbereich hat eine eigene Toolbar, die sich

dem zu bearbeitenden Diagrammtypen anpasst. Durch Auswahl der entsprechenden

Schaltflache in der Toolbar konnen im Diagramm neue Modellelemente erstellt werden.

Eine sehr einfache Art neue Elemente zu erzeugen, die gleich mit bereits bestehenden

Elementen verknupft sind, ist uber die so genannten”Quick-Links“. Diese erscheinen

sobald man die Maus uber ein selektiertes Element bewegt. Direkt unter dem

Editierbereich findet der Detailbereich seinen Platz. In ihm konnen uber eine Vielzahl

von Reitern (Tabs) u. a. die Eigenschaften des gerade ausgewahlten Model Elementes

bearbeitet, die Darstellung des Elementes angepasst und OCL-Kriterien festgelegt

12 2.4 Dokumentation

werden. Dort kann man auch den erzeugten Quellcode fur eine gerade selektierte

Klasse einsehen. Momentan wird die Quellcodegenerierung fur Java, PHP, C++ und

C# unterstutzt. Es konnen aber weitere Sprachen hinzugefugt werden, da es sich

bei der Quellcodegenerierung um ein”modulares framework“ handelt. Leider werden

die Anderungen, die man in dem Quellcode vornimmt nicht gespeichert. Es ist also

momentan fur keine der unterstutzten Sprachen ein Round-Trip Engineering moglich.

Aber zumindest ein Reverse Engineering fur Java Quellcode und JAR-Archive wird

uber”Datei“ →

”Dateien importieren...“ unterstutzt. Der Import fur C++ Code ist

ebenfalls in Arbeit. Jedoch ist er momentan noch in einer fruhen Phase mit einigen

Einschrankungen. Links neben dem Detailbereich befindet sich der ToDo-Bereich. In

ihm werden die von den”design critics“ gefundenen Probleme und die vom Entwickler

hinzugefugten Eintrage in einer Baumstruktur dargestellt. Diese Eintrage konnen

nach Kriterien wie etwa Prioritaten, Problemen oder Zielen sortiert werden. Unterhalb

dieser vier Bereiche bildet die Statusleiste den Abschluss des Programmfensters. Sie

wird dazu genutzt dem Anwender kurze Hinweistext auszugeben. So wird man dort

uber das erfolgreiche Speichern des Projektes oder das Exportieren von Diagrammen

informiert.

2.4 Dokumentation

Das ArgoUML Projekt bietet verschiedene englischsprachige Dokumente fur Nutzer

bzw. Entwickler, um diese bei ihrer Arbeit zu unterstutzen. So gibt es fur die Nutzer

neben einem”ArgoUML Quick Guide“ [WTOO06] auch ein

”ArgoUML User Manu-

al“ [WTB+06] und eine Liste mit”Frequently asked questions for ArgoUML“ [Mor].

Das”Cookbook for Developers of ArgoUML“ [TK06] richtet sich, wie der Name schon

sagt, an die Entwickler.

Die Kurzanleitung (”ArgoUML Quick Guide“) ist dafur gedacht, dem Nutzer einen

groben Uberblick uber ArgoUML zu verschaffen. In ihr werden die Installation des

Programms erklart und verfugbare Kommandozeilenparamter vorgestellt. Außerdem

wird erlautert, was man unter Windows einstellen muss, damit beim Doppelklick auf

eine .zargo-Datei diese mit ArgoUML geoffnet. Zusatzlich wird noch ganz kurz der Auf-

bau und die Funktionsweise des Programms erklart. Fur weiterfuhrende Informationen

wird der Anwender auf das Nutzerhandbuch verwiesen. Dabei handelt es sich um einen

eigenstandigen Teil des ArgoUML Projektes. Die Ziele dieses Teilprojektes sind zum

einen eine Anleitung fur den Einsatz von ArgoUML in der Objektorientierten Analyse

(OOA) und im Objektorientierten Design (OOD) bereitzustellen, und zum anderen

2 ArgoUML 13

eine Darstellung aller Komponenten von ArgoUML zu bieten.

Das Nutzerhandbuch (”ArgoUML User Manual“) hat momentan einen Umfang von

fast 400 Seiten, wobei fur die Kapitel uber”Analyse“ und

”Design“ momentan nur die

Struktur festgelegt wurde und sie erst nach und nach mit Inhalten gefullt werden.

In der FAQ findet der Nutzer Antworten auf eine Vielzahl von Fragen. So wird dort

etwa erklart, wie man Diagramme erstellt und spater ausdrucken kann. Es wird aber

auch auf Java Web Start, XMI und Betriebssystem spezifische Fragen eingegangen. Die

FAQ wird regelmaßig um Problemstellungen bzw. wichtige Informationen, die in der

Anwender-E-Mail-Liste diskutiert werden, erweitert.

Fur die Entwickler ist das Entwickler-Kochbuch (”Cookbook for Developers of

ArgoUML“) gedacht, denn darin wird die interne Funktionsweise von ArgoUML be-

schrieben. Viele Informationen des nachsten Kapitels stammen daraus. Mit seinen

knapp 150 Seiten bietet es jedoch an vielen Stellen nur einen recht groben Uberblick,

so dass ein Blick in die Javadoc7 bzw. ein Untersuchen des Quellcodes unerlasslich

ist. Das Entwickler-Kochbuch wird jedoch regelmaßig uberarbeitet und erweitert und

enthalt somit immer mehr wichtige Informationen, vor allem fur neue Entwickler. Es

ist zusatzlich ratsam, die Entwickler-E-Mail-Liste zu abonnieren und die Diskussio-

nen der Entwickler zu verfolgen, bzw. sich auch selbst daran zu beteiligen, um so die

Design-Entscheidungen besser nachvollziehen zu konnen.

7http://argouml-stats.tigris.org/nonav/javadocs/javadocs-0.22/

http://argouml-stats.tigris.org/nonav/javadocs/javadocs-0.22/

Kapitel 3

ArgoUML Erweitern

ArgoUML kann durch so genannte Module um neue Funktionen erweitert werden,

ohne das Anderungen an ArgoUML selbst vorgenommen werden mussen. In anderen

Tools nennt man solche Module auch Add-Ins oder Plug-Ins, wie etwa bei Gentlewares

Poseidon. In den folgenden Abschnitten wird erklart wie die Modul-Architektur

von ArgoUML funktioniert und wie andere, fur die Pattern-Erweiterung wichtige

Bestandteile von ArgoUML aufgebaut sind und wie sie genutzt werden konnen.

3.1 Modul-Subsystem

Der Programmcode von ArgoUML ist in Subsysteme unterteilt, die jeweils fur be-

stimmte Aufgaben verantwortlich sind, um so die Entwicklung zu vereinfachen. Das

Modul-System ist ein solches Subsystem und es ist verantwortlich fur das Einbinden

von Erweiterungen. Momentan gibt es zwei verschiedene Mechanismen um Module zu

laden. Einen alten”Module Loader“ und einen neuen, der das Schreiben von Modulen

vereinfacht und fur alle neuen Module genutzt werden soll. Beim Lesen des Entwickler-

Kochbuchs ([TK06]) muss man daher auch genau aufpassen, welcher der beiden erklart

wird, so dass man nicht falschlicherweise den alten fur seine Erweiterung nutzt. Der

ursprungliche”Module Loader“ ist jedoch seit Version 0.21.1 als veraltet markiert. Aus

diesem Grund wird sich die Situation in naher Zukunft wieder vereinfachen, da nach

den in [TK06] beschriebenen Programmierstandards solche Klassen nach einer stabilen

Versionen entfernt werden konnen.

Die Module werden beim Start von ArgoUML durch den ModuleLoader2, so der Na-

me des neuen”Module Loaders“, der sich unter org.argouml.moduleloader befindet,

geladen. Es ist auch vorgesehen, dass die Module aus ArgoUML heraus eingebunden,

16 3.2 Modell-Subsystem

bzw. wieder deaktiviert werden konnen. Damit der ModulerLoader2 ein Modul erkennt,

muss eine Klasse des Moduls das Interface ModuleInterface implementieren. Es enthalt

Methoden zum Aktivieren und Deaktivieren sowie zum Identifizieren des Moduls. Die

Manifest-Datei die sich zusammen mit allen Klassen und den benotigten Ressourcen

in dem Modul-jar-Archiv befindet, verweist auf diese Klasse. Bei den Modulen wird

zwischen externen und internen unterschieden, wobei es nur darum geht, ob das Mo-

dul ein eigenstandiges jar-Archiv oder Teil des argouml.jar ist. Die externen Module

mussen sich in einem Unterodner mit dem Namen”ext“ im Programmordner befinden,

damit sie vom”Module Loader“ gefunden werden. Sobald ein Modul aktiviert ist, kann

es nicht mehr vom Rest von ArgoUML unterschieden werden. Es kann somit auf alle

Programmierschnittstelle (APIs) der Subsysteme und anderer Module zugreifen.

Abbildung 3.1: Wichtige Bestandteile des Modul-Subsystems

3.2 Modell-Subsystem

Das Modell-Subsystem wurde geschaffen, um allen anderen Komponenten von

ArgoUML konsistente Schnittstellen bereitzustellen, mit denen Manipulationen des

”model repository“ moglich sind. So ist es fur die Komponenten uninteressant, ob

NetBeans Model Data Repository (MDR), Novosoft UML Library (NSUML) oder ei-


ne andere Implementerieung verwendet wird. Fur das UML 1.3 Metamodel wurde die

NSUML Bibliothek verwendet und fur das 1.4 Metamodel setzt man jetzt auf eine Im-

plementierung, die NetBeans MDR nutzt. Die Manipulationen am Modell erfolgen uber

so genannte Factory- und Helper-Klassen. Die Factories dienen im Allgemeinen zum

Erschaffen neuer Modellelemente, und die Helper bieten die Moglichkeit die Modellele-

mente zu verandern. Der Zugriff auf diese Klassen erfolgt uber statische Methoden der

Klasse org.argouml.model.Model. Sie ist es auch, die entscheidet welche der oben ge-

nannten Implementationen genutzt wird. Dies ist moglich, da jede Implementierung die

selben Factory- und Helper-Klassen bietet und ihre Methoden durch Interfaces vorgege-

ben werden. Zu den wichtigsten dieser Klassen gehoren CoreHelper und CoreFactory. So

kann man z. B. mit Model.getCoreHelper().setName(handle, name) den Namen eines

Modellelementes andern oder mit Model.getCoreFactory().buildAttribute(model,

type) ein neues Attribut erzeugen. Andere wichtige Klassen sind die in Abbildung 3.2

dargestellten ModelManagementHelper und ModelManagementFactory. Mit ihnen kann

man z. B. alle Modellelemente eines bestimmten Typs ermitteln oder ein neues UML

Package erzeugen. Eine weitere wichtige Klasse des Modell-Subsystems ist Facade. Wie

Abbildung 3.2: Beispiel fur Factories und Helper

der Name schon andeutet, ist sie eine Umsetzung des Fassaden-Entwurfsmusters (engl.

Facade). Der Zugriff auf sie erfolgt uber Model.getFacade() und sie erlaubt nur einen

lesenden Zugriff auf das Modell.

3.3 Internationalisierung

Die Internationalisierung, auch i18n genannt, ist ein Infrastruktur Subsystem von

ArgoUML und es steht anderen Subsystemen zur Verfugung um Zeichenketten zu

ubersetzen. Alle Zeichenketten die in der GUI auftreten, werden in”property fi-

les“ unter einer Kennung abgelegt und diese Dateien werden wahrend des Pro-

18 3.4 Build-Prozess

grammstarts in die PropertyResourceBundles geladen. Die Syntax der Kennungen ist

wort1.wort2.wort3, wobei wort1 der erste Teil des Namens der Datei ist, in dem sich

die Kennung befindet. Es gibt Dateien fur Labels, Menus, Tabs etc. und alle haben die

Endung”properties“. Dateien die zu einer anderen Lokalisierung als der der Standard-

sprache US-Englisch gehoren, bekommen einen Namenszusatz um die entsprechende

Sprache identifizieren zu konnen. Die deutschen Lokalisierungsdateien bekommen z. B.

”de“ angehangt. Listing 3.1 zeigt exemplarisch einen Teil einer solchen Datei.

tab.appearance = Appearance

tab.checklist = Checklist

tab.checklist.warning = Warning! What items you check is not saved

tab.checklist.description = Description

tab.constraints = Constraints

tab.documentation = Documentation

Listing 3.1: Auszug aus der tab.properties

Die Kennungen werden in der GUI als Parameter fur die Lokalisierungsmethode lo-

calize verwendet (vgl. Listing 3.2), die wahrend der Laufzeit des Programms die zu

ihnen passenden Zeichenketten der gewahlten Sprache findet und ausgibt. Die Lo-

kalisierungsmethode wird von der Klasse org.argouml.i18n.Translator als statische

Methode bereitgestellt.

import org.argouml.i18n.Translator;

...

String localized = Translator.localize("tab.appearance")

...

Listing 3.2: Verwendung des Internationalisierungs Subsystems

Die Dateien fur die Standardsprache US-Englisch befinden sich in ArgoUML unter

org.argouml.i18n. Alle anderen Sprachen sind als eigenstandige Projekte konzipiert,

die als Module in ArgoUML integriert werden. So ist es ohne großere Probleme

moglich, ArgoUML um neue Sprachen zu erweitern.

3.4 Build-Prozess

ArgoUML verwendet fur den Build-Prozess Apache Ant, um u. a. die einzelnen

Bestandteile von ArgoUML zu kompilieren und aus den Class-Dateien verschiedene

Jar-Archive zu erstellen. Ant ist ein in Java geschriebenes Build-Tool des Jakarta-

Projekts1, einem Teil der Apache Software Foundation, und steht unter der Apache

1http://jakarta.apache.org

http://jakarta.apache.org


Software License. Es erfreut sich großer Beliebtheit im Java Umfeld und in Publika-

tionen wie [Edl02] wird es auch als Nachfolger von make in diesem Bereich bezeichnet.

Ein Grund dafur ist nicht nur die Flexibilitat von Ant, sondern sicherlich auch die gute

Integration in Entwicklungsumgebungen (Integrated Development Environment) wie

Eclipse und NetBeans. Ant ließt aus einer XML-Datei (build.xml) die Regeln daruber,

welche Kommandos worauf angewendet werden sollen. Zu diesen Kommandos, die

in Ant Tasks genannt werden, gehoren u. a. der Aufruf verschiedener Java Compiler,

Zugriff auf Versionsverwaltungen, Kopierkommandos und das Erstellen verschiedener

Archive. Tasks werden in Anweisungsblocken, so genannten Targets gruppiert und

bilden einzelne Arbeitsschritte, die auch von anderen Arbeitsschritten abhangen

konnen. In ArgoUML gibt es neben der Haupt-Build-Datei mit einer Vielzahl von

Targets noch zwei kleinere fur das Model Subsystem und die MDR Implementierung

des Model Subsystems, die von der Hauptdatei verwendet werden. Ferner hat jedes

Modul seine eigene build.xml-Datei. Weitere Informationen uber Ant erhalt man in

der offiziellen Dokumentation2 oder in Buchern wie [Mat05] oder [Edl02], welche auch

als Basis fur meine Ausfuhrungen und Arbeiten mit Ant dienten.

3.5 Besonderheiten und Richtlinien

Beim Programmieren an ArgoUML bzw. an einem Modul fur ArgoUML gibt es einige

Besonderheiten bzw. Richtlinien die ein Entwickler beachten sollte. Im folgenden sollen

einige der wichtigsten noch kurz besprochen werden.

Die Versionsnummer von ArgoUML setzt sich nach dem folgendem Schema zusam-

men: Hauptversionsnummer.Nebenversionsnummer.Revisionsnummer. Die Hauptvertsi-

onsnummer ist noch immer eine 0, was jedoch nicht darauf hindeutet, dass die Ent-

wicklung noch nicht weit fortgeschritten ist, sondern vielmehr, dass selbst nach fast

acht Jahren Entwicklung noch nicht die gesteckten Ziele erreicht wurden. Eine stabile

Version, die von jedem genutzt werden kann, tragt immer eine gerade Nebenversions-

nummer, wie z. B. 0.22. Falls in einer solchen Version Fehler auftreten, die dringend

beseitigt werden mussen, bekommt die verbesserte Version eine entsprechende Revi-

sionsnummer angehangt, so z. B. 0.22.1. Entwicklerversionen tragen immer ungerade

Nebenversionsnummer. So wird in den 0.23.* Versionen an Verbesserungen bzw. Erwei-

terungen gearbeitet, die schließlich zur Veroffentlichung der nachsten stabilen Version

0.24 fuhren werden.

Der Programmierstil in ArgoUML basiert auf den”Code Conventions for the Java

2http://ant.apache.org/manual/index.html

http://ant.apache.org/manual/index.html

20 3.5 Besonderheiten und Richtlinien

Programming Language“3 von Sun Microsystems mit einigen Erweiterungen. Demnach

mussen etwa alle Klassen, Methoden und Variablen mit Javadoc Kommentaren verse-

hen werden und innerhalb von Methoden sollen keine Kommentare geschrieben werden.

Wenn in einer Methode etwas komplexeres geschieht, was einer Erklarung bedarf, soll

dieser Teil nach Moglichkeit in eine eigene Methode auslagert werden und diese einen

entsprechenden Kommentar bekommen. Eine weitere wichtige Erweiterung der”Code

Conventions“ ist der Umgang mit veralteten public oder protected Klassen, Metho-

den und Attributen. Bevor man solche loschen darf, mussen sie fur eine stabile Version

als deprecated markiert sein. Denn nur so ist es moglich, dass Modul-Entwickler ih-

re Anpassungen wahrend den Entwicklerversionen von ArgoUML vornehmen konnen

und aktualisierte Module zusammen mit einer neuen stabilen Version von ArgoUML

erscheinen konnen. Des Weiteren ist es auch fur die Entwicklung von ArgoUML selbst

wichtig, um genugend Zeit fur entsprechende Anpassungen und Test an abhangigen

Programmteilen zu haben. Fur zusatzliche Regeln zum Programmierstil, zum Umgang

mit dem Subversion Repository und zu den Bestimmungen uber die Nutzung externer

Bibliotheken, soll an dieser Stelle auf das”Standards for coding“ Kapitel in [TK06]

verwiesen werden.

Um Meldungen zum Suchen von Fehlern oder andere Informationen uber den Pro-

grammablauf auf der Kommandozeile auszugeben, kann man das Logging Subsystem

von ArgoUML verwenden. Dieses System nutzt log4j4 fur seine Aufgabe. Da man im

ArgoUML Quellcode laut [TK06] kein System.out.println verwenden soll, ist es wich-

tig zu wissen, wie man das Logging System in eigenen Klassen nutzen kann. Der fol-

gende Quellcode soll das kurz demonstrieren:

// Klassendefinition des Loggers importieren

import org.apache.log4j.Logger;

public class deineKlasse {

// den Logger erzeugen

private static final Logger LOG =

Logger.getLogger(deineKlasse.class);

public void eineMethode () {

// eine Debugmeldung ausgeben

LOG.debug("Debug -Test!");

}

}

Listing 3.3: Verwendung des Logging Subsystems

3http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html4http://jakarta.apache.org/log4j/

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

http://jakarta.apache.org/log4j/


Eine Ubersicht uber die verschiedenen Level der Log-Eintrage befindet sich ebenso

wie eine Erklarung zum Aktivieren der verschiedenen Moglichkeiten des Logging

in [TK06]. Eine sehr einfache Moglichkeit das Logging zu aktivieren, ist uber einen der

vorgefertigten Targets der build.xml Datei von ArgoUML. So startet ./build debug

ArgoUML von den kompilierten Quellen und aktiviert das Debug-Level Logging,

worauf alle Debug-Meldungen in der Konsole ausgegeben werden.

Kapitel 4

ArgoUML Pattern-Wizard

Nachdem in den vorangegangenen Kapiteln ArgoUML und dessen interner Aufbau

erklart wurden, soll nun genauer auf den entwickelten Pattern-Wizard eingegan-

gen werden. Dazu werden die wichtigsten Entwicklungsschritte erlautert und die

Moglichkeiten des Wizards ausfuhrlich beschrieben.

4.1 Implementierung

4.1.1 Vorbereitungen

Bevor mit der eigentlichen Entwicklung des Moduls begonnen werden kann, sind ein

paar Vorbereitungen notig. Als erstes benotigt man den Quellcode von ArgoUML. Man

konnte den zu jeder Version zum Download bereitgestellten Quellcode nutzen. Jedoch

ist es besser sich den aktuellsten Code aus dem Subversion Repository auszuchecken.

Da fur die Entwicklung Eclipse verwendet wurde, konnten die vom ArgoUML Projekt

bereitgestellten”Team Project Set“ Dateien genutzt werden. Es werden etwa 30MB

Quellcode und Bibliotheken heruntergeladen und in verschiedene Eclipse-Projekte

aufgeteilt. Auch die notigen Einstellungen fur Eclipse werden vorgenommen. Eine

genaue Beschreibung dazu befindet sich im Kapitel”Setting up Eclipse 3“ des

Entwickler-Kochbuchs.

4.1.2 Erzeugen der Ant Konfigurationsdatei

Nachdem der Quellcode heruntergeladen wurde und ArgoUML aus Eclipse heraus kom-

piliert und gestartet werden kann, muss fur das zu erstellende Modul ein neues Java-

24 4.1 Implementierung

Projekt angelegt werden. In diesem Projekt wird als erstes eine Konfigurationsdatei

fur Ant benotigt. Die fur den Pattern-Wizzard erstellte build.xml befindet sich im An-

hang A.1. Die Build-Datei beginnt mit einer obligatorischen, XML-typischen Anwei-

sung, die die Ant Version und die verwendete Kodierung festlegt. Anschließend erfolgt

in Zeile 17 die Definition des Projektes mit dem Namen”argouml-pattern-wizard“ und

der Festlegung von usage als Standardtarget, falls Ant ohne explizite Angabe eines

Targets aufgerufen wird. Die einzelnen Aufgaben die Ant erfullen soll, sind in separate

Targets aufgeteilt, wobei jedes von ihnen seinen entsprechenden Vorganger mit Hilfe

des depends-Attributs aufruft. Dadurch entsteht eine lineare Verkettung der einzelnen

Targets. Das Projekt enthalt zehn Targets und importiert einen weiteren aus einer an-

deren Build-Datei. Dieser Import erfolgt in Zeile 23 mit dem import-Task. Die Auftei-

lung der Build-Datei orientiert sich an der im Abschnitt”Developing in a subproject“

des Entwickler-Kochbuchs fur alle Unterprojekte geforderten Struktur und erweitert

diese um einige zusatzliche Targets. Das fur die Entwicklung wohl wichtigste Target

ist debug in Zeile 166. Seine Aufgabe ist es ArgoUML im debug-Modus zu starten, um

die Funktion des Moduls zu testen. Um ArgoUML ohne das Logging zu starten nutzt

man den run-Target in Zeile 156. Bevor einer der beiden Targets ArgoUML ausfuhren

kann, muss in Zeile 144 im install-Target das ext-Verzeichnisse fur Erweiterungen

im ArgoUML-Ordner erzeugt werden. Das zuvor im jar-Target (Zeile 120) erzeugte

jar-Archiv des Pattern-Wizards wird anschließend dorthin kopiert. Beim Erstellen des

jar-Archivs wird auch die benotigte manifest.mf Datei erzeugt. In ihr sind der”Class-

Path“ und der Name der Klasse, die das ModuleInterface implementiert, die wich-

tigsten Eintrage. Die Class-Dateien die im jar-Target zum Erstellen des jar-Archivs

benotigt werden, entstehen im compile-Target (Zeile 104) beim Kompilieren des Quell-

codes durch den javac-Task. Doch bevor der Java-Compiler seinen Dienst verrichten

kann, wird der prepare-Target in Zeile 76 ausgefuhrt. Seine Aufgabe ist es im Ord-

ner”build“ einen

”bin“-Ordner anzulegen in dem die Class-Dateien abgelegt werden

konnen. Weiterhin wird der Quellcode des Moduls ebenfalls in den”build“-Ordner ko-

piert (Zeile 81) und dabei werden die im Quellcode befindlichen Token @VERSION@ und

@BUILD@ durch die entsprechenden Zeichenketten ersetzt. So ist sichergestellt, dass die

spater im Pattern-Wizard angezeigten Versionsinformationen auch korrekt sind. Wie

man in Zeile 76 sehen kann ist der prepare-Target von drei weiteren abhangig. Zum

einen vom init-Target (Zeile 28), der verschiedene so genannte Properties definiert,

bzw. diese aus Property-Dateien einließt. Properties sind vergleichbar mit Konstanten.

Sie dienen als Platzhalter fur einen Wert und sobald sie gesetzt sind konnen sie nicht

mehr geandert werden. Der zweite Target von dem prepare abhangt, ist clean (Zeile

180). Er ist dafur verantwortlich die Resultate eines fruheren Durchlaufs zu loschen.

Die dritte Abhangigkeit besteht zum importierten generate-buildnumber-Target, der


in der buildnumber.xml Datei definiert ist. Seine Aufgabe ist es, wie der Name schon

sagt, die Build-Nummer zu erzeugen. Sie besteht aus vier Ziffern, wobei die erste die

Anzahl der Jahre darstellt, die das Modul bereits existiert und die letzten drei stehen

fur die Nummer des Tages an dem das Modul kompiliert wurde. Die Build-Nummer

1242 steht somit fur den Tag 242 des ersten Jahres, in dem das Modul verfugbar ist und

die Nummer 242 steht fur den 30. August. Da Ant keine Tasks fur Kontrollstrukturen

bietet, diese jedoch zum Berechnen der Nummer des Tages notig sind, wird dafur Ant-

Contrib1 eingesetzt. Dabei handelt es sich um eine Sammlung von zusatzlichen Tasks,

die man, nachdem sie per taskdef-Task eingebunden wurden, nutzen kann. Neben den

bereits vorgestellten Targets gibt es noch einen javadoc-Target (Zeile 192) zum Erstel-

len einer Dokumentation und den bereits erwahnten Standardtarget usage (Zeile 54),

der eine Information uber verfugbare Targets ausgibt. Beide benotigen einige Proper-

ties und hangen deshalb ebenfalls vom init-Target ab.

Abbildung 4.1: Abhangigkeiten der Ant Targets

4.1.3 Implementation der Hauptklasse des Moduls

Der nachste Schritt besteht darin eine Klasse zu schreiben, die das ModuleInterface

implementiert. Die Klasse ActionOpenPatternWizard ubernimmt diese Aufgabe und

stellt somit die Hauptklasse dar, die ArgoUMLs ModuleLoader2 erkennt und wahrend

des Programmstarts bzw. nach dem Aktivieren als Modul einbindet. Dafur muss sie

vier Methoden implementieren (vgl. Abbildung 4.2). Zum einen die Methode enable()

um das Modul aktivieren zu konnen, und zum anderen disable() um es bei Bedarf

1http://ant-contrib.sourceforge.net/tasks/

http://ant-contrib.sourceforge.net/tasks/


auch wieder zu deaktivieren. Die anderen beiden Methoden dienen dazu mehr uber das

Modul zu erfahren. So liefert getName() den Namen des Moduls und uber getInfo()

bekommt man je nach Parameter den Autor, eine kurze Beschreibung oder die Version

des Moduls.

Abbildung 4.2: Hauptklasse zum Aktivieren des Pattern-Wizards

Beim Aktivieren des Moduls soll das Menu von ArgoUML um einen Eintrag fur den

Pattern-Wizard im Werkzeuge-Menu erweitert werden. Dazu ist es notig, wie in Lis-

ting 4.1, in der enable()-Methode die GenericArgoMenuBar zu ermitteln. Sie definiert

ArgoUMLs Menuleiste. Uber die getTools()-Methode bekommt man das JMenu-Objekt

des Werkzeug-Menus, welchem man das JMenuItem des Pattern-Wizards anhangen

kann.

public boolean enable () {

GenericArgoMenuBar menubar =

(GenericArgoMenuBar)ProjectBrowser.getInstance ().getJMenuBar ();

menubar.getTools ().add(patternExtMenuItem);

}

Listing 4.1: Menueintrag hinzufugen

Analog muss der Menueintrag auch wieder entfernt werden, wenn das Modul deak-

tiviert wird. Damit ActionOpenPatternWizard auf die Aktion des Nutzers reagieren

kann, muss die Klasse auch einen ActionListener implementieren. Nur so ist es

moglich auf das ausgeloste ActionEvent mit dem offnen des Pattern-Wizards zu

reagieren.

4.1.4 Aufbau der Benutzeroberflache

Wenn der Pattern-Wizard uber”Werkzeuge“ →

”Pattern-Wizard...“ aktiviert wird,

offnet sich ein nicht-modales Dialogfenster. Dieser Dialog wird von der Klasse Pat-

ternWizard (vgl. Abbildung 4.3) erzeugt. Sie ist fur die Interaktion mit dem Benutzer


zustandig und alle von ihm vorgenommenen Anderungen werden an das Datenmodel

weitergegeben. Die Klasse erweitert ArgoDialog welche in ArgoUML fur Dialoge mit

lokalisierten Buttons genutzt wird.

Abbildung 4.3: GUI-Klassen des Pattern-Wizards

Wie Abbildung 4.4 zeigt, ist das Fenster des Pattern-Wizards in drei Bereiche un-

terteilt. Ganz oben befindet sich der Transformationsbereich, in dem uber drei Rei-

ter (Tabs) die Manipulationen an den Klassen vorgenommen werden konnen. Eine

ausfuhrliche Beschreibung der Moglichkeiten in diesen Tabs erfolgt im Abschnitt 4.2.

Unter diesem Bereich befindet sich der Hilfebereich in dem unterschiedlich viele

Tabs geoffnet sein konnen. Einer der immer vorhanden ist, ist der Anleitungs-Tab,

der mit einer Schritt-fur-Schritt-Anleitung die Nutzung des Wizards erklart. Weite-

re Tabs konnen die Informationen uber ausgewahlte Entwurfsmuster enthalten. Sie


werden uber den Button”Zeige Dokumentation“ unterhalb der Liste der verfugbaren

Pattern geoffnet. Die dort dargestellten Informationen stammen aus einer Ubersicht

uber Entwurfsmuster2 des Softwaretechnik Lehrstuhls der Universitat Rostock und

werden in der Dokumentation der Pattern-Packages gespeichert. Im untersten Be-

reich des Pattern-Wizards befinden sich drei Buttons. Einen”Anwenden“-Button,

um die vorgenommenen Manipulationen in ArgoUML zu ubernehmen, einen”Schlies-

sen“-Button, um den Dialog vorubergehend zu schließen (wobei die vorgenommenen

Anderungen nicht verloren gehen) und einen”Zurucksetzen“-Button, um alle vorge-

nommen Anderungen zu verwerfen.

Abbildung 4.4: Benutzeroberflache des Pattern-Wizards

4.1.5 Konzeption des Datenmodels

Alle Daten, die in der Benutzeroberflache dargestellt werden, stammen von einem Ob-

jekt der Klasse CombinePattern. Es speichert alle Daten der an der Kombination betei-

ligten Modellelemente und samtliche vom Nutzer vorgenommenen Anderungen an ih-

nen. Des Weiteren beinhaltet die Klasse die gesamte Logik zum Manipulieren und Kom-

binieren der Entwurfsmuster und der damit verbundenen Interaktion mit ArgoUML.

2http://wwwswt.informatik.uni-rostock.de/deutsch/Infothek/Entwurfsmuster/patterns

http://wwwswt.informatik.uni-rostock.de/deutsch/Infothek/Entwurfsmuster/patterns


Um dem Nutzer die Moglichkeit zu geben die von ihm vorgenommen Anderungen

wieder ruckgangig zu machen, werden die Anderungen nicht sofort in ArgoUML um-

gesetzt, sondern bis zum Betatigen des”Anwenden“-Buttons gespeichert. Dazu wer-

den, wie in [Sch02] Kapselobjekte fur Klassen, Attribute, Methoden und Relationen

von ArgoUML und Befehlsobjekte fur die Anderungen des Nutzers verwendet. In-

stanzen der Klassen ...Wrapper bilden die Kapselobjekte und enthalten jeweils ein

unverandertes ArgoUML Modellelement. Diesen Kapselobjekten werden Befehlsobjek-

te vorgeschaltet falls der Nutzer Modifikationen (...OperatorModify) bzw. Kombina-

tionen (...OperatorMerge) vornimmt. Der Vorteil bei diesem Vorgehen ist, dass das

Ruckgangig Machen von Manipulationen des Nutzers ohne Probleme moglich ist. Da-

zu wird einfach das letzte Befehlsobjekt geloscht. Sollten keine Befehlsobjekte mehr

vorhanden sein, so befindet sich das Modellelemente in seinem Ursprungszustand.

Abbildung 4.5: Kombination von Kapsel- und Befehlsobjekten

Mit Hilfe des Beispiels in Abbildung 4.5 soll die Verwendung der Kapsel- und

Befehlsobjekte genauer beschrieben werden. Ausgangspunkt dieses Beispiels sind

zwei Klassen (UMLClass) eines ArgoUML Klassendiagramms. Diese werden jeweils

in einen ClassWrapper verpackt um einen einheitlichen Zugriff auf die Eigenschaften

des Modellelementes sicherzustellen. Wenn der Nutzer diese beiden Klassen kombi-

niert, wird den beiden Kapselobjekten ein ClassOperatorMerge vorangestellt. Dieses

Befehlsobjekt sorgt fur die Kombination der Eigenschaften beider Vorgangerobjekte.

Wenn der Nutzer anschließend etwa den Namen der entstandenen Klasse andert, wird

ein weiteres Befehlsobjekt, in diesem Fall ein ClassOperatorModify, davor geschaltet.

Anfragen zum ermitteln des Namens wurden dann von diesem Objekt beantwortet und

alle anderen Anfragen wurden an das dahinter liegende ClassOperatorMerge-Objekt

weitergeleitet.

30 4.2 Moglichkeiten des Pattern-Wizards

4.2 Moglichkeiten des Pattern-Wizards

Die Manipulationsmoglichkeiten des Pattern-Wizard sind im Transformationsbereich

auf drei Reiter aufgeteilte. Im Entwurfsmuster-Tab (Abbildung 4.4) werden alle

verfugbaren Entwurfsmuster aufgelistet. Zu diesen kann man sich das Klassendiagramm

in ArgoUML anzeigen lassen und die Informationen die zu ihnen hinterlegt sind, konnen

im unteren Bereich des Wizards, neben dem Hilfe-Reiter eingeblendet werden. Aus die-

ser Liste wahlt man die Entwurfsmuster aus, die kombiniert werden sollen. Die Auswahl

kann per Drag&Drop oder uber die Buttons in der Mitte erfolgen. Fur das aus der Kom-

bination hervorgehende Entwurfsmuster muss ein neuer Name festgelegt werden. Es ist

ebenfalls moglich bereits bestehende Klassen mit Entwurfsmustern zu kombinieren.

Dazu muss man das Kontrollfeld”Umwandeln der ausgewahlten ArgoUML Klassen“

aktivieren. Dabei werden alle zu dem Zeitpunkt in ArgoUML selektierten Klassen mit

ihren Attributen, Methoden und Relationen in den Pattern-Wizard ubernommen und

konnen im Weiteren kombiniert und manipuliert werden. In diesem Fall ist es nicht

notig, einen neuen Namen anzugeben, da das Ergebnis in das bestehende Klassenmo-

del ubernommen wird.

Abbildung 4.6: Komponenten-Tab des PatternWizards

Uber den Komponenten-Tab (Abbildung 4.6) konnen sowohl die Klassen der aus-

gewahlten Entwurfsmuster als auch ihre Attribute und Methoden transformiert werden.


Zu diesem Zweck befinden sich auf der linken Seite zwei List-Boxen. In der linken wer-

den alle Klassen entsprechend ihrer Zugehorigkeit zu den Entwurfsmustern gruppiert

angezeigt und in der List-Box daneben werden die Attribute und Methoden der gerade

selektierten Klasse dargestellt. In der Klassen-Liste werden, falls die entsprechende Op-

tion im Entwurfsmuster-Tab aktiviert wurde, auch die zuvor in ArgoUML ausgewahlten

Klassen aufgefuhrt. Per Drag&Drop konnen die einzelnen Elemente kombiniert werden.

Dabei werden die ursprunglichen Elemente aus der Liste entfernt und das kombinierte

Element unter”geandert“ eingefugt. Dabei ist zu beachten, dass das Element welches

auf ein anderes gezogen wird, den Namen des neuen Elementes bestimmt. Wie im vor-

hergehenden Reiter ist es auch hier moglich die Klassendiagramme der aufgefuhrten

Klassen in ArgoUML anzuzeigen. Ferner konnen Komponenten dupliziert werden und

bereits vorgenommene Anderungen konnen wieder ruckgangig gemacht werden. Auf der

rechten Seite des Komponenten-Tab konnen der Name und die zugewiesenen Stereoty-

pen der gerade selektierten Klasse bzw. des selektierten Merkmals verandert werden.

Der dritte Reiter des Transformationsbereichs ist der Beziehungen-Tab (Abbil-

dung 4.7). Sein Aufbau ist ahnlich dem des Komponenten-Tabs. Auf der linken Seite

werden alle zwischen den Klassen bestehenden Assoziationen, Aggregationen, Kom-

positionen und Vererbungsbeziehungen in einer List-Box dargestellt. Die Beziehungen

die zwischen den selben Klassen bestehen, konnen per Drag&Drop kombiniert wer-

den. Auf der rechten Seite konnen wieder die Eigenschaften der Beziehungen verandert

werden. Fur alle Beziehungen konnen sowohl der Name als auch die zugewiesenen Ste-

reotypen angepasst werden und bei Assoziationen konnen zusatzlich die Rollen und

Multiplizitaten modifiziert werden. Selbstverstandlich ist es auch hier moglich alle vor-

genommen Transformationen ruckgangig zu machen und die Entwurfsmuster in denen

die Beziehungen vorkommen in ArgoUML aufzurufen. Nachdem alle Transformatio-

nen vorgenommen wurden, konnen sie durch den”Anwenden“-Button in ArgoUML

ubernommen werden. Es ist jedoch zu beachten, dass diese Aktion endgultig ist.

4.3 Beispielszenario

Anhand eines Beispiels soll im folgenden die Nutzung des Pattern-Wizards noch einmal

verdeutlicht werden. Dazu wird das leicht verstandliche Uhrenbeispiel aus [For01] in

einer etwas abgewandelten Form verwendet.

Ausgangspunkt dieses Szenarios ist ein Programm, welches die Uhrzeit in zwei ver-

schiedenen Arten auf dem Bildschirm darstellt. Zum einen als ein Display mit Ana-

loguhr und zum anderen als eins mit Digitaluhr. Abbildung 4.8 zeigt die wichtigsten

32 4.3 Beispielszenario

Abbildung 4.7: Beziehungen-Tab des PatternWizards

Klassen dieses Programms. Die Klasse Uhrwerk enthalt die Logik der Uhr und die

Klassen AnalaguhrDisplay und DigitaluhrDisplay sind fur die graphische Darstel-

lung der Uhrzeit verantwortlich. Sobald sich die Uhrzeit in Uhrwerk andert, ruft es die

repaint-Methode der beiden Displays auf, damit diese die Anzeigen aktualisieren. Zum

Abfragen der aktuellen Uhrzeit steht ihnen die Methode getTime zur Verfugung.

Das Problem an dieser Umsetzung ist die fehlende Flexibilitat. Sobald das Pro-

gramm um eine weitere Anzeige erweitert werden soll, muss auch die Implementie-

rung von Uhrwerk angepasst werden. Man erkennt jedoch leicht, dass der Einsatz

des in [GHJV04] beschriebenen Beobachter-Entwurfsmusters dieses Problem beheben

Abbildung 4.8: Wichtige Klassen des Uhrenbeispiels


konnte. Mit Hilfe des Pattern-Wizards ist es auf einfache und schnelle Weise moglich

den bestehenden Entwurf mit dem im Abbildung 1.3 dargestellten Observer zu kombi-

nieren. Dazu mussen die Klassen aus Abbildung 4.8 markiert werden. Anschließend

offnet man den Pattern-Wizard und setzt im Entwurfsmuster-Tab den Haken bei

”Umwandeln der ausgewahlten ArgoUML Klassen“. Nachdem man in der Liste der

verfugbaren Entwurfsmuster den Observer ausgewahlt hat und ihn per Drag&Drop der

Liste auf der rechten Seite hinzugefugt hat, kann man im Komponenten-Tab mit der

Kombination der Klassen beginnen. Da das Uhrwerk das beobachtete Objekt ist, wird

es mit ConcreteSubject kombiniert. Dazu wird in der linken List-Box Uhrwerk auf Con-

creteSubject gezogen. Die daraus entstehende Klasse tragt weiterhin den Namen Uhr-

werk und besitzt jetzt zwei Methoden, die die selbe Funktion haben und daher ebenfalls

per Drag&Drop kombiniert werden. Die beiden Displays des ursprunglichen Entwurfs

konnen als Beobachter des Uhrwerks aufgefasst werden. Das bedeutet, dass sie mit

der Klasse ConcreteObserver kombiniert werden mussen. Da davon jedoch nur eine im

Entwurfsmuster zur Verfugung steht, muss zuerst mit Hilfe des”Duplizieren“-Buttons

eine Kopie erzeugt werden. Danach mussen nur noch die im ursprunglichen Entwurf

nicht enthaltenen Klassen Subject und Observer uber den Eigenschaftenbereich auf der

rechten Seite einen passenderen Namen erhalten. Die erste wird in AbstraktesUhrwerk

und die andere in AbstarktesDisplay umbenannt. Danach wird im Relationen-Tab

die Rolle dieser Assoziation von observer in Anzeige umbenannt. Abschließend wer-

den die Assoziationen zwischen Uhrwerk und AnaloguhrDisplay respektive Uhrwerk und

DigitaluhrDisplay kombiniert und die Rolle subject in Uhrwerk umbenannt. Nach-

dem alle Transformationen vorgenommen wurden und der Pattern-Wizard diese auf

das ArgoUML Diagramm angewendet hat, muss ggf. noch ein kleine Korrektur durch

den Nutzer vorgenommen werden. Die Methoden repaint vom AnaloguhrDisplay und

DigitaluhrDisplay konnen geloscht werden, falls die von AbstraktesDisplay geerbte

bereits implementiert ist.

Das Ergebnis der Kombination des ursprunglichen Entwurfs mit dem Beobachter-

Entwurfsmuster ist in Abbildung 4.9 dargestellt. Der neue Entwurf ist nun viel

flexibler. Weitere Displays konnen jetzt ohne Probleme dem Programm hinzugefugt

werden. Sie mussen sich nur mit der Methode Attach beim Uhrwerk anmelden und

erhalten dann bei jedem Zeitwechsel von der Methode Notify die Botschaft repaint.

34 4.3 Beispielszenario

Abbildung 4.9: Uhrenbeispiel in Kombination mit Beobachter-Entwurfsmuster

Kapitel 5

Schlussbemerkungen

5.1 Erweiterungsmoglichkeiten

Wie eingangs erlautert, stellt der ArgoUML Pattern-Wizard eine Weiterentwicklung

der Pattern-Erweiterung fur Rational Rose aus [Man00] und [Sch02] dar. Ein Großteil

der Funktionalitat der ursprunglichen Implementierung wurde umgesetzt und mit

besonderem Fokus auf objektorientierte Programmierung und eine leichtere Nutz-

barkeit erweitert. Im folgenden soll kurz auf Erweiterungsmoglichkeiten eingegangen

werden, die aus verschiedenen Grunden noch nicht implementiert wurden, jedoch

einen Mehrwert fur den Pattern-Wizard darstellen wurden und daher in zukunftigen

Versionen integriert werden sollten.

5.1.1 Design by Contract

In [Sch02] wurden Klasseninvarianten fur die Komponenten eines Entwurfsmusters

und Vor- und Nachbedingungen fur die Methoden dieser Komponenten genutzt. Durch

diese formale Spezifikation ist es leichter moglich Fehler im Model zu entdecken. Aus

Zeitgrunden war es mir nicht moglich diese Konzepte im Pattern-Wizard umzusetzen.

Es ware jedoch moglich, dazu das in ArgoUML integrierte Dresden OCL Toolkit

zu nutzen und aus dem Pattern-Wizard heraus den OCL Editor zu offnen, um

entsprechende”Vertrage“ zu definieren.

36 5.2 Fazit

5.1.2 Pattern-Kardinalitat

Die ebenfalls in [Sch02] eingefuhrte Pattern-Kardinalitat zur Definition der erlaubten

Anzahl an Vervielfaltigungen einer Komponente, eines Attributes bzw. einer Methode

ist dazu geeignet, dass Verstandnis des Anwenders fur ein Entwurfsmuster zu ver-

bessern und einfache Abhangigkeiten zwischen den Elementen zu definieren. Dieses

Konzept wurde im Pattern-Wizard noch nicht umgesetzt, da es nicht moglich ist

die vorhandenen Model-Elemente um neue Eigenschaften zu erweitern und ich eine

Losung uber Stereotypen fur nicht praktikabel halte. Dieses Problem konnte jedoch

mit der folgenden Erweiterungsmoglichkeit beseitigt werden.

5.1.3 Integration der Entwurfsmuster-Bibliothek

Eine weitere Verbesserungsmoglichkeit ware die Bibliothek mit den Entwurfsmustern

in den Pattern-Wizard zu integrieren, so dass nicht immer das ArgoUML Projekt

mit der Entwurfsmuster-Bibliothek geladen sein muss. Der Pattern-Wizard konnte

bei Bedarf, wenn z. B.”Zeige Entwurfsmuster“ gewahlt wurde, dieses generieren. Die

Entwurfsmuster konnten aber auch bei der Kombination genutzt werden, ohne das

sie zuvor erzeugt werden mussten. Diese Umsetzung hatte den Vorteil, dass das zuvor

erwahnte Problem des Speicherns der Pattern-Kardinalitat gelost ware. Diese Infor-

mationen konnten dann in den Wizard integriert und entsprechend dargestellt werden.

Durch die Integration wurde sich jedoch ein neues Problem ergeben. Der Anwender

konnte nicht mehr wie in der aktuellen Version des Wizards eigene Entwurfsmuster

definieren, die dann genutzt werden konnen. Durch die Moglichkeit eine zusatzliche

externe Bibliothek zu nutzen und zur Verwaltung dieser ein Werkzeug bereitzustellen,

konnte auch dieses Problem umgangen werden.

5.2 Fazit

Trotz der beschriebenen Erweiterungsmoglichkeiten stellt der Pattern-Wizard in seiner

jetzigen Version bereits ein praktisches und leicht zu benutzendes Werkzeug dar, um

in ArgoUML mit Entwurfsmustern zu arbeiten. Damit konnen Softwareentwickler, die

nicht die Moglichkeit haben auf kommerzielle CASE-Tools zuruckzugreifen bzw. dies

aus bestimmten Grunden nicht wollen, nun das frei verfugbare ArgoUML in Verbin-

dung mit dem Pattern-Wizard nutzen. Sie konnen damit bestehende Softwaresyste-

me uberarbeiten und Entwurfsmuster integrieren oder neue Anwendungen mit Hilfe

5 Schlussbemerkungen 37

von Entwurfsmustern realisieren. Dazu wurde eine Entwurfsmuster-Bibliothek aus den

in [GHJV04] vorgestellten Entwurfsmustern zusammengestellt, wobei evt. nicht alle

von ihnen spezifisch genug sind, um effektiv mit dem Pattern-Wizard genutzt zu wer-

den. Diese Entscheidung soll jedoch dem Anwender uberlassen bleiben. Die Bibliothek

kann jederzeit um weitere Muster erweitert werden, so dass es dem Nutzer moglich

ist, sich die fur seine Bedurfnisse passenden Entwurfsmuster zusammenzustellen. Ne-

ben seiner eigentlichen Funktion kann der Wizard auch als eine Art Pattern-Browser

verwendet werden. Man kann sich zu den in der Bibliothek vorhandenen Entwurfs-

mustern die Struktur anzeigen lassen und wird zusatzlich mit Informationen uber

Funktion und Verwendung versorgt. Der Pattern-Wizard wurde von mir unter der

BSD-Lizenz als Projekt auf Tigris.org veroffentlicht, um so eine freie Verfugbarkeit

und die stetige Weiterentwicklung des Wizards zu ermoglichen. Das Projekt ist unter

http://argouml-pattern-wizard.tigris.org erreichbar. Falls der Pattern-Wizard

sowohl von den Nutzern als auch von den Entwickler gut angenommen wird, ist auch

eine feste Integration in ArgoUML denkbar.

http://argouml-pattern-wizard.tigris.org

Anhang A

Anhang

A.1 Apache Ant Konfigurationsdatei (build.xml)

1 <?xml version="1.0" encoding="ISO-8859-1"?>















10 











<project name="argouml-pattern-wizard" default="usage" basedir=".">



20 





<import file="buildnumber.xml"/>







<target name="init">

40 A.1 Apache Ant Konfigurationsdatei (build.xml)

<echo message="Initialising the needed properties ..."/>

30 

<property name="argo.root.dir" value="${basedir}/.."/>



<property file="${argo.root.dir}/argouml/eclipse-ant-build.properties"/>



<property file="module.properties"/>



<property file="${argo.root.dir}/argouml/default.properties"/>



40 <path id="argo.classpath">



<fileset dir="${argo.build.dir}">

<include name="*.jar"/>

</fileset>

</path>



<property file="${user.home}/.argo.ant.properties"/>

<property file="${user.home}/.ant.properties"/>

</target>

50





<target name="usage" depends="init" description="Display usage informations.">

<echo message="’${module.name}’ Build file"/>

<echo message="-----------------------------------------------------------"/>

<echo message="ant [options] [target]"/>

<echo message=" "/>

<echo message="Available targets:"/>

60 <echo message=" "/>

<echo message=" compile --> compiles the source code to the tree"/>

<echo message=" below the ${module.build.dir} folder"/>

<echo message=" package --> generates the ${module.jarfile.name}"/>

<echo message=" run --> runs ArgoUML with ${module.jarfile.name}"/>

<echo message=" install --> moves the created ${module.jarfile.name}"/>

<echo message=" into the ArgoUML ext folder."/>

<echo message=" usage --> show this message (default target)"/>

<echo message=" "/>

<echo message="-----------------------------------------------------------"/>

70 <echo message=" See the comments inside the build.xml file for more details"/>

</target>



A Anhang 41





<target name="prepare" depends="init, clean, generate-buildnumber">

<echo message="Preparing the build directories ..."/>



<mkdir dir="${module.build.dest.dir}"/>

80 

<copy todir="${module.build.src.dir}">

<fileset dir="${module.src.dir}"/>

<filterset>



<filter token="VERSION" value="${module.version}"/>

<filter token="BUILD" value="${build.number}"/>

</filterset>

</copy>



90 <mkdir dir="${module.build.i18n.dir}"/>

<copy todir="${module.build.i18n.dir}">

<fileset dir="${module.src.i18n.dir}"/>

</copy>



<mkdir dir="${module.build.image.dir}"/>

<copy todir="${module.build.image.dir}">

<fileset dir="${module.src.image.dir}"/>

</copy>

</target>

100





<target name="compile" depends="prepare" description="Compile the sources.">

<echo message="Compiling the sources ..."/>



<javac srcdir="${module.build.src.dir}" destdir="${module.build.dest.dir}"

optimize="${optimize}" verbose="${verbose}" debug="${debug}"

deprecation="${deprecation}" excludes="${excluded.files}"

110 source="${source.level}" target="${target.level}">

<classpath>

<path refid="argo.classpath"/>

</classpath>

</javac>

</target>





42 A.1 Apache Ant Konfigurationsdatei (build.xml)



120 <target name="jar" depends="compile" description="Create the module jar file.">

<echo message="Creating the module jar file ..."/>



<jar jarfile="${module.jarfile}" basedir="${module.build.dest.dir}"

includes="${included.files}" excludes="${excluded.files}">



<manifest>

<attribute name="Class-Path" value="argouml.jar"/>

<section name="${main.class.name}">

<attribute name="Extension-name" value="module.${module.name}"/>

130 <attribute name="Specification-Title" value="ArgoUML Dynamic Load Module"/>

<attribute name="Specification-Version" value="${module.version}"/>

<attribute name="Specification-Vendor" value="University of California"/>

<attribute name="Implementation-Title" value="${module.name} - ArgoUML Module"/>

<attribute name="Implementation-Version" value="${module.version}"/>

<attribute name="Implementation-Vendor" value="Rene Lindhorst"/>

</section>

</manifest>

</jar>

</target>

140





<target name="install" depends="jar"

description="Move the created jar into the ArgoUML ext directory.">

<echo message="Installing the module ..."/>



<mkdir dir="${argo.build.ext.dir}"/>



150 <copy file="${module.jarfile}" todir="${argo.build.ext.dir}"/>

</target>







<target name="run" depends="install"

description="Run ArgoUML with the created module.">

<echo message="Executing ArgoUML with the module ..."/>



160 <java jar="${argo.jarfile}" dir="${argo.build.dir}" fork="yes"/>

</target>



A Anhang 43





<target name="debug" depends="install"

description="Run ArgoUML with the created module in debug mode.">

<echo message="Executing ArgoUML with the module in debug mode ..."/>

<echo message="+ ${module.name} v${module.version} (build ${build.number})"/>

170 

<java jar="${argo.jarfile}" dir="${argo.build.dir}" fork="yes">

<sysproperty key="log4j.configuration"

value="org/argouml/resource/full_console.lcf"/>

</java>

</target>







180 <target name="clean" depends="init"

description="Remove files generated by any of the other targets.">

<echo message="Clean up ..."/>



<delete file="${argo.build.dir}/ext/${module.jarfile.name}"/>



<delete dir="${module.build.dir}"/>

</target>



190 



<target name="javadoc" depends="init"

description="Generate the code documentation (API).">

<echo message="Generating the Javadoc ..."/>

<mkdir dir="${module.javadoc.dir}"/>

<javadoc doctitle="${module.name} API Documentation" use="true"

private="true" windowtitle="${module.name} ${module.version}"

author="true" header="" bottom=" c© ${copyright}" splitindex="true"

group="${module.name} ’org.argouml.*’" packagenames="org.argouml.*"

200 sourcepath="${module.src.dir}" destdir="${module.javadoc.dir}"

classpathref="argo.classpath"/>

</target>

</project>



A Anhang 45

A.2 Klassendiagramm des Datenmodels

Literaturverzeichnis

[Bal05] Balzert, Heide: UML 2 kompakt. 2. Auflage. Spektrum Akademischer

Verlag, 2005

[BMR+98] Buschmann, Frank ; Meunier, Regine ; Rohnert, Hans ; Sommer-

lad, Peter ; Stal, Michael: Pattern-orientierte Software-Architektur. Ein

Pattern-System. 2. Auflage. Addison-Wesley, 1998

[Edl02] Edlich, Stefan: Ant - kurz & gut. Koln : O’Reilly Verlag, 2002

[For01] Forbrig, Peter: Objektorientierte Softwareentwicklung mit UML. Fach-

buchverlag Leipzig, 2001

[GHJV04] Gamm, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John:

Entwufsmuster - Elemente wiederverwendbarer objektorientierter Software.

Addison Wesley Verlag, 2004

[Hil] Hillside Group: Home of Patterns Library. http://hillside.net/

patterns/, Abruf: 26.11.2006

[Man00] Mannhaupt, Danko: Integration of Design Patterns into Object-Oriented

Design using Rational Rose, Universitat Rostock, Diplomarbeit, 2000

[Mat05] Matzke, Bernd: Ant - Eine praktische Einfuhrung in das Java-Build-Tool.

2., uberarbeitete und aktualisierte Auflage. Heidelberg : Dpunkt Verlag,

2005

[Mor] Morris, Tom: Frequently asked questions for ArgoUML. http://

argouml.tigris.org/faqs/users.html, Abruf: 22.11.2006

[Rob99] Robbins, Jason E.: Cognitive Support Features for Software Develop-

ment Tools, University of California, Irvine, Diss., 1999. http://argouml.

tigris.org/docs/robbins dissertation/index.html

http://hillside.net/patterns/

http://hillside.net/patterns/

http://argouml.tigris.org/faqs/users.html

http://argouml.tigris.org/faqs/users.html

http://argouml.tigris.org/docs/robbins_dissertation/index.html

http://argouml.tigris.org/docs/robbins_dissertation/index.html

50 LITERATURVERZEICHNIS

[Sch02] Schmacka, Bjorn Rik: Integration von Design Patterns in bestehende

Softwarespezifikationen, Universitat Rostock, Diplomarbeit, 2002

[TK06] Tolke, Linus ; Klink, Markus: Cookbook for Developers of Ar-

goUML: An introduction to Developing ArgoUML. 0.22, Septem-

ber 2006. http://argouml-stats.tigris.org/documentation/pdf/

cookbook/cookbook.pdf

[WTB+06] Wulp, Michiel van d. ; Tolke, Linus ; Bennett, Jeremy ; Oduto-

la, Kunle ; Rueckert, Andreas ; Vanpeperstraete, Philippe ; Ra-

mirez, Alejandro: ArgoUML User Manual: A tutorial and reference de-

scription. 0.22, September 2006. http://argouml-stats.tigris.org/

documentation/pdf/manual/argomanual.pdf

[WTOO06] Wulp, Michiel van d. ; Tolke, Linus ; Oguntimehin, Anthony ;

Odutola, Kunle: ArgoUML Quick Guide: Get started with ArgoUML

0.22. 0.22, September 2006. http://argouml-stats.tigris.org/

documentation/pdf/quick-guide/quickguide.pdf

[ZGK04] Zuser, Wolfgang ; Grechenig, Thomas ; Kohle, Monika: Software

Engineering. Mit UML und dem Unified Process. 2., uberarbeitete Auflage.

Pearson Studium, 2004

http://argouml-stats.tigris.org/documentation/pdf/cookbook/cookbook.pdf

http://argouml-stats.tigris.org/documentation/pdf/cookbook/cookbook.pdf

http://argouml-stats.tigris.org/documentation/pdf/manual/argomanual.pdf

http://argouml-stats.tigris.org/documentation/pdf/manual/argomanual.pdf

http://argouml-stats.tigris.org/documentation/pdf/quick-guide/quickguide.pdf

http://argouml-stats.tigris.org/documentation/pdf/quick-guide/quickguide.pdf

Documents

Studienarbeit Integration von Entwurfsmuster in ArgoUML - Rene... · und in [Sch02] ¨uberarbeiteten Pattern-Erweiterung f ¨ur Rational Rose. Der entwickelte Wizard stellt eine Portierung