1 Maximilian Schmidt, [email protected] Seminar Komponenten Delocalized Plans Maximilian...
-
Upload
alrich-keisler -
Category
Documents
-
view
104 -
download
2
Transcript of 1 Maximilian Schmidt, [email protected] Seminar Komponenten Delocalized Plans Maximilian...
Maximilian Schmidt, [email protected] 1
Seminar „Komponenten“
Delocalized Plans Maximilian Schmidt
Freie Universität Berlin, Institut für Informatikhttp://www.inf.fu-berlin.de/inst/ag-se/
• Modelle
• Experimente• Methoden
• Tools
Maximilian Schmidt, [email protected] 2
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
Maximilian Schmidt, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 9
1.3 Modelle und Strategien - Zusammenfassung
Maximilian Schmidt, [email protected] 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, [email protected] 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, [email protected] 13
• 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
Maximilian Schmidt, [email protected] 14
• 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
Maximilian Schmidt, [email protected] 15
2.2 Experimente – Beispiel II
• Code:
C PDB Main Program . . .C Command loop: Perform DB commands10C 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 correct20 IF (NAME.EQ.OLDNAM) THEN21 IREC = OLDREC22 GOTO 100C Else, search database for record . . .C End of search, now have pointer in IREC . . .100 OLDREC = IREC101 OLDNAM = NAME102 GOTO 10
Maximilian Schmidt, [email protected] 16
2.2 Experimente – Beispiel II
• Code:
C PDB Main Program . . .C Command loop: Perform DB commands10C 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 correct20 IF (NAME.EQ.DBASE(IREC,1))21 THEN GOTO 100C Else, search database for record . . .C End of search, now have pointer in IREC . . .100 GOTO 10
Maximilian Schmidt, [email protected] 17
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 . . .10 READ(13,20,END = 100) DBASE(IREC) IREC = IREC + 1 IF (IREC.LT.MAXREC) GOTO 10 WRITE(6,*) „Database full“ IERR = 1 RETURN100 . . . RETURN END
SUBROUTINE create(….)C Create a new record in the database IF (NRECS.EQ.MAXREC) THEN WRITE(6,*) „Database full.“ RETURNC Else, really create record NRECS = NRECS + 1; . . . RETURN END
Maximilian Schmidt, [email protected] 18
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 . . .10 READ(13,20,END = 100) DBASE(IREC) IREC = IREC + 1 IF (IREC.LT.MAXREC) GOTO 10 WRITE(6,*) „Database full“ IERR = 1 RETURN100 . . . RETURN END
SUBROUTINE create(….)C Create a new record in the database IF (NRECS.EQ.MAXREC) THEN WRITE(6,*) „Database full.“ RETURNC Else, really create record NRECS = NRECS + 1; . . . RETURN END
Maximilian Schmidt, [email protected] 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, [email protected] 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, [email protected] 22
3.1 Methoden - CSD
Beispiel:Hummer.java (ALP IV)mit jGrasp (siehe Tools)
Maximilian Schmidt, [email protected] 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, [email protected] 25
3.2 Methoden - Slicing
Beispiel:
Betrachte alle Abhängigkeitender Variable i und markiere sie.
Der markierte Kontext kannfast unverändert übernommenwerden und würde ein in sichgeschlossenes übersetzbaresProgramm bilden.
Maximilian Schmidt, [email protected] 26
3.2 Methoden - Slicing
Maximilian Schmidt, [email protected] 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, [email protected] 28
3.3 Methoden – Literate Programming
@ Having seen the handling of non-commutative operators, you canappreciate 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 representsthe number, obtaining an actual numerical value, and we push thatvalue 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, [email protected] 29
3.3 Methoden – Literate Programming
Beispiel: Dokumentation
Maximilian Schmidt, [email protected] 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, [email protected] 32
4 Tools
JavaDoc:Variante von„Literate Programming“
Folding/Falten von Strukturen:Variante von CSD
Referenzmarkierung:Variante von Slicing
Maximilian Schmidt, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 39
Danke!