Di 5.2. Kontrolle über Architekturerosion und Codequalität bei 40 Mio Java LOC. Harald Doderer Thomas Schoen

Transkript

1 Di 5.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Kontrolle über Architekturerosion und Codequalität bei 40 Mio Java LOC Harald Doderer Thomas Schoen

2 Kontrolle über Architekturerosion und Codequalität bei 40 Mio LOC Harald Doderer / Thomas Schoen, AEW6TA / hello2morrow GmbH OOP 2009 Ziel dieses Vortrags Automatisch voranschreitende Softwarearchitekturerosion führt zu einer schlechteren Codequalität und zu Mehrkosten bei Wartung und Erweiterungen Im Vortrag wird dieses Problem erläutert Es wird gezeigt, mit welchen technischen Verfahren und Prozessen in der FIDUCIA IT AG gegengesteuert wird Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 2 1

3 Agenda Die FIDUCIA IT AG Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 3 Agenda Die FIDUCIA IT AG Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 4 2

4 Die FIDUCIA IT AG ist führender IT-Dienstleister für Banken in Deutschland Unternehmensprofil Die FIDUCIA IT AG gehört den Volksbanken k und Raiffeisenbanken ist größter IT-Partner im genossenschaftlichen Bankensektor verfügt über mehr als 45 Jahre Erfahrung im IT-Bereich von Banken beschäftigt Mitarbeiter hat ihre Zentrale in Karlsruhe und eine e Niederlassung in München erwirtschaftete 2007 einen Umsatz von 648 Millionen Euro Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 5 Die FIDUCIA IT AG zählt zu den größten IT-Dienstleistern in Deutschland Die TOP 10 IT-Dienstleister Deutschlands Marktanteile vom Umsatz in Deutschland [%] 15,0 7,2 6,4 3,6 32 3,2 2,7 2,6 2,4 1,7 1,4 T-Systems Siemens IT Solutions & Services IBM HP Siemens Comm. Accenture SAP EDS Capgemini Quelle: Gartner 2007 Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 6 3

5 Die FIDUCIA IT AG unterstützt die Wertschöpfung der Banken durch marktgerechte und sichere IT-Lösungen Bankspezifisches Leistungsspektrum IT-Outsourcing für 821 Volksbanken und Raiffeisenbanken, Privatbanken sowie Zentralinstitute Entwicklung und Vertrieb von agree eines der in Deutschland führenden Banksysteme Rechenzentrumsbetrieb unter Einsatz moderner Großrechner-Technologie, Host, Open-System- und Unix-Technologie, Netz Security-Lösungen für höchste Daten- und IT-Sicherheit Training, Beratung, Support des hochintegrierten Banksystems agree Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 7 Die FIDUCIA IT AG betreut mehr als Arbeitsplätze bei ihren Kunden Endgeräte bei Kunden Bankstellen ca PC-Arbeitsplätze Ab t in den Banken Server 7 x 24 Stunden im Online-Betrieb SB-Geräte, davon Geldautomaten Kontoauszugsdrucker SB-Terminals Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 8 4

6 Agenda Die FIDUCIA IT AG Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 9 Innere (technische, strukturelle) Softwarequalität Wie gut ist die Software gebaut? zur Sicherstellung von Verstehbarkeit Änderbarkeit Erweiterbarkeit Wiederverwendbarkeit Testbarkeit Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 10 5

7 Innere (technische, strukturelle) Softwarequalität Wie gut ist die Software gebaut? Die Antwort steht im Sourcecode! Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 11 Softwarearchitektur Stimmt der Architekturentwurf (Soll-Architektur) mit den Strukturen der implementierten Software (IST-Architektur) überein? Symptome Hoher Kopplungsgrad Viele Zyklen Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 12 6

8 Architektur-Erosion Phänomen Architektur-Erosion Die IST-Struktur/Architektur des Projektcodes stimmt immer weniger mit der geplanten Architektur (SOLL-Architektur) überein Softwaresysteme erodieren zunehmend über die Projektlebensdauer: Ein automatischer Prozess Mögliche Ursachen für Architektur-Erosion Mangelhafte Kommunikation im Projekt Termindruck führt zu Abkürzungen Unterschiedlicher Erfahrungs/Wissenshintergrund im Team Stellenwert von innerer Softwarequalität Architekturverletzungen bleiben unbemerkt Manuelle Prüfung unmöglich Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 13 Architektur-Erosion Wieso ist das ein Problem? Technisch: Die Wartungsarbeiten des Systems werden zunehmend aufwändiger Verstehbarkeit Testbarkeit Seiteneffekte bei Änderungen/Erweiterungen Ökonomisch Die Wartungskosten steigen mit zunehmender Lebensdauer an Ein Hauptgrund für überzogene Projekt- und Wartungsbudgets Forderung nach Redesign bis hin zur Neuimplementierung Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 14 7

9 Softwarearchitektur-Management Definition SOLL-Architektur Analyse IST-Architektur Abgleich von SOLL / IST- Architektur Anpassung / Erweiterung Architekturentwurf Planung der Code-Restrukturierung Regelmäßig: Architekturmonitoring Werkzeugunterstützung Software-Tomographen Sotoarc + Sotograph Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 15 Agenda Die FIDUCIA IT AG Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 16 8

10 Aufbau des Software-Tomographen Sotoarc Java Parser C# Parser C/C++ Parser Fremdsprachen Backend Soto Repository Sotograph Sotoweb CodeChecker Plugin Interface Sotoreport Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 17 Software-Tomograph für sehr große Systeme Sotoarc Sehr große Datenmenge Java Parser C# Parser C/C++ Parser Fremdsprachen Backend Soto Repository Sotograph Sotoweb Soto-Repository Integrierte Datenbank Batch-Interface Automatisches Laden des aktuellen Versionsstands Unterstützung eines Trendmodus Vergleich zwischen Versionsständen Filter- und Fokusmechanismen CodeChecker Plugin Interface Sotoreport Verdichtung der Daten durch geeignete Abstraktion Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 18 9

11 Daten im Soto-Repository Alle im Code definierten Objekte und deren Abhängigkeiten untereinander Benutzungsbeziehungen im Code: Vererbung Methodenaufrufe Lesende/schreibende Zugriffe auf Class-Members Typverwendung bei der Definition von Attributen andere Benutzung von Typen/Klassen Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 19 Aggregation auf höhere Abstraktionsebnen: Analyse auf Symbolebene Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 20 Beispielprojekt: LOC ca Symbole Mio Referenzen 10

12 Aggregation auf höhere Abstraktionsebnen: Analyse auf Klassenebene Beispielprojekt: LOC ca Klassen Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 21 Aggregation auf höhere Abstraktionsebnen: Analyse auf Paketebene Beispielprojekt: LOC ca Packages Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 22 11

13 Aggregation auf höhere Abstraktionsebenen: Analyse auf Subsystemebene Beispielprojekt: LOC Subsysteme Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 23 Aggregation auf höhere Abstraktionsebenen: Subsystemschnittstellen Beispielprojekt: LOC Subsysteme Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 24 12

14 Definition einer Softwarearchitektur Beispiel: Schichtenarchitektur Strikte Schichtung durchbrochen (optional) Fachebene 2 Fachebene 1 Allgemeine Funktionen Aufwärtsreferenz zwischen vertikalen Schnitten Oberfläche Verletzung von Schnittstellen Schnittstelle Fachlogik Aufwärtsreferenz Datenhaltung Illegale Benutzungsbeziehungen: Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 25 Verfolgung illegaler Beziehungen Zoomen bis in den Code Referenzen zwischen Schichten ht zwischen Subsystemen zwischen Packages zwischen Klassen/Dateien Aufwärts-Referenzen Bis zum Sprung an die entsprechende Quellcode- Stelle Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 26 13

15 Software-Tomograph Sotoarc Screenshot Wie funktioniert der Software-Tomograph im praktischen Einsatz? Kontrolle über Architekturerosion Thomas Schoen, hello2morrow GmbH OOP 2009 Seite 27 Agenda Die FIDUCIA IT AG Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 28 14

16 Ein großes Softwaresystem wird leicht unübersichtlich Mengengerüst der JAVA-Anwendungen JAVA-basiertes Banking Framework (JBF) Brutto Lines of Code JAVA-Befehle 700 Pakete Klassen 280 Fachliche Komponenten Brutto Lines of Code JAVA-Befehle Pakete Klassen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 29 Statische Code-Analyse erleichtert die Entwicklung und Wartung eines Softwaresystems Unterstützung durch Sotograph Frühzeitiges Entdecken von Mängeln Architektur Design Implementierung Verständnis eines Softwaresystems Graphische Darstellung Architekturmodell Planung und Durchführung von Re-Engineering Abhängigkeiten von Komponenten erkennen Zyklen erkennen und beseitigen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 30 15

17 Zur Verbesserung der Softwarequalität wurden Qualitätsmerkmale festgelegt Kategorien Architekturqualität Subsystemzyklen Schnittstellenverletzungen Feinentwurfsqualität Paketzyklen Klassenzyklen Implementationsqualität Verletzungen der Syntax Java-Konventionen Unnötige Programmteile Fehlende Programmteile Code-Verbesserungen Potentielle Probleme Vermeidung von Problemen beim Bauen der Gesamtanwendung Vermeidung von Problemen in der Wartung Vermeidung von Wartungs- und Performance-Problemen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 31 Auf Sotoweb-Report basierende Benchmarks wurden festgelegt Benchmarks Architekturqualität 98% Feinentwurfsqualität (Fehler) 95% Implementationsqualität (Fehler) 90% Feinentwurfsqualität (Warnung) 96% Implementationsqualität (Warnung) 97% Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 32 16

18 Der Ablauf der automatischen Code-Analyse wurde festgelegt Prozesskette Build-Prozess Vorbereitung der Code-Analyse Code-Analyse durch Sotograph Zugriff auf die Ergebnisse Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 33 Agenda Die FIDUCIA IT AG Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 34 17

19 Sotograph wird auf einem zentralen LINUX-Rechner für die Berechnungen eingesetzt Technische Daten Hardware 4 Intel Xeon CPU 3.20GHz 8 GB Hauptspeicher 700 GB Festplattenbereich Software Betriebssystem SUSE-Linux-Enterprise-Server x Sotoplatform bit Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 35 Der LINUX-Rechner wird für verschiedene Aufgabenstellungen genutzt Funktionen Sotograph-Auswertung Erstellt Sotograph-Datenbanken und Reports Sotograph-Lizenzserver Prüft beim Start von Sotograph die Lizenz Sotograph-Datenbank-Server Stellt die von Sotograph erstellten Datenbanken bereit File-Server Stellt die Sourcen der Komponenten bereit Stellt die Sotograph-Software bereit Stellt die SotoWeb-Reports bereit Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 36 18

20 Sotograph ist in die Entwicklungsumgebung integriert Zusammenspiel Auswertung starten Ergebnisse anzeigen Software installieren Berechnung Datenbanken Datenbanken Source-Archive Übersichtsreports Software + Modelle Lizenzen Build-Portal Sotograph-Rechner h Browser Sotograph Lokaler Rechner Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 37 Die Einbindung über eine Web-Applikation erleichtert die Handhabung Funktionalitäten Sotograph-Berechnungen anstoßen Einzelauswertung für Entwickler Monatliche Gesamtauswertung aller Komponenten Monatliche Einzelauswertung von Komponenten Release-Auswertung Review-Ergebnisse anzeigen Informationen anzeigen Sotograph-Software Software für lokale Installation bereitstellen Forum bereitstellen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 38 19

21 Die Einbindung über eine Web-Applikation erleichtert die Handhabung Einzelauswertung Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 39 Die Einbindung über eine Web-Applikation erleichtert die Handhabung Monatsauswertung Auswertungsart Komponente, Version, Datum Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 40 20

22 Die Einbindung über eine Web-Applikation erleichtert die Handhabung Batch-Auswertung Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 41 Die Einbindung über eine Web-Applikation erleichtert die Handhabung Ergebnisanzeige Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 42 21

23 Die Einbindung über eine Web-Applikation erleichtert die Handhabung Sotoweb-Report Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 43 Die Einbindung über eine Web-Applikation erleichtert die Handhabung Übersichten Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 44 22

24 Die Einbindung über eine Web-Applikation erleichtert die Handhabung Sotograph-Installation Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 45 Die Einbindung über eine Web-Applikation erleichtert die Handhabung Sotograph-Forum Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 46 23

25 Sotograph und Sotoarc werden lokal zur Analyse der zentralen Ergebnisse genutzt Szenarien Sotograph lokal Analyse der zentralen Ergebnisse Erstellung projektspezifischer Auswertungen Sotoarc lokal Beratung zu Zyklen und Re-Engineering Analyse der Architektur Entwicklung von Modellen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 47 Agenda Die FIDUCIA IT AG Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 48 24

26 Die Ergebnisse sind in einen Regelkreislauf eingebunden Regelkreislauf Automatische ti Code-Analyse Umsetzung Beratung Planung Entwickler Consultant Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 49 Mehr als 280 Komponenten werden monatlich gerechnet Größenverteilung der Komponenten winzig klein mittel groß riesig Komponenten Klassen Relevante Code-Zeilen winzig klein mittel groß riesig > > Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 50 25

27 Mit der Größe der Komponenten nehmen auch die Mängel zu Qualität im Vergleich zur Größe 100% 80% 60% 40% ok Mängel Review 20% 0% winzig klein mittel groß riesig Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 51 Aus den Ergebnissen werden Maßnahmen zur Verbesserung der Qualität abgeleitet Maßnahmen Tiefen-Reviews Intensive Analyse der Komponente mit Qualitätsbericht Workshop mit Entwickler(n) Schreiben an Komponenten-Verantwortliche mit Hinweis auf die Auswertung Seminare für Entwickler und Komponentenverantwortliche Vereinbarung von Qualitätszielen Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 52 26

28 Zusammenfassung Software-Architektur unterliegt im Lauf der Zeit einem natürlichen Zerfall Es gibt Tools zum Auffinden von Schwachstellen in der Software Definieren von Regeln und Maßnahmen sind Voraussetzung für eine erfolgreiche Kontrolle der Qualität der Architektur Automatisierte Codeanalyse, Architekturprüfung und Architekturmanagement stellen die innere Codequalität sicher Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 53 Fragen? Diskussion? Harald Doderer Anwendungsentwicklung Technische Architektur Thomas Schoen hello2morrow GmbH Thomas.Schoen@hello2morrow.com Kontrolle über Architekturerosion Harald Doderer, AEW6TA OOP 2009 Seite 54 27