SS / 16 schrittweise Verfeinerung -> Wirth, 1971, Programm Development by Stepwise Refinement

Transkript

1 IMPLEMENTIERUNGSSTRATEGIE bis jetzt: Programmstruktur für Programmieren im Kleinen jetzt: Programmstruktur für Programmieren im Großen zunächst allgemein, d. h. sprachunabhängig SS / 16 MEILENSTEINE DER PROGRAMMIERSTILE Freistil-Programmierung -> Fortran, 1954, Algol 60, 1958; Cobol, 1960,... schrittweise Verfeinerung -> Wirth, 1971, Programm Development by Stepwise Refinement modulare Programmierung -> Anfang der 70iger Jahre -> CDL, FORTRAN ADT-Programmierung -> Simula, 1966; -> Concurrent Pascal, 1974; Alphard, 1974; CLU, 1975;... -> Anfang der 90iger Jahre -> Modula-2, 1980; Oberon, 1987;... Java, 1996,... Objekt-orientierte Programmierung monika.heiner@informatik.tu-cottbus.de SS / 16

2 ZUTATEN procedure EULER (in G : GraphT, out antwort : (nein,geschlossen,offen)) var U: Integer; begin /* 1. Bestimme die Anzahl U */ U := 0; loop Knoten von G do if Anzahl der anliegenden Kanten ungerade then U := U + 1 endif endloop; /* 2. Auswerten der ermittelten Anzahl U */ switch U : case 0: /* geschlossen, d.h. ex Eulerkreis */ case 2: /* offen, d.h. es ex Eulerweg */ default /* nein, d.h. es ex keine Lösung */ endswitch end EULER. monika.heiner@informatik.tu-cottbus.de SS / 16 ZUTATEN procedure EULER (in g : GraphT, out antwort : (nein,geschlossen,offen)) var U: Integer, node: NodeT; begin /* 1. Bestimme die Anzahl U */ U := 0; firstnode(g, node); repeat if odd( neighbours (g, node)) then U := U + 1 endif until not nextnode(g, node); /* 2. Auswerten der ermittelten Anzahl U */ switch U : case 0: /* geschlossen, d.h. ex Eulerkreis */ case 2: /* offen, d.h. es ex Eulerweg */ default /* nein, d.h. es ex keine Lösung */ endswitch end EULER. monika.heiner@informatik.tu-cottbus.de SS / 16

3 ZUTATEN program EulerMain procedure euler (..) procedure initgraph (..) procedure neighbours (..) procedure nextnode (..) procedure addarc (..) procedure addnode (..) procedure createkoenigsberg (..) procedure firstnode (..) GraphT graph = [][] integer procedure odd (..) monika.heiner@informatik.tu-cottbus.de SS / 16 I. IDEE: I : S : SCHRITTWEISE VERFEINERUNG program EulerMain GraphT graph = [][] integer procedure euler (..) procedure createkoenigsberg (..) procedure initgraph (..) procedure firstnode (..) procedure nextnode (..) procedure neighbours (..) procedure addnode (..) procedure addarc (..) procedure odd (..) monika.heiner@informatik.tu-cottbus.de SS / 16

4 1. IDEE, I, W, WERTUNG monolithisches Programm = eine Datei man kann das Programm von oben nach unten lesen ->... und bei einem geeigneten Abstraktionsniveau aufhören eine Änderung (egal wo, egal wie umfangreich) erfordert erneute Übersetzung der gesamten Quelle -> schnell sehr zeitaufwendig -> Übersetzungszeiten wachsen i. allg. überproportional mit Quellkode-Länge monika.heiner@informatik.tu-cottbus.de SS / IDEE: I : M : MODULARE PROGRAMMIERUNG Zerlegung in Programm-Module (Bausteine, Dateien) ein Modul kann getrennt -> organisiert -> separate Datei -> entwickelt -> Arbeitsteilung im Projektteam -> übersetzt -> Zeitersparnis bei größeren Programmen (Änderung in einem Modul erfordert nur erneute Übersetzung dieses Moduls) -> getestet -> Bottom-up Entwurf (mit einem geeigneten Testrahmen) werden Splittung erfolgt nach inhaltlichen Gesichtspunkten -> funktionaler Zusammenhang -> minimale Schnittstellen Kopplung zwischen Modulen erfolgt über import/export monika.heiner@informatik.tu-cottbus.de SS / 16

5 2. IDEE: I : M : MODULARE PROGRAMMIERUNG module GraphT export proc firstnode(..) export proc nextnode(..) export proc neighbours(..) export proc initgraph(..) export proc addnode(..) export proc addarc(..) GraphT graph = [][] integer S C H N I T T S T E L L E module EulerMain import GraphT; proc euler(..) proc createkoenigsberg(..) procedure odd(...) monika.heiner@informatik.tu-cottbus.de SS / 16 -S VISUALISIERUNG DER IMPORT/EXPORT-STRUKTUR Modul-Graph -> Knoten - Module -> Kanten - import/export-relation allg. können beliebige Geflechte von Modulen aufgebaut werden module E module G module F um die Übersicht zu behalten, empfehlen sich jedoch (weitgehend) hierarchische (d.h. azyklische) Strukturen module A module D module B module C monika.heiner@informatik.tu-cottbus.de SS / 16

6 2. IDEE, I, W, WERTUNG modularisiertes Programm = zwei Module sinkende Gesamtübersetzungszeiten während der Programmentwicklung ABER EulerMain kann erst übersetzt werden, wenn GraphT erfolgreich übersetzt wurde -> zur Übersetzung von GraphT müssen jedoch alle Prozeduren und die Implementierung der Datenstruktur ausformuliert sein nur schwache Kontrolle über die Schnittestelle Offenlegung aller Implementierungsdetails keine Trennung von Schnittstellen- und Implementierungsinformationen monika.heiner@informatik.tu-cottbus.de SS / IDEE: I : DATENKAPSEL D (I (INFORMATION HIDING) Modul = ADT ADT - Datentyp, der ausschließlich gekennzeichnet ist durch -> Menge der Werte, die man Objekten dieses Typs zuweisen kann -> Menge von Operationen, die man auf Objekten dieses Typs durchführen kann (was, aber nicht wie) dazu wird ein ADT-Modul in zwei Komponenten zerlegt -> Definitionsteil (export) -> Schnittstelleninformationen -> Interface - Prozedurköpfe - Typname (linke Seite der Typvereinbarung) -> Implementierungsteil - Prozedurkörper - Datenstruktur (rechte Seite der Typvereinbarung) von außen sichtbar von außen unsichtbar räumliche Trennung von Prozedurkopf/-körper bzw. linke/rechte Seite einer Typvereinbarung monika.heiner@informatik.tu-cottbus.de SS / 16

7 3. IDEE: I : D : DATENKAPSEL ADT GraphT Interface export proc firstnode(..); export proc nextnode(..); export proc neighbours(..);... module EulerMain import GraphT; proc euler(..) Implementation export proc firstnode(..) export proc nextnode(..) export proc neighbours(..) proc createkoenigsberg(..)... GraphT graph = [][] integer procedure odd(...) monika.heiner@informatik.tu-cottbus.de SS / IDEE, I, WERTUNG W - V - VORTEILE weitere Modularisierung -> Programm = drei Module Die Implementierung des ADT (Implementations-Module) kann ausgewechselt werden, ohne daß die darauf aufbauenden Algorithmen (Applikations-Module) angepaßt werden müssen. Die Implementierungs-/Validierungsmühen, die man bei der Realisierung der Module investiert hat, können auch von anderen Algorithmen (derselben Problemklasse) nachgenutzt werden. Nach Festlegen der Schnittstelle können die ADT-Implementierungen und Applikations-Algorithmen unabhängig voneinander, z.b. -> parallel, -> räumlich verteilt, bearbeitet werden. monika.heiner@informatik.tu-cottbus.de SS / 16

8 ZUSAMMENFASSUNG DES VORGEHENS Algorithmus 1 Algorithmus 2 Algorithmus 3 2. Applikations- Module ADT.DEF 1. Interface- Module Impl.1 Impl.2 Impl.3 3. Implementations- Module (# (# GEBEN REIHENFOLGE AN) monika.heiner@informatik.tu-cottbus.de SS / IDEE, I, WERTUNG W - N - NACHTEILE Ein solcher Programmierstil ist zunächst aufwendiger! Er lohnt sich dann, wenn -> größere Projekte (mit einer erwarteten längeren Lebensdauer) -> arbeitsteilig -> über einen längeren Zeitraum entwickelt werden. Compileroptimierung Programmlaufzeit monika.heiner@informatik.tu-cottbus.de SS / 16