2. Objektorientierung

2. Objektorientierung
2.1 Objekte: Die Idee
Frage dich nicht, WAS das System macht:
frage, WORAN es etwas macht.
Bertrand Meyer 1988
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Komplexität beherrschbar machen
Zerlegung in Teilsysteme
(Verantwortungsbereiche)
Klare Schnittstellen zwischen Teilsystemen
(Protokolle)
Verschiedene Abstraktionsebenen
(Hierarchie)
Vorgefertigte Teile - Wiederverwendung
(Baukastenprinzip)
T echnische Universität Dresden
Prof. Hußmann
Seite 1
Softwaretechnologie
Verantwortungsbereiche
• Sachbearbeiter in einem Betrieb oder einer Behörde
–
–
–
–
–
Ist unter definierter Adresse/Telnr. erreichbar.
Hat genau definierten Zuständigkeitsbereich
Bearbeitet genau definierte Einzelaufgaben
Verfügt über spezielles Wissen bzw. spezifische Information
Bearbeitet komplexe Geschäftsvorfälle in Zusammenarbeit mit
anderen Sachbearbeitern
• “Software-Sachbearbeiter” = Objekte
Meine Verantwortung:
Kontoführung
T echnische Universität Dresden
Prof. Hußmann
Meine
Verantwortung:
Produktkatalog
Softwaretechnologie
2. Objektorientierung
2.1 Objekte: Die Idee
2.2 CRC-Karten
2.3 Objektorientierte Programmierung
T echnische Universität Dresden
Prof. Hußmann
Seite 2
Softwaretechnologie
Objektorientierung
Identität:
„DD-0X5A“
Zustand:
Normalbetrieb
Verhalten:
„gelbes Licht“
• Wie ist das Objekt bezeichnet?
• Wie verhält es sich zu seiner Umgebung?
• Welche Informationen sind „Privatsache“ des Objekts?
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Grundkonzepte der Objektorientierung
• Ein System besteht aus vielen Objekten.
• Ein Objekt hat ein definiertes Verhalten.
– Verhalten setzt sich zusammen aus einer Menge genau definierter
Operationen zur Erfüllung von Einzelaufgaben.
– Eine solche Operation wird beim Empfang einer Nachricht ausgeführt.
• Ein Objekt hat einen inneren Zustand.
– Der Zustand des Objekts ist Privatsache.
– Das Resultat einer Operation des Objekts (bei Empfang einer
Nachricht) hängt vom aktuellen Zustand des Objektes ab.
• Ein Objekt hat eine eindeutige Identität.
– Die Identität eines Objektes ist unabhängig von seinen anderen
Eigenschaften.
– Es können mehrere verschiedene Objekte mit identischem Verhalten
und identischem inneren Zustand im gleichen System existieren.
T echnische Universität Dresden
Prof. Hußmann
Seite 3
Softwaretechnologie
Beispiel: Ampel-Objekt
Objekt zur Repräsentation
einer Ampel
Ampel DD-0X5A
Zeittakt
Lichtsignale
• Verhalten des Ampel-Objekts:
– Reaktion auf Nachrichten wie ‚Zeittakt‘, ‚Fahrzeugsensor‘
• Zustand des Ampel-Objekts:
– Schaltphase, Restzeit, Betriebsmodus, ...
• Identität des Ampel-Objekts:
– Unabhängig vom Zustand
– Unterscheidbar von anderen Ampeln
(auch solchen im gleichen Zustand!)
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Beispiel: Termin-Objekt
Objekt zur Repräsentation
eines Termins
12. Abteilungsrunde
gibDatum
versendeEinladungen
Ergebnis:
Datum
• Verhalten des Termin-Objekts:
– Reaktion auf Nachrichten wie ‘gibDatum’, ‘versendeEinladungen’
• Zustand des Termin-Objekts:
– Datum, Ort, Teilnehmer, geplant/bestätigt
• Identität des Termin-Objekts:
– Unabhängig vom Zustand
T echnische Universität Dresden
Prof. Hußmann
Seite 4
Softwaretechnologie
Klasse und Objekt
Klasse:
„Ampel“
Polymorphie:
Ampeln mit
Sensorsteuerung
reagieren in
spezieller Weise
auf Zeittakt
Vererbung:
Sensorgesteuerte
Ampel
• Welcher Begriff beschreibt das Objekt?
• Welche Begriffshierarchie wird verwendet?
• Wie hängt das Verhalten des Objektes von der Hierarchie ab?
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Erweiterte Konzepte der Objektorientierung
• Ein Objekt gehört zu einer Klasse.
– Die Klasse schreibt das Verhaltensschema und die innere Struktur
ihrer Objekte vor.
• Klassen besitzen einen ‘Stammbaum’, in der Verhaltensschema
und innere Struktur durch Vererbung weitergegeben werden.
– Vererbung bedeutet Generalisierung einer Klasse zu einer
Oberklasse.
• Polymorphie: Eine Nachricht kann verschiedene Reaktionen
auslösen, je nachdem zu welcher Unterklasse einer Oberklasse
das empfangende Objekt gehört.
n
T echnische Universität Dresden
n
Prof. Hußmann
Seite 5
Softwaretechnologie
Beispiel: Ampel-Klasse und Ampel-Objekte
DD-0X5A: SensorAmpel
DD-0Y3C: ZeitAmpel
DD-0X5B: SensorAmpel
Ampel
SensorAmpel
ZeitAmpel
Instanz einer Klasse
Generalisierung (Vererbung)
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Beispiel: Termin-Klasse und Termin-Objekte
AR-12: Teambesprechung
Figaro am 10.1.01: Theaterbesuch
AR-13: Teambesprechung
Termin
Geschäftstermin
Privater Termin
Teambesprechung Kundenbesuch
Theaterbesuch
Instanz einer Klasse
Generalisierung (Vererbung)
T echnische Universität Dresden
Prof. Hußmann
Seite 6
Softwaretechnologie
Beispiele: Polymorphie
• Jede Ampel reagiert auf den Zeittakt.
– Die Klasse Ampel schreibt vor, daß auf die Nachricht „Zeittakt“
reagiert werden muß.
– Verschiedene Reaktionen:
DD-0Y3C: ZeitAmpel
DD-0X5A: SensorAmpel
• Jeder Termin kann verschoben werden.
– Die Klasse Termin schreibt vor, daß auf die Nachricht
„verschiebeTermin“ reagiert werden muß.
– Verschiedene Reaktionen:
AR-13: Teambesprechung
Figaro: Theaterbesuch
• Unterklassen spezialisieren das Verhalten ihrer Oberklassen.
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Prinzipielle Vorteile von Objektorientierung
Zuständigkeitsbereiche
Lokale Kombination von
Daten und Operationen,
gekapselter Zustand
Klare Schnittstellen
Definiertes Objektverhalten,
Nachrichten zwischen Objekten
Vererbung und Polymorphie
(Spezialisierung),
Klassenschachtelung
Stabilität
Änderungsfreundlichkeit
Hierarchie
Baukastenprinzip
T echnische Universität Dresden
Benutzung vorgefertigter
Klassenbibliotheken,
Anpassung durch Spezialisierung
(mittels Vererbung)
Prof. Hußmann
Seite 7
Wiederverwendung
Softwaretechnologie
2. Objektorientierung
2.2 CRC-Karten
Objektorientiertes
Modell
CRC-Karten
Informelle
Problembeschreibung
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
CRC-Karten
• CRC = Class – Responsibility – Collaborator
(Klasse – Verantwortlichkeit – Mithelfer)
• Beck, Cunningham, Wilkerson, Wirfs-Brock (ca. 1989-1995)
• Technik zur Gruppenarbeit (Rollenspiele)
• Spielerische Hinführung zu objektorientiertem Denken
• Einziges Hilfsmittel: Zu beschriftende Karteikarten
Klassenname (class)
Ober- und Unterklassen
Verantwortlichkeiten
Mithelfer
(responsibilities)
(collaborators)
Klassenname (class)
Definition
Attribute
(attributes)
(Vorderseite)
T echnische Universität Dresden
(Rückseite)
Prof. Hußmann
Seite 8
Softwaretechnologie
CRC-Karten-Methode: Vorgehensweise
• CRC-Karten sind nur ein
Hilfsmittel.
• Das Kernstück der Methode
sind intensive
Gruppensitzungen.
• Voraussetzung: informelle Anforderungsbeschreibung
(ideal: ausführliche Anforderungsspezifikation)
• Kandidaten für Klassen (Karten) identifizieren
• Typische Szenarien identifizieren und durchspielen
(dabei: Karten schrittweise ausfüllen)
• Iteration: Verbesserungen, mehrfache Wiederholung
• Ungewöhnliche Szenarien durchspielen
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Klassen finden: Beispiel Terminverwaltung
Problembeschreibung:
Es ist ein Terminverwaltungssystem für Arbeitsgruppen zu
entwickeln. Das System soll alle geplanten Teambesprechungen
(z.B. Projektbesprechungen) speichern und die Reservierung von
Besprechungsräumen unterstützen. Das System soll automatisch
Kollisionen mit bereits bekannten Terminen vermeiden. Deshalb soll
auch die Eintragung privater Termine möglich sein.
Kandidaten für Klassen:
T echnische Universität Dresden
Prof. Hußmann
Seite 9
Softwaretechnologie
Gruppenspiel
• Ideale Gruppengröße: 5 bis 6 aktive TeilnehmerInnen
• Teilnehmer(Innen):
–
–
–
–
–
Fachspezialisten
Systemanalytiker
Systementwickler
Manager (?)
Moderator, 'Facilitator'
• Gruppendynamik:
– CRC-Karten-Sitzungen können Teamgeist stärken
– Vorhandene Gruppen-Probleme können aufbrechen
– Kein Mittel zur Klärung und Lösung von Problemen im Team !
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Beispiel einer CRC-Karte
Teambesprechung
Oberklassen:
Unterklassen:
Termin
Titel wissen
Datum wissen
Teilnehmer wissen
Teilnehmer einladen
Raum festlegen
Teilnehmer
Besprechungsraum
Teambesprechung
Ein Objekt 'Teambesprechung' beschreibt
genau einen Termin, an dem mehrere Teilnehmer der Gruppe teilnehmen sollen.
Rückseite:
T echnische Universität Dresden
Titel
Datum
Prof. Hußmann
Seite 10
Softwaretechnologie
Regeln für das Ausfüllen von CRC-Karten
• Verantwortlichkeiten:
– Eine Verantwortlichkeit enthält fast immer ein Zeitwort.
– '... wissen' kann auch eine Verantwortlichkeit sein.
• Mithelfer:
– Mithelfer-Einträge nur eintragen, wenn Kommunikation mit anderen
Objekten notwendig.
– Eine Verantwortlichkeit kann mehrere Mithelfer benötigen.
– Die Rückgabe einer Antwort gehört zu einem normalen
Kommunikationsvorgang - nicht als Verantwortlichkeit nennen.
• Karten-Rückseiten:
– Definitionen am besten vor dem Spiel ausfüllen, später überprüfen.
– Attribute können während des Spiels oder später ausgefüllt werden.
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
2. Objektorientierung
2.3 Objektorientierte Programmierung
My guess is that object-oriented programming will be in
the 1980's what structured programming was in the 1970's.
Everyone will be in favor of it.
Every manufacturer will promote his products as supporting it.
Every manager will pay lip service to it.
Every programmer will practice it (differently!).
And no one will know just what it is ..."
Tim Rentsch (1982)
T echnische Universität Dresden
Prof. Hußmann
Seite 11
Softwaretechnologie
Programmierparadigmen
• Funktionale Programmierung:
– Funktionsdefinition und -komposition, Rekursion
– Kein Zustandsbegriff
fac(n) = if n = 0 then 1 else n * fac(n-1) end
• Imperative Programmierung:
– Anweisungsfolgen, Schleifen, Prozeduren
– Variablen (Zustand)
k := n; r := 1; while k > 0 do r := r*k; k := k-1 end;
• Logische Programmierung:
– Formallogische Axiomensysteme (Hornklauseln)
– Fakten und Deduktionsregeln
– Resolution
fac(0,1).
fac(n+1, r) :- fac(n, r1), mult(n+1, r1, r).
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Strukturparadigmen
• Unstrukturierte Programmierung:
– Lineare Folge von Befehlen, Sprüngen, Marken
k:=n; r:=1; M: if k<=0 goto E; r:=r*k; k:=k-1; goto M; E:...
• Strukturierte Programmierung:
– Blöcke, Prozeduren, Fallunterscheidung, Schleifen
– Ein Eingang, ein Ausgang für jeden Block
k := n; r := 1; while k > 0 do r := r*k; k := k-1 end;
• Modulare Programmierung:
– Sammlung von Typdeklarationen und Prozeduren
– Klare Schnittstellen zwischen Modulen
DEFINITION MODULE F; PROCEDURE fac(n:CARDINAL):CARDINAL; ...
• Objektorientierte Programmierung:
– Kapselung von Daten und Operationen in Objekte
– Klassen, Vererbung und Polymorphie
public class CombMath extends Number { int fac(int n) ...
T echnische Universität Dresden
Prof. Hußmann
Seite 12
Softwaretechnologie
Orthogonalität
Strukturiert
Funktional
––
Imperativ
Pascal
C
Logisch
Modular
Objektorientiert
Modula-2
Ada
Java
C++
––
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Funktion und Daten
• Separation von Funktion und Daten
Funktionshierarchie
Datenbasis
• Integration von Funktion und Daten
• In den Strukturparadigmen:
– strukturiert:
Separation von Funktion und Daten
– modular:
Modul = (grosse) Funktionsgruppe + lokale Daten
– objektorientiert: Objekt = (kleine) Dateneinheit + lokale Funktionen
T echnische Universität Dresden
Prof. Hußmann
Seite 13
Softwaretechnologie
Kooperative Ausführung durch Objekte
12. Projektbesprechung
Zeit
M. Huber
(Teiln.1)
...
P. Fischer
(Teiln. n)
Raum
R12
Neu
Kollision?
Kollision?
Reservierung
vormerken
vormerken
Kooperierende Objekte mit lokaler Datenhaltung
Einfacher Übergang zu Parallelverarbeitung und Verteilung
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Objektorientierte Programmiersprachen
ALGOL
Simula
C
Smalltalk
Pascal
C++
Eiffel
UCSD
Pascal
C#
LISP
BASIC
CLOS
Visual
Basic
Ada
Object
Pascal
(Delphi)
Self
Ada-95
Java
T echnische Universität Dresden
Prof. Hußmann
Seite 14
Softwaretechnologie
Geschichte der OO-Programmierung
• Simula: Ole-Johan Dahl + Krysten Nygaard, Norwegen, 1967
• Allan Kay: The Reactive Engine, Dissertation, Univ. Utah, 1969
• Smalltalk: Allan Kay, Adele Goldberg, H. H. Ingalls, Xerox Palo
Alto Research Center (PARC), 1976-1980
• C++: Stroustrup, Bell Labs (New Jersey), 1984
• Eiffel: Bertrand Meyer, 1988
• Java: Ken Arnold, James Gosling, Sun Microsystems, 1995-
T echnische Universität Dresden
Prof. Hußmann
Softwaretechnologie
Die Programmiersprache Java
• Java™ – eine Modeerscheinung?
– die Programmiersprache für das Internet?
– die Geheimwaffe von Sun gegen Microsoft?
• Geschichte:
– Vorläufer von Java: OAK (First Person Inc.), 1991-1992
» Betriebssystem/Sprache für Geräte, u.a. interaktives Fernsehen
– 1995: HotJava Internet Browser
» Java Applets für das World Wide Web
» 1996: Netscape Browser (2.0) Java-enabled
– Weiterentwicklungen:
» Java als Applikationsentwicklungssprache (Enterprise Java)
» Java zur Gerätesteuerung (Embedded Java)
» Java Beans, Enterprise Java Beans (Software-Komponenten)
» Java Smartcards
T echnische Universität Dresden
Prof. Hußmann
Seite 15
Softwaretechnologie
Warum gerade Java?
• Java ist relativ einfach und konzeptionell klar.
• Java vermeidet “unsaubere” (gefährliche) Konzepte.
– Strenges Typsystem
– Kein Zugriff auf Speicheradressen (im Unterschied zu C)
– Automatische Speicherbereinigung
• Java ist unabhängig von Hardware und Betriebssystem.
– Java Bytecode
– Java Virtual Machine
• Java ist abstrakt in seinen Konzepten.
– z.B. Java Collection Framework
• Java ist angepaßt an moderne Benutzungsoberflächen.
– Java Swing Library
• Java ermöglicht nebenläufige Programme.
– sogenanntes multi-threading
T echnische Universität Dresden
Prof. Hußmann
Seite 16
Softwaretechnologie