Die dargestellte Problematik der fehlenden Architekturdebatten und damit verbundenen Aus-wirkungen macht deutlich, dass dies ein relevantes Problem innerhalb der agilen Entwicklung ist. Es konnte festgestellt werden, dass zuerst ein gemeinsames Verständnis für Softwarearchi-tekturen geschaffen werden muss. Dies ermöglicht eine gleiche Kommunikationsbasis für alle Teammitglieder. Außerdem muss vor Beginn eines Projekts geklärt werden, wie relevant eine Architektur für das konkrete Projekt ist.
Für ein dauerhaft erfolgreiches Projekt, mit einer langlebigen Architektur, ist es wichtig die Architektur zielgerichtet, mithilfe von Debatten zu entwickeln und dauerhaft zu verbessern.
Wenn keine explizite Architektur vorhanden ist, kann es schnell zu unvorhersehbaren Proble-men und einem Scheitern des Projektes komProble-men. Die mit der Zeit immer komplexer werdende Erosion stellt ein hohes Risiko für ein Scheitern dar. Besonders die Weiterentwicklung und Wartung einer Anwendung ist davon betroffen. Dies kann ernsthafte Folgen für die beteiligten Unternehmen haben.
Vorhandene agile Vorgehen und das Manifesto machen keine konkreten Aussagen, wie eine Ar-chitektur innerhalb des Prozesses entwickelt werden kann. Diese sind eher auf die Optimierung der Arbeitsprozesse ausgelegt. Vorgaben, wie die konkrete Realisierung aussehen oder wie ein Plan dafür entwickelt werden kann, werden bewusst ausgelassen. Ein Rahmen für Verbesse-rungen wird durch die agilen Prozesse angeboten, ohne deren Prinzipien zu widersprechen.
Refaktorisierungen sind ebenfalls bei Projekten mit Architekturdebatten zwingend erforderlich.
Nur so kann auf Änderungen reagiert und trotzdem eine hohe Codequalität erreicht werden.
Die Architektur hängt sehr von der Struktur und Organisation der Entwicklung und des Un-ternehmens ab (Kapitel2.5). Aus diesem Grund ist es eine sehr wichtige Bedingung, dass das Unternehmen die Entwicklung vollständig unterstützt und entsprechende Strukturen anbietet.
Die Strukturen dürfen nicht zu starr sein und sollten eventuell individuell an die jeweiligen Projekte angepasst werden können.
Es konnte allerdings festgestellt werden, dass es auch ohne eine Architekturdebatte möglich ist, ein Projekt erfolgreich abzuschließen. Die eigentliche Entwicklung läuft dabei ohne grö-ßere Probleme ab. Im Anschluss, während der Wartung und Weiterentwicklung, entstehen allerdings häufig Probleme. Diese verzögern und erschweren die Entwicklung unnötig. Im nächsten Kapitel wird untersucht, wie Analysen auf vorhandenem Quellcode durchgeführt werden können. Diese sollen Strukturen sichtbar machen und mögliche Probleme finden. Die Weiterentwicklung soll dadurch unterstützt werden.
Prüfung und Reengineering
Dieses Kapitel beschreibt Analysemöglichkeiten auf Basis des vorhandenen Quellcodes. Der Quellcode wird verwendet, um Strukturen zu rekonstruieren und Metriken zu berechnen.
Soweit wie möglich sollen die Strukturen und Metriken mithilfe von automatisierten Werk-zeugen berechnet werden. Die Metriken können auf vorhandene Defekte hinweisen. Bei den Defekten kann es sich um unbekannte Architekturerosionen handeln. Durch die Erkennung und Auflösung wird die Softwarequalität deutlich angehoben.
Zu Beginn dieses Kapitels werden die allgemeinen Ziele dieses Ansatzes erläutert. Da dieser Ansatz die Weiterentwicklung und Wartung als wichtiges Einsatzgebiet hat, werden mögliche Szenarien für die Arbeit an einer vorhandenen Software vorgestellt. Im folgenden Abschnitt werden unterschiedliche Techniken und deren Einsatzmöglichkeiten zur Durchführung von Analysen präsentiert. Während der Entwicklung kann ein Monitoring die Architekturent-wicklung unterstützen. Dies wird im anschließendem Ansatz erläutert. Der nächste Abschnitt beschreibt ein Beispiel aus der Praxis, in dem eine Architektur Ermittlung mit Conformance Check durchgeführt wird.
Am Ende dieses Kapitels wird ein Fazit zu den gewonnen Erkenntnissen gezogen.
3.1 Ziele
Der Bottom-Up Ansatz hat das Ziel aus vorhandenem Quellcode eine Architektur zu reengi-neeren. Strukturen sollen sichtbar und Probleme erkannt werden können.
Dies ist sinnvoll, da in vielen Projekten keine aktuelle Architekturdokumentation vorhanden ist [70]. Der Ist-Stand ist deshalb häufig unbekannt. Eine Anwendung muss während ihres Lebenszyklus dauerhaft gewartet werden. Dazu ist erforderlich den aktuellen Stand und Aufbau zu kennen. Ansätze, die die Strukturen einer Anwendung automatisch oder halbautomatisch extrahieren, können das Verständnis über die Anwendung deutlich erhöhen. Dieser Ansatz
wird immer wichtiger, weil die meisten Anwendungen immer länger eingesetzt werden und immer komplexer werden [7]. [30]
Die Wunschvorstellung ist, dass die reengineerte Architektur als Ersatz für eine fehlende oder veraltete manuelle Dokumentation dienen kann. Die Gründe dafür, dass keine aktuelle Dokumentation vorhanden ist, können vielseitig sein. Diese muss immer manuell und zeitnah zu den Änderungen gepflegt und weiterentwickelt werden, ansonsten geraten Details und Gründe schnell in Vergessenheit. Die Anfertigung ist meistens mühselig und eine unbeliebte Aufgabe des Teams. Oft ist nicht bekannt, wie solch eine Dokumentation aussehen soll und liefert im Moment der Anfertigung keinen merkbaren Mehrwert.
Die reengineerte Architekturdokumentation kann dazu dienen Punkte in der Anwendung zu identifizieren, an denen für eine erfolgreiche Weiterentwicklung oder Wartung angesetzt werden muss. Vorteil einer digitalen automatisierten Dokumentation ist, dass diese immer auf dem aktuellen Stand beruht und auch im Nachhinein noch generiert werden kann. Ein weiterer Punkt ist, dass von einer sehr abstrakten Sicht mit Blick auf die gesamte Anwendung, bis hin zu direkten Implementierungsdetails hineingeschaut werden kann. Dies ermöglicht es von einer feinen Ansicht, mit vielen Details, zu einer groben Ansicht, mit allgemeinen Strukturen zu wechseln. Dies kann so realisiert sein, dass in der allgemeinen Ansicht die Basiskomponenten sichtbar sind. Im zweiten Schritt sind z.B. die Strukturen und Komponenten innerhalb einer Basiskomponente sichtbar. In der feinsten Auflösung wird der Quellcode angezeigt.
Das gesamte Verfahren ist allerdings nicht ohne zusätzliche manuelle Arbeit möglich, wie dies für eine Architekturdokumentation erforderlich wäre. Im Rahmen des Grundprojektes1wurden zahlreiche Anwendungen und Tools vorgestellt, die versuchen einen Teil dieses Problems zu lösen. Anschließend konnte in einem Selbstversuchen im Hauptprojekt2festgestellt werden, dass gerade das Finden von Ansatzpunkten für Erweiterungen nur durch die generierte Doku-mentation, bzw. Tool-Artefakte problematisch ist. Es müssen trotzdem weiterhin grobe, bis detaillierte Kenntnisse über die Anwendung und dessen Aufbau vorhanden sein. Viele Tools bieten allerdings bereits funktionierende Möglichkeiten, um Metriken aus einer Anwendung zu extrahieren und zu visualisieren. Einige der Tools konnten automatisiert Entwurfsmuster erkennen. Diese mussten allerdings zuvor manuell definiert werden. Die Definition dieser Muster kann komplex sein. Des Weiteren war die Erkennung häufig fehlerhaft. Es konnten nicht alle Muster erkannt werden. Zusätzliche wurden Muster fälschlicherweise erkannt.
1 http://users.informatik.haw-hamburg.de/~ubicomp/projekte/master2015-proj/fausten.pdf, Abgerufen: 06.08.2016
2 http://users.informatik.haw-hamburg.de/~ubicomp/projekte/master2016-proj/fausten.pdf, Abgerufen: 06.08.2016
Ein weiteres Ziel ist ein Einsatz zum Monitoring. Das Monitoring kann bereits von Beginn an während der Entwicklung eingesetzt werden. Dadurch soll eine dauerhaft gute Codequalität sichergestellt werden. Unbewusste Verletzungen, z.B. beim Codestyle oder Schichtenverletzun-gen, sollen erkannt werden. Ein Monitoring mit einer einfachen Visualisierung ermöglicht es, dass Änderungen direkt sichtbar werden und alle Teammitglieder ein besseres Bewusstsein für den aktuellen Stand haben.