Softwarearchitektur bewerten und pflegen

Anbieter zum Thema

MicroConsult Academy GmbH

MES Electronic Connect GmbH & Co. KG

ISH Ingenieursozietät GmbH

Coverity, Inc.

Fat Metrix und die Anwendungsarchitektur

An jedem Punkt innerhalb des Designs ist es möglich, zu viel Komplexität einzuführen. Nach einer grundsätzlichen Regel sollten Entwickler die Komplexität auf „hirngerechte Portionen“ begrenzen, so dass sie jede Komponente sehen und verstehen können. Fat misst die Abhängigkeiten innerhalb einer Codebasis und stellt die Komplexität dar. Viele Entwickler sind mit zyklischer Komplexität, einem Maß für die Komplexität auf Funktionsebene, vertraut. Um Fat in der Anwendungsarchitektur zu definieren, kann man es als zyklische Komplexität bezeichnen, die auf allen Ebenen eines Softwaresystems herrscht - nicht nur auf der Funktionsebene.

Ein Softwaresystem kann Fat genannt werden, wenn seine hierarchische Struktur zu viel Code auf einem Level in der Hierarchie der Codebasis enthält. Ist z.B. ein Abhängigkeitsgraph nicht lesbar, kann man von einem Entwickler nicht erwarten, dass er die Architektur der repräsentierten Codebase versteht. Ein anderer Weg sich Fat in einer Anwendungsarchitektur vorzustellen ist, Fat als fehlende Struktur im dem zugrunde liegenden Code zu betrachten.

Zu viel Fat in einer Anwendung ruft folgende Probleme hervor:

• Fat Code ist schwer zu verstehen, weil man dazu die einzelnen Funktionen jeder Komponente verstehen muss, was an sich schon schwierig ist. Will ein Entwickler Fat Code verstehen, muss er graduell ein Verständnis für alle Komponenten aufbauen, bevor er wirklich jedes einzelne Stück versteht. Dieses Henne-Ei-Problem lässt sich nur mit vielen teuren Iterationen lösen.
• Fat Code ist schwer zu visualisieren und dadurch schlecht erklärbar.
• Fat Code lässt sich nur mit großem Aufwand modifizieren, weil er saubere Abstraktionen ermangelt und Änderungen unerwartete Effekte auf große Teile des Systems haben können.

Drahtseilakt zwischen Tangle und Fat

Eine fundamentale Herausforderung ist der Ausgleich zwischen Fat und Tangle in einer vorgegebenen Codebasis. Grundsätzlich sollte eine Codebasís einen gewissen Grad an zyklischen Abhängigkeiten zulassen (etwa zwischen Klassen und Funktionen), aber diese Tangles sollten eine handhabbare Größe haben. Einem Tangle sollte nicht möglich sein, zu einer Größe oder Komplexität anzuwachsen, mit der es sich zwischen höheren Levelkomponenten erstreckt.

Für Architekten und Entwickler ist es hiflreich, die kombinierte Bewertung von Fat und Tangle über die Codebasis hinweg zu überblicken, um die Balance der beiden Variablen objektiv einschätzen zu können. Ein Beispiel dieses Einblicks, wie ihn das Tool Coverity Architecture Analyzer ermöglicht, zeigt Bild 2.

Wird das Design einer Architektur überkompensiert, um entweder Fat oder Tangle zu kontrollieren, steigt die Wahrscheinlichkeit für Probleme, die aufgrund eines Übermaßes des anderen entstehen. Um etwa das Tangle in einem Softwaresystem zu kontrollieren, mag ein Entwickler kontinuierlich neue Codekomponenten kreieren, die abwärts gerichtete Abhängigkeiten zu den oberen haben. Geschieht das zu oft, können Entwicklungsteams den Code nicht mehr einsetzen, weil dies zu viele schwer nachzuvollziehende Abhängigkeiten hervorruft.

Ähnlich ist es mit Fat in einer Anwendungsarchitektur: Manche Entwickler wollen mit dem zusammenschließen verschiedener Codekomponenten auf demselben hierarchischen Level zu einer einzigen größeren Komponente die potenziellen Probleme eliminieren. Dies birgt Tücken, denn mit der Zeit wächst die Versuchung eine einzelne Komponente der großen Komponente nochmals zu benutzen. Kommt es zum Wiedereinsatz, wird der andere Code aus der größeren Komponente unnötig verstrickt und kann die Anwendung mit Code aufblähen, der nie genutzt wird. Letztlich ist die Codebasis noch schwieriger zu pflegen.

(ID:331782)