Post on 19-Oct-2020
transcript
08.07.2015
1
WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG
Dr. Carola Lilienthal
Carola.Lilienthal@wps.de
www.wps.de
Langlebige Softwarearchitekturen
08.07.2015 //// Seite 2WPS - Workplace Solutions GmbH
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
2
08.07.2015 //// Seite 3WPS - Workplace Solutions GmbH
Technischen Schulden = Architektur-Erosion
Grad der
Wartbarkeit
Neue Funktionalität
pro Zeiteinheit
Korridor für gute
Architekturqualität
Refactorings
Regelmäßige Architektur-Erneuerung
Architektur-
Erosion
08.07.2015 //// Seite 4WPS - Workplace Solutions GmbH
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
3
08.07.2015 //// Seite 5WPS - Workplace Solutions GmbH
Erfahrungshintergrund
� SotoArc + Sotograph
� SonarJ � Sonargraph
� Lattix
Analysewerkzeuge
Architekturanalysen in Java, C#, C++, ABAP etc.
� Typische Eigenschaften je nach Größe
� Strukturelle Einfachheit und Einheitlichkeit
� Ohne regelmäßige Architektur-Erneuerung
degenerieren Systeme
Erkenntnisse
08.07.2015 //// Seite 6WPS - Workplace Solutions GmbH
Strukturelle Einfachheit der Architektur = Zeitgewinn!
Einfach, einheitliche
Architektur
GeordnetheitModularität Mustertreue
08.07.2015
4
08.07.2015 //// Seite 7WPS - Workplace Solutions GmbH
Strukturelle Einfachheit der Architektur = Zeitgewinn!
Einfach, einheitliche
Architektur
GeordnetheitModularität Mustertreue
08.07.2015 //// Seite 8WPS - Workplace Solutions GmbH
Mustertreue: Was finden wir?
� Ist die Abbildung der Architektur in der Struktur des Codes zu erkennen?
08.07.2015
5
08.07.2015 //// Seite 9WPS - Workplace Solutions GmbH
Architekturstile: Was ist das?
SchichtenarchitekturKomponentenarchitektur
ValueObject
Window
GUI
Service
BusinessObject
Model
View
Control
Mustersprache
„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]
08.07.2015 //// Seite 10WPS - Workplace Solutions GmbH
Zwei Dimensionen einer Architektur
Technische Schichtung Fachliche Schichtung
Leicht zu
behebende
Verletzungen
Schwer zu
behebende
Verletzungen
Eine
Komponente
verursacht die
Probleme
Eine
Komponente
verursacht die
Probleme
08.07.2015
6
08.07.2015 //// Seite 11WPS - Workplace Solutions GmbH
Fachliche Schichtung misslungen
Technische Schichtung Keine fachliche Schichtung
Wenige
Schichten-
verletzungen
Fast alle 90
fachlichen
Komponenten
brauchen sich
gegenseitig
08.07.2015 //// Seite 12WPS - Workplace Solutions GmbH
Mustersprache
☺ 80% des Sourcecodes lässt sich den 23 Mustern zuordnen
☺ 4% Verletzungen in den Mustern
08.07.2015
7
08.07.2015 //// Seite 13WPS - Workplace Solutions GmbH
Strukturelle Einfachheit der Architektur = Zeitgewinn!
Architekturkomplexität
GeordnetheitModularität Mustertreue
08.07.2015 //// Seite 14WPS - Workplace Solutions GmbH
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:
„Objects are not just simple bundles of logic and data. They are responsible members of an
object community.“
�Jede Klasse, jedes Paket, jedes Subsystem, jedes Modul, jede Schicht
sollte für eine klar definierte Aufgabe zuständig sein.
� Dazu passende Ansätze:
� Separation of Concerns (Dijkstra)
� Modularität (Parnas)
� Kohäsion (Myers, Coad&Yourdon)
� Single Responsibility Principle (SRP) (Robert C. Martin)
08.07.2015
8
08.07.2015 //// Seite 15WPS - Workplace Solutions GmbH
Modularität: Ausgewogene Größenverhältnisse
Typische Metriken:
� LOC pro Methode, Klasse, Package, Komponenten
� Duplizierter Code
� Zyklomatische Komplexität
� Ist das System auf den verschiedenen Ebenen ausgewogen?
� Welche Code-Abschnitte fallen durch ihre Größe besonders auf?
Anti-Pattern„Godclass“
08.07.2015 //// Seite 16WPS - Workplace Solutions GmbH
Kopplungsgrad
Ziel: Lose Kopplung
� Ist das System auf den verschiedenen Ebenen lose gekoppelt?
� Welche Code-Abschnitte fallen durch besonders viele Beziehungen auf?
08.07.2015
9
08.07.2015 //// Seite 17WPS - Workplace Solutions GmbH
Beispiel: Größenverhältnis und Kopplungsgrad
0
5
10
15
20
25
30
0 200.000 400.000 600.000 800.000 1.000.000 1.200.000 1.400.000
RLOCB
ezie
hu
ng
en
/Kla
sse
0
50
100
150
200
250
300
0 200.000 400.000 600.000 800.000 1.000.000 1.200.000 1.400.000
RLOC
RL
OC
/Kla
sse
� Große Steuerungsklassen benutzen bis zu 100 – 500 andere Klassen
� Ausgewogene Größenverhältnisse auf allen Ebenen führen zu geringerer
Kopplung und besserem objektorientiertem Entwurfs
08.07.2015 //// Seite 18WPS - Workplace Solutions GmbH
Strukturelle Einfachheit der Architektur = Zeitgewinn!
Architekturkomplexität
GeordnetheitModularität Mustertreue
08.07.2015
10
08.07.2015 //// Seite 19WPS - Workplace Solutions GmbH
Zyklenfreiheit – Hierarchische StrukturenAcyclic Dependencies Principle (ADP)
Auswirkung auf:
� Wartbarkeit
� Austauschbarkeit
� Testbarkeit
� Einstiegspunkt beim
Analysieren
� Zyklen zwischen Klassen, Paketen,
Komponenten und Schichten vermeiden
08.07.2015 //// Seite 20WPS - Workplace Solutions GmbH
Große Zyklen sichtbar machen
327 Klassen aus 8 Komponenten
brauchen sich gegenseitig
08.07.2015
11
08.07.2015 //// Seite 21WPS - Workplace Solutions GmbH
Der Zwang zur Zyklenfreiheit
80% des Sourcecodes
9 Komponenten = 17 Subsysteme
08.07.2015 //// Seite 22WPS - Workplace Solutions GmbH
Grundregeln struktureller Einfachheit für Architektur
Architekturkomplexität
GeordnetheitModularität Mustertreue
� Architekturstil(e)
� Einheitlich und
durchgängige
� Zyklenfreiheit auf
allen Ebenen
� Zuständigkeit
� Kopplung
� Größenverhältnisse
� Schnittstellen
08.07.2015
12
08.07.2015 //// Seite 23WPS - Workplace Solutions GmbH
Phase 1: Aufräumen
Phase 1
Soll-/Ist-Architektur
vergleichen
Phase 2
Architektur diskutieren und
verbessern
Phase 3
Im Architekturkorridor
bleiben und Architektur
verbessern
2-Tage
Workshop
Verletzungen
beheben
Tage 2x2-Tage
Work-
shop
Anpassungen an
neue Architektur
-Guidlines
1-Tages
Work-
shop
Repara-
turen
Tages½-Tages
Work-
shop
Schrittweise Weiterentwicklung der Architektur
Phase 2: Verbessern Phase 3: Erhalten
08.07.2015 //// Seite 24WPS - Workplace Solutions GmbH
Vielen Dank für Ihre Aufmerksamkeit.
Dr. Carola Lilienthal
Mitglied der Geschäftsleitung
cl
+49 170 184 77 11
Diplom-Informatikerin