Freie Universität Berlin Institut für Informatik 26 August 2003 Seminar „Komponenten“ Delocalized Plans Maximilian Schmidt Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/inst/ag-se/ Modelle Experimente Methoden Tools Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik Inhalt 26 August 2003 1 Modelle und Strategien 1.1 Einführung 1.2 Begriffe 1.3 Zusammenfassung 2 Experimente 2.1 Autoren 2.2 Beispiele 2.3 Zusammenfassung 3 Methoden 3.1 Slicing 3.2 CSD 3.3 Literate Programming 3.4 Zusammenfassung 4 Tools 5 Zusammenfassung 5.1 Modelle/Strategien 5.2 Experimente 5.2 Methoden 5.3 Tools 5.4 Fazit Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik Delocalized Plans 26 August 2003 Modelle und Strategien Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

1.1 Modelle und Strategien - Einführung Freie Universität Berlin Institut für Informatik 1.1 Modelle und Strategien - Einführung 26 August 2003 Die Pflege eines Softwaresystems macht mehr als 50% des gesamten Aufwands aus. Pflege bedeutet u.a.: Erweiterung um neue Funktionen Aktualisierung von bestehenden Funktionen Modifizieren von Software erfolgt in 3 Phasen: Verstehen des bisherigen Systems Modifikation/Hinzufügen einer Funktion Verifikation der Änderungen / Funktionalitätstests Häufig treten Fehler auf, weil unter Zeitersparnis die Zusammenhänge nicht erfasst werden und intuitiv programmiert wird. Meiste Aufwand nachdem Produkt auf dem Markt (50%) - Fehlerbehebung - Nachrrüsten von Features - Aktualisieren von Funktionen Modifikationsschritte - Verstehen- suchen der zu ändernden Features - Verändern - selten von gleicher Person durchgeführt, die Author - ist keine langfristige Beschäftigung, daher flüchtig durchgeführt - kann zu unschönen Konstrukten führen, wenn Problem zu komplex - Tests - wenn keine automatischen Tests, dann nur Standard-Szenario, kein Abdecken aller Faktoren Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

1.2 Modelle und Strategien - Begriffe Freie Universität Berlin Institut für Informatik 1.2 Modelle und Strategien - Begriffe 26 August 2003 ´Delocalized plans´ beschreiben eine Funktionalität innerhalb eines Softwaresystems, die über mehrere logische Einheiten (Funktionen/Module/etc.) verstreut implementiert ist. Warum sind ´delocalized plans´ ein Problem? Wird eine bestimmte Operation geändert, können durch Funktionen, die auf ´delocalized plans´ beruhen, Nebeneffekte (side-effects) auftreten, welche die Stabilität des gesamten Systems gefährden können. Es ist oft schwer zu erfassen, welche übergreifenden Zusammenhänge zwischen den verteilten Funktionen bestehen. Dadurch zieht sich das Verstehen in die Länge, was bei umfangreichen Systemen nicht nur ineffizient, sondern auch nervenaufreibend sein kann. - sind Features, physikalisch auf mehrere Funktionen verteilt - wird andere Funktion geändert und Plan ist nicht bewusst, mögliche Fehlerquelle - wird Plan erkannt, schwierig Einzelteile auszumachen/ Zusammenhänge zu finden. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

1.2 Modelle und Strategien - Begriffe Freie Universität Berlin Institut für Informatik 1.2 Modelle und Strategien - Begriffe 26 August 2003 Plan (eng. „plan“): beschreibt eine kleine Funktionseinheit, welche nicht durch ein Muster, sondern durch eine Tätigkeit bzw. eine Idee umschrieben wird z.B. „Rekursion auf binärem Baum“, nicht „Rekursion auf einem binären Baum mittels eines Iterators auf Basis einer verketteten Liste“ Ziel (eng. „goal“): beschreibt eine abstrakte Funktionalität, die auf mehreren Plänen beruht z.B. „Sortieren einer Liste von Zahlen“ – auf welcher Datenstruktur bzw. mit welchem Algorithmus wird nicht betrachtet Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

1.2 Modelle und Strategien - Begriffe Freie Universität Berlin Institut für Informatik 1.2 Modelle und Strategien - Begriffe 26 August 2003 untergeordnetes Ziel/Subgoal: Ein Plan besteht aus mehreren untergeordneten Zielen, welche meist direkt in Quelltext ausdrückbar sind. Beispiel Mergesort: Goal: „Sortieren einer Liste von Zahlen“ Plan 1: „Rekursion auf binärem Baum“ Subgoal 1: „Suche Wurzel-Element“ Subgoal 2: „Vergleiche Wurzel-Element mit rechtem Knoten“ …. Plan 2: „Folge von Zahlen in 2 Teilfolgen aufteilen“ Plan 3: „2 Zahlen aufsteigend sortieren“ Plan 4: „Zusammensetzen von sortierten Teilfolgen“ Begriffe sehr abstrakt. Ungefähr vorstellbar aber auch variabel einsetzbar. Wesentliche Aufgabe bei Verstehen: Features zu finden, Features -> mehrere Goals, Goals -> Plans Existenz von Knowledge-Base basierten Programmen, die Code nach Plans durchsuchen z.B. Iteration über Liste mit Tauschen zweier Werte = Sortieren Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

1.2 Modelle und Strategien - Begriffe Freie Universität Berlin Institut für Informatik 1.2 Modelle und Strategien - Begriffe 26 August 2003 Kontext erfassen und Arbeitsumfeld suchen mit ´macro-strategies´: ´as-needed´/zweckmässiges Vorgehen: Inspiziere nur Teile, die konkret mit der Aufgabe zu tun haben. ´systematic´/systematisches Vorgehen Studiere den kompletten Quelltext um umfassendes Verständnis zu erhalten. Aufgaben strukturieren, wenn Kontext erfasst mit ´micro – strategies´: Schrittweise Planung der Modifikation Für uns hier nicht relevant, da Kontexterfassung wesentlich. makro: - As needed notwendig bei grösseren Projekten - systematisch = top-down, as-needed = bottom-up micro: - Erstellung eins Plans für Vorgehensweise bei Modifikation relevant, laut Experiment - Systematischer Ansatz gute Ergebnisse, jedoch nur bei kleineren Test Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

1.3 Modelle und Strategien - Zusammenfassung Freie Universität Berlin Institut für Informatik 1.3 Modelle und Strategien - Zusammenfassung 26 August 2003 Plans könen sich überschneiden: 1. Sortiere Teilliste und 2. verknüpfe Teillisten, z.B. durch einsortieren einer Teilliste in andere Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik Delocalized Plans 26 August 2003 Experimente Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 2.1 Experimente - Autoren 26 August 2003 Letovsky chief executive officer at Letovsky Associates specializing in the design of biological information systems and analytical software Ph.D in Computer Science (AI) works on Brain Image databases and the Human Genome Project database Soloway: University of Michigan Charles F. Thurnau Professor in College of Engineering, School of Education, and School of Information founder of GoKnow, an educational software development company Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

2.2 Experimente – Beispiele Freie Universität Berlin Institut für Informatik 2.2 Experimente – Beispiele 26 August 2003 Experimentelle Tests – Grundlagen: Objekt: „personal database“ (PDB) Dokumentation: ausführlich und vielfältig Versuchspersonen: 6 professionelle Programmierer Aufgabe: Methode RESTORE zum Wiederherstellen eines gelöschten Eintrags (durch DELETE) implementieren Analysetechnik: Lautsprechen („think aloud protocol“) - Tests von Letovsky/Soloway - PDB mit 300LOC, 15 Funktionen (INSERT,DELETE,SEARCH) - Fortran - Dokumentation mit Flussdiagrammen/Programmtrace - 3 von 6 Programmierern erfolgreich Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

2.2 Experimente – Beispiel I Freie Universität Berlin Institut für Informatik 2.2 Experimente – Beispiel I 26 August 2003 Bei Erstellen der RESTORE Routine musste DELETE inspiziert werden. Fehler traten beim Verständnis bzgl. der Variable NCHNGE auf: In der Dokumentation wurde NCHNGE wie folgt beschrieben: Aufgrund der Annahme, dass eine Wiederherstellung eine Änderung darstellt, wurde diese Zeile in RESTORE übernommen. NCHNGE = NCHNGE + 1 NCHNGE: contains the number of changes to the database made during the current session Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

2.2 Experimente – Beispiel I Freie Universität Berlin Institut für Informatik 2.2 Experimente – Beispiel I 26 August 2003 Aber: Annahme falsch! Zähler NCHNGE zählt Zugriffe, um (in Hauptroutine) zu entscheiden, ob Datenbank geschrieben werden soll: Der Fehler trat auf, weil die Versuchsperson diese bedingte Anweisung für NCHNGE nicht gelesen hat, da der Plan zur Verwaltung der Änderungen nicht lokal implementiert wurde. Verbesserung der Dokumentation mit Rollenbeschreibung und Ziel nach Letovsky/Soloway: IF (NCHNGE .NE .0) CALL PUTDB(…) Variablen - Rolle: Inhaltliche Beschreibung (enthält/speichert was) Ziel: Verwendungszweck, semantische Beschreibung Zusammenhang NCHNGE: Role: contains the number of changes to the database so far Goal: used to test whether database file needs to be updated at the end of a session Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

2.2 Experimente – Beispiel II Freie Universität Berlin Institut für Informatik 2.2 Experimente – Beispiel II 26 August 2003 Code: C PDB Main Program . . . C Command loop: Perform DB commands 10 C Loop body: Perform command on a record C Find pointer to current record for this iteration using NAME C Reuse pointer to previous record if still correct 20 IF (NAME.EQ.OLDNAM) THEN 21 IREC = OLDREC 22 GOTO 100 C Else, search database for record C End of search, now have pointer in IREC 100 OLDREC = IREC 101 OLDNAM = NAME 102 GOTO 10 - Löschen erfolgte nicht wirklich durch Löschen, nur durch passiv setzen - Restore über Suchfunktion nach passiv gesetztem Eintrag In Search Konstrukt siehe Folie (Variablenbeschreibung) - Zeile 21 keinen Effekt, da IREC immer gleich OLDREC. - Damit auch OLDNAM redundant, da über IREC erreichbar. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

2.2 Experimente – Beispiel II Freie Universität Berlin Institut für Informatik 2.2 Experimente – Beispiel II 26 August 2003 Code: C PDB Main Program . . . C Command loop: Perform DB commands 10 C Loop body: Perform command on a record C Find pointer to current record for this iteration using NAME C Reuse pointer to previous record if still correct 20 IF (NAME.EQ.DBASE(IREC,1)) 21 THEN GOTO 100 C Else, search database for record C End of search, now have pointer in IREC 100 GOTO 10 Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

2.2 Experimente – Beispiel III Freie Universität Berlin Institut für Informatik 2.2 Experimente – Beispiel III 26 August 2003 MAXREC = # maximale Einträge NRECS = # bisherige Einträge IREC = aktueller Eintrag Wo liegt der Fehler? SUBROUTINE getdb(…) C Read the database into the array . . . 10 READ(13,20,END = 100) DBASE(IREC) IREC = IREC + 1 IF (IREC.LT.MAXREC) GOTO 10 WRITE(6,*) „Database full“ IERR = 1 RETURN 100 . . . END SUBROUTINE create(….) C Create a new record in the database IF (NRECS.EQ.MAXREC) THEN WRITE(6,*) „Database full.“ C Else, really create record NRECS = NRECS + 1; Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

2.2 Experimente – Beispiel III Freie Universität Berlin Institut für Informatik 2.2 Experimente – Beispiel III 26 August 2003 MAXREC = # maximale Einträge NRECS = # bisherige Einträge IREC = aktueller Eintrag Wo liegt der Fehler? Genau! Der Schutz vor Überlauf in getdb(…) ist überflüssig, da schon in create(…) vorhanden SUBROUTINE getdb(…) C Read the database into the array . . . 10 READ(13,20,END = 100) DBASE(IREC) IREC = IREC + 1 IF (IREC.LT.MAXREC) GOTO 10 WRITE(6,*) „Database full“ IERR = 1 RETURN 100 . . . END SUBROUTINE create(….) C Create a new record in the database IF (NRECS.EQ.MAXREC) THEN WRITE(6,*) „Database full.“ C Else, really create record NRECS = NRECS + 1; Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

2.3 Experimente - Zusammenfassung Freie Universität Berlin Institut für Informatik 2.3 Experimente - Zusammenfassung 26 August 2003 Bei einer falschen Interpretation von Variablen können Missverständnisse entstehen, die mehr oder weniger ernste Folgen haben: Redundanz Performanceverlust Schwerwiegendere Fehler sind jedoch wortwörtlich vorprogrammiert – im letzten Fall ist selbst dem Autor des Programmes die Redundanz nicht aufgefallen Der Quelltext verrät nur, WIE ein Konstrukt verwendet wird, nicht WARUM. Das Verstehen durch intuitive Ansätze funktioniert nur, solange der Autor eines Programmes die gleiche Intention mit einem Bezeichner verknüpft hat. Abhilfe schafft ein Dokumentation, welche die Intention festhält, z.B. durch Ziel- oder Rollenzuordnung. Bei Modifikation müssen Zusammenhänge erneuert werden (Umbenennen von Variablen) z.B. Variable OLDREC redundant, also stehenlassen und in anderem Kontext verwenden Dadurch intuitive Herangehensweise nicht möglich. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik Delocalized Plans 26 August 2003 Methoden Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 3.1 Methoden - CSD 26 August 2003 CSD = control structure diagram: Betrachtung des Quelltextes in einem Baum. Abzweigungen u.a. bei Paketen/Klassen/Methoden/ Schleifen/Ausnahmen/etc. Der Programmierer hat die Möglichkeit den Code auf verschiedenen Ebenen der Abstraktion zu betrachten und gleichzeitig zu editieren ohne zu einer anderen Sichtweise (grafisch/textuell) wechseln zu müssen. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 3.1 Methoden - CSD 26 August 2003 Beispiel: Hummer.java (ALP IV) mit jGrasp (siehe Tools) Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 3.1 Methoden - CSD 26 August 2003 Optimiertes Beispiel mit goals/plans Könnte eine Dokumentation im Sinne der Konstrukte Goals->Plans->Subgoals gewährleisten. Wird in vielen IDEs aber nur ansatzweise integriert. UML/JavaDoc haben ähnlichen Ansatz, jedoch perspektivisch nicht gleichzeitig verwendbar. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 3.2 Methoden - Slicing 26 August 2003 (Program)-´Slicing´ = Zuordnung von Programmteilen Über ´Slicing´ kann man sich alle zugehörigen Referenzen zu einem Konstrukt aufzeigen lassen und somit die delokalisierten Teilstücke auf einem Fleck zusammenfassen, ohne durch nicht zugehörige Codestücke abgelenkt zu werden. Für OO-Sprachen wird dynamisches ´Slicing´ verwendet, um Laufzeitbindungen von Objekten zu erhalten. Einfaches Beispiel: Alle Zugriffe auf eine Variable in separater Sicht anzeigen lassen, Änderungen vornehmen und wieder automatisch einfügen lassen. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 3.2 Methoden - Slicing 26 August 2003 Beispiel: Betrachte alle Abhängigkeiten der Variable i und markiere sie. Der markierte Kontext kann fast unverändert übernommen werden und würde ein in sich geschlossenes übersetzbares Programm bilden. Wie beispielhaft gezeigt, wird durch delokalisierte Strukturen Funktionalität verteilt und erschwert somit das Verständnis. ´Slicing´ ist in OOP schwierig umzusetzen, da durch Vererbung und Polymorphie die Konturen der Übergänge verwischt werden. Beispiel sollte berechnen Folge sum 0+1+3+5+7 oder 0+2+4+6+8... bis MAX berechnet nun Zähler i <= MAX in Schritten +2 oder +1 Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 3.2 Methoden - Slicing 26 August 2003 Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

3.3 Methoden – Literate Programming Freie Universität Berlin Institut für Informatik 3.3 Methoden – Literate Programming 26 August 2003 ´Literate Programming´ beschreibt das direkte Einflechten der Dokumentation in den Quelltext. Der Quelltext und die eingeflochtene Dokumentation werden gefiltert und der reine Quelltext geht an den Compiler, die eingeflochtene Dokumentation mit Codestücken wird an ein Programm zum Setzen von Texten geschickt (z.B. TeX). Dadurch ist es jederzeit möglich eine saubere, strukturierte und aktuelle Dokumentation zu erzeugen. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

3.3 Methoden – Literate Programming Freie Universität Berlin Institut für Informatik 3.3 Methoden – Literate Programming 26 August 2003 @ Having seen the handling of non-commutative operators, you can appreciate the comparative simplicity of handling commutative ones. @<Cases for commutative operators@>= case '+': push(pop() + pop()); break; case '*': push(pop() * pop()); @ The handling of numbers is easy: we parse the string that represents the number, obtaining an actual numerical value, and we push that value onto the stack. @<Case for numbers@>= case NUMBER: push(atof(s)); @ When we see a newline character, we print the top element of the stack. @<Case for newlines@>= case '\n': printf("\t%.8g\n", pop()); @* Index. Beispiel: Code Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

3.3 Methoden – Literate Programming Freie Universität Berlin Institut für Informatik 3.3 Methoden – Literate Programming 26 August 2003 Aufwand für Integration in Übersetzer zu groß, daher nicht verbreitet. Ansätze des Prinzips in JavaDoc wiederzufinden. Beispiel: Dokumentation Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

3.4 Methoden - Zusammenfassung Freie Universität Berlin Institut für Informatik 3.4 Methoden - Zusammenfassung 26 August 2003 CSD Gibt den Quelltext in Baumstruktur wieder. Unrelevante Ebenen können ausgeblendet werden. Ist nur integriert (Quelltext direkt veränderbar) und mit guter Dokumentation sinnvoll. Slicing Extrahiert (verteilte) Zusammenhänge über ein gewähltes Konstrukt und stellt sie als Einheit dar. Umsetzung für OO-Sprachen aufwendig. Literate Programming Dokumentation wird in Quelltext eingebettet. Dokumentation und lauffähiges Programm werden durch verschiedene Prozesse extrahiert und aufbereitet. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik Delocalized Plans 26 August 2003 Tools Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 4 Tools 26 August 2003 JavaDoc: Variante von „Literate Programming“ Folding/Falten von Strukturen: Variante von CSD Referenzmarkierung: Variante von Slicing Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 4 Tools 26 August 2003 jGrasp versucht das Konzept der CSDs in einer eigenen Entwicklungsumgebung zu integrieren. Es können zusätzlich automatisch UML/CPG Diagramme aus vorhandenem Code erzeugt werden. http//www.jgrasp.org/ ´Code Folding´ ist ein Plugin für Eclipse und bietet die Möglichkeit verschiedenste Strukturen faltbar zu machen. http://www.coffee-bytes.com/ ´Protocols´ für Eclipse bietet die Möglichkeit verschiedenste Elemente eines Programmes durch Markierung auf Dokumentationsebene in Sektionen (z.B. plans/goals) einzuteilen und in einer eigenen Ansicht zu visualisieren. Auf diese Weise ist es möglich verteilte Zusammenhänge zu gruppieren und sichtbar zu machen. http://www.bergner.se/protocols Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 4 Tools 26 August 2003 ´RefactorIT´ ist ein komplettes Paket für Eclipse um verschiedenste Wartungsoperationen zu vereinfachen. Integriert ist u.a. die Visualisierung von Abhängigkeiten und mehr als 30 Operationen und Assistenten für die Modifikation von Quelltext. http://www.refactorit.com (CAP´ (Code Analysis Plugin) bietet für Eclipse die Möglichkeit alle Abhängigkeiten eines Konstrukts (Klassen/Pakete) mit verschiedenen Diagrammen zu visualisieren und statistische Werte über das Projekt zu erhalten. http://cap.xore.de) Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik Delocalized Plans 26 August 2003 Zusammenfassung Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 5.2 Zusammenfassung 26 August 2003 Es wurde gezeigt, dass dezentralisierte Konstrukte das Verständnis für globale Zusammenhänge verzerren können, wenn sie falsch dokumentiert sind. Variablen mit dezentralem Kontext sollten mit Dokumentation über ihr Rollenverhalten und ihre Verwendungsform versehen werden. Ein intuitives Herangehen an das Verstehen eines Quelltextes ist nicht anzuraten. Bei schlechter/unzureichender Dokumentation sollte der weitere Kontext eines Konstruktes im Quelltext referiert werden, statt nur Annahmen darüber zu treffen. Redundanz sollte vermieden werden. Redundanz als Verständnishilfe sollte eher in Form von erweiterter Dokumentation gegeben werden. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 5.3 Zusammenfassung 26 August 2003 Mit CSDs (´control structure diagramms´) ist es möglich Abstraktionsebenen von Quelltext zu betrachten und für den Betrachter unrelevante Ebenen auszublenden. Mit ´Slicing´, dem Herausfiltern und Visualisieren von dezentralen Konstrukten, ist es möglich das Problem der ´delocalized plans´ an der Wurzel zu fassen und Modifikationen an dezentralen Funktionen mit Sicht auf die Abhängigkeiten vorzunehmen. Durch das direkte Einflechten von Dokumentation in den Quelltext im Sinne von ´literate Programming´ ist es möglich Intentionen beim Programmieren besser textuell festzuhalten und in eine geordnete und leicht abrufbare Form zu bringen. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 5.5 Zusammenfassung 26 August 2003 Es gibt viele nützliche Programme und Plugins, welche helfen das Problem der ´delocalized plans´ zu mindern – allein in jeder besseren Entwicklungsumgebung sind Mittel zur Abhängigkeitsanalyse vorhanden. Dokumentation ist entscheidend. Jeder der schon einmal in der freien Wirtschaft programmiert hat, weiß eine gute Dokumentation zu schätzen. Auch wenn es die Arbeitszeit vorerst verlängert: Eine Klasse die das letzte Mal vor einem Monat angesehen wurde liest sich sehr viel einfacher, wenn eine gute (nicht zu sachliche) Dokumentation vorhanden ist. Es ist angeraten, für die persönlich favorisierte Entwicklungsumgebung alle möglichen Erweiterungen auszutesten. Ist ein solcher Helfer erst einmal integriert, möchte man ihn kaum noch missen. dezentrale Konstrukte sind problematisch, noch problematischer mit falscher/ungenauer Dokumentation Deswegen Variablen mit semantischer Beschreibung bestücken Intuitives Herangehen nicht gut, da Intention des Authors vielleicht anders Redundanz für Verständnis gut, für Wartung eher schlecht Dokumentation entscheidend: Mitarbeiter vergessen was letzten Tag geschrieben, herausfinden aber wesentlich länger. Erweiterungen helfen. Freaks mit vi gut beraten, aber es fehlt uU. bei sehr grossen Programmen die Übersicht. Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 26 August 2003 Danke! Maximilian Schmidt, schmidtm@inf.fu-berlin.de schmidtm@inf.fu-berlin.de