Transformation von nicht linear rekursiven Funktionen in iterative Funktionen

Transkript

1 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.8) Methoden / Rekursion 1 Transformation von nicht linear rekursiven Funktionen in iterative Funktionen FUNCTION fiboaux (N, Acc1,Acc2: Integer): Integer; BEGIN END ; IF N=0 THEN fiboaux := Acc1 ELSE fiboaux := fiboaux (N-1, Acc2, Acc1+Acc2) 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 ; 2.8) Methoden / Rekursion 2 1

2 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: 2.8) Methoden / Rekursion 3 Klassifikation rekursiver Methoden Definition: Zwei Funktionen heißen wechselseitig rekursiv, wenn sie sich gegenseitig aufrufen. Beispiel: Die Methode Even/Odd sind wechselseitig rekursiv. 2.8) Methoden / Rekursion 4 2

3 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 5 Objektorientierte Modellierung Zentrales Konzept...der UML ist die objektorientierte Modellierung. Doch was ist eigentlich ein Objekt? Beispiel: Kaffeemühle 6 3

4 Kaffeemühle: Funktionen kurbeln = Bohnen zu Pulver mahlen Kaffeebohnen einfüllen Kaffeepulver entnehmen 7 Kaffeemühle: Zustandswerte Bohnenvorrat Pulvervorrat 8 4

5 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 9 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. 10 5

6 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. 11 Phasen der Softwareentwicklung 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) 2.8) Methoden / Rekursion 12 6

7 Phasen der Softwareentwicklung 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. 13 Phasen der Softwareentwicklung 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. 14 7

8 Phasen der Softwareentwicklung 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. 2.8) Methoden / Rekursion 15 Phasen der Softwareentwicklung 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 16 8

9 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 17 OO Analyse Erforschung des Anwendungsbereichs, d.h. Objekte entdecken Klassen ableiten Klassen strukturieren Aufgaben zuordnen Zusammenarbeit festlegen 18 9

10 OO Analyse 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 19 OO Analyse 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) 20 10

11 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) 21 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

12 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. 23 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

13 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