...we make the invisible visible... Qualitätsanalyse, Code Comprehension und Reengineering 1
Statische Software Analyse From Wikipedia, the free encyclopedia Static analysis is the analysis of computer software that is performed without actually executing programs built from that software (analysis performed on executing programs is known as dynamic analysis). In most cases the analysis is performed on some version of the source code and in the other cases some form of the object code. The term is usually applied to the analysis performed by an automated tool, with human analysis being called program understanding or program comprehension. 2
Inhalt Grundidee der statischen Analyse Auf statischer Analyse basierende Qualitätsanalyse Auf statischer Analyse basierende Unterstützung für das Verstehen und Verändern von Softwaresystemen 3
Use Cases Qualitätsanalyse Projektbegleitend Einmalig durch externe Experten Code Comprehension Visualisierung High-level Cross-Referencing Verwendung von Bibliotheken Reengineering What-if-Analyse Simulation von Umstellungen der Package-Struktur Überwachung des Übergangs von der Soll- zur Ist-Architektur 4
Sotograph-Werkzeugfamilie Web & Reporting Add-On Sotoweb Sotoreport HTML Reports fast overview of trends in relevant quality aspects for sets of software systems HTML-GUI fast interactive access of information about rule violations and metric values, their change over time, flexible zooming down to source code Repository (RDBMS) Sotograph Sotograph Client Swing-GUI manage architecture and metric models visualization what-if-analyses ad-hoc queries 5
Sotograph-Integrationsschnittstellen Eclipse, Developer Studio, UltraEdit, Emacs,... Java Byte Code Parser IDE Plugin Interface Java Source Parser Remote Call Analysis EJB Analyzer C++ Parser Repository Fill Interface Repository (RDBMS) Custom Fill Interfaces Component Configuration Analysis C# Parser CodeChecker Plugin Interface PMD Checkstyle, PCLint... DupliScope 6
Top-down Qualitätsmodelle z.b. ISO 9126 7
Entwurfszielgetriebenes Qualitätsmodell 8
Bottom-up Qualitätsmodell Bottom-up (oder was kann ich messen) Harte Fakten Architekturabweichungen und Schnittstellenverletzungen Projektspezifische Architekturregeln Zyklen Grosse duplizierte Code Blöcke Regelverletzungen Hinweise auf potentielle Probleme Typischerweise durch Metriken Grösse Kopplung Komplexität Metrikwerte müssen interpretiert werden 9
Bottom-up Metrikaggregationsmodell 10
Top-down vs. Bottom-up in der Praxis Top-down Spricht tendenziell eher Manager an Qualitätszielorientiert Unternehmensweites Vergleichen von Anwendungen Benchmarking Keine Architekturprüfung Schwergewichtig einzuführen Bottom-up Spricht tendenziell eher Architekten an Problemorientiert Architekturzentriert Einfach einzuführen 11
Architekturanalyse Grundvoraussetzungen Abstraktion Analyse der Veränderung über die Zeit 12
Analyse auf Symbolebene 500.000 LOC 50.000 Symbole 13
Analyse auf Klassen/Dateiebene 4.000 Klassen 14
Analyse auf Paket/Verzeichnisebene 250 Packages 15
Analyse auf Subsystemebene 20 Subsysteme 16
Subsystemschnittstellen 17
Grapharchitekturen Erlaubte Beziehung Verbotene Beziehung 18
Schichtenarchitekturen Strikte Schichtung durchbrochen (optional) Produkt 1 Produkt 2 Abhängigkeit innerhalb einer Schicht (optional) Interface Datenhaltung Aufwärtsreferenz: Immer illegal Oberfläche Fachlogik Illegale Benutzungsbeziehungen: 19
Anwendung von Schichtenarchitekturen Klassische Prozessmodelle Prozess- und Library- Schichtenmodelle Vertikale Schichten z.b. für Produktlinien Verfeinern einer Schicht 20
Zyklenbasierte Architekturanalyse Wieso sind zyklische Beziehungen problematisch? Artefakte die zyklisch gekoppelt sind können nicht einzeln getestet werden. Artefakte die in verschiedenen Zyklen gebraucht werden spielen dabei häufig mehrere Rollen, was sie schlecht verständlich macht. Artefakte die in verschiedenen Zyklen gebraucht werden können nicht mehr einfach ausgetauscht werden. Erfahrung in grossen Projekten zeigt dass Zyklen die Wartbarkeit deutlich verschlechtern das Auflösen von Zyklen nicht mehr Wartbare Systeme wieder erweiterbar machen kann 21
Identifikation von dupliziertem Code Erfahrung aus der Praxis zeigt dass man in mittelgrossen Projekten häufig Kopien von Klassen oder grossen Teilen von Klassen findet In sehr grossen Softwaresystemen bis zu 70% des Codes aus Kopien besteht Auswirkungen Kopien bedeuten, dass bei Änderungen mehrere Stellen berücksichtigt werden müssen. Häufig ist man sich dessen aber nicht bewusst. Kopien, speziell wenn sie noch leicht angepasst sind komplizieren das Testen. 22
Metrik- und regelbasierte Analyse Arten Architekturmetriken Z.B. Stabilitätsmetriken von Robert C. Martin Grössen- und Kopplungsmetriken Z.B. Anzahl Klassen pro Package, Anzahl verwendeter Packages Komplexitätsmetriken Z.B. Cyclomatic Complexity Regeln Z.B eine Klasse darf die von ihr abgeleiteten Klassen nicht kennen Bad Smells Z.B. Flaschenhälse, unbenutzte Artefakte 23
Möglichkeiten und Grenzen Was bedeutet es wenn alle Messwerte im Grünen Bereich liegen? Wichtige strukturelle Eigenschaften entsprechen den Vorgaben. Zentrale Ursachen für den Architekturellen Verfall werden vermieden. Es wird sorgfältig und sauber gearbeitet. Worüber kann man keine Schlüsse ziehen? Sinnvollkeit der Vorgaben Logik der Implementierung Was gehört sonst noch zu einer umfassenden Sicherung der inneren Softwarequalität? Reviews auf Architektur- und Quelltextebene Diese müssen durch Werkzeuge unterstützt werden. Der Nutzen hängt stark von den Fähigkeiten des Reviewers ab. 24
Typischer Einsatz in der Praxis Kurzanalysen Ein Tag genügt um den Finger in die offenen Wunden zu legen. Die Entwickler sind sich der Ursachen ihrer Probleme häufig nicht bewusst. Kontinuierliche Qualitätsüberwachung Mit kleinem wöchentlichen Aufwand möglich Prozessveränderungen und Auseinandersetzung mit der Architektur kosten Zeit Sollte früh im Projekt einsetzen Basisanalyse und Einarbeitung: 2-3 Tage Workshop über Qualitätsmodelle nach ein paar Monaten Erfahrung Software Qualitätsanalyse durch Qualitätsberater Sehr tiefgehende Qualitätsanalysen grosser, komplexer Softwaresysteme zwei Personenwochen Aufwand Expertenwissen notwendig 25
Nutzen des Qualitätsmonitoring T-Systems Multimedia Solutions GmbH, Dresden In den Projekten in denen wir diese Techniken einsetzen sparen wir ca. 20% Wartungskosten. Christian Federspiel, VOEST-ALPINE Industrieanlagenbau, Linz Mit Hilfe des Sotographen untersuchen wir unsere Software regelmässig auf Architekturabweichungen. Das frühe Auffinden solcher Abweichungen spart uns erhebliche Kosten bei späteren Erweiterungen und kundenspezifischen Anpassungen. Wir sind sehr froh, dass wir den Sotographen haben! Michael Qvortrup, Zühlke Engineering AG, Zürich Nach ca. einen Tag Aufwand hat mir der Sotograph für ein mittelgrosses Projekt mehr relevante Architekturprobleme gezeigt, als ich nach etwa einer Woche manuellen Review selbst gefunden habe. Besser noch, der Sotograph überprüft danach laufend, ob die Probleme behoben worden sind, oder ob neue dazu gekommen sind. 26
Nutzen des Qualitätsmonitoring II Frank Simon, SQS Software Quality Systems AG, Köln Erst mit Werkzeugen wie dem Software-Tomographen ist eine maximale Transparenz bzgl. Technischer Qualität möglich und kann damit die Zukunftsfähigkeit moderner Softwaresysteme gesichert werden. In unterschiedlichen Projekten konnten wir belegen, daß der initiale Aufwand, der für die Umsetzung der Konzepte erforderlich ist, bereits nach einem Jahr einen deutlich positiven ROI besitzt. Neben diesen monetären Vorteilen existieren weitere Verbesserungen wie einfachere Planbarkeit, bessere Mitarbeiteraustauschbarkeit und höhere Unabhängigkeit zu bestimmten Werkzeugen/Techniken. 27
Buchempfehlung Refactorings in grossen Software Projekten Martin Lippert und Stefan Roock Beschreibt Architecture-Smells. D.h. probematische Muster auf architekturebene Wie man Architecture- Smells identifiziert Wie man Architecture- Smells ausmerzt 28
Software-Tomography GmbH Cottbus, München, Zug www.software-tomography.com 29