Seminar in Software Engineering und Software-Qualitätsmanagement Thema: Messen und Prüfen von Software
Maße für Objekt Orientierte Software
Von Andrea F. Realini arealini@access.unizh.ch
Prof. Dr. M. Glinz Betreuer: C.Seybold
18.12.2001
Abstract
Nowadays quality plays a central role in the development of software. Managers and software developers are focusing their efforts to increase quality and reduce costs.
Metrics give the opportunity to have an objective validation of projects and design.
This paper presents a suite of metrics specially developed for object-oriented programming. They are divided in metrics for projects and metrics for OO design-phase.
Project metrics give a datum point for managers and are less formal presented than design metrics.
OO design-metrics are an instrument to “measure” software quality, and for Basili [1] they are
indicators for fault-proneness of a class. These metrics give us the opportunity to find design problems in the early stage of development, avoiding high costs, that we had sustained in order to fix software- errors in the test-phase. For every metric I’ll give a formal demonstration of its validity.
This paper is entirely written in German, but for sake of simplicity I conserved the name of each metric in English.
Inhaltverzeichnis
1 Einführung 5
2 Maße für Projekte 6
2.1 Application Size 6
2.1.1 Number of Scenario Scripts (NSS) 6
2.1.2 Number of Key Classes (NKC) 7
2.1.3 Number of Support Classes (NSC) 7
2.1.4 Average Number of Support Classes per Key 7
2.1.5 Number of Subsystems (NOS) 8
2.2 Staffing Size 8
2.2.1 Average Person-Days per Class (PDC) 8 2.2.2 Average Number of Classes per Developer (CPD) 9
2.3 Scheduling 9
2.3.1 Number of Major Iterations (NMI) 9
2.3.2 Number of Contracts Completed (NCC) 9
2.4 Abhängigkeiten zwischen Maße für Projekte 10
3 Maße für Object Oriented Design (OOD) 11
3.1 Theorie der OOD Maße 11
3.1.1 Design-Theorie von Booch 11
3.1.2 Arbeitsverfahren von CK 12
3.2 Maße für OOD 13
3.2.1 Weighted Methods per Class (WMC, Complexity Metric) 13 3.2.2 Depth of Inheritance Tree (DIT, Inheritance Metric) 14 3.2.3 Number of Children (NOC, Inheritance Metric) 15 3.2.4 Coupling beetwen Object Classes (CBO, Coupling Metric) 15 3.2.5 Response for a Class (RFC, Coupling Metric) 15 3.2.6 Lack of Cohesion in Methods (LCOM, Cohesion Metric) 16
3.2.7 Formale Evaluation der Maße 17
3.3 Maße für OOD als Qualitätsindikatoren 18
3.3.1 CK-Maße als Fehlerindikatoren 18
3.3.2 Kritik am Basili-Modell 20
4 Schlusswort 21
5 Literatur 22
1 Einführung
“Ein Maß1 ordnet mit Hilfe eines Messverfahrens einer Menge von Gegenständen Messwerte
auf einer Skala zu. Die Messwerte machen eine Aussage über das zu messende Merkmal der gemessenen Gegenstände. Dabei müssen die Menge der Merkmalswerte und die Skala struktur-ähnlich sein, das heißt, die Eigenschaften der Skala müssen mit denen des Merkmals übereinstimmen” [7].
Die Softwarequalität ist im IT-Bereich immer mehr von Bedeutung. Um die Konkurrenz zu schlagen, müssen die Firmen und deren Produkte immer zuverlässiger werden und Manager müssen mehr als früher auf die Qualität der Produkte achten. Die Maße für Sofware können eine objektive Beurteilung der Softwarequalität geben.
Ich möchte zwei Gruppe von Maßen hier vorstellen: Maße für Projekte und Maße für OO Design.
Die Maße von Projekten werden hier nur generell gezeigt und mit einer einfachen Notation, weil sie von Lorenz und Kidd [8] mehr für Manager gedacht sind.
Die Maße für OO Design, die von Chidamer und Kemerer (CK) [4] am Anfang studiert wurden, möchte ich mehr im Detail erklären. Ich werde mit einer Einführung über die Verfahren beginnen, die von CK benutzt wurden, um diese Maße zu beweisen. Nachher werde ich auf eine Studie von Basili [1], wo die Maße von CK als Qualitätsindikatoren behandelt werden, eingehen. Am Schluss dieser Arbeit werde ich die Kritik an der Methode von Basili erwähnen, die von El Emam et al. angezeigt wurde [5].
Die Maße die von CK studiert wurden, sind noch nicht als Standard akzeptiert worden; sie werden aber von vielen Programmierern als Referenz für ihre Arbeit in Anspruch genommen.
1 Maß = Metrik
2 Maße für Projekte
Maße für Projekte helfen Projektleitern Kosten und Aufwand zu schätzen, z.B. das benötige Personal.
Diese Maße können auch die Fortschritte messen, um den Entwicklungsstand eines bestimmten Zeitpunkt zu veranschaulichen.
Maße für Projekte werden meistens in der Planungsphase benutzt.
Diese Maßverfahren kommen aus einer Studie von Kidd und Lorenz [8]. Sie unterteilen die Maße in drei Hauptkriterien:
1 Application Size 2 Staffing Size 3 Scheduling
Jedes Kriterium ist noch in eine weitere Anzahl von Maßen unterteilt.
Im Gegensatz zu Maße für OO Design messen die Maße für Projekte die Qualität der Software nicht.
Diese Maße sind für die Schätzung des gesamten Projektes wichtig.
2.1 Application Size
Diese Maße bestimmen den Arbeitsumfang eines Projektes. Ziel dieser Maße ist es die zu erwartende Arbeit bzw. Arbeitsdauer zu messen.
2.1.1 Number of Scenario Scripts2(NSS)
Bild 2.1 Ein Scenario Script für ein Inventory Management (Quelle: [8])
2 Scenario Script bedeutet eine Sequenz von Schritten, die der Benutzer und das System tun, um eine Aufgabe auszuführen.
Initiator Action Participant
User request Item information on InventoryQueryWindow
InventoryQueryWindow sends item: aNumber to Inventory
Inventory ... ...
...
Im Bild 2.1 ist ein Beispiel von einem Scenario Script zu sehen. Ein Script wird für jede Hauptfunktion des Benutzers geschrieben.
NSS ergibt den Grosse der zu entwickelnde Applikation. NSS steht auch in Beziehung mit den Testfällen, die noch geschrieben werden müssen.
2.1.2 Number of Key Classes3 (NKC)
Schlüsselklassen (Key Classes) werden zu Beginn der Planungsphase schon bestimmt. Diese Maße entsprechen dem Aufwand der ganzen Arbeit.
NKC zählt, wie viele Klassen eine zentrale Rolle für ein Projekt spielen. Diese Bestimmung ist nicht endgültig. Eine Klasse, die als „Key“ in der Planungsphase definiert wurde, kann diese Eigenschaft in späteren Entwicklungsphasen verlieren.
Lorenz und Kidd [8] bestimmen die Key Classes anhand dieser drei Fragen:
1 Kann ich diese Applikation auch ohne diese Klasse einfach entwickeln?
2 Ist für den Kunden die Funktionalität diese Klasse wichtig?
3 Gibt es viele Szenarien, die durch diese Klasse verwirklicht werden?
Oft haben Key Classes einen Umfang von 30-40% des gesamten Projektes, die anderen Klassen werden als Support Classes bezeichnet [8].
2.1.3 Number of Support Classes (NSC)
Auch die Anzahl der Support Classes ist ein wichtiges Maß, um den Umfang eines Projektes zu bestimmen. Beispiele von Support Classes sind die GUI’s oder die „Helper“.
Support Classes können aber in der Planungspahse noch nicht bestimmt werden.
2.1.4 Average Number of Support Classes per Key Class
Bild 2.2 Average NSC per Key Class
3 Key Class ist eine Klasse, die notwendig für die Arbeitsweise einer Software ist.
Average NSC per Key Class = Σ NSC / Σ NKC
Wie schon oben erwähnt, bestimmen wir zuerst die Key Classes einer Applikation und in den weiteren Entwicklungsphasen planen wir auch die Support Classes.
Aus der Erfahrung mit anderen Projekten können wir anhand von Durchschnittswerten eine Schätzung machen, um die Gesamtzahl der Klassen, die wir brauchen, zu bestimmen.
Zum Beispiel: Wie haben ein Projekt, das 100 Key Classes umfasst. Die Average NSC per Key Class beträgt 2.5. Die Anzahl der Support Classes wird ungefähr (100 x 2.5) = 250 und die Gesamtanzahl der Klassen (100 + 250) = 350 sein.
2.1.5 Number of Subsystems (NOS)
„A subsystem is a collection of modules, some of which are visible to other subsystems and others which are hidden“ [2].
Ein Subsystem ist eine Menge von Klassen, die eine Reihe von Benutzerfunktionen unterstützen [8].
Wir können ein Projekt in weitere Subsysteme unterteilen und nebenläufige Arbeitsgruppen organisieren.
2.2 Staffing Size
Wie viele Mitarbeiter braucht man für dieses Projekt? Wie lange braucht man sie?
Diese Maße sind verantwortlich für die Bestimmung der Anzahl der Projektmitarbeiter.
2.2.1 Average Person-Days per Class (PDC)
Nachdem wir die Anzahl der Klassen geschätzt haben, können wir daraus die durchschnittliche Arbeitszeit bestimmen, die ein Mitarbeiter braucht, um eine Klasse zu programmieren.
Dieses Verfahren ist sehr abhängig von der Programmiersprache, z.B. C++ -Programme bestehen aus grösseren Klassen als Smalltalk. Smalltalk Programme sind u.a. einfacher wiederzuverwenden [8].
Wie die Bestimmung des Average Number of Support Classes per Key Classes ist auch dieses Verfahren von der Erfahrung des Projektleiters abhängig. Man braucht ein Referenzmaß, um das Average Person-Days per Class zu bestimmen.
Eine geeignete Grösse kann mit diesen Kriterien bestimmt werden:
q Abstract oder Konkrete Klasse
q Key oder Support Klasse
q „Mature“4 oder „Immature“ Klasse
q Programmierer-Umgebung
q Vorhandene Klassenbibliothek
2.2.2 Average Number of Classes per Developer (CPD)
Hier ist die Erfahrung des Programmierers sehr wichtig. Zum Beispiel kann ein Programmierer, der grössere Erfahrung hat, mehr Klassen „verwalten“ als ein Kollege mit kleinerer Erfahrung.
Die Faktoren zur Bestimmung einer geeigneten Grösse sind:
q Ist die Klasse aktiv entwickelt oder nur verwaltet?
q Erfahrungsniveau des Programmierers
q Die Gruppierung der Subsysteme
2.3 Scheduling
Diese Maße sind für die Zeitplanung eines Projektes verantwortlich.
2.3.1 Number of Major Iterations5 (NMI)
NMI bestimmt die Anzahl Iterationen eines Projektes. Dieses Maß ist für alle Projekte von signifikanter Bedeutung.
Lorenz und Kidd [8] empfehlen, eine Anzahl zwischen drei und sechs Iterationen pro Projekt zu verwenden.
2.3.2 Number of Contracts Completed6
Contracts sind ein gutes Maß für den Fortschritt der Funktionalität eines Programmes.
4 “Mature Class = a class that have existed and been reused long enough so that it no longer changes very often” [8]
5 Eine Iteration ist ein Zeitabschnitt der Softwareentwicklung, in dem ein vollständiges Teilergebnis mit betriebsfähiger Software erarbeitet und ausgeliefert wird [7].
6 “A contract is a simplifying abstraction of a group of related public responsibilities that are to be provided by subsystems and classes to their clients” [8]
2.4 Abhängigkeiten zwischen Maßen für Projekte
NSS NKC NSC NOS PDC CPD NMI NCC
Application Size
Number of Scenario Script (NSS) -
Number of Key Classes (NKC) - X
Number of Support Classes (NSC)
X -
Number of Subsystem (NOS) -
Staffing Size
Person-Days per Class (PDC) X - X
Class per Developer (CPD) X -
Scheduling
Number of Major Iterations (NMI)
-
Number of Contracts Completed (NCC)
-
X = Es existiert Abhängigkeiten zwischen den zwei Maßen
Bild 2.3 Abhängigkeiten zwischen Maßen für Projekte (Quelle: [8])
Jedes Maß ist nicht unabhängig und wird oft von einem anderen beeinflusst. Diese Tabelle zeigt die Abhängigkeiten zwischen den verschiedenen Maßen eines Projektes.
3 Maße für Object Oriented Design (OOD)
Software Maße stellen eine Methode dar, um Prozesse zu messen. Unser Ziel ist es, eine Gruppe von Maßen zu finden, die die Analyse der Qualität einer Software ermöglichen können. Mit OOD wollen wir nicht die Softwaretests umgehen, sondern nur die personellen und finanziellen Kosten vermeiden.
Wir alle wissen, wieviel eine Verbesserung nach einem Test kostet. Maße für OOD ermöglichen es, einen Teil der Fehler schon in der Designphase zu vermeiden.
Der Bedarf an neuen Maßen, speziell für OO, resultiert aus zwei Gründen [4]:
q Frühere Maße haben grosse theoretische Lücken und waren sehr „Labor-Intensiv“ ⇒ wir brauchen stärkere mathematische und theoretische Strenge
q OO und funktionsorientierte Programmierung haben zwei unterschiedliche Lösungsmethoden
⇒ die Maße entwickelt für funktionsorientierte Programmierung sind für OO nicht geeignet, wir müssen neue Maße spezifisch für OO entwickeln
In diesem Abschnitt will ich zuerst eine Gruppe von sechs Maßen präsentieren, die in einer Studie von Chidamber und Kemerer (CK) [4] enthalten sind. Nachher werde ich auf diese Maße als Qualitätsanzeiger (d.h. die Möglichkeit fehleranfällige Klassen zu bestimmen) zu sprechen kommen.
Am Schluss werden auch ein paar Kritiken behandelt.
Die Maße von CK sind in vier Hauptmengen unterteilt.
3.1 Theorie der OOD Maße
3.1.1 Design-Theorie von Booch
Es gibt eine Vielzahl von Design Methoden. Wir stützen uns auf die von Booch [2].
Die wichtigsten vier Stufen des Designs sind:
1 Klassen und Objekte identifizieren
2 Semantik von Klassen identifizieren (Bedeutung von jeder Klasse und jedem Objekt und deren Lebensdauer)
3 Beziehungen zwischen Klassen und Objekten identifizieren (Interaktionen, Vererbung usw.)
4 Implementation von Klassen und Objekten (Definition von Methoden und deren Funktionen)
3.1.2 Arbeitsverfahren von Chidamber und Kemerer
Ein OOD kann als ein relationales System definiert werden. Definieren wir ein Design D als eine Menge von Elementen, Relationen und binären Operationen.
D ≡ (A, R1 ... Rn, O1 ... Om) A = Menge von Objekten;
R1 ... Rn = Empirische Relationen (z. B. grösser, kleiner usw.) und O1 ... Om = binäre Relationen von A (z.B. Kombination).
Aus diesen Relationen können wir intuitive Aussagen machen, z.B. über die Komplexität der Gestaltung.
Diese Aussagen werden von CK als Sichtpunkte (Viewpoints) definiert [4]. Diese Sichtpunkte können ihrerseits als Anfangspunkte für die Evaluation der Maße [6] definiert werden.
Diese intuitiven Aussagen müssen wir in einen formalen Beweis umwandeln.
Dazu müssen wir unsere empirische Relation in eine formale Relation umsetzen:
F ≡ (C, S1 ... Sn, B1 ... Bm)
C = Menge von Elementen (Realzahlen);
R1 ... Rn = Formale Relationen (z. B. >, < usw.) und O1 ... Om = binäre Relationen von C (z.B. +, -, =).
Die Übersetzung von einem Sichtpunkt (empirischem System D) in ein formales System folgt mit einem Maß µ. Z.B.: für jedes Element a ∈ D gibt es ein Maß µ (a) ∈ F.
Ein Beispiel wird uns die Idee der Validierung eines Maßes vereinfachen:
Wenn wir zwei Personen sehen, können wir intuitive Aussagen über sie machen, z.B. Person A ist grösser als Person B. Diese Aussage ist aber nur intuitiv und muss noch formal bewiesen werden. Wir messen die zwei Personen und bekommen folgende Daten: A 1.90m und B 1.60m. Jetzt können wir sagen 1.90 > 1.60, A grösser als B.
Maße sind der formale Beweis eines Sichtpunktes.
Die Maße von CK wurden praktisch von einem Team von Programmierern bewiesen. Zwei Projekte waren in diesem Verfahren involviert.
Projekt A besteht aus 634 Klassen, die von einer Softwarefirma zur Wiederverwendung erstellt wurde.
Projekt B war ein Halbleiterersteller, der Software entwickelt hat, um Maschinen zu kontrollieren.
Im nächsten Abschnitt präsentiere ich die sechs Maße von CK und deren Sichtpunkte. Danach werde ich anhand einer Tabelle mit sechs formalen Beweiskriterien auf die Objektivität der Maße zu sprechen kommen.
3.2 Maße für OOD
Die folgenden sechs Maße kommen aus einer Studie von Chidamber und Kemerer [4]. Jedes Maß ist in einer Menge katalogisiert. Es gibt vier Hauptmengen [5]:
1 Coupling Metrics: entsprechen der Abhängigkeit zwischen den Klassen eines Systems 2 Cohesion Metrics: entsprechen der Höhe der internen Abhängigkeit einer Klasse 3 Complexity Metrics: entsprechen der Komplexität der Klassen
4 Inheritance Metrics: ensprechen der hierarchischen Struktur eines Systems
Für jedes Maß wird immer die Menge angegeben zu welcher sie gehört.
3.2.1 Weighted Methods per Class (WMC, Complexity Metric)
n
WMC = Σ c
ii=1
c = Komplexität der Methode
Nehmen wir eine Klasse Cmit einer Menge von Methoden M1, ..., Mn. c1, ..., cn sind als die Komplexität der einzelnen Methoden definiert.
Die Bestimmung der Komplexität einer Methode ist absolut subjektiv und ist von der Erfahrung des Programmierers abhängig [5]. Um ein einfacheres Maß zu haben, kalibrieren wir oft alle c gleich, d.h.
c1, ..., cn = 1. WMC ist jetzt gleich der Anzahl der Methoden einer Klasse.
Sichtpunkte:
q Die Anzahl von Methoden und deren Komplexität voraussagen; Angabe der Zeit und der Arbeit um eine Klasse zu entwickeln und zu verwalten
q Je grösser der WMC-Wert, desto grösser die Wirkung auf die Klassen, die ihre Methoden erben
q Mit einem Wachstum der WMC sinkt die Möglichkeit an Wiederverwendung der Klasse (mehr spezifische Klassen)
3.2.2 Depth of Inheritance Tree (DIT, Inheritance Metric)
Wir können ein System wie einen Baum strukturieren; DIT misst die maximale Länge von einem Knoten bis zur Wurzel der Hierarchie.
Bild 3.2 A: Ein System kann auch als ein „Baum“ aus Klassen gesehen werden. B: Das DIT der Klasse D ist der Pfad A-B- D.
In Bild 3.2 zum Beispiel suchen wir das DIT der Klasse D. Der Pfad des Knotens D bis zur Wurzel ist D-B-A und das DIT der Klasse D ist gleich 2.
Sichtpunkte:
q Je grösser das DIT, desto mehr Methoden werden von einer Klasse vererbt ⇒ grössere Schwierigkeit, das Verhalten vorauszusagen
q Tiefere Bäume bedeuten grössere Gestaltungsschwierigkeit (mehr Klassen und Methoden involviert)
q Je tiefer eine Klasse in der Hierarchie liegt, desto grösser ist ihr Wiederverwendungspotential von den vererbten Methoden
3.2.3 Number of Children (NOC, Inheritance Metric)
NOC ist nichts anderes als die Anzahl der direkt verbundenen Knoten. Z.B.: in Bild 3.2 A ist der NOC von B = 2 (D und E).
Sichtpunkte:
q Eine grössere Anzahl von „Söhnen“ entsprechen einer grösseren Wiederverwendung der Klasse
q Mit einer grossen Anzahl von „Söhnen“ ist die Wahrscheinlichkeit einer falschen Abstraktion grösser
q NOC enspricht der Wichtigkeit einer Klasse in der Gestaltung des Systems
3.2.4 Coupling between Object Classes (CBO, Coupling Metric)
CBO ist die Anzahl der Klassen, an welche unsere Klasse gekoppelt ist, d.h. wie viele Methoden oder Parameter von anderen Klassen benutzt werden.
Sichtpunkte:
q Je kleiner der CBO einer Klasse, desto grösser die Möglichkeit einer Wiederverwendung
q Ein grösseres CBO bedeutet grösseren Verwaltungsaufwand
q Je mehr eine Klasse an eine andere gekoppelt ist, desto intensiver muss getestet werden
3.2.5 Response for a Class (RFC, Coupling Metric)
RFC ist definiert als die Anzahl der Methoden, die bei einer Nachrichtenantwort einer Klasse zum Einsatz kommen.
RFC = |RS| mit RS = {M} ∪all i {Ri}
{M} = Methoden in einer Klasse
{Ri} = Methoden, die von einer Methode i aufgerufen werden
Eine Methode kann aber auch Methoden von anderen Klassen aufrufen. RFC entspricht der Kommunikation zwischen den Klassen eines Systems.
Sichtpunkt:
q Ein Testverfahren ist komplizierter, je grösser der RFC ist (mehrere Methoden involviert)
q Je grösser der RFC ist, desto komplizierter ist die Klasse
q Um einen geeigneten Wert für die Testdauer zu bestimmen, müssen wir den “Worst Case“ des RFCs annehmen
3.2.6 Lack of Cohesion in Methods (LCOM, Cohesion Metric) LCOM = |P| - |Q|, wenn |P| > |Q|, sonst LCOM = 0
Klasse C mit n Methoden M1, ..., Mn und {Ij} ist eine Menge von Variablen, die von M benutzt werden.
P = {(Ii, Ij)| Ii ∩ Ij = 0} und Q= {(Ii, Ij)| Ii ∩ Ij ≠ 0}. Wenn {Ii}, ..., {In} sind 0, dann P = 0.
LCOM enspricht der Anzahl von Methoden, die unterschiedliche Attribute benutzen (Ii ∩ Ij = 0) minus die, die dieselben Attribute benutzen (Ii ∩ Ij ≠ 0).
Je grösser LCOM ist, desto kleiner wird die Kohäsion.
Sichtpunkt:
q Kohäsion fördert eine grössere Verkapselung einer Klasse
q Kleinere Kohäsion enspricht grössere Komplexität
q LCOM zeigt die Notwendigkeit an, eine Klasse in mehrere Subklassen zu unterteilen
q LCOM hilft Gestaltungsmängel zu finden
3.2.7 Formale Evaluation der Maße
In diesem Abschnitt möchte ich diese Maße anhand von sechs Eigenschaften formalisieren.
Weyuker [9] hat neun Eigenschaften definiert, die die Softwaremaße besitzen müssen. CK haben sechs von diesen neun benutzt.
1 Noncoarness: nicht jede Klasse hat denselben Wert für ein Maß, d.h. für zwei Klassen A und B und deren Maße µ(A) und µ(B) gilt: µ(A) ≠ µ(B)
2 Nonuniqueness: es können zwei Klassen A und B mit µ(A) = µ(B) existieren
3 Design Details are Important (DDI): auch wenn zwei Klassen dieselbe Funktionalität haben, ist es nicht eindeutig, dass µ(A) = µ(B) ist
4 Monotonicity: für alle Klasse A und B gilt: µ(A) ≤ µ(A+B) und µ(B) ≤ µ(A+B)
5 Nonequivalence Of Interaction (NOI): wenn µ(A) = µ(B) bedeutet dies nicht, dass µ(A + C) = µ(B + C)
6 Interaction Increases Complexity (IIC): µ(A) + µ(B) < µ(A + B)
Anhand dieser sechs Eigenschaften können wir unsere Maße analysieren.
Maß Noncoarness Nonuniqueness DDI Monotonicity NOI IIC
WMC Ja Ja Ja Ja Ja Nein
DIT Ja Ja Ja Nein
(Teilweise)
Ja Nein
NOC Ja Ja Ja Ja Ja Nein
CBO Ja Ja Ja Ja Ja Nein
RFC Ja Ja Ja Ja Ja Nein
LCOM Ja Ja Ja Nein Ja Nein
Ja: die Eigenschaft ist von diesem Maß erfüllt. Nein: nicht erfüllte Eigenschaft
Tabelle 3.1 Formalisierung der Maße durch Bestimmung von Eigenschaften
Jedes Maß genügt der Mehrheit der Eigenschaften, mit einer grossen Ausnahme von Eigenschaft 6 (IIC), die von keinem Maß erfüllt wird. Dies bedeutet, dass die Komplexität eines Maßes steigt (statt sinkt) wenn eine Klasse in zwei neue Klassenunterteilt wird.
Es gibt zwei weitere Fälle, wo eine Eigenschaft nicht erfüllt ist. Für DIT ist Monotonicity nur teilweise erfüllt, wenn eine Klasse eine „Parent-Relationship“ hat (ein „Sohn“ von einer anderen ist).
LCOM erfüllt Monotonicity nicht, wenn wir z.B. zwei Klassen haben, die kombiniert sind und welche die gleichen Variablen benutzen, d.h. eine Klasse P hat drei Methoden (M1, M2, M3)und zwei von diesen (M2, M3) haben eine gemeinsame Variable (LCOM = 1). Drei Methoden einer Klasse Q mit, nutzen eine gemeinsame Variable (LCOM = 0). Wenn wir P+Q erstellen und die Methoden von Q die gleiche Variablen wie M2, M3 haben, dann ist LCOM = 0 ⇒ µ(P) > µ(P+Q) !
3.3 Maße für OOD als Qualitätsindikatoren
3.3.1 CK-Maße als Fehlerindikatoren
Bild 3.3 Theorie der Gestaltung neuer Maße für OOD [3]
Die Komplexität einer Klasse (interne Maße, z.B. Coupling, Complexity) hat eine Beziehung zur Cognitive Complexity und somit mit der externen Qualität (externe Maße, z.B. Fehleranfälligkeit), d.h.
bei einer wachsenden strukturellen Komplexität wird die Klasse fehleranfälliger sein, weil die kognitive Komplexität zunimmt [3].
Dieser Ansatz kann anhand folgender Behauptung besser verstanden werden:
„There is a clear intuitive basis for believing that complex programs have more faults in them than simple programs“ [5].
Mit einer grösseren kognitiven Komplexität steigt die Gefahr von Fehlern und die Verwaltung einer Klasse wird schwieriger.
Um die kognitive Komplexität zu verstehen und die konsequente Fehleranfälligkeit zu messen, brauchen wir eine Gruppe von Maßen, die einem objektiven Beweis der Eigenschaften einer Klasse entspricht (d.h interne Maße).
Basili [1] studiert die Möglichkeit, für die CK-Maße die Fehlerhaftigkeit einer Klasse vorauszuschauen, d.h. aus internen Maßen die externen zu bestimmen.
Basili versucht seine Hypothese anhand eines Experiments zu beweisen. Das Experiment wurde von Studenten entwickelt. Die Studenten mussten eine Videorental-Software entwickeln. Die Programmierer hatten wenig Erfahrung und sie konnten das System frei gestalten.
Aus den Daten, die Basili sammelte, versuchte er anhand einer univariablen und einer multivariablen Regressionsanalyse seine Hypothese zu beweisen.
Das Verfahren von Basili war wie folgt organisiert: mit einer univariablen Regression evaluierte er die Abhängigkeiten zwischen den einzelnen Maßen und die Fehleranfälligkeit. Mit multivariabler Regression bestimmte er die prädiktive Kapazität von den Maßen, die relevante Daten aus der univariablen Regression präsentierten [1].
Metric Hypothese Wahrscheinlichkeit der Hypothese (aus
univariabler Regressionsanalyse) WMC Ein grösser WMC bedeutet mehrere
Fehler
Die Daten unterstützen die Hypothese
DIT Ein grösser DIT bedeutet mehr
Fehlerhaftigkeit
Die Daten unterstützen die Hypothese
NOC Eine Klasse mit mehreren Subklassen enthält i.d.R. mehr Fehler
Die Daten unterstützen die Hypothese
CBO Mehrere verkoppelte Klassen sind fehlerhafter
Die Daten unterstützen die Hypothese
RFC Ein grösseres RFC bedeutet eine grössere Wahrscheinlichkeit, Fehler zu enthalten
Die Daten unterstützen die Hypothese
LCOM Klassen mit einem grösseren LCOM sind i.d.R. fehlerhafter als andere
Die Daten unterstützen die Hypothese nicht
Tabelle 3.2 Die Resultate von Basilis Experiment
Aus dem Experiment von Basili resultiert, dass fünf von sechs Maßen für die Bestimmung der Fehlerhäftigkeit von Klassen anwendbar ist.
Anhand dieser Daten demonstriert Basili die Abhängigkeit zwischen internen und externen Maßen und gibt ein Modell an, um die externen Maße aus den internen zu bestimmen.
3.3.2 Kritik an Basili-Modell
Eine grosse Kritik am Modell von Basili kommt von Khaled El Emam et al [5]. Die Idee ist, dass eine zweite Variable beachtet werden müsste, um zu beweisen, dass die Maße von CK Fehleranfälligkeiten schätzen können: die Grösse der Klasse.
Anhand von empirischen und mathematischen Daten hat El Emam die Theorie von Basili in Frage gestellt.
Bild 3.4 Verwirrender Effekt der Grösse einer Klasse
Diese Kritik relativiert die Studien von Basili. In Zukunft müssen sich die Entwicklern mehr auf die Grösse der Klasse stützen, um Maße zu validieren.
4 Schlusswort
Sind Maße objektiv? Brauchen wir neue Maße für OO? Sind die Maße von der Programmiersprache und Umgebungsfaktoren unabhängig? Können wir die Maße als Qualitätsindikatoren verwenden?
Diese sind die wichtigen Fragen, die die Forscher beantworten wollen. Bis jetzt haben wir viele Theorien gesehen, die die Vollständigkeit dieser Maße nicht genau beweisen.
Der Unterschied von funktionsorientierter und objektorientierter Programmierung zwangen Chidamber und Kemerer [4] eine neue Gruppe von Maßen zu entwickeln, die speziell für OO gedacht sind.
Basili [1] hat gezeigt, dass diese Maße eine gute Methode sind, um die Qualität der Software zu
bestimmen und, dass sie den Entwicklern die Möglichkeit geben, Fehler schon in der Gestaltungsphase zu bemerken. Man ist aber noch nicht sicher, dass dieses Modell ausreichend ist. El Emam [5] hat bemerkt, dass die Theorie von Basili lückenhaft ist, weil sie die Grösse der Klasse nicht berücksichtigt.
5 Literatur
[1] V. R. Basili et al., A Validation of Object-Oriented Design Metrics as Quality Indicators, IEEE Trans. Software Eng., vol. 22, no. 10, pp. 751 – 761, 1996.
[2] G. Booch, Object-Oriented Analysis and Design, second edition, Redwood City, CA: Benjamin/
Cunnings, 1994.
[3] L. C. Briand, Empirical Investigation of Quality Factors in Object Oriented Software, 1997.
[4] S.R. Chidamber and C.F. Kemerer, A Metrics Suite for Object-Oriented Design, IEEE Trans.
Software Eng., vol. 20, no. 6, pp. 476 – 493, 1994.
[5] K. El Emam et al., The Confounding Effect of Class Size on the Validity of Object-Oriented Metrics, IEEE Trans. Software Eng., vol. 27, no. 7, pp. 630 – 650, 2001.
[6] N. E. Fenton, Software Metrics, A Rigorous Approach, New York: Chapman & Hall, 1991.
[7] M. Glinz, Software Engineering I, Vorlesungsskript, WS 2001/2002.
[8] M. Lorenz and J. Kidd, Object-Oriented Software Metrics, Prentice Hall OO Series, 1994.
[9] E. Weyuker, Evaluating Software Complexity Measures“, IEEE Trans. Software Eng., vol. 14, pp.
1357 – 1365, 1988.
