Langlebige Systeme mu¨ssen kontinuierlich von Entwicklern angepasst werden, wenn sie nicht an Wert verlieren sollen. Ohne ausreichendes Versta¨ndnis des A¨ nderungswunsches und des zu a¨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 ko¨nnen. Methoden und Werkzeuge mu¨ssen bereitgestellt werden, um die Aktivita¨ten bei der A¨ nderung zu unterstu¨tzen. Dazu ist ein umfassendes Versta¨ndnis notwendig, wie u¨berhaupt Entwickler Programme verstehen. In diesem Beitrag geben wir eine U¨ bersicht u¨ber den Stand der Wissenschaft zum Thema Programmverstehen und identifizieren weiteren Forschungsbedarf.
Programme u¨berhaupt verstehen. Wenn dieser Verstehensprozess ausreichend verstanden ist, ko¨nnen wir fu¨r versta¨ndnisfo¨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 unterstu¨tzen zu ko¨nnen.
Die Forschung hat sich deshalb dem Thema Programmverstehen intensiv gewidmet. Jedoch flachte das Interesse nach einer Blu¨tezeit in den Achtziger Jahren, in der vorwiegend Theorien u¨ber kognitive Strategien entwickelt wurden, wieder ab. Hin und wieder erscheinen auch in den letzten Jahren einzelne Publikationen zu diesem Thema. Dennoch ko¨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 gea¨ußerten offen Fragen lauten:
3. Demographics of maintainers – age, technical experience, language experience, application experience? Diese Fragen sind noch immer weitgehend offen, auch wenn einzelne Studien versucht haben, Teile von ihnen zu beantworten. Eine sehr bekannte und vielzitierte Studie, die die zweite offene Frage adressiert, stammt aus dem Jahr 1979 [FH79]. In dieser Studie kommen die Autoren zum Schluss, dass Wartungsentwickler rund die Ha¨lfte (bei korrektiver Wartung sogar bis zu 60 %) ihrer Zeit mit dem Versta¨ndnis des Problems und des Systems verbringen. Schon auf dem bereits angesprochenen Workshop wurde auf fehlende Vergleichsstudien hingewiesen [KS97]. Umso mehr ist es heute unklar, ob diese Zahlen auf heutige Verha¨ltnisse u¨bertragbar sind. Außerdem hat diese Studie nur eine globale Aussage zum Programmverstehen gemacht (50 % des Aufwands in der Wartung), aber nicht weiter untersucht, wie lange die Programmierer dabei mit einzelnen Aktivita¨ten bescha¨ftigt sind. Schließlich ist Zweifel an der Verla¨sslichkeit der Aussage zum Aufwand des Programmverstehens angebracht, da die Zahlen lediglich u¨ber Umfragen erhoben wurden, ohne tatsa¨chlich selbst den Aufwand bei Wartungsaufgaben zu messen. Dennoch zitieren viele wissenschaftlichen Publikationen in Ermangelung von Alternativen diese Studie. In diesem Beitrag geben wir eine U¨bersicht u¨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 mo¨chte.
Entwicklung von Hilfsmitteln: Dieses Feld befasst sich mit der Frage, wie Werkzeuge beim Programmverstehen helfen ko¨nnen und wie diese aussehen sollten. Bisherige empirische Studien: Hier fassen wir fru¨here Studien zusammen, die empirisch neue Technologien und Werkzeuge sowie kognitive Aspekte untersuchten. 2
Die Erforschung der kognitiven Aspekte des Programmverstehens befasst sich mit menschlichen Denkprozessen von Programmierern bei der Analyse von Programmen. Sie ergru¨ndet, welche Strategien ein Programmierer beim Verstehen von Programmen verfolgt. Um diese Strategien zu untersuchen, muss man ermitteln, welche Informationen der Programmierer nutzt, um ein Stu¨ck Software und das zugrunde liegende Modell zu begreifen, und wie er diese verwendet. Im Verstehensprozess ko¨nnen zwei grundlegend verschiedene Strategien verfolgt werden. Der Top-Down-Ansatz geht davon aus, dass Hypothesen generiert werden und diese in Richtung auf niedrigere Abstraktionsebenen gepru¨ft, verfeinert und gegebenenfalls revidiert werden. Beim Bottom-Up-Ansatz hingegen wird die Repra¨sentation eines Programms von unten nach oben aufgebaut, d.h. bei der Ableitung der Verfahrensweise eines Programmteils wird allein vom Quelltext ausgegangen, ohne dass vorher Annahmen u¨ber das Programm getroffen werden.
Ein Beispiel fu¨r den Bottom-Up-Ansatz ist das Modell von Soloway und Ehrlich [SE84]. Ihre Analyse basiert auf der Erkennung von Konzepten im Programm-Code. Diese Konzepte werden zusammengefasst zu Teilzielen und diese wiederum zu Zielen. Verschiedene Experimente besta¨tigen dieses Modell, und ein von Letowsky [Let88] entwickeltes Werkzeug fu¨hrt Teile des Analyseprozesses automatisch aus. Auch Shneiderman und Mayer [SM79] beschreiben ein Bottom-Up-Modell. Sie unterscheiden zwei Arten von Wissen u¨ber ein Programm: syntaktisches und semantisches Wissen. Das syntaktische Wissen ist sprachabha¨ngig und beschreibt die grundlegenden Einheiten und Anweisungen im Quelltext. Das semantische Wissen hingegen ist sprachunabha¨ngig. Es wird schrittweise aufgebaut, bis ein mentales Modell entsteht, das den Anwendungsbereich beschreibt. Das Bottom-Up-Modell von Pennington [Pen87] besteht aus zwei Teilen: dem Situationsmodell und dem Programmmodell. Bei unbekanntem Code wird durch die Abstraktion des Kontrollflusses das Programmmodell gebildet. Dies geschieht in einem Bottom-UpProzess durch Zusammenfassen von kleinen Programmfragmenten (Anweisungen, Kontrollstrukturen) zu gro¨ßeren Einheiten. Nach dem Programmmodell wird das Situationsmodell gebildet. Das Situationsmodell ergibt sich bottom-up, indem durch Ru¨ckverweise auf das Programmmodell eine Abstraktion des Datenflusses und eine funktionale Abstraktion entsteht.
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 u¨ber ein oder mehrere Zwischenbereiche auf einen Programmierbereich.
Der Verstehensprozess umfasst die Rekonstruktion von allen oder Teilen dieser Abbildungen.
Der Rekonstruktionsprozess wird durch Erwartungen geleitet, d.h. durch das Aufstellen, Besta¨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 Abha¨ngigkeiten untereinander sind bauma¨hnlich aufgebaut. Hypothesen sind Annahmen u¨ber diese Abha¨ngigkeiten. Die prima¨re Hypothese bildet die Wurzel. Sie beschreibt, was das Programm nach dem gegenwa¨rtigen Versta¨ndnis des Programmierers tut. Das Verfeinern der prima¨ren Hypothese fu¨hrt zu einer Kaskade von erga¨nzenden Hypothesen. Dieser Prozess wird solange fortgefu¨hrt, bis eine Hypothese gefunden ist, die pra¨zise genug ist, um sie anhand des Codes und der Dokumentation zu verifizieren oder zu falsifizieren. Pra¨zise genug heißt, dass die Hypothese Abla¨ufe oder Datenstrukturen beschreibt, die mit sichtbaren Elementen im Quellcode oder der Dokumentation in Zusammenhang gebracht werden ko¨nnen. Diese sichtbaren Elemente werden mit dem Begriff Beacons beschrieben. Ein typischer Beacon fu¨r das Sortieren in einem Datenfeld wa¨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: Die Wissensbasis beinhaltet Fachwissen, Wissen u¨ber den Problembereich, Stilregeln, Pla¨ne und Ziele.
Das mentale Modell beschreibt das gegenwa¨rtige Versta¨ndnis des Programmierers u¨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.
Warum-Vermutungen fragen nach dem Zweck eines Code-Fragments.
Was-Vermutungen fragen nach, was etwas ist und was es tut (z.B. eine Funktion, die eine Variable setzt).
Das integrierte Metamodell von Mayrhauser und Vans[vMV95] ist ebenso eine Synthese der bereits erla¨uterten Modelle. Es besteht aus drei Komponenten, die Verstehensprozesse darstellen und verschiedene mentale Repra¨sentationen von Abstraktionsebenen enthalten. Die vierte Komponente bildet die Wissensbasis, die die Informationen fu¨r den Verstehensprozess bereit stellt und diese speichert.
In allen Modellen lassen sich gemeinsame Elemente wiederfinden. So verfu¨gt ein Programmierer u¨ber Wissen aus zwei Bereichen: das allgemeine und das systemspezifische Softwarewissen. Das allgemeine Wissen ist unabha¨ngig von einem konkreten System, das verstanden werden soll, und umfasst Kenntnisse u¨ber Algorithmen, Programmiersprachen und allgemeine Programmierprinzipen. Das systemspezifische Wissen hingegen repra¨sentiert das gegenwa¨rtige Versta¨ndnis des spezifischen Programms, das der Programmierer betrachtet. Wa¨hrend des Verstehensprozesses erwirbt der Programmierer weiteres systemspezifisches Wissen, jedoch kann ebenso zusa¨tzliches allgemeines Wissen no¨tig sein [vMV95]. Der Prozess des Programmverstehens gleicht neu erworbenes Wissen mit Bestehendem ab und pru¨ft, ob zwischen beiden eine Beziehung besteht, d.h. ob sich bekannte Strukturen im neuen Wissen befinden. Je mehr Korrelationen erkannt werden, desto gro¨ßer ist das Versta¨ndnis, und es bildet sich ein mentales Modell. Das mentale Modell beim Programmverstehen ist eine interne Repra¨sentation der betrachteten Software und setzt sich aus statischen und dynamischen Elementen zusammen [vMV95]. 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 Versta¨ndnis fu¨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 fu¨r seine aktuelle Aufgabe von Bedeutung sein ko¨nnten, ohne die weiteren Abha¨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. Mo¨gliche Faktoren sind z.B. die Programmeigenschaften, die individuellen Unterschiede von Programmierern und die Aufgabenabha¨ngigkeit [SWM00]. Zu den Programmeigenschaften geho¨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 Fa¨higkeiten und Kreativita¨t. Weiterhin ko¨nnen sich die Vorgehensweisen beim Programmverstehen je nach Aufgabe und Wartungsfragestellung unterscheiden. Programmverstehen stellt kein eigensta¨ndiges Ziel im Wartungsprozess dar, sondern ist vielmehr ein no¨tiger Schritt, um A¨ nderungen an einem Programm durchzufu¨hren, Fehler zu beheben oder Programmteile zu erweitern. Somit ha¨ngt auch der Verstehensprozess von der jeweiligen Aufgabe ab. 3
Computergestu¨tzte Hilfsmittel ko¨nnen beim Programmverstehen von großem Nutzen sein, indem sie Programmierern helfen, Informationen herzuleiten, um daraus Wissen auf einem ho¨heren Abstraktionsniveau zu schaffen.
Reverse-Engineering ist ein wichtiger Begriff im Zusammenhang mit der Unterstu¨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 Unterstu¨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 Pra¨sentation. Werkzeuge, die sich mit der Extraktion von Daten befassen, sind beispielsweise Parser. Analysetools erzeugen Aufrufgraphen, Modulhierarchien oder A¨ hnliches mit Hilfe von statischen und dynamischen Informationen. Bei der statischen Analyse werden die Informationen u¨ber ein Programm aus dem zugrunde liegenden Quelltext extrahiert. Im Gegensatz dazu wird bei der dynamischen Analyse das Programm mit Testdaten ausgefu¨hrt. Zu den Tools, die sich mit der Pra¨sentation der Informationen befassen, geho¨ren Browser, Editoren und Visualisierungswerkzeuge. Moderne Entwicklungsumgebungen und Reverse-EngineeringWerkzeuge vereinen oft Eigenschaften aus mehreren Kategorien in einem integrierten Werkzeug.
Die existierenden Analysen werden in grundlegende und wissensbasierte Analysen unterschieden [KP96]. Die grundlegenden Analysen ermitteln Informationen u¨ber das Programm und pra¨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 ko¨nnen. Ein Beispiel hierfu¨r sind Kontrollflussanalysen. Grundlegende dynamische Analysen hingegen ermitteln Informationen wa¨hrend des Programmlaufs.
Die wissensbasierten Analysen verfu¨gen u¨ber Vorwissen. Dieses spezielle Wissen u¨ber Programmierung, Entwurf oder den Anwendungsbereich ermo¨glicht es den Analysen, automatisch zu abstrahieren. Nach Soloway und Ehrlich [SE84] verfu¨gen erfahrene Programmierer u¨ber eine Basis an Wissen, die es ihnen ermo¨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 Unterstu¨tzung des Programmverstehens gefu¨hrt. Bei der Bildung eines mentalen Modell spielt die Pra¨sentation der extrahierten Information eine wichtige Rolle. Ein Modell zur Bewertung von Visualisierungen wurde von Pacione et al. [PRW04] vorgestellt. Mit Hilfe dieses Modells ko¨nnen Visualisierungen anhand ihrer Abstraktion, ihres Blickwinkels und ihren zugrundeliegenden Informationen evaluiert werden. Neuere Ansa¨tze befassen sich außerdem mit der Integration von auditiver Unterstu¨tzung in moderne Entwicklungsumgebungen [HTBK09, SG09].
Es ergeben sich verschiedene Anforderungen an die Werkzeuge, die das Programmverstehen unterstu¨tzen sollen. Nach Lakhotia [Lak93] sollte ein Werkzeug die partielle Rekonstruktion des System-Designs ermo¨glichen. Singer et al. [SLVA97] identifizieren drei wichtige Funktionen, die ein Werkzeug bieten sollte. Zum einen sollte es dem Benutzer ermo¨glichen, nach Artefakten im Programm zu suchen, und zum anderen sollte das Werkzeug die Abha¨ngigkeiten und Attribute der gefundenen Artefakte in geeigneter Form darstellen ko¨nnen. Um bereits gefundene Informationen zu einem spa¨teren Zeitpunkt wiederverwenden zu ko¨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 unterstu¨tzen, statt die Aufgaben im gesamten Wartungsprozess fest vorzugeben.
Leider ist festzuhalten, dass bisherige empirische Studien zur Eignung von Werkzeugen fu¨r das Programmverstehen oft nur mit einer geringen Anzahl von Teilnehmern und an kleineren Systemen durchgefu¨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 unterstu¨tzen ko¨nnen, erfordert jedoch mehr empirische Grundlagen auf diesem Gebiet. 4
Sobald der Nutzen einer Methode, einer Theorie oder eines Werkzeugs von menschlichen Faktoren abha¨ngt, sind Studien und Experimente mit Menschen erforderlich. In Bezug auf das Programmverstehen sind empirische Studien sowohl fu¨r die Erforschung kognitiver Aspekte als auch fu¨r die Entwicklung von unterstu¨tzenden Anwendungen wichtig. Sie bieten die einzige Mo¨glichkeit, Hypothesen systematisch zu besta¨tigen oder zu widerlegen, da mathematische Beweisfu¨hrung fu¨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 fu¨r gro¨ßere Programme geltend gemacht werden ko¨nnen. Außerdem fehlen Aussagen u¨ber die Anwendung von Fachkenntnissen, da den meisten Untersuchungen lediglich Wissen u¨ber die statische Struktur eines Programms zu Grunde liegt. Ein großer Teil der Erkenntnisse stammt zudem von Studien, die bereits u¨ber zehn Jahre zuru¨ck liegen, aber bisher nicht wieder besta¨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 Validita¨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] begru¨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 beschra¨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, ku¨nstlich erstellte Code-Fragmente, so dass sich wieder die Frage nach der U¨ 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 A¨nderungen im Code. Ergebnisse zur Nu¨tzlichkeit von Werkzeugen stammen von Bennicke und Rust [BR04]. Die Experimente belegen, dass der Einsatz von Werkzeugen dazu fu¨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 Lo¨sen der gestellten Aufgabe unterstu¨tzen. Aktuellere Experimente haben sich mit der Frage befasst, inwieweit eine auditive Unterstu¨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 A¨ nderungsaufgabe. Die Ergebnisse belegen zwar, dass systematisches Vorgehen beim Programmverstehen bessere Erfolgsquoten bei der A¨nderungsaufgabe erzielt als das zufa¨llige Vorgehen; allerdings waren bei dem Experiment nur fu¨nf Programmierer beteiligt. Weitere Studien untersuchen Behauptungen u¨ber den positiven Einfluss bestimmter neuer Techniken auf das Programmverstehen. Beispiele fu¨r diese Kategorie von Studien sind die Arbeiten von Prechelt et al. [PULPT02] u¨ber den Einfluss von Dokumentation von Entwurfsmustern, von Arisholm et al. [AHL06] u¨ber den Einsatz von UML sowie von Murphy et al. [MWB98] u¨ber den Einfluss von aspektorientierten Konzepten auf Aktivita¨ten in der Wartung. Ein weiterer Mehrwert dieser Studien u¨ber die U¨ berpru¨fung einer konkreten Hypothese hinaus ist der Beitrag zur empirischen Methodik. Sie adaptieren und verfeinern allgemeine empirische Methoden fu¨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 fu¨r das Versta¨ndnis wichtigen Teile im Quelltext. Nach Ho¨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 fu¨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 mu¨ssen, beschreibt eine Studie von Parnin und Rugaber [PR09].
Die Frage nach dem Einfluss von verschiedenen Codecharakteristika auf das Programmverstehen hat in den letzten Jahren zu einer Reihe von Untersuchungen gefu¨hrt. Eine a¨ltere Studie von Arab [Ara92] untersucht, inwieweit die Formatierung von Quelltext und Kommentare das Programmverstehen unterstu¨tzen ko¨nnen. Weitere Studien u¨ber den Nutzen von Dokumentation stammen unter anderem von [BC05, DH09a, DH09b, SPL+88]. Alle Untersuchungen haben gezeigt, dass verschiedene Codecharateristika das Programmverstehen beeinflussen.
Inwieweit sich geschlechtsspezifische Unterschiede bei der ra¨umlichen Wahrnehmung auf den Verstehensprozess u¨bertragen lassen, untersuchen Fisher et al. [FCZ06] basierend auf der Hypothese von Cox et al. [CFO05], dass sich zwischen dem Programmverstehen und der Raumkognition Gemeinsamkeiten identifizieren lassen. Diese Studie ist eine der wenigen, die explizit die Unterschiede des Programmverstehens hinsichtlich des Geschlechtes betrachtet. 5
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 hauptsa¨chlich Experimente mit relativ kleinen Programmen zu Grunde. Die meisten Untersuchungen wurden zudem nur mit einer kleinen Anzahl von Teilnehmern durchgefu¨hrt, wodurch sich die Frage nach der Verallgemeinerbarkeit der Ergebnisse stellt. Es fehlen Aussagen zu gro¨ßeren Systemen sowie eine klare Methodologie fu¨r das Programmverstehen, die methodisches Vorgehen nach der Wartungsaufgabe differenziert. Außerdem liegen viele der Studien bereits Jahrzehnte zuru¨ck, und die heutige Gu¨ltigkeit der Ergebnisse angesichts moderner Programmiersprachen und Entwicklungsumgebungen steht in Frage. Die Trends der heutigen Softwareprojekte, wie z.B. das sta¨rkere Einbinden von Open-Source-Komponenten, die zunehmende Verteilung der Entwickler oder die ku¨rzeren Entwicklungszyklen, haben auch zu neuen Erkenntnisse u¨ber die Entwicklungsmethoden, die Eigenschaften der entwickelten Programme und das Verhalten der Entwickler gefu¨hrt. Das hinterfragt zusa¨tzlich die fru¨heren Erkenntnisse u¨ber das Programmverstehen und erho¨ht den Bedarf nach aktuellen, detaillierten und signifikanten Untersuchungen.
Auf Basis unserer Literaturstudie zum Thema Programmverstehen formulieren wir die folgenden offenen Fragen, die zuku¨nftige Forschung adressieren sollte:
Vorgehensweisen: Wie gehen Programmierer – abha¨ngig von der Art ihrer Aufgabe – genau vor, wenn sie Programme a¨ndern sollen? Aus welchen Einzelaktivita¨ten besteht der Programmverstehensprozess fu¨r welche Art von Aufgaben? Welche Informationen werden abha¨ngig von der Aufgabe beno¨tigt? Warum gehen Programmierer so vor? Worin unterscheiden sich die Vorgehensweisen unterschiedlicher Programmierer? Welche Vorgehensweisen fu¨hren eher zum Erfolg? Aufwand: Wie hoch ist der Aufwand des Programmverstehens in der Wartungsphase im Verha¨ltnis zu A¨nderung und Test? Wie hoch ist der Aufwand der Einzelaktivita¨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 fu¨r ihren Zweck? Wie lassen sie sich verbessern? Fu¨r welche Aspekte existiert noch unzureichende Werkzeugunterstu¨tzung? Welches Wissen kann kaum von Werkzeugen verwaltet werden? Methoden: Was sind gut geeignete Vorgehensweisen beim Programmverstehen fu¨r wiederkehrende Aufgabenarten? Welche Informationen und Werkzeuge sind geeignet, um diese Vorgehensweisen zu unterstu¨tzen? Code-Strukturen: Welche Auswirkungen haben die Bad Smells von Beck und Fowler auf das Programmversta¨ndnis? Einfluss von Architektur Wie wird Architektur in der Praxis dokumentiert? Wie wird sie von Programmierern benutzt? Welche Probleme gibt es fu¨r den Austausch des Architekturwissens? Wissenschaftliche Methoden: Welche Methoden aus den Sozial- und Kognitionswissenschaften und der Psychologie lassen sich fu¨r die Forschung im Programmverstehen wie u¨bertragen? Wie ko¨nnen empirische Beobachtungen und Experimente durch Softwaresysteme unterstu¨tzt werden? Literatur [AHL06] [AN91] [Ara92] [Art88] [BC05] [BR04] [Bro83] [CC90] [CFO05] [CSW02] [DH09a] [DH09b]
L.C. Arisholm, E.and Briand, S.E. Hove und Y. Labiche. The impact of UML documentation on software maintenance: an experimental evaluation. IEEE Computer Society TSE, 32(6):365–381, Juni 2006.
A. Abran und H. Nguyenkim. Analysis of maintenance work categories through measurement. In Software Maintenance, 1991., Proceedings. Conference on, Seiten 104– 113, Oct 1991.
Mouloud Arab. Enhancing program comprehension: formatting and documenting. SIGPLAN Not., 27(2):37–46, 1992.
Scott Blinman und Andy Cockburn. Program comprehension: investigating the effects of naming style and documentation. In Proc. of AUIC’05, Seiten 73–78, Darlinghurst, Australia, Australia, 2005. Australian Computer Society, Inc.
M. Bennicke und H. Rust. Programmverstehen und statische Analysetechniken im Kontext des Reverse Engineering und der Qualita¨tssicherung, April 2004. Virtuelles Software Engineering Kompetenzzentrum.
Ruven E. Brooks. Towards a Theory of the Comprehension of Computer Programs. IJMMS, 18(6):543–554, 1983.
Elliot J. Chikofsky und James H. Cross. Reverse Engineering and Design Recovery: a Taxonomy. IEEE Software, 7(1):13–17, Januar 1990.
Anthony Cox, Maryanne Fisher und Philip O’Brien. Theoretical Considerations on Navigating Codespace with Spatial Cognition. In Proc. of PPIG’05, Seiten 92–105, 2005.
Martha E. Crosby, Jean Scholtz und Susan Wiedenbeck. The Roles Beacons Play in Comprehension for Novice and Expert Programmers. In Proc. PPIG’02, Seiten 18–21, 2002.
Uri Dekel und James Herbsleb. Improving API Documentation Usability with Kneowledge Pushing. In Proc. of ICSE’09, 2009. [FCZ06] [FH79] [HT06] [HTBK09] [KAM05] [KDV07] [Ko03] [KP96] [KR91] [KS97] [Lak93] [Let86] [Let88] [LOZP06] [LP06] [LPLS86] [LS81] [LS86] [Mar83] [MN97] [MW01]
Maryanne Fisher, Anthony COx und Lin Zhao. Using Sex Differences to Link Spatial Cognition and Program Comprehension. In Proc. ICSM’06, Seiten 289–298, Washington, DC, USA, 2006. IEEE Computer Society.
R.K. Fjeldstad und W.T. Hamlen. Application Program Maintenance Study: Report to our Respondents. In Proc. of GUIDE 48, Philadelphia, PA, 1979.
Andreas Ho¨fer und Walter F. Tichy. Status of Empirical Research in Software Engineering. In Empirical Software Engineering Issues, Seiten 10–19, 2006.
Khaled Hussein, Eli Tilevich, Ivica Ico Bukvic und SooBeen Kim. Sonification DEsign Guidelines to Enhance Program Comprehension. In Proc. ICPC’09, Seiten 120– 129, Vancouver, Canada, 2009. IEEE Computer Society.
Andrew J. Ko, Htet Htet Aung und Brad A. Myers. Eliciting Design Requirements for Maintenance-Oriented IDEs: A Detailed Study of Corrective and Perfective Maintenance Tasks. In Proc. ICSE’05, Seiten 126–135, 2005.
Andrew J. Ko, Robert DeLine und Gina Venolia. Information Needs in Collocated Software Development Teams. Proc. ICSE’07, Seiten 344–353, 2007.
Andrew Jensen Ko. Individual Differences in Program Comprehension Strategies in an Unfamiliar Programming System. In IWPC’03, 2003.
R. Koschke und E. Plo¨dereder. Ansa¨tze des Programmverstehens, Seiten 159–176. Deutscher Universita¨tsverlag/Gabler Vieweg Westdeutscher Verlag, 1996. Editor: Franz Lehner.
Ju¨rgen Koenemann und Scott P. Robertson. Expert problem solving strategies for program comprehension. In Proc. of SIGCHI’91, Seiten 125–130, New York, NY, USA, 1991. ACM.
Chris F. Kemerer und Sandra Slaughter. Methodologies for Performing Empirical Studies: Report from WESS’97. EMSE, 2(2):109–118, Juni 1997.
Arun Lakhotia. Understanding someone else’s code: Analysis of experiences. JSS, 23(3):269–275, 1993.
Stanley Letovsky. Cognitive Processes in Program Comprehension. In Workshop ESP, Seiten 58–79, Norwood, NJ, USA, 1986. Ablex Publishing Corp.
Stanley Letovsky. Plan analysis of programs. Bericht Research Report 662, Yale University, Dezember 1988.
Andrea De Lucia, Rocco Oliveto, Francesco Zurolo und Massimiliano Di Penta. Improving Comprehensibility of Source Code via Traceability Information: a Controlled Experiment. Proc. of ICPC’06, 0:317–326, 2006.
Giuseppe A. Di Lucca und Massimiliano Di Penta. Experimental Settings in Program Comprehension: Challenges and Open Issues. In Proc. of ICPC’06, Seiten 229–234, Washington, DC, USA, 2006. IEEE Computer Society.
D. C. Littman, Je. Pinto, S. Letovsky und E. Soloway. Mental Models and Software Maintenance. In Workshop ESP, Seiten 80–98, Norwood, NJ, USA, 1986. Ablex Publishing Corp. Reprinted in Journal Systems and Software 7, 4 (Dec. 1987), 341–355. Bennet P. Lientz und E. Burton Swanson. Problems in application software maintenance. Commun. ACM, 24(11):763–769, 1981.
S. Letovsky und E. Soloway. Delocalized Plans and Program Comprehension. Software, IEEE, 3(3):41–49, May 1986.
James Martin. Software Maintenance the Problem and Its Solution. Prentice Hall, third printing. Auflage, 6 1983.
Gail C. Murphy und David Notkin. Reengineering with Reflexion Models: A Case Study. IEEE Computer, 30(8):29–36, August 1997. Reprinted in Nikkei Computer, 19, January 1998, p. 161-169.
Russel Mosemann und Susan Weidenbeck. Navigation and Comprehension of Programs by Novice Programmers. In Proc. of IWPC’01, Seite 79, Washington, DC, USA, 2001. IEEE Computer Society. [MWB98] G. Murphy, R. Walker und E. Baniassad. Evaluating Emerging Software Development Technologies: Lessons Learned from Assessing Aspect-oriented Programming.
Technical Report TR-98-10, University of Britsh Columbia, Computer Science, 1998. [Pen87] N. Pennington. Comprehension Strategies in Programming. In Workshop ESP, Seiten 100–113, Norwood, NJ, USA, 1987. Ablex Publishing Corp. [PR09] Chris Parnin und Spencer Rugaber. Resumption Strategies for Interrupted Programming Tasks. Proc. of ICPC’09, 0:80–89, 2009. [PRW04] Michael J. Pacione, Marc Roper und Murray Wood. A Novel Software Visualisation Model to Support Software Comprehension. In Proc. of WCRE’04, Seiten 70–79, Washington, DC, USA, 2004. IEEE Computer Society. [PSK07] Massimiliano Di Penta, R. E. Kurt Stirewalt und Eileen Kraemer. Designing your Next Empirical Study on Program Comprehension. In ICPC, Seiten 281–285. IEEE Computer Society, 2007. [PULPT02] L. Prechelt, B. Unger-Lamprecht, M. Philippsen und W.F. Tichy. Two controlled experiments assessing the usefulness of design pattern documentation in program maintenance. IEEE Computer Society TSE, 28(6):595–606, Juni 2002. [RCM04] M. Robillard, W. Coelho und G. Murphy. How Effective Developers Investigate Source Code: An Exploratory Study. IEEE Computer Society TSE, 30(12):889–903, 2004. [RR08] R. L. Rosnow und R. Rosenthal. Beginning behavioral research: A conceptual primer.
Pearson/Prentice Hall, 6th. Auflage, 2008. [Rug92] Spencer Rugaber. Program Comprehension for Reverse Engineering. In AAAI Workshop, Juli 1992. [SDVFM05] J. Sillito, K. De Voider, B. Fisher und G. Murphy. Managing software change tasks: an exploratory study. In ESE’05, Seiten 10 pp.–, Nov. 2005. [SE84] Elliot Soloway und Kate Ehrlich. Empirical Studies of Programming Knowledge.
IEEE TSE, 10(5):595–609, 1984. [SG09] Andreas Stefik und Ed Gellenbeck. Using Spoken Text to Aid Debugging: An Emperical Study. Proc. of ICPC’09, 0:110–119, 2009. [SLVA97] Janice Singer, Timothy Lethbridge, Norman Vinson und Nicolas Anquetil. An examination of software engineering work practices. In Proc. of CASCON’97, Seite 21. IBM Press, 1997. [SM79] B. Shneiderman und R. Mayer. Syntactic/Semantic Interactions in Programmer Behavior: A Model and Experimental Results. IJCIS, 8(3):219–238, 1979. [SPL+88] E. Soloway, J. Pinto, S. Letovsky, D. Littman und R. Lampert. Designing Documentation to Compensate for Delocalized Plans. Commun. ACM, 31(11):1259–1267, November 1988. [SWM00] M.-A. D. Storey, K. Wong und H. A. Mu¨ller. How do program understanding tools affect how programmers understand programs? Science of Computer Programming, 36(2–3):183–207, 2000. [Tic98] Walter F. Tichy. Should computer scientists experiment more? IEEE Computer, 31(5):32–40, Mai 1998. [TS96] Scott R. Tilley und Dennis B. Smith. Coming Attractions in Program Understanding.
Bericht, Software Engineering Institute, Pittsburgh, PA 15213, Dezember 1996. [vMV93] Anneliese von Mayrhauser und A. Marie Vans. From Program Comprehension to Tool Requirements for an Industrial Environment. In IWPC, Seiten 78–86. IEEE Computer Society Press, Juli 1993. [vMV95] Anneliese von Mayrhauser und A. Marie Vans. Program Comprehension During Software Maintenance and Evolution. IEEE Computer, 28(8):44–55, 1995. [vMVL98] Anneliese von Mayrhauser, A. Marie Vans und Steve Lang. Program Comprehension and Enhancement of Software. In Proc. of the IFIP World Computing Congress. IEEE, August-September 1998.