David Lorge Parnas and Paul C David Lorge Parnas and Paul C. Clements A Rational Design Process: How and Why to Fake It

Der ideale Design-Prozess Studien: Design subjektiv nicht Top-Down eher zufällig Gesucht: Design-Prozess als systematische Ableitung  rationaler Design-Prozess Parnas/Clements: nicht real umsetzbar, aber Dokumentation des idealen Prozesses möglich „Fake“: Dokumentation so, als ob sie aus dem idealen Prozess entstanden wäre

Schritte zum rationalen Design-Prozess Warum ein rationaler Design-Prozess? Was ist ein rationaler Design-Prozess? Welche Phasen hat der Design-Prozess, und welche Dokumente entstehen dabei? Warum einen idealen Prozess vortäuschen?

Warum ein rationaler Design-Prozess? SW-Design irrational gewünschtes Verhaltens unklar Beschränkungen für die Implementation unklar Design-Entscheidungen ohne Begründung Gewünscht: Ableitung aus Anforderungen wie Theoreme aus Axiomen (Beweis)  Top-Down-Methoden rationalen Design-Prozess vortäuschen Entwicklung und Wartung leichter

Idealisierter Design-Prozess SW-Projekte nie auf rationale Art: Auftraggeber weiß nicht genau, was er will und kann nicht alles mitteilen. Details werden erst während der Entwicklung klar. Einteilung von Aufgabenbereichen „Human errors can only be avoided if one can avoid the use of humans.“  immer Fehler Design belastet mit früheren Ideen Wiederverwendung anderer Projekte

Nutzen des rationalen Design-Prozesses kein reales System rational entwickelt Design-Methoden: Design logisch vollziehen realer Prozess so nah wie möglich am idealen Prozess  „fake a rational design process“ Reihenfolge: idealer Prozess sagt, womit man beginnen soll besser als ad-hoc: Wissenslücken identifizieren Standard-Prozedur: Austausch möglich Messen von Fortschritt, Review einfacher

Der rationale Design-Prozess für jede Phase: Welches Produkt soll entstehen? Kriterien, Beteiligte, Referenzinformationen Anforderungen: Requirements Document Architektur: Module Guide Schnittstellen: Module Interface Specification Hierarchie: Uses Hierarchy Interne Struktur: Module Design Document Implementation Wartung und Pflege

Requirements Document I vom User gewünschtes Verhalten (Review) alle Entscheidungen über Anforderungen hier Konsistenz: Fragen der Designer, Programmierer und Reviewer beantworten Aufwandsabschätzung schwierigster Teil: gesuchte Information finden soll genau das enthalten, was nötig ist, um für User akzeptable SW zu entwickeln keine Implementationsdetails fehlende Information explizit kennzeichnen Referenz-Dokument, keine Erzählung

Requirements Document II Autor: ideal User, real Entwickler (Entwurf) mathematisches Modell : hybrider Computer analog: kontinuierlicher Input  kont. Output digital: diskrete Änderung des Output Hauptteil des Requirement Document: mathematische Funktionen (Output als Funktion externer Zustandsvariablen Organisation des Requirement Document: Zielrechner, I/O-Schnittstellen, Ausgabe, Zeit- und Genauigkeitsanforderungen, Änderungswahrscheinlichkeit, Fehlerfall

Module Guide Aufgaben: Design-Entscheidungen für jedes Modul Submodule: Guide für Substruktur Anzahl der Module: Baum-Struktur, am Ende kleine Module enthält gesamtes Design: besonders für Wartung

Module Interface Specification unabhängige Implementation: module interface specification „black box“: andere können die Funktionen des Moduls nutzen, mehr nicht Autor: Designer, Review durch Programmierer Inhalt: rufbare Funktionen – „access programs“ Parameter und äußere Effekte Zeit- und Genauigkeitsanforderungen unerwünschte Ereignisse

Uses Hierarchy Module und access programs: Abhängigkeit binäre Matrix: Position (A, B) true gdw. Programm A nur dann korrekt, wenn korrektes Programm B im System existiert Mengen von Modulen, die ohne andere Module funktionsfähig sind stückweise Fertigstellung fail-soft-Systeme Programmfamilien Autor: Designer

Module Design Document Hauptanliegen des Moduls beschreiben effizientes Review vor der Implementation beschreibt Submodule oder interne Datenstruktur und Auswirkung der Funktionen darauf unerwünschte Ereignisse Verifikation: Programm mit diesen Eigenschaften erfüllt Module Specification falls keine lesbare Hochsprache verwendet wird, zusätzlich Pseudocode-Notation

Implementation und Pflege Anforderungen: Requirements Document Architektur: Module Guide Schnittstellen: Module Interface Specification Hierarchie: Uses Hierarchy Interne Struktur: Module Design Document  Code erstellen, schnell und flüssig keine redundanten Kommentare (Gefahr der Inkonsistenz) Pflege ist Redesign: Prinzipen beibehalten, Änderungen in allen betroffenen Dokumenten

Bedeutung der Dokumentation meist: schwer zu verwenden, nicht gelesen notwendiges Übel, wegen Bürokratie hinterher dazu Stil: „stream of consciousness“, „stream of execution“  Information nicht auffindbar langweilige Erzählung: viele Worte statt einer Anweisung, Formel oder Grafik Terminologie konfus und inkosistent falscher Inhalt: gut Vertraute dokumentieren Details

Ideale Dokumentation Bedürfnisse aller Beteiligten (vom Projektbeginn bis zur Wartung) Referenz-Dokumente (Reifung) für jedes Detail genau eine Stelle in der Dokumentation erst Struktur der Dokumente, dann Inhalt erstellen typisierte Terminologie (!+Variable+!, %Wert%, #Funktion#)

Faking the Ideal Process Dokumente so erstellen, wie man sie erstellt hätte, wenn der Entwicklungsprozess ideal verlaufen wäre keine Design-Entscheidung ohne Dokumentation egal, wie oft man in Sackgassen landet, endgültige Dokumentation ist genau und rational dokumentiert nicht reale Entstehung, aber der Leser will auch das Programm verstehen, nicht die Entwicklung nachvollziehen wenn Dokumentation vernünftig, ist sie lebenslang verwendbar und nützlich, und wenn sie lange verwendet wird, sollte sie gut sein

Schlussfolgerung (Parnas und Clements) Es ist schwer, ein rationaler Designer zu sein, auch das Vortäuschen ist nicht leicht. Aber es entsteht ein Ergebnis, das verstanden, gewartet und wiederverwendet werden kann. Wenn das Projekt es wert ist, durchgeführt zu werden, sind auch die beschriebenen Methoden es wert, angewandt zu werden.

Diskussion Die von Parnas und Clements entwickelte Vorgehensweise ist eigentlich nur ein Wasserfallmodell. Der rationale Design-Prozess hat keinen Nutzen, weil jeder Entwickler ihn wieder subjektiv interpretiert. Er bedeutet nur zusätzlichen Aufwand, der sich nicht lohnt.