...we make the invisible visible...

Transkript

1 ...we make the invisible visible... 1

2 Inhalt Qualitätsbegriff Fragestellungen im Zusammenhang mit innerer Softwarequalität Analysen und deren Anwendung Erfahrungen 2

3 Ausfallsicherheit Datensicherheit Zuverlässigkeit Qualität eines IT-Systems Korrektes funktionale Verhalten Akzeptable Performance Benutzerfreundlichkeit Installierbarkeit / Konfigurierbarkeit Modultests, Funktionstests, Lasttests, Massentests, Sicherheitstests, Recovery-Tests, Acceptance-Tests, Installationstests, Konfigurationstests Software wird als Blackbox betrachtet! 3

4 Innere (technische, strukturelle) Softwarequalität Grundsätzliche Fragen Ist die Software mit vernünftigem Aufwand wartbar? Ist die Software testbar? Gibt es eine im Quelltext auffindbare Gesamtarchitektur? Sind die Architekturvorgaben/Designregeln bei der Implementierung eingehalten? Entspricht das System handwerklich unseren Anforderungen? Können Systemteile ersetzt werden? 4

5 Innere (technische, strukturelle) Softwarequalität Verständlichkeitsbezogene Fragen Können sich neue Entwickler mit akzeptablem Aufwand einarbeiten? Wissen wir wie unsere Bibliotheken eingesetzt werden? Kann diese Komponente wiederverwendet werden? 5

6 Innere (technische, strukturelle) Softwarequalität Ist die Software mit vernünftigem Aufwand wartbar? Ist die Software testbar? Gibt es eine logische Gesamtarchitektur? Sind die Architekturvorgaben/Designregeln bei der Implementierung eingehalten? Können sich neue Entwickler mit akzeptablem Aufwand einarbeiten? Die Sind einzelne Antworten Komponenten liegen wiederverwendbar im Quelltext?! Können Systemteile durch technologisch neuere ersetzt werden? Kann die Software erweitert werden ohne dabei die Qualität zu verschlechtern? Werden Technologie-Standards durchgängig eingesetzt? 6

7 Ist innere Softwarequalität wirklich wichtig? Unser System fassen wir nur noch in Ausnahmefällen an. Wir haben jedesmal Angst, dass es uns auseinander fällt. Dieses System schmeissen wir am besten weg und implementieren alles neu. Wir legen den Grundstein zur Zerstörung einer Architektur meist schon während der Implementierung In der Regel wird ein Softwaresystem über seine gesamte Lebensdauer von verschiedenen Projektleitern/Entwicklern gepflegt. Kostensenkung über die ganze Lebensdauer; Investitionssicherheit; Erweiterbarkeit 7

8 Aufbau des Sotographen Java Parser IDE Interaction Query Developer Architecture Scope Java Source Parser Query Scope SNiFF+ C/C++ EJB Analyzer Repository Fill Interface Repository (RDBMS) Xref- Scope Graph Scope Component Structure Custom Fill Interfaces CM Information Metrics & Transformation Engine Metrics Scope 8

9 Verfügbare Beziehungen Abhängigkeiten zwischen beliebigen Artefakten: Vererbungsbeziehungen Call-Referenzen (Aufrufbeziehungen); auch polymorphe Lesezugriff auf Attribute/Variabeln Schreibzugriff auf Attribute/Variabeln Beliebige andere Benutzung von Typen/Klassen Throw/Catch-Referenzen 9

10 Software -Analyse mit Sotograph Abstraktion Architekturanalyse Metrikbasierte Analyse Code Comprehension 10

11 Analyse auf Symbolebene LOC Symbole 11

12 Analyse auf Klassen/Dateiebene Klassen 12

13 Analyse auf Paket/Verzeichnisebene 250 Packages 13

14 Analyse auf Subsystemebene 20 Subsysteme 14

15 Subsystemschnittstellen 15

16 Schichtenarchitektur Strikte Schichtung durchbrochen (optional) Produkt 1 Produkt 2 Datenhaltung Aufwärtsreferenz: Immer illegal Verletzung des Subsystem-APIs: Immer illegal Abhängigkeit innerhalb einer Schicht (optional) Interface Oberfläche Fachlogik Illegale Benutzungsbeziehungen: 16

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

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

19 Metrik- und Regelbasierte Analyse Schwierigkeiten Sehr grosse Menge Messwerte Filtern Verstehen der Ursache eines Messwerts Erklärungen Visualisierung im Kontext des Softwaresystems Das Untersuchen einer Version genügt oft nicht Trend-Unterstützung Definieren eigener Metriken Ermöglicht durch Einfaches Datenmodell im Repository 19

20 Erfahrungen aus der Praxis Kurzanalysen durch uns Ein halber Tag genügt um den Finger in die offenen Wunden zu legen. Die Kunden sind sich dieser Ursachen ihrer Probleme häufig nicht bewusst. Software Qualitätsanalyse durch Qualitätsberater Sehr tiefgehende Qualitätsanalysen grosser, komplexer Softwaresysteme zwei Personenwochen Aufwand Aufwand: Zwei Personenwochen versus 10 Personenwochen Architektur-Reengineering bei einer Schweizer Grossbank 2'000'000 LOC Identifizierung des Problems Überwachung der iterativen Verbesserung Basisanalyse und Einarbeitung: drei Tage 20

21 Software-Tomography GmbH Cottbus, München, Zürich 21