David L. Parnas: Designing Software for Ease of Extension and Contraction Willkommen zum Vortrag

1. David L. Parnas: Designing Software for Ease of Extension and Contraction Willkommen zum Vortrag Achim Klein

2. Agenda • Überblick • Probleme • Modulare Software • Hindernisse • Lösungsansätze • Anforderungsanalyse • Interfaces und Module • Virtual Machine Ansatz • „uses“ Hierarchie

3. Überblick Problem: • Software schwer zu warten • Leicht änderbare Software schaffen Lösungsversuche: • Modulgrößen-, Kodier-, Dokumentationsstandards David Parnas‘ Ansatz: • Anforderungen müssen erwartete, zukünftige Veränderungen berücksichtigen  flexiblere Software designen • Änderungsanfällige Teile separieren • Konzept hilft Software Architektur zu organisieren

4. Probleme • Eingeschränktes Pre-Release erstellen  ein Subsystem funktioniert erst, wenn das gesamte System funktioniert • Eine einfache Funktion hinzufügen  erfordert das Verändern großer Teile des Codes • Features entfernen  erfordert das Verändern großer Teile des Codes

5. Modulare Software ganze Familie von Programmen / Modulen Motivation: • Gemeinsamkeiten nutzen, Wartungskosten reduzieren Unterschiede bei Familien von Programmen: • Läuft auf verschiedener Hardware • Unterschiedliche Ein- / Ausgabeformate • Unterschiedliche Datenstrukturen oder Algorithmen • Schmalere Version einer Software Flexibles Design: z.B. generisches Theorem statt mehrere spezielle  Erwartete Veränderungen beim Produktentwurf berücksichtigen

6. Hindernisse 1. Zu starke Informationsverteilung • Teile des Codes gehen von Vorhandensein eines gewissen Features aus 2. Kette von Daten transformierenden Komponenten • Eine Komponente ist schwer entfernbar, da Nachfolgekomponente eine spezifische Eingabe erwartet, die Vorgänger nicht liefert 3. Komponenten, die mehr als eine Funktion implementieren • Eine einzelne der Funktionen ist nicht separat ausführbar 4. Schleifen in der „uses“ Relation • Code wird wiederverwendet, d.h. von mehreren Komponenten genutzt • Problem (bei Schleifen): System funktioniert erst, wenn alles funktioniert

7. Ansätze Schritte hin zu einer leichter veränderbaren Software Architektur: • Anforderungsdefinition: Subkomponenten identifizieren • Information Hiding: Interface und Modul Definitionen • Das Virtual Machine Konzept • Die „uses“ Hierarchie

8. Anforderungen • Identifizierung der Subkomponenten als Teil der Anforderungsanalyse • Frage wird vom zukünftigen Nutzer nicht hinreichend beantwortet Vorgehen: • Minimale Teilmenge suchen • Dann minimale inkrementelle Erweiterungen Vorteile: • Komponenten vermeiden, die mehr als eine Funktion implementieren  Maximale Flexibilität

9. Interfaces und Module • Veränderliche Teile in Module kapseln • Zwischen den Modulen: stabile Schnittstellen, die unanfällig für erwartete Änderungen sind Eigenschaften: • Module ohne leicht erkennbare physikalische Identität • Schnittstelle ist generisch, das implementierende Modul ist es nicht Realisierung: • Konzepte: information hiding, Kapselung, Abstraktion • (Nicht-) Vorhandensein einer Komponente vor anderen verbergen  diese Informationen in Modulen mit abstrakten Schnittstellen kapseln

10. Virtual Machine Konzept • Probleme der Kette Daten transformierender Komponenten vermeiden Vorgehen: • Ausgangspunkt: Hardwareinstruktionen • Virtual Machine baut darauf auf und stellt Softwareinstruktionen (Features) bereit • VM Instruktionen sind generisch nutzbar • Wenn Instruktionen nicht benötigt, einfach weglassbar • Schrittweise Erweiterung: Hierarchie von Virtual Machines • Ressourcen einer Machine werden vollständig gekapselt  Vermeidung von Komplikationen Vorteile: • Ein großes Problem in mehrere kleine zerlegen  Jede VM ist sinn- und nutzvolles Subsystem

11. „uses“ Relation • System in Komponenten aufteilen • Jede Komponente braucht Spezifikation, welchen Effekt eine Ausführung hat Programm A „uses“ B: korrekte Ausführung von B ist notwendig, damit A gemäß Spezifikation ausgeführt werden kann Unterschied „uses“ und „invokes“: • Wenn Spezifikation von A erfordert, dass B aufgerufen wird, ist A korrekt unabhängig davon, ob B korrekt ist • Programm A kann „uses“ Beziehung zu B haben, ohne dass es B aufruft Vorteil: • Modularisierung, Wiederverwendung, Vereinfachung auf höherer Schicht Nachteil: • Bei zu starker „uses“ Nutzung: Teile des Systems stark voneinander abhängig

12. „uses“ Hierarchie • Einsatz der „uses“ Relation beschränken, so dass ihr Graph schleifenfrei ist  Vorteile von „uses“ nutzen ohne die Probleme „uses“ Schichtenhierarchie: • Unterste Schicht: nutzt kein anderes Programm • Jede Schicht darüber nutzt jeweils nur Programme der direkt darunter liegenden Schicht Vorteile: • Jede Schicht bietet testbare und nutzbare Teilmenge • Einfache Verfügbarkeit von Teilmengen erlaubt Entwicklung einer breiten Familie von Systemen  „uses“ Hierarchie ist großer Design-Meilenstein

13. Kriterien für „uses“ Bedingungen für A „uses“ B: A ist wesentlich einfacher, da es B benutzt • B ist wesentlich komplexer, da A es nicht nutzen darf • Es gibt eine nutzvolle Teilmenge, die B – und nicht A enthält • Es gibt keine nutzvolle Teilmenge, die A – aber nicht B enthält Problemfall: • Wenn 2 Programme sich gegenseitig nutzen wollen: Sandwichlösung A nutzt B2 und B1 nutzt A

14. Referenzen • David L. Parnas: “Designing Software for Ease of Extension and Contraction” aus Software Fundamentals: Collected Papers by David Parnas, Addison Wesley Professional • http://www.informatik.hu-berlin.de/~klein/softwarearchitektur