Langlebige Softwarearchitekturen Dr. Carola Lilienthal Carola.Lilienthal@wps.de www.wps.de //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG Die zwei Architekturziele für diesen Vortrag Architekturziel 1: Wartbarkeit Stabilität und Verständlichkeit Reduktion von Komplexität schnelle Fehleranalyse schnelle Changes Architekturziel 2: Fachliche Flexibilität Geschäftsprozesse verschiedener Kunden unterstützen Anpassbarkeit an geänderte Anforderungen Baukastenprinzip 08.07.2015 //// Seite 2 1
Technischen Schulden = Architektur-Erosion Grad der Wartbarkeit Regelmäßige Architektur-Erneuerung Korridor für gute Architekturqualität Architektur- Erosion Refactorings Neue Funktionalität pro Zeiteinheit 08.07.2015 //// Seite 3 Architekturanalyse: Was ist das? Findet sich die geplante Architektur (Soll-Architektur) in der Strukturen der implementierten Software (Ist-Architektur) wieder? Soll-Architektur Ist-Architektur Quelltext 08.07.2015 //// Seite 4 2
Erfahrungshintergrund Architekturanalysen in Java, C#, C++, ABAP etc. Erkenntnisse Typische Eigenschaften je nach Größe Strukturelle Einfachheit und Einheitlichkeit Ohne regelmäßige Architektur-Erneuerung degenerieren Systeme Analysewerkzeuge SotoArc + Sotograph SonarJ Sonargraph Lattix 08.07.2015 //// Seite 5 Strukturelle Einfachheit der Architektur = Zeitgewinn! Einfach, einheitliche Architektur Modularität Geordnetheit Mustertreue 08.07.2015 //// Seite 6 3
Strukturelle Einfachheit der Architektur = Zeitgewinn! Einfach, einheitliche Architektur Modularität Geordnetheit Mustertreue 08.07.2015 //// Seite 7 Mustertreue: Was finden wir? Ist die Abbildung der Architektur in der Struktur des Codes zu erkennen? 08.07.2015 //// Seite 8 4
Architekturstile: Was ist das? Ein Architekturstil ist eine prinzipielle Lösungsstruktur, die für ein Softwaresystem durchgängig und unter weitgehendem Verzicht auf Ausnahmen angewandt werden sollte. [Reussner et al. 2006] Komponentenarchitektur Schichtenarchitektur Mustersprache GUI Window View Model C on t r o l Service BusinessObject ValueObject 08.07.2015 //// Seite 9 Zwei Dimensionen einer Architektur Technische Schichtung Fachliche Schichtung Eine Komponente verursacht die Probleme Schwer zu behebende Verletzungen Leicht zu behebende Verletzungen Eine Komponente verursacht die Probleme 08.07.2015 //// Seite 10 5
Fachliche Schichtung misslungen Technische Schichtung Fast alle 90 fachlichen Komponenten brauchen sich gegenseitig Keine fachliche Schichtung Wenige Schichtenverletzungen 08.07.2015 //// Seite 11 Mustersprache 80% des Sourcecodes lässt sich den 23 Mustern zuordnen 4% Verletzungen in den Mustern 08.07.2015 //// Seite 12 6
Strukturelle Einfachheit der Architektur = Zeitgewinn! Architekturkomplexität Modularität Geordnetheit Mustertreue 08.07.2015 //// Seite 13 Modularität: Entwurf nach Zuständigkeiten Entwurf nach Zuständigkeiten (engl.: Responsibility-Driven Design) ist eine Entwurfsphilosophie, die von Rebecca Wirfs-Brock et al. Ende der 80er Jahre formuliert wurde: Dazu passende Ansätze: Separation of Concerns (Dijkstra) Modularität (Parnas) Objects are not just simple bundles of logic and data. They are responsible members of an object community. Kohäsion (Myers, Coad&Yourdon) Single Responsibility Principle (SRP) (Robert C. Martin) Jede Klasse, jedes Paket, jedes Subsystem, jedes Modul, jede Schicht sollte für eine klar definierte Aufgabe zuständig sein. 08.07.2015 //// Seite 14 7
Modularität: Ausgewogene Größenverhältnisse Ist das System auf den verschiedenen Ebenen ausgewogen? Welche Code-Abschnitte fallen durch ihre Größe besonders auf? Typische Metriken: LOC pro Methode, Klasse, Package, Komponenten Duplizierter Code Zyklomatische Komplexität Anti-Pattern Godclass 08.07.2015 //// Seite 15 Kopplungsgrad Ist das System auf den verschiedenen Ebenen lose gekoppelt? Welche Code-Abschnitte fallen durch besonders viele Beziehungen auf? Ziel: Lose Kopplung 08.07.2015 //// Seite 16 8
Beispiel: Größenverhältnis und Kopplungsgrad Große Steuerungsklassen benutzen bis zu 100 500 andere Klassen 300 30 250 25 RLOC/Klasse 200 150 100 50 0 0 200.000 400.000 600.000 800.000 1.000.000 1.200.000 1.400.000 RLOC Beziehungen/Klasse 20 15 10 5 0 0 200.000 400.000 600.000 800.000 1.000.000 1.200.000 1.400.000 RLOC Ausgewogene Größenverhältnisse auf allen Ebenen führen zu geringerer Kopplung und besserem objektorientiertem Entwurfs 08.07.2015 //// Seite 17 Strukturelle Einfachheit der Architektur = Zeitgewinn! Architekturkomplexität Modularität Geordnetheit Mustertreue 08.07.2015 //// Seite 18 9
Zyklenfreiheit Hierarchische Strukturen Acyclic Dependencies Principle (ADP) Auswirkung auf: Wartbarkeit Austauschbarkeit Testbarkeit Einstiegspunkt beim Analysieren Zyklen zwischen Klassen, Paketen, Komponenten und Schichten vermeiden 08.07.2015 //// Seite 19 Große Zyklen sichtbar machen 327 Klassen aus 8 Komponenten brauchen sich gegenseitig 08.07.2015 //// Seite 20 10
Der Zwang zur Zyklenfreiheit 80% des Sourcecodes 9 Komponenten = 17 Subsysteme 08.07.2015 //// Seite 21 Grundregeln struktureller Einfachheit für Architektur Architekturkomplexität Modularität Geordnetheit Mustertreue Zuständigkeit Kopplung Größenverhältnisse Schnittstellen Zyklenfreiheit auf allen Ebenen Architekturstil(e) Einheitlich und durchgängige 08.07.2015 //// Seite 22 11
Schrittweise Weiterentwicklung der Architektur Phase 1: Aufräumen Phase 1 Soll-/Ist-Architektur vergleichen Phase 2: Verbessern Phase 2 Architektur diskutieren und verbessern Phase 3: Erhalten Phase 3 Im Architekturkorridor bleiben und Architektur verbessern 2-Tage Workshop Verletzungen beheben 2x2-Tage Workshop Anpassungen an neue Architektur -Guidlines 1-Tages Workshop Reparaturen ½-Tages Workshop 08.07.2015 //// Seite 23 Vielen Dank für Ihre Aufmerksamkeit. Diplom-Informatikerin Dr. Carola Lilienthal Mitglied der Geschäftsleitung cl +49 170 184 77 11 08.07.2015 //// Seite 24 12