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
58 5 Ein Referenzmodell für den objektorientierten Entwurf CBO. Außerdem wird, wie bei WMC, keine Aussage darüber gemacht, welche Methoden eigentlich mitzählen. Lack of Cohesion in Methods (LCOM). Diese Metrik soll den Zusammenhalt der Methoden einer Klasse erfassen, indem deren Ähnlichkeit betrachtet wird. Die Ähnlichkeit zweier Methoden ist hier die Anzahl der Attribute der Klasse, auf die beide zugreifen. LCOM ist definiert als die Anzahl von Methodenpaaren mit Ähnlichkeit 0 (keine gemeinsamen Attribute) minus die Anzahl der Paare mit einer Ähnlichkeit größer 0. Falls das Ergebnis kleiner als 0 ist, wird LCOM zu 0 gesetzt. Je geringer LCOM, desto besser. Wie bei CBO scheitert die Formalisierung daran, dass Information über die Zugriffe von Methoden auf Attribute benötigt wird. Fazit. DIT und NOC können leicht formalisiert werden, weil sie sich auf die Vererbungshierarchie beziehen, die Teil des Architekturentwurfs ist. Die Metriken CBO, RFC und LCOM benötigen mehr detaillierte Information zur Messung, als ODEM bieten kann. WMC kann in seiner Standardform formalisiert werden, allerdings ist die ursprüngliche Definition zu ungenau, um eine eindeutige Formalisierung zu erlauben. Zusammenfassung Die Paketmetriken von Martin (1995) lassen sich problemlos formalisieren; gleichzeitig wurden bei der Formalisierung Lücken in der Definition aufgedeckt. Von den Klassenmetriken von Chidamber und Kemerer (1994) lässt sich hingegen nur ein Teil formalisieren. Für die übrigen Metriken ist eine Formalisierung auf der Basis von ODEM nicht möglich, weil dafür detaillierte Informationen über die Aufrufbeziehungen von Methoden und den Zugriff von Methoden auf Attribute vorausgesetzt werden. Diese Informationen sind in UML-Modellen aber selten verfügbar und daher in ODEM nicht vorhanden. Es handelt sich bei CBO, RFC und LCOM genau genommen eher um Code-Metriken als um Entwurfsmetriken. ODEM ist sehr gut zur Definition von Metriken für den objektorientierten Entwurf geeignet, sofern sich die benötigte Information aus UML-Modellen (insbesondere aus Klassendiagrammen) gewinnen lässt. Das belegt auch die erfolgreiche Nutzung von ODEM in dieser Arbeit bei der Definition der Metriken von QOOD (vgl. Anhang A).
Kapitel 6 Softwarequalität Quality … you know what it is, yet you don’t know what it is. But that’s self-contradictory. But some things are better than others, that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There’s nothing to talk about. But if you can’t say what Quality is, how do you know what it is, or how do you know that it even exists? If no one knows what it is, then for all practical purposes it doesn’t exist at all. But for all practical purposes it really does exist. What else are the grades based on? Why else would people pay fortunes for some things and throw others in the trash pile? Obviously some things are better that others … but what’s the “betterness”? … So round and round you go, spinning mental wheels and nowhere finding anyplace to get traction. What the hell is Quality? What is it? (Pirsig, 1981, S. 163f.) In diesem Kapitel wird der Qualitätsbegriff erst allgemein und dann spezifisch für Software diskutiert. Softwarequalität wird häufig durch Qualitätsmodelle definiert, daher werden Ansätze und Beispiele für solche Modelle vorgestellt. Den Abschluss bildet eine kurze Diskussion zur Qualitätssicherung. 6.1 Qualität 6.1.1 Definition Das Wort „Qualität“ kommt vom lateinischen Wort qualitas (Beschaffenheit) und beschreibt die Güte oder den Wert eines Objekts. DIN 55350 definiert den Begriff Qualität ähnlich, aber nicht gleich wie die Deutsche Gesellschaft für Qualität (DGQ). Definition 6-1 (Qualität, DIN 55350-11:1987-05) Die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Tätigkeit, die sich auf die Eignung zur Erfüllung gegebener Erfordernisse bezieht. Definition 6-2 (Qualität, DGQ, 1995) Die Gesamtheit von Merkmalen (und Merkmalswerten) einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen. 59
- Seite 17 und 18: Kapitel 2 Modelle und Metriken In d
- Seite 19 und 20: 2.2 Metriken 9 2.1.2 Beispiele […
- Seite 21 und 22: 2.2 Metriken 11 Merkmalsart Qualita
- Seite 23 und 24: 2.2 Metriken 13 Definition 2-2 (qua
- Seite 25 und 26: Kapitel 3 Objektorientierung What i
- Seite 27 und 28: 3.1 Begriffe 17 Klasse Person mit A
- Seite 29 und 30: 3.1 Begriffe 19 3.1.5 Abstrakte Kla
- Seite 31 und 32: 3.2 Unified Modeling Language 21 3.
- Seite 33 und 34: Kapitel 4 Objektorientierter Entwur
- Seite 35 und 36: 4.1 Was ist Entwurf? 25 rungen im C
- Seite 37 und 38: 4.2 Klassifikationen des Entwurfs 2
- Seite 39 und 40: 4.2 Klassifikationen des Entwurfs 2
- Seite 41 und 42: 4.3 Muster und Rahmenwerke 31 und P
- 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: 5.5 Formale Definition von Metriken
- 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 und 94: 7.3 Entwurfsregeln 83 Produkt 1 Pro
- Seite 95 und 96: 7.3 Entwurfsregeln 85 Prinzip Besch
- 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
Kapitel 6<br />
Softwarequalität<br />
Quality … you know what it is, yet you don’t know what it is. But that’s self-contradictory.<br />
But some things are better than others, that is, they have more quality. But when you try to say<br />
what the quality is, apart from the things that have it, it all goes poof! There’s nothing to talk<br />
about. But if you can’t say what Quality is, how do you know what it is, or how do you know<br />
that it even exists? If no one knows what it is, then for all practical purposes it doesn’t exist at<br />
all. But for all practical purposes it really does exist. What else are the grades based on? Why<br />
else would people pay fortunes for some things and throw others in the trash pile? Obviously<br />
some things are better that others … but what’s the “betterness”? … So round and round you<br />
go, spinning mental wheels and nowhere finding anyplace to get traction. What the hell is<br />
Quality? What is it?<br />
(Pirsig, 1981, S. 163f.)<br />
In diesem Kapitel wird <strong>der</strong> <strong>Qualität</strong>sbegriff erst allgemein und dann spezifisch für<br />
Software diskutiert. Softwarequalität wird häufig durch <strong>Qualität</strong>smodelle definiert,<br />
daher werden Ansätze und Beispiele für solche Modelle vorgestellt. Den Abschluss<br />
bildet eine kurze Diskussion zur <strong>Qualität</strong>ssicherung.<br />
6.1 <strong>Qualität</strong><br />
6.1.1 Definition<br />
Das Wort „<strong>Qualität</strong>“ kommt vom lateinischen Wort qualitas (Beschaffenheit) und<br />
beschreibt die Güte o<strong>der</strong> den Wert eines Objekts. DIN 55350 definiert den Begriff <strong>Qualität</strong><br />
ähnlich, aber nicht gleich wie die Deutsche Gesellschaft für <strong>Qualität</strong> (DGQ).<br />
Definition 6-1 (<strong>Qualität</strong>, DIN 55350-11:1987-05)<br />
Die Gesamtheit von Eigenschaften und Merkmalen eines Produktes o<strong>der</strong> einer Tätigkeit, die<br />
sich auf die Eignung zur Erfüllung gegebener Erfor<strong>der</strong>nisse bezieht.<br />
Definition 6-2 (<strong>Qualität</strong>, DGQ, 1995)<br />
Die Gesamtheit von Merkmalen (und Merkmalswerten) einer Einheit bezüglich ihrer Eignung,<br />
festgelegte und vorausgesetzte Erfor<strong>der</strong>nisse zu erfüllen.<br />
59