Bewertung der Qualität objektorientierter Entwürfe - Worte-Projekt
Bewertung der Qualität objektorientierter Entwürfe - Worte-Projekt Bewertung der Qualität objektorientierter Entwürfe - Worte-Projekt
198 A Metriken für QOOD A.6 Dokumentierung Auch für die Dokumentierung ist eine subjektive Bewertung nötig. Zwar kann bei entsprechenden Dokumentierungskonventionen automatisch geprüft werden, ob Kommentare im geforderten Umfang vorhanden sind, doch ist es sehr schwer, automatisch zu prüfen, ob die Kommentare sinnvoll und hilfreich sind. A.7 Verfolgbarkeit Die Verfolgbarkeit lässt sich nicht direkt aus dem UML-Modell ermitteln, da es für die Verknüpfung von UML-Artefakten mit den Anforderungen kein standardisiertes Verfahren gibt. Für Klassen und Pakete kann man nur beurteilen, wie gut dokumentiert ist, auf welche Anforderungen ihr Vorhandensein zurückzuführen ist. Eine (sinnvolle) objektive Metrik dafür lässt sich leider nicht angeben. Auf der Systemebene kann man eine objektive Metrik angeben, die sich allerdings nicht auf der Basis von ODEM ermitteln lässt: Die Metrik RTTR (ratio of traceable to total requirements) ist das Verhältnis der Anzahl der im Entwurf verfolgbaren Anforderungen zur Gesamtzahl der Anforderungen. Je größer der Wert, desto besser. Neben der reinen Anzahl verfolgbarer Anforderungen könnte auch zusätzlich eine Gewichtung der Anforderungen vorgenommen werden, so dass die Verfolgbarkeit wichtiger oder instabiler Anforderungen stärker berücksichtigt wird als die Verfolgbarkeit unwichtiger oder stabiler Anforderungen. Eine solche Verfeinerung ist allerdings Aufgabe des spezifischen Qualitätsmodells. Sofern ein bestimmtes Verfahren zur Verknüpfung von UML-Artefakten mit den Anforderungen existiert, kann diese Metrik auch automatisiert erhoben werden, nachdem ODEM um die entsprechenden Konstrukte erweitert wurde. In UML ist ein spezielles Stereotyp «trace» für Abstraktionsbeziehungen zwischen UML-Modellelementen definiert (im UML-Metamodell repräsentiert durch die Klasse Abstraction, vgl. Abbildung 5-2). Mit Hilfe einer solchen Beziehung lässt sich Tracing in UML realisieren. Es kann aber wohl nicht davon ausgegangen werden, dass sich alle Anforderungen in UML sinnvoll darstellen lassen (z. B. als Anwendungsfälle) und dass alle «trace»-Beziehungen vorhanden sind. A.8 Wartbarkeit Die wesentlichen Metriken zur Wartbarkeit stecken bereits in den Kriterien. Neu hinzugenommen werden können nur noch Metriken, die über das UML-Modell hinausgehen. Beispielsweise kann auf der Basis eines Szenario-basierten Bewertungsansatzes die (adaptive) Wartbarkeit gemessen werden, indem für jedes Änderungsszenario die Schwierigkeit der Änderung bewertet und eine Gesamtbewertung ermittelt wird (vgl. Abschnitt B.8). Solche Metriken müssen aber speziell für jedes spezifische Qualitätsmodell entwickelt werden.
A.9 Theoretische Validierung 199 A.9 Theoretische Validierung Bevor die objektiven Metriken angewendet werden, sollten sie theoretisch validiert sein. Die Metriken zu Knappheit, Strukturiertheit und Entkopplung in QOOD lassen sich als Komplexitätsmetriken auffassen, weshalb sich das Axiomensystem von Weyuker (1988) für Komplexitätsmetriken auf sie anwenden lässt. Zusätzlich gibt es noch ein Axiomensystem vom Briand et al. (1999) für Kopplungsmetriken, die spezifisch für die Metriken der Entkopplung betrachtet werden können. 12.5.1 Komplexitätsmetriken Weyuker (1988) hat eine Liste von neun Axiomen publiziert, die für Komplexitätsmetriken, die Programme auf syntaktischer Basis bewerten, gelten sollten. Sei m eine Komplexitätsmetrik und P, Q, R seien Programme. Dann muss gelten: Axiom W1. Es muss Programme geben, die unterschiedliche Komplexität besitzen. Damit sollen Metriken ausgeschlossen werden, die allen Programmen die gleiche Komplexität zuweisen. ∃ P, Q: m(P) ≠ m(Q) Axiom W2. Die Anzahl der Programme, welche die gleiche Komplexität besitzen, muss endlich sein. Damit wird eine feinere Unterscheidung in Komplexitätsklassen gefordert als bei Axiom W1. ∀ c ≥ 0: |{P | m(P) = c}| < ∞ Axiom W3. Es muss Programme geben, welche die gleiche Komplexität besitzen. Damit soll (als Gegenpol zu Axiom W2) eine zu feine Klassifikation (z. B. eine Gödelisierung) ausgeschlossen werden. ∃ P, Q: P ≠ Q ∧ m(P) = m(Q) Axiom W4. Es muss funktional äquivalente Programme geben, die unterschiedliche Komplexität besitzen. Damit soll sichergestellt werden, dass die Komplexität der Implementierung und nicht die der implementierten Funktion gemessen wird. ∃ P, Q: P ≡ Q ∧ m(P) ≠ m(Q) (≡ist die funktionale Äquivalenz) Axiom W5. Werden zwei Programme kombiniert, muss die Komplexität des Ganzen mindestens so groß sein wie die seiner Teile. ∀ P, Q: m(P) ≤ m(P;Q) ∧ m(Q) ≤ m(P;Q) (; kombiniert zwei Programme) Axiom W6. Wird ein Programm mit zwei verschiedenen Programmen gleicher Komplexität kombiniert, können die Komplexitäten der Resultate unterschiedlich sein. Das Axiom soll sicherstellen, dass es mindestens einen solchen Fall je Kombinationsreihenfolge gibt. a) ∃ P, Q, R: m(P) = m(Q) ∧ m(P;R) ≠ m(Q;R) b) ∃ P, Q, R: m(P) = m(Q) ∧ m(R;P) ≠ m(R;Q) Axiom W7. Werden die Anweisungen eines Programms permutiert, kann sich die Komplexität ändern (sie muss aber nicht). Daher wird gefordert, dass es eine Permutation eines Programms geben muss, die eine andere Komplexität hat als das Programm selbst. Damit wird aber von allen Komplexitätsmetriken verlangt, dass sie
- Seite 157 und 158: 10.2 Anwendung des Qualitätsmodell
- Seite 159 und 160: 10.3 Besonderheiten bei Mustern 149
- Seite 161 und 162: Kapitel 11 Werkzeugunterstützung H
- Seite 163 und 164: 11.1 Werkzeuge aus anderen Arbeiten
- Seite 165 und 166: 11.2 Selbst realisierte Werkzeuge 1
- Seite 167 und 168: 11.2 Selbst realisierte Werkzeuge 1
- Seite 169 und 170: 11.3 Ausblick: Ein ideales Werkzeug
- Seite 171 und 172: Kapitel 12 Zusammenfassung und Ausb
- Seite 173 und 174: 12.2 Bewertung des Ansatzes 163 Die
- Seite 175 und 176: 12.3 Vergleich mit anderen Arbeiten
- Seite 177 und 178: 12.4 Ausblick 167 Entwerfen QOOD ka
- Seite 179 und 180: Literatur Abowd et al. (1996) Abowd
- Seite 181 und 182: Beyer et al. (2000) Beyer, D.; Lewe
- Seite 183 und 184: Cavano, McCall (1978) Cavano, J.; M
- Seite 185 und 186: Dißmann (1990) Dißmann, S.: Anfor
- Seite 187 und 188: Gursaran, Roy (2002) Gursaran; Roy,
- Seite 189 und 190: Koenig (1995) Koenig, A.: Patterns
- Seite 191 und 192: McCabe (1976) McCabe, T.: A Complex
- Seite 193 und 194: Rising (2000) Rising, L.: The Patte
- Seite 195 und 196: Wand (1989) Wand, Y.: A Proposal fo
- Seite 197 und 198: Akronyme Allgemeine Akronyme CMM Ca
- Seite 199 und 200: Anhang A Metriken für QOOD Dieser
- Seite 201 und 202: A.1 Knappheit 191 Ihre Verwaltung m
- Seite 203 und 204: A.3 Entkopplung 193 Neben der Tiefe
- Seite 205 und 206: A.3 Entkopplung 195 NEDC p (number
- Seite 207: A.5 Einheitlichkeit 197 Ein alterna
- Seite 211 und 212: A.9 Theoretische Validierung 201 Ax
- Seite 213 und 214: Anhang B Fragebögen für QOOD Dies
- Seite 215 und 216: B.2 Strukturiertheit 205 Paket Bedi
- Seite 217 und 218: B.3 Entkopplung 207 Klasse/Interfac
- Seite 219 und 220: B.4 Zusammenhalt 209 System Bedingu
- Seite 221 und 222: B.6 Dokumentierung 211 Klasse/Inter
- Seite 223 und 224: B.7 Verfolgbarkeit 213 System Bedin
- Seite 225 und 226: Anhang C Dokumente zum Softwareprak
- Seite 227 und 228: C.1 Aufgabenstellung 217 muss der P
- Seite 229 und 230: C.1 Aufgabenstellung 219 dann Ihr H
- Seite 231 und 232: C.2 Anforderungen 221 C.2.4 Fahrgas
- Seite 233 und 234: C.2 Anforderungen 223 alle weiteren
- Seite 235 und 236: C.3 Begriffslexikon 225 Endhalteste
198 A Metriken für QOOD<br />
A.6 Dokumentierung<br />
Auch für die Dokumentierung ist eine subjektive <strong>Bewertung</strong> nötig. Zwar kann bei<br />
entsprechenden Dokumentierungskonventionen automatisch geprüft werden, ob<br />
Kommentare im gefor<strong>der</strong>ten Umfang vorhanden sind, doch ist es sehr schwer, automatisch<br />
zu prüfen, ob die Kommentare sinnvoll und hilfreich sind.<br />
A.7 Verfolgbarkeit<br />
Die Verfolgbarkeit lässt sich nicht direkt aus dem UML-Modell ermitteln, da es für die<br />
Verknüpfung von UML-Artefakten mit den Anfor<strong>der</strong>ungen kein standardisiertes Verfahren<br />
gibt.<br />
Für Klassen und Pakete kann man nur beurteilen, wie gut dokumentiert ist, auf welche<br />
Anfor<strong>der</strong>ungen ihr Vorhandensein zurückzuführen ist. Eine (sinnvolle) objektive<br />
Metrik dafür lässt sich lei<strong>der</strong> nicht angeben. Auf <strong>der</strong> Systemebene kann man eine<br />
objektive Metrik angeben, die sich allerdings nicht auf <strong>der</strong> Basis von ODEM ermitteln<br />
lässt: Die Metrik RTTR (ratio of traceable to total requirements) ist das Verhältnis <strong>der</strong><br />
Anzahl <strong>der</strong> im Entwurf verfolgbaren Anfor<strong>der</strong>ungen zur Gesamtzahl <strong>der</strong> Anfor<strong>der</strong>ungen.<br />
Je größer <strong>der</strong> Wert, desto besser.<br />
Neben <strong>der</strong> reinen Anzahl verfolgbarer Anfor<strong>der</strong>ungen könnte auch zusätzlich eine<br />
Gewichtung <strong>der</strong> Anfor<strong>der</strong>ungen vorgenommen werden, so dass die Verfolgbarkeit<br />
wichtiger o<strong>der</strong> instabiler Anfor<strong>der</strong>ungen stärker berücksichtigt wird als die Verfolgbarkeit<br />
unwichtiger o<strong>der</strong> stabiler Anfor<strong>der</strong>ungen. Eine solche Verfeinerung ist allerdings<br />
Aufgabe des spezifischen <strong>Qualität</strong>smodells.<br />
Sofern ein bestimmtes Verfahren zur Verknüpfung von UML-Artefakten mit den<br />
Anfor<strong>der</strong>ungen existiert, kann diese Metrik auch automatisiert erhoben werden,<br />
nachdem ODEM um die entsprechenden Konstrukte erweitert wurde. In UML ist ein<br />
spezielles Stereotyp «trace» für Abstraktionsbeziehungen zwischen UML-Modellelementen<br />
definiert (im UML-Metamodell repräsentiert durch die Klasse Abstraction, vgl.<br />
Abbildung 5-2). Mit Hilfe einer solchen Beziehung lässt sich Tracing in UML realisieren.<br />
Es kann aber wohl nicht davon ausgegangen werden, dass sich alle Anfor<strong>der</strong>ungen<br />
in UML sinnvoll darstellen lassen (z. B. als Anwendungsfälle) und dass alle<br />
«trace»-Beziehungen vorhanden sind.<br />
A.8 Wartbarkeit<br />
Die wesentlichen Metriken zur Wartbarkeit stecken bereits in den Kriterien. Neu hinzugenommen<br />
werden können nur noch Metriken, die über das UML-Modell hinausgehen.<br />
Beispielsweise kann auf <strong>der</strong> Basis eines Szenario-basierten <strong>Bewertung</strong>sansatzes<br />
die (adaptive) Wartbarkeit gemessen werden, indem für jedes Än<strong>der</strong>ungsszenario<br />
die Schwierigkeit <strong>der</strong> Än<strong>der</strong>ung bewertet und eine Gesamtbewertung ermittelt wird<br />
(vgl. Abschnitt B.8). Solche Metriken müssen aber speziell für jedes spezifische <strong>Qualität</strong>smodell<br />
entwickelt werden.
Change language