Softwareentwicklung mit UML und Eclipse · TU Wien Business Informatics Group Institut für Softwaretechnik und Interaktive Systeme Softwareentwicklung mit UML und Eclipse Diplomarbeit

TU Wien

Business Informatics Group

Institut für Softwaretechnik und Interaktive Systeme

Softwareentwicklung mit UML und Eclipse

Diplomarbeit zur Erlangung des akademischen Grades eines

Diplom Ingenieurs (Dipl. Ing.)

eingereicht bei o. Univ.-Prof. Mag. Dipl.-Ing. Dr. Gerti Kappel

Christian Sokop

Wien, Oktober 2008

Eidesstattliche Erklärung

Ich erkläre an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne frem-

de Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die den be-

nutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich

gemacht habe.

<Ort, Datum> <Eigenhändige Unterschrift>

Danksagung

Mein besonderer Dank geht an meine gesamte Familie, insbesondere an meine El-

tern, Eva und Alfred Sokop, die mich zuerst finanziell und in weiterer Folge emotio-

nal unterstützt haben.

Weiters möchte ich mich bei Frau Gerti Kappel für die fachliche Betreuung dieser

Arbeit, und Daniel Stevens für die Hilfestellung bei der englischen Übersetzung be-

danken.

Zum Abschluss möchte ich mich bei all meinen Freunden und Kollegen für die schö-

nen, kurzweiligen, intensiven, feucht-fröhlichen und besten Stunden während meiner

Studienzeit bedanken, und die Hoffnung aussprechen, dass es für immer so lustig

weitergeht!

Abstract

Today not only the world but also the requirements for computer-based applications

change permanently. In addition to these requirements, the development of

technologies and tools also continues. Modern and object-oriented technologies, such

as UML and Java meet today’s high standards.

Distributed systems and web applications respectively represent a wide field in

software development. In relation to UML, an excellent way to develop such systems

is the object-oriented programming language Java, or more precisely the Java

Enterprise Edition. This topic, however, has been thoroughly discussed in [Soko07].

Further tools of today’s projects are integrated development environments. When we

think of Java software development we can find the project „eclipse“ [Ecli08] being

a very popular and freely accessible development environment. The advantage of this

particular development environment is a distinctive plugin management which

allows the project to be easily upgraded.

This thesis evaluates projects and plugins respectively for the development

environment „eclipse“ which support UML 2.0 and therefore assist in the

development.

Furthermore, this thesis assesses whether the tested plugins allow an automated code

generation by exemplifying an application.

Finally, this thesis shall also find cost-efficient alternatives to the development

environments by IBM (IBM Rational Application Developer [IBM08]) and Omondo

(Eclipse Uml [Omon08]).

Kurzfassung

In der heutigen Zeit ändern sich Anforderungen an Anwendungen laufend. Neben

den Anforderungen haben sich natürlich auch die Hilfsmitteln und Technologien

weiterentwickelt. Moderne objektorientierte Sprachen, wie z.B. UML und Java, wer-

den den heutigen Ansprüchen gerecht.

Zu einem großen Teilgebiet der Softwareentwicklung zählen verteilte Systeme bzw.

Web-Anwendungen. Die objektorientierte Programmiersprache Java, oder besser

gesagt die Java Enterprise Edition, in Zusammenhang mit UML eignet sich hervor-

ragend solche Systeme zu entwickeln. Dieses Thema wurde ausführlich in [Soko07]

behandelt.

Als weiteres Hilfsmittel wird heutzutage in jedem Projekt eine Entwicklungsumge-

bung verwendet. Eine sehr verbreitete und frei zugängliche Entwicklungsumgebung

im Bereich der Java Softwareentwicklung ist das Projekt „eclipse“ [Ecli08]. Der

Vorteil dieser Entwicklungsumgebung ist, dass sie durch ein ausgeprägtes Plugin-

management leicht erweiterbar ist.

Diese Arbeit evaluiert Projekte bzw. Plugins für die Entwicklungsumgebung „ec-

lipse“, die UML 2.0 unterstützen und dadurch bei der Entwicklung behilflich sind.

Weiters soll diese Arbeit evaluieren, inwieweit die getesteten Plugins eine automati-

sierte Codegenerierung erlauben. Dies soll anhand einer kleinen Beispielanwendung

demonstriert werden.

Ein weiteres Ziel dieser Arbeit ist es kostengünstige Alternativen zu den Entwick-

lungsumgebungen von IBM (IBM Rational Application Developer [IBM08]) und

Omondo (Eclipse Uml [Omon08]) zu finden.

Inhaltsverzeichnis

Einleitung.................................................................................................................. 10

1.1 Motivation ............................................................................................... 10

1.2 Problemstellung....................................................................................... 11

1.3 Ziel der Arbeit ......................................................................................... 12

Technologien............................................................................................................. 14

2.1 UML 2.0 - Unified Modeling Language ................................................. 14

2.1.1 Grundlagen von UML 2.0 .......................................................... 15

2.1.2 Diagrammübersicht .................................................................... 15

2.2 (Java) Enterprise Anwendungen ............................................................. 19

2.2.1 Designpatterns............................................................................ 19

2.2.2 Java EE - Java Enterprise Edition .............................................. 22

2.3 Die Entwicklungsumgebung Eclipse ...................................................... 24

2.3.1 Geschichte .................................................................................. 24

2.3.2 Arbeitsweise............................................................................... 25

2.3.3 Eclipse Plugins ........................................................................... 26

2.4 Begleitendes Beispiel .............................................................................. 27

Softwareentwicklung mit UML .............................................................................. 28

3.1 Anwendungsfalldiagramm ...................................................................... 28

3.2 Aktivitätsdiagramm................................................................................. 30

3.2.1 Geschäftsprozessmodellierung................................................... 31

3.2.2 Anwendungsfallbeschreibung.................................................... 31

3.2.3 Implementierung einer Operation .............................................. 33

3.3 Zustandsdiagramm .................................................................................. 34

3.4 Sequenzdiagramm ................................................................................... 37

3.4.1 Architekturbeschreibung............................................................ 38

3.4.2 Designpatterns............................................................................ 39

3.4.3 Detailmodellierung..................................................................... 40

3.5 Kommunikationsdiagramm..................................................................... 41

3.6 Zeitdiagramm .......................................................................................... 42

3.7 Interaktionsübersichtsdiagramm ............................................................. 43

3.8 Klassendiagramm.................................................................................... 43

3.8.1 Konzeptuell-analytische Modellierung ...................................... 44

3.8.2 Logische, desgin-orientierte Modellierung ................................ 45

3.9 Paketdiagramm........................................................................................ 47

3.9.1 Funktionale Gliederung.............................................................. 47

3.9.2 Definition von Schichten ........................................................... 49

3.10 Objektdiagramm...................................................................................... 50

3.11 Kompositionsstrukturdiagramm.............................................................. 52

3.11.1 Kompositionsstrukturdiagramm für Klassen ............................. 53

3.11.2 Kompositionsstrukturdiagramm für Kollaborationen ................ 55

3.12 Komponentendiagramm.......................................................................... 56

3.13 Verteilungsdiagramm.............................................................................. 59

UML Erweiterungen für Eclipse ............................................................................ 61

4.1 Einleitung ................................................................................................ 61

4.2 MyEclipse ............................................................................................... 65

4.2.1 Anwendungsfalldiagramm ......................................................... 66

4.2.2 Klassen- und Paketdiagramm..................................................... 68

4.2.3 Sequenz- und Kollaborationsdiagramm..................................... 70

4.2.4 Weitere Diagrammarten ............................................................. 71

4.2.5 Zusammenfassung...................................................................... 74

4.3 UML Editoren ......................................................................................... 74

4.3.1 Blueprint Software Modeler....................................................... 74

4.3.2 Violet UML Editor..................................................................... 78

4.4 Codegeneratoren ..................................................................................... 79

4.4.1 Apollo for Eclipse ...................................................................... 79

4.4.2 GreenUML ................................................................................. 83

4.5 Erweiterte Codegeneratoren.................................................................... 85

4.5.1 eUML2 Modeler ........................................................................ 85

4.5.2 AmaterasUML ........................................................................... 90

4.5.3 SlimeUML ................................................................................. 93

Zusammenfassung und Ausblick............................................................................ 95

5.1 Zusammenfassung................................................................................... 95

5.2 Ausblick .................................................................................................. 96

Literaturverzeichnis................................................................................................. 97

Abbildungsverzeichnis

Abbildung 1: Übersicht der Diagramme in UML 2.0 [Hitz05] ................................. 16

Abbildung 2: Übersicht 4-Tier Architektur (basiert auf [Lang06]) ........................... 20

Abbildung 3: Eclipse Architektur [Schr02] ............................................................... 25

Abbildung 4: Anwendungsfalldiagramm Übersicht .................................................. 30

Abbildung 5: Aktivitätsdiagramm des Anwendungsfall „Bestellung durchführen“.. 32

Abbildung 6: Aktivitätsdiagramm Bubble Sort ......................................................... 34

Abbildung 7: Protokollzustandsdiagramm „Shopping Cart“..................................... 36

Abbildung 8: Anwendungen von Sequenzdiagrammen im Projekt [Rupp05] .......... 37

Abbildung 9: Sequenzdiagramm 4-Schichtenmodell ................................................ 39

Abbildung 10: Sequenzdiagramm DAO-Pattern (basiert auf [Sun08]) ..................... 40

Abbildung 11: Sequenzdiagramm Lebenszyklus Servlet (basiert auf [Ahme02])..... 41

Abbildung 12: Klassendiagramm DAO-Pattern [Sun08] .......................................... 45

Abbildung 13: Klassendiagramm Domainmodell...................................................... 46

Abbildung 14: Paketdiagramm Shopsystem Übersicht ............................................. 48

Abbildung 15: Paketdiagramm Übersicht Enterprise Anwendung............................ 49

Abbildung 16: Objektdiagramm Testdaten Domänenmodellklassendiagramm ........ 52

Abbildung 17: Kompositionsstrukturdiagramm Kontextklasse „Customer“............. 54

Abbildung 18: Kompositionsstrukturdiagramm DAO-Pattern .................................. 55

Abbildung 19: Kompositionsstrukturdiagramm Anwendung DAO-Pattern.............. 56

Abbildung 20: Komponentendiagramm Java Enterprise Anwendung....................... 57

Abbildung 21: Komponentendiagramm Java EE Web-Anwendung ......................... 58

Abbildung 22: Verteilungsdiagramm Java EE Web-Anwendung ............................. 60

Abbildung 23: MyEclipse: Benutzeransicht .............................................................. 66

Abbildung 24: MyEclispe: Anwendungsfalldiagramm ............................................. 67

Abbildung 25: MyEclipse: Klassendiagramm ........................................................... 68

Abbildung 26: MyEclipse: Klassendiagramm Reverse Engineering......................... 70

Abbildung 27: MyEclipse: Sequenzdiagramm .......................................................... 71

Abbildung 28: MyEclipse: Aktivitätsdiagramm ........................................................ 72

Abbildung 29: MyEclipse: Zustandsdiagramm ......................................................... 73

Abbildung 30: MyEclipse: Verteilungsdiagramm ..................................................... 73

Abbildung 31: Blueprint Software Modeler: Arbeitsbereich..................................... 75

Abbildung 32: Blueprint Software Modeler: Anwendungsfalldiagramm.................. 76

Abbildung 33: Blueprint Software Modeler: Klassendiagramm ............................... 77

Abbildung 34: Apollo for eclipse: Arbeitsumgebung................................................ 80

Abbildung 35: Apollo for eclipse: Klassendiagramm................................................ 81

Abbildung 36: Apollo for eclipse: Klassendiagramm................................................ 82

Abbildung 37: GreenUML: Benutzeransicht ............................................................. 83

Abbildung 38: GreenUML: Reverse Engineering ..................................................... 84

Abbildung 39: eUML: Benutzeroberfläche ............................................................... 86

Abbildung 40: eUML: Erstellen einer Assoziation.................................................... 87

Abbildung 41: eUML: Klassendiagramm.................................................................. 88

Abbildung 42: eUML: Sequenzdiagramm................................................................. 89

Abbildung 43: AmaterasUML: Anwendungsfalldiagramm ...................................... 91

Abbildung 44: AmaterasUML: Ansicht Klassendiagramm....................................... 91

Abbildung 45: AmaterasUML: Sequenzdiagramm ................................................... 92

Abbildung 46: SlimeUML: Anwendungsfalldiagramm............................................. 93

Kapitel 1

Einleitung

Im Folgenden werden Motivation, Problemstellung und Ziele der vorliegenden Ar-

beit erläutert.

1.1 Motivation

In der heutigen Zeit ändern sich Anforderungen an Anwendungen laufend. Neben

den Anforderungen haben sich natürlich auch die Hilfsmitteln und Technologien

weiterentwickelt. Moderne objektorientierte Sprachen wie z.B. UML und Java wer-

den den heutigen Ansprüchen gerecht.

Als weiteres Hilfsmittel wird heutzutage in jedem Projekt eine Entwicklungsumge-

bung verwendet. Eine sehr verbreitete und frei zugängliche Entwicklungsumgebung

im Bereich der Java Softwareentwicklung ist das Projekt „eclipse“ [Ecli08].

Zu einem großen Teilgebiet der Softwareentwicklung zählen verteilte Systeme bzw.

Web-Anwendungen. Die objektorientierte Programmiersprache Java, oder besser

gesagt die Java Enterprise Edition, in Zusammenhang mit UML eignet sich hervor-

ragend solche Systeme zu entwickeln. Dieses Thema wurde ausführlich in [Soko07]

behandelt.

Die aktuelle Marktlage zeigt, dass einige Tools angeboten werden, die bei der Mo-

dellierung mit UML helfen sollen. Ein gutes Beispiel ist das Open Source Projekt

StarUML [Star08]. Für die Entwicklung von Java Anwendungen werden Entwick-

Einleitung Seite 11

lungsumgebungen, wie z.B. „eclipse“ angeboten. Die Entwicklungsumgebung „ec-

lipse“ bietet ein Pluginmanagement an und lässt sich dadurch schnell und einfach

erweitern. Mittlerweile gibt es auch eine Reihe von UML Plugins für diese Entwick-

lungsumgebung.

Wie mehrere Jahre praktischer Erfahrung gezeigt haben, werden Java Enterprise

Anwendungen sehr technologiegetrieben entwickelt. In den meisten Fällen beginnen

Programmierer mit der Implementierung zu einem Zeitpunkt im Projekt, zu dem nur

wenige Anforderungen existieren und die existierenden Anforderungen wenig bis gar

nicht analysiert wurden. Im Laufe der Zeit werden mehr und mehr Anforderungen

bekannt, die sofort umgesetzt werden. Dadurch ist, vor allem in großen Projekten,

ein ständiges Neuorganisieren der Teilprojekte notwendig und die Implementierung

wird immer unübersichtlicher. Diese Form der Implementierung ist mit hohem Zeit-

und Ressourcenaufwand verbunden.

Als unterstützendes „Werkzeug“, um dieses Szenario zu vermeiden, dient die objekt-

orientierte Modellierungssprache UML. Sie bietet Diagramme um Softwaresysteme

zu modellieren.

Die Entwicklungsumgebung hat, unter anderem, die Aufgabe diese beiden Techno-

logien zu verbinden. Kommt es in einem großen System zu einer kleinen Änderung

(wie z.B. ein neues Attribut), so muss sowohl der Source Code, wie auch das Dia-

gramm (z.B. Klassendiagramm) angepasst werden. Anzustreben im Sinne der effek-

tiven und modellgetriebenen Entwicklung ist eine Änderung an einer Stelle im Pro-

jekt. Auch in diesem Fall sollte die Entwicklungsumgebung hilfreich sein.

1.2 Problemstellung

Das Hauptproblem bei einer Softwareentwicklung ist die Verwendung von mehreren

Tools. Auf der einen Seite wird eine Entwicklungsumgebung, auf der anderen Seite

werde verschiedene Modellierungswerkzeuge für Dokumentation und Modellierung

der Projekte eingesetzt.

Dadurch kommt es häufig vor, dass diese Tools nicht zusammenspielen und dadurch

der doppelte Aufwand bei der Entwicklung entsteht.

Einleitung Seite 12

1.3 Ziel der Arbeit

Ziel dieser Arbeit ist die Evaluierung von Projekten bzw. Plugins für die Entwick-

lungsumgebung „eclipse“, die UML 2.0 unterstützen und sich in die Entwicklungs-

umgebung integrieren lassen und dadurch bei der Entwicklung behilflich sind.

Weiters soll diese Arbeit evaluieren, inwieweit die getesteten Plugins eine automati-

sierte Codegenerierung erlauben. Dies soll anhand einer kleinen Beispielanwendung

demonstriert werden.

Ein weiteres Ziel dieser Arbeit ist es kostengünstige Alternativen zu den Entwick-

lungsumgebungen von IBM (IBM Rational Application Developer [IBM08]) und

Omondo (Eclipse Uml [Omon08]) zu finden.

Im ersten Teil der Arbeit wird auf die Einsatzmöglichkeiten von UML 2.0 in der

Entwicklung von Java Enterprise Anwendungen eingegangen.

Im zweiten Teil werden folgende Plugins untersucht:

• Apollo for Eclipse [Apol08]: Dieses Plugin unterstützt eine Mischung aus

dem Paket- und Klassendiagramm mit der Möglichkeit Code automatisch

generieren zu lassen.

• AmaterasUML [Amat08]: Dieses Plugin unterstützt das Klassen-, Sequenz-

und Anwendungsfalldiagramm und die Möglichkeit der Codegenerierung

bzw. Reverse Engineering aus dem Klassendiagramm.

• Blueprint Software Modeler [Blue08]: Diese auf „eclispe“ basierende Ent-

wicklungsumgebung bietet mit dem Klassen-, Paket-, Komponenten-, Kom-

positionsstruktur-, Objekt-, Anwendungsfall-, Aktivitäts-, Zustands- und Se-

quenzdiagramm die wichtigsten Diagrammarten an.

• eUML [eUML08]: Dieses Plugin bietet Klassen-, Paket- und Sequenzdia-

gramme und die Möglichkeit der Codegenerierung aus Klassendiagrammen

an.

• green [gree08]: Dieses Plugin bietet nur das Klassendiagramm und eine auto-

matisierte Codegenerierung bzw. Reverse Engineering an.

• MyEclipse [Myec08]: Die auf „eclipse“ basierende Entwicklungsumgebung

Einleitung Seite 13

„MyEclipse“ bietet neben der Unterstützung von UML eine Vielzahl von

weiteren Plugins an, die für die Entwicklung von Enterprise Anwendung ei-

ne große Hilfe darstellen. Das integrierte UML Plugin unterstützt das An-

wendungsfall-, Klassen-, Sequenz-, Kollaborations-, Zustands-, Aktivitäts-

und Verteilungsdiagramm.

• Slime UML [slim08]: Dieses Plugin bietet eine volle Unterstützung von Klas-

sen-, Paket- und Anwendungsfalldiagrammen an. Außerdem soll auch mit

diesem Plugin eine automatische Anpassung der Diagramme bei Änderung

des Codes erfolgen.

• Violet UML Editor [Viol08]: Dieses Plugin bietet das Anwendungsfall-, Klas-

sen-, Aktivitäts-, Sequenz-, Zustands- und Objektdiagramm an. Die Codege-

nerierung wird bei diesem Plugin nicht unterstützt.

Die Arbeit verfolgt zwei Ziele. Einerseits soll ein Überblick über die Einsatzmög-

lichkeiten von UML 2.0 in Java Enterprise Anwendungen gegeben werden. Anderer-

seits sollen die oben genannten Plugins vorgestellt werden. Dazu werden die Dia-

gramme aus dem ersten Teil mit Hilfe der Plugins anhand einer Beispielanwendung

umgesetzt.

Kapitel 2

Technologien

Das folgende Kapitel soll eine Einleitung über die behandelten Technologien geben.

Einige Teile dieses Kapitels basieren auf [Soko07].

2.1 UML 2.0 - Unified Modeling Language

Als kurze Definition von der Unified Modeling Language gibt [Rupp05] eine „ver-

breitete Notation, um Softwaresysteme zu analysieren und zu entwerfen“ an. Die in

dieser Arbeit verwendete Version 2.0 wurde von der Object Management Group

OMG im April 2005 offiziell verabschiedet [Rupp05]. Die aktuellste Version (Stand

Juni 2008) von UML ist 2.1.2 und wurde im November 2007 veröffentlicht

[OMG07]. Die Object Management Group ist ein internationales Konsortium, wel-

ches sich um die Entwicklung von Standards kümmert. Neben der objektorientierten

Modellierungssprache UML wurde unter anderem der verbreitete Standard CORBA1

von OMG entwickelt [OMG08].

Neben einigen Änderungen und Erweiterungen, werden in UML 2.0 im Vergleich

zur Version 1, auch einige neue Diagramme beschrieben.

1 Common Object Request Broker Architecture (plattformunabhängige Architektur für verteilte An-

wendungen [OMG08a])

Technologien Seite 15

2.1.1 Grundlagen von UML 2.0

UML gilt als Modellierungssprache und kann über den gesamten Softwareentwick-

lungsprozess hinweg verwendet werden. Dadurch ist UML unabhängig von Vorge-

hensmodellen für die Softwareentwicklung und hat auch nicht das Ziel ein eigenes,

neues Vorgehensmodell zu definieren. Weiters soll UML unabhängig von Entwick-

lungswerkzeugen und Programmiersprachen, sowie mit verschiedensten Anwen-

dungsbereichen kompatibel sein [Hitz05]. Diese Punkte spiegeln auch die Vorteile

von UML wider. Die Einsatzmöglichkeiten reichen von der Analysephase bis hin zur

Implementierungsbeschreibungen einer Softwareentwicklung. UML kann sowohl bei

Echtzeitsystemen wie auch für verteilte Systeme angewendet werden.

Praktische Modellierung mit StarUML

Die in Kapitel 3 gezeigten Diagramme wurden, soweit wie möglich, mit dem frei

verfügbaren Tool StarUML [Star08] modelliert. Dieses Produkt wurde gewählt, da es

eine Vielzahl der zu modellierenden Diagramme unterstützt und im Gegensatz zu

vielen anderen Modellierungstools frei verfügbar ist [Reic06].

In weiterer Folge wurde versucht die in StarUML modellierten Diagramme mit Hilfe

der Entwicklungsumgebung „eclipse“ [Ecli08] zu modellieren.

2.1.2 Diagrammübersicht

Das folgende Kapitel soll einen kurzen Überblick über die 13 Diagrammarten von

UML 2.0 geben. Prinzipiell kann in UML zwischen Verhaltens- und Strukturdia-

grammen unterschieden werden. Mit Verhaltensdiagrammen wird, wie der Name

schon sagt, das Verhalten eines Systems modelliert. Mit Verhaltensdiagrammen wer-

den die dynamischen Aspekte eines Systems beschrieben. Mit Hilfe von Strukturdia-

grammen werden die statischen und strukturellen Aspekte eines Systems modelliert

[Hitz05].

Zu den Strukturdiagrammen zählen in UML 2.0 Klassen-, Objekt-, Paket-, Komposi-

tionsstruktur-, Komponenten- und Verteilungsdiagramme. Bei Verhaltensdiagram-

men wird zwischen Anwendungsfall-, Aktivitäts-, Zustands- und Interaktionsdia-

grammen unterschieden. Interaktionsdiagramme werden noch in Sequenz-, Kommu-

nikations-, Zeit- und Interaktionsübersichtsdiagramme eingeteilt.


Die Grenze zwischen den Diagrammen ist fließend. So ist es z.B. möglich Teile ei-

nes Klassendiagramms in einem Paketdiagramm oder umgekehrt zu modellieren

[Hitz05].

Abbildung 1 zeigt eine Übersicht über die Diagrammarten in UML 2.0.

Abbildung 1: Übersicht der Diagramme in UML 2.0 [Hitz05]

Verhaltensdiagramme in UML 2.0

UML 2.0 beschreibt folgende Verhaltensdiagramme:

• Anwendungsfalldiagramm: Das Anwendungsfalldiagramm beschreibt die

Anwendung in einer hohen Abstraktionsebene. Mit Hilfe dieses Diagramms

wird der Zusammenhang zwischen Aktoren und Anwendungsfällen be-

schrieben. Ein Anwendungsfall ist eine „abgeschlossene, zusammenhängen-

de Einheit, welche einen Teil der Funktionalität des Systems repräsentiert“

[Zuse01].

• Aktivitätsdiagramm: Das Aktivitätsdiagramm dient für die Modellierung von

Prozessen und Software [Hitz05]. Diese Diagrammart wurde zum Vergleich

zu älteren UML Definitionen enorm verändert und erweitert. Es beschreibt

die gesamten (Teil-)Abläufe in einem System mit Hilfe der zeitlichen Abfol-

ge von Aktivitäten, die im System passieren.


• Zustandsdiagramm: Beim Zustandsdiagramm werden Zustände und Über-

gänge von Zuständen im System modelliert. Eine Änderung des Zustands

kann vom System oder von einem Aktor außerhalb des Systems bestimmt

werden [Rupp05].

• Interaktionsdiagramm: Das Interaktionsdiagramm ist kein eigenes Diagramm,

sondern der Überbegriff für vier weitere Diagramme.

Folgende Interaktionsdiagramme, als Teil der Verhaltensdiagramme werden in UML

2.0 unterschieden:

• Sequenzdiagramm: Mit Sequenzdiagrammen werden Interaktionen zwischen

Objekten modelliert. Dabei steht die zeitliche Abfolge der Nachrichten im

Vordergrund [Hitz05]. Mit dem Sequenzdiagramm soll die Frage „Wie läuft

die Kommunikation in meinen System ab?“ [Rupp05] beantwortet werden.

Das Sequenzdiagramm ist das meistverwendete unter den Interaktionsdia-

grammen [Rupp05].

• Kommunikationsdiagramm: Das Kommunikationsdiagramm beschreibt, wie

auch das Sequenzdiagramm, Interaktionen zwischen Objekten. Bei dieser

Diagrammart stehen allerdings die strukturellen Beziehungen der Objekte

zueinander im Vordergrund [Hitz05].

• Zeitdiagramm: Das Zeitdiagramm dient zum Modellieren von Änderungen

der Zustände von Objekten. Besonders geeignet ist diese Diagrammart für

die Modellierung von Systemen mit zeitkritischem Verhalten (Echtzeitsys-

teme) [Hitz05].

• Interaktionsübersichtsdiagramm: Das Interaktionsübersichtsdiagramm ist ei-

ne Variante des Aktivitätsdiagramms. Es soll den Zusammenhang zwischen

Interaktionen zeigen. Das Interaktionsübersichtsdiagramm soll die Frage „In

welcher Reihenfolge und unter welchen Bedingungen finden Interaktionen

statt?“ [Rupp05] beantworten.


Strukturdiagramme in UML 2.0

Folgende Diagrammarten werden in UML 2.0 der Strukturmodellierung zugeordnet:

• Klassendiagramm: Das Klassendiagramm beschreibt die strukturellen As-

pekte des zu entwickelten Systems in Form von Klassen und Schnittstellen

(Interfaces). Außerdem werden Beziehungen zwischen Klassen und Inter-

faces modelliert [Hitz05]. Ein Klassendiagramm kann stark durch seine Abs-

traktionsebene unterschieden werden. So ist es möglich einen groben Über-

blick über das Gesamtsystem zu geben. Ein Klassendiagramm kann aber

auch eine detaillierte Darstellung der Klassen im System geben und dadurch

als Implementierungsgrundlage dienen. Dieser Aspekt spielt vor allem bei

der Codegenerierung eine große Rolle. Das Klassendiagramm soll die Frage

„Wie sind die Daten und das Verhalten meines Systems im Detail struktu-

riert?“ [Rupp05] beantworten.

• Paketdiagramm: Das Paketdiagramm dient zur strukturellen Darstellung des

Systems. Auch bei diesem Diagramm können verschiedene Abstraktionsebe-

nen unterschieden werden. Mit Hilfe dieses Diagramms soll die Komplexität

des Systems reduziert werden, indem es in mehrere Pakete aufgeteilt wird

[Hitz05].

• Objektdiagramm: Das Objektdiagramm ist dem Klassendiagramm sehr ähn-

lich und unterscheidet sich dadurch, dass mit Hilfe dieses Diagramms nicht

die Klassen, sondern Objekte (Instanzen von Klassen) modelliert werden.

Das Objektdiagramm bietet einen Ausschnitt eines prototypischen bzw. ex-

emplarischen Systems [Hitz05].

• Kompositionsstrukturdiagramm: Das Kompositionsstrukturdiagramm wurde

in der UML Version 2.0 neu eingeführt. Es bietet die Möglichkeit die interne

Struktur einer Klasse und Beziehungen einer Klasse zu anderen Teilen des

Systems darzustellen [Rupp05].

• Komponentendiagramm: Das Komponentendiagramm bietet die Möglichkeit

Komponenten und deren Zusammenhänge zu definieren. Eine Komponente

kann dabei sowohl eine Klasse, aber auch eine systemspezifische Konfigura-

tionsdatei sein. Es soll die Frage „Wie ist mein System strukturiert und wie


werden diese Strukturen erzeugt?“ [Rupp05] beantworten.

• Verteilungsdiagramm: Mit dem Verteilungsdiagramm kann die eingesetzte

Hardwaretopologie und das zugeordnete Laufzeitsystem, sowie eine Vertei-

lung der Komponenten modelliert werden [Hitz05].

2.2 (Java) Enterprise Anwendungen

Das folgende Kapitel soll einen Überblick über Enterprise Anwendungen geben. Als

Definition von Java Enterprise Anwendungen, kann man sagen, dass es sich um An-

wendungen handelt, die mit der Java Enterprise Edition (Java EE) implementiert

sind. Java EE könnte man in einem Satz als das „am weitesten verbreitete ‚Betriebs-

system’ für Webanwendungen“ [Star05] beschreiben.

Ein wichtiger Punkt in Enterprise Anwendungen ist es, sich an gewisse Vorgaben (so

genannte Designpatterns) zu halten. Die wichtigsten werden in Kapitel 2.2.1 erklärt.

2.2.1 Designpatterns

Ein Pattern (Entwurfsmuster) ist die „best practice“ zum Lösen eines bestimmten,

wiederkehrenden Problems. Das heißt ein Pattern beschreibt ein wiederkehrendes

Problem und stellt eine Möglichkeit für eine Lösung dar [Mari02].

Bekannt in diesem Bereich wurde die so genannte „Gang of Four“ (GoF), die in ih-

rem Buch [Gamm95] 23 verschiedene Patterns vorstellt. Eines der bekanntesten

Entwurfspatterns ist das so genannte Model-View-Controller (MVC) Pattern, wel-

ches eine Trennung zwischen Domainobjekten (Model), der Anzeige (View) und der

Businesslogik (Controller) vorsieht.

Weitere Designpattern, vor allem Pattern in der Softwarearchitektur, werden in

[Busc96] beschrieben.

Grundlegende Architektur einer Enterprise Anwendung

Die grundsätzliche Architektur einer Enterprise Anwendung ist die so genannte 4-

Tier-Architecture (4-Schichten-Architektur). Laut [Lang06] gilt die 4-Schichten-

Architektur seit dem Internet Boom Mitte der 90er Jahre als „State-of-the-art-


Architektur“ für webbasierte Anwendungen.

Abbildung 2 zeigt eine graphische Darstellung der 4-Tier-Architektur:

Abbildung 2: Übersicht 4-Tier Architektur (basiert auf [Lang06])

Die vier Schichten (Ebenen) werden wie folgt eingeteilt [Lang06]:

• Visualisierungsebene (Web-Client): Diese Ebene nimmt Eingaben des Be-

nutzers entgegen und gibt diese an die nächste Schicht weiter. Nach der Ver-

arbeitung werden Daten von der nächsten Schicht entgegen genommen und

für den Benutzer gerecht dargestellt.

• Präsentationsebene (Web-Server): Diese Ebene verarbeitet und prüft die

vom Benutzer eingegebenen Daten und schickt diese an die dritte Schicht

weiter. In die andere Richtung werden die Daten von der nächsten Ebene

empfangen und für die Visualisierungsebene vorbereitet.

• Geschäftslogik (Anwendungsserver): Die Geschäftslogik stellt das Herzstück

der Enterprise Anwendung dar. In dieser Ebene werden die Daten verarbeitet

und alle Prozesse, die die eigentliche Anwendung betreffen, implementiert.

Zu speichernde Daten werden an die nächste Schicht weitergegeben. Benö-

tigte Daten von der vierten Ebene gelesen.

• Datenbankebene (Datenbankserver): In dieser Ebene werden die Daten, die

in der Geschäftlogik entstehen, gespeichert, bzw. Daten, die von der Ge-


schäftslogik benötigt werden, geholt.

Der Vorteil bei einer mehrstufigen Schichten Architektur liegt vor allen an der Ska-

lierbarkeit und der einfachen Wartung der Anwendungen. So kann jede Schicht für

sich auf einen eigenen physischen Rechner laufen und einzeln gewartet werden

[Schä02].

Auch im Zusammenhang mit dem Entwicklungsprozess stellen mehrschichtige Ar-

chitekturen einen Vorteil dar. Entwickler können relativ unabhängig von anderen

Schichten ihren Teil implementieren.

Weitere Designpattern einer Enterprise Anwendung

Eine Liste von häufig verwendeten Patterns in Java Enterprise Anwendungen wird

von der Firma Sun Microsystems zur Verfügung gestellt [Sun08]. Auf dieser Inter-

netseite befinden sich auch ausführliche Erklärungen der verschiedenen Patterns.

Im Rahmen der vorliegenden Arbeit soll, mit dem DAO-Pattern („Data Access Ob-

ject“ - Datenzugriffsobjekt), ein weiteres Grundkonzept einer Enterprise Anwendung

beschrieben werden. Dieses Pattern wird in weiterer Folge in Form von UML Dia-

grammen ausführlicher beschrieben.

Das DAO-Pattern kapselt den Datenzugriff vom aufrufenden Objekt. Dazu wird ein

Interface verwendet, welches die Zugriffs- bzw. Schreibemethoden für den Datenbe-

stand beinhaltet. Die Implementierung dieses Interfaces kann auf verschiedene Arten

erfolgen. Der Zugriff auf die Daten kann z.B. mittels Datenbankabfragen implemen-

tiert werden. Wird in einer späteren Phase im Projekt entschieden, als Datenquelle

XML zu verwenden, so muss nur die Implementierung des Zugriffobjektes und die

Konfiguration ausgetauscht werden. Die, meist komplexe, Business Logik bleibt

hingegen unverändert. In der Praxis wird häufig ein Austausch der Implementierung

für das Testen der Businessmethoden vorgenommen, wenn gewisse Objekte nicht in

die Datenbank gespeichert werden sollen, sondern z.B. am Bildschirm ausgegeben

oder in ein Testprotokoll geschrieben werden sollen.


2.2.2 Java EE - Java Enterprise Edition

Bei der Suche nach einer einfachen und kurzen Definition von der Java Enterprise

Edition (Java EE) wird man in der freien Internet-Enzyklopädie Wikipedia fündig:

Java Plattform, Enterprise Edition, abgekürzt Java EE oder früher J2EE, ist die Spe-

zifikation einer Softwarearchitektur für die transaktionsbasierte Ausführung von in

Java programmierten Anwendungen.

Es handelt sich also um eine Spezifikation einer Softwarearchitektur. Die offizielle

und standardisierte Architekturbeschreibung der Java Enterprise Edition [Jend06],

welche von der Firma Sun Microsystems verfasst wurde, besteht aus etwa 1.300 Sei-

ten.

Einen kurzen Einblick über Java EE Architektur soll die Einteilung der Kapitel zei-

gen [Jend06]:

• Web-tier Technologien: Dieser Teilbereich der Java Enterprise Edition um-

fasst Standards wie z.B. Java Servlets, Java Server Pages oder Java Server

Faces.

• Web Service Technologien: In diesem Teil werden alle Modelle beschrieben,

die sich mit Web Services befassen.

• Enterprise Java Beans (EJB): Dieser Teil beschreibt, wie man die Business

Logik einer Java Enterprise Anwendung entwickelt und umfasst Basistech-

nologien, wie Session beans und Message-driven beans.

• Persistenz Technologien: Diese Kapiteln beschäftigen sich mit dem Daten-

bankzugriff von einer Java Enterprise Anwendung.

• Plattform Services: Das letzte Kapitel beschäftigt sich mit Themen, die von

vielen anderen Komponenten verwendet werden. Hier werden unter anderem

die grundlegenden Technologien wie das Transaktionshandling oder die Si-

cherheit einer Java Enterprise Anwendung beschrieben.


Zur Ausführung einer Java Enterprise Anwendung, welche Enterprise Java Beans

verwendet, wird ein so genannter Anwendungsserver benötigt. Die gängigsten sind

das Open Source Projekt JBoss2, sowie die kommerziell vertriebenen Anwendungs-

server von Bea (Bea Weblogic3) und IBM (IBM Websphere4). Es existieren aller-

dings auch weitere Produkte am Markt.

Motivation und Ziele

Java Enterprise Anwendungen stellen eine Vereinfachung für die Entwicklung von

Client-Server Anwendungen dar. Folgende Ziele werden dabei verfolgt [Schä02]:

• Wiederverwendbarkeit: Die Implementierung von fachlichen Komponenten

ist unabhängig von technischen Konzepten (Business Objekte).

• Standardisierte Schnittstellen: Durch standardisierte Schnittstellen soll die

Unabhängigkeit zu anderen Systemen ermöglicht werden. Dadurch wird die

Enterprise Anwendung herstellerunabhängig.

• Trennung zwischen fachlichen und technischen Aspekten: Jeder Entwickler

hat eine spezielle Aufgabe im Projekt und ist durch standardisierte Schnitt-

stellen unabhängig(er) von anderen Entwicklern.

Vor- und Nachteile

Der größte Vorteil an der Java Enterprise Edition bzw. an Java allgemein ist die

Plattformunabhängigkeit und die laufende Weiterentwicklung und Anpassung der

Programmiersprache.

In der heutigen Zeit haben modern entwickelte webbasierten Systeme hohe Anforde-

rungen, wie Skalierbarkeit und Wartbarkeit. Dadurch bietet sich eine mehrstufige

2 http://www.jboss.org

3 http://www.bea.com

4 http://www.ibm.com/websphere


Systemarchitektur an, um Benutzersicht, Geschäftslogik und Datenbank zu trennen

[Schä02]. Mit Hilfe der Java Enterprise Edition wird genau diese Trennung innerhalb

einer Anwendung ermöglicht.

Einer der größten Nachteile von Java Enterprise Anwendungen ist, dass es zwar ei-

nen Standard gibt, in der Praxis dieser Standard allerdings (leider) von jedem An-

wendungsserver im Detail etwas anders implementiert wird [Schä02].

Ein weiterer Nachteil ist die Performanz einer Java Enterprise Anwendung. In vielen

Fällen erfolgt bei jedem Aufruf ein Zugriff auf eine entfernte („remote“) Komponen-

te. Dadurch müssen alle Objekte die verschickt werden zuerst serialisiert werden und

danach beim Empfänger wieder zu einem vollständigen Objekt zusammengebaut

werden. Dieser Vorgang benötigt einiges an Zeit und Rechenleistung [Schä02].

2.3 Die Entwicklungsumgebung Eclipse

Das folgende Kapitel soll einen kurzen Überblick über die Entwicklungsumgebung

(IDE5) eclipse geben.

„Eclipse ist eine Entwicklungsumgebung für ‚alles und nichts’ - das bedeutet, dass

sie verwendet werden kann, um Software in einer beliebigen Programmiersprache zu

entwickeln“ [Burn06].

Wie dieser einleitende Satz zeigen soll, ist Eclipse eine beliebte, state-of-the-art Ent-

wicklungsumgebung mit einem breiten Einsetzgebiet.

2.3.1 Geschichte

Die IDE eclipse ist der Nachfolger von IBM Visual Age for Java 4.0 und wurde von

IBM im November 2001 als Open Source Projekt freigegeben. Seitdem wurde die

Entwicklungsumgebung über 50 Millionen Mal heruntergeladen [Burn06] und ihre

beliebtheit steigt von Tag zu Tag. Mittlerweile wird die Weiterentwicklung der Ent-

wicklungsplattform von einer unabhängigen Organisation geführt, der „Eclipse

Foundation“.

5 IDE = engl. Integrated development environment


2.3.2 Arbeitsweise

Seit der Version 3.0 sind Erweiterungen (so genannten Plugins) die Basis von „ec-

lipse“. Das heißt, wenn das Standardpaket („eclipse standard development kit“) von

der Webseite [Ecli08] heruntergeladen wird, hat man nur den Kern der Entwick-

lungsumgebung mit den beiden vorinstallierten Plugins „Java Development Tooling“

(JDT) und „Plugin Developer Environment“ (PDE) [Tilm05]. Das Plugin „Java De-

velopment Tooling“ macht Eclipse zur Java Entwicklungsumgebung, die „Plugin

Developer Environment“ erlaubt dem Benutzer weitere Plugins zu implementieren

und installieren.

Abbildung 3 zeigt die vier Hauptteile der Entwicklungsumgebung „eclipse“:

Abbildung 3: Eclipse Architektur [Schr02]

Die angedockten „New Tools“ in Abbildung 3 entsprechen den Plugins. Aufbauend

auf die „Platform Runtime“ werden folgende Bestandteile unterschieden [Schr02]:

• Workbench: Unter dem Workbench wird das graphische Interface verstan-

den. Das graphische Interface wird mit Hilfe von SWT (Standard Widgeting

Toolkit) und JFace umgesetzt [Schr02].

• Workspace: Der Workspace ist die Verknüpfung der Entwicklungsumgebung

mit dem Dateisystem. Der Benutzer wählt beim Starten der Umgebung einen

Pfad aus, in dem sich alle seine Dateien befinden.

• Help: Dieser Teil beinhaltet eine leicht (mit Hilfe von XML-Dateien) erwei-

terbare Hilfefunktion für Plugins.


• Version and Configuration Management (VCM): Die Entwicklungsumge-

bung „eclipse“ stellt standardmäßig ein Versionierungssystem zur Verfü-

gung. Dieses erlaubt dem Benutzer ein Einfaches einbinden von neuen Plug-

ins und ein updaten von vorhandenen Plugins.

2.3.3 Eclipse Plugins

Die gesamte Entwicklungsumgebung besteht aus Plugins. Alle Plugins werden in

Java programmiert und bleiben damit plattformunabhängig. Beim Starten der Ent-

wicklungsumgebung „eclipse“ wird in einem bestimmten Verzeichnis nach neuen

Plugins gesucht, die geladen werden sollen [Schr02].

Grundsätzlich besteht jedes Plugin aus folgenden Dateien [Schr02]:

• Manifest-Datei: Die Manifest Datei beinhaltet neben der Beschreibung des

Plugins auch weitere Informationen, wie zum Beispiel die Art und Weise,

wie das Plugin in die Entwicklungsumgebung „eclipse“ integriert werden

soll.

• Jar-Archiv: Dieses Java Archiv beinhaltet die ausführbaren Klassen, also die

Implementierung des Plugins.

• Weitere Ressourcen: In diesem Ordner des Plugins werden weitere Ressour-

cen wie Bilddateien oder Sprachdateien verwaltet.

• Quellcode: Wenn das Plugin Open Source sein soll, beinhaltet dieser Bereich

den Quellcode.

Mittlerweile wird für beinahe jede Problemstellung ein geeignetes Plugin bereitge-

stellt. Alle offiziellen Eclipse Plugins sind auf einer Internetseite [Ecli08a] aufgelis-

tet. Mit Stand Ende Mai 2008 werden 1068 verschiedene Plugins zu den verschie-

densten Themengebieten angeboten.


2.4 Begleitendes Beispiel

Als begeleitendes Beispiel wurde ein kleines Shopsystem implementiert. Dieses Sys-

tem wurde mit Hilfe von EJB 3.0 entwickelt. Als Datenbank dient eine MySql6 Da-

tenbank und als Anwendungsserver JBoss.

Dieses Shopsystem soll möglichst einfach aufgebaut sein. Als Präsentationsschicht

wird eine einfache Weboberfläche verwendet. Es wurde darauf geachtet die oben

beschriebene Schicht-Architektur zu verwenden.

Folgende zwei Anwendungsfälle wurden implementiert:

• Produkte verwalten: Ein Administrator hat die Möglichkeit Produkte anzule-

gen, zu löschen und zu ändern. Ein Produkt wird einer Produktgruppe zuge-

ordnet.

• Bestellung durchführen: Der Kunde, der als eindeutige Identifikation eine

Emailadresse angibt, hat die Möglichkeit eine Bestellung durchzuführen.

Dabei kann er beliebig viele Produkte in den Warenkorb legen und in weite-

rer Folge bestellen. Wurde die Bestellung durchgeführt wird ein Datensatz in

die Datenbank geschrieben.

Für die Entwicklung selbst wurde „MyEclipse“ verwendet. Es wurde außerdem auf

die Verwendung von weiteren Frameworks verzichtet.

6 http://www.mysql.de

Kapitel 3

Softwareentwicklung mit UML

Im folgenden Kapitel wird das Zusammenspiel zwischen UML 2.0 und Java Enter-

prise Anwendungen beschrieben. Dabei wird jedes Diagramm einzeln evaluiert und

auf seine Einsetzbarkeit geprüft. Einige Teile dieses Kapitels basieren auf [Soko07].

Die Unterkapiteln 3.1 bis 3.7 beziehen sich auf die Verhaltensmodellierung. Bei der

Verhaltensmodellierung stehen die dynamischen Aspekte des Systems im Vorder-

grund [Hitz05]. Verhaltensmodelle können in jeder Phase des Projektes zum Einsatz

kommen. Zur Verhaltensmodellierung zählen Anwendungsfall-, Aktivitäts-, Zu-

stands-, Sequenz-, Kommunikations-, Zeit- und Interaktionsübersichtsdiagramme.

Die Unterkaptitel 3.8 bis 3.13 beziehen sich auf die strukturelle Modellierung. Struk-

turdiagramme beschreiben - wie der Name schon sagt - die Struktur eines Systems.

Strukturdiagramme bieten eine Vielzahl von Möglichkeiten, die von der Auf-

baustruktur einer Klasse bis hin zur Gliederung vollständiger Architekturen und Sys-

teme reichen [Rupp05]. Zu den Strukturdiagrammen zählen das Klassen-, Paket-,

Objekt-, Kompositionsstruktur-, Komponenten- und Verteilungsdiagramm.

3.1 Anwendungsfalldiagramm

Das Anwendungsfalldiagramm abstrahiert das zu entwickelte System und stellt es in

Form vom Anwendungsfällen aus Sicht des Benutzers dar [Hitz05]. Mit einem An-

wendungsfalldiagramm soll die Frage „Was soll mein geplantes System eigentlich

leisten“ [Rupp05] beantwortet werden. In älteren Versionen von UML wurde das

Anwendungsfalldiagramm als Strukturdiagramm geführt und nicht als Verhaltens-

Softwareentwicklung mit UML Seite 29

diagramm.

In einem Anwendungsfalldiagramm werden prinzipiell zwischen Aktoren und An-

wendungsfällen unterschieden. Aktoren interagieren mit dem System, sind aber klar

außerhalb des Systems angesiedelt [Hitz05]. Dabei kann es sich um Benutzer, aber

auch um andere Systeme handeln. Ein Anwendungsfall ist eine abgeschlossene, zu-

sammenhängende Einheit, welche einen Teil der Funktionalität des Systems reprä-

sentiert [Zuse01].

Ein Anwendungsfalldiagramm ist ein guter Einstieg, um einen Überblick über das

gesamte System zu geben und wird deshalb sehr früh, wenn nicht sogar als erstes, in

einem Projekt modelliert. Das Anwendungsfalldiagramm wird in der Praxis öfters in

Absprache mit dem Kunden erstellt. Beim Anwendungsfalldiagramm soll die Benut-

zer spezifische Ebene modelliert werden und ist deshalb eine sehr abstrakte, wenig

detaillierte Sicht auf eine Enterprise Anwendung.

Ein Anwendungsfalldiagramm wird meist in mehreren Iterationen entworfen. Das

erste Diagramm gibt eine grobe Übersicht über das Gesamtsystem und enthält nur

jene Anwendungsfälle, die der Grundfunktionalität des Systems entsprechen. In ei-

nem weiteren Schritt können diese Anwendungsfälle verfeinert werden.

In vielen Fällen und auch von der Literatur empfohlen ([Zuse01], [Hitz05], …), ist es

sinnvoll eine Anwendungsfallbeschreibung durchzuführen. Diese Beschreibung soll

eine detaillierte Übersicht über den Anwendungsfall geben und enthält unter ande-

rem eine Kurzbeschreibung, Vorbedingungen, Beschreibung des Ablaufs und Aus-

wirkungen [Zuse01]. In UML wird keine Anwendungsfallbeschreibung vorgeschrie-

ben. Anwendungsfälle können in UML 2.0 mit Hilfe der anderen Diagrammarten

beschreiben werden, wie es die folgenden Kapiteln zeigen werden.

Wie schon beschrieben stellt ein Anwendungsfalldiagramm eine graphische Über-

sicht über das System und seine Aktoren dar. Im begleitenden Beispiel sind Kunden

und Administratoren die Aktoren der Enterprise Anwendung.

Das Suchen von Anwendungsfällen geht meistens ein genaues studieren einer tex-

tuellen Beschreibung voraus. Verben in den Sätzen sind dabei mögliche Tätigkeiten

und Ansätze für einen Anwendungsfall [Zuse01]. Im begleitenden Beispiel sind die


ersten Anwendungsfälle „Produkte verwalten“ und „Produkte bestellen“.

Abbildung 4 zeigt ein Anwendungsfalldiagramm auf einer sehr abstrakten Ebene. Es

wird nur die Grundfunktionalität des Systems beschrieben. Dieses Anwendungsfall-

diagramm wird zu einem späteren Zeitpunkt in dieser Arbeit verfeinert dargestellt

(siehe Kapitel 4.2.1).

System

Administrator

Customer

Manage products

Order products

Abbildung 4: Anwendungsfalldiagramm Übersicht

Seit UML 2.0 können Anwendungsfälle in Pakete gegliedert werden [Rupp05]. Für

die Modellierung bedeutet das, dass schon auf dieser sehr abstrakten Ebene eine Ein-

teilung in Pakete erfolgen kann. In Bezug auf eine Enterprise Anwendung könnten

die Pakete, die zu implementierenden Services sein. Im begleiteten Beispiel könnte

das Anwendungsfalldiagramm z.B. in ein Administration Service und ein Shop Ser-

vice eingeteilt werden.

3.2 Aktivitätsdiagramm

Aktivitätsdiagramme sind mit der Version 2.0 von UML komplett überarbeitet wor-

den. Sie spezifizieren den Kontroll- und Datenfluss zwischen verschiedenen Arbeits-

schritten [Hitz05]. Ein Aktivitätsdiagramm soll die Frage „Wie realisiert mein Sys-

tem ein bestimmtes Verhalten?“ beantworten [Rupp05]. In früheren Versionen stell-

ten Aktivitätsdiagramme eine spezielle Form von Zustandsdiagrammen dar. Mit der

Version 2.0 von UML wurden neue Elemente, wie z.B. Strukturierte Knoten, Ent-

scheidungsknoten oder Schleifenknoten eingeführt [Rupp05].


Aktivitätsdiagramme können in verschiedenen Abstraktionsebenen modelliert wer-

den. Das ist auch der Grund, warum sie in vielen Projektphasen einsetzt werden kön-

nen. Die drei wichtigsten Einsatzbereiche sind die Geschäftsprozessmodellierung,

die Beschreibung von Anwendungsfällen und die Implementierung einer Operation

[Rupp05].

Damit bietet das Aktivitätsdiagramm jegliche Form der Abstraktion an und reicht in

seiner Vielfalt von der Modellierung von Geschäftprozessen, welche eine sehr abs-

trakte Sicht auf ein Unternehmen gibt, bis hin zur Modellierung eines Algorithmus,

welcher einen kleinen Teil in einem Programm darstellt.

Gegliedert nach diesen drei Anwendungsbereichen sollen die folgenden Kapiteln

Aktivitätsdiagramme in Bezug auf Enterprise Anwendungen beschreiben.

3.2.1 Geschäftsprozessmodellierung

Die Modellierung eines Geschäftsprozesses macht in Bezug auf das begleitende Bei-

spiel keinen Sinn, da im begleitenden Beispiel kein Geschäftsprozess realisiert wird.

Bei Anwendungen, die den Businessprozess unterstützen sind Aktivitätsdiagramme

in dieser Abstraktionsebene durchaus sinnvoll und können gerade in der Anfangs-

phase eines Projekts eine gute Übersicht geben.

3.2.2 Anwendungsfallbeschreibung

Die Beschreibung von Anwendungsfällen ist ein weiteres Einsatzgebiet von Aktivi-

tätsdiagrammen, wie es das folgende Kapitel anhand des Beispiels „Bestellung

durchführen“ zeigen soll.

Dieses Beispiel gibt einen guten Überblick über die Einsatzmöglichkeit von Aktivi-

tätsdiagrammen in Enterprise Anwendungen. Der Anwendungsfall wird in Bezug auf

Benutzer- und Systemaktivitäten dargestellt.

Anwendungsfälle, die mittels Aktivitätsdiagramme beschrieben werden sollen, müs-

sen einen chronologischen Ablauf haben. In diesem Punkt sehe ich auch einen klei-

nen Nachteil beim Aktivitätsdiagramm. Es können nicht alle Anwendungsfälle aus-

sagekräftig modelliert werden.

Die Modellierung von Aktivitätsdiagrammen wird von StarUML nicht ausreichend

unterstützt. Deshalb stimmen einige in Abbildung 5 gezeigten Elemente nicht zu


100% mit der UML 2.0 Notation überein [Reic06].

Customer ShopSystem

Request productlist

Show productlist

Add (remove) product to cart

Save order

Input Customerdata

Save Customerdata

(De)select product

Send order

Check order

[Product]<<datastore>>

[more]

[change order]

[Order]

[Order]<<datastore>>

[customer]<<datastore>>

{create}

[shoppingCart]<<centralBuffer>>

Abbildung 5: Aktivitätsdiagramm des Anwendungsfall „Bestellung durchführen“

Das Aktivitätsdiagramm eignet sich prinzipiell sehr gut für die Modellierung der

Präsentationsschicht einer mehrschichtigen Architektur. Hier kann sehr gut beschrie-

ben werden, welche Aktivitäten der Benutzer vornimmt und welche Aktionen (Akti-

vitäten) das System macht, unabhängig davon, in welcher Ebene die eigentliche Lo-

gik implementiert ist.


Zusammengefasst kann gesagt werden, dass das Aktivitätsdiagramm eine gute Mög-

lichkeit darstellt, um komplexe Anwendungsfälle zu beschreiben, ohne dabei ins

Detail zu gehen. Ein komplexer Anwendungsfall durchläuft mehrere Aktivitäten und

kann möglicherweise auch mehrere alternative Aktivitäten durchlaufen.

3.2.3 Implementierung einer Operation

Ein weiteres Einsatzgebiet von Aktivitätsdiagrammen ist die Modellierung von Algo-

rithmen bzw. Operationen [Rupp05], wie es das hier gezeigte Beispiel demonstrieren

soll.

Als Beispiel wurde hier der Sortieralgorithmus „Bubble Sort“ gewählt. Dieser Sor-

tieralgorithmus durchläuft ein Array bis zum Ende, vergleicht zwei Zahlen, und

tauscht sie, wenn die vordere Zahl größer ist. Dieser Vorgang wird so lange wieder-

holt, bis das Array sortiert ist.

Der Quellcode des Algorithmus in Java zeigt Listing 1 [Möss05].

// Sort a (using bubble sort)

static void sort(int[] a) {

for (int i = a.length - 1; i > 0; i--)

for (int j = 0; j < i; j++)

if (a[j] > a[j+1]) {

int h = a[j];

a[j] = a[j + 1];

a[j + 1] = h;

}

}

}

}

Listing 1: Quelltext „Bubble Sort“

Als sehr hilfreich bei der Modellierung des hier gezeigten Aktivitätsdiagramms er-

wies sich ein Vergleich zwischen Nassi-Shneiderman-Struktogrammen [Nass73] und

Aktivitätsdiagrammen [Soph05].

Das Aktivitätsdiagramm in dieser Form für dieses einfache Beispiel ist noch eini-

germaßen übersichtlich, allerdings sagt die Literatur [Rupp05], dass die Verwendung

von anderen Modellierungstools durchaus in Betracht gezogen werden soll, sobald

komplexere Problemstellungen modelliert werden.

Auch das Aktivitätsdiagramm des relativ einfachen Sortieralgorithmus wirkt schon

etwas unübersichtlich. Bei komplexeren Algorithmen sind Pseudocode oder andere


Methodiken vorzuziehen, die nicht so platzintensiv sind. Meiner Meinung nach wur-

de in UML 2.0 diese Möglichkeit geschaffen, um auch Algorithmen darzustellen zu

können, was mit älteren Versionen von UML nicht möglich war.

Abbildung 6: Aktivitätsdiagramm Bubble Sort

Das Modellierungstool StarUML bietet die in Abbildung 6 gezeigte Notation nicht

an [Reic06].

3.3 Zustandsdiagramm

Zustandsdiagramme sind eine weitere Möglichkeit um das Verhalten eines Systems

zu modellieren. Dabei werden die Zustände, die das System einnehmen kann und

Änderungen von Zuständen modelliert. Änderungen von Zuständen können durch

interne oder externe Ereignisse ausgelöst werden [Rupp05].

Ein Zustandsdiagramm soll die Frage „Wie verhält sich das System in einem be-

stimmten Zustand bei gewissen Ereignissen?“ [Rupp05] beantworten. Zustandsdia-

gramme erlauben auch die Modellierung von parallel ablaufenden Zustandsautoma-


ten, was vor allem bei der Modellierung von verteilten Systemen zum Einsatz kom-

men kann [Rupp05].

Prinzipiell haben Zustandsautomaten mehrere Einsatzgebiete, die sich wie folgt defi-

nieren lassen [Rupp05]:

• Anwendungsfälle und Zustandsautomaten: Zustandsdiagramme eignen sich,

neben der textuellen Beschreibung und den Aktivitätsdiagrammen, zur Be-

schreibung von Anwendungsfällen [Rupp05]. Der Unterschied zum Aktivi-

tätsdiagramm, ist die Sicht auf das Gesamtsystem. Während beim Aktivitäts-

diagramm das Zusammenspiel zwischen den Aktoren und dem System mo-

delliert wird, werden im Zustandsdiagramm nur systeminterne Zustände und

deren Änderungen modelliert. Damit kann eine gute Übersicht über mögliche

Zustände der Präsentationsschicht gegeben werden. Ein Zustand entspricht

dabei einer Seite, die der Benutzer sieht. Eine Änderung des Zustands ent-

spricht zum Beispiel einer Benutzeraktivität. Das heißt Zustandsdiagramme

sind, wie auch Aktivitätsdiagramme, in dieser Abstraktionsebene für die

Modellierung der Präsentationsschicht geeignet.

• Klassen und Zustandsautomaten: Klassen und Attribute von Klassen können

bestimmte Zustände einnehmen. Ist die Anzahl der Zustände endlich, können

auch diese mit einem Zustandsdiagramm dargestellt werden (z.B. Enumera-

tionen) [Rupp05].

• Protokollzustandsautomaten: Diese spezielle Art von Zustandsdiagrammen

dient zur Beschreibung eines Protokolls. Unter einem Protokoll wird hier ein

abgeschlossenes System (z.B. eine Klasse) verstanden. Innerhalb dieser

Klasse werden mögliche Zustände und Änderungen von Zuständen beschrie-

ben. In dieser Form des Zustandsdiagrams dürfen nur bestimmte Protokoll-

zustände und Protokolltransitionen verwendet werden. Unter Protokollzu-

ständen versteht man Zustände ohne Aktivitäten. Protokolltransitionen haben

folgenden Aufbau: „[Vorbedingung] Operation / [Nachbedingung]“

[Rupp05].

Als Beispiel wird ein Protokollzustandsdiagramm des Objektes „Warenkorb“ model-


liert (siehe Abbildung 7). Mittels Zustandsdiagrammen kann eine übersichtliche Dar-

stellung der Zustände in einem Objekt modelliert werden.

empty

filled

ordered

empty

filled

ordered

add product

[no. products = 0] delete product

cancel order

submit order

send order

add product

[no. products > 0] delete product

Abbildung 7: Protokollzustandsdiagramm „Shopping Cart“

Mögliche Zustände eines Warenkorbes in einer Online Anwendung sind üblicher-

weise „leer“, „befüllt“ und „bestellt“.

Der Ausgangszustand eines Warenkorbs der Anwendung ist „leer“. Nach dem Hin-

zufügen des ersten Artikels ist der Warenkorb im Zustand „befüllt“. Werden weitere

Artikel in den Warenkorb hinzugefügt bleibt der Zustand des Objektes gleich. Wird

ein Artikel aus dem Warenkorb gelöscht, ändert sich der Zustand des Objektes nicht,

außer wenn alle Artikel aus dem Warenkorb gelöscht wurden, dann ist der Waren-

korb wieder im Zustand „leer“.

Ist das Objekt Warenkorb im Zustand „befüllt“ kann die Bestellung durchgeführt

werden. Nachdem die Bestellung durchgeführt wurde, nimmt das Objekt Warenkorb


den Zustand „bestellt“ ein. In diesem Zustand kann die Bestellung abgebrochen wer-

den. Wird die Bestellung abgebrochen nimmt das Objekt Warenkorb wieder den Zu-

stand „befüllt“ ein.

Befindet sich das Objekt im Zustand „bestellt“, kann die Bestellung abschickt bzw.

bestätigt werden. Bei dieser Änderung des Zustandes werden die Produkte im Wa-

renkorb bestellt (die Bestellung wird gespeichert) und das Objekt Warenkorb nimmt

wieder den Zustand „leer“ ein.

3.4 Sequenzdiagramm

Das Sequenzdiagramm dient zur Modellierung von Interaktionen im System. Eine

Interaktion spezifiziert die Art und Weise, wie Nachrichten und Daten zwischen ver-

schiedenen Interaktionspartnern ausgetauscht werden [Hitz05]. Ein Sequenzdia-

gramm soll die Frage „Wie läuft die Kommunikation in meinem System ab?“ beant-

worten [Rupp05].

Einen guten Überblick über die verschiedenen Einsatzmöglichkeiten von Sequenz-

diagrammen in Bezug auf die Phasen in einem Projekt soll Abbildung 8 zeigen.

Abbildung 8: Anwendungen von Sequenzdiagrammen im Projekt [Rupp05]

Das Sequenzdiagramm stellt ein sehr mächtiges Werkzeug für die Modellierung in

UML 2.0 dar. Mittels Sequenzdiagrammen lassen sich Interaktionen auf verschie-

densten Abstraktionsebenen modellieren. Diese Diagrammart erlaubt sowohl die


Modellierung des Systemkontexts, wie auch die Modellierung eines detaillierten

Operationsablaufs.

Bei der Modellierung des Operationsablaufs werden die Aufrufe einzelner Methoden

modelliert. Diese Art von Sequenzdiagrammen stellt einen detaillierten Blick auf das

System dar und ist vor allem für die Codegenerierung von Bedeutung. Das ist auch

der Grund, wieso Sequenzdiagramme in vielen Phasen des Projekts sinnvoll einge-

setzt werden können [Rupp05].

Sequenzdiagramme bieten auch eine gute Möglichkeit, um Architekturen und De-

signpatterns in einem System zu beschreiben. In der Praxis werden des Öfteren ver-

schiedene Designpattern mit Hilfe eines Sequenzdiagramms erklärt (vergleiche z.B.

[Sun08]).

Der Nachteil beim Sequenzdiagramm ist, dass die Modellierung relativ aufwendig

ist. Deshalb kann kein Projekt im angemessenen Zeitrahmen komplett mit Sequenz-

diagrammen modelliert werden [Rupp05]. Ziel von Sequenzdiagrammen soll es eher

sein, komplexe Abläufe in einem System zu beschreiben.

Die folgenden Kapiteln zeigen, anhand vom Beispielen, den Einsatz des Sequenzdia-

gramms als Architekturbeschreibung, zur Beschreibung eines Designpatterns und ein

weiteres Beispiel mit Operationsaufrufen.

3.4.1 Architekturbeschreibung

Als Beispiel für eine Architekturbeschreibung soll ein allgemein gehaltenes Se-

quenzdiagramm modelliert werden, welches den Aufruf der einzelnen Schichten dar-

stellt (siehe Abbildung 9).

Mit Hilfe eines Sequenzdiagramms kann das 4-Schichten Modell („4-tier-

architecture“) und seine Datenflüsse gut und übersichtlich dargestellt werden. Die

vier Schichten sind Client, Webserver, Anwendungsserver („applicationserver“) und

Datenbankserver („databaseserver“). Ein Client schickt eine Anfrage („httpRe-

quest“) an den Webserver. Dieser verarbeitet die Daten, und leitet eine entsprechende

Anfrage an den Anwendungsserver weiter. Der Anwendungsserver, welcher die Bu-

sinesslogik implementiert, speichert die empfangenen Daten in die Datenbank bzw.


liest die Daten von der Datenbank und schickt eine entsprechende Antwort an den

Webserver zurück. Der Webserver verarbeitet diese Daten und schickt die Antwort

an den Client zurück („httpResponse“).

Java Enterprise 4-tier Modelsd

Client Webserver Applicationserver Databaseserver

1 : httpRequest()

2 : request()3 : loadOrUpdateData()

4 : data

5 : response

6 : httpResponse

Abbildung 9: Sequenzdiagramm 4-Schichtenmodell

3.4.2 Designpatterns

Im folgenden Kapitel wird das DAO-Pattern („data access object“) mit Hilfe eines

Sequenzdiagramms dargestellt. Weitere häufig verwendete Designpatterns, die eben-

falls mit Hilfe von Sequenzdiagrammen (und auch Klassendiagrammen) beschrieben

wurden, befinden sich in der von Sun zur Verfügung gestellten Internetseite „Core

J2EE Patterns“ [Sun08].

Wie in Abbildung 10 gut ersichtlich kapselt das DAO-Pattern die Zugriffe auf die

Datenspeicherungsschicht. Das Business Objekt greift nicht direkt auf die Datenquel-

le zu, sondern nur auf das Datenzugriffsobjekt. Das ist der große Vorteil dieses Pat-

terns, da die Datenquelle leicht austauschbar bleibt (z.B. von einer Datenbank zu

XML Dateien). Bei einer Änderung der Datenquelle sind keine Änderungen an der

Business Logik notwendig.


Dieses Beispiel soll das Laden eines Objekts demonstrieren, welches in weiterer Fol-

ge geändert, und wieder in die Datenbank geschrieben werden soll.

Data Access Objectsd

BusinessObject DataAccessObject DataSource DomainObject

1 : create()

<<create>>

2 : loadData()

3 : loadData()

4 : create()

<<create>>

5 : setProperty()

6 : updateData()

7 : updateData()

Abbildung 10: Sequenzdiagramm DAO-Pattern (basiert auf [Sun08])

3.4.3 Detailmodellierung

Als weiteres Beispiel soll der Lebenszyklus eines Java Servlets mit Hilfe eines Se-

quenzdiagramms modelliert werden. Dieses Beispiel soll demonstrieren, dass mittels

Sequenzdiagrammen auch detaillierte technische Spezifikationen modelliert werden

können (siehe Abbildung 11).

Der Client schickt eine Anfrage („request“) an den Webserver. Dieser legt das Java

Servlet an und initialisiert es. Nach dem Aufruf der „init()“ Methode, wird die Servi-

cemethode aufgerufen. Hier wird nach der Requestmethode unterschieden („HTTP

GET, POST, ...“). In der Servicemethode findet die eigentliche Verarbeitung statt,

und das Antwortobjekt („response“) wird erzeugt. Das Java Servlet gibt das Ant-

wortobjekt an den Webserver weiter, welcher dieses Objekt wieder zurück an den

Client schickt. Danach wird das Java Servlet vom Webserver zerstört, nachdem die


Methode „destroy()“ aufgerufen wird.

Servlet life cyclesd

Client Werserver Servlet

1 : request()

2

<<create>>

3 : init()

4 : service()

5

6

7 : destroy()

<<destroy>>

Abbildung 11: Sequenzdiagramm Lebenszyklus Servlet (basiert auf [Ahme02])

3.5 Kommunikationsdiagramm

Das Kommunikationsdiagramm stellt das System auf einer relativ abstrakten Ebene

dar. Es soll die Frage „Welche Teile einer komplexen Struktur arbeiten wie zusam-

men, um eine bestimmte Funktion zu erfüllen?“ [Rupp05] beantworten. In älteren

Versionen von UML wurde das Kommunikationsdiagramm unter dem Namen Kol-

laborationsdiagramm geführt [Hitz05].

Ein Kommunikationsdiagramm bildet auf mittlerer Abstraktionsebene das Zusam-

menspiel von Kommunikationspartner zur Lösung einer gemeinsamen Aufgabe ab

[Rupp05]. Bei diesem Diagramm steht, im Vergleich zum Sequenzdiagramm, die

Übersicht im Vordergrund. Details und die zeitliche Abfolge sind beim Kommunika-


tionsdiagram nicht entscheidend [Rupp05]. Deshalb sind Kommunikationsdiagram-

me leichter zu modellieren und leichter zu lesen als Sequenzdiagramme.

Kommunikationsdiagramme werden unter anderem für folgende Problemstellungen

verwendet:

• Kommunikationsdiagramme können verwendet werden, um die Implementie-

rung eines Anwendungsfalls zu modellieren [Hitz05].

• Außerdem können Kommunikationsdiagramme für die Modellierung der

Implementierung einer Operation verwendet werden [Hitz05].

• Das Kommunikationsdiagramm dient zur Darstellung von komplexen Struktu-

ren auf eine übersichtliche Art und Weise [Rupp05].

• Mit Hilfe eines Kommunikationsdiagramms kann die grundsätzliche Struktur

eines Systems modelliert werden [Rupp05].

Das heißt das Kommunikationsdiagramm ist, wie auch das Sequenzdiagramm, in

Bezug auf die Abstraktionsebene sehr weit gestreut und kann in vielen Phasen im

Projekt eingesetzt werden.

Der Vorteil am Kommunikationsdiagramm, im Vergleich zum Sequenzdiagramm, ist

dass neben den Interaktionen auch strukturelle Aspekte modelliert werden können.

Dadurch ist, im Vergleich zu Sequenzdiagrammen, kein zusätzliches Diagramm

notwendig um strukturelle Aspekte zu modellieren [Hitz05].

3.6 Zeitdiagramm

Das Zeitdiagramm zeigt das zeitliche Verhalten in einem System. Es wurde in UML

2.0 neu eingeführt und soll die Frage: „Wann befinden sich verschiedene Interakti-

onspartner in welchem Zustand?“ beantworten [Rupp05].

Zeitdiagramme werden für die Modellierung von zeitkritischen Systemen, wie es

Echtzeitsysteme sind, verwendet [Hitz05]. Im Unterschied zu Sequenz- bzw. Kom-

munikationsdiagrammen können mittels Zeitdiagrammen der Ablauf nur exempla-

risch darstellt werden, da laut Standard keine Kontrollstrukturen zur Verfügung ste-

hen [Hitz05].


Zeitdiagramme sind u. a. unter folgenden Bedingungen einzusetzen [Rupp05]:

• Bei einem stark modularisiertem System mit stark abhängigen Zustandsdia-

grammen, um die Kommunikation zwischen den Automaten darzustellen.

• Wenn beim dem zu implementierenden System genaue zeitliche Übergänge

wichtig sind.

• Wenn für den zu modellierenden Sachverhalt lokale und globale Daten we-

niger interessant sind.

• Wenn bei der Anwendung Interaktionen einfach gestrickt sind und Neben-

läufigkeiten oder Kontrollelemente unnötig sind.

Alle oben beschrieben Punkte treffen bei einer Enterprise Anwendung nur sehr we-

nig zu.

3.7 Interaktionsübersichtsdiagramm

Das Interaktionsübersichtsdiagramm zeigt das Zusammenspiel verschiedener Inter-

aktionen. Die Darstellung erfolgt in Form einer Abwandlung des Aktivitätsdia-

gramms [Rupp05]. Ein Interaktionsübersichtsdiagramm soll die Frage „In welcher

Reihenfolge und unter welchen Bedingungen finden Interaktionen statt?“ beantwor-

ten [Rupp05].

Ein Interaktionsübersichtsdiagramms verwendet verschiedene Komponententypen

aus anderen Diagrammarten. Deshalb wurde es öfters kritisiert, soll aber dennoch

einen guten Überblick über die Ablaufreihenfolge verschiedener Interaktionsdia-

gramme geben [Hitz05].

3.8 Klassendiagramm

Ein Klassendiagramm zeigt die statische Struktur des Systems, indem es die stati-

schen Eigenschaften einer Klasse und deren Beziehungen zueinander beschreibt. Das

Klassendiagramm bildet den Kern der Modellierungssprache UML 2.0 [Rupp05] und

ist dadurch die zentrale Diagrammart in fast jedem Projekt. Sie können in jedem

Schritt der Softwaremodellierung in unterschiedlicher Abstraktionsebene verwendet


werden. Es soll die Frage „Wie sind die Daten und das Verhalten meines Systems im

Detail strukturiert?“ beantworten [Rupp05].

Prinzipiell können zwei Arten von Klassendiagrammen unterschieden werden, wobei

der Übergang fließend ist [Rupp05]:

• Konzeptuell-analytische Modellierung: Die Konzeptuell-analytische Model-

lierung wird in der Analysephase eines Projekts eingesetzt. Das heißt ein

Klassendiagramm soll in diesem Fall einen abstrakten Überblick über das

System geben. Ziel auf dieser Ebene ist es, die korrekten Zusammenhänge

im Projekt zu definieren. Das Klassendiagramm soll die Fachkonzepte und

deren Beziehungen zueinander abbilden, dabei stehen konkrete Attribute und

Operationen im Hintergrund [Rupp05].

• Logische, design-orientierte Modellierung: Die logische, design-orientierte

Modellierung findet in einer späteren Phase im Projekt statt. Sie soll als Vor-

bild für die Implementierung verwendet werden. Diese Art des Klassendia-

gramms stellt die Basis für die Codegenerierung dar. Hier werden alle Attri-

bute und Operationen, mit deren Datentypen bzw. Rückgabewerte und deren

Sichtbarkeit beschrieben [Rupp05].

An dieser einführenden Beschreibung lässt sich schon erkennen, wieso Klassendia-

gramme ein sehr beliebtes Werkzeug für die Modellierung sind. Klassendiagramme

sind gut lesbar, in jeder Phase des Projektes einsetzbar und erlauben große Unter-

schiede im Hinblick auf ihre Abstraktionsebene.

3.8.1 Konzeptuell-analytische Modellierung

Ein Klassendiagramm kann in einer sehr hohen Abstraktionsstufe einen Überblick

über die verwendete Systemarchitektur oder ein bestimmtes Designpattern geben.

Dabei werden nur die essentiellen Attribute und Operationen modelliert.

In der Literatur werden Patterns sehr oft mit einem Klassendiagramm und einem

Sequenzdiagramm (vgl. Kapitel 3.4.2) beschrieben (vgl. z.B. [Sun08]).

Abbildung 12 zeigt, wie das DAO-Pattern mittels Klassendiagramm beschrieben

werden kann. Wie schon im vorigen Kapitel beschrieben kapselt das DAO-Pattern


die Datenzugriffslogik von der Businesslogik. Beide Klassen verwenden ein so ge-

nanntes Transferobjekt um miteinander zu kommunizieren.

BusinessObject TransferObject

DataAccessObject DataSource

obtains/modifies

creates/usesuses

encapsulates

Abbildung 12: Klassendiagramm DAO-Pattern [Sun08]

In diesem Klassendiagramm lässt sich gut der Sinn dieses Pattern erkennen. Das Bu-

sinessobjekt greift nicht direkt auf die Datenquelle zu, sondern kommuniziert mit

Hilfe des Transferobjektes über das Datenzugriffsobjekt mit der Datenquelle. Da-

durch ist die Datenquelle leicht austauschbar macht. Um die Datenquelle zu ändern,

muss nur die Datenzugriffsklasse angepasst werden, die Businesslogik kann hinge-

gen unverändert bleiben.

Zusammengefasst kann gesagt werden, dass zur Modellierung von Designpattern,

Klassendiagramme in Verbindung mit Sequenzdiagrammen am besten geeignet sind,

wie es auch in der Literatur öfters verwendet wird (vgl. z.B. [Sun08]).

3.8.2 Logische, desgin-orientierte Modellierung

Als logisches, design-orientiertes modelliertes Klassendiagramm wird hier das Do-

mainmodell gezeigt (siehe Abbildung 13).

Ein Domainmodellklassendiagramm gibt einen guten Überblick über das System und

seine Meta-Daten. Es werden alle Klassen mit deren Attributen, Typen von Attribu-

ten und auch mögliche Defaultwerte modelliert.

Jede dieser modellierten Klassen hat als Operatoren „getter“ und „setter“ Methoden,

die zum Lesen und Setzen der Attribute dienen. Diese werden in der Praxis oft weg-


gelassen, um die Übersicht zu bewahren.

Aus diesem Diagramm (vgl. Abbildung 13) könnten im Rahmen einer modellgetrie-

benen Softwareentwicklung Klassen generiert werden und auch teilweise Daten-

bankskripts zum Erstellen von Datenbanktabellen. Leider wird in UML 2.0 nur der

Typ der Attribute angegeben und keine weiteren Informationen, wie z.B. die Feld-

länge.

Product

-id: Long-description: String-name: String-price: BigDecimal

ProductGroup

-id: Long-name: String

Order

-id: Long-date: Date

OrderItem

-numberOfProducts: Integer

Customer

-email: String-firstName: String-lastName: String

1

0..*

1

1

1

0..*

1

1..*

Abbildung 13: Klassendiagramm Domainmodell

Jeder Kunde („Customer“) tätigt mehrere Bestellungen („Order“). Eine Bestellung

(„Order“) besteht aus mehreren Teilen („OrderItem“). Jeder Teil einer Bestellung ist

genau einem Produkt („Product“) zugewiesen. Diese Zwischenklasse wurde ange-

legt, um ein Produkt öfters bestellen zu können. Ein Produkt ist in genau einer Pro-

duktgruppe („Productgroup“), wobei eine Produktgruppe mehrere Produkte beinhal-

ten kann, aber auch leer sein kann.


3.9 Paketdiagramm

Das Paketdiagramm dient zur Gliederung des Gesamtsystems in Pakete. Es soll die

Frage „Wie kann ich mein Modell so darstellen, dass ich den Überblick behalte?“

beantworten [Rupp05].

Das Paketdiagramm bietet eine gute Möglichkeit, um einen Überblick des Gesamt-

systems zu modellieren. Nachdem größere Softwareprojekte meist aus sehr vielen

verschiedenen Klassen bestehen, müssen diese in Pakete zusammengefasst werden,

um die Übersicht zu behalten.

Allgemein können Paketdiagramme in zwei unterschiedliche Anwendungsgebiete

eingeteilt werden [Rupp05]:

• Funktionale Gliederung: Bei einer funktionalen Gliederung werden alle Tei-

le, die funktional oder logisch im Zusammenhang stehen, zu einem Paket zu-

sammengefasst. Diese Einteilung wird meist zu einem frühen Zeitpunkt im

Projekt durchgeführt, da das modellierte Paketdiagramm einen guten Über-

blick gibt, welche Teile der Enterprise Anwendung zusammenhängend imp-

lementiert werden können [Rupp05].

• Definition von Schichten: Die Definition von Schichten dient zur Darstellung

eines mehrschichtigen Systems, wie es auch Enterprise Anwendungen sind.

In dieser Form von Paketdiagrammen werden die Pakete meist verschachtelt

dargestellt.

Paketdiagramme sind ein gutes Werkzeug, um die Struktur eines Projektes darzustel-

len. Bei dieser Diagrammart sind auch verschiedene Abstraktionsebenen zu beach-

ten.

So kann ein Paketdiagramm einen sehr groben Überblick über die verwendete Archi-

tektur geben, aber auch als Gliederung eines Klassendiagramms und dadurch als

Implementierungsgrundlage dienen.

3.9.1 Funktionale Gliederung

Das hier gezeigte Paketdiagramm (siehe Abbildung 14) zeigt eine funktionale Eintei-

lung der gesamten Anwendung.


Dieses Beispiel soll einen groben Überblick über die funktionale Einteilung in Pake-

ten geben.

Shopsystem

ProductService

Administrator Customer

OrderService

<<access>>

Abbildung 14: Paketdiagramm Shopsystem Übersicht

Dieses Diagramm zeigt eine grobe Übersicht über das Gesamtsystem, ohne die Pake-

te näher zu beschreiben.

Die gesamte Enterprise Anwendung teilt sich in zwei Pakete:

• „Productservice“: Das Produktservice beinhaltet die gesamte Produkt- und

Produktgruppenverwaltung. Zu diesem Service zählen Anwendungsfälle wie

unter anderem „Produkt anlegen“, „Produkt ändern“ oder „Produktliste an-

zeigen“.

• „Orderservice“: In diesem Paket sind alle Teile der Bestellung enthalten. Zu

diesem Paket zählen unter anderem die Anwendungsfälle „Bestellung ab-

schicken“ oder „Produkt zum Warenkorb hinzufügen“.


3.9.2 Definition von Schichten

Paketdiagramme bieten eine gute Möglichkeit, um eine Einteilung der Schichten zu

modellieren [Hitz05]. Abbildung 15 zeigt ein Systemmodell einer Enterprise An-

wendung.

User

EnterpriseApplication<<systemModel>>

Web-Subsystem Enterprise-Subsystem

View

PersisentData

Businesslogic

Controller

<<access>>

<<access>>

<<import>>

Abbildung 15: Paketdiagramm Übersicht Enterprise Anwendung

Der Aktor „User“ greift auf das „Web-Subsystem“ zu. In diesem Teilpaket befinden

sich die Elemente der Präsentationsschicht und die Controllerelemente. Die Control-

lerelemente greifen auf das Enterprise Subsystem zu. In diesem Paket ist das Unter-

paket Geschäftslogik, welches auf das ein weiteres Subpaket „persistierte Daten“

zugreift, um Daten aus der Datenbank zu lesen bzw. Daten in die Datenbank zu

schreiben.

In der Praxis werden Paketdiagramme und Klassendiagramme sehr oft in Kombina-

tion verwendet. So können die im vorigen Diagramm dargestellten Pakete die model-

lierten Klassen aus dem Klassendiagramm enthalten.

Das UML-Modellierungstool StarUML sieht keine eigene Diagrammart „Paketdia-

gramm“ vor, sondern die Elemente des Paketdiagramms sind im Klassendiagramm


inkludiert [Reic06].

3.10 Objektdiagramm

Ein Objektdiagramm bietet die Möglichkeit Instanzen von Klassen, Komponenten,

Knoten, Assoziationen und Attributen zu modellieren. Es soll die Frage: „Wie sieht

ein Schnappschuss meines Systems zur Ausführungszeit aus?“ beantworten

[Rupp05]. Eine Klasse wird als Objekt dargestellt, ein Attribut einer Klasse als kon-

kreter Wert und eine Assoziation zwischen Klassen als Link.

Der Aufbau eines Objektdiagramms, ist dem Klassendiagramm sehr ähnlich, mit

dem Unterschied, dass bei Objektdiagrammen Instanzen von Klassen modelliert

werden.

Ein Vorteil des Objektdiagramms im Vergleich zum Klassendiagramm ist, dass sich

Attribute von Klassen besser beschreiben lassen. Das Klassendiagramm erlaubt nur

die Modellierung eines Defaultwertes, während beim Objektdiagramm konkrete

Werte modelliert werden [Rupp05].

Das Klassendiagramm bietet einen abstrakten Überblick über Objekte. Im Vergleich

dazu werden mit dem Objektdiagramm konkrete Anwendungen und Instanzen von

Klassen modelliert. Das Objektdiagramm bietet aus diesem Grund eine detaillierte

Sicht auf ein Teilsystem.

Objektdiagramme haben im Projekt breit gestreute Anwendungsmöglichkeiten. Die

Anwendungsmöglichkeiten im Projekt sind unter anderem [Rupp05]:

• Objektdiagramme dienen zur Illustration rekursiver Strukturen im Klassen-

diagramm. Das Objektdiagramm zeigt die tatsächlichen Strukturen zwischen

Instanzen gleicher Klassen. Diese rekursiven Strukturen sind im Klassendia-

gramm nicht ersichtlich.

• Objektdiagramme können zur Überprüfung von Klassendiagrammen einge-

setzt werden. Wird ein konkreter Fall in Form eines Objektdiagramms mo-

delliert, können auch in einer frühen Phase des Projekts Fehler im Klassen-

diagramm aufgedeckt werden.


• Zum Finden von Klassen durch die Modellierung von Objektdiagrammen.

Wird zuerst das Objektdiagramm modelliert, so kann aus diesem ein mögli-

ches Klassendiagramm abgeleitet werden.

• Für die Dokumentation von Architekturen, in denen Objekte durch abstrakte

oder generische Fabriken erzeugt werden. Diese Objekte sind in einem Klas-

sendiagramm nicht sichtbar und werden erst durch die Darstellung des kon-

kreten Objekts sichtbar.

• Für die Modellierung von Konfigurationen, falls diese dem Modell entnom-

men werden. Auch Konfigurationsdateien können mit Hilfe des Objektdia-

gramms dargestellt werden. Dies macht vor allem dann Sinn, wenn Konfigu-

rationsdateien aus dem Modell generiert werden sollen.

• Ein weiterer Anwendungsfall für Objektdiagramme ist die Modellierung von

Testdaten. In diesem Fall werden konkrete Testdaten in Form eines Objekt-

diagramms modelliert.

Objektdiagramme bieten für Enterprise Anwendungen eine gute Übersicht. In Enter-

prise Anwendungen gibt es meistens eine Vielzahl von Interfacedefinitionen und

Implementierungen, dadurch ist es durchaus sinnvoll, eine konkrete Abbildung des

Klassendiagramms in Form eines Objektdiagramms zu modellieren.

Ein weiterer Anwendungsfall ist die Modellierung eines Objektdiagramms für Do-

mainobjekte. Es stellt eine gute Überprüfung für das Klassendiagramms dar und der

gleiche Arbeitsschritt ermöglicht die Modellierung von Testdaten.

Als Beispiel soll für das Klassendiagramm aus Kapitel 3.8 (siehe Abbildung 13) eine

konkrete Instanz modelliert werden. Es könnte sich dabei um Testdaten des Domä-

nenmodells handeln.

Anhand des Objektsdiagramms (siehe Abbildung 16) kann man gut erkennen, dass

das vorher modellierte Klassendiagramm korrekt ist und in dieser Form angewendet

werden kann.

Durch die Modellierung dieses konkreten Beispiels wurde auch klar, dass es wohl

nicht vorkommt, dass ein Kunde zur gleichen Zeit mehrere Bestellungen hat. Diese


1:n Beziehung würde allerdings sehr wohl bei der Administration von Bestellungen

Sinn machen.

customer : Customer

email = [email protected] = ChristianlastName = Sokop

order1 : Order

id = 2date = 2008-05-23

order2 : Order

id = 4date = 2008-05-24

orderItem1 : OrderItem

numberOfProducts = 1





product1 : Product

id = 123name = UML Glasklarprice = 35

product2 : Product

id = 47name = UML@workprice = 39

product3 : Product

id = 39name = WindowsVistaprice = 430

productGroup1 : ProductGroup

id = 2name = Books

productGroup2 : ProductGroup

id = 4name = OS

Abbildung 16: Objektdiagramm Testdaten Domänenmodellklassendiagramm

3.11 Kompositionsstrukturdiagramm

Mit dem Kompositionsstrukturdiagramm lassen sich interne Strukturen von Kompo-

nenten und deren Interaktionen zu anderen Komponenten darstellen. Es soll die Fra-

ge „Wie sind die einzelnen Architekturkomponenten strukturiert und mit welchen

Rollen spielen sie dabei zusammen?“ beantworten [Rupp05].


Das Kompositionsstrukturdiagramm wurde in UML 2.0 neu eingeführt [Rupp05].

Prinzipiell kann zwischen zwei Arten von Kompositionsstrukturdiagrammen unter-

schieden werden [Hitz05]:

• Kompositionsstrukturdiagramm für Klassen: Das Ziel des Kompositions-

strukturdiagramms für Klassen ist es, eine detaillierte Beschreibung der in-

ternen Struktur einer Klasse zu modellieren. Der Vorteil gegenüber dem

Klassendiagramm ist es, dass im Kompositionsstrukturdiagramm die Zu-

sammenhänge der Klassen aus Sicht einer bestimmten Klasse (Kontextklas-

se) modelliert werden. Dadurch ist ein Kompositionsstrukturdiagramm in

vielen Fällen übersichtlichter als das Klassendiagramm, hat aber die gleiche

Aussage.

• Kompositionsstrukturdiagramm für Kollaborationen: Hier wird das Zusam-

menspiel der Komponenten modelliert. Das Hauptaugenmerk liegt dabei

nicht auf das „wie und wann“, sondern wer mit welcher Komponente kom-

muniziert [Hitz05]. Diese Art des Kompositionsstrukturdiagramms eignet

sich besonders gut, um Designpattern zu beschreiben, die in der Implemen-

tierung angewendet werden [Rupp05].

In den folgenden Kapiteln sollen für diese beiden Arten von Kompositionsstruktur-

diagrammen Beispiele modelliert werden.

3.11.1 Kompositionsstrukturdiagramm für Klassen

Mit Hilfe des Kompositionsstrukturdiagramms kann eine Art Klassendiagramm mo-

delliert werden. Dazu wird eine Kontextklasse bestimmt und ausgehend von dieser

Klasse werden die anderen Klassen und deren Zusammenhänge modelliert. In diesem

Diagramm kommt die Navigation durch die Klassen gut zum Vorschein.

In diesem Kapitel wird das Klassendiagramm aus Sicht des Kunden modelliert (siehe

Abbildung 17). Dieses Kompositionsstrukturdiagramm gibt eine Übersicht über die

einzelnen Klassen im Klassendiagramm aus Sicht der Klasse Kunde („Customer“).

Ein Kunde kann mehrere Bestellungen („Order“) haben. Eine Bestellung wiederum

besteht aus mehreren Teilen („OrderItem“). Diese werden genau einem Produkt


(„Product“) zugewiesen, welches einer Produktgruppe („Produktgroup“) zugeordnet

sein kann.

Customer

-email: String-firstName: String-lastName: String-order: Order[0..*]

Order

-id: Long-date: Date-orderItem: OrderItem[1..*]

OrderItem

-numberOfProducts: Integer-product: Product[1]

Product

-id: Long-description: String-name: String-price: BigDecimal-productGroup: ProductGroup[0..1]

ProductGroup

-id: Long-name: String

Abbildung 17: Kompositionsstrukturdiagramm Kontextklasse „Customer“

Üblicherweise werden, anders als hier gezeigt, weitere Attribute der Klassen nicht

modelliert, sondern nur die Attribute, die eine Verbindung zu einer anderen Klasse

definieren.

Diese Diagrammart gibt einen guten Überblick über das Zusammenspiel der Klassen.

Im Vergleich zum Klassendiagramm lassen sich mit Hilfe des Kompositionsstruktur-

diagramms die Zusammenhänge der Klassen übersichtlicher modellieren, da das ge-

samte Diagramm von einer Kontextklasse aus betrachtet wird.


3.11.2 Kompositionsstrukturdiagramm für Kollaborationen

Kompositionsstrukturdiagramme für Kollaborationen bieten eine gute Möglichkeit

um Designpattern zu beschreiben [Rupp05]. Die Beschreibung von Designpattern ist

ein wichtiger Punkt in einer Enterprise Anwendung. In weiterer Folge können die

modellierten Patterns in konkreten Beispielen angewendet werden.

Im Kompositionsstrukturdiagramm für Kollaboration werden die benötigten Elemen-

te und die Zusammenhänge zwischen den Elementen modelliert. Das Kompositions-

strukturdiagramm soll in dieser Abstraktionsebene eine Übersicht über ein Pattern

geben und nicht den genauen Aufbau eines Patterns beschreiben. Für die Beschrei-

bung des Aufbaus eines Patterns sind Klassen- bzw. Sequenzdiagramme besser ge-

eignet.

Abbildung 18 zeigt, das im Rahmen dieser Arbeit schon des Öfteren modellierte

DAO-Pattern.

Abbildung 18: Kompositionsstrukturdiagramm DAO-Pattern

Im Falle des DAO-Patterns werden das Businessobjekt, das Datenzugriffsobjekt, das

Transferobjekt und die Datenquelle modelliert.

Diese Modellierung des Kompositionsstrukturdiagramms erlaubt in weiterer Folge

die Modellierung eines konkreten Anwendungsfalls des Patterns, wie es Abbildung

19 demonstrieren soll.

Wie in der in Abbildung 18 gezeigten Modellierung des DAO-Patterns werden ein


Businessobjekt, ein Transferobjekt, ein Datenzugriffsobjekt und eine Datenquelle

benötigt. Die Datenquelle wird in diesem konkreten Beispiel nicht modelliert.

ProductServiceImpl

DAOPattern

ProductDataAccessObject

Product

-id: Long-description: String-name: String-price: BigDecimal-productGroup: ProductGroup[0..1]

Abbildung 19: Kompositionsstrukturdiagramm Anwendung DAO-Pattern

Das Kompositionsstrukturdiagramm in Abbildung 19 zeigt die Anwendung des

DAO-Patterns. Das Businessobjekt wird in Form der Klasse „ProductServiceImpl“

dargestellt. Als Datenzugriffsobjekt wird die Klasse „ProductDataAccessObject“

verwendet und als Transferobjekt die Klasse „Product“. Dieses Diagramm soll ver-

deutlichen, dass hier das DAO-Pattern verwendet wird.

Da das Kompositionsstrukturdiagramm in UML 2.0 neu definiert wurde, wird es von

StarUML noch nicht ausreichend unterstützt [Reic06].

3.12 Komponentendiagramm

Das Komponentendiagramm bietet die Möglichkeit, die Struktur eines Systems zur

Laufzeit darzustellen. Es soll die Frage „Wie ist mein System strukturiert und wie

werden diese Strukturen erzeugt?“ beantworten [Rupp05].

Der Begriff Komponente ist in UML 2.0 „ein modularer Teil eines Systems, der zur

Abstraktion und Kapselung einer beliebig komplexen Struktur dient, die nach außen


wohldefinierte Schnittstellen zur Verfügung stellt“ [Hitz05].

Das Komponentendiagramm erlaubt „sowohl die interne Struktur einer Komponente

abzubilden als auch die verschiedenen Wechselbeziehungen zwischen Komponenten“

[Rupp05]. Mit Hilfe des Komponentendiagramms lassen sich „sowohl physische als

auch logische Modellierungsaspekte abdecken“ [Hitz05]. Aus diesem Grund sind

Komponentendiagramme ein wichtiges Modellierungswerkzeug für verteilte Syste-

me, wie es auch Enterprise Anwendungen sind. Das Komponentendiagramm kann

auch das Zusammenspiel zwischen physischen und logischen Komponenten darstel-

len.

In einer Enterprise Anwendung werden sehr viele Interfaces und Implementierungen

verwendet. Das Komponentendiagramm bietet eine gute Möglichkeit, um diese Inter-

faces darzustellen.

Eine Java Enterprise Anwendung besteht aus mehreren Komponenten, die in

Abbildung 20 dargestellt werden.

UserInterface

BusinessService

DataAccess

Database

BusinessMethods

PersistenceMethods

DataSource

Abbildung 20: Komponentendiagramm Java Enterprise Anwendung

Das Komponentendiagramm in Abbildung 20 zeigt einen üblichen Aufbau einer Java

Enterprise Anwendung. Die Datenbank stellt eine Datenquelle zur Verfügung, wel-

che von den Datenzugriffsobjekten verwendet wird. Diese stellen wieder ein Inter-


face zur Verfügung (Persistenzmethoden), welches vom Businessservice verwendet

wird. Die vom Businessservice zur Verfügung gestellten Businessmethoden werden

vom Userinterface aufgerufen. Es kann sich dabei sowohl um physische, wie auch

um logische Komponenten handeln.

Weiters bieten Komponentendiagramme die Möglichkeit Artefakte und deren Inhalte

darzustellen. Das Diagramm in Abbildung 21 soll das Zusammenspiel der Kompo-

nenten einer Java Enterprise Anwendung darstellen.

sample.ear<<artifact>>

sample.war<<artifact>>

jsp-page

controllerClasses

jsp-page

controllerClasses

sample.jar<<artifact>>

interfaces

Domainobjects

interfaces

Domainobjects

web.xml<<artifact>>

BusinessMethods

sample-impl.jar<<artifact>>

implemetationsimplemetations

BusinessMethodsImpl

ejb-jar.xml<<artifact>>

Abbildung 21: Komponentendiagramm Java EE Web-Anwendung

Das Komponentendiagramm der Java EE Web-Anwendung zeigt den Aufbau der

„ear“ Datei. Eine „ear“ (Enterprise Archiv) Datei enthält alle Komponenten, die in


einer Java Enterprise Anwendung vorhanden sind. Das sind insbesondere eine „war“

(Web Archiv) Datei, die Interfaces der Businessmethoden (Enterprise Java Beans)

und die Implementierung der Business Methoden. Die „war“ Datei enthält alle Kom-

ponenten, die für die Realisierung des Webteils benötigt werden. Die Interfaces ent-

halten neben den Definitionen der Businessinterfaces selbst, die gemeinsam verwen-

deten Domainobjekte und einen Deploymentdeskriptor („ejb-jar.xml“).

Mit Komponentendiagrammen kann eine exakte Deploymentumgebung modelliert

werden. Das ist bei Java Enterprise Web-Anwendungen relativ schwierig, da es,

selbst bei sehr kleinen Projekten, eine genaue Anordnung der Komponenten vorsieht.

3.13 Verteilungsdiagramm

Ein Verteilungsdiagramm beschreibt die Zuordnung von Artefakten auf Hardware-

einheiten. Mit Hilfe dieses Diagramms soll die Frage „Wie werden die Artefakte des

Systems zur Laufzeit wohin verteilt?“ beantwortet werden [Rupp05].

Die Modellierung von Verteilungsdiagrammen eignet sich nur, wenn die Anwendung

auf mehreren Hardwarekomponenten (Knoten) läuft [Rupp05]. Bei Enterprise An-

wendungen ist die Entwicklung von Verteilungsdiagrammen daher sehr sinnvoll, da

Enterprise Anwendungen zumindest theoretisch auf mehrere Knoten verteilt werden

können.

Verteilungsdiagramme enthalten neben den „normalen“ Knoten auch Ausführungs-

umgebungsknoten. Diese Ausführungsumgebungen können z.B. ein Betriebssystem

oder ein Webbrowser sein [Hitz05]. Zusätzlich werden für die Modellierung eines

Verteilungsdiagramms unter anderem Artefakte und „Deployment Spezifications“

angeboten [Hitz05].

Eine Java EE Web-Anwendung besteht üblicherweise aus drei verschiedenen physi-

schen Konten. Der Benutzer greift mit seinem Client, auf dem in den meisten Fällen

der Webbrowser läuft, auf den Anwendungsserver zu. In dieser Serverumgebung ist

die Anwendung installiert. Der Anwendungsserver greift auf einen externen Daten-

bankserver zu.

Dieses Diagramm gibt eine gute Übersicht über die verschiedenen Artefakte und

deren Verteilung auf physischen Knoten. Es soll nicht unerwähnt bleiben, dass bei


kleinen Projekten der DB-Server und der Anwendungsserver auf demselben physi-

schen Knoten liegen.

Eine allgemeine Darstellung einer Java Enterprise Web-Anwendung ist in Abbildung

22 zu sehen.

Client<<device>>

Webbrowser<<executionEnvironment>>

Server<<device>>

DbServer<<device>>

J2EE-ApplikationServer<<executionEnvironment>>

serverlibs<<artifact>>

application.ear<<artifact>>

application.war<<artifact>>

web.xml<<deployment spec>>

ejb-jar.xml<<deployment spec>>

<<internet>>

<<ethernet>>

<<deploy>>

Abbildung 22: Verteilungsdiagramm Java EE Web-Anwendung

Kapitel 4

UML Erweiterungen für Eclipse

Das folgende Kapitel soll zunächst einen kurzen Überblick über die verschiedenen

Plugins der Entwicklungsumgebung „eclipse“ geben. In weiterer Folge wird jedes

dieser Plugins einzeln evaluiert.

4.1 Einleitung

Es gibt eine Vielzahl von Plugins für die Entwicklungsumgebung „eclipse“. Für jede

noch so spezielle Anforderung findet sich relativ schnell ein passendes Plugin (vgl.

z.B. [Ecli08a]). Mit Stand Mitte Juni 2008 werden an dieser zentralen Stelle 1058

verschiedene Plugins vorgestellt, welche nach Kategorien eingeteilt sind. Unter dem

Überbegriff UML werden 35 Plugins angeboten, weitere 65 Plugins sind unter dem

Begriff „Modeling“ gelistet.

Der erste Schritt im Rahmen dieser Diplomarbeit ist es, aus der Vielzahl der vorhan-

denen Plugins einige passende auszuwählen, die in weiterer Folge evaluiert werden

sollen. Ziel ist es möglichst kostengünstige Plugins auszuwählen, die sowohl eine

Modellierung mit UML, wie auch die Generierung von Java Quelltext aus den Dia-

grammen erlauben. Unter kostengünstig wird hier ein Betrag von 100 Euro pro Jahr

oder weniger pro Lizenz angenommen.

Bei der Auswahl wurde auch darauf geachtet, dass die Plugins am aktuellen Stand

sind und wenn möglich laufend weiterentwickelt werden. Wurde die aktuellste Ver-

sion des Plugins vor mehr als einem Jahr (Stand Mai 2008) zur Verfügung gestellt,

wird dieses im Rahmen dieser Diplomarbeit nicht weiter beachtet. Außerdem wurde

UML Erweiterungen für Eclipse Seite 62

darauf geachtet keine Beta-Versionen zu evaluieren.

Ein weiteres Kriterium sind, die auf der Internetseite [Ecli08a] verfassten Benutzer-

kommentare. Wird in diesen Kommentaren von einer Vielzahl von Fehlern berichtet

oder das Plugin von mehreren Personen als unbrauchbar eingestuft, wurde es im

Rahmen dieser Diplomarbeit nicht näher evaluiert.

Die hier ausgewählten Plugins sind nicht die einzigen die am Markt existieren, son-

dern eine Auswahl aus denen, die den oben genannten Anforderungen entsprechen.

Folgende Plugins werden näher in betracht gezogen (in alphabethischer Reihenfol-

ge):

• Apollo for Eclipse [Apol08]: Dieses kostenpflichtige Plugin unterstützt nur

eine Mischung aus dem Paket- und Klassendiagramm. Besonders interessant

ist die Möglichkeit der Codegenerierung aus dem Diagramm und auch die

Möglichkeit Diagramme aus dem Quelltext erzeugen zu lassen. Als besonde-

res Feature soll dieses Plugin den Quellcode und das Diagramm synchron

halten. Im Rahmen dieser Diplomarbeit wurde Version 3.0.1 dieses Plugins

evaluiert.

• AmaterasUML [Amat08]: Dieses Plugin ist kostenlos verfügbar und unter-

stützt das Klassen-, Sequenz- und Anwendungsfalldiagramm. Außerdem soll

Java Quelltext aus dem Klassendiagramm generiert werden können und

Klassen sollen im Rahmen eines Reverse Engineering einfach ins Klassen-

diagramm importiert werden können [Ecli08a]. Im Rahmen dieser Diplom-

arbeit wurde Version 1.3.1 dieses Plugins evaluiert.

• Blueprint Software Modeler [Blue08]: Dieses Plugin, oder besser gesagt diese

auf Eclipse basierende Entwicklungsumgebung, bietet in einer kostenlosen

Version mit dem Klassen-, Paket-, Komponenten-, Kompositionsstruktur-,

Objekt-, Anwendungsfall-, Aktivitäts-, Zustands- und Sequenzdiagramm die,

für die Entwicklung von Enterprise Anwendungen wichtigsten Diagrammar-

ten an. Nicht unterstützt werden das Kommunikation-, Zeit-, Interaktionsü-

bersichts- und leider auch das Verteilungsdiagramm. Diese Diagrammarten

werden, mit Ausnahme des Verteilungsdiagramms, für die Modellierung ei-

ner Enterprise Anwendung nicht verwendet, wie das vorherige Kapitel zeigt.


Eine Transformation von UML in Java Quelltext ist leider erst ab der mit

800 Euro (Stand Mai 2008) relativ teuren Professional Version möglich.

Deshalb wird im Rahmen dieser Diplomarbeit die Version 1.4.0 der „Free

Community Edition“ evaluiert.

• eUML [eUML08]: Von diesem Eclipse Plugin gibt es, neben der mit 590 Eu-

ro relativ teuren (Stand Mai 2008) Version, auch eine freie Version. Zusätz-

lich wird eine Lizenz für Universitäten angeboten. Mit der im Rahmen dieser

Diplomarbeit evaluierten freien Version besteht die Möglichkeit Klassen-,

Paket- und Sequenzdiagramme zu erstellen. Als weiteres Feature wird ange-

geben, dass eine „Realtime code/model synchronization“ möglich ist, was

besonders im Hinblick auf eine modellgetriebene Entwicklung von großer

Bedeutung ist. Im Rahmen dieser Diplomarbeit wurde die Version

3.1.0.20080415 dieses Plugins evaluiert.

• green [gree08]: Dieses freie verfügbare Plugin wurde von der Universität in

Buffalo entwickelt. Es wird das Klassendiagramm und eine automatisierte

Codegenerierung angeboten. Außerdem soll es die Möglichkeit anbieten aus

bestehenden Klassen, Diagramme zu erzeugen. Als weiteres Feature wird

genannt, das sich Klassendiagramm und Quelltext automatisch synchronisie-

ren. Im Rahmen dieser Diplomarbeit wurde die Version 3.0.0 des Plugins

evaluiert.

• MyEclipse [Myec08]: Die auf eclipse basierende Entwicklungsumgebung

„MyEclipse“ bietet neben der Unterstützung von UML eine Vielzahl von

weiteren Plugins an, die für die Entwicklung von Enterprise Anwendung ei-

ne große Hilfe darstellen. Das integrierte UML Plugin unterstützt das An-

wendungsfall-, Klassen-, Sequenz-, Kollaborations-, Zustands-, Aktivitäts-

und Verteilungsdiagramm. Da man davon ausgehen kann, dass das Paketdia-

gramm im Rahmen des Klassendiagramms realisiert wurde, werden mit die-

sem Plugin die wichtigsten Diagrammarten angeboten. Der Preis von ca. 60

Euro pro Jahr (Stand: Mai 2008) ist für das gebotene durchaus akzeptabel.

Im Rahmen dieser Diplomarbeit wurde die Version 6.0.1 GA dieser Ent-

wicklungsumgebung evaluiert.

• Slime UML [slim08]: Das freie Plugin „Slime UML“ bietet eine volle Unter-


stützung von Klassen-, Paket- und Anwendungsfalldiagrammen. Außerdem

soll auch mit diesem Plugin eine automatische Anpassung der Diagramme

bei Änderung des Codes erfolgen. Im Rahmen dieser Diplomarbeit wurde

die Version 2.0.7 dieses Plugins evaluiert.

• Violet UML Editor [Viol08]: Dieses freies verfügbare Eclipse Plugin bietet

zwar leider keine Möglichkeit der Codegenerierung an, dafür werden mit

dem Anwendungsfall-, Klassen-, Aktivitäts-, Sequenz-, Zustands- und Ob-

jektdiagramm die meist verwendeten Diagrammarten unterstützt. Dieses

Plugin wirbt besonders mit einer unkomplizierten und intuitiven Erstellung

von den oben genannten Diagrammen. Im Rahmen dieser Diplomarbeit wur-

de die Version 0.21 dieses Plugins evaluiert.

Als nächster Schritt sollen die ausgewählten Plugins nach ihrer Funktionalität und

Angebot gruppiert werden. Die Plugins „Apollo for Eclipse“ und „Green“ bieten nur

das Klassendiagramm an, dafür wird bei diesen beiden Plugins die Codegenerierung

realisiert.

Die Plugins „eUML“, „AmaterasUML“ und „Slime UML“ bieten neben dem Klas-

sendiagramm und der Möglichkeit der Codegenerierung noch zumindest eine weitere

Diagrammart an. Das Plugin „Slime UML“ bietet zusätzlich das Anwendungsfalldia-

gramm, das Plugin „eUML“ das Sequenzdiagramm und das Plugin „AmaterasUML“

bietet sowohl das Anwendungsfall- wie auch das Sequenzdiagramm an.

Die Plugins „Blueprint Software Modeler“ und „Violet UML Editor“ bieten eine

Vielzahl der vorhandenen UML Diagrammarten an. Leider wird bei diesen beiden

Plugins keine Codegenerierung angeboten.

Einzig die auf eclipse basierende Entwicklungsumgebung „MyEclipse“ bietet einen

Großteil der vorhandenen Diagramme und die Codegenerierung an.

Für die folgenden Kapitel wurde folgende Gruppierung festgelegt:

• „MyEclipse“: Diese erweiterte Entwicklungsumgebung bietet als einziges

hier evaluierte Tool, sowohl eine Vielzahl von UML Diagrammen, wie auch


die Codegenerierung an.

• UML Editoren: Hier werden die Plugins „Blueprint Software Modeler“ und

„Violet UML Editor“ evaluiert. Diese beiden Plugins bieten nur die Mög-

lichkeit UML Diagramme zu modellieren, allerdings keine automatisierte

Codegenerierung.

• Codegeneratoren: In diesem Kapitel werden die Plugins, die nur ein Klas-

sendiagramm, bzw. ein um das Paketdiagramm erweitertes Klassendia-

gramm, und die automatisierte Codegenerierung anbieten, evaluiert. Es han-

delt sich dabei um die Plugins „Apollo for Eclipse“ und „Green“.

• Erweiterte Codegeneratoren: Hier werden die Plugins, die sowohl die Code-

generierung aus Klassendiagrammen, sowie zumindest ein weiteres Dia-

gramm anbieten, evaluiert. Es handelt sich dabei um die Plugins „eUML“,

„AmaterasUML“ und „SlimeUML“.

4.2 MyEclipse

Die auf der Entwicklungsumgebung „eclipse“ basierende Entwicklungsumgebung

bietet neben der Unterstützung von UML, auch eine Reihe weitere Features und Er-

weiterungen an, die vor allem bei der Entwicklung von Enterprise Anwendungen

sehr hilfreich sein können. Die evaluierte Version kostet für ein Jahr ca. 60 Euro

(Stand Mai 2008).

Die Installation dieser Entwicklungsumgebung ist relativ einfach. Auf der Internet-

seite wird die komplette Entwicklungsumgebung als Installationsdatei für Microsoft

Windows angeboten. Für andere Betriebssysteme wird ein Update, welches auf „ec-

lipse“ basiert angeboten.

Der erste Eindruck ist sehr positiv, da der Start sehr einfach und vertraut ist. Nach

Anlegen eines Projekts, können schon erste Diagramme modelliert werden.

Der UML Teil der Entwicklungsumgebung bietet das Anwendungsfall-, Klassen-,

Sequenz-, Kollaborations-, Zustands-, Aktivitäts- und Verteilungsdiagramm an. In

den folgenden Kapiteln werden die einzelnen Diagrammarten einzeln evaluiert.


Den Aufbau der Benutzeroberfläche soll Abbildung 23 zeigen. Nach Erstellung einer

„MyEclipse UML Datei“ können an diese Datei alle angebotenen Diagrammarten

hinzugefügt werden.

Im linken Bereich in Abbildung 23 werden die vorhandenen Diagramme gelistet. Der

Hauptbereich teilt sich in diagrammbezogene Elemente (im oberen Bereich, hier

Anwendungsfalldiagramm) und dem Diagramm selbst.

Abbildung 23: MyEclipse: Benutzeransicht

4.2.1 Anwendungsfalldiagramm

Das Erstellen eines Anwendungsfalldiagramms ist relativ einfach. Im oberen Bereich

der Ansicht stehen die benötigten Elemente, wie Anwendungsfälle, Aktoren und Be-

ziehungen zueinander zur Auswahl (siehe Abbildung 23).

Allerdings wird nur die Basisfunktionalität angeboten. Soll ein Anwendungsfalldia-

gramm in Pakete eingeteilt werden, so ist dies nur händisch mittels Rechtecken mög-

lich.

Ein großer Pluspunkt, ist die Möglichkeit jedes Element im Diagramm (in jeder Dia-


grammart, nicht nur im Anwendungsfalldiagramm) mit einem Kommentar zu verse-

hen. Dadurch kann bei der Modellierung eine, auf Text beschränkte, Beschreibung

der Anwendungsfälle erfolgen. Zusätzlich wird die Möglichkeit geboten, UML

Kommentare zu modellieren.

Ein weiterer Vorteil sind die verschiedenen Exportmöglichkeiten, die diese Entwick-

lungsumgebung bietet. Die Diagramme können sowohl als XMI-Datei, wie auch in

verschiedene Bildformate exportiert werden.

Als praktische Anwendung wurde versucht das UML Anwendungsfalldiagramm aus

Kapitel 3 des begleiteten Beispiels zu verfeiern. Das (exportierte) Ergebnis zeigt

Abbildung 24.

Abbildung 24: MyEclispe: Anwendungsfalldiagramm

In Abbildung 24 wurden neben den Beziehungen zwischen Aktoren und Anwen-


dungsfälle die gezeigten Anwendungsfälle mit Hilfe von „extends“ und „include“

Beziehungen verfeinert.

4.2.2 Klassen- und Paketdiagramm

Die Mischung aus Klassen- und Paketdiagrammen lässt sich, wie auch das Anwen-

dungsfalldiagramm einfach modellieren. Im oberen Bereich werden wieder alle gän-

gigen Elemente angeboten.

Als Beispiel wurde das in Kapitel 3.8. Klassendiagramm modelliert. Es zeigt die En-

titäten des begleitenden Beispiels. Das Ergebnis zeigt Abbildung 25.

Abbildung 25: MyEclipse: Klassendiagramm

Die Entwicklungsumgebung „MyEclipse“ bietet eine automatische Codegenerierung


aus diesem Modell an. Nach der Durchführung dieser Codegenerierung wurde der

erzeugte Quelltext näher evaluiert. Der erzeugte Quelltext enthält einige Fehler, die

hier kurz angeführt werden sollen:

• Die standardmäßigen Zugriffsmethoden der privaten Attribute (sogenannte

„Getter-“ und „Setter“-Methoden) werden zwar angelegt, aber nicht ord-

nungsgemäß implementiert. Die Zugriffsmethoden geben immer den Wert

null zurück und die Schreibemethoden werden immer als leere Methoden

generiert.

• Bei den Zugriffsmethoden werden keine generischen Listen implementiert,

was zu einer Warnung des Übersetzers („compiler“) führt.

• Wird als Typ eines Attributs eine Java spezifische Klasse verwendet, so wird

bei diesen Attributen der Name nicht richtig übernommen. So wird zum Bei-

spiel bei der Klasse „Order“ ein Attribute „private Date Order____date;“ an-

gelegt.

• Bei der Auflösung der Beziehungen zwischen den Klassen tritt ein Fehler bei

der Navigation durch die Klassen auf. Dieser Fehler tritt allerdings nur in ei-

nem Fall auf, die anderen Navigationen werden korrekt aufgelöst.

Als weiteres Feature wird von der Entwicklungsumgebung „MyEclipse“ das Reverse

Engineering angeboten. Nach der Realisierung des Java Quelltextes wurde als Er-

gebnis das Diagramm in Abbildung 26 generiert (Ausschnitt).

Wie auf den ersten Blick ersichtlich ist das Ergebnis nicht sehr gut. Die Assoziatio-

nen werden falsch bzw. teilweise (zwischen den Klassen „Order“ und „OrderItem“)

nicht generiert. Auch die Kardinalitäten (z.B. die 1 zu n Beziehung zwischen den

Klassen „Product“ und „Productgroup“) werden nicht übernommen.

Es wird auch keine Möglichkeit angeboten die „getter“- und „setter“-Methoden aus

dem Diagramm auszublenden. Dieses Feature würde die Lesbarkeit des Klassendia-

gramms erhöhen.

Das Zusammenspiel zwischen Klassendiagramm und Quelltext funktioniert nicht.

Das Diagramm und der Quelltext werden nicht automatisch synchronisiert. Wird im


Modell ein Teil geändert, so muss die Klasse neu erstellt werden. Dabei werden

mögliche Änderungen in der Klasse wieder überschrieben.

Auch umgekehrt ist die Synchronisation nicht möglich, wird z.B. ein Attribut im

Quelltext hinzugefügt, so muss es im Modell händisch nachgezogen werden und

wird nicht automatisch übernommen.

Abbildung 26: MyEclipse: Klassendiagramm Reverse Engineering

4.2.3 Sequenz- und Kollaborationsdiagramm

Als Beispiel für ein Sequenz- bzw. Kollaborationsdiagramm wurde versucht der

Anwendungsfall „Add Product“ von einer sehr technischen Sichtweise zu modellie-

ren. Das resultierende Sequenzdiagramm zeigt Abbildung 27.

Das erste Problem wurde beim Anlegen des Objektes „Administrator“ gefunden. So

ist es nicht möglich Stereotypen zu verwenden. Bei der weiteren Vorgehensweise

konnten weitere Einschränkungen und Fehler bei der Modellierung gefunden wer-

den.

Das Diagramm neigt dazu sich in die Länge zu ziehen und es besteht keine Möglich-

keit das Diagramm händisch anzupassen. Wie in Abbildung 27 ersichtlich kann das


Diagramm nur händisch abgeschnitten werden.

Zusammenfassend kann gesagt werden, dass die Darstellung des Sequenzdiagramms

noch sehr fehlerhaft und noch nicht sehr weit fortgeschritten ist.

Abbildung 27: MyEclipse: Sequenzdiagramm

Ähnliche Einschränkungen wurden beim Kollaborationsdiagramm gefunden. Bei

dieser Diagrammart wird die UML Notation nicht eingehalten. Es besteht auch keine

Möglichkeit den Datenfluss mit Hilfe von Pfeilen darzustellen.

Auch das Kollaborationsdiagramm wird den Ansprüchen von UML nicht gerecht.

4.2.4 Weitere Diagrammarten

Neben den oben vorgestellten Diagrammarten bietet der UML Teil der Entwick-

lungsumgebung „MyEclipse“ die Möglichkeit Aktivitäts-, Zustands- und Vertei-


lungsdiagramme zu modellieren.

Alle dieser drei Diagrammarten werden zwar von der Entwicklungsumgebung „My-

Eclipse“ angeboten, jedoch nicht ausreichend unterstützt, wie die folgenden Kapiteln

zeigen sollen.

Aktivitätsdiagramm

Die Aktivitätsdiagramme werden in der Entwicklungsumgebung „MyEclipse“ nicht

ausreichend unterstützt. So ist es nicht möglich einen Aktivitätsbereich darzustellen.

Ein kleines Beispiel soll hier das speichern einer Bestellung gezeigt werden (siehe

Abbildung 28).

Abbildung 28: MyEclipse: Aktivitätsdiagramm

Zusätzlich, zu den in Abbildung 28 gezeigten Notationen, werden mit Verzwei-

gungs- bzw. Verbindungsknoten und den Parallelisierungs- bzw. Synchronisations-

knoten die meist verwendeten Notationen angeboten.

Zustandsdiagramm

Für das Zustandsdiagramm wurde versucht das Beispiel aus dem vorigen Kapitel zu

erstellen. Es handelt sich um das Protokollzustandsdiagramm „Warenkorb“.

Abbildung 29 zeigt das Ergebnis der Modellierung.

Wie aus Abbildung 29 ersichtlich konnte das gewünschte Ergebnis nicht erreicht

werden. Es ist keine Beschriftung bei Änderungen von Zuständen möglich. Dadurch

hat das gezeigte Diagramm wenig Aussagekraft.


Zusätzlich ist zwischen zwei Zustanden nur eine Beziehung in einer Richtung dar-

stellbar. Dadurch ist dieser Teil der Entwicklungsumgebung nicht verwendbar und

noch in der Entwicklungsphase.

Abbildung 29: MyEclipse: Zustandsdiagramm

Verteilungsdiagramm

Mit Hilfe dieser Diagrammart können verteilte Systeme modelliert werden.

Abbildung 30: MyEclipse: Verteilungsdiagramm


Als Beispieldiagramm wurde im Rahmen dieser Diplomarbeit versucht, den klassi-

schen Aufbau einer Enterprise Anwendung zu modellieren.

Wie Abbildung 30 zeigt, ist mit Hilfe dieser Diagrammart eine schöne Übersicht

möglich. Leider werden beim exportieren des Diagramms in eine Bilddatei die Ecken

abgeschnitten.

Diese Modellart kann durchaus vor allem bei komplexeren verteilten Systemen sehr

hilfreich sein.

4.2.5 Zusammenfassung

Zusammengefasst kann gesagt werden, dass der UML Teil von der Entwicklungs-

umgebung „MyEclipse“ nicht zu empfehlen ist, da er noch ziemlich fehlerhaft ist.

Die auf der Internetseite versprochenen Features sehen viel versprechend aus, leider

existieren einige Bugs, die ein Arbeiten mit diesem Tool nicht ermöglichen.

Es soll allerdings nicht unerwähnt bleiben, dass die Entwicklungsumgebung „MyEc-

lipse“ eine große Menge an Plugins inkludiert, die bei der Implementierung einer

Java Enterprise Anwendung sehr hilfreich sind. So werden mit dieser Entwicklungs-

umgebung unter anderem ein JavaScript Debugger, ein XML Editor oder die Unter-

stützung von Webservices mitgeliefert.

4.3 UML Editoren

Als UML Editoren werden hier Plugins verstanden, die keine Möglichkeit der Code-

generierung anbieten, dafür aber eine breite Palette an UML Diagrammen anbieten.

4.3.1 Blueprint Software Modeler

Das Plugin „Blueprint Software Modeler“ setzt sich als Ziel, einen modellgetriebe-

nen Softwareentwicklungsprozess mit Hilfe eines Tools anzubieten. Leider wird die-

ser vollständige Prozess erst in der relativ teuren Professional Edition angeboten.

Die, hier im Rahmen dieser Arbeit evaluierte, freie Version, bietet die Möglichkeit

eine Vielzahl von UML 2.0 Diagrammen zu modellieren. Es wird die Modellierung

von Anwendungsfall-, Klassen-, Paket-, Komponenten-, Kompositionsstruktur-, Ob-

jekt-, Aktivitäts-, Zustands- und Sequenzdiagrammen angeboten. Damit werden die

meist verwendeten Diagrammarten angeboten, die bei der Modellierung einer Enter-


prise Anwendung verwendet werden.

Die Installation dieses Plugins ist sehr einfach, da auf der Internetseite [Blue08] ein

Gesamtpaket zum Download zur Verfügung gestellt wird.

Die Benutzeroberfläche ist zu Beginn etwas gewöhnungsbedürftig, da dieses Plugin

davon ausgeht den ganzen Softwaremodellierungsprozess zu unterstützen.

Um ein einfaches Anwendungsfalldiagramm erstellen zu können muss zunächst ein

ganzes Projekt und ein ganzer Prozess angelegt und beschrieben werden, wie in

Abbildung 31 auf der linken Seite ersichtlich ist.

Abbildung 31: Blueprint Software Modeler: Arbeitsbereich

Anwendungsfalldiagramm

Das Anwendungsfalldiagramm des Plugins „Blueprint Software Modeler“ bietet alle

Notationen, um ein aussagekräftiges Diagramm zeichnen zu können. Leider besteht

keine Möglichkeit das Diagramm als Bild zu exportieren.

Als Beispiel wurde das Anwendungsfalldiagramm aus Sicht des Administrators mo-


delliert. Das Ergebnis zeigt Abbildung 32.

Bei diesem Plugin werden eine Reihe von UML 2.0 (bzw. 2.1) Notationen geboten,

die sonst kein anderes Plugin anbietet. So werden unter anderem für einen Anwen-

dungsfall die Möglichkeit geboten „Constraints“ oder „Extension points“ zu model-

lieren.

Abbildung 32: Blueprint Software Modeler: Anwendungsfalldiagramm

Als weiterer guter Punkt kann zu jedem Element eine Dokumentation verfasst wer-

den. So besteht auch hier die Möglichkeit einen Anwendungsfall zumindest mit Hilfe

von Text im Rahmen des Modells zu beschreiben.

Paket- und Klassendiagramme

Das Plugin „Blueprint Software Modeler“ bietet leider nur die Möglichkeit ein Paket-

oder ein Klassendiagramm zu erstellen. Es besteht keine Möglichkeit diese beiden

Diagrammarten in einem Diagramm darzustellen.

Sehr gut sind die verschiedenen Darstellungsmöglichkeiten der Klassen im Klassen-


diagramm. So kann für jede Klasse einzeln bestimmt werden, welche Methoden an-

gezeigt werden, und welche nicht. Dieses Feature erlaubt es übersichtliche Dia-

gramme zu erzeugen, und zum Beispiel „getter“- und „setter“-Methoden aus dem

Diagramm auszublenden.

Als Beispiel wird hier ein Ausschnitt aus dem Domänenmodell gezeigt. Es zeigt das

Zusammenspiel der Klasse „Product“ und der Klasse „Productgroup“ (siehe

Abbildung 33).

Abbildung 33: Blueprint Software Modeler: Klassendiagramm

Auffallend ist, dass es nur wenige Möglichkeiten gibt, den Typ eines Attributes zu

beschreiben. Die hier angebotenen Typen beschränken sich auf „Integer“, „String“,

„Boolean“ und „UnlimitedNatural“.

Weitere Diagrammarten

Als weitere Diagrammarten werden Aktivitäts-, Zustands-, Sequenz-, Objekt-, Kom-

positionsstruktur- und Komponentendiagramme angeboten.


Im Rahmen dieser Diplomarbeit wird nur das Objektdiagramm näher betrachtet. Das

Anlegen von Werten von Attributen ist relativ kompliziert gelöst. Es muss zu jedem

Attribut ein Element („Slot Value“) angelegt werden, um Werte festzulegen. Dieser

Wert wird allerdings nicht mit dem Diagramm synchronisiert. Daher ist es nicht

möglich auf eine einfache Weise Objektdiagramme zu erstellen. Als Pluspunkt kann

gesagt werden, dass es ein gutes Zusammenspiel mit dem Klassendiagramm gibt. Es

können nur „echte“ Instanzen von Klassen angelegt werden.

Zusammenfassung

Das Plugin „Blueprint Software Modeler“ bietet eine Vielzahl von Diagrammarten

an, die auch im vollsten Umfang unterstützt werden. Der Nachteil ist, dass die Gene-

rierung von Quelltext bei der evaluierten Version nicht implementiert ist. Das Anle-

gen von Diagrammen ist am Anfang etwas gewöhnungsbedürftig, da ein gesamter

Softwareprozess angelegt werden muss. In der Praxis kann sich dies aber durchaus

als Vorteil erweisen.

Dieses Plugin ist gut, da es sich an den UML Standard hält.

4.3.2 Violet UML Editor

Dieser UML Editor ist gratis verfügbar und relativ leicht zu erlernen. Das Tool wird

neben dem Plugin auch als Standalone Programm oder auch als Java Applet angebo-

ten. Für eine erste Evaluierung kann das Tool auch mittels Java Web Start (vgl.

[WebS08]) gestartet werden.

In diesem Tool wird eine Vielzahl von UML Diagrammarten angeboten. Mit Hilfe

dieses Tool können Klassen-, Sequenz-, Zustands-, Objekt- und Anwendungsfalldia-

gramme modelliert werden.

Leider besteht keine Möglichkeit den Quelltext aus den Diagrammen generieren zu

lassen. Beim Projekt „Violet UML Editor“ handelt es sich um ein reines Zeichenpro-

gramm, weshalb auch keine semantische Validierung der Modelle angeboten wird

[Viol08]. Es handelt sich um ein kleines, freies Tool, welches bei zeichnen von UML

Modellen unterstützen soll.

Die aktuellste Version kann nicht in Eclipse inkludiert werden, da sie einige Fehler

aufweist (siehe [Viol08]). Deshalb wird dieses Tool im Rahmen dieser Diplomarbeit


nicht näher in Betracht gezogen, da hier nur Tools evaluiert werden sollen, die sich

in die Entwicklungsumgebung „eclipse“ integrieren lassen.

4.4 Codegeneratoren

Die hier vorgestellten Plugins erlauben die Generierung von Quelltext aus einem

Klassendiagramm bzw. die Generierung von Klassendiagrammen aus bestehenden

Sourcecode.

Beim Plugin „Apollo for Eclipse“ werden Teile des Paketdiagramms im Klassendia-

gramm integriert.

Beim Plugin „GreenUML“ wird nur das Klassendiagramm angeboten, es besteht

keine Möglichkeit Pakete zu modellieren. Dieses Punkt ist sicher als großer Nachteil

zu betrachten, da selbst bei kleineren Projekten eine Unterteilung in Pakete von Vor-

teil sein kann.

4.4.1 Apollo for Eclipse

Das Plugin „Apollo for Eclipse“ bietet eine Mischung aus dem Klassen- und Paket-

diagramm an. Der Preis für dieses Tool beträgt etwa 5 Euro pro Monat (Stand Mai

2008), wählt man eine längere Mitgliedschaft, verringert sich dieser Betrag.

Mit Hilfe dieses Plugins ist sowohl ein Forward Engineering (Automatisches Gene-

rieren von Quelltext aus dem Klassendiagramm), wie auch das Erstellen eines Klas-

sendiagramms aus dem Quelltext (Reverse Engineering) möglich.

Ein weiteres Feature dieses Plugin ist die automatische Synchronisation zwischen

Quelltext und Diagramm. Wird das Diagramm geändert, so wird der Quelltext ange-

passt, wird der Quelltext zum Beispiel um ein Attribut erweitert, wird dieses Attribut

automatisch im Diagramm übernommen.

Forward Engineering

Bei der Erstellung der Klassen mit Hilfe des Klassendiagramms wird die resultieren-

de Java Klasse automatisch angelegt. Das Anlegen von Attributen kann entweder

direkt im Quelltext oder im Klassendiagramm erfolgen.

Dies kann auch ein Nachteil sein, wenn ein Klassendiagramm in einer hohen Abs-


traktionsebene modelliert werden soll und dieses nicht in Quelltext umgesetzt wer-

den soll.

Das heißt dieses Plugin ist sehr praxisnahe und nur für Klassendiagramme geeignet,

die im Rahmen einer logisch, design-orientierte Modellierung (vgl. Kapitel 3.8.2)

erstellt werden sollen.

Mit Hilfe dieses Plugins wurde versucht einen Ausschnitt aus dem Domänenmodell

(die Beziehung zwischen „product“ und „productgroup“) aus dem begleiteten Bei-

spiel mit Hilfe des Klassendiagramms zu modellieren.

Die Arbeitsumgebung ist sehr ansprechend, wie die Abbildung 34 zeigen soll.

Wie man in Abbildung 34 sehen kann, werden alle notwendigen Elemente im rechten

Bereich des Bildschirmes angeboten. Mit Hilfe dieser Elemente können unter ande-

rem Pakete, Klassen, Interfaces aber auch Attribute oder Operationen angelegt wer-

den.

Abbildung 34: Apollo for eclipse: Arbeitsumgebung


Besonders hervorzuheben ist das Anlegen eines Attributes. Dieser Schritt erfolgt mit

Hilfe von Java Quelltext. Der gleiche Mechanismus wird beim Anlegen von Metho-

den verwendet. Das heißt Methoden können direkt beim Anlegen implementiert oder

zumindest kommentiert werden.

Diese Vorgehensweise erlaubt eine sehr praxisnahe Modellierung und Implementie-

rung, da diese zwei Schritte relativ einfach zu einem Schritt zusammengefasst wer-

den. Den Aufbau dieses Features soll Abbildung 35 zeigen.

Abbildung 35: Apollo for eclipse: Klassendiagramm

Reverse Engineering

Im Rahmen des Reverse Engineering wurde versucht aus dem implementieren Klas-

sen des Domänenmodells ein Klassendiagramm zu erstellen.

Die Vorgehensweise ist sehr einfach, nachdem die Klassen in den Arbeitsbereich

importiert wurden, müssen die implementierten Klassen via Drag and Drop zum

Diagramm hinzugefügt werden.

Wie in Abbildung 36 zu sehen werden alle Assoziationen korrekt dargestellt und


gefunden. Es werden auch alle Methoden und Attribute richtig interpretiert.

Der einzige kleine Nachteil ist, dass die Zugriffsmethoden („getter“ und „setter“-

Methoden) nicht ausgeblendet werden können.

Das exportierte Ergebnis zeigt Abbildung 36.

Abbildung 36: Apollo for eclipse: Klassendiagramm

Zusammenfassung

Das Plugin „Apollo for Eclipse“ kann eine große Hilfe in der Entwicklung darstellen.

Leider wird nur eine Mischung aus Klassen- und Paketdiagramm angeboten, dafür ist

die Qualität beachtlich.


4.4.2 GreenUML

Das freie Plugin „GreenUML“ unterstützt sowohl das Forward Engineering, wie

auch das Reverse Engineering. Dieses Plugin wurde von der Universität Buffalo

entwickelt, um Studenten eine pädagogische Sicht auf das Design zu geben [Gree08].

Leider kann keine Einteilung in Paketen vorgenommen werden. Dieses Plugin er-

laubt nur die Modellierung von Klassen in einem Paket. Es können keine Paketüber-

greifende Klassen graphisch dargestellt werden. Allerdings werden die Namen der

Klassen um den Namen des Pakets erweitert.

Forward Engineering

Das Forward Engineering funktioniert sehr intuitiv und einfach. Es wurde wieder

versucht einen Ausschnitt aus dem begleiteten Domänenmodell zu modellieren. Eine

Ansicht auf die Benutzeroberfläche zeigt Abbildung 37. Die angebotenen Elemente

werden auf der linken Seite des Arbeitsbereichs angezeigt.

Abbildung 37: GreenUML: Benutzeransicht

Wird eine Klasse im Klassendiagramm angelegt, so wird diese Klasse im gleichen

Schritt auch im Quelltext angelegt. Diese Vorgehensweise bringt die gleichen Vortei-


le wie, die im vorherigen Kapitel beschriebenen mit sich.

Reverse Engineering

Wie oben beschrieben bezieht sich ein Klassendiagramm auf ein Paket. Im Rahmen

des Reverse Engineering wird das fertige Klassendiagramm sofort mit den vorhan-

denen Klassen erstellt. Leider werden dabei die Assoziationen zwischen den Klassen

nicht erkannt. Das Ergebnis des Reverse Engineering zeigt Abbildung 38.

Abbildung 38: GreenUML: Reverse Engineering

Zusammenfassung

Das Plugin „GreenUML“ erlaubt ein einfaches Anlegen von Klassendiagrammen,

wobei der Quelltext im gleichen Schritt erstellt wird. Bei Reverse Engineering sind

noch etliche Probleme vorhanden.

Ein großer Nachteil ist, dass mit Hilfe des Klassendiagramms keine Pakete erstellt

werden können, deshalb kann dieses Plugin bei größeren Projekten leider nur bedingt

eingesetzt werden, was auch nie Ziel dieses Plugins sein sollte.


4.5 Erweiterte Codegeneratoren

Als erweiterte Codegeneratoren werden hier Tools bzw. Plugins beschrieben, die

neben der Möglichkeit Quelltext aus einem Klassendiagramm zu generieren, auch

eine weitere UML Diagrammart unterstützen.

Beim Plugin „eUML Modeler“ wird zusätzlich das Sequenzdiagramm angeboten, das

Plugin „AmaterasUML“ bietet unter anderem ein Sequenzdiagramm wie auch ein

Anwendungsfalldiagramm an, und das Plugin „Slime UML“ bietet ausschließlich ein

Anwendungsfalldiagramm an.

4.5.1 eUML2 Modeler

Das Eclipse Plugin „eUML Modeler“ bietet die Modellierung aus einer Mischung aus

dem Klassen- und Paketdiagramms den Quellcode automatisch erstellen zu lassen.

Zusätzlich ermöglicht die kostenpflichtige Version dieses Plugin Quellcode aus Se-

quenzdiagrammen zu erstellen.

Klassendiagramm

Dieses Plugin erstellt den Quellcode sofort im Modellierungsprozess aus dem model-

lierten Klassendiagramm. Dabei werden die Eclipse Standard Dialoge zum Erstellen

der Klassen verwendet.

Diese erstellten Klassen werden in einem anderen Fenster graphisch dargestellt, wie

Abbildung 39 demonstrieren soll. Der Vorteil bei dieser Vorgehensweise ist, dass das

Diagramm und der Quelltext synchron bleiben.

Der Nachteil ist, wenn man in einer frühen Phase des Projekts ein Klassendiagramm

entwerfen will, wird automatisch der Quelltext erstellt, obwohl das möglicherweise

nicht erwünscht ist. Das heißt diese Vorgehensweise ist nur für eine logische, design-

orientierte Modellierung, nicht aber für eine konzeptuell-analytische Modellierung

gedacht.

Bei der Erstellung eines Attributes in der Klasse werden automatisch Zugriffsmetho-

den („getter“- und „setter“-Methoden) erstellt. Zusätzlich werden einige (konfigu-

rierbare) Kommentare erstellt, wie Listing 2 zeigen soll.


Abbildung 39: eUML: Benutzeroberfläche

Listing 2 zeigt einen Ausschnitt aus dem generierten Code der Klasse „Product“:

public class Product {

/**

* @uml.property name="id"

*/

private Long id;

/**

* @return Returns the id.


*/

public Long getId() {

return id;

}

/**

* @param id The id to set.


*/

public void setId(Long id) {

this.id = id;

}

}

Listing 2: Source Code „Product“ (Auszugsweise)


Besonders bemerkenswert ist das Erstellen von Assoziationen zwischen den Klassen,

wie die Abbildung 40 darstellen soll. Mit Hilfe dieses Dialogs können alle möglichen

Formen der Assoziation dargestellt werden.

Abbildung 40: eUML: Erstellen einer Assoziation

Ein kleiner Nachteil beim Erstellen von Assoziationen ist, dass beim Auflösen einer

1 zu n Beziehung zwar der Typ der Liste angegeben werden kann, aber nicht die ge-


nerische Implementierung der Liste. Dieser fehlende Punkt führt seit der Einführung

von Generics in Java (seit Version 1.5) zu einer Warnung im Übersetzer („compi-

ler“).

Das Zusammenspiel zwischen Quelltext und Modell funktioniert einwandfrei. Wird

im Quellcode etwas geändert, so wird auch das Modell automatisch angepasst.

Dieses Plugin bietet die Möglichkeit an, ein Diagramm als Bild zu exportieren. Das

Ergebnis zeigt Abbildung 41.

Abbildung 41: eUML: Klassendiagramm

Wie in Abbildung 41 ersichtlich wird als Darstellungsform bei den Attributen keine

gängige UML Notation verwendet, sondern es wird auf die Eclipse interne Darstel-

lungsform zurückgegriffen. Das hat den Nachteil, dass Entwickler, die mit dieser

Notation nicht vertraut sind, die Diagramme nicht auf Anhieb lesen können.


Sequenzdiagramm

Bei der kostenpflichtigen Version besteht die Möglichkeit ein Sequenzdiagramm aus

dem Quelltext erstellen zu lassen. Die hier evaluierte Free Edition erlaubt nur das

händische Zeichnen von UML Diagrammen.

Dabei wird von einer sehr praxisnahen Modellierung ausgegangen. Im oberen Be-

reich der Ansicht (siehe Abbildung 42) wird das UML Diagramm gezeigt, im unteren

Bereich wird der Java Quelltext angezeigt. Auch hier werden, wenn es zu einem Me-

thodenaufruf kommt diese gleich im Quelltext generiert.

Abbildung 42: eUML: Sequenzdiagramm

Das Erzeugen eines Sequenzdiagramms ist also sehr praxisnahe und der Quelltext

wird im gleichen Schritt erstellt.

Zusammenfassung

Das Plugin „eUML Modeler“ bietet mit der gleichzeitigen Modellierung und Quell-


textgenerierung eine gute Möglichkeit für eine modellgetriebene Softwareentwick-

lung. Der Nachteil ist sicher, dass dieses Feature nicht immer gewünscht ist, wenn

man z.B. ein Sequenzdiagramm zur Übersicht erstellen will, was aber nicht in Quell-

text wiedergegeben werden soll.

Zusammengefasst kann gesagt werden, dass dieses Plugin gut ist, aber es ist die

Verwendung eines weiteren Tools notwendig, da erstens nicht alle Klassen- und Se-

quenzdiagramme abgebildet werden können und nur die Möglichkeit besteht ein Se-

quenz- bzw. ein Paket-/Klassendiagramm zu erstellen. Auch die verwendetet Notati-

on ist nicht zu 100% mit der UML Notation gleich. Der Vorteil liegt sicher an der

Praxisnähe. Es kann gleichzeitig mit der Implementierung ein brauchbares Dia-

gramm z.B. für Dokumentationszwecke erstellt werden.

4.5.2 AmaterasUML

Dieses Plugin unterstützt das Zeichnen von Klassen-, Sequenz- und Anwendungs-

falldiagrammen. Außerdem erlaubt das Plugin eine Codegenerierung aus Klassen-

diagrammen und auch ein Reverse Engineering. Leider wird von diesem Plugin nur

das Klassendiagramm unterstützt und keine Möglichkeit geboten die erstellten Klas-

sen in Pakete einzuteilen.

Die Installation dieses Plugins ist etwas komplizierter als bei den bisher evaluierten

Plugins. Es wird kein Gesamtpaket angeboten und auch eine Installation über den in

der Entwicklungsumgebung „eclipse“ integrierten Updatemanager ist nicht vorgese-

hen. Das heißt die Installation dieses Plugin muss manuell vorgenommen werden.


Das Plugin „AmaterasUML“ bietet eine einfache und schnelle Möglichkeit ein An-

wendungsfalldiagramm mit allen Standardnotationen zu erstellen.

Das erstellte Anwendungsfalldiagramm kann als Bilddatei exportiert werden. Als

Beispiel wurde hier das Anwendungsfalldiagramm in der höchsten Abstraktionsebe-

ne modelliert. Das exportierte Bild zeigt Abbildung 43.


Abbildung 43: AmaterasUML: Anwendungsfalldiagramm

Klassendiagramm

Der Klassendiagrammeditor schaut sehr intuitiv und einfach aus, wie Abbildung 44

zeigen soll. Für diese Evaluierung wurde wieder versucht ein Ausschnitt aus dem

Domänenmodell zu erstellen. Es wurde wieder die beiden Klassen „product“ und

„productgroup“ ausgewählt.

Abbildung 44: AmaterasUML: Ansicht Klassendiagramm

Leider fehlt dabei die Möglichkeit das Klassendiagramm in Pakete einzuteilen.


Die Generierung von Quellcode ist relativ einfach möglich. Leider werden die Asso-

ziationen nicht aufgelöst. Bei der Modellierung fehlt auch die Möglichkeit der Navi-

gierung durch die Klassen anzugeben. Auch die Synchronisation zwischen Modell

und Quelltext fehlt, das heißt der Quelltext bzw. das Modell müssten händisch ange-

passt werden.

Bei Reverse Engineering können Klassen nur einzeln eingefügt werden, und nicht

ganze Packages, was zur Folge hat, das keine Assoziationen erkannt werden.

Sequenzdiagramm

Mit dem Eclipse Plugin lassen sich relativ einfach kleine Sequenzdiagramme erstel-

len. Leider fehlen einige Notationen wie z.B. das Löschsymbol. Das heißt mit diesem

Tool können nur sehr einfache Sequenzdiagramme erstellt werden, wie Abbildung 45

zeigen soll.

Abbildung 45: AmaterasUML: Sequenzdiagramm

Eine automatische Codegenerierung aus dem Sequenzdiagramm ist nicht vorgesehen.

Weitere Diagramme

Als weiteres Diagramm wird das Aktivitätsdiagramm angeboten. Diese Diagrammart

wird im Rahmen dieser Diplomarbeit nicht näher evaluiert.


Zusammenfassung

Beim Plugin „AmaterasUML“ funktioniert beim Anwendungsfalldiagramm die Ex-

portfunktion nicht zu 100%. Das Klassendiagramm schaut zwar nett aus, es fehlen

allerdings grundlegende Features, wie Pakete oder die Auflösung von Assoziationen.

Auch das Modellieren von einfachen Sequenzdiagrammen ist mit Hilfe dieses Tools

möglich, allerdings fehlen auch hier einige Notationen.

4.5.3 SlimeUML

Dieses Plugin bietet eine einfache und schnelle Installation über den Eclipse Update

Manager an. Es wird das Anwendungsfalldiagramm und eine Mischung aus dem

Klassen- bzw. Paketdiagramm angeboten.

Der Quellcode kann automatisch aus dem Klassendiagramm erstellt werden und es

wird auch die Möglichkeit des Reverse Engineering angeboten.


Das Anwendungsfalldiagramm bietet alle verwendeten Notationen. Leider wird das

exportieren der Diagramme in ein Bild nicht unterstützt.

Abbildung 46: SlimeUML: Anwendungsfalldiagramm


Als kleines Beispiel wurde wieder versucht das Anwendungsfalldiagramm in einer

hohen Abstraktionsebene zu modellieren. Besonders bemerkenswert ist die Möglich-

keit, dass Diagramme mit Hilfe dieses Plugins gezoomt werden können. So ist es

auch möglich große Diagramme übersichtlich anzuzeigen.

Auffallend ist auch, dass keine Trennung zwischen Klassen- und Anwendungsfall-

diagramm gemacht wird. Es gibt nur eine Diagrammart und man kann alle Elemente

von beiden Diagrammen verwenden.

Klassendiagramm

Bei der normalen Modellierung eines Klassendiagramms konnten keine Attribute

hinzugefügt werden. Die Dokumentation ist in dieser Beziehung auch mehr als spär-

lich, hier wird nur die Anleitung gegeben, wie das Reverse Engineering funktioniert.

Es ist leider nur eine Dokumentation einer alten Version verfügbar.

Beim Reverse Engineering werden Assoziationen nicht erkannt und müssten hän-

disch nachgezogen werden. Wird allerdings ein Attribut im Quellcode geändert, so

wird diese Änderung automatisch ins Klassendiagramm übernommen.

Zusammenfassung

Beim Plugin „SlimeUML“ ist nur das Anwendungsfalldiagramm zu verwenden. Das

Klassendiagramm kann in dieser Form nicht verwendet werden.

Kapitel 5

Zusammenfassung und Ausblick

In diesem Kapitel werden die Erkenntnisse zusammengefasst und ein Ausblick auf

weitere Tools gegeben.

5.1 Zusammenfassung

Zusammengefasst kann gesagt werden, dass zwar UML 2.0 und Java Enterprise An-

wendungen hervorragend zusammenspielen, sich allerdings die kostengünstige Tool-

unterstützung noch in der Entwicklungsphase befindet. Nichts desto trotz sollen hier

einige evaluierte Plugins erwähnt werden.

Der UML Teil der Entwicklungsumgebung „MyEclipse“ ist noch nicht sehr ausge-

reift, allerdings bietet diese Entwicklungsumgebung eine Vielzahl an anderen Plug-

ins an, die für die Java Enterprise Entwicklung hilfreich sein können. Diese Entwick-

lungsplattform wird laufend weiterentwickelt, daher ist es nur eine Frage der Zeit, bis

auch das UML Plugin den Ansprüchen gerecht wird.

Als reiner UML Editor ist das Plugin „Blueprint Software Modeler“ am besten ge-

eignet. Leider bietet dieses Plugin in der freien Version keine Möglichkeit Quelltext

automatisch zu erzeugen.

Bei der Codegenerierung schneiden die Plugins „Apollo for Eclipse“ und „eUML

Modeler“ am besten ab. Mit Hilfe dieser Plugins wird das Klassendiagramm gleich-

zeitig mit dem Quelltext erstellt. Auch das Plugin „GreenUML“ bietet das gleiche

Feature, allerdings keine Möglichkeit Klassendiagramme in Pakete aufzuteilen.

Zusammenfassung und Ausblick Seite 96

5.2 Ausblick

Es existieren eine Vielzahl von Produkten und Plugins, die sich mit der Generierung

von Code aus den Diagrammen (MDA - Model Driven Architecture - vgl.

[OMG07b]) auseinandersetzen. Einige dieser, meist kostspieligen, Plugins sollen im

Rahmen dieser Arbeit nicht unerwähnt bleiben:

- IBM Rational [IBM08]: Ein Teil der IBM Rational Produktpalette ist der

„Rational Software Architekt“. Mit Hilfe dieses umfassenden Produktes kön-

nen sowohl standardisierte UML Diagramme, wie auch implementierungsna-

he Diagramme erstellt werden. Die erstellten Diagramme können mittels ma-

nuell zu beschreibenden Konverter in Java umgewandelt werden. Mit Hilfe

dieses Tools ist auch ein einfaches und umfassendes Reverse Engineering

möglich. So kann man mit Hilfe dieses Tools unter anderem Sequenzdia-

gramme aus dem Quelltext (via Drag und Drop) erstellen.

- Omondo [Omon08]: Das Plugin „EclipseUML 2008 Studio“ bietet alle 13

Diagrammarten von UML 2.0 an. Dabei werden die definierten Standards

verwendet. Mit Hilfe dieses Plugins wird sowohl ein Forward Engineering

wie auch das Backward Engineering von Anwendungen unterstützt.

Zusammengefasst muss gesagt werden, dass in allen Fällen die kostengünstige Alter-

native meist nicht die bessere Variante darstellt.

Literaturverzeichnis Seite 97

Literaturverzeichnis

[Ahme02] K. Ahmed, C. Umrysh; Developing Enterprise Java Applications with J2EE and UML, Addison-Wesley, Indianapolis, 2002

[Amat08] AmaterasUML, http://amateras.sourceforge.jp [14.6.2008]

[Apol08] Apollo for eclipse, http://www.gentleware.com/apollo.html [14.6.2008]

[Blue08] Blueprint Software Modeler, http://www.atportunity.com/blueprintsm.php [14.6.2008]

[Burn06] E. Burnette; Eclipse IDE kurz & gut, O’Reillys Taschenbibliothek, 2006

[Busc96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal; Pattern-oriented Software Architecture. A System of Patterns, Wiley, Chichester (England), 1996

[Ecli08] Eclipse - an open development platform, http://www.eclipse.org [4.6.2008]

[Ecli08a] Eclipse plugin central (EPIC), http://www.eclipseplugincentral.com [5.6.2008]

[eUML08] Soyatec - eUML2, http://www.soyatec.com/euml2 [14.6.2008]

[Gamm95] E. Gamma, R. Helm, R. E. Johnson; Desgin Patterns. Elements of Reusable Object-Oriented Software, Addison-Wesley, Amsterdam, 1995

[gree08] green, http://green.sourceforge.net [14.06.2008]

[Hitz05] M. Hitz, G. Kappel, E. Kapsammer, W. Retschitzegger; UML@work - Objektorientierte Modellierung mit UML 2, 3. Auflage, dpunkt, Heidelberg, 2005

[IBM08] IBM, Rational Software, http://www-01.ibm.com/software/rational [3.10.2008]

[Jend06] E. Jendrock, J. Ball, D. Carson, I. Evans, S. Fordin, K. Haase; The Java EE 5 Tutorial - For Sun Java System Application Server Platform Edition 9, Third Edition, Addison-Wesley, USA, 2006


[Lang06] T. Langner, D. Reiberg; J2EE und JBoss - Verteilte Enterprise Anwendungen auf der Basis von J2EE, JBoss & Eclipse, Hanser, München, 2006

[Mari02] F. Marinescu; EJB Design Patterns - Advanced Patterns, Processes and Idioms, Wiley, New York, 2002

[Möss05] H. Mössenböck; Sprechen Sie Java?, dpunkt, Musterlösungen, 2005, http://www.ssw.uni-linz.ac.at/Misc/JavaBuch/Muster [5.6.2008]

[Myec08] My eclipse - Infinite Possibilities, http://www.myeclipseide.com [14.6.2008]

[Nass73] I. Nassi, B. Shneiderman; Flowchart techniques for structured programming, State University of New York, 1973

[OMG07] The Object Management Group (OMG), Unified Modeling Language (UML), http://www.omg.org/spec/UML/2.1.2 [4.6.2008]

[OMG08] The Object Management Group (OMG), http://www.omg.org [4.6.2008]

[OMG08a] The Object Management Group (OMG), CORBA Basiscs, http://www.omg.org/gettingstarted/corbafaq.htm [2.10.2008]

[OMG08b] The Object Management Group (OMG), Model Driven Architecture, http://www.omg.org/mda [4.10.2008]

[Omon08] Omondo - The live UML company, EclipseUML, http://www.uml2.org [3.10.2008]

[Reic06] M. Reichold; Evaluierung des UML Modellierungswerkzeuges StarUML, Magisterarbeit, TU Wien, Oktober 2006

[Rupp05] C. Rupp, J. Hahn, S. Queins, M. Jeckle, B. Zengler; UML 2 glasklar - Praxiswissen für die UML-Modellierung und Zertifizierung, Hanser, München, 2005

[Schä02] R. Schätzle, T. Seifert, J. Kleine-Gung; Enterprise JavaBeans - Kritische Betrachtungen zu einer modernen Software-Architektur, Wirtschaftsinformatik 44, 2002, S. 217 - 224

[Schr02] D. Schramm; Eclipse - Die Entwicklungsumgebung für Java und andere Sprachen, Seminararbeit, FH Wedel, 2002, http://www.fh-wedel.de/~si/seminare/ws02/Ausarbeitung/7.eclipse/eclipse0.htm [5.6.2008]

[slim08] Slime UML - the lean and mean modeling tool, http://www.slimeuml.de [14.6.2008]

[Soko07] C.Sokop; Java Enterprise Anwendungen und UML 2.0 - ein starkes Team?, Diplomarbeit (Wirtschaftsinformatik), TU Wien, 2007


[Soph05] Sophist Group; Vergleich von Nassi-Shneidermann-Struktogrammen und Aktivitätsdiagrammen, http://www.uml-glasklar.com; Link 13-1 [4.6.2008]

[Star05] T. Stark; J2EE - Einstieg für Anspruchsvolle, Addison-Wesley, München 2005

[Star08] StarUML, The Open Source UML/MDA Platform, http://staruml.sourceforge.net/en [4.6.2008]

[Sun08] Sun Microsystems, Core J2EE Patterns: Patterns index page, http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html [4.6.2008]

[Tilm05] W. Tilman; Architektur und Konzepte von Eclipse 3, Seminararbeit, Freie Universität Berlin, WS 2004/05, 2005

[Viol08] Violet UML Editor, http://alexdp.free.fr/violetumleditor/page.php [14.6.2008]

[WebS08] Java SE Desktop Technologies, Java Web Start Technology, http://java.sun.com/products/javawebstart/ [5.6.2008]

[Zuse01] W. Zuser, S. Biffl, T. Grechenig, M. Köhle; Software-Engineering mit UML und dem Unified Process, Pearson Studium, 2001

Documents

Softwareentwicklung mit UML und Eclipse · TU Wien Business Informatics Group Institut für Softwaretechnik und Interaktive Systeme Softwareentwicklung mit UML und Eclipse Diplomarbeit