paper - Business Informatics Group

Transcrição

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 fremde Hilfe verfasst, andere als die angegebenen Quellen nicht benützt und die den benutzten 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 Eltern, Eva und Alfred Sokop, die mich zuerst finanziell und in weiterer Folge emotional 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 bedanken.
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, werden 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 hervorragend solche Systeme zu entwickeln. Dieses Thema wurde ausführlich in [Soko07]
behandelt.
Als weiteres Hilfsmittel wird heutzutage in jedem Projekt eine Entwicklungsumgebung 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 Pluginmanagement leicht erweiterbar ist.
Diese Arbeit evaluiert Projekte bzw. Plugins für die Entwicklungsumgebung „eclipse“, die UML 2.0 unterstützen und dadurch bei der Entwicklung behilflich sind.
Weiters soll diese Arbeit evaluieren, inwieweit die getesteten Plugins eine automatisierte Codegenerierung erlauben. Dies soll anhand einer kleinen Beispielanwendung
demonstriert werden.
Ein weiteres Ziel dieser Arbeit ist es kostengünstige Alternativen zu den Entwicklungsumgebungen 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 Arbeit 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 werden den heutigen Ansprüchen gerecht.
Als weiteres Hilfsmittel wird heutzutage in jedem Projekt eine Entwicklungsumgebung 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 hervorragend solche Systeme zu entwickeln. Dieses Thema wurde ausführlich in [Soko07]
behandelt.
Die aktuelle Marktlage zeigt, dass einige Tools angeboten werden, die bei der Modellierung 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 „eclipse“ 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 Entwicklungsumgebung.
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 Zeitund Ressourcenaufwand verbunden.
Als unterstützendes „Werkzeug“, um dieses Szenario zu vermeiden, dient die objektorientierte Modellierungssprache UML. Sie bietet Diagramme um Softwaresysteme
zu modellieren.
Die Entwicklungsumgebung hat, unter anderem, die Aufgabe diese beiden Technologien 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 Diagramm (z.B. Klassendiagramm) angepasst werden. Anzustreben im Sinne der effektiven und modellgetriebenen Entwicklung ist eine Änderung an einer Stelle im Projekt. 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
1.3
Seite 12
Ziel der Arbeit
Ziel dieser Arbeit ist die Evaluierung von Projekten bzw. Plugins für die Entwicklungsumgebung „eclipse“, die UML 2.0 unterstützen und sich in die Entwicklungsumgebung integrieren lassen und dadurch bei der Entwicklung behilflich sind.
Weiters soll diese Arbeit evaluieren, inwieweit die getesteten Plugins eine automatisierte Codegenerierung erlauben. Dies soll anhand einer kleinen Beispielanwendung
demonstriert werden.
Ein weiteres Ziel dieser Arbeit ist es kostengünstige Alternativen zu den Entwicklungsumgebungen 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-, Sequenzund Anwendungsfalldiagramm und die Möglichkeit der Codegenerierung
bzw. Reverse Engineering aus dem Klassendiagramm.
• Blueprint Software Modeler [Blue08]: Diese auf „eclispe“ basierende Entwicklungsumgebung bietet mit dem Klassen-, Paket-, Komponenten-, Kompositionsstruktur-, Objekt-, Anwendungsfall-, Aktivitäts-, Zustands- und Sequenzdiagramm die wichtigsten Diagrammarten an.
• eUML [eUML08]: Dieses Plugin bietet Klassen-, Paket- und Sequenzdiagramme und die Möglichkeit der Codegenerierung aus Klassendiagrammen
an.
• green [gree08]: Dieses Plugin bietet nur das Klassendiagramm und eine automatisierte 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 eine große Hilfe darstellen. Das integrierte UML Plugin unterstützt das Anwendungsfall-, Klassen-, Sequenz-, Kollaborations-, Zustands-, Aktivitätsund Verteilungsdiagramm.
• Slime UML [slim08]: Dieses Plugin bietet eine volle Unterstützung von Klassen-, 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-, Klassen-, Aktivitäts-, Sequenz-, Zustands- und Objektdiagramm an. Die Codegenerierung wird bei diesem Plugin nicht unterstützt.
Die Arbeit verfolgt zwei Ziele. Einerseits soll ein Überblick über die Einsatzmöglichkeiten von UML 2.0 in Java Enterprise Anwendungen gegeben werden. Andererseits sollen die oben genannten Plugins vorgestellt werden. Dazu werden die Diagramme 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 „verbreitete 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, welches 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 Softwareentwicklungsprozess hinweg verwendet werden. Dadurch ist UML unabhängig von Vorgehensmodellen für die Softwareentwicklung und hat auch nicht das Ziel ein eigenes,
neues Vorgehensmodell zu definieren. Weiters soll UML unabhängig von Entwicklungswerkzeugen und Programmiersprachen, sowie mit verschiedensten Anwendungsbereichen 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 Strukturdiagrammen unterschieden werden. Mit Verhaltensdiagrammen wird, wie der Name
schon sagt, das Verhalten eines Systems modelliert. Mit Verhaltensdiagrammen werden die dynamischen Aspekte eines Systems beschrieben. Mit Hilfe von Strukturdiagrammen werden die statischen und strukturellen Aspekte eines Systems modelliert
[Hitz05].
Zu den Strukturdiagrammen zählen in UML 2.0 Klassen-, Objekt-, Paket-, Kompositionsstruktur-, Komponenten- und Verteilungsdiagramme. Bei Verhaltensdiagrammen wird zwischen Anwendungsfall-, Aktivitäts-, Zustands- und Interaktionsdiagrammen unterschieden. Interaktionsdiagramme werden noch in Sequenz-, Kommunikations-, Zeit- und Interaktionsübersichtsdiagramme eingeteilt.
Technologien
Seite 16
Die Grenze zwischen den Diagrammen ist fließend. So ist es z.B. möglich Teile eines 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 beschrieben. Ein Anwendungsfall ist eine „abgeschlossene, zusammenhängende 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 Abfolge von Aktivitäten, die im System passieren.
Technologien
Seite 17
• Zustandsdiagramm: Beim Zustandsdiagramm werden Zustände und Übergä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 Interaktionsdiagrammen [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 (Echtzeitsysteme) [Hitz05].
• Interaktionsübersichtsdiagramm: Das Interaktionsübersichtsdiagramm ist eine 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.
Technologien
Seite 18
Strukturdiagramme in UML 2.0
Folgende Diagrammarten werden in UML 2.0 der Strukturmodellierung zugeordnet:
•
Klassendiagramm: Das Klassendiagramm beschreibt die strukturellen Aspekte des zu entwickelten Systems in Form von Klassen und Schnittstellen
(Interfaces). Außerdem werden Beziehungen zwischen Klassen und Interfaces modelliert [Hitz05]. Ein Klassendiagramm kann stark durch seine Abstraktionsebene unterschieden werden. So ist es möglich einen groben Überblick ü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 strukturiert?“ [Rupp05] beantworten.
•
Paketdiagramm: Das Paketdiagramm dient zur strukturellen Darstellung des
Systems. Auch bei diesem Diagramm können verschiedene Abstraktionsebenen 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 ähnlich 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. exemplarischen 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 Konfigurationsdatei sein. Es soll die Frage „Wie ist mein System strukturiert und wie
Technologien
Seite 19
werden diese Strukturen erzeugt?“ [Rupp05] beantworten.
•
Verteilungsdiagramm: Mit dem Verteilungsdiagramm kann die eingesetzte
Hardwaretopologie und das zugeordnete Laufzeitsystem, sowie eine Verteilung 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 Anwendungen handelt, die mit der Java Enterprise Edition (Java EE) implementiert
sind. Java EE könnte man in einem Satz als das „am weitesten verbreitete ‚Betriebssystem’ 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 ihrem Buch [Gamm95] 23 verschiedene Patterns vorstellt. Eines der bekanntesten
Entwurfspatterns ist das so genannte Model-View-Controller (MVC) Pattern, welches 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 4Tier-Architecture (4-Schichten-Architektur). Laut [Lang06] gilt die 4-SchichtenArchitektur seit dem Internet Boom Mitte der 90er Jahre als „State-of-the-art-
Technologien
Seite 20
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 Benutzers entgegen und gibt diese an die nächste Schicht weiter. Nach der Verarbeitung 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-
Technologien
Seite 21
schäftslogik benötigt werden, geholt.
Der Vorteil bei einer mehrstufigen Schichten Architektur liegt vor allen an der Skalierbarkeit 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 Architekturen 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 Internetseite befinden sich auch ausführliche Erklärungen der verschiedenen Patterns.
Im Rahmen der vorliegenden Arbeit soll, mit dem DAO-Pattern („Data Access Object“ - Datenzugriffsobjekt), ein weiteres Grundkonzept einer Enterprise Anwendung
beschrieben werden. Dieses Pattern wird in weiterer Folge in Form von UML Diagrammen 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 Datenbestand beinhaltet. Die Implementierung dieses Interfaces kann auf verschiedene Arten
erfolgen. Der Zugriff auf die Daten kann z.B. mittels Datenbankabfragen implementiert 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.
Technologien
Seite 22
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 Spezifikation 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 Seiten.
Einen kurzen Einblick über Java EE Architektur soll die Einteilung der Kapitel zeigen [Jend06]:
•
Web-tier Technologien: Dieser Teilbereich der Java Enterprise Edition umfasst 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 Basistechnologien, wie Session beans und Message-driven beans.
•
Persistenz Technologien: Diese Kapiteln beschäftigen sich mit dem Datenbankzugriff 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 Sicherheit einer Java Enterprise Anwendung beschrieben.
Technologien
Seite 23
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 Anwendungsserver von Bea (Bea Weblogic3) und IBM (IBM Websphere4). Es existieren allerdings 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 Schnittstellen 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 Anforderungen, 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
Technologien
Seite 24
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 einen Standard gibt, in der Praxis dieser Standard allerdings (leider) von jedem Anwendungsserver 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“) Komponente. 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 Entwicklungsumgebung 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 Entwicklungsplattform von einer unabhängigen Organisation geführt, der „Eclipse
Foundation“.
5
IDE = engl. Integrated development environment
Seite 25
Technologien
2.3.2 Arbeitsweise
Seit der Version 3.0 sind Erweiterungen (so genannten Plugins) die Basis von „eclipse“. Das heißt, wenn das Standardpaket („eclipse standard development kit“) von
der Webseite [Ecli08] heruntergeladen wird, hat man nur den Kern der Entwicklungsumgebung mit den beiden vorinstallierten Plugins „Java Development Tooling“
(JDT) und „Plugin Developer Environment“ (PDE) [Tilm05]. Das Plugin „Java Development 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 verstanden. 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) erweiterbare Hilfefunktion für Plugins.
Technologien
•
Seite 26
Version and Configuration Management (VCM): Die Entwicklungsumgebung „eclipse“ stellt standardmäßig ein Versionierungssystem zur Verfügung. Dieses erlaubt dem Benutzer ein Einfaches einbinden von neuen Plugins 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 Entwicklungsumgebung „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 Ressourcen 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 bereitgestellt. Alle offiziellen Eclipse Plugins sind auf einer Internetseite [Ecli08a] aufgelistet. Mit Stand Ende Mai 2008 werden 1068 verschiedene Plugins zu den verschiedensten Themengebieten angeboten.
Technologien
2.4
Seite 27
Begleitendes Beispiel
Als begeleitendes Beispiel wurde ein kleines Shopsystem implementiert. Dieses System wurde mit Hilfe von EJB 3.0 entwickelt. Als Datenbank dient eine MySql6 Datenbank 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 anzulegen, zu löschen und zu ändern. Ein Produkt wird einer Produktgruppe zugeordnet.
•
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 weiterer 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 Enterprise 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 Vordergrund [Hitz05]. Verhaltensmodelle können in jeder Phase des Projektes zum Einsatz
kommen. Zur Verhaltensmodellierung zählen Anwendungsfall-, Aktivitäts-, Zustands-, Sequenz-, Kommunikations-, Zeit- und Interaktionsübersichtsdiagramme.
Die Unterkaptitel 3.8 bis 3.13 beziehen sich auf die strukturelle Modellierung. Strukturdiagramme beschreiben - wie der Name schon sagt - die Struktur eines Systems.
Strukturdiagramme bieten eine Vielzahl von Möglichkeiten, die von der Aufbaustruktur einer Klasse bis hin zur Gliederung vollständiger Architekturen und Systeme 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 Anwendungsfalldiagramm 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-
Seite 29
diagramm.
In einem Anwendungsfalldiagramm werden prinzipiell zwischen Aktoren und Anwendungsfä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, zusammenhä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 Benutzer 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 einem 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 anderem eine Kurzbeschreibung, Vorbedingungen, Beschreibung des Ablaufs und Auswirkungen [Zuse01]. In UML wird keine Anwendungsfallbeschreibung vorgeschrieben. 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 Übersicht ü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 textuellen 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
Seite 30
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 Anwendungsfalldiagramm wird zu einem späteren Zeitpunkt in dieser Arbeit verfeinert dargestellt
(siehe Kapitel 4.2.1).
System
Manage products
Administrator
Order products
Customer
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 Einteilung 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 Service eingeteilt werden.
3.2
Aktivitätsdiagramm
Aktivitätsdiagramme sind mit der Version 2.0 von UML komplett überarbeitet worden. Sie spezifizieren den Kontroll- und Datenfluss zwischen verschiedenen Arbeitsschritten [Hitz05]. Ein Aktivitätsdiagramm soll die Frage „Wie realisiert mein System ein bestimmtes Verhalten?“ beantworten [Rupp05]. In früheren Versionen stellten Aktivitätsdiagramme eine spezielle Form von Zustandsdiagrammen dar. Mit der
Version 2.0 von UML wurden neue Elemente, wie z.B. Strukturierte Knoten, Entscheidungsknoten oder Schleifenknoten eingeführt [Rupp05].
Seite 31
Aktivitätsdiagramme können in verschiedenen Abstraktionsebenen modelliert werden. Das ist auch der Grund, warum sie in vielen Projektphasen einsetzt werden können. 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 abstrakte 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 Beispiel 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 Anfangsphase eines Projekts eine gute Übersicht geben.
3.2.2 Anwendungsfallbeschreibung
Die Beschreibung von Anwendungsfällen ist ein weiteres Einsatzgebiet von Aktivitä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 Aktivitä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üssen einen chronologischen Ablauf haben. In diesem Punkt sehe ich auch einen kleinen Nachteil beim Aktivitätsdiagramm. Es können nicht alle Anwendungsfälle aussagekrä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
Seite 32
100% mit der UML 2.0 Notation überein [Reic06].
Customer
ShopSystem
<<datastore>>
[Product]
Request productlist
Show productlist
[more]
(De)select product
Add (remove) product to cart
<<datastore>>
[customer]
Input Customerdata
<<centralBuffer>>
[shoppingCart]
Save Customerdata
Check order
[change order]
Save order
Send order
{create}
[Order]
<<datastore>>
[Order]
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 beschrieben werden, welche Aktivitäten der Benutzer vornimmt und welche Aktionen (Aktivitäten) das System macht, unabhängig davon, in welcher Ebene die eigentliche Logik implementiert ist.
Seite 33
Zusammengefasst kann gesagt werden, dass das Aktivitätsdiagramm eine gute Möglichkeit 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 Algorithmen bzw. Operationen [Rupp05], wie es das hier gezeigte Beispiel demonstrieren
soll.
Als Beispiel wurde hier der Sortieralgorithmus „Bubble Sort“ gewählt. Dieser Sortieralgorithmus 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 wiederholt, 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 erwies 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 einigermaß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
Seite 34
Methodiken vorzuziehen, die nicht so platzintensiv sind. Meiner Meinung nach wurde 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 bestimmten Zustand bei gewissen Ereignissen?“ [Rupp05] beantworten. Zustandsdiagramme erlauben auch die Modellierung von parallel ablaufenden Zustandsautoma-
Seite 35
ten, was vor allem bei der Modellierung von verteilten Systemen zum Einsatz kommen kann [Rupp05].
Prinzipiell haben Zustandsautomaten mehrere Einsatzgebiete, die sich wie folgt definieren lassen [Rupp05]:
•
Anwendungsfälle und Zustandsautomaten: Zustandsdiagramme eignen sich,
neben der textuellen Beschreibung und den Aktivitätsdiagrammen, zur Beschreibung von Anwendungsfällen [Rupp05]. Der Unterschied zum Aktivitätsdiagramm, ist die Sicht auf das Gesamtsystem. Während beim Aktivitätsdiagramm das Zusammenspiel zwischen den Aktoren und dem System modelliert 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 entspricht 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. Enumerationen) [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 beschrieben. In dieser Form des Zustandsdiagrams dürfen nur bestimmte Protokollzustände und Protokolltransitionen verwendet werden. Unter Protokollzustä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-
Seite 36
liert (siehe Abbildung 7). Mittels Zustandsdiagrammen kann eine übersichtliche Darstellung der Zustände in einem Objekt modelliert werden.
empty
[no. products = 0] delete product
[no. products > 0] delete product
add product
send order
add product
filled
cancel order
submit order
ordered
Abbildung 7: Protokollzustandsdiagramm „Shopping Cart“
Mögliche Zustände eines Warenkorbes in einer Online Anwendung sind üblicherweise „leer“, „befüllt“ und „bestellt“.
Der Ausgangszustand eines Warenkorbs der Anwendung ist „leer“. Nach dem Hinzufü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 Warenkorb 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
Seite 37
den Zustand „bestellt“ ein. In diesem Zustand kann die Bestellung abgebrochen werden. Wird die Bestellung abgebrochen nimmt das Objekt Warenkorb wieder den Zustand „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 Warenkorb 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 verschiedenen Interaktionspartnern ausgetauscht werden [Hitz05]. Ein Sequenzdiagramm soll die Frage „Wie läuft die Kommunikation in meinem System ab?“ beantworten [Rupp05].
Einen guten Überblick über die verschiedenen Einsatzmöglichkeiten von Sequenzdiagrammen 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 verschiedensten Abstraktionsebenen modellieren. Diese Diagrammart erlaubt sowohl die
Seite 38
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 eingesetzt werden können [Rupp05].
Sequenzdiagramme bieten auch eine gute Möglichkeit, um Architekturen und Designpatterns in einem System zu beschreiben. In der Praxis werden des Öfteren verschiedene 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 Sequenzdiagrammen 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 Sequenzdiagramms 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 Sequenzdiagramm modelliert werden, welches den Aufruf der einzelnen Schichten darstellt (siehe Abbildung 9).
Mit Hilfe eines Sequenzdiagramms kann das 4-Schichten Modell („4-tierarchitecture“) 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 („httpRequest“) an den Webserver. Dieser verarbeitet die Daten, und leitet eine entsprechende
Anfrage an den Anwendungsserver weiter. Der Anwendungsserver, welcher die Businesslogik implementiert, speichert die empfangenen Daten in die Datenbank bzw.
Seite 39
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“).
sd Java Enterprise 4-tier Model
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 ebenfalls 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 Datenquelle zu, sondern nur auf das Datenzugriffsobjekt. Das ist der große Vorteil dieses Patterns, 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.
Seite 40
Dieses Beispiel soll das Laden eines Objekts demonstrieren, welches in weiterer Folge geändert, und wieder in die Datenbank geschrieben werden soll.
sd Data Access Object
BusinessObject
DataAccessObject
DataSource
DomainObject
<<create>>
1 : create()
2 : loadData()
3 : loadData()
<<create>>
4 : 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 Sequenzdiagramms 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 Servicemethode 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 Antwortobjekt 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
Seite 41
Methode „destroy()“ aufgerufen wird.
sd Servlet life cycle
Client
Werserver
1 : request()
Servlet
<<create>>
2
3 : init()
4 : service()
5
6
<<destroy>>
7 : 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 zusammen, um eine bestimmte Funktion zu erfüllen?“ [Rupp05] beantworten. In älteren
Versionen von UML wurde das Kommunikationsdiagramm unter dem Namen Kollaborationsdiagramm geführt [Hitz05].
Ein Kommunikationsdiagramm bildet auf mittlerer Abstraktionsebene das Zusammenspiel 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-
Seite 42
tionsdiagram nicht entscheidend [Rupp05]. Deshalb sind Kommunikationsdiagramme 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 Implementierung 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 Strukturen 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 Interaktionspartner 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. Kommunikationsdiagrammen können mittels Zeitdiagrammen der Ablauf nur exemplarisch darstellt werden, da laut Standard keine Kontrollstrukturen zur Verfügung stehen [Hitz05].
Seite 43
Zeitdiagramme sind u. a. unter folgenden Bedingungen einzusetzen [Rupp05]:
•
Bei einem stark modularisiertem System mit stark abhängigen Zustandsdiagrammen, 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 weniger interessant sind.
•
Wenn bei der Anwendung Interaktionen einfach gestrickt sind und Nebenläufigkeiten oder Kontrollelemente unnötig sind.
Alle oben beschrieben Punkte treffen bei einer Enterprise Anwendung nur sehr wenig zu.
3.7
Interaktionsübersichtsdiagramm
Das Interaktionsübersichtsdiagramm zeigt das Zusammenspiel verschiedener Interaktionen. Die Darstellung erfolgt in Form einer Abwandlung des Aktivitätsdiagramms [Rupp05]. Ein Interaktionsübersichtsdiagramm soll die Frage „In welcher
Reihenfolge und unter welchen Bedingungen finden Interaktionen statt?“ beantworten [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 Interaktionsdiagramme geben [Hitz05].
3.8
Klassendiagramm
Ein Klassendiagramm zeigt die statische Struktur des Systems, indem es die statischen 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
Seite 44
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 Modellierung 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 Vorbild für die Implementierung verwendet werden. Diese Art des Klassendiagramms stellt die Basis für die Codegenerierung dar. Hier werden alle Attribute und Operationen, mit deren Datentypen bzw. Rückgabewerte und deren
Sichtbarkeit beschrieben [Rupp05].
An dieser einführenden Beschreibung lässt sich schon erkennen, wieso Klassendiagramme ein sehr beliebtes Werkzeug für die Modellierung sind. Klassendiagramme
sind gut lesbar, in jeder Phase des Projektes einsetzbar und erlauben große Unterschiede 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
Seite 45
die Datenzugriffslogik von der Businesslogik. Beide Klassen verwenden ein so genanntes Transferobjekt um miteinander zu kommunizieren.
BusinessObject
obtains/modifies
TransferObject
creates/uses
uses
DataAccessObject
encapsulates
DataSource
Abbildung 12: Klassendiagramm DAO-Pattern [Sun08]
In diesem Klassendiagramm lässt sich gut der Sinn dieses Pattern erkennen. Das Businessobjekt greift nicht direkt auf die Datenquelle zu, sondern kommuniziert mit
Hilfe des Transferobjektes über das Datenzugriffsobjekt mit der Datenquelle. Dadurch ist die Datenquelle leicht austauschbar macht. Um die Datenquelle zu ändern,
muss nur die Datenzugriffsklasse angepasst werden, die Businesslogik kann hingegen 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 Domainmodell 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 Attributen 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-
Seite 46
gelassen, um die Übersicht zu bewahren.
Aus diesem Diagramm (vgl. Abbildung 13) könnten im Rahmen einer modellgetriebenen Softwareentwicklung Klassen generiert werden und auch teilweise Datenbankskripts zum Erstellen von Datenbanktabellen. Leider wird in UML 2.0 nur der
Typ der Attribute angegeben und keine weiteren Informationen, wie z.B. die Feldlänge.
ProductGroup
Customer
-id: Long
-name: String
-email: String
-firstName: String
-lastName: String
1
1
0..*
0..*
Product
Order
-id: Long
-description: String
-name: String
-price: BigDecimal
-id: Long
-date: Date
1
1
1..*
1
OrderItem
-numberOfProducts: Integer
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 angelegt, um ein Produkt öfters bestellen zu können. Ein Produkt ist in genau einer Produktgruppe („Productgroup“), wobei eine Produktgruppe mehrere Produkte beinhalten kann, aber auch leer sein kann.
3.9
Seite 47
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 Gesamtsystems 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 Teile, die funktional oder logisch im Zusammenhang stehen, zu einem Paket zusammengefasst. Diese Einteilung wird meist zu einem frühen Zeitpunkt im
Projekt durchgeführt, da das modellierte Paketdiagramm einen guten Überblick gibt, welche Teile der Enterprise Anwendung zusammenhängend implementiert 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 darzustellen. Bei dieser Diagrammart sind auch verschiedene Abstraktionsebenen zu beachten.
So kann ein Paketdiagramm einen sehr groben Überblick über die verwendete Architektur 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 Einteilung der gesamten Anwendung.
Seite 48
Dieses Beispiel soll einen groben Überblick über die funktionale Einteilung in Paketen geben.
Shopsystem
ProductService
Customer
Administrator
<<access>>
OrderService
Abbildung 14: Paketdiagramm Shopsystem Übersicht
Dieses Diagramm zeigt eine grobe Übersicht über das Gesamtsystem, ohne die Pakete 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 anzeigen“.
•
„Orderservice“: In diesem Paket sind alle Teile der Bestellung enthalten. Zu
diesem Paket zählen unter anderem die Anwendungsfälle „Bestellung abschicken“ oder „Produkt zum Warenkorb hinzufügen“.
Seite 49
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 Anwendung.
<<systemModel>>
EnterpriseApplication
Web-Subsystem
Enterprise-Subsystem
View
Businesslogic
User
<<import>>
<<access>>
<<access>>
Controller
PersisentData
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 Controllerelemente greifen auf das Enterprise Subsystem zu. In diesem Paket ist das Unterpaket 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 Kombination verwendet. So können die im vorigen Diagramm dargestellten Pakete die modellierten Klassen aus dem Klassendiagramm enthalten.
Das UML-Modellierungstool StarUML sieht keine eigene Diagrammart „Paketdiagramm“ vor, sondern die Elemente des Paketdiagramms sind im Klassendiagramm
Seite 50
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 konkreter 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 Klassendiagramm. Das Objektdiagramm zeigt die tatsächlichen Strukturen zwischen
Instanzen gleicher Klassen. Diese rekursiven Strukturen sind im Klassendiagramm nicht ersichtlich.
•
Objektdiagramme können zur Überprüfung von Klassendiagrammen eingesetzt werden. Wird ein konkreter Fall in Form eines Objektdiagramms modelliert, können auch in einer frühen Phase des Projekts Fehler im Klassendiagramm aufgedeckt werden.
•
Seite 51
Zum Finden von Klassen durch die Modellierung von Objektdiagrammen.
Wird zuerst das Objektdiagramm modelliert, so kann aus diesem ein mögliches Klassendiagramm abgeleitet werden.
•
Für die Dokumentation von Architekturen, in denen Objekte durch abstrakte
oder generische Fabriken erzeugt werden. Diese Objekte sind in einem Klassendiagramm nicht sichtbar und werden erst durch die Darstellung des konkreten Objekts sichtbar.
•
Für die Modellierung von Konfigurationen, falls diese dem Modell entnommen werden. Auch Konfigurationsdateien können mit Hilfe des Objektdiagramms dargestellt werden. Dies macht vor allem dann Sinn, wenn Konfigurationsdateien 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 Objektdiagramms modelliert.
Objektdiagramme bieten für Enterprise Anwendungen eine gute Übersicht. In Enterprise 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 Domainobjekte. 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
Seite 52
1:n Beziehung würde allerdings sehr wohl bei der Administration von Bestellungen
Sinn machen.
customer : Customer
email = [email protected]
firstName = Christian
lastName = Sokop
order1 : Order
order2 : Order
id = 2
date = 2008-05-23
id = 4
date = 2008-05-24
orderItem1 : OrderItem
numberOfProducts = 1
product1 : Product
product2 : Product
product3 : Product
id = 123
name = UML Glasklar
price = 35
id = 47
name = UML@work
price = 39
id = 39
name = WindowsVista
price = 430
productGroup1 : ProductGroup
productGroup2 : ProductGroup
id = 2
name = Books
id = 4
name = OS
Abbildung 16: Objektdiagramm Testdaten Domänenmodellklassendiagramm
3.11 Kompositionsstrukturdiagramm
Mit dem Kompositionsstrukturdiagramm lassen sich interne Strukturen von Komponenten und deren Interaktionen zu anderen Komponenten darstellen. Es soll die Frage „Wie sind die einzelnen Architekturkomponenten strukturiert und mit welchen
Rollen spielen sie dabei zusammen?“ beantworten [Rupp05].
Seite 53
Das Kompositionsstrukturdiagramm wurde in UML 2.0 neu eingeführt [Rupp05].
Prinzipiell kann zwischen zwei Arten von Kompositionsstrukturdiagrammen unterschieden werden [Hitz05]:
•
Kompositionsstrukturdiagramm für Klassen: Das Ziel des Kompositionsstrukturdiagramms für Klassen ist es, eine detaillierte Beschreibung der internen Struktur einer Klasse zu modellieren. Der Vorteil gegenüber dem
Klassendiagramm ist es, dass im Kompositionsstrukturdiagramm die Zusammenhänge der Klassen aus Sicht einer bestimmten Klasse (Kontextklasse) 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 Zusammenspiel der Komponenten modelliert. Das Hauptaugenmerk liegt dabei
nicht auf das „wie und wann“, sondern wer mit welcher Komponente kommuniziert [Hitz05]. Diese Art des Kompositionsstrukturdiagramms eignet
sich besonders gut, um Designpattern zu beschreiben, die in der Implementierung angewendet werden [Rupp05].
In den folgenden Kapiteln sollen für diese beiden Arten von Kompositionsstrukturdiagrammen Beispiele modelliert werden.
3.11.1 Kompositionsstrukturdiagramm für Klassen
Mit Hilfe des Kompositionsstrukturdiagramms kann eine Art Klassendiagramm modelliert 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
Seite 54
(„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
-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 Kompositionsstrukturdiagramms die Zusammenhänge der Klassen übersichtlicher modellieren, da das gesamte Diagramm von einer Kontextklasse aus betrachtet wird.
Seite 55
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 Elemente und die Zusammenhänge zwischen den Elementen modelliert. Das Kompositionsstrukturdiagramm soll in dieser Abstraktionsebene eine Übersicht über ein Pattern
geben und nicht den genauen Aufbau eines Patterns beschreiben. Für die Beschreibung des Aufbaus eines Patterns sind Klassen- bzw. Sequenzdiagramme besser geeignet.
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
Seite 56
Businessobjekt, ein Transferobjekt, ein Datenzugriffsobjekt und eine Datenquelle
benötigt. Die Datenquelle wird in diesem konkreten Beispiel nicht modelliert.
ProductServiceImpl
ProductDataAccessObject
DAOPattern
Product
-id: Long
-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 verdeutlichen, 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
Seite 57
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 Systeme, wie es auch Enterprise Anwendungen sind. Das Komponentendiagramm kann
auch das Zusammenspiel zwischen physischen und logischen Komponenten darstellen.
In einer Enterprise Anwendung werden sehr viele Interfaces und Implementierungen
verwendet. Das Komponentendiagramm bietet eine gute Möglichkeit, um diese Interfaces darzustellen.
Eine Java Enterprise Anwendung besteht aus mehreren Komponenten, die in
Abbildung 20 dargestellt werden.
UserInterface
BusinessService
BusinessMethods
DataAccess
PersistenceMethods
Database
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, welche von den Datenzugriffsobjekten verwendet wird. Diese stellen wieder ein Inter-
Seite 58
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 Komponenten einer Java Enterprise Anwendung darstellen.
<<artifact>>
sample.ear
<<artifact>>
sample.war
jsp-page
controllerClasses
<<artifact>>
web.xml
<<artifact>>
sample-impl.jar
implemetations
BusinessMethods
BusinessMethodsImpl
<<artifact>>
sample.jar
interfaces
Domainobjects
<<artifact>>
ejb-jar.xml
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
Seite 59
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 Komponenten, die für die Realisierung des Webteils benötigt werden. Die Interfaces enthalten neben den Definitionen der Businessinterfaces selbst, die gemeinsam verwendeten 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 Hardwareeinheiten. 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 Anwendungen 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ührungsumgebungsknoten. 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 physischen 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 Datenbankserver 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
Seite 60
kleinen Projekten der DB-Server und der Anwendungsserver auf demselben physischen Knoten liegen.
Eine allgemeine Darstellung einer Java Enterprise Web-Anwendung ist in Abbildung
22 zu sehen.
<<device>>
Client
<<executionEnvironment>>
Webbrowser
<<device>>
Server
<<internet>>
<<executionEnvironment>>
J2EE-ApplikationServer
<<deployment spec>>
ejb-jar.xml
<<artifact>>
serverlibs
<<deploy>>
<<artifact>>
application.ear
<<artifact>>
application.war
<<deployment spec>>
web.xml
<<ethernet>>
<<device>>
DbServer
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 vorhandenen 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 Diagrammen 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 Version 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
Seite 62
darauf geachtet keine Beta-Versionen zu evaluieren.
Ein weiteres Kriterium sind, die auf der Internetseite [Ecli08a] verfassten Benutzerkommentare. 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, sondern eine Auswahl aus denen, die den oben genannten Anforderungen entsprechen.
Folgende Plugins werden näher in betracht gezogen (in alphabethischer Reihenfolge):
• 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 besonderes 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 unterstü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 Klassendiagramm importiert werden können [Ecli08a]. Im Rahmen dieser Diplomarbeit 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 Diagrammarten 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 einer Enterprise Anwendung nicht verwendet, wie das vorherige Kapitel zeigt.
Seite 63
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 Euro relativ teuren (Stand Mai 2008) Version, auch eine freie Version. Zusätzlich 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 angegeben, 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 synchronisieren. 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 eine große Hilfe darstellen. Das integrierte UML Plugin unterstützt das Anwendungsfall-, Klassen-, Sequenz-, Kollaborations-, Zustands-, Aktivitätsund Verteilungsdiagramm. Da man davon ausgehen kann, dass das Paketdiagramm im Rahmen des Klassendiagramms realisiert wurde, werden mit diesem 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 Entwicklungsumgebung evaluiert.
• Slime UML [slim08]: Das freie Plugin „Slime UML“ bietet eine volle Unter-
Seite 64
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 Objektdiagramm 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 wurde 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 Klassendiagramm und der Möglichkeit der Codegenerierung noch zumindest eine weitere
Diagrammart an. Das Plugin „Slime UML“ bietet zusätzlich das Anwendungsfalldiagramm, 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
Seite 65
die Codegenerierung an.
•
UML Editoren: Hier werden die Plugins „Blueprint Software Modeler“ und
„Violet UML Editor“ evaluiert. Diese beiden Plugins bieten nur die Möglichkeit UML Diagramme zu modellieren, allerdings keine automatisierte
Codegenerierung.
•
Codegeneratoren: In diesem Kapitel werden die Plugins, die nur ein Klassendiagramm, bzw. ein um das Paketdiagramm erweitertes Klassendiagramm, und die automatisierte Codegenerierung anbieten, evaluiert. Es handelt sich dabei um die Plugins „Apollo for Eclipse“ und „Green“.
•
Erweiterte Codegeneratoren: Hier werden die Plugins, die sowohl die Codegenerierung aus Klassendiagrammen, sowie zumindest ein weiteres Diagramm 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 Erweiterungen 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 Internetseite wird die komplette Entwicklungsumgebung als Installationsdatei für Microsoft
Windows angeboten. Für andere Betriebssysteme wird ein Update, welches auf „eclipse“ 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.
Seite 66
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 Beziehungen zueinander zur Auswahl (siehe Abbildung 23).
Allerdings wird nur die Basisfunktionalität angeboten. Soll ein Anwendungsfalldiagramm in Pakete eingeteilt werden, so ist dies nur händisch mittels Rechtecken möglich.
Ein großer Pluspunkt, ist die Möglichkeit jedes Element im Diagramm (in jeder Dia-
Seite 67
grammart, nicht nur im Anwendungsfalldiagramm) mit einem Kommentar zu versehen. 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 Entwicklungsumgebung 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-
Seite 68
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 Anwendungsfalldiagramm einfach modellieren. Im oberen Bereich werden wieder alle gängigen Elemente angeboten.
Als Beispiel wurde das in Kapitel 3.8. Klassendiagramm modelliert. Es zeigt die Entitäten des begleitenden Beispiels. Das Ergebnis zeigt Abbildung 25.
Abbildung 25: MyEclipse: Klassendiagramm
Die Entwicklungsumgebung „MyEclipse“ bietet eine automatische Codegenerierung
Seite 69
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 ordnungsgemäß 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 Beispiel bei der Klasse „Order“ ein Attribute „private Date Order____date;“ angelegt.
• 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 einem 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 Ergebnis das Diagramm in Abbildung 26 generiert (Ausschnitt).
Wie auf den ersten Blick ersichtlich ist das Ergebnis nicht sehr gut. Die Assoziationen 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 Klassendiagramms erhöhen.
Das Zusammenspiel zwischen Klassendiagramm und Quelltext funktioniert nicht.
Das Diagramm und der Quelltext werden nicht automatisch synchronisiert. Wird im
Seite 70
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 modellieren. 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 werden.
Das Diagramm neigt dazu sich in die Länge zu ziehen und es besteht keine Möglichkeit das Diagramm händisch anzupassen. Wie in Abbildung 27 ersichtlich kann das
Seite 71
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 Entwicklungsumgebung „MyEclipse“ die Möglichkeit Aktivitäts-, Zustands- und Vertei-
Seite 72
lungsdiagramme zu modellieren.
Alle dieser drei Diagrammarten werden zwar von der Entwicklungsumgebung „MyEclipse“ 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 Verzweigungs- bzw. Verbindungsknoten und den Parallelisierungs- bzw. Synchronisationsknoten 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.
Seite 73
Zusätzlich ist zwischen zwei Zustanden nur eine Beziehung in einer Richtung darstellbar. 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
Seite 74
Als Beispieldiagramm wurde im Rahmen dieser Diplomarbeit versucht, den klassischen 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 Entwicklungsumgebung „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 „MyEclipse“ eine große Menge an Plugins inkludiert, die bei der Implementierung einer
Java Enterprise Anwendung sehr hilfreich sind. So werden mit dieser Entwicklungsumgebung unter anderem ein JavaScript Debugger, ein XML Editor oder die Unterstützung von Webservices mitgeliefert.
4.3
UML Editoren
Als UML Editoren werden hier Plugins verstanden, die keine Möglichkeit der Codegenerierung 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 modellgetriebenen Softwareentwicklungsprozess mit Hilfe eines Tools anzubieten. Leider wird dieser 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-, Objekt-, Aktivitäts-, Zustands- und Sequenzdiagrammen angeboten. Damit werden die
meist verwendeten Diagrammarten angeboten, die bei der Modellierung einer Enter-
Seite 75
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
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-
Seite 76
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 Anwendungsfall die Möglichkeit geboten „Constraints“ oder „Extension points“ zu modellieren.
Abbildung 32: Blueprint Software Modeler: Anwendungsfalldiagramm
Als weiterer guter Punkt kann zu jedem Element eine Dokumentation verfasst werden. 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 Paketoder 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-
Seite 77
diagramm. So kann für jede Klasse einzeln bestimmt werden, welche Methoden angezeigt werden, und welche nicht. Dieses Feature erlaubt es übersichtliche Diagramme 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-, Kompositionsstruktur- und Komponentendiagramme angeboten.
Seite 78
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 Generierung von Quelltext bei der evaluierten Version nicht implementiert ist. Das Anlegen 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 angeboten. 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 Anwendungsfalldiagramme 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 Zeichenprogramm, 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
Seite 79
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 Klassendiagramm 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 Vorteil sein kann.
4.4.1 Apollo for Eclipse
Das Plugin „Apollo for Eclipse“ bietet eine Mischung aus dem Klassen- und Paketdiagramm 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 Generieren von Quelltext aus dem Klassendiagramm), wie auch das Erstellen eines Klassendiagramms 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 angepasst, 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 resultierende 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-
Seite 80
traktionsebene modelliert werden soll und dieses nicht in Quelltext umgesetzt werden 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 Beispiel 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 anderem Pakete, Klassen, Interfaces aber auch Attribute oder Operationen angelegt werden.
Abbildung 34: Apollo for eclipse: Arbeitsumgebung
Seite 81
Besonders hervorzuheben ist das Anlegen eines Attributes. Dieser Schritt erfolgt mit
Hilfe von Java Quelltext. Der gleiche Mechanismus wird beim Anlegen von Methoden verwendet. Das heißt Methoden können direkt beim Anlegen implementiert oder
zumindest kommentiert werden.
Diese Vorgehensweise erlaubt eine sehr praxisnahe Modellierung und Implementierung, da diese zwei Schritte relativ einfach zu einem Schritt zusammengefasst werden. 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 Klassen 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
Seite 82
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.
Seite 83
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 erlaubt nur die Modellierung von Klassen in einem Paket. Es können keine Paketübergreifende 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-
Seite 84
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 vorhandenen 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
Seite 85
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 Sequenzdiagrammen zu erstellen.
Klassendiagramm
Dieses Plugin erstellt den Quellcode sofort im Modellierungsprozess aus dem modellierten 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, designorientierte Modellierung, nicht aber für eine konzeptuell-analytische Modellierung
gedacht.
Bei der Erstellung eines Attributes in der Klasse werden automatisch Zugriffsmethoden („getter“- und „setter“-Methoden) erstellt. Zusätzlich werden einige (konfigurierbare) Kommentare erstellt, wie Listing 2 zeigen soll.
Seite 86
Abbildung 39: eUML: Benutzeroberfläche
Listing 2 zeigt einen Ausschnitt aus dem generierten Code der Klasse „Product“:
public class Product {
/**
* @uml.property
*/
private Long id;
name="id"
/**
* @return Returns the id.
* @uml.property name="id"
*/
public Long getId() {
return id;
}
/**
* @param id The id to set.
* @uml.property name="id"
*/
public void setId(Long id) {
this.id = id;
}
}
Listing 2: Source Code „Product“ (Auszugsweise)
Seite 87
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-
Seite 88
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 („compiler“).
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 Darstellungsform zurückgegriffen. Das hat den Nachteil, dass Entwickler, die mit dieser
Notation nicht vertraut sind, die Diagramme nicht auf Anhieb lesen können.
Seite 89
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 Bereich 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 Methodenaufruf 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-
Seite 90
textgenerierung eine gute Möglichkeit für eine modellgetriebene Softwareentwicklung. 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 Quelltext 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 Sequenzdiagramme abgebildet werden können und nur die Möglichkeit besteht ein Sequenz- bzw. ein Paket-/Klassendiagramm zu erstellen. Auch die verwendetet Notation 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 Diagramm z.B. für Dokumentationszwecke erstellt werden.
4.5.2 AmaterasUML
Dieses Plugin unterstützt das Zeichnen von Klassen-, Sequenz- und Anwendungsfalldiagrammen. Außerdem erlaubt das Plugin eine Codegenerierung aus Klassendiagrammen und auch ein Reverse Engineering. Leider wird von diesem Plugin nur
das Klassendiagramm unterstützt und keine Möglichkeit geboten die erstellten Klassen 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 vorgesehen. Das heißt die Installation dieses Plugin muss manuell vorgenommen werden.
Das Plugin „AmaterasUML“ bietet eine einfache und schnelle Möglichkeit ein Anwendungsfalldiagramm mit allen Standardnotationen zu erstellen.
Das erstellte Anwendungsfalldiagramm kann als Bilddatei exportiert werden. Als
Beispiel wurde hier das Anwendungsfalldiagramm in der höchsten Abstraktionsebene modelliert. Das exportierte Bild zeigt Abbildung 43.
Seite 91
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.
Seite 92
Die Generierung von Quellcode ist relativ einfach möglich. Leider werden die Assoziationen nicht aufgelöst. Bei der Modellierung fehlt auch die Möglichkeit der Navigierung durch die Klassen anzugeben. Auch die Synchronisation zwischen Modell
und Quelltext fehlt, das heißt der Quelltext bzw. das Modell müssten händisch angepasst 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 erstellen. 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.
Seite 93
Zusammenfassung
Beim Plugin „AmaterasUML“ funktioniert beim Anwendungsfalldiagramm die Exportfunktion 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
Seite 94
Als kleines Beispiel wurde wieder versucht das Anwendungsfalldiagramm in einer
hohen Abstraktionsebene zu modellieren. Besonders bemerkenswert ist die Möglichkeit, 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 Anwendungsfalldiagramm 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ärlich, 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ändisch 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 Anwendungen hervorragend zusammenspielen, sich allerdings die kostengünstige Toolunterstü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 ausgereift, allerdings bietet diese Entwicklungsumgebung eine Vielzahl an anderen Plugins an, die für die Java Enterprise Entwicklung hilfreich sein können. Diese Entwicklungsplattform 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 geeignet. 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 gleichzeitig mit dem Quelltext erstellt. Auch das Plugin „GreenUML“ bietet das gleiche
Feature, allerdings keine Möglichkeit Klassendiagramme in Pakete aufzuteilen.
Zusammenfassung und Ausblick
5.2
Seite 96
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önnen sowohl standardisierte UML Diagramme, wie auch implementierungsnahe Diagramme erstellt werden. Die erstellten Diagramme können mittels manuell 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 Sequenzdiagramme 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 Alternative meist nicht die bessere Variante darstellt.
Literaturverzeichnis
Seite 97
[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
Seite 98
[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.fhwedel.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
Seite 99
[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

paper - Business Informatics Group

Transcrição

Documentos relacionados

Übungen zur Softwaretechnik - Software and Systems Engineering

Eine Benefizfahrt mit dem Fahrrad von

Referenz: Generic Java Ontology API Thema: Eclipse Plug

Plugins installieren

FONTYS HOGESCHOLEN FACULTEIT VENLO

Leseprobe (50 Seiten, 649 KB)

Photoshop Plugins

Versionen kommerzieller UML – Werkzeuge

JAVA – Installation und Einrichtung des Java

UML 2.4.1 Referenz