Haben wir Programmverstehen schon ganz verstanden? RainerKoschke koschke@tzi.de Rebecca Tiarks Arbeitsgruppe Softwaretechnik Fachbereich Mathematik Informatik Universität Bremen
Postfach 33 04 40 28334 Bremen
Haben wir Programmverstehen schon ganz verstanden? 8002B6DBC5F27930D1E0380E7082ED84 GROBID - A machine learning software for extracting information from scholarly documents

Langlebige Systeme müssen kontinuierlich von Entwicklern angepasst werden, wenn sie nicht an Wert verlieren sollen. Ohne ausreichendes Verständnis des Änderungswunsches und des zu ändernden Gegenstands kann die Anpassung nicht effizient und effektiv vorgenommen werden. Deshalb ist es wichtig, das System so zu strukturieren, dass Entwickler es leicht verstehen können. Methoden und Werkzeuge müssen bereitgestellt werden, um die Aktivitäten bei der Änderung zu unterstützen. Dazu ist ein umfassendes Verständnis notwendig, wie überhaupt Entwickler Programme verstehen.

In diesem Beitrag geben wir eine Übersicht über den Stand der Wissenschaft zum Thema Programmverstehen und identifizieren weiteren Forschungsbedarf.
Einf ührung

Die Möglichkeit zur kontinuierlichen Wartung ist die Voraussetzung für langlebige Systeme, weil nur stete Anpassungen an geänderte Rahmenbedingungen Software nützlich erhält. Eine Reihe von Studien zeigt, dass die meisten Ressourcen in der Softwareentwicklung gerade in der Wartung und nicht für die initiale Erstellung von neuen Systemen verwendet werden [AN91,Art88,LS81,Mar83]. In der Wartung werden Fehler beseitigt, umfassende Restrukturierungen vorgenommen oder neue Funktionalität eingebaut.

Wartbarkeit ist keine absolute Eigenschaft eines Systems; sie hängt neben inneren Eigenschaften des Systems immer ab von der Art der Änderung und nicht zuletzt auch von den Entwicklern, die sie durchführen sollen. So können manche Entwickler eine Änderung schnell vornehmen, während andere dafür sehr viel mehr Zeit benötigen. Diese Unterschiede ergeben sich aus unterschiedlichen kognitiven Fähigkeiten, Vertrautheit mit dem System und Erfahrung in der Wartung, aber auch durch unterschiedliche Vorgehensweisen.

Wenn wir also bei langlebigen Systemen für nachhaltige Wartbarkeit sorgen wollen, müssen wir nicht nur zukünftige Änderungen beim initialen Entwurf antizipieren, sondern das System auch so strukturieren und dokumentieren, dass die zukünftigen Wartungsentwickler in der Lage sind, das System für den Zweck ihrer Änderung soweit zu verstehen, dass sie es anpassen und testen können. Dies erfordert ein grundlegendes Verständnis, wie Entwickler Programme überhaupt verstehen. Wenn dieser Verstehensprozess ausreichend verstanden ist, können wir für verständnisfördernde Systemstrukturen sorgen und Wartungsentwicklern effektive und effiziente Methoden und Werkzeuge bereitstellen. Diese sollten sich nach dem jeweiligen Wartungsziel richten, um sowohl die korrektive als auch die adaptive Wartung optimal unterstützen zu können.

Die Forschung hat sich deshalb dem Thema Programmverstehen intensiv gewidmet. Jedoch flachte das Interesse nach einer Blütezeit in den Achtziger Jahren, in der vorwiegend Theorien über kognitive Strategien entwickelt wurden, wieder ab. Hin und wieder erscheinen auch in den letzten Jahren einzelne Publikationen zu diesem Thema. Dennoch können wir nicht belastbar behaupten, die Forschungsagenda, die im Jahre 1997 bei einem internationalen Workshop zu empirischen Studien in der Softwarewartung aufgestellt wurde, abgearbeitet zu haben [KS97]. Die dort speziell in Bezug auf Entwickler geäußerten offen Fragen lauten: In diesem Beitrag geben wir eine Übersicht über den Stand der Wissenschaft zum Thema Programmverstehen und identifizieren weiteren Forschungsbedarf. Die folgende Darstellung zum Stand der Forschung im Programmverstehen gliedern wir in drei Themenfelder:

• Untersuchung von kognitiven Aspekten: In dieser Kategorie geht es um die Frage, wie ein Entwickler bzw. eine Entwicklerin vorgeht, wenn er oder sie ein Programm verstehen möchte.

• Entwicklung von Hilfsmitteln: Dieses Feld befasst sich mit der Frage, wie Werkzeuge beim Programmverstehen helfen können und wie diese aussehen sollten.

• Bisherige empirische Studien: Hier fassen wir frühere Studien zusammen, die empirisch neue Technologien und Werkzeuge sowie kognitive Aspekte untersuchten.

2 Untersuchung von kognitiven Aspekten Ein Verfechter des Top-Down-Modells ist Brooks [Bro83]. Die Grundlage seines Modells des Programmverstehens bilden drei Pfeiler:

• Der Programmierprozess ist eine Konstruktion von Abbildungen von einem Anwendungsbereich über ein oder mehrere Zwischenbereiche auf einen Programmierbereich.

• Der Verstehensprozess umfasst die Rekonstruktion von allen oder Teilen dieser Abbildungen.

• • Die Wissensbasis beinhaltet Fachwissen, Wissen über den Problembereich, Stilregeln, Pläne und Ziele.

• Das mentale Modell beschreibt das gegenwärtige Verständnis des Programmierers über das Programm.

• Der Prozess des Wissenserwerbs gleicht Quellcode und Dokumentation mit der Wissensbasis ab. Dadurch entwickelt sich das mentale Modell weiter. Der Prozess kann sowohl top-down als auch bottom-up erfolgen.

Nach Letovsky [Let86] gibt es drei Arten von Hypothesen:

• Warum-Vermutungen fragen nach dem Zweck eines Code-Fragments.

• Wie-Vermutungen fragen nach der Umsetzung eines Zwecks.

• Was-Vermutungen fragen nach, was etwas ist und was es tut (z. Auf Basis unserer Literaturstudie zum Thema Programmverstehen formulieren wir die folgenden offenen Fragen, die zukünftige Forschung adressieren sollte:

• Vorgehensweisen: Wie gehen Programmierer -abhängig von der Art ihrer Aufgabe -genau vor, wenn sie Programme ändern sollen? Aus welchen Einzelaktivitäten besteht der Programmverstehensprozess für welche Art von Aufgaben? Welche Informationen werden abhängig von der Aufgabe benötigt? Warum gehen Programmierer so vor? Worin unterscheiden sich die Vorgehensweisen unterschiedlicher Programmierer? Welche Vorgehensweisen führen eher zum Erfolg?

• Aufwand: Wie hoch ist der Aufwand des Programmverstehens in der Wartungsphase im Verhältnis zu Änderung und Test? Wie hoch ist der Aufwand der Einzelaktivitäten des Programmverstehens? Wie hoch sind die Kosten, wenn bestimmte Informationen fehlen?

• Werkzeuge: Wie werden moderne Entwicklungswerkzeuge beim Programmverstehen benutzt? Wie gut eignen sie sich für ihren Zweck? Wie lassen sie sich verbessern? Für welche Aspekte existiert noch unzureichende Werkzeugunterstützung? Welches Wissen kann kaum von Werkzeugen verwaltet werden?

• Methoden: Was sind gut geeignete Vorgehensweisen beim Programmverstehen für wiederkehrende Aufgabenarten? Welche Informationen und Werkzeuge sind geeignet, um diese Vorgehensweisen zu unterstützen?

• Code-Strukturen: Welche Auswirkungen haben die Bad Smells von Beck und Fowler auf das Programmverständnis?

• Einfluss von Architektur Wie wird Architektur in der Praxis dokumentiert? Wie wird sie von Programmierern benutzt? Welche Probleme gibt es für den Austausch des Architekturwissens?

• Wissenschaftliche Methoden: Welche Methoden aus den Sozial-und Kognitionswissenschaften und der Psychologie lassen sich für die Forschung im Programmverstehen wie übertragen? Wie können empirische Beobachtungen und Experimente durch Softwaresysteme unterstützt werden?

Der Rekonstruktionsprozess wird durch Erwartungen geleitet, d.h. durch das Aufstellen, Bestätigen und Verfeinern von Hypothesen. Beim Verstehensprozess werden die Abbildungen, die bei der Entwicklung des Programms als Grundlage dienten, rekonstruiert. Die Menge von Abbildungen und ihre Abhängigkeiten untereinander sind baumähnlich aufgebaut. Hypothesen sind Annahmen über diese Abhängigkeiten. Die primäre Hypothese bildet die Wurzel. Sie beschreibt, was das Programm nach dem gegenwärtigen Verständnis des Programmierers tut. Das Verfeinern der primären Hypothese führt zu einer Kaskade von ergänzenden Hypothesen. Dieser Prozess wird so-lange fortgeführt, bis eine Hypothese gefunden ist, die präzise genug ist, um sie anhand des Codes und der Dokumentation zu verifizieren oder zu falsifizieren. Präzise genug heißt, dass die Hypothese Abläufe oder Datenstrukturen beschreibt, die mit sichtbaren Elementen im Quellcode oder der Dokumentation in Zusammenhang gebracht werden können. Diese sichtbaren Elemente werden mit dem Begriff Beacons beschrieben. Ein typischer Beacon für das Sortieren in einem Datenfeld wäre z.B. ein geschachteltes Paar von Schleifen, in denen zwei Elemente miteinander verglichen und vertauscht werden[Bro83].Ein weiteres Modell, das aus einer Kombination der beiden vorherigen Modelle besteht, ist das wissensbasierte Modell von Letovsky[Let86]. Es geht davon aus, dass Programmierer sowohl top-down als auch bottom-up vorgehen. Es besteht aus drei Komponenten:
B. eine Funktion, die eine Variable setzt).Das integrierte Metamodell von Mayrhauser und Vans[vMV95] ist ebenso eine Synthese der bereits erläuterten Modelle. Es besteht aus drei Komponenten, die Verstehensprozesse darstellen und verschiedene mentale Repräsentationen von Abstraktionsebenen enthalten. Die vierte Komponente bildet die Wissensbasis, die die Informationen für den Verstehensprozess bereit stellt und diese speichert.In allen Modellen lassen sich gemeinsame Elemente wiederfinden. So verfügt ein Programmierer über Wissen aus zwei Bereichen: das allgemeine und das systemspezifische Softwarewissen. Das allgemeine Wissen ist unabhängig von einem konkreten System, das verstanden werden soll, und umfasst Kenntnisse über Algorithmen, Programmiersprachen und allgemeine Programmierprinzipen. Das systemspezifische Wissen hingegen repräsentiert das gegenwärtige Verständnis des spezifischen Programms, das der Programmierer betrachtet. Während des Verstehensprozesses erwirbt der Programmierer weiteres systemspezifisches Wissen, jedoch kann ebenso zusätzliches allgemeines Wissen nötig sein[vMV95]. Der Prozess des Programmverstehens gleicht neu erworbenes Wissen mit Bestehendem ab und prüft, ob zwischen beiden eine Beziehung besteht, d.h. ob sich bekannte Strukturen im neuen Wissen befinden. Je mehr Korrelationen erkannt werden, desto größer ist das Verständnis, und es bildet sich ein mentales Modell. Das mentale Modell beim Programmverstehen ist eine interne Repräsentation der betrachteten Software und setzt sich aus statischen und dynamischen Elementen zusammen[vMV95].Computergestützte Hilfsmittel können beim Programmverstehen von großem Nutzen sein, indem sie Programmierern helfen, Informationen herzuleiten, um daraus Wissen auf einem höheren Abstraktionsniveau zu schaffen.Reverse-Engineering ist ein wichtiger Begriff im Zusammenhang mit der Unterstützung des Programmverstehens. Nach Chikofsky und Cross[CC90] ist Reverse-Engineering der Analyseprozess eines Systems, um die Systemkomponenten und deren Beziehungen zu identifizieren. Das Ziel des Reverse-Engineerings ist es, ein Softwaresystem zu verstehen, um das Korrigieren, Verbessern, Umstrukturieren oder Neuschreiben zu erleichtern [Rug92]. Reverse-Engineering kann sowohl auf Quellcodeebene als auch auf Architekturoder Entwurfsebene einsetzen. Die maschinelle Unterstützung von Programmverstehen ist Gegenstand der aktiven Forschung. Die resultierenden Werkzeuge lassen sich in drei Kategorien einteilen [TS96]: Werkzeuge zur Extraktion, zur Analyse und zur Präsentation. Werkzeuge, die sich mit der Extraktion von Daten befassen, sind beispielsweise Parser. Analysetools erzeugen Aufrufgraphen, Modulhierarchien oder Ähnliches mit Hilfe von statischen und dynamischen Informationen. Bei der statischen Analyse werden die Informationen über ein Programm aus dem zugrunde liegenden Quelltext extrahiert. Im Gegensatz dazu wird bei der dynamischen Analyse das Programm mit Testdaten ausgeführt. Zu den Tools, die sich mit der Präsentation der Informationen befassen, gehören Browser, Editoren und Visualisierungswerkzeuge. Moderne Entwicklungsumgebungen und Reverse-Engineering-Werkzeuge vereinen oft Eigenschaften aus mehreren Kategorien in einem integrierten Werkzeug. Neuere Ansätze befassen sich außerdem mit der Integration von auditiver Unterstützung in moderne Entwicklungsumgebungen [HTBK09, SG09]. Es ergeben sich verschiedene Anforderungen an die Werkzeuge, die das Programmverstehen unterstützen sollen. Nach Lakhotia [Lak93] sollte ein Werkzeug die partielle Rekonstruktion des System-Designs ermöglichen. Singer et al. [SLVA97] identifizieren drei wichtige Funktionen, die ein Werkzeug bieten sollte. Zum einen sollte es dem Benutzer ermöglichen, nach Artefakten im Programm zu suchen, und zum anderen sollte das Werkzeug die Abhängigkeiten und Attribute der gefundenen Artefakte in geeigneter Form darstellen können. Um bereits gefundene Informationen zu einem späteren Zeitpunkt wie-derverwenden zu können, sollte das Werkzeug außerdem die Suchhistorie speichern. Einen weiteren wichtigen Aspekt formulieren Mayrhauser und Vans [vMV93]: ein Werkzeug sollte die verschiedenen Arbeitsweisen von Programmierern unterstützen, statt die Aufgaben im gesamten Wartungsprozess fest vorzugeben. Leider ist festzuhalten, dass bisherige empirische Studien zur Eignung von Werkzeugen für das Programmverstehen oft nur mit einer geringen Anzahl von Teilnehmern und an kleineren Systemen durchgeführt wurden. Außerdem stehen bei den meisten Untersuchungen die Werkzeuge im Vordergrund und nicht die Verhaltensweisen und kognitiven Prozesse der Programmierer. Der steigende Bedarf an weitreichenderen Werkzeugen, die ein Benutzermodell entwickeln und den Entwickler somit besser proaktiv unterstützen können, erfordert jedoch mehr empirische Grundlagen auf diesem Gebiet. 4 Bisherige empirische Studien Sobald der Nutzen einer Methode, einer Theorie oder eines Werkzeugs von menschlichen Faktoren abhängt, sind Studien und Experimente mit Menschen erforderlich. In Bezug auf das Programmverstehen sind empirische Studien sowohl für die Erforschung kognitiver Aspekte als auch für die Entwicklung von unterstützenden Anwendungen wichtig. Sie bieten die einzige Möglichkeit, Hypothesen systematisch zu bestätigen oder zu widerlegen, da mathematische Beweisführung für dieses Feld nicht in Frage kommt [Tic98, RR08]. Eine Reihe von Experimenten zum Programmverstehen beschreiben Mayrhauser und Vans [vMV95]. Die meisten dokumentierten Versuche beziehen sich allerdings auf kleine Programme mit einigen hundert Zeilen Code. Es stellt sich die Frage, ob die Ergebnisse auch für größere Programme geltend gemacht werden können. Außerdem fehlen Aussagen über die Anwendung von Fachkenntnissen, da den meisten Untersuchungen lediglich Wissen über die statische Struktur eines Programms zu Grunde liegt. Ein großer Teil der Erkenntnisse stammt zudem von Studien, die bereits über zehn Jahre zurück liegen, aber bisher nicht wieder bestätigt oder widerlegt worden sind; so z.B. auch die Ergebnisse von Fjeldstad und Hamlen [FH79]. Bei den neueren Studien stellt sich die Frage nach der externen Validität und der statistischen Signifikanz, da sie auf einer starken Vereinfachung des Umfelds beruhen. So wurden bei der Untersuchung von Ko et al. [KDV07] beispielsweise nur ein Entwickler in einem einzelnen Unternehmen beobachtet. Murphy et al. [MN97] begründen den Nutzen der Reflektionsmethode anhand einer Fallstudie, an der nur ein Programmierer beteiligt war. Außerdem sind viele der Studien nur auf ein Werkzeug oder eine Programmiersprache beschränkt (z.B. Eclipse: [SDVFM05, KAM05, LOZP06], Java: [DH09b], C++:[MW01]. Die Resultate aus der Studie von Soloway und Ehrlich [SE84] belegen, dass Programmierer Programme besser verstehen, wenn sie mit bestimmten Konzepten erstellt worden sind und sie bestimmten Programmierrichtlinien folgen, jedoch waren die verwendeten Programme kurze, künstlich erstellte Code-Fragmente, so dass sich wieder die Frage nach der Übertragbarkeit auf große Programme stellt. Littman et al. [LPLS86] haben Wartungsprogrammierer beobachtet und dabei festgestellt, dass diese entweder einer opportunistischen oder einer systematischen Vorgehensweise folgen. Die Programmierer, die systematisch versucht haben, den Code zu verstehen, konnten ein mentales Modell des Programms aufbauen. Dadurch waren sie erfolgreicher bei der Umsetzung von Änderungen im Code. Ergebnisse zur Nützlichkeit von Werkzeugen stammen von Bennicke und Rust [BR04]. Die Experimente belegen, dass der Einsatz von Werkzeugen dazu führen kann, dass die Wartung effizienter und effektiver wird. Auch die Ergebnisse von Storey et al. [SWM00] zeigen, dass die drei von ihnen verglichenen Werkzeuge die bevorzugten Verstehensstrategien der Programmierer beim Lösen der gestellten Aufgabe unterstützen. Aktuellere Experimente haben sich mit der Frage befasst, inwieweit eine auditive Unterstützung, neben der visuellen, beim Programmverstehen hilfreich sein kann [SG09, HTBK09]. Sie belegen, dass der Einsatz von auditiven Informationen den Verstehensprozess positiv beeinflusst. Eine Studie von Robillard et al. [RCM04] befasst sich mit den Kennzeichen effektiven Programmverstehens, also mit der Frage, inwieweit Strategien beim Programmverstehen Einfluss haben auf den Erfolg einer Änderungsaufgabe. Die Ergebnisse belegen zwar, dass systematisches Vorgehen beim Programmverstehen bessere Erfolgsquoten bei der Änderungsaufgabe erzielt als das zufällige Vorgehen; allerdings waren bei dem Experiment nur fünf Programmierer beteiligt. Weitere Studien untersuchen Behauptungen über den positiven Einfluss bestimmter neuer Techniken auf das Programmverstehen. Beispiele für diese Kategorie von Studien sind die Arbeiten von Prechelt et al. [PULPT02] über den Einfluss von Dokumentation von Entwurfsmustern, von Arisholm et al. [AHL06] über den Einsatz von UML sowie von Murphy et al. [MWB98] über den Einfluss von aspektorientierten Konzepten auf Aktivitäten in der Wartung. Ein weiterer Mehrwert dieser Studien über die Überprüfung einer konkreten Hypothese hinaus ist der Beitrag zur empirischen Methodik. Sie adaptieren und verfeinern allgemeine empirische Methoden für konkrete Untersuchungen im Bereich Programmverstehen. Arbeiten zur empirischen Methodik finden sich unter anderem bei Di Penta et al. [PSK07, LP06]. Mit den individuellen Unterschieden von Programmierern befasst sich eine Studie von Crosby et al. [CSW02]. Sie untersucht, welchen Einfluss der Wissensstand eines Programmierers auf das Erkennen der von Brooks [Bro83] identifizierten Beacons hat. Demnach erkennen erfahrenere Programmierer eher die sogennanten Beacons und finden dadurch schneller die für das Verständnis wichtigen Teile im Quelltext. Nach Höfer und Tichy [HT06] fehlen allerdings empirische Untersuchungenen zu den individuellen Eigenschaften von Programmierern, die neben der Softwaretechnik auch andere Disziplinen wie Sozialwissenschaften und Psychologie miteinbeziehen. Eine Untersuchung von Ko [Ko03] belegt, dass die Erfahrung eines Programmierers Einfluss hat auf die Strategie, die er anwendet, wenn er mit einer unbekannten Programmierumgebung und Programmiersprache konfrontiert ist. Die Ergebnisse zeigen auch, dass für Wartungsarbeiten im Bereich der Fehlerbeseitigung das systemspezifische Wissen eher von Bedeutung ist als die Erfahrung eines Programmierers. Wie Programmierer vorgehen, wenn sie nach einer Unterbrechung eine Aufgabe erneut aufnehmen und somit sich somit an bereits erlangtes Wissen erinnern müssen, beschreibt eine Studie von Parnin und Rugaber [PR09].Das Ziel, den Aufwand der Wartung und damit die Gesamtkosten der Softwareentwicklung zu reduzieren, hat den Anstoß zu einer Reihe von Untersuchungen zum Programmverstehen gegeben. Diesen Studien liegen jedoch hauptsächlich Experimente mit relativ kleinen Programmen zu Grunde. Die meisten Untersuchungen wurden zudem nur mit einer kleinen Anzahl von Teilnehmern durchgeführt, wodurch sich die Frage nach der Verallgemeinerbarkeit der Ergebnisse stellt. Es fehlen Aussagen zu größeren Systemen sowie eine klare Methodologie für das Programmverstehen, die methodisches Vorgehen nach der Wartungsaufgabe differenziert. Außerdem liegen viele der Studien bereits Jahrzehnte zurück, und die heutige Gültigkeit der Ergebnisse angesichts moderner Programmiersprachen und Entwicklungsumgebungen steht in Frage. Die Trends der heutigen Softwareprojekte, wie z.B. das stärkere Einbinden von Open-Source-Komponenten, die zunehmende Verteilung der Entwickler oder die kürzeren Entwicklungszyklen, haben auch zu neuen Erkenntnisse über die Entwicklungsmethoden, die Eigenschaften der entwickelten Programme und das Verhalten der Entwickler geführt. Das hinterfragt zusätzlich die früheren Erkenntnisse über das Programmverstehen und erhöht den Bedarf nach aktuellen, detaillierten und signifikanten Untersuchungen.
mentare das Programmverstehen unterstützen können. Weitere Studien über den Nutzenvon Dokumentation stammen unter anderem von [BC05, DH09a, DH09b, SPL + 88]. AlleUntersuchungen haben gezeigt, dass verschiedene Codecharateristika das Programmver-stehen beeinflussen.Inwieweit sich geschlechtsspezifische Unterschiede bei der räumlichen Wahrnehmung aufden Verstehensprozess übertragen lassen, untersuchen Fisher et al. [FCZ06] basierend aufder Hypothese von Cox et al. [CFO05], dass sich zwischen dem Programmverstehen undder Raumkognition Gemeinsamkeiten identifizieren lassen. Diese Studie ist eine der weni-gen, die explizit die Unterschiede des Programmverstehens hinsichtlich des Geschlechtesbetrachtet.5 FazitDie Frage nach dem Einfluss von verschiedenen Codecharakteristika auf das Programm-verstehen hat in den letzten Jahren zu einer Reihe von Untersuchungen geführt. Eine ältereStudie von Arab [Ara92] untersucht, inwieweit die Formatierung von Quelltext und Kom-
Man unterscheidet beim Programmverstehen zwischen zwei Strategien: die opportunistische und die systematische Vorgehensweise. Bei einem systematischen Ansatz geht ein Programmierer in einer systematischen Reihenfolge vor, um ein Verständnis für das Programm als Ganzes zu erlangen, z.B. durch zeilenweises Verstehen des Codes [vMVL98]. Beim opportunistischen Ansatz geht der Programmierer nach Bedarf vor und konzentriert sich nur auf die Teile des Codes, von denen er denkt, dass sie für seine aktuelle Aufgabe von Bedeutung sein könnten, ohne die weiteren Abhängigkeiten zu anderen Programmteilen weiter zu betrachten. [LPLS86, KR91, LS86]. Die kognitive Psychologie befasst sich außerdem mit der Frage, welche weiteren Faktoren einen Einfluss darauf haben, wie gut ein Programm verstanden werden kann. Mögliche Faktoren sind z.B. die Programmeigenschaften, die individuellen Unterschiede von Programmierern und die Aufgabenabhängigkeit [SWM00]. Zu den Programmeigenschaften gehören unter anderem die Dokumentation, die Programmiersprache und das Programmierparadigma, das einer Sprache zugrunde liegt. Die Programmierer selber unterscheiden sich ebenso durch eine Reihe von individuellen Eigenschaften in Bezug auf ihre Fähigkeiten und Kreativität. Weiterhin können sich die Vorgehensweisen beim Programmverstehen je nach Aufgabe und Wartungsfragestellung unterscheiden. Programmverstehen stellt kein eigenständiges Ziel im Wartungsprozess dar, sondern ist vielmehr ein nötiger Schritt, um Änderungen an einem Programm durchzuführen, Fehler zu beheben oder Programmteile zu erweitern. Somit hängt auch der Verstehensprozess von der jeweiligen Aufgabe ab. 3 Entwicklung von Hilfsmitteln Die existierenden Analysen werden in grundlegende und wissensbasierte Analysen unterschieden [KP96]. Die grundlegenden Analysen ermitteln Informationen über das Programm und präsentieren diese in geeigneter Form. Der Betrachter nimmt mithilfe dieser Informationen die Abstraktion selber vor. Grundlegende statische Analysen erleichtern den Zugriff auf Informationen aus dem Quelltext. Sie verwenden ausschließlich Daten, die direkt aus dem Quelltext oder anderen Dokumenten abgeleitet werden können. Ein Beispiel hierfür sind Kontrollflussanalysen. Grundlegende dynamische Analysen hingegen ermitteln Informationen während des Programmlaufs. Die wissensbasierten Analysen verfügen über Vorwissen. Dieses spezielle Wissen über Programmierung, Entwurf oder den Anwendungsbereich ermöglicht es den Analysen, automatisch zu abstrahieren. Nach Soloway und Ehrlich [SE84] verfügen erfahrene Programmierer über eine Basis an Wissen, die es ihnen ermöglicht, schneller als Unerfahrene zu abstrahieren. Anhand dieser Wissensbasis versuchen wissensbasierte Analysen, automatisch zu abstrahieren. Die Forschung auf dem Gebiet der Softwarevisualisierung hat zu einer Reihe von Werkzeugen zur Unterstützung des Programmverstehens geführt. Bei der Bildung eines mentalen Modell spielt die Präsentation der extrahierten Information eine wichtige Rolle. Ein Modell zur Bewertung von Visualisierungen wurde von Pacione et al. [PRW04] vorgestellt. Mit Hilfe dieses Modells können Visualisierungen anhand ihrer Abstraktion, ihres Blickwinkels und ihren zugrundeliegenden Informationen evaluiert werden.
The impact of UML documentation on software maintenance: an experimental evaluation LCArisholm EBriand SEHove YLabiche IEEE Computer Society TSE 32 6 Juni 2006 Analysis of maintenance work categories through measurement AAbran HNguyenkim Proceedings. Conference on Conference on 1991. Oct 1991 Software Maintenance Enhancing program comprehension: formatting and documenting MouloudArab SIGPLAN Not 27 2 1992 Software Evolution: A Software Maintenance Challenge LowellJay Arthur 1988 John Wiley & Sons 2 Program comprehension: investigating the effects of naming style and documentation ScottBlinman AndyCockburn Proc. of AUIC'05 of AUIC'05
Darlinghurst, Australia, Australia
 Australian Computer Society, Inc 2005 MBennicke HRust Programmverstehen und statische Analysetechniken im Kontext des Reverse Engineering und der Qualitätssicherung April 2004 Virtuelles Software Engineering Kompetenzzentrum Towards a Theory of the Comprehension of Computer Programs RuvenEBrooks IJMMS 18 6 1983 Reverse Engineering and Design Recovery: a Taxonomy JElliot Chikofsky HJames Cross IEEE Software 7 1 Januar 1990 Theoretical Considerations on Navigating Codespace with Spatial Cognition AnthonyCox MaryanneFisher Und Philip O'Brien Proc. of PPIG'05 of PPIG'05 2005 The Roles Beacons Play in Comprehension for Novice and Expert Programmers MarthaECrosby JeanScholtz Und SusanWiedenbeck Proc. PPIG'02 PPIG'02 2002 Improving API Documentation Usability with Kneowledge Pushing UriDekel JamesHerbsleb Proc. of ICSE'09 of ICSE'09 2009 Reading the Documentation of Invoked API Functions in Program Comprehension UriDekel Und JamesDHerbsleb Proc. of ICPC'09 of ICPC'09
Vancouver, Canada
 IEEE Computer Society 2009 Using Sex Differences to Link Spatial Cognition and Program Comprehension MaryanneFisher AnthonyCox Und LinZhao Proc. ICSM'06 ICSM'06
Washington, DC, USA
 IEEE Computer Society 2006 Application Program Maintenance Study: Report to our Respondents RKFjeldstad WTHamlen Proc. of GUIDE 48 of GUIDE 48
Philadelphia, PA
 1979 Status of Empirical Research in Software Engineering AndreasHöfer Und Walter FTichy Empirical Software Engineering Issues 2006 Sonification DEsign Guidelines to Enhance Program Comprehension KhaledHussein EliTilevich IvicaIco Bukvic SoobeenUnd Kim Proc. ICPC'09 ICPC'09
Vancouver, Canada
 IEEE Computer Society 2009 Eliciting Design Requirements for Maintenance-Oriented IDEs: A Detailed Study of Corrective and Perfective Maintenance Tasks AndrewJKo HtetHtet Aung Und BradAMyers Proc. ICSE'05 ICSE'05 2005 Information Needs in Collocated Software Development Teams AndrewJKo RobertDeline Und GinaVenolia Proc. ICSE'07 ICSE'07 2007 Individual Differences in Program Comprehension Strategies in an Unfamiliar Programming System AndrewJensen Ko IWPC'03 2003 RKoschke EPlödereder Ansätze des Programmverstehens FranzLehner Deutscher Universitätsverlag/Gabler Vieweg Westdeutscher Verlag 1996 Expert problem solving strategies for program comprehension JürgenKoenemann Und Scott PRobertson Proc. of SIGCHI'91 of SIGCHI'91
New York, NY, USA
 ACM 1991 Methodologies for Performing Empirical Studies: Report from WESS'97 ChrisFKemerer SandraSlaughter EMSE 2 2 Juni 1997 Understanding someone else's code: Analysis of experiences ArunLakhotia JSS 23 3 1993 Cognitive Processes in Program Comprehension StanleyLetovsky Workshop ESP
Norwood, NJ, USA
 Ablex Publishing Corp 1986 Plan analysis of programs StanleyLetovsky Dezember 1988 662 Yale University Bericht Research Report Improving Comprehensibility of Source Code via Traceability Information: a Controlled Experiment AndreaDe Lucia RoccoOliveto FrancescoZurolo Und Massimiliano DiPenta Proc. of ICPC' 06 0 2006 Experimental Settings in Program Comprehension: Challenges and Open Issues GiuseppeADi Lucca Und Massimiliano DiPenta Proc. of ICPC'06 of ICPC'06
Washington, DC, USA
 IEEE Computer Society 2006 Mental Models and Software Maintenance DCLittman JePinto SLetovsky ESoloway Workshop ESP
Norwood, NJ, USA
 Ablex Publishing Corp 1986. Dec. 1987 7 Problems in application software maintenance BennetPLientz EBurton Swanson Commun. ACM 24 11 1981 Delocalized Plans and Program Comprehension SLetovsky ESoloway Software May 1986 3 Software Maintenance the Problem and Its Solution JamesMartin 1983 Auflage 6 third printing Reengineering with Reflexion Models: A Case Study GailCMurphy DavidNotkin Reprinted in Nikkei Computer 30 8 August 1997. January 1998 IEEE Computer Navigation and Comprehension of Programs by Novice Programmers RusselMosemann SusanWeidenbeck Proc. of IWPC'01, Seite 79 of IWPC'01, Seite 79
Washington, DC, USA
 IEEE Computer Society 2001 Evaluating Emerging Software Development Technologies: Lessons Learned from Assessing Aspect-oriented Programming GMurphy RWalker EBaniassad TR-98-10 1998 University of Britsh Columbia, Computer Science Technical Report Comprehension Strategies in Programming NPennington Workshop ESP
Norwood, NJ, USA
 Ablex Publishing Corp 1987 Resumption Strategies for Interrupted Programming Tasks ChrisParnin SpencerRugaber Proc. of ICPC' 09 0 2009 A Novel Software Visualisation Model to Support Software Comprehension JMichael MarcPacione MurrayRoper Und Wood Proc. of WCRE'04 of WCRE'04
Washington, DC, USA
 IEEE Computer Society 2004 Designing your Next Empirical Study on Program Comprehension MassimilianoDi Penta REKurt Stirewalt Und EileenKraemer ICPC IEEE Computer Society 2007 Two controlled experiments assessing the usefulness of design pattern documentation in program maintenance LPrechelt BUnger-Lamprecht MPhilippsen WFTichy IEEE Computer Society TSE 28 6 Juni 2002 How Effective Developers Investigate Source Code: An Exploratory Study MRobillard WCoelho GMurphy IEEE Computer Society TSE 30 12 2004 Beginning behavioral research: A conceptual primer RLRosnow RRosenthal 2008 Pearson/Prentice Hall 6th. Auflage Program Comprehension for Reverse Engineering SpencerRugaber AAAI Workshop Juli 1992 Managing software change tasks: an exploratory study JSillito KDeVoider BFisher GMurphy ESE'05 Nov. 2005 10 Empirical Studies of Programming Knowledge ElliotSoloway KateEhrlich IEEE TSE 10 5 1984 Using Spoken Text to Aid Debugging: An Emperical Study AndreasStefik EdGellenbeck Proc. of ICPC' 09 0 2009 An examination of software engineering work practices JaniceSinger TimothyLethbridge NormanVinson Und NicolasAnquetil Proc. of CASCON'97 of CASCON'97 IBM Press 1997 21 Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental Results BShneiderman RMayer ;ESoloway JPinto SLetovsky DLittman Und RLampert Commun. ACM 8 3 1979. November 1988 IJCIS How do program understanding tools affect how programmers understand programs? M.-ADStorey KWong HAMüller Science of Computer Programming 36 2-3 2000 Should computer scientists experiment more? FWalter Tichy IEEE Computer 31 5 Mai 1998 Coming Attractions in Program Understanding RScott DennisBTilley Smith Dezember 1996 Pittsburgh, PA 15213 Bericht, Software Engineering Institute From Program Comprehension to Tool Requirements for an Industrial Environment AnnelieseVon Mayrhauser Und AMarieVans IWPC IEEE Computer Society Press Juli 1993 Program Comprehension During Software Maintenance and Evolution AnnelieseVon Mayrhauser Und AMarieVans IEEE Computer 28 8 1995 Program Comprehension and Enhancement of Software AMarieAnneliese Von Mayrhauser SteveVans Lang Proc. of the IFIP World Computing Congress. IEEE of the IFIP World Computing Congress. IEEE August-September 1998