Software-Qualität sichtbar machen

Transkript

1 Software-Qualität sichtbar machen Prof. Dr. Claus Lewerentz BTU Cottbus Vortrag im Rahmen des Berlin-Brandenburger Software-Forums Zeit: 28. April 2003,18.30 Uhr Ort: Fraunhofer FIRST Berlin

2 Software Qualität Software-Produkt Nutzer Entwickler Externe Qualität Interne Qualität Benutzbarkeit Fehlerfreiheit erfüllt Aufgaben gut wartbar verständlich gut strukturiert Anforderungsanalyse Testen... Reviews Metrikbasierte Qualitätsanalyse

3 Typische Szenarien Software-Systeme 10 2 Subsysteme Klassen 10 6 LOC Probleme... Wie können (neue) Entwickler ein System verstehen? Systemüberblick? Wie wartbar ist ein System? Wie können qualitätskritische Teile identifiziert werden? Gibt es einen Qualitätstrend?...diese Informationen in sehr kurzer Zeit beschaffen? Unterstützung für Reverse Engineering, Reengineering Vorbereitung von Reviews Qualitätsanalyse Lange Lebensdauer

4 Produkt-Analyse und Visualisierung Metapher aus der Medizin: Tomography... Unsichtbare Dinge sichtbar machen...? Therapie Diagnose

5 Software-Tomographie Daten-Extraktion, Visualisierung, Interpretation Analyse- und Visualisierungswerkzeuge IDE/C ASE interactio n Ar chitect ure scope Parser Query scope CASE- Information scope Tool extractor s Reposi- (RDB) System Metrics scope Runtime data Graph visualizer Query developer Analysemodell re-engineering Programm-Analyse IDE CM- tory Xref-

6 Beispiel eines Qualitätsmodells Qualitätsziel Faktor Entwurfsprinzip Entwurfsregel Metrik (Zielwert) Modularität Schmale Schnittstellen #Parameter pro Methode (min) Kopplung #Referenzen (min) CBO (min) Strukturiertheit Subsysteme #Referenzen über Paketgrenzen (min Kohäsion #Aufrufe (min) Wartbarkeit Realisieren Abstraktion Prüfen Abstrakte Schnittstellen LCOM (min) Verständlichkeit Einfachheit Kapselung #öffentliche Methoden (min) Vererbung Klassenkomplexität Methodenkomplexität Verbindungskomplexität Tiefe des Vererbungsgraphen (T) Breite des Vererbungsgraphen (T) Referenzen zu abstr. Klassen (max) zyklomatische Komplexität (min) WMC (T) LOC pro Methode (T)

7 Beispiel eines Produktmodells system 1..1 subsystem name : string Subsystemschachtelung 1..n subclass superclass file name : string 1..1 class name : string abstract : bool Vererbungsstruktur Klassenschachtelung method name : string visibility : int length : int abstract : bool virtual : bool read/write called calling Aufrufgraph Benutzt -Graph attribute name : string visibility : int

8 Betrachtungsebenen Paketebene Eingehende Aufrufkopplung zwischen Paketen Ausgehende Aufrufkopplung zwischen Paketen Anzahl Klassen Klassenebene Anzahl öffentlicher Methoden Anzahl öffentlicher Attribute Tiefe im Vererbungsbaum LCOM (lack of cohesion in methods) Anzahl direkt geerbter Methoden Attributenebene Methodenebene NoGetSet McCabe

9 Aufruf Vererbung Attributzugriff Größe opplung ohäsion odeeigenchaften Interessante SW-Maße Anzahl Klassen pro Paket Anzahl Methoden/Attribute pro Klasse Anzahl Parameter pro Methode Anzahl der genutzten Komponenten Anzahl der nutzenden Komponenten Anzahl gemeinsam genutzter Komponenten Pakete Klassen Methoden Anzahl Quellcodezeilen (LOC) Zyklomatische Komplexität Kommentaranteil

10 Qualitätseindruck: Paketstruktur Interne Software Qualität Strukturiertheit Gruppierung von Klassen in Subsystemen Anzahl von Klassen pro Subsystem (sollte überschaubar sein) de/jwamx/technology/iafpf/swingpf de/jwamalpha/handling/processfolder/tool 8 Frequenz Anzahl Klassen pro Subsystem

11 Qualitätseindruck: Paketkopplung Interne Software Qualität Wartbarkeit Kopplung Anzahl genutzter Pakete (sollte klein sein) : de/jwamx/handling/desktop 60: de/jwamalpha/handling/collection Frequenz Anzahl Pakete, von denen ein Fokuspaket etwas nutzt

12 Visualisierung komplexer Strukturen Formen Farben Größe Kanten mit verschiedenen Farbübergängen Layout (ähnliche Objekte räumlich nah) - Objekttypen (Paket, Klasse) - Eigenschaften (Messwerte) - Beziehungen zwischen Objekten (Vererbung, Aufruf, Benutzt) und deren Richtungen - Ähnlichkeit von Objekten (bzgl. Beziehungen mit anderen Objekten)

13 Beispiele für 3D-Modelle

14 arstellung der ufrufstrukturen ischen Klassen

15 Anwendungen Programmverstehen reverse engineering, re-engineering Industrieprojekte Vorbereitung von Reviews Unterstützung von Aktivitäten zur Reorganisation Produktqualitätsbewertung Trendanalyse KLOC C++, JAVA Code PARION data experts

16 Parser SNiFF+ CASE- Tool CM- System Runtime data Analyse-Umgebung sotograph IDE/CASE interaction Query developer Architecture scope Nmnds Dsjdhskj Mdnsmd# dnmsd Nmnds Dsjdhskj Mdnsmd# dnmsd Query scope Information Extractors (XML streams) Repository (RDB) Xrefscope Graph visualizer transformation engine Nmnds Dsjdhskj Mdnsmd# dnmsd Metrics scope

17 Metrikbasierter Reviewprozess Rückkopplung Produktdaten + quantitative Daten, Ziele Vorbereitung Ausführung + gefundene Anomalien Reflexion dokumentiert in dokumentiert in Beispiel JWAM 1.4: BERICHT 220 KLOC Java 1159 Klassen Zum Kunden

18 Diagnosen und Empfehlungen Zwei Beispiele aus JWAM 1.4 Bericht Lines of Code: Die Datei HtmlStandardWriter scheint zu groß (1277 LOC) Zustimmung Neuigkeit Anzahl öffentlicher Attribute: Die Klasse ConfigurationStandard enthält 18 öffentliche Attributes. Diese werden nur innerhalb der Methoden der Klasse verwendet. Ihre Sichtbarkeit sollte daher auf private oder protected beschränkt werden. Das selbe gilt für die Klasse ClassUseMapper. Zustimmung Neuigkeit + 0 -

19 Evaluation der Analyse-Ergebnisse JWAM 1.4: 27 Diagnosen 28 Empfehlungen strong accept (++) weak accept(+) Indifferent (0) weak reject (-) strong reject (--) die kritischsten Probleme wurden JWAM 1.5 behoben JWAM 1.5: 36 Diagnosen 32 Empfehlungen

20 Zusammenfassung Software-Tomographie = Explizitmachen von Qualitätseindrücken mit dem Ziel Reengineering-Aktivitäten zu fokussieren Softwarequalität kann unter externen und internen Aspekten betrachtet werden Die objektive Messung von interner Qualität führt über Ein Qualitätsmodell Automatische Erfassung des Messwerte entspr. Metriken Interpretation der Messwerte im Hinblick auf die ursprünglichen Anforderungen Anwendung: Metrikbasierter Reviewprozess anwendbar bei großen SW-Systemen ( LOC) Liefert schnell einen Überblick, Eindruck von Struktur des Systems Generiert Fragen hinsichtlich der Qualitätsanforderungen BERICHT

21 ViSEK ist für Sie da! Ausführliche Informationen zum Thema Messen im Software-Engineering befinden sich im Portal Einstieg: SE-Themen/Qualität