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
84 7 Entwurfsqualität Hier werden einige Prinzipien für den objektorientierten Entwurf, von denen viele aus dem strukturierten Entwurf übernommen wurden, kurz vorgestellt. Dabei werden strategische (Tabelle 7-2) und taktische Prinzipien (Tabelle 7-3) unterschieden. Strategische Entwurfsprinzipien sind fundamentaler Art, sie geben eine Art Entwurfstheorie vor. Die taktischen Prinzipien sind technischer Art, sie schlagen die Anwendung bestimmter Techniken vor. Eine ausführliche Erläuterung der Prinzipien findet sich bei Reißing (2002). Prinzip Beschreibung Führe den Entwurf auf die Anforderungen zurück Jede Entwurfsentscheidung muss auf ihre zugehörigen Anforderungen zurückgeführt werden können (und umgekehrt). Diese Eigenschaft wird als Verfolgbarkeit (traceability) bezeichnet. Erfinde nicht das Rad neu Falls immer es möglich ist, sollte für eine vorgesehene Komponente des Entwurfs eine bereits vorhandene Komponente wiederverwendet werden, statt eine neue zu schaffen. Kenne den Anwendungsbereich Sorge für intellektuelle Kontrolle (Witt et al., 1994) Minimiere den intellektuellen Abstand (Structural Correspondence, Jackson, 1975) Stelle konzeptionelle Integrität her (Witt et al., 1994) Verberge Realisierungsentscheidungen (Geheimnisprinzip, Parnas, 1972b) Minimiere die Komplexität Vermeide Redundanz (Beck, 1996; Hunt, Thomas, 1999) Tabelle 7-2: Strategische Prinzipien Der Entwerfer sollte die Begriffswelt und typische Abläufe der Anwendung kennen, aber auch mit ihrer Arbeitsumgebung vertraut sein. Dazu gehört die technische Umgebung genauso wie die soziale Umgebung, die aus den Benutzern und den geltenden Gesetzen und Standards besteht. Nur dann können die optimale Architektur und geeignete Algorithmen gewählt werden. Sowohl die Entwickler als auch die Wartungsprogrammierer sollen in der Lage sein, den Entwurf vollständig zu verstehen. Dies wird durch hierarchische Strukturierung, Abstraktion und Einfachheit der einzelnen Komponenten erleichtert. Außerdem muss der Entwurf gut dokumentiert sein. Der intellektuelle Abstand ist der Unterschied (z. B. in der Struktur) zwischen dem Problem und der Software-Lösung. Um einen geringen intellektuellen Abstand zu erreichen, sollten sich die relevanten Begriffe der Problemwelt (in der Regel die reale Welt) möglichst originalgetreu in der Lösung wiederfinden. Konzeptionelle Integrität bedeutet, dass der gesamte Entwurf einem einheitlichen Stil folgen soll. Der Entwurf soll am Ende so aussehen, als sei er von einer einzigen Person geschaffen worden. Alle Realisierungsentscheidungen sollen in Module gekapselt und so vor dem Rest des Systems verborgen werden. Die Modulschnittstelle soll also über die innere Struktur möglichst wenig Auskunft geben. Gerade bei Entscheidungen, die sich wahrscheinlich ändern, ist das hilfreich. Komplexität erschwert das Verständnis und damit die intellektuelle Kontrolle. Daher sollte sie so gering wie möglich sein. Jede Form von Redundanz stellt ein Risiko dar, da es bei Änderungen leicht zu Inkonsistenzen kommt. Stattdessen sollte eine Funktion an genau einer Stelle realisiert werden.
7.3 Entwurfsregeln 85 Prinzip Beschreibung Benutze Abstraktion Abstraktion ist ein für den Menschen natürliches Verfahren, mit komplexen Sachverhalten umzugehen. Bei der Abstraktion werden irrelevante Details ausgeblendet. Um einen Sachverhalt zu verstehen, ist es dann nicht mehr notwendig, alle Details auf einmal im Gedächtnis zu haben. Es genügt, die an der aktuellen Aufgabenstellung beteiligten Abstraktionen zu beherrschen. Teile und herrsche Ein Problem wird in kleinere, möglichst unabhängige Teilprobleme zerlegt, die gelöst werden. Aus den Einzellösungen wird dann die Gesamtlösung zusammengesetzt. Das Verfahren lässt sich rekursiv anwenden, bis man zu einfach lösbaren Teilproblemen gelangt. Der Vorteil dieses Vorgehens besteht darin, dass zu einem Zeitpunkt nur ein Problem relativ geringer Komplexität gelöst werden muss. Strukturiere hierarchisch (Simon, 1962; Parnas, 1972b) Der Mensch kann nur dann mit komplexen Systemen umgehen, wenn sie hierarchisch sind. Daher sind hierarchische Strukturen im Entwurf vorteilhaft. Modularisiere Das System wird – im Geiste des Teile-und-herrsche-Prinzips – in sinnvolle Subsysteme und Module zerlegt. Das Modul dient dabei als Behälter für Funktionen oder Zuständigkeiten des Systems. Trenne die Zuständigkeiten (separation of concerns) Trenne Verhalten und Implementierung (separation of policy and implementation; Rumbaugh et al., 1993) Kapsele Zusammengehöriges Trenne Schnittstelle und Implementierung Vermeide Abhängigkeiten von Details (Martin, 1996c) Das System wird anhand von Zuständigkeiten (häufig auch als Verantwortlichkeiten bezeichnet) in Komponenten aufgeteilt. Komponenten, die an der gleichen Aufgabe beteiligt sind, werden gruppiert und von denen abgegrenzt, die für andere Aufgaben zuständig sind. Eine Komponente (oder eine Methode) soll entweder für das Verhalten oder die Implementierung zuständig sein, nicht für beides. Eine Komponente für das Verhalten trifft Entscheidungen anhand des Kontextes, interpretiert Ergebnisse und koordiniert andere Komponenten. Eine Komponente für die Implementierung dagegen führt einen Algorithmus auf vorliegenden Daten aus. Komponenten für die Implementierung sind in der Regel stabil, während sich die Komponenten für das Verhalten oft ändern, daher gibt es Sinn, sie zu trennen. Zusammengehörige Bestandteile einer Abstraktion werden zu einem Ganzen zusammengefasst und von anderen abgegrenzt. Die Implementierung wird hinter einer Schnittstelle verborgen. Bei der objektorientierten Sichtweise wird die Kapselung durch die Definition von Klassen erreicht. Eine Komponente soll aus einer Schnittstelle und einer Implementierung bestehen. Die Schnittstelle soll nicht von der Implementierung abhängen, so dass der Verwender nicht durch Änderungen von Implementierungsdetails betroffen sein kann. Komponenten sollten nicht von Details (i. d. R. Implementierungsdetails) abhängig sein, sondern von abstrakten Schnittstellen. In der Objektorientierung bedeutet das, dass die wesentlichen Abstraktionen in Form von Interfaces oder abstrakten Klassen formuliert sind. Tabelle 7-3: Taktische Prinzipien (Abschnitt 1 von 2)
- Seite 43 und 44: 4.3 Muster und Rahmenwerke 33 Kateg
- Seite 45 und 46: 4.5 Probleme des Entwurfs 35 Lösun
- Seite 47 und 48: 4.5 Probleme des Entwurfs 37 Kompon
- Seite 49 und 50: 4.5 Probleme des Entwurfs 39 Aufgab
- Seite 51 und 52: 4.5 Probleme des Entwurfs 41 • di
- Seite 53 und 54: Kapitel 5 Ein Referenzmodell für d
- Seite 55 und 56: 5.2 Umfang 45 Abbildung 5-2: UML-Me
- Seite 57 und 58: 5.2 Umfang 47 5.2.2 Erweiterungen N
- Seite 59 und 60: 5.3 Kern 49 und I muss in genau ein
- Seite 61 und 62: 5.3 Kern 51 • uses: C × (C ∪ I
- Seite 63 und 64: 5.4 Erweiterungen 53 5.4.2 Erweiter
- Seite 65 und 66: 5.5 Formale Definition von Metriken
- Seite 67 und 68: 5.5 Formale Definition von Metriken
- Seite 69 und 70: Kapitel 6 Softwarequalität Quality
- Seite 71 und 72: 6.1 Qualität 61 Benutzerbezogene S
- Seite 73 und 74: 6.2 Qualitätsmodelle 63 Die Defini
- Seite 75 und 76: 6.2 Qualitätsmodelle 65 Boehm et a
- Seite 77 und 78: 6.2 Qualitätsmodelle 67 IEEE Stand
- Seite 79 und 80: 6.3 Qualitätssicherung 69 6.2.4 Fa
- Seite 81 und 82: 6.3 Qualitätssicherung 71 rung und
- Seite 83 und 84: Kapitel 7 Entwurfsqualität Softwar
- Seite 85 und 86: 7.1 Ein Beispiel 75 scheidung nach
- Seite 87 und 88: 7.1 Ein Beispiel 77 WMC DIT NOC CBO
- Seite 89 und 90: 7.2 Perspektiven der Entwurfsqualit
- Seite 91 und 92: 7.2 Perspektiven der Entwurfsqualit
- Seite 93: 7.3 Entwurfsregeln 83 Produkt 1 Pro
- Seite 97 und 98: 7.3 Entwurfsregeln 87 7.3.2 Heurist
- Seite 99 und 100: 7.4 Beispiele für OOD-Qualitätsmo
- Seite 101 und 102: 7.4 Beispiele für OOD-Qualitätsmo
- Seite 103 und 104: 7.4 Beispiele für OOD-Qualitätsmo
- Seite 105 und 106: 7.4 Beispiele für OOD-Qualitätsmo
- Seite 107 und 108: 7.6 Entwurfsbewertung 97 7.5.2 Kons
- Seite 109 und 110: 7.6 Entwurfsbewertung 99 Evaluation
- Seite 111 und 112: Kapitel 8 Das allgemeine Qualitäts
- Seite 113 und 114: 8.1 Vorüberlegungen 103 8.1.4 Indi
- Seite 115 und 116: 8.3 Wartbarkeit 105 unabhängige Mo
- Seite 117 und 118: 8.3 Wartbarkeit 107 auswirkt (höhe
- Seite 119 und 120: 8.3 Wartbarkeit 109 Diskussion Für
- Seite 121 und 122: 8.3 Wartbarkeit 111 Diskussion Zusa
- 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
84 7 Entwurfsqualität<br />
Hier werden einige Prinzipien für den objektorientierten Entwurf, von denen viele<br />
aus dem strukturierten Entwurf übernommen wurden, kurz vorgestellt. Dabei werden<br />
strategische (Tabelle 7-2) und taktische Prinzipien (Tabelle 7-3) unterschieden.<br />
Strategische Entwurfsprinzipien sind fundamentaler Art, sie geben eine Art Entwurfstheorie<br />
vor. Die taktischen Prinzipien sind technischer Art, sie schlagen die<br />
Anwendung bestimmter Techniken vor. Eine ausführliche Erläuterung <strong>der</strong> Prinzipien<br />
findet sich bei Reißing (2002).<br />
Prinzip Beschreibung<br />
Führe den Entwurf auf die<br />
Anfor<strong>der</strong>ungen zurück<br />
Jede Entwurfsentscheidung muss auf ihre zugehörigen Anfor<strong>der</strong>ungen<br />
zurückgeführt werden können (und umgekehrt). Diese Eigenschaft<br />
wird als Verfolgbarkeit (traceability) bezeichnet.<br />
Erfinde nicht das Rad neu Falls immer es möglich ist, sollte für eine vorgesehene Komponente<br />
des Entwurfs eine bereits vorhandene Komponente wie<strong>der</strong>verwendet<br />
werden, statt eine neue zu schaffen.<br />
Kenne den Anwendungsbereich<br />
Sorge für intellektuelle<br />
Kontrolle<br />
(Witt et al., 1994)<br />
Minimiere den intellektuellen<br />
Abstand<br />
(Structural Correspondence,<br />
Jackson, 1975)<br />
Stelle konzeptionelle Integrität<br />
her<br />
(Witt et al., 1994)<br />
Verberge Realisierungsentscheidungen<br />
(Geheimnisprinzip, Parnas,<br />
1972b)<br />
Minimiere die Komplexität<br />
Vermeide Redundanz<br />
(Beck, 1996; Hunt, Thomas,<br />
1999)<br />
Tabelle 7-2: Strategische Prinzipien<br />
Der Entwerfer sollte die Begriffswelt und typische Abläufe <strong>der</strong><br />
Anwendung kennen, aber auch mit ihrer Arbeitsumgebung vertraut<br />
sein. Dazu gehört die technische Umgebung genauso wie die soziale<br />
Umgebung, die aus den Benutzern und den geltenden Gesetzen<br />
und Standards besteht. Nur dann können die optimale Architektur<br />
und geeignete Algorithmen gewählt werden.<br />
Sowohl die Entwickler als auch die Wartungsprogrammierer sollen<br />
in <strong>der</strong> Lage sein, den Entwurf vollständig zu verstehen. Dies wird<br />
durch hierarchische Strukturierung, Abstraktion und Einfachheit <strong>der</strong><br />
einzelnen Komponenten erleichtert. Außerdem muss <strong>der</strong> Entwurf<br />
gut dokumentiert sein.<br />
Der intellektuelle Abstand ist <strong>der</strong> Unterschied (z. B. in <strong>der</strong> Struktur)<br />
zwischen dem Problem und <strong>der</strong> Software-Lösung. Um einen geringen<br />
intellektuellen Abstand zu erreichen, sollten sich die relevanten<br />
Begriffe <strong>der</strong> Problemwelt (in <strong>der</strong> Regel die reale Welt) möglichst originalgetreu<br />
in <strong>der</strong> Lösung wie<strong>der</strong>finden.<br />
Konzeptionelle Integrität bedeutet, dass <strong>der</strong> gesamte Entwurf einem<br />
einheitlichen Stil folgen soll. Der Entwurf soll am Ende so aussehen,<br />
als sei er von einer einzigen Person geschaffen worden.<br />
Alle Realisierungsentscheidungen sollen in Module gekapselt und<br />
so vor dem Rest des Systems verborgen werden. Die Modulschnittstelle<br />
soll also über die innere Struktur möglichst wenig Auskunft<br />
geben. Gerade bei Entscheidungen, die sich wahrscheinlich än<strong>der</strong>n,<br />
ist das hilfreich.<br />
Komplexität erschwert das Verständnis und damit die intellektuelle<br />
Kontrolle. Daher sollte sie so gering wie möglich sein.<br />
Jede Form von Redundanz stellt ein Risiko dar, da es bei Än<strong>der</strong>ungen<br />
leicht zu Inkonsistenzen kommt. Stattdessen sollte eine Funktion<br />
an genau einer Stelle realisiert werden.