Langlebige architekturen

WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG

Langlebige Softwarearchitekturen - technische Schulden beherrschen und abbauen

Dr. Carola [email protected], @cairolaliwww.wps.de

07.02.2016 //// Seite 2WPS - Workplace Solutions GmbH

Die WPS – Workplace Solutions GmbH

Anwendungsorientierung

Kompetenz

Qualität

Software-Architektur

Anforderungs-ermittlung

Leitstand und Interaktion

Individual-software

Business-Software,die Spaß macht!



Technische Schulden ≠ Langlebigkeit


Maßnahmen gegen technische Schulden

� Kontinuierliche Architekturdiskussion

� Weiterbildung der Architekturen und Entwickler

� Automatisches Testen und Refactoring

� Regelmäßige Architekturanalyse und -Erneuerung


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


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

• Serviceorientierung und Skalierbarkeit

• Baukastenprinzip


Expertise zu Architekturanalyse

� Architektur-Review und Bewertungen mit Qualitätsgutachten

� Analyse und Priorisierung von technischen Schulden

� Beratung zu Architekturverbesserung und Refactorings

� Einführung und Weiterentwicklung von Architekturstile

Unsere Dienstleistungen


70%

20%

10%

Code verstehen

Problem lösen

Code schreiben

Womit verbringen wir unsere Zeit?


Komplexe Strukturen verstehen = Zeitgewinn!

Kognitive Mechanismen

Bildung von Hierarchien

ChunkingAufbau von Schemata







Einfache, einheitliche Architektur

Modularität


Modularität

�Hohe Kohäsion und lose Kopplung

�Responsibility Driven Design

�Separation of Concerns

�Single Responsibility Principle







Modularität


Hierarchien

� �






HierarchisierungModularität






HierarchisierungModularität Musterkonsistenz


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

che

Sch

ich

tun

gFachliches

Modul CFachliches

Modul C


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


Fachliche Schichtung misslungen

Technische Schichtung Keine fachliche Schichtung

Wenige Schichten-

verletzungen

Fast alle 90 fachlichen

Komponenten brauchen sich gegenseitig


Hierarchien auf Klassenebene

Auswirkung auf:

� Wartbarkeit

� Austauschbarkeit

� Testbarkeit

� Modularität

� Musterkonsistenz

� Hierarchien auf allen Ebenen einführen


Einfache Zyklengruppe


Schwierige Zyklengruppe


119 Klassen aus 4 Komponenten+ 28 weitere Klassen


Große Zyklen sichtbar machen

327 Klassen aus 8 Komponentenbrauchen sich gegenseitig









Uneven Modules

9 Komponenten = 17 Subsysteme


Uneven Modules

Ein großer Monolith mit vielen kleinen Satelliten

950.860 LOC

84.808 LOC

Häufige Ursache: Build-System, das Zyklen verbietet


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“


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









Muster auf Architekturebene: Vier Module

Modul

Grün

Modul

LilaModul

Orange

Modul

Blau


Musterkonsistenz: Was finden wir?

� Ist die Abbildung der Architektur in der Struktur des Codes zu erkennen?


Muster sinnvoll eingesetzt


Muster auf Klassenebene: 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

ust

er


Gute umgesetzte Mustersprache

☺ 90% des Sourcecodes lässt sich den Mustern zuordnen

☺ 0,1% Verletzungen in den Mustern

��

��


Entdeckung einer Mustersprache

☺ 80% des Sourcecodes lässt sich den 23 Mustern zuordnen

☺ 4% Verletzungen in den Mustern







� Einheitliche und durchgängige Muster

� Zyklenfreiheit auf allen Ebenen

� Zuständigkeit� Kopplung� Größenverhältnisse� Schnittstellen


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


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• Seerene


Vorgehen bei der Architekturanalyse und Verbesserung


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

Vielen Dank für Ihre Aufmerksamkeit!

www.langlebige-softwarearchitektur.de

Dr. Carola LilienthalMitglied der

Geschäftsleitung

[email protected]

www.wps.de

+49 170 184 77 11

Diplom-Informatikerin

@cairolali