Software Engineering I/II - Fakultät Informatik/Mathematik

Software Engineering I/II
Skript zur Lehrveranstaltung
Hartmut Fritzsche
Hochschule für Technik und Wirtschaft Dresden
Fakultät Informatik/Mathematik
11. Dezember 2013

Inhaltsverzeichnis
1 Einführung 4
1.1 Aufbau der Lehrveranstaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Ziele und Arbeitsmethoden der Softwaretechnik . . . . . . . . . . . . . . . . 4
1.2.1 Was ist Softwaretechnik? . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Methodologie der Softwareentwicklung . . . . . . . . . . . . . . . . . . 5
1.3 Softwareentwicklungswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Die Entwicklungsplattform Eclipse . . . . . . . . . . . . . . . . . . . . 8
1.3.3 Werkzeuge zur UML-Unterstützung . . . . . . . . . . . . . . . . . . . 12
1.3.4 Diagrammaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.5 Werkzeuge zur Versionsverwaltung . . . . . . . . . . . . . . . . . . . . 16
1.3.6 Werkzeuge für das Build-Management . . . . . . . . . . . . . . . . . . 17
2 Der Softwareentwicklungsprozess 18
2.1 Die Phasen im Softwareentwicklungsprozess . . . . . . . . . . . . . . . . . . . 18
2.2 Lebenszyklus-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Prozessmodellierung und Projektmanagement . . . . . . . . . . . . . . . . . . 19
2.4 Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Ziele und Maßnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.3 Validation und Verifikation . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Anforderungsanalyse und -definition 24
3.1 Das Pflichtenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Formale Beschreibungsmittel . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Anwendungsfall-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Objektorientierte Modellierung 28
4.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Klassenbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Klassen - Instanzen - Abstraktionen . . . . . . . . . . . . . . . . . . . 28
1

INHALTSVERZEICHNIS 2
4.2.2 Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.3 Operationen und Methoden . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.4 Grafische Notation für Klassen und Objekte . . . . . . . . . . . . . . . 30
4.2.5 Sichtbarkeit von Attributen und Operationen . . . . . . . . . . . . . . 31
4.2.6 Klassen als Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Assoziationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Assoziation und Verknüpfung . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.2 Rollen und Multiplizität . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.3 Aggregation und Komposition . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Generalisierung und Spezialisierung . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1 Die Inklusionsrelation . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.2 Vererbung und Delegation . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4.3 Polymorphie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.4 Abstrakte und konkrete Klassen . . . . . . . . . . . . . . . . . . . . . 40
4.4.5 Parametrisierte Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Dynamische Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5.1 Instanzen als Laufzeitobjekte . . . . . . . . . . . . . . . . . . . . . . . 44
4.5.2 Interaktionsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5.3 Statechart-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.5.4 Aktivitäts-Diagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5 Von UML nach Java ... 56
5.1 Applikationen und Applets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Baum-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3 Interfaces und Mehrfachvererbung . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 Implementation von Aggregationen: Vektoren und Hash-Tabellen . . . . . . . 67
5.4.1 Vektoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4.2 Hash-Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5 Dynamische Modelle und Event-Handling . . . . . . . . . . . . . . . . . . . . 69
5.6 Fehler und Ausnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.7 Parallelität durch Multithreading . . . . . . . . . . . . . . . . . . . . . . . . 77
6 Entwurf und Implementation 80
6.1 Modellmanagement und Systementwurf . . . . . . . . . . . . . . . . . . . . . 80
6.1.1 Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2 Komponentendiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.3 Verteilungsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.4 Objektserialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.5 Modell-/Diagrammaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

INHALTSVERZEICHNIS 3
7 Konfigurations-, Test- und Dokumentationsmanagement 96
7.1 Der KM-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.2 Versionsverwaltungssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.3 Aufbau eines Build-Prozesses . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.4 Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.4.1 Nutzung von Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.4.2 Erstellung von Ant-Skripten . . . . . . . . . . . . . . . . . . . . . . . . 106
7.5 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.6 Zustandsbasiertes Testen mit JUnit und JUnitDoclet . . . . . . . . . . . . . . 117
7.7 Generieren von Dokumentationen mit Javadoc . . . . . . . . . . . . . . . . . 122
7.8 Signieren von Java-Archiven . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8 Wiederverwendung und Evolution 126
8.1 Individuelle Komponenten: Module und Klassen . . . . . . . . . . . . . . . . 126
8.2 Komponentenbasierte Softwareentwicklung - Frameworks . . . . . . . . . . . 127
8.3 Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
9 Musterarchitekturen 145
9.1 Die MVC-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.2 Grafische Benutzeroberflächen . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.2.1 Java AWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.2.2 Die Layout-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
9.2.3 Swing 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
9.2.4 Entwurf eines Swing–GUI . . . . . . . . . . . . . . . . . . . . . . . . 149
9.2.5 JTree - Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
9.2.6 SWT: Das Standard Widget Toolkit . . . . . . . . . . . . . . . . . . . 151
9.2.7 Einbettung von Swing-Komponenten in SWT . . . . . . . . . . . . . . 157
9.2.8 JFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
9.3 Client-Server-Systeme mittels http und Servlets . . . . . . . . . . . . . . . . . 162
9.4 Datenbankanbindungen an Java-Applikationen . . . . . . . . . . . . . . . . . 166
9.5 Server2Go . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Literaturverzeichnis 172

Kapitel 1
Einführung
1.1 Aufbau der Lehrveranstaltung
Die Lehrveranstaltung umfasst die Module ”
Software Engineering I” und ”
Software Engineering
II” und erstreckt sich über zwei Semester. Die Vorlesung ist insgesamt in acht Kapitel
gegliedert. Grundsätzlich orientiert sich die Gliederung an den Phasen des Softwareentwicklungsprozesses.
Einen Schwerpunkt im ersten Teil bildet das Kapitel 4 über die objektorientierte
Modellierung.
Basis der praktischen Arbeit in der Lehrveranstaltung (in Form eines wöchentlichen Praktikums)
bildet die Entwicklungsplattform Eclipse, ergänzt um mehrere Plug-ins. Einzelheiten
zu den verwendeten Plug-ins und die jeweiligen Installationen werden im Abschnitt 1.3
besprochen. Im Rahmen der praktischen Ausbildung arbeitet jeder Studierende in einem
Gruppenprojekt an einer konkreten Softwareentwicklungsntwicklungsaufgabe mit.
Literatur zur Lehrveranstaltung ist themenbezogen im Skript angegeben. Publikationen
zu den Grundlagen der Softwaretechnik sind [Som07], [Bal05], [BES08], [Lar05] und [Dum03].
1.2 Ziele und Arbeitsmethoden der Softwaretechnik
1.2.1 Was ist Softwaretechnik?
Die Softwaretechnik (engl. Software Engineering, deutsch auch als Softwaretechnologie bezeichnet)
ist die Lehre vom Prozess der organisierten Softwareproduktion. Sie umfasst (die
Erforschung von) Theorie, Prinzipien, Methoden und Werkzeuge(n) zur Herstellung und
zur Wartung (Anpassung, Weiterentwicklung) von Software. Das schliesst Maßnahmen zur
analytischen und konstruktiven Qualitätssicherung, die Nachnutzung bereits vorhandener
Software sowie das Projektmanagement und das Konfigurationsmanagement ein.
Softwareentwicklung ist ein Prozess, der methodisch gestaltet werden muss und dabei
entscheidend von den eingesetzten Entwicklungswerkzeugen (engl. tools) geprägt wird. Diese
Werkzeuge werden zunehmend wirkungsvoller, je besser der Softwareentwicklungsprozess
verstanden wird. Das wiederum ermöglicht die Weiterentwicklung angewendeter Methoden.
4

1.2. ZIELE UND ARBEITSMETHODEN DER SOFTWARETECHNIK 5
Softwareentwicklungsmethoden sind somit nach wie vor Gegenstand intensiver Forschung
(Beispiel: ”
Modellgetriebene Softwareentwicklung”).
Die Lehrveranstaltung setzt Programmierkenntnisse voraus, letztlich geht es um die Entwicklung
funktionsfähiger Anwendungssysteme. Während es in der Programmierung eher um
die Entwicklung von Algorithmen geht, tritt jetzt ein ganzes Anwendungsfeld (eine ”
Domäne”)
in den Fokus der Betrachtung. Abbildung 1.2.1 verdeutlicht, um welche Aspekte es in
der Softwaretechnik und damit auch in der Lehrveranstaltung geht. Die Abkürzung ”
CASE”
steht für Computer Aided Software Engineering. Es wird zwischen Lower Case- und Upper
Case-werkzeugen unterschieden.
Abbildung 1.2.1: Wesentliche Aspekte der Softwaretechnik
1.2.2 Methodologie der Softwareentwicklung
Es gibt nicht eine Entwicklungsmethode, sondern eine Vielzahl von Methoden. Die Lehre von
den Methoden bezeichnet man allgemein als ”
Methodologie”. Die in der Lehrveranstaltung
schwerpunktmäßig behandelte Methodik gründet sich auf die Objekttechnologie. Von führenden
Softwaretechnologen (Ivar Jacobson, James Rumbaugh und Grady Booch) wurde mit
der Unified Modeling Language (UML) eine einheitliche grafische Modellierungs- und Entwurfssprache
entwickelt, die in wesentlichen Teilen ”
objektbasiert” ist die und eine geeignete

1.2. ZIELE UND ARBEITSMETHODEN DER SOFTWARETECHNIK 6
Zahl von Modelltypen unterstützt. Die UML hat seit etwa Anfang der 1990er Verbreitung
gefunden und wird weiterentwickelt. Die Objekttechnologie hat sich damit gegenüber z.B.
der Structured Analysis (SA) und der Structured Analysis and Design Technique (SADT)
durchgesetzt.
Ein wesentlicher Aspekt bei der Einführung der Objekttechnologie in der Softwaretechnik
war die Standardisierung der sprachlichen Darstellungsmittel. Es wurde also bewusst nicht
die Methodik standardisiert (wie anfangs beabsichtigt), sondern die sprachlichen Mittel.
Seit Anfang der 1990er Jahre bildet die UML (aktuell UML 2) einen Quasi-Standard
in der Softwaretechnik. Mit der UML werden Modelle unterschiedlicher Art entwickelt, die
jeweils Ausschnitte einer zu modellierenden angenommenen oder realen Welt widerspiegeln.
Zur Darstellung der Modelle unterschiedlicher Art dienen jeweils Diagramme. Diagramme
visualisieren und formalisieren Ausschnitte aus bzw. Sichten auf Modelle.
Die UML 2 definiert die nachfolgend beschriebenen 14 Diagrammtypen.
Strukturdiagramme:
• Klassenstruktur-Diagramm (static structure diagram)
• Objekt-Diagramm (object diagram)
• Kompositionsstruktur-Diagramm (composite structure diagram)
• Komponenten-Diagramm (component diagram)
• Verteilungs-Diagramm (deployment diagram)
• Paket-Diagramm (package diagram)
• Pofil-Diagramm (profile diagram)
Verhaltensdiagramme:
• Anwendungsfall-Diagramm (use case diagram)
• Aktivitäts-Diagramm (activity diagram)
• Interaktionsübersichts-Diagramm (interaction overview diagram)
• Sequenz-Diagramm (sequence diagram)
• Zustands-Diagramm (state diagram)
• Zeitverlaufs-Diagramm (timing diagram)
• Kommunikations-Diagramm (communication diagram)
Dabei ist es durchaus möglich, dass ein Diagramm grafische Elemente enthält, die per Definition
zu unterschiedlichen Diagrammtypen gehören.

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 7
Charakterisierung der grafischen Modellierungssprache: In der UML-Notation werden 4
Arten grafischer Konstrukte verwendet: Icons, 2-dimensionale Symbole, Pfade und Strings.
Im Sinne eines Graphen bilden zweidimensionale Symbole Knoten, die durch Pfade als Kanten
verbunden sein können. Strings besitzen (mit Ausnahme von Kommentaren) eine Syntax,
sie können singulär auftreten oder anderen Sprachelementen zugeordnet sein.
Die UML ist eine formale Sprache. Die Definition der Syntax (und evtl. der Semantik)
einer formalen Sprache erfolgt mit den Mitteln einer (formalen) Sprache. Diese Sprache
heißt Metasprache und dient zur Definition einer Objektsprache. Die UML wird auch als
Metasprache zur Modellierung von UML-Konzepten selbst eingesetzt (Metamodellierung).
1.3 Softwareentwicklungswerkzeuge
1.3.1 Klassifikation
Am Anfang steht die Werkzeug-Zeug-Metapher: ”
Werkzeuge” bearbeiten ”
Zeug”. ”
Zeug” sind
Daten und ”
Werkzeuge” sind Programme, die Daten verarbeiten und produzieren. So gesehen
sind alle Applikationen Werkzeuge. Als ”
CASE-Tools” bezeichnen wir speziell die Art
von Werkzeugen, die den Softwareentwicklungsprozess unterstützen (andere Berufsgruppen
setzen auch Werkzeuge ein).
Historisch gesehen waren Text-Editoren, Compiler bzw. Assembler für Programmiersprachen
und Programmverbinder die ersten Softwareentwicklungswerkzeuge. Dazu kamen Debugger
und diverse Werkzeuge zur Unterstützung des Testens von Software, z.B. Testdatengeneratoren.
Da der Softwareentwickler sich um die Anwendung jedes einzelnen Werkzeuges
selbst kümmern muss, bezeichnen wir diese Art von Werkzeugen als Einzelwerkzeuge. Die
Benutzung von Einzelwerkzeugen erfolgt in der Regel direkt im Betriebssystem über das
Graphical User Interface (GUI) oder über ein Kommandozeilen-Werkzeug. Zum Teil nutzen
Softwareentwickler noch heute Einzelwerkzeuge.
Die Technologie der Herstellung von Software entwickelte sich weiter und es wurden Programmierumgebungen
angeboten. Charakteristisch für Programmierumgebungen ist, dass der
Quellcode der Ausgangspunkt für die Erzeugung lauffähiger Anwendungen ist. Programmierumgebungen
sind typischerweise Menü-gesteuert, über Schaltflächen sind die Werkzeugfunktionen
aktivierbar. Beispiele sind Racket [Rac] oder SWI-Prolog [SWI].
Weiterentwicklungen von Programmierumgebungen bilden die Softwareentwicklungsumgebungen.
Die Aufgabe einer Softwareentwicklungsumgebung ist es, möglichst viele Aspekte
der Softwareentwicklung zu unterstützen. Softwareentwicklungsumgebungen beinhalten
Werkzeuge aus Programmierumgebungen, dazu üblicherweise Modellierungswerkzeuge, Konfigurierungswerkzeuge,
Werkzeuge zur Qualitätssicherung und zur Unterstützung des Projektmanagements.
Im Gegensatz zu Programmierumgebungen beginnt der Build-Prozess
meist bereits bei Modellen (auch grafischen Modellen, z.B. Klassendiagrammen). Diese Philosophie
gipfelt bisher in der ”
Modellgetriebenen Softwareentwicklung”. Modellierungswerkzeuge
verfügen in der Regel über grafische Editoren zur Erstellung und Modifikation von
Modellen und sind heute in der Lage, Programmcode automatisch zu erzeugen. Quellco-

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 8
de, der von Werkzeugen generiert wird, wird getrennt von handgeschriebenem Code (z.B. in
unterschiedlichen Verzeichnissen src und src-gen) verwaltet. Wichtig ist, dass bei einer Neugenerierung
von Quellcode aufgrund von Modelländerungen handgeschriebener Code nicht
zerstört wird. Wahlweise kann Code für unterschiedliche Zielsprachen (Java, C++, Ada, ...)
generiert werden.
Hervorzuheben im Bereich der Softwareentwicklungsumgebungen ist die Firma Rational
mit einer umfangreichen Produktpalette. Ein Überblick über Case-Tools ist in der Wikipedia
unter http://de.wikipedia.org/wiki/Computer-aided software engineering zu finden.
Eine konkrete und auch an der HTW Dresden in der Lehre eingesetzte Softwareentwicklungsumgebung
ist ObjectIF [Obj] von der Firma MicroTOOL.
1.3.2 Die Entwicklungsplattform Eclipse
In der Lehrveranstaltung wird Eclipse SDK 4.2 (Juno) als Entwicklungsplattform verwendet
(vgl. [Ecl]) . Eclipse ist keine Softwareentwicklungsumgebung im herkömmlichen Sinne. Es ist
eine Plattform, die zu einer komfortablen Softwareentwicklungsumgebung erweitert werden
kann.
Eclipse basiert auf einer ”
Plug-in”-Technologie, die es erlaubt, ein System zur Laufzeit
(d.h. ohne neu zu compilieren) um vorgefertigte Komponenten zu erweitern, wenn sie eine
vorgegebene Schnittstellenkonvention erfüllen. Das Konzept der Plug-ins kennt Erweiterungspunkte
(engl. extension points) und Erweiterungen (engl. extensions). Erweiterungen sind
Applikationen, die in Erweiterungspunkte eingehängt werden können. Solche Erweiterungen
können ihrerseits wieder Erweiterungspunkte anbieten.
Auch Eclipse selbst besteht bereits weitgehend aus Plug-ins. Was übrig bleibt, wenn man
alle Plug-ins wegnimmt, ist ein Kern. Andererseits ist auch das grafische Benutzerinterface
(GUI) von Eclipse ein Plug-in.
Abb. 1.3.1 zeigt die Architektur von Eclipse. Eclipse besteht aus Subsystemen, die auf
einer Runtime-Maschine arbeiten. Der Begriff Workbench wird in Eclipse für die Desktop-
Entwicklungsumgebung verwendet. SWT ist das (open source) Standard Widget Toolkit für
Java. JFace ist ein UI-Framework und enthält Klassen, die von UI-Plug-ins benötigt werden.
Team ist ein Subsystem zur Unterstützung der Versionsverwaltung. Help ist ein komfortables
Hilfesystem.
Die Abbildung 1.3.2 zeigt das GUI der um Plug-ins zur Unterstützung der UML erweiterten
Eclipse-IDE in einer Perspektive (Topcased Modeling), in der die Herstellung und
Bearbeitung von UML-Diagrammen unterstützt wird.
Während des Startvorganges von Eclipse ist vom Benutzer zunächst der Ort eines Arbeitsverzeichnisses
(Workspace) festzulegen (vgl. Abb. 1.3.3). Der Workspace kann später
während der Laufzeit geändert werden.
Eclipse bietet verschiedene Perspektiven an. Perspektiven bestehen aus Views (z.B. Package
Explorer, Hierarchy, Task List, Outline, Problems und andere) und Editoren sowie speziellen,
angepassten Menüs. Views sind jeweils genau einer Perspektive zugeordnet, Editoren
arbeiten Perspektiven-übergreifend. Anwendungen, die in Eclipse laufen, können eigene Per-

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 9
Abbildung 1.3.1: Architektur von Eclipse
spektiven besitzen.
Eclipse ist ein Java-Programm, enthält aber selbst kein Java Runtime Environment (JRE)
zu dessen Abarbeitung. Eclipse wird mit einer separat zu installierenden JRE verbunden, so
dass als Grundfunktionalität das Erstellen und Ausführen von Java-Programmen unterstützt
wird. Zum Kennenlernen von Eclipse wird die über Help erreichbare Sammlung von Tutorials
empfohlen (vgl. Abb. 1.3.4).
Ein spezielles Thema ist die Installation von vorgefertigten Plug-ins. Es gibt zwei Möglichkeiten:
1. Online aus bereitgestellten Update-Sites (z.B. der Entwicklungsumgebung des Eclipse-
Projekts) über den Update-Manager. Dieser ist im Menü Help Install New Software ...
→
zu finden (vgl. Abb. 1.3.5), ein Wizard wird gestartet. Nach der Auswahl werden im
nächsten Schritt die zu installierenden Komponenten angezeigt. Meist ist danach eine
Lizenzvereinbarung zu akzeptieren (z.B. GNU Lesser Gereral Public License).
2. als Download-Datei
Ein Feature ist eine aus Plug-ins bestehende Funktionalitäts-Einheit, die separat downloadbar
und installierbar ist. Features können hierarchisch organisiert werden.
Plug-ins können in Eclipse vom Anwendungsentwickler selbst programmiert werden. Dazu
kann das Plug-in Development Environment (PDE) genutzt werden.

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 10
Abbildung 1.3.2: Eclipse in der Topcased Modeling-Perspektive
Abbildung 1.3.3: Festlegung des ”
Workspace”

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 11
Abbildung 1.3.4: Eclipse Online Tutorials

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 12
1.3.3 Werkzeuge zur UML-Unterstützung
Es gibt eine Vielzahl von Werkzeugen, die die Erstellung grafischer Modelle für verschiedene
Modelltypen der UML unterstützen. Manche dieser Werkzeuge sind selbständige Applikationen,
manche sind Plug-ins zu Eclipse, und manche der Werkzeuge sind in beiden Formen
verfügbar. Eine Übersicht über solche Werkzeuge bietet
http://www.jeckle.de/umltools.htm.
TOPCASED
Wir verwenden in der Lehrveranstaltung das Entwicklungswerkzeug TOPCASED
( http://www.topcased.org/) in der Version 4.0.0 zur Unterstützung der objektorientierten
Modellierung (Version 4.1.0 bereits verfügbar). TOPCASED ist ein freies Werkzeug. Es arbeitet
als Plug-in in der Eclipse-Umgebung (ab Eclipse 3.6, Helios) und erfordert mindestens
eine JVM 1.5 . Eine Installation einer kompletten Umgebung Eclipse + TOPCASED ist
mittels Topcased-RCP-win32-4.0.0.zip möglich. Die nachträgliche Installation in Eclipse
ist über die Dateien und org.topcased.experimental-4.0.0.zip möglich. Die Installation
in Eclipse kann online erfolgen (vgl. Abb. 1.3.5).
TOPCASED unterstützt die Erstellung und Weiterbearbeitung von UML 2-Diagrammen.
Zur Erstellung eines neuen Modells ist zunächst über File → ”
UML Model with TOPCASED”
die ”
Topcased Modeling”-Perspektive auszuwählen (vgl. Abb. 1.3.6). Danach kann die Diagrammart
gewählt werden.
Folgende Diagrammarten sind verfügbar (vgl. Abb. 1.3.6):
• Aktivitäts-Diagramm (activity diagram)
• Komponenten-Diagramm (component diagram)
• Kompositionsstruktur-Diagramm (composite structure diagram)
• Verteilungs-Diagramm (deployment diagram)
• Sequenz-Diagramm (sequence diagram)
• Zustands-Diagramm (state machine diagram)
• Klassen-Diagramm (class diagram)
• Anwendungsfall-Diagramm (use case diagram)
Die Situation in einem Projekt ”
First Topcased” nach Anlegen eines ersten Klassen-Modells
zeigt Abb. 1.3.8.
Im Editor-Fenster ”
package Class-Model-1”kann nun mit der Zeichnung eines Diagramms
begonnen werden. Dazu müssen wir aber erst – im Kapitel 2 – die Diagramm- und Modellarten
kennenlernen.

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 13
Abbildung 1.3.5: TOPCASED-Installation
Abbildung 1.3.6: In TOPCASED unterstützte Modelltypen

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 14
Abbildung 1.3.7: In TOPCASED unterstützte Diagrammarten

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 15
Abbildung 1.3.8: Anlegen eines ersten UML-Klassenmodells

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 16
FUJABA
Ein weiteres interessantes Eclipse-Plug-in ist FUJABA:
ObjectIF
Das Werkzeug (http://www.microtool.de/objectif/de/, ObjectiF-7.0 Personal) wird ebenfalls
in der Softwaretechnik-Ausbildung an der HTW Dresden eingesetzt.
1.3.4 Diagrammaustausch
Obwohl die UML ein Standard ist, ist es nicht einfach, Diagramme zwischen unterschiedlichen
UML-Werkzeugen auszutauschen. Ein Diagrammaustausch kann auf der Basis von XMI
(XML Metadata Interchange) über Export- und Importfunktionen möglich gemacht werden.
1.3.5 Werkzeuge zur Versionsverwaltung
Das z.Z. wohl am häufigsten verwendete Werkzeug zur Versionsverwaltung ist Subversion
(svn). In Eclipse wird Subversion wiederum durch ein Plug-in verfügbar gemacht, wir verwenden
subclipse. Detailliert behandeln wir MERCURIAL im Kapitel 7. MERCURIAL ist
als Kommandozeilen-orientiertes Werkzeug und ebenfalls als Plug-in für Eclipse verfügbar
(vgl. Abb. 1.3.9).
Mercurial ist ein schnelles und robustes Versionsverwaltungssystem, welches in Python
”
geschrieben ist und beispielsweise von den MoinMoin und Mozilla Entwickler-Teams verwendet
wird.” Quelle: http://wiki.ubuntuusers.de/Mercurial.

1.3. SOFTWAREENTWICKLUNGSWERKZEUGE 17
Abbildung 1.3.9: Bereitstellung von Mercurial
1.3.6 Werkzeuge für das Build-Management
Eine weitere Gruppe von Werkzeugen, die in der Softwaretechnik benötigt werden, dienen
der Unterstützung des Build-Prozesses. Wir behandeln aus dieser Gruppe im Kapitel 7 die
Werkzeuge Ant und Maven.

Kapitel 2
Der Softwareentwicklungsprozess
2.1 Die Phasen im Softwareentwicklungsprozess
Der Softwareentwicklungsprozess – zunächst als Vorwärtsentwicklung betrachtet – lässt sich
als Menge von Aktivitäten definieren, die zur Produktion eines Softwaresystems führen (vgl.
[Som07], S. 94). Dabei sind folgende Fälle zu unterscheiden:
1. es handelt sich um eine komplette Neuentwicklung,
2. bestehende Systeme werden erweitert, verändert,
3. Systemkomponenten werden konfiguriert oder integriert.
Versuche, den gesamten Softwareentwicklungsprozess umfassend zu automatisieren, waren
bisher wenig erfolgreich. Grundlegende Abläufe, die alle Softwareentwicklungsprozesse gemeinsam
haben, sind:
• Analyse einschließlich der Spezifikation (Definition der Funktion und der Constraints)
• Entwurf und Implementierung (Erstellung der Software, die der Spezifikation genügt)
• Validation und Verifikation (Nachweise für Konsistenz und Äquivalenz von Modellen
und Programmen auf verschiedenen Entwicklungsstufen)
• Evolution (Weiterentwicklung, Anpassung an Kundenwünsche)
Kernaktivitäten der Analysephase sind die Problemdefinition, die Anforderungsanalyse, die
Anforderungsdefinition (mit Lastenheft und Pflichtenheft), Aufwands- und Risiko abschätzungen,
Festlegung des Vorgehens. Modelle und Spezifikationen sind das Ergebnis von Analysen.
Die Analysephase beinhaltet für die Entwicklung von Anwendungssystemen typischerweise
eine objektorientierte Analyse.
In der Entwurfsphase wird die Softwarearchitektur festgelegt. Die Entwurfsphase beinhaltet
für Objekt-basierte Systeme einen objektorientierten Entwurf.
18

2.2. LEBENSZYKLUS-MODELLE 19
2.2 Lebenszyklus-Modelle
Ein Vorgehensmodell ist eine sehr abstrakte Darstellung eines Softwareentwicklungsprozesses.
Der Softwareentwicklungsprozess wurde – als industrieller Fertigungsprozess – in der Vergangenheit
im Zusammenhang mit dem Lebenszyklus der Software beschrieben. Es entstanden
Lebenszyklus-Modelle.
Das Wasserfallmodell stellt die wesentlichen Prozessaktivitäten als eigenständige Phasen
dar (vgl. Abb. 2.2.1). Es wurde vom Vorgehen von andersartigen ingenieurtechnischen
Entwicklungen abgeleitet.
Anforderungsdefinition
System- u.
Softwareentwurf
Implementation
und Unit-Test
Integration und
Systemtest
Einsatz und
Wartung
Abbildung 2.2.1: Wasserfallmodell (Royce, 1970)
Der Ansatz der evolutionären Entwicklung verknüpft Aktivitäten, um schnell ein erstes
System zu schaffen. Dieses wird zyklisch unter Berücksichtigung von Kundeninformationen
verbessert. Ein typisches evolutionäres Lebenszyklusmodell ist das Spiralmodell nach B.W.
Boehm (vgl. Abb. 2.2.2).
Das V-Modell – nach seiner Form mit einem absteigenden und einem aufsteigenden Ast
benannt – stellt auf mehreren Abstraktionsstufen jeweils Konstruktions- und Überprüfungsaktionen
optisch sichtbar gegenüber (vgl. Abb. 2.2.3). Auf der obersten Ebene, in der Anforderungsanalyse
und Abnahmetest gegenübergestellt werden, spricht man bei der Überprüfung
von Validation, darunter von Verifikation.
Ein weiteres Modell ist die komponentenbasierte Softwaretechnik.
2.3 Prozessmodellierung und Projektmanagement
Ein Prozessmodell definiert den Ablauf der Software-Entwicklung als einen idealisierten
Prozess unter Anwendung formaler, struktureller Beschreibungsmittel (Metamodelle). Es
dient der Benennung, Beschreibung und Ordnung von Dokumenten, Aktivitäten oder Tätigkeiten
innerhalb der Software-Entwicklung. Der Prozess der Softwareentwicklung wird modelliert
und (soweit möglich) programmiert. Wesentliche Strukturelemente dabei sind Rollen,
Aktivitäten, Dokumente und Ressourcen.

2.3. PROZESSMODELLIERUNG UND PROJEKTMANAGEMENT 20
Abbildung 2.2.2: Spiralmodell (Boehm, 1988)
Das Projektmanagement (PM) umfasst alle Maßnahmen zur Planung, Verfolgung und
Qualitätssicherung einzelner Projekte und von Projektfamilien.
Zur Projektplanung zählen:
• Festlegung der Projektorganisation
• Personalplanung
• Meilenstein-/Terminplanung für alle Aktivitäten und Zuordnung zu Bearbeitern.
Die Projektverfolgung umfasst alle technisch-organisatorischen Maßnahmen zur Erreichung
der Projektziele. Dazu zählen die Verfolgung von Meilensteinen, Terminen und (Rest-) Aufwänden
sowie die Kontrolle der Aktivitäten der Bearbeiter. Grundlage der Projektmanagement-
Aktivitäten bilden Dokumente spezieller Typen, z.B. Aktivitätsgraphen, Balkendiagramme
usw. Gegenstand der Prozessmodellierung ist die Formalisierung und Computerunterstützung
des Softwareentwicklungsprozesses selbst. Neben Bausteinen und Ergebnissen müssen
Aufgaben und Ressourcen verwaltet werden. Wichtig ist dabei die Konsistenzsicherung.

2.4. QUALITÄTSSICHERUNG 21
2.4 Qualitätssicherung
2.4.1 Ziele und Maßnahmen
Abbildung 2.2.3: V-Modell
Die Qualitätssicherung umfasst die Planung/Durchführung von Qualitätssicherungsmaßnahmen
(QSM), die Kontrolle der Einhaltung von Standards (ISO 9000, ... ) und die Qualitätsbewertung
anhand von Metriken. Wesentliche Qualitätsmerkmale sind Korrektheit und
Robustheit. Die Begriffe sind relativ zur Spezifikation zu sehen: Korrekt kann ein Programm
nur relativ zu seiner Spezifikation sein, d.h. Korrektheit ist eine Ja-Nein-Entscheidung. Robust
kann ein Programm mehr oder weniger sein, insbesondere wird auch das Verhalten
außerhalb der Spezifikation betrachtet (vgl. Abb. 2.4.1) .
Abbildung 2.4.1: Korrektheit und Robustheit im Verhältnis zur Spezifikation
Weitere wichtige Qualitätskriterien sind Erweiterbarkeit, Wiederverwendbarkeit, Portabilität
und Verständlichkeit.

2.4. QUALITÄTSSICHERUNG 22
Es werden konstruktive und analytische QSM unterschieden (vgl. Abb. 2.4.2). Zu den
analytischen QSM zählen statische Analysen, der symbolische Test und dynamische Analysen
(das ”
eigentliche”Testen). Zu den statischen Analysen zählen vor allem die Kontrollfluss- und
Datenflussanalyse sowie die verschiedenen Verfahren zur Programmverifikation.
QSM
konstruktive
analytische
statische Analysen
(Compilertechnik)
Kontrollfluß- / Datenflußanalyse
Verifikation
dynamischer Test
(Testläufe in realer Umgebung)
Unittest / Integrationstest
Blackbox- / Whiteboxtest
diversifizierende Verfahren
:.
symbolischer Test
(Interpretation in künstlicher Umgebung)
Abbildung 2.4.2: Qualitätssicherungsmaßnahmen im Überblick
2.4.2 Testen
Das zustandsbasierte Testen von Klassen nach Turner und Robson ist eine Technik, die
auf der Modellierung von Klassen durch endliche Automaten basiert. Automaten werden zur
Generierung von Testfällen herangezogen.
Jeder Testfall umfasst
• die Erzeugung eines bestimmten Zustandes des Testobjekts,
• gefolgt vom Aufruf ( ”
Invocation”) einer Operation (Methode) und
• die Validierung des durch die Operation herbeigeführten Zustandes.
2.4.3 Validation und Verifikation
Bei der Verifikation werden formale (mathematische) Beweismethoden eingesetzt, um die
Korrektheit von Programmen zu beweisen. Dabei geht es um den Nachweis bestimmter
Programmeigenschaften, wobei eine Unterscheidung in sequentielle, parallele (Nutzung eines
gemeinsamen Speichers) und verteilte (lokale Speicher und Austausch von Nachrichten)
Programme vorgenommen wird. Es handelt sich um folgende Eigenschaften:

2.4. QUALITÄTSSICHERUNG 23
• Für sequentielle Programme:
– partielle Korrektheit: Wenn ein Ergebnis geliefert wird, erfüllt es die Spezifikation.
Das Programm muss nicht terminieren
– Nachweis der Termination (die totale Korrektheit eines Programms ist gegeben,
wenn ein partiell korrektes Programm immer terminiert)
– Es gibt keine Exceptions (unerwartete Programmabbrüche)
• Für parallele Programme:
– Interferenz-Freiheit:
– Deadlock-Freiheit
– Korrekt unter Fairness-Annahmen
Teile des Verifikationsprozesses sind automatisierbar.
Betrachten wir zunächst Verifikationsverfahren. Es gibt verschiedene Ansätze zur Verifikation:
• die operationale Methode (nur für sequentielle Programme sinnvoll)
• die axiomatische Methode

Kapitel 3
Anforderungsanalyse und
-definition
In der Phase der Anforderungsanalyse (Requirements Engineering) geht es um die Ermittlung
der
• Anforderungen der Benutzer,
• Anforderungen an das zu entwickelnde System,
• prozessbezogenen Anforderungen.
Während der Anforderungsanalyse muss die fachliche Konzeption erarbeitet werden, Implementierungsaspekte
spielen keine Rolle. Es geht auch (noch) nicht um die Verteilung der
Software auf verschiedene Computersysteme. Problematisch dabei ist, dass sich der Systemanalytiker
dem Auftraggeber verständlich machen kann.
Der Entwickler muss auch entscheiden, welche Art von System entwickelt werden soll:
Man unterscheidet transformative Systeme und reaktive Systeme (vgl. Abb. 3.0.1).
3.1 Das Pflichtenheft
Das Pflichtenheft umfasst (vgl. [Som07], S.168)
• Benutzeranforderungen an das zu entwickelnde System
• detaillierte Spezifikation der Systemanforderungen.
Benutzeranforderungen werden zunächst abstrakt und vorwiegend verbal beschrieben. Bei
den Systemanforderungen werden funktionale und nichtfunktionale Anforderungen spezifiziert.
Spezifikationen gelten als Vertrag zwischen AG und AN. Den Aufbau eines Pflichtenheftes
zeigt Abb. 3.1.1.Das Pflichtenheft wird verwendet von
• Systemkunden
24

3.2. SPEZIFIKATIONEN 25
Abbildung 3.0.1: Klassifizierung von Systemen aus Entwicklersicht
• dem höheren Management des Unternehmens
• den Systementwicklern
• Systemtestern
• der Systemwartung
In der LV müssen wir (Sudenten) uns wechselweise in die verschiedenen Rollen versetzen.
3.2 Spezifikationen
Anforderungsspezifikationen in natürlicher Sprache sind anfällig gegen Missverständnisse
( ”
Er winkt dem Mann mit dem Hut”).
3.2.1 Formale Beschreibungsmittel
Es gibt grafische Notationen.
3.3 Anwendungsfall-Analyse
Ein Anwendungsfall bzw. Use-Case (use case) beschreibt die Interaktionen zwischen Anwendern
und dem (zu entwickelnden) Anwendungssystem, die notwendig sind, um einen

3.3. ANWENDUNGSFALL-ANALYSE 26
Abbildung 3.1.1: Aufbau eines Pflichtenheftes
Arbeitsgang durchzuführen. Im Wesentlichen sind Anwendungsfälle und Akteure zu identifizieren.
Das Darstellungsmittel der UML für Anwendungsfälle sind Use-Case-Diagramme. Ein
Use-Case-Diagramm zeigt die Beziehungen zwischen Akteuren (actors) und Anwendungsfällen
in einem System. Das System wird durch ein Rechteck dargestellt, das die Systemgrenzen
zeigt. Ein Use-Case wird durch eine Ellipse dargestellt. Der Name des Anwendungsfalles wird
innerhalb oder unterhalb der Ellipse dargestellt. Ein Use-Case wird immer von einem Akteur
ausgelöst ( ”
getriggert”).
Im Use-Case-Diagramm können auch Beziehungen zwischen Anwendungsfällen gezeigt
werden.
Die -Beziehung definiert, dass ein Use-CAse das in einem anderen Use-Case
beschriebene Verhalten einschließt. Der Pfeil zeigt auf den Use-CAse, dessen Verhalten eingeschlossen
(importiert) wird. Zyklen bzgl. der -Beziehungen sind nicht erlaubt.
Die -Beziehung zwischen Use-Cases zeigt an, dass ein Use-Case durch einen
anderen Use-Case erweitert werden kann (aber nicht muss). Der Pfeil zeigt zu dem erweiternden
Use Case.
Generalisierungen/Spezialisierungen zwischen Use-Cases sind ebenfalls erlaubt.

3.3. ANWENDUNGSFALL-ANALYSE 27
Abbildung 3.3.1: UseCase-Diagramm für Aktivitäten einer Autovermietung

Kapitel 4
Objektorientierte Modellierung
4.1 Einführung
Die objektorientierte Modellierung umfasst die Entwicklungsphasen
• objektorientierte Analyse
• objektorientierter Entwurf
4.2 Klassenbildung
4.2.1 Klassen - Instanzen - Abstraktionen
Ein Objekt ist ein (abstrakter) Gegenstand oder ein Konzept mit klarer Abgrenzung und
präziser Bedeutung.
Beispiele: Kommissar Rex, das Fenster im Haus oben links, Herr Lutze, die Fa.
Mediatec GmbH, ...
Eine Klasse umfasst eine Menge von Objekten, die
• ähnliche Struktur und ähnliche Merkmale (sog. Attribute) besitzen,
• ähnliches Verhalten zeigen (Operationen bzw. ”
Methoden”),
• in Relationen zu Objekten anderer Klassen oder der gleichen Klasse stehen.
Eine Klasse kann durch Aufzählung der zu ihr gehörenden Objekte oder durch die Definition
der relevanten Eigenschaften der Objekte beschrieben werden. Zu einer Klasse gehörige
Objekte werden als Instanzen, Instanzobjekte oder auch Exemplare der Klasse bezeichnet.
Klassen werden benannt.
Beispiele: Hund, Fenster, Person, Firma, ...
Feststellungen
• Die Identifizierung und Benennung von Objekten hilft, die zu modellierende Welt zu
verstehen. Modellierte Objekte werden bei der programmtechnischen Realisierung typischerweise
zu Implementierungseinheiten, die zur Laufzeit existieren.
28

4.2. KLASSENBILDUNG 29
• Klassenbildung ist Abstraktion. Unter allen denkbaren bzw. tatsächlichen Eigenschaften
betrachteter Objekte wird von den für den Zweck der Betrachtung unwesentlichen
Eigenschaften abstrahiert (Abstraktion bedeutet das Weglassen von Unwesentlichem).
Abstraktion ist ein mächtiges Mittel zur Bewältigung von Komplexität.
• Objekte besitzen eine Identität und (insbesondere bzgl. der technischen Realisierung
auf einem Rechner) eine Lebensdauer. Mit der Klassendefinition wird zugleich eine
Vorschrift zur Bildung von Instanzen festgelegt. Der Vorgang der Erzeugung einer
Instanz wird Instanziierung genannt.
• Jedes Objekt gehört zu genau einer Klasse und ”
kennt” seine Klasse.
• Die konkrete Dekomposition eines Problems bzw. einer Domäne in Klassen und Objekte
ist subjektiv.
4.2.2 Attribute
Attribute beschreiben für eine Klasse die betrachteten strukturellen Merkmale, die alle zu
der Klasse gehörenden Instanzen in einer gewissen spezifischen Ausprägung besitzen.
Jedes einzelne Objekt der Klasse besitzt für jedes Attribut (Merkmal) eine individuelle
Ausprägung (Merke: Objekt - Merkmal - Ausprägung), die sich allerdings für ein Objekt im
Laufe der Zeit ändern kann. Ausprägungen sind Datenwerte eines in der Klassendefinition
vorbestimmten Datentyps. Der Wertebereich ist für jedes Attribut (eventuell implizit) in der
Klassendefinition festgelegt.
Jedes Objekt einer Klasse kann für ein bestimmtes Attribut zum selben Zeitpunkt einen
anderen Wert aus dem Wertebereich besitzen.
Die Gesamtheit der Werte (d.h. der Ausprägungen) der Attribute bestimmt den Zustand
eines Instanzobjektes zu einem bestimmten Zeitpunkt.
4.2.3 Operationen und Methoden
Operationen definieren das Verhalten von Objekten. Alle einer Klasse zugeordneten Objekte
verhalten sich in einer gewissen Weise gleichartig. Das Verhalten eines Objektes wird dabei
von individuellen Ausprägungen der Attribute mitbestimmt.
Die Verhaltensbeschreibung wird der Klassendefinition hinzugefügt, und nicht jedem Objekt
einzeln. Sie besteht aus einer Menge von Operationen und existiert damit einmal unabhängig
von der Anzahl vorhandener Instanzen, was bei der Implementation der Operationen
in einer objektorientierten Programmiersprache genauso umgesetzt wird.
Auf alle Objekte einer Klasse können die gleichen Operationen angewendet werden.
Die Funktionalität von Operationen wird in objektorientierten Sprachen durch Methoden
implementiert. Methoden können Parameter verarbeiten und liefern ein Objekt eines
bestimmten Objekttyps als Wert. Methoden können Zustandsänderungen eines Objektes
( ”
Seiteneffekte”) durch Überschreiben von Attributwerten bewirken. Operationen, die den

4.2. KLASSENBILDUNG 30
Zustand eines Objektes nicht verändern, heißen ”
Anfragen”. Ein ”
abgeleitetes Attribut” ist
eine Anfrage, die keine Argumente (d. h. Parameter) besitzt.
4.2.4 Grafische Notation für Klassen und Objekte
Die UML unterstützt eine grafische Notation zur Definition von Klassen und zur Spezifikation
ihrer Eigenschaften. Klassen werden innerhalb eines Klassendiagramms deklariert und
können in anderen Diagrammen verwendet werden.
Für die Darstellung von Klassen und Instanzen wird das Rechteck als geometrisches
Symbol verwendet. Eine waagerechte Linie separiert den Namen der Klasse von den Attributbeschreibungen
sowie diese von den Operationsbeschreibungen:
klassenname
visibility attributname : datentypname = defaultwert
.
visibility operationsname (argumentliste) : ergebnistyp
.
Die Argumentliste einer Operationsbeschreibung enthält durch Komma getrennte Parameterangaben.
Eine Parameterangabe wird als
〈 formaler Parameter〉:〈Parametertyp〉
notiert.
Die Reihenfolge der Einträge in den Feldern der Attributbeschreibungen und Operationsbeschreibungen
ist von Bedeutung. Innerhalb einer Liste können Einträge gruppiert werden.
Einer solchen Gruppierung kann ein in 〈〈 〉〉 eingeschlossenes Schlüsselwort vorangestellt
werden.
Die Felder zur Spezifikation von Attributen und Operationen können leer sein (dann
können auch die Trennlinien entsprechend entfallen). Empfehlungen zur Notation:
• Klassenname fett und zentriert im Feld notieren, Klassennamen beginnen mit Großbuchstaben
• Attribut- und Operationsnamen beginnen mit Kleinbuchstaben
Instanzobjekte werden wie Klassen durch Rechtecke repräsentiert. Anstelle des Klassennamens
wird im Rechteck der Instanzname (Benennung der Instanz) notiert, gefolgt von ”
:”,
gefolgt vom Klassennamen. Klassenname und Instanzname sind optional. Fehlt der Instanzname,
spricht man von einer ”
anonymen Instanz”. Die so gebildete Zeichenkette wird gemäß
UML 2 unterstrichen (siehe Abbildung 4.2.2). 1
Klassifizierungen bzw. Instanziierungen können innerhalb eines Klassendiagrammes notiert
werden (siehe Abbildung 4.2.3).
Diagramme, die ausschließlich Instanzobjekte darstellen, werden Objektdiagramme genannt.
1 In Topcased fehlt die Unterstreichung.

4.2. KLASSENBILDUNG 31
Window
Window
size : Area
visibility : Boolean
display ()
hide ()
Window
+ size : Area = (100,100)
# visibility : Boolean = invisible
+ default-size : Rectangle
# maximum-size : Rectangle
+ display ()
+ hide ()
+ create ()
Abbildung 4.2.1: unterschiedliche Ausprägungen der Darstellung einer Klasse
insttanzname
attributname =
...
: klassenname
wert
Abbildung 4.2.2: Darstellung eines Instanzobjektes
4.2.5 Sichtbarkeit von Attributen und Operationen
Benennungen ordnen Objekten und Operationen Namen zu. Namen sind immer innerhalb
einer gewissen Umgebung (Enviroment) sichtbar. Einem Attribut- oder Operationsnamen
kann in der Darstellung ein Kennzeichen zur Beschreibung der Sichtbarkeit (visibility) vorangestellt
werden:
+ public Es kann von außerhalb der Klasse (auch von
Nachfahren der Klasse) zugegriffen werden.
# protected Java: Zugriff ist grundsätzlich innerhalb des die
Klasse enthaltenden Paketes möglich. Von anderen
Paketen ist es nur Nachfahren möglich, auf ein
protected-Attribut oder eine protected-Methode
zuzugreifen.C++: Zugriff ist nur innerhalb der Klasse
und in allen Unterklassen möglich. protected
entspricht in Java private protected.
- private Java: Es ist von außerhalb des Objektes und von
Nachfahren des Objektes nicht möglich zuzugreifen.

4.3. ASSOZIATIONEN 32
klassenname
instanzname : klassenname
Abbildung 4.2.3: Instanziierungsrelation
Fehlt das Kennzeichen, wird damit angezeigt, dass die Sichtbarkeit nicht gezeigt wird. Es
bedeutet nicht, dass die Sichtbarkeit public oder undefiniert ist.
4.2.6 Klassen als Objekte
Attribute und Operationen, deren Scope-Bereich die Klasse (und nicht eine Instanz) ist, werden
als Klassen-Attribute bzw. Klassen-Operationen bezeichnet. In der grafischen Notation
im Klassensymbol werden die entsprechenden Einträge unterstrichen.
4.3 Assoziationen
4.3.1 Assoziation und Verknüpfung
Eine Assoziation ist eine abstrakte, d.h. nicht näher charakterisierte Beziehung zwischen zwei
(binäre A.) oder mehr Klassen. In der grafischen Darstellung werden die Symbole der beteiligten
Klassen durch eine durchgezogene Linie verbunden. Die Enden einer Assoziationslinie
können mit demselben Klassensymbol verbunden sein.
Assoziationen höherer Ordnung (ternäre, ... ) werden durch einen Rhombus dargestellt,
der durch Linien mit den Klassensymbolen verbunden ist. Assoziationen höherer Ordnung
sollten nach Möglichkeit vermieden werden. Sie sind schwerer zu verstehen, darzustellen und
zu implementieren als binäre Assoziationen.
Eine Verknüpfung (Link) ist ein Element einer Assoziation. Sie setzt eine Anzahl von
Objekten entsprechend der Assoziation in Beziehung. Ist durch eine binäre Assoziation eine
Klasse mit sich selbst verbunden, können unterschiedliche Objekte dieser Klasse verknüpft
sein oder auch ein Objekt mit sich selbst.
Der Pfad einer Assoziation kann (in seinem Hauptteil) beschriftet sein. Die Beschriftung
ist optional. Sie zeigt die Eigenschaften der Assoziation als Ganzes. Es gibt folgende Arten:
1. Assoziations-Namen
(string + ausgefülltes Dreieck)
Das Dreieck zeigt (falls vorhanden) mit seiner Spitze
die Richtung an, in der der Name zu lesen ist.

4.3. ASSOZIATIONEN 33
2. Assoziations-Klassensymbol
Eine Assoziation kann wie Klassen Eigenschaften besitzen.
Dargestellt wird das durch ein Klassensymbol, das mit
dem Pfad der Assoziation durch eine gestrichelte Linie
verbunden ist.
Falls ein Assoziations-Name und eine Assoziations-Klasse angegeben sind, müssen die Namen
übereinstimmen.
Beispiele:
1. Abb. 4.3.1 zeigt eine binäre Assoziation.
Person
name
vorname
hat_Mutter
Person
name
vorname
Person
name
vorname
hat_Mutter
Abbildung 4.3.1: binäre Assoziation
Eine binäre Assoziationn in Topcased zeigt Abb. 4.3.2 .
Abbildung 4.3.2: binäre Assoziation in TOPCASED
2. Abb. 4.3.3 zeigt eine Verknüpfung (Link) zwischen Instanzen der Klasse Person.

4.3. ASSOZIATIONEN 34
:Person
name = Müller
vorname = Martin
hat_Mutter
:Person
name = Müller
vorname = Martina
Abbildung 4.3.3: Verknüpfung
3. In Topcased können Objekte und Klassen gemeinsam in einem Diagramm dargestellt
werden. Die Zugehörigkeit der Objekte zu Klassen ist aus dem Klassennamen im Objektdiagramm
ersichtlich, kann aber auch durch eine Abhängigkeitsbeziehung (dependency)
kenntlich gemacht werden (vgl. Abb. 4.3.4).
Abbildung 4.3.4: Klassen und Objekte in einem Klassendiagramm dargestellt
4. Abb. 4.3.5 zeigt eine ternäre Assoziation: Personen (die in der Rolle eines Programmierers
tätig sind) verwenden in Projekten Programmiersprachen.
4.3.2 Rollen und Multiplizität
In einer Assoziation können die beteiligten Klassen Rollen spielen. An den Enden des die
Assoziation kennzeichnenden Pfades können jeweils der Rollenname der Klasse und eine
Kardinalität notiert werden.
Durch die Angabe einer Kardinalität wird die Multiplizität beschrieben. Die Angabe
erfolgt durch die Aufzählung von Bereichen, die durch Komma getrennt werden. Eine Bereichsangabe
hat die allgemeine Form untere-grenze .. obere-grenze. Ein * kann für eine nicht

4.3. ASSOZIATIONEN 35
Projekt
Programmiersprache
Person
Abbildung 4.3.5: ternäre Assoziation
negative ganze Zahl zur Kennzeichnung einer nach oben offenen Grenze gesetzt werden.
Beispiele
7, 10, 1..3
0..∗
∗
1..∗
Ein Klassendiagramm, mit Rollen (Arbeitgeber, Arbeitnehmer, Vorgesetzter, Unterstellter),
Multiplizität und einer Assoziationsklasse zeigt Abbildung 4.3.6.
Firma
Job
* 1..* Person
AG
AN
Unterstellter
Job
gehalt
*
Vorgesetzter
0..1
Leitet
Abbildung 4.3.6: Klassendiagramm mit Assoziationsklasse
Abbildung 4.3.7 zeigt zusammengefasst das Metamodell für binäre Assoziationen.
klasse
card(
R2 ) assoziationsname card( R1 )
rollenname ( R2 )
rollenname ( R1 )
Abbildung 4.3.7: Metamodell für Assoziationen
klasse
4.3.3 Aggregation und Komposition
Aggregation Eine Aggregation ist eine Sonderform der Assoziation mit zusätzlicher Semantik
und bedeutet eine Teil-Ganzes”-Beziehung. Objekte, die Komponenten einer Sache
”

4.4. GENERALISIERUNG UND SPEZIALISIERUNG 36
repräsentieren, sind mit einem Objekt verknüpft, das die Komponentengruppe (das Aggregat)
repräsentiert. Aggregation ist über eine beliebige Anzahl von Ebenen hinweg möglich:
Eine Komponente kann ihrerseits Aggregat weiterer Komponenten sein. Die Relation ”
Aggregation”
ist transitiv und antisymmetrisch.
Darstellung: Hohle Raute an dem Ende der Assoziation, das dem Aggregat zugeordnet
ist.
Komposition Die Komposition wird als enge” Aggregation verstanden, die eine Verbindung
der Teile mit dem Ganzen auch hinsichtlich der Lebenslinie” bedeutet. Attribute
”
”
einer Klasse können als Komposition zwischen der Klasse und den Klassen (bzw. Typen) der
Attribute verstanden werden.
Darstellung: Ausgefüllte Raute anstelle der hohlen Raute.
Beispiel (Abbildung 4.3.8): Die Punkte eines Polygons können auch ohne Polygon existieren
(Aggregation), die Textur hat nur im Zusammenhang mit dem Polygon einen Sinn
(Komposition).
Polygon
1
1
hat
+ Eckpunkte
3..*
{ordered}
Punkt
x : real
y : real
1
- Verbund
Grafik-Verbund
farbe
texture
schwärzung
Abbildung 4.3.8: Aggregation und Komposition
Aggregationen (und Kompositionen) können ggf. in Form eines Aggregationsbaumes dargestellt
werden.
4.4 Generalisierung und Spezialisierung
4.4.1 Die Inklusionsrelation
Generalisierung und Spezialisierung sind Vorgänge die eine Taxonomie-Relation (Inklusionsrelation)
zwischen (mindestens) einer allgemeineren und (mindestens) einer spezielleren Entität
etablieren. Eine speziellere Entität besitzt alle Eigenschaften der allgemeineren Entität
(Inklusion) sowie zusätzliche und/oder anders ausgeprägte Eigenschaften.
Generalisierung und Spezialisierung werden zunächst auf Klassen angewendet (Anwendung
für Pakete und Use-Cases werden separat behandelt).

4.4. GENERALISIERUNG UND SPEZIALISIERUNG 37
Die Inklusionsrelation ist gerichtet. Sie ist transitiv und antisymmetrisch. Eine an der
Relation beteiligte allgemeinere Klasse wird als Superklasse (Oberklasse), eine speziellere
Klasse als Subklasse (Unterklasse) bezeichnet.
Sprechweise:
Ein Hund ist ein” (is-a) Säugetier. Die Klasse Hund ist Subklasse zur
”
Klasse Säugetier. Die Klasse
Säugetier ist Superklasse zur
Klasse Hund.
Ein Student ist eine” Person. Die Klasse Student ist Subklasse
”
zur Klasse Person. Die Klasse
Person ist Superklasse zur Klasse
Student.
Eine Subklasse hat gegenüber der zugeordneten Superklasse veränderte Eigenschaften.
Dabei kann es sich um
• zusätzliche Attribute,
• zusätzliche Operationen,
• Modifikationen bzw. spezielle Ausprägungen von Operationen,
• Modifikationen von Festlegungen für Anfangswerte von Attributen
handeln.
Durch Generalisierung bzw. Spezialisierung entstehen bzgl. der Inklusionsrelation zyklenfreie,
gerichtete Graphen.
In einer Klassenhierarchie (Darstellung siehe Abbildung 4.4.1) kann eine Klasse nur eine
Superklasse haben. In einer Klassenheterarchie kann eine Klasse mehrere Superklassen haben.
Eine Klasse mit mehr als einer Superklasse heisst Vereinigungsklasse.
klassenname
(Superklasse)
klassenname klassenname (Subklassen)
Abbildung 4.4.1: Klassenhierarchie
Ein Dreieck stellt im Klassendiagramm die Generalisierungs-/Spezialisierungsbeziehung dar.
Die Spitze des Dreiecks zeigt zur Superklasse.
Constraints Für eine Generalisierung können Constraints angegeben werden (neben dem
Dreieck in geschweiften Klammern notiert). Vordefinierte alternativ verwendbare Angaben
sind overlapping vs. disjoint sowie complete vs. incomplete.

4.4. GENERALISIERUNG UND SPEZIALISIERUNG 38
Sind alle Subklassen angegeben (die Anordnung ist vollständig, es werden keine weiteren
Subklassen erwartet) wird complete angegeben, andernfalls incomplete. Der implizit angenommene
Standardwert (d.h. falls die Angabe fehlt) ist incomplete. Kann ein Nachkomme
von mehr als einer Subklasse abgeleitet werden, kann dies durch overlapping gekennzeichnet
werden. Das Gegenteil kann durch disjoint gekennzeichnet werden.
Beispiel (Abbildung 4.4.2): Fahrzeuge können sowohl nach der Antriebsart als auch nach
dem Medium, auf bzw. in dem sie sich bewegen, spezialisiert werden. Ein Lastkraftwagen
(LKW) ist demnach ein Fahrzeug, das motorgetrieben ist und sich auf dem Land bewegt.
{overlapping}
Antrieb
Antrieb
Fahrzeug
Medium
Medium
{overlapping}
Windgetrieben
F.
Motorgetrieben
F.
Land-
F.
Wasser-
F.
LKW
Segelboot
Amphibienf.
Abbildung 4.4.2: Mehrfachvererbung
4.4.2 Vererbung und Delegation
Als Vererbung (inheritance) wird die Weitergabe der Beschreibung von Eigenschaften (Attribute,
Operationen, Standardinitialwerte) einer Klasse an eine Subklasse bezeichnet. Die
Eigenschaften bzgl. der Inst. der Klasse werden entlang der Inklusionsrelation (an die Subklasse)
vererbt. Tatsächlich müssen die Eigenschaften einer Superklasse bei der Subklasse
nicht noch einmal beschrieben werden, sie gelten implizit. Von besonderem Interesse ist,
dass das auch bzgl. der Implementation gilt.
Durch Mehrfachvererbung ist es möglich, dass eine Klasse, die mehrere Oberklassen hat,
Merkmale von allen Oberklassen erbt.
Ein Merkmal aus der gleichen Vorfahrenklasse, das in mehr als einem Pfad gefunden
wird, wird nur einmal geerbt, es handelt sich um das gleiche Merkmal.
Konflikte zwischen parallelen Definitionen führen zu Mehrdeutigkeiten, die bei der programmtechnischen
Realisierung gelöst werden müssen.
Delegation ist ein Implementierungsmechanismus, mit dessen Hilfe ein Objekt eine Operation
auffängt und an ein anderes Objekt zur Ausführung sendet.
Mittels Delegation kann fehlende Mehrfachvererbung umgangen werden.

4.4. GENERALISIERUNG UND SPEZIALISIERUNG 39
4.4.3 Polymorphie
Wörtlich: Vielgestaltigkeit. Eine durch Namen und Signatur spezifizierte Operation kann
in unterschiedlichen (abgeleiteten) Klassen durch unterschiedliche Methoden implementiert
sein.
Signatur: Form eines Merkmales, d.h. Anzahl und Typen der Argumente einer
Operation sowie ggf. der Typ des Rückgabewertes.
Beispiel:
Wir betrachten Unruhen (mobiles) und möchten mit einer Operation balancedp() bestimmen,
ob sich eine Unruhe im Gleichgewicht befindet. Abstrahiert man von den physikalischen
Gegebenheiten, handelt es sich bei den Unruhen um eine spezielle Art gewichtsbalancierter
Bäume (im Unterschied zu höhenbalancierten Bäumen). Wir modellieren eine Klasse
Mobile mit den Merkmalen ”
linker Nachfolger” (lsucc) und ”
rechter Nachfolger” (rsucc).
Die Merkmale sind vom Typ Mobile, d.h. entsprechende Variablen können Referenzen auf
Objekte vom Typ Mobile aufnehmen. Die Armlängen (links bzw. rechts von der Aufhängung)
spielen zunächst keine Rolle. Es wird angenommen, sie sind für jede Unruhe links und
rechts gleich groß.
Abbildung 4.4.3: Ein Mobile (Unruhe)
Jede Unruhe verwaltet ein Objekt vom Typ Node. Das Attribut key der Klasse Node ist
vom Typ int (ganze Zahl) und dient zur Identifikation einer Unruhe (die Werte entsprechen
den blauen Zahlen in Abb. 4.4.3). Für Unruhen ohne Nachfolger (d.h. für Blattknoten im
Baum der Unruhen) enthält das Attribut weight das Gewicht (die Werte entsprechen den

4.4. GENERALISIERUNG UND SPEZIALISIERUNG 40
grünen Zahlen in Abb. 4.4.3). Unruhen mit Nachfolgern besitzen kein Gewicht. Bei Unruhen
mit Nachfolgern (inneren Knoten) wird weight der Wert 0 zugewiesen.
Abbildung 4.4.4: Mobile mit unterschiedlichen Stablängen
Unruhen mit Nachfolgern senden Nachrichten an die Nachfolger, um derenGewicht zu
erhalten, und addiert diese.
Die Klasse MobileA spezialisiert die Klasse Mobile in der Weise, dass die Arme einer Unruhe
unterschiedlich lang sein können. Zur Speicherung der Armlängen dienen die Attribute
larm und rarm. Die Attribute lsucc und rsucc werden von Mobile an MobileA vererbt. Die
Methode balancedp() kann auf Instanzen von Mobile (binärer gewichtsbalancierter Baum)
und von MobileA angewendet werden. Für jeden dieser Fälle wird in Abhängigkeit vom Typ
des aktuellen Objekts allerdings eine andere Methode ausgeführt (siehe Abbildung 4.4.5). Da
in diesem Fall zur Laufzeit entschieden wird, welche Methode tatsächlich ausgeführt wird,
heißt diese Art der Polymorphie ”
dynamische Polymorphie”.
4.4.4 Abstrakte und konkrete Klassen
abstrakte Klasse: Klasse, die selbst keine direkten Instanzen besitzt, deren Nachkommen
aber direkte Instanzen besitzen.
konkrete Klasse: Klasse, die direkte Instanzen besitzen kann ( ”
instanziierbare Klasse“).
Nur konkrete Klassen können Blattklassen im Vererbungsbaum sein (siehe Abbildung
4.4.6)!
Eine abstrakte Klasse kann sowohl abstrakte Operationen als auch nicht abstrakte Operationen
definieren.
Eine Operation kann abstrakt sein. Das ist der Fall, wenn die Klasse, die die Operation
deklariert, diese Operation nicht als Methode implementiert. Eine Kennzeichnung im Klassensymbol
erfolgt entweder durch den Zusatz {abstract} oder dadurch, dass die Signatur

4.4. GENERALISIERUNG UND SPEZIALISIERUNG 41
Abbildung 4.4.5: Dynamische Polymorphie
der Operation in italics gesetzt wird. Ein Auftreten der Signatur der Operation in einer abgeleiteten
Klasse (ohne Kennzeichnung als abstrakte Operation) zeigt an, dass die abgeleitete
Klasse eine Methode für die Operation definiert.
4.4.5 Parametrisierte Klassen
Eine parametrisierte Klasse ist ein Template, d.h. eine Beschreibung für eine Klasse mit einem
oder mehreren formalen Parametern. Ein solches Template definiert eine Familie von
Klassen, wobei eine Klasse durch Bindung aller formalen Parameter an aktuelle Werte spezifiziert
wird. Eine parametrisierte Klasse ist also keine direkt nutzbare Klasse. Sie besitzt
ungebundene Parameter, und erst durch deren Bindung entsteht eine Klasse.
Ein kleines gestricheltes Rechteck wird dem die Klasse symbolisierenden Rechteck auf
der rechten oberen Ecke überlagert. Das Rechteck enthält eine Liste der formalen Parameter
der Klasse und gegebenenfalls deren Implementationstypen.
Name, Attribute und Operationen der parametrisierten Klasse erscheinen normal im
Klassensymbol und können Vorkommen der formalen Parameter enthalten.
Beispiel: Keller von Elementen eines beliebigen Typs T (siehe Abbildung 4.4.7)
Durch Bindung der formalen Parameter eines Templates für eine parametrisierte Klasse
an aktuelle Parameter entsteht eine Klasse.
Beispiel: (siehe Abbildung 4.4.8)
Im Beispiel kann T an Integer gebunden werden, um einen Stack für Integer-Werte
zu realisieren. Die UML sieht für die Bindung folgende Notation vor:
< 〈parametername〉→〈aktuellerparameter〉 > vor.

4.4. GENERALISIERUNG UND SPEZIALISIERUNG 42
Hat_Subklassen
Subklasse
Subklasse
Klasse
1..* 1..*
Hat_Subklassen
Konkrete
Klasse
Abstrakte
Klasse
1
Superklasse
1
Superklasse
Konkrete
Nicht-Blattklasse
Konkrete
Blattklasse
Abbildung 4.4.6: Metamodell ”
abstrakte u. konkrete Klassen”
Stack
T
empty () : boolean
push (x : T)
pop ()
top () : T
Abbildung 4.4.7: Parametrisierte Klasse Stack

4.4. GENERALISIERUNG UND SPEZIALISIERUNG 43
Stack < Integer >
oder alternativ
Stack
T
empty () : boolean
push (x : T)
pop ()
top () : T
>
Stack
Abbildung 4.4.8: Bindung für eine parametrisierte Klasse

4.5. DYNAMISCHE MODELLIERUNG 44
4.5 Dynamische Modellierung
4.5.1 Instanzen als Laufzeitobjekte
Ein Objekt ist als Instanz einer Klasse ein Laufzeitobjekt (in der Ebene M0 ). Es belegt bei
der programmtechnischen Realisierung Speicherplatz und hat eine gewisse Lebensdauer.
Auch Klassen können als Laufzeitobjekte behandelt werden, man spricht dann von Klassenobjekten.
Objekte können benannt werden. Das bedeutet, dass eine Assoziation zwischen einem
Namen und einer Objektreferenz aufgebaut wird. Namen sind einem Sichtbarkeitsbereich
(engl. scope) zugeordnet. Wir unterscheiden verschiedene Sichtbarkeitsbereiche:
• global
• Paket-lokal
• Klassen-lokal
• Methoden-lokal
Im Laufe der Zeit können sich Assoziationen ändern, d.h. ein Name kann mit einer Referenz
auf ein anderes Objekt assoziiert werden (z.B. Wertveränderung einer Variablen).
Typkompatibilität bedeutet, dass einem Bezeichner, der mit einer Referenz auf ein Objekt
einer Klasse assoziiert ist, ein Objekt einer anderen Klasse ( ”
Referenzklasse”) zugeordnet
werden darf. Typkompatibilität wird in der UML nicht speziell unterstützt. Welche Typen
kompatibel sind, hängt von der verwendeten objektorientierten Programmiersprache ab.
Die Erzeugung eines Objektes kann auf zweierlei Weise erfolgen:
• statisch, mit der Initialisierung des Anwendungssystems
• dynamisch, durch Anwendung eines Konstruktors der Klasse während der Ausführung
einer Methode.
Das Erzeugen und Löschen von Objekten wird in Sequenzendiagrammen dargestellt. Das
Sequenzendiagramm zeigt den Programmablauf einer Methode und berücksichtigt dabei die
Interaktion mit anderen Objekten.
In objektorientierten Programmiersprachen kann der Zeitpunkt zum Löschen eines Objektes
selbst bestimmt werden (z.B. Java).
Objektzustände
vordefinierte Ausprägungen für Zustände von Objekten sind:
• nicht existent (eigentlich ein Widerspruch!)
• existent: Für ein Objekt wurde Speicher erfolgreich angefordert, die Zuordnung
der Methoden aus der Klassendefinition war erfolgreich.
• initialisiert

4.5. DYNAMISCHE MODELLIERUNG 45
• deinitialisiert
• gelöscht
Für persistente Objekte werden zusätzliche Zustände erklärt: ausgelagert, im-
Speicher.
4.5.2 Interaktionsmodelle
Interaktionsmodelle werden in Interaktionsdiagrammen dargestellt. Die UML stellt zur Darstellung
von Interaktionsmodellen folgende Diagrammarten bereit:
• Sequezdiagramm
• Kommunikationsdiagramm
• Timing-Diagramm
• Interaktionsübersichtsdiagramm
Sequenzdiagramm Das Sequenzdiagramm dient der Visualisierung des Interaktionsmodells.
Es beschreibt Interaktionen zwischen einer ausgewählten Menge von Objekten durch
den Austausch von Nachrichten. Die Interaktionen zwischen Objekten gehen stets von Objekten
oder Prozessen aus. Das Sequenzdiagramm berücksichtigt den zeitlichen Ablauf und
zeigt die zeitliche Abfolge von Interaktionen in einer zeitlich begrenzten Situation. Dargestellt
werden: Objekte, Zeitachse (jedem Objekt wird eine vertikale Lebenslinie zugeordnet),
Nachrichtenaustausch in Form von Methodenaufrufen. Zeitaspekte werden durch zusätzliche
Bedingungen dargestellt.
Symbol zum Erzeugen eines Objektes: (siehe Abbildung 4.5.1)
new Klassenname()
neuObjekt : Klassenname
Abbildung 4.5.1: Erzeugen eines Objektes
4.5.3 Statechart-Modelle
In der UML werden Zustandsautomaten” zur Modellierung des Verhaltens von Objekten des
”
Typs Classifier eingesetzt. Zustandsautomaten basieren auf den von D. Harel eingeführten
Statecharts”. Ein Zustandsautomat (das ist ein endlicher Automat) ist ein Graph, bestehend
aus Zuständen und Transitionen, der die Reaktion eines Objektes einer Klasse auf den
”
Empfang von äußeren Stimuli” beschreibt. Ein Zustandsautomat ist einer Klasse oder einer
”
Methode zugeordnet.

4.5. DYNAMISCHE MODELLIERUNG 46
Ein Zustand (engl. state) ist die Verfassung (im Verlaufe des Lebens) eines Objektes, in
der es einer Bedingung genügt, eine Aktivität ausführt (andauernd) oder auf ein Ereignis
wartet. Ein Objekt verweilt eine endliche Zeit in einem Zustand. Nicht jede Änderung eines
Wertes einer Instanzvariablen wird als Zustandsänderung betrachtet, es gibt sogenannte
verallgemeinerte Zustände”.
”
Eine Transition ist eine durch ein Ereignis verursachte Zustandsänderung eines Objektes.
Ereignisse (engl. events) sind bemerkenswerte Vorkommnisse”. In Bezug auf Statecharts
”
ist ein Ereignis ein Vorkommnis, das eine Transition auslöst. Es hat keine Dauer. Der Zustand
eines Objektes bestimmt die Reaktion des Objektes auf ankommende Ereignisse. Reaktionen
können Aktionen und/oder Zustandsänderungen sein. Wenn ein Ereignis empfangen wird,
hängt der nächste Zustand des Objekts sowohl vom aktuellen Zustand als auch vom empfangenen
Ereignis ab. Ein neu erzeugtes Objekt befindet sich zunächst in einem Initialzustand.
Aktionen (engl. actions) sind atomar und nicht unterbrechbar. Ein Zustand kann mit
einer andauernden Aktivität verbunden sein. Eine solche Aktivität wird selbst als Zustandsautomat
ausgedrückt. Eine andauernde Aktivität kann als Paar von Aktionen ausgedrückt
werden.
Notation: Ein Statechart (Zustands-Diagramm) repräsentiert einen Zustandsautomaten.
Zustände werden durch Zustandsymbole (Rechteck mit abgerundeten Ecken) repräsentiert.
Sie können einen Namen beinhalten und optional durch horizontale Linien in bis zu drei
Bereiche geteilt werden. Spezielle Symbole existieren für den Startzustand und Endzustände.
Transitionen werden durch Pfeile dargestellt, die Zustandssymbole verbinden (vgl. Abb.
4.5.2). Ereignisse, die Zustandsübergänge auslösen, werden als Beschriftung an die zugehörigen
Pfeile geschrieben. Übergänge ohne Ereignisbeschriftung werden automatisch ausgelöst,
sobald die mit dem Zustand verbundenen Aktionen/Aktivitäten abgeschlossen sind.
Zustandsübergänge können an Bedingungen geknüpft sein. Eine Bedingung muss erfüllt sein,
damit ein Ereignis tatsächlich einen Zustandswechsel bewirkt.
Syntax: event(argument ...) [ bedingung ]/ operation(argument ...)
zustand
< transition >
Abbildung 4.5.2: Transition
zustand
Alle von einem Zustand ausgehenden Transitionen müssen unterschiedlichen Ereignissen entsprechen!
Es darf keine von Endzuständen ausgehenden Transitionen geben.
Komposite Zustände
Ein Zustand kann mittels
• and-Relation in parallele Teilzustände und/oder
• or-Relation in sich gegenseitig ausschließende sequentielle Teilzustände
dekomponiert werden. Eine Verfeinerung eines Zustandes ist nur auf einem dieser beiden
Wege möglich. Bei parallelen, konkurrierenden Teilzuständen wird das Zustandssymbol durch

4.5. DYNAMISCHE MODELLIERUNG 47
stornieren()
[reserveirtePlaetze>1]
OhneReservierung
entry /ruecksetzen()
reservieren()
stornieren()
[reserveirtePlaetze=1]
Teilweise-
Reserviert
reservieren()
[freiePlaetze>1]
flug
Einrichten()
flugStreichen()
stornieren()
reservieren()
[freiePlaetze=1]
schliessen()
Ausgebucht
Geschlossen
schliessen()
Abbildung 4.5.3: Flugreservierungs-System
gestrichelte Linien in weitere Abschnitte unterteilt.
Pseudozustände
Es gibt verschiedene Arten von Pseudozuständen:
Symbol Zustand Beschreibung
Startzustand
(Initial)
Entscheidung
(Choice)
Betreten des Zustandsautomaten, kein Trigger,
keine Bedingung
Kreuzung
(Junction)
Terminator
(Terminate)
Austrittspunkt
(Exit Point)
mindestens je eine eingehende und ausgehende
Transition, dient der Vereinfachung
bricht die Ausführung des Zustandsautomaten
ab, Ende der Lebensdauer
Bei der Realisierung von Zustandsdiagrammen mittels Topcased werden unterschiedliche
Arten von Events unterschieden (vgl. Abb. 4.5.6). Der Übergang von einem Zustand über
einen Pseudozustand zu einem weiteren Zustand muss ohne Zeitverbrauch erfolgen. Das
System darf sich nicht in einem Pseudozustand aufhalten. Der Startzustand ist ebenfalls ein
Pseudozustand.

4.5. DYNAMISCHE MODELLIERUNG 48
Abbildung 4.5.4: Modell einer Klimaanlage

4.5. DYNAMISCHE MODELLIERUNG 49
Abbildung 4.5.5: Unterzustände

4.5. DYNAMISCHE MODELLIERUNG 50
Abbildung 4.5.6: Zustandsdiagramme in Topcased

4.5. DYNAMISCHE MODELLIERUNG 51
4.5.4 Aktivitäts-Diagramme
Das Aktivitäts-Diagramm ist eine spezielle Art des Zustandsdiagramms, das hauptsächlich
Aktivitäten/Aktionen und Übergänge des Steuerflusses zwischen diesen zeigt. Eine Aktivität
ist einem Zustand zugeordnet und repräsentiert eine andauernde interne Aktion.
Eine Aktivität wird durch einen gerichteten Graphen modelliert. Knoten können Aktionsknoten,
Kontrollknoten oder Objektknoten sein. Durch Kanten wird das Steuerflussmodell
repräsentiert.
Aktionen sind die kleinsten ausführbaren Funktionseinheiten innerhalb einer Aktivität.
Eine Aktion kann
• ein elementarer Verarbeitungschritt oder
• ein Aktivitätsaufruf
sein.
Eine Aktivität kann Kontrollknoten enthalten:
• Start- und Endknoten
Start- und Endzustand werden wie im Zustandsdiagramm dargestellt.
• Entscheidung und Zusammenführung
• Splitting und Synchronisation
Transitionen können geteilt und synchronisiert werden (Parallelität).
Abbildung 4.5.7: Darstellung von Aktionen (oben) und Aktivitäten (unten) in einem Aktivitätsdiagramm
(Topcased)
Symbole zur Darstellung von Aktivitäten (siehe Abbildung 4.5.7) enthalten eine Aktionsbeschreibung
in Form eines Namens oder eines Freitextes. Dabei kann auch eine Algorithmenbeschreibung
in Form von Pseudo- oder Programmcode vorliegen. Bedingungen werden
in Form boolescher Ausdrücke notiert. Sie werden an die die Aktivität verlassenden Transitionen
geschrieben. Es können auch explizit Verzweigungspunkte in Form kleiner Rauten
verwendet werden, von denen die durch Bedingungen unterschiedenen Transitionen ausgehen.

4.5. DYNAMISCHE MODELLIERUNG 52
[x 0] [x 0]
oder
[x 0]
[x 0]
Abbildung 4.5.8: Entscheidung, Kontrollknoten Entscheidung
Teilung
Synchronisation
Abbildung 4.5.9: Aufsplitten des Kontrollflusses und Synchronisation
Aktivitäten können sich auf Objektzustände beziehen (Abbildung 4.5.10). Diese Möglichkeit
gibt es allerdings in UML 2 nicht mehr.
aktivität1()
aktivität2()
object
[ zustand ]
Abbildung 4.5.10: Einbeziehung von Objektzuständen
Ein gestrichelter Pfeil, der von einer Aktivität zu einem Objekt führt, kennzeichnet einen
aus der Aktivität resultierenden Objektzustand. Ein gestrichelter Pfeil, der von einem Objekt
zu einer Aktivität führt, kennzeichnet, dass die Aktivität den Objektzustand voraussetzt.
Beispiel: Kfz-Rücknahme innerhalb einer Anwendung Kfz-Vermietung (siehe Abbildung
4.5.11).
Als Beispiel für ein in Topcased erstelltes Aktivitätsdiagramm wird die Einladung zu
einer Feier betrachtet (vgl. Abb. 4.5.12). Die Einladung ist ein Eingangsparameter.
Ein Aktivitäsdiagramm kann einem Use-Case zugeordnet werden. Wie das in Topcased
erfolgt, zeigt Abb. 4.5.13.

4.5. DYNAMISCHE MODELLIERUNG 53
Kunde
auswählen
Kunde
Vertrag
eines Kunden
auswählen
Vertrag
auswählen
Vertragseinhaltung
prüfen
Vertrag
[Kfz übergeben]
Vertrag
[Kfz zurück]
Kfz zurücknehmen
Abrechnungsdaten
erfassen
Abrechnungs
daten
Rechnung
erstellen
Vertrag
[abgeschlossen]
Rechnung
Abbildung 4.5.11: Aktivitätendiagramm zum Vorgang ”
Kfz-Rücknahme”

4.5. DYNAMISCHE MODELLIERUNG 54
Abbildung 4.5.12: Aktivitätsdiagramm in Topcased

4.5. DYNAMISCHE MODELLIERUNG 55
Abbildung 4.5.13: Zuordnung eines Aktivitätsdiagramms zu einem UseCase in Topcased

Kapitel 5
Von UML nach Java ...
In diesem Kapitel wird untersucht, wie man technologisch von einer Anzahl unterschiedlicher
erstellter Modelle zu einer ausführbaren Anwendung gelangt. Dabei wird besonders auf
automatisierbare Vorgänge geachtet, die in den Build-Prozess verlagert werden können. In
Abhängigkeit der zur Modellierung verwendeten Werzeuge ist bereits während der Modellierung
Quellcode entstanden. d.h. generiert worden. Nun kommt es darauf an, Code-Gerüste
zu schaffen oder bestehende Code-Gerüste um weiteren Code anzureichern. Dabei bietet eine
Zielprogrammiersprache mehr oder weniger gut geeignete Konstukte an. Schwierig wird es
etwa, wenn UML-Modelle (Klassen) auf eine nicht objektbasierte Sprache abgebildet werden
sollen. Die von uns betrachtete Abbildung von UML-Modellen auf Java, also eine objektbasierte
Sprache ist zwar deutlich einfacher, aber auch nicht ganz ohne Probleme.
Bei der Umsetzung von Klassen-Modellen in Java-Anwendungen gibt es zwei Möglichkeiten:
• Nutzung der mit der Entwicklungsumgebung bereitgestellten Frameworks, Pakete oder
Klassen für die Implementierung (z.B. Hashtable).
• Implementation neuer Klassen, die jedoch bestehende Klassen erweitern können und/oder
Interfaces implementieren.
Java-Anwendungen können Applets und Applikationen sein.
5.1 Applikationen und Applets
Eine Applikation ist ein Programm in einer virtuellen Maschinensprache (Virtual Machine
Specification). Ein solches Programm wird interpretativ durch den Java-Interpreter java
verarbeitet:
java MyApplication
Die Applikation wid durch Compilation aus einem Quellprogramm MyApplication.java
erzeugt und in MyApplikation.class gespeichert. Die Datei MyApplication bildet eine
Übersetzungseinheit.
56

5.1. APPLIKATIONEN UND APPLETS 57
javac MyApplication.java
Durch diese Art der Verarbeitung wird Plattformunabhängigkeit gewährleistet, die Verfügbarkeit
eines Interpreters auf jeder Betriebssystem-Plattform vorausgesetzt.
Java-Applikationen werden von einer Klassenstruktur gebildet.
Beispiel:
public class MyApplication{
public static void main (String args[]){
System.out.println("Hello world");
for (int i = args.length - 1; i>=0; i--)
System.out.println(args[i]);
}
}
Die Hauptklasse einer Anwendung (z.B. MyApplication) muss die Methode main() implementieren.
Mit static gekennzeichnete Methoden oder Variablen beziehen sich auf eine
Klasse als Objekt, und nicht auf ein Instanzobjekt. Sie werden Klassenmethoden bzw. Klassenvariablen
genannt. Für jede Methode ist ein Ergebnistyp festzulegen. Wird dieser mit
void angegeben, liefert die Methode keinen Ergebniswert. Beim Programmaufruf können
Kommandozeilen–Parameter an eine Applikation übergeben werden. Im Beispiel kann über
das Array args auf solche Parameter zugegriffen werden. Zur Verwaltung der Länge eines
Arrays besitzt jedes Array das Feld length. Dieses Feld wird wie eine Instanzvariable eines
Objektes zugegriffen. Strings sind immer Objekte, also keine Character-Arrays.
Bei der Erzeugung von String-Objekten kann eine Initialisierung mittels String-Literaten
vorgenommen werden:
String s = new String("Hello world")
Beispiel für einen Aufruf:
java MyApplication huhu haha hoho
Hello world!
hoho
haha
huhu
Applets
Applets sind Java- Anwendungen, die in HTML-Dokumente mittels eines Applet-Tags eingebunden
werden können.
Beispiel:

5.1. APPLIKATIONEN UND APPLETS 58
Applet-Demonstration
Lehrveranstaltung "Software Engineering"
The Browser doesn’t know the applet-tag.
Ein Browser, der das Applet-Tag nicht kennt, überliest es. Alternative HTML-Elemente
können in die Applet-Umgebung eingefügt werden. Kennt ein Browser das Applet-Tag im
obigen Beispiel nicht, erscheint stattdessen ”
The Browser doesn’t know the applet-tag”.
Das Attribut ALT wird verwendet, um bei Textbrowsern anstelle des Applets alternativen
Text zu zeigen.
Mit dem Attribut CODE wird die Datei spezifiziert, in der die Hauptklasse des Applets
liegt.
Jedes Applet besitzt die Methoden init(), start(), stop() und destroy(), die standardmäßig
keinen Code enthalten.
Beispiel:
import java.applet.Applet;
import java.awt.*;
public class AppletDemo extends Applet{
String text;
public void init(){
System.out.println("init");
if ((text = getParameter("text")) == null)
text = "kein text-Parameter vorhanden";
System.out.println(text);
}
public void start(){
System.out.println("start");
}
public void stop(){
System.out.println("stop");
}
public void destroy(){
System.out.println("destroy");

5.2. BAUM-KLASSEN 59
}
public void paint(Graphics g){
g.drawString("Hello world !",90,25);
}
}
Der Browser gibt Ausgaben auf der Standardausgabe über die ”
Java-Console” aus. Zur
Präsentation von Applets kann auch der Appletviewer verwendet werden. Ist das Applet
während der Präsentation geändert worden, d.h. es ist ein neues .class-File erzeugt worden,
muss der Appletviewer neu gestartet werden, um das geänderte Applet zu präsentieren.
5.2 Baum-Klassen
Als Beispiel sollen die im Abschnitt über Polymorphie betrachteten und modellierten Unruhen
nun implementiert werden. Getreu dem Klassenmodell (vgl. Abbildung 4.4.5) programmieren
wir die Klassen Mobile, MobileA und Node.
public class Mobile{
Node root = new Node();
Mobile lsucc,rsucc;
void insKeyWeight(int k,int w){
root.setKey(k);
root.setWeight(w);
}
void insLsucc(Mobile s){
lsucc = s;
root.setWeight(0);
}
void insRsucc(Mobile s){
rsucc = s;
root.setWeight(0);
}
int weight(){
if (root.getWeight() == 0)
return(lsucc.weight() + rsucc.weight());
else
return( root.getWeight());
}
boolean balancedp(){
if (root.getWeight() == 0)
return(lsucc.balancedp() &&

5.2. BAUM-KLASSEN 60
}
rsucc.balancedp() &&
(lsucc.weight() == rsucc.weight()));
else
return(true);
}
void makebalance(){
}
class Node{
private int key,weight;
}
int getWeight(){
return(weight);
}
int getKey(){
return(key);
}
void setWeight(int weight){
this.weight = weight;
}
void setKey(int key){
this.key = key;
}
public class MobileA extends Mobile{
int larm,rarm;
void insLarm(int a){
larm = a;
}
void insRarm(int a){
rarm = a;
}
boolean balancedp(){
if (root.getWeight() == 0)
return( lsucc.balancedp() &&
rsucc.balancedp() &&
(larm * lsucc.weight() == rarm * rsucc.weight()));
else

5.2. BAUM-KLASSEN 61
}
}
return(true);
Unruhen vom Typ Mobile befinden sich im Gleichgewicht, wenn es sich um Gewichte
handelt, oder andernfalls, wenn links und rechts Unruhen hängen, die sich selbst im Gleichgewicht
befinden, und die Gewichte links und rechts gleich sind.
Die Instanzvariablen lsucc und rsucc können auch auf Instanzen von Subklassen von
Mobile verweisen. Die Methode weight() kann so unmittelbar auch auf Unruhen vom Typ
MobileA angewendet werden. Bei Anwendung der Methode weight auf die in lsucc und
rsucc verwalteten Objekte wird der Typ nicht zur Compilezeit festgelegt! Die Methode kann
laufzeitabhängig auf eine Instanz der Klasse Mobile oder der Klasse MobileA angewendet
werden (auch keine Deklaration als ”
virtual” notwendig, wie etwa in Modula-2).
Innerhalb der Applikation UseMobiles werden zwei Unruhen konstruiert. Mit den Konstruktoren
werden Objekte erzeugt, die dann mit den Methoden insKeyWeight, insLsucc
und insRsucc bewertet und in Beziehung zueinander gesetzt werden:
public class UseMobiles{
public static void main(String argv[]){
System.out.println("Konstruktion von Mobiles");
Mobile tree1, tree2;
MobileA tree3, tree4;
// Beispiel1
tree1 = new Mobile();
tree1.insKeyWeight(5,1);
tree2 = new Mobile();
tree2.insKeyWeight(4,0);
tree2.insLsucc(tree1);
tree1 = new Mobile();
tree1.insKeyWeight(6,1);
tree2.insRsucc(tree1);
tree1 = new Mobile();
tree1.insKeyWeight(3,0);
tree1.insLsucc(tree2);
tree2 = new Mobile();
tree2.insKeyWeight(7,2);
tree1.insRsucc(tree2);
tree2 = new Mobile();
tree2.insKeyWeight(1,0);
tree2.insRsucc(tree1);
tree1 = new Mobile();

5.2. BAUM-KLASSEN 62
tree1.insKeyWeight(2,4);
tree2.insLsucc(tree1);
System.out.println(tree2.weight());
if (tree2.balancedp())
System.out.println("balanced");
else
System.out.println("not balanced");
// Beispiel2
tree3 = new MobileA();
tree3.insKeyWeight(5,2);
tree4 = new MobileA();
tree4.insKeyWeight(4,0);
tree4.insLsucc(tree3);
tree4.insLarm(1);
tree4.insRarm(2);
tree3 = new MobileA();
tree3.insKeyWeight(6,1);
tree4.insRight(tree3);
tree3 = new MobileA();
tree3.insKeyWeight(3,0);
tree3.insLsucc(tree4);
tree3.insLarm(1);
tree3.insRarm(3);
tree4 = new MobileA();
tree4.insKeyWeight(7,1);
tree3.insRight(tree4);
tree4 = new MobileA();
tree4.insKeyWeight(1,0);
tree4.insRsucc(tree3);
tree4.insLarm(4);
tree4.insRarm(3);
tree3 = new MobileA();
tree3.insKeyWeight(2,3);
tree4.insLsucc(tree3);
System.out.println(tree4.weight());
if (tree4.balancedp())
System.out.println("balanced");
else
System.out.println("not balanced");
System.out.println("Bye Mobiles!");
}

5.3. INTERFACES UND MEHRFACHVERERBUNG 63
}
Mobile() ist ein Konstruktor der Klasse Mobile. Bei Aufruf von new wird Speicherplatz
ausgefasst und eine Instanz von Mobile angelegt. Alle Klassen, die selbst keinen Konstruktor
definieren, besitzen implizit einen Konstruktor, der keine Parameter erwartet. Ein Konstruktor
hat den Namen der Klasse und keinen Ergebnistyp.
5.3 Interfaces und Mehrfachvererbung
In Java gibt es im Unterschied zu C++ keine Mehrfachvererbung. Statt dessen gibt es sog.
Interfaces, die reine Schnittstellen darstellen und keinerlei Implementierung enthalten.
Interfaces definieren ausschließlich abstrakte Methoden und Konstanten.
Eine Klasse kann ein oder auch mehrere Interfaces ”
erben”, in dem sie die Interfaces
implementiert. Die Klasse erbt damit alle abstrakten Methoden und alle Konstanten.
Um geerbte Methoden anwenden zu können, müssen sie zuvor geeignet überschrieben, d.
h. definiert werden.
Die Eigenschaft, ein Interface zu implementieren, vererbt eine Klasse an ihre Nachfahren.
Deklaration von Interfaces in Java
Die Deklaration von Interfaces erfolgt analog der von Klassen, wobei anstelle des Schlüsselwortes
class das Schlüsselwort interface verwendet wird.
Festlegungen:
• alle Elemente eines Interfaces sind implizit final static. Eine explizite gemeinsame
oder einzelne Angabe der Modifier final und static ist auch möglich. Ein Initialwert
muss angegeben werden.
• ein Interface muss als public vereinbart werden, wenn es außerhalb des Paketes, zu
dem es definiert wurde, verwendet werden soll. Ein public-Interface muss in einer
Datei stehen, die genauso heisst, wie das Interface.

5.3. INTERFACES UND MEHRFACHVERERBUNG 64
Beispiel:
LKWs sind motorgetriebene Fahrzeuge und gleichzeitig Landfahrzeuge (vgl.
Abbildung 4.4.2). Wegen der fehlenden Mehrfachvererbung in Java werden
Landfahrzeuge bzw. Wasserfahrzeuge jeweils als Interface LandF bzw.
WasserF definiert.
public interface LandF{
String medium = "Land";
void rollen(String untergrund);
}
public interface WasserF{
String medium = "Wasser";
void schwimmen(String untergrund);
}

5.3. INTERFACES UND MEHRFACHVERERBUNG 65
Fahrzeuge werden wie folgt definiert:
class Fahrz{
void start(){};
void bewegen(){};
void stop(){};
}
class MotorF extends Fahrz{
void start(){
System.out.println("Motor gestartet");
}
void stop(){
System.out.println("Motor gestoppt");
}
void bewegen(String untergrund, LandF fz ){
System.out.println("Fahrwerk_aktivieren");
fz.rollen(untergrund);
}
void bewegen(String untergrund, WasserF fz ){
System.out.println("Fahrwerk_aktivieren");
fz.schwimmen(untergrund);
}
}
class LKW extends MotorF implements LandF{
public void rollen(String untergrund){
if (untergrund.equals(medium))
System.out.println("Fahrt des LKW prolemlos");
else
System.out.println("LKW im Wasser oder in der Luft!");
}
public void fortbewegen(String untergrund){
this.start();
this.bewegen(untergrund,this);
stop();
}
}

5.3. INTERFACES UND MEHRFACHVERERBUNG 66
Die Anwendung zeigt die Klasse InterfaceDemo:
public class InterfaceDemo {
public static void main(String args[]){
LKW myF = new LKW();
String under = "Land";
myF.fortbewegen(under);
String undern = "Wasser";
myF.fortbewegen(undern);
}
}
Der Test:
/* Test:
~> java InterfaceDemo
Motor gestartet
Fahrwerk_aktivieren
Fahrt des LKW prolemlos
Motor gestoppt
Motor gestartet
Fahrwerk_aktivieren LKW im Wasser oder in der Luft!
Motor gestoppt
~>
*/
Implementierung eines Interface Damit ein Interface wirksam wird, muss es von einer
Klasse implementiert werden. Anstelle des für die Vererbung von Klassen verwendeten
Schlüsselworts extends wird hier das Schlüsselwort implements verwendet.
Es ist nicht zwingend, dass die Klasse, die ein Interface implementiert, dessen Methoden
tatsächlich eine Funktionalität gibt. Die Methodenkörper können auch leer sein, allerdings
muss die Klasse alle Methoden des Interface überschreiben.
Eine Klasse kann ein oder mehrere Interfaces implementieren. Die Interface-Bezeichner
werden in diesem Fall nach dem Schlüsselwort implements durch Kommata getrennt in der
Klassendefinition aufgeführt. Eine Kombination von extends und implements ist möglich.
Die Benutzung von Interfaces erfolgt analog der von Klassen. An eine Variable von einem
Interface-typ können Verweise auf Objekte aller Klassen zugewiesen werden, die das Interface
implementieren. Eine Instanz einer Klasse, die mehrere Interfaces implementiert, kann an
Verweise auf alle Interfaces zugewiesen werden, die diese Klasse implementiert.
Durch das Interface-Konzept in Verbindung mit dem Konzept der einfachen Vererbung
wird sichergestellt, dass eine Klasse nur von einer Klasse gebrauchsfertige” Methoden und
”

5.4. IMPLEMENTATION VON AGGREGATIONEN: VEKTOREN UND
HASH-TABELLEN 67
Instanzvariablen erben kann.
5.4 Implementation von Aggregationen: Vektoren und Hash-
Tabellen
5.4.1 Vektoren
Ein Vektor ist in Java (als Instanz der Klasse Vector) ein eindimensionales dynamisches
Array, das als Elemente Instanzen von Object und allen Nachfahren aufnehmen kann. Die
tatsächliche Größe eines Vektors wird stufenweise automatisch an die benötigte Größe angepasst.
Es existieren u.a. folgende Methoden:
public final synchronized void addElement (Object elem)
fügt das Element elem nach allen vorhandenen Elementen (d.h. nach
dem Element mit dem bisher größten Index) ein, wobei die Kapazität
des Vektors ggfs. vergrößert wird.
public final synchronized void insertElement (Object elem, int index)
fügt das Element elem an der Position index ein, ggf. wird dazu die
Kapazität des Vektors erhöht. Der Index ist 0-basiert.
public final synchronized void setElementAt (Object elem, int index)
falls index ein im Vektor vorhandener Index ist, wird das Element an
dieser Stelle durch elem ersetzt.
public final boolean contains (Object elem)
liefert true, wenn elem ein Element des Vektors ist und sonst false.
5.4.2 Hash-Technik
Hash–Verfahren ermöglichen einen effizienten Zugriff auf Datenelemente in veränderlichen
Datenbeständen (Elemente suchen, einfügen, löschen). Es wird zwischen direkter und indirekter
Hash–Technik unterschieden.
Direkte Hash-Technik
Es existiert eine eineindeutige Abbildung der Menge aller möglichen Schlüssel U (Universum)
auf die Menge der Adressen einer Tabelle.
Sei K die Menge der tatsächlich benutzten Schlüssel K ⊆ U. Falls card(U) ≫ card(K)
bzw. card(U ) sehr groß ist, ist dieses Verfahren ineffizient, die meisten Tabellenplätze bleiben
unbenutzt. In diesem Fall geht man zur indirekten Hashtechnik über.
Indirekte Hash-Technik

5.4. IMPLEMENTATION VON AGGREGATIONEN: VEKTOREN UND
HASH-TABELLEN 68
Mittels einer Hashfunktion h wird eine eindeutige (nicht eineindeutige!) Abbildung einer
Menge von Schlüsseln auf die Menge der Indizees einer Hashtabelle definiert (siehe Abbildung
5.4.1).
Tabelle
6
1
Universum der SchlüsselU
5
Benutzte SchlüsselK
2
nil
nil
nil
1
2
3
4
5
3
4
data
data
4
3 8
7
9
nil
nil
6
7
8
9
7
9
data
data
Abbildung 5.4.1: Hashtabelle mit indirekter Adressierung
Beispiel: Divisionsrest-Methode
h(k) = n(k) MOD m
Darin sind m die Anzahl der Tabellenelemente und k ein (meist alphanumerischer)
Schlüssel. MOD bezeichnet die Modulo-Operation. Die Funktion n bildet die
Menge der Schlüssel auf die Menge der natürlichen Zahlen ab.
Verschiedene k ∈ K können ein gleiches h(k) besitzen. Durch h wird K in disjunkte
Klassen zerlegt (d.h. ”
zerhackt” = hash).
Beispiel:
n(k) = 10 · k, K = { 1, 2, . . . , 10}, m = 13 (Empfehlung: m ist Primzahl)
h(1) = 10, h(2) = 7, h(3) = 4, h(4) = 1, h(5) = 11, h(6) = 8, h(7) = 5, h(8) =
2, h(9) = 12, h(10) = 9
Ein Schlüssel k wird gemeinsam mit der Nutzinformation an der Tabellenposition T[h(k)]
abgespeichert. Eine Kollision tritt auf, wenn
h(k 1 ) = h(k 2 ) für k 1 , k 2 ∈K und k 1 ≠ k 2 .
Strategien zur Kollisionsauflösung
Ein mögliches Verfahren zur Kollisionsauflösung ist die offene Hash–Technik. Im Konfliktfall
wird durch sequentielles Suchen ein freier Tabellenplatz gesucht. Bei diesem Verfahren
muss mindestens ein Restplatz in der Tabelle frei bleiben.
Das Java Development Kit bietet Unterstützung für die Hashtabellen-Technik. Im Package
java.util wird die Klasse Hashtable bereitgestellt. Es existieren u.a. folgende Methoden:

5.5. DYNAMISCHE MODELLE UND EVENT-HANDLING 69
• public synchronized Object get (Object key)
liefert das dem Schlüssel-Objekt key in der Hash-Tabelle zugeordnete Datenobjekt
zurück, falls der Schlüssel key in der Tabelle gefunden wird, und sonst null.
• public synchronized Object put (Object key, Object value)
trägt das Schlüssel-Objekt key und das Datenobjekt value in die Tabelle ein, falls der
Schlüssel in der Tabelle noch nicht existiert. In diesem Fall liefert put den Wert null.
Falls der Schlüssel in der Tabelle vorhanden war, wird der zugeordnete Wert durch das
Objekt value ersetzt. In diesem Fall liefert put den alten Wert.
Der Platz in der Hashtabelle wird mit Hilfe der Methode hashCode() ermittelt.
• public synchronized Object remove (Object key)
entfernt das Schlüssel-Objekt key und das zugehörige Datenobjekt aus der Tabelle, falls
key in der Tabelle gefunden wird. In diesem Fall wird das zugeordnete Datenobjekt
zurückgegeben. Wird der Schlüssel nicht gefunden, ist der Rückgabewert null.
• public synchronized Enumeration elements()
liefert eine Instanz der Klasse Enumeration, die eine Zusammenstellung aller Datenobjekte
enthält.
Falls durch fortgesetztes Eintragen in die Hashtabelle (mittels put) die Reorganisationsschwelle
überschritten wird, erfolgt automatisch ein Aufruf der geschützten Methode rehash().
Dabei wird die Hash-Tabelle automatisch vergrößert.
Alle Klassen, deren Instanzobjekte als Schlüssel dienen sollen, müssen die Methoden
hashCode() und equals(...) implementieren.
Die Standardklassen in Java implementieren diese Methoden bereits, d.h. alle von Object
abgeleiteten Klassen. Die Methoden müssen also vom Nutzer nur dann neu definiert werden,
wenn eine spezielle Berechnungsvorschrift gewünscht wird bzw. wenn für Schlüssel ein Objekttyp
verwendet wird, der von keinem Standard-Java-Objekttyp abgeleitet ist.
5.5 Dynamische Modelle und Event-Handling
Ein Problem ist die Umsetzung von Zustandsdiagrammen in Java-Programme.
Bei jeder Mausbetätigung oder Tastatureingabe wird ein Objekt der Klasse Event bzw.
einer Subklasse dieser Klasse erzeugt. Den Programmkomponenten, die auf Events reagieren
sollen, werden zur jeweiligen Event-Art passende Listener hinzugefügt. Die Programmierung
der gewünschten Aktionen bei Eintreten bestimmter Ereignisse erfolgt in sog. Handlern.
Listener-Interfaces definieren solche Handler zur Behandlung von Events. Ein Listener kann
mehrere Event-Quellen haben. Zu einer Event-Quelle kann es andererseits auch mehrere
Listener geben.
Die nachfolgenden Aussagen beziehen sich zunächst auf das Event-Handling im JDK
1.0.x.

5.5. DYNAMISCHE MODELLE UND EVENT-HANDLING 70
Alle Komponenten des Abstract Window Toolkit (AWT) besitzen eine Methode handleEvent(Event)
als ”
Handler”.
handleEvent(Event) ruft in Abhängigkeit von der Art des Events unterschiedliche Hilfsmethoden
auf. Die Information über die Art eines Events ist im Event-Objekt in der Komponente
(der Instanzvariablen) id enthalten. Alle Handler haben den Ergebnistyp boolean.
Zunächst wird bei dem Objekt, in dem ein Event erzeugt wurde, begonnen, nach einem
Handler zu suchen.
Beispiel: Applet zur Ausgabe des Labels eines gedrückten Buttons auf der Standard-Ausgabe.
Die Ausgabe erscheint auf der Java-Console.
import java.applet.*;
import java.awt.*;
public class AcEvDemo extends Applet{
public void init() {
System.out.println("Hello world!");
add(new Button("open"));
add(new Button("close"));
System.out.println("I am waiting for events.");
}
public boolean action(Event evt,Object what){
if ("open".equals(what)){
System.out.println("action in open");
return true;
}
if ("close".equals(what)){
System.out.println("action in close");
return true;
}
return false;
}
}
Ab Java 1.1 hat sich das Event-Handling geändert (wobei Kompatibilität gewahrt wurde,
d.h. Programme mit dem Event-Handling von Java 1.0.x lassen sich auch unter Java 1.1 und
höheren Versionen übersetzen u. interpretieren). Es gibt verschiedene Klassen von Events.
Alle Event-Klassen erben von EventObject. Ein Event ist ein unveränderliches Objekt, das
Informationen über den Typ und die Event-Quelle enthält.
Ein Event tritt bei einem Quellobjekt auf und wird an einen ”
Hörer” (einen Listener)
weitergeleitet. Den Komponenten, in denen Events ausgelöst werden können (die also die
Event-Quelle bilden), werden ein oder mehrere zur jeweiligen Event-Klasse passende Listener
hinzugefügt.

5.5. DYNAMISCHE MODELLE UND EVENT-HANDLING 71
Listener sind Interfaces. Die Klasse, in der die Behandlung eines Events vorgenommen
werden soll, muss das entsprechende Listener-Interface implementieren, oder von einer Klasse
abgeleitet sein, die dieses Interface implementiert. Die Behandlung von Events innerhalb einer
Klasse wird in Handlern programmiert. Ein Objekt der Klasse, die Handler bereitstellt, wird
dann als Listener registriert.
Beispiel:
import java.applet.*;
import java.awt.event.*;
import java.awt.*;
public class AcEvDemo2 extends Applet implements ActionListener{
public void init() {
System.out.println("Hello world!");
Button bopen = new Button("open");
Button bclose = new Button("close");
bopen.addActionListener(this);
bclose.addActionListener(this);
add(bopen);
add(bclose);
System.out.println("I am waiting for events.");
}
public void actionPerformed(ActionEvent evt){
if (evt.getActionCommand().equals("open")){
System.out.println("action in open");
return true;
}
if (evt.getActionCommand().equals("close")){
System.out.println("action in close");
}
}
}
Die Anwendungsklasse implementiert das Interface ActionListener und definiert die
Methode ActionPerformed(), der ein Action-Event als Parameter übergeben wird. Den
Buttons bopen und bclose wird mit der Methode addActionListener ein Listener hinzugefügt.
Beispiel:
Applet zur Demonstration von Maus-Events:
import java.applet.*;
import java.awt.event.*;
import java.awt.*;

5.5. DYNAMISCHE MODELLE UND EVENT-HANDLING 72
public class EventDemoNeu extends Applet implements ActionListener {
public void init() {
System.out.println("Hello world!");
setLayout(new BorderLayout());
setBackground((Color.green).darker());
Button bopen = new Button("open");
bopen.addActionListener(this);
add("West",bopen);
Button bclose = new Button("close");
bclose.addActionListener(this);
add("East",bclose);
System.out.println("I am waiting for events.");
Label myLabel = new Label();
myLabel.setAlignment(Label.CENTER);
add("South",myLabel);
GraphicCanvas grcanv = new GraphicCanvas(myLabel);
grcanv.addMouseListener(grcanv);
Panel p1 = new Panel();
p1.add("Center",grcanv );
add("Center",p1);
}
public void actionPerformed(ActionEvent evt){
if (evt.getActionCommand().equals("open")){
System.out.println("action in open");
}
if (evt.getActionCommand().equals("close")){
System.out.println("action in close");
}
}
}
class GraphicCanvas extends Canvas implements MouseListener {
Label positionLabel;
Rectangle rect;
public GraphicCanvas(Label positionLabel){
this.positionLabel = positionLabel;
setBackground(Color.green);
rect = new Rectangle(80,40,60,70);
}
public void paint(Graphics g){
g.setColor(Color.blue);

5.5. DYNAMISCHE MODELLE UND EVENT-HANDLING 73
}
g.fillRect(rect.x,rect.y,rect.width,rect.height);
}
public Dimension preferredSize(){
return new Dimension(200,200);
}
public Dimension minimumSize(){
return new Dimension(200,200);
}
public void mouseEntered(MouseEvent evt){
positionLabel.setText("Mouse is in");
}
public void mouseExited(MouseEvent evt){
positionLabel.setText("Mouse is out");
}
public void mouseClicked(MouseEvent evt){
}
public void mousePressed(MouseEvent evt){
}
public void mouseReleased(MouseEvent evt){
}
Abschließend noch ein Beispiel, das zeigt, wie eine über ein Frame dargestellte Anwendung
durch das Schließen des Fensters beendet wird:
import java.awt.event.*;
import java.awt.*;
public class ApplicationTest extends Frame implements WindowListener{
public static void main(String args[]){
ApplicationTest myFrame = new ApplicationTest("Neues Frame");
myFrame.addWindowListener(myFrame);
myFrame.resize(400,400); myFrame.show();
}
public ApplicationTest(String s){
super(s);
}
public void windowClosing(WindowEvent evt){
System.exit(0); dispose();
}
public void windowActivated(WindowEvent evt){
}
public void windowClosed(WindowEvent evt){

5.6. FEHLER UND AUSNAHMEN 74
}
}
public void windowDeactivated(WindowEvent evt){
}
public void windowDeiconified(WindowEvent evt){
}
public void windowIconified(WindowEvent evt){
}
public void windowOpened(WindowEvent evt){ }
5.6 Fehler und Ausnahmen
Im Sprachgebrauch des Software Engineering wird zwischen Fehlern und Ausnahmen unterschieden.
Ein wesentlicher Beitrag zur Kärung der Begriffe und zur Sicherheitsproblematik
ist von B. Meyer mit dem Vertragskonzept geleistet worden [Mey90].
Als Fehler bezeichnet man danach eine Nicht-Übereinstimmung eines Programmes mit
seiner Spezifikation.
Ausnahmen (exceptions) bedeuten Ausnahmesituationen, d.h. abnormale Bedingungen
während der Ausführung von Software-Elementen, die normalerweise den Abbruch eines
Programmes zur Folge haben.
Fehler können, müssen aber nicht Ausnahmen zur Folge haben.
Das Exception-Konzept in Java ermöglicht es, bestimmte Arten von Ausnahmen zu behandeln,
so dass Programme in jedem Fall sicher weiterlaufen.
Die Bedingungen, unter denen in Java eine Exception ausgelöst wird, ist entweder im
Interpreter verankert, oder sie wird vom Programmierer definiert.
Neben Exceptions kennt Java noch Ausnahmen, die ”
schwere Fehler” darstellen, und die
in jedem Fall zur Beendigung des Interpreters führen. Diese Art von Ausnahmen heisst in
Java Error.
Alle Errors und Exceptions sind Objekte, die von der Klasse Throwable abstammen.
Ein Programmierer kann eigene Exceptions definieren, indem er eine Unterklasse von einer
vorhandenen Exception ableitet.
Konstruktoren für Exceptions können optional mit einem Parameter aufgerufen werden.
public class NullPointerException extends RuntimeException{
public NullPointerException(){
super();
}
public NullPointerException(String s){
super(s);
}
}

5.6. FEHLER UND AUSNAHMEN 75
Throwable
Error
Exception
IndexOutOfBoundsException
. . .
RuntimeException
ArrayIndexOutOfBoundsException
NullPointerException
Abbildung 5.6.1: Errors und Exceptions
Der Parameter s vom Typ String repräsentiert eine Fehlernachricht.
Auftrefende Exceptions können durch eine try/catch-Kombination abgefangen werden.
Ist das nicht der Fall, erfolgt eine Übergabe an den nächsten Programmblock bzw. eine übergeordnete
Methode. Außer bei RuntimeExceptions ist für Methoden eine throws-Klausel
erforderlich, sonst meldet bereits der Compiler einen Fehler.
Der Interpreter unterbricht letztlich das Programm, falls nirgends eine Behandlung einer
Exception erfolgt.
Behandlung von Exceptions
1. Kombinierte Anwendung der Anweisungen try, catch und finally
try {
// Programmtext, der eine Exception ausloesen kann
}
.
catch (FirstException e){
// Programmtext, der beim Auftreten einer Exception e
// vom Typ FirstException ausgefuehrt wird
}
catch (SecondException e){
// Programmtext, der beim Auftreten einer Exception e
// vom Typ SecondException ausgefuehrt wird
}
.

5.6. FEHLER UND AUSNAHMEN 76
finally {
// Programmtext, der grundsaetzlich ausgefuehrt wird
}
Falls bei der Ausführung der Anweisungen des try-Blockes eine Exception ausgelöst
wird, wird die Verarbeitung sofort abgebrochen und zu den catch-Anweisungen verzweigt.
Es gibt keine Möglichkeit mehr, in den try-Block zurückzuspringen. Die catch-
Anweisungen sind optional. Falls zu einer Exception eine passende catch-Anweisung
existiert, wird dieser die Exception übergeben und es werden die in der catch-Anweisung
enthaltenen Anweisungen ausgeführt. Falls eine Exception auftritt, zu der keine catch-
Anweisung existiert, wird die Exception an den nächst höheren Programmblock weitergeleitet.
Beispiel:
import java.io.*;
import java.awt.*;
import java.lang.*;
public class ExceptionDemo {
public static void main(String args[]){
DataInputStream dataInput = new DataInputStream(System.in);
int a,b,c;
try{
b = Integer.valueOf(dataInput.readLine().trim()).intValue();
c = Integer.valueOf(dataInput.readLine().trim()).intValue();
a = b/c;
System.out.println(a);
}
catch(ArithmeticException e){
System.out.println("Error: "+e.getMessage());
}
catch(IOException e){
System.out.println("Error: "+e.getMessage());
}
}
}
Im Beispiel entfernt die Methode trim() im eingelesenen String vorstehende und nachfolgende
Leerzeichen. Erhält c den Wert 0, wird bei der Division eine ArithmeticException
ausgelöst. Die Methode getMessage() wird von Throwable definiert und ist damit bei
allen Exception-Objekten verfügbar.

5.7. PARALLELITÄT DURCH MULTITHREADING 77
2. Die Verwendung der throws-Klausel im Kopf einer Methode kennzeichnet den Verzicht
auf eine lokale Fehlerbetrachtung, z.B.
... main(...) throws IOException ...
Es können - durch Komma getrennt - auch mehrere Exceptions angegeben werden.
Das explizite Auslösen einer Exception signalisiert einen Fehlerzustand und erfolgt mittels
throw.
Im Programm folgt auf das Schlüsselwort throw eine Referenz auf eine Instanz der Art
von Exception, die ausgelöst werden soll, z.B.
throw new NullPointerException("Cdr einer leeren Liste").
Benutzerdefinierte Exceptions Vom Programmierer können eigene Exception-Klassen
definiert werden, indem sie von einer existierenden Exception-Klasse abgeleitet werden.
5.7 Parallelität durch Multithreading
Multitasking und Multiprocessing beziehen sich auf Eigenschaften eines Betriebssystems
oder der Hardware. Auf einem Multitasking-System können mehrere Programme quasiparallel
ablaufen. Soll ein Programm in diesem Kontext Teile parallel abarbeiten, so kann
das Programm Prozesse erzeugen, die jeweils in einer eigenen Umgebung mit einem eigenen
Speicherbereich arbeiten und über die üblichen Interprozesskommunikationsprimitiven
miteinander Kommunizieren (child-Prozesse).
Eine Programmiersprache mit der Multithreading-Eigenschaft bietet die Möglichkeit, auf
einfache und ressourcenschonende Weise Teile eines Programmes innerhalb eines einzigen
Prozesses parallel ablaufen zu lassen.
Ein Thread ist eine sequentielle Folge von Anweisungen die parallel zu den Anweisungsfolgen
anderer Threads abgearbeitet wird.
Um einen Thread zu erzeugen, kann man eine Subklasse der Klasse Thread bilden, in
dieser die Methode run() überschreiben und dann ein Objekt der Subklasse instanziieren.
Die Methode start() muss auf die neue Instanz angewendet werden und ruft dann run()
auf.
Beispiel:
Die Methode run() der Klasse DemoThread gibt aller 5 Sekunden einen Text aus.
public class DemoThread extends Thread {
public void run() {
for (int i=0; i

5.7. PARALLELITÄT DURCH MULTITHREADING 78
}
}
}
System.out.println("Demo-Thread");
Mit sleep(5000) wird die Ausführung der Methode 5000 ms angehalten. Java erlaubt
die Unterbrechung der Methode sleep() durch einen anderen Thread. Wird der Thread
während der Ausführung von sleep() unterbrochen, wird ihm die Unterbrechung durch
Auslösen einer InterruptedException signalisiert.
In der main-Methode der Klasse UseDemoThread wird nun ein Thread erzeugt und gestartet:
public class UseDemoThread {
public static void main(String argv[]){
System.out.println(Thread.MAX_PRIORITY);
System.out.println(Thread.MIN_PRIORITY);
System.out.println(Thread.NORM_PRIORITY);
DemoThread thread1 = new DemoThread();
Thread.currentThread().setPriority(4);
thread1.start();
System.out.println("--- 1 ---");
System.out.println(Thread.currentThread().getPriority());
thread1.suspend();
try {
Thread.currentThread().sleep(5000);
}
catch(InterruptedException e){
};
System.out.println("--- 2 ---");
thread1.resume();
System.out.println("--- 3 ---");
}
}
/* Test:
~>java UseDemoThread
10
1
5
5
--- 1 ---
4
--- 2 ---
DemoThread

5.7. PARALLELITÄT DURCH MULTITHREADING 79
--- 3 ---
DemoThread
DemoThread
~>
*/
Threads können eine Priorität zwischen MIN_PRIORITY und MAX_PRIORITY erhalten.

Kapitel 6
Entwurf und Implementation
6.1 Modellmanagement und Systementwurf
In diesem Abschnitt werden zunächst UML-Konzepte vorgestellt, die allgemein auf Modelle
anwendbar sind. Modellelemente können in Modelle, Pakete und Subsysteme organisiert sein.
Es kann ein Metamodell des Modell-Managements angegeben werden.
6.1.1 Packages
Ein Paket (engl. package) gruppiert eine Menge von Modellelementen. Ein Paketdiagramm
bietet die Möglichkeit, die Struktur von Systemen logisch zu gliedern und Sichten in verschiedenen
Abstraktionsebenen zu beschreiben. Dadurch wird es z.B. möglich, in einem großen
System - z.B. von über 100 Klassen - den Überblick zu behalten.
In einem Paket können paketierbare Elemente gruppiert werden. Classifier - d.h. Instanzen
von Classifier - sind paketierbare Elemente. Classifier ist eine Metaklasse, sie beschreibt
Notationselemente mit bestimmten gleichen Eigenschaften. Classifier können
• Features haben,
• abstrakt sein,
• in Generalisierungs-/Spezialisierungsbeziehungen zueinander stehen,
• als Typ interpretiert werden.
Die Klasse ist der wichtigste Classifier in der UML. Klassen unterscheiden sich von anderen
Classifiern z.B. durch das Vorhandensein von Operationen (Methoden).
Pakete können hierarchisch geschachtelt werden. Ein Paket kann sowohl untergeordnete
Pakete als auch gewöhnliche Modellelemente enthalten. Alle Arten von UML - Modellelementen
und Diagrammen können in Paketen organisiert sein.
Der Paket-Import ist eine gerichtete Beziehung zwischen zwei Paketen. Ein Quellpaket
möchte Zugriff auf die Elemente eines anderen (Ziel-)Pakets haben. Der Zugriff auf die Elemente
aus dem Zielpaket erfolgt ”
unqualifiziert“.
80

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 81
Der Element-Import ist eine gerichtete Beziehung zwischen einem Paket und einem paketierbaren
Element. Der Element-Import erlaubt es, in einem Paket mittels eines nicht
qualifizierten Namens auf ein Element in einem anderen Paket zuzugreifen.
Ein Paket-Merge definiert, wie der Inhalt eines Pakets durch den Inhalt eines anderen
Pakets erweitert wird. Es werden neue, spezialisierte Classifier angelegt. Die ”
gemergten“
Classifier werden direkt im Paket angelegt und können dort verändert werden. Es entsteht
eine Spezialisierungshierarchie.
Notation
Ein Paket wird als großes Rechteck mit einem kleinen Rechteck an einer Ecke (meist links
oben) dargestellt. Damit wird ein Aktenordner symbolisiert.
Der Inhalt des Pakets kann im großen Rechteck gezeigt werden. Wenn der Inhalt des
Paketes nicht gezeigt wird, wird der Name in das große Rechteck geschrieben. Wenn der
Inhalt des Paketes gezeigt wird, wird der Name in das kleine Rechteck geschrieben. Über
dem Package-Namen kann ein Schlüsselwort notiert werden.
Die Sichtbarkeit von Paketelementen nach außen kann durch Angabe von + oder - vor
dem Elementnamen gekennzeichnet werden.
Ein Package-Import/Element-Import wird durch einen gestrichelten Pfeil dargestellt. Das
Schlüsselwort import am Pfeil beschreibt einen öffentlichen Import.
Namensraum
Durch ein UML-Paket wird ein Namensraum definiert, dem alle Elemente des Pakets angehören.
Packages in Topcased
In Topcased können Packages in Klassendiagrammen oder in Komponentendiagrammen verwendet
werden. Klassen können ebenso wie Komponenten in Paketen gruppiert werden. Das
nachfolgende Beispiel demonstriert die Verwendung von Paketen in Klassendiagrammen.
Beispiel: Im Anwendungsbeispiel wird eine Paket-Struktur im Topcased-Projekt Vorlesungsbeispiele2
unter Models neu erzeugt. Als Diagramm-Typ für ein neues UML-Modell
wir Class Diagram gewählt. Danach kann die Paket-Struktur erarbeitet werden, wie in Abb.
6.1.1 gezeigt.
Die Klasse UseP1 soll die Klassen C1, C3 und C5 nutzen. Die Klasse C2 kann von UseP1
nicht direkt genutzt werden, sie soll nur Paket-weit sichtbar sein und ist außerhalb des Pakets
p2 nicht sichtbar.
Am Beispiel soll gezeigt werden, wie
1. die Package-Struktur bei der Code-Generierung in eine Verzeichnisstruktur abgebildet
wird,
2. im Build-Pozess eine ausführbare Anwendung automatisch erzeugt wird (in einem bin-
Verzeichnis),

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 82
Abbildung 6.1.1: Entwicklung einer Paket-Struktur in Topcased
3. die Anwendung unmittelbar ausgeführt wird.
Das entwickelte UML-Modell (vgl. Abb. 6.1.1) wird - wie in der Navigator-Darstellung gezeigt
- gespeichert (vgl. Abb. 6.1.2).
Für die Code-Generierung sind zunächst die Eigenschaften festzulegen. Dies erfolgt über
das Kontextmenü des Modells Packages.uml.
Der Quellcode wird in ein Projekt Vorlesungsbsp mit der Java-Perspektive hinein generiert.
Die Erzeugung des Java-Quellcodes wird über das Kontextmenü des Pakets (vgl. Abb.
6.1.4) initiiert.
Es ergibt sich die in Abb. 6.1.5 gezeigte Stuktur.
Jetzt müssen die Quellcode-Dateien per Hand angepasst werden. Folgende Aktivitäten
sind notwendig:
• Methodenkörper in allen Methoden ergänzen,
• evtl. package-Anweisungen korrigieren (im Normalfall sind die package-Anweisungen
richtig erzeugt),

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 83
Abbildung 6.1.2: Navigatordarstellung
• import-Anweisungen ergänzen (bei Modellierung von import-Beziehungen werden import-
Anweisungen generiert).
Im nächsten Schritt wird der Bild-Prozess vorbereitet (vgl. Abb. 6.1.6 und Abb. 6.1.7).
Nachfolgend wird die Konfiguration eingestellt. Die Main class wird per Hand eingestellt
(vgl. Abb. 6.1.8). Die Konfiguration wird als PackageBeispiel gespeichert.
Die Ausführung ist mit einem Build-Prozess verbunden. Über den Menüpunkt Run As
... ist noch die gewünschte Anwendung auszuwählen (vgl. Abb. 6.1.9).
Abb. 6.1.10 zeigt das Protokoll der Ausführung.
Einem Package können auch in Komponenten-Modellen existierende Klassen zugeordnet
werden. Dies erfolgt über die outline-Darstellung (vgl. Abb. 6.1.11). Importierte Klassen
müssen noch per drag and drop der Diagrammdarstellung zugeordnet werden.
Packages in Java
Das Konzept der Pakete der UML entspricht genau dem package-Konzept in Java. Der Name
einer Klasse ist innerhalb des Paketes sichtbar (scope), in dem die Klasse deklariert ist. Der
Name einer Klasse muss sich von allen anderen Klassennamen des Pakets unterscheiden. In
Java umfasst ein Paket eine beliebige Anzahl von Compilationseinheiten.
Die Übersetzungseinheit C1.java enthält zwei Klassen.
Die package-Anweisung muss die erste Anweisung in einer Quelldatei sein. Fehlt die
package-Anweisung, werden die Klassen einem voreingestellten Standardpaket ohne Namen
zugeordnet. Die Namen dieser Klassen können von allen Klassen verwendet werden, die sich
im gleichen Verzeichnis befinden. Pakete können hierarchisch gegliedert sein. Paketnamen
korrespondieren mit Pfad-/Dateinamen. Punkte der package-Anweisung werden dabei durch
File-Separatoren ersetzt.

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 84
Abbildung 6.1.3: Eigenschaften des Pakets für die Code-Geenerierung festlegen
Die Übersetzung und Ausführung von Java-Anwendungen, die in Packages organisiert
sind, kann jeweils durch einen Aufruf erfolgen. Abhängige Übersetzungseinheiten werden
automatisch mit übersetzt.

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 85
Abbildung 6.1.4: Starten der Code-Generierung
Abbildung 6.1.5: Bei der Codegenerierung erzeugte Struktur

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 86
Abbildung 6.1.6: Einstellungen des Java Build Path - Ort der Quelldateien
Abbildung 6.1.7: Bereitstellung der Bibliotheken
Abbildung 6.1.8: Einstellung der Run Configuration

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 87
Abbildung 6.1.9: Auswahl der auszuführenden Applikation
Abbildung 6.1.10: Ausgaben der Applikation auf der Standardausgabe
Abbildung 6.1.11: Importieren von Klassen in Packages

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 88
P1
P2
C1.java
C3.java
P3
C5.java
Abbildung 6.1.12: Verzeichnisstruktur als Package-Struktur
Abbildung 6.1.13: Benutzung der Packages

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 89
C1.java
package P1.P2;
public class C1 {
...
}
class C2 extends C1 {
...
}
C3.java
package P1.P2;
class C3 extends C1 {
...
}
class C4 {
...
}
C5.java
package P1.P3;
public class C5 extends C1 {
...
}
class C6 {
...
}
Abbildung 6.1.14: package-Anweisungen zur Realisierung der Package-Struktur
Abbildung 6.1.15: Beispiel, Übersetzen mit ”
Gesprächigkeit”

6.1. MODELLMANAGEMENT UND SYSTEMENTWURF 90
Abbildung 6.1.16: Beispiel, Ausführung

6.2. KOMPONENTENDIAGRAMME 91
6.2 Komponentendiagramme
Betrachtet man die logische Struktur eines objektbasierten Systems, so sieht man Klassenstrukturen.
Bei der Systemarchitektur wird dagegen häufig eine nicht objekt-basierte Komponentenstruktur
zugrunde gelegt.
Zur Darstellung der Komponentenstruktur werden Komponentenmodelle verwendet. Komponentenmodelle
werden in der UML mit Komponentendiagrammen repräsentiert. Komponentendiagramme
beschreiben die Struktur eines Systems zur Laufzeit.
Eine Komponente stellt eine physikalische Programmeinheit dar, die als Quellcode, Objektcode
oder ausführba-res Programm vorliegen kann. Komponenten werden in Subsystemen
(Paketen) organisiert.
Abbildung 6.2.1: Komponentendiagramm
Abbildung 6.2.2: Komponenten mit Schnittstellen
Diagrammelemente:
• in Klassen- und Objektdiagrammen vewendete Modellelemente
• Sichten auf Sachverhalte, die in anderen Modellen beschrieben sind

6.2. KOMPONENTENDIAGRAMME 92
• eigene Modellelemente:
– Komponente
– Schnittstelle (Klassendiagramm)
– Realisierungs-/Implementierungs-/Verwendungs-Beziehung
– Artefakt
– Port

6.3. VERTEILUNGSDIAGRAMME 93
6.3 Verteilungsdiagramme
Das Verteilungsdiagramm (deployment diagram) ermöglicht die Modellierung expliziter physischer
Strukturen auf Instanzenebene. Es zeigt die Zuordnung von Artefakten (Softwarekomponenten)
zu Hardware-Einheiten (als Knoten bezeichnet), d.h. es enthält Knoten (node),
auf denen Prozesse (im Sinne von Betriebssystemprozessen) ablaufen.
Ein Knoten (Node) ist ein zur Laufzeit physisch vorhandenes Objekt, auf das Artefakte
für die Ausführung verteilt (deployes) werden können. Knoten sind (strukturierte) Classifier
und lassen sich schachteln. Knoten können sowohl auf der Ebene M1 (Typebene) als auch auf
der Ebene M0 (Instanzen-Ebene) definiert werden. Gerät und Ausführungsumgebung sind
in der UML definierte Spezialisierungen von Knoten.
Ein Gerät (Device) ist eine Ressource, die die Fähigkeit besitzt, Berechnungen auszuführen.
Ein Gerät besitzt Rechenkapazität. Geräte können komplex sein, d.h. sie können aus
anderen Geräten bestehen.
Eine Ausführungsumgebung (Execution Environment) ist ein Knoten, der eine Ausführungsumgebung
für spezielle Typen von Komponenten bereitstellt. Ausführungsumgebungen
können geschachtelt werden. Zum Beispiel kann die Ausführungsumgebung eines
Datenbanksystems in die Ausführungsumgebung eines Betriebssystems eingebettet sein.
Abbildung 6.3.1: Elemente eines Deploymentdiagramms

6.3. VERTEILUNGSDIAGRAMME 94
Notation
Knoten werden (dreidimensional) durch Quader dargestellt (vgl. Abb. 6.3.1). Falls es sich
um Knoteninstanzen handelt, wird der Name unterstrichen dargestellt. Knoten können durch
Kanten (connection) verbunden werden. Kanten repräsentieren Kommunikationspfade (communication
path).
Geräte werden als Knoten dargestellt und mit dem Schlüsselwort ≪device≫ gekennzeichnet.
Zur Darstellung von Geräten können in der UML auch frei definierte Symbole
verwendet werden (z.B. Workstation, Lautsprecher).
In einer Ausführungsumgebung können bestimmte Softwarekomponenten eines Systems
ausgeführt werden. Voraussetzung ist, dass die Komponenten als ablauffähige Artefakte vorliegen.
Ausführungsumgebungen werden als Knoten dargestellt und mit dem Schlüsselwort
≪ExecutionEnvironment≫ gekennzeichnet.
Verteilungsaspekte können programmtechnisch mit RMI (Remote Method Invocation)
oder CORBA umgesetzt werden.

6.4. OBJEKTSERIALISIERUNG 95
6.4 Objektserialisierung
Die Objektserialisierung dient der persistenten, d.h. dauerhaften Speicherung von Laufzeitobjekten
einer Java-Applikation zu einem bestimmten Zeitpunkt. Durch eine Deserialisierung
kann die serialisierte Objektwelt zu einem späteren Zeitpunkt wieder hergestellt werden, wobei
alle Objekte den Zustand annehmen, den sie zum Zeitpunkt der Serialisierung hatten.
Grundgedanke für die Realisierung der Serialisierung ist, dass Klassen eines Anwendungsmodells
selbst kein Wissen über externe Formate und Schnittstellen für Speicherung und
Transport haben sollen.
Um Objekte serialisieren zu können, muss die zugehörige Klasse das Interface Serializable
implementieren oder von einer Klasse abgeleitet sein, die dieses Interface implementiert. Das
Interface definiert keine Methoden, es dient nur zur Markierung der bei der Serialisierung zu
berücksichtigenden Klassen.
Die Serialisierung erfolgt, indem zunächst eine Instanz von ObjectOutputStream (Klasse
im Package java.io) erzeugt wird. Auf dieses Objekt wird die Methode writeObject(Object)
angewendet. writeObject(Object) bekommt als Parameter ein Objekt übergeben, von dem
aus beginnend die Serialisierung rekursiv erfolgen soll.
Beim Serialisieren werden die Werte aller Instanzvariablen eines Objekts in den spezifizierten
ObjectOutputStream geschrieben. Das Schreiben erfolgt rekursiv, d.h. für Werte, die
Objekte darstellen, werden auch deren Instanzvariablen geschrieben usw. Objekte werden
allerdings nur einmal geschrieben, es gibt keine Endlosrekursionen. Die Werte von Instanzvariablen,
die als transient deklariert sind, werden nicht ausgelagert.
Die Deserialisierung erfolgt, indem zunächst eine Instanz von ObjectInputStream (Klasse
im Package java.io erzeugt wird. Auf dieses Objekt wird die Methode readObject()
angewendet. Die von dieser Methode gelieferte Instanz vom Typ Object ist noch an den
gewünschten Typ anzupassen.
6.5 Modell-/Diagrammaustausch
Für den Austausch von UML2-Diagrammen bzw. Modellen zwischen unterschiedlichen UML-
Werkzeugen kann das von der OMG entwickelte Austauschformat XMI (XML Metadata
Interchanche) genutzt werden. Bisher wird XMI hauptsächlich für den UML- Austausch
eingesetzt, d.h. UML-Modelle werden in XMI (und damit auch in XML) repräsentiert. Der
Datenaustausch von Objekten basiert auf der MOF (Meta Object Facility).

Kapitel 7
Konfigurations-, Test- und
Dokumentationsmanagement
Das Konfigurationsmanagement hat das Ziel, die im Prozess der Softwareentwicklung als Ergebnisse
entstehenden Artefakte sicher zu verwalten, verteilt arbeitenden Entwicklern Zugriff
darauf zu gewähren und die Kontrolle über die im Laufe der Zeit anfallenden Änderungen an
Artefakten zu behalten. Der Fokus liegt dabei auf den Elementen des Produktes und nicht
auf Artefakten, die den Entwicklungsprozess beschreiben (z.B. Projektpläne).
Als Grundlage für dieses Kapitel dient u.a. das Buch ”
Konfigurationsmanagement - mit
Subversion, Ant und Maven” von Popp [Pop08].
7.1 Der KM-Prozess
Konfigurationsmanagement ist ein Regelwerk (bzw. eine Sammlung von Richtlinien), mit dem
ein Prozess - der sog. KM-Prozess - beschrieben wird. Es regelt und optimiert insbesondere
die Zusammenarbeit im Team.
Das Konfigurationsmanagement umfasst Aufgaben wie:
• die Kontrolle der Quellprogramme
• Bereitstellung von ”
Build”-Funktionalität
• Release Engineering
Der erste Standard für das Konfigurationsmanagement (AFSCM-375-1) wurde 1963 vom
US-Militär entwickelt und war auf die Entwicklung von Hardware bezogen. Popp erwähnt
unter Bezug auf Literaturquellen, dass es inzwischen mehr als 200 KM-Standards gibt.
Auswahl der Konfigurationselemente
Eine zentrale Rolle in jedem KM-Prozess spielt die Verwaltung der Konfigurationselemente.
Als Konfigurationselemente bezeichnen wir bestimmte Typen (Klassen) von Artefakten:
96

7.2. VERSIONSVERWALTUNGSSYSTEME 97
UseCases, Klassendiagramme, Quelltexte, Build-Skripte, Installationsanleitungen usw. Für
die Verwaltung stellt das KM Konzepte und Werkzeuge zur Verfügung.
Instanzen der Konfigurationselemente - das sind Verzeichnisse und Dateien - werden
in einem Repository gespeichert. Das Repository ist eine zentrale (oder bei Mercurial: auch
dezentrale) Ablage, auf die alle Teammitglieder zugreifen können. Repositorien sollten sowohl
Text- als auch Binärdateien verwalten können.
Werkzeuge, die Repositorien verwalten, setzen intern Versionierung ein, um die Nachvollziehbarkeit
aller Änderungen und die Datenintegrität zu sichern. Das Konfikurationsmanagement
ist dadurch eng verzahnt mit einer Versionskontrolle.
Verwaltung der Konfigurationselemente
Der Aufbau eines Repository entspricht prinzipiell der Projektstruktur, aber ohne Einbeziehung
temporärer Ordner. Eine effektive Arbeit mit Werkzeugen ist nur möglich, wenn
herstellerspezifische Formate im Repository verwaltet werden können. Repositorien werden
deshalb oft über eine Schnittstelle direkt in die Werkzeuge integriert.
Werkzeuge für die Arbeit mit Repositorien setzen intern die Versionierung ein: Nach jeder
Änderung an einer Datei wird eine neue Revision im Repository gespeichert. Revisionen, die
in der Zukunft parallel weiter gepflegt werden sollen, werden oft als Versionen bezeichnet.
Nach und nach entsteht eine Revisions-/Versionshistorie, alle jemals vorgenommenen Änderungen
werden dokumentiert (auch Löschen als Spezialfall einer Änderung). Dieser Prozess
heisst Versionskontrolle - Revisionen einer Datei werden vom Repository durchnummeriert.
7.2 Versionsverwaltungssysteme
Versionsverwaltungssysteme stellen dem KM-Prozess ein Repository zur Verfügung.
Das Concurrent Versions System (CVS) ist ein verbreitetes System, das das Versionsmanagement
in Projekten auf der Ebene der Quellprogramme unterstützt (keine Deltas auf
der Ebene der Binaries). Ein Schwerpunkt ist die Unterstützung der Gruppenarbeit. Jeder
Entwickler arbeitet in seinem eigenen Arbeits-Verzeichnis. CVS mischt die Arbeiten
und verwaltet ein zentrales Repository. Eine Schwäche von CVS ist, dass keine Verzeichnisse
versioniert werden können (nur gewöhnliche Dateien). Außerdem unterstützt CVS keine
Transaktionen. Beim Check-in mehrerer Dateien werden die Dateien einzeln übertragen. Bei
Netzwerkproblemen kann es daher zu inkonsistenten Zuständen im Repository kommen.
Subversion
Subversion ist ein Nachfolgesystem zu CVS. Auch Subversion stellt ein Repository für einen
KM-Prozess zur Verfügung. Das Repository verwaltet eine zentrale Kopie der Historie.
Unter Windows kann TortoiseSVN als Subversion-Client genutzt werden ([Tor], Erweiterung
zum Explorer von Windows).
Um ein in der Arbeitskopie erstelltes neues Dokument dem Repository hinzuzufügen,
sind zwei Schritte nötig (vgl. Abb. 7.2.1):

7.2. VERSIONSVERWALTUNGSSYSTEME 98
1. TortoiseSVN → Add ...
2. SVN Commit...
Abbildung 7.2.1: SVN-Client TortoiseSVN im Windows-Explorer
Subversion kann ebenso wie CVS in Eclipse als Client genutzt werden, dazu muss Subversion
als Plug-in (subclipse) bereitgestellt werden.
Beispiel 1. Es wird ein Java-Projekt im workspace angelegt. Mit Team share ... wird es
dem Repository hinzugefügt.

7.2. VERSIONSVERWALTUNGSSYSTEME 99
Mercurial
Als ein neueres Versionsverwaltungssystem soll nachfolgend Mercurial behandelt werden.
Für Mercurial steht ein Kommandozeilen-orientiertes Werkzeug zur Verfügung (alle Kommandos
beginnen mit hg, vgl. http://mercurial.selenic.com/, Distributionen sind plattformspezifisch).
Dieses System wird in einem online verfügbaren Buch von Bryan O’Sullivan
beschrieben [O’S]. Eine integrierte Webschnittstelle steht ebenfalls zur Verfügung. Drittanbieter
stellen grafische Frontends oder Plug-ins für Entwicklungsumgebungen zur Verfügung.
In Eclipse wird Mercurial durch ein Plug-in unterstützt (zur Installation vgl. Abb. 1.3.9).
Das Plug-in wird auf javaforge gepflegt (http://www.javaforge.com/project/HGE). Eine
Beschreibung ist dort zu finden [HGE].
Mercurial bietet die von Subversion bekannten Funktionen an und unterstützt zusätzlich
eine dezentrale Entwicklung. Dazu können bei einer verteilten Entwicklung dezentral eigenständige
Repositorien gepflegt werden. Ein Repository verwaltet in einem Speicher die vollständige
Historie der Entwicklung eines Projekts (alle jemals durchgeführten Änderungen).
Das Arbeitsverzeichnis eines Projektbearbeiters enthält eine Kopie der Verzeichnisse/Dateien
des Projekts zu einem bestimmten Zeitpunkt und verwaltet eine eigene private Kopie dieser
Historie (in einem Verzeichnis .hg).
Beim Klonen (clone) eines Repositorys entsteht ein neues Repository, das eine exakte
Kopie des alten Repositorys zum Zeitpunkt des Klonens darstellt. Es umfasst den Inhalt des
Arbeitsspeichers einschließlich der gesamten Historie.
Aufeinanderfolgende Änderungen an verschiedenen Dateien können jeweils zu einem atomaren
Changeset zusammengefasst werden. Changesets entsprechen den Revisionen des Gesamtprojekts.
Changesets erhalten aufeinanderfolgende Nummern. Mercurial weist außerdem
jeder Revision eine globale Changeset-ID zu. Eine ChangesetID ist eine 40-stellige Hexadezimalzahl.
Zweige (branches) und Zusammenführungen (merges) können in der Revisions-Historie
an jedem Punkt auftreten. Jeder nicht zusammengeführte Zweig erzeugt einen neuen Head
der Revisionshistorie. Der Head mit der höchsten Revisionsnummer heißt Tip (tip).
Beispiel. Ein Projekt wird von Alice und Bob bearbeitet. Im Repository von Alice existieren
vier Revisionen:
Bob klont das Repository von Alice, es sieht danach wie folgt aus:
Bob führt Änderungen in seinem Arbeitsverzeichnis durch und führt ein Commit durch:

7.2. VERSIONSVERWALTUNGSSYSTEME 100
Parallel dazu führt Alice ihre eigenen Änderungen durch:
Mittels Pull kann Bob nun alle Änderungen von Alice in sein Repository übernehmen
(mittels Push kann Alice dasselbe tun).
Weil Alices g der jüngste Head in Bobs Repository ist, wird er als Tip gekennzeichnet.
Bob führt ein Merge durch, das seine letzte Änderung mit dem Tip verbindet. Für das
Ergebnis wird ein Commit durchgeführt:
Nutzung von Mercurial unter Eclipse
Es wird zunächst ein Repository benötigt. Dieses liegt typischerweise auf dem lokalen Rechner.
Es gibt zwei Wege:
1. Man kreiert ein Mercurial-Repository durch Klonen eines bereits vorhandenen Repositorys
oder durch Anlegen eines neuen Repositorys (vgl. Abb. 7.2.2).
Bei Auswahl Create New Mercurial Repository wird ein neues Mercurial-Repository
erstellt. Dabei wird man aufgefordert, den Speicherort für das Repository festzulegen
(vgl. Abb. 7.2.3). Ein neues, lokales Repository wird bei Bestätigung (Finish) eingerichtet.
Damit existiert aber noch kein Java- bzw. Topcased-Projekt. Dies kann jetzt
nachträglich erfolgen, der Projektname entspricht dem Repository-Namen.
2. Ein bestehendes Java- oder Topcased-Projekt wird für Mercurial erweitert (share).
Dabei kann ein bestehendes Repository referenziert oder ein neues angelegt werden.
Nachdem ein Java-Projekt unter Mercurial-Verwaltung gestellt wurde, muss das Repository
”
befüllt” werden (vgl. Abb. 7.2.6).
Ein Repository kann als Bundle exportiert und importiert werden.

7.2. VERSIONSVERWALTUNGSSYSTEME 101
Abbildung 7.2.2: Wizard zum Erzeugen eines Mercurial-Repositorys
Das Klonen eines Repositorys erfolgt von der Kommandozeile:
ilap124:workspace fritzsch$ hg clone XXX YYY
Aktualisiere auf Zweig default
6 Dateien aktualisiert, 0 Dateien zusammengeführt, 0 Dateien entfernt, 0
Dateien ungelöst
ilap124:workspace fritzsch$

7.2. VERSIONSVERWALTUNGSSYSTEME 102
Abbildung 7.2.3: Speicherort für das Mercurial-Repository festlegen
Abbildung 7.2.4: Java-Projekt erweitern für Versionsverwaltung mit Mercurial

7.2. VERSIONSVERWALTUNGSSYSTEME 103
Abbildung 7.2.5: Repository im Projekt-Verzeichnis anlegen

7.2. VERSIONSVERWALTUNGSSYSTEME 104
Abbildung 7.2.6: Repository mit Konfigurationselementen befüllen
Abbildung 7.2.7: Bundle

7.3. AUFBAU EINES BUILD-PROZESSES 105
7.3 Aufbau eines Build-Prozesses
Die Schritte zur Erstellung eines Produkts sollen jederzeit wiederholt werden können. Sie
sollen deshalb automatisiert werden.
Obwohl der Build-Prozess abhängig von der Basistechnologie ist, gibt es Schritte, die
nahezu in jedem Build-Prozess berücksichtigt werden müssen (vgl. [Pop08]):
1. Quellelemente ermitteln
2. Produkt aus den Quellelementen erstellen
3. Produkt prüfen
4. Produkt ausliefern
5. Ergebnisse dokumentieren
Die Basis für jede Automatisierung bilden Skripte, die von einem Interpreter ausgeführt
werden. Beispiele für entsprehende Systeme sind Ant und Maven. Auch Shell-Skripte können
verwendet werden, die allerdings nicht plattformunabhängig sind.
Wird eine Version des Softwareproduktes an die Anwender ausgeliefert, bezeichnet man
dies als Release.
Die Werkzeuge Ant und Maven unterstützen die Projektautomatisierung.
7.4 Ant
7.4.1 Nutzung von Ant
Das Werkzeug Ant dient zur Umsetzung eines Build-Prozesses. Es ist ein Nachfolger von
make, aber nicht wie dieses an eine Plattform gebunden.
Ant ist ein Produkt der Apache Software Foundation und wird unter
http://ant.apache.org/bindownload.cgi u.a. als zip-Archiv bereitgestellt. Aktuell ist die
Version Ant 1.8.2. Das System ist nach der Installation von der Kommandozeile zu benutzen.
Zur Installation wird das Archiv heruntergeladen und in einem beliebigen Verzeichnis des lokalen
Dateisystems entpackt. Anschließend wird die Umgebungsvariable ANT_HOME definiert.
Sie soll auf das Homeverzeichnis des zuvor entpackten Ant-Archives verweisen.
Zur Ausführung von Ant wird ein JDK ab Version 1.5 benötigt. Der Pfad zum JDK sollte
Wert der Umgebungsvariablen $JAVA_HOME sein.
Die Umgebungsvariable PATH wird zweckmäßigerweise um $ANT_HOME/bin ergänzt.

7.4. ANT 106
Beispiel 2.
Vorbereitung der Nutzung von Ant an der Kommandozeile: ilap124:Downloads fritzsch$
export ANT_HOME=/Users/fritzsch/Downloads/apache-ant-1.8.2
ilap124:Downloads fritzsch$ export PATH=$Ant_HOME/bin:$PATH
ilap124:Downloads fritzsch$ ant -version
Apache Ant(TM) version 1.8.2 compiled on December 20 2010
ilap124:Downloads fritzsch$
Ant sucht im aktuellen Arbeitsverzeichnis nach einem Build-Skript mit dem Namen
build.xml.
Die Dokumentation ist im Unterverzeichnis $ANT_HOME/docs zu finden.
Ant kann in Eclipse-Java-Projekten genutzt werden (vgl. Abb. 7.4.1). Eine Auswahl
der auszuführenden Build-Ziele ist über einen Wizard möglich (Kontextmenü der Datei
build.xml → Run As ... → Ant ... , vgl. Abb. 7.4.3). Die Ziele wurden im Build-Skript
definiert. Wie Ziele definiert werden, wird im nächsten Abschnitt beschrieben.
7.4.2 Erstellung von Ant-Skripten
Ant-Skripte werden als XML-Dateien geschrieben. Auf der obersten Ebene eines Ant-Build-
Skripts ist das Project-Element angeordnet. Bei der Implementierung eines Build-Skriptes
sollten fest kodierte Werte vermieden werden. Alle Konstanten werden deshalb als Properties
definiert. Darunter werden Schritte in Form von Zielen (Targets) festgelegt.
Eine von mehreren Möglichkeiten für die Angabe von Properties ist
Properties gelten unabhängig vom Ort ihres Auftretens global für das gesamte Skript. Ein
einmal zugewiesener Wert kann nachfolgend nicht mehr geändert werden. Auf den Wert einer
Property kann nach der Definition an beliebiger Stelle im Skript mittels ${name} zugegriffen
werden. Folgende Properties sind vordefiniert:
${basedir}
${ant.file}
${ant.version}
${ant.project.name}
${ant.java.version}
Wert des basedir-Attributs im project-Element
Pfad des build-Skripts
Version von Ant
Name des Projektes entsprechend name-Attribut im
project-Element
Version der JVM, die Ant ausführt

7.4. ANT 107
Abbildung 7.4.1: Ant-Aufruf in Eclipse für das Projekt Jamus1.11

7.4. ANT 108
Abbildung 7.4.2: Auswahl der auszuführenden build-Ziele

7.4. ANT 109
Beispiel 3. Ant-Skript mit den Zielen
• Anlegen von Zielverzeichnissen (prepare),
• Generieren der API (gen-api),
• Übersetzen von Java-Klassen (compile)
Zeile 1 erklärt die Datei zu einer XML-Datei. Darauf folgt die Definition des Projekts. Mittels
des Attributs name wird der Name des Projektes festgelegt. Das Attribut basedir bestimmt
das Bezugsverzeichnis für Verzeichnisangaben in Zielen und Funktionen. Die Angabe „..”
ist sinnvoll, wenn das Skript selbst in einem Verzeichnis auf derselben Stufe mit src und
bin liegt.
Die bei Ausführung des Zieles prepare (Zeile 12) angelegten Verzeichnisse (sie werden erzeugt,
wenn sie noch nicht existieren) sind in Eclipse in der Projekt-Explorer-View oder der
Navigator-View erst nach einem refresh (F5) sichtbar.
Zeile 19 enthält die Definition eines Filesets zur Festlegung der Quelldateien, die bei Javadoc
einbezogen werden sollen.
Beim Aufruf von Ant wird der Name des auszuführenden Ziels als Parameter überge-

7.4. ANT 110
ben. Jedes Ziel besteht aus einer oder mehreren Funktionen (Tasks). Target-Namen legt
der Anwender fest, Task-Namen werden von Ant bereitgestellt. Die Funktionen bilden den
Befehlsumfang der Skriptsprache. Datentypen stellen die Variablen der Sprache dar.
Häufig muss nach dem Übersetzen auch ein Produkt erstellt werden.
Abbildung 7.4.3: Aufruf von Ant mit dem Ziel prepare
An der Console wird die Verarbeitung protokolliert (vgl. Abb. 7.4.4).
Zum Aufruf des Java-Compilers dient die Javac-Funktion. Eine Minimalversion verwendet
Quell- und Zielverzeichnis als Parameter.
Die Erzeugung eines Java-Archives aus .class-Dateien kann mittels der Jar-Funktion erfolgen.
Abb. 7.4.5 zeigt ein entsprechendes Ziel im Ant-Skript. Das erzeugte Archiv unixkunst.jar
hat (nach dem Entpacken) die im Verzeichnis unixkunst dargestellte Struktur (Abb. 7.4.6).

7.4. ANT 111
Abbildung 7.4.4: Protokollierung der Ant-Verarbeitung
Abbildung 7.4.5: Ziel zur Erzeugung eines Jar-Archives im Ant-Skript.
Abbildung 7.4.6: im Workspace erzeugtes jar-Archiv

7.5. MAVEN 112
7.5 Maven
Maven ist ein Produkt der Apache Software Foundation und wird unter
http://maven.apache.org/download u.a. als zip-Archiv bereitgestellt. Aktuell ist die Version
Maven 3.0.3. Das System ist nach der Installation von der Kommandozeile zu benutzen.
Zur Installation wird das Archiv heruntergeladen und in einem beliebigen Verzeichnis des
lokalen Dateisystems entpackt. Anschließend wird die Umgebungsvariable MAVEN_HOME definiert.
Sie soll auf das Homeverzeichnis des zuvor entpackten Maven-Archivs verweisen. Die
Umgebungsvariable PATH muss um $MAVEN_HOME/bin ergänzt werden. Weiterhin muss die
Umgebungsvariable JAVA_HOME gesetzt sein und es wird ein JDK ab Version 1.5 vorausgesetzt.
Mit dem Befehl mvn -version kann überprüft werden, ob die Variablen korrekt gesetzt
sind.
Beispiel 4.
ilap124:~ fritzsch$ export MAVEN_HOME=/Users/fritzsch/Downloads/apache-maven-3.0.3
ilap124:~ fritzsch$ export PATH=$MAVEN_HOME/bin:$PATH
ilap124:~ fritzsch$ mvn -version
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: /Users/fritzsch/Downloads/apache-maven-3.0.3
Java version: 1.6.0_15, vendor: Apple Inc.
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: "mac os x", version: "10.6", arch: "x86_64", family: "mac"
ilap124:~ fritzsch$
Maven basiert auf einem deklarativen, Modell-basierten Ansatz. Man beschreibt in einem
Projektmodell (POM genannt) die Metadaten des Projektes. Anhand der Metadaten legt
Maven den Build-Prozess fest und führt ihn aus. Maven kann nur deswegen automatisch den
Build-Prozess festlegen, weil es gewisse Annahmen über den Ablauf eines Build-Prozesses
macht.
Der Funktionsumfang von Maven kann unterteilt werden in:
1. Durchführung des Build-Prozesses
2. Verwaltung der Abhängigkeiten zu externen Bibliotheken
3. Erstellung der Projektdokumentation
Maven geht mit Abhängigkeiten im Build-Prozess vorbildlich um. Maven kümmert sich um
Verwaltung der externen Bibliotheken in Maven-Repositories (keine Versionierung!).
Maven bietet umfangreiche Unterstützung zur Erstellung einer Projekt-Homepage an.
Maven ist eine Java-Anwendung. Sie besteht aus einem kompakten Kern und verschiedenen
Plug-ins.
Der Kern ist in der Lage,

7.5. MAVEN 113
Abbildung 7.5.1: Maven Architektur nach Popp
• ein Projektmodell zu interpretieren und
• die zur Erstellung des Produktes notwendigen Schritte festzulegen (Phasen).
Jede einzelne Phase wird von einem Build-Ziel ausgeführt. Benötigte Build-Ziele müssen
als Plug-ins nachinstalliert werden. Die Nachinstallation erfolgt vollautomatisch über eine
Internet-Verbindung. Der Maven-Kern sucht plug-ins zunächst im lokalen Repository. Dieses
wird standardmäßig im Benutzerverzeichnis des Anwenders unter .m2\repository angelegt.
Ist ein Plug-in dort nicht vorhanden, wird das Plug-in-Repository durchsucht. Dieses befindet
sich standardmäßig unter
http://repo1.maven.org/maven2.
Das Projektmodell wird in einer XML-Datei erfasst, die standardmäßig pom.xml heisst.
Sie wird zweckmäßigerweise im Wurzelverzeichnis des Entwicklungsprojekts angelegt.
Das Projektmodell enthält:
... zur Beschreibung des zu erstellenden Artefakts. Weiterhin sind
die Pfade zu den Quellelementen festzulegen.
In Tabelle 7.1 sind wichtige Basisfunktionen von Maven zusammengestellt, die in der

7.5. MAVEN 114
Kommandozeile aufgerufen werden können. Die Syntax für den Aufruf lautet:
mvn basisfunktion [ basisfunktion ... ]
Basisfunktion
compile
test
package
install
clean
site
deploy
Verwendung
Compilieren der Quellcodes
Ausführen von Unit-Tests
Java-Archiv im target-Verzeichnis erzeugen
Kopieren des Java-Archivs in lokale Repository
Aufräumen des Projektverzeichnisses target
Erstellen der Dokumentation
Kopieren des Java-Archivs in ein angegebenes Repository
Das Compilieren zeigt Abb. 7.5.2.
Tabelle 7.1: Phasen
Installation des Maven-Plug-ins in Eclipse
Die ”
update site” für Maven muss dem Wizard zur Installation neuer Software in Eclipse
hinzugefügt werden.
Nach dem Installieren ist Maven im Kontextmenü eines Projektes verfügbar.

7.5. MAVEN 115
Abbildung 7.5.2: Compilieren

7.5. MAVEN 116
Abbildung 7.5.3: Maven für Eclipse
Abbildung 7.5.4: Maven-Auswahl

7.6. ZUSTANDSBASIERTES TESTEN MIT JUNIT UND JUNITDOCLET 117
7.6 Zustandsbasiertes Testen mit JUnit und JUnitDoclet
Im Zusammenhang mit dem Build-Prozess soll nachfolgend die Unterstützung des Testens
mit den Werkzeugen JUnit und JUnitDoclet behandelt werden. JUnit ist ein Java-
Framework, das bereits in Eclipse integriert ist und im Kontext der IDE genutzt werden
kann (mindestens ab Eclipse 3.6).
Betrachtet wird hier der Klassentest als spezielle Art eines Unit-Tests. Der Klassentest
basiert auf dem Konzept des ”
zustandsbasierten Testens”: Die Wirkung der Anwendung einer
Methode auf ein Objekt (Instanz) hängt im allgemeinen sowohl von den Methodenparametern
als auch vom aktuellen Zustand des Objekts ab.
Jeder Testfall umfasst
• die Erzeugung eines Objekts und das Versetzen des Objekts in einen bestimmten Ausgangszustand,
anschließend
• die Ausführung einer Operation (den Aufruf einer Methode, ”
invocation”) und danach
• die Validierung des durch die Operation herbeigeführten Endzustands.
Ein Objekt wird als sequentieller Zustandsautomat (FSA) betrachtet. Es wird davon ausgegangen,
dass die Menge der Zustände des AUtomaten endlich ist.
Beispiel. Als Beispiel betrachten wir eine Klasse Count zur Realisierung eines Zählers, der
bei 1 beginnend fortlaufend modulo 4 zählt. Abb. 7.6.1 zeigt den Quelltext.
Abbildung 7.6.1: Zu testende Klasse Count
Der aktuelle Zustand eines Objekts wird durch die Kombination der Attributwerte aller
Attribute zu einem bestimmten Zeitpunkt gebildet. Um die potentiell große Zahl von
Zuständen zu reduzieren, werden ”
verallgemeinerte Zustände” (Substates) gebildet.

7.6. ZUSTANDSBASIERTES TESTEN MIT JUNIT UND JUNITDOCLET 118
Der Zustand eines Count-Objekts soll vor und nach Ausführung einer Operation überprüft
werden. Es wird eine Klasse CountUT erzeugt, die von Count abgeleitet wird und dadurch
Zugriff auf die Attribute erlaubt.
Es werden zwei Ziele verfolgt:
1. Es soll ein Substate geprüft werden können. test-for-substate1 liefert true, wenn
der als Parameter übergebene Zustand tatsächlich vorliegt, und sonst false.
2. Es soll geprüft werden können, ob sich ein Attributwert geändert hat. iStoreMirror
ist die Spiegelung eines Attributs. Das Mirror-Attribut wird initialisiert durch Aufruf
der Operation test-for-substate-change1 mit true.
Der Test:
Abbildung 7.6.2: Klasse CountUT
fritzsch$ java -classpath /usr/share/junit:/usr/share/junit/junit.jar:.

7.6. ZUSTANDSBASIERTES TESTEN MIT JUNIT UND JUNITDOCLET 119
junit.textui.TestRunner JavaTests.CountUTTest
.
Test: testNext()
Test: fertig
Time: 0,002
OK (1 test)
fritzsch$

7.6. ZUSTANDSBASIERTES TESTEN MIT JUNIT UND JUNITDOCLET 120
Abbildung 7.6.3: Ableitung der Testklasse CountUTTest vom JUnit-Framework

7.6. ZUSTANDSBASIERTES TESTEN MIT JUNIT UND JUNITDOCLET 121
Abbildung 7.6.4: CountUTTest

7.7. GENERIEREN VON DOKUMENTATIONEN MIT JAVADOC 122
7.7 Generieren von Dokumentationen mit Javadoc
Mit dem Werkzeug Javadoc können zu Java-Quelltexten automatisch HTML-Dateien erzeugt
werden, die die Struktur und den Quellcode dokumentieren (API). Das Programm javadoc
ist Bestandteil des JDK.
Javadoc parst Java-Quelltexte und erkennt (in der Regel Methoden vorangestellte) Javadoc-
Kommentare in der Form:
Javadoc-Kommentare können Javadoc-Tags enthalten (vgl. Abb. 7.7.1). Ein Doclet erzeugt
die Ausgabe, es existieren Doclets für die Ausgabe in HTML, RTF, XML, PDF und
anderen Formaten.
Abbildung 7.7.1: Javadoc-Tags
Syntax des Aufrufs von der Kommandozeile:
javadoc [ options ] { package | sourcefile }
Alternativ zum Aufruf mit Quelldatei-Namen kann javadoc auch mit Paketnamen als

7.7. GENERIEREN VON DOKUMENTATIONEN MIT JAVADOC 123
Argument aufgerufen werden. Wenn nicht mit der Option -d etwas anderes verlangt wird,
erzeugt javadoc die Dokumentationsdateien im aktuellen Verzeichnis.
Abbildung 7.7.2 zeigt ein Beispiel zur Generierung mit Javadoc. Nach der Option -d wird
das Zielverzeichnis für die Generierung angegeben.
Abbildung 7.7.2: Beispiel eines Javadoc-Aufrufs
Javadoc kann auch in Eclipse verwendet werden. Die Generierung wird über das Projekt-
Menü erreicht (Abb. 7.7.3 und Abb. 7.7.4).
Abbildung 7.7.3: Javadoc in Eclipse
Die Visualisierung erfolgt nach der Generierung, indem die index.html mit einem Webbrowser
geöffnet wird.
Auch vom Quelltext aus können kontextabhängig mittels F3 die Javadoc Erklärungen in
einer separaten View angezeigt werden.

7.7. GENERIEREN VON DOKUMENTATIONEN MIT JAVADOC 124
Abbildung 7.7.4: Javadoc-Wizard

7.8. SIGNIEREN VON JAVA-ARCHIVEN 125
7.8 Signieren von Java-Archiven
Mit dem (kommandozeilenorientierten) keytool können
• eine keystore-Datei erzeugt werden,
• Schlüssel-Einträge und Zertifikat-Einträge in eine keystore-Datei vorgenommen werden.
Das keytool ist Bestandteil des JDK.

Kapitel 8
Wiederverwendung und Evolution
8.1 Individuelle Komponenten: Module und Klassen
Klassen verkörpern abstrakte Datentypen (ADT). Sie stellen Operationen zum Erzeugen
von Instanzeobjekten bereit und bilden damit eine Art von ”
Objektfabriken”. Neue Klassen
können von vorhandenen Klassen abgeleitet werden. Das kann in separaten Übersetzungseinheiten
erfolgen, bestehende Quelltexte müssen dazu nicht verändert werden.
Die Wiederverwendung individueller Komponenten ist nicht kostenlos. Es entsteht Aufwand
für das Ausfindigmachen anwendbarer Komponenten bzw. Klassen, für das Verstehen
von Schnittstellen und für die Wartung der Bibliotheken. Objektbasierte Sprachen allein
garantieren noch nicht die Wiederverwendung!
Beispiel. Die im JDK (Java Development Kit) bereitgestellte Standardbibliothek umfasst
folgende Pakete:
java.applet
java.awt
java.lang
java.io
java.net
java.util
Die Funktionalität der Standardbibliothek ist u.a. in [MSS96]beschrieben.
Bibliotheken mit Top-down-Routinen bzw. Klassen stellen keine Anwendungsstrukturen
bereit, d.h. die Systemarchitektur muss selbst definiert werden (vgl. Abb. 8.1.1). Das Verhalten
einzelner Routinen wird durch Parameter flexibel gestaltet.
Bei Bibliotheken mit Routinen im Callback-Verfahren liegt umgekehrt die gesamte Anwendungsarchitektur
in den Bibliotheksroutinen (vgl. Abb. 8.1.2). Die Routinen der Anwendung
werden meist zyklisch aktiviert.
126

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 127
Abbildung 8.1.1: Bibliotheken mit Top-down-Routinen bzw. Klassen
Abbildung 8.1.2: Bibliotheken mit Routinen im Callback-Verfahren
8.2 Komponentenbasierte Softwareentwicklung - Frameworks
Die komponentenbasierte Softwareentwicklung mit Frameworks wird u.a. von W. Pree in
[Pre97] ausführlich behandelt. Die nachfolgenden Beispiele entstammen dieser Quelle.
Ein Framework ist eine Sammlung individueller Komponenten mit definiertem Koperationsverhalten
zur Lösung einer bestimmten Aufgabe. Frameworks geben im Unterschied zu
gewöhnlichen Klassenbibliotheken die Architektur eines Systems vor, beschreiben also auch
die Interaktionen zwischen Komponenten (Verbindungslinien in den Abbildungen 8.2.2 und
8.2.3).
Gewisse Komponenten eines Frameworks sollen austauschbar sein. Solche ”
variablen”
Stellen eines Frameworks heißen Hot-Spots.
Whitebox-Frameworks bestehen aus einer Anzahl unvollständig spezifizierter Klassen, d.h.
Klassen mit abstrakten Methoden, sog. Einschubmethoden.
Um das Verhalten von White-Box-Frameworks zu verändern, wird Vererbung eingesetzt.
Einschubmethoden werden in den Unterklassen der Frameworkklassen überschrieben. Die
Architektur der Anwendung verbleibt dabei im Framework. Beispiel (Abbildung 8.2.1) : Die
grau markierte Methode in Klasse A wird in einer Unterklasse A1 überschrieben.
Um Methoden sinnvoll überschreiben zu können, muss ein Programmierer das Framework
bis zu einem gewissen Detaillierungsgrad gedanklich erfasst und verstanden haben.

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 128
. . .
. . .
Frameworkklassen
. . .
A
B
A1
Anpassung
des
Frameworks
Abbildung 8.2.1: Beispiel für eine Hierarchie von Frameworkklassen
Blackbox-Frameworks bestehen aus einer Anzahl fertiger Komponenten. Anpassungen des
Frameworks werden durch Kompositionen der Komponenten erreicht, nicht durch Vervollständigung
von Klassen, also nicht durch Programmierung.
Beispiel. An den Stellen A und B in Abb. 8.2.2 werden Instanzen benötigt, die zu den
Klassen A und B kompatibel sind. Flexibilität wird dadurch erreicht, dass an diesen Stellen
Instanzen der Klassen A1 und B2 gebildet und entsprechend eingesetzt werden, wie in Abb.
8.2.3 gezeigt . Bei B liegt eine gebrauchsfertige Unterklasse vor. Bei A existiert eine abstrakte
Methode (grau), die die Unterklasse A1 erst noch spezifizieren muss.
Aus einem Whitebox-Framework entwickelt sich mit zunehmendem Reifegrad ein Blackbox-
Framework. Gängige Frameworks sind weder reine Whitebox- noch reine Blackbox-Frameworks.
Nachfolgend soll nun an einem Beispiel dargestellt werden, wie ein Framework entwickelt
und für die Entwicklung einer Anwendung nachgenutzt und angepasst wird.
Beispiel. Entwicklung eines Frameworks zur Simulation diskreter Ereignisse ( ”
Diskrete Simulation”).
Das Framework soll anschließend zur Simulation einer Kasse im Supermarkt und
zur Simulation eines Parkhauses verwendet werden.
Zentrale Elemente einer Simulation sind Ereignisse mit zugeordneter Zeit (Zeitpunkt,
zu dem ein Ereignis eintritt. Zum Beispiel der Zeitpunkt, zu dem ein Kunde an der Kasse
eines Supermarktes erscheint). Ereignisse werden durch einen Zufallsgenerator erzeugt. Die
Simulation entwickelt sich in Richtung der Zeitachse und sammelt statistische Informationen.

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 129
A
B
Abbildung 8.2.2: Framework vor der Spezialisierung
A1
B2
Abbildung 8.2.3: Framework nach der Spezialisierung
Ein Actor (oder Akteur) ist ein Paar: Ereignis - Aktion (vgl. Abb. 8.2.4). Akteure wissen,
wie sie auf erhaltene Nachrichten zu reagieren haben. In der Instanzvariablen time ist der
Zeitpunkt des Eintritts des Ereignisses gespeichert. Die Methode commit() kapselt die Funktionalität
des Actors. Das Simulationsframework ruft commit() auf, wenn die Eintrittszeit
des Ereignisses erreicht ist.
Die Klassen Simulation und Actor repräsentieren das Simulationsframework (vgl. Abb.
8.2.5). Eine Instanz von Simulation verwaltet Akteure in einer SortedQueue.
Eine Methode schedule der Klasse Simulation fügt einen Actor entsprechend dem
Eintrittszeitpunkt seines Ereignisses in die SortedQueue ein. Die Zeit des Actors wird auf
die aktuelle Simulationszeit eingestellt.
Die Methode simulate iteriert über den Actor-Objekten in der SortedQueue (vgl. Abb.
8.2.6). Dabei wird die aktuelle Zeit jeweils auf die Zeit des Actors eingestellt. Danach wird

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 130
Abbildung 8.2.4: Klasse Actor
Abbildung 8.2.5: Simulations-Framework
eine commit()-Nachricht an den Actor gesendet. Die Simulation endet, wenn die zu Beginn
der Simulation eingestellte Simulationszeit verbraucht ist (Parameter duration). Sind keine
Actor-Objekte mehr in der Warteschlange, wird das Ende der Simulation erzwungen.
Auf die jeweils aktuelle Simulationszeit kann bei der Erzeugung neuer Actor-Objekte
während des Ablaufens der Simulation Bezug genommen werden. In der Instanzvariablen
time wird die Eintrittszeit des Ereignisses gespeichert.
Mittels der Methode reset kann die Simulation ”
auf Anfang” gestellt werden: Die Warteschlange
in SortedQueue wird gelöscht und die abgelaufene Simulationszeit wird zurückgesetzt
(time=0).
Die Klasse Simulation realisiert eine (abstrakte) Simulation auf der Basis des Protokolls
der abstrakten Klasse Actor. Jede Instanz von Simulation kann mit jeder Instanz von Actor
oder jeder Subklasse von Actor interagieren, und das ohne Änderungen und Neuübersetzung.
Das Verhalten von Actor (abstrakt!) kann später überschrieben werden.
Das Framework setzt die Existenz von Klassen zur Realisierung von Warteschlangen
voraus. Die in Abb. 8.2.7 gezeigten Klassen werden im Package Qs des Simulationsframeworks
bereitgestellt. Die Einträge in einer Queue sind vom Typ QueueItem. Diese Klasse ist
ebenfalls im Package Qs enthalten. Die Einträge in einer SortedQueue werden gemäß Ereigniszeitpunkt
geordnet. Aufgrund der Polymorphie können Queue-Objekte auch Instanzen
von Unterklassen von Actor speichern.
Durch die Klassen Simulation und Actor wird ein White-Box-Framework gebildet. Die-

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 131
public class Simulation{
public long time;
protected SortedQueue actors;
...
public void simulate(long duration){
Actor actor;
long endOfSimulation = time + duration;
do{
if (!actors.isEmpty()){
actor = actors.dequeue();
time = actor.time;
actor.commit();
} else // no more actors enqueued
time = endOfSimulation + 1;
} while (time

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 132
Abbildung 8.2.7: Warteschlangen
in die SortedQueue mit einem zeitlichen Abstand ein, der seiner Bediendauer entspricht.
Kommt ein neuer Kunde an, während noch ein anderer Kunde bedient wird, wird der neue
Kunde in die Kundenwarteschlange waitingLine eingereiht (Aufruf der Methode requestService).

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 133
public class SimpleServiceStation{
protected Simulation sim;
protected FIFOQueue waitingLine = new FIFOQueue();
...
public void requestService(Customer c){
}
if (path.n == 0)
// Warteschlange leer
// und kein Kunde wird gerade bedient ?
c.activate();
else
waitingLine.enqueue(c);
// Kunden in die Kundenwarteschlange
// aufnehmen
...
// Erstellen von Statistiken
}
public void free(){
Actor actor;
}
...
// Erstellen von Statistiken
...
if (path.n > 0){
// Warteschlange enthaelt Kunden ?
actor = waitingLine.dequeue();
if (actor instanceof Customer)
((Customer)actor).activate();
}
Abbildung 8.2.8: Klasse SimpleServiceStation realisiert eine Kasse

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 134
public class Customer extends Actor{
SimpleServiceStation station;
Simulation simulation;
long arrivalTime;
public Customer(long t, SimpleServiceStation s, Simulation sim){
super(t);
station = s;
simulation = sim;
arrivalTime = simulation.time;
}
public void commit(){
station.free();
...
}
public void activate(){
int myServiceDuration;
simulation.schedule(this,simulation.time +
(myServiceDuration =
(int)(RandomNumbers.negExp(
station.avrgServiceDuration))));
...
}
}
Abbildung 8.2.9: Klasse Customer

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 135
public class CustomerGenerator extends Actor{
SimpleServiceStation station;
Simulation simulation;
public CustomerGenerator(long t, SimpleServiceStation s, Simulation sim){
super(t);
station = s;
simulation = sim;
}
public void commit(){
Customer c = new Customer(0,station,simulation);
...
station.requestService(c);
simulation.schedule(
new CustomerGenerator(0,station,simulation),
simulation.time + (long)(RandomNumbers.negExp(station.arrivalRate)));
}
...
}
Abbildung 8.2.10: Klasse CustomerGenerator
Abbildung 8.2.11: Szenario zur Bedienung eines Kunden

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 136
Abbildung 8.2.12: Nutzung des Frameworks ”
Diskrete Simulation”

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 137
Entwurfsüberlegungen Eine Schwachstelle in der Realisierung der Anwendung ist die enge
Kopplung zwischen den Klassen CustomerGenerator, Customer und SimpleServiceStation:
Die Methode commit von CustomerGenerator erzeugt direkt Customer-Objekte. Die Klasse
SimpleServiceStation arbeitet direkt mit einem Customer-Objekt. Problematisch wird es
damit bei späteren Veränderungen. Zum Beispiel könnte eine Service-Station mit zwei Bedienern
gewünscht sein oder der Ausfall eines Bedieners soll realisiert werden können. Es
werden nachfolgend Mittel gezeigt, wie Frameworks flexibler gestaltet werden können.
Platzierung von Einschubmethoden Schablonenmethoden rufen Einschubmethoden (engl.
hook) auf. Das Überschreiben an vorgegebenen Einschubstellen (in abgeleiteten Klassen) verändert
das Verhalten, ohne dass der Quellcode der Klasse geändert werden muss.
So könnte es im Beispiel Diskrete Simulation interessant sein, die Anzahl benachrichtigter
Actor-Objekte zu erfassen. Abb. 8.2.13 zeigt, wie das Verhalten der Methode simulate
(Schablonenmethode) teilweise (Ausketten und Benachrichtigen eines Actors) in eine Einschubmethode
notificationHook ausgelagert wird. Die Hook-Methode besitzt standardmäßig
eine leere Implementierung. Eine von der Klasse Simulation abgeleitete Klasse MySimulation
kann dann die Einschubmethode notificationHook mit der gewünschten Funktionalität definieren
(vgl. Abb. 8.2.14).
Abbildung 8.2.13: Schablonenmethode simulate und Einschubmethode notificationHook
Entkopplung der Klassen CustomerGenerator und Customer Die Klasse CustomerGenerator
unterstützt explizit die Erzeugung von Customer-Objekten (vgl. Abb. 8.2.10). Das Verhalten
kann auch hier durch die Definition von Unterklassen veränderbar gestaltet werden.
Die Klasse CustomerGenerator wird jetzt durch eine Klasse ActorGenerator ersetzt
(vgl. Abb. 8.2.15).
Wenn Schablonen- und Einschubmethoden sich in einer Klasse befinden, kann Verhalten
nur durch die Definition weiterer Unterklassen verändert werden (Quellcode!). Damit sind
Anpassungen zur Laufzeit nicht möglich.

8.2. KOMPONENTENBASIERTE SOFTWAREENTWICKLUNG - FRAMEWORKS 138
Abbildung 8.2.14: Definition der Hook-Methode in der abgeleiteten Klasse MySimulation
public class ActorGenerator extends Actor {
...
public void commit(){
Actor a=makeActor();
station.requestService(a);
}
public void makeActor(){
return new Customer( ... );
}
...
}
Abbildung 8.2.15: Klasse ActorGenerator
Flexibilität zur Laufzeit durch Komposition Einschubmethoden erlauben flexible Anpassungen
zur Laufzeit, wenn ihre Klasse mit der Klasse abstrakt gekoppelt ist, die die zur
Einschubmethode gehörende Schablonenmethode enthält.
Beispiel Diskrete Simulation: In der bisherigen Lösung wird die abstrakte Methode
enqueue() der Klasse Queue in Unterklassen überschrieben.

8.3. ENTWURFSMUSTER 139
8.3 Entwurfsmuster
Wesentliche Beiträge zur Thematik der Entwurfsmuster wurden von E. Gamma et al. geleistet
[GHJV09]. Die Autoren stellten einen Katalog von 23 Entwurfsmustern vor.
Ein Muster beschreibt allgemein ein in unserer Umwelt beständig wiederkehrendes Problem
und erläutert den Kern der Lösung für dieses Problem. So kann die Lösung beliebig oft
angewendet werden, ohne sie jemals ein zweites Mal gleich auszuführen.
Die hier beschriebenen Entwurfsmuster beschreiben zusammenarbeitende Objekte und
Klassen, die so zugeschnitten sind, dass sie ein allgemeines Entwurfsproblem in einem bestimmten
Kontext lösen. Entwurfsmuster sind typischerweise in Anwendungen vorkommende
Kombinationen von Klassen zu größeren Einheiten, unabhängig von der Programmiersprache.
Muster sind durch vier grundlegende Elemente beschrieben:
1. Mustername
2. Problemabschnitt
3. Lösungsabschnitt
4. Konzequenzenabschnitt
Der von Gamma et al. angegebene Katalog ordnen die Muster drei Klassen zu. Danach gibt
es Erzeugungsmuster, Strukturmuster und Verhaltensmuster.
Das Fabrikmethode-Muster
Das Fabrikmethode-Muster ist ein Klassen-basiertes Erzeugungsmuster. Die Verwendung
erfolgt in einem Framework, bestehend aus den abstrakten Klassen Product und Creator.
Die Klasse Creator bietet eine Schnittstelle zum Erzeugen von Instanzen an. Das Muster
wird genutzt, wenn eine Klasse (hier: Creator) die von ihr zu erzeugenden Objekte nicht im
Voraus kennen kann (andernfalls könnte der Konstruktor direkt aufgerufen werden.
Die abstrakte Methode createProduct() heißt Fabrikmethode.
Das Beobachter-Muster
Das Beobachtermuster ist ein Objekt-basiertes Verhaltensmuster (auch als Publisher - Subscriber
- Muster bezeichnet).
Definiere eine 1-zu-n-Abhängigkeit zwischen Objekten, so dass die Änderung des Zustandes
eines Objektes dazu führt, dass alle abhängigen Objekte benachrichtigt und automatisch
aktualisiert werden.
Beispiel. Zeitgeber ist eine konkrete Subjektklasse zum Verwalten der Tageszeit. Der zeitgeber
benachrichtigt den Beobachter jede Sekunde.
Eine Digitaluhr ist ein Beobachter.

8.3. ENTWURFSMUSTER 140
Abbildung 8.3.1: Fabrikmethode-Muster
Abbildung 8.3.2: Beobachter-Muster
Das Kompositum-Muster
Füge Objekte zu Baumstrukturen zusammen, um Teil-Ganzes-Hierarchien zu repräsentieren.
Das Kompositionsmuster ermöglicht es Klienten, einzelne Objekte sowie Kompositionen von
Objekten einheitlich zu behandeln.
Das Strategie-Muster
Das Muster ist verhaltensorientiert.
Definition. Definiere eine Familie von Algorithmen, kapsele jeden einzeln und mache sie
austauschbar. Das Strategiemuster ermöglicht es, den Algorithmus unabhängig von ihn nutzenden
Klienten zu variieren.

8.3. ENTWURFSMUSTER 141
public class Zeitgeber extends Subject{
...
int gibStunde(){ }
int gibMinute(){ }
int gibSekunde(){ }
void tick(){
// aktualisiert internen Zustand des Zeitgebers
benachrichtige();
}
...
}
Abbildung 8.3.3: Klasse Zeitgeber
Abbildung 8.3.4: Strategiemuster
Proxy-Muster (Proxy)
Definition. Kontrolliere den Zugriff auf ein Objekt mit Hilfe eines vorgelagerten Stellvertreterobjekts.
Der Proxy leitet Befehle an das echte Objekt weiter.
Singleton-Muster (Singleton)
Das Singleton-Muster ist ein Erzeugungsmuster.
Definition. Sichere ab, dass eine Klasse genau eine Instanz besitzt (nur eine) und stelle
einen globalen Zugriffspunkt darauf bereit.
Dies wird üblicherweise durch private-Konstruktoren in Kombination mit static-Klassenfeldern
realisiert.

8.3. ENTWURFSMUSTER 142
Abbildung 8.3.5: Proxy-Muster
Abbildung 8.3.6: Singleton-Muster
public final class Singleton {
private static Singleton uniqueInstance = null;
private Singleton(){ }
public static Singleton instance(){
if (uniqueInstance == null) {
uniqueInstance = new Singleton();
}
return uniqueInstance; }
}
In den meisten Fällen scheinen Singletons unnötig zu sein. Nach Keriewsky ist ein Singleton
unnötig, wenn es einfacher ist, eine Objektressource als Verweis auf die Objekte, die
sie benötigen, zu übergeben, als Objekte global auf die Ressource zugreifen zu lassen. Ein
Singleton ist unnötig, wenn es dazu verwendet wird, unbedeutende Speicher- oder Leistungsverbesserungen
zu erzielen[. . . ].
Fassade-Muster (Facade)
Definition. Biete eine einheitliche, einfache Schnittstelle zu einer Menge von Schnittstellen
bzw. Klassen (Paket). Die Fassadenklasse definiert eine abstrakte Schnittstelle, um die

8.3. ENTWURFSMUSTER 143
Benutzung des Pakets zu vereinfachen.
Die Facade weiß, welche Klassen des Pakets für die Bearbeitung einer Botschaft zuständig
sind und delegiert Botschaften an die zuständige Klasse. Die Fassade definiert keine neue
Funktionalität!
Adapter-Muster (Adapter, Wrapper)
Definition. Passe die Schnittstelle einer Klasse an eine andere, von Kunden erwartete
Schnittstelle an. Zur Anpassung eines Interfaces an ein anderes wird ein Adapterobjekt verwendet.
Abbildung 8.3.7: Adapter-Muster
Schablonenmethode-Muster (Template)
Das Muster ist verhaltensorientiert und objektbasiert.
Definition. Definiere das Skelett eines Algorithmus in einer Operation und delegiere einzelne
Schritte an Unterklassen. Die Verwendung einer Schablonenmethode ermöglicht es Unterklassen,
bestimmte Schritte eines Algorithmus zu überschreiben, ohne seine Struktur zu
verändern.
Schablonenmethoden bilden die grundlegende Technik zur Wiederverwendung von Code.
Im Beispiel (vgl. Abb. 8.3.8) werden in der Schablonenmethode templateMethod() die
Einschubmethoden hookOperation1 und hookOperation2 aufgerufen.
Das Schablonenmethode-Muster haben wir in der Anwendung ”
Diskrete Simulation” verwendet
(vgl. Abb. 8.2.13).

8.3. ENTWURFSMUSTER 144
Abbildung 8.3.8: Schablonenmethode

Kapitel 9
Musterarchitekturen
In diesem Kapitel geht es um die Nachnutzung konkreter Softwarebausteine und Techniken
zu deren Nutzung. Dabei steht die Nützlichkeit für die Entwicklung von typischen Applikationen
im Vordergrund. Solche Applikationen haben eine Client-Server-Architektur, greifen
serverseitig auf Datenbanken zu und benötigen clientseitig grafische Benutzeroberflächen.
9.1 Die MVC-Architektur
Das Model-View-Controller-Prinzip, das bereits in der Programmiersprache Smalltalk für
die Konstruktion von Benutzerschnittstellen Anwendung fand, bietet einen Ansatz für die
Architektur von Anwendungen, die aus einer grafischen Benutzeroberfläche, einem funktionalen
Kern und einer Datenverwaltung bestehen sollen. Ein Model–Objekt stellt das Anwendungsobjekt
dar, das View–Objekt seine Bildschirmrepräsentation und das Controller–
Objekt bestimmt die Möglichkeiten, mit denen auf Benutzereingaben reagiert werden kann.
Grundgedanke ist, dass View und Model durch den Aufbau eines Protokolls zur gegenseitigen
Benachrichtigung entkoppelt werden. Das Model-Objekt repräsentiert das Anwendungsobjekt.
Ein oder mehrere View-Objekte verkörpern Bildschirmrepräsentationen. Das Controller-Objekt
bestimmt die Möglichkeiten, mit denen auf Benutzereingaben reagiert werden
kann.
View und Model werden durch den Aufbau eines Protokolls zur Benachrichtigung voneinander
entkoppelt.
145

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 146
Der Antwortmechanismus der Oberfläche wird in einen Controller gekapselt.
Die MVC-Architektur verwendet die Entwurfsmuster Beobachter und Strategie.
Ein interessanter Gesichtspunkt ist die Realisierung von der Komponenten in eigenständigen
Threads.
9.2 Grafische Benutzeroberflächen
Die Entwicklung grafischer Benutzeroberflächen erfordert Aktivitäten auf zwei spezielleren
Gebieten:
- Oberflächenprogrammierung
- Grafikprogrammierung
Grafische Benutzeroberflächen werden aus vordefinierten Komponenten komponiert. Nachfolgend
werden die für Java-Anwendungen verfügbaren Bibliotheken
• AWT (schwergewichtig, plattformunabhängig),
• Swing (leichtgewichtig, plattformunabhängig) und
• SWT (plattformabhängig, schwergewichtig)
behandelt.
Der Aufbau einer GUI erfordert 2 Schritte:
1. das Erstellen einer Struktur aus Grafik-Komponenten
2. das Implementieren von Aktionen, die über GUI-Objekte ausgelöst werden.
9.2.1 Java AWT
Das ”
Abstract Window Toolkit” (AWT) stellt eine plattformunabhängige Standard-API für
die Programmierung grafischer Oberflächen dar und ist Bestandteil der Java Foundation
Classes (JFC). Das Toolkit umfasst vordefinierte Klassen, die je nach Betriebssystem die
geeigneten Bibliotheken benutzen (für UNIX z.B. Motif).
Portabilität: Peers Die AWT–Objekte setzen nicht dierekt auf der Programmierschnittstelle
(API) einer bestimmten Betriebssystemplattform auf. Die Unabhängigkeit der GUI-
Klassen von der Betriebssystem-API wird durch Peers sichergestellt. Peers sind in Java
geschriebene Interfaces, die im Paket java.awt.peer enthalten sind. Für unterschiedliche
Plattformen werden Peer-Schnittstellen unterschiedlich implementiert (vgl. Abb. 9.2.1).
Der Aufbau der AWT-Klassenbibliothek ist ein Beispiel für die Anwendung des Entwurfsmusters
Kompositum” (vgl. Abschnitt 8.3).
”
Alle Komponenten sind von der abstrakten Klasse Component abgeleitet. Komponenten
können

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 147
Abbildung 9.2.1: Peers sichern die Plattformunabhängigkeit (Abb. aus [MSS96]).
• mittels setVisible sichtbar oder unsichtbar
• mittels setEnabled selektierbar/nicht selektierbar (enable/disable)
gemacht werden. Komponenten haben weitere Merkmale, z.B. x-y-Koordinaten. Komponenten
können mit dem Benutzer interagieren.
Eine gewisse Inkonsequenz besteht darin, dass nicht alle Methoden bei allen von Component
abgeleiteten Klassen sinnvoll sind.
Container sind Komponenten, die andere Komponenten enthalten können (ermöglicht
die Hierarchiebildung!). Dazu enthalten Container einen Vektor von Komponenten. Container
werden nicht direkt instantiiert.
Windows (Klasse Window) und Panels (Klasse Panel) sind spezielle Container. Objekte
der Klasse Window besitzen keinen Rahmen und keine Menüleiste. Panel-Objekte können als
Zeichenelement genutzt werden (z.B. Platzierung eines Buttons auf einem Hintergrundbild).
Die Klasse Frame repräsentiert einen Container, der ein Fenster mit Rahmen bildet.
Elementare AWT-Komponenten (wie Button, Checkbox, TextArea usw. ) werden hier
nicht besprochen. Häufig benötigte ”
Radiobuttons” werden - etwas umständlich - mit Hilfe
der Klassen CheckboxGroup realisiert.
9.2.2 Die Layout-Manager
Jeder Container verwaltet einen (Voreinstellung beachten!) Layout-Manager. Layout-Manager
nehmen dem Anwender die Arbeit der absoluten Positionierung von Komponenten in Containern
ab. Sie definieren Regeln, nach denen Komponenten in einem Container platziert
werden. Komponenten können mit Containern mitwachsen.
FlowLayout Die Anordnung der Elemente erfolgt nebeneinander in logischer Reihenfolge.
Die Komponenten werden in mehreren Reihen dargestellt, falls der Container zu schmal ist,

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 148
um die Komponenten in einer Zeile darzustellen.
FlowLayout ist der voreingestellte Layout-Manager von Panel.
BorderLayout Es gibt maximal 5 Komponenten: oben, links, mitte, rechts, unten. Beim
Hinzufügen einer Komponente zum Container muss zusätzlich eine der Zeichenketten North,
East, South, West oder Center als Parameter angegeben werden. Ein im Zentrum hinzugefügtes
Panel nimmt den gesamten Raum des Containers ein, wenn keine weiteren Plätze
belegt werden.
CardLayout Anordnung der Komponenten in einem Stapel (ähnlich Spielkarten), nur die
oberste Komponente ist sichtbar. Es gibt vier Methoden zum Blättern.
GridLayout Anordnung der Komponenten in einem Gitter aus gleichgroßen Gitterzellen.
Jede Komponente nimmt eine Gitterzelle ein. Die Breite bzw. Höhe der Gitterzellen richtet
sich nach der breitesten bzw. höchsten Komponente. Gitterzellen werden von links oben nach
rechts unten mit Komponenten aufgefüllt.
GridBagLayout Ähnlich dem GridLayout, aber flexibler. Eine Komponente kann sich
über einen Anzeigebereich von mehreren Gitterzellen erstrecken. Spalten/Zeilen können unterschiedlich
breit/hoch sein. Die Einstellung der Eigenschaften des GridBagLayout erfolgt
über eine Instanz der Klasse GridBagConstraints. Diese Klasse enthält keine Methoden,
ihre Instanzvariablen müssen in der gewünschten Weise belegt werden.
Die Methode setConstraints der Klasse GridBagLayout erzeugt eine Verknüpfung
zwischen der hinzuzufügenden Komponente und der GridBagConstraints-
Instanz:
setConstraints( Component comp, GridBagConstraints const)
9.2.3 Swing 1.1
Swing ist eine API und eine Grafikbibliothek zum Programmieren von grafischen Benutzeroberflächen.
Dokumentationen zu Swing sind unter folgenden Adressen zu finden:
1. The Swing Connection
http://java.sun.com/products/jfc/swingdoc-current/
2. The Component Gallery
http://java.sun.com/products/jfc/swingdoc-current/comp\ gal.html
3. Using the JFC/Swing Components
http://java.sun.com/docs/books/tutorial/ui/swing/index.html
Swing-Komponenten sind von java.awt.container abgeleitet (vgl. Abb. 9.2.3).

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 149
9.2.4 Entwurf eines Swing–GUI
Jedes Programm, das ein Swing-GUI repräsentiert, enthält wenigstens einen Toplevel-Swing-
Container, d.i. eine Instanz von
• JFrame oder
• JDialog oder
• JApplet.
MVC-Architektur für GUI-Komponenten
Neu in Swing sind die Klassen ChangeEvent und ChangeListener zur Behandlung von
Zustandsänderungen an Modellen. View und Controller sind in einem Objekt vereinigt, das
Delegate heißt. Delegates
• rendert das Modell (View-Aspekt) und
• übertragen Nutzereingaben zum Modell (Controller-Aspekt).
Eine JComponent hat
• ein simple model und
• ein simple delegate.
Mögliche Models für eine spezielle JComponent sind Klassen, die ein für die Komponente spezifisches
Model Interface implementieren. Mögliche Delegates für eine spezielle JComponent
sind Klassen, die ein für die Komponente spezifisches Delegate Interface implementieren. Alle
Delegates sind von ComponentUI abgeleitet.
MVC-Architektur und GUI-Event Handling
Die Verwendung der MVC-Architektur wird nachfolgend an einem Beispiel (Klasse SwingMVC)
demonstriert. Das GUI der betrachteten Anwendung (vgl. Abb. 9.2.4) besitzt ein TextField
zur (wiederholten) Eingabe einzelner Ganzzahl-Werte (links), die zu einer Liste hinzugefügt
werden sollen. Ein TextArea dient zur Visualisierung aller eingegebenen Werte (rechts
oben). Aus allen in der Liste eingetragenen Zahlen wird ein Mittelwert berechnet und in
einem weiteren Textfeld (TextField) angezeigt (rechts unten in Abb. 9.2.4).
Eine ”
Liste” fungiert als Modell für zwei Views. Ein Objekt der Klasse IntVectorModel
verwaltet dazu als Modell einen Vektor von Integer-Zahlen. Das TextArea ListView zur
Visualisierung der Werte hat den Status ”
nicht editierbar”. Zur Benachrichtigung wird das
Event-Handling benutzt. Die Views (avgField und textList) fungieren als ChangeListener
zum Modell (implementieren ein ChangeListener-Interface). Sie benutzen eine Methode stateChanged.
Das zur Eingabe vorgesehene Textfeld fungiert als Controller, der Nutzereingaben in die Liste
überträgt. Dies erfolgt mittels eines Action-Listeners.

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 150
Motivation: Der Mittelwert kann nicht von der View-Liste berechnet werden. Problem:
Falls die View-Liste abgeschaltet wird, kann kein Mittelwert mehr berechnet werden.
Bevor mit der Implementierung begonnen wird, wird noch eine weitere Entwurfsüberlegung
umgesetzt: Mit Hilfe von Adaptern werden Controller, Modell und Views noch voneinander
entkoppelt. Im Konstruktor SwingMVC(...) der Anwendung werden drei Adapter-
Objekte erzeugt, die die Funktion der Listener übernehmen (Abb. 9.2.5).
Der Controller kennt nur den Adapter cm, das Modell kann gegebenenfalls geändert werden,
ohne den Controller zu verändern. Das Modell kennt ebenfalls nur die Adapter mv1 und
mv2, die Views können geändert werden, ohne das Modell anpassen zu müssen.
Der Adapter mv1 wirkt als ChangeListener beim Modell, er kennt Modell und View.
Wird sein Handler aktiviert, wirkt das als Benachrichtigung, dass sich das Modell geändert
hat. Er holt mit der Methode getData() die relevanten Daten aus dem Modell ab und reicht
sie an die View weiter.
9.2.5 JTree - Anwendung
Die Klasse JTree im Package java.swing.tree ist die Basisklasse für die Präsentation
hierarchischer Strukturen. Die Klasse ist von JComponent abgeleitet und implementiert die
Interfaces Scrollable und Accessible. Ein JTree-Objekt enthält selbst keine Daten. Daten
werden über das Datenmodell der Komponente beschafft.
Jede durch ein JTree-Objekt angezeigte Zeile präsentiert ein Datenelement, d.h. einen
Knoten des Baumes. Es werden Blattknoten (die keine Nachfolger haben können) und innere
Knoten (die Nachfolger haben können) unterschieden.
Innere Knoten können ”
expanded” oder ”
collapsed” sein. Knoten vom Typ ”
hidden” sind
solche, die als Vorfahren einen ”
collapsed” Knoten haben.
Verwendete Interfaces:
• TreeModel beschreibt das Datenmodell
• TreeSelectionModel
• TreeCellRenderer spezifiziert die Visualisierung von Knoten im Baum
• TreeNode und MutableTreeNode beschreiben, was an jedem Knoten des Baumes dargestellt
wird
Beispiel. Eine Anwendung von JTree findet man in dem im Rahmen der Lehrveranstaltung
Software-Qualitätssicherung” entwickelten Testwerkzeug Jamus:
”
i:\Prakt\fritzsch\QSM\Projekt
Beispiel. Die mit Swing gelieferte Anwendung SampleTree demonstriert zusätzlich die dynamische
Erweiterung hierarchischer Strukturen.

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 151
9.2.6 SWT: Das Standard Widget Toolkit
Das SWT gehört zu den Komponenten (Plug-ins) der Eclipse-Workbench und steht gleichzeitig
für Software-Entwickler als API zur Verfügung. Die Widgets des SWT sind in org.eclipse.swt.widgets
enthalten.
Zum Kennenlernen des SWT werden innerhalb der Eclipse-Dokumentation ”
Examples”
beschrieben, die in der Eclipse-Workbench als lauffähige Anwendungen bereit gestellt werden
können.
Die Eclipse-Dokumentation (Helios) insgesamt ist unter http://help.eclipse.org/helios/index.jsp
erreichbar.
Die Beispiele für die Nutzung des SWT sind darin erreichbar über
→ Platform Plug-in Developer Guide
→ Examples Guide
→ Standard Widget Toolkit
→Using the SWT example launcher
Zum Erproben der Examples gibt es einen SWT Example Launcher. Die SWT-Examples
können ”
Workbench Views”(in der aktuellen Eclipse-Perspektive geöffnet) sein oder ”
standalone”-
Applikationen (launched in separatem Fenster).
Nach seiner Installation in Eclipse kann der Launcher gestartet werden:
Window → Show View → Other. Weiter Im Dialog : → SWT-Examples → SWT
Example Launcher. Bei Auswahl wird der Launcher als Eclipse-View geöffnet. Über den
gezeigten Explorer können Beispiele ausgewählt und mittels des Buttons ”
run” gestartet
werden. Die Ausführung des ”
standalone”-Examples ”
Hello World (5)” zum Beispiel öffnet
ein Frame (vgl. Abb. 9.2.6).
Das SWT ist (im Unterschied zu JFace) ein ”
low level”-Toolkit. Den Kern von SWT
bilden Widgets, Layouts und Events.
Eine typische ”
stand alone”-Applikation mit SWT umfasst:
• Erzeugen eines ”
Display”-Objekts zur Repräsentation einer Session,
• Erzeugen einer oder mehrerer ”
Shells”, die das oder die Hauptfenster der Applikation
repräsentieren,
• Erzeugen weiterer ”
Widgets”, die innerhalb der Shell verwendet werden,
• Initialisieren der Zustände der Widgets (z.B. der Größe) und Registrieren der benötigten
Event-Listener,
• Öffnen der Shell,
• Behandlung von Events bis zum Auftreten einer erfüllten Abbruchbedingung und
Schließen des Shell-Fensters,
• Beenden der ”
Display”-Session.

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 152
Display Die Klasse Display (org.eclipse.swt.widgets.Display) bildet die Verbindung zwischen
SWT und dem GUI-System der Plattform. Displays dienen dem Management der
Event-Loop”und steuern die Kommunikation zwischen dem UI-Thread und anderen Threads.
”
Ein Display ist vor einem Window (Shell) zu erzeugen und am Ende nach Entfernen der Shell
zu schließen. Displays sind für Multi-Thread-Anwendungen wichtig.
Shell Ein Shell-Objekt ist ein Fenster (top level shell oder dialog shell) einer Applikation
und wird vom Window-Manager der Betriebssystem-Plattform organisiert. top level shells
werden als Kind-Objekte von Display erzeugt. These windows are the windows that users
move, resize, minimize, and maximize while using the application. Secondary shells are those
that are created as a child of another shell. These windows are typically used as dialog
windows or other transient windows that only exist in the context of another window.
Beispiel. ”
Hello, World.”-Programm mit SWT.
Um das Beispiel in Eclipse ausführen zu können, gibt es zwei Möglichkeiten:
1. Die Ausführung als Eclipse-Projekt, oder
2. die Ausführung als Java-Applikation. In diesem Fall muss zuvor das Paket org.eclipse.swt.widgets
verfügbar gemacht werden.
Beispiel.

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 153
Abbildung 9.2.2: Muster ”
Kompositum” zur Beschreibung von Komponenten einer grafischen
Benutzeroberfläche

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 154
Abbildung 9.2.3: Abbildung aus Wikipedia
Abbildung 9.2.4: Swing-Applikation mit MVC-Architektur

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 155
Abbildung 9.2.5: Erzeugung und Registrierung der Adapter
Abbildung 9.2.6: Beispiele im ”
Example Launcher”
Abbildung 9.2.7: ”
Hello, World.” mit SWT

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 156
Abbildung 9.2.8: Einstellung der Umgebungsvariablen ECLIPSE HOME

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 157
9.2.7 Einbettung von Swing-Komponenten in SWT
Die Eclipse-IDE basiert wie gesagt auf SWT. Soll nun eine bereits existierende Applikation (in
der Regel ein Entwicklungswerkzeug, z.B. das Testwerkzeug Jamus) mit einer AWT/Swingbasierten
GUI in der Eclipse-IDE zur Verfügung gestellt werden, ist dies auf zwei Wegen
möglich:
1. kann die Swing-basierte Applikation umgeschrieben werden oder
2. kann die Swing-Applikation in SWT eingebettet werden.
Beispiel: Integration von Jamus in die Eclipse-IDE
Hier wird nachfolgend die Einbettung von Swing-Komponenten am Beispiel von Jamus betrachtet.
Um etwas (Jamus) einbetten zu können, muss zunächst eine ”
Hülle” geschaffen
werden. Dazu wird ein neues Jamus-Projekt als PDE-Projekt (Plug-in Development Environment)
geschaffen. Alle Pakete unter de.htw.dresden.jamus werden neu geschaffen.
Für die Enbettung ist ein spezielles Package swingintegration.example 0.0.2.jar nutzbar,
das über die Eclipse-Homepage erreichbar ist
(http://www.eclipse.org/articles/Article-Swing-SWT-Integration/files/swingintegration.example 0.0.2.jar)
Das Package ist zunächst in die eigene Anwendung - das PDE-Projekt - zu übernehmen.
Dazu werden alle Klassen dieses Pakets in das Paket de.htw.dresden.jamus.embeddedSwing
übertragen, anschließend müssen die Quelltexte individuell angepasst werden.
Die Klasse EmbeddedSwingComposite ist die Basis für die Einbettung von AWT/Swing-
Komponenten in die SWT-basierte Oberfläche (vgl. Abb. 9.2.9).
Folgende Anpassungen sollen vorgenommen werden:
1. Jamus-Perspektive schaffen
2. Integration der Jamus-Menüs
3. Integration von Views/Editoren in die Eclipse-IDE
4. Frames bleiben Frames
Zu 1.: Jamus-Perspektive schaffen
Die Jamus-Perspektive soll eigene Views beinhalten. Die Perspektive wird der Workbench
über den Extension Point org.eclipse.ui.perspectives bekannt gegeben. Abb. 9.2.10 zeigt die in
der Datei plugin.xml verwaltete XML-Darstellung. Zur Erstellung der Datei in der Eclipse-
IDE kann ein Wizard verwendet werden.
Das Attribut id bestimmt einen eindeutigen Identifikator zur Referenzierung der Perspektive.
Der Wert des Attributs name ist ein Text-Label für die Perspektive. Falls fixed="true"
gesetzt ist, können zur Perspektive gehörige Views nicht geschlossen werden. Die im Attribut

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 158
Abbildung 9.2.9: Paketstruktur des Jamus-Plug-in-Projekts
class angegebene Klasse beschreibt das Layout der Perspektive. Die Klasse wird durch einen
parameterlosen Konstruktoraufruf instantiiert.
Die Klasse Perspective (vgl. Abb. 9.2.11) muss org.eclipse.ui.IPerspectiveFactory
implementieren. Die Methode CreateInitialLayout ist die im Interface definierte und in
Perspective überschriebene Methode, mit der der Perspektive verschiedene Ansichten (z.B.
Projekt Explorer, Editor) hinzugefügt und das Layout für die Perspektive konfiguriert werden
können. Per Default beinhaltet der Layout-Bereich Platz für Editoren, aber nicht für
Views. Die Factory-Methode kann weitere Views hinzufügen, die relativ zum Editor oder zu
anderen View platziert werden.
Abbildung 9.2.12 zeigt die Eclipse-IDE bei geöffneter Jamus-Perspektive.
Zu 2.: Integration der Jamus-Menüs

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 159
Abbildung 9.2.10: Extension Jamus-Perspektive
Abbildung 9.2.11: Klasse Perspective

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 160
Abbildung 9.2.12: Eclipse-IDE in der Jamus-Perspektive
Abbildung 9.2.13: Beispiel zur Einbettung

9.2. GRAFISCHE BENUTZEROBERFLÄCHEN 161
9.2.8 JFace
JFace ist ein ”
higher level” UI-Toolkit. Darin werden aus den von SWT zur Verfügung gestellten
Basiskomponenten komplexere Widgets zusammengesetzt. Es wird eine Abstraktionsschicht
für den Zugriff auf die Komponenten bereitgestellt.
JFace besitzt Abhängigkeiten zu einigen Eclipse-Bibliotheken (die ggf. als .jar-Dateien aus
Eclipse verfügbar gemacht werden müssen). Eclipse ist eine Applikation, die JFace einsetzt.

9.3. CLIENT-SERVER-SYSTEME MITTELS HTTP UND SERVLETS 162
9.3 Client-Server-Systeme mittels http und Servlets
Servlets sind spezielle Java-Klassen, die Code enthalten, der in einer Web-Anwendung serverseitig
unter Kontrolle eines Servers ausgeführt werden kann. Servlets können mit Web-
Clients mittels eines Request/Response–Paradigmas interagieren, basierend auf dem HTTP-
Protokoll. Java-Servlets sind für Server, was Java-Applets für Clients sind.
Java-Servlets können zur dynamischen Erzeugung von Web-Inhalten (alternativ zu CGI-
Skripten, PHP etc.) eingesetzt werden. Aktuell ist die Spezifikation Java Servlet 3.0.
Der Servlet-Lebenszyklus
Servlets werden durch eine spezielle Laufzeitumgebung - einen Servlet-Container bzw. Web-
Container - als Instanz der Servlet-Klasse erzeugt und zur Abarbeitung gebracht. Ein verbreitet
eingesetzter Web-Container ist Apache Tomcat. Die Ausführung unterliegt - ähnlich
wie die Ausführung von Applets - einem speziellen Lebenszyklus. Der Web-Container ist für
das Laden und Initialisieren zuständig. Servlets akzeptieren Requests von Clients und liefern
Daten an sie zurück. Schließlich können Web-Container Servlets entfernen.
Im einzelnen bedeutet das:
1. Die Laufzeitumgebung aktiviert die Methode init des Servlets. Ein Neuladen ist erst
nach Entfernen des Servlets möglich. Dazu muss der Server die Methode destroy
ausführen.
2. Nach dem Initialisieren ist ein Servlet in der Lage, von Clients gelieferte Daten zu verarbeiten
(request) und Daten an sie zurückzuliefern (response). Die Behandlung von
Client-Requests erfolgt mit der Methode service des Servlets. Jeder Client–Request
bewirkt, dass die service-Methode in einem eigenen Thread läuft. Für die Organisation
der gleichzeitigen Verarbeitung mehrerer service-Methoden ist der Nutzer zuständig.
Programmierung eines Servlets
Servlets implementieren das Interface javax.servlet.Servlet.
Es gibt 2 Möglichkeiten:
1. Entwickler können das Interface direkt implementieren.
2. Servlets, die das http-Protokoll benutzen, um mit Clienten zu interagieren, spezialisieren
zweckmäßigerweise die Klasse javax.servlet.http.HttpServlet und nutzen sie
auf diese Weise nach. Die Klasse HttpServlet implementiert ihrerseits das Interface
javax.servlet.Servlet.
Die Methode service leitet Requests an eine in der Servlet-Klasse definierte Methode
doXXX weiter, sie muss vom Anwender in der Klasse HttpServlet nicht überschrieben werden.
Für das Interagieren mit Clients ist es notwendig, die erwünschten Methoden doXXX
für die Behandlung von http-Interaktionen der Klasse HttpServlet zu überschreiben.

9.3. CLIENT-SERVER-SYSTEME MITTELS HTTP UND SERVLETS 163
Kandidaten dafür sind:
• doGet - Behandlung von GET-Requests, bedingten GET-Requests, HEAD-Requests
• doPost - Behandlung von POST-Requests
• doPut - Behandlung von PUT-Requests
• doDelete - Behandlung von DELETE-Requests
Alle Methoden, die überschrieben werden, erwarten zwei Parameter:
1. Instanz von HttpServletRequest für Daten vom Client
2. Instanz von HttpServletResponse für Antwort an den Client
Eine HttpServletRequest-Instanz ermöglicht den Zugriff auf die Http-Header-Daten. Ein
Http-Header enthält Informationen über den Körper, wie z.B. Kodierung oder Inhaltstyp,
die Http-Methode, mit der der Request ausgeführt wurde sowie weitere Angaben (Browser,
Sprache, Cookies). Für den Zugriff auf diese Daten (Requests) gibt es folgende Möglichkeiten:
• für alle HTTP-Methoden:
– getParameterValues liefert den Wert eines Parameters
– getParameterNames liefert die Namen der Parameter
• speziell für GET (HTTP):
– getQueryString liefert einen String, der ggf. zu parsen ist.
• für POST, PUT, DELETE:
– getReader liefert einen BufferedReader, der zum Lesen von Text-Daten verwendet
werden kann,
– getInputStream liefert einen ServletInputStream, der zum Lesen von binär-
Daten verwendet werdeen kann.
Für die Rückgabe von Antworten bietet ein HttpServletResponse-Objekt folgende Möglichkeiten:
• getWriter liefert einen Writer für die Ausgabe von Textdaten
• getOutputStream liefert einen Output Stream für die Ausgabe von Binaries
Vor der Ausgabe müssen die Header-Daten gesetzt werden. Dazu werden die Methoden
contentType, contentLength und encoding benutzt.
Nach der Übertragung signalisiert das Schließen des Writers oder des Output Streams
dem dem Server, dass die Übertragung beendet ist.

9.3. CLIENT-SERVER-SYSTEME MITTELS HTTP UND SERVLETS 164
Servlet-Metadaten
Metainformationen über das Servlet werden in einer XML-Datei web.xml gespeichert (sog.
Deployment Deskriptor). Die XML-Datei wird zusammen mit der compilierten Klasse gespeichert.
Die Nutzung des Servlet-Runners aus dem Java Servlet Development Kit erfordert das
Anlegen einer Property-Datei servlet.properties, sie enthält den Namen des Servlets und
die Initialisierungsparameter.
Kommunikation zwischen Client und Servlet
Vom Client aus kann die Kommunikation mit einem Servlet auf folgenden Wegen erfolgen:
• direkt über die URL des Browsers,
• mittels eines HTML-Formulars,
• mittels eines Applets, das in einem HTML-Dokument refereziert wird.
Beispiel. Das in der Server2Go-Applikation verwendete Servlet MyServlet:
...
...
...
Die Methode doMysql wird ebenfalls in der Klasse MyServlet definiert und realisiert eine
Datenbankabfrage. Der Methode wird der PrintWriter übergeben, über den in der Methode
Ausgaben erfolgen.

9.3. CLIENT-SERVER-SYSTEME MITTELS HTTP UND SERVLETS 165
Beispiel. Ein Applet Countis baut eine Verbindung zum Servlet auf, schreibt und liest. Es
gibt verschiedene Konstruktoren für URL-Objekte. Der Host-Name kann durch getCodeBase().getHost()
ermittelt werden.
public class Countis extends Applet {
public void init(){
URL url = new URL(...);
URLConnection connection = url.openConnection();
OutputStream out = connection.getOutputStream;
PrintStream pout = new Printstream(out);
InputStream in = connection.getInputStream();
}
}

9.4. DATENBANKANBINDUNGEN AN JAVA-APPLIKATIONEN 166
9.4 Datenbankanbindungen an Java-Applikationen
Ein Client-Programm, das auf eine Datenbank zugreifen soll, enthält folgende Funktionen:
1. Laden eines JDBC-Treibers
2. Öffnen einer Datenbank (Verbindung aufbauen)
3. Senden von SQL-Anweisungen an die Datenbank
4. Auslesen und Bearbeiten der Ergebnisse
Die Schritte 1. und 2. sind einmal in einer Anwendung auszuführen, die Schritte 3 und 4
werden wiederholt ausgeführt.
Beispiel:
1. JDBC-Treiber laden
Class.forName("com.mysql.jdbc.Driver");
Ein JDBC-Treiber ist eine gewöhnliche Java-Klasse, die aber erst zur Laufzeit mit
Class.forName(klassenname) bereitgestellt wird. Class.forName(klassenname) gibt zu
einem ihr als Parameter übergebenen Klassennamen ein Class-Objekt zurück und lädt zuvor
die Klasse in die JVM.
com.mysql.jdbc.Driver implementiert com.sql.Driver. Um den Treiber benutzen
zu können, muss das mit der Java-Distribution bereitgestellte Archiv
mysql-connector-java-[version]-bin.jar verfügbar gemacht werden. Die vollständige
Adresse muss in den CLASSPATH aufgenommen werden.
2. Datenbankverbindung aufbauen.
Der Treiber-Manager prüft mittels
Connection con = DriverManager.getConnection(...)
welcher der geladenen Treiber den als Parameter angegebenen JDBC-URL öffnen kann. Die
Datenbank wird mit der Methode getConnection geöffnet. Die Methode erwartet ein, zwei
oder drei Parameter. Drei Parameter haben folgende Bedeutung:
(a) die Datenbank, angegeben als url-String der Form jdbc : subprotocol : subname.
Beispiel: String url = "jdbc:mysql://localhost:7188/server2go";
(b) den Benutzernamen, angegeben als String,
Beispiel: "root"
(c) das zugehörige Passwort, angegeben als String.
Beispiel: ""
b) und c) zusammen erlauben den DB-Zugriff.
Die Methode getconnection(...) gibt ein Connection-Objekt zurück.

9.4. DATENBANKANBINDUNGEN AN JAVA-APPLIKATIONEN 167
3. SQL-Anweisung an die DB senden.
Über die zuvor geöffnete DB-Verbindung sendet der Client SQL-Anweisungen an das
DBMS:
(a) Erzeugen eines Statement-Objektes, um SQL-Statements an die Datenbank zu
senden:
Statement stmt = con.createStatement();
(b) Übermitteln des SFW-Blockes in der Methode executeQuery:
String query =
"SELECT *" +
"FROM items";
ResultSet rs = stmt.executeQuery(query);
(c) Automatische Übermittlung des Statements an das DBMS mittels JDBC-Treiber.
4. Auslesen und Bearbeiten der Ergebnisse
Die SFW-Anweisung liefert eine Tabelle als Instanz der Klasse ResultSet. Die Methoden
von ResultSet dienen dem Durchlaufen der Tabelle und dem Zugriff auf Ergebnisse:
Zeilenweise von links nach rechts (bzw. von vorn nach hinten) .
Die Tabelle wird zweckmäßigerweise als HTML-Datei ausgegeben. In dem Fall kümmert
sich der Web-Browser um die Formatierung.
Der Zugriff auf Metadaten ermöglicht z.B. die Ausgabe von Attribut- bzw. Spaltenzahl
und -bezeichnungen:
ResultSetMetaData rsmd = rs.getMetaData();
int colums = rsmd.getColumnCount();
System.out.println(""
for(int i=1;i

9.5. SERVER2GO 168
9.5 Server2Go
Server2Go (Homepage http://www.server2go-web.de) ist ein Web-Server, der ohne Installation
arbeitsfähig ist (Autor: Timo Haberkern). Auf Server2Go basierende Web-
Applikationen sind direkt vom Datenträger nutzbar, ohne Apache, PHP oder MySQL konfigurieren
zu müssen. Ein Tomcat bearbeitet Anfragen an Servlets oder JSP. Die Verarbeitung
von Java-Servlets ist im Funktionsumfang von Server2Go nicht enthalten, dazu muss der Server2Go
speziell eingerichtet werden.
Beispiel. Für die Lehrveranstaltung wurde eine Beispielkonfiguration zusammengestellt
(Dank an J. Roeper!). Eine entsprechend bereitgestellte zip-Datei ist zunächst an einen
gewünschten Ort zu entpacken. Es entsteht ein Verzeichnis server2go. Bei Ausführung der
darin enthaltenen Server2Go.exe wird die Anwendung gestartet. Es öffnet sich der MS
Internet Explorer mit der Adresse http://127.0.0.1:4001/. Bei Schließen des Internet
Explorers wird der Server2Go wieder heruntergefahren.
Wir nutzen nach dem Starten eine vorgefertigte Servlet-Einbindung: Klick auf ”
Servlet
mit Datenbankabfrage” unter den rechts platzierten Angeboten. Es öffnet sich im Explorer
http://127.0.0.1:4001/mywebapp/MyServlet und zeigt einen einfachen HTML-Text:
Auf Seiten des Clients steht ein Link im HTML-Text:

9.5. SERVER2GO 169
Server mit DB-Abfrage
Das Servlet MyServlet.class (ebenso MyServlet.java) befindet sich im Unterverzeichnis
htdocs/webapps/mywebapp/Web-INF/classes.
Beispiel. Die im Beispiel benötigte Datenbank items kann zuvor mittels phpmyadmin erstellt
werden.
Abbildung 9.5.1: Bearbeiten der verwendeten Datenbank mittels phpMyAdmin

9.5. SERVER2GO 170
Abbildung 9.5.2: Darstellung der Tabelle items in der server2go-Datenbank

9.5. SERVER2GO 171
Beispiel. Sächsische Historische Biographie (BioLex)
Es wird ein Client-Server-Applikation entwickelt, die sich Client-seitig auf ein Applet
stützt.

9.5. SERVER2GO 172

Literaturverzeichnis
[Bal05]
[BES08]
Balzert, Heide: Lehrbuch der Objektmodellierung - Analyse und Entwurf mit
der UML 2. 2. Auflage. Heidelberg : Spektrum Akademischer Verlag, 2005
Balzert, H. ; Ebert, Ch. ; Spindler, G.: Lehrbuch der Softwaretechnik: Softwaremanagement.
2. Auflage. Spektrum Akademischer Verlag, 2008
[Dum03] Dumke, Reiner: Software Engineering. 4. Auflage. Vieweg Verlag, 2003
[Ecl]
www.eclipse.org/juno
[GHJV09] Gamma, E. ; Helm, R. ; Johnson, R. ; Vlissides, J.: Entwurfsmuster - Elemente
wiederverwendbarer objektorientierter Software. Addison-Wesley, 2009
[HGE]
[Lar05]
[Mey90]
[MSS96]
[Obj]
[O’S]
[Pop08]
MercurialEclipse. http:javaforge.com/project/HGE
Larman, Craig: UML 2 und Patterns angewendet - Objektorientierte Softwareentwicklung.
1. Auflage. Bonn : mitp-Verlag, 2005
Meyer, B.: Objektorientierte Softwareentwicklung. New York etc. : Coedition
Carl Hanser Verlag u. Prentice-Hall, 1990
Mittendorf, S. ; Singer, R. ; Strobel, R.: Java Programmierhandbuch und
Referenz. Dpunkt.verlag, 1996
http://www.microtool.de/objectif/de/index.asp?gclid=
CN6ynL6r0rkCFQdb3godwUMAUA
O’Sullivan, B.: Mercurial: The Definite Guide. http://hgbook.red-bean.com.
– Homepage des gleichnamigen Buches
Popp, Gunther: Konfigurationsmanagement - mit Subversion, Ant und Maven:
Grundlagen für Softwarearchitekten und Entwickler. 2., aktualisierte Auflage.
dpunkt.verlag, 2008
[Pre97] Pree, W.: Komponentenbasierte Softwareentwicklung mit Frameworks.
dpunkt.verlag, 1997
[Rac] DrRacket. http://racket-lang.org, Abruf: 2013-09-17
173

LITERATURVERZEICHNIS 174
[Som07] Sommerville, I.: Software Engineering. 8.,aktualisierte Auflage. Addison-
Wesley, 2007
[SWI] SWI-Prolog. http://www.swi-prolog.org, Abruf: 2013-12-06
[Tor] TortoiseSVN. http://tortoisesvn.tigris.org/, Abruf: 2013-12-06

Index
A
Abstraktion, 29
Actor, 129
Adapter-Muster, 143
Aggregation, 35
Aggregationsbaum, 36
Aktion, 46
Ant, 17, 105
Ant-Skript, 106
Apache Tomcat, 162
Assembler, 7
Assoziation, 32
Attribut, 29
Ausführungsumgebung, 93
AWT, 146
B
Beobachter-Muster, 139
Blackbox-Framework, 128
Build-Management, 17
Build-Prozess, 7
Build-Ziele, 106
C
Case-Tools, 8
Changeset, 99
Check-in, 97
Classifier, 80
Compiler, 7
Concurrent Versions System, 97
CVS, 97
D
Debugger, 7
Delegate, 149
Doclet, 122
doGet, 163
doMysql, 164
doPost, 163
E
Eclipse, 8
Einschubmethode, 127
Einzelwerkzeug, 7
EmbeddedSwingComposite, 157
Entwurfsmuster, 139
Ereignis, 46
Erweiterbarkeit, 21
evolutionäre Entwicklung, 19
F
Fabrikmethode-Muster, 139
Fassade-Muster, 142
Feature, 9
Filesets, 109
Framework, 127
G
Gerät, 93
H
Handler, 69
Head, 99
Hot-Spot, 127
Http-Header, 163
HttpServlet, 162
I
ID, 99
Initialzustand, 46
Inklusionsrelation, 36
Instanziierung, 29
175

INDEX 176
Instanzobjekt, 30
Interface, 63
J
Jamus, 157
Jar-Archiv, 111
Jar-Funktion, 110
Javac-Funktion, 110
Javadoc, 122
Javadoc-Kommentar, 122
Javadoc-Tag, 122
JDBC-Treiber, 166
JFace, 8, 151, 161
JFC, 146
JRE, 9
JTree, 150
K
Klassendiagramm, 30
Klassenheterarchie, 37
Klassenhierarchie, 37
Klassenname, 30
Klonen, 99
KM-Prozess, 96
Knoten, 93
Kommunikationspfade, 94
Komposition, 36
Konfigurationselemente, 96
Korrektheit, 21
L
Layout-Manager, 147
Listener, 69
M
make, 105
Maven, 17, 105
MERCURIAL, 16
Mercurial, 99
Merge, 100
Methode, 28, 29
Motif, 146
Multiplizität, 34
MVC-Architektur, 145
O
ObjectIF, 8
Objektdiagramm, 30
Objekttechnologie, 5
P
package, 80
Paket, 80
Paketdiagramm, 80
PDE, 9
Peer, 146
Perspective, 158
Perspektiven, 8
Plug-ins, 8
private, 31
Produkt, 110
Programmierumgebung, 7
Programmverbinder, 7
protected, 31
Proxy-Muster, 141
Prozessmodell, 19
public, 31
Pull, 100
Q
QSM, 21
R
Relation, 36
Repository, 97
Revision, 97
Robustheit, 21
Rolle, 34
S
SADT, 6
Schablonenmethode-Muster, 143
Sequenzendiagramm, 44
Server2Go, 168
Servlet, 162
Servlet-Lebenszyklus, 162
Servlet-Runner, 164

INDEX 177
SFW-Anweisung, 167
Sichtbarkeit, 31
Sichtbarkeitsbereich, 44
Simulationsframework, 129
Singleton-Muster, 141
Smalltalk, 145
Softwareentwicklungsprozess, 18
Softwareentwicklungsumgebung, 7
Strategie-Muster, 140
Structured Analysis, 6
subclipse, 16, 98
Subklasse, 37
Subversion, 97
Superklasse, 37
svn, 16
Swing, 148
SWT, 8, 151, 157
Whitebox-Framework, 127
Wiederverwendbarkeit, 21
X
XMI, 16
Z
Zustand, 29, 46
T
Target, 106
Task, 110
Testdatengeneratoren, 7
Thread, 77, 146
Tip, 99
tools, 4
Topcased, 8
Transition, 46
Typkompatibilität, 44
U
Übersetzungseinheit, 56
UML, 6, 30
Unified Modeling Language, 5
URL-Objekt, 165
V
Verifikation, 22
Verknüpfung, 32
Version, 97
View, 8
Vorgehensmodell, 19
W
Wasserfallmodell, 19