Kontrolle über Architekturerosion und Codequalität bei 40 Mio LOC

Präsentation zum Thema: "Kontrolle über Architekturerosion und Codequalität bei 40 Mio LOC"—  Präsentation transkript:

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

2 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

3 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

4 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

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

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

7 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)

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

9 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.

10 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

11 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

12 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

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

14 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

15 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

16 Aggregation auf höhere Abstraktionsebnen: Analyse auf Symbolebene
Beispielprojekt: LOC ca Symbole – 1 Mio Referenzen

17 Aggregation auf höhere Abstraktionsebnen: Analyse auf Klassenebene
Beispielprojekt: LOC ca Klassen

18 Aggregation auf höhere Abstraktionsebnen: Analyse auf Paketebene
Beispielprojekt: LOC ca Packages

19 Aggregation auf höhere Abstraktionsebenen: Analyse auf Subsystemebene
Beispielprojekt: LOC Subsysteme

20 Aggregation auf höhere Abstraktionsebenen: Subsystemschnittstellen
Beispielprojekt: LOC Subsysteme

21 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:

22 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

23 Wie funktioniert der Software-Tomograph im praktischen Einsatz?

24 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

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

26 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

27 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

28 Auf Sotoweb-Report basierende Benchmarks wurden festgelegt
Architekturqualität % Feinentwurfsqualität (Fehler) % Implementationsqualität (Fehler) % Feinentwurfsqualität (Warnung) % Implementationsqualität (Warnung) %

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

30 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

31 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 x Sotoplatform bit Technische Daten

32 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

33 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

34 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

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

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

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

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

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

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

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

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

43 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

44 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

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

46 Mehr als 280 Komponenten werden monatlich gerechnet
Größenverteilung der Komponenten Klassen Relevante Code-Zeilen winzig 1 – klein 1.000 – mittel 151 – 1.000 – groß 1.001 – 2.500 – riesig > 2.500 >

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

48 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 mit Hinweis auf die Auswertung Seminare für Entwickler und Komponentenverantwortliche Vereinbarung von Qualitätszielen Maßnahmen

49 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

50 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

51 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

52 Fragen? – Diskussion? Harald Doderer Thomas Schoen
Anwendungsentwicklung Technische Architektur Thomas Schoen hello2morrow GmbH

53 Ihr IT-Partner Vielen Dank