Der Weg von der objektorientierten Analyse zum Design
Einsatz und Evaluierung von UML im Web Engineering
©2001
Diplomarbeit
129 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Unabhängig von der Art des zu entwickelnden Anwendungssystems stellen auch heute noch die ersten Phasen der Software-Entwicklung, die Analyse und das Design, wesentliche Schwachpunkte im gesamten Software-Entwicklungszyklus dar. Einerseits treten große Schwierigkeiten bei der Erhebung und Identifikation der problemrelevanten Informationen und Objekte, deren Komponenten und Verhalten, auf, andererseits gibt es Probleme, bereits existierende Komponenten wiederzuverwenden. Des weiteren gibt es nach wie vor Probleme im Bereich der Visualisierung und im Design von relevanten Informationen, da die so zahlreich am Markt verfügbaren Analyse- und Design-Werkzeuge nicht ausreichend Funktionalität bieten, um angesprochene Problembereiche vollständig abzubilden. Viele Werkzeuge stellen im wesentlichen Grundfunktionen zur Umsetzung der theoretischen Konzepte objektorientierter Analyse- und Design-Methoden zur Verfügung, unterscheiden sich aber häufig nur wenig von klassischen Zeichenprogrammen.
Um den komplexen Bereich der objektorientierten Analyse und Design effizient bewältigen zu können, benötigt man eine den Bedürfnissen von Software-Entwicklern angepasste Methodik. Diese Methodik sollte neben einem entsprechenden Grundmodell eine klar definierte Vorgehensweise und entsprechende Techniken zur Verfügung stellen.
Ein Gegenstand dieser Arbeit ist somit eine etwas genauere Untersuchung der Problembereiche objektorientierte Analyse und Design. Es soll geklärt werden, was man darunter versteht, wie man dabei vorgeht und in welchen Phasen des Software-Entwicklungsprozesses die beiden Bereiche integriert sind. Zudem soll geklärt werden, ob für die Durchführung von Analyse- und Designaufgaben eine Werkzeugunterstützung gegeben ist.
Ziel dieser Arbeit ist, basierend auf den Erkenntnissen von OOA und OOD, eine neuartige Analyse- und Designmethode (UML) vorzustellen und diese weitgehend auf die Anforderungen an derartige Methoden zu überprüfen. Dieser neue Ansatz soll eine Weiterentwicklung sowohl bewährter und erprobter als auch in der Praxis noch nicht verbreiteter Methoden zur objektorientierten Analyse und Design darstellen.
Aufgrund der Forderung nach praktischer Anwendbarkeit und Testbarkeit sollte der Ansatz nicht nur theoretisch fundiert sein, sondern zur Bewertung auch durch ein entsprechendes Software-Werkzeug unterstützt werden. Aus dieser Forderung ergibt sich der letzte Schwerpunkt der Arbeit:
Definition eines […]
Unabhängig von der Art des zu entwickelnden Anwendungssystems stellen auch heute noch die ersten Phasen der Software-Entwicklung, die Analyse und das Design, wesentliche Schwachpunkte im gesamten Software-Entwicklungszyklus dar. Einerseits treten große Schwierigkeiten bei der Erhebung und Identifikation der problemrelevanten Informationen und Objekte, deren Komponenten und Verhalten, auf, andererseits gibt es Probleme, bereits existierende Komponenten wiederzuverwenden. Des weiteren gibt es nach wie vor Probleme im Bereich der Visualisierung und im Design von relevanten Informationen, da die so zahlreich am Markt verfügbaren Analyse- und Design-Werkzeuge nicht ausreichend Funktionalität bieten, um angesprochene Problembereiche vollständig abzubilden. Viele Werkzeuge stellen im wesentlichen Grundfunktionen zur Umsetzung der theoretischen Konzepte objektorientierter Analyse- und Design-Methoden zur Verfügung, unterscheiden sich aber häufig nur wenig von klassischen Zeichenprogrammen.
Um den komplexen Bereich der objektorientierten Analyse und Design effizient bewältigen zu können, benötigt man eine den Bedürfnissen von Software-Entwicklern angepasste Methodik. Diese Methodik sollte neben einem entsprechenden Grundmodell eine klar definierte Vorgehensweise und entsprechende Techniken zur Verfügung stellen.
Ein Gegenstand dieser Arbeit ist somit eine etwas genauere Untersuchung der Problembereiche objektorientierte Analyse und Design. Es soll geklärt werden, was man darunter versteht, wie man dabei vorgeht und in welchen Phasen des Software-Entwicklungsprozesses die beiden Bereiche integriert sind. Zudem soll geklärt werden, ob für die Durchführung von Analyse- und Designaufgaben eine Werkzeugunterstützung gegeben ist.
Ziel dieser Arbeit ist, basierend auf den Erkenntnissen von OOA und OOD, eine neuartige Analyse- und Designmethode (UML) vorzustellen und diese weitgehend auf die Anforderungen an derartige Methoden zu überprüfen. Dieser neue Ansatz soll eine Weiterentwicklung sowohl bewährter und erprobter als auch in der Praxis noch nicht verbreiteter Methoden zur objektorientierten Analyse und Design darstellen.
Aufgrund der Forderung nach praktischer Anwendbarkeit und Testbarkeit sollte der Ansatz nicht nur theoretisch fundiert sein, sondern zur Bewertung auch durch ein entsprechendes Software-Werkzeug unterstützt werden. Aus dieser Forderung ergibt sich der letzte Schwerpunkt der Arbeit:
Definition eines […]
Leseprobe
Inhaltsverzeichnis
ID 5194
Stadlbauer, Franz: Der Weg von der objektorientierten Analyse zum Design: Einsatz und
Evaluierung von UML im Web Engineering. / Franz Stadlbauer - Hamburg: Diplomica GmbH,
2002
Zugl.: Linz, Universität, Diplom, 2001
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
1 Einleitung
1
1.1 Motivation
1
1.2
Gegenstand, Ziel und Abgrenzung der Arbeit
2
1.3 Übersicht
4
2
Objektorientierte Analyse und Design
5
2.1
Objektorientierte Analyse (OOA)
5
2.1.1
Begriffsdefinitionen
5
2.1.2
Warum sollte OOA eingesetzt werden?
7
2.1.3 Die
Analysephase
7
2.1.4
Die Objektorientierung
9
2.1.5
Konzepte der Objektorientierung 10
2.1.6
Objektorientierte Analyse
12
2.2
OOA im Software-Entwicklungsprozeß
14
2.2.1
Vorgehensmodelle und Life-Cycle
14
2.2.2
Evolutionäre Softwareentwicklung
15
2.2.3
Der Object Engineering Process (OEP)
17
2.3
Vorgehensweise bei OOA
18
2.4
Objektorientiertes Design (OOD)
20
2.4.1
Begriffsdefinitionen
21
2.4.2
Objektorientiertes Design
23
2.4.3
Aufgaben und Ergebnisse von OOD
24
2.4.4
Die Systemarchitektur
24
2.5
OOD im Software-Entwicklungsprozeß
26
2.5.1
OOD und Prototyping
27
2.5.2
Der Übergang zur Implementierung
29
2.6
Vorgehensweise bei OOD
30
2.6.1
Grob- und Feindesign
31
2.6.2
Design Patterns
32
2.7
Werkzeugunterstützung für OOA und OOD
34
3
UML Unified Modeling Language
37
3.1
Begriffsdefinitionen
37
3.2
Zweck und Gegenstand der UML
39
3.2.1
Entstehung der UML
40
3.2.2
Ziele der UML
41
3.2.3
UML im Softwareentwicklungsprozeß
42
3.3
Grundlegende Konzepte der UML
43
3.3.1
Aufbau der UML
43
3.3.2
Das Metamodell
44
3.3.3
Die Object Constraint Language (OCL)
46
3.4
Diagramme
47
3.4.1
Anwendungsfalldiagramm
48
3.4.2
Klassendiagramm
50
3.4.3
Sequenzdiagramm
53
3.4.4
Kollaborationsdiagramm
54
3.4.5
Zustandsdiagramm
56
3.4.6
Aktivitätsdiagramm
58
3.4.7
Komponentendiagramm
60
3.4.8
Verteilungsdiagramm
61
4
UML im Web Engineering
63
4.1
Begriffsdefinitionen
63
4.2
Web Engineering und UML
64
4.2.1
Web Life-Cycle Modell
65
4.2.2
Unterschiede zum traditionellen Software Engineering
67
4.2.3
UML-Erweiterungen für Web Applikationen
68
4.3
UML-Werkzeuge
74
4.3.1
objectiF 4.5
75
4.3.2
Rational Rose 2001 Enterprise
77
4.4
Use Case Szenario Online Shop
80
4.4.1
Problembeschreibung
81
4.4.2
Analyse
82
4.4.3
Design
87
4.5
Anforderungen an UML-Werkzeuge
92
4.5.1
Unterstützung der UML-Diagramme
92
4.5.2
Methodenbasierte Kriterien
93
4.5.3
Funktionale Kriterien
94
4.5.4
Web Engineering Kriterien
97
4.6
Gegenüberstellung und Vergleich der UML-Werkzeuge
98
4.6.1
Ziel der Evaluation
98
4.6.2
Darstellung der Ergebnisse
99
4.6.3
Auswertung der Ergebnisse
114
4.6.4
Kritik und Ausblick
117
5 Literaturverzeichnis
119
1 Einleitung
1
1 Einleitung
Unabhängig von der Art des zu entwickelnden Anwendungssystems stellen auch heute noch die
ersten Phasen der Software-Entwicklung, die Analyse und das Design, wesentliche
Schwachpunkte im gesamten Software-Entwicklungszyklus dar. Einerseits treten große
Schwierigkeiten bei der Erhebung und Identifikation der problemrelevanten Informationen und
Objekte, deren Komponenten und Verhalten, auf, andererseits gibt es Probleme, bereits
existierende Komponenten wiederzuverwenden. Weiters gibt es nach wie vor Probleme im
Bereich der Visualisierung und im Design von relevanten Informationen, da die so zahlreich am
Markt verfügbaren Analyse- und Design-Werkzeuge nicht ausreichend Funktionalität bieten, um
angesprochene Problembereiche vollständig abzubilden. Viele Werkzeuge stellen im
wesentlichen Grundfunktionen zur Umsetzung der theoretischen Konzepte objektorientierter
Analyse- und Design-Methoden zur Verfügung, unterscheiden sich aber häufig nur wenig von
klassischen Zeichenprogrammen.
1.1 Motivation
,,Das Ziel der Systemanalyse ist die Erstellung einer möglichst eindeutigen, widerspruchsfreien,
vollständigen, überprüfbaren, änderbaren und nachvollziehbaren Anforderungsdefinition."
[STEIN97, S.13]
Im Laufe der letzten Jahre sind zahlreiche Analysemethoden zur Erstellung einer derartigen
Anforderungsdefinition, oder auch Software Requirements Specification, entwickelt worden, die
sich zum Teil in ihren Ansätzen wesentlich voneinander unterscheiden. Gerade die
Notwendigkeit, große und immer unüberschaubarere Software-Systeme in einer schnellebigen
Zeit wie heute zu entwickeln, treibt die Entwicklung von neuen Ansätzen im Bereich der
Analyse und Design voran. Schwierigkeiten traditioneller Software-Entwicklung, die weitgehend
auf dem klassischen Software-Life-Cycle beruhen, stammen daher, daß notwendige
Rückkopplungen zu früheren Phasen des Entwicklungsprozesses nicht vorgesehen sind und die
Wiederverwendung bereits existierender und getesteter Software-Bestandteile nicht unterstützt
wird.
In der Zwischenzeit haben sich Schlagwörter wie ,,Objektorientierung" oder ,,objektorientierte
Software-Entwicklung" etabliert und sich deren Vorteile herauskristallisiert. Trotz der vielen
1 Einleitung
Start
Motivation
Gegenstand
Übersicht
1 Einleitung
2
Vorteile einer objektorientierten Denk- und Vorgehensweise werden heute immer noch zwei
wesentliche Problembereiche dieses Ansatzes vernachlässigt: die objektorientierte Analyse und
das objektorientierte Design. Einerseits gibt es bis heute nur wenig anerkannte und auch
eingesetzte adäquate Methodiken für objektorientierte Analyse und Design, andererseits bringt
die Trennung zwischen Analyse und Design im Sinne der Objektorientierung neue Probleme mit
sich. Die Trennlinie zwischen Analyse und Design ist unklar definiert und der Weg von der
Analyse zum Design, d.h. der Übergang von der Anforderungsdefinition zur Modellierung,
bringt für Systemanalytiker und Designer nach wie vor Probleme mit sich. Es muß daher auch
geklärt werden, wie objektorientierte Analyse und Design in den gesamten Software-
Entwicklungsprozeß integriert sind und wann es zu Wechselwirkungen zwischen diesen beiden
Prozessen bzw. Phasen kommt.
Aufgrund der Durchsetzung des objektorientierten Paradigmas wurden in den letzten Jahren
zahlreiche objektorientierte Analyse- und Designmethoden entwickelt. Es erscheint nicht mehr
notwendig, die viel zitierten Methoden zu vergleichen, sondern eine neuartige objektorientierte
Analyse- und Designmethode die Unified Modeling Language (UML) - herauszugreifen, diese
eingehend zu beschreiben und zu überprüfen, ob sie den Anforderungen einer derartigen
Methodik standhält. Weiters erscheint es sinnvoll, bereits erhältliche Werkzeuge für UML
genauer unter die Lupe zu nehmen, damit ersichtlich wird, ob derartige Werkzeuge auch die
theoretischen Konzepte der Methodik vollständig unterstützen und somit einen wesentlichen
Beitrag zur Lösung des Analyse- und Designproblems leisten.
1.2 Gegenstand, Ziel und Abgrenzung der Arbeit
Um den komplexen Bereich der objektorientierten Analyse und Design effizient bewältigen zu
können, benötigt man eine den Bedürfnissen von Software-Entwicklern angepaßte Methodik.
Diese Methodik sollte neben einem entsprechenden Grundmodell eine klar definierte
Vorgehensweise und entsprechende Techniken zur Verfügung stellen.
Ein Gegenstand dieser Arbeit ist somit eine etwas genauere Untersuchung der Problembereiche
objektorientierte Analyse und Design. Es soll geklärt werden, was man darunter versteht, wie
man dabei vorgeht und in welchen Phasen des Software-Entwicklungsprozesses die beiden
Bereiche integriert sind. Zudem soll geklärt werden, ob für die Durchführung von Analyse- und
Designaufgaben eine Werkzeugunterstützung gegeben ist.
Ziel dieser Arbeit ist, basierend auf den Erkenntnissen von OOA und OOD, eine neuartige
Analyse- und Designmethode (UML) vorzustellen und diese weitgehend auf die Anforderungen
1 Einleitung
3
an derartige Methoden zu überprüfen. Dieser neue Ansatz soll eine Weiterentwicklung sowohl
bewährter und erprobter als auch in der Praxis noch nicht verbreiteter Methoden zur
objektorientierten Analyse und Design darstellen.
Dieser neue Ansatz sollte idealerweise folgende Zieleigenschaften haben:
· Unterstützung sämtlicher objektorientierter Eigenschaften und Techniken
· Berücksichtigung von statischen und dynamischen Eigenschaften des zu entwerfenden
Systems
· Überführung von Analyse-Ergebnissen in nachfolgende Phasen
Wie die Abbildung zeigt, soll eine Übernahme und Weiterverarbeitung der Ergebnisse einer
Phase in die nächste möglich sein. Wenn eine 1:1 Übernahme der Ergebnisse in eine neue
Phase möglich ist, werden nicht nur auftretende Probleme beim Phasenübergang reduziert,
sondern auch die Qualität der Ergebnisse gesteigert. Ziel ist es somit, durch eine
einwandfreie Überführung der Ergebnisse, besonders die aus der Analyse beeinflußbaren
Transformationsprobleme an der Schnittstelle zum Design zu vermindern.
· Praktische Anwendbarkeit und Relevanz
Aufgrund der Forderung nach praktischer Anwendbarkeit und Testbarkeit sollte der Ansatz nicht
nur theoretisch fundiert sein, sondern zur Bewertung auch durch ein entsprechendes Software-
Werkzeug unterstützt werden. Aus dieser Forderung ergibt sich der letzte Schwerpunkt der
Arbeit:
· Definition eines Anforderungskatalogs an UML-Werkzeuge
· Gegenüberstellung von zwei vorhandenen Werkzeugen und Evaluierung anhand des
Anforderungskatalogs
Die Abgrenzung der Arbeit im Sinne der Festlegung des zu untersuchenden Bereichs ist somit in
der Vorstellung einer Methode zur OOA und OOD und deren werkzeugmäßigen Unterstützung
gegeben.
Abb. 1: Phasenergebnisse und übergänge bei objektorientierter Vorgehensweise [Schad94, S.31]
1 Einleitung
4
1.3 Übersicht
Die vorliegende Arbeit ist im weiteren wie folgt gegliedert:
Kapitel 2: beschäftigt sich mit zwei wesentlichen Problembereichen der objektorientierten
Software-Entwicklung Analyse und Design wo geklärt werden soll, was man darunter
versteht, welche Vorgehensweise bei OOA und OOD nötig ist und wann welche
Vorgehensweise stattfindet. Dabei wird auch eine Abgrenzung der oft synonym verwendeten
Begriffe der objektorientierten Analyse und des objektorientierten Designs vorgenommen und
überprüft, ob zur Durchführung der Tätigkeiten von OOA und OOD eine
Werkzeugunterstützung gegeben ist.
Kapitel 3: stellt eine neuartige objektorientierte Analyse- und Designmethode - UML - vor.
Zunächst soll Zweck und Gegenstand der Unified Modeling Language erläutert und anschließend
eine Einführung in die Konzepte gegeben werden. In weiteren Unterkapiteln werden die
einzelnen Elemente bzw. Diagramme und deren Notation vorgestellt.
Kapitel 4: versucht, auf Basis eines Anforderungskatalogs an UML-Werkzeuge deren Eignung
für den Einsatz im Web Engineering zur Entwicklung von Web-Applikationen zu ermitteln.
Dazu sollen zuerst die Unterschiede zwischen dem traditionellen Software Engineering und Web
Engineering aufgezeigt werden, bevor anhand eines Use Case aus dem E-Business Bereich zwei
am Markt erhältliche UML-Werkzeuge gegenübergestellt und anhand des Anfoderungskatalogs
evaluiert werden. Eine Untersuchung soll zeigen, ob die Werkzeuge die theoretischen Konzepte
der UML unterstützen und mit den zur Verfügung stehenden Diagrammen das Use Case
Szenario modelliert werden kann.
2 Objektorientierte Analyse und Design
5
2 Objektorientierte Analyse und Design
2.1 Objektorientierte Analyse (OOA)
Im folgenden Kapitel soll nun auf den Begriff Objektorientierte Analyse, die Vorgehensweise
beim Analyseprozeß und Bedeutung im Software-Entwicklungsprozeß eingegangen werden.
Objektorientierte Analyse ist die systematische Vorgehensweise zur Erschließung und Erfassung
von Eigenschaften einer Aufgabe und deren Problembereich nach objektorientierten
Gesichtspunkten. Primäre Aufgabe von OOA ist die vollständige und widerspruchsfreie
Beschreibung der Anforderungen an das zu entwickelnde Software-System unter Anwendung
einer OOA-Methode. OOA wird in frühen Phasen des Entwicklungsprozesses von Software
eingesetzt. Sie integriert neben einer klar strukturierten Vorgehensweise (siehe Kap. 2.3) in der
Regel eine spezielle, textuelle oder graphische Notation zur Dokumentation des Software-
Systems. Zur Erstellung der Anforderungsdefinition wird der Entwickler durch geeignete
Software-Werkzeuge, sogenannte CASE-Tools (siehe Kap. 2.7), unterstützt, welche in der Regel
die Notation einer OOA-Methode integrieren.
2.1.1 Begriffsdefinitionen
Objektorientierte Analyse
Der Begriff "Objektorientierte Analyse" wird in der verwendeten Literatur mehrdeutig definiert.
Coad sieht in der Analysephase die Identifikation des Problembereiches und deren
Komponenten:
,,Object-Oriented Analysis is the challenge of understanding the problem domain, and then the
system's responsibilities in that light". [Coad91, S.9]
Die Definition von Coad wird im Rahmen dieser Arbeit betrachtet und ihrem Kontext
entsprechend verwendet. Booch sieht in der OOA bereits eine Vorgehensweise zur Identifikation
von Klassen und deren Objekte:
,,Objektorientierte Analyse ist eine Analysemethode, die die Anforderungen aus der Perspektive
der Klassen und Objekte, die sich im Vokabular des Problembereichs finden, betrachtet."
[Booch94, S.318]
2 OOA und OOD
OOA
OOD
Werkzeugunterstützung für
OOA und OOD
2 Objektorientierte Analyse und Design
6
Die Klassenidentifikation ist aus der Sicht von Coad erst Aufgabe von OOD. Wie sich hier zeigt,
ist auch die Abgrenzung zwischen OOA und OOD in der Literatur nicht eindeutig definiert.
Objektorientierte Analyse ist die Beschreibung des Problembereichs durch Anwendung von
objektorientierten Konzepten. Im Mittelpunkt der Beschreibung steht immer die Frage: ,,Was ist
zu tun?"
Software-Life-Cycle
Der Begriff ,,Software-Life-Cycle" findet in der verwendeten Literatur eine eindeutige
Definition. Pomberger spricht von der gesamten Lebensdauer eines Softwareprodukts:
,,Ein Software-Life-Cycle ist die Zeitspanne, in der ein Softwareprodukt entwickelt und
eingesetzt wird, bis zum Ende seiner Benutzung." [Pombe96, S.18]
Becker bezieht den Life-Cycle ebenfalls auf die Herstellung, Wartung und Benutzung des
Produkts:
,,Ein Software-Life-Cycle ist die Beschreibung von methodischen Entwicklungsprozessen eines
Softwareprodukts bis hin zur Wartung und Benutzung." [Becke95]
Die Definition von Pomberger liegt dieser Arbeit zugrunde. Life-Cycle Modelle sind
Beschreibungen von Entwicklungsphasen und deren Zusammenhänge. Der Life-Cycle bezieht
sich auf die Entwicklung, Benutzung und Wartung eines Softwareprodukts.
Evolutionäre Softwareentwicklung
Der Begriff ,,Evolutionäre Softwareentwicklung" wird in der verwendeten Literatur relativ
eindeutig definiert. Oestereich sieht darin eine inkrementelle Systementwicklung:
,,Evolutionäre Softwareentwicklung ist eine inkrementelle Systementwicklung, bei der
Prototypen schrittweise zum Produkt ausgebaut werden." [Oeste95, S.24]
Gleichermaßen wird dieser Begriff von Pomberger definiert, der eine evolutionäre
Softwareentwicklung ebenfalls in Verbindung mit Prototyping sieht:
,,Evolutionäres Prototyping ist der schrittweise Ausbau eines Prototypen zum fertigen Produkt."
[Pombe96, S.5]
Evolutionäre Softwareentwicklung wird im Rahmen dieser Arbeit als die Erstellung eines
Softwaresystems durch den schrittweisen (inkrementellen) Ausbau eines Prototypen zum
fertigen Produkt bezeichnet.
2 Objektorientierte Analyse und Design
7
2.1.2 Warum sollte OOA eingesetzt werden?
Der Einsatz von OOA in frühen Entwicklungsphasen durch den Software-Entwickler bringt
sowohl Vorteile im Bereich der Problemanalyse als auch im gesamten Entwicklungsprozeß. Die
Anwendung von OOA bringt folgende Vorteile mit sich [vgl. Coad91, S.3ff]:
· Bewältigung verschiedener Problembereiche
OOA unterstützt den Entwickler im Problemverständnis und setzt einen klaren Fokus auf die
Definition und Untersuchung relevanter Eigenschaften des Problembereichs. Somit wird
auch die Fähigkeit des Entwicklers, verschiedenartige Probleme zu verstehen und zu lösen,
gefördert.
· Erhöhung der internen Konsistenz der Analyseergebnisse
OOA reduziert die Abhängigkeiten der verschiedenen Analyseaktivitäten durch Anwendung
geeigneter Werkzeuge für jede Aktivität. Durch konsequente Anwendung von Methoden und
Werkzeugen in den jeweiligen Aktivitäten werden konsistente Ergebnisse erzeugt.
· Aufbau von allgemeinen und beständigen Spezifikationen
Durch den Einsatz von OOA werden allgemein anwendbare Spezifikationen erzeugt.
Ergebnisse, die in einem spezifischen Problembereich produziert wurden, können in
ähnlichen Bereichen wiederverwendet werden und zeichnen sich durch Stabilität bei sich
wechselnden Anforderungen aus.
· Wiederverwendbarkeit der Analyseergebnisse
Ergebnisse erhalten durch OOA eine Struktur, so daß diese auf ähnliche oder zukünftige
Probleme angewendet und in diesen wiederverwendet werden können.
· Konsistente Repräsentationsformen
OOA stellt konsistente Darstellungen für den Problembereich zur Verfügung (was soll
erstellt werden?) und gibt Anleitungen für eine systematische Überführung der Ergebnisse in
ein spezifisches Design (wie soll es erstellt werden?).
2.1.3 Die Analysephase
Eine Zerlegung des Begriffs ,,Objektorientierte Analyse" ergibt zwei wesentliche Elemente:
· Analyse
· Objektorientierung
Es erscheint durchaus sinnvoll, diese zwei Begriffe zuerst getrennt voneinander zu betrachten
und anschließend wieder als eine Einheit in den gesamten Entwicklungsprozeß einzubetten.
2 Objektorientierte Analyse und Design
8
Abb. 2: Tätigkeiten in der Analyse [Oeste95, S.137]
Die Analyse ist die Gesamtheit aller
Tätigkeiten, welche durchgeführt
werden, um ein vollständig
dokumentiertes logisches Modell des
relevanten Problembereichs zu
erstellen. Die Dokumentation des
Modells kann unter Verwendung von
objektorientierten Konzepten (siehe
Kap. 2.1.5) erfolgen, soweit diese
programmiersprachenunabhängig sind. Durchzuführende Tätigkeiten in der Analysephase sind
unter anderem das Identifizieren der im Problembereich relevanten Objekte und deren
Beziehungen zueinander, das Zusammenfassen dieser Objekte zu Klassen und die entsprechende
Strukturierung der neu generierten Klassen. Besonders wichtig ist die Festlegung der
Eigenschaften und des Verhaltens der Objekte, wodurch sich automatisch die Festlegung der
Kommunikationsbeziehungen zwischen diesen ergibt. [vgl. Schäf94]
,,Das Ziel der Problemanalyse besteht in der Festlegung, welche Aufgaben unter welchen
Umgebungsbedingungen computerunterstützt gelöst werden sollen." [Pombe96, S.18]
Die Definition von Pomberger geht auf das oberste Ziel der Problemanalyse ein: Auftraggeber
und Entwickler müssen sich darüber klar werden, was eigentlich gemacht werden soll.
Anschließend soll gemeinsam versucht werden, das System im Problembereich zu beschreiben.
Die Beschreibung kann unter folgenden drei Aspekten erfolgen: [vgl. Oeste95]
· Abbildung von Objekten, Klassen und deren Abhängigkeiten bzw. Strukturen
· Erfassung von Kontrollflüssen oder globalem Systemverhalten
· Beschreibung von lokalem funktionalen Verhalten oder Klassenmethoden
Neben dieser Variante zur vollständigen Beschreibung und Modellierung des zu
implementierenden Systems sollte in der Analysephase, besonders im Hinblick auf komplexere
Systeme, die Möglichkeit bestehen, Analysetätigkeiten durch CASE-Tools zu unterstützen.
Dahingehend müssen vor allem die Notation und die gegenseitigen Abhängigkeiten der
einzelnen Analysedokumente klar und widerspruchsfrei definiert sein, ansonsten könnte es zu
Inkonsistenzen in den Analyseergebnissen kommen. Nur durch konsequentes Anwenden von
adäquaten Methoden und Techniken können Informationsverluste und Inkonsistenzen vermieden
werden.
2 Objektorientierte Analyse und Design
9
2.1.4 Die Objektorientierung
Der Begriff Objektorientierung ist in der letzten Zeit eines der meistbenutzten Schlagwörter in
der Softwaretechnik. Der Begriff der Objektorientierung beschreibt vor allem eine Metapher zur
Strukturierung komplexer Systeme mit dem Hauptzweck bzw. nutzen der Erhöhung des
verfügbaren Abstraktionsgrades während des gesamten Software-Entwicklungsprozesses. Die
Objektorientierung und ihre Denkweise haben mittlerweile eine überaus starke und wachsende
Bedeutung für die Software-Entwicklung gewonnen. Dies zeigt sich vor allem dadurch, daß neue
Programmiersprachen, Design-Methoden, Datenbanken, Benutzerschnittstellen und
Betriebssysteme basierend auf objektorientierten Konzepten entstanden.
Was kennzeichnet nun eine objektorientierte Denkweise?
Der objektorientierte Ansatz versucht, die Umwelt und ihre Realitäten in einer wesentlich
direkteren Form in Softwarekonstrukte wie Objekte umzusetzen. Diese Denkweise soll daher die
Modellierung von Systemen ermöglichen. Eine derartige Denkweise sollte jedoch nicht nur im
Anfangsstadium des Entwicklungszyklus verwendet werden, sondern das Denken in Objekten
und deren Beziehungen zueinander vollzieht sich in allen Phasen des Software-
Entwicklungsprozesses. Beispielsweise dienen dem Software-Entwickler Objekte sowohl als
Metapher zur Beschreibung des Problems als auch der Lösung, d.h. von der Analyse bis zur
Implementierung und Installierung des Systems.
Im Unterschied zu konventionellen Vorgehens- oder Denkweisen bringt der objektorientierte
Ansatz folgende wesentlichen Vorteile für ein Unternehmen und im besonderen für den
Anwendungsentwickler [vgl. Vette98, S.24]:
· erhöhte Produktivität
· leichte Änderbarkeit von Anwendungen
· leichte Erweiterbarkeit von Anwendungen
· hoher Grad an Wiederverwendbarkeit
· Unterstützung bei der Realisierung moderner Konzepte wie Client/Server Anwendungen
und Benutzerschnittstellen (GUI's)
· spiralförmiges, stetigen Änderungswünschen Rechnung tragendes
Anwendungsentwicklungsvorgehen
Die Unternehmung profitiert vor allem von erhöhter Produktivität, leichter Änderbarkeit und der
Erweiterbarkeit von Anwendungen, da das Informationsangebot ständig in immer kürzer
werdenden Zeitabständen an völlig neue Bedürfnisse anzupassen ist. Der
2 Objektorientierte Analyse und Design
10
Anwendungsentwickler profitiert vor allem vom hohen Grad an Wiederverwendbarkeit und
standardisierten Benutzerschnittstellen, wodurch sich ein erhebliches Einsparungspotential bei
der Entwicklung von neuen Software-Produkten ergibt. [vgl. Vette98]
2.1.5 Konzepte der Objektorientierung
Zusätzlich zur wesentlichen Charakteristik einer objektorientierten Methode erscheint es
notwendig, die nachfolgenden Konzepte, die sich bereits in zahlreichen veröffentlichten Arbeiten
wiederfinden und auch Bestandteil des Objektmodells der Object Management Group [OMG
(1995)] sind, zu erläutern. Die objektorientierte Software-Entwicklung baut auf folgenden
wesentlichen Konzepten auf:
· Klasse
"A class is a pattern, template, or blueprint for a
category of structurally identical items." [Berar98]
Die Klasse ist eine Schablone für eine bestimmte Art
von Objekten, welche die Struktur, Schnittstelle und
das Verhalten eines Objekts definiert. Die Klasse ist
ähnlich einem abstrakten Datentyp, wodurch
Implementierungsdetails verborgen bleiben und über
öffentliche Schnittstellen mit den Ausprägungen der Klasse Nachrichten ausgetauscht
werden können.
· Objekt
"Objects are the physical and conceptual things we
find in the universe around us." [Berar98]
Das Objekt ist ein Exemplar einer ganz bestimmten
Klasse, deren Kerneigenschaft im Zusammenfassen
von Attributen und auf diesen anwendbaren
Operationen (Methoden) liegt. Dadurch ist das
Objekt stets eine in sich geschlossene Einheit und
tritt immer als Ganzes auf.
· Ausprägung
Die Ausprägung einer Klasse wird immer zur Laufzeit erzeugt und repräsentiert die
physische Realisierung eines Objekts. Ein Objekt entsteht somit als Ausprägung einer Klasse
und ist in ihrem Wesen dynamisch.
Abb. 3: Notation einer Klasse [Berar98]
Abb. 4: Notation eines Objekts [Berar98]
2 Objektorientierte Analyse und Design
11
· Information Hiding
,,Information Hiding ist eine Fähigkeit, den Implementierungsteil zu verbergen, wodurch der
eigentliche Programmcode vor unerlaubten Zugriffen geschützt wird." [Yourd92, S.94]
"Information hiding is the principle stipulating that users of a software component need to
know only the essential details of how to utilize and access the component." [Berar98]
· Datenkapselung und Datenabstraktion
Datenkapselung beschreibt die
Zusammenfassung von Daten und
Methoden eines Objekts derart, daß auf
die Daten eines Objekts ausschließlich
über seine Methoden zugegriffen werden
kann. [vgl. Schad94]
"The purpose of data abstraction is to
separate behaviour from implementation,
where behaviour is what a data type
provides that other programs can rely
on." [Berar98]
Datenabstraktion beschreibt einerseits beide vorher genannten Mechanismen, betrachtet diese
jedoch aus einem anderen Blickwinkel. Abstraktion bedeutet, sich auf das Wesentliche zu
konzentrieren, d.h. so abstrakt wie möglich und so konkret wie nötig zu sein.
Datenkapselung und Datenabstraktion ergänzen sich gegenseitig: Abstraktion betrachtet nur
die äußere Sicht auf das Objekt, Kapselung dagegen verbirgt die innere Sicht auf das Objekt.
· Vererbung und Klassenhierarchie
Vererbung ist die Weitergabe
von Eigenschaften einer Klasse
an eine in der Hierarchie
untergeordnete Klasse (auch
Subklasse genannt). Die
Subklasse erbt dabei die
Datenstruktur (Attribute) und das
Verhalten (Methoden) der
übergeordneten Klasse (auch Oberklasse
genannt). Weiters wird in diesem
Kontext zwischen einfacher und
Abb. 5: Datenkapsel als Zusammenfassung von
Daten und Methoden [Vette98, S.41]
Abb. 6: Vererbung als Weitergabe von Eigenschaften [Pombe96, S.195]
Abb. 7: Mehrfache Vererbung [Oeste95, S.45]
2 Objektorientierte Analyse und Design
12
mehrfacher Vererbung unterschieden. Bei einfacher Vererbung erbt die Subklasse nur von
einer Oberklasse, bei mehrfacher Vererbung von mehreren Oberklassen. [vgl. Pombe96]
Wenn das Konzept der Vererbung konsequent und wiederholt auf Objekte der Realität
angewendet wird, entsteht eine umfassende Klassenhierarchie. Bei einfacher Vererbung kann
die entstandene Hierarchie durch eine Baumstruktur und bei mehrfacher Vererbung durch
einen azyklischen, gerichteten Graphen beschrieben werden.
· Polymorphismus und dynamische Bindung
Polymorphismus bedeutet Vielgestaltigkeit eines Objekts, d.h. zur Laufzeit gibt es
Referenzen auf unterschiedliche Objekte, deren
Klassen jedoch in einer Vererbungsbeziehung
stehen müssen. Dadurch wird es möglich, die
gleiche Nachricht an verschiedene Objekte
derselben Basisklasse zu schicken, wodurch
objektspezifische interne Abläufe aktiviert
werden. [vgl. Schäf94]
"Dynamic binding allows new objects and code
to be interfaced with or added to a system
without affecting existing code and eliminates
switch statements." [Berar98]
Dynamische Bindung ist sozusagen die technische Voraussetzung für Polymorphismus.
Dynamisch Binden ist die Zuordnung von Anweisungen zu einem Methodenaufruf während
der Laufzeit einer Applikation.
2.1.6 Objektorientierte Analyse
Objektorientierte Analyse ergibt sich aus der Durchführung der Tätigkeiten einer Analyse eines
Systems unter Zuhilfenahme von
objektorientierten Konzepten. Die
Untersuchung bzw. die Beschreibung des
Problembereichs wird mit objektorientierten
Konzepten durchgeführt, wobei immer die
Frage ,,Was ist zu tun?" im Mittelpunkt der
Untersuchung steht. Ziel ist es also, eine
möglichst vollständige und konsistente
Abb. 8: Polymorphismus [Oeste95, S.65]
Abb. 9: Objektorientierte Analyse [Schad94, S.139]
2 Objektorientierte Analyse und Design
13
Beschreibung des Problembereichs zu erhalten.
Die Erreichung des Ziels wird durch Identifizierung der Klassen und Objekte und Beschreibung
dieser anhand von objektorientierten Notationen sichergestellt. Die Interaktionen und das
Verhalten zwischen den identifizierten Objekten werden so modelliert, daß das objektorientierte
Analysemodell den Anforderungen genügt. Ergebnis der OOA ist daher ein vollständiges Abbild
des Problembereichs, das Abhängigkeiten zwischen den einzelnen Objekten zeigt und somit als
Basis für die nächste Tätigkeit im objektorientierten Lebenszyklus zur Verfügung steht.
Eine etwas detailliertere Beschreibung, was OOA ist bzw. wozu sie dient und wie sie in eine
ganzheitliche Anwendungsentwicklung eingebettet ist, liefert der methodische Rahmen der
objektorientierten Analyse [vgl. Vette98, S.269ff].
Eine Zielformulierung sollte idealerweise folgende Punkte beinhalten:
· Was soll mit dem Projekt erreicht werden?
· Identifikation von kritischen Erfolgsfaktoren
· Wer ist wofür verantwortlich?
Wie die angeführte Grafik zeigt, bewegt sich die Definition des Problems von einem
identifizierten IST-Zustand zu einem definierten SOLL-Zustand. OOA sieht vor, daß während
dieses gesamten Prozesses ein entsprechendes evolutionäres Prototyping stattfindet. Anhand von
evolutionärem Prototyping also mit Beteiligung des Auftraggebers und der zukünftigen
Benutzer des Systems - wird an die endgültige Lösung herangetastet, wobei eine permanente
Bewertung des Systems erfolgt. Um evolutionäres Prototyping durchführen zu können, werden
Abb. 10: Der methodische Rahmen von OOA [Vette98, S.276]
2 Objektorientierte Analyse und Design
14
sogenannte CASE-Tools eingesetzt, mit denen für den Benutzer vorab einsetzbare Prototypen
des Systems generiert werden können, ohne dabei schon vorhandene Daten zu benutzen.
2.2 OOA im Software-Entwicklungsprozeß
Das nun folgende Kapitel betrachtet den objektorientierten Analyseprozeß als Ganzes und
versucht anhand verschiedener Softwareentwicklungsmodelle aufzuzeigen, welchen Stellenwert
OOA im gesamten Software-Entwicklungsprozeß besitzt und welche Phasen eine weitere
wichtige Rolle nach Erhebung der Anforderungen eines Systems darstellen. Wie bereits erwähnt,
ist es zielführend, den objektorientierten Ansatz auf alle Phasen der Software-Produktion zu
beziehen. Demnach werden in diesem Kapitel Softwareentwicklungsmodelle dargestellt, die in
ihrer Gesamtheit dem objektorientierten Ansatz folgen.
2.2.1 Vorgehensmodelle und Life-Cycle
Softwareentwicklung ist eine Ingenieurdisziplin, wobei bei der Entwicklung generell von
Softwarelebenszyklen gesprochen wird, d.h. ein Softwareprodukt durchläuft bei seiner
Entwicklung mehrere Entwicklungsstationen. Sogenannte Life-Cycle Modelle sind abstrakte
Beschreibungen der strukturierten, methodischen Entwicklungen und Änderungsprozesse,
welche typischerweise die Hauptstadien in der
Herstellung und Wartung von lauffähiger Software
abbilden. Obwohl das Ziel des Entwicklungsprozesses die
Herstellung von einsetzbarer Software ist, betrachten die
Modelle einen umfassenderen Bereich, welcher auch die
Anforderungen, Entwurfsspezifikationen, Verifikation
und Aktivitäten u.a. in Betracht zieht. Bei der Definition
von "Life-Cycle" werden auch die Benutzung und
Wartung der Software miteinbezogen. [vgl. Becke95]
Erste Modelle von Software-Lebenszyklen wurden bereits
in den 70er Jahren entwickelt. Seit damals sind diese
Modelle einem ständigen Wandel und weiteren
Anpassungen unterworfen.
Das klassische Phasenmodell - oder auch
Wasserfallmodell genannt - ist das älteste und
einfachste Vorgehensmodell für die
Abb. 11: Das Phasenmodell [Becke95]
2 Objektorientierte Analyse und Design
15
Softwareentwicklung. Hauptmerkmal ist sein streng sequentieller Charakter. OOA ist wie bereits
mehrmals erwähnt eine der ersten Phasen der Softwareentwicklung, so auch im Phasenmodell.
Es muß einen allgemeinen Projektplan geben und die Anforderungen müssen ermittelt und
validiert werden. Beim praktischen Einsatz für heutige Software-Systeme erweist sich dieses
Vorgehensmodell als sehr restriktiv. Wiederverwendung wird ebenso wie Prototyping nicht
gefördert und es wird davon ausgegangen, daß die Analysephase nur einmal durchgeführt
werden kann [vgl. Yourd92]. Im klassischen Phasenmodell besitzen alle Phasen einen
definierten Anfang sowie ein definiertes Ende, wobei sie sich zeitlich nicht überlappen, d.h. die
Einzelphasen haben eine strikt sequentielle Abfolge.
Grady Booch [Booch94] äußerte sich mit Bezug auf den Namen Wasserfallmodell, daß
Handlungen einer Phase gleichzeitig mit Handlungen einer anderen Phase durchgeführt werden
können, d.h. es finden Überlappungen der einzelnen Phasen statt. Das Phasenmodell hat
mittlerweile viele Änderungen erfahren müssen, nicht nur aufgrund der rasanten
Weiterentwicklung heutiger Technologien.
Aufgrund von Veränderungen in der Programmierung von Softwaresystemen von der
strukturierten zur objektorientierten Programmierung und Anforderungen aus
Managementsichtweise waren Anpassungen von bereits bestehenden Life-Cycle Modellen
notwendig. Gerade aufgrund der starken Durchdringung der objektorientierten Denkweise und
der Verwendung von objektorientierten Programmiersprachen mußten altgediente
Entwicklungsmodelle erneuert werden. Ein bedeutender Schritt in Richtung OO-Entwicklung
wurde durch evolutionäre Softwareentwicklung und evolutionäres Prototyping sichergestellt.
2.2.2 Evolutionäre Softwareentwicklung
Evolutionäre Softwareentwicklung ist die
Erstellung eines Softwaresystems durch den
schrittweisen (inkrementellen) Ausbau eines
Prototypen zum fertigen Produkt. Das
Schlagwort zur Entwicklung heißt
,,evolutionäres Prototyping".
Das Vorgehensmodell der evolutionären
Softwareentwicklung sieht den Prozeß nicht
mehr als lineare Abfolge von Tätigkeiten,
sondern als eine Folge von Entwicklungszyklen,
Abb. 12: Evolutionäre Softwareentwicklung [Becke95]
2 Objektorientierte Analyse und Design
16
an deren Ende jeweils eine verbesserte Version des Produkts steht (siehe Abb.12). Eine
Wartungsphase als solche gibt es bei diesem Ansatz nicht. Sie wird durch einen weiteren
Entwicklungszyklus, basierend auf dem vorliegenden System und den neuen Anforderungen,
ersetzt.
Evolutionäre Prototypen wachsen grundsätzlich auf zwei Arten: inkrementell oder evolvierend.
Inkrementelles Wachstum bedeutet die schrittweise Erweiterung einer unvollständigen
Anfangslösung zur vollen Lösung. Bei evolvierenden Lösungen steht dagegen am Ende eines
jeden Zyklus nicht die Frage nach der Vollständigkeit, sondern Fragen nach der Konsistenz
(Widerspruchsfreiheit) und der Angemessenheit im Mittelpunkt. In beiden Fällen ist die
intensive Beteiligung des Auftraggebers am Entwicklungsprozeß erforderlich [vgl. Pombe96].
Wie aus dem Modell deutlich erkennbar ist, spielt OOA im evolutionären Prototyping eine sehr
wichtige Rolle. Im Gegensatz zu älteren Entwicklungsmodellen ohne Prototyping wird hier die
Analyse des Systems durch adäquate Werkzeuge des Software Engineering unterstützt. Der
Prototyp wird durch Einsatz von CASE-Tools erstellt und schrittweise bzw. evolutionär
entsprechend den Anforderungen von Benutzern und Auftraggeber modifiziert.
Einen ähnlichen Ansatz zu evolutionärer Softwareentwicklung liefert Boehm [Boehm88] mit
seinem Spiralmodell. Das Modell versucht, notwendige Phasen der Analyse, des Entwurfs, usw.
möglichst durchgängig oder wiederholbar zu gestalten, um so nach und nach die vollständige
Funktionalität des Systems zu
realisieren. Außerdem kann in jedem
erneuten Durchlaufen eines Zyklus ein
anderes Teilgebiet des Projektes gezielt
angesprochen werden, wenn dort in einer
vorhergehenden Phase Mängel entdeckt
worden sind. Hier kann ein
unvollständiger Prototyp des Systems
erstellt werden, an dem der Kunde
prüfen kann, ob das Produkt den
Wünschen entspricht. Das entspricht
grundsätzlich einem mehrfachen
Durchlaufen des Phasenmodells, nur daß
hier explizit gewünscht ist, bei jedem
Durchlauf der Spirale ein Modell zu
Abb. 13: Das Spiralmodell von Boehm [Boehm88]
2 Objektorientierte Analyse und Design
17
erstellen oder zu verfeinern, welches von jeder der anderen Phasen weiter bearbeitet werden
kann. [vgl. Schad94]
OOA spielt im Spiralmodell eine wichtige Rolle bzw. Phase, die mehrmals durchlaufen werden
kann, bis ein vollständiger Prototyp des zu erstellenden Systems erzeugt wurde. Durch
Prototyping sind sowohl Benutzer als auch Auftraggeber in den Entwicklungsprozeß
miteingebunden und stets an der Analyse des Systems beteiligt.
2.2.3 Der Object Engineering Process (OEP)
Der Object Engineering Process (OEP) ist ein praxisorientiertes Vorgehensmodell zur
Entwicklung objektorientierter Softwaresysteme, das sich sehr einfach und schnell an
unternehmensspezifische Bedürfnisse anpassen läßt.
Der OEP unterscheidet sich bezüglich der einzelnen Phasen unwesentlich von den klassischen
objektorientierten Softwareentwicklungsmodellen. Die Entwicklungsschritte Analyse, Design,
Implementierung und Test werden in einem Zyklus durchlaufen (vgl. Spiralmodell von Boehm
[Boehm88]).
Ein wesentlicher Unterschied besteht hingegen in der Anwendung des Modells auf das zu
entwickelnde System. Der OEP ist auf die Entwicklung individueller betrieblicher
Informationssysteme in großen Unternehmen abgestimmt, d.h. nur die unternehmensinterne
Softwareentwicklungsabteilung verwendet diesen Prozeß.
Das Vorgehensmodell ist sehr konkret ausformuliert und zugeschnitten auf eine ganz bestimmte
Architektur, Organisation und Entwicklungsumgebung. Die Anpassung des OEP für andere
Organisationen bzw. Projekte geschieht nicht, wie bei vielen anderen Vorgehensmodellen, durch
Konkretisierung der abstrakten Beschreibungen, sondern durch Entfernen unpassender und
Hinzufügung von fehlenden Beschreibungen. Der OEP gliedert sich in 5 Phasen bzw.
Iterationen, wobei OOA vorwiegend als Aktivität in der Vorbereitungsphase und im Entwurf
Abb. 14: Der Object Engineering Process [Oeste99]
2 Objektorientierte Analyse und Design
18
gesehen wird. Während Phasen den Hauptprozeß repräsentieren, werden die einzelnen
Iterationen, bestehend aus Analyse, Design, Implementierung und Test, in einem
untergeordneten Prozeß durchgeführt.
Prinzipiell steht im OEP der praktische Nutzen im Vordergrund, eine Idealisierung und
theoretische Perfektionierung des Prozeßmodells wird als zweitrangig betrachtet. [vgl. Oeste99]
2.3 Vorgehensweise bei OOA
Das Ziel der OOA ist eine möglichst vollständige Beschreibung des Problembereichs anhand
eines Analysemodells. Zur Erreichung des Ziels ist es notwendig, OOA nach einem anerkannten
Vorgehensmodell durchzuführen. Zur Erstellung eines Analysemodells ist es notwendig, nach
einer anerkannten Methodik vorzugehen. Vetter [Vette98] unterteilt OOA in eine Grob- und
Feinanalyse.
Die Grobanalyse umfaßt eine IST-
Zustandsaufnahme, Zielformulierung
und die Festlegung der Systemgrenzen.
Die Grobanalyse ist kein Zyklus, d.h.
diese Schritte werden im Rahmen eines
Projektes nur einmal durchgeführt. Die
Ergebnisse der Grobanalyse gehen in
den Prozeß der Feinanalyse ein, in dem
eine prototypmäßige Ermittlung der
Ergebnisse durchgeführt wird.
Der Prozeß der Feinanalyse ist ein
Zyklus, da pro Benutzersicht das
System vollständig modelliert und
implementiert wird (inklusive Design,
Konstruktion und Test), um anschließend wieder zur Feinanalyse zurückzukehren und die
nächste Benutzersicht festzulegen. Das Durchlaufen von Zyklen entspricht dem bereits
angeführten Spiralmodell, das sich mittlerweile als Vorgehensmodell in der objektorientierten
Softwarekonstruktion etabliert hat. [vgl. Vette98]
Die Grobanalyse und deren Inhalte als erster Schritt in der OOA sind nur vom jeweiligen Projekt
und dessen Zielen abhängig. Die Feinanalyse als wiederholbare Abfolge von Analyseschritten ist
sowohl abhängig vom Projekt, sowie von dessen Inhalt und funktionalen Anforderungen. Aus
Abb. 15: Vorgehensweise bei OOA [Vette98, S.279]
2 Objektorientierte Analyse und Design
19
diesem Grund erscheint es sinnvoll, nachfolgend den Prozeß der Feinanalyse und dessen
durchzuführende Tätigkeiten genauer zu beleuchten. Anschließend soll eine Auflistung bereits
anerkannter Methoden zur Durchführung der Feinanalyse zeigen, welche unterschiedlichen
Konzepte und Vorgehensweisen dabei verwendet werden.
Der Prozeß der Feinanalyse
Der Prozeß Feinanalyse als wesentlicher Teil von OOA dient dazu, ein globales Analysemodell
zu erstellen, bestehend aus [vgl. Schad94, S35.ff]:
· Statisches Modell
Die statische Sicht beinhaltet die Abbildung von Klassen, deren Objekten und Strukturen.
Eine mögliche Vorgehensweise zur Erstellung des statischen Modells beinhaltet folgende
Punkte:
1. Identifikation von Klassen und Objekten
2. Identifikation von Attributen und Objektbeziehungen
3. Identifikation von Strukturen
4. Zerlegung des Systems in Teilsysteme und Modellierung des statischen Modells
· Dynamisches Modell
Die dynamische Sicht beinhaltet eine Modellierung des Verhaltens von Objekten sowie die
Beschreibung der Veränderung ihrer Attributwerte und Beziehungen im zeitlichen Ablauf.
Eine mögliche Vorgehensweise zur Erstellung des dynamischen Modells beinhaltet folgende
Punkte:
1. Identifikation von Objektzuständen und Ereignissen, welche Attributwerte von
Objekten ändern
2. Identifikation von Ereignisfolgen und möglichen Szenarios
3. Identifikation von Aktionen und Aktivitäten der Objekte selbst
4. Modellierung des dynamischen Modells anhand von Zustandsdiagrammen
· Funktionales Modell
Die funktionale Sicht beinhaltet im Gegensatz zum statischen und dynamischen Modell nicht
eine Beschreibung der Objekte und Klassen selbst, sondern bildet die Systemfunktionalität
anhand von geeigneten Modellen und Diagrammen ab. Eine mögliche Vorgehensweise zur
Erstellung des funktionalen Modells beinhaltet folgende Punkte:
1. Abbildung der Funktionalität in Struktogrammen
2. Beschreibung von Funktionen in Pseudocode
2 Objektorientierte Analyse und Design
20
3. Abbildung der Funktionalität in Datenflußdiagrammen
Viele bekannte Analysemethoden enthalten die oben angeführte Dreiteilung in der
objektorientierten Feinanalyse, wobei jede Methode andere Schwerpunkte setzt. Als Ergänzung
soll nachfolgend eine Auswahl bekannter objektorientierter Analysemethoden kurz und
übersichtlich dargestellt werden, um aufzuzeigen, wo generelle Unterschiede in der
Modellierung und Konzeption zwischen den Methoden herrschen und ob alle 3 Teilmodelle
(statisch, dynamisch, funktional) des globalen Analysemodells von der Methode unterstützt
werden.
2.4 Objektorientiertes Design (OOD)
Im folgenden Kapitel soll nun auf den Begriff Objektorientiertes Design, dessen Vorgehensweise
und Bedeutung im Software-Entwicklungsprozeß eingegangen werden.
Der Begriff OOD wird in der Literatur oft auf unterschiedliche Weise zitiert. Daraus ergibt sich
so manche Schwierigkeit, den Begriff des objektorientierten Designs einerseits kurz und bündig
zu definieren und andererseits von OOA abzugrenzen. Viele OO-Experten verwenden auch
heute noch OOD als Synonym für OOA, die folgenden Kapitel sollen jedoch zeigen, daß sich
OOD durch seine Aufgaben, Inhalte und Konzepte sehr wohl von OOA unterscheidet und somit
eine eigenständige Phase in der Software-Entwicklung darstellt.
2.4.1 Begriffsdefinitionen
Objektorientiertes Design
Analysemethoden statisch dynamisch
funktional
Balzert, MOSA
x
x
x
Booch, OOD
x
x
x
Coad/Yourdon, OOA
x
(x)
x
Coleman, FUSION
x
x
x
Henderson-Sellers, OOO
(x)
x
Jacobson, OOSE
(x)
x
x
Martin/Odell, OOA&D
x
x
x
Rubin/Goldberg, OBA
(x)
x
(x)
Rumbaugh, OMT
x
x
(x)
Sully, MWO
x
x
x
Wirfs-Brock, RDD
(x)
x
Legende:
x = modellierbar
(x) = bedingt modellierbar
Abb. 16: OOA-Methoden und die modellierbaren Perspektiven [vgl. Stein97, S.40]
2 Objektorientierte Analyse und Design
21
Der Begriff ,,Objektorientiertes Design" wird in der verwendeten Literatur nicht eindeutig
spezifiziert. Schäfer spricht von einem Abbild der Realität auf den Lösungsbereich:
,,Objektorientiertes Design ist der Zwischenschritt von der Analyse zur Implementierung und
befaßt sich mit der Abbildung des Realitätsmodells auf den Lösungsbereich." [Schäf94, S.30]
Shumate definiert OOD als einen Prozeß zur Erstellung der Systemarchitektur, die primäres Ziel
von OOD sein soll:
,,Object Oriented Design is the determination of the overall system architecture, which consists
of a set of physical processing components hardware, software, people, and the
communication among them that will satisfy the system's essential requirements." [Shuma92,
S.46]
Die im Sinne dieser Arbeit treffendste Definition liefert Booch:
Zweck des objektorientierten Designs ist es, eine Architektur für die Entwicklung einer
Implementierung zu erzeugen und die allgemeine taktische Vorgehensweise festzulegen, die von
verschiedenen Elementen des Systems verwendet werden muß. [Booch94, S.320]
Unter OOD wird in der vorliegenden Arbeit eine strukturierte Vorgangsweise zur Erstellung der
Systemarchitektur verstanden. Eingebettet in einen objektorientierten Software-Life-Cycle soll
die Phase OOD die Ergebnisse von OOA übernehmen und selbst verwendbare Ergebnisse für die
Implementierung liefern. OOD legt den Grundstein für eine erfolgreiche Implementierung und
gibt Anweisungen für nachfolgende Entwicklungsphasen.
Prototyp - Prototyping
Über den Begriff ,,Prototyp" sind sich die Autoren der verwendeten Literatur relativ einig. Die
Definition von Pomberger liegt der vorliegenden Arbeit zugrunde:
,,Ein Prototyp ist ein mit wesentlich geringerem Aufwand als das geplante Produkt
hergestelltes einfach zu änderndes und zu erweiterndes ausführbares Modell des geplanten
Softwareprodukts. Prototyping umfaßt alle Arbeiten, die zur Herstellung von Prototypen
notwendig sind." [Pombe96, S.4]
Die Definition von Oestereich ist vergleichbar mit der von Pomberger, allerdings bezieht sich
Oestereich dabei nur auf evolutionäres Prototyping:
,,Prototyping ist die Realisierung von Teilsystemen, d.h. sukzessive zum Komplettsystem zu
gelangen." [Oeste95, S.25]
Der Begriff ,,Prototyp" und dessen Stellenwert im Entwicklungsprozeß wird durch Pomberger
treffend definiert. Prototyping wird im Rahmen dieser Arbeit als Aktivität im
Entwicklungsprozeß angesehen und dient als Unterstützung zur Lösung des
Spezifikationsproblems.
2 Objektorientierte Analyse und Design
22
Systemarchitektur
Der Begriff "Systemarchitektur" wird in der verwendeten Literatur eindeutig definiert. Booch
sieht in der Systemarchitektur die Organisation der Software und ihrer Komponenten:
"An architecture is the set of significant decisions about the organization of a software system,
the selection of the structural elements and their interfaces by which the system is composed,
together with their behavior as specified in the collaborations among those elements, the
composition of these structural and behavioral elements into progressively larger subsystems,
and the architectural style that guides this organization---these elements and their interfaces,
their collaborations, and their composition." [Booch99, S.37]
Eine ähnliche Definition liefern Garlan und Perry:
"Software architecture is "the structure of the components of a program/system, their
interrelationships, and principles and guidelines governing their design and evolution over
time." [Garlan and Perry, guest editorial to the IEEE Transactions on Software Engineering,
April 1995]
Die Systemarchitektur wird in dieser Arbeit als die Spezifikation des Gesamtsystems bezeichnet.
So wie es Garlan und Perry definieren, zeigt die Architektur Beziehungen zwischen
Komponenten und deren Struktur.
Design Pattern
Der Begriff "Design Pattern" wird in der verwendeten Literatur nicht eindeutig spezifiziert.
Levine spricht von einer vorgefertigten Lösung für ein spezielles Problem in der
Softwareentwicklung:
,,Design Patterns represent solutions to problems that arise when developing software within a
particular context" [Levin99, S.7]
Die Definition von Gamma dagegen wirkt detaillierter und liegt der vorliegenden Arbeit
zugrunde:
"A Design Pattern names, abstracts, and identifies the key aspects of a common design structure
that make it useful for creating a reusable object-oriented design" [Gamma94, S.3]
Ein Design Pattern ist eine Designvorlage zur Lösung eines spezifischen Problems in der Phase
OOD. Wie Gamma treffend erklärt, werden durch den Einsatz von Design Patterns
wiederverwendbare Strukturen für ähnliche Probleme im OOD geschaffen.
Computer Aided Software Engineering (CASE)
Über den Begriff ,,CASE" sind sich die Autoren der verwendeten Literatur relativ einig. Die
Definition vom SEI der Carnegie Mellon Universität liegt der vorliegenden Arbeit zu Grunde:
"A CASE tool is a computer-based product aimed at supporting one or more software
engineering activities within a software development process" [Carne99]
2 Objektorientierte Analyse und Design
23
CASE ist die werkzeugmäßige Unterstützung zur Durchführung einer oder mehrerer Aktivitäten
des Software Engineering im Rahmen des Entwicklungsprozesses. CASE-Werkzeuge werden in
der vorliegenden Arbeit nur auf die Phasen OOA und OOD bezogen.
Bieberstein bezieht den CASE-Ansatz auf alle Phasen des Software-Entwicklungsprozesses:
"CASE ist die computerunterstützte ingenieurmäßige Planung, Entwicklung und Fertigung von
Software-Systemen" [Biebe93, S.3]
2.4.2 Objektorientiertes Design
Objektorientiertes Design ist eine Methode des Software Engineering mit dem Hauptzweck bzw.
Ziel, die Architektur eines Softwaresystems zu erstellen, um so eine den Qualitätsanforderungen
entsprechende Entwicklung zu erreichen. [vgl. Pombe96]
Im Gegensatz zu OOA, wo ,,What is to be built" im Mittelpunkt steht, geht es beim OOD um das
,,How it is to be built". Der Begriff OOD ist im Software Engineering sicherlich nicht eindeutig
definiert. Autoren wie zum Beispiel Grady Booch [Booch94] und Peter Coad [Coad91]
verstehen darunter den Entwurf bzw. das Design von Objekten und deren Methoden. Bernd
Oestereich [Oeste98] wiederum schreibt vom Entwurf objektorientierter Bibliotheken mit
wiederverwendbaren Komponenten. OOD ist aber nicht nur die Spezifikation von Objekten,
sondern auch die Entwicklung der Systemarchitektur des zu entwickelnden Softwaresystems.
Daraus folgt, daß aus einem Feindesign der Objekte Beziehungen zwischen diesen hergestellt
und in einem Modell die Interaktionen zwischen diesen dargestellt werden.
Das Systemdesign baut auf den Ergebnissen der Anforderungsanalyse auf: identifizierte Objekte
der realen Welt werden in ein Modell übertragen. Anschließend werden daraus Klassen
abgeleitet, Beziehungen zwischen diesen vertieft (Feindesign) und die Systemarchitektur wird
erstellt (Grobdesign). Während der Analysephase war es ausreichend, die Verhaltensweisen und
Eigenschaften abstrakt zu beschreiben; da die Designphase die Vorstufe für die Implementierung
darstellt, müssen nun Mechanismen zur Kommunikation mit der Systemumwelt integriert
werden. Dies bedeutet auch, in der Designphase Ziel- und Entwicklungsumgebung festzulegen.
[vgl. Oeste95]
2.4.3 Aufgaben und Ergebnisse von OOD
Die Aufgaben im Rahmen des objektorientierten Designs lassen sich einerseits aus den
Ergebnissen der Anforderungsanalyse (OOA) und andererseits aus dem Ziel des OOD selbst
ableiten. Wichtige Aktivitäten und Aufgaben im Designprozeß sind:
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2001
- ISBN (eBook)
- 9783832451943
- ISBN (Paperback)
- 9783838651941
- DOI
- 10.3239/9783832451943
- Dateigröße
- 2.5 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Johannes Kepler Universität Linz – Wirtschaftsinformatik
- Erscheinungsdatum
- 2002 (März)
- Schlagworte
- uml-tools
