Kontrolle über Architekturerosion durch Softwarearchitektur-Management Thomas Schoen hello2morrow GmbH, Software-Tomography GmbH 1
Innere (technische, strukturelle) Softwarequalität Wie gut ist die Software gebaut? zur Sicherstellung von Verstehbarkeit Änderbarkeit Erweiterbarkeit Wiederverwendbarkeit Testbarkeit Software-Architektur 2
Innere (technische, strukturelle) Softwarequalität Wie gut ist die Software gebaut? Die Antwort steht im Sourcecode! 3
Softwarearchitektur Stimmt der Architekturentwurf (Soll-Architektur) mit den Strukturen der implementierten Software (IST-Architektur) überein? 4
Was bedeutet "Softwarearchitektur"? Eine Softwarearchitektur definiert die grundlegenden Komponenten und deren Zusammenspiel innerhalb eines Softwaresystems. Diese Komponenten bilden eine Zerlegung des Gesamtsystems. Jedes Code-Artefakt (z.b. Datei) ist einer Architekturkomponente eindeutig zugeordnet. Der Architekturentwurf ist eine wesentliche (kritische und wichtige) Softwaredesign- Entscheidung. Sie wird in einem sehr frühen Projektstadium getroffen und ist später nur mit hohem Aufwand änderbar. Beim Architekturentwurf sind Kriterien entscheidend wie Erweiterbarkeit, Wartbarkeit, Wiederverwendbarkeit aber auch Stabilität, Fehlertoleranz, Performanz. 5
Architektur-Erosion Die IST-Struktur/Architektur des Projektcodes stimmt immer weniger mit der geplanten Architektur (SOLL-Architektur) überein Softwaresysteme erodieren zunehmend über die Projektlebensdauer Ein automatischer Prozess Gründe für Architektur-Erosion Zeitdruck führt zu Abkürzungen, die später nie durch saubere Lösungen ersetzt werden Verständnis/Wissen über das System und Projekterfahrung sind nicht überall im Team in gleicher Weise vorhanden. Verschärftes Problem -> Outsourcing Hacks: Architekturelle Vorgaben werden beim Implementieren ignoriert oder umgangen. Architekturverletzende Abhängigkeiten entstehen oft unbemerkt und bleiben dies auch für längere Zeit. Kopplungsgrad und Komplexität wachsen im Projekt oft schneller als man erwartet. Wenn man es bemerkt und den Überblick verliert, gibt es oft keinen Weg zurück. Dem Projektmanagement ist die innere Softwarequalität oft nicht wichtig: Black Box; wirkt sich erst mit Verzögerung aus; Zusammenhang oft unklar Es ist nicht möglich, alle Architekturverletzungen in einem Softwaresystem manuell zu erkennen. 6
Architektur-Erosion Symptome Symptome Hoher Kopplungsgrad Viele Zyklen 7
Technisch Architektur-Erosion Wieso ist das ein Problem? Systeme werden immer schwerer zu warten Verstehbarkeit Testbarkeit Seiteneffekte bei Änderungen/Erweiterungen Ökonomisch Es wird immer teurer Systeme zu warten, bis es ökonomisch nicht mehr sinnvoll ist. Forderung nach Redesign -> Neuimplementierung Ein Hauptgrund für überzogene Projekt- und Wartungsbudgets 8
Kosten durch Architektur-Erosion Kosten einer Erweiterungsmassnahme Steigen in architekturkonformen Systemen während des Lebenszyklus nur geringfügig. Steigen in erodierten Systemen mit Lebensdauer (und Fortschritt des Erosionsprozesses) kontinuierlich und deutlich an. Erodierte Systeme sind schwerer verstehbar und verursachen viele Seiteneffekte Dadurch dauert die Implementierung einer Erweiterung länger und wird teurer. Dadurch werden bei der Implementierung mehr Fehler eingeschleppt. Diese verursachen zusätzliche Kosten. Die Kosten unterscheiden sich häufig um mehr als den Faktor 2. Kosten für Erweiterung 70 60 50 40 30 20 10 Erweiterungsmassnahme erodiertes System Erweiterungsmassnahme architekturkonformes System 0 Projekt-Lebensdauer 9
Softwarearchitektur-Management Definition SOLL-Architektur Analyse IST-Architektur Abgleich von SOLL / IST- Architektur Anpassung / Erweiterung Architekturentwurf Planung der Code-Restrukturierung Regelmässig: Architekturmonitoring Werkzeugunterstützung Architekturverifikation am Entwicklerarbeitsplatz Implementierung 10
Statische Codeanalyse Welche Informationen kann ein Werkzeug aus dem Code herauslesen? Duplizierte Codeblöcke Verstöße gegen Codierungsregeln Verletzung von Namenskonventionen Entartete Objekte (zu große/kleine Methoden, Klassen, Packages) Besonders komplexe Objekte (zyklomatische Komplexität) Stark gekoppelte Objekte Ungenutzte Codesegmente Verstöße gegen OO-Prinzipien (entartete Vererbung, direkter Class- Member-Zugriff) Zyklische Abhängigkeiten auf Klassen-/Package-/Architekturebene Verletzung von Komponenten-Schnittstellen Architekturverletzungen (Verstöße gegen eine vorgegebene Softwarearchitektur) 11
Strukturanalyse des Quellcodes Werkzeuggestützte Statische Codeanalyse Im Code identifizierbare Artefakte Typen (Klassen, Interface-Klassen, Structs, Unions) Methoden, Attribute Funktionen, Variabeln Source Dateien, Directories Java Packages, C# Namespaces Code Referenzen 12
Abhängigkeiten / Benutzungsbeziehungen Abhängigkeiten zwischen beliebigen Artefakten: Vererbungsbeziehungen Call-Referenzen (Aufrufbeziehungen); auch polymorphe Lesezugriff auf Attribute/Variabeln Schreibzugriff auf Attribute/Variabeln Typverwendung bei der Definition von Attributen Beliebige andere Benutzung von Typen/Klassen 13
Aggregation auf höhere Abstraktionsebnen: Analyse auf Symbolebene 500.000 LOC 50.000 Symbole 14
Aggregation auf höhere Abstraktionsebnen: Analyse auf Klassen/Dateiebene 4.000 Klassen 15
Aggregation auf höhere Abstraktionsebnen: Analyse auf Paket/Verzeichnisebene 250 Packages 16
Aggregation auf höhere Abstraktionsebnen: Analyse auf Subsystemebene 20 Subsysteme 17
Aggregation auf höhere Abstraktionsebnen: Subsystemschnittstellen 18
Definition einer Softwarearchitektur Beispiel Schichtenmodell Strikte Schichtung durchbrochen (optional) Fachebene 2 Fachebene 1 Allgemeine Funktionen Aufwärtsreferenz zwischen vertikalen Schnitten Oberfläche Verletzung von Schnittstellen Schnittstelle Fachlogik Aufwärtsreferenz Datenhaltung Illegale Benutzungsbeziehungen: 19
Verfolgung illegaler Beziehungen: Zoomen bis in den Code Aufwärts-Referenzen Referenzen zwischen Schichten zwischen Subsystemen zwischen Packages zwischen Klassen/Dateien Bis zum Sprung an die entsprechende Quellcode-Stelle 20
Zyklische Strukturen LEVEL Element A 3 Element A Element B 2 Element B Element C 1 Element C cyclic acyclic 21
Nachteil zyklischer Strukturen LEVEL Element A 3 Element A Element B 2 Element B Element C 1 Element C cyclic acyclic Verstehbarkeit der Funktionalität/Rolle einer einzelnen Komponenten Testbarkeit einzelner Komponenten Wiederverwendbarkeit eingeschränkt Eine Impact Analyse ist problematisch und unsicher Isolierte Fehlerbehebung in einer Komponente nicht möglich 22
Praxisbeispiel: zyklische Struktur Erfahrung in grossen Projekten zeigt dass Zyklen die Wartbarkeit deutlich verschlechtern. erodierte Systeme durch das systematische Aufbrechen von Zyklen wieder wartbar gemacht werden können. 23
Vermeidung von zyklischen Strukturen Large-Scale C++ Software Design, John Lakos,1996: Cyclic physical dependencies in large, low-level subsystems have the greatest capacity to increase the overall cost of maintaining a system Cyclic physical dependencies among components inhibit understanding, testing and reuse Agile Software Development, Robert C. Martin, 2003: The dependencies between packages must not form cycles. Forderung für Software-Architekturmanagement Keine zyklischen Strukturen im Architekturentwurf Zyklen auf Packageebene möglichst vermeiden insbesondere über Subsystemgrenzen hinweg 24
Erfolgsfaktoren für Software-Architekturmanagement Unterstützung durch das Management Einen/mehrere Verantwortliche im Projekt Entwurf einer vollständigen, zyklenfreien Softwarearchitektur vor der Implementierungsphase Konsistenz zwischen Architektur- und physischer Codeebene: Package/Namespace-Strukturen, Namensschema Vernünftige Granularität der Codeeinheiten: Z.B. Packagegrösse Einsatz leistungsfähiger Werkzeuge zur Architekturanalyse Regelmässiges Monitoring der aktuellen Architektur Trendvergleich: Übersicht der Entwicklung der Architekturtreue über verschiedene Versionsstände hinweg Kontinuierliche Reparatur von Architekturverletzungen: Stoppen der Architekturerosion 25
www.software-tomography.ch 26