Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Maximilian Schmidt, Seminar Komponenten Delocalized Plans Maximilian Schmidt Freie Universität Berlin, Institut für Informatik.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Maximilian Schmidt, Seminar Komponenten Delocalized Plans Maximilian Schmidt Freie Universität Berlin, Institut für Informatik."—  Präsentation transkript:

1 1 Maximilian Schmidt, Seminar Komponenten Delocalized Plans Maximilian Schmidt Freie Universität Berlin, Institut für Informatik Modelle Experimente Methoden Tools

2 2 Maximilian Schmidt, Inhalt 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

3 3 Maximilian Schmidt, Delocalized Plans Modelle und Strategien

4 4 Maximilian Schmidt, 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.

5 5 Maximilian Schmidt, 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.

6 6 Maximilian Schmidt, 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

7 7 Maximilian Schmidt, 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

8 8 Maximilian Schmidt, 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 erfasst mit ´micro – strategies´: Schrittweise Planung der Modifikation Für uns hier nicht relevant, da Kontexterfassung wesentlich.

9 9 Maximilian Schmidt, 1.3 Modelle und Strategien - Zusammenfassung

10 10 Maximilian Schmidt, Delocalized Plans Experimente

11 11 Maximilian Schmidt, 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

12 12 Maximilian Schmidt, 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)

13 13 Maximilian Schmidt, 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. 2.2 Experimente – Beispiel I NCHNGE: contains the number of changes to the database made during the current session NCHNGE = NCHNGE + 1

14 14 Maximilian Schmidt, 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: 2.2 Experimente – Beispiel I 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

15 15 Maximilian Schmidt, 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 OLDREC = IREC 101 OLDNAM = NAME 102 GOTO 10

16 16 Maximilian Schmidt, 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 GOTO 10

17 17 Maximilian Schmidt, 2.2 Experimente – Beispiel III MAXREC = # maximale Einträge NRECS = # bisherige Einträge IREC = aktueller Eintrag Wo liegt der Fehler? SUBROUTINE getdb(…) C Read the database into the array READ(13,20,END = 100) DBASE(IREC) IREC = IREC + 1 IF (IREC.LT.MAXREC) GOTO 10 WRITE(6,*) Database full IERR = 1 RETURN 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

18 18 Maximilian Schmidt, 2.2 Experimente – Beispiel III 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 READ(13,20,END = 100) DBASE(IREC) IREC = IREC + 1 IF (IREC.LT.MAXREC) GOTO 10 WRITE(6,*) Database full IERR = 1 RETURN 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

19 19 Maximilian Schmidt, 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.

20 20 Maximilian Schmidt, Delocalized Plans Methoden

21 21 Maximilian Schmidt, 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.

22 22 Maximilian Schmidt, 3.1 Methoden - CSD Beispiel: Hummer.java (ALP IV) mit jGrasp (siehe Tools)

23 23 Maximilian Schmidt, 3.1 Methoden - CSD Optimiertes Beispiel mit goals/plans

24 24 Maximilian Schmidt, 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.

25 25 Maximilian Schmidt, 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.

26 26 Maximilian Schmidt, 3.2 Methoden - Slicing

27 27 Maximilian Schmidt, 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.

28 28 Maximilian Schmidt, 3.3 Methoden – Literate Having seen the handling of non-commutative operators, you can appreciate the comparative simplicity of handling commutative = 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 = case NUMBER: push(atof(s)); When we see a newline character, we print the top element of the = case '\n': printf("\t%.8g\n", pop()); Index. Beispiel: Code

29 29 Maximilian Schmidt, 3.3 Methoden – Literate Programming Beispiel: Dokumentation

30 30 Maximilian Schmidt, 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.

31 31 Maximilian Schmidt, Delocalized Plans Tools

32 32 Maximilian Schmidt, 4 Tools JavaDoc: Variante von Literate Programming Folding/Falten von Strukturen: Variante von CSD Referenzmarkierung: Variante von Slicing

33 33 Maximilian Schmidt, 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. ´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.

34 34 Maximilian Schmidt, 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. (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.

35 35 Maximilian Schmidt, Delocalized Plans Zusammenfassung

36 36 Maximilian Schmidt, 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.

37 37 Maximilian Schmidt, 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.

38 38 Maximilian Schmidt, 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.

39 39 Maximilian Schmidt, Danke!


Herunterladen ppt "1 Maximilian Schmidt, Seminar Komponenten Delocalized Plans Maximilian Schmidt Freie Universität Berlin, Institut für Informatik."

Ähnliche Präsentationen


Google-Anzeigen