Dieses Kapitel hat gezeigt, dass es durchaus möglich ist nur aus Quellcode eine Architektur zu reengineeren. Allerdings müssen viele Einschränkungen in Kauf genommen werden. Das gewünschte Ziel, eine vollständige Architekturdokumentation automatisch generieren zu kön-nen, kann bisher nicht erreicht werden. Die Einarbeitung in eine unbekannte Anwendung ist somit nicht gut unterstützt. Andere hilfreiche Informationen können aber gewonnen wer-den. Es konnte bei den Analysetechniken festgestellt werden, dass statische Analysen sehr effizient sind und sich deshalb auch ein Einsatz in großen Projekten lohnen kann. Es können automatisiert kritische Fehler in Anwendungen gefunden werden [46]. Dynamische Analysen sind sehr komplex. Zu diesem Thema fehlen aktuelle Arbeiten, zusätzlich gibt es nur wenige Werkzeuge, die dies unterstützen. Ähnlich ist dies bei der Erkennung von Entwurfsmustern, dies wird ebenfalls nicht praktisch eingesetzt.
Im anschließendem Absatz wurden Analysemöglichkeiten vorgestellt, die ebenfalls in der Praxis eingesetzt werden können. Allgemein konnte zum Einsatz der Tools festgestellt werden, dass diese sehr viel effizienter eingesetzt werden können, wenn die Analyseregeln individuell an das jeweilige Projekt angepasst werden. Häufig sind nur die Standard Regeln im Einsatz.
Aber auch diese können bereits zu einer besseren Codequalität beitragen. Die Conformance Prüfung eignet sich gut zum Auffinden von Verletzungen, wie nicht erlaubte Strukturen, Abhän-gigkeiten oder Zugriffen. Für diese Erkennung müssen allerdings Modelle für die Architektur entwickelt werden. Die Definition von Regeln und das Handling der Tools ist häufig komplex und ohne Übung fehleranfällig. Da dies von Tool zu Tool unterschiedlich ist, sollte vor dem Einsatz geprüft werden, welches für längere Zeit hilfreich ist. Es macht Sinn, dass Entwickler sich ausführlicher in dieses Tool einarbeiten. Dies bedeutet zwar, dass anfänglich mehr Zeit investiert werden muss, bringt in Zukunft allerdings Vorteile, da es anschließend schneller in neuen Projekten eingesetzt werden kann. Durch den Einsatz von individuellen Regeln, kann die Anwendung besser im Bereich der„Guten Architektur“, wie zu Beginn in Abbildung2.2 dargestellt, gehalten werden. Die späten Refaktorisierungsmaßnahmen werden verringert, weil Probleme früher gefunden und direkt behoben werden können. In den meisten Fällen ist eine Kombination von unterschiedlichen Tools sinnvoll, da die einzelnen meist nur einen Teil der Probleme angehen [35]. Um den Vorgang möglichst komfortabel und gleichzeitig verpflichtend zu gestalten, sollten die Analysen in einem Continuous Integration System integriert werden.
Eine Integration der Tools in den Entwicklungsprozess verpflichtet die Entwickler sich an spezielle Coderichtlinien zu halten. Diese Richtlinien können z.B. durch dieDefinition of Done festgelegt werden. Die Integration kann z.B. dadurch realisiert sein, dass Branches im Git
Repository nur in den Hauptentwicklungsstrang gemerged werden können, wenn alle Prü-fungen erfolgreich durchgelaufen sind. Die durchgehende Analyse der Anwendung kann als Monitoring realisiert werden. Dadurch soll es allen Entwicklern möglich sein den aktuel-len Stand im Blick zu behalten. Außerdem können sie direkt erkennen, wie die Architektur durch ihre Änderung beeinflusst wird. Für ein Monitoring ist eine gute und übersichtliche Visualisierung sehr wichtig. Bei Projekten mit langer Laufzeit macht es durchaus Sinn, diese Prüfungen auch im Nachhinein noch einzuführen. Dies führt, in den meisten Fällen vorerst zu einer aufwendigen Refaktorisierungsphase, welche die Anwendung auf einen einheitlichen Qualitätsstandard hebt. Wenn keine Soll-Architektur festgehalten ist, sollte diese in diesem Schritt entwickelt und dokumentiert werden. Es ist nicht sinnvoll, wenn diese alleine in den Köpfen der Entwickler vorhanden ist.
Die Analyse mit Sonargraph macht bei großen Anwendungen ebenfalls Sinn. Eventuell ist es gut, wenn dies regelmäßig in Projekten als Architektur-Review durchgeführt wird. Dieses Review könnte durch einen nicht an der Entwicklung beteiligten Spezialisten des Unternehmens geleitet werden. Refaktorisierungsschritte können dadurch geplant werden. Der Vorteil bei einem Spezialisten ist, dass dieser die gesamte Anwendung unvoreingenommen betrachten und Anregungen für Änderungen, die er in anderen Projekten gesehen hat, einbringen kann.
Außerdem muss nur dieser mit den Analysetools im Detail zurechtkommen. Ein weiterer, für viele Unternehmen sehr wichtiger Nebeneffekt ist, das die Kosten niedriger sind, weil weniger Lizenzen benötigt werden.
Über den Reengineering Ansatz gibt es zahlreiche Forschungen, bei denen viele nicht zu einem vollständig zufriedenstellendem Ergebnis kommen. Die meisten Untersuchungen wurden in reinen Testszenarien mit extra dafür entwickelten Werkzeugen durchgeführt. Weitere Untersuchungen zum Einsatz in der Praxis sind erforderlich. De Silva u.a. stellen in [72]
einen Überblick über Möglichkeiten, Tools und Technologien zum Finden, Minimieren und Kontrollieren einer Architekturerosion vor.
Zusammenfassend kann gesagt werden, dass der Reengineeringansatz nur beschränkt für das Ziel, herauszufinden welche Architektur aktuell ist, verwendet werden kann. Viele der Ansätze können allgemeine Fehlerstellen finden, haben aber nicht das primäre Ziel einen Überblick geben, speziell gesuchte Stellen finden oder sogar eine Einarbeitung ermöglichen zu können. Bei einer Weiterentwicklung kann der Ansatz in einzelnen Phasen hilfreich sein, wie zuvor in [41] festgestellt wurde. Es kann z.B. unterstützen, wenn eine Stelle gefunden wurde, an der Änderungen notwendig sind. Für diese Stelle kann ein Baum aufgebaut werden, um
herauszufinden welche Codestellen diese aufrufen und welche wiederum von ihr aufgerufen werden. Dies ermöglicht eine bessere Kontrolle und Verhinderung von Seiteneffekten.
Eine Diskussion auf der Ebene von Mustern und Strukturen ist nicht möglich. Der alleinige Ansatz des Reengineering, um ein Architektur-Redesign durchzuführen, ist nicht sehr er-folgsversprechend. Bei Conformance Prüfungen ist es erforderlich, dass eine Soll-Architektur existiert. Das Entwerfen dieser ist schwer und bewirkt keine Prüfung dieser Architektur. Die Soll-Architektur kann ebenfalls nicht optimal sein. Aus diesem Grund darf das Ziel nicht starr festgelegt sein und sollte regelmäßig überprüft und angepasst werden.
Ein weiterer wichtiger Punkt ist, dass mit diesem Ansatz nicht herausgefunden werden kann, aus welchem Grund bestimmte Lösungen entwickelt wurden. Dies zeigt, dass bereits vor, bzw.
auch während der Entwicklung eine ausführliche Debatte über die Architektur notwendig ist. Die getroffenen Entscheidungen müssen direkt begründet dokumentiert werden. Nur so sind diese im Anschluss nachvollziehbar. Dies macht deutlich, dass auf eine hohe Qualität der Softwarearchitektur von Beginn an der Entwicklung geachtet werden muss. Eine Kombination aus Reengineering und regelmäßigen Debatten kann die Qualität nochmals steigern.
Im nächsten Kapitel soll aufgrund der gewonnen Erkenntnisse die Architekturentwicklung von einem anderen Standpunkt aus betrachtet werden. Es werden Möglichkeiten untersucht, um eine Architektur begleitend mit der Anwendung zu entwickeln.
Architekturdebatten in agilen Prozessen
Dieses Kapitel beschreibt Möglichkeiten, um Architekturdebatten in den Entwicklungsprozess zu integrieren. Es wird untersucht, wie dies in einem agilen Prozess, wie Scrum, integriert werden kann. Die Schwierigkeit besteht häufig darin die Agilität nicht einzuschränken. Vor-handene Arbeiten und Ideen werden vorgestellt und diskutiert. Einige der Inhalte wurden im BuchAgile Software Architecturevon Babar u.a. [9] veröffentlicht. Da die Inhalte von anderen Personen stammen, werden diese direkt referenziert.
Zu Anfang werden die Ziele einer vollständigen Integration in den Entwicklungsprozess vorge-stellt. In einer Debatte müssen zwingend Entscheidungen gefällt werden. Bei Entscheidungen spielt dasWer?,Wie?undWann? eine wichtige Rolle. Für diese Fragen soll in diesem Kapitel versucht werden Antworten zu finden.
Unterschiedliche Arten zur Entscheidungsfindung werden hierzu vorgestellt. Anschließend wird darauf eingegangen wie die agilen Prinzipien auf die Architekturentwicklung abge-bildet werden können. In den folgenden Schritten werden Möglichkeiten erläutert, um die Anforderungen an eine Architektur zu ermitteln, eine leichtgewichtige Dokumentation zu erzeugen und die Rolle eines Softwarearchitekten zu integrieren. Zum Ende dieses Kapitel werden vorhandene Ideen, zu Vorgehen mit einer integrierten Debatte, vorgestellt und ein Fazit gezogen.