Modelle Experimente

1. Modelle Experimente Methoden Tools Seminar „Komponenten“Delocalized Plans Maximilian SchmidtFreie Universität Berlin, Institut für Informatikhttp://www.inf.fu-berlin.de/inst/ag-se/ Maximilian Schmidt, schmidtm@inf.fu-berlin.de

2. Inhalt • 4 Tools • 5 Zusammenfassung • 5.1 Modelle/Strategien • 5.2 Experimente • 5.2 Methoden • 5.3 Tools • 5.4 Fazit • 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 Maximilian Schmidt, schmidtm@inf.fu-berlin.de

3. Delocalized Plans Modelle und Strategien Maximilian Schmidt, schmidtm@inf.fu-berlin.de

4. 1.1 Modelle und Strategien - Einführung • 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. Maximilian Schmidt, schmidtm@inf.fu-berlin.de

5. 1.2 Modelle und Strategien - Begriffe ´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. Maximilian Schmidt, schmidtm@inf.fu-berlin.de

6. 1.2 Modelle und Strategien - Begriffe • 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

7. 1.2 Modelle und Strategien - Begriffe • 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“ Maximilian Schmidt, schmidtm@inf.fu-berlin.de

8. 1.2 Modelle und Strategien - Begriffe • 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 erfasstmit ´micro – strategies´: • Schrittweise Planung der Modifikation • Für uns hier nicht relevant, da Kontexterfassung wesentlich. Maximilian Schmidt, schmidtm@inf.fu-berlin.de

9. 1.3 Modelle und Strategien - Zusammenfassung Maximilian Schmidt, schmidtm@inf.fu-berlin.de

10. Delocalized Plans Experimente Maximilian Schmidt, schmidtm@inf.fu-berlin.de

11. 2.1 Experimente - Autoren • 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

12. 2.2 Experimente – Beispiele • 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“) Maximilian Schmidt, schmidtm@inf.fu-berlin.de

13. 2.2 Experimente – Beispiel I • 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

14. 2.2 Experimente – Beispiel I • 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(…) 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

15. 2.2 Experimente – Beispiel II • 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 Maximilian Schmidt, schmidtm@inf.fu-berlin.de

16. 2.2 Experimente – Beispiel II • 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

17. 2.2 Experimente – Beispiel III 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 . . . RETURN END SUBROUTINE create(….) C Create a new record in the database IF (NRECS.EQ.MAXREC) THEN WRITE(6,*) „Database full.“ RETURN C Else, really create record NRECS = NRECS + 1; . . . RETURN END • MAXREC= # maximale Einträge • NRECS= # bisherige Einträge • IREC= aktueller Eintrag • Wo liegt der Fehler? Maximilian Schmidt, schmidtm@inf.fu-berlin.de

18. 2.2 Experimente – Beispiel III 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 . . . RETURN END SUBROUTINE create(….) C Create a new record in the database IF (NRECS.EQ.MAXREC) THEN WRITE(6,*) „Database full.“ RETURN C Else, really create record NRECS = NRECS + 1; . . . RETURN END • 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 Maximilian Schmidt, schmidtm@inf.fu-berlin.de

19. 2.3 Experimente - Zusammenfassung • 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. Maximilian Schmidt, schmidtm@inf.fu-berlin.de

20. Delocalized Plans Methoden Maximilian Schmidt, schmidtm@inf.fu-berlin.de

21. 3.1 Methoden - CSD • 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

22. 3.1 Methoden - CSD Beispiel: Hummer.java (ALP IV) mit jGrasp (siehe Tools) Maximilian Schmidt, schmidtm@inf.fu-berlin.de

23. 3.1 Methoden - CSD Optimiertes Beispiel mit goals/plans Maximilian Schmidt, schmidtm@inf.fu-berlin.de

24. 3.2 Methoden - Slicing • (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

25. 3.2 Methoden - Slicing 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. Maximilian Schmidt, schmidtm@inf.fu-berlin.de

26. 3.2 Methoden - Slicing Maximilian Schmidt, schmidtm@inf.fu-berlin.de

27. 3.3 Methoden – Literate Programming • ´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

28. 3.3 Methoden – Literate Programming @ 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()); break; @ 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)); break; @ When we see a newline character, we print the top element of the stack. @<Case for newlines@>= case '\n': printf("\t%.8g\n", pop()); break; @* Index. Beispiel: Code Maximilian Schmidt, schmidtm@inf.fu-berlin.de

29. 3.3 Methoden – Literate Programming Beispiel: Dokumentation Maximilian Schmidt, schmidtm@inf.fu-berlin.de

30. 3.4 Methoden - Zusammenfassung • 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

31. Delocalized Plans Tools Maximilian Schmidt, schmidtm@inf.fu-berlin.de

32. 4 Tools JavaDoc: Variante von „Literate Programming“ Folding/Falten von Strukturen: Variante von CSD Referenzmarkierung: Variante von Slicing Maximilian Schmidt, schmidtm@inf.fu-berlin.de

33. 4 Tools • 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

34. 4 Tools • ´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

35. Delocalized Plans Zusammenfassung Maximilian Schmidt, schmidtm@inf.fu-berlin.de

36. 5.2 Zusammenfassung • 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

37. 5.3 Zusammenfassung • 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

38. 5.5 Zusammenfassung • 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. Maximilian Schmidt, schmidtm@inf.fu-berlin.de

39. Danke! Maximilian Schmidt, schmidtm@inf.fu-berlin.de