3 Objektorientierte Methode

3 Objektorientierte Methode
3.1 Einführung ................................................................................................ 3
3.1.1 Abstrakte Datentypen ......................................................................... 3
Modularten ............................................................................................................................................ 3
Abstrakte Datenstrukturen ..................................................................................................................... 3
Abstrakte Datentypen ............................................................................................................................ 4
3.1.2 Begriffe ............................................................................................... 4
Objekt .................................................................................................................................................... 4
Botschaften ............................................................................................................................................ 5
Klasse .................................................................................................................................................... 5
Vererbung .............................................................................................................................................. 5
3.1.3 Auffinden von Objekten und Klassen ................................................ 6
3.1.4 UML - Unified Modelling Language ................................................. 6
Historische Entwicklung........................................................................................................................ 6
Umfang .................................................................................................................................................. 7
2
OOD
UML
3
3 Objektorientierte Methode
3.1 Einführung
Bei funktionsorientierten Ansätzen geht man von einer den
Lösungsbereich bestimmenden Hauptfunktion aus, die schrittweise verfeinert
wird. Die datenorientierten Ansätze stellen die Struktur der Daten in den
Vordergrund. Objektorientierte Ansätze bieten eine grundsätzlich andere
Sichtweise an, die dann auch i.a. zu nicht-hierarchischen Programmstrukturen
führt. Hier werden Daten nicht aus der Sicht von Ein- und Ausgaben von
Funktionen betrachtet, sondern als abgeschlossene Einheit, für die eine gewisse
Menge von Diensten und Operatoren definiert werden. Das führt uns zu den
abstrakten Datentypen. Der Weg zur Objektorientierung führte über abstrakte
Datentypen.
3.1.1 Abstrakte Datentypen
Modularten
Die einfachsten Modularten enthalten nur entweder eine Sammlung von
Daten (=Datenmodule) oder eine Sammlung von Funktionen
(=Funktionsmodule). Komplexere Modularten kombinieren diese beiden
Elementarformen.
Abstrakte Datenstrukturen
Abstrakte Datenstrukturen sind Module, die aus Datenstrukturen und
Operationen, die auf diesen Datenstrukturen arbeiten, bestehen. Während die
Datenstrukturen außerhalb des Moduls unsichtbar sind - man "abstrahiert" von
ihnen -, werden einige oder alle Operationen exportiert, so daß ein Zugriff auf
579863597
4
OOD
die Datenstrukturen außerhalb des Moduls nur über diese Operationen möglich
ist. Beispiele: Keller (stacks) und Warteschlangen (queues).
Abb.: Ringpuffer
Abb.: Ringpuffer in PDL
Der wichtigste Unterschied zwischen einer abstrakten Datenstruktur und
einem Funktionsmodul besteht darin, daß bei Funktionsmodulen der Aufruf
einer exportierten Funktion unabhängig von früheren Aufrufen ist, wohingegen
die lokalen Variablen in einer abstrakten Datenstruktur als Gedächtnis im
Modul fungieren.
Abstrakte Datentypen
Ein abstrakter Datentyp enthält die Deklaration von Datentypen und
Operationen, die Objekte dieser Typen manipulieren. Im Gegensatz zur
Vereinbarung abstrakter Datenstrukturen wird auf diese Weise nur das
Konstruktionsprinzip für Datenstrukturen vom gleichen Typ definiert, noch
keine Struktur selbst.
Beispiel:
TYPE puffer=MODULE
EXPORT nicht_leer, nicht_voll ...
:
:
END MODULE;
puffer1, puffer2:PUFFER
Es hat sich erwiesen, daß die Konstruktion von Software-Systemen mit
Hilfe abstrakter Datentypen eine der wertvollsten Abstraktionen beim Entwurf
großer Systeme darstellt.
3.1.2 Begriffe
Objekt
Ein Objekt ist irgendeine Einheit, die eine sichtbare Rolle spielt, indem sie
Dienste an Clients zur Verfügung stellt. Konkreter, ein Objekt ist ein
Softwarebaustein, der intern lokale Daten besitzt. Diese Daten charakterisieren
den Zustand des Objekts. Auf diese Daten können nur lokal für diese Einheit
definierte Operationen angewandt werden. Objekte vereinen in sich sowohl
Datenstruktur als auch Verhalten.
Zwei Objekte sind klar voneinander unterscheidbar, selbst wenn alle ihre
Attributwerte - wie Namen und Größe - identisch sind. Während ein Objekt in
der realen Welt einfach existiert, muß ein Objekt in einem Programmsystem
identifizierbar sein.
UML
5
Wir können Objekten folgende Merkmale zuordnen:
1. Alle Objekte verkörpern eine Abstraktion.
2. Objekte stellen Dienste bereit.
3. Clients stellen Anforderungen.
4. Anforderungen identifizieren Operationen.
5. Anforderungen können Objekte identifizieren.
6. Neue Objekte können kreiert werden.
7. Operationen können generisch sein.
8. Objekte können entsprechend ihren Diensten klassifiziert werden.
9. Objekte können eine gemeinsame Implementierung haben (=
Klasse).
10. Objekte können sich Teilimplementierungen teilen.
Botschaften
Das Ansprechen von Objekten erfolgt über den Austausch von
Botschaften. Eine Botschaft besteht aus dem
 Namen des adressierten Objektes und
 dem Aufruf einer Methode dieses Objektes sowie
 den gegebenenfalls zur Ausführung des Moduls benötigten
Informationen in Form einer Parameterliste.
Zumeist wird folgendes Schema angewendet:
 Empfänger Selektor [Argument [...]]
Klasse
In objektorientierten Programmen treten viele gleichartige Objekte auf,
die sich voneinander nur dadurch unterscheiden, daß sie verschiedene Werte
enthalten, also verschiedene Zustände haben. Die Struktur und das Verhalten die Art, wie sie auf Nachrichten reagieren werden gleich sein. Um diese
Gemeinsamkeiten auszudrücken, faßt man gleichartige Objekte zu Klassen
zusammen. Es wäre nicht rationell, dieselben Methoden in jedem einzelnen
Objekt separat zu speichern.
Klassen dienen dann als Mechanismus zur Erzeugung von Objekten
(Objektfabriken).
Klassen stellen Schablonen zur Definition der Methoden und Daten
gleichartiger Objekte dar. Die Objekte einer Klasse besitzen die gleiche
Struktur der Daten und die gleiche Menge von Operationen auf den Daten. Die
konkreten Mechanismen, die das Konzept der Objektklassen unterstützen,
unterscheiden
sich
in
den
verschiedenen
objektorientierten
Programmiersprachen.
Vererbung
Klassen von Objekten werden als abgeschlossene Einheiten von
Datenstrukturen und Operationen definiert. Häufig werden sich in
unterschiedlichen Objektklassen gleiche oder ähnliche Eigenschaften erkennen
579863597
6
OOD
lassen. Die gemeinsame Verwendung von Eigenschaften bestimmter
Datenstrukturen und Operationen wird durch das Konzept Vererbung
(inheritance) ermöglicht.
Für das Vererben können die Techniken
 der generischen Einheiten,
 des Polymorphismus (Overloading, Überschreiben)
verwendet werden.
3.1.3 Auffinden von Objekten und Klassen
Klassifizieren ist das Mittel mit dem wir unser Wissen ordnen.
Unglücklicherweise gibt es keinen eindeutigen Weg, um zu Klassen zu
kommen, keine Kochbuch-Antworten auf die Frage nach Klassen und
Objekten. Es gibt nun mehrere Wege, auf denen versucht wird, Klassen und
Objekte zu finden:
1. Linguistischer Ansatz
2. Attribut-Ansatz
3. Konzeptueller Ansatz
4. Strukturierter Ansatz
5. Zustands-Ansatz
6. Verarbeitungs-Ansatz
7. Beziehungstyp-Ansatz
8. Dekompositions-Ansatz
9. Wiederverwendungs-Ansatz
10. Abstraktions-Ansatz
.
3.1.4 UML - Unified Modelling Language
Historische Entwicklung
UML ruht im wesentlichen auf drei Säulen, repräsentiert durch die
Arbeiten dreier Entwickler:
 Grady Booch:
"Object-Oriented Analysis and Design with
Applications"
 James Rumbaugh: "Object-Orientied Modeling and Design". Von ihm
stammt vor allem das Klassendiagramm.
 Ivar Jacobson "Object-Oriented Software Engineering" Darin wurden
nun nicht Klasse und statische Struktur an den Anfang der
Entwicklung gestellt, sondern der Prozeß (Use Case). Damit kam es zu
einer Verbindung zwischen der Geschäftsmodellierung und der
Software-Entwicklung.
Die Version 1 der UML wurde Januar 1997 bei der OMG zur
Standardisierung eingereicht. Im September 97 wurde die Version 1.1
herausgegeben. Inzwischen eixsitert Version 1.3.
UML
7
Umfang
Die Modellierungssprache legt die Notation der einzelnen Sichten auf das
Anwendungsmodell fest. In UML sind acht Diagrammarten vorgesehen:
 Use-Case-Diagramm
 Sequenzdiagramm
 Zusammenspieldiagramm
 Klassenstrukturdiagramm
 Zustandsdiagramm
 Aktivitätdiagramm
 Komponentendiagramm
 Verteilungsdiagramm
Diagramme beschreiben statische Aspekte durch
Modul,
Klasse,
Assoziation/Rolle
und dynamische Aspekte durch
Prozeß (=Instanz e. Methode),
Ereignis,
Objekt.
579863597