Programmierung im Grossen

Transkript

1 1 Letzte Aktualisierung: 16. April 2004 Programmierung im Grossen Bertrand Meyer

2 2 Vorlesung 2: Modularität, Wiederverwendbarkeit

3 Programm für heute 3 Software Qualität Modularität Wiederverwendbarkeit

4 Software Qualität 4 Externe Faktoren: für Kunden sichtbar (nicht nur der Endbenutyer, zb auch Käufer) Beispiele: leichte Benutzbarkeit, Erweiterbarkeit Interne Faktoren: nur von Entwicklern wahrnehmbar Beispiele: guter Programmier-Stil, Information Hiding Letztendlich zählen nur die externen Faktoren, aber die internen ermöglichen erst deren Erreichung.

5 Externe Qualitäts-Faktoren 5 KORREKTHEIT ROBUSTHEIT INTEGRITÄT SPEZIFIKATION FEHLER FEINDLICHE VERWENDUNG LEICHTE BENUTZBARKEIT WIEDERVERWENDBARKEIT ERWEITERBARKEIT PORTABILITÄT EFFIZIENZ Korrektheit Robustheit Integrität Korrektheit: Die Fähigkeit eines Software Systems, entsprechend der Spezifikation zu arbeiten, in durch die Spezifikation definierten Fällen. Robustheit: Die Fähigkeit eines Software Systems, sich in Fällen, die nicht von der Spezifikation abgedeckt werden, angemessen zu verhalten.

6 Zuverlässigkeit 6 Korrektheit + Robustheit Techniken werden genau diskutiert werden: Typisierung, Design by Contract,

7 Modularität 7 Wiederverwendbarkeit + Erweiterbarkeit Begünstigt durch architektonische Techniken, die zur Sicherstellung dezentralisierter Module tendieren

8 Modularität 8 Einige Prinzipien von Modularität: Zerlegbarkeit Zusammensetzbarkeit Kontinuität Information Hiding (manchmal Geheimnisprinzip ) Das Offen-Geschlossen Prinzip Das Einzige Auswahl Prinzip

9 Zerlegbarkeit 9 Diese Methode hilft komplexe Probleme in Teil-Probleme zu zerlegen. Folgerung: Aufspaltung der Arbeit. Beispiel: Top-down Design-Methode (folgt). Gegenbeispiel: Allgemeines Initialisierungs- Modul.

10 Top-down funktionales Design 10 Oberste funktionale Abstraktion A Sequenz B D C Schleife Bedingung C1 I I1 C2 I2

11 Top-down Design 11 Siehe Niklaus Wirth, Program Construction by Stepwise Refinement, Communications of the ACM, 14, 4, (April 1971), p

12 Zusammensetzbarkeit 12 Diese Methode bevorzugt die Erzeugung von Software-Elementen die frei untereinander zusammengesetzt werden können, um neue Software zu erzeugen. Beispiel: Unix Shell Konventionen Programm1 Programm2 Programm3

13 Direktes Abbilden 13 Diese Methode ergibt ein Software-System dessen modulare Struktur kompatibel bleibt mit irgendeiner modularen Struktur, die beim modellieren der Problem-Domäne erdacht wird.

14 Prinzip der wenigen Schnittstellen 14 Jedes Modul redet mit so wenigen anderen Modulen wie möglich. (A) (B) (C)

15 Prinzip der kleinen Schnittstellen 15 Wenn zwei Module kommunizieren, tauschen sie so wenig Information aus wie möglich. x, y z

16 Prinzip der expliziten Schnittstellen 16 Wenn zwei Module A und B kommunizieren, ist das aus dem Text von A oder B oder von beiden offensichtlich. Modul A Modul B Modifiziert Daten x Liest

17 Kontinuität 17 Diese Methode stellt sicher, dass kleine Änderungen an der Spezifikation auch kleine Änderungen an der Architektur ergeben. Design Methode: Spezifikation Architektur Beispiel: Prinzip des einheitlichen Zugriffs (folgt) Gegenbeispiel: Programme mit Mustern nach der physikalischen Implementierung der Datenstrukturen.

18 Prinzip des einheitlichen Zugriffs 18 Funktionen die von einem Modul verwaltet werden sind für Kunden in der selben Weise zugreifbar, egal ob sie mit Berechnung oder Speicherung implementiert sind. Definition: Ein Kunde eines Moduls ist irgendein Modul, dass seine Funktionen benutzt.

19 Einheitlicher Zugriff: Beispiel 19 balance = list_of_deposits.total list_of_withdrawals.total list_of_deposits (A1) list_of_withdrawals balance (A2) list_of_deposits list_of_withdrawals Ada, Pascal, C/C++, Java, C#: a.balance balance (a) a.balance() Simula, Eiffel: a.balance

20 Information Hiding 20 Zugrundeliegende Frage: Wie bewirbt man die Möglichkeiten eines Moduls? Jedes Modul sollte der externen Welt durch eine offizielle, öffentliche, public Schnittstelle bekannt sein. Die restlichen Eigenschaften des Moduls sind seine Geheimnisse. Es soll unmöglich sein auf die Geheimnisse von aussen zuzugreifen.

21 Das Information Hiding Prinzip 21 Der Designer jedes Moduls muss eine Teilmenge der Eigenschaften des Moduls als offizielle Information über das Modul auswählen. Diese Teilmenge wird den Entwicklern von Kunden-Modulen zur Verfügung gestellt.

22 Information Hiding 22 Öffentlicher Teil Geheimer Teil

23 Information Hiding 23 Begründungen: Kontinuität Zerlegbarkeit

24 Das Offen-Geschlossen Prinzip 24 Module sollen Offen und Geschlossen sein. Definitionen: Offenes Modul: Kann erweitert werden. Geschlossenes Modul: Für Kunden verwendbar. Kann freigegeben, als Grundlinie (baseline) verwendet und (falls eine Programmeinheit) kompiliert werden. Die Begründungen ergänzen sich: Ein Modul zu schliessen (Manager-Perspektive): Kunden benötigen es jetzt. Ein Modul offen zu lassen (Entwickler-Perspektive): Man übersieht oft Aspekte des Problems.

25 Ein Objekt hat eine Schnittstelle 25 start forth item index put_right before after

26 Ein Objekt hat eine Implementierung 26 start forth item index put_right before after

27 Information Hiding 27 start forth item index put_right before after

28 Das Offen-Geschlossen Prinzip 28 B A C E D F A H I G

29 Zu frühes schliessen eines Moduls 29 type PUBLICATION = record author, title: STRING; publication_year: INTEGER case pubtype: (book, journal, conference) of book: (publisher: STRING); journal: (editor: STRING); conference: (place, chair: STRING) end end Verwendung in Kunden: p: PUBLICATION ; case p.pubtype of book:... p.publisher...; journal:... p.editor...; conference:... p.place... end

30 Das Einzige Auswahl Prinzip 30 Immer wenn ein Software-System eine Menge von Alternativen unterstützen muss gibt es genau ein Modul im System, dass die komplette Liste kennt. Editor: Menge von Kommandos (Einfügen, Löschen, etc.) Graphik-System: Menge von Formen (Rechteck, Kreis, etc.) Kompiler: Menge von Sprach-Konstrukten (Anweisung, Schleife, Ausdruck, etc.)

31 Wiederverwendbarkeits-Probleme 31 Organisations- und Management-Probleme: (Werden hier nicht behandelt.) Technische Probleme: Welche Form von Komponenten? Prozedur-Bibliotheken Packete (Ada) Klassen-Bibliotheken Welche Form von Klassen?

32 Wiederverwendbarkeit: Techn. Probleme 32 Allgemeines Muster für eine Such-Routine: has (t: TABLE; x: ELEMENT): BOOLEAN is -- Erscheint Element x in der Tabelle t? local pos: POSITION do from pos := initial_position (t) until exhausted (t, pos) or else found (t, x, pos) loop pos := next (t, pos) end Result := found (t, x, pos) end

33 Probleme eines allgemeinen Such-Moduls 33 Typ-Varianten: Was sind die Tabellen-Elemente? Routinen-Groupierung: Eine Such-Routine ist nicht genug: sie sollte mit Routinen für die Tablellen-Erzeugung, das Einfügen und Löschen, etc. kombiniert sein. Implementierungs-Varianten: Viele mögliche Alternativen für die Datenstrukturen und Algorithmen: sequentielle Tabelle (sortiert oder unsortiert), Array, binärer Such-Baum, Dateien,...

34 Probleme (fortgesetzt) 34 Repräsentations-Unabhängigkeit: Kann ein Kunde Operationen verwenden, wie zb Tabellen-Suche (has), ohne zu wissen welche Implementierung intern verwendet wird? has (t1, y)

35 Probleme (fortgesetzt) 35 Ausgliedern von Gemeinsamkeiten: Wie kann der Autor von Zuliefer-Modulen die Gemeinsamkeiten von Teilen der möglichen Implementierungen positiv ausnutzen? Beispiel: Die Menge an sequentiellen Tabellen- Implementierungen. Gemeinsamer Routinen-Text für has: has (...; x: T): BOOLEAN is -- Erscheint x in der Tabelle? do from start until after or else found (x) loop forth end Result := found (x) end

36 Ausgliedern von Gemeinsamkeiten 36 before item after 1 back forth count start index

37 Ausgliedern von Gemeinsamkeiten 37 TABLE has start after found forth SEQUENTIAL_ TABLE TREE_ TABLE HASH_ TABLE ARRAY_ TABLE LINKED_ TABLE FILE_ TABLE

38 Implementierungs-Varianten 38 start forth after found (x) Array i := 1 i := i + 1 i > count t [i] = x Linked list c := first_cell c := c.right c = Void c.item = x File rewind read end_of_file f = ξ

39 Kapselungs-Sprachen ( Object-based ) 39 Ada, Modula-2, CLU... Grundidee: Sammle eine Gruppe von Routinen, die einen ähnlichen Zweck dienen, zb has, insert, remove, etc., zusammen mit den entsprechenden Beschreibungen der Datenstrukturen. Das behandelt das verwandte Routinen-Problem. Vorteile: Für Zuliefer-Autoren: Alles unter einem Dach. Vereinfacht Konfigurations-Management, Veränderung der Implementierung, hinzufügen von neuen Basisfunktionen. Für Kunden-Autoren: Man findet alles an einem Platz. Vereinfacht die Suche nach existierenden Routinen und Erweiterungs-Anfragen.

40 Ergänzendes Material 40 OOSC2: Kapitel 3: Modularity Kapitel 4: Approaches to reusability

41 41 Ende Vorlesung 2