1 Qualitätssicherung mit statischer Analyse

Transkript

1 1 Qualitätssicherung mit statischer Analyse Walter Bischofsberger - Software-Tomography GmbH Inhaltsverzeichnis Qualitätssicherung mit statischer Analyse...1 1Grundidee der statischen Analyse...1 Kurze Definition...1 Ausführliche Definition [Wikipedia Static Code Analysis]...1 Datenerhebung...2 Abstract Syntax Tree...2 Definition [Wikipedia]...2 Linking in Java...2 Datenverwendung...3 Cyclomatic Complexity...3 Qualitätsanalyse auf Ebene von Entitäten und Abhängigkeiten...3 Use Cases...3 2Auf statischer Analyse basierende Qualitätsanalyse...4 Typische Probleme...4 Ansätze zur Verbesserung...5 Identifikation von duplizierten Code...6 Zyklenanalyse...6 Analyse auf Klassen / Dateiebene...6 Analyse auf Paket, Namespace oder Verzeichnissebene...7 Analyse auf Subsysteme...7 Grapharchitekturen...7 Sichtenarchitektur...7 Anwendungen von Schichtenarchitekturen...7 Qualitätsmodelle...7 Bottom Up Qualitätsmodell...8 Möglichkeiten und Grenzen vom Ganzen...8 3Architekturmanagement...8 Enterprise Architekture Management...8

2 1. Grundidee der statischen Analyse Kurze Definition Bei der Statischen analyse wird der Quellcode analysiert. Dynamische Analyse bedeutet Laufzeitanalyse. Ausführliche Definition [Wikipedia Static Code Analysis] Static code 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. The sophistication of the analysis performed by tools varies from those that only consider the behavior of individual statements and declarations, to those that include the complete source code of a program in their analysis. Uses of the information obtained from the analysis vary from highlighting possible coding errors (e.g., the lint tool) to formal methods that mathematically prove properties about a given program (e.g., its behavior matches that of its specification). Some people consider software metrics and reverse engineering to be forms of static analysis. A growing commercial use of static analysis is in the verification of properties of software used in safetycritical computer systems and locating potentially vulnerable code. Datenerhebung Suche nach Mustern Häufige Anwendung: Duplizierten Code finden Oft lässt sich mit sehr einfachen Methoden eine Aussage zur Qualität der Dokumentation machen, zum Beispiel bei der Suche nach dem String hack. Wird bei einem mittelgrossen Projekt nichts bei der Suche nach solchen Schlüsselwörter gefunden kann man davon ausgehen, das entweder alles sauber ohne Hacks programmiert wurde (eher unwahrscheinlich) oder das die Hacks einfach nicht dokumentiert wurden. Syntaxgetriebene Analyse Lexikalische Analyse Analyse der Token aufgrund der Syntax Recursive Descent vs Tabellengetrieben Linking Symboltabelle und Abstract Syntax Tree Durch Analysewerkzeug Entitäten und Abhängigkeiten Abstract Syntax Tree Definition [Wikipedia] In computer science, an abstract syntax tree (AST), or just syntax tree is a finite, labeled, directed tree, where each interior node represents a programming language construct and the children of that node represent meaningful components of the construct. We devise operators to name these programming language constructs. Internal nodes are labeled by these operators, and the leaf nodes represent the operands of the operators. Thus, the leaf nodes are NULL operators and only represent variables or

3 constants. Praktisch, wenn man verstehen will, wie genau die Statements abgearbeitet werden. AST nicht geeignet für komplexe Programme. Deswegen wird eine Symboltabelle generiert, die den Namensraum aufzeigt. Code generieren, low level Analyse. Nicht geeignet für high level Analyse. Linkschritt Bäume werden nach Packages zusammengefasst (z.b. Java) Linking in Java Bei C/C++ muss man die einzelnen Binaries nach dem Compilieren noch linken. Bei Java ist dieser Schritt nicht notwendig. Dies geschieht zur Laufzeit vom Classloader. Datenverwendung Transformieren und generieren von Code Hier werden Relgen, die ursprünglich in der KI entwickelt wurden, verwendet. Regelprüfung Mustersuche in Syntaxbäumen. (z.b. nach leerem Catch prüfen) Metriken Cyclomatic Complexity, deeply nested Statements (z.b. Suche nach sehr langen Methoden) Cyclomatic Complexity Kurz: Beschreibt die Anzahl Statements, die in einer Methode verwendet werden. [Wikipedia McCabe-Metrik] Die McCabe-Metrik (auch zyklomatische Komplexität - cyclomatic complexity) ist eine Software- Metrik, mit der die Komplexität eines Software-Moduls gemessen werden kann. Die zyklomatische Komplexität wurde bereits 1976 durch Thomas J. McCabe eingeführt. Hinter der Software-Metrik von McCabe steckt der Gedanke, dass ab einer bestimmten Komplexität das Modul für den Menschen nicht mehr begreifbar ist. Er definiert seine cyclomatic complexity auf dem Kontrollflussgraphen eines Moduls. Einfach ausgedrückt ist das Komplexitätsmaß nach McCabe gleich der Anzahl der binären Verzweigungen plus 1. Symbolische Ausführung Suche nach potentiellen Laufzeitfehlern. C/C++ Suche nach falsch verwendeten Pointers und nicht initialisierten Variablen. Qualitätsanalyse auf Ebene von Entitäten und Abhängigkeiten Kopplungsmetriken: Wie und von wo wird etwas Aufgerufen.

4 Softwaremetriken Az verwendete Klassen. Zyklensuche Wieso interessant? Abhängigkeit von mehreren teilen. Schwieriges Testen. Nur zusammen Austauschen oder gar nicht. Architekturprüfung Übereinstimmung Architektur und Quelltext Use Cases Qualitätsanalyse Qualitätsmonitoring: Periodische Überwachung. Allg Voraussetzung: Regeln müssen geprüft werden. Keine der selbstgegeben Regeln werden verletzt. Differenz der Regelverletzungen seit letzten Release Detailierte Analyse Gemacht von Spezialisten, dauert 1-2 Wochen. Nicht nur Regeln und Metriken, Diskussion mit Leuten. Werkzeug muss so viel Information wie möglich liefern. Code Comprehension Visualisierung Crossreferencing Use case: Man möchte etwas aus einem Projekt in einem anderen Projekt verwenden. Transitive Hülsen, UML. Doku Kann man automaitsch ein grosses UML Diagramm generieren, das Dokumentationswert hat? => Nein zu viel Information, Resultat muss noch angepasst und Dokumentiert werden. Detailabfragen Reenginieering What-if Analyse Simulation von Umstellung der Package-Struktur Überwachung des Übergangs von der Soll- zur Ist-Architektur. Problem: Es gibt viele, kleine, einfach zu behebende Verletzungen. Und nur wenige schwerwiegende Probleme. Aus Sicht der Analyse gibt es Verletzungen, die man einfach erkennen und beheben kann. (Klasse umbenennen und verschieben) Dabei gibt es auch Verletzungen die man bei der Analyse schwieriger zu finden sind. (zb Klasse auspalten.)

5 Problem Koordination in Grossen Projekten, Architektur muss periodisch überprüft werden. 2 Auf statischer Analyse basierende Qualitätsanalyse Typische Probleme Auf der Implementationsebene Handwerklich schlechte Codierung riesige, komplexe Methoden unsorgfältige Fehlerbehandlung Design Ebene Schlecht Strukturierte Klassenknäuel Gottklassen Architekturebene Fehlende Architektur Degenerierte Architektur [Big Ball of Mud Pattern - While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture. These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them. A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them? Ansätze zur Verbesserung Foote and Yoder: An die Sonne legen Expose your code to daylight! Kommunikation, Ausbildung, Kontrolle Code Reading, Pair Programming (Problem: Funktioniert nicht so gut auf Architekturebene, man sieht oft das grosse Bild nicht) Regelprüfung auf Implementationsebene Software Metriken

6 Regelprüfung auf Design und Architekturebene Regelprüfung auf Code-Ebene Regelbeispiele (Fx Cop von Microsoft) Abstract types should not have constructors Assemblies should have valid strong nanmes. Avoid empty interfaces etc Sonnenseite: Design, wie die Platform verwendet werden soll wird geprüft. Schattenseite: Verletzung der Regeln können nicht immer behoben werden. (z.b. out Parameter, aus irgend einem Grund wurden diese schliesslich eingeführt) Im Verlauf eines Projektes wird die Liste von potentiellen Problemen immer grösser. Man müsste die Differenz zwischen 2 Releases anschauen können. Erfahrung Regelpolitik, Entwickler haben oft einen eigenen Sytle und eine Einigung, welche Regeln Sinnvoll sind ist oft schwierig. Findet bei erfahrenen Entwicklern kaum Probleme. Tools für Java: PMD, Chceckstyle, FindBugs Software Metriken Kategorien Grösse Az public Methoden Az Zeilen / Methoden Kopplung Az Artefakte Komplexität Verschachtelung; Cyclomatic Komplexität Bad Smells Gottklassen, unbenutzt Artefakte Erfahrungen Liefert Werde, die interpretiert werden müssen. Viele false Positives. Findet Extremfälle. Gut geeignet als Input für Qualitätsanalysen. Metriken können erfolgreich zu Regeln befördert werden. zb keine Methoden mit mehr als 100 Zeilen. Hauptsächlich als Zusatzinformation nützlich.

7 Identifikation von duplizierten Code Auswirkungen sind bekannt. Erfahrungen aus der Praxis Findet man häufig in mittelgrossen Projekten In vielen Projekten auch kein Problem. In sehr grossen Systemen bis zu 70% des Codes aus Kopien. Koordination der Leute ist ein Problem, Testing ist sehr komplex, vorgeschriebene Test Strukturen. Zyklenanalyse Probleme bei Zyklen Bei Änderung müssen alle Komponenten in einem Zyklus geändert werden. Schichten funktioniert nicht mehr, allerdings können Systeme beim auflösen der Zyklen wieder wartbar machen. Erfahrungen Warten wird mühsam. Auflösen von Zyklen können Systeme wieder wartbar machen. Identifikation von Zyklengruppen Az und Grösse der Gruppe von Entitäten innerhalb deren jede Entität direkt oder indirekt von jeder anderen abhängig ist. Probleme bei Komponenten basierter Software. Komponenten werden häufig mit mehreren Packages verwendet. In Java werden die Access Modifier somit Nutzlos. Das Eclipse Projekt beschäftigt sich seit längerem damit und hat unter anderem ein eigenes Komponentenmodell entwickelt. Ein einfacher Ansatz damit umzugehen ist, alle Sachen, die von aussen verwendet werden dürfen in eine eigene Package zu Packen. Analyse auf Klassen / Dateiebene Man überprüft, das die Muster richtig verwendet werden. (z.b. Framework wird richtig verwendet) In der Praxis leider sehr wenig verwendet. Analyse auf Paket, Namespace oder Verzeichnissebene Architektur wird hier nicht analysisert, macht wenig Sinn. Hauptstruktur wird mit Modul, Komponente oder Subsystem beschrieben. Mapping auf Package Abhängigkeiten macht oft nicht Sinn, da ein Modul oft in Form von mehreren Modulen implementiert wird. Analyse auf Subsysteme.Net Assemblies und dlls, Mapping für Assemblies häufig aufgrund von technischen Aspekten vorgenommen und passen dann nicht zur Architektur.

8 Grapharchitekturen Erlaubte und Verbotene Beziehungen werden dargestellt. Schwierig zu verstehen und zu kommunizieren. Sichtenarchitektur Einfachste Arch: MVC Semantik wird gut Verstanden, aus der Sicht der Kommunikation vorteilhaft. Illegale Beziehung: Zb Datenhaltung benutzt Fachlogik Weitere Beispiele: TCP/IP Anwendungen von Schichtenarchitekturen Vertikale Schichten: Klar abtrennbare Anwendungsteile, die Implementation in mehreren Hauptschichen haben. Beispiel Business Software Horizontale Komponenten: GUI, Datenhaltung, Logik Vertikale Komponenten: Buchhaltung, CRM, Stammdatenhaltung Qualitätsmodelle [ISO 9126] Definiert folgende Qualitätsmerkmale: Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizient, Änderbarkeit, Portabilität Entwurfszielgetriebenes Qualitätsmodell: ISO Werte werden immer weiter verfeinert, bis man bei Coding guidelines ist. Vergleichbarkeit kann geschaffen werden, aber objektive Qualität kann nicht beurteilt werden. Trend zu Benchmarking. Schattenseite: Entwickler kennen die Metriken und Coden entsprechend, und zwar so das man mit dem kleinsten Aufwand das Modell so optimiert, das es einen guten Benchmark gibt (z.b. leere Kommentare) Bottom Up Qualitätsmodell Harte Faken, z.b. Zyklen Hinweise auf potentielle Probleme Grösse Kopplung Komplexität Beispiel Interpretation: Gottklasse ist kein wirkliches Problem, wenn Sie nicht verändert werden muss. Muss sie allerdings ständig angepasst werden und wird dabei noch immer grösser, dann ist es ein Problem.

9 Möglichkeiten und Grenzen vom Ganzen Ergänzung zu herkömmlichen Methoden (Pair programming, Code review) Unterstüzung bei Entscheidungen in Bezug auf Architektur. Globale Sicht, es wird Objektiver entschieden. Nutzen von aufräumen kann dem Management besser kommuniziert werden. 3 Architekturmanagement Enterprise Architekture Management Was machen wir Prozessmässig? Idee: Gesamtarchitektur im Griff halten. Interessiert an Schnittstellen, Technologien (Standards and Guidelines) Application Architecture Management Understand and Judge Quality Target Architecture; Gap Analysis Architecture Decision and Migration Planning Software Architekten haben keine Haftung mehr am Quellcode, nach der Entscheidung werden keine Gedanken mehr über die Arch gemacht => Riesen Problem. Architektur in 2 PPT Folien beschrieben. Feedback Mechanismus?