Folien zu Kapitel 4: Objektorientierte Software-Entwicklung W. Küchlin, A. Weber: Einführung in...

W. Küchlin, A. Weber: Einführung in die Informatik – objektorientiert mit Java -1- Springer-Verlag, ISBN 3-540-20958-1

Folien zu Kapitel 4: Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung

Analyse und Design

Foliensatz von A. Weber zur Vorlesung Informatik I, Bonn, 2002/03Überarbeitet von W. Küchlin zu Informatik I, Tübingen 2003/04



Objekte und Klassen

• Objekt (object)– Gedankliche oder reale Einheit in der Umwelt oder in Software

– Objekt i.A. gegeben durch Zustand (Attribute) und Funktionalität (Methoden, Operationen)

– Zustand ist durch die Werte von (Zustands-)Variablen (in Java: Felder (fields)) gegeben

– Methoden sind Algorithmen, die auf den Variablen operieren und so den Objekt-Zustand verändern können

– Ein Objekt ist ein Einzelstück• wie etwa ein bestimmtes Gerät mit Seriennummer



Objekte und Klassen

• Zwei Objekte gehören der gleichen (Objekt-) Klasse (class) an, wenn ihr Zustand und ihre Funktionalität gleich aufgebaut sind– alle Objekte einer Klasse haben die selben Methoden

– jedes Objekt hat einen eigenen Satz von Variablen mit dem gleichen Namen und Typ, aber mit eigenen Werten

• Z.B. zwei Geräte-Objekte mit unterschiedlicher Seriennummer

– Graphische Repräsentation nach folgendem Schema• Verwenden im wesentlichen UML (Unified Modeling Language)



z: Schaltzustands: Seriennummerk: Kanall: Lautstärke

aus() ein() getSeriennummer() wähleKanal() wähleLautstärke()

TV2000

«datatype»Schaltzustand

«datatype»Seriennummer

«datatype»Kanal

«datatype»Lautstärke

Objekte und Klassen

• Beispiel: Fernsehapparate der Klasse „TV2000“– Zustand setzt sich zusammen aus

den Werten der Zustandsvariablen (Name: Typ)

• s: Seriennummer, k: Kanal, l: Lautstärke, z: Schaltzustand

– Funktionalität setzt sich zusammen aus den Funktionen

• wähleKanal(), ein(), aus(), wähleLautstärke(), getSeriennummer()

• Graphische Notation

Zustand

Funktio-nalität

Name



Objekte und Klassen

• Weitere Beispiele:

d: Drehzahlr: Rückwärtslaufv: Vorwärtslaufz: EinAus

aus() ein() getDrehzahl() rückwärts() setDrehzahl() vorwärts()

Motor

p: Greifpositionz: EinAus

aus() bewegeLinear() bewegePunktZuPunkt() ein()

Robot

UMLBuch

(Java Stil)



Objektbeziehungen

• etwas UML Notation:– name: type– Zugang (access) zu Variablen und Methoden:

• + public (für alle anderen Objekte offen)

• - private (nur für Objekte der eigenen Klasse offen)

• # protected (nur für Objekte verwandter Klassen offen)

– Klassen: groß geschrieben– Objekte: unterstrichene Namen name: Class

• name ein Objekt, Klasse unbekannt

• : Class ein anonymes Objekt der Klasse Class



Objektbeziehungen

• Modellieren vom Beziehungen durch mathematische Relationen (Relation = Beziehung)

– Die Liste der Beziehungen ist die Liste der Tupel der Relation

– Diese Listen lassen sich in Tabellen speichern• Geschieht auf diese Art in relationalen Datenbanken

– Aus objektorientierter Sicht entspricht jeder Zeile ein Objekt• Die Tabelle entspricht der Klasse als der Summe ihrer Objekte

– Eine Objektklasse allein modelliert also auch schon eine Beziehung • Die zwischen den Zuständen der Objekte



Objektbeziehungen

• Beziehungen zwischen Objektklassen also „Relationen von Relationen“

• Objekte sind jedoch noch mächtiger (als Relationen von Relationen)– Enthalten neben Daten auch Funktionen

• Funktionen aus mathematischer Sicht spezielle Relationen• Aus Sicht der Informatik i.A. durch Programme repräsentiert

– Nur einfache Funktionen können als Tabelle repräsentiert werden– Vgl. auch hier wieder das Problem der Komplexität

• Spezielle Notation zur Repräsentation verschiedener Beziehungen zwischen Objekt-Klassen erleichtert das Verstehen durch den Menschen



• Allgemeine Beziehung zwischen Klassen durch Linien repräsentiert – Bsp: Zwischen Objekten der

Klasse Person und Objekten der Klasse Auto besteht die Beziehung „besitzt“

• Linie kann annotiert sein: Charakter der Beziehung– Name über der Linie angeben (Leserichtung durch Dreieck)– Vielfachheiten an Enden angegeben

• Zahl, oder * für „beliebig“ (0, 1, 2, ...), oder Bereich 1..2– Rolle der Klassen in der Relation an Enden angegeben

• Bsp: Person=Besitzer, Auto=Besitztum

Objektbeziehungen



Objektbeziehungen

• Beziehungen zwischen Objekten (bzw. Objekt-Klassen) können verschiedenster Natur sein. Wichtig:– strukturelle Beziehungen (structural relationship),

• liegen statisch, zur Übersetzungszeit, fest und beziehen sich auf Klassen

– verhaltensbezogene Beziehungen (behavioral relationship)• bestehen dynamisch, zur Laufzeit, zwischen Objekten

• Strukturell– Einschluss (containment, has-a)– Subtyp oder Vererbung (inheritance, subtype, is-a)

• Verhaltensbezogen– Informationsfluss oder Nachrichten (message)– Methodenaufruf oder Kunde/Lieferant (client/server)



Strukturelle Objektbeziehungen: Einschlussbeziehungen

• Zwei Objektklassen stehen in einer Einschluss-Beziehung (containment) zueinander, falls Objekte der einen Klasse Objekte der anderen Klasse einschließen

• Wir sprechen von einer Ansammlung oder Aggregation (aggregation) der Teilobjekte im umfassenden Objekt

• Wir sprechen auch von einer „hat-“ (has-a)-Beziehung, da hier ein umfassendes Objekt ein oder mehrere Teilobjekte hat

• Die Aggregation wird graphisch dadurch veranschaulicht, dass man am umfassenden Ende der Beziehungslinie eine Raute anbringt




• Beispiel:

– Eine Vorlesung „hat“ 0..200 Studenten

– Ein Student nimmt an 0..5 Vorlesungen teil• Die Analyse der realen Welt kann Fehler enthalten und muss

gegebenenfalls an neue Situationen angepasst werden– Eine Vorlesung kann auch 400 Studenten haben




• Die Aggregation kann im allgemeinen eine recht lose Beziehung sein– Zu einer Vorlesung gehören zwar Studenten, aber die Studenten

sind kein integraler Bestandteil• Zur Not könnte die Vorlesung auch ohne Studenten abgehalten werden

– Jedes Teilobjekt ist eines der Attribute des umfassenden Objekts, also Teil seines Zustands

• Für den (häufigen) Spezialfall, dass die Teilobjekte integraler Bestandteil des Ganzen sind, sprechen wir von einer Kompositions-Beziehung (composition relationship)– Die Teile sind nicht ohne das Ganze denkbar (sinnvoll).– Falls wir die Komposition speziell hervorheben wollen, benutzen

wir im Diagramm eine schwarz gefüllte Raute




• Beispiel: – Ein Auto „hat“ 4 Räder und einen Motor

In Java:Jedes Teilobjekt wird innerhalb des umfassenden Objekts als Feld deklariert.class Auto { Rad vr,vl,hr,hl; Motor m; // ... m.ein();}



Strukturelle Objektbeziehungen: Vererbungsbeziehungen

• Zwei Objektklassen stehen in einer Subtypbeziehung zueinander, falls der eine (der Subtyp) alle Eigenschaften der anderen (des Obertyps) besitzt – Und darüber hinaus evtl. noch weitere

• Der Subtyp (subtype) ist also eine ganz spezielle Abart (instance) des Obertyps (supertype) dadurch, dass er (evtl.) weitere spezialisierende Eigenschaften hat

• Der Obertyp ist eine Verallgemeinerung des Subtyps• Es gelten für die Menge der Daten und Methoden von

Subtyp S und Obertyp O die Beziehungen– DatenO DatenS und MethodenO MethodenS




• Ein Typ wird also durch Hinzunahme von Eigenschaften weiter spezialisiert

• Wir sprechen auch davon, dass der Subtyp zunächst die Eigenschaften des Obertyps erbt (inherit)– Die Beziehung ist eine Vererbungsbeziehung (inheritance

relationship)– Umgekehrt verallgemeinert der Obertyp den Subtyp dadurch, dass

er spezialisierende Eigenschaften weglässt• Wir sprechen darum auch von einer Verallgemeinerung

(generalization)• Verallgemeinerungen erlauben es, Replikationen von Eigenschaften

und Methoden in ähnlichen Typen zu vermeiden, indem sie in einem gemeinsamen Obertyp zusammengefasst werden

• Vererbungsbeziehungen werden durch einen Pfeil mit breiter hohler Spitze veranschaulicht– Jede Vererbungsbeziehung kann eine Aufrufbeziehung von der

Unterklasse zur Oberklasse (in Pfeilrichtung) beinhalten




• Beispiel:– Der Zustand

„Seriennummer“, der sowohl in „Fernsehgerät“ als auch in „Motor“ vorhanden ist, wird in einem gemeinsamen Obertyp „Gerät“ aufgeführt und von dort vererbt

– Vererbungsbeziehungen werden durch einen Pfeil veranschaulicht

seriennummer

seriennummer seriennummer




• Weiteres Beispiel: – Kaffeemaschinen vom Typ Cafe2000 haben eine Funktion zur

Befüllung von Kaffee und Wasser für bis zu 12 Tassen

– Das Luxusmodell Cafe2000LT hat zusätzlich noch eine Timerfunktion zur Eingabe der gewünschten Startzeit

Vererbung in Java: In Java erweitert (extend) man die Oberklasse (um weitere Eigenschaften) zu einer Unterklasse.class Cafe2000LT extends Cafe2000 { Time t; void timer(Time time) { // ... } }



Verhaltensbezogene Objektbeziehungen: Informationsfluss

• Objekte interagieren untereinander durch Austausch von Information

• Die elementarste und allgemeinste Art der Interaktion zwischen zwei Objekten ist das Versenden einer Nachricht (message) von einem Objekt zu einem andern

• Logisch wie Versenden eines Briefs– Eine Methode des Absenders schickt die Nachricht an den

Empfänger, wo eine weitere Methode die Nachricht empfängt und weiterverarbeitet

– Das Absenden und Empfangen geschieht unabhängig voneinander• Absender und Empfänger müssen also nie im Gleichklang sein und der

Absender kann nach dem Abschicken sofort weiterarbeiten asynchrone Kommunikation (asynchronous communication)




• Nachrichtenversand (message passing) hat den sehr großen Vorteil, dass er genauso gut zwischen räumlich getrennten Systemen funktioniert

• Wir veranschaulichen den Nachrichtenfluss als Pfeil mit offener Spitze über der zugrundeliegenden Beziehung – UML verwendet hier einen ähnlichen Pfeil mit einer

einarmigen Spitze– Wir dekorieren den Pfeil nach Bedarf mit geeigneten

Erläuterungen




• Beispiel für Nachrichtenversand:– Ein Objekt :Student der Klasse „Student“

schickt einem Objekt :Studentensekretariat die Personaldaten




• Wie in realer Welt können Objekte ein komplexes Geflecht von Informationsfluss-Beziehungen eingehen– Jedes Objekt kann (z. B. durch verschiedene Methoden)

vielerlei Nachrichten senden und auch empfangen

• Diese komplexen Situationen können durch Interaktionsdiagramme (interaction diagrams) modelliert werden– Sequenzdiagramme (sequence diagram)

• zeitl. Abfolge durch Anordnung der Nachrichten von oben nach unten

– Kollaborationsdiagramme (collaboration diagram)• Die Nachrichten werden bei Bedarf nummeriert, um ihre zeitliche

Abfolge zu verdeutlichen




• Beispiel:– Kollaborationsdiagramm einer komplexeren

Interaktion „Anmeldung mit Mahnung“ zwischen :Student und :Studentensekretariat




• Informationsflussbeziehungenkönnen i.A. als Client/Server Beziehungen modelliert werden– Ein Objekt spielt dabei die Rolle des Kunden

(Auftraggeber, Client)• Dieses fordert eine Dienstleistung an

– Ein anderes Objekt spielt die Rolle des Dienstleisters (Lieferant, Server)

• Dieses erbringt die Dienstleistung



Verhaltensbezogene Objektbeziehungen: Client/Server

• Dienstleistungen des Servers sind aufrufbare Methoden– Der Kunde ruft die Methode des Servers auf und liefert gegebenenfalls nötige

Parameter mit– Der Server führt die Methode aus und liefert ein Ergebnis zurück

• Sei es nur die Meldung, dass er fertig ist– Client und Server sind hier wie bei einem Telefongespräch für die Dauer des

Methodenaufrufs im Gleichklang• Der Client wartet zuerst, bis der Server seinen Aufruf akzeptiert und wartet

danach auf das Ergebnis• Synchrone Kommunikation (synchronous communication)

• Der Methodenaufruf (method call) ist von großer Bedeutung, da er die Erledigung von Aufgaben durch Delegation von Unteraufgaben erlaubt– Funktioniert aber nicht ohne weiteres zwischen räumlich getrennten Systemen

• Wir veranschaulichen den Methodenaufruf als Pfeil mit geschlossener Spitze über der zugrundeliegenden Beziehung– Wir dekorieren den Pfeil nach Bedarf mit geeigneten Erläuterungen



Verhaltensbezogene Objektbeziehungen: Methodenaufruf

• Beispiel: – Ein Roboter :Robot gibt einem seiner

„Antriebe“ :Drive einen Auftrag durch den Methodenaufruf vorwärts()

Methodenaufruf in JavaDer Client ruft auf einem Server-Objekt d der Klasse Drive eine Methode auf.// ...d.vorwärts();// ...



Verhaltensbezogene Objektbeziehungen

• Jede Einschlussbeziehung ermöglicht im allgemeinen eine Informationsflussbeziehung– Das umfassende Objekt kennt seine Teile und kann

ihnen deshalb eine Nachricht senden bzw. ihre Methoden aufrufen

d.vorwärts();

Drive d;vorwärts();



Verhaltensbezogene Objektbeziehungen: Methodenaufruf

• Der Methodenaufruf kann insbesondere in räumlich getrennten Systemen auch als Austausch eines Nachrichtenpaares verstanden werden– Allerdings mit der Maßgabe, dass der Empfänger die

Auftragsnachricht möglichst zeitnah bearbeitet und– der Sender der Auftragsnachricht wartet, bis er die zugehörige

Quittungsnachricht (mit dem Ergebnis) erhalten hat• Im objektorientierten Kontext wird manchmal nur noch

vom Versand von Nachrichten gesprochen, auch wenn es sich um Methodenaufrufe handelt– Da Nachrichten immer auch über Systemgrenzen hinweg verschickt

werden können– Allerdings ist Infrastruktur für einen entfernten Methodenaufruf

(remote method invocation) heute allgemein verfügbar• Java RMI • RPC (remote procedure call) Software für C




• Ein Methodenaufruf kann also als spezielle Form einer Informationsflussbeziehung verstanden werden

• Beispiel: – Ein Roboter :Robot interagiert mit einem seiner Antriebe :Drive

Als allgemeiner InformationsflussPaar von Nachrichten

Zum Vergleich noch einmal alsMethodenaufruf




• Ein Objekt kann sowohl Client als auch Server sein

• :Kunde im Beispiel nur Client

• :AutoHersteller ist Server (für Kunde) als auch Client (für Zulieferer1 und Zulieferer2)

• Zulieferer1 und Zulieferer2 sind Server



Objektorientierte Software-Entwicklung

• Hauptphasen bei der objektorientierten Software-Entwicklung– Analyse (analysis)– Entwurf (design)– Implementierung (implementation)



Hauptphasen der objektorientierten Software-Entwicklung: Analyse

• Analyse (analysis)– „Reale Welt“ wird auf die Existenz von Objekten

und Objektbeziehungen hin untersucht• Ein objektorientiertes Modell der realen Welt wird

erstellt

• Außerdem wird analysiert, auf welche Art das Softwaresystem später genutzt werden soll

– Welche Funktionalität es wem zur Verfügung stellen muss

– Es wird gefragt, was mit den Objekten warum geschieht oder geschehen soll



Hauptphasen der objektorientierten Software-Entwicklung: Entwurf

• Entwurf (design)– Das objektorientierte Modell der realen Welt wird in

die Welt der Software übertragen – Es wird aufgrund von programmiertechnischen

Notwendigkeiten ergänzt oder modifiziert• Es entsteht ein Modell der Software-Architektur

– Nun ist von Interesse, wie etwas im Prinzip geschehen soll



Hauptphasen der objektorientierten Software-Entwicklung: Implementierung

• Implementierung (implementation)– Die Software-Architektur wird zum lauffähigen

Programm konkretisiert• Objektzustände werden durch Datenstrukturen

repräsentiert

• Objektfunktionalität wird durch Algorithmen realisiert und ausprogrammiert

– Es wird genau festgelegt, wie alles im Einzelnen geschieht



Objektorientierte Analyse und Entwurf

• Objektorientierte Analyse beschäftigt sich mit dem Extrahieren von Objektklassen und Objektbeziehungen aus einer informellen Problembeschreibung– Das Ziel ist es, ein Modell der realen Welt zu gewinnen, das dann im

anschließenden Entwurf zum Grundstock eines Modells der Software wird

• Bei der Analyse beginnt man mit einer natürlich-sprachlichen Beschreibung des Problems – Das Problem kann z. B. sein, dass ein bestimmtes Software-System zur

Anlagesteuerung gebraucht wird– Zum einen muss das Umfeld des Systems beschrieben werden, also z. B.

die zu steuernden Geräte einer Anlage– Zum anderen werden alle Nutzungsarten (use cases) separat beschrieben

mit einer genauen schrittweisen Aufzählung der abzubildenden Arbeitsabläufe

• Wir sprechen von einer Nutzungsartanalyse (use case analysis) und Nutzungsszenarien (scenarios)



Objektorientierte Analyse und Entwurf

• Diese Beschreibungen untersuchen wir gezielt nach – darin enthaltenen Objekten, ihren Attributen, ihrer

Funktionalität und ihren Beziehungen• Substantive geben oft Hinweise auf Objekte und ihre Zustände,• Verben auf Funktionalität,• Aussagen wie „hat ein“ oder „ist ein“ deuten auf Objektbeziehungen

hin

• Im objektorientierten Entwurf werden die gefundenen Strukturen auf die jeweilige Programmiersprache abgebildet und gegebenenfalls um softwaretechnische Notwendigkeiten und Hilfskonstrukte (z. B. spezielle Datenstrukturen) ergänzt– Da wir diese Konstrukte hier noch nicht kennen, konzentrieren

wir uns im folgenden größeren Beispiel auf die Analyse und den unmittelbar durch sie bedingten Teil des Entwurfs



Analyse einer Werkstück-Vereinzelungseinheit

• Gegeben ist eine modellhafte Roboterzelle, bestehend aus einem Roboter mit Zuführ- bzw. Wegführsystemen– Zu Demonstrationszwecken werden Gummibälle in Röhren

und über ein Transportsystem im Kreis bewegt• Der Roboter hebt die Bälle von einem System aufs andere

– Es ist hier nur die Steuerung für die sog. Vereinzelungseinheit zu entwerfen

• Sie ist typisch für die Aufgabe, einen Strom aus Werkstücken (Teilen) so zu separieren, dass die Teile einzeln aufgenommen und weiterbearbeitet werden können




Roboterzelle

Applet zur Simulation der Vereinzelung

http://robo16.fh-reutlingen.de/german/



Werkstück-Vereinzelungseinheit

Roboterzelle

Nachbau der Vereinzelungseinheit(Bälle werden nach links ausgeblasen)

http://robo16.fh-reutlingen.de/german/DemonstrationenFernsteuerung einer Werkstückvereinzelung




• Situationsbeschreibung– Die Vereinzelungseinheit besteht aus einer senkrechten Röhre, zwei

Schiebern A und B, zwei Sensoren C und D, sowie einem Druckluftventil V – In der Röhre können Bälle gespeichert werden, die von oben zugeführt

werden und die auf Anforderung unten einzeln aus der Röhre geblasen werden sollen

– Die Schieber können die Stellungen geöffnet oder geschlossen einnehmen• Ist ein Schieber geschlossen, so ist die Röhre geschlossen

– Die Sensoren melden, ob sich an der entsprechenden Stelle ein Ball befindet• Falls ja, sind sie aktiviert, falls nein, sind sie deaktiviert

– Am unteren Ende der Röhre befindet sich ein Druckluftventil, das geöffnet oder geschlossen werden kann und das nicht ständig geöffnet bleiben sollte




• Vereinfachtes Schema der Vereinzelungseinheit

• Simulation in einem Applet




• Nutzungsszenarien:– 1. Standardoperation:

• Die Bälle werden von oben zugeführt und von der Röhre gespeichert

• Auf Anforderung wird genau ein Ball freigegeben und aus dem Ausgabeschacht geblasen

– 2. Wartung/Fehlerbeseitigung: • Der Wartungstechniker aktiviert einen Wartungszyklus, in dem alle

Operationen der beteiligten Geräte einmal ausgeführt werden

• Stellt er eine Fehlfunktion fest, so lässt er sich die Seriennummer des betreffenden Geräts ausgeben und tauscht es aus




• Mögliche Objekte– Vereinzelungseinheit, Schieber, Sensor, Ventil, Ball(?),

Röhre(?)

– Bei Ball und Röhre ist fraglich, ob sie Funktionalität und Zustände haben

• Beziehungen– Die Vereinzelungseinheit enthält Schieber, Sensoren, Ventil

und eine Röhre

– Bälle sind kein integraler Bestandteil, aber es besteht in jedem Fall eine (eventuell temporäre) Beziehung




• Modellierung der Beziehungen

Alternative Klassendiagramme für die Vereinzelungseinheit




Vereinzelungseinheit (Alternative I) nach Szenarium 1

Für Szenarium 2




Klassendiagramm für dieVereinzelungseinheitmit Vererbung(des generalisierendenKonzepts „Gerät“).

(Für Szenarium II, für get_Seriennummer)




• Nun folgt ein weiterer Zyklus der Präzisierung um Hilfskonstrukte mit dem Ziel der Implementierung– Insbesondere ist die (1:n)-Beziehung zu Ball zu modellieren

• Wir gehen in die Analyse zurück– Wir erfahren (vom Hersteller):

• Die Vereinzelungseinheit enthält zu jedem Zeitpunkt eine Menge von maximal sieben Bällen

• Eine endliche Menge kann durch ein Software-Objekt „E-Menge“ modelliert werden, da wir es mit einem abstrakten Datentyp mit Grundmenge und Funktionalität (einfügen, wegnehmen) zu tun haben– Enthaltensein ist hier eine lose Assoziation, da die Bälle auch außerhalb der

Menge existieren können




Klassendiagramm für E-Menge



Entwurfsmuster

• Man ist bestrebt, für häufig vorkommende Problemstellungen entsprechende Entwurfsmuster (design patterns) für die Architektur der Software zu entwickeln

• Ein Entwurfsmuster besteht aus einer Anzahl von Klassen und ihren Beziehungen– Gegeben durch ein Klassendiagramm, Interaktionsdiagramm, ...

• Die für die Problemstellung relevanten Attribute und Methoden sind skizziert– aber nicht im Detail vorgeschrieben

• Ein konkreter Entwurf folgt dem Muster, gestaltet es aber im Detail noch aus



Beispiel: Architekturmuster einer Gerätefernsteuerung

• Schema eines Geräts mit entfernter Steuerung




Klassendiagramm für Muster „Remote Control- Controller-Hardware“




• Die Geräte-Hardware selbst unterstützt aber keine Funktionsaufrufe – Kann deshalb unmittelbar nur als Klasse mit Speicherstellen anstatt

von Methoden modelliert werden.

• Für die Realisierung brauchen wir einen Adapter

• Adapter-Pattern




• Schema Remote-Controller




• Entwurfsmuster des Stellvertreters (Proxy)



Objekte, Klassen, abstrakte Datentypen

• Ein Datentyp ist gegeben durch die Spezifikation einer Menge von Objekten mit gleichartigem Zustand und gleicher Funktionalität

• Eine Objekt-Klasse repräsentiert einen Typ (type) durch eine Implementierung– Objekt-Zustand in Datenstruktur gespeichert– Funktionalität durch Funktionen ausprogrammiert (die auf Objekten operieren)

• Diese Bündelung von Objekten mit den auf ihnen relevanten Operationen ist ganz ähnlich wie bei herkömmlichen abstrakten Daten-Typen – In Mathematik wird i.A. von Signaturen gesprochen

• Zustand ist Konzept der Informatik, nicht der Mathematik, siehe auch später



Objekte, Klassen, abstrakte Datentypen

• Aufrufschnittstelle besteht aus öffentlichen (public) Methoden und Attributen

• Zur Realisierung der Funktionalität werden i.A. auch private Methoden und Attribute benötigt– Dies ergibt sich auch aus dem Prinzip der

funktionalen Dekomposition des Software Designs



Funktionale Dekomposition

• Funktionale Dekomposition ist ein allgemeines Entwurfsprinzip für Software– Das auch bei objektorientierter Software

Entwicklung wichtigen Platz hat– Ganz wesentlich funktionaler Programmierung

zugrundeliegt– Und auch bei imperativen Sprachen eingesetzt

werden sollte



Funktionale Dekomposition

• Im Verfahren der funktionalen Dekomposition geht man folgendermaßen vor:

1) Hierarchisch absteigende Zerlegung der Funktion in immer elementarere Teilfunktionen,

2) Abstrakte Spezifikation der Funktionen (bzw. Methoden), die etwa die Aufrufschnittstelle realisieren sollen die jeweils von höheren Funktionen aufgerufen werden und selbst kleinere Teilfunktionen aufrufen

3) Ausprogrammieren der Funktionen (bzw. Methoden)

Folien zu Kapitel 4: Objektorientierte Software-Entwicklung W. Küchlin, A. Weber: Einführung in...

Documents

Transcript of Folien zu Kapitel 4: Objektorientierte Software-Entwicklung W. Küchlin, A. Weber: Einführung in...