Herangehensweise und Erkenntnisse einer Architektur-Analyse im Rahmen eines Code Reviews

Nachdem in dem letzten Artikel wichtige Kennzahlen aus der statischen Analyse eines Code Reviews betrachtet wurden, werden nun Aspekte der manuellen Analyse beleuchtet. Wie läuft eine Architektur-Analyse bei einem Code Review ab und welche Erkenntnisse können daraus gezogen werden?

Aus der Softwarearchitektur lassen sich die wesentlichen Elemente des Systems und die Beziehungen zwischen ihnen erkennen. Die Architektur wird maßgeblich von den nicht-funktionalen Anforderungen (z.B. Zeitverhalten und Ressourcenverbrauch) an ein System beeinflusst. Für die Durchführung einer Architektur-Analyse an einer bestehenden Applikation ist die Kenntnis über nicht-funktionale Anforderungen somit von hoher Bedeutung.

Die Veranschaulichung der Architektur durch ein externes Code Review  kann sehr von Nutzen sein. So kann ein Abgleich zwischen einer möglicherweise vorhandenen Ziel-Architektur und der realisierten Architektur in der Anwendung vorgenommen werden. Hierdurch können Abweichungen festgestellt werden und es kann beurteilt werden, ob die Anwendung sich für den Einsatz in angedachten Betriebsszenarien eignet. Bei der Bewertung des Aufbaus und der Struktur einer Anwendung ist eine Ziel-Architektur oder zumindest die Kenntnis über ein gewünschtes Betriebsszenario entscheidend. Eine Architektur ist immer nur zu bewerten, wenn sie in einen Kontext gesetzt wird. Die Sinnhaftigkeit einer Architektur kann ohne Wissen über Anwendung und/oder Einsatzszenario nicht bewertet werden.

Die Architektur einer Anwendung lässt sich am leichtesten anhand von Diagrammen zeigen und veranschaulichen. Um  den Aufbau einer Anwendung darzustellen, eignen sich beispielsweise folgende UML-Diagramme:

  • Komponentendiagramm: Stellt die Zusammenhänge der einzelnen Komponenten mittels Schnittstellen, Abhängigkeitsbeziehungen und Konnektoren dar.
  • Verteilungsdiagramm: Beschreibt die Abhängigkeiten von Komponenten, indem deren Verteilungen und die Beziehungen zwischen den Komponenten auf Rechnerknoten dargestellt werden.

In der Praxis werden häufig Abwandlungen der UML-Notationen benutzt. Wichtig ist es hierbei eine generelle Verständlichkeit zu gewährleisten, weshalb ein Festhalten an gängigen Konventionen von Vorteil ist. Um eine Architektur visualisieren zu können, muss erstmal der grobe Aufbau einer Applikation verstanden werden. Dazu eignen sich zwei verschiedene Vorgehensweisen. Einmal kann es zu Beginn hilfreich sein die Software in große Module einzuteilen (Backend, Frontend, Datenbank, …).  Daran kann man prüfen, welche Schnittstellen und Datenflüsse zwischen den einzelnen Modulen bestehen. Aus welchem Modul werden Daten wohin gesendet und wie werden diese weiterverarbeitet? Anhand dieser Fragen können in der Regel weitere Komponenten/ Module dem Schaubild hinzugefügt werden bis sich ein Gesamtbild ergibt. Nach Fertigstellung des Gesamtbildes muss für die Betrachter des Diagrammes relativ einfach erkennbar sein, was für Komponenten die Software besitzt und wie diese im Zusammenspiel funktionieren.

Eine weitere Möglichkeit den Aufbau einer Software zu analysieren, ist eine automatisch generierte quellcodeseitige Aufteilung in Module und der darunterliegenden Komponenten. Über diese Übersicht, als eine Art Komponentenbaum, kann einfach ermittelt werden, welche Module es gibt und für welche Funktionalitäten im System diese zuständig sind. Daraufhin müssen die einzelnen Module noch über existierende Schnittstellen, Datenflüsse und Abhängigkeiten in Zusammenhang gesetzt werden.

In der ersten Herangehensweise nähert man sich dem Gesamtbild also durch eine grobe Einteilung in Module, welche nach und nach verfeinert wird. In der zweiten Variante geht man von seinem sehr kleinteiligen Aufbau der Module und darunterliegenden Komponenten aus, um diese zusammenzufassen und in Beziehung zueinander zu setzen. Neben der Visualisierung des Architekturbildes werden auch verwendete Frameworks und Technologien betrachtet und bewertet. Hierbei geht es vor allem um die Frage, ob eine Anwendung mit ihrem Aufbau und der verwendeten Technologien als zukunftsfähig angesehen werden kann und sich an einem aktuellen Technologiestack bedient hat. Bei schon länger in Betrieb genommenen Anwendungen muss beurteilt werden, ob Updates auf neuere Versionen benötigt werden und ob diese möglich sind.

Bei der Betrachtung der Architektur auf ein bestimmtes Einsatzszenario kann bewertet werden, ob diese dafür geeignet ist. Falls nicht können Verbesserungsvorschläge und Handlungsempfehlungen gegeben werden, um die Anwendung besser an das Zielszenario auszurichten. Zudem kann eine Einschätzung über die Zukunftstauglichkeit der Anwendung in ihrem momentanen Zustand und mit den verwendeten Technologien abgegeben werden.

Diesen Beitrag teilen

Benny Schwarting
IT-Consultant
Als IT-Consultant kümmert sich Benny maßgeblich um die Projektkoordination und das Requirements Engineering. Dabei hat er stets für unsere Kunden und deren Anforderungen ein offenes Ohr und steht ihn mit guten Ideen zur optimalen Lösungsfindung zur Seite.