1 2.8) Methoden / Rekursion Transformation von nicht linear rekursiven Funktionen in iterative Funktionen Beispielhaft an fibo (über schlicht nach iterativ):

Präsentation zum Thema: "1 2.8) Methoden / Rekursion Transformation von nicht linear rekursiven Funktionen in iterative Funktionen Beispielhaft an fibo (über schlicht nach iterativ):"—  Präsentation transkript:

1 1 2.8) Methoden / Rekursion Transformation von nicht linear rekursiven Funktionen in iterative Funktionen Beispielhaft an fibo (über schlicht nach iterativ): Trick: akkumulierende Parameter Idee: es wird ja immer wieder dasselbe berechnet, deshalb werden Berechnungsergebnisse gespeichert. fiboAux erhält 3 Parameter, k und zwei Akkumulatoren, in denen fibo(k-2) und fibo(k-1) gespeichert werden.

2 2 2.8) Methoden / Rekursion Transformation von nicht linear rekursiven Funktionen in iterative Funktionen FUNCTION fiboAux (N, Acc1,Acc2: Integer): Integer; BEGIN IF N=0 THEN fiboAux := Acc1 ELSE fiboAux := fiboAux (N-1, Acc2, Acc1+Acc2) END ; fiboAux ist schlicht rekursiv und berechnet fibo, wenn wir sie mit Acc1=Acc2=1 aufrufen. FUNCTION fibo (N : Integer): Integer; BEGIN fibo := fiboAux (N,1,1) END ;

3 3 2.8) Methoden / Rekursion Transformation von nicht linear rekursiven Funktionen in iterative Funktionen fibo(5) = fiboAux(5,1,1) = fiboAux(4,1,2) = fiboAux(3,2,3) = fiboAux(2,3,5) = fiboAux(1,5,8) = fiboAux(0,8,13) = 8 Vergleich der folgenden Definitionen: Behauptung: fibo(n) = fiboAux(n,1,1) Beweis:

4 4 2.8) Methoden / Rekursion Klassifikation rekursiver Methoden Definition: Zwei Funktionen heißen wechselseitig rekursiv, wenn sie sich gegenseitig aufrufen. Beispiel: Die Methode Even/Odd sind wechselseitig rekursiv.

5 5 DigInf 05/06 Grundlagen der Objektorientierung Grundlagen und Begriffe Begriffe Analyse versus Entwurf Objektorientierung versus prozedurale Entwicklung Was ist die Unified Modelling Language (UML) Diagrammtypen Welche Diagrammtypen gibt es? Wie werden sie typischerweise verwendet? Eigenschaften objektorientierter Prozesse

6 6 DigInf 05/06 Objektorientierte Modellierung Zentrales Konzept...der UML ist die objektorientierte Modellierung. Doch was ist eigentlich ein Objekt? Beispiel: Kaffeemühle

7 7 DigInf 05/06 Kaffeemühle: Funktionen Kaffeebohnen einfüllen kurbeln = Bohnen zu Pulver mahlen Kaffeepulver entnehmen

8 8 DigInf 05/06 Kaffeemühle: Zustandswerte Bohnenvorrat Pulvervorrat

9 9 DigInf 05/06 Kaffeemühle: Charakterisierung unterstützte Funktionen füllen (mit Kaffeebohnen) mahlen (manipuliert den Inhalt) entnehmen (von Kaffeepulver) Inspektion des Bohnenvorrats Inspektion des Pulvervorrats zustandsbestimmende, interne Werte Bohnenvorrat Pulvervorrat Zusammenhänge zwischen Funktionen und Zustand Füllen nur möglich, wenn Bohnenvorrat noch nicht voll ist Mahlen nur möglich, wenn Bohnenvorrat noch nicht erschöpft ist Entnehmen nur möglich, wenn Pulvervorrat noch nicht erschöpft ist

10 10 DigInf 05/06 Kaffeemühle: Technische Interna Wie funktioniert das Mahlen? Technische Realisierung der internen Abläufe bleibt unbekannt Wissen um technische Realisierung ist zur Benutzung der Kaffeemühle unerheblich!  Gerade das Nicht-Wissen um die Realisierung von Funktionen und die interne Zustände ermöglicht die einfache Nutzung vieler Gegenstände/Konzepte. ?

11 11 DigInf 05/06 Modelle für komplexe Systeme Wozu braucht man Modelle in der Softwareentwicklung? Die Entwicklung komplexer Systeme erfordert die Bildung von Modellen, damit Menschen die Struktur und die Abläufe darin planen und realisieren können. Warum braucht man verschiedene Modelle für ein System? Es werden häufig unterschiedliche Modelle verwendet, um jeweils einen bestimmten Aspekt des Systems zu fokussieren. Je nach Aspekt werden häufig unterschiedliche Modellierungssprachen verwendet. Welche Probleme ergeben sich daraus? Für die Konstruktion des Gesamtsystems muss jedoch sichergestellt werden, dass die Einzelmodelle auch wirklich zueinander passen. Modelle unterschiedlicher Sprachen müssen zusammengeführt werden.

12 12 2.8) Methoden / Rekursion Anforderungsanalyse Was will der Anwender? Spezifikation, Analyse Unter der Spezifikation (auch Verhaltensspezifikation) verstehen wir eine Beschreibung des Verhaltens des Software-Systems. Die Spezifikation enthält keine Angaben darüber, wie dieses Verhalten realisiert werden soll, sondern nur darüber was das Verhalten sein soll. (WAS statt WIE) Phasen der Softwareentwicklung

13 13 DigInf 05/06 Spezifikation der Software-Steuerung für einen Telefondienst im Hotel Spezifikation / Was: Um ein Ferngespräch zu führen, muß der Anwender den Hörer abnehmen. Nach maximal 3 Sekunden ertönt ein Ton. Der Anwender wählt eine 9. Nach maximal drei weiteren Sekunden ertönt ein Freizeichen und der Anwender kann eine Telefonnummer wählen. Vorwegnahme von Entwurfsentscheidung / Wie: Das System umfaßt vier Zustände: wartend, Ton, Freizeichen, Verbunden. Um vom Zustand wartend in den Zustand Ton zu kommen, muß der Anwender den Hörer heben. Um vom Zustand Ton in den Zustand Freizeichen zu kommen muß der Anwender eine 9 wählen. Phasen der Softwareentwicklung

14 14 DigInf 05/06 Entwurf „konzeptioneller Entwurf“ implementierungsunabhängige Verfeinerung des Ergebnisses der Analyse im Hinblick auf technische Eigenschaften „pragmatischer Entwurf“ implementierungsabhängige Anpassung der Architektur an die Zielsprache. „Algorithmenentwurf“ Festlegung von klasseninternen Algorithmen und Datenstrukturen. Phasen der Softwareentwicklung

15 15 2.8) Methoden / Rekursion Entwurf Der Software-Entwurf wird oft auch als die Software-Architektur bezeichnet. In der Praxis werden oft fachliche Architektur, software-technische Architektur und systemtechnische Architektur unterschieden. Fachliche Architektur: Software-Systeme und ihre wesentlichen Schnittstellen (aus Anwendersicht) Software-technische Architektur: Komponenten, Module und ihre Aufrufbeziehungen, die wesentlichen Algorithmen Systemtechnische Architektur: Rechner, DBMS, Betriebssysteme, Middleware, Kommunikationsprotokolle, Telekommunikationsinfrastruktur Realisierung / Programmierung. Phasen der Softwareentwicklung

16 16 DigInf 05/06 Traditionelle Probleme prozeduraler Vorgehensweisen: Für Anforderungsanalyse, Analyse, Entwurf werden Spezialsprachen und –Modelle verwendet, die ineinander übersetzt werden müssen. Deshalb: neue Experten, neue Fehler, Anwendungswissen tritt in den Hintergrund Phasen der Softwareentwicklung

17 17 DigInf 05/06 Oo Entwicklungsabschnitte Anforderungsanalyse: Wie bisher, Überlappung mit OOA OO-Analyse: Bestimmen von Objekten und Klassen aus der Realität des Anwendungsbereichs OO-Entwurf: Ergänzen der Strukturen aufgrund technischer Erfordernisse OO-Programmierung: Umsetzen in Programmiersprache und Anpassen an Sprachspezifika

18 18 DigInf 05/06 OO Analyse Erforschung des Anwendungsbereichs, d.h. Objekte entdecken Klassen ableiten Klassen strukturieren Aufgaben zuordnen Zusammenarbeit festlegen

19 19 DigInf 05/06 Entdecken von Objekten des Anwendungsbereichs: Ableiten aus textueller Beschreibung (Hauptwörter selektieren und normieren) Ableiten aus eigenem Wissen Ableiten aus Expertenbefragung Ableiten aus „Use Case Model“ (Analyse der anwendungstypischen Handlungsabläufe) Kandidaten für Objekte sind greifbare Dinge Konzepte Ereignisse OO Analyse

20 20 DigInf 05/06 Ableiten von Klassen aus Objekten =„natürliche“ Gemeinsamkeiten von Objekten erkennen und diese in Klassen zusammenfassen Strukturieren der Klassen existierende Vererbungsstrukturen bestimmen (mögliche Subklassen suchen) (mögliche Superklassen suchen) Superklassen ergänzen (Gemeinsamkeiten in Superklassen extrahieren) Abhängigkeiten bestimmen (Aggregationen und Assoziationen charakterisieren) OO Analyse

21 21 DigInf 05/06 OO Analyse - Statik und Dynamik OOA erfasst statische und dynamische Aspekte statische Aspekte: alles um die Struktur von Klassen Klassen Attribute, Operationen Subsysteme dynamische Aspekte: alles rund um Objekte und ihre Werte Objekte Ereignisse Prozesse (verstanden als die Ausführung von Operationen)

22 22 DigInf 05/06 Objektorientierter Entwurf Ziel der Analyse ist ausschließlich: Verstehen und Beschreiben der Realität des Problembereichs. Ziele des Entwurfs sind: Ergänzung bisher fehlender technischer Aspekte, technische Umsetzbarkeit der Analyseergebnisse vorbereiten, organisatorische Umsetzbarkeit sicherstellen, Schnittstellen zu bereits vorhandener Software beachten, Möglichkeiten von Programmiersprachen einarbeiten, Implementierung vorbereiten.

23 23 DigInf 05/06 Objektorientierter Entwurf Bestandteile des Entwurfs: Überarbeiten von Klassen und Klassenstrukturen zur technischen Präzisierung der Analyseergebnisse. Überarbeitung von Klassen und Klassenstrukturen aufgrund von technischen Qualitätsanforderungen. Ergänzen der Klassenstruktur zur Konzeption einer Systemarchitektur. Überarbeiten der Klassenstruktur zur Realisierung einzelner Klassen. Überarbeitung der Klassenstruktur zur Realisierung von Verknüpfungen zwischen Objekten.

24 24 DigInf 05/06 Konzeption einer Systemarchitektur Zielsetzung: Ergänzen von Strukturen für Benutzungsschnittstelle, Prozesssteuerung und Datenhaltung. Anbinden dieser Strukturen an das problemspezifische Ergebnis der Analyse. Im Folgenden am Beispiel der „Datenhaltung“ erörtert.

25 25 DigInf 05/06 Konzeption einer Systemarchitektur Konzeption der Datenhaltung: Jedes Objekt muss selbst für Ablage persistenter Daten sorgen. Datenhaltung wird lokal unterstützt: Jedes Objekt wird individuell gesichert. Datenhaltung ist verteilt mit vielen Einzellösungen. Datenhaltung erfolgt durch Objektmanagementsystem: Objektmanagementsysteme standardisieren die lokale Datenhaltung. Datenhaltung erfolgt durch zentrale (relationale) Datenbank: Klasse(n) verkapseln Datenbank gegenüber objektorientiertem System. Jedes Objekt sendet seine Daten an Datenbankobjekt.