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

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

Ü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

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

Modulare Software Motivation: 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

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

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

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

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

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

„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

„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

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

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