View
1.067
Download
0
Category
Preview:
Citation preview
WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG
Dr. Carola Lilienthal
Carola.Lilienthal@wps.de@cairolaliwww.wps.de
Technische Schulden in Architekturen abbauen
25.10.2015 //// Seite 3WPS - Workplace Solutions GmbH
Zwei Architekturziele für Langlebigkeit
Architekturziel 1: Wartbarkeit
• schnelle Fehleranalyse
• schnelle Anpassungen
• Analysierbarkeit und Verständlichkeit
• Reduktion von Komplexität
Architekturziel 2: Flexibilität
• Varianten von Geschäftsprozessen
• Geänderte Anforderungen
• Microservices und Skalierbarkeit
• Baukastenprinzip
25.10.2015 //// Seite 4WPS - Workplace Solutions GmbH
Technischen Schulden = Architektur-Erosion
Grad derWartbarkeit
Neue Funktionalität pro Zeiteinheit
Korridor geringer technischer Schulden
Refactorings
Regelmäßige Architektur-Erneuerung
Architektur-Erosion
Wartung und Erweiterung
25.10.2015 //// Seite 5WPS - Workplace Solutions GmbH
Maßnahmen gegen technische Schulden
� Festlegen von verbindlichen Architekturzielen
� Durchgängige Architekturprinzipien und Architekturstile
� Automatisches Testen und Refactoring
� Weiterbildung der Architekturen und Entwickler
� Regelmäßige Architekturanalyse und -Erneuerung
25.10.2015 //// Seite 6WPS - Workplace Solutions GmbH
Architekturanalyse: Was ist das?
Findet sich die geplante Architektur (Soll-Architektur) in der Strukturen der implementierten Software (Ist-Architektur) wieder?
Plan mit
Klassen =
Soll-Architektur Ist-Architektur
≠ Sourcecode
DirectoriesDirectoriesPackagesNamespaces
Subsysteme KomponentenModule
Schichten
25.10.2015 //// Seite 7WPS - Workplace Solutions GmbH
Erfahrungen und Erkenntnisse
� Typische Eigenschaften der Architektur nach Größen und Sprache
� Strukturelle Einfachheit und Einheitlichkeit ist der Schlüssel zum Erfolg
� Ohne Architektur-Erneuerung sammeln sich technische Schulden an
Erkenntnisse
25.10.2015 //// Seite 8WPS - Workplace Solutions GmbH
Strukturelle Einfachheit der Architektur = Zeitgewinn!
Einfach, einheitliche Architektur
HierarchieModularitätMuster-
konsistenz
25.10.2015 //// Seite 9WPS - Workplace Solutions GmbH
Strukturelle Einfachheit der Architektur = Zeitgewinn!
Einfach, einheitliche Architektur
HierarchieModularitätMuster-
konsistenz
25.10.2015 //// Seite 10WPS - Workplace Solutions GmbH
Muster auf Architekturebene: Vier Module
Modul
Grün
Modul
LilaModul
Orange
Modul
Blau
25.10.2015 //// Seite 11WPS - Workplace Solutions GmbH
Musterkonsistenz: Was finden wir?
� Ist die Abbildung der Architektur in der Struktur des Codes zu erkennen?
25.10.2015 //// Seite 13WPS - Workplace Solutions GmbH
Muster in Architekturen: Entwurfsmuster und Mustersprachen
User Interface
Domain
Application
Fachliches ModulFachliches Modul
Window
GUI
Model
ViewControl
ValueObject
Service
BusinessObject
Sch
ich
tun
g d
urc
h M
uste
r
25.10.2015 //// Seite 14WPS - Workplace Solutions GmbH
Gute umgesetzte Mustersprache
☺ 90% des Sourcecodes lässt sich den Mustern zuordnen
☺ 0,1% Verletzungen in den Mustern
�������
�����������
25.10.2015 //// Seite 15WPS - Workplace Solutions GmbH
Entdeckung einer Mustersprache
☺ 80% des Sourcecodes lässt sich den 23 Mustern zuordnen
☺ 4% Verletzungen in den Mustern
25.10.2015 //// Seite 16WPS - Workplace Solutions GmbH
Strukturelle Einfachheit der Architektur = Zeitgewinn!
Einfach, einheitliche Architektur
HierarchieModularitätMuster-
konsistenz
25.10.2015 //// Seite 17WPS - Workplace Solutions GmbH
Modularität: Entwurf nach Zuständigkeiten
�Hohe Kohäsion und lose Kopplung
�Responsibility Driven Design
�Separation of Concern
�Single Responsibility Principle
25.10.2015 //// Seite 18WPS - 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“
25.10.2015 //// Seite 19WPS - Workplace Solutions GmbH
Beispiel: Größenverhältnis und Kopplungsgrad
� Große Steuerungsklassen benutzen bis zu 100 – 500 andere Klassen
� Ausgewogene Größenverhältnisse führen zu geringerer Kopplung
25.10.2015 //// Seite 20WPS - Workplace Solutions GmbH
Strukturelle Einfachheit der Architektur = Zeitgewinn!
Einfach, einheitliche Architektur
HierarchieModularitätMuster-
konsistenz
25.10.2015 //// Seite 21WPS - Workplace Solutions GmbH
User Interface
Domain
Application
Hierarchien in Architekturebene: Schichten und Module
Fachliches Modul B
Fachliches Modul B
Fachliches Modul A
Fachliches Modul A
Fachliche Schichtung
Tech
nis
ch
e S
ch
ich
tun
gFachliches
Modul CFachliches
Modul C
25.10.2015 //// Seite 22WPS - 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
25.10.2015 //// Seite 23WPS - Workplace Solutions GmbH
Fachliche Schichtung misslungen
Technische Schichtung Keine fachliche Schichtung
Wenige Schichten-
verletzungen
Fast alle 90 fachlichen
Komponenten brauchen sich gegenseitig
25.10.2015 //// Seite 24WPS - Workplace Solutions GmbH
Zyklische Strukturen sichtbar machen, bevor ….
119 Klassen aus 4 Komponenten+ 28 weitere Klassen
25.10.2015 //// Seite 25WPS - Workplace Solutions GmbH
sie immer weiter verklumpen!
327 Klassen aus 8 Komponentenbrauchen sich gegenseitig
25.10.2015 //// Seite 26WPS - Workplace Solutions GmbH
Der Zwang zur Zyklenfreiheit
80% des Sourcecodes
9 Komponenten = 17 Subsysteme
25.10.2015 //// Seite 27WPS - Workplace Solutions GmbH
Grundregeln struktureller Einfachheit für Architektur
Einheitliche Architektur
HierarchieModularitätMuster-
konsistenz
� Einheitlich und durchgängig
� Zyklenfreiheit auf allen Ebenen
� Zuständigkeit� Kopplung� Größenverhältnisse� Schnittstellen
25.10.2015 //// Seite 28WPS - Workplace Solutions GmbH
Kostenfreie Werkzeuge
• SonarQube:
• Leitstand für Qualitätsmetriken
• Plattform für vielfältige Plugins
• JDepend:
• wenige Metriken
• einfache Abhängigkeitsanalyse
• JDepend + Google Architecture Rules:
• einfache Architekturbeschreibung
• Ndepend/CDepend:
• Metriken
• Abhängigkeitsanalyse
• XRadar:
• Analyse von Java-Projekten via maven
• Reports bezüglich Komplexität und Architekturverletzungen
• Moose
• Code City
25.10.2015 //// Seite 29WPS - Workplace Solutions GmbH
Kommerzielle Produkte
� Axivion Bauhaus: Java, .Net, C/C++, Ada, VB und Cobol
� Lattix: Java, .Net, C/C++, Ada, Delphi und DB-Systeme
� Structure101: Java, C++, Ada
� SotoArc und Sonargraph: Java, .Net, C/C++, ABAP, PHP
• TeamScale
• Software-
Diagnostics
25.10.2015 //// Seite 30WPS - Workplace Solutions GmbH
Vorgehen bei der Architekturanalyse und Verbesserung
25.10.2015 //// Seite 31WPS - Workplace Solutions GmbH
Phase 1: Aufräumen
Schrittweise Weiterentwicklung der Architektur
Phase 2: Verbessern Phase 3: Erhalten
Phase 1: AufräumenAbgleich Soll-/Ist-Architektur
fehlende Architektur-konzepte ergänzen
Phase 2: VerbessernArchitektur diskutieren
und verbessernArchitekturregeln
festlegen
Phase 3: ErhaltenIm Architekturkorridor
bleibenLanglebigkeit fördern
Initialer
Workshop
Verletzungen behebenStrukturen einziehen
Analyse-Workshop
Anpassungen an neue Architektur-
Regeln
Nach-
sorgekleinere
Reparaturen
25.10.2015 //// Seite 32WPS - Workplace Solutions GmbH
Leitstand für Verbesserungen im laufenden Betrieb
� Die Architekturziele sind im ganzen Team präsent und werden verfolgt.
� Softwarewartung und –Änderung ist einfacher und kostengünstig.
� Die Software ist stabil, flexibel und langlebig.
� Neue Mitarbeiter können nach kurzer Zeit produktiv mitentwickeln.
Ergebnis
TatsächlichesProblem?24%
34%
44%
54%
64%
74%
84%
94%
v1.0 v1.1_b1 v1.1_b2 v1.1_b3 v1.1 v1.2_b1 v1.2 v2.0_b1 v2.0_b2 v2.0
Architekturqualität
Feinentwurfsqualität
Implementierungsqualität
Testabdeckung
Recommended