David Lorge Parnas and Paul C

Präsentation zum Thema: "David Lorge Parnas and Paul C"—  Präsentation transkript:

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

2 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

3 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?

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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#)

17 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

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

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