Validierung von SW-Architekturen - Erfahrungen beim Einsatz des Sotographen Dr. Carola Lilienthal Carola.Lilienthal@workplace-solutions.

Transkript

1 Validierung von SW-Architekturen - Erfahrungen beim Einsatz des Sotographen Dr. Carola Lilienthal Carola.Lilienthal@workplace-solutions.de //// Hans-Henny-Jahnn-Weg 29 //// HAMBURG WPS Workplace Solutions Die Firma POS GbR Partner für objektorientierte Softwareentwicklung WPS Workplace Solutions GmbH C1 WPS - Workplace Solutions GmbH Mitglied der C1 Group WPS - Workplace Solutions GmbH Mitglied der CORA ,7 2,4 2,9 Umsatz 3,7 2,8 2,8 4 4,4 Gesellschafter:! CORA (Mehrheitsgesellschafter)! Prof. Dr.-Ing. Heinz Züllighoven (GF)! Dr. Guido Gryczan (GF)! Dr. Carola Lilienthal (GL)! Holger Breitling (GL)! Ute Zimmermann! C1 WPS Beteiligungs-GbR ! 2012: ~50 Mitarbeiter (VBE: > 30) //// Seite 2 1

2 Frontend News- Client... Frontend Produkte- Client 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 Frontend Autoren- DB-Client Produktionsstrecke XML- RPC XML- RPC Content HPE XMetaL 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 HPE Produktionsbereich //// Seite 3 SotoArc und Sonargraph! Kommerzielles Produkt seit 2002! Arbeitet Datenbank-gestützt! Analysiert Java, C++, C# sowie ABAP und bietet offene Schnittstelle für weitere Parser! Referenzkunden, u.a. Siemens, Lufthansa, Kühle&Nagel, Daimler, Infineon! Einbindung in den Buildprozess, Vielfältige Reports //// Seite 4 2

3 Arbeitsweise von Sotoarc und Sotographen Java Parser C/C++ Parser C# Parser Repository Fill Interface ABAP Parser Repository RDBMS Analyse Werkzeuge DupliScope CodeChecker Plugin Interface Metrik Interface Integration PMD, CheckStyle FindBugs, Code Inspector,... Entwicklungsumgebung Qualitäts-Leitstand //// Seite 5 Systemevolution der Architektur Ist-Architekturen Zeit Version 1 Version 2 Version 3 Aufwand Soll-Architektur! Integration ins Nightly Build! Auswertungen des Trends! 1h/Woche beim Architekt //// Seite 6 3

4 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 7 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 8 4

5 Erfahrungshintergrund und Werkzeuge Architekturanalysen in Java, C#, C++, ABAP Erkenntnisse! Typische Eigenschaften der Architektur bei bestimmten Größen! Strukturelle Einfachheit und Einheitlichkeit ist der Schlüssel zum Erfolg! Ohne regelmäßige Architektur-Erneuerung degenerieren Systeme //// Seite 9 Architektur-Erosion = Technical Debts Grad der Wartbarkeit Regelmäßige Architektur-Erneuerung Korridor für gute Architekturqualität Architektur- Erosion Großes Refactoring Die Folge von Erosion: Neue Funktionalität pro Zeiteinheit Sourcecode ist für die Entwickler schwerer zu verstehen Erweiterungen verursachen viele Seiteneffekte Neue Fehler werden unbemerkt eingebaut oder ausgelöst Verlängerte Entwicklungsdauer und steigende Kosten //// Seite 10 5

6 Kosten durch Architektur-Erosion Kosten für Erweiterung Erweiterungsmassnahme erodiertes System Erweiterungsmassnahme architekturkonformes System 0 Projekt-Lebensdauer 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 11 Maßnahmen gegen Architektur-Erosion! Festlegen von verbindlichen Architekturzielen! Durchgängige Architekturprinzipien und Architekturstile! Regelmäßige Architekturanalyse und -Erneuerung! Weiterbildung der Architekturen und Entwickler! Etablieren einer Architekturgruppe //// Seite 12 6

7 Architekturanalyse: Was ist das? Findet sich die geplante Architektur (Soll-Architektur) in der Strukturen der implementierten Software (Ist-Architektur) wieder? Soll-Architektur Ist-Architektur Klassen Directories Packages Subsysteme Komponenten e en Quelltext //// Seite 13 Architekturanalyse: Wie gehen wir vor? Architekturentwurf Zerlegung in Teilsysteme Planung von Abhängigkeiten und Schnittstellen Soll- Architektur Abbildungs- Vorschrift Rekonstruktion Ist- Architektur Analyse + Diskussion Source- Code Verletzungen Refactorings Priorisierung der Maßnahmen Einplanung in den Entwicklungszyklus Maßnahmen festlegen //// Seite 14 7

8 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 Workshop Reparaturen ½-Tages Workshop! Phase 1: Aufräumen! Phase 2: Verbessern! Phase 3: Erhalten //// Seite 15 Strukturelle Einfachheit der Architektur Architekturkomplexität Mustertreue arität Geordnetheit //// Seite 16 8

9 Mustertreue: Was finden wir?! Ist die Abbildung der Architektur im Code erkennbar? Komponenten im Package/Directory-Baum Schnittstellen von Komponenten (z.b. Package api vs impl ) //// Seite 17 Architekturstil: ung mit zwei Dimensionen Fachliche ung Fachliches Fachliches Fachliches Technische ung Präsentations- Applikations- Fachdomänen- Infrastruktur //// Seite 18 9

10 Schwierigkeiten der Infrastruktur- Fachliche ung Technische ung Präsentations- Applikations- Fachdomänen- Fachliches Fachliches Fachliches Infrastruktur- Logging Framework Widgets- Library Druck- Library OR-Mapper //// Seite 19 Lösung Infrastruktur- Fachliche ung Technische ung Präsentations- Applikations- Fachdomänen- Fachliches Fachliches Fachliches Infrastruktur- Widgets- Library Druck- Library OR-Mapper Logging Framework Infrastruktur //// Seite 20 10

11 Zwei Dimensionen einer Architektur Technische ung Fachliche ung Eine Komponente verursacht die Probleme Schwer zu behebende Verletzungen Eine Komponente verursacht die Probleme Leicht zu behebende Verletzungen //// Seite 21 Fachliche ung misslungen Technische ung Fast alle 90 fachlichen Komponenten braucht sich gegenseitig Keine fachliche ung Wenige enverletzungen //// Seite 22 11

12 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 enarchitektur Mustersprache GUI Window View Model C o n tr o l Service BusinessObject ValueObject //// Seite 23 Architekturstile Einführen und Entwickeln Mustersprache Horizontale enarchitektur Komponentenarchitektur mit Schnittstellen Projektanfang Horizontale enarchitektur Komponentenarchitektur mit Schnittstellen Vertikale enarchitektur Komponentenarchitektur mit Schnittstellen Horizontale enarchitektur " Ein und mit der Zeit mehrere Architekturstile für das ganze System durchgängig einführen //// Seite 24 12

13 aritä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)! arität (Parnas)! Kohäsion (Myers, Coad&Yourdon)! Single Responsibility Principle (SRP) (Robert C. Martin) "Jede Klasse, jedes Paket, jedes Subsystem, jedes, jede sollte für eine klar definierte Aufgabe zuständig sein //// Seite 25 arität: Schnittstellen Public part! Nur relevante Merkmale einer Entwurfs- und Konstruktionseinheit sollten für Klienten sichtbar und zugänglich sein (Kapselung).! Details der Implementierung sollten verborgen bleiben (Lokalität).! Schon allein das Wissen über Interna kann missbraucht werden! (Geheimnisprinzip) Program to an interface, not an implementation. Secret part Gamma et al " Schnittstellen für alle Klassen, Pakete, Komponenten, en einführen //// Seite 26 13

14 aritä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 27 Kopplungsgrad! Ist das System auf den verschiedenen Ebenen lose gekoppelt?! Welche Code-Abschnitte fallen durch besonders viele Beziehungen auf? Ziel: Lose Kopplung //// Seite 28 14

15 Beispiel: Größenverhältnis und Kopplungsgrad! Große Steuerungsklassen benutzen bis zu andere Klassen RLOC/Klasse Beziehungen/Klasse RLOC RLOC " Ausgewogene Größenverhältnisse auf allen Ebenen führen zu geringerer Kopplung und besserem objektorientiertem Entwurfs //// Seite 29 Zyklenfreiheit Hierarchische Strukturen Acyclic Dependencies Principle (ADP) Auswirkung auf:! Wartbarkeit! Austauschbarkeit! Testbarkeit! Einstiegspunkt beim Analysieren " Zyklen zwischen Klassen, Paketen, Komponenten und en vermeiden //// Seite 30 15

16 enarchitektur fast ohne Verletzungen WebServices 1 # Ca LOCs Services 1 Tools 1 Client Services 2 Tools 2 Tools 3 Tools 4 # Die en spiegeln den Aufbau einer Client- Server-Architektur wieder: Anwendungen, Client, Server und Basis. WebServices //// Seite 31 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 32 16

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

18 Grundregeln struktureller Einfachheit für Architektur Architekturkomplexität Mustertreue arität Geordnetheit " durchgängige Architekturstile " Zuständigkeit " Schnittstellen " Zyklenfreiheit //// Seite 35 Restrukturierung von großen Systemen Erfahrung mit dem Sotographen! Umfassender Einblick und Überblick über die vorhandene Architektur! Ausprobieren von Restrukturierungen mit WhatIf-Analyse! Überprüfen der Effekte von Restrukturierungen auf die Architektur! Graphische Dokumentation mit Architekturdiagrammen! Refactoring-Anleitung aller durchgeführten Schritte //// Seite 36 18

19 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 37 Vielen Dank für Ihre Aufmerksamkeit. Diplom-Informatikerin Dr. Carola Lilienthal Mitglied der Geschäftsleitung cl //// Seite 38 19