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
164 12 Zusammenfassung und Ausblick 12.2.6 Grenzen des Ansatzes Die wichtigste Einschränkung des Ansatzes ist, dass sämtliche dynamischen Entwurfseigenschaften unberücksichtigt bleiben. Das führt dazu, dass wichtige Qualitäten wie Effizienz oder Zuverlässigkeit nicht bewertet werden können. Ursache für die Beschränkung ist die Beobachtung, dass dynamische Entwurfsinformation in UML zwar ausgedrückt werden kann, dies in der Praxis aber nur bruchstückhaft getan wird. Soll auch dynamische Entwurfsinformation bei der Bewertung berücksichtigt werden, müssen entsprechende Anforderungen an Umfang und Detaillierungsgrad der UML-Dokumentation gestellt werden. Es hat sich gezeigt, dass die UML-Dokumentation eines Entwurfs nicht ausreicht, um den Entwurf vollständig zu beschreiben. Zusätzlich ist weitere erläuternde Dokumentation notwendig. Diese ließe sich zwar theoretisch in Form von Notizen auch in UML darstellen, doch ist ein beschreibendes Entwurfsdokument, in das UML-Diagramme eingebettet sind, übersichtlicher und leichter verständlich. Diese über die UML-Diagramme hinausgehende Information wird bei der Bewertung genutzt, ist aber nicht im Referenzmodell ODEM repräsentiert. Eine Entwurfsbewertung ist am effektivsten, wenn sie in Zusammenhang mit einem Entwicklungsprozess eingesetzt wird, der dem Wasserfallmodell (Royce, 1970) entspricht, weil am Ende der Entwurfsphase der Entwurf vollständig vorliegt, aber noch keine Realisierung vorgenommen wurde. Ein solcher Entwicklungsprozess ist aber nur dann sinnvoll, wenn die Anforderungen klar und stabil sind, was selten gegeben ist. Daher findet Software-Entwicklung häufig in einem iterativen, evolutionären Prozess statt. Der Entwurf entsteht (und wächst) schrittweise und wird immer wieder überarbeitet. Auf der einen Seite kann dieses Vorgehen zu einem besseren Entwurf führen als beim Wasserfallmodell. Auf der anderen Seite kann es schwieriger werden, Fehlentwicklungen zu erkennen, weil eine Bewertung des Gesamtbilds erst spät im Entwicklungsprozess möglich ist. Der vorgestellte Ansatz zur Bewertung kann jederzeit durchgeführt werden, auch auf Zwischenversionen des Entwurfs. Nur kann eben immer nur die bereits vorliegende Entwurfsinformation berücksichtigt werden. Eine völlig rationale, objektive und gleichzeitig weitgehend zutreffende Bewertung des Entwurfs ist theoretisch denkbar. Der dazu zu treibende Aufwand ist allerdings immens: Der Entwurf muss hinreichend formalisiert werden, es muss ein spezifisches Qualitätsmodell erstellt und validiert werden, und für jede Bewertung sind die erforderlichen Daten zu erheben und zu verarbeiten. Der Gesamtaufwand dürfte also so groß sein, dass es auch in Zukunft schon aus ökonomischen Erwägungen erforderlich sein wird, die Bewertung im Wesentlichen mit Hilfe der Intuition und Erfahrung eines guten Entwerfers durchzuführen. Qualitätsmodelle mit objektiven Metriken und daraus abgeleitete automatisierte Entwurfsregeln sind dabei praktische Hilfsmittel der Analyse, die dem Bewerter die Arbeit erleichtern, ihn aber nicht ersetzen. 12.3 Vergleich mit anderen Arbeiten Grundlage der Entwurfsbewertung In dieser Arbeit ist die Grundlage der Entwurfsbewertung ein UML-Modell. Die meisten Arbeiten im Bereich der Entwurfsbewertung stützen sich allerdings entweder
12.3 Vergleich mit anderen Arbeiten 165 auf eine nicht näher spezifizierte Architekturdokumentation (z. B. Bass et al., 1998; Clements et al., 2002) oder auf Code (z. B. Erni, 1996; Bär, 1998). Für die Bewertung auf der Basis einer Entwurfsdokumentation in UML gibt es bisher nur die Ansätze von Robbins, Redmiles (1999) und Nenonen et al. (2000). Bei Robbins und Redmiles werden weder Metriken erhoben noch wird eine Gesamtbewertung angestrebt; der Schwerpunkt liegt im Aufzeigen von Mängeln auf der Basis von Entwurfsregeln. Der Ansatz von Nenonen et al. arbeitet mit Metriken und bezieht dabei auch UML- Bestandteile zur Modellierung der dynamischen Struktur ein. Die erhobenen Metriken sollen zur Qualitätsbewertung dienen – wie diese allerdings genau durchgeführt werden soll, sagen die Autoren nicht. Qualitätsmodellierung In Abschnitt 7.4 wurden einige Qualitätsmodelle für den objektorientierten Entwurf vorgestellt. Die wenigsten sehen eine quantitative Bewertung vor. Diese Modelle eignen sich daher besser für eine qualitative Bewertung bzw. für eine Mängelanalyse auf der Basis von Fragebögen und Checklisten. Ein quantitatives, validiertes Qualitätsmodell findet sich bei Erni (1996), es ist jedoch nur für die Bewertung der Wartbarkeit von Rahmenwerken gedacht. Auch dieses Qualitätsmodell dient vor allem der Mängelanalyse, auf eine Gesamtbewertung wird verzichtet. Nur bei Bansiya und Davis (2002) gibt es eine Gesamtbewertung, die durch teilweise gewichtete Aggregation von Metriken entsteht. Eine Gesamtbewertung ist Voraussetzung für den Vergleich von Entwurfsalternativen, die auch durch spezifische Modelle auf der Basis von QOOD ermöglicht wird. Bewertungstechniken Wie in Abschnitt 7.6 gezeigt gibt es verschiedene Techniken zur Bewertung von Entwürfen: Szenarien, Simulation, Metriken, Fragebögen und Checklisten. Metriken werden häufig zur Bewertung verwendet, z. B. arbeiten fast alle der in Abschnitt 11.1 vorgestellten Arbeiten mit Metriken. Allerdings werden die Metriken nie exakt definiert – ein Mangel, der in dieser Arbeit durch die Einführung des Referenzmodells ODEM vermieden wird. Außerdem werden hier die objektiven Metriken mit Fragebögen (und subjektiven Metriken) kombiniert. Dies hat sich als vorteilhaft erwiesen, weil die Fragebögen die Unzulänglichkeiten der objektiven Metriken bei der Bewertung ausgleichen können. Diese Kombination ist in dieser Form bei der Entwurfsbewertung bisher einzigartig. Neu ist ebenfalls das Konzept der Verfeinerung von Metriken. Eine mögliche Alternative zu den Fragebögen ist die Kombination von Metriken mit Szenarien, wie sie Briand und Wüst (2001) in einer Fallstudie zur Bewertung der Wartbarkeit vorgenommen haben. Das Ergebnis dieser Fallstudie deutet darauf hin, dass sich die beiden Bewertungstechniken ebenfalls gut ergänzen. In eine ähnliche Richtung gehen die Erkenntnisse von Laitenberger et al. (2000), die durch ein Experiment festgestellt haben, dass bei der Inspektion von UML-Dokumenten ein Szenariobasierter Prüfansatz einem Checklisten-basierten überlegen ist, was Effektivität und Kosten angeht. Abowd et al. (1996) und Bosch (2000) raten bei der Bewertung von Software-Architekturen von der Verwendung von Metriken eher ab und empfehlen stattdessen Szenarien, Fragebögen, Checklisten und Simulationen. Das könnte allerdings daran liegen, dass Architekturbeschreibungen häufig nicht formal genug sind, oder dass Metriken
- Seite 123 und 124: 8.5 Wiederverwendbarkeit 113 derver
- Seite 125 und 126: 8.7 Testbarkeit 115 kann. Technisch
- Seite 127 und 128: Kapitel 9 Quantifizierung des Quali
- Seite 129 und 130: 9.1 Bewertungsverfahren 119 Bewertu
- Seite 131 und 132: 9.2 Objektive Metriken 121 Akronym
- Seite 133 und 134: 9.2 Objektive Metriken 123 Paket NC
- Seite 135 und 136: 9.3 Subjektive Metriken 125 Gewicht
- Seite 137 und 138: 9.4 Fragebögen 127 9.4 Fragebögen
- Seite 139 und 140: 9.4 Fragebögen 129 auch Fragen, f
- Seite 141 und 142: 9.5 Gesamtbewertung 131 der Gewicht
- Seite 143 und 144: 9.6 Ableitung spezifischer Modelle
- Seite 145 und 146: Kapitel 10 Ein spezifisches Qualit
- Seite 147 und 148: 10.1 Ableitung des Qualitätsmodell
- Seite 149 und 150: 10.1 Ableitung des Qualitätsmodell
- Seite 151 und 152: 10.2 Anwendung des Qualitätsmodell
- Seite 153 und 154: 10.2 Anwendung des Qualitätsmodell
- Seite 155 und 156: 10.2 Anwendung des Qualitätsmodell
- 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: 12.2 Bewertung des Ansatzes 163 Die
- 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 und 208: A.5 Einheitlichkeit 197 Ein alterna
- Seite 209 und 210: A.9 Theoretische Validierung 199 A.
- 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
12.3 Vergleich mit an<strong>der</strong>en Arbeiten 165<br />
auf eine nicht näher spezifizierte Architekturdokumentation (z. B. Bass et al., 1998;<br />
Clements et al., 2002) o<strong>der</strong> auf Code (z. B. Erni, 1996; Bär, 1998). Für die <strong>Bewertung</strong><br />
auf <strong>der</strong> Basis einer Entwurfsdokumentation in UML gibt es bisher nur die Ansätze<br />
von Robbins, Redmiles (1999) und Nenonen et al. (2000). Bei Robbins und Redmiles<br />
werden we<strong>der</strong> Metriken erhoben noch wird eine Gesamtbewertung angestrebt; <strong>der</strong><br />
Schwerpunkt liegt im Aufzeigen von Mängeln auf <strong>der</strong> Basis von Entwurfsregeln. Der<br />
Ansatz von Nenonen et al. arbeitet mit Metriken und bezieht dabei auch UML-<br />
Bestandteile zur Modellierung <strong>der</strong> dynamischen Struktur ein. Die erhobenen Metriken<br />
sollen zur <strong>Qualität</strong>sbewertung dienen – wie diese allerdings genau durchgeführt<br />
werden soll, sagen die Autoren nicht.<br />
<strong>Qualität</strong>smodellierung<br />
In Abschnitt 7.4 wurden einige <strong>Qualität</strong>smodelle für den objektorientierten Entwurf<br />
vorgestellt. Die wenigsten sehen eine quantitative <strong>Bewertung</strong> vor. Diese Modelle eignen<br />
sich daher besser für eine qualitative <strong>Bewertung</strong> bzw. für eine Mängelanalyse auf<br />
<strong>der</strong> Basis von Fragebögen und Checklisten. Ein quantitatives, validiertes <strong>Qualität</strong>smodell<br />
findet sich bei Erni (1996), es ist jedoch nur für die <strong>Bewertung</strong> <strong>der</strong> Wartbarkeit<br />
von Rahmenwerken gedacht. Auch dieses <strong>Qualität</strong>smodell dient vor allem <strong>der</strong> Mängelanalyse,<br />
auf eine Gesamtbewertung wird verzichtet. Nur bei Bansiya und Davis<br />
(2002) gibt es eine Gesamtbewertung, die durch teilweise gewichtete Aggregation von<br />
Metriken entsteht. Eine Gesamtbewertung ist Voraussetzung für den Vergleich von<br />
Entwurfsalternativen, die auch durch spezifische Modelle auf <strong>der</strong> Basis von QOOD<br />
ermöglicht wird.<br />
<strong>Bewertung</strong>stechniken<br />
Wie in Abschnitt 7.6 gezeigt gibt es verschiedene Techniken zur <strong>Bewertung</strong> von <strong>Entwürfe</strong>n:<br />
Szenarien, Simulation, Metriken, Fragebögen und Checklisten. Metriken werden<br />
häufig zur <strong>Bewertung</strong> verwendet, z. B. arbeiten fast alle <strong>der</strong> in Abschnitt 11.1 vorgestellten<br />
Arbeiten mit Metriken. Allerdings werden die Metriken nie exakt definiert<br />
– ein Mangel, <strong>der</strong> in dieser Arbeit durch die Einführung des Referenzmodells ODEM<br />
vermieden wird. Außerdem werden hier die objektiven Metriken mit Fragebögen<br />
(und subjektiven Metriken) kombiniert. Dies hat sich als vorteilhaft erwiesen, weil die<br />
Fragebögen die Unzulänglichkeiten <strong>der</strong> objektiven Metriken bei <strong>der</strong> <strong>Bewertung</strong> ausgleichen<br />
können. Diese Kombination ist in dieser Form bei <strong>der</strong> Entwurfsbewertung<br />
bisher einzigartig. Neu ist ebenfalls das Konzept <strong>der</strong> Verfeinerung von Metriken.<br />
Eine mögliche Alternative zu den Fragebögen ist die Kombination von Metriken mit<br />
Szenarien, wie sie Briand und Wüst (2001) in einer Fallstudie zur <strong>Bewertung</strong> <strong>der</strong><br />
Wartbarkeit vorgenommen haben. Das Ergebnis dieser Fallstudie deutet darauf hin,<br />
dass sich die beiden <strong>Bewertung</strong>stechniken ebenfalls gut ergänzen. In eine ähnliche<br />
Richtung gehen die Erkenntnisse von Laitenberger et al. (2000), die durch ein Experiment<br />
festgestellt haben, dass bei <strong>der</strong> Inspektion von UML-Dokumenten ein Szenariobasierter<br />
Prüfansatz einem Checklisten-basierten überlegen ist, was Effektivität und<br />
Kosten angeht.<br />
Abowd et al. (1996) und Bosch (2000) raten bei <strong>der</strong> <strong>Bewertung</strong> von Software-Architekturen<br />
von <strong>der</strong> Verwendung von Metriken eher ab und empfehlen stattdessen Szenarien,<br />
Fragebögen, Checklisten und Simulationen. Das könnte allerdings daran liegen,<br />
dass Architekturbeschreibungen häufig nicht formal genug sind, o<strong>der</strong> dass Metriken