Softwarearchitektur-Management

Transkript

1 Kontrolle über Architekturerosion durch Softwarearchitektur-Management Thomas Schoen hello2morrow GmbH, Software-Tomography GmbH 1

2 Innere (technische, strukturelle) Softwarequalität Wie gut ist die Software gebaut? zur Sicherstellung von Verstehbarkeit Änderbarkeit Erweiterbarkeit Wiederverwendbarkeit Testbarkeit Software-Architektur 2

3 Innere (technische, strukturelle) Softwarequalität Wie gut ist die Software gebaut? Die Antwort steht im Sourcecode! 3

4 Softwarearchitektur Stimmt der Architekturentwurf (Soll-Architektur) mit den Strukturen der implementierten Software (IST-Architektur) überein? 4

5 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

6 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

7 Architektur-Erosion Symptome Symptome Hoher Kopplungsgrad Viele Zyklen 7

8 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

9 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 Erweiterungsmassnahme erodiertes System Erweiterungsmassnahme architekturkonformes System 0 Projekt-Lebensdauer 9

10 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

11 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

12 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

13 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

14 Aggregation auf höhere Abstraktionsebnen: Analyse auf Symbolebene LOC Symbole 14

15 Aggregation auf höhere Abstraktionsebnen: Analyse auf Klassen/Dateiebene Klassen 15

16 Aggregation auf höhere Abstraktionsebnen: Analyse auf Paket/Verzeichnisebene 250 Packages 16

17 Aggregation auf höhere Abstraktionsebnen: Analyse auf Subsystemebene 20 Subsysteme 17

18 Aggregation auf höhere Abstraktionsebnen: Subsystemschnittstellen 18

19 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

20 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

21 Zyklische Strukturen LEVEL Element A 3 Element A Element B 2 Element B Element C 1 Element C cyclic acyclic 21

22 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

23 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

24 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

25 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

26 26