Some Software Engineering Principles

Transkript

1 David L. Parnas: Some Software Engineering Principles Marco Oppel Seminar Software-Architektur Institut für Informatik Humboldt Universität zu Berlin 1

2 Problemstellung Software Engineering Multi-Personen Programmierung Multi-Versions Programmierung Aufgabenverteilung Modifizierbarkeit Anforderungsdefinition Sinnvolle Teilprogramme Fehlerbehandlung Erweiterbarkeit 2

3 Was ist ein gut strukturierte Software? Programmstruktur: Menge von Teilen des Systems Verbindungen zwischen diesen Teilen Gute Struktur: Verbindungen enthalten sehr wenig Informationen Wozu? Beweis der Korrektheit des Systems Veränderungen am System 3

4 Korrektheitsbeweis Modul A..Anforderungen....Theoreme.. Voraussetzungen Axiome Modul B Modul C Beweis der Korrektheit des Gesamtsystems Nutze Beweise über Korrektheit der Teilsysteme 4

5 Veränderungen am System Zentrale Frage: Welche Veränderungen können an einem Teil des Systems vorgenommen werden, ohne andere Teile des Systems zu verändern? Antwort Nur Änderungen, die den Annahmen an den Softwareteil nicht widersprechen 5

6 Veränderungen am System Modul A (3) Korrektheit von Modul A kann nicht mehr bewiesen werden. (2) Axiome gelten nicht mehr...anforderungen....theoreme..? X Voraussetzungen Axiome Modul B..Anforderungen....Theoreme.. Modul C (1) Modul B wird so verändert, dass es nicht mehr den Anforderungen entspricht. 6

7 Techniken Techniken zur Erstellung Decomposition Specification 7

8 Decomposition Aufteilung des Systems in Module (hier: work assignments) Schlecht: Flussdiagramme Grobes Diagramm Anschließend Verfeinerung Problem: Viele Informationen in den Verbindungen Besser: Konstruktion von Module um Annahmen, die sich am meisten ändern werden Sich wenig ändernde Schnittstellen 8

9 Decomposition Vorteil Beschränkung von Änderungen auf ein Modul Problem: Vermittlung/Lehre Nur anhand sehr vieler Beispiele erlernbar 9

10 Specification Kontrolle über die Struktur des Systems durch Exakte Beschreibung der Annahmen über ein Modul Problem Zuwenig Beschreibung Zwangsläufig ineffiziente Programme Zuviel Beschreibung Eventuell werden Annahmen über ein Modul gemacht, die so nicht beabsichtigt wurden 10

11 Specification - Schlechte Wege Interne Struktur des Moduls beschreiben Programm wird schwerer modifizierbar, weil Teile des Systems von der internen Struktur des Moduls abhängen können Beschreibung einer hypothetischen Implementation des Moduls Programm kann eventuell nie korrekt arbeiten, wenn ein Aspekt der hypothetischen Implementation nie korrekt war Schwierig zu vermitteln, welche Teile der offengelegten Informationen nicht benutzt werden dürfen 11

12 Der richtige Weg: Information Hiding Genaue Spezifikation der nach außen sichtbaren Aspekte Keine Andeutungen über interne Strukturen Bestätigung durch Experiment KWIC-Index 1971: 20 Studenten, Spezifikation gegeben 15 funktionierende Module Test von 25 Kombinationen, alle erfolgreich Bestätigung dieses Ergebnisses durch ähnliche Experimente 12

13 Error Handling Durch Information Hiding wird die Behandlung von Laufzeitfehlern massiv erschwert Fehler werden in Datenstrukturen und Programmen ausgedrückt, die nicht in allen Teilen des Systems bekannt sind Informationen zum verstehen und behandeln des Fehlers eventuell in anderen Modulen Zerstörung des Information Hiding Prinzips durch Übermittlung des Fehlers 13

14 Error Handling Während des Entwurfs von Modulen, über mögliche Fehler nachdenken Traps einbauen In hierarchischen Software-Strukturen Ein extra Fehler-Handling Modul je Schicht Fehler nach oben/unten propagieren Fehlerbeschreibung an Abstraktionsniveau der Schicht anpassen 14

15 Error Handling Nachteil Erhöhter Aufwand beim Entwurf Vorteil Feststellen des verursachenden Moduls ohne Wissen über das Innere der Module Verbesserte Fehlersuche Verbesserte Verläßlichkeit des Systems Möglichkeit zur Verbesserung des Error Handling während der Softwareentwicklung 15

16 Hierarchische Strukturen Viel Diskussion zu der Zeit Nach Parnas der bedeutendste Ansatz: die Uses Hierarchie Programm 1 Programm 1 uses uses uses Programm 2 Programm 1 arbeitet nur dann korrekt, wenn auch Programm 2 korrekt arbeitet. Programm 2 Schlecht: Zyklen Das Gesamtsystem arbeitet erst korrekt, wenn alle Teilsysteme korrekt arbeiten. 16

17 Hierarchische Strukturen Entwurf der Uses-Hierarchie vor der Implementation (Teil-)Programmpakete leicht aus der Uses-Hierarchie erstellbar 17

18 Abstract Interfaces Design in 2 Schritten: 1.Liste mit Annahmen, die sich während des gesamten Software life cycle (wahrscheinlich) nicht ändern werden 2.Spezifikation einer Menge von Schnittstellen-Funktionen, die auf Grund dieser Annahmen garantiert implementiert werden können 18

19 Zusammenfassung Mehraufwand in den frühen Phasen der Softwareentwicklung lohnt sich Alle angesprochenen Konzepte sollten auf jeden Fall berücksichtigt werden Dekomposition in Module Präzise Spezifikation Design leicht modifizierbarer Systeme Design abstrakter Interfaces 19

20 Quellen David L. Parnas: Some Software Engineering Principles ; 1978 David L. Parnas, H. Würges: Response to Undesired Events in Software Systems ;