05.11.2013 Aufrufe

Datenorientierter Entwurf - Institut für Pervasive Computing - JKU

Datenorientierter Entwurf - Institut für Pervasive Computing - JKU

Datenorientierter Entwurf - Institut für Pervasive Computing - JKU

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

5. <strong>Entwurf</strong><br />

<strong>Entwurf</strong><br />

Software Engineering 2<br />

Analyse und Synthese<br />

<strong>Entwurf</strong>sebenen<br />

Subsysteme und Module<br />

Algorithmenentwurf<br />

Top-Down und Bottom-Up<br />

01000101 11100110<br />

10110110 00011010<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


2<br />

5. <strong>Entwurf</strong><br />

Motivation (1)<br />

Häufiger Fehler: übereilter Beginn mit<br />

Implementierung<br />

Software Engineering 2<br />

Folgen daraus:<br />

unzureichendes Problemverständnis<br />

Selbstüberschätzung, Optimismus<br />

Hackertum<br />

Orientierung an Sprach- und Maschinendetails<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


3<br />

5. <strong>Entwurf</strong><br />

Motivation (2)<br />

Software Engineering 2<br />

Sparen beim <strong>Entwurf</strong> (oder überhaupt Einsparen<br />

des <strong>Entwurf</strong>s) ist<br />

bei kleinen (Mini-) Projekten noch akzeptabel<br />

bei mittleren Projekten gefährlich<br />

bei großen Projekten katastrophal<br />

Folgen:<br />

es entsteht eine vorläufige Lösung<br />

Lösung hat „kleine“ Mängel<br />

Verbesserungen sollen die Mängel beseitigen<br />

=> Flickwerk<br />

hohe Fehlerwahrscheinlichkeit<br />

Produkt kann kaum gewartet werden<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


4<br />

5. <strong>Entwurf</strong><br />

Fazit<br />

daher: erst denken, dann handeln…<br />

Software Engineering 2<br />

typischer <strong>Entwurf</strong>saufwand:<br />

doppelter Implementierungsaufwand!<br />

(aus 40:20:40-Regel)<br />

Je sauberer der <strong>Entwurf</strong>, desto weniger Probleme<br />

beim Komponenten- und Integrationstest<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


5<br />

5. <strong>Entwurf</strong><br />

<strong>Entwurf</strong> ≈ Analyse<br />

Software Engineering 2<br />

<strong>Entwurf</strong> wird oft auch als Analyse bezeichnet.<br />

manchmal nur der erste (grobe) <strong>Entwurf</strong>sschritt<br />

z.B. bei OOP:<br />

OOA = Object-Oriented Analysis<br />

OOD = Object-Oriented Design<br />

nach dem eigentlichen Wortsinn:<br />

Analyse = Zerlegung<br />

Synthese = Zusammensetzung<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


6<br />

5. <strong>Entwurf</strong><br />

Analyse und Synthese (1)<br />

Problem<br />

?<br />

Lösung<br />

!<br />

<strong>Entwurf</strong> Analyse Synthese Integration<br />

Software Engineering 2<br />

? ?<br />

? ?<br />

Implementierung<br />

! !<br />

! !<br />

Teilprobleme<br />

Teillösungen<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


7<br />

5. <strong>Entwurf</strong><br />

Analyse und Synthese (2)<br />

In der Praxis mehrstufig:<br />

?<br />

Software Engineering 2<br />

Je nach Komplexität<br />

der Gesamtaufgabe:<br />

• unterschiedliche Detaillierung<br />

• unterschiedliche Tiefe<br />

(vgl. schrittweise Verfeinerung)<br />

? ?<br />

? ?<br />

?<br />

?<br />

?<br />

?<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


8<br />

5. <strong>Entwurf</strong><br />

<strong>Entwurf</strong>sebenen<br />

1. Zerlegung in Subsysteme<br />

Software Engineering 2<br />

2. Modularisierung<br />

3. Algorithmen<br />

„Architektur“<br />

In allen Ebenen:<br />

parallele Behandlung<br />

von Algorithmen<br />

und Datenstrukturen<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


9<br />

5. <strong>Entwurf</strong><br />

Zerlegung in Subsysteme<br />

Software Engineering 2<br />

Orientiert sich an den Ergebnissen der<br />

Problemanalyse<br />

Teilsysteme sind oft eigenständige Programme<br />

typische Abgrenzungen:<br />

Benutzergruppen<br />

Reihenfolge<br />

Benutzungshäufigkeit (z.B. Buchungen, Bilanz)<br />

Interaktivität (Client/Server; Batch-Abläufe)<br />

schwache Kopplung zwischen den Teilen<br />

Kommunikation über Dateien, Datenbanken,<br />

Netzwerk<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


10<br />

5. <strong>Entwurf</strong><br />

Modularisierung<br />

Software Engineering 2<br />

Zerlegung eines Teilsystems in handhabbare<br />

Brocken, die unabhängig voneinander entwickelt<br />

werden können.<br />

Module sind nicht allein ablauffähig<br />

enge Kopplung<br />

Kommunikation über Aufrufschnittstellen<br />

(Parameter), gemeinsame Speicherbereiche<br />

(siehe Kapitel 7 „Modularisierung“)<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


11<br />

5. <strong>Entwurf</strong><br />

Algorithmenentwurf<br />

Software Engineering 2<br />

Parallele Verfeinerung von Algorithmen und<br />

Datenstrukturen<br />

Was davon steht im Vordergrund?<br />

Funktionsorientierter <strong>Entwurf</strong><br />

<strong>Datenorientierter</strong> <strong>Entwurf</strong><br />

Objektorientierter <strong>Entwurf</strong><br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


12<br />

5. <strong>Entwurf</strong><br />

Funktionsorientierter <strong>Entwurf</strong><br />

(1)<br />

Eingabe<br />

Input<br />

I<br />

Algorithmus<br />

Process<br />

P<br />

Ausgabe<br />

Output<br />

O<br />

Software Engineering 2<br />

Typische Verfahren:<br />

schrittweise Verfeinerung (Wirth 1971)<br />

HIPO (Hierarchical Input Process Output; IBM 1974)<br />

SADT (Structured Analysis and Design Technique; Schomann<br />

1977)<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


13<br />

5. <strong>Entwurf</strong><br />

Funktionsorientierter <strong>Entwurf</strong><br />

(2)<br />

Grundidee:<br />

Zerlegung eines Problems in Teilprobleme<br />

Getrennte Betrachtung der Teilprobleme (rekursiv)<br />

Terminierung, wenn direkt implementierbar<br />

Software Engineering 2<br />

hilfreich: Abstraktion von der<br />

Implementierungssprache!<br />

allgemeingültiger <strong>Entwurf</strong>; erhöht Portabilität<br />

endet bei „hinreichender“ Konkretisierung<br />

vermeidet Einfluss spezieller Spracheigenschaften<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


14<br />

5. <strong>Entwurf</strong><br />

Systematische Verfeinerung<br />

Reihenfolge des weiteren Vorgehens:<br />

Software Engineering 2<br />

1<br />

4<br />

2<br />

Initialisieren<br />

Lesen<br />

Ende<br />

?<br />

Verarbeiten<br />

Ausgeben<br />

Terminieren<br />

3<br />

1. Sequentiell: 1. Teil schafft Voraussetzungen<br />

<strong>für</strong> den nächsten, etc.<br />

2. Datenquelle: Eingabedaten bestimmen<br />

den Ablauf (z.B. interaktive Programme).<br />

3. Datensenke: Ergebnisse sind bekannt; aus<br />

den Berechnungsalgorithmen ergeben sich<br />

die erforderlichen Eingabedaten.<br />

4. „Hardest First“: frühes Erarbeiten von<br />

Details; vermeidet Fehlentscheidungen<br />

wegen falscher Annahmen.<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


15<br />

5. <strong>Entwurf</strong><br />

<strong>Datenorientierter</strong> <strong>Entwurf</strong> (1)<br />

Daten stehen im Mittelpunkt:<br />

Software Engineering 2<br />

Aktion A<br />

Daten X<br />

Daten Y<br />

Aktion B<br />

Aktion C<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


16<br />

5. <strong>Entwurf</strong><br />

<strong>Datenorientierter</strong> <strong>Entwurf</strong> (2)<br />

Software Engineering 2<br />

Konzentration auf Datenfluss und<br />

Datenstrukturen<br />

Typische Verfahren und Hilfsmittel:<br />

JSD (Jackson Structured Programming; 1975)<br />

ER (Entity Relationship; Chen 1976)<br />

SA; Data Dictionary (Structured Analysis; Datenfluss;<br />

DeMarco 1979)<br />

Entscheidungstabellen<br />

attributierte Grammatiken<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


17<br />

5. <strong>Entwurf</strong><br />

Eignung des<br />

datenorientierten <strong>Entwurf</strong>s<br />

besonders günstig bei:<br />

Software Engineering 2<br />

komplexen Daten<br />

vielen (verschiedenen) Daten<br />

Datenbanken<br />

(ER-Diagramme)<br />

strukturierten Datenströmen<br />

(attributierte Grammatiken)<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


18<br />

5. <strong>Entwurf</strong><br />

Anwendungen des<br />

datenorientierten <strong>Entwurf</strong>s<br />

Software Engineering 2<br />

besonders häufig bei kaufmännischen<br />

Anwendungen:<br />

Ausgangspunkt Dokumentenanalyse<br />

(Formulare, Listen, Berichte, …)<br />

Untersuchung des Datenflusses<br />

(aus Struktur- und Ablaufanalyse)<br />

Ermitteln von Datentypen, Relationen und<br />

Konsistenzbedingunen (aus Datenanalyse)<br />

Rückschluss auf erforderliche Algorithmen<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


19<br />

5. <strong>Entwurf</strong><br />

Notationen<br />

Jackson<br />

Data Dictionary<br />

Bibliothek<br />

Bibliothek = { Buch }.<br />

Buch<br />

*<br />

Buch = Fachbuch | Lehrbuch.<br />

Software Engineering 2<br />

Fachbuch<br />

o<br />

Lehrbuch<br />

o<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


20<br />

5. <strong>Entwurf</strong><br />

Data Dictionary<br />

Software Engineering 2<br />

systematische Aufstellung der beteiligten Daten in<br />

BNF-ähnlicher Notation mit Erweiterungen:<br />

minimale u. maximale Anzahl von Wiederholungen<br />

Seminar = 5 { Teilnehmer } 20<br />

Wertebereiche von Datenelementen<br />

Tag = 1 .. 31<br />

ungeordnete Aufzählung von Elementen<br />

Name = Vorname + Zuname<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


21<br />

5. <strong>Entwurf</strong><br />

<strong>Datenorientierter</strong> <strong>Entwurf</strong><br />

(Fortsetzung)<br />

Alle Daten und Beziehungen fixiert, dann…<br />

Software Engineering 2<br />

Aufstellen von typischen Benutzungsfolgen<br />

(vgl. „Use Cases“, „Szenarien“)<br />

Sammlung der erforderlichen Operationen<br />

weiter mit algorithmischem Detailentwurf<br />

Algorithmen sind üblicherweise einfach<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


22<br />

5. <strong>Entwurf</strong><br />

Objektorientierter <strong>Entwurf</strong><br />

Software Engineering 2<br />

Kombination aus funktions- und<br />

datenorientiertem <strong>Entwurf</strong><br />

beginnt üblicherweise datenorientiert (z.B. nach<br />

Abbott), im weiteren Verlauf Szenarien („Use<br />

Cases“)<br />

Konzentration auf Objekt-Schnittstellen,<br />

Einbeziehung zentraler Spracheigenschaften:<br />

Vererbung<br />

Polymorphie<br />

dynamische Bindung<br />

Klassenbibliotheken und Frameworks<br />

OO-<strong>Entwurf</strong> ist kaum<br />

sprachunabhängig<br />

durchzuführen!<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


23<br />

5. <strong>Entwurf</strong><br />

Objektorientierter <strong>Entwurf</strong><br />

Verfahren und Hilfsmittel<br />

Software Engineering 2<br />

RDD (Responsibility-Driven Design; Wirfs-Brock 1989)<br />

CRC (Class, Responsibility, Collaboration; Beck,<br />

Cunningham 1989)<br />

OOA (Object-Oriented Analysis; Coad 1990)<br />

OOSD (Object-Oriented Structured Design;<br />

Wasserman 1990)<br />

OOD (Object-Oriented Design; Booch 1991)<br />

OMD (Object-Oriented Modeling and Design;<br />

Rumbaugh 1991)<br />

<strong>Entwurf</strong>smuster (Design Patterns; Gamma, Johnson,<br />

Vlissides 1995)<br />

UML (Unified Modeling Language; OMG, 1997)<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


24<br />

5. <strong>Entwurf</strong><br />

Top-Down und Bottom-Up-<br />

<strong>Entwurf</strong><br />

Top-Down<br />

Bottom-Up<br />

Software Engineering 2<br />

Zerlegung<br />

in Teilprobleme<br />

(Analyse)<br />

Ausgangspunkt:<br />

Vision vom<br />

Gesamtsystem<br />

Zusammenbau<br />

von Teillösungen<br />

(Synthese)<br />

Ausgangspunkt:<br />

Bibliotheken und<br />

Teilfunktionen<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


25<br />

5. <strong>Entwurf</strong><br />

Top-Down-<strong>Entwurf</strong><br />

Beginnt mit Problemstellung; zerlegt sie in Teilprobleme,<br />

endet schließlich bei nicht weiter zerlegbaren „Mini-<br />

Problemen“, die direkt implementiert werden können.<br />

Software Engineering 2<br />

Vorteile:<br />

+ gutes Problemverständnis<br />

+ maschinen- und<br />

sprachunabhängig<br />

+ kein Verirren in Details<br />

+ saubere Schnittstellen<br />

+ <strong>Entwurf</strong> noch im Produkt<br />

erkennbar<br />

Nachteile:<br />

– kritische Integration<br />

am Ende<br />

– Übersehen von<br />

existierenden<br />

(Teil-) Lösungen<br />

– gravierende Änderungen<br />

bei spät erkannten<br />

Problemen<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


26<br />

5. <strong>Entwurf</strong><br />

Bottom-Up-<strong>Entwurf</strong><br />

Beginnt mit konkreter Maschine, baut darauf immer<br />

weitere „abstrakte Maschinen“, die Teilprobleme lösen;<br />

endet bei „Problemlösungsmaschine“<br />

Software Engineering 2<br />

Vorteile:<br />

+ hoher Wiederverwendungsgrad<br />

+ hohe Funktionssicherheit<br />

durch<br />

inkrementellen Test<br />

+ schrittweise<br />

Integration<br />

Nachteile:<br />

– beginnt mit vermuteten<br />

Teilproblemen<br />

– Orientierung an<br />

technischen<br />

Gegebenheiten statt an<br />

Benutzeranforderungen<br />

– Gefahr der frühzeitigen<br />

Optimierung<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz


27<br />

5. <strong>Entwurf</strong><br />

Mischform: Outside-In-<strong>Entwurf</strong><br />

Software Engineering 2<br />

Bei objektorientiertem <strong>Entwurf</strong> mit Hilfe eines<br />

Frameworks<br />

Framework gibt die Grobstruktur vor<br />

wird schrittweise „von außen nach innen“ mit<br />

anwendungsspezifischen Funktionen gefüllt<br />

Inkrementelle Software-Entwicklung:<br />

„Design a little, implement a little, test a little.“<br />

Mini-Zyklen mit hoher Funktionssicherheit<br />

© G. Blaschek, <strong>Institut</strong> <strong>für</strong> <strong>Pervasive</strong> <strong>Computing</strong>, <strong>JKU</strong> Linz

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!