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
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
7.3 Entwurfsregeln 87<br />
7.3.2 Heuristiken<br />
Useful suggestions about quality, when they are brought to our attention, usually strike us at<br />
once as familiar and revelatory. We see them as sensible, reflecting what we have felt but perhaps<br />
not expressed.<br />
(Dromey, 1996, S. 43)<br />
Eine Heuristik ist eine Daumenregel, die meistens funktioniert, aber nicht immer optimale<br />
Ergebnisse liefert. Daher ist eine Heuristik im Gegensatz zum Prinzip nicht allgemein<br />
gültig, son<strong>der</strong>n es muss anhand des Kontextes entschieden werden, ob ihr<br />
Einsatz an einer bestimmten Stelle im Entwurf sinnvoll ist.<br />
Eine <strong>der</strong> ersten Sammlungen von Heuristiken stammt von Korson und McGregor<br />
(1990, S. 54). Riel (1996) veröffentlichte die bisher umfangreichste Sammlung, aber<br />
auch Booch et al. (1998) führen in ihrem UML-Handbuch viele Heuristiken auf. Weitere<br />
Heuristiken finden sich z. B. bei Firesmith (1995), Lakos (1996) und Johnson und<br />
Foote (1988).<br />
Die Heuristiken lassen sich in fünf Bereiche einteilen: Heuristiken für Klassen, Interfaces,<br />
Pakete, Vererbungsbeziehungen und sonstige Beziehungen. Tabelle 7-4 zeigt<br />
einige Beispiele für jede Kategorie (siehe auch Reißing, 2002).<br />
Heuristiken für Klassen<br />
Die Klasse soll eine abgegrenzte Abstraktion eines Begriffs aus dem Problem- o<strong>der</strong> Lösungsbereich<br />
sein (Booch et al., 1998).<br />
Die Klasse soll eine kleine, wohldefinierte Menge von Verantwortlichkeiten enthalten und diese<br />
alle gut ausführen (Booch et al., 1998).<br />
Die Attribute und Operationen <strong>der</strong> Klassen sollen (wirklich) notwendig sein, um die Verantwortlichkeiten<br />
<strong>der</strong> Klasse zu realisieren (Booch et al., 1998).<br />
Enthält eine Klasse zu viele Verantwortlichkeiten, sollen diese auf neue Klassen verteilt werden<br />
(Booch et al., 1998).<br />
Enthält eine Klasse zu wenig Verantwortlichkeiten, soll sie mit an<strong>der</strong>en Klassen zusammengefasst<br />
werden (Booch et al., 1998).<br />
Die Klasse soll eindeutig zwischen <strong>der</strong> Schnittstelle und <strong>der</strong> Implementierung <strong>der</strong> Abstraktion<br />
trennen (Booch et al., 1998).<br />
Die Klasse soll verständlich und einfach sein, aber trotzdem erweiterbar und anpassbar (Booch<br />
et al., 1998).<br />
Die öffentliche Schnittstelle einer Klasse soll nur aus Operationen bestehen (Korson, McGregor,<br />
1990).<br />
Jede Methode einer Klasse soll Attribute <strong>der</strong> Klasse verwenden (lesend o<strong>der</strong> schreibend) (Korson,<br />
McGregor, 1990).<br />
Tabelle 7-4: Heuristiken (Abschnitt 1 von 2)
Change language