15.10.14

Keine technischen Schulden mehr! Dr. Carola Lilienthal [email protected] www.wps.de WPS  Workplace Solutions GmbH //// HansHennyJahnnWeg 29 //// 22085 HAMBURG

Expertise der WPS

Rund um Architekturanalyse   ArchitekturReview und Qualitätsgutachten   Architektur und RefactoringBeratung   Architekturstile  Einführung und Entwicklung

Rund um EAM

eBiz - Portal

Portalbereich

Browser

iDesk - Browser

http

  Analyse der IST/SOLLGeschäfts prozesse mit Fachanwendern   Darstellung von kompletten Software/ HardwareLandschaften   Strategische EAEntwicklung WPS  Workplace Solutions GmbH

Shop

Community

iDesk - Service

Portal Such-Ergebnisse

Content

Frontend

Produktionsstrecke

NewsClient Produkte

Topthemen

...

Portale – System

Frontend

ProdukteClient

News

Login, Abo-Daten

HPE XMLRPC Beiträge

Produkte

Bestellungen

Entscheidungen

Normen

tägl.

HRS

Tools

tägl.

SAP Bestellungen

XMLRPC XMetaL

Frontend

NormenN Normen ormenDB Client DB-Client Kunden

SAP

HPE

Abo-Daten

Frontend

AutorenDB-Client

Produkte

Produktionsbereich

15.10.14 //// Seite 2

1

15.10.14

Zwei übliche Architekturziele

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 WPS  Workplace Solutions GmbH

15.10.14 //// Seite 3

Technischen Schulden = ArchitekturErosion

Regelmäßige ArchitekturErneuerung Grad der Wartbarkeit Korridor für gute Architekturqualität

Architektur Erosion

Refactorings Neue Funktionalität pro Zeiteinheit

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 4

2

15.10.14

Technischen Schulden = ArchitekturErosion Regelmäßige ArchitekturErneuerung Grad der Wartbarkeit Korridor für gute Architekturqualität

Architektur Erosion

Refactorings Neue Funktionalität pro Zeiteinheit

Ursachen dieses ErosionsProzesses: •  Unbemerkt steigender Kopplungsgrad und Komplexität •  • 

Hacks aus Zeitdruck durch Kunde und Projektleitung Entwicklung eines zweiten/dritten Produkts auf Basis eines Ersten

• 

Keine Zeit für ArchitekturDiskussionen + ArchitekturErneuerung

• 

Fehlendes Architekturverständnis im Entwicklungsteam

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 5

Maßnahmen gegen ArchitekturErosion

         

Festlegen von verbindlichen Architekturzielen Durchgängige Architekturprinzipien und Architekturstile Weiterbildung der Architekturen und Entwickler Etablieren einer Architekturgruppe Regelmäßige Architekturanalyse und Erneuerung

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 6

3

15.10.14

Architekturanalyse: Was ist das?

Findet sich die geplante Architektur (SollArchitektur) in der Strukturen der implementierten Software (IstArchitektur) wieder?

IstArchitektur

SollArchitektur

≠ 

Quelltext

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 7

Erfahrungshintergrund

Architekturanalysen in Java, C#, C++, ABAP etc.

Erkenntnisse

Analysewerkzeuge

  Typische Eigenschaften je nach Größe   Strukturelle Einfachheit und Einheitlichkeit   Ohne regelmäßige ArchitekturErneuerung degenerieren Systeme

  SotoArc + Sotograph   SonarJ  Sonargraph   Lattix

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 8

4

15.10.14

Strukturelle Einfachheit der Architektur

Einfach, einheitliche Architektur

Modularität

Geordnetheit

WPS  Workplace Solutions GmbH

Mustertreue

15.10.14 //// Seite 9

Strukturelle Einfachheit der Architektur

Einfach, einheitliche Architektur

Modularität

WPS  Workplace Solutions GmbH

Geordnetheit

Mustertreue

15.10.14 //// Seite 10

5

15.10.14

Mustertreue: Was finden wir?

  Ist die Abbildung der Architektur in der Struktur des Codes zu erkennen? WPS  Workplace Solutions GmbH

15.10.14 //// Seite 11

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

View

Window

Model

C o n ttr o l

Service Servi S e BusinessObject B us nessOb ecct ValueObject Va ueObject

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 12

6

15.10.14

Zwei Dimensionen einer Architektur Technische Schichtung

Fachliche Schichtung

Eine Komponente verursacht die Probleme

Schwer zu behebende Verletzungen

Eine Komponente verursacht die Probleme Leicht zu behebende Verletzungen WPS  Workplace Workplac Work place plac e Sol Solutio Solutions utions utio ns GmbH GmbH mb bH b H

15.10.14 ///// Seite 13

Fachliche Schichtung misslungen Technische Schichtung

Fast alle 90 fachlichen Komponenten brauchen sich gegenseitig

Keine fachliche Schichtung

Wenige Schichten verletzungen

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 14

7

15.10.14

Mustersprache

☺  80% des Sourcecodes lässt sich den 23 Mustern zuordnen ☺  4% Verletzungen in den Mustern WPS  Workplace Solutions GmbH

15.10.14 //// Seite 15

Strukturelle Einfachheit der Architektur

Architekturkomplexität

Modularität

WPS  Workplace Solutions GmbH

Geordnetheit

Mustertreue

15.10.14 //// Seite 16

8

15.10.14

Modularität: Entwurf nach Zuständigkeiten   Entwurf nach Zuständigkeiten (engl.: ResponsibilityDriven Design) ist eine Entwurfsphilosophie, die von Rebecca WirfsBrock 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.“  

Dazu passende Ansätze:  

Separation of Concerns (Dijkstra)

 

Modularität (Parnas)

 

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. WPS  Workplace Solutions GmbH

15.10.14 //// Seite 17

Modularität: Ausgewogene Größenverhältnisse   Ist das System auf den verschiedenen Ebenen ausgewogen?   Welche CodeAbschnitte fallen durch ihre Größe besonders auf?

Typische Metriken:      

LOC pro Methode, Klasse, Package, Komponenten Duplizierter Code Zyklomatische Komplexität

WPS  Workplace Solutions GmbH

Anti-Pattern „Godclass“ 15.10.14 //// Seite 18

9

15.10.14

Kopplungsgrad   Ist das System auf den verschiedenen Ebenen lose gekoppelt?   Welche CodeAbschnitte fallen durch besonders viele Beziehungen auf?

Ziel: Lose Kopplung WPS  Workplace Solutions GmbH

15.10.14 //// Seite 19

Beispiel: Größenverhältnis und Kopplungsgrad   Große Steuerungsklassen benutzen bis zu 100 – 500 andere Klassen 300

30

250

25

Beziehungen/Klasse

RLOC/Klasse

200

150 100 50

20 15 10 5

0 0

200.000

400.000

600.000

800.000

RLOC

1.000.000

1.200.000

1.400.000

0 0

200.000

400.000

600.000 800.000 RLOC

1.000.000 1.200.000 1.400.000

 Ausgewogene Größenverhältnisse auf allen Ebenen führen zu geringerer Kopplung und besserem objektorientiertem Entwurfs WPS  Workplace Solutions GmbH

15.10.14 //// Seite 20

10

15.10.14

Strukturelle Einfachheit der Architektur

Architekturkomplexität

Modularität

Geordnetheit

WPS  Workplace Solutions GmbH

Mustertreue

15.10.14 //// Seite 21

Zyklenfreiheit – Hierarchische Strukturen Acyclic Dependencies Principle (ADP)

Auswirkung auf:   Wartbarkeit   Austauschbarkeit    

Testbarkeit Einstiegspunkt beim Analysieren

 Zyklen zwischen Klassen, Paketen, Komponenten und Schichten vermeiden WPS  Workplace Solutions GmbH

15.10.14 //// Seite 22

11

15.10.14

Schichtenarchitektur fast ohne Verletzungen

WebServices 1

 

Ca. 200.000 LOCs

 

Die Schichten spiegeln den Aufbau einer ClientServer Architektur wieder: Anwendungen, Client, Server und Basis.

Services 1 Tools 1 Client

Services 2

Tools 2

Tools 3

Tools 4

WebServices 2

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 23

Chaos auf Klassenebene    

30% der Klassen sind in Klassenzyklen 60% der Packages sind in Zyklen

Problem B

Problem A

BadSmell: God Class      

98% der Klassen haben zu weniger als 10 Klassen Beziehungen „Problem A“ kennt 21 Klassen und wird von 49 benutzt „Problem B“ kennt 63 Klassen und wird von 18 Klassen benutzt

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 24

12

15.10.14

Große Zyklen sichtbar machen

327 Klassen aus 8 Komponenten brauchen sich gegenseitig WPS  Workplace Solutions GmbH

15.10.14 //// Seite 25

Der Zwang zur Zyklenfreiheit

80% des Sourcecodes

9 Komponenten = 17 Subsysteme WPS  Workplace Solutions GmbH

15.10.14 //// Seite 26

13

15.10.14

Grundregeln struktureller Einfachheit für Architektur

Architekturkomplexität

Modularität

       

Zuständigkeit Kopplung Größenverhältnisse Schnittstellen

Geordnetheit

 

Zyklenfreiheit auf allen Ebenen

Mustertreue

   

Architekturstil(e) Einheitlich und durchgängige

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 27

Kommerzielle Produkte   Axivion Bauhaus: Java, .Net, C/C++, Ada, VB und Cobol   CAST: 28 Programmiersprachen (u.a. Java, .Net, Cobol/CICS)   Lattix: Java, .Net, C/C++, Ada, Delphi und DBSysteme   Structure101: Java, C++, Ada   SotoArc und Sonargraph: Java, .Net, C/C++, ABAP

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 28

14

15.10.14

Kostenfreie Werkzeuge •  Sonar: •  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 JavaProjekten via maven •  Reports bezüglich Komplexität und Architekturverletzungen WPS  Workplace Solutions GmbH

15.10.14 //// Seite 29

Restrukturierung von großen Systemen

Erfahrung mit AnalyseWerkzeugen   Umfassender Einblick und Überblick über die vorhandene Architektur   Graphische Dokumentation mit Architekturdiagrammen   Diskussionsgrundlage für und Simulation von ArchitekturRestrukturierung   Überprüfen der Effekte von Restrukturierungen auf die Architektur   RefactoringAnleitung für die erarbeitete Restrukturierungen WPS  Workplace Solutions GmbH

15.10.14 //// Seite 30

15

15.10.14

Schrittweise Weiterentwicklung der Architektur

2Tage p Workshop

Phase 3 Im Architekturkorridor bleiben und Architektur verbessern

Phase 2 Architektur diskutieren und verbessern

Phase 1 Soll/IstArchitektur vergleichen

Verletzungen beheben

2x2Tage e Work shop

Anpassungen an ur neue Architektur Guidlines

1Tages es k Work shop

½Tages Work shop

Repara a turen

  Phase 1: Aufräumen   Phase 2: Verbessern   Phase 3: Erhalten

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 31

Leitstand für Verbesserungen im laufenden Betrieb 94% 84% 74% Architekturqualität 64%

Feinentwurfsqualität

54%

Implementierungsqualität

44%

Testabdeckung

Tatsächliches 24% Problem? ev1.0 m v1.1_b1 34%

v1.1_b2

v1.1_b3

v1.1

v1.2_b1

v1.2

v2.0_b1

v2.0_b2

v2.0

Ergebnis   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. WPS  Workplace Solutions GmbH

15.10.14 //// Seite 32

16

15.10.14

Vielen Dank für Ihre Aufmerksamkeit.

Diplom-Informatikerin Dr. Carola Lilienthal Mitglied der Geschäftsleitung

+49 170 184 77 11 cl

WPS  Workplace Solutions GmbH

15.10.14 //// Seite 33

17