Softwareentwicklung mit UML und Eclipse

Transkript

1 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

2 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>

3 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!

4 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]).

5 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.

6 Inhaltsverzeichnis Einleitung Motivation Problemstellung Ziel der Arbeit Technologien UML Unified Modeling Language Grundlagen von UML Diagrammübersicht (Java) Enterprise Anwendungen Designpatterns Java EE - Java Enterprise Edition Die Entwicklungsumgebung Eclipse Geschichte Arbeitsweise Eclipse Plugins Begleitendes Beispiel Softwareentwicklung mit UML Anwendungsfalldiagramm Aktivitätsdiagramm Geschäftsprozessmodellierung Anwendungsfallbeschreibung Implementierung einer Operation Zustandsdiagramm Sequenzdiagramm Architekturbeschreibung Designpatterns Detailmodellierung Kommunikationsdiagramm Zeitdiagramm Interaktionsübersichtsdiagramm... 43

7 3.8 Klassendiagramm Konzeptuell-analytische Modellierung Logische, desgin-orientierte Modellierung Paketdiagramm Funktionale Gliederung Definition von Schichten Objektdiagramm Kompositionsstrukturdiagramm Kompositionsstrukturdiagramm für Klassen Kompositionsstrukturdiagramm für Kollaborationen Komponentendiagramm Verteilungsdiagramm UML Erweiterungen für Eclipse Einleitung MyEclipse Anwendungsfalldiagramm Klassen- und Paketdiagramm Sequenz- und Kollaborationsdiagramm Weitere Diagrammarten Zusammenfassung UML Editoren Blueprint Software Modeler Violet UML Editor Codegeneratoren Apollo for Eclipse GreenUML Erweiterte Codegeneratoren euml2 Modeler AmaterasUML SlimeUML Zusammenfassung und Ausblick Zusammenfassung Ausblick Literaturverzeichnis... 97

8 Abbildungsverzeichnis Abbildung 1: Übersicht der Diagramme in UML 2.0 [Hitz05] Abbildung 2: Übersicht 4-Tier Architektur (basiert auf [Lang06]) Abbildung 3: Eclipse Architektur [Schr02] Abbildung 4: Anwendungsfalldiagramm Übersicht Abbildung 5: Aktivitätsdiagramm des Anwendungsfall Bestellung durchführen.. 32 Abbildung 6: Aktivitätsdiagramm Bubble Sort Abbildung 7: Protokollzustandsdiagramm Shopping Cart Abbildung 8: Anwendungen von Sequenzdiagrammen im Projekt [Rupp05] Abbildung 9: Sequenzdiagramm 4-Schichtenmodell Abbildung 10: Sequenzdiagramm DAO-Pattern (basiert auf [Sun08]) Abbildung 11: Sequenzdiagramm Lebenszyklus Servlet (basiert auf [Ahme02]) Abbildung 12: Klassendiagramm DAO-Pattern [Sun08] Abbildung 13: Klassendiagramm Domainmodell Abbildung 14: Paketdiagramm Shopsystem Übersicht Abbildung 15: Paketdiagramm Übersicht Enterprise Anwendung Abbildung 16: Objektdiagramm Testdaten Domänenmodellklassendiagramm Abbildung 17: Kompositionsstrukturdiagramm Kontextklasse Customer Abbildung 18: Kompositionsstrukturdiagramm DAO-Pattern Abbildung 19: Kompositionsstrukturdiagramm Anwendung DAO-Pattern Abbildung 20: Komponentendiagramm Java Enterprise Anwendung Abbildung 21: Komponentendiagramm Java EE Web-Anwendung Abbildung 22: Verteilungsdiagramm Java EE Web-Anwendung Abbildung 23: MyEclipse: Benutzeransicht Abbildung 24: MyEclispe: Anwendungsfalldiagramm Abbildung 25: MyEclipse: Klassendiagramm Abbildung 26: MyEclipse: Klassendiagramm Reverse Engineering Abbildung 27: MyEclipse: Sequenzdiagramm... 71

9 Abbildung 28: MyEclipse: Aktivitätsdiagramm Abbildung 29: MyEclipse: Zustandsdiagramm Abbildung 30: MyEclipse: Verteilungsdiagramm Abbildung 31: Blueprint Software Modeler: Arbeitsbereich Abbildung 32: Blueprint Software Modeler: Anwendungsfalldiagramm Abbildung 33: Blueprint Software Modeler: Klassendiagramm Abbildung 34: Apollo for eclipse: Arbeitsumgebung Abbildung 35: Apollo for eclipse: Klassendiagramm Abbildung 36: Apollo for eclipse: Klassendiagramm Abbildung 37: GreenUML: Benutzeransicht Abbildung 38: GreenUML: Reverse Engineering Abbildung 39: euml: Benutzeroberfläche Abbildung 40: euml: Erstellen einer Assoziation Abbildung 41: euml: Klassendiagramm Abbildung 42: euml: Sequenzdiagramm Abbildung 43: AmaterasUML: Anwendungsfalldiagramm Abbildung 44: AmaterasUML: Ansicht Klassendiagramm Abbildung 45: AmaterasUML: Sequenzdiagramm Abbildung 46: SlimeUML: Anwendungsfalldiagramm... 93

10 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-

11 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.

12 Einleitung Seite 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

13 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.

14 Kapitel 2 Technologien Das folgende Kapitel soll eine Einleitung über die behandelten Technologien geben. Einige Teile dieses Kapitels basieren auf [Soko07]. 2.1 UML 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 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 CORBA 1 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 Anwendungen [OMG08a])

15 Technologien Seite 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 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.

16 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.

17 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.

18 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

19 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 erklärt 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 4- Tier-Architecture (4-Schichten-Architektur). Laut [Lang06] gilt die 4-Schichten- Architektur seit dem Internet Boom Mitte der 90er Jahre als State-of-the-art-

20 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-

21 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.

22 Technologien Seite 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 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.

23 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 JBoss 2, sowie die kommerziell vertriebenen Anwendungsserver von Bea (Bea Weblogic 3 ) und IBM (IBM Websphere 4 ). 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

24 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 (IDE 5 ) 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 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

25 Technologien Seite 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.

26 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 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.

27 Technologien Seite Begleitendes Beispiel Als begeleitendes Beispiel wurde ein kleines Shopsystem implementiert. Dieses System wurde mit Hilfe von EJB 3.0 entwickelt. Als Datenbank dient eine MySql 6 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 adresse 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

28 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-

29 Softwareentwicklung mit UML 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

30 Softwareentwicklung mit UML 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 Administrator Manage products 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].

31 Softwareentwicklung mit UML 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 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 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

32 Softwareentwicklung mit UML Seite % 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 Check order Save Customerdata <<centralbuffer>> [shoppingcart] [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.

33 Softwareentwicklung mit UML 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 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

34 Softwareentwicklung mit UML 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-

35 Softwareentwicklung mit UML 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-

36 Softwareentwicklung mit UML 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 ordered submit order 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