Softwarearchitektur und Agile Entwicklung ... - HAW Hamburgubicomp/...Softwarearchitektur und Agile Entwicklung Architekturawareness durch Monitoring und automatischer Rekonstruktion

Softwarearchitektur und Agile EntwicklungArchitekturawareness durch Monitoring und automatischer Rekonstruktion

Leon Fausten

Hochschule für Angewandte Wissenschaften Hamburg, DeutschlandEmail: [email protected]

Der Chaos Report von 2014, der Standish Group, hat her-ausgefunden, dass 31,1% aller Software Projekte abgebrochenwerden. Bei 52,7% der untersuchten Projekte werden dieKosten mit insgesamt 187%, im Vergleich zur ursprünglichenPlanung, überschritten. Ein großes Problem ist, dass vieleProjekte häufig erneut von vorne gestartet werden. Von 100Projekten werden im Schnitt 94 Projekte neu gestartet. Eingleiches Projekt kann dabei mehrfach neu gestartet werden.Die Studie besagt ebenfalls, dass im Durchschnitt nur 61%der Anforderungen und Funktionalitäten umgesetzt werdenkönnen. Für die Architektur sind besonders die nicht funk-tionalen Anforderungen wichtig, wenn diese nicht umgesetztwerden kann dies den Erfolg des Projektes beeinträchtigen.Eine Befragung hat ergeben, dass unvollständige (Platz 2,12,3%) und sich ändernde Anforderungen (Platz 3, 11,8%) für32,1% ein Grund für Fehlschläge sind.[1]

80% der Gesamtkosten eines Systems entstehen in derWartung. Dies ist unter anderem auf das altern und dadurchverschlechtern der Architektur zurück zu führen. Deshalb solltedie Architektur bereits während der Wartung weiterentwick-elt und eventuell restrukturiert werden. Für eine erfolgreicheAnpassung der Architektur muss die derzeitig implementierteArchitektur bekannt sein.[2]

Softwarearchitekturen sind meistens sehr komplex undschwer im Detail vollständig zu verstehen. Dies liegt daran,dass sie aus vielen unterschiedlichen Bestandteilen beste-hen und bei großen Projekten einen Umfang haben, dernicht auf Anhieb verständlich ist. Moderne Entwicklungs-Frameworks1 behandeln die Architekturentwicklung nur sehrleichtgewichtig. Doch wie sollte eine optimale Möglichkeitaussehen, solch eine Architektur zu entwickeln und zu warten.Ein erster Schritt ist es dabei ein Bewusstsein für die Architek-tur zu schaffen, damit alle Projektbeteiligten immer genauwissen, woran sie arbeiten. Die Kenntnis der derzeit imple-mentierten Architektur kann Ansatzpunkte für problematischeStellen liefern, die ausgebessert werden sollten. Es soll einBewusstsein geschaffen werden, dass die Architektur einewichtige Rolle für den Erfolg eines Projektes spielt.Innerhalb dieser Arbeit wird eine genauere Problemstellung er-arbeitet und eine mögliche Wunschsoftware zur Unterstützungentworfen. Dabei werden neben Informationen aus einer zuvorgeführten Umfrage und Ergebnisse aus relevanten Arbeiten,Ideen aus existierenden Anwendungen herangezogen. Zentralwird vor allem die automatisierte Unterstützung und Visual-isierung mithilfe von Reverse Engineering betrachtet. BeimReverse Engineering wird die Architektur anhand vom Quell-

1z.B. Scrum, Kanban, ...

code und anderen Artefakten (Dokumentation, Datenfluss,...) rekonstruiert. Eine manuelle Untersuchung, durch einehändisch durchgeführte Code Inspektion, ist meist praktischnicht durchführbar und sehr teuer, da die Anwendungen sehrumfangreich sein können. [3]. [4][5][6]Automatisierte Rekonstruktion ist aufwendig und schwierig,da Menschen aus Erfahrungswerten intuitiv erahnen, welcheBestandteile relevant für die Architektur sind. AutomatisierteTools arbeiten deshalb oftmals mit Clustering und der Erken-nung von Mustern. Dabei können aber schnell Fehler entste-hen. Deshalb ist eine Mischung aus automatisierter undmanueller Rekonstruktion wünschenswert.[5]

I. PROBLEMSTELLUNG

Innerhalb der Agilen Frameworks ist kein Vorgehen zurArchitektur Entwicklung beschrieben. Wie in der Ausarbeitungzum Grundseminar2 festgestellt, befinden sich teilweise sogarwidersprüchliche Aussagen innerhalb des Agilen Manifesto.Dadurch entsteht die Architektur meistens zufällig, durch dieunterschiedlichen Erfahrungen und Vorlieben der Entwickler.Einzelne Komponenten können dadurch ohne genau Kon-ventionen und Richtlinien vollständig unterschiedlich aufge-baut sein. Die entstehende Gesamtarchitektur ist dadurchentsprechend chaotisch und meist zusätzlich noch unbekannt.

Da nicht alle nicht funktionalen Anforderungen mit äqui-valent hoher Priorität umgesetzt werden können, muss vonden Stakeholder genau festgelegt werden, welche Eigen-schaften in welchem Umfang realisiert werden sollen. Dienicht funktionalen Eigenschaften, wie z.B. Ausfallsicherheitund Geschwindigkeit können nicht gleichermaßen erreichtwerden.

Der aktuelle Stand der Architektur, während der Entwick-lung, ist meist nur grob oder gar nicht bekannt. Dies ist meistder Fall, wenn mehrere Personen an der Entwicklung beteiligtsind. Dadurch kann ein einzelner nicht genau wissen, wiesich die Anwendung weiterentwickelt hat. Festzustellen, obdie Architektur der gewünschten Soll-Architektur entsprichtist dadurch schwer möglich.[5] Zu Projektbeginn wird dieArchitektur meist nur informal über Diagramme oder textuelleBeschreibungen kommuniziert. Dadurch driften die konzep-tionelle Architektur und die implementierte Architektur meistauseinander. [6]

Falls keine oder nur eine initiale Architektur, die nie wei-terentwickelt wurde existiert, kann nicht sichergestellt werden,

2siehe Ausarbeitung Grundseminar, http://users.informatik.haw-hamburg.de/ ubicomp/projekte/master14-15-gsm/fausten/bericht.pdf

dass die Architektur überhaupt noch den Bedürfnissen undWünschen der Stakeholder entspricht, da der aktuelle Standunbekannt ist.

Es gibt den Ansatz in die eigentliche Programmierspracheeine Architektur Beschreibungssprache (ADL - ArchitecturalDescription Language) zu integrieren, wie z.B. in ArchJava[7] geschehen. Bei ArchJava wurde die ursprüngliche JavaSprache um die ADL erweitert. Alle Architekturentitätensind first-class Elemente der Sprache. Das Architekturwissenwird in diesem Ansatz vollständig im Code abgebildet. DerNachteil bei diesem Ansatz ist, dass eine hohe Abhängigkeitzu der dedizierten Sprache entsteht. Im Beispiel zu Arch-Java, wurde diese seit 2005 nicht weiterentwickelt. Diesstellt ein großes Problem bei langlebigen Anwendungen dar.Ein anderer Ansatz ist, die Untersuchung mit unabhängigenexternen Tools durchzuführen. Diese sollen keinen direktenEinfluss auf die Entwicklung haben und können auch ohneProbleme während der Entwicklung eingeführt, gewechseltoder abgeschafft werden.[6] Innerhalb dieser Arbeit wird nurdie Verwendung von externen Tools weiter betrachtet, dadas Risiko durch die starke Abhängigkeit bei einer direktenIntegration in die Sprache zu hoch erscheint.

II. RESULTATE DER UMFRAGE

Um aktuelle Informationen über die Entwicklung in derPraxis zu erhalten, wurde eine Umfrage mit 17 Teilnehmernzu Projekten ihrer Wahl durchgeführt. Jeder Teilnehmer undjede Teilnehmerin hat eigenständig ein Projekt, unabhängigvon anderen Teilnehmern gewählt. Die Teilnehmer habenunterschiedliche Rollen. Project Owner, Scrum Master, Ar-chitekten und Entwickler haben an der Umfrage teilgenommen.In Abbildung 1a ist zu sehen, dass bei einem Großteil derProjekte Scrum verwendet wird. Aus diesem Grund machtes Sinn, die Anwendung in das Framework zu integrieren.Es sind Projekte unterschiedlicher Größe ausgewählt worden,angefangen bei 1,5 Entwicklern, bis hin zu 90 Entwicklern.Sechs der Entwickler sind seit Beginn an dem jeweiligenProjekt beteiligt.

(a) Entwicklungsvorgehen (b) regelmäßige Debatte

Abbildung 1

Ebenfalls Sechs der 17 Teilnehmern (35,29%) war der aktuelleProjektstand unbekannt, sie konnten nicht abschätzen, wie vielder Arbeit bereits ungefähr erledigt war. Nur fünf Personenhatten Kenntnisse über die geplante Gesamtdauer des Projek-tes.

Über 70% der Befragten bietet sich bereits die Möglichkeitim Rahmen einer regelmäßigen Debatte (Abbildung 1b) miteinem Abstand von ein bis zwei Wochen über Änderungen und

Erweiterungen zu diskutieren. Diese Debatte bietet sich an, umsie um einen Bestandteil der Architekturdebatte zu erweitern,wenn dies nicht bereits durchgeführt wird.

(a) Arten (b) Regelmäßigkeit

Abbildung 2. Evaluierung

Die meisten der Projekte werden mithilfe von Reviewsevaluiert. Dies bietet eine gute Grundlage um daraufaufzubauen und in alle Projekte zu integrieren. Nur bei einemTeilnehmer werden automatisierte Tools zur Überprüfungverwendet. Die Verwendung solcher Tools ermöglicht eineregelmäßige Prüfung inklusive Monitoring. Da dies sel-ten verwendet wird, kann dies zur Folge haben, dasssich die Architektur in eine falsche Richtung entwick-elt, ohne das es rechtzeitig bemerkt wird. Nicht automa-tisierte Evaluierungsmethoden, bedeuten, dass nicht immerdie vollständige Anwendung geprüft wird, sondern maximalnur Ausschnitte. Die Begutachtung durch wechselnde Dritteist empfehlenswert, da die Personen die Anwendung un-voreingenommen betrachten können und neues Wissen undErfahrung ins Team bringen können.Sechs der Projekte werden alle ein bis zwei Wochen evaluiert(Abbildung 2b), meistens geschieht dies durch Reviews.Länger sollte der Abstand der einzelnen Evaluierungen nichtsein, damit Probleme frühzeitig erkannt werden und Lösungengefunden werden können.

(a) Ansprechpartner beiArchitekturfragen

(b) Änderungen

Abbildung 3

In Abbildung 3a ist zu sehen, dass die meisten Teilnehmerder Umfrage einen Ansprechpartner bei Fragen zur Architekturhaben. Drei Personen steht dabei ein professioneller Architektzur Verfügung. In den meisten Fällen ist das gesamte Teamfür die Architektur zuständig. Zum Teil wird Scrum nichtkorrekt durchgeführt, da der Scrum Master bei zwei Personender Ansprechpartner ist. Außerdem sind zwei Personenvollständig auf sich selbst gestellt, obwohl deren Teamsaus 7, bzw. 12 Entwicklern besteht. Dadurch, dass es in

2

den meisten Fällen keinen speziellen Ansprechpartner undArchitekturverantwortlichen gibt, werden wichtige Aktionen,wie z.B. ein Review meist vernachlässigt. Vier der Teilnehmersind mit der entwickelten Architektur nicht einverstanden. Beieiner Änderung der Architektur im Laufe der Entwicklungstimmen zwei Personen nicht zu, dass sie sich hätte ändernmüssen. Ebenfalls zwei Personen zufolge hätte sie sich ändernsollen, obwohl sie es nicht tat (Abbildung 3b).Für einen erfolgreichen Projektstart, ist wichtig, dassalle Teammitgliedern eine Einführung in die Architekturbekommen. Neben der Einführung ist eine gute Dokumentationwichtig, damit sie schnell eine Übersicht über die gewünschteund die aktuell entwickelte Architektur erhalten können.Elf der Teilnehmer waren nicht von Anfang an am Projektbeteiligt, nur zwei von ihnen haben eine Einführung in dieArchitektur bekommen. Die Restlichen mussten sich selbsteinen Überblick schaffen, indem sie aktiv nachgefragt haben,den Code durchgesehen haben oder entstandene Dokumentebetrachtet haben. Dies verdeutlicht umso mehr, dass eineaktuelle Dokumentation wichtig ist, die es ermöglicht einenschnellen Einblick in das derzeit implementierte System zubekommen.Die Dokumentation wird auf unterschiedlichste Artendurchgeführt. Dabei wird in sieben Fällen eine rein grafische,eine rein mündliche oder keine Art von Dokumentationerstellt. Diese haben das Problem, dass sie sehr kurzlebigsind. Grafiken ohne Text sind nach langer Zeit oder fürunbeteiligte Personen meist schwer verständlich. Reinmündliche Dokumentationen werden oft fehlerhaft undunvollständig weitergegeben und geraten mit der Zeit inVergessenheit. In acht Fällen wird eine lokal installierteAnwendung oder ein global zugängliches Websystem zurDokumentation verwendet. Eine webbasierte Dokumentationhat den Vorteil, dass diese von überall zugreifbar ist, ohnezusätzliche Software installieren zu müssen, hat aber denNachteil, dass lokale Änderungen nicht berücksichtigt werden.Dies ist aber nur relevant, wenn das Tool die Anwendungautomatisch analysiert und nicht manuell gepflegt werdenmuss.

Zusammenfassend kann gesagt werden, dass in den meistenhier vorhandenen Projekten bereits eine Grundlage für eineArchitekturdebatte vorhanden ist. Vorhandene Meetings undteilweise konkrete Versuche die Architektur explizit weiter-zuentwickeln zeigen deutlich, dass eine Bereitschaft existiertdas Vorgehen zu verfeinern. Der erste Schritt kann dabei dieEinführung eines Tools sein, um den aktuellen Zustand derArchitektur visuell aufzuarbeiten und zu monitoren.

III. DAS WUNSCH-SYSTEM

Zur Lösung der Probleme ist eine softwaregestützte Lösunghilfreich. Diese soll durch den Vorgang leiten und mitnützlichen Tools unterstützen.

Innerhalb dieses Abschnittes soll eine theoretischeWunschanwendung erarbeitet werden, dazu werden Punkte er-arbeitet, die mit bereits existierenden Anwendungen verglichenwerden sollen.

1) Gruppieren und Abstrahieren Damit große Sys-teme händelbar werden, sollen diese bei der Mod-ellierung in viele kleine Komponenten zerteilt wer-

den können, die wiederum aus Komponenten beste-hen können. Tickets aus dem Ticketsystem könnenkonkreten Komponenten zugeordnet werden. Überdas Versionierungstool, kann die Änderungshisto-rie von Komponenten betrachtet werden. Durchdie Möglichkeit Details und ganze Komponentenauszublenden soll die Komplexität des Systems ver-ringert werden. Bei einer Betrachtung kann sich soauf die in diesem Moment wichtigen Bestandteilebesser konzentriert werden. Bei Bedarf können De-tails wieder mit eingeblendet werden. Einzelne Kom-ponenten können z.B. gezielt ein/ausgeblendet wer-den.

2) Referenz Referenzen auf Pattern, Referenzarchitek-turen oder ähnlichem können festgelegt werden oderdurch eine Codeanalyse ermittelt werden. Dadurchkann sichergestellt werden, dass sich bereits bewährteLösungen wiederverwendet werden.Eine Modell-Datenbank kann bei der Suche nachähnlichen Strukturen, wie der umzusetzenden, hil-freich sein. Diese Datenbank enthält hilfreiche Pat-tern, inklusive deren Vor- und Nachteile. Die Ref-erenzen können z.B. zu Komponenten oder Tick-ets hinzugefügt werden. Bei der Suche nach einemPattern kann man in der Modell-DB sehen, inwelchen Projekten diese verwendet wurden undwelche Ansprechpartner man bei Fragen kontaktierenkann.

3) Sprachen unabhängig Für eine möglichstgroßflächige Nutzbarkeit sollte das Tool nichtabhängig von speziellen Programmiersprachensein, sondern bei möglichst allen weit verbreitetenSprachen einsetzbar sein.

4) Abhängigkeiten Durch die unterschiedlichen Kom-ponenten entstehen zwingend Abhängigkeiten zwis-chen ihnen, ansonsten könnten sie ein eigenständigesSystem bilden. Dadurch kann schnell erkannt wer-den, welche Komponenten bei Schnittstellenänderun-gen aktualisiert werden müssen. Außerdem wer-den potentielle Nadelöhre sichtbar. Zu viele unter-schiedliche Abhängigkeiten zwischen Komponentenkönnen zusätzlich auf einen falschen Aufbau derKomponenten hinweisen.

5) Zugriff Alle Informationen sind überall zugänglich.Damit effektiv immer auf Basis von aktuellen Datengearbeitet werden kann, sind alle Informationen auchaußerhalb der Meetings mit aktuellen Daten vorhan-den. Am nützlichsten ist dabei eine direkte Integrationin die Entwicklungsumgebung und als webbasiertesSystem. Das webbasierte System eignet sich gut fürMeetings oder für ein Monitoring auf einem gutsichtbaren Bildschirm. Die Daten des Websystemsbeziehen sich dann immer auf den Stand auf demEntwicklungsserver. Dadurch muss keine zusätzlicheAnwendung gestartet werden oder die aktuelle Ver-sion auf einen Server übertragen werden, um dieÄnderungen während der Entwicklung zu sehen. EineMischung von lokaler Integration und Websystem istwünschenswert.

6) Entwicklung Damit die Architektur nicht zufälligentsteht, sondern direkt gewünschte Eigenschaftenunterstützt, sollte die Entwicklung aktiv von Beginn

3

an des Projektes unterstützt und dauerhaft begleitetwerden. Ein initialer Architekturentwurf wird durchdie Anwendung unterstützt und kann als Grundlagefür den Projektstart dienen. Durch eine direkte Inte-gration in die IDE (siehe Zugriff) kann eine Art vonModel Driven Development umgesetzt werden, in-dem das Design dort grafisch modelliert werden kann.Das entsprechende Code Grundgerüst (Komponenten,Klassen, Interfaces, ..) kann daraufhin generiert wer-den. Details müssen manuell ergänzt werden.

7) Bemerkungen, Hinweise und Alerts An möglichstallen Stellen, können freitext Kommentare erstelltwerden, um auf etwas aufmerksam zu machen oderFragen zu stellen, die sich auf konkrete Stellenbeziehen. Diese lassen sich priorisieren und gesam-melt in einer Übersicht anzeigen. Es ist möglich un-terschiedliche Typen auszuwählen (z.B. Frage, Hin-weis, Empfehlung, u.s.w.). Diese sollen automatisiertz.B. in einem Meeting oder einem Zeitpunkt Erin-nerungen anzeigen. Zusätzlich sollen automatisierteMeldungen bei der Verletzung von vorgegebenenRichtlinien angezeigt werden. Es können z.B. bei In-terface Verletzungen (z.B. Erkennung von Casten aufkonkrete Objekte) oder Differenzen zwischen mod-ellierter Architektur und implementierter ArchitekturWarnungen erzeugt werden.

8) Abstimmungen und Beschlüsse Es ist möglich Ab-stimmungen zu starten, um die unterschiedliche Mei-nungen der Projektbeteiligten zu erfahren.

9) Workflow Die Anwendung unterstützt den Vorgangaktiv und kann ihn sogar leiten, indem z.B. Re-views nach vielen Änderungen oder einer bestimmterZeitspanne empfohlen werden. Durch eine direkte In-tegration in die IDE (siehe Punkt Entwicklung) kanneine Art von Model Driven Development unterstütztwerden.

10) Review/ Evaluierung Dies beinhaltet die Prüfung,ob die Ist-Architektur der Soll-Architektur entspricht.Bei der Soll-Architektur soll ermittelt werden, obdiese überhaupt noch mit den Projektzielen über-einstimmt oder angepasst werden muss. Dazu wirdermittelt, ob sich die Projektziele seit Beginn der En-twicklung geändert haben. Dies muss manuell durchdas Projektteam und den Stakeholdern geschehen.Für Reviews gibt es einen Review-Benutzertyp, dieserkann für jeden teilnehmenden Entwickler eingeführtwerden. Jeder Entwickler muss maximal eine fest-gelegte Anzahl von Reviews pro Zeitraum (z.B. 2Reviews pro Monat) durchführen. In der Anwendungexistiert ein Button um ein Review anzufordern.Die Anwendung ermittelt dann einen zufälligen Re-viewer. Dies hat den Vorteil, dass Wissen zwischenTeams einfacher ausgetauscht wird und Personen un-terschiedlicher Erfahrung und Vorwissen ein Reviewdurchführen. Dabei können auch Personen andererAbteilungen gewählt werden. Neben dem Prüfender Codequalität wird das Fachwissen breiter in derFirma verteilt.

11) Kommunizieren/ Vorstellen Das Vorstellen der Ar-chitektur den anderen und vor allem neuen Team-mitgliedern ist sehr wichtig, damit alle das gleicheVerständnis der aktuellen Architektur besitzen. Dazu

soll es eine Übersichtsseite mit wichtigen Entschei-dungen und Fakten zum Projekt geben. Diese solldazu dienen allen Projektbeteiligten einen grobenEinblick über den aktuellen Stand zu präsentieren.Eine gute Übersicht kann dauerhaft auf einem gutsichtbarem Monitor dargestellt werden. Dadurch wer-den Diskussionen angeregt und automatisch alle, diedaran vorbei laufen, auf den aktuellen Stand gebracht.

12) Visualisierung Für eine anschauliche Darstellungist eine geeignete Visualisierung notwendig. Diesesollten die Komplexität und auch die Abhängigkeitendarstellen können. Die Visualisierung soll den un-terschiedlichen Bedürfnissen angepasst werden, umso die Konzentration auf unterschiedliche Punktelenken zu können. Komplexe Visualisierungen, wieAbhängigkeitsgraphen mit vielen Verknüpfungen,sollten durch Ausblenden einzelner Details und Be-standteilen vereinfacht werden können.

13) Metriken und Analysen Es lassen sich Metrikenwie Methoden/Klassengrößen, ungenutzter Code, du-plizierter Code und ähnlichem Berechnen. Analysenzu Interface Verletzungen, leeren Try-Catch Blöckenoder ähnlichem können durchgeführt werden.

14) Pattern und Strukturen Die Anwendung kann au-tomatisiert Pattern und Strukturen erkennen. Die Pat-tern können manuell bestimmt werden.

IV. RELEVANTE ARBEITEN

Es existieren bereits einige Ideen zur softwaregestütztenArchitekturentwicklung. In diesem Abschnitt werden ein paardavon besprochen und deren Vor- und Nachteile erläutert. Eswird untersucht, auf welchen man aufbauen kann und welchegute Ideen und Ansätze für die eigene Anwendung liefern.

In dem Artikel Visual Tools for Software ArchitectureUnderstanding [5] wurden unterschiedliche Tools zur Visual-isierung untersucht. Einige der Anwendungen, hatten dabei denNachteil, dass diese sehr aufwendig zu konfigurieren waren.Dadurch sind diese nicht besonders nützlich, da für eine guteVisualisierung viel zeitaufwendiges Feintuning erforderlich ist.Für die Visualisierung ist wichtig, wer dessen Stakeholdersind, Entwickler benötigen andere Darstellungen als Manager.In diesem Projekt sind die Entwickler und Architekten dieAdressaten. Ein Ergebnis deren Studie ist, dass sich dieDarstellung von mehreren Attributen gleichzeitig, wie z.B.bei Tree Maps (z.B. Abbildung 6) am besten eignet umInformationen gebündelt darzustellen. Ein großes Problem istdie automatisierte Erkennung der Architektur:

Major technical limitations to architecture analysisinclude the lack of reliable, easily reusable solutionsfor automated architecture extraction, architecturecomparison (visual or not), and architecture patterndetection, despite sustained ongoing research.[5]

Die Rekonstruktion kann durch unterschiedliche Arten vonAnalysen durchgeführt werden.statische Analyse: nur mit Hilfe des Quellcodes, ohneAusführung der Anwendungdynamische Analyse: mithilfe der Ausführung der Anwen-dung

4

A. Architektur Rekonstruktion

Durch die dauerhafte Weiterentwicklung ist eine manuelleDokumentation schwierig und schnell veraltet. Deshalb ist eineautomatische Rekonstruktion (SAR - Software ArchitectureReconstruction) sehr hilfreich und empfehlenswert.

Die Rekonstruktion der Architektur aus Quellcode istsehr komplex, da sich die Architektur in den meistenSprachen nicht direkt ersichtlich im Code befindet undsich dauerhaft weiterentwickelt. Eine Architektur wird nichtallein durch Klassen und Pakete abgebildet, sondern auchdurch den Daten- und Kontrollfluss. Der Sourcecode unddie Anwendungsausführung sind eine der wenigen wirk-lich verlässlichen Informationen, die die aktuelle Architek-tur enthalten. Durch unterschiedlichste Sprachkomplexe, wiePolymorphismus, späte Bindung, dynamische Bindung zurLaufzeit, Delegation und Vererbung wird die Rekonstruktionsehr komplex und aufwendig. Eine reine automatisierte Rekon-struktion ist im Normalfall aber nicht ausreichend, da dieBeweggründe für Architekturentscheidungen für das Verständ-nis meist unerlässlich sind. Eine reine Rekonstruktion enthältnoch keine Bewertung der Architektur. Eine Bewertung kannmithilfe von Performance Untersuchungen, Pattern Erkennungoder ähnlichem vorgenommen werden. [8]

Eine Architekturrekonstruktion kann unterschiedlich ange-gangen werden. Eine Methode ist die Cluster-basierte Meth-ode, eine weitere basiert auf der Erkennung von Pattern.

Bei dem Cluster-basierten Ansatzes werden Teile derAnwendung mithilfe einfach berechenbarer Metriken zusam-mengefasst. Diese Metriken können z.B. den Zusammenhaltbeschreiben. Das Ergebnis ist eine Menge von Komponenten(z.B. Subsysteme oder Module) und deren Verbindungen un-tereinander. Der Cluster-basierte Ansatz, hat den Nachteil, dassdie Abstraktion durch die Metriken sehr hoch wird. Außer-dem können nicht alle Architektur relevanten Informationenmithilfe von Metriken entdeckt werden. Strukturen könnenerkannt werden, aber nicht deren Zweck. Erkenntnisse zumBeispiel zur Kopplung oder Kohäsion können durch die ClusterMethode erkannt werden. Der Vorteil dieser Methode ist, dasssich die Metriken im Vergleich zur Pattern-basierten Methodeschnell berechnen lassen. [2]

Eine andere Möglichkeit der Architektur Rekonstruktion istdie Pattern-basierte Rekonstruktion. Pattern sind sich bereitsbewährte Lösungsmuster für häufig vorkommende Problem-stellungen. Neben Pattern, die eine Lösungsart empfehlen,gibt es auch Anti-Pattern, die Lösungen darstellen, die nichtgewählt werden sollen, weil sie spezielle Probleme mit sichbringen. Das Vorkommen von Anti-Pattern weist auf Code-Smell hin.

A code smell is a surface indication that usuallycorresponds to a deeper problem in the system. [9]

Da die Pattern Erkennung erheblich mehr Daten, wie z.B. denKontroll- und Datenfluss benötigt ist die Analyse langsamerim Vergleich zur Cluster-basierten Variante. Pattern-basierteArchitekturrekonstruktion hat das Ziel vordefinierte Musterund Verhaltens Strukturen zu erkennen.[2]

Durch eine Analyse können Strukturen erkannt werden undbekannten Mustern (Pattern) zugeordnet werden. Sie erhöhen

das Verständnis für die Software, da dadurch die Beweggründedes Entwicklers deutlicher werden. Pattern haben sich imNormalfall bereits mehrfach bewiesen, außerdem sind derenVor- und Nachteile bekannt oder können nachgelesen werden.Eine Diskussion unter Entwicklern wird durch Pattern verein-facht, da diese grob im Allgemeinen bekannt sind und nichtim Detail besprochen werden müssen. Die Architektur wirddadurch leichter verständlich. Arcelli und Fontana [3] habenherausgefunden, dass die meisten Tools, die die Möglichkeitzur automatisierten Erkennung von Pattern besitzen nur einenBruchteil der Pattern der Gang of Four erkennen und beimittelgroßen bis großen Systemen schlecht skalieren. Außer-dem werden häufig falsche, nicht umgesetzte Pattern gefun-den (false positive). Sie haben ein Eclipse Plugin (MARPLE- Metrics and Architecture Reconstruction) zur ArchitekturRekonstruktion und zur Pattern Extraktion (DPD - DesignPattern Detection) entwickelt. Beide Verfahren gleichzeitig zuverwenden bietet den Vorteil, dass die Ergebnisse der Pat-ternanalyse zur Architekturrekonstruktion verwendet werdenkönnen. [3] Neben der Detektion von Design Pattern, könnenauch Anti Pattern oder Pattern für Bad Smell gezielt gesuchtwerden. Diese beschreiben schlechte Lösungen für häufigauftretende Problemstellungen. [2]

Abbildung 4. Empfohlenes Vorgehen beim Reengineering Prozess [2]

Von Detten und Becker empfehlen eine iterative Kombina-tion von beiden Vorgehen (siehe Abbildung 4) zum Reengi-neering der Anwendung. Beim schrittweisen Anpassen derArchitektur soll immer erst eine Cluster-basierte Rekonstruk-tion und anschließend, auf dessen Basis, eine Pattern-basierteRekonstruktion stattfinden. Dies hat den Vorteil, dass diedurchführende Person nach und nach eine bessere Kenntnis derArchitektur erlangt und die zuvor durchgeführten Änderungendirekt sehen und überprüfen kann. Die Qualität der Softwarenimmt schrittweise zu. Für eine beschleunigte Durchführungder Pattern Erkennung kann diese nur auf bestimmte Bereicheeingegrenzt werden, wo z.B. die Cluster Erkennung besondersProbleme festgestellt hat. [2] Beim Monitoring werden beideSchritte nur einmal vollständig durchgeführt.

Neben dem Reengineering kann dies während der Entwick-lung durchgeführt werden, um schnell einen Fortschritt zusehen und durch die Berechnungen nicht zu lange von derEntwicklung abgelenkt zu werden.

Die Rekonstruktion nur mithilfe von Source Code (low-level Informationen) wird als Bottom-Up Prozess bezeichnet.Ausgehend vom Quellcode aus werden die Modelle rekon-struiert. Das Top-Down Verfahren ist ein anderer Ansatz.Bei diesem besitzt man am Anfang Informationen über An-forderungen oder Architekturstile. Ziel ist es die Architekturmithilfe von möglichen Hypothesen durch Vergleiche mit demSource Code zu rekonstruieren. Ein hybrider Ansatz, der eineKombination des Bottom-Up und des Top-Down Prozessesmiteinander kombiniert ist ebenfalls möglich. Hierbei werdenbeide Prozesse durchgeführt und die Ergebnisse miteinander

5

verglichen. Dieser Ansatz wird oft zur Vermeidung von Ar-chitektur Erosion verwendet. Die konzeptionelle Architekturwird mit der realen Architektur verglichen. [8]

B. Technische Umsetzung und Bibliotheken

Hier werden zwei Open Source Anwendungen betrachtet,die die Analyse von Metriken und das Erkennen von Patterndurchführen können. Die Anwendungen werden teilweise inspäter vorgestellten Anwendungen eingesetzt.

SoMoX (Software Model Extractor) [10] kann aus vorhan-denen Anwendungen Modelle und Strukturen extrahieren undermöglicht dadurch Analysen der Codequalität. Die Analysenbasieren auf der Auswertung unterschiedlicher zuvor berech-neter Metriken. Für die Auswertungen können Einstellungenzu den Metriken vorgenommen werden, um sie an das jew-eilige Projekt anpassen zu können. Mithilfe einer Blacklistkann Code ausgewählt oder per regulärem Ausdruck bestimmtwerden, der bei der Analyse ausgeschlossen werden soll. DieErgebnisse können als Graph erzeugt werden. Es wurde an demKarlsruhe Institute für Technologie entwickelt und unterstütztdie Sprachen C/C++, Delphi und Java. Die Software wurde sogebaut, dass sie einfach um weitere Sprache erweitert werdenkann.

Reclipse [11] ist ein Tool zur Pattern Erkennung. Eswurde an der Universität Paderborn entwickelt. Statischeund dynamische Code Analysen werden unterstützt. Zurstatischen Analyse werden Patternbeschreibungen in einerspeziellen Spezifikationssprache verwendet. Mithilfe vonGraph-Matching Methoden werden mögliche Pattern Kandi-daten gefunden. Eine anschließend durchgeführte dynamischeAnalyse kann die Liste der gefundenen Kandidaten verfeinern.

Reclipse beherrscht die Erkennung von Struktur und Ver-haltens Mustern. Suchbare Pattern werden mithilfe einer DSLbeschrieben. Diese können grafisch modelliert werden.

Beide Tools analysieren den Source Code nicht direkt,sondern verwenden deren Generalisierten Abstrakten SyntaxBaum (GAST). SoMoX berechnet Metriken, wie Kopplungoder Kohäsion als Input für den eigentlichen Clustering Algo-rithmus. Bei erreichen von festgelegten Grenzwerten werdenElemente zu Komponenten zusammengefasst. [2]

V. VORHANDENE SOFTWARE - TOOLCHAIN

Dieser Abschnitt stellt bereits vorhandene Anwendungenund Bibliotheken vor. Dazu wurde ein Beispiel Projekt zurAnalyse verwendet. Als Testprojekt wurde der Open SourceAndroid Mail Client K9-Mail3 verwendet. Die Anwendungbesteht aus 66 862 Zeilen Code in 367 Dateien mit 4 443Funktionen. Davon sind 3,8% (3 548 Zeilen) duplizierterCode.4

Es wird nur ein Ausschnitt an vorhandenen Syste-men gezeigt, viele der Anwendungen wurden nur zuForschungszwecken entwickelt, waren nie produktiv im Ein-satz und wurden seit Jahren nicht weiterentwickelt. Einige derAnwendungen existieren nicht in direkt ausführbarer Form.

3https://github.com/k9mail/k-94gemessen mit Sonarqube, siehe V-A

Deshalb werden nur deren Ideen, die bei der aktuellen Prob-lemstellung hilfreich sein können erwähnt.

Punkte, der Wunschanwendungen, die die vorgestellten An-wendungen im Ansatz oder Teilweise lösen, werden genannt.Pro Anwendung werden zu Beginn ein paar Fakten kurztabellarisch präsentiert.

A. Sonarqube

Open SourceSprachen: mehr als 20 durch PluginsFunktionalitäten durch Plugins erweiterbarWebsystem, Plugins für IntelliJ, Eclipsewird noch WeiterentwickeltLöst die Punkte: Sprachenunabhängig, Zugriff, Visu-alisierung, Kommunizieren/ Vorstellen, Metriken undAnalysen, andere Punkte durch Plugin größtenteilslösbar

Sonarqube [12] ist eine Plattform um Codequalitäts Analysendurchzuführen und zu präsentieren. Durch die Möglichkeitsie durch Plugins zu erweitern ist die Anwendung kompat-ibel zu vielen Programmiersprachen und Anwendungsfällen.Außerdem können zahlreiche unterschiedliche Analysendurchgeführt werden. Einige der im folgenden vorgestelltenAnwendungen bieten ebenfalls Plugins für Sonarqube an undstellen deshalb eine gute Kombination dar.Auf der Startseite bietet Sonarqube ein frei konfigurier-bares Dashboard an, welches an die persönlichen Bedürfnisseangepasst werden kann. Neben den Plugins können über eineRest-Schnittstelle Daten angefragt werden.Die Anwendung ist aus einem Server und beliebig vielenClients aufgebaut. Der Server speichert die Ergebnisse derAnalysen und bietet ein Webinterface um diese darzustellen.Die Clients werden auf den Systemen mit den Anwendungenausgeführt. Sie führen die Analysen durch und übertragensie an den Server. Der Client kann entweder ein Plugin fürdie Entwicklungsumgebung sein oder ein separater Sonar-Runner. Für den Test wurde der Sonar-Runner verwendet, dadieser unabhängig von der IDE ist. Der Sonar-Runner wird alseinfacher Terminalbefehl ausgeführt, dadurch kann dieser auchfest in den Buildprozess integriert werden.

Per Default sind bereits, ohne zusätzliche Plugins, einigeAnalysen möglich, wie z.B. Test Coverage, Komplexität unddas Aufspüren von Duplikaten im Code. Das SQALE Pluginbietet die Darstellung eines Sunbirst (siehe Abbildung 5). Hierwird die Anwendung in verschiedene Oberkategorien, wie z.B.Testbarkeit, Sicherheit, Wartbarkeit, Zuverlässigkeit unterteilt.Diese werden erneut nach Kriterien, wie Exception Handlingoder Lesbarkeit unterteilt, und deren Kinder ebenfalls. DieGröße der einzelnen Felder wird durch Kriterien des äußerstenRings, wie z.B. ein öffentlicher Konstruktor(Verständlichkeit -Wartbarkeit) oder falscher Zugriff auf Daten bestimmt. [12]

6

Abbildung 5. Sonarqube SQALE Sunbirst

Abbildung 6. Sonarqube Treemap nach Codezeilen (Größe) und dupliziertemCode (Farbe)

B. Sonargraph

erwerbliche, zeitbasierte Lizenz, Preis abhängig von derProjektgrößestatische AnalysenSprachen: Java (C#, C/C++)lokal installierte Anwendung für Windows, OS X, Linuxwird noch WeiterentwickeltLöst die Punkte: Gruppieren und Abstrahieren,Abhängigkeiten, Zugriff, Visualisierung, Metriken undAnalysen, Pattern und Strukturen

Sonargraph [13] ist ein Produkt-Paket der FirmaHello2Morrow. Die beinhaltenden Anwendungen führenrein statische Analysen (nur anhand von Quellcode, ohneAusführung) durch. Die Anwendungen können mit einerzeitlich beschränkten Lizenz erworben werden. Die Kostensind abhängig von der Größe des zu untersuchenden Projekts.

Es besteht aus verschiedenen Programmen, demSonargraph-Explorer, Sonargraph-Architekt und SonargraphQuality. Der Explorer unterstützt bereits die weiterenProgrammiersprachen C# und C/C++. Durch das Parsender Anwendung wird ein Model erzeugt. Metriken, wie dieDuplikation von Code, Abhängigkeiten und andere werdenberechnet. Benutzerdefinierte Qualitätsrichtlinien könnenüberprüft werden. Der Architekt ermöglicht den Vergleicheiner definierten Architektur mit der implementiertenArchitektur. Eine durchgehende Prüfung der Architektur istmöglich. Bei nicht einhalten zuvor festgelegter Schwellwertefür Metriken können Meldungen aktiviert werden. KomplexeSchritte einer Refaktorisierung können vor der Realisierungsimuliert werden. Durch diese Simulation kann geprüftwerden, ob das gewünschte Resultat erreicht wird. Es istmöglich mehrere Lösungen miteinander zu vergleichen ohnedas diese Umgesetzt werden müssen.

Sonargraph-Quality beinhaltet alle Funktionalitäten desSonargraph-Architekt. Kann allerdings zusätzlich genauereAnalysen durchführen und den Verlauf von mehreren Analysenbetrachten. Durch die Kenntnis mehrerer Analysen könnenTrends in Metriken berechnet werden, welche Probleme seitdem letzten Build gelöst wurden und welche hinzugekommensind. Queries ermöglichen die Suche nach speziellen Struk-turen (z.B. Bad Smells).

Sonargraph kann in Sonarqube integriert werden. Die Anal-ysedaten werden dazu von der Sonargraph Installation zuSonarqube, mit entsprechend installiertem Plugin, übertragen.

Um eine Anwendung zu Analysieren muss ein EclipseProjekt oder ein IntelliJ Projekt importiert werden. Das zuuntersuchende Projekt kann auch selber definiert werden.

Abbildung 7. Sonargraph Dashboard

Das Importieren aus einem Projekt scheint in den meistenFällen nicht auszureichen, da die Warnung angezeigt wird,das der Workspace teilweise ungültig ist. Die Fehler bestehendarin, dass beim Importieren definierte Pfade nicht existieren.Auf Anhieb ist nicht ersichtlich, wie diese Fehler zu behebensind und ob diese relevant für die Analysen sind, da trotz-dem Metriken berechnet werden können. Das Sonargraph-Architekt Dashboard (Abbildung 7) ist auf dem ersten Blicksehr unübersichtlich. Es werden einem nur Metriken als Zahlenpräsentiert, ohne jegliche Grafiken.

In Abbildung 8 wird ein Abhängigkeitsgraph als gerichteterGraph zwischen Paketen dargestellt. Anfänglich werden alleBeziehungen dargestellt, es ist allerdings möglich einzelnePakete zu selektieren, damit werden nur Abhängigkeitenmarkiert, die mit dem Paket in Verbindung stehen. Durch

7

diese Darstellung kann festgestellt werden, wo zyklischeAbhängigkeiten bestehen, die eventuell aufgelöst werden soll-ten.

Abbildung 8. Sonargraph Zyklische Paketabhängigkeiten

Abhängigkeiten können in einem zusätzlichen ArchitekturBereich betrachtet werden. Dort sind die obersten Pakete undderen Abhängigkeiten untereinander sichtbar. Durch klickenauf einzelne Pakete ist sichtbar, welche Abhängigkeiten einPaket hat. [13]

C. Codecity

statische AnalysenJavaEclipse PluginNeuentwicklung aus einer rein akademisch nutzbarenVersionwird noch WeiterentwickeltLöst die Punkte: Visualisierung, Metriken und Analysen

CodeCity [14] stellt eine Anwendung als 3-DimensionaleStadt dar. Die Höhe und Farbe der Gebäude kann durchunterschiedliche Kriterien bestimmt werden. Dazu gehört dieAnzahl der deklarierten Methoden, die Codezeilen, Anzahl derAutoren und Commits und einige weitere. Es wird eine reineCluster-basierte Analyse durchgeführt.

Die aktuelle Version ist eine Nachimplementierung einerauf Smalltalk basierenden Version von CodeCity5. Die dama-lige Version durfte nur zu rein akademischen Zwecken genutztwerden und ist als eigenständige Anwendung entwickelt wor-den. Über das neue Eclipse Plugin ist es schwer genauereInformationen über die Lizenz und den aktuellen Stand zuerhalten. Bis auf die Eclipse Plugin Seite gibt es keine offizielleSeite mit Informationen.

Abbild 9 zeigt das Ergebnis für die Android App K9-Mail.Die Fläche der Gebäude stellt dabei die Anzahl der deklariertenFelder innerhalb der Klasse dar. Die Höhe und Farbe wirdin diesem Fall durch die Anzahl der deklarierten Methodenbestimmt. Auf jedem Gebäude ist ein Hover-Effekt mit demalle berechneten Informationen zur Klasse dargestellt werden.

Diese Art der Darstellung stellt die Strukturen sehr gut dar,und kann deutlich machen, welche Klassen häufig Problemeverursachen, weil diese z.B. sehr oft von unterschiedlichenPersonen bearbeitet wurden. Durch die Darstellung nach der

5http://www.inf.usi.ch/phd/wettel/codecity.html

Abbildung 9. Codecity Methoden Deklarationen

zyklischen Komplexität können schnell Klassen erkannt wer-den, die Performance Probleme verursachen können.

Um die Stadt darzustellen muss diese innerhalb von Eclipsegeneriert werden. Anschließend wird sie im Browser interaktivdargestellt. Innerhalb des Browsers gibt es Einstellungen zuden Darstellungskriterien. Es kann definiert werden, wonachsich die Länge und Breite der Häuser orientiert, welcheEigenschaft die Höhe bestimmt und was durch die Färbungdargestellt werden soll. Dies bietet die Möglichkeit drei Un-terschiedliche Kriterien innerhalb eines Graphen darzustellen.Ein Nachteil ist allerdings, dass bei Änderungen die Darstel-lung jedes mal erneut generiert werden muss. Dies dauertin dem verhältnismäßig kleinem Beispielprojekt bereits einpaar Sekunden. Über den Browser können die Daten nichtaktualisiert werden. Die Integration von Metriken in diesemTool aus dem Versionskontrollsystem ist sehr hilfreich undwird nicht von vielen anderen Tools unterstützt. [14]

D. IntelliJ Code Analyse Funktionen

statische AnalysenJavaEigenständige erwerbbare IDE, kostenfreie Community-Version vorhandenwird noch WeiterentwickeltLöst die Punkte: Zugriff, Abhängigkeiten, Metriken undAnalysen

Viele moderne Entwicklungsumgebungen bieten Funktionenzur Codeanalyse. Die Codeanalyse von IntelliJ [15] untersuchtden Code neben Compilierfehler auf unerreichbaren Code,nie ausführbaren Code, nicht auflösbare Methoden, MemoryLeaks und auch Rechtschreibfehler. Für die Analysen könnenAnalyseprofile ausgewählt werden, diese können pro Pro-jekt individuell definiert werden. Analysen können auf demgesamten Projekt durchgeführt werden, auf einzelne Dateienoder Ordner. Compilierfehler werden, wie bei den meistenIDEs direkt beim Schreiben analysiert und angezeigt. Diemanuell durchgeführten Analysen werden als Liste präsentiert,sortiert nach Fehlerart (z.B. Compilerfehler, Fehlerbehand-

8

lung). Eine grafische Darstellung gibt es nicht. Diese Listekann allerdings trotzdem hilfreich sein, um Schwachstellen zufinden und auszubessern.

Die IDE bietet auch die Möglichkeit einer Abhängigkeits-analyse. Die Abhängigkeiten werden als Liste mit drei Fen-ster dargestellt. In der ersten ist die normale Struktur derAnwendungen dargestellt. Hier wählt man eine entsprechendeDatei aus, die analysiert werden soll. In dem zweiten Fenstererscheinen daraufhin die davon abhängigen Dateien. Bei derAuswahl einer Datei aus dem zweiten Fenster, werden imDritten daraufhin die genaue Abhängigkeit dargestellt (z.B.anlegen eines Objektes).

Diese ist im Vergleich zu den anderen hier vorgestelltenTools sehr unübersichtlich und liefert nur bei sehr genauerBetrachtung nützliche Informationen. Um sich einen grobenÜberblick über die Anwendung zu verschaffen eignet sichdiese Möglichkeit nicht. Grundlegende Probleme können soaber durch ein durcharbeiten der Liste behoben werden.

E. CodeCrawlerOpen SourceJava Anwendung für Tomcatseit 2005 nicht weiterentwickeltLöst die Punkte: Sprachen unabhängig, Zugriff, Kom-munizieren/ Vorstellen, Metriken und Analysen

CodeCrawler [16] ist eine webbasierte Anwendung um Quell-code zu durchsuchen. Bei der Analyse jeder einzelnen Dateiwird ein Suchindex aufgebaut und semantisch wichtige Infor-mationen werden gesammelt. Die indexierte Analyse kann übereine Webschnitte durchsucht werden. Die Ergebnisse werdennach Relevanz oder dem letztem Änderungsdatum sortiertund verweisen auf die entsprechenden Stellen im Quellcode.Die Relevanz wird durch semantische Faktoren, wie etwaKlassennamen sind relevanter als Variablennamen bestimmt.Die Suche wird durch zusätzliches Wissen über die Pro-grammiersprache erweitert. Dadurch wird eine intelligentereSuche ermöglicht. Bei der Suche kann explizit nach Klassen-namen, Dateinamen oder ähnlichem gesucht werden. DieSuche wird mithilfe eines Queries gebildet und kann dadurchbeliebig komplex werden. CodeCrawler kann die Codebasisselbstständig zeitgesteuert aus einem Repository herunterladenund die Analysen und Indizierungen aktualisieren. Es wirdallerdings nur CVS, WebDAV und lokale Dateien unterstützt.

CodeCrawler kann zusätzlich zur Visualisierung der Datenverwendet werden. Die Abhängigkeiten können ähnlich wie inAbbildung 8 als Graph dargestellt werden. Die Komplexitäteiner Anwendung wird durch Kästchen unterschiedlicherGröße präsentiert. Die Breite ergibt sich aus der Anzahl derAttribute, die Höhe aus der Anzahl der Methoden und dieFarbe anhand der Codezeilen. In Abbildung 10 ist eine SystemHotspot Sicht dargestellt. Die Größe wird hier nach der Anzahlder Methoden bestimmt und die Farbe nach der Stärke derEinbindung in die Hierarchie. [17] Die Anwendung wurdefür Entwickler mit Kenntnissen zu Programmiersprachen undRegulären Ausdrücken entwickelt.

Die Anwendung wird als Websystem auf einem TomcatServer deployed. Es wurde allerdings seit 2005 nicht weiter-entwickelt.

Abbildung 10. CodeCrawler System Hotspot [17]

F. SHrIMP/Creole

Open SourceSprachen: Java#lokal installierte Anwendung für Windows, OS X undLinux, Plugin für Eclipse, Sonar, Intellij, Web Anwen-dungletztes Update 2013Löst die Punkte: Gruppieren und Abstrahieren,Abhängigkeiten, Zugriff, Visualisierung, Metriken undAnalysen

SHrIMP (Simple Hierarchical Multi-Perspective)[18] und Cre-ole [19] sind die gleiche Anwendung. Creole bezeichnet dabeidie Version als Eclipse Plugin.In der Hauptansicht verwendet die Anwendung eine hierar-chische Ansicht um Strukturen darzustellen. In die Ansichtkann hereingezogenen werden, um Details zu betrachten.Dadurch werden irrelevante Informationen ausgeblendet undfür diesen speziellen Bereich vorhandene Kontextinformatio-nen eingeblendet. Die Software Hierarchien werden durchverschachtelte Graphen dargestellt (Pakete beinhalten weiterePakete, Klassen, Interfaces, usw.6). Je nach Konfiguration,kann der Graph auch als Vererbungshierarchie dargestellt wer-den. Zusätzliche Beziehungen, wie z.B. extends (Vererbung)oder implements werden über Pfeile repräsentiert. SHriMPkann mit JavaDoc interagieren und entsprechende Stellen inden Graphen automatisch verlinken und präsentieren. Das Toolwurde so designed, dass es einfach für die Zusammenarbeit mitanderen Tools angepasst werden kann.[20] [21]Durch die Integration von Source Code und Dokumenta-tion innerhalb einer Ansicht wollen sie die Effektivität beimdurchsuchen und kennenlernen der Architektur erleichtern.Zu entsprechendem Sourcecode ist direkt ersichtlich, wie dieumliegende Architektur aussieht und zur visuellen Architekturist ersichtlich, wie die Implementierung aussieht.[21]

6Eltern - Kind Beziehung

9

G. UnderstandKommerziellstatische AnalysenEigenständige IDESprachen: Java, Ada, Cobol C, C#, uvw.Linux, OS X, Windowswird noch weiterentwickeltLöst die Punkte: Gruppieren und Abstrahieren, Sprachenunabhängig, Abhängigkeiten, Zugriff, Entwicklung, Vi-sualisierung , Metriken und Analysen

Understand ist eine von Grund auf neu entwickelte En-twicklungsumgebung. Sie muss kommerziell erworben wer-den. Die IDE bietet typische Informationen zu verwende-ten Methoden, Klassen und Variablen (Wo und Wie wer-den sie verwendet) wie andere IDEs an. Metriken, wieCodezeilen oder Komplexität werden automatisiert erzeugt.Qualitätsreports werden erzeugt, die z.B. duplizierten Code,oder eventuell problematische Abschnitte hervorheben. Vi-suell kann die Anwendung mithilfe von Treemaps (wie Ab-bildung 6), UML Klassen Diagramme, Sequenzdiagramme,Kontrollfluss Diagramme, Hierarchiegraphen (siehe Abbildung11), Deklarationsgraphen (z.B. wer ruft eine Methode auf,Was wird innerhalb der Methode aufgerufen, Welche Param-eter werden in einer Methode verwendet) und Abhängigkeits-graphen dargestellt werden. [22]

Abbildung 11 zeigt den Architekturgraphen der Paket-struktur. Dieser kann einen schnellen Einblick auf die Struk-turierung der Anwendung geben. Der in Abbildung 12

Abbildung 11. Understand Architektur Graph

dargestellte Abhängigkeitsgraph, zeigt alle Verknüpfungenunter den einzelnen Programmteilen. Er kann beliebig detail-liert dargestellt werden. Initial werden nur die Pakte dargestellt,in diese Ansicht kann bis zur untersten Ebene gezoomt werden.Es ist sehr Vorteilhaft, dass einzelne Nodes komplett, inklusivealler ihrer Verknüpfungen ausgeblendet werden können. Ein

Abbildung 12. Understand Abhängigkeitsgraph

weiteres interessantes Feature ist der Vergleich von Soll undIst-Architektur um Verstöße festzustellen.

Diese Anwendung scheint die Modellierung von Anwen-dungen und deren Überprüfung/Monitoring bereits gut zuunterstützen und zahlreiche reichlich Analyse und Visual-isierungsmöglichkeiten zur Verfügung.

H. gql4jung/ JUNG

Open SourceSprachen: Javaletzte Weiterentwicklung 2010Löst die Punkte: Abhängigkeiten, Visualisierung,Metriken und Analysen

Die Anwendung gql4jung [23] verwendet das Fram-work JUNG (Java Universal Network/Graph Framework)[24]. JUNG bietet eine erweiterbare Sprache an, um Daten,die als Graph abgebildet sind zu modellieren, analysierenund zu visualisieren. Die Bibliothek unterstützt unter-schiedliche Darstellungsarten, wie z.B. gerichtete und un-gerichtete Graphen. JUNG ist ebenfalls unter einer OpenSource Lizenz veröffentlicht worden. An jeden Graphen, jederEntität und jede Beziehung können Metadaten angehängt wer-den. Es wurde seit 2010, mit der Veröffentlichung von Ver-sion 2.0.1, nicht weiterentwickelt. Algorithmen zur GraphenTheorie (z.B. Pfadsuche), Data Mining (Suchen von Musternin großen Datensätzen, Erkennung von Trends), statistischeAnalysen und weitere sind bereits in der Anwendung im-plementiert. Für die Visualisierung kann ein mitgelieferterAlgorithmus verwendet werden. Das Framework unterstütztaber auch die Entwicklung einer eigenen Darstellung undstellt dazu Möglichkeiten zum Filtern der Informationen zurVerfügung.

Das gql4jung Projekt erweitert das JUNG Framework umeine Query Sprache für Graphen. Die Queries werden in XMLdefiniert. Dadurch können Queries zum finden von (Anti-) Pattern definiert erzeugt werden. Es werden Graphen imGraphML [25] Format unterstützt, außerdem können Graphenaus Java Code extrahiert werden. GraphML ist ein OpenSource Format auf XML Basis. Das Format wurde ebenfallsseit 2007 nicht weiterentwickelt. Zum Extrahieren aus bereitscompiliertem Java Code wird der Dependency Finder [26]verwendet. Dies ist ein Tool, dass aktuell weiterentwickeltwird und zur Analyse von compiliertem Java Code verwendetwerden kann. Neben einer Comandozeilen basierten Version,existiert auch eine grafische Oberfläche. Teil dieser Anwen-dung ist das Tool JarJarDif, dass Unterschiede zwischen zweiImplementierungen feststellen kann.

I. PMDOpen Source (BSD Lizenz)Plugins für Maven, Eclipse, NetBeans, InteliJ, ...Sprachen: Java, JavaScript, PLSQL, Apache Velocity,XML, XSLwird noch WeiterentwickeltLöst die Punkte: Referenzen, Metriken und Analysen

PMD [27] kann Quellcode Analysen durchführen um möglicheProblemstellen ausfindig zu machen. Es wird nach möglichenBugs gesucht, indem unter anderem nach leere try-catchBlöcken, ungenutzten Variablen und Parametern oder privatenMethoden gesucht wird. Eine überflüssige Verwendung von

10

Strings, if Anweisungen oder Schleifen kann entdeckt werden,sowie duplizierter Code. Die Analysen werden mithilfe vonRegelwerken durchgeführt. Um die Anzahl der Ergebnissezu begrenzen kann nach einzelnen speziellen Regeln (z.B.nur nach ungenutztem Code suchen) analysiert werden. Eineweitere Möglichkeit ist aus einem Regelwerk einzelne Regelngezielt auszuschließen. Bei Ausführung kann eine HTML Listemit Änderungsvorschlägen erstellt werden. Bei der Analysemuss ein entsprechendes Regelwerk angegeben werden. Indem Dokument werden Änderungsvorschläge, wie

Fields should be declared at the top of the class,before any method declarations, constructors, initial-izers or inner classes.

,

Avoid if (x != y) ..; else ..;

oder

No need to check for null before an instanceof

erstellt.

An den Beispielen kann man sehen, dass sowohlVorschläge für ein besseres Verständnis (unnötige Nega-tion), aber auch Vorschläge für Performance Verbesserungen(überflüssige Abfragen und Vergleiche) gemacht werden. Beijeder Meldung ist ein Link hinterlegt, der auf eine GithubSeite mit einer Erläuterung und Beispielen verweist. PMD wirdaktuell noch gepflegt und weiterentwickelt und bietet für vieleIDEs ein Plugin an. Dadurch ist die Verwendung unkompliziertund kann ohne Umwege in die Entwicklung integriert werden.

J. Archimetrix - Iterative Architecture Recovery and Reengi-neering

Open SourceSprachen: Java, C++, DelphiLöst die Punkte: Gruppieren und Abstrahieren,Abhängigkeiten, Pattern und Strukturenseit 2014 nicht Weiterentwickelt

Archimetrix [28] wurde an der Uni Paderborn entwickelt.Neben der Architektur Rekonstruktion durch die Cluster-basierte Methode bietet es die Möglichkeit der Pattern Erken-nung an. Defizite innerhalb von Komponenten und der Ar-chitektur können erkannt werden. Bei der Analyse gefundeneDefizite werden nach der Stärke der Architektur Beeinflussungsortiert. Ein schrittweise Behebung der Probleme, mit häufigerAktualisierung der Analyse wird empfohlen. Zum Beheben derProbleme werden Empfehlungen angezeigt, bestimmte Reengi-neering Strategien können dabei automatisiert durchgeführtwerden. Resultate der automatisierten Änderungen könnenzuvor in einer Vorschau betrachtet werden.

Zur Architektur Rekonstruktion geht die Anwendung inzwei Schritten vor. Im ersten Schritt wird ein generalisierterabstrakter Syntax Baum (GAST) mithilfe des Parsers SISSy(Structural Investigation of Software Systems) [29] erzeugt.Zusätzlich zum Parsen des Codes kann Sissy problematischePattern identifizieren (z.B. Interface-Verletzungen). Mithilfevon SISSy können außerdem Metriken, wie z.B. zum Zugriffauf externe Daten oder der durchschnittlichen Komplexität

aller Methoden einer Klasse berechnet werden. Im zweitenSchritt wird mit SoMoX (siehe IV-B) die Architektur rekon-struiert.

K. Web of Patterns - The Pattern X-Ray

Open SourceArchitektur Rekonstruktion und Pattern ErkennungSprachen: Java, C++, Delphiseit 2007 nicht weiterentwickeltLöst die Punkte:Gruppieren und Abstrahieren, Patternund Strukturen

Das Pattern X-Ray ist als Eclipse Plugin entwickelt wordenund ein Bestandteil des Web of Patterns Projekt [30]. Esbeinhaltet ein sprachen neutrales Format, um Design Patternzu beschreiben. Das Format basiert auf RDF7 und OWL8.Die Pattern werden mithilfe des Apache Jena Frameworks9eingelesen. Die Pattern Definitionen können von einem Repos-itory heruntergeladen werden. Die Ergebnisse werden nachÄhnlichkeiten zusammengefasst und können als XML ex-portiert und gespeichert werden. Um Pattern zu finden werdenderen gespeicherten Definitionen in Constraints umgewandelt,diese werden versucht mithilfe des GAST zu lösen. EineBewertung der Pattern durch die Benutzer ist möglich. DieBewertungen werden auf den Server übertragen und sind vonallen einsehbar. Mithilfe eines Wizzards können eigene Patterndefiniert werden, die Formal korrekt im RDF Format generiertwerden. Diese können wieder für andere Veröffentlicht werden.

Seit 2007 wurde dieses Projekt nicht weiterentwickelt.

Die Idee eine Community für Pattern einzurichten ist einegute Idee um verschiedene Meinungen über Lösungen zuerfahren und weiterzuentwickeln.

L. Weitere Tools

Es existieren zahlreiche weitere Tools, die die Architek-turentwicklung unterstützen und versuchen die Entwicklungallgemein und die Anwendung selbst effizienter und wenigerFehleranfällig zu machen. Doxygen [31] ist hauptsächlichdazu gedacht Dokumentation anhand von Kommentaren zuerzeugen. Es kann aber auch aus unkommentiertem QuellcodeStrukturen extrahieren. Dieses Tool eignet sich gut um schnellDokumentation anhand von JavaDoc (oder äquivalentem inanderen Sprachen) zu generieren.

Weitere, während der Recherche gefundenen Tools, dieallerdings nicht weiter untersucht wurden sind JDepend [32],Structure101 [33], Ndepend [34], SolidSX [35], EnterpriseArchitect [36], Rational Software Architect [37], Bauhaus [38],Sotograph [39], Swagkit [40], Lattix [41] und Marple - Metricsand Architecture Reconstruction Plug-in for Eclipse [42]

Der Großteil dieser Tools konzentriert sich auf die Rekon-struktion von Architektur und nicht auf deren initiale Entwick-lung und Weiterentwicklung. Die genannten Tools EnterpriseArchitect und Rational Software Architect stellen eine Aus-nahme dar, diese unterstützend die reine Modellierung derArchitektur, dafür aber nicht deren Rekonstruktion.

7http://www.w3.org/RDF/8http://www.w3.org/TR/owl-features/9http://jena.apache.org/

11

VI. EIGENER LÖSUNGSANSATZ

Im Rahmen des Hauptseminars und des Hauptprojektessoll mit der Umsetzung einer eigenen Anwendung begonnenwerden. Dazu müssen verschiedene Entscheidungen getroffenwerden. Am nützlichsten ist ein Plugin für eine IDE, wieIntelliJ oder Eclipse. Die Einbindung in Monitoring- undBuiltsystemen, wie Sonarqube oder Jenkins ist sehr hilfreich.

Da alle Anforderungen auf einmal nicht umsetzbar sind,soll sich vorerst auf ein paar Anwendungsfälle konzentriertwerden. Die resultierende Anwendung soll anfänglich vorallem das Bewusstsein für die Architektur fördern. Deshalb sollsie im ersten Schritt hauptsächlich als Monitoring Tool dienen,Metriken berechnen und eine grobe Architekturrekonstruktionbieten.

Da die Hauptfunktionalität der Darstellung des aktuellenZustandes dienen soll, wird die Anwendung so gebaut, dass sieals eigenständiges System laufen kann. Die Analysen könnenentweder mithilfe eines Buildservers oder lokal auf einemPC der Entwickler durchgeführt werden. Um den Entwick-lungsaufwand einzuschränken, soll vorerst nur Java als einzigeProgrammiersprache unterstützt werden. Für diese Spracheexistieren bereits viele Tools und Bibliotheken, die eventuellwiederverwendet werden können.

A. Vorgehen

Am Anfang der Entwicklung soll eine Möglichkeit zumParsen des Sourcecodes umgesetzt werden, um auf dem Re-sultat grobe Analysen durchführen zu können. Der Sourcecodewird in eine andere Darstellung, wie z.B. dem generalisiertemSyntax Baum umgewandelt. Dazu muss praktisch untersuchtwerden, welche vorhandenen Bibliotheken dazu eingesetztwerden können. In dieser Phase wird nur der Source Codeoder der compilierte Code als Input dienen. Hier können dieTools aus gq4ljung (JUNG, Dependency Finder) verwendetwerden. Es handelt sich um einen reinen Bottom-Up Prozess,Nach dem erfolgreichen Parsen der Daten sollen Metrikenmithilfe eines Cluster-basierten Verfahren berechnet werden.Hierbei kann z.B. dass vorgestellte SoMoX (siehe KapitelIV-B) verwendet werden. Es soll mit Metriken zu dupliziertemCode, zyklomatischer Komplexität und Abhängigkeiten be-gonnen werden. Die Ergebnisse werden zunächst als Listeausgegeben und erst im anschließenden Schritt visualisiert. Beider Visualisierung soll mit einer TreeMap begonnen werden.Diese Darstellung erscheint für den Anfang am simpelstenund für viele unterschiedliche Metriken einsetzbar zu sein, umein schnelles Resultat zu erzeugen. Für die Abhängigkeitenmuss eine graphbasierte Darstellung implementiert werden.Diese Visualisierungen sollen zunächst nicht interaktiv sein.Für eine universell einsetzbare Visualisierung soll diese inner-halb eines Browsers als Webpage dargestellt werden. Dadurchist es möglich, diese sowohl für ein Monitoring System zuverwenden, wie auch lokal auf den Rechnern der Entwickler.Die Darstellung soll in das vorhandene Sonarqube (sieheKapitel V-A) Tool integriert werden. Dadurch kann sich auf dieEntwicklung des Plugins konzentriert werden. Der Aufwandfür die Entwicklung von nicht direkt relevanten Aufgaben(wie Absicherung, Webserver, Administration) wird dadurchminimiert. Die Analysen werden per Skript durchgeführt undan Sonarqube übermittelt.

Im zweiten Schritt sollen die berechenbaren Metrikenerweitert werden. Die Visualisierungen sollen durch weitereDarstellungsmöglichkeiten und Funktionalitäten ergänzt wer-den. So kann bei der graphbasierten Darstellung hinzukom-men, dass einzelne Nodes ausgeblendet und wieder einge-blendet werden können. Die Darstellung der TreeMap kannwährend des Betriebs durch andere Kriterien bestimmt werden.

Im dritten Schritt soll die Pattern-basierte Analyse integriertwerden. Dazu muss zunächst eine geeignete Repräsentation fürdie Vergleichspattern gefunden werden. Dies kann ähnlich wiedas Format im Web of Patterns Tool aussehen. Die PatternAnalyse kann mit dem Reclipse Tool umgesetzt werden (sieheKapitel IV-B).

B. Weitere Entwicklung- und Forschungsmöglichkeiten

Die derzeit geplanten Features bilden nur sehr begrenztdie Möglichkeiten der Softwareanalyse und Architekturrekon-struktion dar. Nur wenige der am Anfang erarbeiteten Wun-schfunktionen stehen zur Verfügung. Wie die Analyse bere-its vorhandener Anwendungen gezeigt hat, sind noch einigeweitere Analysen und Visualisierungen, wie z.B. die SunbirstVariante möglich.

Die Einbeziehung weiterer Informationsquellen ist eben-falls sehr wünschenswert. Dies kann z.B. die Versionskontrollesein. Dadurch kann festgestellt werden, welche Dateien beson-ders häufig geändert werden oder wie viele unterschiedlichePersonen an den gleichen Komponenten gearbeitet haben.

Eine weitere Quelle, wie das Ticketsystem kann eingebun-den werden um Informationen zu Tickets, Personen, Diskus-sionen und z.B. einem Gesprächsverlauf direkt mit dem Quell-code zu verknüpfen.

Die Planung, Weiterentwicklung und Evaluierung der Ar-chitektur wurde in dieser Arbeit nur am Rande betrachtet,ist für eine erfolgreiche und effiziente Architektur aber er-forderlich. Die vorgestellten Tools haben zum Großteil nurdie Rekonstruktion beherrscht, eine Möglichkeit der Model-lierung gab es zusätzlich nur bei Sonagraph. Die nicht weitervorgestellten Tools Enterprise Architect und Rational SoftwareArchitect beherrschen die Architektur Modellierung, bietenaber nicht die Möglichkeit der automatisierten Rekonstruktion.

Funktionalitäten, die die Zusammenarbeit aktiv Fördernwurden bisher nicht betrachtet. Dazu gehört die einfacheMöglichkeit, an sämtlichen Stellen für alle verfügbar Anno-tationen hinzufügen zu können. Ebenfalls zu diesem Bereichgehört die Bewertung von Pattern, mit Verweisen auf möglicheAnsprechpartner und deren Vor- und Nachteilen. Eine Diskus-sion über das Anfordern eines Reviews kann in zukünftigenArbeiten einbezogen werden.

Durch die Wahl von Java als derzeit einzige unterstützeSprache sind die Verwendungsmöglichkeiten für die Anwen-dung sehr eingeschränkt. Die Erweiterung auf andere weitverbreitete Sprachen würde die Nützlichkeit der Anwendungsehr erhöhen und den möglichen Nutzerkreis stark erweitern.

VII. ZUSAMMENFASSUNG UND BEWERTUNG

Die Architektur einer Anwendung ist sehr wichtig undträgt zu einem großen Teil zum Erfolg eines Projektes bei.

12

Existierende Entwicklungsframeworks und Tools unterstützenTätigkeiten in Bezug auf die Architekturentwicklung nur sehrgering. Architekturdebatten benötigen ebenfalls einen tech-nischen Abschnitt mit Implementierungsdetails. Agile Frame-works, wie Scrum konzentrieren sich allerdings primär auffachliche Aufgaben.

Die Unterstützung der Architekturentwicklung ist sehrhilfreich und wie die Umfrage gezeigt hat, von den En-twicklern gewünscht. Durch eine Unterstützung können dieFehlerquellen verringert werden. Derzeit werden allerdings innur sehr wenigen Projekten automatisierte Tools verwendet.Derzeit existieren nur wenige Produkte, die Entwicklung vonAnfang, bis zum Ende unterstützen (Planung, Entwicklung,Wartung). Diese sind meist sehr komplex und teuer in derAnschaffung, bei sehr unterschiedlichem Leistungsumfang.

Bereits die reine Rekonstruktion ist sehr hilfreich um dasBewusstsein für die Architektur zu stärken oder auf möglichstsimple Weise den aktuellen Stand kommunizieren zu können.Einfach berechenbare Metriken können als Grundlage für eineDiskussion dienen und Hinweise bieten, um die Qualität derSoftware zu erhöhen. Derzeit werden solche Tools allerd-ings selten produktiv verwendet, sondern dienen meist reinForschungszwecken. Dadurch sind viele Anwendungen veral-tet und wurden seit Jahren nicht gepflegt und weiterentwick-elt. Vorhandene Tools bieten meist nur eingeschränkte, sehrunterschiedliche Funktionen. Die Verwendung ist in einigenFällen komplex und erfordert eine längere Einarbeitungsphase.Ausnahme bietet das Understand Tool (siehe Kapitel V-G).Dieses stellt gute Analysemöglichkeiten, integriert in einerIDE zur Verfügung. Diese IDE ist allerdings nur kommerziellerwerbbar und bietet keine Community Version oder ähnlichesfür einzelne Entwickler an. Die Sonargraph Anwendung bi-etet die Möglichkeit um Refaktorisierungen zu simulieren.Dies kann sehr hilfreich bei großen, schnell unübersichtlichenÄnderungen sein. Eine Schrittweise Durchführung, ohne dasdie Lauffähigkeit der Anwendung beeinträchtigt wird, istdadurch möglich. Ebenfalls kann geprüft werden, ob dieÄnderungen theoretisch den gewünschten Erfolg bieten. Diesspart Zeit und Kosten.

Die Entwicklung einer weiteren Anwendung scheint sin-nvoll, dabei sollten die Kenntnisse aus früheren Untersuchun-gen verwendet werden und wenn möglich verwendete Biblio-theken aktualisiert werden. Dadurch können individuelle An-forderungen umgesetzt werden. Zu den neuen Anforderungenzählt unter anderem die Verwendung von unterschiedlichenInformationsquellen neben dem Source Code, wie dem Ver-sionskontrollsystem oder dem Ticketsystem. Möglichkeiten,die Zusammenarbeit aktiv durch soziale Funktionalitäten zuunterstützen, bringen einen großen Vorteil, um das Wissenzu verbreiten und gleichzeitig festzuhalten. Dazu gehört dasAnfordern von Reviews, Verweise auf im Unternehmen ähn-liche Implementierungen, inklusive Ansprechpartner, Abstim-mungen und Bewertungen von Pattern. Das Fachwissen wirdim Unternehmen besser verbreitet und bleibt nicht nur inner-halb einzelner Abteilungen oder Projekten. Eine Voraussetzungist allerdings, dass genügend Mitarbeiter dazu beitragen.

Da der Aufwand für alle Anforderungen sehr hoch ist, mussdie Anwendung Schrittweise umgesetzt und erweitert werden.

REFERENZEN

[1] Standish Group, “CHAOS Report,” Tech. Rep., 2014. [Online]. Avail-able: https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

[2] M. von Detten and S. Becker, “Combining clustering andpattern detection for the reengineering of component-basedsoftware systems,” in Proceedings of the joint ACM SIGSOFTconference – QoSA and ACM SIGSOFT symposium – ISARCSon Quality of software architectures – QoSA and architectingcritical systems – ISARCS - QoSA-ISARCS ’11. New York,New York, USA: ACM Press, 2011, p. 23. [Online]. Available:http://www.scopus.com/inward/record.url?eid=2-s2.0-79960533364\&partnerID=40\&md5=375602d02a2ac11320cc460b050ade38$\backslash$nhttp://portal.acm.org/citation.cfm?doid=2000259.2000265http://portal.acm.org/citation.cfm?doid=2000259.2000265

[3] F. Arcelli Fontana and M. Zanoni, “A tool for design pattern detectionand software architecture reconstruction,” Information Sciences,vol. 181, no. 7, Apr. 2011, pp. 1306–1324. [Online]. Available:http://linkinghub.elsevier.com/retrieve/pii/S0020025510005955

[4] M. Von Detten, “Archimetrix: A tool for deficiency-aware softwarearchitecture reconstruction,” in Proceedings - Working Conference onReverse Engineering, WCRE, 2012, pp. 503–504.

[5] A. Telea, L. Voinea, and H. Sassenburg, “Visual Tools for SoftwareArchitecture Understanding: A Stakeholder Perspective,” IEEESoftware, vol. 27, no. 6, Nov. 2010, pp. 46–53. [Online]. Available: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5518754

[6] J. Van Eyck, N. Boucké, A. Helleboogh, and T. Holvoet, “Using codeanalysis tools for architectural conformance checking,” Proceeding ofthe 6th international workshop on SHAring and Reusing architecturalKnowledge - SHARK ’11, 2011, p. 53. [Online]. Available:http://portal.acm.org/citation.cfm?doid=1988676.1988687

[7] J. Aldrich, “Using types to enforce architectural structure,” in 7thIEEE/IFIP Working Conference on Software Architecture, WICSA2008, 2008, pp. 211–220.

[8] 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

[9] M. Fowler, “Code Smell,” 2006. [Online]. Available: http://martinfowler.com/bliki/CodeSmell.html

[10] Karlsruhe Institute für Technologie, “SoMoX,” 2015. [Online].Available: https://sdqweb.ipd.kit.edu/wiki/SoMoX

[11] Uni Paderborn, “Reclipse,” 2015. [Online]. Available: https://code.google.com/p/reclipse-emf/

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

[13] Hello2Morrow, “Sonargraph,” 2015. [Online]. Available: https://www.hello2morrow.com/products/sonargraph

[14] Codetrails, “Codecity,” 2015. [Online]. Available: https://marketplace.eclipse.org/content/codecity

[15] JetBrains, “ntelliJ IDEA 14.1.0 Help - Code Analysis,” 2015. [Online].Available: https://www.jetbrains.com/idea/help/code-analysis.html

[16] University Illinois-Urbana Champaign, “CodeCrawler,” 2005. [Online].Available: http://codecrawler.sourceforge.net/

[17] M. Lanza and S. Ducasse, “CodeCrawler–An Extensible and LanguageIndependent 2D and 3D Software Visualization Tool,” in Tools forSoftware Maintenance and Reengineering, 2005, pp. 74–94. [Online].Available: http://scg.unibe.ch/archive/papers/Lanz05bCCBookChapter.pdf

[18] Chiselgroup, “SHriMP,” 2013. [Online]. Available: http://thechiselgroup.org/2003/07/06/shrimp-views/

[19] ——, “Creole,” 2013. [Online]. Available: http://thechiselgroup.org/2003/07/06/creole/

[20] M.-a. Storey, C. Best, and J. Michand, “Shrimp views: Aninteractive environment for exploring java programs,” ProgramComprehension, 2001. . . . , 2001, pp. 1–4. [Online]. Available:http://ieeexplore.ieee.org/xpls/abs\ all.jsp?arnumber=921719

[21] M.-a. Storey, “SHriMP Views: An Interactive Environment forExploring Multiple Hierarchical Views of a Java Program,” 2002.

13

[Online]. Available: https://chiselgroup.files.wordpress.com/2012/07/10-1-1-94-8538.pdf

[22] Scitools, “Understand,” 2015. [Online]. Available: https://scitools.com/[23] J. Dietrich, “gql4jung,” 2010. [Online]. Available: https://code.google.

com/p/gql4jung/[24] T. J. F. D. Team, “JUNG - Java Universal Network/Graph Framework,”

2010. [Online]. Available: http://jung.sourceforge.net/[25] Graph Drawing Steering Committee, “GraphML,” 2007. [Online].

Available: http://graphml.graphdrawing.org/[26] J. Tessier, “Dependency Finder,” 2015. [Online]. Available: http:

//depfind.sourceforge.net/[27] PMD, “PMD,” 2015. [Online]. Available: https://pmd.github.io/[28] Uni Paderborn, “Archimtrix,” 2013. [Online]. Available: https:

//code.google.com/p/archimetrix/wiki/Introduction[29] SQools, “SISSy,” 2012. [Online]. Available: http://sissy.fzi.de/sissy/[30] J. Dietrich, “The Web of Patterns Project,” 2007. [Online]. Available:

http://www-ist.massey.ac.nz/wop/[31] Doxygen, “Doxygen,” 2015. [Online]. Available: http://www.stack.nl/

∼dimitri/doxygen/index.html[32] I. Clarkware Consulting, “JDepend,” 2009. [Online]. Available:

http://clarkware.com/software/JDepend.html[33] Structure101, “Structure101,” 2015. [Online]. Available: http:

//structure101.com/[34] P. Smacchia, “ndepend,” 2014. [Online]. Available: http://www.

ndepend.com/[35] SolidSource IT, “SolidSX,” 2013. [Online]. Available: http://www.

solidsourceit.com/products/SolidSX-source-code-dependency-analysis.html

[36] Systems Sparx, “Enterprise Architect,” 2015. [Online]. Available:http://www.sparxsystems.com/products/ea/

[37] IBM, “IBM Rational Software Architect,” 2015. [Online]. Available:https://www.ibm.com/developerworks/downloads/r/architect/

[38] Uni Stuttgart, “Bauhaus,” 2006. [Online]. Available: http://www2.informatik.uni-stuttgart.de/iste/ps/bauhaus/save/index-english.html

[39] Hello2Morrow, “Sotograph,” 2015. [Online]. Available: https://www.hello2morrow.com/products/sotograph

[40] Swag, “Swag Kit,” 2015. [Online]. Available: http://www.swag.uwaterloo.ca/swagkit/index.html

[41] Lattix, “Lattix Architect,” 2015. [Online]. Available: http://lattix.com/[42] Uni Milano Bicocca, “MARPLE,” 2013. [Online]. Available: http:

//essere.disco.unimib.it/reverse/Marple.html

14

Documents

Softwarearchitektur und Agile Entwicklung ... - HAW Hamburgubicomp/...Softwarearchitektur und Agile Entwicklung Architekturawareness durch Monitoring und automatischer Rekonstruktion