Katalog von objektorientierten Qualitätsmassen
Geschwurbel von Daniel Schwamm (03.08.1994)
Inhalt
SW-Metriken sollen helfen, möglichst frühzeitig im
SW-Lebenszyklus (objektive) Bewertungen der SQ-Qualität vorzunehmen, um
später die teuren Wartungsaufwände einschränken zu können.
Anzumerken ist, dass die Aussagen der Metriken nicht zu weitreichenden
Folgen führen dürfen, denn ihre Aussagekraft ist beschränkt. So
variieren die gemessenen Ausmasse in ihrer Bedeutung für den
Anwender, von vielen wichtigen, aber schwer quantifizierbaren Faktoren (z.B.
Erfahrungsgrad der Entwickler) wird abstrahiert, die Metriken können z.T.
erst spät im Lebenszyklus zum Einsatz gebracht werden, und es gibt
aufgrund des Mehraufwands durch die Metriken erhebliche Akzeptanzprobleme was
ihren Gebrauch angeht. Für die praktische Anwendbarkeit der Metriken gilt,
dass sie sein sollten:
-
Einfach
-
Automatisierbar
-
Aussagekräftig bzgl. der Konsequenzen.
-
Früh einsetzbar im SW-Lebenszyklus.
-
Objekt- und Klassenversionen erlauben.
Im folgenden sind einige Metriken aufgeführt, die
für die Entwicklung speziell objektorientierter SW herangezogen werden
können, d.h. sie berücksichtigen i.d.R. insbesondere die OOA- und
OOD-Phasen und sind auf Langfristigkeit ausgelegt.
-
Gewichtete Attribute pro Klasse:
-
Aufbau: Summe der gewichteten Attribute einer Klasse.
-
Aussage: Komplexitätsmass. Einflüsse
auf abgeleitete Klassen, die die Attribute erben. Je grösser Metrik,
desto grösser Spezialität, desto kleiner Reuse-Nutzen.
-
Kritik: Nur public-Attribute relevant? Gewichtung
abhängig vom Datentyp? Kein Richtmass möglich ==> nur
Vergleichsmass. Früh einsetzbar (bei Gewichtungsfaktor=1).
-
Gewichtete Methoden pro Klasse:
-
Aufbau: Summe der gewichteten Methoden einer Klasse.
-
Aussage: Komplexitätsmass. Einflüsse
auf abgeleitete Klassen, die die Methoden erben. Je grösser Metrik,
desto grösser Spezialität, desto kleiner Reuse-Nutzen.
-
Kritik: Nur public-Methoden relevant? Gewichtung
abhängig von den LOC? Kein Richtmass möglich ==> nur
Vergleichsmass. Früh einsetzbar (bei Gewichtung=1).
-
Tiefe einer Vererbungsstruktur:
-
Aufbau: Anzahl der Basisklassen bei
Nicht-Mehrfacher-Vererbung (Wurzel=0).
-
Aussage: Komplexitätsmass. Zeigt auf,
inwieweit die Klasse von anderen Klassen beeinflusst wird.
-
Kritik: Ein Richtmass lässt sich wegen
der menschlichen Kapazitätsbeschränkung auf 7+/-2 festlegen.
Früh einsetzbar.
-
Anzahl abgeleiteter Klassen:
-
Aufbau: Anzahl der Klassen, die Eigenschaften werben.
-
Aussage: Einfluss im Gesamtsystem.
Rückschlüsse auf Test- und Wartungsaufwand möglich.
-
Kritik: Verbalisierte Richtwerte möglich ("Wegen
Reuse lieber breit, als tief ableiten!"). Abstrahiert von der Objekte-Anzahl und
den Verbindungsnachrichten, die auch Einfluss auf das system haben.
-
Nicht-vererbungsbedingte Beziehungen:
-
Aufbau: Zahl aller Beziehungen, Aggregationen und
Nachtrichten-Verbindungen.
-
Aussage: Coupling-Grad bezüglich stabiler und dynamischer
Verbindungen. Die Unabhängigkeit gibt Reuse-Nutzung an. Hohes Coupling
lässt auf kontextspezifische Nutzung schliessen.
-
Kritik: Kardinalitäten zu berücksichtigen?
Gleichgewichtung der Beziehungstypen? Hohe Kommunikation kann dem System
dienlich sein, wird hier aber negativ interpretiert.
-
Antwortmenge einer Klasse:
-
Aufbau: Anzahl der Methoden, die für andere
Klassen Aussagen führen.
-
Aussage: Coupling-Grad. Rückschlüsse auf
Schwierigkeitsgrad einer Klasse.
-
Kritik: Objektversion denkbar.
-
Informationsfluss-Mass:
-
Aufbau: Misst Fan-in (Anzahl Klassen, die Klasse
nutzen können) und Fan-out (Anzahl der benutzten Klassen).
-
Aussage: Coupling-Mass (Grad der
äusseren Verflechtung). Hoher Informationsfluss bedeutet zu
viele integrierte Aufgaben bzw. eine zu niedrige Datenkapselung der Klasse.
Internes/strukturelles Produktmass.
-
Kritik: Fan in und Fan out nicht gleichwertig zu
bewerten.
-
Fehlender innerer Zusammenhang:
-
Aufbau: Nutzung der inneren Methoden der inneren
Attribute.
-
Aussage: Kohäsionsgrad. Zeigt auf, ob der Grad
der Aufteilung bzw. Zusammenfassung nicht gross genug ist. Internes
Produktmass.
-
Kritik: Einsatz erst nach der Methoden-Spezifikation
möglich Richtwert ist 1 ==> wenn >1, dann Zerkleinerung anzuraten.
-
Isolationsfaktor:
-
Aufbau: Messung der Benutzung der Klasse durch andere.
-
Aussage: Coupling-Grad. Selbstständigkeit einer
Klasse. Strukturelles Mass.
-
Kritik: Idealwert ist 1 ==> wenn <1, dann
kontextabhängige Integration zu gross.
-
Systemgrösse:
-
Aufbau: Summe der Grösse aller Klassen.
-
Aussage: Komplexitätsgrad des Systems.
Strukturelles Mass.
-
Kritik: System mehr als die Summe seiner Teile.
Gerade die Beziehungen und Vererbungen, die hier nicht gemessen werden, machen
Komplexität v.a. aus.
-
Rentabilitätsquotient:
-
Aufbau: Ersparnis durch Reuse geteilt durch Kosten
durch Reuse.
-
Aussage: Kostenersparnis von Projekten durch Reuse. Prozess-Mass.
-
Kritik: Nicht alle Grössen quantifizierbar.
Zeitpunkt der Bewertung wichtig (wegen langfristiger Wirkung des Reuse).
Suchaufwand nicht konstant, hiervon wird aber abstrahiert. Gute
Motivationsbasis.