Software-Entwurf

Softwarearchitektur bewerten und pflegen

Seite: 2/4

Anbieter zum Thema

Abhängigkeiten durch Abstraktionsverletzungen:

  • Abhängigkeit, die einen Level in der Hierarchie des Softwaresystems überspringt und somit gewünschte Funktionen umgeht.
  • Sicherheitsschwachstellen können durch das Umgehen einer Authentifizierungsschicht entstehen.

Architektonische Komplexität bewerten: Tangle und Fat

Um mit Softwarekomplexität umzugehen, muss man zwischen erforderlicher und unabsichtlicher Komplexität unterscheiden. In Systemen gibt es Komplexitäten, die man nicht vermeiden kann – baut man z.B. eine Rakete, ist das schwer. Trotzdem gibt es Komplexitäten, die für den Bau des Softwaresystems nicht nötig sind.

Ein Beispiel wären die überflüssigen und ungewollten Abhängigkeiten, die entstehen, wenn ein Entwickler den Gesamtplan nicht versteht. Zufällige Komplexitäten führen zu anfälligem Code. Daher sollte man sicher gehen und Zeit zum Reduzieren von schlechter Komplexität aufwenden, nicht von Guter. Architektonische Komplexität kann den Erfolg eines Softwareprojektes genauso gefährden wie immens komplexer, fehleranfälliger Code.

Die architektonische Komplexität im Rahmen eines gegebenen Software-Systems zu verstehen erfordert geeignete Mittel zur Bewertung. um zu verstehen, wo Reparaturen, Überarbeitungen oder eine neue Architektur von Nöten sind, um Qualitätsdefekte und Sicherheitsschwachstellen zu verhindern. Die Komplexität einer Anwendungsarchitektur kann mit den zwei Metriken Tangle und Fat evaluiert werden.

Ein Softwaresystem ist tangled, wenn es Abhängigkeiten enthält, die ungewollte Auswirkungen auf eine Codekomponente haben, wenn maneine andere Komponente modifiziert. Der Abhängigkeitsgraph in Bild 1 veranschaulicht Abhängigkeiten, die zwischen Codekomponenten existieren bevor sie in eine Anwendung zusammengeführt werden. Sind alle Abhängigkeiten in der Komponentenhirarchie „nach unten gerichtet“, gibt es keine Abhängigkeiten, die die Qualität oder Sicherheit der Software gefährden.

Bild 1: Graph mit gefährlichen Abhängigkeiten zwischen den Komponenten. Ein Softwaresystem ist tangled, wenn es Abhängigkeiten enthält, die ungewollte Auswirkungen auf eine Codekomponente haben, wenn man eine andere Komponente modifiziert. (Archiv: Vogel Business Media)

Im Gegensatz dazu stellt Bild 1 ein Tangle von neun Packages dar. Für Entwickler, die diese Codebasis pflegen müssen, bedeuten die zyklischen oder aufwärts gerichteten Abhängigkeiten unnötige Herausforderungen:

  • Komplizierte Tests: Bei übermäßig komplexen Abhängigkeiten muss man viele Codekomponenten herauslösen, um sie effektiv zu testen. Besteht etwa eine Codebase aus mehreren Schichten, kann das QA-Team jede Komponente samt ihren Abhängigkeiten von unten nach oben testen, so dass es immer gegen bereits getestete Komponenten testet. Bei zyklischen Abhängigkeiten müssen Entwickler alle Komponenten auf einmal testen und wiederverwerten.
  • Starre Freigabetermine: Die Freigabe aller Codekomponenten in einem Tangle muss wegen der Abhängigkeiten, die sie miteinander teilen, zur gleichen Zeit erfolgen.
  • Kontrollprobleme: Entwickler, die an einem tangled Code arbeiten, müssen mit Versionsproblemen rechnen, da ihre Files grundlegend mit den Files anderer Entwickler verbunden sind.

(ID:331782)