thesis - LMU

INSTITUT FÜR INFORMATIK 

LUDWIG – MAXIMILIANS – UNIVERSITÄT 

MÜNCHEN 

Diplomarbeit 

Erweiterung eines Open Source-Werkzeugs 

für die UML-basierte Modellierung 

von Webanwendungen 

Dariya Sharonova 

Aufgabensteller: Prof. Dr. Martin Wirsing 

Betreuer: Dr. Nora Koch (LMU München) 

Abgabedatum: 27.10.2011 

i

Eidesstattliche Erklärung 

Ich erkläre, dass ich die vorliegende Arbeit selbständig verfasst, nicht anderweitig für 

Prüfungszwecke vorgelegt, alle benutzten Quellen und Hilfsmittel angegeben, sowie wörtliche und 

sinngemäße Zitate gekennzeichnet habe. 

München, den 27.10.2011 ___________________________ 

ii

Моим родителям посвящается... 

(russ. Meinen Eltern gewidmet...) 

Ich möchte mich ganz herzlich bei meiner Betreuerin Frau Dr. Nora Koch 

bedanken. Danke Ihnen, dass Sie immer für mich da waren und Geduld 

hatten. 

Auch geht ein Dank an meine Arbeitskollegen bei der Sulzer GmbH, die mir 

immer mit einem guten Rat zur Seite standen. 

Und bei Dmitry möchte ich mich bedanken, ohne seine Unterstützung hätte ich 

das kaum geschafft. 

Ein besonderer Dank geht an meine Eltern, die trotz der großen Entfernung 

mich immer großartig unterstützten und mitfieberten. 

iii

Abstract 

Im Rahmen dieser Diplomarbeit werden Implementierungsmöglichkeiten für 

eine UML 1 -basierte Modellierung von Webanwendungen untersucht. Die 

betrachteten Modellierungstechniken stammen aus einer Methodik namens 

UML-based Web Engineering, kurz UWE. Dies ist ein vor ca. 15 Jahren 

entstandener UML-basierter Ansatz zur Modellierung und Entwicklung von 

Webanwendungen, der u.a. ein speziell für Webanwendungen angepasstes 

UML-Profil vorsieht. 

Die Arbeit umfasst eine umfangreiche Analyse von UML-CASE 2 -Tools für 

Eclipse 3 im Hinblick auf ihre Erweiterbarkeit für UWE. Zu den analysierten 

Merkmalen gehören die Unterstützung bestimmter UML-Diagrammtypen, 

geschachtelter Diagramme, Profile und Stereotype 4 . Darüber hinaus werden 

grafische Modellierungsmöglichkeiten, enthaltene Entwicklertools, 

Möglichkeiten der Codegenerierung, Qualität der Dokumentation und Lizenz 

betrachtet. 

Das Hauptziel der Analyse ist die Auswahl eines UML-CASE-Tools als 

Zielplattform für UWE-Erweiterungen. Anschließend werden Funktionen für die 

UWE-Notation und UWE-basierte Modellierung von Webanwendungen als 

Erweiterung des ausgewählten UML-CASE-Tools implementiert. 

1 UML – Unified Modeling Language 

2 CASE – Computer-aided software engineering 

3 Quelloffene Entwicklungsplattform ([web-eclipse]) 

4 Lt. Duden ([web-duden-stereotyp]) ist das Wort Stereotyp grammatikalisch sächlich und hat folgende Wortformen: 

Nominativ Singular das Stereotyp, Nominativ Plural die Stereotype 

iv

Inhaltsverzeichnis 

1 Einleitung.............................................................................................1 

1.1 Motivation und Zielsetzung...............................................................1 

1.2 Gliederung der Arbeit.......................................................................2 

2 Grundlagen und verwendete Techniken....................................................4 

2.1 UML...............................................................................................4 

2.1.1 Diagramme...............................................................................4 

2.1.1.1 Klassendiagramm................................................................5 

2.1.1.2 Anwendungsfalldiagramm.....................................................5 

2.1.1.3 Aktivitätsdiagramm.............................................................6 

2.1.1.4 Zustandsdiagramm..............................................................6 

2.2 UML-based Web Engineering (UWE)...................................................6 

2.2.1 ArgoUWE..................................................................................7 

2.2.2 MagicUWE................................................................................8 

2.3 Eclipse...........................................................................................9 

2.4 TOPCASED....................................................................................10 

2.4.1 Grundlagen.............................................................................10 

2.4.2 TOPCASED UML Editor..............................................................12 

2.4.3 Beispiel: Adressbuch................................................................13 

3 Vergleich von Werkzeugen für die UML-Modellierung................................20 

3.1 Kriterien.......................................................................................20 

3.2 Vergleich......................................................................................21 

3.3 Entscheidung................................................................................30 

3.3.1 Ausgewählte Tools...................................................................30 

3.3.2 Detaillierte Analyse..................................................................33 

3.3.3 Entscheidung über das Tool für die UWE-Erweiterung...................34 

4 Anforderungsanalyse............................................................................36 

4.1 Zielplattform und Integration..........................................................36 

4.2 Benutzeroberfläche........................................................................36 

4.2.1 Hauptmenü.............................................................................37 

4.2.1.1 Menüeintrag New UWE Diagram..........................................38 

4.2.1.2 Menüeintrag Transformations..............................................40 

4.2.1.3 Menüeintrag Create Default Models......................................41 

4.2.1.4 Menüeintrag Apply Profile...................................................42 

4.2.1.5 Menüeintrag About UWEclipse.............................................43 

v

4.2.2 Kontextmenü im Projektbaum...................................................44 

4.2.2.1 Neue Diagramme anlegen...................................................44 

4.2.2.2 Transformation von Inhaltsmodellen....................................45 

4.2.2.3 Transformationen von Navigationsmodellen..........................46 

4.2.3 Kontextmenü im Diagrammeditor..............................................48 

4.2.4 Palette im Diagrammeditor.......................................................51 

5 Implementierung.................................................................................53 

5.1 GUI-Abläufe..................................................................................53 

5.1.1 Anlegen eines TOPCASED-Modells..............................................53 

5.1.2 Laden des UWE-Profils..............................................................54 

5.1.3 Anwenden des UWE-Profils auf das TOPCASED-Modell..................55 

5.1.4 Anwenden eines Stereotyps auf das TOPCASED-Modell................56 

5.1.5 Anwenden eines Stereotyps auf eine Klasse................................57 

5.2 Designentscheidungen....................................................................59 

5.2.1 Ermitteln von Stereotypeigenschaften........................................59 

5.2.2 Nested Classes........................................................................59 

5.2.3 Kontextmenü im Diagrammeditor..............................................59 

5.2.4 Palette im Diagrammeditor.......................................................60 

5.2.5 Drag & Drop von Stereotypen...................................................61 

5.3 Implementierungsdetails................................................................61 

5.3.1 Projektstruktur........................................................................61 

5.3.2 Benutzeroberfläche..................................................................62 

5.3.2.1 Ansichtsfenster..................................................................63 

5.3.2.2 Hauptmenü.......................................................................64 

5.3.2.3 Kontextmenü im Projektbaum.............................................65 

5.3.2.4 Kontextmenü im Diagrammeditor........................................66 

5.3.2.5 Palette im Diagrammeditor.................................................67 

5.3.3 Anlegen von Modell-Containern.................................................67 

5.3.4 Laden und Anwenden des Profils................................................68 

5.3.5 Anlegen von Diagrammen.........................................................70 

5.3.6 Transformationen.....................................................................71 

5.3.7 Anmerkungen..........................................................................71 

5.3.7.1 Aufruf der psu-Ansicht vor der Arbeit mit UWEclipse..............71 

5.3.7.2 Ermitteln des Typs des selektierten Objekts..........................72 

5.3.7.3 Übergang von einem Diagrammelement zu seiner internen 

Repräsentation.............................................................................72 

6 Modellierung eines Beispiels mit UWEclipse.............................................74 

6.1 Vorbereitung.................................................................................74 

6.2 Transformationen...........................................................................74 

7 Zusammenfassung und Ausblick............................................................78 

7.1 Durchgeführte Arbeit......................................................................78 

vi

7.2 Vergleich zu MagicUWE...................................................................79 

7.3 Ausblick........................................................................................79 

Literaturverzeichnis.................................................................................80 

Webreferenzen....................................................................................80 

Literaturreferenzen..............................................................................82 

Sourcecodereferenzen..........................................................................83 

vii

1 Einleitung 

Erweiterung eines Open Source-Werkzeugs für die UML-basierte Modellierung von Webanwendungen 

1.1 Motivation und Zielsetzung 

Moderne Softwareentwicklung ist kaum vorstellbar ohne Techniken, die zur 

Systematisierung und Automatisierung in verschiedenen Phasen des 

Entwicklungsprozesses beitragen. Eine wichtige Rolle spielt dabei die 

Modellierung des zu entwickelnden Softwaresystems, die heutzutage oft in 

engem Zusammenhang mit dem Begriff Unified Modeling Language (UML) 

steht. 

Eine der auf UML basierenden Techniken ist UWE (UML-based Web 

Engineering) – eine Methodik für die Modellierung und Entwicklung von 

Webanwendungen, die von modellgetriebenen Ansätzen Gebrauch macht und 

dem Entwickler ein auf Webanwendungen zugeschnittenes UML-Profil zur 

Verfügung stellt. Dieses Profil sowie die ganze UWE-Methodik lassen sich dank 

voller UML-Konformität von UWE grundsätzlich mit jedem UML-CASE-Tool 

(CASE – Computer-aided software engineering) einsetzen, welches UML 

unterstützt. 

Das Hauptziel von UWE ist die Systematisierung und Unterstützung des 

Entwicklungsprozesses, der eine automatische oder halbautomatische 

Generierung der Webanwendungen ermöglicht. 

Für die Unterstützung des UWE-basierten Modellierungsvorganges wurden für 

die UML-Werkzeuge ArgoUML und MagicDraw (beides sind CASE-Tools für die 

Modellierung von Softwaresystemen mit Hilfe von UML) spezielle Plugins 

entwickelt: ArgoUWE und MagicUWE, die den Entwickler durch die 

Teilautomatisierung des UWE-basierten Modellentwurfs unterstützen. 

Vorteil von ArgoUML ist seine Open Source-Lizenz. Allerdings unterstützt das 

Tool UML2 5 nicht. Somit wurde auch die Entwicklung von ArgoUWE eingestellt. 

MagicDraw bietet dagegen zwar die UML2-Unterstützung, ist jedoch ein 

kommerzielles Tool. 

Dadurch zeichnet sich die Notwendigkeit ab, die Funktionalität der erwähnten 

UWE-Plugins auf Basis eines Open Source UML-Tools mit UML2-Unterstützung 

zu implementieren. Von besonderem Interesse ist dabei Eclipse – etablierte 

Open Source IDE (Integrated development environment, Integrierte 

5 UML2 bzw. UML 2.x ist die 2. Version der UML-Spezifikation, die zahlreiche Änderungen im Vergleich zu der Version 

1 bringt und insgesamt wesentlich ausgereifter ist 

1


Entwicklungsumgebung) mit Unterstützung der UML-Modellierung. 

Somit gehen wir zu den Aufgaben über, denen sich diese Diplomarbeit widmet: 

– Analyse vorhandener Eclipse-basierter UML-Werkzeuge im Hinblick auf 

ihre Erweiterbarkeit für UWE 

– Auswahl eines UML-CASE-Tools – anhand der Analyse – als Zielplattform 

für UWE-Erweiterungen 

– Implementierung von Funktionen zur UWE-basierten Modellierung von 

Webanwendungen im ausgewählten UML-CASE-Tool 

Die Analyse wird nach mehreren Kriterien durchgeführt: Unterstützung UWErelevanter 

UML-Diagrammtypen, Arbeit mit UML-Profilen und -Stereotypen, 

grafische Modellierungsmöglichkeiten, integrierte Entwicklertools, 

Möglichkeiten der Codegenerierung, Qualität der Dokumentation, Lizenz. 

Nach der Analyse wird entschieden, welches UML-Werkzeug für die 

Implementierung der UWE-Methodik und die Migration der Funktionalität von 

ArgoUWE und MagicUWE am besten geeignet ist. 

Als Nächstes wird im Rahmen dieser Diplomarbeit das ausgewählte Tool um die 

Funktionen zur UWE-basierten Modellierung von Webanwendungen erweitert. 

Im Laufe der Entwicklung werden Teile der MagicUWE-Funktionalität als Plugin 

zum ausgewälten UML-Werkzeug implementiert. 

1.2 Gliederung der Arbeit 

Die vorliegende Arbeit besteht aus 6 Kapiteln: 

– Im Kapitel 1 wird die Arbeit kurz vorgestellt sowie die Motive zu ihrer 

Entstehung erläutert. 

– Kapitel 2 enthält eine Einführung in Techniken und Begriffe, die mit 

Modellierung und UWE zu tun haben und im Rahmen dieser Arbeit 

benutzt wurden. 

– Im Kapitel 3 wird die umfangreiche Analyse der verfügbaren Eclipsebasierten 

UML-Wekrzeuge durchgeführt. Dabei wird anhand der 

festgelegten Kriterien das für die UWE-Modellierung am besten geeignete 

Werkzeug festgestellt. 

– Kapitel 4 widmet sich der Anforderungsanalyse für das zu entwickelnde 

Plugin zum UML-Werkzeug, das im Kapitel 3 ausgewählt wurde. 

– Die Entwicklung des Plugins wird im Kapitel 5 beleuchtet. Dabei werden 

nicht nur implementierte Funktionen, technische Details der 

Implementierung und Designentscheidungen geschildert, sondern auch 

2


technische Probleme, die während der Entwicklung entstanden sind. 

– Im Kapitel 6 wird die Modellierung mit dem entwickelten Plugin anhand 

eines Beispiels veranschaulicht. 

– Kapitel 7 beinhaltet die Zusammenfassung für die ganze Arbeit sowie die 

Beschreibung der Möglichkeiten zur Weiterentwicklung im Bereich UWEbasierte 

Modellierung von Webanwendungen in Bezug auf das 

entwickelte Plugin. 

3


2 Grundlagen und verwendete Techniken 

Dieses Kapitel enthält einen Überblick über Techniken und Begriffe aus dem 

Bereich Modellierung – sowohl allgemeine als auch diejenigen, die im 

Zusammenhang mit UWE im Rahmen dieser Arbeit in Frage kommen. 

2.1 UML 

UML (Unified Modeling Language, [web-uml]) ist eine universale grafische 

Modellierungssprache zum Spezifizieren, Konstruieren und Dokumentieren von 

Softwaresystemen. UML wird in vielen Anwendungsbereichen eingesetzt und ist 

momentan die führende Modellierungssprache in der IT-Industrie ([lit-umlinfra]). 

Mit der Standardisierung und Weiterentwicklung von UML befasst sich 

die OMG (Object Management Group, [web-omg]). 

UML verfügt über einen Erweiterungsmechanismus, der im Rahmen dieser 

Arbeit von Bedeutung ist: sog. UML-Profile. Ein UML-Profil dient zur Anpassung 

von UML an eine bestimmte Entwicklungsplattform oder einen bestimmten 

Anwendungsbereich – somit entsteht jeweils ein neuer UML-Dialekt ([lit-umlinfra]). 

2.1.1 Diagramme 

Die aktuelle Version 2.3 der UML-Spezifikation legt 14 Diagrammtypen fest, die 

in 2 Gruppen (mit jeweils 7 Diagrammtypen) aufgeteilt sind: 

– Strukturdiagramme (structure diagrams) 

– Verhaltensdiagramme (behavior diagrams) 

Die gesamte Diagrammübersicht ist auf Abb. 2.1 dargestellt. 

4


Abbildung 2.1. UML-Diagrammübersicht [lit-uml-super]:704 

UWE-Funktionalität setzt Unterstützung von 4 folgenden UML-Diagrammtypen 

voraus ([lit-uwe-meta]): 

– Klassendiagramme 

– Anwendungsfalldiagramme 

– Aktivitätsdiagramme 

– Zustandsdiagramme 

Diese Diagrammtypen werden in nachfolgenden Abschnitten kurz vorgestellt. 

2.1.1.1 Klassendiagramm 

Das Klassendiagramm (class diagram) dient zur Darstellung der statischen 

Struktur des Systems. Es zeigt Klassen, deren Eigenschaften (Attribute) und 

Operationen sowie Klassenbeziehungen und Schnittstellen. Klassendiagramme 

sind eines der wichtigsten Konzepte der objektorientierten Modellierung und 

werden während aller Phasen des Entwicklungsprozesses verwendet. 

2.1.1.2 Anwendungsfalldiagramm 

Das Anwendungsfalldiagramm (use case diagram) stellt Anwendungsfälle, 

Akteure (Benutzer des Systems) und ihre Beziehungen (Interaktionen) dar. 

5


2.1.1.3 Aktivitätsdiagramm 

Das Aktivitätsdiagramm (activity diagram) beschreibt Aktionen und Abläufe 

eines Systems. Es wird dargestellt, in welcher Reihenfolge die Aktionen 

augeführt werden und wie Kontroll- und Datenflüsse organisiert sind. Es ist 

möglich, Bedingungen und Nebenläufigkeit der Aktionen darzustellen. 

2.1.1.4 Zustandsdiagramm 

Das Zustandsdiagramm (state machine diagram) ist eine durch UML-Notation 

dargestellte Variante der endlichen Automaten. Zustandsdiagramme dienen 

zum Darstellen von Zuständen eines Objektes sowie von Transitionen 

(Übergängen) zwischen diesen Zuständen. Bei Transitionen können Ereignisse 

angegeben werden, die diese Transitionen auslösen. Es besteht auch die 

Möglichkeit, Bedingungen festzulegen, die für das jeweilige Ereignis erfüllt sein 

müssen, damit es gefeurt werden kann. 

2.2 UML-based Web Engineering (UWE) 

UML-based Web Engineering, kurz UWE, ([web-uwe], [lit-chapter-7-uwe]), ist 

eine Methodik aus dem Bereich Softwaretechnik, die sich mit der Entwicklung 

von Webanwendungen befasst. Das Hauptziel ist dabei die Systematisierung 

und Unterstützung des Entwicklungsprozesses, der eine automatische oder 

halbautomatische Generierung der Websysteme ermöglicht. UWE setzt 

modellgetriebene Ansätze bei der Entwicklung ein, baut auf UML auf und wird 

im Bereich UML-Modellierung und Entwicklung von Webanwendungen 

eingesetzt. 

UWE zeichnet sich durch volle UML-Konformität aus: alle UWE-Modellelemente 

sind mit Hilfe eines speziellen UML-Profils definiert. Durch den Einsatz dieses 

UML-Profils kann das Metamodell um Stereotype erweitert werden, die speziell 

im Bereich Webentwicklung benötigt werden (z.B. für die Darstellung von 

Elementen der Navigationsstruktur einer Webseite). 

Ein wichtige Eigenschaft des Entwicklungsprozesses mit UWE ist die getrennte 

Modellierung unterschiedlicher Sichten des Websystems (separation of 

concerns). Dabei werden während jeder Entwicklungsphase (Analyse, Design, 

Implementierung) Modelle erstellt, die jeweils eine Sicht der Webanwendung 

darstellen: 

– Inhalt (Festlegung der Konzepte aus dem Anwendungsbereich und deren 

Zusammenhänge) 

– Navigation (Navigationspfade und -elemente) 

6


– Präsentation (Darstellung und Interaktion mit dem Benutzer) 

Somit ergibt sich ein 2D-artiger Entwicklungsprozess - mit Entwicklungsphasen 

und Systemsichten als 2 Dimensionen. Eine solche Vorgehensweise trägt zu 

besserer Wartung, Reengineering und Portierung des zu entwickelnden 

Websystems bei. 

Des Weiteren kann der Vorgang um eine 3. Dimension erweitert werden, 

nämlich die Aspekt-Achse, wenn man neben standardmäßig modellierten 

Strukturaspekten auch noch Verhaltensaspekte in die Modellierung mit 

einbezieht. Letztere werden in UML mit Hilfe von Interaktions- und 

Zustandsdiagrammen dargestellt. Auch eine 4. Dimension kommt in Betracht, 

und zwar die Anpassbarkeit, bei der es sich um die automatische 

Personalisierung der Webanwendung für den jeweiligen Benutzer bzw. um die 

Berücksichtigung des Nutzungskontextes handelt. 

Weitere Eigenschaft der UWE-Methodik ist das sogenannte Model-Driven 

Development (MDD, Modellgetriebene Entwicklung). Dieser Ansatz basiert auf 

der konsequenten Nutzung von Modellen in allen Entwicklungsphasen sowie 

deren Umwandlungen (Transformationen) und eignet sich besonders gut für die 

Entwicklung der Websysteme. 

Da UWE UML-konform ist, lassen sich UWE-Modelle grunsätzlich mit Hilfe von 

allen CASE-Tools entwickeln, die UML unterstützen. Zur tiefgreifenden 

Unterstützung des UWE-basierten Modellentwurfs wurden darüber hinaus 

spezielle Tools entwickelt, wie z.B. ArgoUWE und MagicUWE. 

2.2.1 ArgoUWE 

ArgoUWE ([web-uwe-argo], [lit-chapter-7-uwe]) ist ein Open Source-Plugin für 

das CASE-Tool ArgoUML ([web-argouml]), das auf dem UWE-Metamodell 

basiert (welches seinerseits vom UML-Metamodell abgeleitet wird). ArgoUWE 

stellt einen Editor für die UWE-basierte Modellierung von Webanwendungen zur 

Verfügung und bietet Funktionen für Modelltransformationen und 

Konsistenzprüfung des Modells. Die Verwendung des UWE-Profils bei der 

Modellentwicklung ermöglicht den Modellaustausch zwischen ArgoUWE und 

anderen UML CASE-Werkzeugen (ArgoUWE stellt dafür die Funktion des XMI 6 - 

Exports zur Verfügung). 

In ArgoUWE können Diagramme erstellt werden, mit deren Hilfe die von UWE 

eingeführten Modelltypen abgebildet werden können: Navigations-, 

Präsentations-, Prozess- und Anpassungsmodell. Es stehen folgende 

6 XMI – XML Metadata Interchange – ist ein Austauschformat für Metadaten, verwendet z.B. für den UML-Modell- 

Austausch zwsichen UML-Werkzeugen, zwischen einem Modellierungstool und einem Codegenerator etc. 

7


Transformationsmöglichkeiten für die Umwandlung von Modellen nach UWEbzw. 

MDD-Methodik zur Verfügung: 

– Inhaltsmodell → Navigationsmodell 

– Navigationsmodell → Präsentationsmodell 

ArgoUWE besitzt einen Mechanismus für die Konsistenzprüfung des Modells in 

Bezug auf OCL-Einschränkungen (OCL, Object Constraint Language, [lit-ocl], 

[web-ocl-dd]), die im UWE-Metamodell definiert wurden. Diese Funktion baut 

auf dem sog. Design Critics-Feature von ArgoUML. 

Dabei läuft im Hintergrund ein Thread, der alle Einschränkungsverletzungen im 

Laufe der Modellentwicklung registriert, ohne den Entwicklungsprozess zu 

unterberechen und den Entwickler dabei zu stören. Der Entwickler hat jederzeit 

die Möglichkeit, sich über gefundene Verletzungen und Inkonsistenzen mittels 

entsprechender Liste im To-Do-Bereich der Benutzeroberfläche zu erkundigen. 

Lt. [web-uwe-argo], ist die Entwicklung von ArgoUWE mittlerweile eingestellt. 

Die Ursache war fehlende UML2-Unterstützung in ArgoUML. 

2.2.2 MagicUWE 

MagicUWE ([web-uwe-magic]) ist ein Tool für die UWE-basierte Modellierung 

von Webanwendungen, das als Plugin für das UML-Entwicklungswerkzeug 

MagicDraw ([web-magicdraw]) implementiert wurde. 

MagicUWE basiert auf Standards wie UML und MDA (Model-Driven Architecture, 

Modellgetriebene Architektur), realisiert die in 2.2 beschriebene getrennte 

Modellierung unterschiedlicher Sichten der zu entwickelnden Webanwendung 

(separation of concerns), unterstützt modellgetriebene Vorgehensweise bei 

der Entwicklung und bietet Möglichkeit zur Konsistenzüberprüfung des Modells 

([web-uwe-magic-brief]). 

Zu der Funktionalität von MagicUWE gehört die Unterstützung von UWE- 

Profilen ([web-uwe-magic-profile]), -Stereotypen und -Package-Struktur sowie 

die Möglichkeit der Modelltransformationen ([web-uwe-magic-brief]). 

MagicUWE bietet einige Konfigurations- und Anpassungsmöglichkeiten und 

lässt sich leicht um weitere UWE-Modellierungselemente erweitern ([web-uwemagic-brief]). 

Auf Abb. 2.2 ist die Menüstruktur von MagicUWE sowie ein im 

Editor von MagicDraw geöffnetes UWE-Diagramm zu sehen. 

8


Abbildung 2.2. MagicUWE 1.3.2 und MagicDraw 16.8 

Ein vollständiges Verzeichnis der in MagicUWE realisierten Erweiterungen und 

Automatisierungen von MagicDraw-Funktionalität ist unter [web-uwe-magicref] 

zu finden. Einige dieser Funktionen wurden im UML-Werkzeug 

implementiert, das im Rahmen dieser Arbeit entstand: automatisches Laden 

des UWE-Profils, Anlegen von Standard-UWE-Modellen, Anlegen von UWE- 

Diagrammen etc. Eine detaillierte Liste der implementierten Funktionalität wird 

im Kapitel 5 aufgeführt. 

2.3 Eclipse 

Eclipse spielt eine wichtige Rolle in dieser Arbeit, da diese Plattform als Open 

Source lizenziert ist, zahlreiche Möglichkeiten zur UML-Modellierung anbietet 

und über eine große Community verfügt. Im Kapitel 3 werden Eclipse-basierte 

UML-Modellierungslösungen untersucht, um das Tool für die angestrebte UWE- 

Erweiterung zu ermitteln, das den gestellten Anforderungen am besten 

entspricht. 

Eclipse ([web-eclipse], [web-eclipse-wiki-faq-what]) ist eine auf Java-Technik 

basierende plattformunabhängige Softwareentwicklungsumgebung, die auf 

einem höchst erweiterbaren Plugin-System aufbaut. Es ist eine Plattform mit 

einem relativ kleinen Kern, der das Laden, Integration und Verwaltung von 

Plugins übernimmt und sich allerdings darauf beschränkt. Alles weitere - die 

ganze Funktionalität also, die dem Eclipse-Benutzer zur Verfügung steht - wird 

in Form von Plugins bereitgestellt. 

9


Kernfunktionen von Eclipse basieren auf Equinox ([web-eclipse-equinox]) - 

einer Implementierung der OSGi 7 R4-Basisspezifikation ([web-osgi-spec-4], 

[web-aneeshkumarkb]), die eine Architektur für komponentenbasierte 

Anwendungen festlegt. Es werden hierbei u.a. folgende Aspekte definiert: 

– Umgebung (Container) für Komponenten (die hier als Bundles bezeichnet 

werden) 

– vom Container bereitgestellte Funktionen für die Integration, Verwaltung 

und Ausführung von Bundles 

– Standards für OSGi-kompatible Bundle-Entwicklung 

Somit stellt Equinox die Möglichkeit zur Verfügung, eine aus mehreren Bundles 

(Eclipse-Plugins in dem Fall) bestehende Anwendung zusammenzubauen, und 

stellt alle dafür benötigten Verwaltungsmittel bereit. 

2.4 TOPCASED 

TOPCASED ist einer der zentrale Begriffe in dieser Arbeit. Es ist eine Sammlung 

von Werkzeugen für den gesamten Softwarentwicklungsprozess. Ein 

Bestandteil von TOPCASED ist der TOPCASED UML Editor – das UML- 

Modellierungstool, welches als Objekt der Anpassung für UWE im Rahmen 

dieser Arbeit ausgewählt wurde. Wie diese Auswahl erfolgte, wird ausführlich 

im Kapitel 3 beschrieben. 

In 5.1 werden einige grundlegende Abläufe aus der Arbeit mit dem TOPCASED 

UML Editor aufgeführt. Diese Abläufe veranschaulichen einerseits einige 

Möglichkeiten des TOPCASED UML Editors. Andererseits dienen sie als Vorgabe 

für die zu implementierende (automatische) UWE-bezogene Funktionalität des 

Plugins, das im Rahmen dieser Diplomarbeit entwickelt wurde. 

2.4.1 Grundlagen 

TOPCASED ([web-topcased], [web-topcased-heise], [web-topcasedpresentation-30-min], 

[web-topcased-presentation-2-h]) ist ein aus den 

Bedürfnissen der Luft- und Raumfahrtbranche (Airbus) hervorgegangenes 

Projekt, in dessen Rahmen eine Reihe von Werkzeugen von hoher Qualität für 

die Entwicklung sicherheitskritischer und dauerhaft einsetzbarer Systeme 

entsteht. Der Name TOPCASED steht dementsprechend treffend für Toolkit in 

OPen source for Critical Applications & SystEms Development (Open-Source- 

Werkzeugsammlung für die Entwicklung kritischer Anwendungen und 

Systeme). TOPCASED-Werkzeuge sollen alle Phasen des Entwicklungsprozesses 

7 OSGi – Open Services Gateway initiative 

10


abdecken – von der Spezifikation bis zur Implementiertung. Sie finden 

Verwendung bei der Entwicklung von Software- und Hardware-Systemen in 

Luft- und Raumfahrttechnik, Automotive und anderen Branchen mit ähnlichen 

Anforderungen. 

Technisch gesehen ist TOPCASED eine erweiterbare Eclipse-basierte RCP (Rich 

Client Platform) [web-eclipse-rcp]. 

Dadurch, dass TOPCASED auf Eclipse und seiner Plugin-Architektur aufbaut, 

stehen alle Vorteile Eclipse-basierter Systeme zur Verfügung ([web-topcasedpresentation-2-h]): 

– Plattformunabhängigkeit (da Eclipse selbst eine auf Java-Technik 

basierende IDE ist) 

– modularer Aufbau (auf einer Seite – der auf ein Minumum reduzierte 

Kern, der nur für das Laden, Integration und Verwaltung von Plugins 

verantwortlich ist, auf der anderen – Plugins, die die ganze Funktionalität 

bereitstellen) 

– ausgereifte Mechanismen zur Softwareverteilung, automatische Updates, 

Unterstützung mehrerer parallel installierter Versionen 

– ergonomischer Aspekt (etabliertes GUI auf Basis von SWT und JFace) 

– weitgehende Unterstützung für Teamarbeit (CVS, SVN) 

Des Weiteren bedient sich TOPCASED der Funktionen von GEF und EMF ([webtopcased-presentation-2-h]): 

– GEF (Graphical Editor Framework, [web-eclipse-wiki-gef-faq], [webeclipse-gef]) 

stellt Funktionalität bereit, mit deren Hilfe eine Eclipsebasierte 

Anwendung mit einem vollwertigen grafischen Editor versehen 

werden kann. 

– EMF (Eclipse Modeling Framework, [web-eclipse-emf]) stellt 

Mechanismen für Modellierung und Codegenerierung zur Verfügung, inkl. 

Laden, Bearbeiten, Vergleichen, Zusammenlegen und Abfragen von 

Modellen, Modelltransformationen, Import von Modellen aus anderen 

Programmen, Transaktionen für Modellbearbeitung, Integritätsprüfungen 

für Modelle, Mappings von Modellen zu relationalen Datenbanken etc. 

Die TOPCASED-Schicht ([web-topcased-presentation-2-h]), die auf o.g. 

Mechanismen aufbaut, besteht aus dem Ecore-Editor (Modelleditor für das 

grundlegende EMF-Metamodell, mittlerweile ein Teil des Eclipse-Projekts 

geworden), einem SDK zum Erstellen von neuen Modelleditoren, einer Reihe 

von Editoren und Tools für Modellüberprüfung, Modellsimulation, Code- und 

Dokumentationsgenerierung etc. Auf Abb. 2.3 ist der Modellierungs-Stack von 

Eclipse, EMF und TOPCASED dargestellt. 

11


Abbildung 2.3. Modellierungs-Stack von Eclipse und TOPCASED [web-topcasedpresentation-2-h] 

2.4.2 TOPCASED UML Editor 

Ein Unterprojekt von TOPCASED, der TOPCASED UML Editor [web-topcaseddownload], 

ist ein grafisches UML-Modellierungswerkzeug mit Unterstützung 

semantischer Zusammenhänge zwischen Diagrammelementen. 

Grundlegende Abläufe aus der Arbeit mit dem TOPCASED UML Editor – im 

Zusammenhang mit der UWE-Funktionalität, die im Rahmen dieser Arbeit zu 

entwickeln ist – werden in 5.1 beschrieben. 

Begriffe TOPCASED und TOPCASED UML Editor werden in dieser Arbeit 

weiterhin als Synonyme verwendet. 

Auf Abb. 2.4 und 2.5 ist der TOPCASED UML Editor in typischer Konfiguration 

zu sehen. 

12


Abbildung 2.4. GUI des TOPCASED UML Editors [web-topcased-quick-start] 

Abbildung 2.5. Anwendungsfalldiagramm im TOPCASED UML Editor [webtopcased-quick-start] 

2.4.3 Beispiel: Adressbuch 

Dieser Abschnitt enthält mit TOPCASED erstellte Diagramme, die bei der UWEbasierten 

Entwicklung eines Beispielprojektes verwendet werden, nämlich 

eines Adressbuches. Das Beispielsprojekt stammt aus [web-uwe-ex-abwcu], 

13


dort sind auch Diagramme enthalten, die im Rahmen dieser Arbeit mit Hilfe 

von TOPCASED nachgebildet und weiter unten aufgeführt werden, um die 

grundlegenden Möglichkeiten von TOPCASED zu veranschaulichen. 

Das Beispiel soll zeigen, wie mit Hilfe von UWE ein Websystem modelliert 

werden kann, das die Arbeit mit gleichartigen Objekten (Anlegen, Bearbeiten, 

Löschen, Veröffentlichen) auf Basis der Benutzerinteraktion ermöglicht. 

Das betrachtete Adressbuch enthält Kontakte, die jeweils einen Namen, 2 

Telefonnummern, 2 Postanschriften, eine E-Mail-Adresse und ein Bild 

umfassen. Ausgegeben werden Informationen zu Kontakten, die vom Benutzer 

mittels Eingabe von Suchkriterien ausgesucht wurden. [web-uwe-ex-abwcu] 

In diesem Beispiel wird eines der Prinzipien der UWE-Methodik befölgt, nämlich 

die getrennte Modellierung unterschiedlicher Sichten des zu entwickelnden 

Websystems (separation of concerns). Für Inhalts-, Navigations- und 

Präsentationsaspekte werden dabei jeweils eigene Modelle erstellt. 

Auf Abb. 2.6 ist das Inhaltsmodell des Adressbuches in Form eines UML- 

Anwendungsfalldiagramms dargestellt. 

Abbildung 2.6. Inhaltsmodell des Adressbuches 

Abb. 2.7 zeigt eine mögliche Implementierungsvariante des Adressbuches: das 

Inhaltsmodell in Form eines UML-Klassendiagramms mit Klassen für das 

Addressbuch selbst (AddressBook), für den Kontakt (Contact), die 

14


Postanschrift (Address), die Telefonnummer (Phone) und das Bild (Picture). 

Abbildung 2.7. Inhaltsmodell einer möglichen Implementierung des 

Adressbuches 

Abb. 2.8 beschreibt die Navigationsstruktur der Anwendung, die aus Knoten 

und Verbindungen zwischen den Knoten besteht. Das dargestellte 

Navigationsmodell enthält Knoten und Verbindungen von folgenden Typen, die 

von UWE zur Verfügung gestellt werden: 

– Knoten: 

• 

• 

• 

• 

• 

– Verbindungen: 

• 

• 

Zu den auf dem Modell dargestellten Navigationsklassen 

() gehören Knoten für die Klassen AddressBook und 

Contact. Dagegen sind die Klassen Address, Phone und Picture aus Abb. 2.7 

in diesem Modell nicht vorhanden, weil sie bei der Navigation keine Rolle 

spielen. 

15


Der -Knoten Search stellt die Kontaktsuche dar: durch die Eingabe 

von Suchkriterien kann der Benutzer bestimmte Kontakte aussuchen, die dann 

als Liste ausgegeben werden, die durch den -Knoten ContactList 

repräsentiert wird. 

Inhaltsänderungen (Anlegen, Löschen und Bearbeiten von Kontakten) werden 

mit den -Knoten ContactCreation, ContactDeletion und 

ContactUpdate dargestellt, die über -Verbindungen in das 

Navigationsmodell eingebunden sind. 

Das Hauptmenü der Webanwendung und das Menü zum Löschen und 

Bearbeiten von Kontakten sind auf dem Modell in Form von -Knoten 

MainMenu und ContactMenu dargestellt. 

Abblidung 2.8. Navigationsstruktur des Adressbuches 

Auf Abb. 2.9 ist das Prozessmodel des Adressbuches dargestellt, das Abläufe in 

der Webanwendung beschreibt. 

16


Abbildung 2.9. Prozessstruktur des Adressbuches 

Abb. 2.10 zeigt die Vorgehensweise beim Löschen eines Kontaktes aus dem 

Adressbuch. 

17


Abbildung 2.10. Prozessmodell zum Löschen eines Kontaktes aus dem 

Adressbuch 

Auf Abb. 2.11 ist ein Teil des Präsentationsmodells des Adressbuches in Form 

eines UML-Klassendiagramms dargestellt. 

18


Abbildung 2.11. Präsentationsmodell des Adressbuches (Teil) 

19


3 Vergleich von Werkzeugen für die UML- 

Modellierung 

In diesem Kapitel werden die zum Zeitpunkt dieser Arbeit verfügbaren UML- 

Plugins und -Tools für Eclipse bzw. auf Basis von Eclipse betrachtet. Es werden 

grundlegende Kriterien für die benötigte Funktionalität, Verfügbarkeit und 

Nutzungsmöglichkeiten der Tools formuliert. Im Hinblick auf die gestellten 

Anforderungen wird ein Vergleich sowie die Auswahl der Werkzeuge 

vorgenommen. Ausgewählte Tools werden detaillierter analysiert. Dabei wird 

das für UWE zu erweiterndes Werkzeug ermittelt. 

Insgesamt waren zum Zeitpunkt dieser Arbeit mehr als 70 UML-bezogene 

Werkzeuge für Eclipse verfügbar. Die Liste der betrachteten Tools wurde auf 

Basis der Software-Verzeichnisse von [web-epc-1] und [web-epc-2] 

zusammengestellt. Das sind 2 umfangreichste Webportals für Eclipse-Plugins 

und Eclipse-basierte Lösungen. 

3.1 Kriterien 

Angesichts des großen Umfanges des Themenbereichs UML muss zunächst eine 

generelle primäre Trennung nach Relevanz der UML-Werkzeuge für diese Arbeit 

vorgenommen werden. Diese Trennung erfolgt in 2 aufeinander aufbauenden 

Stufen: 

– Kriterium I-a. Das Werkzeug muss generell für die Erstellung von UML- 

Diagrammen geeignet sein. 

– Kriterium I-b. Diagramme müssen mit Hilfe eines visuellen Editors 

erstellt werden können. 

An die nach der primären 2-stufigen Trennung ermittelten UML-Werkzeuge 

werden folgende grundsätzliche Anforderungen gestellt: 

– Kriterium II-a. Open Source-Lizenz 

– Kriterium II-b. Unterstützung von folgenden 4 Diagrammtypen, die von 

UWE benötigt werden (2.1.1): 

• Class 

• Use Case 

• Activity 

20


• State Machine 

Die Open Source-Lizenzierung (Kriterium II-a) wurde aus folgenden Gründen 

als Anforderung festgelegt: 

– freie Nutzung der Software für beliebige Zwecke (oder mit nur wenigen 

lizenzbedingten Einschränkungen) 

– uneingeschränkte Anzahl von Benutzern, d.h. es entstehen keine Kosten 

in Bezug auf Benutzerzahl (häufig auch keine Anschaffungskosten) 

– offener Quellcode, was bei der Entwicklung von Erweiterungen/Plugins 

häufig sehr hilfreich ist 

– an der Entwicklung ist oft eine vielseitige Community beteiligt, was 

positive Auswirkungen auf die Softwarequalität hat und dem 

Erfahrungsaustausch beiträgt 

– geringe Gefahr des Vendor Lock-in 8 

3.2 Vergleich 

In Tabelle 3.1 sind alle betrachteten UML-Werkzeuge aufgeführt – inkl. 

unterstützte Diagrammtypen sowie ein Vermerk zur Verfügbarkeit des 

jeweiligen Tools unter einer Open Source-Lizenz. 

Als Erstes wird das Kriterium I-a aus 3.1 angewendet (Erstellung von UML- 

Diagrammen generell). Es gibt eine Menge der UML-Werkzeuge, die sich mit 

ganz anderen Bereichen des UML befassen (z.B. OCL) und somit in diesem 

Schritt wegfallen. 

Als Nächstes wird die Verfügbarkeit des visuellen Diagrammeditors überprüft 

(Kriterium I-b). 

Ziel bzw. Schwerpunkt vieler UML-Werkzeuge, die mit der Erstellung von UML- 

Diagrammen zu tun haben, ist die Umwandlung des Programmcodes (dabei 

kommen diverse Programmiersprachen vor, meistens Java, aber auch C++, 

C#, JavaScript, PHP etc.) in UML-Diagramme. Solche Werkzeuge fokussieren 

sich auf die Zusammenhänge zwischen dem Programmcode und UML. Auf die 

visuelle Erstellung der (losen) UML-Diagramme wird dagegen eher rudimentär 

oder gar nicht eingegangen. Beispiele solcher Werkzeuge sind: Cpp2Uml, 

MaintainJ, JS/UML, LightUML, M2Code for Java, M2Flex, M2Spring etc. Diese 

und ähnliche durch die Anwendung vom Kriterium I-a ausgewählten Tools 

werden hiermit dementsprechend durch das Kriterium I-b aussortiert. 

8 Vendor Lock-in ist die Abhängigkeit vom Hersteller, die den Herstellerwechsel wegen großen materiellen Aufwands 

wesentliich erschwert 

21


Danach müssen die UML-Werkzeuge in Bezug auf Kriterien II-a und II-b 

(Verfügbarkeit unter einer Open Source-Lizenz + Unterstützung von 4 

benötigten Diagrammtypen) betrachtet werden. 

22

Tabelle 3.1. Analyse der UML-Werkzeuge 


+ – Unterstützt bzw. vorhanden 

– – Nicht unterstützt bzw. nicht vorhanden 

P – In Planung 

kA – keine Angaben 

UML-Werkzeug 

Class 

Use Case 

Unterstützte 

Diagrammtypen 

Activity 

State Machine 

Sequence 

Component 

Deployment 

Composite 

Structures 

Visueller Editor 

Code Generator 

Diagram from Code 

(reverse-engineered 

diagrams) 

Actifsource - Model- 

Erstellt den Code aus Diagrammen 

Driven Code 

Generator 

- - - - - - - - + + - - 

Agile4R 

- - - - - - - - kA + - - 

Generiert Anwendungen aus .emx UML2 

Modellen 

AgileJ 

Generiert Diagramme aus dem Java-Code 

StructureViews code 

visualizer 

+ - - - - - - - kA - + - 

Altova Umodel + + + + + + + + + + + - 

AmaterasUML + + + - + - - - + - - + 

Apollo for Eclipse + - - - - - - - + + + - 

Architexa + - - - + - - - + - + - 

ArgoUML + + + + + - + - + + + + Nicht ausgereift 

Blueprint Software + + + + + + - + + - - - 

23 

Open Source 

Bemerkungen

UML-Werkzeug 

Class 


Use Case 

Unterstützte 

Diagrammtypen 

Activity 

State Machine 

Sequence 

Component 

Deployment 

Composite 

Structures 





diagrams) 

Modeler – 

Community Edition 

Blueprint Software 

Round-trip engineering 

Modeler – 

Professional Edition 

+ + + + + + - + + + + - 

Classtemplater - - - - - - - - - + - + Class based code generator for Eclipse 

CodeLogic + - - + - - - - + - + - Generiert Diagramme aus dem Java-Code 

Coffea + - - - - - - - + + kA - Bindeglied zw. Unterschiedlichen UML-Plugins 

Cpp2Uml + - - - - - - - + - + + Generiert Diagramm aus dem C++-Code 

CRUD Booster + - - - - - - - + + + - 

DresdenOCL + - - - - - - - + + - kA 

DSM/IA 

- - - - - - - - - + - kA 

E-Platero + - - - - - - - + - - + 

EMF Triple 

- - - - - - - - - - - kA 

Open Source 

Bemerkungen 

Generiert DSM (Dependency Structure Matrix) 

aus UML 

Speichern und Laden von EMF-Modellen in/aus 

RDF-Datenquellen (EMF – Eclipse Modeling 

Framework, RDF – Resource Description 

Framework) 

eUML2 + - - - + - - - + + + - 

Green UML + - - - - - - - + + + + 

Hiber Objects + - - - + - - - + + - + 

IBM Rational Rose 

XDE Modeler 

+ + - + + + + - + - - - 

IBM Rational + + - + - - - - + + kA - Zum Bestandteil von Rational Software 

24

UML-Werkzeug 

Class 


Use Case 

Unterstützte 

Diagrammtypen 

Activity 

State Machine 

Sequence 

Component 

Deployment 

Composite 

Structures 





diagrams) 

Software Modeler Architect geworden 

IBM UML2 Utilities 

for Model Driven 

Development 

k 

A 

k 

A 

k 

A 

k 

A 

k 

A 

k 

A 

k 

A 

kA kA kA kA kA 

Entwicklung eingestellt 

IdafeUML + + P - P - - - + + + kA 

Janus - Java'n'UML 

Simultanously 

+ - - - - - - - + + + + 

Java To UML2 + - - - - - - - - - + + Konvertiert den Java-Code ins UML-Modell 

JS/UML 

+ - - - - - - - - - + + 

Konvertiert den JavaScript-Code ins UML- 

Modell 

Jupe + - - - - - - - + + + + 

LightUML + - - - - - - - + - + + Generiert Diagramme aus dem Java-Code 

M2Code for Java - 

Konvertiert UML2-Modelle in Java Enterprise 

Agile Model Driven 

JEE Generator 

+ + + - + - - - - + - - Applications 

M2Flex - Agile Model 

Konvertiert UML2-Modelle in RIA auf Basis von 

Driven Flex App + + + - + - - - - + - - Flex/Spring/Hibernate (RIA – Rich Internet 

Generator 

Application) 

M2Spring - Agile 

Konvertiert UML2-Modelle in Spring 2.5 

Spring 2.5 

Application 

Generator 

+ + + - + - - - - + - - 

Enterprise Applications 

MaintainJ + - - - + - - - + - + - Generiert UML aus dem Code 

MDWorkbench + + + + + + + + + + - - 

25 

Open Source 

Bemerkungen

UML-Werkzeug 

Class 


Use Case 

Unterstützte 

Diagrammtypen 

Activity 

State Machine 

Sequence 

Component 

Deployment 

Composite 

Structures 





diagrams) 

Mentor Graphics 

EDGE UML Suite 

+ + + + + - - - + + - - 

Mia-Studio + + + + + + + + + + - + 

MOSKitt – UML + + + + + - - - + + + + 

Obeo Designer - + - - + - - - + + - - 

ObjectAid UML 

Designer 

+ - - - + - - - + - + -/+ 

Objecteering/UML + + + + + + + - + + - - 

ObjectiF Eclipse 

Edition 

+ + + + - - - - + + + - 

Papyrus 

PlantUML 

+ + P + - + + + + + - + 

+ + + + + + - - + - + + 

Poseidon UML 

professional edition 

QiQu - Code 

+ + + + + + + - + + - - 

Generator 

Framework 

- - - - - - - - - + - + 

Slime UML + + - - - - - - + + + - 

Taylor MDA 

+ + + - - - - - + + - + 

TextUML Toolkit + - - - - - - - + + + kA 

26 

Open Source 

Bemerkungen 

Konvertiert UML-Modelle in den C/C++-Code 

Diagramme werden nicht in einem visuellen 

Editor gezeichnet, sondern durch speziellen 

Code definiert und vom Plugin gezeichnet bzw. 

in eine Grafik gerendert 

Transformiert XMI in den Code (Java, C#) 

Spezialisiert auf der Entwicklung von 

Enterprise Applications

UML-Werkzeug 

Class 


Use Case 

Unterstützte 

Diagrammtypen 

Activity 

State Machine 

Sequence 

Component 

Deployment 

Composite 

Structures 





diagrams) 

+ + + + + + + + + + + - ↔ 

Together Community 

Edition for Eclipse 

+ + + - + - - - + + + - 

TOPCASED UML 

Editor 

+ + + + + + + + + + + + 

UML Tool for Eclipse 

(SDE-EC Community 

Edition, Visual 

Round-trip engineering UML2 Java 

Paradigm for UML) 

UMLet - Fast UML 

Editor 

+ + + + - - - - + - - + 

UniMod + - + + - - - - + + - kA 

Violet UML Editor for 

Eclipse 

+ + + + - - - - + - - + 

Visual UML Editor 

Eclipse Plugin 

+ - + - - - - - + - - + 

27 

Open Source 

Bemerkungen


Zu erwähnen sind einige Werkzeuge, die zwar alle 4 benötigten 

Diagrammtypen unterstützen (Kriterium II-b ist somit erfüllt) und dabei 

softwaretechnisch als ausgereift und funktionsreich einzuschätzen sind, jedoch 

aus Lizenzgründen im Rahmen der gestellten Anforderungen nicht 

berücksichtigt werden können (Kriterium II-a ist nicht erfüllt). 

Das sind solche Tools wie SDE-EC Community Edition, Objecteering/UML for 

Java etc. Weiteres Beispiel: das Paket Poseidon von Gentleware AG bietet zwar 

die Möglichkeit, es unter einer Open Source-Lizenz (mit speziellen 

Bedingungen) zu benutzen, diese gilt aber nur für die Community Edition des 

Produktes, die im Gegensatz zur Professional Edition keine Eclipse-Integration 

hat und auch kostenpflichtig ist. 

Andererseits gibt es eine Reihe von UML-Tools, die zwar als Open Source 

lizenziert sind (Kriterium II-a ist erfüllt) und Erstellung von Diagrammen 

mehrerer (unter anderem für diese Arbeit nicht in Frage kommender) Typen 

ermöglichen (z.B. Sequence, Communication etc.), von den 4 benötigten aber 

nicht alle unterstützen (bzw. zum Zeitpunkt dieser Arbeit noch nicht 

unterstützten wie z.B. Slime UML, wo Activity und State Machine-Diagramme 

erst in Planung waren). Kriterium II-b ist somit nicht erfüllt. 

Eine ergänzende Anforderung muss gestellt werden, um den Begriff der 

visuellen Diagrammerstellung zu präzisieren. Die gesuchten Tools müssen 

semantische Vorgehensweise beim Erstellen von Diagrammen unterstützen, 

d.h. die Verbindungen zwischen einzelnen Bestandteilen des Diagramms 

müssen vom Tool während der Entwicklung registriert, verfolgt und 

dementsprechend bei visuellen Änderungen angepasst werden. Ein 

Gegenbeispiel ist das Tool UMLet, das zwar alle 4 benötigten Diagrammtypen 

unterstützt (Kriterium II-b), dabei aber über keine semantische Bindungen 

verfügt: alle Elemente des Diagramms sind lediglich grafische Objekte ohne 

Zusammenhänge, was z.B. zur Folge hat, dass die grafische Darstellung von 

Kantenverbindungen beim Ändern der Knotenpositionen immer wieder 

händisch angepasst werden muss. 

Ein nennenswertes, aber leider nicht zu berücksichtigendes Tool ist PlantUML, 

das zwar Open Source ist (Kriterium II-a) und alle 4 Diagrammtypen 

unterstützt (Kriterium II-b). Diagramme werden jedoch nicht in einem 

visuellen Editor gezeichnet, sondern durch einen speziellen Code definiert und 

vom Plugin gezeichnet bzw. in eine Grafik gerendert. 

3.3 Entscheidung 

3.3.1 Ausgewählte Tools 

28


Durch die Berücksichtigung von Kriterien II-a und II-b (Open Source-Lizenz + 

Unterstützung von 4 erwähnten Diagrammtypen) werden schließlich nur in 

Tabelle 3.2 aufgeführte UML-Tools ausgewählt. 

Tabelle 3.2. Für die Entscheidung ausgewählte UML-Werkzeuge 

UML-Werkzeug Ausführung 

MOSKitt Standalone RCP auf Eclipse-Basis 

Papyrus 

– Standalone RCP auf Eclipse-Basis 

– Eclipse-Plugin 

TOPCASED UML Editor Standalone RCP auf Eclipse-Basis (zum 

Zeitpunkt dieser Arbeit allerdings nur für 32-Bit- 

Systeme verfügbar) 

Violet UML Editor for 

Eclipse 

– Standalone JAR 

– Eclipse-Plugin 

Diese Werkzeuge werden in Bezug auf Unterstützung von weiterer UMLbezogener 

Funktionalität untersucht, in erster Linie von Profilen und 

Stereotypen. 

Violet UML Editor for Eclipse wird aus weiteren Betrachtungen mangels 

Unterstützung von Profilen und Stereotypen sowie auf Grund von insgesamt 

relativ dürftiger UML-Unterstützung (es werden nur grundlegende Elemente 

unterstützt) ausgeschlossen. 

Papyrus konnte zum Zeitpunkt der Tool-Analyse keine Unterstützung für 

Aktivitätsdiagramme aufweisen: sie hätte zwar lt. Roadmap schon längst 

implementiert sein müssen, auf der Webseite waren Aktivitätsdiagramme 

damals jedoch als "Still under development" markiert, dementsprechend fehlte 

auch deren Unterstützung im Tool selbst. Aus diesem Grund wurde Papyrus aus 

der Betrachtung ausgenommen. 

Beispiele für Klassendiagramme, die mit MOSKitt, Papyrus, TOPCASED und 

Violet erstellt wurden, sind auf Abb. 3.1, 3.2, 3.3 und 3.4 zu sehen. 

29


Abbildung 3.1 Klassendiagram in MOSKitt 

Abbildung 3.2. Klassendiagramm in Papyrus 

30


Abbildung 3.3. Klassendiagramm in TOPCASED 

3.3.2 Detaillierte Analyse 

Abbildung 3.4. Klassendiagramm in Violet 

Nachfolgende Tabellen enthalten Informationen zu den beiden letzlich 

ausgewählten Tools – MOSKitt und TOPCASED UML Editor: 

– Tabelle 3.3 – Unterstützung von UML-Features, die für diese Arbeit von 

Bedeutung sind. 

– Tabelle 3.4 – Nicht-funktionale (Vergleichs)Kriterien. 

Tabelle 3.3. Unterstützung von UML-Features 

31

UML- 

Werkzeug 


Version Profile Stereotype 

Pins 

Nested 

Classes 

MOSKitt 1.3.0 + + + - 

TOPCASED 5.0.0 + + + - 

Tabelle 3.4. Nicht-funktionale Kriterien 

Kriterium MOSKitt TOPCASED 

Dokumentation 

Bedienung 

Support 

– Spanische Version ist nicht ganz 

aktuell (Dokumentation v. 1.1.0 

bei aktueller MOSKitt-Version 

1.3.0), Englische Version ist 

veraltet (0.7.0) und enthält 

teilweise Sätze und Beispiele 

auf Spanisch. 

– Aus MOSKitt aufgerufene Hilfe 

ist teilweise auf Spanisch. 

– Auf der Webseite sind Webcasts 

zur Bedienung des Programms 

verfügbar. 

– Bequeme Bedienung, Aufbau 

des UI ähnelt sehr dem bei 

TOPCASED. 

– Palette der UML-Elemente ist 

nicht vollständig, es fehlt z.B. 

Central Buffer Node (zentraler 

Pufferknoten). 

– Nettes, hilfsbereites und 

verständnisvolles Team, wobei 

der Kontakt nur über Frau Dr. 

Koch möglich war. 

– Aktuelle 

Dokumentation ist 

vorhanden. 

– Bequeme Bedienung, 

Aufbau des UI ähnelt 

sehr dem bei 

MOSKitt. 

– Umfangreiche Palette 

der UML-Elemente. 

– Mailinglisten zu 

einzelnen Bereichen 

stehen zur Verfügung 

(für Benutzer, 

Entwickler etc.). 

3.3.3 Entscheidung über das Tool für die UWE-Erweiterung 

Als Werkzeug, das als Zielplattform für UWE-Erweiterungen im Rahmen dieser 

Arbeit dienen soll, wird aufgrund des abschließenden Vergleichs TOPCASED 

ausgewählt. Fukntionen für die UWE-Notation und UWE-basierte Modellierung 

32


von Webanwendungen werden als eine in TOPCASED integrierte Lösung 

implementiert. 

33


4 Anforderungsanalyse 

In diesem Kapitel werden Anforderungen an die zu implementierende Software 

gestellt. Folgende Aspekte werden festgelegt: 

– Zielplattform, wo das zu implementierende Tool integriert sein soll 

– Art der Integration 

– Benutzerinteraktion 

– Menüstruktur 

– Funktionalität 

4.1 Zielplattform und Integration 

Die zu entwickelnde Software-Lösung für die Unterstützung der UWE-Methodik 

(vorläufiger Codename: UWEclipse) soll in den TOPCASED UML Editor integriert 

werden. Es ist ein grafisches UML-Modellierungswerkzeug (Eclipse-basierte 

RCP), das im Kapitel 3 als Zielplattform für die Implementierung von UWE 

vorgesehener Funktionen und Möglichkeiten ausgewählt wurde. 

TOPCASED ist unter [web-topcased-download] erhältlich und lag zum 

Zeitpunkt dieser Diplomarbeit in der Version 5.0.0 9 vor. 

Es bietet sich an, UWEclipse in Form eines Eclipse-Plugins zu entwickeln. Auf 

diese Weise kann es problemlos in jede mit TOPCASED ausgestattete Eclipse- 

Distribution integriert werden und auf der Funktionalität von TOPCASED 

aufbauen. 

4.2 Benutzeroberfläche 

UWEclipse soll dem Benutzer folgende GUI-Elemente zur Verfügung stellen (die 

in die Eclipse/TOPCASED-Benutzeroberfläche integriert sein sollen): 

– UWEclipse-Hauptmenü in der Eclipse-Menüleiste (Nr. 1 auf Abb. 4.1) 

– Erweiterung des Kontextmenüs im Projektbaum (Nr. 2 auf Abb. 4.1) 

– Erweiterung des Kontextmenüs im Diagrammeditor (Nr. 3 auf Abb. 4.1) 

9 Zum Zeitpunkt des Abschlusses der Arbeit war bereits die Version 5.1.0 herunterzuladen, diese konnte jedoch nicht 

mehr berücksichtigt werden 

34


– Erweiterung der Palette im Diagrammeditor (Nr. 4 auf Abb. 4.1) 

4.2.1 Hauptmenü 

Abbildung 4.1. Grafische Integration von UWEclipse 

Der Eintrag für das UWEclipse-Hauptmenü (Namensgebung: UWEclipse) soll 

sich in der Eclipse-Menüleiste befinden. Die Menüstruktur sieht 

folgendermaßen aus: 

UWEclipse 

New UWE Diagram 

Content Diagram 

Navigation Diagram 

Presentation Diagram 

Process Structure Diagram 

Process Flow Diagram 

Transformations 

Content → Navigation 

Navigation → Presentation 

Navigation → Process Structure 

35


Navigation → Process Flow 

Create Default Models 

Apply Profile 

About UWEclipse 

Das Anwendungsfalldiagramm für die Arbeit mit dem UWEclipse-Hauptmenü ist 

auf Abb. 4.2 dargestellt. 

Abbildung 4.2. Anwendungsfalldiagramm für das UWEclipse-Hauptmenü 

4.2.1.1 Menüeintrag New UWE Diagram 

Folgende UWE-Modelltypen sollen zur Verfügung gestellt werden: 

– Content 

– Navigation 

– Presentation 

– Process Structure 

– Process Flow 

36


Für jeden dieser UWE-Modelltypen soll es einen gleichnamigen Menüeintrag im 

Untermenü New UWE Diagram des UWEclipse-Hauptmenüs geben. Beim Aufruf 

eines solchen Menüeintrages wird ein leeres TOPCASED-Modell mit einem 

leeren TOPCASED-Diagramm angelegt: 

– Klassendiagramm für alle UWE-Modelltypen außer Process Flow 

– Aktivitätsdiagramm für Process Flow 

Daraufhin soll auf das TOPCASED-Modell folgendes angewendet werden: 

a) das (vorher geladene) UWE-Profil 

b) das entsprechende UWE-Stereotyp: 

• UWE Profile::contentModel 

• UWE Profile::navigationModel 

• UWE Profile::presentationModel 

• UWE Profile::processModel 

Das soeben angelegte TOPCASED-Diagramm soll danach im Diagrammeditor 

geöffnet werden. Der als Standard vergebene TOPCASED-Diagrammname wird 

vom Namen des UWE-Modelltyps abgeleitet (New Content Diagram, New 

Navigation Diagram, New Presentation Diagram, New Process Structure 

Diagram, New Process Flow Diagram). 

Bei jedem TOPCASED-Modell soll intern ein Vermerk über den entsprechenden 

UWE-Modelltyp mit gespeichert werden. Des Weiteren ist die 

Auswahlmöglichkeit der UWE-Modellierungselemente vom UWE-Modellttyp 

abhängig. 

Auf Abb. 4.3 ist das Aktivitätsdiagramm für den Menüeintrag New UWE Diagram 

dargestellt. 

37


Abbildung 4.3. Aktivitätsdiagramm für den Menüeintrag New UWE Diagram 

4.2.1.2 Menüeintrag Transformations 

Im Untermenü Transformations des UWEclipse-Hauptmenüs stehen die 

Transformationsmöglichkeiten unter verschiedenen UWE-Modelltypen zur 

Verfügung: 

– Content → Navigation 

– Navigation → Presentation 

– Navigation → Process Structure 

– Navigation → Process Flow 

Dabei wird das aktuell im visuellen Diagrammeditor geöffnete Diagramm in das 

Diagramm des jeweiligen Zieltyps umgewandelt – vorausgesetzt, dass das 

aktuelle TOPCASED-Diagramm einem UWE-Modelltyp entspricht (d.h. mit dem 

entsprechenden internem Vermerk versehen ist) und dass sein Typ mit dem 

Quelltyp des ausgewählten Menüeintrages übereinstimmt. Sollte das nicht der 

Fall sein oder wenn im Editor kein Diagramm vorhanden ist, soll eine 

entsprechende Meldung erscheinen. 

Auf Abb. 4.4 ist das Aktivitätsdiagramm für den Menüeintrag Transformations 

dargestellt. 

38


Abbildung 4.4. Aktivitätsdiagramm für den Menüeintrag Transformations 

4.2.1.3 Menüeintrag Create Default Models 

Mit Hilfe des Untermenüs Create Default Models des UWEclipse-Hauptmenüs 

sollen automatisch Modell-Container angelegt werden, die mit Ordnern im 

TOPCASED-Projektbaum repräsentiert werden: 

– Content 



– Process 

Auf Abb. 4.5 ist das Aktivitätsdiagramm für den Menüeintrag Create Default 

Models dargestellt. 

39


Abbildung 4.5. Aktivitätsdiagramm für den Menüeintrag Create Default 

Models 

4.2.1.4 Menüeintrag Apply Profile 

Menüeintrag Apply Profile des UWEclipse-Hauptmenüs bietet die 

Möglichkeit, das UWE-Profil zu laden und auf das Modell anzuwenden, falls 

noch kein Profil angewendet wurde. 

Auf Abb. 4.6 ist das Aktivitätsdiagramm für den Menüeintrag Apply Profile 

dargestellt. 

40


Abbildung 4.6. Aktivitätsdiagramm für den Menüeintrag Apply Profile 

4.2.1.5 Menüeintrag About UWEclipse 

Menüeintrag About UWEclipse des UWEclipse-Hauptmenüs enthält allgemeine 

Informationen über UWEclipse (Version etc.). 

Auf Abb. 4.7 ist das Aktivitätsdiagramm für den Menüeintrag About UWEclipse 

dargestellt. 

41


Abbildung 4.7. Aktivitätsdiagramm für den Menüeintrag About UWEclipse 

4.2.2 Kontextmenü im Projektbaum 

Im Kontextmenü des Projektbaums (Ansichten Package Explorer, Project 

Explorer, Navigator und Topcased Navigator) sollen UWEclipse-Funktionen 

zur Verfügung stehen, die für das Anlegen und die Transformationen von 

Diagrammen verantwortlich sind. Diese Funktionen sollen in das bereits 

vorhandene Eclipse/TOPCASED-Kontextmenü integriert sein. 

4.2.2.1 Neue Diagramme anlegen 

Beim Klick mit der rechten Maustaste auf einen Unterordner im Projektbaum 

(Ansichten Package Explorer, Project Explorer, Navigator und Topcased 

Navigator) sollen im Kontextmenü die Menüeinträge zum Anlegen von neuen 

Diagrammen für folgende UWE-Modelltypen erscheinen: 

– Content 




– Process Flow 

Die Funktionalität, die sich hinter diesen Menüeinträgen verbirgt, stimmt genau 

mit dem überein, was in 4.2.1.1 beschrieben wurde. 

Abb. 4.8 und 4.9 zeigen das Anwendungsfalldiagramm und das 

Aktivitätsdiagramm für diese Kontextmenüeinträge. 

Abbildung 4.8. Anwendungsfalldiagramm für das Kontextmenü im Projektbaum 

42


zum Anlegen von neuen Diagrammen 

Abbildung 4.9. Aktivitätsdiagramm für das Kontextmenü im Projektbaum zum 

Anlegen von neuen Diagrammen 

4.2.2.2 Transformation von Inhaltsmodellen 

Beim Klick mit der rechten Maustaste im Projektbaum (Ansichten Package 

Explorer, Project Explorer, Navigator und Topcased Navigator) auf einen 

Knoten, der einem Content Diagram entspricht, soll der Menüeintrag für die 

Transformation Content → Navigation escheinen. 

Die Funktionalität dieses Menüeintrages entspricht dem, was in 4.2.1.2 

beschrieben wurde, allerdings mit dem Unterschied, dass die Transformation 

nicht auf das aktuell im Diagrammeditor geöffnete Diagramm angewendet 

wird, sondern auf das im Baum ausgewählte. 


Aktivitätsdiagramm für diesen Kontextmenüeintrag. 

43


Abbildung 4.10. Anwendungsfalldiagramm für das Kontextmenü im 

Projektbaum für die Transformation von Inhaltsmodellen 

Abbildung 4.11. Aktivitätsdiagramm für das Kontextmenü im Projektbaum für 

die Transformation von Inhaltsmodellen 

4.2.2.3 Transformationen von Navigationsmodellen 

44


Beim Klick mit der rechten Maustaste im Projektbaum (Ansichten Package 

Explorer, Project Explorer, Navigator und Topcased Navigator) auf einen 

Knoten, der einem Navigation Diagram entspricht, sollen die Menüeinträge für 

die Transformationen Navigation → Presentation, Navigation → Process 

Structure und Navigation → Process Flow erscheinen. 

Die Funktionalität dieser Menüeinträge entspricht dem, was in 4.2.1.2 

beschrieben, allerdings mit dem Unterschied, dass die Transformation nicht auf 

das aktuell im Diagrammeditor geöffnete Diagramm angewendet wird, sondern 

auf das im Baum ausgewählte. 


Aktivitätsdiagramm für diese Kontextmenüeinträge. 

Abbildung 4.12. Anwendungsfalldiagramm für das Kontextmenü im 

Projektbaum für die Transformationen von Navigationsmodellen 

45


Abbildung 4.13. Aktivitätsdiagramm für das Kontextmenü im Projektbaum für 

die Transformationen von Navigationsmodellen 

4.2.3 Kontextmenü im Diagrammeditor 

Im Kontextmenü des Diagrammeditors sollen UWEclipse-Menüeinträge 

vorhanden sein, die den Attributen der Stereotype entsprechen, welche auf das 

gerade ausgewählte Element angewendet wurden (falls auf das ausgewählte 

Element keine Stereotype angewendet wurden, sollen keine UWEclipse- 

Einträge im Kontextmenü erscheinen). Bei der Auswahl eines Attributes aus 

dem Kontextmenü soll ein Fenster kommen, wo der Attributwert angegeben 

bzw. bearbeitet oder gelöscht werden kann. 

Diese Menüeinträge sollen nur für bestimmte Modelltypen und bestimmte 

46


Diagrammelemente verfügbar sein: 

– Modelltypen (beides TOPCASED-Klassendiagramme) 

• Navigation 

• Presentation 

– Klassendiagrammelemente 

• Klasse 

• Assoziation 

• Komposition 

• Aggregation 

Auf Abb. 4.14, 4.15, 4.16 und 4.17 sind Anwendungsfalldiagramme und 

Aktivitätsdiagramme für das Kontextmenü des Diagrammeditors für Elemente 

eines Navigations- bzw. eines Präsentationsmodells dargestellt. 

Abblidung 4.14. Anwendungsfalldiagramm für das Kontextmenü im 

Diagrammeditor für Elemente eines Navigationsmodells 

Abblidung 4.15. Anwendungsfalldiagramm für das Kontextmenü im 

Diagrammeditor für Elemente eines Präsentationsmodells 

47


Abblidung 4.16. Aktivitätsdiagramm für das Kontextmenü im Diagrammeditor 

für Elemente eines Navigationsmodells 

48


Abblidung 4.17. Aktivitätsdiagramm für das Kontextmenü im Diagrammeditor 

für Elemente eines Präsentationsmodells 

4.2.4 Palette im Diagrammeditor 

Die Palette des Diagrammeditors (Toolbar mit Diagrammelementen, Abb. 4.18) 

soll erweitert werden: es soll ein Bereich hinzugefügt werden, der Stereotype 

des geladenen Profils enthält. Dies soll jedoch nur für folgende UWE- 

Modelltypen gelten: 




49


Abbildung 4.18. Palette des Diagrammeditors 

50


5 Implementierung 

In diesem Kapitel wird die Entwicklung des Plugins beschrieben. Dabei werden 

implementierte Funktionen, technische Details der Implementierung, 

Designentscheidungen und während der Entwicklung entstandene technische 

Probleme beleuchtet. 

5.1 GUI-Abläufe 

Die Implementierung der UWEclipse-Funktionalität lehnt sich an einige Eclipsebzw. 

TOPCASED-Funktionen an, die bei gewissen Benutzeraktionen aufgerufen 

werden. So wird z.B. das Laden des UWE-Profils auf die Art und Weise 

implementiert, wie es beim Aufruf des Kontextmenüeintrages Load 

Resource... eines TOPCASED-Modells der Fall ist. Als nächstes werden solche 

auf der Benutzeroberfläche stattfindende Abläufe beschrieben, die bei der 

Implementierung als Referenz dienen. 

5.1.1 Anlegen eines TOPCASED-Modells 

Alle Abläufe setzen voraus, dass ein Projekt vom Typ Topcased Project 

vorliegt (Beispielsname topcased_uweclipse_test), das ein Modell vom Typ 

UML Model with TOPCASED enthält (Beispielsname demodel), welches mit der 

Option Empty model with a default diagram und dem Diagrammtyp Class 

Diagram erstellt wurde. Auf der Abb. 5.1 ist das Ergebnis in den Ansichten 

Topcased Navigator und Outline zu sehen. 

51


Abbildung 5.1. Referenzprojekt in TOPCASED 

5.1.2 Laden des UWE-Profils 

In der Outline-Ansicht im Kontextmenü des -Knotens wird der 

Menüeintrag Load Resource... ausgewählt. Anschließend wird über den 

Button Browse File System... das UWE-Profil ausgewählt und geladen. 

Nachdem das Profil geladen wurde, erscheint es in der Outline-Ansicht unter 

Additional Resources. Die Outline-Ansicht sieht dabei wie auf Abb. 5.2 

dargestellt aus. 

52


Abbildung 5.2. Geladenes UWE-Profil 

5.1.3 Anwenden des UWE-Profils auf das TOPCASED-Modell 

Das UWE-Profil wird auf das TOPCASED-Modell angewendet, indem man in der 

Outline-Ansicht im Kontextmenü des -Knotens den Menüeintrag 

Apply Profile und dort das UWE-Profil auswählt (Abb. 5.3). 

53


Abbildung 5.3. Anwenden des UWE-Profils auf das TOPCASED-Modell 

5.1.4 Anwenden eines Stereotyps auf das TOPCASED-Modell 

Ein Stereotyp wird auf das TOPCASED-Modell angewendet, indem man in der 

Outline-Ansicht im Kontextmenü des -Knotens den Menüeintrag 

Apply Stereotype auswählt (Abb. 5.4). 

54


Abbildung 5.4. Anwenden eines Stereotyps auf das TOPCASED-Modell 

5.1.5 Anwenden eines Stereotyps auf eine Klasse 

Im visuellen Diagrammeditor wird eine Klasse (SampleClass in unserem 

Beispiel) angelegt. Daraufhin erscheint in der Outline-Ansicht ein 

entsprechender Knoten ( SampleClass unter → 

demodel). Im Kontextmenü des Klassenknotens ist der Menüeintrag Apply 

Stereotype und anschließend das gewünschte Stereotyp auszuwählen (Abb. 

5.5). 

Alternativ kann man die Stereotypauswahl auch über die Eigenschaftsansicht 

der Klasse in grafischer Darstellung im Diagrammeditor vornehmen: Klick mit 

der rechten Maustaste auf die betroffene Klasse im Diagrammeditor → Show 

Properties → Bereich Stereotypes → Stereotyp auswählen und mit Add > 

anwenden (Abb 5.6). 

55


Abbildung 5.5. Anwenden eines Stereotyps auf eine Klasse in der Outline- 

Ansicht 

Abbildung 5.6. Anwenden eines Stereotyps auf eine Klasse im Diagrammeditor 

56


5.2 Designentscheidungen 

Bei Designentscheidungen sowie TOPCASED-bezogenen Fragen in Hinsicht auf 

Entwicklung und Verwendung wurde die TOPCASED-Kommunikationsplattform 

in Form von Mailinglisten [web-topcased-mail-users] und [web-topcased-maildevel] 

([web-topcased-contacts]) benutzt. Auf diese Weise wurde über einige 

nachfolgende Punkte entschieden. 

5.2.1 Ermitteln von Stereotypeigenschaften 

Eigenschaften eines Stereotyps (die z.B. im Profilbaum von MagicUWE unter 

dem jeweiligen Stereotypknoten angezeigt werden) lassen sich mit Hilfe der 

beiden Methoden Stereotype.getAllAttributes() und 

Stereotype.getFeatures() ermitteln: 

Stereotype stereo; 

... 

// Alternative 1 

for ( Property prop : stereo.getAllAttributes() ) { /* Behandlung 

von prop */ } 

// Alternative 2 

for ( Feature feat : stereo.getFeatures() ) { /* Behandlung von 

feat */ } 

Es gibt jedoch einen Unterschied zwischen den beiden Alternativen, der sich 

z.B. beim UWE-Profil zeigt: dort liefern zwar beide Alternativen in meisten 

Fällen die selben Ergebnisse, es gibt jedoch einige Stereotype, wo 

getAllAttributes() jeweils 1 Element mehr liefert, als getFeatures(). Das 

ist immer die Eigenschaft isHome. Aus diesem Grund wurde bei der 

Entwicklung für die Methode getAllAttributes() entschieden. 

5.2.2 Nested Classes 

Die Arbeit mit Nested Classed war zum Zeitpunkt dieser Arbeit nicht möglich, 

da deren Darstellung von TOPCASED nicht unterstützt wurde. 

5.2.3 Kontextmenü im Diagrammeditor 

Es wurde beschlossen, das Kontextmenü im Diagrammeditor (4.2.3) nicht zu 

implementieren, da TOPCASED bereits eine bequeme Oberfläche für die 

Bearbeitung von Attributwerten eines Stereotyps bereitstellt (Abb. 5.7). Man 

57


gelangt dorthin, indem man Show Properties im Kontextmenü des 

selektierten Diagrammelements auswählt und dort in den Bereich Stereotype 

Attributes geht. 

Abbildung 5.7. Attribute eines Stereotyps im TOPCASED UML Editor 

5.2.4 Palette im Diagrammeditor 

Ursprüngliche Anforderung war, die Palette des TOPCASED-Diagrammeditors zu 

erweitern, und zwar um einen Bereich, der Stereotype des geladenen Profils 

enthalten würde (4.2.4). 

Dazu wäre folgendes benötigt: 

– Erweiterung (durch Vererbung) beider abstrakter Klassen 

• ModelerPaletteManager [src-topcased-ModelerPaletteManager] 

• AbstractCreationUtils [src-topcased-AbstractCreationUtils] 

– Integration neuer Klassen in den Quellcode 

Das Problem dabei: diese Vorgehensweise ist nur als Erweiterung des 

TOPCASED-Quellcodes möglich, d.h. nicht als Bestandteil des zu 

programmierenden Eclipse-Plugins. Dies hat zur Folge, dass man sich für eine 

der beiden Entwicklungsstrategien entscheiden müsste: 

58


– Fork (Abspaltung) von TOPCASED, d.h. Gründung eines eigenständigen 

Projektes auf Basis von TOPCASED – zwar mit Implementierung 

gewünschter Änderungen an der Palette, jedoch auch mit genereller 

Weiterentwicklung des gesamten Projektes, was sich natürlich im 

Widerspruch zum Ziel und den Möglichkeiten dieser Arbeit befindet. 

– Anpassung des aktuellen TOPCASED-Quellcodes, allerdings ohne 

Absichten, daraus einen Fork zu machen. Diese Variante ist jedoch 

äußerst kurzlebig und bedarf ständiger Neuimplementierung bei jedem 

größeren Versionssprung von TOPCASED, weil sich der bei Anpassungen 

benutzte TOPCASED-Quellcode in jeder neuen Version ändert, ggf. auch 

radikal. 

Somit wurde auf das Thema Palettenerweiterung verzichtet. 

5.2.5 Drag & Drop von Stereotypen 

Eine Idee war, Stereotype aus dem Profil auszulesen, in einem Baum 

darzustellen und dort die Möglichkeit zur Verfügung zu stellen, sie per Drag & 

Drop in den Diagramm-Bereich zu ziehen und auf die jeweilige Zielklasse 

automatisch anzuwenden. Nach dem Austausch in [web-topcased-mail-devel] 

stellte sich heraus, dass es in TOPCASED keine direkte Möglichkeit für diese Art 

von Drag & Drop gibt. Es sollte jedoch möglicherweise mit Hilfe eines Drop 

Listeners machbar sein, der zum TOPCASED-Editor programmtechnisch 

hinzugefügt werden müsste. Ein Beispiel für solche Vorgehensweise sollte die 

Klasse DropListenersManager [src-topcased-DropListenersManager] 

darstellen. Es war jedoch nicht möglich, auf Basis dieser Klasse 

nachzuvollziehen, wie der gewünschte Mechanismus in Bezug auf TOPCASED- 

Editor implementiert werden könnte. Aus diesem Grund wurde die Drag & 

Drop-Funktion für Stereotype im Baum nicht implementiert. 

5.3 Implementierungsdetails 

UWEclipse wurde in Java geschrieben und stellt ein Eclipse-Plugin dar. In 

diesem Abschnitt werden die softwaretechnischen Aspekte der 

Implementierung von UWeclipse beleuchtet. 

5.3.1 Projektstruktur 

Das Java-Projekt von UWEclipse trägt den Namen psu, der noch vor der 

Entscheidung über die Namensgebung festgelegt wurde und soviel wie Profiles 

and Stereotypes for UWE bedeutet. Die Struktur des Projektes ist auf Abb. 5.8 

59

zu sehen. 


Abbildung 5.8. Projektstruktur 

Wie man der Abb. 5.8 entnehmen kann, ist das Projekt in mehrere Packages 

aufgeteilt: 

– psu – Verwaltung vom Lebenszyklus des Plugins (Activator.java), 

Ansichtsfenster des Plugins (psu-Ansicht, psuView.java) 

– psu.controllers – Klassen für die Arbeit mit Profilen, Stereotypen und 

Diagrammen 

– psu.enums – Aufzählungstypen (enum) 

– psu.handlers – Ereignisbehandlungsroutinen für das UWEclipse- 

Hauptmenü sowie für die Kontextmenüs 

– psu.tree – Klassen für die Darstellung von Stereotypen und deren 

Eigenschaften in einer Baumstruktur 

5.3.2 Benutzeroberfläche 

60


5.3.2.1 Ansichtsfenster 

Das Plugin verfügt über eine Eclipse-typische andockbare Ansicht (view), die 

beim Start leer ist und beim Laden eines UML-Profils durch UWEclipse mit den 

darin enthaltenen Stereotypen und deren Eigenschaften aufgefüllt wird. 

Stereotype und Stereotypeigenschaften werden in Form einer Baumstruktur 

mit 2 Ebenen dargestellt (Mitglied TreeViewer tree der Klasse psu.psuView), 

wie auf Abb. 5.9 dargestellt. Die psu-Ansicht ist beim Erststart nicht zu sehen 

und kann über das Eclipse-Menü aktiviert werden: Window | Show View | 

Other... → psu → psu. 

61


Abbildung 5.9. psu-Ansicht mit Stereotypen und Stereotypeigenschaften aus 

dem UWE-Profil 

5.3.2.2 Hauptmenü 

Das UWEclipse-Hauptmenü wurde lt. Anforderungen in 4.2.1 implementiert 

und ist auf Abb. 5.10 dargestellt. Menüdefinitionen wurden in der Datei 

plugin.xml vorgenommen, und zwar im Register Extensions, Bereiche 

62


org.eclipse.ui.commands, org.eclipse.ui.handlers und 

org.eclipse.ui.menus. Die Bearbeitung von Ereignissen, die bei 

Menüaufrufen auftreten, wird von der Klasse psu.handlers.MainHandler 

übernommen. 

Abbildung 5.10. UWEclipse-Hauptmenü 

5.3.2.3 Kontextmenü im Projektbaum 

Kontextmenüeinträge im Projektbaum (Anforderungen in 4.2.2) sind auf Abb. 

5.11 zu sehen. Sie sind in der Datei plugin.xml definiert, und zwar im 

Register Extensions, Bereich org.eclipse.ui.popupMenus: 

psu.objectContribution01 (Anlegen von UWE-Diagrammen) und 

psu.objectContribution02 (Transformationen). Beide sind vom Typ 

objectContribution, d.h. die entsprechenden Menüeinträge werden nur beim 

Selektieren von GUI-Objekten eines bestimmten Typs (angegeben jeweils in 

der objectClass-Eigenschaft) aktiv und erscheinen daraufhin im 

Kontextmenü: 

– psu.objectContribution01 (Anlegen von UWE-Diagrammen) gilt nur 

für Objekte vom Typ org.eclipse.core.resources.IFolder 

– psu.objectContribution02 (Transformationen) gilt nur für Objekte vom 

Typ org.eclipse.core.resources.IFile 

Die Bearbeitung von Ereignissen, die bei Menüaufrufen auftreten, wird von der 

Klasse psu.handlers.PopupHandler übernommen. 

63


Abbildung 5.11. Kontextmenüeinträge im Projektbaum 

5.3.2.4 Kontextmenü im Diagrammeditor 

Das Kontextmenü im Diagrammeditor (4.2.3) wurde zwar aus den in 5.2.3 

dargelegten Gründen nicht implementiert. Es wurde jedoch die Möglichkeit der 

Implementierung eines solchen Menüs untersucht. 

Die Definition erfolgte in der Datei plugin.xml, Register Extensions, Bereich 

org.eclipse.ui.popupMenus. Der objectContribution-Eintrag, der für das 

Kontextmenü UWEClipse - Stereotype attributes verantwortlich ist, heißt 

psu.contextmenu.classeditpart und ist mit dem Typ (objectClass) 

org.topcased.modeler.uml.classdiagram.edit.ClassEditPart verbunden, 

so dass das beschriebene Kontextmenü nur beim Selektieren von 

ClassEditPart-Objekten erscheint. 

Somit ist für jeden relevanten Typ grafischer Diagrammelemente ein eigenes 

Kontextmenü benötigt. Eine wichtige Frage, die in diesem Zusammenhang 

aufkommt, ist die Ermittlung der entsprechenden Klasse, die jeweils als 

objectClass einzutragen ist. Dieses Problem wird wie folgt gelöst: Man 

selektiert das gewünschte Diagrammelement im Diagrammeditor und drückt 

die Tastenkombination ALT+SHIFT+F1. Dabei erscheint das Fenster des in 

Eclipse integrierten Tools namens Plug-in Selection Spy (Abb. 5.12). In 

diesem Fenster kann man den Namen der gesuchten Klasse sehen (The type 

of the selected element). 

Die Bearbeitung von Ereignissen, die bei Menüaufrufen auftreten, würde in der 

Klasse psu.handlers.PopupHandler erfolgen. 

64


Abbildung 5.12. Plug-in Selection Spy 

5.3.2.5 Palette im Diagrammeditor 

Die Erweiterung der Palette des Diagrammeditors (4.2.4) wurde aus den in 

5.2.4 dargelegten Gründen nicht implementiert. 

5.3.3 Anlegen von Modell-Containern 

Die Modell-Container für Diagramme (4.2.1.3) werden in Form von Ordnern im 

Projektbaum angelegt. Die dafür verantwortliche Funktion, 

psu.controllers.DiagramController.CreateFolders(), ermittelt das 

aktuell selektierte Element im Projektbaum, leitet davon den Rootordner des 

Projektes ab und übergibt ihn sowie die Namen der anzulegenden Ordner an 

die Hilfsfunktion psu.controllers.DiagramController.create_folder(), die 

das Anlegen von Ordnern übernimmt. 

65


Auf der Abb. 5.13 ist das Ergebnis der Funktion zu sehen. 

Abbildung 5.13. Von UWEclipse angelegte Modell-Container für Diagramme 

5.3.4 Laden und Anwenden des Profils 

Das Laden und das Anwenden des Profils (4.2.1.4) ist in der Funktion 

LoadApplyProfile() der Klasse psu.controllers.ProfileController 

implementiert. 

Die Funktion versucht zunächst das aktuelle Diagramm im Diagrammeditor zu 

ermitteln und zu überprüfen, ob darauf bereits ein Profil angewendet wurde. 

Falls das der Fall ist, wird die Funktion verlassen. Dieser Vorgang sieht wie 

folgt aus (Fehlerbehandlung wurde zwecks besserer Lesbarkeit ausgelassen): 

UMLEditor editor = (UMLEditor)UMLPlugin.getDefault(). 

GetWorkbench().getActiveWorkbenchWindow().getActivePage(). 

getActiveEditor(); 

Diagram dia = editor.getActiveDiagram(); 

Package pack = (Package)Utils.getDiagramModelObject(dia); 

Integer I = pack.getAllAppliedProfiles().size(); 

if (I >= 1) { 

msg(I.toString() + " profile(s) already applied (" + 

pack.getAllAppliedProfiles().get(0).getName() + ")."); 

return; 

} 

Als Nächstes wird mit Hilfe eines FileDialog-Objekts dem Benutzer die 

Möglichkeit zur Verfügung gestellt, die Profildatei auszuwählen. 

Die Profildatei wird mit Hilfe der getResource()-Methode der Klasse 

org.eclipse.emf.ecore.resource.ResourceSet ausgelesen: 

ResourceSet rs = new ResourceSetImpl(); 

URI profilePath = URI.createURI("file:////" + filepath); 

Resource profileResource = rs.getResource(profilePath,true); 

Profile profile = (Profile)EcoreUtil.GetObjectByType 

(profileResource.getContents(),UMLPackage.eINSTANCE.getProfile()); 

66


Zum Ermitteln aller im Profil enthaltenen Stereotype wird die Methode 

Profile.allOwnedElements() verwendet: 

EList lst = profile.allOwnedElements(); 

for ( Element item : lst ) { 

if (!(item instanceof Stereotype)) continue; 

// Hier kommt die Behandlung des Stereotyps "(Stereotype)item" 

} 

Eigenschaften eines Stereotyps werden mit Hilfe von 

Stereotype.getAllAttributes() ermittelt (5.2.1 enthält die Erklärung, 

warum dabei auf Stereotype.getFeatures() verzichtet wurde): 

Stereotype stereo; 

for ( Property prop : stereo.getAllAttributes() ) { /* Behandlung 

von prop */ } 

Für die Anzeige von Stereotyp- und Eigenschaftsbezeichnungen können jeweils 

folgende äquivalente Aufrufe benutzt werden: 

– Stereotypbezeichnung: Stereotype.getKeyword() oder 

Stereotype.getLabel() 

– Eigenschaftsbezeichnung (mittels Property-Klasse): 

Property.getName() oder Property.getLabel() 

– Eigenschaftsbezeichnung (mittels Feature-Klasse): Feature.getName() 

oder Feature.getLabel() 

Für Testzwecke und zur Veranschaulichung des Inhalts des UWE-Profils werden 

darin enthaltene Stereotype und deren Eigenschaften in einer Baumstruktur in 

der psu-Ansicht des UWEclipse dargestellt. Dafür sind folgende Module aus 

dem psu.tree-Package verantwortlich: 

– UweTreeContentProvider.java 

– UweTreeItem.java 

– UweTreeLabelProvider.java 

Das Anwenden des Profils erfolgt mit Hilfe der Funktion 

Package.applyProfile(), anschließend wird das Diagramm aktualisiert und 

abgespeichert: 

pack.applyProfile(profile); 

editor.refreshActiveDiagram(); 

editor.doSave(null); 

67


5.3.5 Anlegen von Diagrammen 

Das Anlegen von UWE-Diagrammen (Content, Navigation, Presentation, 

Process Structure, Process Flow), wie in 4.2.1.1 und 4.2.2.1 beschrieben, 

erfolgt mit Hilfe der Funktion CreateModel() der Klasse 

psu.controllers.DiagramController. 

Anhand der übergebenen UWE-Modelltyp-Kennung (ein Wert vom Typ 

psu.enums.UweModelType) wird die UML-Diagrammtyp-Kennung ermittelt (ein 

Wert vom Typ psu.enums.UmlDiagramType): Aktivitätsdiagramm für Process 

Flow, Klassendiagramm für alle anderen UWE-Modelltypen. Danach wird auf 

Basis der UML-Diagrammtyp-Kennung eine interne TOPCASED-ID der 

jeweiligen Diagrammschablone ermittelt, die in TOPCASED-Funktionen zur 

Angabe des Typs des anzulegenden Diagramms dient. Diese 2-stufige 

Umwandlung (UWE-Modelltyp → UML-Diagrammtyp → TOPCASED- 

Diagrammschablone-ID) könnte zwar reduziert werden, indem man den UML- 

Diagrammtyp (psu.enums.UmlDiagramType) ausschließt, so ist es aber eine 

klarere und mehr strukturierte Vorgehensweise. 

Auf Basis des selektierten Elementes im Projektbaum wird der Zielordner 

ermittelt. Anschließend werden mit Hilfe eines 

org.topcased.modeler.extensions.Template-Objekts 2 Diagrammdateien 

angelegt: eine .uml- und eine .umldi-Datei. Letztere wird im Diagrammeditor 

geöffnet. 

Auf der Abb. 5.14 ist das Ergebnis der Funktion zu sehen. 

Abbildung 5.14. Von UWEclipse angelegtes und geöffnetes Diagramm 

Beim Anlegen von Diagrammen wurde intensiv Gebrauch von Teilen des Codes 

aus folgenden TOPCASED-Klassen gemacht: 

– UMLDiagramsPage ([src-topcased-moskitt-UMLDiagramsPage]) 

– DiagramsPage ([src-topcased-DiagramsPage]) 

– NewUMLDiagrams ([src-topcased-moskitt-NewUMLDiagrams]) 

68


5.3.6 Transformationen 

Für die Transformationen von Modellen (4.2.1.2, 4.2.2.2, 4.2.2.3) ist die 

Funktion psu.controllers.DiagramController.Transformation() 

zuständig. 

Auf alle Klassen des zu transformierenden Diagramms wird das jeweilige 

Stereotyp angewendet (dabei werden bereits angewendete Stereotype 

zurückgesetzt): 


Stereotype stereo = this.find_stereo(pack,target_stereotype_name); 

if (stereo == null) { 

msg("Target stereotype not found!"); 

return; 

} 

for ( Element el : pack.allOwnedElements() ) { 

// Nur Klassen werden behandelt 

if (!el.getClass().toString().endsWith("ClassImpl")) continue; 

} 

for ( Stereotype st : el.getAppliedStereotypes()) 

// el.getAppliedStereotypes().clear() wird nicht unterstützt 

el.unapplyStereotype(st); 

try { el.applyStereotype(stereo); } catch (Exception e) {}; 

Anschließend wird das betroffene Diagramm aktualisiert und abgespeichert. 

5.3.7 Anmerkungen 

In diesem Abschnitt sind Anmerkungen aufgeführt, die bei der Arbeit mit 

UWEclipse bzw. bei seiner Weiterentwicklung von Bedeutung sein können. 

5.3.7.1 Aufruf der psu-Ansicht vor der Arbeit mit UWEclipse 

Ein Problem, das im Rahmen der Implementierung nicht gelöst werden konnte, 

ist das Abfangen von Objektselektionen ohne Aktivierung der psu-Ansicht. Das 

Abfangen von Selektionen funktioniert nämlich erst dann, wenn man einmal 

zur psu-Ansicht gewechselt hat. Nach dem einmaligen Wechsel zur psu-Ansicht 

69


(bzw. wenn sie bereits beim Start geöffnet und aktiv war) funktioniert das 

Abfangen von Selektionen, selbst wenn man im Laufe der Arbeit zu einer 

anderen Ansicht wechselt. 

Das bedeutet, dass vor der Arbeit mit UWEclipse grundsätzlich zur 

psu-Ansicht gewechselt werden muss. 

In den Klassen, die für die Ereignisbehandlung von Menüs verantwortlich sind 

(MainHandler und PopupHandler aus psu.handlers), wird es mit der 

Bedingung if (psuView.GetTree() == null) überprüft. Wenn diese 

Bedingung erfüllt ist, ist das Abfangen von Selektionen noch nicht aktiv, und es 

wird eine entsprechende Meldung angezeigt. 

5.3.7.2 Ermitteln des Typs des selektierten Objekts 

Um den Typ eines selektierten Objekts zu ermitteln, kann man die 

Tastenkombination ALT+SHIFT+F1 benutzen (5.3.2.4). Dabei erscheint das 

Fenster des in Eclipse integrierten Tools namens Plug-in Selection Spy 

(Abb. 5.12). In diesem Fenster kann man den Namen der gesuchten Klasse 

sehen (The type of the selected element). 

5.3.7.3 Übergang von einem Diagrammelement zu seiner 

internen Repräsentation 

Eine Lösung, die in der endgültigen Version von UWEclipse nicht gebraucht 

wurde, jedoch potentiell bei künftigen Weiterentwicklungen nützlich sein 

könnte, betrifft den Übergang von einem grafischen Diagrammelement zu 

seiner internen Repräsentation. 

Es wäre z.B. dann wichtig, wenn man anhand des selektierten 

Diagrammelements seinen im Hintergrund stehenden Bestandteil des Modells 

ermitteln möchte: um z.B. darauf Stereotype anzuwenden etc. 

Im nachfolgenden Beispiel (enthalten in auskommentierter Form im 

selectionChanged()-Ereignis des ISelectionListener listener aus der 

Klasse psu.psuView) wird diese Vorgehensweise veranschaulicht: 

ClassEditPart c = (ClassEditPart) 

((IStructuredSelection)CurrentSelection).getFirstElement(); 

String class_name = c.getEditableLabel().toString(); 

UMLEditor editor = (UMLEditor) 

((ModelerGraphicalViewer)c.getViewer()).getModelerEditor(); 

70


Diagram dia = editor.getActiveDiagram(); 


org.eclipse.uml2.uml.Class cls = 

(org.eclipse.uml2.uml.Class)pack.getMember(class_name); 

msg(cls.getName()); 

71


6 Modellierung eines Beispiels mit UWEclipse 

Dieses Kapitel ist eine Einführung in UWEclipse für die Benutzer. Es soll zeigen, 

wie mit Hilfe von UWEclipse modelliert wird. Als Basis dient das Beispiel mit 

dem Adressbuch aus 2.4.3. 

6.1 Vorbereitung 

Man erstellt ein neues TOPCASED-Projekt. Mit Hilfe des UWEclipse-Hauptmenüs 

oder des UWEclipse-Kontextmenüs im Projektbaum legt man ein neues UWE- 

Diagramm an. 

Mit dem Menüeintrag Apply Profile im UWEclipse-Hauptmenü geht das 

Laden und das Anwenden des Profils leichter und schneller, als mit den 

Standardmitteln. 

Über das Kontextmenü des selektierten Diagrammelements (Menüeintrag Show 

Properties → Bereich Stereotype Attributes) gelangt man in den Bereich, 

wo Attributwerte des auf das selektierte Diagrammelement angewendeten 

Stereotyps angezeigt werden und bearbeitet werden können. 

6.2 Transformationen 

Als Beispiel wird das bereits mit TOPCASED modellierte Inhaltsmodell des 

Adressbuches (Abschnitt 2.4.3, Abb. 2.7) benutzt. 

Mit Hilfe des UWEclipse-Hauptmenüs oder des UWEclipse-Kontextmenüs im 

Projektbaum fürht man die Transformation Content → Navigation durch. Das 

Ergebnis ist auf Abb. 6.1 zu sehen. 

72


Abblidung 6.1. Ergebnis der Transformation Content → Navigation 

Als ein weiteres Beispiel wird das Navigationsmodell aus 2.4.3 (Abb. 2.8) 

verwendet. 

Mit Hilfe des UWEclipse-Hauptmenüs oder des UWEclipse-Kontextmenüs im 

Projektbaum fürht man die Transformationen Navigation → Presentation 

und Navigation → Process Structure durch. Das Ergebnis ist auf Abb. 6.2 

und 6.3 zu sehen. 

73


Abblidung 6.2. Ergebnis der Transformation Navigation → Presentation 

74


Abblidung 6.3. Ergebnis der Transformation Navigation → Process 

Structure 

75


7 Zusammenfassung und Ausblick 

Im Rahmen dieser Diplomarbeit wurden UML-CASE-Tools für Eclipse im Hinblick 

auf ihre Erweiterbarkeit für UWE (eine UML-basierte Methodik zur Modellierung 

und Entwicklung von Webanwendungen) analysiert. Das Hauptziel der Analyse 

war die Auswahl eines als Open Source lizenzierten UML-CASE-Tools für die 

UWE-Anpassung. Ein weiterer Bestandteil der Arbeit war die Implementierung 

der UWE-Funktionalität im ausgewählten Tool. 

7.1 Durchgeführte Arbeit 

Die durchgeführte Analyse von UML-CASE-Tools war umfangreich und umfasste 

mehrere Vergleichskriterien (Unterstützung UWE-relevanter UML- 

Diagrammtypen, Unterstützung von UML-Profilen und -Stereotypen, grafische 

Modellierungsmöglichkeiten, enthaltene Entwicklertools, Möglichkeiten der 

Codegenerierung, Qualität der Dokumentation, Lizenz). Die Recherche und die 

Auswahl des Werkzeugs, das als Zielplattform für UWE-Erweiterungen dienen 

sollte, war eine anspruchsvolle Aufgabe und benötigte auch Installation und 

praktische Tests von einigen Kandidatentools. 

Die Analyse ergab, dass das Tool namens TOPCASED UML Editor sich für die 

UWE-Anpassung am besten eignet. TOPCASED ist eine Eclipse-basierte RCP 

(Rich Client Platform), die sich im rasanten Tempo weiterentwickelt. Als diese 

Arbeit in der Anfangsplanung war, lautete die damals aktuelle TOPCASED- 

Version 4.1.0. Danach kamen 5 weitere Releases heraus, so dass zum 

Zeitpunkt des Abschlusses der Arbeit bereits die Version 5.1.0 herunterzuladen 

war. Das alles spricht dafür, dass die Entwicklung dieses UML-CASE-Tools nicht 

stehenbleibt. Eine Community von Entwicklern und Benutzern ist immer bereit, 

einen Drittentwickler zu unterstützen, der sich mit der Entwicklung auf Basis 

von TOPCASED befasst. Somit hat die auf TOPCASED basierende UWE-Lösung 

eine solide Grundlage, auf der man im Zuge der Weiterentwicklung weiterhin 

aufbauen kann. 

Als Nächstes wurden im Rahmen dieser Diplomarbeit Funktionen für die UWE- 

Notation und UWE-basierte Modellierung von Webanwendungen als TOPCASED- 

Erweiterung implementiert. Diese Erweiterung, genannt UWEclipse, ist ein 

Eclipse-Plugin und macht u.a. Gebrauch von TOPCASED-Funktionen. Im Laufe 

der UWEclipse-Entwicklung hat sich die Auswahl von TOPCASED als 

Zielplattform durchaus bestätigt. 

76


In UWEclipse wurden Funktionen implementiert, welche die UWE-basierte 

Modellierung unterstützen bzw. vereinfachen. Dazu gehört das Anlegen von 

UWE-Modellen, Laden und Anwenden des UWE-Profils, Transformationen von 

UWE-Modellen. 

Neben der eigentlichen Implementierung der UWE-Funktionalität wurden die 

von Eclipse und TOPCASED zur Verfügung gestellten Klassen und Funktionen 

für die UML-Modellierung erforscht und somit die Erfahrungen gesammelt, die 

sowohl im UWEclipse-Code als auch in dieser Ausarbeitung zusammengefasst 

wurden. 

7.2 Vergleich zu MagicUWE 

Das urpsrüngliche Ziel der Entwicklung von UWEclipse war die Nachbildung 

bzw. die Migration der MagicUWE-Funktionalität in ein Open Source-Werkzeug 

mit vergleichbaren zu MagicDraw Modellierungsmöglichkeiten. Es sollte u.a. 

den UWE-Entwicklern den Umstieg auf die neue Modellierungsoberfläche 

erleichtern, da die Menüstruktur und die Bedienung von MagicUWE im neuen 

Tool möglichst beibehalten werden sollte. 

Das UWEclipse-Hauptmenü und das UWEclipse-Kontextmenü im Projektbaum 

entsprechen den Menüs von MagicUWE. Zu den in UWEclipse implementierten 

MagicUWE-Funktionen gehören das Anlegen von UWE-Modellen und deren 

Transformationen. 

Das Laden (mit dem anschließenden Anwenden) des UWE-Profils erfolgt nicht 

automatisch, sondern bei Bedarf durch den Benutzer. 

Das Kontextmenü im Diagrammeditor wurde nicht implementiert, da die 

entsprechende Funktionalität (Bearbeiten von Attributwerten zu ausgewählten 

Stereotypen) vom TOPCASED UML Editor bereits zur Verfügung gestellt wurde. 

7.3 Ausblick 

Die implementierte Funktionalität und die gesammelten Erfahrungen bilden 

insgesamt einen guten Ausgangspunkt für künftige Erweiterungen der UWErelevanten 

Funktionalität im TOPCASED UML Editor. 

Bei der UWEclipse-Weiterentwicklung könnten z.B. einige Verbesserungen in 

der Bedienung bzw. Benutzerführung in Betracht gezogen werden. 

Außerdem wären solche Themen interessant wie die Erweiterung der Palette 

des TOPCASED-Diagrammeditors um einen Bereich mit Stereotypen oder Drag 

77


& Drop von Stereotypen von einem Baum in den Diagramm-Bereich zwecks 

Anwendung auf die ausgewählte Klasse. 

Nicht zu vergessen wäre auch die Arbeit mit Nested Classes, die zwar 

momentan von TOPCASED nicht unterstützt werden, in künftigen Versionen 

jedoch aktuell werden können. 

Eine wichtige Weiterentwicklung wäre die Unterstützung von RIA 10 Patterns mit 

dem automatischen Einbinden von Zustandsmaschinen. 

10 RIA – Rich Internet Application – Webanwendung mit reichhaltiger Menge an Funktionen und 

Interaktionsmöglichkeiten 

78


Literaturverzeichnis 

Webreferenzen 

[web-uwe] UWE - UML-based web engineering; http://uwe.pst.ifi.lmu.de/; 

Stand 02.02.2011. 

[web-uwe-argo] UWE – ArgoUWE; 

http://uwe.pst.ifi.lmu.de/toolargoUWE.html; Stand 10.04.2011. 

[web-uwe-magic] UWE – MagicUWE; 

http://uwe.pst.ifi.lmu.de/toolMagicUWE.html; Stand 23.09.2011. 

[web-uwe-magic-brief] MagicUWE – A CASE Tool Plugin for Modeling Web 

Applications; http://uwe.pst.ifi.lmu.de/toolMagicUWE.html (direkt: 

http://uwe.pst.ifi.lmu.de/posters/MagicUWE.pdf); Stand 23.09.2011. 

[web-uwe-magic-ref] UWE - MagicUWE - Reference; 

http://uwe.pst.ifi.lmu.de/toolMagicUWEReferenceV1.3.html; Stand 

25.09.2001. 

[web-uwe-magic-profile] UWE - Metamodel and Profile; 

http://uwe.pst.ifi.lmu.de/publicationsMetamodelAndProfile.html (direkt: 

http://uwe.pst.ifi.lmu.de/download/UWE_Profile_v2.0.zip); Stand 25.09.2011. 

[web-uwe-ex-abwcu] UWE – Examples: Address Book With Content Updates; 

http://uwe.pst.ifi.lmu.de/exampleAddressBookWithContentUpdates.html; 

Stand 11.07.2011. 

[web-argouml] argouml.tigris.org; http://argouml.tigris.org/; Stand 

10.04.2011. 

[web-magicdraw] UML | UML Modeling Tool | UML Designing Tool | Graphical 

Modelling Tool from No Magic; http://www.magicdraw.com/; Stand 

10.04.2011. 

[web-ocl-dd] OCL Portal; http://www-st.inf.tu-dresden.de/ocl/; Stand 

10.04.2011. 

[web-epc-1] Eclipse Plugins, Bundles and Products - Eclipse Marketplace; 

http://marketplace.eclipse.org (Suchergebnis: 

http://marketplace.eclipse.org/search/apachesolr_search/?filters=tid 

79


%3A19&solrsort=sort_title%20asc); Stand 20.12.1010. 

[web-epc-2] EclipsePlugins : hi! Find your plugin for Eclipse here.; 

http://www.eclipse-plugins.info (Suchergebnis: http://www.eclipseplugins.info/eclipse/plugins.jsp?category=UML); 

Stand 20.12.1010. 

[web-topcased] Topcased - Home; http://www.topcased.org/; Stand 

13.02.2011. 

[web-topcased-heise] Airbus: Systementwicklung mit Open Source | heise 

open; http://www.heise.de/open/artikel/82839; Dr. Oliver Diedrich 

(odi@heiseopen.de), 21.12.2006; Stand 13.02.2011. 

[web-topcased-presentation-30-min] Topcased 30 minutes Presentation; 

http://www.topcased.org/ (direkt: 

http://gforge.enseeiht.fr/docman/view.php/52/3629/TOPCASED-presentation- 

30mn.pdf); Stand 11.09.2011. 

[web-topcased-presentation-2-h] Topcased 2 hours Presentation; 

http://www.topcased.org/ (direkt: 

http://gforge.enseeiht.fr/docman/view.php/52/3627/TOPCASED-presentation- 

2h.pdf); Stand 11.09.2011. 

[web-topcased-quick-start] Quick start editor tutorial; 

http://www.topcased.org/index.php?documentsSynthesis=y&Itemid=59 

(direkt: 

http://gforge.enseeiht.fr/docman/view.php/7/4536/TPC_5.0.0_QuickStart_edit 

or_tutorial.pdf); Stand 11.09.2011. 

[web-topcased-download] Downloads for project TOPCASED; 

http://www.topcased.org/index.php?idd_projet_pere=52&Itemid=60; Stand 

13.02.2011. 

[web-topcased-contacts] Topcased – Contacts; 

http://www.topcased.org/index.php/content/view/41/58/; Stand 01.08.2011. 

[web-topcased-mail-users] TOPCASED mailing list for end-users; topcasedusers@lists.gforge.enseeiht.fr 

[web-topcased-mail-devel] TOPCASED mailing list for developers; topcaseddevel@lists.gforge.enseeiht.fr 

[web-eclipse-rcp] Eclipse Rich Client Platform; 

http://www.eclipse.org/home/categories/rcp.php; Stand 13.02.2011. 

[web-eclipse] Eclipse - The Eclipse Foundation open source community 

80


website.; http://www.eclipse.org/; Stand 13.04.2011. 

[web-eclipse-wiki-faq-what] FAQ What is Eclipse? - Eclipsepedia; 

http://wiki.eclipse.org/FAQ_What_is_Eclipse%3F; Stand 13.04.2011. 

[web-eclipse-wiki-gef-faq] GEF/Developer FAQ – Eclipsepedia; 

http://wiki.eclipse.org/GEF/Developer_FAQ; Stand 12.09.2011. 

[web-eclipse-equinox] Equinox; http://www.eclipse.org/equinox/; Stand 

13.04.2011. 

[web-eclipse-gef] GEF; http://www.eclipse.org/gef/; Stand 12.09.2011. 

[web-eclipse-emf] Eclipse Modeling - EMF – Home; 

http://www.eclipse.org/modeling/emf/; Stand 12.09.2011. 

[web-osgi-spec-4] OSGi Alliance | Specifications / HomePage; 

http://www.osgi.org/Specifications/HomePage?section=2#Release4; Stand 

13.04.2011. 

[web-aneeshkumarkb] OSGi - The Dynamic Module System for Java; 

http://aneeshkumarkb.blogspot.com/; Stand 13.04.2011. 

[web-omg] Object Management Group; http://www.omg.org/; Stand 

26.10.2011. 

[web-uml] Object Management Group – UML; http://www.uml.org/; Stand 

30.09.2011. 

[web-duden-stereotyp] Duden | Stereotyp | Bedeutung, Rechtschreibung, 

Grammatik; http://www.duden.de/rechtschreibung/Stereotyp; Stand 

09.10.2011. 

Literaturreferenzen 

[lit-chapter-7-uwe] Nora Koch, Alexander Knapp, Gefei Zhang, Hubert 

Baumeister, UML-based Web Engineering: An Approach based on Standards 

(book chapter). In Web Engineering: Modelling and Implementing Web 

Applications. Gustavo Rossi, Oscar Pastor, Daniel Schwabe and Luis Olsina 

(Eds.), chapter 7, 157-191, © Springer, HCI, 2008. Im Web: 

http://uwe.pst.ifi.lmu.de/publicationsByTopic.html (direkt: 

http://www.pst.ifi.lmu.de/veroeffentlichungen/uwe.pdf). 

[lit-uml-infra] UML Infrastructure Specification, v2.3; OMG Document Number: 

81


formal/2010-05-03; Im Web: http://www.omg.org/spec/UML/2.3/ (direkt: 

http://www.omg.org/spec/UML/2.3/Infrastructure/PDF/). 

[lit-uml-super] UML Superstructure Specification, v2.3; OMG Document 

Number: formal/2010-05-05; Im Web: http://www.omg.org/spec/UML/2.3/ 

(direkt: http://www.omg.org/spec/UML/2.3/Superstructure/PDF/). 

[lit-ocl] Object Constraint Language, v2.3; OMG Document Number: ptc/2010- 

11-42; Im Web: http://www.omg.org/spec/OCL/2.3/Beta2/ (direkt: 

http://www.omg.org/spec/OCL/2.3/Beta2/PDF). 

[lit-uwe-meta] Christian Kroiß, Nora Koch and Sergej Kozuruba; UWE 

Metamodel and Profile: User Guide and Reference. Version 1.9; LMU Technical 

Report 1101, April 2011; Im Web: 

http://uwe.pst.ifi.lmu.de/publicationsMetamodelAndProfile.html (direkt: 

http://uwe.pst.ifi.lmu.de/download/UWE-Metamodel-Reference-v1.9.pdf). 

Sourcecodereferenzen 

[src-topcased-ModelerPaletteManager] TOPCASED-Source, topcased-mf, Klasse 

ModelerPaletteManager; 

http://gforge.enseeiht.fr/scm/viewvc.php/plugins/modeler/org.topcased.model 

er/src/org/topcased/modeler/editor/palette/ModelerPaletteManager.java? 

revision=1.3&root=topcased-mf&view=markup&pathrev=HEAD 

[src-topcased-AbstractCreationUtils] TOPCASED-Source, topcased-mf, Klasse 

AbstractCreationUtils; 

http://gforge.enseeiht.fr/scm/viewvc.php/plugins/modeler/org.topcased. model 

er/src/org/topcased/modeler/editor/AbstractCreationUtils.java? 

diff_format=u&revision=1.9&root=topcased-mf&view=markup 

[src-topcased-DropListenersManager] TOPCASED-Source, topcased-req, Klasse 

DropListenersManager; 

http://gforge.enseeiht.fr/scm/viewvc.php/plugins/org.topcased.requirement.bu 

ndle.topcased/src/org/topcased/requirement/bundle/topcased/services/DropLis 

tenersManager.java?root=topcased-req&view=markup 

[src-topcased-moskitt-UMLDiagramsPage] TOPCASED/MOSKitt-Source, Klasse 

UMLDiagramsPage; http://subversion.moskitt.org/gvcaseadaptations/topcased/trunk/org.topcased.modeler.uml/src/org/topcased/model 

er/uml/wizards/UMLDiagramsPage.java 

[src-topcased-DiagramsPage] TOPCASED-Source, topcased-mf, Klasse 

DiagramsPage; 

82


http://gforge.enseeiht.fr/scm/viewvc.php/plugins/modeler/org.topcased.model 

er/src/org/topcased/modeler/wizards/DiagramsPage.java? 

diff_format=u&revision=1.33&root=topcased-mf&view=markup 

[src-topcased-moskitt-NewUMLDiagrams] TOPCASED/MOSKitt-Source, Klasse 

NewUMLDiagrams; http://subversion.moskitt.org/gvcaseadaptations/topcased/trunk/org.topcased.modeler.uml/src/org/topcased/model 

er/uml/wizards/NewUMLDiagrams.java 

83

thesis - LMU

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?