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:

• Durchchnittliche Entwicklungszeit von Klassen (Unterschieden nach Art der Klasse z.B UIKlassen, DomainKlassen).
• Anzahl der entwickelten (Domain-) Klassen, Applikationen.

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.

• Vererbungstiefe ( Class hierarchy nesting level)

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

• Verwendung globaler Variablen (Global Usage)

Verwendung vieler globaler Variablen weissen auf ein schlechtes Objektmodel hin

• Prozentsatz kommentierter Methoden (Percentage of commented methods)

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.

• Beziehungen zwischen Untersystemen (Intersubsystems relationships)

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).

• Zahl der Instanzenmethoden

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

• Zahl der Instanzvariablen

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

• Zahl der Klassenmethoden

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

• Zahl der überschriebene Methoden

Ü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..

• Spezialisierungs Index

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

• Prozentsatz der kommentierten Methoden

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

• Zahl der Fehlerprotokolle pro Klasse

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

• Klassen wiederverwendbarkeit (Class reuse)

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

• Zahl der gesendeten Methoden

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

• MethodenKomplexität

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.

• Zahl der öffentlichen Instanzmethoden

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

• Wiederverwendung von Klassen

Geringe Wiederverwendung deutet auf schlechte Managementunterstützung hin.

• Zahl der Fehlerprotokolle pro Klasse

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

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:

• Der Benutzer soll selbst die Werte eingeben können., in der die Meßergebnisse noch als sinnvoll anzusehen sind.
• Flexible Auswahl mit welchen Metriken gemessen werden soll.
• Ausgabe der Auswertung auf Bildschirm und Dateien
• Flexible Auswertung soll Suche nach bestimmten Anomalien suchen.

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

ISBN 3-8274-0065-1

• Die Metriken vermitteln ein Gefühl für die vielfältigen Faktoren, die die Komplexität eines Systems und die Komplexität zwischen Systemkomponenten bestimmen.
• Die objektorientierten Metriken zeigen deutlich die Unterschiede zu traditionellen Systemen auf.
• Die Metriken geben Hilfestellung bei der Qualitätsicherung von Systemen.

• Es ist problematisch, die Gesamtkomplexität eines Systems durch einen Wert zu Charakterisieren.
• Es werden in der Regel nur einfache Sachverhalte gezählt. Der empirische Nachweis, daß damit bestimmte Qualitätsmerkmale gemessen werden, ist in der Regel (noch) nicht erbracht.
• Viele Metriken sind schlecht definiert und meßtheoretisch unzureichend spezifiziert
• Mögliche Metriken für die objektorientierte Analyse und den objektorientierten Entwurf fehlen noch (z.B. Assoziationen, Aggregationen).