OO Analyse

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
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 ;
2.8) Methoden / Rekursion
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
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
DigInf 05/06
5
Objektorientierte Modellierung
• Zentrales Konzept
• ...der UML ist die objektorientierte Modellierung. Doch
was ist eigentlich ein Objekt?
• Beispiel: Kaffeemühle
DigInf 05/06
6
Kaffeemühle: Funktionen
kurbeln = Bohnen zu Pulver mahlen
Kaffeebohnen einfüllen
Kaffeepulver entnehmen
DigInf 05/06
7
Kaffeemühle: Zustandswerte
Bohnenvorrat
Pulvervorrat
DigInf 05/06
8
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
DigInf 05/06
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.
DigInf 05/06
10
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.
DigInf 05/06
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
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.
DigInf 05/06
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.
DigInf 05/06
14
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
DigInf 05/06
16
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
DigInf 05/06
17
OO Analyse
• Erforschung des Anwendungsbereichs, d.h.
•
•
•
•
•
DigInf 05/06
Objekte entdecken
Klassen ableiten
Klassen strukturieren
Aufgaben zuordnen
Zusammenarbeit festlegen
18
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
DigInf 05/06
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)
DigInf 05/06
20
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)
DigInf 05/06
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.
DigInf 05/06
22
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.
DigInf 05/06
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.
DigInf 05/06
24
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.
DigInf 05/06
25