Kontrolle über Architekturerosion und Codequalität bei 40 Mio LOC Harald Doderer / Thomas Schoen, AEW6TA / hello2morrow GmbH | JBFOne 2008

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

Agenda Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Ausblick

Agenda Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Ausblick

Innere (technische, strukturelle) Softwarequalität Wie gut ist die Software gebaut? zur Sicherstellung von Verstehbarkeit Änderbarkeit Erweiterbarkeit Wiederverwendbarkeit Testbarkeit

Innere (technische, strukturelle) Softwarequalität Wie gut ist die Software gebaut? Die Antwort steht im Sourcecode!

Welche Informationen kann ein Werkzeug aus dem Code herauslesen? Duplizierte Codeblöcke Verstöße gegen Codierungsregeln Verletzung von Namenskonventionen Entartete Objekte (zu große/kleine Methoden, Klassen, Packages) Besonders komplexe Objekte (zyklomatische Komplexität) Stark gekoppelte Objekte Ungenutzte Codesegmente Verstöße gegen OO-Prinzipien (entartete Vererbung, direkter Class-Member-Zugriff) Zyklische Abhängigkeiten auf Klassen-/Package-/Architekturebene Verletzung von Komponenten-Schnittstellen Architekturverletzungen (Verstöße gegen eine vorgegebene Softwarearchitektur)

Softwarearchitektur Stimmt der Architekturentwurf (Soll-Architektur) mit den Strukturen der implementierten Software (IST-Architektur) überein? Symptome Hoher Kopplungsgrad Viele Zyklen

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 Mögliche Ursachen für Architektur-Erosion Mangelhafte Kommunikation im Projekt über die geltende Softwarearchitektur Termindruck führt zu Abkürzungen, die später nie korrigiert werden Unterschiedlicher Erfahrungs/Wissenshintergrund im Team; verschärftes Problem bei Outsourcing Für Projektleitung hat innere Softwarequalität keinen hohen Stellenwert; negative Auswirkungen werden erst mit Verzögerung deutlich Architekturverletzende Abhängigkeiten entstehen oft unbemerkt und bleiben dies auch für längere Zeit Es ist unmöglich, alle Architekturverletzungen in einem größeren Softwaresystem manuell zu erkennen.

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

Softwarearchitektur-Management Analyse IST-Architektur Planung der Code-Restrukturierung Abgleich von SOLL / IST- Architektur Anpassung / Erweiterung Architekturentwurf Definition SOLL-Architektur Regelmäßig: Architekturmonitoring Werkzeugunterstützung Software-Tomographen Sotoarc + Sotograph

Agenda Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Ausblick

Aufbau des Software-Tomographen Soto Reposi-tory CodeChecker Plugin Interface Sotoweb Sotoarc Sotograph Sotoreport Fremdsprachen Backend C/C++ Parser C# Java

Software-Tomograph für sehr große Systeme Soto Reposi-tory CodeChecker Plugin Interface Sotoweb Sotoarc Sotograph Sotoreport Fremdsprachen Backend C/C++ Parser C# Java Sehr große Datenmenge Soto-Repository Integrierte Datenbank Batch-Interface Automatisches Laden des aktuellen Versionsstands Unterstützung eines Trendmodus Vergleich zwischen Versionsständen Filter- und Fokusmechanismen Verdichtung der Daten durch geeignete Abstraktion

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

Aggregation auf höhere Abstraktionsebnen: Analyse auf Symbolebene Beispielprojekt: 500.000 LOC ca. 50.000 Symbole 100.000 – 1 Mio Referenzen

Aggregation auf höhere Abstraktionsebnen: Analyse auf Klassenebene Beispielprojekt: 500.000 LOC ca. 3.000 - 5.000 Klassen

Aggregation auf höhere Abstraktionsebnen: Analyse auf Paketebene Beispielprojekt: 500.000 LOC ca. 200 - 300 Packages

Aggregation auf höhere Abstraktionsebenen: Analyse auf Subsystemebene Beispielprojekt: 500.000 LOC 10 - 30 Subsysteme

Aggregation auf höhere Abstraktionsebenen: Subsystemschnittstellen Beispielprojekt: 500.000 LOC 10 - 30 Subsysteme

Definition einer Softwarearchitektur Beispiel: Schichtenarchitektur 11/137/198 106/172/218 223/234/246 164/197/229 197/199/200 156/157/159 77/75/74 0/66/138 (Überschrift) 242/79/18 (Akzente) 131/174/211 (Hintergrund Schaubild/Foto) 213/227/248 (Hintergrund Text/Diagramm) Füllfarben Fachebene 1 Allgemeine Funktionen Fachebene 2 Strikte Schichtung durchbrochen (optional) Ober-fläche Aufwärtsreferenz zwischen vertikalen Schnitten Verletzung von Schnittstellen Schnittstelle Fach- logik Aufwärts-referenz Daten- haltung Illegale Benutzungsbeziehungen:

Verfolgung illegaler Beziehungen Zoomen bis in den Code Referenzen zwischen Schichten zwischen Subsystemen zwischen Packages zwischen Klassen/Dateien Bis zum Sprung an die entsprechende Quellcode- Stelle Aufwärts-Referenzen

Wie funktioniert der Software-Tomograph im praktischen Einsatz?

Agenda Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Ausblick

Ein großes Softwaresystem wird leicht unübersichtlich JAVA-basiertes Banking Framework (JBF) 1.100.000 Brutto Lines of Code 450.000 JAVA-Befehle 700 Pakete 8.000 Klassen 280 Fachliche Komponenten 43.900.000 Brutto Lines of Code 15.000.000 JAVA-Befehle 9.000 Pakete 175.000 Klassen Mengengerüst der JAVA-Anwendungen

Statische Code-Analyse erleichtert die Entwicklung und Wartung eines Softwaresystems 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 Unterstützung durch Sotograph

Zur Verbesserung der Softwarequalität wurden Qualitätsmerkmale festgelegt Kategorien Architekturqualität Subsystemzyklen Schnittstellenverletzungen Vermeidung von Problemen beim „Bauen“ der Gesamtanwendung Feinentwurfsqualität Vermeidung von Problemen in der Wartung Paketzyklen Klassenzyklen Implementationsqualität Verletzungen der Syntax Java-Konventionen Unnötige Programmteile Fehlende Programmteile Code-Verbesserungen Potentielle Probleme Vermeidung von Wartungs- und Performance-Problemen

Auf Sotoweb-Report basierende Benchmarks wurden festgelegt Architekturqualität 98% Feinentwurfsqualität (Fehler) 95% Implementationsqualität (Fehler) 90% Feinentwurfsqualität (Warnung) 96% Implementationsqualität (Warnung) 97%

Der Ablauf der automatischen Code-Analyse wurde festgelegt Prozesskette Build-Prozess Vorbereitung der Code-Analyse durch Sotograph Zugriff auf die Ergebnisse

Agenda Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Ausblick

Sotograph wird auf einem zentralen LINUX-Rechner für die Berechnungen eingesetzt Hardware 4 Intel® Xeon™ CPU 3.20GHz 8 GB Hauptspeicher 700 GB Festplattenbereich Software Betriebssystem SUSE-Linux-Enterprise-Server x86-64-10 Sotoplatform 3.2.1 64bit Technische Daten

Der LINUX-Rechner wird für verschiedene Aufgabenstellungen genutzt 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 Funktionen

Sotograph ist in die Entwicklungsumgebung integriert Zusammenspiel Auswertung starten Berechnung Datenbanken Ergebnisse anzeigen Datenbanken Source-Archive Software installieren Übersichtsreports Software + Modelle Lizenzen Build-Portal Sotograph-Rechner Lokaler Rechner Browser Sotograph

Die Einbindung über eine Web-Applikation erleichtert die Handhabung 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 für lokale Installation bereitstellen Forum bereitstellen Funktionalitäten

Die Einbindung über eine Web-Applikation erleichtert die Handhabung Einzelauswertung

Die Einbindung über eine Web-Applikation erleichtert die Handhabung Auswertungsart Komponente, Version, Datum Monatsauswertung

Die Einbindung über eine Web-Applikation erleichtert die Handhabung Batch-Auswertung

Die Einbindung über eine Web-Applikation erleichtert die Handhabung Ergebnisanzeige

Die Einbindung über eine Web-Applikation erleichtert die Handhabung Sotoweb-Report

Die Einbindung über eine Web-Applikation erleichtert die Handhabung Übersichten

Die Einbindung über eine Web-Applikation erleichtert die Handhabung Sotograph-Installation

Die Einbindung über eine Web-Applikation erleichtert die Handhabung Sotograph-Forum

Sotograph und Sotoarc® werden lokal zur Analyse der zentralen Ergebnisse genutzt Sotograph lokal Analyse der zentralen Ergebnisse Erstellung projektspezifischer Auswertungen Sotoarc® lokal Beratung zu Zyklen und Re-Engineering Analyse der Architektur Entwicklung von Modellen Szenarien

Agenda Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Ausblick

Die Ergebnisse sind in einen Regelkreislauf eingebunden Automatische Code-Analyse Beratung Umsetzung Planung Entwickler Consultant

Mehr als 280 Komponenten werden monatlich gerechnet Größenverteilung der Komponenten Klassen Relevante Code-Zeilen winzig 1 - 10 1 – 999 klein 11 - 150 1.000 – 9.999 mittel 151 – 1.000 10.000 – 99.999 groß 1.001 – 2.500 100.000 – 249.999 riesig > 2.500 > 250.000

Mit der Größe der Komponenten nehmen auch die Mängel zu Qualität im Vergleich zur Größe

Aus den Ergebnissen werden Maßnahmen zur Verbesserung der Qualität abgeleitet Tiefen-Reviews Intensive Analyse der Komponente mit Qualitätsbericht Workshop mit Entwickler(n) Schreiben an Komponenten-Verantwortliche E-Mail mit Hinweis auf die Auswertung Seminare für Entwickler und Komponentenverantwortliche Vereinbarung von Qualitätszielen Maßnahmen

Agenda Innere Softwarequalität und Architektur-Erosion Software-Tomograph Voraussetzungen für die statische Codeanalyse Aufbau des Umfeldes bei der FIDUCIA Ergebnisse und Maßnahmen Ausblick

Die nächsten Schritte Planung Quality-Gate für neue Komponenten Verankert im Vorgehensmodell Aufnahme weiterer spezieller Metriken (newDTInteger, SystemOutPrint, PrintStacktrace) Neue projektspezifische Auswertung Zusammenfassung mehrerer Komponenten zu einer Gesamtauswertung Ausblendmöglichkeit bestimmter Klassen für bestimmte Metriken Beim Berechnen Beim Erstellen des Reports Planung

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

Fragen? – Diskussion? Harald Doderer Thomas Schoen Anwendungsentwicklung Technische Architektur harald.doderer@fiducia.de 0721 - 4004 - 2215 Thomas Schoen hello2morrow GmbH Thomas.Schoen@hello2morrow.com 089 - 548479 - 41

Ihr IT-Partner Vielen Dank