Verwendung von objektorientierten Metriken zur Softwarequalitätsvorhersage. Arno Egger,

Transkript

1 Verwendung von objektorientierten Metriken zur Softwarequalitätsvorhersage Arno Egger,

2 Metriken in OO-Programmierung Traditionelle Metriken (Cyclomatic Complexity, Lines Of Code etc.) auf OO-Methoden anwendbar, aber: zusätzliche Metriken zur Erfassung OO-spezifischer struktureller Aspekte (z.b. Klassen, Polymorphie, Vererbung) + darauf basierender Annahmen (z.b. Ermittlung der Systemgesamtkomplexität aus Komponentenkomplexitäten) erforderlich Mehrere OO-Metriksuiten (Sammlungen von Metriken) verfügbar, z.b. CK, MOOD, Lorenz and Kidd -> im Folgenden Behandlung der CK-Suite.

3 Metriken in OO-Programmierung Name der Metrik Abkürzung Art der Metrik Anwendung auf TRADITIONELL Cyclomatic Complexity Lines of Code Comment Percentage CC SIZE COM Traditionell Traditionell Traditionell Methoden Methoden Methoden CHIDAMBER-KEMERER OO Weighted Methods per Class Response for a Class Lack of Cohesion of Methods Coupling between Objects Depth of Inheritance Tree Number of Children WMC RFC LCOM CBO DIT NOC Objektorientiert Objektorientiert Objektorientiert Objektorientiert Objektorientiert Objektorientiert Klasse/Methode Klasse/Nachricht Klasse/Kohäsion Obj.-Kopplung Vererbung Vererbung

4 Chidamber-Kemerer Metriksuite 1994 mit dem Ziel entwickelt, ein Set von Metriken zu finden, das auf fundierter theoretischer Basis (Mario Bunge Ontologie) analytisch in Hinblick auf vorher festgelegte Messprinzipien weder zu abstrakt noch zu plattformspezifisch ohne übermäßigen Aufwand in der Sammlung der Daten die Qualitätsevaluierung objektorientierten Softwarecodes ermöglicht. Sechs Designmetriken für jede Klasse: WMC Weighted Methods per Class DIT Depth of Inheritance Tree NOC Number of Children RFC Response for a Class CBO... Coupling between Object Classes LCOM Lack of Cohesion in Methods

5 Fallbeispiel: Handelssystem Beispielsystem Trader besteht aus der Superklasse Trade und den davon abgeleiteten Subklassen Equity Trade, FX Trade sowie Bond Trade. Zusammenfassung der Metriken unten, Pseudocode siehe nächste zwei Seiten.

6 Fallbeispiel: Handelssystem

7 Fallbeispiel: Handelssystem

8 WMC: Weighted Methods per Class Klasse: Vorlage zur Erzeugung konkreter Objekte Methode: Operation an einem Objekt WMC zählt die in einer Klasse enthaltenen Methoden oder (schwieriger zu implementieren) misst deren Komplexität sagt Entwicklungs- & Wartungsaufwand der Klasse voraus Klassen, die viele Methoden enthalten sind oft applikationsspezifisch, d.h. schlechte Wiederverwendbarkeit evaluiert Usability & Reusability

9 WMC Fallbeispiel: Handelssystem WMC = Anzahl der Methoden in einer Klasse Trade besitzt drei Methoden, daher WMC für Trade = 3 Bond und FX besitzen eine Methode, Equity zwei

10 DIT: Depth of Inheritance Tree Inheritance: Vererbung, ermöglicht die Wiederverwendung von bereits erstellten Objekten inklusive Variablen und Operatoren. DIT maximale Länge des Pfades von einem Klassenelement zur Wurzel des Klassenbaums, gemessen an der Zahl der Vater/Mutterklassen je tiefer in der Hierarchie, desto mehr Methoden üblicherweise von anderen Klassen geerbt, desto komplexer und schlechter vorhersehbar das Verhalten der Klasse Hohe Hierarchietiefe ist normalerweise auch Indikator für hohen Grad der Codewiederverwendung evaluiert Testbarkeit, Codeverständlichkeit und Reusability

11 DIT Fallbeispiel: Handelssystem DIT = Länge des maximalen Pfads von der Klasse zur Hierarchiewurzel Trade ist die oberste Klasse der Hierarchie, d.h. DIT für Trade=0 DIT für die Subklassen von Trade = 1

12 NOC: Number of Children NOC Anzahl der unmittelbar einer Klasse unterstellten Unterklassen Indikator des potenziellen Einflusses, den die Klasse auf das Gesamtsystem haben kann je größer die Anzahl der Subklassen, desto größer die Wahrscheinlichkeit einer fehlerhaft bzw. zu generell abstrahierten Elternklasse je größer die Anzahl der Subklassen, desto größer Code-Reuse große Kinderzahl erhöht durch großen Testaufwand die Testzeit evaluiert Testbarkeit und Design

13 NOC Fallbeispiel: Handelssystem NOC = Anzahl unmittelbarer Subklassen zu Trade gehören drei Subklassen, NOC ist somit 3 Equity, FX und Bond besitzen keine Subklassen

14 RFC: Response for a Class Nachricht: Anfrage eines Objektes an ein anderes Objekt zur Ausführung einer Operation. Die Operation, die als Antwort darauf ausgeführt wird, ist eine Methode. RFC Kardinalität (Größenordnung) des Sets aller Methoden, die als Antwort auf aus anderen Klassen oder Methoden kommenden Nachrichten ausgeführt werden können misst Klassenkomplexität als Kombination von Methodenanzahl und Umfang der Kommunikation mit anderen Klassen Testaufwand steigt mit Anzahl aufrufbarer Methoden erheblich evaluiert Design, Usability, Testbarkeit

15 RFC Fallbeispiel: Handelssystem RFC = Kardinalität der Methoden, die als Antwort auf eine Nachricht ausgeführt werden können Eingehende Nachrichten können bei Trade vier verschiedene Methoden auslösen (drei interne, und die in position_update aufgerufene externe), d.h. RFC für Trade = 4

16 CBO: Coupling Between Object Classes Kopplung: Stärke der Assoziation zwischen zwei Entitäten z.b. durch Austausch von Nachrichten zwischen zwei Objekten, Verwendung der Methode einer Klasse durch eine andere, Vererbung. CBO zählt Anzahl der anderen (nicht geerbten) Klassen, mit denen eine Klasse gekoppelt ist exzessive Kopplung widerspricht modularem Aufbau, reduziert durch Abhängigkeiten der Klasse deren externe Wiederverwendbarkeit starke Kopplung erhöht Sensitivität gegenüber Änderungen in anderen Programmteilen, macht Code schwer überblickbar evaluiert Design und Reusability

17 CBO Fallbeispiel: Handelssystem CBO = Kopplung mit anderen Klassen (Aufrufe von Methoden oder Instanzvariablen anderer Klassen) Die Klasse Trade verwendet eine Methode der position_manager- Klasse, CBO ist somit 1.

18 LCOM: Lack of Cohesion in Methods Kohäsion: Grad, zu dem Methoden innerhalb einer Klasse miteinander verbunden sind und zusammenarbeiten. LCOM misst die Ähnlichkeit von Methoden anhand der von Ihnen verwendeten Attribute und Variablen entweder durch Ermittlung, wie viele Prozent der Methoden jedes Datenfeld der Klasse verwenden oder durch Vergleich der eingesetzten Attribute hohe Kohäsion signalisiert gute Klassenunterteilung niedrige Kohäsion erhöht Komplexität und Fehleranfälligkeit Klassen mit niedriger Kohäsion erlangen durch Aufspaltung in mehrere Klassen möglicherweise bessere Kohäsionswerte evaluiert Design und Reusability

19 LCOM Fallbeispiel: Handelssystem LCOM = Anzahl der Methodenpaare ohne gemeinsame Instanzvariable minus Methodenpaare mit gemeinsamer Instanzvariable hier 1, weil die Klasse Trade drei Methoden (3) hat, also drei Methodenpaare möglich sind, zwei davon auf keine gemeinsame Variable zugreifen (2), ein Paar (get_trade & pos_update) sich jedoch auf die gemeinsame Variable trade_id bezieht (2-1)

20 Studie 1: Validität der CK-Metriken Hypothese: CK Metriken zur Messung von Designkomplexität geeignet Folgerung: Metrikwerte müssen in engem Zusammenhang mit resultierender Softwarekomplexität, -produktivität, -verwendbarkeit und -wartbarkeit stehen Überprüfung der Hypothese anhand der Analyse dreier kommerzieller Softwaresysteme der European Bank ISD Ergebnis: Metriken NOC und DIT unerheblich (minimaler Einsatz von Vererbung); WMC, RFC und CBO hochgradig korreliert (>0.8), gemeinsame Verwendung in Regressionsanalyse somit problematisch deshalb Konzentration auf hohe Korrelation mit abhängiger Managementgröße in Einzelbereichen: z.b. Produktivität, Nachbearbeitungsaufwand, Designaufwand

21 Studie 1: Produktivität Produktivität = SIZE (Codegröße) / EFFORT (Arbeitsstunden) Untersuchung: Inwiefern erklären OO Metriken Produktivitätsunterschiede in OO-Programmen besser als traditionelle Metriken? Einführung von Dummy-Variablen zur Ausschaltung gerade nicht relevanter Metriken: HICBO und HILCOM, werden Eins oder Null bei Überschreiten von Metrikschwellenwerten Schrittweise Regression führt zum Ergebnis: Produktivität mit hohen CBO oder LCOM-Werten stark negativ korreliert. Entwickler benötigen daher für stark gegenseitig verknüpfte (CBO) und inkohärente (LCOM) Klassen mehr Programmier- und Testzeit (siehe Formel unten)

22 Studie 1: Nachbearbeitungsaufwand Wiederverwendbarkeit von Code bedeutender Vorteil der objektorientierten Programmierung Niedriger Nachbearbeitungsaufwand erwünscht, d.h. Klassen sollen möglichst unverändert in neue Projekte übernehmbar sein Aufwand bei einem der 3 Systeme empirisch ermittelt & analysiert Ergebnis: hohe CBO und LCOM-Werte stehen für höheren Nachbearbeitungsaufwand, STAFF (Leistungsunterschiede beim Programmierer) und SIZE (Codegröße) aber nicht mehr signifikant

23 Studie 1: Designaufwand ermittelt an einem System, an dem der Code selbst noch nicht implementiert war, erst die Klassen spezifiziert somit keine SIZE- und STAFF-Informationen verfügbar (Code erst grob entworfen, Anzahl der Zeilen noch unbekannt) Wie bei Nachbearbeitungsaufwand hohes CBO + LCOM = Vorhersage für arbeitsaufwändige Implementierung Zusammenfassung: Metriken auf Systemen mit verschiedenen Programmiersprachen und selbst bei noch nicht implementierten Klassen sinnvoll ermittelbar DIT und NOC bei keiner der Untersuchungen relevant WMC, CBO und RFC hochgradig korreliert Hohes Coupling (CBO) und fehlende Kohäsion (LCOM) resultieren in ineffizientem Code

24 Studie 2: Metriken als Qualitätsindikatoren Empirische Analyse der CK OO-Metriken hinsichtlich ihrer Fähigkeit zur Fehlerwahrscheinlichkeitsvorhersage Hypothesen: H-WMC: hohe Funktionszahl -> komplex, fehleranfällig H-DIT: tiefe Hierarchien -> Integritäts- und Vererbungsfehler H-NOC: Kinderreiche Klassen testintensiv & schwer modifizierbar H-CBO: Von anderen abhängige Klassen fehleranfälliger H-RFC: Funktionsvielfalt erzeugt Komplexität und Fehler H-LCOM: Niedrige Kohäsion resultiert aus Designfehlern

25 Studie 2: Datensammlung & Analyse Viermonatige empirische Studie mit Studententeams der University of Maryland, OO-Analyse und Design Jedes Team entwickelt eigenes Management- Informationssystem anhand des Wasserfallmodells, testet diese auf Fehler und vermerkt gefundene (Report) Expertenevaluierung der resultierenden Systeme+Reports, Anwendung der CK-Metriken auf Quellcode; Vergleich der von den Metriken vorhergesagten Fehlerraten mit den tatsächlich aufgetretenen (Wahrscheinlichkeitsverteilung, Regressionsanalyse,

26 Studie 2: Ergebnisse Eindimensionale Analyse (einzelne Metriken) WMC, DIT, RFC, CBO signifikant, Hypothese soweit bestätigt Number of Childen hochsignifikant, aber hier Hyp. widerlegt: je höher die NOC, desto niedriger die Wahrscheinlichkeit eines Fehlers. Vermuteter Grund: hohes Coderecycling bedeutet viel Vererbung, somit viele Subklassen, positive Auswirkung des bereits erprobten Codes überwiegt ggü. Komplexitätszunahme LCOM nirgends signifikant Mehrdimensionale Analyse (mehrere Metriken simultan) Fehlerhäufigkeitsvorhersagen der OO-Metriken treffen zu OO-Metriken bei OO-Code besser als klassische M. geeignet

27 Weiterführende Literatur Lanza/Marinescu: Object-Oriented Metrics in Practice: Using Software Metrics to characterize, evaluate and improve the Design of Object-Oriented Systems. Springer, New York, Henderson-Sellers, Brian: Object-Oriented Metrics. Measures of Complexity. Prentice Hall, New Jersey 1996 Lorenz/Kidd: Object-Oriented Software Metrics. Prentice Hall, New Jersey Shaw/Garlan: Software Architecture. Perspectives on an Emerging Discipline. Prentice Hall, New Jersey, 1996.

28 Weiterführende Literatur Chidamber/Kemerer: A Metrics Suite for Object Oriented Design. MIT Sloan School of Management, Massachusetts Chidamber/Darcy/Kemerer: Managerial Use of Metrics for Object- Oriented Software. IEEE Transactions on Software Engineering, Vol. 24 No. 8, August Basili/Briand/Melo: A Validation of Object-Oriented Design Metrics as Quality Indicators. IEEE Transactions on Software Engineering, Vol. 22 No. 10, October Marinescu: Measurement and Quality in Object-Oriented Design. Proceedings of the 21st IEEE International Conference on Software Maintenance (ICSM 2005), IEEE Computer Society Press,2005