Objektorientierte Softwareentwicklung. Unified Modeling Language (UML) und Rational Unified Process (RUP)

Inhaltsverzeichnis

1 Einleitung

2 Methoden zur Softwareentwicklung
2.1 Begriffsbestimmungen
2.2 Objektorientierte Softwareentwicklung
2.3 Ausgewählte Methoden zur objektorientierten Softwareentwicklung
2.4 Ausgewählte Vorgehensmodelle zur Softwareentwicklung

3 UML und RUP zur OO Softwareentwicklung
3.1 UML als Modellierungssprache für objektorientierte SW- Entwicklung
3.1.1 Entstehungsgeschichte
3.1.2 UML Struktur und Sprachelemente
3.1.3 UML Diagramme
3.1.4 „Sichten eines Systems“ − Konzept und UML
3.2 RUP als Vorgehensmodell zur objektorientierten SW-Entwicklung mit UML
3.2.1 Entstehungsgeschichte
3.2.2 Das RUP - Prozessrahmenwerk
3.2.3 RUP Artefakte und UML
3.2.4 RUP-Projekt Implementierung

4 Beispielanwendung „Bibliothekssystem“
4.1.1 Beschreibung der Beispielanwendung
4.1.2 Implementierung des RUP für das Beispielprojekckage
4.1.3 Ausgewählte RUP Artefakte

5 Zusammenfassung

6 Literaturverzeichnis

7 Anhänge
7.1 Abkürzungsverzeichnis
7.2 UML 2.0 Notationsübersicht
7.3 Vergleich ausgewählter OO-Methoden
7.4 UML 2.0 Metamodell
7.5 UML 2.0 Classifier-Konzept

Tabellenverzeichnis

Tabelle 1: Abstraktion der Modellierung, Diagrammarten und OO Konzepte, nach [Fran00, S.715]

Tabelle 2: Zwölf Regeln des Extreme Programming [Rune04, S.2]

Tabelle 3: Übersicht zu verschiedenen Vorgehensmodellen [Opit03, S.58]

Tabelle 4: UML Strukturdiagramme [Jeck04, S.21ff]

Tabelle 5: UML Verhaltensdiagramme [Jeck04, S.65ff]

Tabelle 6: RUP Prozess Disziplinen

Tabelle 7: RUP Prozess Phasen

Tabelle 8: RUP Modelle, nach [Admi08]

Tabelle 9: UML Diagramme und RUP Modelle, nach [Admi08]

Tabelle 10: RUP Project Timeline (Beispiel), [Hirs02, S.5]

Tabelle 11: RUP Project Artifacts (Beispiel), [Hirs02, S.6]

Tabelle 12: „Bibliothekssystem“-Projekt Artefakte des RUP

Tabelle 13: Anwendungsfall „Buch aufnehmen“ [Schm04, S.47]

Tabelle 14: Vergleich ausgewählter OO-Methoden, nach [Dabi00, S.5ff]

Abbildungsverzeichnis

Bild 1: Aufbau der Arbeit

Bild 2: Software-Technik als Fachgebiet der Praktischen Informatik [Balz00, S.39]

Bild 3: Komponenten einer Methode [Balz00, S.37]

Bild 4: Ursprünge und grundlegende Konzepte der objektorientierten Softwareentwicklung [nach Balz96, S.20f.]

Bild 5: Beispieldiagramme der OO Modellierung (UML Notation)

Bild 6: Historische Entwicklung objektorientierter Methoden und insbesondere der UML [Oest04, S.20]

Bild 7: Wasserfall-Modell / Softwarelebenszyklus [Somm07, S.97]

Bild 8: V-Modell der Softwareentwicklung [Opit03, S.26]

Bild 9: Inkrementell-Iteratives Modell der SW-Entwicklung [Somm07, S.102]

Bild 10: Spiral-Modell der SW-Prozesses [Somm07, S.104]

Bild 11: EP Vorgehensmodell [XP08]

Bild 12: Übersicht der UML-Diagramme, nach [Oest04, S.211 und Jeck04, S.19]

Bild 13: Verhaltensdiagramme und Verhalten einer Operation eines Classifiers [Jeck04, S.67]

Bild 14: Beispiel Notation des Klassendiagramms [Jeck04, S.26]

Bild 15: USDP Softwareentwicklungsprozess, nach [Hirs02, S.2]

Bild 16: RUP Modelle und ihre Abhängigkeiten, [Admi08, S.2]

Bild 17: Geschäftsprozessanalyse für den Betrieb einer Bibliothek

Bild 18: Strukturierung des Bibliothekssystems

Bild 19: Funktionale Anforderungen an das SW-System

Bild 20: Anwendungsfall „Bibliothekssystem“

Bild 21: Anwendungsfall „Bestandsverwaltung“, nach [Schm04, S.35]

Bild 22: Anwendungsfall „Leihbetrieb“, nach [Schm04, S.34]

Bild 23: Aktivitätsdiagramm „Benutzer anmelden“, nach [Schm04, S.57]

Bild 24: Bildschirmansicht eines GUI Prototyps

Bild 25: Klassendiagramm Leihobjekt, nach [Schm04, S.90]

Bild 26: Klassendiagramm Entleihung, nach [Schm04, S.95]

Bild 27: Zustandsdiagramm Exemplar, nach [Schm04, S.101]

Bild 28: Sequenzdiagramm Buch ausleihen, nach [Schm04, S.111]

Bild 29: UML 2.0 Metamodell [Jeck04, S. 117]

Bild 30: UML 2.0 Classifier-Konzept [Jeck04, S. 16]

1 Einleitung

Die Größe und Komplexität von Softwaresystemen verdoppelt sich etwa alle fünf Jahre. Heutige Softwaresysteme können leicht aus mehreren millionen Zeilen Quelltext bestehen. Sie werden mehrheitlich nicht mehr für einen einzelnen Computer geschrieben sondern bestehen aus verteilten Anwendungen, die als Teil komplexer Softwarearchitekturen ihre Aufgabe erfüllen müssen [West06, S.6]. Die Entwicklung fehlerfreier Software stellt eine große Herausforderung für die Entwickler dar, die ohne methodisches Vorgehen und Techniken aus dem Software Engineering nur schwer möglich ist [Somm07, S.30f].

Seit Beginn der 90iger Jahre haben objektorientierte Techniken stark an Bedeutung gewonnen. Aus den zahlreichen Methoden, 1993 wurden ca. 40 verschiedene objektorientierte Methoden gezählt [Balz96, S. 19], hat sich eine geringe Anzahl an heute gebräuchlichen Modellierungsund Vorgehensweisen durchgesetzt. Mit der Unified Modeling Language (UML) hat sich ein Quasistandard zur objektorientierten Modellierung herausgebildet, unter den Vorgehensmodellen und -methoden findet der Rational Unified Process (RUP) eine große Verbreitung [Oest04, S.19ff].

Innerhalb dieser Arbeit soll die objektorientierte Softwareentwicklung mittels UML und RUP als Beispiel für ein methodisches Vorgehen im Sinne des Software Engineering detailiert dargestellt werden. Hierbei liegt der Schwerpunkt der Darstellungen auf den technischen Aspekten der Softwareherstellung (technische Prozesse der Softwareentwicklung) und auf den ersten beiden Prozessaktivitäten (Softwarespezifikation und Softwareentwicklung) des Softwareprozesses [Somm07, S. 33f].

Die Arbeit gliedert sich in drei Abschnitte (vgl. Bild 1). Im ersten Abschnitt werden die grundlegenden Begriffe und ausgewählte Techniken und Vorgehensweisen aus dem Software Engineering vorgestellt und diskutiert. Der zweite Abschnitt vertieft UML als Modellierungsmethode und RUP als Vorgehensmodell zur objektorientierten Softwareentwicklung. Grundlegenden Prin-

zipien, Arbeitsschritte und Phasen von RUP und die Notation und Semantik der Modellierungsmethode UML werden beschrieben. Eine kurze Beispielanwendung der vorgestellten Methodik und Vorgehensweise im dritten Abschnitt der Arbeit zeigt die praktische Umsetzung für ein Softwaresystem zur Bibliotheksverwaltung.

Abbildung in dieser Leseprobe nicht enthalten

Bild 1: Aufbau der Arbeit

2 Methoden zur Softwareentwicklung

Der folgende Abschnitt diskutiert die grundlegenden Begriffe und ausgewählte Techniken und Vorgehensweisen aus dem Software Engineering, die für das Verständnis dieser Arbeit notwendig sind.

2.1 Begriffsbestimmungen

Das zentrale Thema dieser Arbeit sind Methoden und Vorgehensmodelle für die objektorientierte Softwareentwicklung. Diese sind Gegenstand des Software Engineering (zu Deutsch: Software-Technik), einem Fachgebiet der Informatik (siehe Bild 2), das bei [Balz00, S. 36] wie folgt definiert wird:

Software-Technik : Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkszeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen. Zielorientiert bedeutet die Berücksichtigung z.B. von Kosten, Zeit, Qualität.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2: Software-Technik als Fachgebiet der Praktischen Informatik [Balz00, S.39]

Das Software Engineering beschäftigt sich demnach mit allen Aspekten der Softwareherstellung, sowohl der eigentlichen Entwicklung wie auch der Wartung nach Inbetriebnahme. Die Entstehung eines Softwareproduktes kann durch einen Softwareprozess, eine Menge von Tätigkeiten und damit zu-

sammenhängenden Ergebnissen beschrieben werden. Der Softwareprozess weist vier grundlegende Prozessaktivitäten auf [Somm07, S.33f]:

1. Softwarespezifikation: Definition der zu produzierenden Software und ihrer Einsatzrandbedingungen.
2. Softwareentwicklung: Entwurf und Programmierung der Software.
3. Softwarevalidierung: Überprüfung der Software auf Erfüllung der Spezifikation.
4. Softwareevolution: Weiterentwicklung und Anpassung der Software an veränderte Anforderungen.

Eine vereinfachte Beschreibung des Softwareprozesses wird Vorgehensmodell genannt. Vorgehensmodelle stellen spezielle Sichten dieses Prozesses dar [Somm07, S.35] und liefert so nur einen Teil der Informationen über ihn. Nahezu alle Vorgehensmodelle lassen sich auf drei allgemeine Modelle (Prozessparadigmen) zurückführen. Sie sind im aktuellen Software Engineering weit verbreitet und werden in verschiedenen konkreten Implementierungen von Vorgehensmodellen wie etwa dem Rational Unified Process (RUP) kombiniert [Somm07, S. 35 und S.95]:

1. Wasserfall-Modell: Stellt die grundlegenden Prozessabläufe wie Spezifikation, Entwicklung, Validierung und Weiteentwicklung als eigenständige Phasen des Prozesses dar. Nach Realisierung jeder Phase wird diese vollständig abgeschlossen und die Entwicklung geht zur nächsten Phase über.
2. Evolutionäre Entwicklung: Spezifikation, Entwicklung und Validierung werden verknüpft und mit Hilfe der abstrakten Spezifikation wird schnell ein erstes System entwickelt. Auf Basis der Rückmeldungen der Anwender wird das System verbessert, bis es den Anforderungen entspricht.
3. Komponentenbasiertes Software Engineering: Basis bilden existierenden, wiederverwendbaren Komponenten, aus dem das neue System entstehen soll. Der Systementwicklungsprozess fokussiert auf die Integration dieser Komponenten, weniger auf die Entwicklung neuer Komponenten.

Der strukturierte Ansatz für die Softwareentwicklung wird im Software Engineering als Methode bezeichnet. Methoden zielen auf die Entwicklung von (graphisch darstellbaren) Modellen eines Systems und ihre Verwendung für die Systemspezifikation oder den Entwurf [Somm07, S.38]. Wie in Bild 3 abgebildet, wird im Software Engineering der Methodenbegriff auch als Oberbegriff von Konzepten, Notationen und Vorgehensweisen verstanden [Balz00, S.37].

Abbildung in dieser Leseprobe nicht enthalten

Bild 3: Komponenten einer Methode [Balz00, S.37]

Hierbei erlauben Konzepte die Modellierung definierter Sachverhalte unter einem oder mehreren Gesichtspunkten. Sie können durch Notationen dargestellt werden, indem diese Informationen symbolisch abbilden. Das Methodisches Vorgehen schließlich beschreibt die Schritte und Regeln zur Zielerreichung [Balz00, S.37f].

2.2 Objektorientierte Softwareentwicklung

Die objektorientierte Softwareentwicklung basiert auf den grundlegenden Konzepten Objekt, Klasse, Botschaft, Vererbung und Polymorphismus. Sie werden durch die Assoziation, die Aggregation, den Zustandsautomaten und um Subsysteme ergänzt (siehe Bild 4). Vorteilhaft ist dabei, dass die meisten Konzepte durchgängig über alle Phasen des objektorientierten Softwareprozesses hinweg verwendet werden können [Balz96, S. 21f.].

Abbildung in dieser Leseprobe nicht enthalten

Bild 4: Ursprünge und grundlegende Konzepte der objektorientierten Softwareentwicklung [nach Balz96, S.20f.]

Die objektorientierten Methoden der Softwareentwicklung nutzen diese Konzepte im Rahmen der Analyse der Anwendungsdomänen zur Abstraktion, d.h. zur Erstellung von konzeptionellen Modellen als Kommunikationsmittel zwischen Anwender und Softwareentwickler [Fran00, S. 709].

Tabelle 1: Abstraktion der Modellierung, Diagrammarten und OO Konzepte, nach [Fran00, S.715]

Abbildung in dieser Leseprobe nicht enthalten

Im Mittelpunkt der objektorientierten Modellierung stehen graphische Darstellungen bzw. Diagramme zur verständlichen Beschreibung bestimmter Aspekte der Anwendungsdomäne (siehe Tabelle 1 und Bild 5) [Fran00, S.715].

Abbildung in dieser Leseprobe nicht enthalten

Bild 5: Beispieldiagramme der OO Modellierung (UML Notation)

2.3 Ausgewählte Methoden zur objektorientierten Softwareentwicklung

Die Entwicklung der Methoden der Softwareentwicklung ist durch die stetige Zunahme der Abstraktionen gekennzeichnet. Hatte die strukturierte Analyse noch das Ziel, die grundlegenden funktionalen Komponenten eines Systems zu erkennen, wurde diese später durch objektorientierten Methoden ersetzt, um die wesentlich höheren Abstraktionsmöglichkeiten der Objektorientierung zu unterstützen [Somm07, S.37; Oest04, S.16]. Historisch gehen die heute gebräuchlichen objektorientierte Methoden und Vorgehensweisen auf verschiedene Arbeiten insbesondere von Booch, Rumbaugh und Jacobson, den drei sogenannten „Amigos“ zurück, die später ihre Methoden zu der heutigen Standard Notation UML vereinigten. Bild 6 zeigt eine Übersicht dieser Entwicklung.

Abbildung in dieser Leseprobe nicht enthalten

Bild 6: Historische Entwicklung objektorientierter Methoden und insbesondere der UML [Oest04, S.20]

Die heute gebräuchlichste objektorientierte Modellierungssprache UML entstand aus der Boch Methode, OMT und OOSE und weist daneben Einflüsse auch anderer Methoden, etwa von Harel (Statechart-Notation) und Coad/Yourdon (OOA) auf [Dabi00, S.5ff.]:

Die Booch Methode geht auf die Arbeit von Grady Booch [Booc94] zurück und enthält sowohl eine Notation als auch einen Prozess (ein Vorgehensmodell) zur objektorientierten Analyse und zum Entwurf von Software. Die Booch Methode definiert vier Entwicklungsphasen (Requirements, Domain Analysis, Design und Implementierung) und stellt acht Diagramme zur Modellierung der Anwendungssichten zur Verfügung (Klassendiagramm, Objektdiagramm, Hilfsroutinenschablone, Zustandsübergangsdiagramm, Klasseanschblone, Objektschablone, Funktionsschablone und Zeitdiagramm).

Die Booch Methode unterstützt inkrementelle und interaktive Entwicklungszyklen.

Die OMT (Object-Modeling-Technique) wurde von James Rumbaugh et.al. [Rumb93] entwickelt. Ihre dreistufige Vorgehensweise (Analyse, System Design, Objekt Design) hat ihre Wurzeln in der strukturierten Methode und wird durch eine umfangreiche Notation unterstützt. OMT unterteilt streng in Analyse und Entwurf. Zur Analyse werden Diagramme zur Beschreibung der statische Sicht (Object Modell), der dynamischen Sicht (Dynamic Object) und eine funktionale Sicht (Functional Modell) bereit gestellt. Die Entwurfsphase beinhaltet die Ableitung der Systemarchitektur und die Identifikation von Teilsystemen und Parallelitäten. Der Objektentwurf fügt dann die im Analysemodell erstellten drei Sichten für die Implementierung zusammen.

Die OOSE (Object-Oriented Software Engineering) Methode geht auf Arbeiten von Ivar Jacobson et.al. [Jaco92] zurück und wurde später von der Firma Ericson entwickelt. Die Methode stellt den Anwendungsfall (use case) in den Mittelpunkt des Entwicklungsprozesses, die Beschreibung der Benutzerinteraktion mit dem Softwaresystem (Szenarien der Systemnutzung).

Die OOA (object oriented analysis) Methode, auch Coad/Yourdon Methode genannt, geht auf Arbeiten von Coad und Yourdon zurück [Coad94]. Schwerpunkt der Methode ist die bessere Unterstützung der Analyse in der objektorientierten Softwareentwicklung, für die Coad und Yourdon eine übersichtliche Notation und einen fünfstufigen Prozess (Objektidentifikation, Strukturidentifikation, Subjektbildung, Definition der Attribute, Methodenspezifikation) einführten. Stärke der Methodik ist insbesondere die detailierte Spezifikation der Attribute und Methoden. Für die Spezifikation der Systemdynamik werden nur Zustandsdiagramme angeboten.

Anhang 7.4 enthält eine tabellarische Übersicht der vorgestellten objektorientierten Methoden und ihre Stärken und Schwächen.

Die Verschmelzung der oben beschriebenen objektorientierten Methoden zur UML Methode erfolgte unter Nutzung und Vereinigung der besten Ansätze. Wesentliche UML-Elemente lassen sich auf sie zurückführen [Dabi00, S.4]:

– Anwendungsfälle (use case Diagramm) gehen maßgeblich auf OOSE zurück
– Klassendiagramme wurden aus OMT, Booch Methode u.a. Methoden entlehnt
– Zustandsdiagramme und Aktivitätsdiagramme gehen auf Statecharts von Harel [Hare87] und ihre Nutzung u.a. auf die OOA Methode zurück
– Kollaborationsdiagramme und Implementierungsdiagramme wurden u.a. aus der Booch Methode abgeleitet

2.4 Ausgewählte Vorgehensmodelle zur Softwareentwicklung

Die vorgestellten objektorientierten Methoden beinhalten mehr oder weniger stark ausgeprägte Vorgehensmodelle. Bei der Entwicklung von UML aus diesen Methoden wurde das Vorgehensmodell zunächst jedoch ausgeklammert, um zu gewährleisten, dass UML eine möglichst breite Anwendbarkeit aufweist. So hat das International Council on Systems Engineering (INCOSE) 2001 das Ziel formuliert, UML zu einer Standardsprache für das Systems Engineering zu machen [Weil06, S.21].

Jedoch wurde schnell die Bedeutung eines Prozesses für die Implementierung von UML u.a. in Softwarewerkzeuge erkannt. Für die Anwendung von UML im Software Engineering wurde daher durch die drei „Amigos“ ein Rahmenwerk für Prozesse definieren. Dieses Rahmenwerk lehnte sich an den von Jacobson entwickelte „Objectory“ Prozess an, aus dem später der Rational Unified Process (RUP) entstand [Dabi00, S.13].

Zu den klassischen Vorgehensmodellen zur Softwareentwicklung gehören: Das Wasserfall-Modell für die Softwareentwicklung kann durch eine Kaskade von Phasen beschrieben werden, die den Softwarelebenszyklus abbilden (vgl. Bild 7).

Das Wasserfall-Modell ist durch ein Top-Down-Vorgehen gekennzeichnet, die Software wird sequentiell in den vorgegebenen Phasen entwickelt. Alle Ergebnisse der jeweiligen Entwicklungsphase werden dokumentiert und Iterationen finden nur zwischen benachbarten Phasen statt. Dem Wasserfall- Modell liegt die Annahme zu Grunde, dass alle Anwenderanforderungen in der ersten Projektphase vollständig und richtig erfasst und definiert werden können [Opit03, S.13ff.].

Abbildung in dieser Leseprobe nicht enthalten

Bild 7: Wasserfall-Modell / Softwarelebenszyklus [Somm07, S.97]

Das V-Modell für die Softwareentwicklung erweitert das Wasserfall-Modell um Aspekte der Qualitätssicherung. Das V-Modell beinhaltet neben dem Modul zur Erstellung des Softwaresystems Module zur Qualitätssicherung, zum Konfigurationsmanagement und zum Projektmanagement. Damit unterstützt das V-Modell das gesamte Projekt über die reine Softwareentwicklung hinaus.

Abbildung in dieser Leseprobe nicht enthalten

Bild 8: V-Modell der Softwareentwicklung [Opit03, S.26]

[...]