OO-Metriken

Dies ist eine grobe Zusammenfassung des Buchs: Object-Oriented-Software-Metrics von Mark Lorenz und Jeff Kidd.Verlag Prentice Hall ISBN: 0-13-179292-X Preis: ca. 80 DM

OO-Metriken ist der Versuch, Softwarequalität zu messen. Es wird zwischen Projekt und Designmetriken unterschieden.

Projektmetriken messen, wie weit ein Softwareprojekt fortgeschritten ist; und ob der Ressourceneinsatz

(Geld, Zeit, Zahl der Entwickler) optimal ist. Typische Projektmetiiken sind:

Projektmetriken dienen der Planung, können aber auch zur Leistungskontrolle der Entwickler benutzt werden, und sind deshalb umstritten.

Designmetriken analysieren den SourceCode, und messen die Qualität des Designs:

In der unteren Tabelle sind die wichtigsten Design-Meriken aufgelistet.

Dabei bedeutet ++ dass die Metrik empfohlen wird,

und * kennzeichnet, dass diese Metrik für entsprechende Qualitätskriterium angewendet werden kann.

 

Model Quality

Class Quality

Method Quality

Management

Method Size

       

Number of message sends

   

++

 

Lines of code

   

*

 

Method Internals

       

Method complexity

   

++

 

Strings of message sends

   

*

 

Class Size

       

Number of public instance methods

 

++

 

++

Number of instance methods

 

++

   

Number of instance variables

 

++

   

Number of class methods

 

++

   

Number of class variables

 

*

   

Class Inheritance

       

Hierarchy nesting level

++

     

Multiple inheritance

++

     

Method Inheritance

       

Number of methods overridden

 

++

   

Number of methods inherited

 

*

   

Number of methods added

 

*

   

Specialization index

 

++

   

Class Internals

       

Class cohesion

 

*

   

Global usage

++

     

Instance variable usage

 

*

   

 

 

 

 

 

 

 

 

 

 

 

Model Quality

Class Quality

Method Quality

Management

Method Size

       

Parameters per method

 

*

   

Friend functions

++

*

   

Function-oriented code

++

 

*

 

Comment lines per method

 

*

   

Percentage of commented methods

++

++

   

Problem reports per class

 

++

 

++

Class Externals

       

Class coupling

 

*

   

Class reuse

 

++

 

++

Number of classes thrown away

     

*

Number of collaborations

 

*

   

Subsystem Coupling

       

Intersubsystem relationships

++

     

Interclass relationships

*

     

 

Unsauberheit im Objektmodel können durch folgende Metiken erkannt werden:

Da Änderungen an einer Oberklasse sich auf allen Unterklassen auswirken, sollten die Vererbungstiefe nicht zu hoch sein.

Verwendung vieler globaler Variablen weissen auf ein schlechtes Objektmodel hin

Wenig Kommentare deuten auf schlechte Wartbarkeit des Modellís hin. (Hinweis: Im Gegensatz zu den Autoren des Buchs, bin ich der Meinung; dass ein gutes Objektmodell die Kommentierung von Methoden weitgehend überflüssig macht. Bedingung ist, daß die Methoden kurz sind und aussagekräfitge Namen beinhalten.

In einem guten objektorientierten Design, werden Klassen in Untersystemen (Module, Applikationen) eingeteilt, die i.a. hierarchisch angeordnet sind.(Beispiel ist Einteilung zwischen UIKlassen, DomainKlassen, PersistenzKlassen). Die Klassen in einem Untersystem sollten ausser miteinander, nur mit Klassen weniger anderere Untersysteme (die eine Hierarchiestufe tiefer liegen) kommunizieren. (Beispiel: UIKlassen sollten nicht direkt mit PersistenzKlassen zusammenarbeiten).

Unsauberheiten bei Klassen koennen duch folgende Metriken erkannt werden:

Zuviele Methoden, deuten darauf hin, da ß eine Klasse zu viel Verantwortung hat.

Zuviele Instanzvariablen deuten darauf hin, dass diese mit zu vielen anderen Klassen zusammenarbeiten, und dadurch schwer wiederzuverwenden sind.

Eine zu hohe Zahl von Klassenmethoden kennzeichnen, daß Methoden die auf Klassenseite implementiert sind, weitgehend auf Instanzenseite implementiert werden können.

Überschreibt eine Klasse mehrere Methode seiner Oberklassen, so deutet dies darauf hin, daß die Unterklassenbeziehung nicht sinnvoll ist. Es ist darauf zu achten ob die Methode der Oberklasse nur ergaenzt

(in Smalltalk geschieht dies mit super) oder wirklich überschrieben wird..

Er ist folgendermassen definiert: Zahl der überschiebenen Methoden * Vererbungstiefe / Gesamtanzahl der Methoden.

Der Spezialisierungsindex sollte niedrig sein. Ansonsten deutet dies auf einen Fehler in der Klassen-/Unterklassenbeziehung hien

Gibt Hinweis auf die Wartbarkeit des Softwaresystems. (Meine eigene Meinung: Man sollte Namen und Design so wählen, dass Methodenkommentare weitgehend überflüssig sind)

Treten Fehler immer in derselben Klasse auf, so sollte ein "ReDesign" dieser Klasse gemacht werden

Je öfter eine Klasse gebraucht wird, desto wertvoller ist die Klasse

Unsauberheiten bei den Methoden werden durch folgende Metriken erkannt:

Methoden sollten möglichst kurz sein. Sehr lange Methoden deuten darauf hin, daß hier nicht objektorientiert programmiert wurde.

Gesendete Methoden, temporäre Variable, Zuweisung, Schleifen, Bedingungen , Verwendung von primitiven oder Schnittstellen zu LegacySoftware werden verschieden gewichtet. Die Methodenkomplexität sollte möglichst gering sein.

Fehler im Management können durch folgende Metriken erkannt werden:

Die Schnittstellen sollten möglichst einfach gehalten werden, und gering sein.

Geringe Wiederverwendung deutet auf schlechte Managementunterstützung hin.

Klassen die sehr fehleranfällig sind, sind Kandidaten für "ReDesign"

Umgang mit Software-Metriken:

Das Resultat der Software-Metriken sind Zahlen, mit die zumindest für einen Anfänger nicht aussagekräftig sind. Sinnvolle Werte sind abhängig von der Programmiersprache, der Komplexität des Softwareprojekts,

und Art der Klasse. So sind Methoden in C++ i.a. laenger als in Smalltalk; die Anzahl von Instanzvariablen

bei Domain-Klassen geringer als bei UIKlassen, und bei komplexen Softwareprojekten ist die Vererbungstiefe naturgemäß größer.

Den hier vorgestellten Metriken, benötigen lediglich eine statische Analyse des Sourcecodes. Sehr viel aussagekräftigere Metriken können durch Analyse zur Laufzeit ermittelt werden.

Ein Metriksystem sollte folgende Eigenschaften besitzen:

 

 

 

 

 

 

 

 

 

Vor- und Nachteile von OO-Metriken:

( aus Lehrbuch der Software Technik Band II, Kapitel 6.4 , von Helmut Balzert, Spektrum der Wissenschaft

ISBN 3-8274-0065-1

Vorteile:

Nachteile: