Keine technischen Schulden mehr!

Transkript

1 News- Client Produkte- Client Frontend... Frontend Produkte News Topthemen Produkte Bestellungen Abo-Daten tägl. Kunden Bestellungen Produkte Browser tägl. http Such-Ergebnisse Login, Abo-Daten idesk - Browser Beiträge Normen Frontend Normen- DB-Client Entscheidungen Tools Autoren- DB-Client Frontend Produktionsstrecke XML- RPC XML- RPC Content HPE XMetaL Keine technischen Schulden mehr! Dr. Carola Lilienthal [email protected] //// Hans-Henny-Jahnn-Weg 29 //// HAMBURG Expertise der WPS Rund um Architekturanalyse Architektur-Review und Qualitätsgutachten Architektur- und Refactoring-Beratung Architekturstile - Einführung und Entwicklung Rund um EAM Analyse der IST/SOLL-Geschäftsprozesse mit Fachanwendern Darstellung von kompletten Software/ Hardware-Landschaften Strategische EA-Entwicklung Portalbereich SAP Shop Community Portal SAP Portale System ebiz - Portal idesk - Service HRS Produktionsbereich HPE //// Seite 2 1

2 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 //// Seite 3 Technischen Schulden = Architektur-Erosion Grad der Wartbarkeit Regelmäßige Architektur-Erneuerung Korridor für gute Architekturqualität Architektur- Erosion Refactorings Neue Funktionalität pro Zeiteinheit //// Seite 4 2

3 Technischen Schulden = Architektur-Erosion Grad der Wartbarkeit Regelmäßige Architektur-Erneuerung Korridor für gute Architekturqualität Architektur- Erosion Refactorings Neue Funktionalität pro Zeiteinheit Ursachen dieses Erosions-Prozesses: 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 Architektur-Diskussionen + Architektur-Erneuerung Fehlendes Architekturverständnis im Entwicklungsteam //// Seite 5 Maßnahmen gegen Architektur-Erosion Festlegen von verbindlichen Architekturzielen Durchgängige Architekturprinzipien und Architekturstile Weiterbildung der Architekturen und Entwickler Etablieren einer Architekturgruppe Regelmäßige Architekturanalyse und -Erneuerung //// Seite 6 3

4 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 //// Seite 7 Erfahrungshintergrund Architekturanalysen in Java, C#, C++, ABAP etc. Erkenntnisse Typische Eigenschaften je nach Größe Strukturelle Einfachheit und Einheitlichkeit Ohne regelmäßige Architektur-Erneuerung degenerieren Systeme Analysewerkzeuge SotoArc + Sotograph SonarJ Sonargraph Lattix //// Seite 8 4

5 Strukturelle Einfachheit der Architektur Einfach, einheitliche Architektur Modularität Geordnetheit Mustertreue //// Seite 9 Strukturelle Einfachheit der Architektur Einfach, einheitliche Architektur Modularität Geordnetheit Mustertreue //// Seite 10 5

6 Mustertreue: Was finden wir? Ist die Abbildung der Architektur in der Struktur des Codes zu erkennen? //// 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 Window View Model C ontr t o l Service e BusinessObject ect ValueObject //// Seite 12 6

7 Zwei Dimensionen einer Architektur Technische Schichtung Fachliche Schichtung Eine Komponente verursacht die Probleme Schwer zu behebende Verletzungen Leicht zu behebende Verletzungen Eine Komponente verursacht die Probleme //// Seite 13 Fachliche Schichtung misslungen Technische Schichtung Fast alle 90 fachlichen Komponenten brauchen sich gegenseitig Keine fachliche Schichtung Wenige Schichtenverletzungen //// Seite 14 7

8 Mustersprache 80% des Sourcecodes lässt sich den 23 Mustern zuordnen 4% Verletzungen in den Mustern //// Seite 15 Strukturelle Einfachheit der Architektur Architekturkomplexität Modularität Geordnetheit Mustertreue //// Seite 16 8

9 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. 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 //// Seite 17 Modularität: Ausgewogene Größenverhältnisse Ist das System auf den verschiedenen Ebenen ausgewogen? Welche Code-Abschnitte fallen durch ihre Größe besonders auf? Typische Metriken: LOC pro Methode, Klasse, Package, Komponenten Duplizierter Code Zyklomatische Komplexität Anti-Pattern Godclass //// Seite 18 9

10 Kopplungsgrad Ist das System auf den verschiedenen Ebenen lose gekoppelt? Welche Code-Abschnitte fallen durch besonders viele Beziehungen auf? Ziel: Lose Kopplung //// Seite 19 Beispiel: Größenverhältnis und Kopplungsgrad Große Steuerungsklassen benutzen bis zu andere Klassen RLOC/Klasse RLOC Beziehungen/Klasse RLOC Ausgewogene Größenverhältnisse auf allen Ebenen führen zu geringerer Kopplung und besserem objektorientiertem Entwurfs //// Seite 20 10

11 Strukturelle Einfachheit der Architektur Architekturkomplexität Modularität Geordnetheit Mustertreue //// 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 //// Seite 22 11

12 Schichtenarchitektur fast ohne Verletzungen WebServices 1 Ca LOCs Services 1 Tools 1 Client Services 2 Tools 2 Tools 3 Tools 4 Die Schichten spiegeln den Aufbau einer Client-Server- Architektur wieder: Anwendungen, Client, Server und Basis. WebServices //// 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 //// Seite 24 12

13 Große Zyklen sichtbar machen 327 Klassen aus 8 Komponenten brauchen sich gegenseitig //// Seite 25 Der Zwang zur Zyklenfreiheit 80% des Sourcecodes 9 Komponenten = 17 Subsysteme //// Seite 26 13

14 Grundregeln struktureller Einfachheit für Architektur Architekturkomplexität Modularität Geordnetheit Mustertreue Zuständigkeit Kopplung Größenverhältnisse Schnittstellen Zyklenfreiheit auf allen Ebenen Architekturstil(e) Einheitlich und durchgängige //// 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 DB-Systeme Structure101: Java, C++, Ada SotoArc und Sonargraph: Java,.Net, C/C++, ABAP //// Seite 28 14

15 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 Java-Projekten via maven Reports bezüglich Komplexität und Architekturverletzungen //// Seite 29 Restrukturierung von großen Systemen Erfahrung mit Analyse-Werkzeugen Umfassender Einblick und Überblick über die vorhandene Architektur Graphische Dokumentation mit Architekturdiagrammen Diskussionsgrundlage für und Simulation von Architektur-Restrukturierung Überprüfen der Effekte von Restrukturierungen auf die Architektur Refactoring-Anleitung für die erarbeitete Restrukturierungen //// Seite 30 15

16 Schrittweise Weiterentwicklung der Architektur 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 2x2-Tage Workshop Anpassungen an neue Architektur -Guidlines 1-Tages Work- shop Repara- a- turen ½-Tages Workshop Phase 1: Aufräumen Phase 2: Verbessern Phase 3: Erhalten //// Seite 31 Leitstand für Verbesserungen im laufenden Betrieb 94% 84% 74% 64% 54% 44% 34% Tatsächliches 24% Problem? 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 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 //// Seite 32 16

17 Vielen Dank für Ihre Aufmerksamkeit. Diplom-Informatikerin Dr. Carola Lilienthal Mitglied der Geschäftsleitung cl //// Seite 33 17