Def. Statische Codeanalyse
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
Def. Analysierende Verfahren
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
Def. Testende Verfahren (2 Tests)
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)]
Arten der Programmanalyse (5)
Visualisierung von Programmstrukturen
manuelle Reviews
Compilerprüfungen
Programmverifikation und symbolische Ausführung
Stilanalysen
Arten der statischen Programmanalyse (2)
Kontroll- und Datenflussanalysen
Metriken
Def. Softwarearchitektur
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.
Def. Softwaresystem
Ein Softwaresystem besteht aus Teilsystemen, die zusammengehörige Gruppen von Diensten anbieten und möglichst unabhängig voneinander realisiert sind
Def. Teilsystem
Ein Teilsystem kann wiederum aus Teilsystemen aufgebaut werden, die aus Modulen (Paketen) bestehen.
Def. Modul
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
Def. Strukturierte Gruppenprüfungen (Reviews)
Systematische Verfahren zur gemeinsamen „Durchsicht“ von Dokumenten (wie z.B erstellte UML-Modelle, implementierten Klassen, … )
Verfahren für strukturierte Gruppenprüfungen (Reviews) (4)
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 ]
Aufbau einer Inspektion (7)
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)
Def. Kontrollflussgraph
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
Def. Anomalie
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.
Def. Datenflussanomalie (2)
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)
Def. Kontrollflussanomalie
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).
Def. Softwaremetriken (2 Arten von Softwaremetriken)
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
Gewünschte Eigenschaften von Maß / Metriken (5)
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
Maßskalen (3)
Nominalskala
Ordinalskala
Retionalskala
Zielsetzungen von Softwaremetriken (5)
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)
Komplexitätsmaße (4)
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
Vorgehensweise beim Einsatz von Maßen (5)
Fragen zur Ausgangssituation
Bewertung des aktuellen Standes des Entwicklungsprozesses:
Mittel zur Bestimmung des aktuellen Standes, zu messende Aspekte
Analyse der Ergebnisse und Erarbeitung von Verbesserungsvorschlägen
Bewertung der durchgeführten Änderungen
Zuletzt geändertvor 6 Monaten