Softwarearchitektur und Agile EntwicklungExperimentaufbau zur toolgestutzten Architekturrekonstruktion

Leon Fausten

Hochschule fur Angewandte Wissenschaften Hamburg, DeutschlandEmail: leon.fausten@haw-hamburg.de

I. EINLEITUNG

Um eine Anwendung am leben zu halten, muss dieseregelmaßig gewartet werden. Dazu gehort die Korrektur vonFehlern und die Implementierung von neuen Funktionalitaten.Um Anderungen erfolgreich und effizient durchfuhren zukonnen, ist es erforderlich zu wissen, wo angesetzt werdenmuss. Dafur muss die Architektur der Anwendung bekanntsein.[1] Der Wartungsprozess ist der zeitaufwendigste undteuerste Abschnitt der Softwareentwicklung. Die meiste Zeitgeht dabei verloren, ein Verstandnis fur die Software zuentwickeln. [2] Wenn die Erweiterungen und Wartungen durchPersonen durchgefuhrt werden, die lange nicht, oder sogarnoch nie an dem Projekt gearbeitet haben, mussen diese sichvorerst in das Projekt einarbeiten. Die Einarbeitung in eingroßes Projekt kann sehr komplex und zeitaufwendig sein.Die zur Verfugung stehenden Unterlagen, um ein Projektkennen zu lernen, sind in den meisten Fallen sehr unter-schiedlich. Dies hangt sehr von der vorhandenen Dokumen-tation und der Art der Umsetzung ab. In manchen Projektenist eine genaue schriftliche Dokumentation vorgegeben, an-dere verzichten vollstandig auf diese und setzen nur auf reinmundliche Absprachen. Je nach Anwendungsfall und Adressat,werden unterschiedliche Informationen uber die Architekturbenotigt, dadurch wird eine allumfassende Dokumentationsehr groß und unubersichtlich. Dies ist in einem Dokumentschwer umzusetzen, da sich dort, fur alle Personen, allerelevanten Informationen befinden mussen. Bei solchen großenDokumenten entsteht die Schwierigkeit, in der Masse derInformationen, die von den Einzelpersonen benotigten Infor-mationen gezielt in akzeptabler Zeit zu finden. Je großer undausfuhrlicher die Dokumentation ist, desto schwieriger wirdes die gesuchten Informationen zu finden.[3] Der Umfang,fur viele unterschiedliche angepasste Dokumentationen, istschwer abzustecken, außerdem mussen diese jeweils einzelngepflegt werden. Die manuelle Pflege im Allgemeinen kostetviel Zeit und wird dadurch schnell vernachlassigt.[4] Diebenotigten Informationen sollten mithilfe einer einfachen,schnell durchfuhrbaren Suche gefunden werden konnen.[5]

Im Grundseminar1 wurde beschrieben, welche Problemedie Agile Entwicklung fur die Entwicklung der Architekturmitbringt. Die Architektur wird in vielen Fallen nicht mehrexplizit geplant, sondern entsteht als ein Nebenprodukt derImplementation. Dadurch ist diese haufig nicht gut strukturiertund unubersichtlich. Dies fallt besonders bei Projekten mitvielen unterschiedlichen Entwicklern auf.

1http://users.informatik.haw-hamburg.de/ ubicomp/projekte/master14-15-gsm/fausten/bericht.pdf

Im Grundprojekt2 wurden die Moglichkeiten des Mo-nitorings und der Visualisierung der Architektur diskutiert.Um stets die aktuelle Architektur monitoren zu konnen, isteine automatische Architekturrekonstruktion notwendig. DieAusarbeitung des Grundprojektes beinhaltet eine Vorstellungund kurze Analyse von Tools und Bibliotheken, die diesbewerkstelligen konnen. Diese konnen neben der Berechnungvon Metriken zu Abhangigkeiten und ahnlichem, teilweiseUML-Diagramme erzeugen, Aussagen uber die Code Qualitatmachen oder bekannte Programmiermuster (Pattern) erkennen.

Eine alleinige manuelle schriftliche Dokumentation derArchitektur ist nur in den wenigsten Fallen praktikabel. DieErstellung und Wartung ist sehr aufwendig. In den meistenFallen ist diese deshalb entweder nicht vorhanden oder veraltetund entspricht dadurch nicht mehr der realen Umsetzung.Schnelle Veranderungen in der Software konnen in den meistenFallen nicht durch die Dokumentation abgebildet werden,weil den Entwicklern die entsprechende Zeit dazu fehlt.[6]Eine grafische Visualisierung der Anwendung ermoglicht einbesseres und schnelleres Verstandnis des Softwaredesigns undder Funktionalitaten zu erhalten.[2] Interaktive Graphiken, mitdenen sich manuell durch die Architektur navigiert werdenkann sind hilfreich. In den vorherigen Arbeiten wurden Tools,die dies bewerkstelligen konnen hauptsachlich beschrieben,ohne dass dies praktisch evaluiert wurden.

Eine Evaluierung, ob eine toolgestutzte Dokumentationdurch eine automatische Rekonstruktion auch in der Re-alitat hilfreich ist, steht noch aus. Es ist weiterhin offen, obzusatzliche Tools einen merkbaren Vorteil bei der Entwicklung,im Vergleich zu Standard Entwicklungsumgebungen bringen.Innerhalb dieser Arbeit werden deshalb zu Anfang in KapitelII bereits vorhandene Evaluierungen vorgestellt und bewertet.Anschließend wird in Kapitel III ein moglicher Experimentauf-bau beschrieben. Dieser soll sowohl das Vorgehen, bestehendaus der Aufgabenstellung, der Vorstellung der zur Verfugungstehenden Toolchain, sowie die Art der Auswertung bein-halten. Nach der Vorstellung des Versuchsaufbaus, wird derAufbau in einem eingeschrankten Selbstversuch in Kapitel IVdurchgefuhrt und die Ergebnisse dessen vorgestellt. Am Endedieser Arbeit (Kapitel V) werden der Experimentaufbau unddie Ergebnisse des Versuches bewertet und, wenn moglichAnderungsvorschlage erarbeitet, welche in den Aufbau ein-fließen sollen. Mogliche weitere Aspekte fur einen sinnvollenEinsatz der Tools werden genannt.

2http://users.informatik.haw-hamburg.de/ ubicomp/projekte/master2015-proj/fausten.pdf

II. AHNLICHE ARBEITEN

Viele der vorhandenen Anwendungen wurden mit einemwissenschaftlichem Hintergrund entwickelt und wurden de-shalb zum großen Teil nur innerhalb eines Experimentesevaluiert. Ergebnisse dieser Evaluationen werden in diesemAbschnitt gesammelt und zusammengefasst.

Kobayashi und andere [7] haben ihre entwickelte Tech-nik SArF Map mithilfe mehrerer Fallstudien uberpruft. IhreTechnik beinhaltet die Visualisierung von Funktionalitatenund Schichten mithilfe einer stadtahnlichen Darstellung. DieDarstellung wird mithilfe eines zuvor entwickelten Clustering-Algorithmus zur Abhangigkeitsanalyse durchgefuhrt. Dieentstehenden Graphen sollen ebenfalls fur Nicht-Entwicklerverstandlich sein und als gutes Mittel zur Kommunikationdienen konnen. Klassen werden als Hauser dargestellt undVerbindungen zwischen ihnen als Straßen. Straßenblockestellen Funktionalitaten dar. Die Stadtdarstellung beschreibensie im Allgemeinen sehr positiv, da sie sehr intuitivVerstandlich und fur viele unterschiedliche Metriken geeignetist. Außerdem konnen mehrere Metriken zur gleichen Zeitbetrachtet werden, ohne dafur zwischen Darstellungen wech-seln zu mussen. Um den Nutzen zu uberprufen, wurden funfFallstudien mit Open Source und kommerziellen Java An-wendungen durchgefuhrt. In einem Beispiel konnte erfolgreicherkannt werden, dass ein Package weit verstreut, an vielen ver-schiedenen Stellen auftaucht, dies bedeutet, dass dieses Pack-age weiter aufgeteilt werden sollte. Durch die Moglichkeit aufeine vorhandene Dokumentation zuruckgreifen zu konnen odersogar die Entwickler fragen zu konnen, konnte sichergestelltwerden, dass die Anwendungen korrekt analysiert wurden. DieFallstudien haben nur untersucht, ob die durchgefuhrten Anal-ysen korrekte Ergebnisse liefern. Wie sie allerdings ebenfallsfestgestellt haben, mussen weitere Studien zeigen, wie hilfreichdiese Visualisierungen in der Praxis sind. Schwachstellen imAlgorithmus, wie z.B. wenn sich mehrere Features uberlappen,wurden festgestellt. Außerdem ist die Darstellung abhangigvon der Qualitat des gelieferten Abhangigkeitsgraphen. DerGraph kann zuvor berechnet oder mitgeliefert werden. Bei derVerwendung von Techniken, wie Reflection oder DependencyInjection ist es moglich, dass unvollstandige Stadtdarstellungengeneriert werden.[7]

Caserta und andere [2] haben eine sehr ausfuhrlicheStudie zur Visualisierung von Anwendungen durchgefuhrt unddabei zahlreiche Darstellungsmoglichkeiten und vorhandeneAnwendungen betrachtet. Ziel ihrer Untersuchung war es her-auszufinden, wie hilfreich diese im praktischen Einsatz sind.Sie haben festgestellt, dass man die Analysen und die darausentstehenden Visualisierungen in drei Kategorien (statisch,dynamisch und evolutionar) unterteilen kann. Bei statischenAnalysen wird nur der Source Code betrachtet, dieser ist beijeder Art von Ausfuhrung gultig. Dynamischen Analysen be-trachten einzelne, spezielle Ausfuhrungsstrange zur Laufzeit.Die evolutionaren Analysen fugen eine Zeitkomponente zuder statischen Analyse hinzu. Dadurch ist erkennbar, wie eineSoftware weiterentwickelt wurde. In ihrer Untersuchung habensie allerdings nur die statischen Analysen und die Evolutiondieser betrachtet.3D Darstellungen haben im Vergleich zu 2D Darstellungenden Vorteil, dass in ihnen mehr Informationen gleichzeitigprasentiert werden konnen. Dies erhoht aber die Gefahr

der Informationsuberladung. Dadurch wird die Darstellungunter Umstanden zu unubersichtlich. Die Visualisierung einerKlassenstruktur, inklusive der Darstellung von Abhangigkeiten(Methoden Aufrufe und ahnliches) stellt z.B. Informationendar, fur dessen Erkennung der Quellcode ansonsten vollstandigdurchgegangen werden musste. Wenn allerdings zu vieleKlassen auf einmal prasentiert werden, wird die Darstellungschnell sehr unubersichtlich.Ein Baum Model (wie in Abbildung 1a) eignet sich gut umPakete, Klassen und Methoden Strukturen darzustellen, wer-den aber bei großen komplexen Strukturen ebenfalls schnellsehr unubersichtlich. Ein Treemap Model kann Hierarchienebenfalls gut widerspiegeln, nutzt den verfugbaren Platz, imVergleich zu normalen Baum Strukturen, erheblich effektiveraus. Abbildung 1b zeigt eine aquivalente Treemap Struktur, imVergleich zur Baumstruktur in Abbildung 1a. Die Darstellungwird erheblich kompakter, die Strukturen sind aber nur nochindirekt ersichtlich. In der zirkulare Treemap, in Abbildung1c, sind die Strukturen mithilfe von Kreisen verdeutlicht.Die Hierarchien kommen hier wieder deutlicher, dadurch dassubergeordnete Knoten ihre Kinder auch visuell beinhalten,zum Vorschein Der Platz wird aber nicht mehr so effizient,wie bei der Treemap, ausgenutzt. Abbildung 1d zeigt eineSunburst Darstellung. Diese ist von innen nach außen aufge-baut und stellt dadurch die Strukturen ebenfalls vollstandigund einfacher verstandlich, als eine Treemap dar. Experimente[8] haben allerdings gezeigt, dass das Finden von Elementenin Treemaps und in Sunbursts keine relevanten Unterschiedebei der Geschwindigkeit aufweist. Die Sunburst Darstellungist allerdings schwieriger zu verstehen. Die Darstellung alsStadt haben Caserta und andere ebenfalls untersucht. DieseDarstellungsart ist intuitiv verstandlich. Der Betrachter hataußerdem die Moglichkeit in die Stadt rein zu zoomen um De-tails genauer betrachten zu konnen. Da nicht alle Eigenschaftenauf die Stadtmetapher abgebildet werden konnen, mussenInformationen teilweise vereinfacht werden (z.B. Metriken inBereiche zusammenfassen). Es wurde allerdings festgestellt,dass dies sogar das einfachere Verstandnis fordert.Baumartige Graphen eignen sich gut um Beziehungen zu visu-alisieren. Beziehungen konnen z.B. Vererbungen oder Metho-denaufrufe sein. Die entstehenden Graphen konnen dabei sehrunubersichtlich, durch zahlreiche sich uberlappende Beziehun-gen, werden. Alternativ werden Beziehungen haufig eben-falls gerne mithilfe einer quadratischen Matrix dargestellt.Die Anzahl der Beziehungen zwischen einer Entitat einerReihe und einer Entitat einer Zeile werden dort notiert. DieAnzahl reprasentiert die Anzahl der Verbindungen, die inner-halb eines Graphen zwischen zwei Punkten notwendig waren.UML-Klassendiagramm sind graph-basierte Darstellungen. IhrZiel ist es Vererbungen, Generalisierungen, Assoziationen,Aggregationen und Kompositionen darzustellen. Damit dieKomplexitat großer UML-Diagramme verringert wird, wirdvorgeschlagen, die sich uberlappenden Verbindungen zu re-duzieren. Dies kann z.B. durch die Vereinigung von Verbindun-gen, mit identischem Ziel oder einem festgelegtem orthogo-nalem Layout geschehen. Fur eine bessere Ubersicht habenmanche Tools Funktionalitaten, um z.B. nur Methodenaufrufeeiner bestimmten Klasse darzustellen umgesetzt.Statische Software Metriken sind berechnete Zahlenwerte. Siekonnen Aussagen uber System Stabilitat, Ressourcennutzungund Design Komplexitat machen. Metriken zur Kopplungkonnen z.B. im zuvor vorgestellten Stadt Design angezeigt

2

werden. Je starker die Kopplung ist, desto naher sind zweiGebaude. Diese Darstellung ist sehr intuitiv verstandlich, kannaber bei Veranderungen verwirren, da es vorkommen kanndass sich das allgemeine Layout schnell andert. Metriken,wie z.B. die Anzahl der Methoden oder der Klassengroßeallgemein konnen an die Hauserhohe oder Breite gebundenwerden. Um die visuelle Komplexitat zu verringern, wirdempfohlen die unterschiedlichen Hohen auf maximal funf zubegrenzen. Dies kann z.B. durch das Aufteilen in Bereicheerreicht werden.[9][10][2]

Panas und andere [11] nennen einen wichtigen Punkt beiindividuellen Visualisierungen je nach Stakeholdertyp. Durchdie unterschiedlichen Darstellungen wird die Kommunikationzwischen Gruppen schwierig, da alle nur die fur sie gedachtenDarstellungen kennen. Aus diesem Grund empfehlen sie eineallgemein gultige Visualisierung, die alle notwendigen Infor-mationen enthalt.

Im Allgemeinen ist zu erkennen, dass alle festgestellthaben, dass Visualisierungen helfen, es existiert aber einegroße Gefahr, dass Darstellungen schnell zu groß und Kom-plex werden. Dies betrifft vor allem den Einsatz innerhalbgroßer Software Projekte. Fur diese ist solch eine automa-tisierte Dokumentation und Visualisierung allerdings beson-ders wichtig, da diese nicht einfach ohne Hilfe uberblicktwerden konnen. Außerdem sind Anwendungen entsprechenderGroße im Normalfall sehr lange in Verwendung und mussendadurch dauerhaft gewartet und erweitert werden. Aus diesemGrund sind interaktive Darstellungen, die anfanglich eine starkvereinfachte Struktur darstellen und bei Bedarf Details schrit-tweise einblenden konnen sehr wichtig.

III. EXPERIMENTAUFBAU

Zur Evaluierung der Tools wird ein Versuchsaufbau er-arbeitet. Dieser wird anschließend in einem Selbstversuchevaluiert. Zu dem Aufbau gehort die Vorstellung unter-schiedlicher Ausgangsszenarien, die Auswahl der wahrend desExperiments zur Verfugung stehenden Tools, sowie die Art derEvaluierung im Anschluss.

A. Szenarien

Die Aufgabe in jedem Szenario ist die gleiche. EinemEntwickler wird die Aufgabe gegeben an einer bereits vorhan-denen Anwendung zu arbeiten. Es sollen entweder Fehlerbehoben oder eine neue Funktionalitat entwickelt werden. DieEntwickler mussen die Stellen im Code finden, an denen siefur Anderungen ansetzten mussen.

Im Folgenden werden drei unterschiedliche Ausgangssitu-ationen beschrieben, die ebenfalls unter realen Bedingungendenkbar sind.

Szenario A: Der Entwickler kennt das Projekt und hat bereitsfruher an diesem gearbeitet. Das Projekt wurde seit mindestenseinem halben Jahr nicht weiter entwickelt. Der Entwicklerkennt die Strukturen dadurch nur noch grob. Er kann sich abereventuell schneller wieder an den Aufbau und die Grunde dafurerinnern, nachdem er sich wieder etwas eingearbeitet hat.

Szenario B: Die Erweiterung wird von einem Entwicklerdurchgefuhrt, fur den das Projekt neu ist. Fur den Entwickler

ist es moglich ursprungliche am Projekt beteiligte Entwick-ler zu kontaktieren um nach Unterstutzung zu fragen. Diesekonnen ihm Tipps geben, um die Aufgabe zu losen unddie Struktur der Anwendung vorstellen. Der Erfolg diesesSzenarios ist sehr von der Unterstutzungsbereitschaft der ur-sprunglichen Entwickler abhangig. Wenn die Testperson aneinem Open Source Projekt mit einer großer Communityentwickelt, ist es wahrscheinlicher, zeitnah die gewunschtenAntworten zu bekommen, als bei einem Projekt mit einemeinzelnen schwer erreichbaren Entwickler. Fur die Testpersonist es am besten, wenn es sich um ein Projekt innerhalb desgleichen Arbeitsumfeldes, bei dem er die ursprunglichen En-twickler personlich auf kurzem Weg ansprechen kann, handelt.

Szenario C: Die Erweiterung wird von einem Entwicklerdurchgefuhrt, fur den das Projekt neu ist. Im Unterschiedzu Szenario B hat dieser nicht die Moglichkeit mit einemfruheren Entwickler Kontakt aufzunehmen, um diesen umUnterstutzung zu beten. Die ursprunglichen Entwickler sindentweder nicht auffindbar oder wollen, bzw. konnen nichthelfen. Dadurch ist die Person vollstandig auf sich alleinegestellt und muss sich alles selbst erarbeiten. Fragen zuBeweggrunden oder zu komplexen Strukturen muss er sicheigenstandig erschließen.

In allen Szenarien wird die vollstandige, lauffahige Anwen-dung zur Verfugung gestellt. Bereits existierende Dokumen-tationen stehen in allen Szenarien zur Verfugung. In denSzenarien kann sich sowohl an diesen orientiert werden, sowieauch an der Dokumentation innerhalb des Quellcodes. Fallsdie Dokumentation der Anwendung sehr ausfuhrlich ist, kanndiese im Rahmen des Experiments gekurzt werden oder denTeilnehmern vorenthalten werden. Dadurch kann zusatzlichgepruft werden, ob dieser der realen Umsetzung entspricht.Dies hat den Grund, dass in vielen Projekten keine oder einenicht aktuelle Dokumentation existiert. Oft ist die Dokumenta-tion außerdem sehr kurz gehalten, mit nur minimal nutzlichenInformationen fur Weiterentwicklung und Wartung.

Jedes Szenario wird dabei mit zwei unterschiedlichenAufbauten durchgefuhrt. Im ersten Aufbau stehen nur dieInfos und Moglichkeiten, wie in der Szenariobeschreibung,zur Verfugung. Im zweiten Aufbau wird eine zuvor festgelegteToolchain zur Verfugung gestellt. Diese soll es erleichtern, dienotwendigen Ansatzpunkte fur die erforderliche Anderungenzu finden. Die Probanden bekommen eine Einweisung in dieToolchain.

Geplant ist, nur Szenario C in einer praktischen Evalua-tion zu uberprufen, da diese den extrem Fall, ohne jeglicheHilfe durch Dritte darstellt. Dazu muss zuvor allerdingssichergestellt werden, ob diese Szenarien sich wirklich in derArt ahneln und die Szenarien A und B nur abgeschwachte Aus-gangssituationen zu C sind. Es stellt sich die Fragen, ob in denbeiden anderen Szenarien nicht andere Informationen benotigtwerden, da das Kennenlernen der Anwendung unter Anleitungdurch andere, bzw. durch eigene Kenntnisse geschieht.

B. Toolchain

Bei einer Reihe der Durchfuhrungen durfen die Testperso-nen eine Toolchain zur Unterstutzung verwenden, diese wirdin diesem Abschnitt genauer vorgestellt. Die Testpersonen

3

Abbildung 1: Moglichkeiten Strukturen zu visualisieren [2]

ohne Toolchain, arbeiten mit einer Standard IDE, wie Eclipse3

oder IntelliJ4. Die Standard IDE steht den Testpersonen mitToolchain ebenfalls zusatzlich zur Verfugung.

Es werden zwei unterschiedliche Tools zur Verfugunggestellt, zum einen Sonarqube5 und die IDE Understand6.

1) Sonarqube: Sonarqube [12] ist eine Open Source Plat-tform um Codequalitat zu managen. Sonarqube ist mit vielenunterschiedlichen Plugins erweiterbar. Die Funktionalitatenund die eingesetzten Plugins, die fur das Experiment eingesetztwerden, werden hier vorgestellt. Sonarqube besteht aus zweiTeilen, einem Server mit Webinterface, der die Informationendarstellt und zur Administration und Datenhaltung der Analy-sen dient. Der zweite Teile ist der Sonar-Runner, dieser fuhrtdie eigentlichen Analysen durch und sendet die Daten an denServer. Er muss auf dem Rechner ausgefuhrt werden, auf demsich der Sourcecode befindet. Dies kann auf einem Buildserver,oder auch direkt auf den Entwicklerrechnern geschehen. Furweit verbreitete Entwicklungsumgebungen, wie z.B. Eclipseund IntelliJ existieren Plugins, die es ermoglichen die Anal-ysen direkt aus diesen durchzufuhren. Analysen konnen vonbeliebig vielen Clients eingereicht werden. Die im Beispielverwendeten Grafiken wurden, wie im Grundprojekt, mit demOpen Source Android Mail Client K9 generiert.

Innerhalb einer Instanz konnen mehrere unterschiedlicheProjekte analysiert werden. Fur jedes Projekt lasst sich eineigenes unabhangiges Dashboard einrichten. Projekte konnenmiteinander verglichen werden.

Fur die meisten Analysen reicht der reine Quellcode aus,fur die Abhangigkeitsanalysen werden zusatzlich die kom-pilierten Quelldateien benotigt.

Der Aufbau der Anwendung kann mithilfe einer Treemap(Abbildung 2) dargestellt werden. Durch klicken auf dieeinzelnen Pakete kann man bis zur konkrete Datei zoomen.Die Große der Felder wird durch die Anzahl der Codezeilenbestimmt, die Farbe visualisiert die Anzahl der dupliziertenCodezeilen. Die Parameter sind beliebig konfigurierbar.

Abbildung 3 zeigt die Anwendung als Stadt7. In derDarstellung sind die Paketstrukturen ersichtlich. In der default

3https://eclipse.org/home/index.php4https://www.jetbrains.com/idea/5http://www.sonarqube.org/6https://scitools.com/7http://softvis3d.com/#/download

Abbildung 2: Sonarqube Treemap

Abbildung 3: Sonarqube SoftVis3d City

Ansicht reprasentiert die Hohe der Hauser, die Anzahl derCodezeilen. Die Breite wird durch die Komplexitat definiert.Wie auch bei der Treemap ist es moglich andere Parameterzur Visualisierung auszuwahlen. Innerhalb der Visualisierungist es moglich, durch die Auswahl eines Objektes, dessen Kindund Elternobjekte als Metainformationen zu erhalten. AndereTools/Plugins bieten an dieser Stelle erweiterte Informationenan, diese sind allerdings nicht kostenfrei oder als SonarqubePlugin erhaltlich.

Mithilfe eines Balkendiagramms kann man sich Tech-nische Schulden (Technical Depts) ansehen. Abbildung 4 zeigtdies beispielhaft fur die Android K9 App. Die technischenSchulden, werden in Kategorien, wie z.B. Wiederverwend-barkeit oder Testbarkeit eingeteilt. In dem Diagramm istz.B. ersichtlich, dass die Wartbarkeit Schulden von 49 Tagenhat. Dies heißt nach einer Schatzung, dass circa 49 Tagebenotigt werden um diese zu beheben. Die Probleme werdennach definierten Codequalitatsrichtlinien gefunden. Fur diese

4

Abbildung 4: Sonarqube Technische Schulden

Abbildung 5: Understand Klassendiagramm

kann dort ebenfalls eine geschatzte Losungsdauer angegebenwerden. Durch drauf klicken auf den Wert, kann bis zurentsprechenden Codestellen gesprungen werden. Die Problemewerden zusatzlich nach Wichtigkeit priorisiert. Die hochste Pri-oritat enthalt Probleme, die zu einem Blockieren der Anwen-dung fuhren konnen. Die niedrigste stellt nur Informationen,wie z.B. gefundene TODO Kommentare dar.

Abhangigkeiten werden, wie zuvor in Kapitel IIbeschrieben, mithilfe einer quadratischen Matrix dargestellt.Fur die K9-App werden allerdings keine Abhangigkeitengefunden.

In der Praxis muss sich zeigen, ob diese Informationenhelfen neue Features zu entwickeln oder ob sich diese eherfur ein Monitoring eignen.

2) Understand: Understand [13] ist eine eigenstandigeIDE. Sie wurde von Grund auf neu Entwickelt, mit direktintegrierten Moglichkeiten zur Architekturrekonstruktion.

Mithilfe der Anwendung ist es moglich Klassendiagramme,wie in Abbildung 5 zu generieren. Im dargestellten Beispielwurde die Analyse auf einer Datei ausgefuhrt. Es ist zuerkennen, dass in dieser Datei zwei Klassen definiert werden.Außerdem sieht man die offentlichen, sowie privaten Variablenund Methoden. Die Vererbungshierarchie ist uber die Baum-darstellung ersichtlich.

Abhangigkeiten konnen mithilfe drei verschiedenerDarstellungen betrachtet werden. Abbildung 6 zeigt, von

Abbildung 6: Understand Abhangigkeiten Von

Abbildung 7: Understand Abhangigkeiten

welchen Bestandteilen die untersuchte Datei abhangig ist. Dieandere Richtung wird in Abbildung 7 dargestellt. Hier wirdprasentiert, welche Dateien von der untersuchten abhangigsind. Die dritte Moglichkeit ist die Kombination aus denbeiden innerhalb eines Diagramms.

In dem Cluster Call By Butterfly Diagramm (Abbildung8) konnen ebenfalls Abhangigkeiten betrachtet werden. Hierkann mithilfe von Doppelklicks rein und rausgezoomt werden.Bei der Start-Darstellung (kein Zoom) wird die Beziehung vonDateien dargestellt. In der detailliertesten Darstellung sind diekonkreten Methodenaufrufe sichtbar (erkennbar oben links inder Abbildung). Je weiter in die Details reingezoomt wird,desto großer und dadurch unubersichtlicher wird der Graph.

Ahnlich zu Sonarqube kann eine Treemap generiert wer-den, diese kann nach Dateien, Klassen oder Methoden berech-net werden.Da die Anwendung eine IDE ist, besteht der Vorteil. dass derSourcecode direkt bearbeitet werden kann. Kompilieren derAndroid Anwendung ist aber nicht moglich.Ein weiteres hilfreiches Feature ist, dass alle berechnetenMetriken als CSV exportiert werden und dadurch außerhalbder Anwendung genutzt werden konnen.

Abbildung 8: Understand Cluster Call Butterfly

5

C. Experimentevaluierung

Damit gepruft werden kann, ob die Toolchain unterstutzendwirkt, muss dies evaluiert werden. Dies soll durch Beobach-tungen und Interviews geschehen.

Innerhalb von Sonarqube kann das Piwik8 Plugin zusatzlichintegriert werden. Dies ist eine Analyse Plattform, ahnlichwie Google Analytics9. Piwik funktioniert aber auch bei reininternen Webseiten. Dadurch lasst sich untersuchen, welcheSeiten besucht wurden und wie lange diese betrachtet wurden.Es kann leider nicht festgestellt werden, welche Grafiken genaubetrachtet wurden, falls nur die Sammlung auf dem Dashboardbetrachtet wird.

Zur Durchfuhrung werden Fragen erarbeitet, welche beiBeendigung des Experiments in einem personlichem Interviewals Leitfaden dienen sollen.

1) Wie war der erste Eindruck der Tools?2) Hat die Einfuhrung in die Tools geholfen?3) Wie haben Sie begonnen?

a) War dies hilfreich oder wurden Sie nachstesmal anders vorgehen?

4) Wie haben Sie die notwendigen Stellen fur dieAnderungen gefunden, wie sind Sie weiter vorgegan-gen?

5) Haben die Tools Sie eher abgelenkt oder unterstutzt?6) Welche Informationen haben Ihnen wahrend der

Bearbeitung gefehlt?7) Welche Visualisierung, welche Funktionalitat hatten

Sie sich zusatzlich gewunscht?8) Welche Fragen wurden sie den ursprunglichen Ent-

wicklern, der zu Bearbeitenden Anwendung, gerneweiterhin stellen, welche sind ihnen wahrend derBearbeitung gekommen?

9) Konnen Sie sich andere Einsatzmoglichkeiten fur dieVisualisierungen und Tools vorstellen?

10) Was hat Ihrer Meinung nach besonders zum Erfolgbeigetragen?

11) Was hat Ihrer Meinung nach am wenigsten zumErfolg beigetragen?

12) Welche Parameter finden Sie fur die Darstellungender Treemaps und der Stadtdarstellungen am hilfrei-chsten?

Die Fragen sollen als Leitfaden am Ende des Versuchs furein personliches Interview dienen. Diese konnen bei Bedarfim Gesprach angepasst und je nach Situation individualisiertund erweitert werden. Durch die Moglichkeit im Gesprachnachzuhaken, ist es moglich erst allgemeine Fragen zu stellenund diese bei Bedarf zu spezialisieren.

IV. SELBSTVERSUCH

In zwei kleinen Selbstversuchen soll uberpruft werden, obder Experimentaufbau sinnvoll ist. Dafur wird der Aufbau ineinem theoretischen Experiment uberpruft. Das Experimentwird, wie im Szenario C beschrieben, ohne Hilfe der ur-sprunglichen Entwickler durchgefuhrt. Das Programm und dieToolchain stehen, wie zuvor vorgestellt, zur Verfugung. Falls

8http://piwik.org/what-is-piwik/9http://www.google.com/analytics/

Abbildung 9: K9 Mail Titel Zeile

der Aufwand der Umsetzung zu hoch ist, soll statt der Umset-zung des gewunschten Features, bzw. Behebung des Bugs, nurgepruft werden, ob die Tools helfen, die richtigen Stellen zufinden, an denen angesetzt werden muss, um die gewunschteFunktionalitat zu entwickeln oder zumindest hilfreiche Ansatzeliefern kann.

Fur beide Selbstversuche soll erneut, wie im Grundprojektdie Android App K9-Mail10 dienen. Auf Github haben bereits132 Personen Anderungen und Erweiterungen in uber 5000Commits seit Oktober 2008 beigesteuert [14].

A. Versuch A: Darstellung des Betreffs

Im Selbstversuch soll versucht werden eines der vorhande-nen Issues11 zu losen. Dadurch ist die Durchfuhrung moglichstnah an der Realitat, es muss nicht extra ein kunstlicherAnwendungsfall konstruiert werden.

1) Aufgabenstellung: Im konkreten Fall soll folgende An-frage bearbeitet werden:

Can’t read the full subject on long email subjects#94612

Bei diesem Problem geht es darum, dass lange Betreffzeilennicht angezeigt werden. Im Normalfall sollte diese bei einerKurzung im Nachrichtenteil vollstandig wiederholt angezeigtwerden, dies ist in der Beschreibung nicht der Fall. DieserFehler kann nicht nachgestellt werden. Allerdings wird bei zulangen Betreffzeilen der Text innerhalb des Nachrichtenteilsebenfalls nach drei Zeilen gekurzt (siehe Abbildung 9 und 10).Konkret geht es in dem Fehler um das zweite Auftreten desBetreffs. Bei kurzen Texten, die in die oberen zwei Titelzeilenpassen, wird er kein zweites mal angezeigt. Beim Nachstellendes Problems wurde zusatzlich festgestellt, dass trotz einerBegrenzung des oberen Titels auf zwei Zeilen ein drittes malumgebrochen wird, wenn die Worter mit einem Bindestrichgetrennt sind. Bei zu langen Wortern wird ebenfalls korrektgekurzt.

2) Durchfuhrung und Ergebnisse: Der Fehler, des falschenUmbrechens, bei Bindestrichen in der Titelleiste ist eigentlichnicht Teil des Issues, soll im Versuch aber zu Anfang gelostwerden. Hauptaufgabe ist es die Stellen zu finden, an denenangesetzt werden muss. Dazu wurde eine TreeMap auf Basis

10https://github.com/k9mail/k-911https://github.com/k9mail/k-9/issues12https://github.com/k9mail/k-9/issues/946

6

Abbildung 10: K9 Mail Titel Zeile

Abbildung 11: Understand TreeMap der gesamten Anwendung

der Klassen und Interfaces, gruppiert anhand der Ordnerstruk-tur generiert. Als Ergebnis wurde eine recht unubersichtlicheDarstellung geliefert (Abbildung 11).

Bei genauerer Betrachtung konnte eine Gruppierung nachdem View Ordner gefunden werden. Sofern die Benennungkorrekt ist, sollten hier weitere Hinweise zu finden sein. InAbbildung 12 ist die TreeMap nur fur die View Komponenteabgebildet. Diese reduzierte Darstellung ist bereits erheblichubersichtlicher.

In dieser Ansicht kann wiederum die MessageTitle-View.java Datei gefunden werden. Auf Basis der TreeMapkann von hier aus nicht weitergearbeitet werden. WeitereDetails sind in dieser Ansicht nicht darstellbar. Die IDE bietetallerdings an, sich z.B. eine Ubersicht uber die Deklarationenanzeigen zu lassen (Abbildung 13). Hier kann erkannt werden,dass die Klasse tatsachlich von einem Widget erbt. Das heißt,dass sie fur die Darstellung zustandig ist. Des weiteren isterkennbar, dass die Klasse eine globale Variable MAX LINESbeinhaltet. Diese wurde testweise verandert. Entsprechend wirdkorrekterweise nach mehr, bzw. weniger Zeilen ausgeblendet.

Abbildung 12: Understand TreeMap der View Gruppierung

Abbildung 13: Understand Deklarationen

Abbildung 14: Source Code Verwendung der VariableMAX LINES in der Klasse Message Title View

Das Feld, in dem sich die Titelleise befindet wird allerdingsnicht vergroßert, dadurch sind bei mehreren Zeilen nur circa2,5 Zeilen im Vordergrund sichtbar. Dieser Versucht hat abergezeigt, dass diese Datei fur die Darstellung der Titelleisezustandig ist.

Ab hier wird in der Code betrachtet. Dazu wird gepruft, wodie zuvor gefundene Variable verwendet wird (Abbildung 14).Konkret wird die Anzahl der zulassigen Zeichen mithilfe derZeile int lineEndIndex = getLayout().getLineEnd(MAX LINES- 1); berechnet. Innerhalb der IDE ist es nicht moglich sichdie konkreten Methoden anzusehen, da die entsprechendenKlassen Bestandteil des Android SDKs sind, welches nichtgefunden wird. Bei IntelliJ ist dies ohne weiteres moglich.Das Problem scheint also in der gefundenen Zeile zu liegen

7

und handelt sich somit sogar um ein Bug im Android Systemselbst und wird deshalb nicht weiter verfolgt.

Im nachsten Schritt suchen wir die Stellen, die dasKurzen des Betreffs im Nachrichtenbereich bewirken. Indem gefundenen Code Abschnitt wird im alternativ Fall,wenn der Text der Titelzeile nicht gekurzt werden mussmHeader.hideSubjectLine(); ausgefuhrt. Hierbei handelt essich um die zusatzliche Betreffzeile innerhalb der Nachricht,die ausgeblendet wird. Die entsprechende Stelle verweist aufdie MessageHeader Klasse. Hier wird der entsprechende Textfur den Subheader verwendet. Durch manuelles Hinzufugenvon Text kann uberpruft werden, ob der Text zuvor bearbeitetwird und deshalb trotzdem, wie zuvor, gekurzt wird. Dies istnicht der Fall, da nach drei Zeilen ebenfalls gekurzt wird.Deshalb handelt sich sich sehr wahrscheinlich um eine Festle-gung innerhalb des Frontends des Views. Durch eine Referenzauf das konkrete Objekt in der Oberflache kann folgendeZeile gefunden werden: android:maxLines=”3”. Wenn dieseentfernt wird, ist es moglich den gesamten Betreff, ohneKurzung, innerhalb der Nachricht anzuzeigen.

3) Bewertung der Ergebnisse: In diesem Selbstversuchwurden relativ schnell Ansatze zur Losung gefunden. Trotz-dem wird nicht klar, ob die Tools einen entsprechendenVorteil liefern konnen. Zu Beginn wurde die Stelle des erstenProblems mithilfe der Tools schnell gefunden, beim zweitenProblem wurde die Tools allerdings nicht eingesetzt. In diesemFall haben die Tools nur zum Teil geholfen. Es ist schwergezielt vorzugehen, da nicht bewusst ist, welche Tools denEinstieg erleichtern. Außerdem wird die Android Entwicklungnicht vollstandig unterstutzt.

Bei der TreeMap konnten die Strukturen schnell erkanntwerden. Bei Projekten mit unklaren Benennung und bei Prob-lemen, bei denen unklar ist, in welchem Bereich diese liegenhilft dieser Ansatz allerdings nicht.

B. Versuch B: Einschranken der Suche

Im Rahmen des zweiten Versuches soll eine selbst konstru-ierte Anforderung umgesetzt werden. Die Erweiterung beziehtsich nur die die Logik und Datenhaltung und soll nicht auf derOberflache umgesetzt werden.

1) Aufgabenstellung: Die Aufgabe ist es, eine Suchezu entwickeln, die die bereits vorhandene, rein textbasierteSuche um eine Moglichkeit auf eine Einschrankung fur einenZeitraum hinzuzufugen (Angabe von maximalen und mini-malem Von-Datum). Die Entwicklung soll sich hierbei nurauf die entsprechende Logik konzentrieren, innerhalb der App-Oberflache soll diese Funktionalitat nicht eingebaut werden.

2) Durchfuhrung und Ergebnisse: Bei dieser Durchfuhrungsoll am Anfang, die bereits vorhandene Suche analysiertwerden. Diese soll anschließend entsprechend erweitert, bzw.angepasst werden. Damit dies geschehen kann mussen dieentsprechenden Stellen zu Anfang gefunden werden. DieTreeMap liefert in diesem Fall keinen Ansatzpunkt, da keineKomponente direkt mit der Suche in Verbindung gebrachtwerden kann. Als Alternative wird global nach ”Search” undahnlichen Synonymen gesucht um einen Startpunkt zu finden.Es wird eine Search Klasse gefunden, diese erbt von derMessage List Klasse. Diese beinhaltet mehrere Suchmethoden,

mit unterschiedlichen Parametern. Um klar zu machen, obdies die gesuchte Methode ist, sehen wir uns mithilfe einesButterfly Diagramms (Abbildung 15) an, wie die Methodeaufgerufen wird und welche Methoden von ihr wiederumaufgerufen werden. Dies liefert allerdings keine hilfreichenHinweise.

Durch den erneuten Einbau von Debugausgaben, kannfestgestellt werden, dass keine dieser Methoden bei der Sucheaufgerufen wird. Dies zeigt, dass das Tool nicht nur nutzlicheHinweise liefert. Außerdem wurde um die Stelle zu finden, dieSuche verwendet. Dies bietet auch jede IDE an.

Im nachsten Ansatz wird von der Oberflache ausgegangen,indem nach der Methode gesucht wird, welche von dem Suche-Button ausgefuhrt wird. Die Understand IDE enthalt allerdingsnicht den Android Designer fur die Oberflachen, weshalbwieder auf Android Studio zuruckgegriffen werden muss.Dadurch kann der Suchen-Button gefunden werden und auchdie benotigte Methode, welche allerdings nur das Suchfensteroffnet. Dadurch kann im nachsten Schritt allerdings auch dieMethode gefunden werden, welche aufgerufen wird, wenndie Suche ausgefuhrt wird. Dieser Ansatz wird nicht weiterverfolgt, da dazu die zu untersuchenden Tools nicht verwendetwerden. Dazu ist die Standard Version von Android Studioausreichend.

3) Bewertung der Ergebnisse: Auch im zweiten Versuchhaben die Tools keinen merkbaren Vorteil gebracht. Im Endef-fekt wurde bei der Hauptaufgabe, dem Finden der entsprechen-den Stellen erneut die Android Studio Version von IntelliJverwendet und nicht die Funktionalitaten der Understand IDE.Nachdem die entsprechende Stelle gefunden wurde, hattewieder auf die Tools zuruckgegriffen werden konnen um zuerfahren, in welcher Sequenz diese aufgerufen werden.

V. FAZIT UND AUSBLICK

Sonarqube wurde in diesem Versuch nicht verwendet undeignet sich deshalb vermutlich in den wenigsten Fallen umbei einer aktiven Entwicklung zu unterstutzen. Als Mon-itoring Tool ist dies eher hilfreich, um eine hohe Code-qualitat sicherzustellen. Sonarqube kann durch automatisierte,regelmaßige Prufungen sicherstellen, dass ein definierter Stan-dard eingehalten wird und auf Stellen aufmerksam machen,die Probleme verursachen konnen.

Des weiteren wurden nur wenige Tools von Understandverwendet. Es ist gut vorzustellen, dass bei Problem mitunterschiedlichen Methodenaufrufen und Abhangigkeiten, dieSequenz- und Kontrollflussdiagramme unterstutzend wirkenkonnen. Um die Understand IDE effektiver zu verwenden, istes notwendig, diese genauer kennenzulernen. Da es sich beidieser IDE aber um ein hauptsachlich kommerziell eingesetztesTool handelt, ist keine große Community vorhanden, diebei Fragen unterstutzen kann. Ein weiterer Nachteil ist, dasszwar in der Understand IDE entwickelt, aber nicht kompiliertwerden kann. Deshalb wird zusatzlich noch IntelliJ benotigt.Es sollte außerdem herausgefunden werden, ob die fehlendenBibliotheken entsprechend eingebunden werden konnen unddadurch eine vollstandige Android Entwicklung ohne IntelliJmoglich wird. Wenn dies nicht der Fall ist, ist ein effektiverEinsatz schwer moglich. Wenn dies nicht der Fall ist, sollte fur

8

Abbildung 15: Butterfly Diagramm Suche

die konkrete Evaluierung, mit Testpersonen, ein Projekt gefun-den werden, welches vollstandig durch Understand unterstutztwird.

Die Testanwendung wird als Open Source Anwendungentwickelt, dadurch arbeiten viele unterschiedliche Entwickleran dem Projekt. Da in Projekten dieser Art haufig Nachfragenanderer Entwickler entstehen, wird auf eine gute Lesbarkeit,durch aussagekraftige Namen und Strukturen geachtet. Außer-dem wird fur den Großteil der Codeeinreichungen, bevordiese in den Haupt Entwicklungsstrang uberfuhrt werden, einReview durch andere Entwickler durchgefuhrt. Dies bewirkt,dass die Mehrheit der Nachfragen entweder uberflussig werdenoder schnell beantwortet werden konnen.[15]Im Gegensatz dazu, ist es bei Closed Source Projekten haufigder Fall, dass wenige Personen den Code sehen und dieEntwickler gegen eine festgelegte Deadline arbeiten. Dadurchwird der Code bei Zeitdruck schnell geschrieben, statt dass aufsauberen und lesbaren Code geachtet wird.

Es konnte nicht herausgefunden werden, wie ein erfol-greicher Einstieg aussehen kann, um sich in eine neue An-wendung einzuarbeiten. Die Tools konnten nicht erfolgre-ich dazu beitragen. Ein nicht rein toolbasiertes Vorgehen istdeshalb empfehlenswert. Es ist erforderlich, dass erst einGrundverstandnis fur die Anwendung aufgebaut wird. Dieangebotenen Tools sind nur in ausgewahlten Abschnitten un-terstutzend. Fur ein Grundverstandnis der Anwendung, istes erforderlich, dass zu Beginn die Dienstleistungen, welchedie Software anbietet verstanden werden. Dies ist notwendig,um zu verstehen, wozu die Anwendung verwendet werdenkann. Dies ermoglicht es wahrend der Entwicklungen genauereVermutungen zu treffen, um diese Anschließend zu uberprufen.Anschließend sollen die Punkte gefunden werden, welchedie gesuchte Dienstleistung auslosen. Dazu kann entwedervon Oberflache (z.B. welche Methode wird beim Druckeneines Knopfes ausgelost) oder von der API aus, vorgegangenwerden. Ab hier ist in unterschiedlichen Phasen ein Einsatzder Tools und Visualisierungen denkbar. Es kann z.B. einSequenzdiagramm erzeugt werden, welches den Aufruf dergefundenen Punkte darstellt. Dies ermoglicht es auf einenBlick zu sehen, wie welche Methoden, mit welchen Datenaufgerufen werden. Ohne das Diagramm musste jede Meth-ode im Code einzeln betrachtet werden. Wenn eine Methodegefunden wird, bei der Anderungen erforderlich sind, musszuvor gepruft werden, ob diese ebenfalls an anderen Stellenzum Einsatz kommt. Dies kann innerhalb fachlich vollstandigunabhangigen Dienstleistungen sein. Diagramme, wie das But-

terfly Diagramm in Abbildung 15 konnen helfen, die Stellen zufinden, an denen diese Methoden verwendet werden. Fur diegefundenen Abhangigkeiten darf sich bei einer Anderung dergefundenen Methode, im Normalfall nichts andern. Dadurchkonnen unerwunschte Nebeneffekte verhindert werden. Einegenauere Beschreibung eines solchen Vorgehens, mit denmoglichen Einsatzzwecken der Tools sollte in zukunftigenArbeiten entwickelt werden.

Die bereits vorhandenen Tools konnten in diesem Rahmennur eingeschrankt unterstutzen. Ein vollstandiger Workflow,fur die hier verwendeten Anwendungsfalle, kann mit ihnennoch nicht abgebildet werden. Dies zeigt, dass in diesem The-menbereich noch einiges an zukunftiger Arbeit steckt. Dazuzahlt unter anderem neue Darstellungsformen zu entwickeln,die auch bei großen Projekten nicht zu unubersichtlich werden.

Eine weitere andere mogliche Betrachtungsweise diesesProblems fur neue Projekte ist es, nicht erst aus bereitsexistierendem Code eine Architektur zu rekonstruieren, son-dern von Beginn an eine geplante Architektur zu entwickeln.Dazu muss herausgefunden werden, wie die Planung einer Ar-chitektur und ein agiles Vorgehen erfolgreich zusammenspielenkonnen.

REFERENZEN

[1] S. Ducasse and D. Pollet, “Software architecture reconstruc-tion: A process-oriented taxonomy,” IEEE Transactions onSoftware Engineering, vol. 35, no. 4, 2009, pp. 573–591. [Online]. Available: http://rmod.lille.inria.fr/archives/papers/Duca09c-TSE-SOAArchitectureExtraction.pdf

[2] P. Caserta and O. Zendra, “Visualization of the Static Aspectsof Software: A Survey,” IEEE Transactions on Visualization andComputer Graphics, vol. 17, no. 7, jul 2011, pp. 913–933. [On-line]. Available: http://www.ncbi.nlm.nih.gov/pubmed/20733234http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5557869

[3] R. Kazman and S. J. Carriere, “Playing Detective: ReconstructingSoftware Architecture from Available Evidence RICK,” AutomatedSoftware Engineering, vol. 6, no. 2, 1999, pp. 107–138. [Online].Available: http://link.springer.com/10.1023/A:1008781513258

[4] M. T. Su, “Capturing exploration to improve softwarearchitecture documentation,” in Proceedings of the Fourth EuropeanConference on Software Architecture Companion Volume -ECSA ’10. New York, New York, USA: ACM Press, 2010,p. 17. [Online]. Available: http://dl.acm.org/citation.cfm?id=1842752.1842758http://portal.acm.org/citation.cfm?doid=1842752.1842758

[5] C. Stoermer, L. O’Brien, and C. Verhoef, “Practice patterns forarchitecture reconstruction,” in Ninth Working Conference on ReverseEngineering, 2002. Proceedings. IEEE Comput. Soc, 2002, pp.151–160. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1173073

9

[6] R. Koschke, “Architecture Reconstruction,” in Technical ReportCMU/SEI-2002-TR-034, 2009, no. November, Third Edition, pp.140–173. [Online]. Available: http://www.sei.cmu.edu/reports/02tr034.pdfhttp://link.springer.com/10.1007/978-3-540-95888-8{\ }6

[7] K. Kobayashi, M. Kamimura, K. Yano, K. Kato, and A. Matsuo,“SArF map: Visualizing software architecture from feature andlayer viewpoints,” in 2013 21st International Conference onProgram Comprehension (ICPC). IEEE, may 2013, pp. 43–52.[Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6613832

[8] J. T. Stasko, R. Catrambone, M. Guzdial, and K. Mcdonald, “An evalua-tion of space-filling information visualizations for depicting hierarchicalstructures,” Int. J. Hum.-Comput. Stud., vol. 53, no. 5, 2000, pp. 663–694.

[9] R. Wettel and M. Lanza, “Visualizing Software Systemsas Cities,” in 2007 4th IEEE International Workshopon Visualizing Software for Understanding and Analysis.IEEE, jun 2007, pp. 92–99. [Online]. Available: http://www.inf.unisi.ch/projects/evospaces/publications/Wettel07b.pdfhttp://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4290706

[10] ——, “Program Comprehension through Software Habitability,” in15th IEEE International Conference on Program Comprehension(ICPC’07), 2007, pp. 231–240. [Online]. Available: http://www.inf.unisi.ch/phd/wettel/download/Wettel07a-icpc.pdf

[11] T. Panas, T. Epperly, D. Quinlan, A. Saebjornsen, and R. Vuduc,“Communicating Software Architecture using a Unified Single-ViewVisualization,” in 12th IEEE International Conference on EngineeringComplex Computer Systems (ICECCS 2007). IEEE, 2007, pp.217–228. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4276318

[12] Sonarsource, “Sonarqube,” 2015. [Online]. Available: http://www.sonarqube.org

[13] Scitools, “Understand,” 2015. [Online]. Available: https://scitools.com/[14] K9mail, “k-9,” 2015. [Online]. Available: https://github.com/k9mail/k-9[15] O. A. Samoladas Ioannis, Stamelos Ioannis, Angelis Lefteris, “Open

Source Software Development Should Strive for EVEN GREATERCODE MAINTAINABILITY,” Communications of the ACM, vol. 47,no. 10, 2004, pp. 83–87.

10