Langlebige Softwarearchitekturen - Der Umgang mit technischen Schulden

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

Dr. Carola Lilienthal

[email protected]

www.wps.de

Langlebige Softwarearchitekturen

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

Architekturziele für Langlebige Softwarearchitekturen

Architekturziel 1: Wartbarkeit

• Analysierbarkeit und Verständlichkeit

• schnelle Fehleranalyse

• schnelle Changes

• Reduktion von Komplexität

Architekturziel 2: Fachliche Flexibilität

• Geschäftsprozesse verschiedener Kunden unterstützen

• Anpassbarkeit an geänderte Anforderungen

• Baukastenprinzip


Technischen Schulden = Architektur-Erosion

Grad der

Wartbarkeit

Neue Funktionalität

pro Zeiteinheit

Korridor geringer

technischer Schulden

Refactorings

Regelmäßige Architektur-Erneuerung

Architektur-

Erosion

Wartung und Erweiterung


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


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

Directories

Packages

Namespaces

Subsysteme

Komponenten

Module

Schichten


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


Strukturelle Einfachheit der Architektur = Zeitgewinn!

Einfach, einheitliche

Architektur

HierarchieModularitätMuster-

konsistenz


Strukturelle Einfachheit der Architektur = Zeitgewinn!

Einfach, einheitliche

Architektur


konsistenz


User Interface

Domain

Application

Muster in Architekturen: Schichten und Module

Fachliches

Modul B

Fachliches

Modul A

Fachliche Schichtung

Te

ch

nis

ch

e S

ch

ich

tun

gFachliches

Modul C


Musterkonsistenz: Was finden wir?

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


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


Uneven Modules

80% des Sourcecodes

9 Komponenten = 17 Subsysteme


Muster in Architekturen: Entwurfsmuster und Mustersprachen

User Interface

Domain

Application

Fachliches Modul

Window

GUI

Model

ViewControl

ValueObject

Service

BusinessObject

Sc

hic

htu

ng

du

rch

Mu

ste

r


Mustersprache

80% des Sourcecodes lässt sich den Mustern zuordnen

0,1% Verletzungen in den Mustern

Eventer

ProcessesService


Mustersprache

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

4% Verletzungen in den Mustern


Grundregeln struktureller Einfachheit für Architektur

Architekturkomplexität


konsistenz

Architekturstil(e)

Einheitlich und

durchgängige

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

• Software-

Diagnostics


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 verbessern

Architekturregeln

festlegen

Phase 3: ErhaltenIm Architekturkorridor

bleiben

Langlebigkeit fördern

Initialer

Workshop

Verletzungen

beheben

Strukturen einziehen

Analyse-

Workshop

Anpassungen an

neue Architektur-

Regeln

Nach-

sorge

kleinere

Reparaturen


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ächliches

Problem?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


Langlebige Software-Architekturen

Dr. Carola Lilienthal

Mitglied der Geschäftsleitung

[email protected]

www.wps.de

+49 170 184 77 11

Diplom-Informatikerin

@cairolali


Vielen Dank für Ihre Aufmerksamkeit. Fragen?