Measurement-based Product Analysis

Größe: px

Ab Seite anzeigen:

Download "Measurement-based Product Analysis"

Harry Bachmeier
vor 6 Jahren
Abrufe

1 Measurement-based Product Analysis real world empirical relational system formal relational system? model validate cognition barrier measure 126, , 13 97, , 17 > transformation calculation result interpret 24% 38% visualize visual models 1

2 Example: Basic Structural OO Product Abstraction system 1..1 subsystem name : string subsystem nesting 1..n inheritance structure subclass superclass file name : string 1..1 class nesting class name : string abstract : bool method name : string visibility : int length : int abstract : bool virtual : bool read/write called calling use/call graph attribute name : string visibility : int 2

3 Software Produkt-Metriken Kategorien: Größe Anzahl der Komponenten (K) einer Einheit Kopplung Anzahl der K, die eine K kennt, verwendet oder voraussetzt (Aufruf, Zugriff auf Attribut, etc.) ausgehend (afferent), eingehend (efferent) Kohäsion Intensität des Zusammenhangs der K innerhalb einer Einheit Komplexität??? algorithmisch / kognitiv??? 3

4 Einige bekannte Software-Metriken (1) Halstead PL/1, Fortran: complexity for writing/maintaining programs Programm = Menge von Operationen + Menge von Operanden Basis-Metriken: n # verschiedener Operatoren m # verschiedener Operanden N # Operatoren M # Operanden abgleitete Metriken: Programm-Länge L = N+M Volumen V = L*log 2 (n+m) Komplexität K = (n/2)*(m/m) Aufwand E = V*K etc. nie validiert! genügt nicht der Messtheorie! 4

5 Einige bekannte Software-Metriken (2) McCabe Cyclomatic Complexity ( 76) Ziel: Komplexität für Wartung und Verstehen messen Idee: Struktur berücksichtigen; Kontrollflussgraph (CFG) Programm Graph P = (E,V) v V meist Funktionen e E Kontrollflussabhängigkeiten CC(P) = E - V + p (p: Zshg.-Komponenten) Gegenbeispiel s empirische Korrelation für OO nicht geeignet 5

6 OO Metriken DIT: depth of inheritance tree NOC: number of subclasses CBO(c): coupling between objects # der benutzten Attr./Methoden anderer Klassen RFC(c): response for class # Methoden von c + # aller benutzen Methoden anderer Klassen LCOM(c): lack of cohesion ~ wie misst man, ob Klasse c einen abstrakten Datentyp implementiert eine Klasse ein Konzept? 6

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

8 Einflüsse auf das Qualitätsmodell generelles Entwurfswissen Styleguide (projektspez.) Projektrichtlinien Anwendungsdomäne Reifegrad Perspektive Qualitätsziel Faktor Entwurfsprinzip Entwurfsregel Metrik Zielwert Konstruktions- Paradigma Entwurf/ Programmiersprache Metrikauswahl Anwendungstyp 8

Example from a Case Study DFS quality goals: Maintainability Level of object-orientation Portability Dependability focus of analysis OO models a system as a set of collaborating objects Objects

9 Example from a Case Study DFS quality goals: Maintainability Level of object-orientation Portability Dependability focus of analysis OO models a system as a set of collaborating objects Objects have a state and an interface OO Design Principles Bundling Encapsulation Inheritance Polymorphism Apply principles in favour of quality goals Check, whether principles have been applied properly 9

10 Quality Criteria and Metrics Design Concepts Bundling: everything is a class! Encapsulation: hide data representation make encapsulation explicit encapsulate platform dependent parts Low coupling, high cohesion Metrics (target) Usage of class/struct keywords (use class!) number of global variables/functions (min) Usage of keywords private/public/... Number of public attributes (min) Usage of abstraction layers Coupling: degree of dependencies Directions: out-/ingoing Kinds: call/attribute/inheritance attribute couplings (min) bidirectional couplings (min) access to attributes of superclass (min) CBO (min) 10

11 Quality Criteria and Metrics Design Concepts Cohesion: degree of togetherness Levels: package/class/method One class = one responsibility Inheritance: Express specialisation Factor out common class elements Polymorphism: many forms Abstract One class = one responsibility Metrics (target) No. of attributes/methods per class (T) LCOM (min) Number of private method calls (max) No. of abstract classes (max) DIT (T) NOC (T) Number of overwritten methods (max) Number of enums and switches (min) Coding style: Central places for constants Simple control flow Distribution of string constants (min) CC (min) Number of if/switch per unit (min) 11

12 Interpretation of Metrics Values value filter functions definition of threshold values (design rules / statistics) Schwellenwert aus Entwurfsregel threshold from design rule # of "# methods Methoden sollte should kleiner 50 be sein" < 20 (d.h. nach oben begrenzt) outlier Ausreißer Schwellenwert statistisch ermittelt statistical threshold Ausreißer, wenn Wert nach oben begrenzt ("Wert darf nicht zu groß sein") } } µ + σ statist. µ Mittelwert mean value µ µ µ-σ σ outlier Ausreißer, wenn Wert nach unten begrenzt ("Wert value muß at mindestens least... so und so groß sein") 12

13 Quality assessment (package structure) Internal software quality Structuredness Grouping of classes to subsystems Number of classes within a subsystem (should support understandability) de/jwamx/technology/iafpf/swingpf 14 Frequency de/jwamalpha/handling/processfolder/tool Number of classes within a subsystem 13

14 Quality assessment (coupling between packages) Internal software quality Ease of maintenance Coupling Number of packages a package uses something from (should be small) : de/jwamx/handling/desktop 60: de/jwamalpha/handling/collection Frequency Number of packages a package uses something from 14

15 Trend Data for 3 System Releases data 20000from analysis of requirements documents version history attributes methods classes files pakages V.1.6 V.1.8 V

16 Trend Data for 2 Classes 9 BasicTraceObserver DialerServer NoPubM effcbo kwmc NoP NoPubA NoPubM outcbo kwmc NoP NoPubA

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

30 abgeleiteten Klassen Vererbung gering genutzt geringe Tiefe, extreme Breite

18 3D Graph Vererbung Untersuchtes System Anderes System CH QAR Nur 8 Klassen vererben, 2 Klassen haben 250 bzw. 30 abgeleiteten Klassen Vererbung gering genutzt geringe Tiefe, extreme Breite Risiken: Chance, Ähnlichkeitsbeziehungen aus Problembereich im Code auszudrücken wenig genutzt Dadurch erschwertes Verständnis 18

19 Metapher: Stadt/Landschaft 19

20 Diagnoses & Recommendations (two examples from analysis of JWAM 1.4) Lines of Code: The file HtmlStandardWriter seems too large (1277 LOC). agreement novelty Number of public Attributes: The class ConfigurationStandard contains 18 public attributes. Because they are used only by methods of this class the visibility should be reduced to protected at least. The same should be applied to class ClassUseMapper. agreement novelty

21 Evaluation of our results: JWAM 1.4: 27 diagnoses 28 recommendations strong accept (++) weak accept(+) Indifferent (0) weak reject (-) strong reject (--) the most relevant critical situations got repaired in JWAM 1.5 JWAM 1.5: 36 diagnoses 32 recommendations

22 Parser IDE Xrefscope CASE- Tool CM- System Runtime data Information extractors IDE/CASE interaction R e p o s i - t o r y ( R D Query B developer ) Architecture scope Query scope Analysedaten Metrics scope Graph visualizer Szenario 1: Initiales Q-Assessment Q-Ziele Q-Ziele Q-Bericht QS/Management SW-Entwickler Q-Modell Q-Assessor Quellcode Analysewerkzeuge 22

Parser IDE Xrefscope CASE- Tool CM- System Runtime data Information extractors IDE/CASE interaction R e p o s i - t o r y ( R D Query B developer ) Architecture scope Query scope

23 Parser IDE Xrefscope CASE- Tool CM- System Runtime data Information extractors IDE/CASE interaction R e p o s i - t o r y ( R D Query B developer ) Architecture scope Query scope Analysedaten Metrics scope Graph visualizer Szenario 2: Review-Unterstützung Q-Ziele Q-Bericht QS/Management SW-Entwickler Richtlinien Q-Modell Q-Assessor Quellcode Analysewerkzeuge 23

Ähnliche Dokumente

Software-Qualität sichtbar machen

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 Software Qualität