David Lorge Parnas and Paul C. Clements

A Rational Design Process:How and Why to Fake It

Der ideale Design-Prozess

• Studien: Design subjektivnicht Top-Downeher 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 irrationalgewünschtes Verhaltens unklarBeschrä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äuschenEntwicklung 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 entwickelnkeine Implementationsdetailsfehlende Information explizit kennzeichnenReferenz-Dokument, keine Erzählung

Requirements Document II

• Autor: ideal User, real Entwickler (Entwurf)• mathematisches Modell : hybrider Computer

analog: kontinuierlicher Input kont. Outputdigital: 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 EffekteZeit- und Genauigkeitsanforderungenunerwü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 Fertigstellungfail-soft-SystemeProgrammfamilien

• 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.