Statische Programmanalyse & Metriken

Statische Codeanalyse verlangt ein stures, monotones Anwenden von relativ einfachen Regeln auf oft umfangreichen Code. Diese Aufgabe erfordert keinerlei Kreativität aber eine sehr große Übersicht und Kontrolle. ...

Statische Codeanalyse ist daher prädestiniert zur Automatisierung durch Werkzeuge. Ich empfehle Ihnen, diese Techniken entweder werkzeuggestützt oder gar nicht einzusetzen

Der „Prüfling” (Programm, Modell, Dokumentation) wird von Menschen oder Werkzeugen auf Vorhandensein/Abwesenheit von Eigenschaften untersucht

-> Review (Inspektion, Walkthrough): Prüfung durch (Gruppe v.) Menschen

-> statische Analyse: werkzeuggestützte Ermittlung von „Anomalien”

->(formale) Verifikation: werkzeuggestützter Beweis von Eigenschaften

Der „Prüfling” wird mit konkreten oder abstrakten Eingabewerten auf einem Rechner ausgeführt

• dynamischer Test: Prüfung des Testobjekts durch Ausführung auf einem Rechner (mit ganz konkreten Eingaben)

• [symbolischer Test: Ausführung mit symbolischen Eingaben (die oft unendliche Mengen möglicher konkreter Eingaben repräsentieren)]

• Visualisierung von Programmstrukturen

• manuelle Reviews

• Compilerprüfungen

• Programmverifikation und symbolische Ausführung

• Stilanalysen

• Kontroll- und Datenflussanalysen

• Metriken

Große Systeme sind immer in Subsysteme gegliedert, von denen jedes eine Anzahl von Diensten bereitstellt. Der fundamentale Prozess zur Definition dieser Subsysteme und zur Errichtung eines Rahmenwerkes für die Steuerung und Kommunikation dieser Subsysteme wird Entwurf der Architektur ... genannt.

Ein Softwaresystem besteht aus Teilsystemen, die zusammengehörige Gruppen von Diensten anbieten und möglichst unabhängig voneinander realisiert sind

Ein Teilsystem kann wiederum aus Teilsystemen aufgebaut werden, die aus Modulen (Paketen) bestehen.

Ein Modul (Paket) bietet über seine Schnittstelle Dienste an und benutzt (importiert) zu ihrer Realisierung Dienste anderer Module (Pakete).

Ein Modul fasst „verwandte“ Prozeduren, Klassen, ... zusammen

Systematische Verfahren zur gemeinsamen „Durchsicht“ von Dokumenten (wie z.B erstellte UML-Modelle, implementierten Klassen, … )

• Inspektion: ein stark formalisiertes Verfahren, dessen Ziel die Identifizierung von Befunden in einem Arbeitsprodukt ist und das Statistiken (Messungen) zur Verbesserung des Reviewprozesses und des Softwareentwicklungsprozesses liefert

• Technisches Review: weniger formale manuelle Prüfmethode; weniger Aufwand als bei Inspektion, ähnlicher Nutzen

• Informelles Review (Walkthrough): unstrukturiertere Vorgehensweise; Autor des Dokuments liest vor, Gutachter stellen spontan Fragen

• [ Pair Programming: Programm wird von vornherein zu zweit erstellt ]

• Planung des gesamten Verfahrens durch Management und Moderator

• Auslösung der Inspektion durch Autor eines Dokumentes (z.B. durch Freigabe)

• Eingangsprüfung durch Moderator (bei vielen offensichtlichen Fehlern wird das Dokument sofort zurückgewiesen)

• Einführungssitzung, bei der Prüfling den Gutachtern vorgestellt wird

• Individualuntersuchung des Prüflings (Ausschnitt) durch Gutachter (zur Vorbereitung auf gemeinsame Sitzung) anhand ausgeteilter Referenzdokumente

• auf Inspektionssitzung werden Prüfergebnisse mitgeteilt und protokolliert sowie Prüfling gemeinsam untersucht

• Nachbereitung der Sitzung und Freigabe des Prüflings durch Moderator (oder Rückgabe zur Überarbeitung)

Der Kontrollflussgraph ist eine häufig verwendete Methode zur Darstellung von Programmen. Die Verarbeitungssteuerung übernehmen die Kontrollstrukturen der Software unter Nutzung der Datenwerte. Eingabedaten werden gelesen, um Zwischenergebnisse zu bestimmen, die in den Speicher geschrieben werden. Die Daten „fließen“ quasi durch die Software; von Eingaben zu Ausgaben

Eine Anomalie eines Softwareprodukts ist eine Unstimmigkeit, die durch Abweichung von (berechtigten) Erwartungen ausgelöst wird, bzw. eine verdächtige Stelle in einem Softwareprodukt. Eine solche verdächtige Stelle ist keine garantiert fehlerhafte, aber eine potentiell fehlerhafte Stelle im betrachteten Softwareprodukt.

• es gibt einen Pfad im Kontrollflussgraphen, auf dem eine Variable v referenziert wird bevor sie zum ersten Mal definiert wird (Zugriff auf undefinierte Variable)

• es gibt einen Pfad im Kontrollflussgraphen, auf dem eine Variable v zweimal definiert wird ohne zwischen den Definitionsstellen referenziert zu werden (nutzlose Zuweisung an Variable)

Kontrollflussanomalien sind bei modernen Programmiersprachen von geringerer Bedeutung. Im wesentlichen handelt es sich dabei bei Programmiersprachen ohne „goto“-Anweisungen um nicht erreichbaren Code (ansonsten beispielsweise Sprünge in Schleifen hinein).

Die Definition von Software-Maßen basiert auf dem Wunsch, einen quantitativen Zugang zum abstrakten Produkt Software zu gewinnen. Dabei ist zwischen der Vermessung von Eigenschaften einer Software und der quantitativen Kontrolle des zugrundeliegenden Entwicklungsprozesses zu unterscheiden

• Produktmetriken: Eigenschaften der SW

• Prozessmetriken: Eigenschaften des Entwicklungsprozesses

• Einfachheit: berechnetes Maß lässt sich einfach interpretieren

• Eignung (Validität): es besteht ein (einfacher) Zusammenhang zwischen der gemessenen Eigenschaft und der interessanten Eigenschaft

• Stabilität: gemessene Werte sind stabil gegenüber Manipulationen untergeordneter Bedeutung

• Rechtzeitigkeit: das Maß kann zu einem Zeitpunkt berechnet werden, zu dem es noch zur Steuerung des Entwicklungsprozesses hilfreich ist

• Reproduzierbarkeit: am besten automatisch berechenbar ohne subjektive Einflussnahme des Messenden

• Nominalskala

• Ordinalskala

• Retionalskala

• Metrik soll zur Prognose der Fehler (einer bestimmten Art) in einem Softwaresystem eingesetzt werden

• Softwarequalität wird also mit etwas „leicht“ messbaren wie der Anzahl der Fehler pro Codezeile (die bis zum Zeitpunkt x gefunden wurden) gleichgesetzt

• 1. Hypothese: komplexer Code enthält mehr Fehler als einfacher Code (pro Zeile Quelltext)

• gesucht werden also Metriken für Komplexität eines untersuchten (gemessenen) Softwaresystems

• 2. Hypothese: es gibt einfachen Zusammenhang zwischen der gemessenen Softwarekomplexität und der Anzahl später gefundener Fehler (pro Codezeile)

• Response For Class (RFC): die Anzahl der in der Klasse deklarierten Methoden + die Anzahl der geerbten Methoden + die Anzahl sichtbarer Methoden anderer Klassen (Alle Methoden, die aufgerufen werden können? Sehr schwammig definiert!!!)

• Weighted Methods Per Class (WMPC1): die Summe der zyklomatischen Zahlen ZZ aller Methoden der Klasse (ohne geerbte Methoden)

• Number of Remote Methods (NORM): die Anzahl der in einer Klasse gerufenen Methoden „fremder“ Klassen (also nicht die Klasse selbst oder eine ihrer Oberklassen)

• Attribute Complexity (AC): die gewichtete Summe der Attribute einer Klasse wird gebildet; Gewichte werden gemäß Typen/Klassen der Attribute vergeben

1. Fragen zur Ausgangssituation

2. Bewertung des aktuellen Standes des Entwicklungsprozesses:

3. Mittel zur Bestimmung des aktuellen Standes, zu messende Aspekte

4. Analyse der Ergebnisse und Erarbeitung von Verbesserungsvorschlägen

5. Bewertung der durchgeführten Änderungen