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
40 4 Objektorientierter Entwurf Budgen (1994) bezeichnet den Entwurf sogar als ein bösartiges Problem (wicked problem). Bösartige Probleme sind nach Rittel und Webber (1984) unter anderem durch folgende Eigenschaften gekennzeichnet: • Es gibt keine endgültige Formulierung des Problems. Ein Grund dafür ist, dass sich Spezifikation und Entwurf nicht klar trennen lassen (Swartout, Balzer, 1982). • Es gibt keine Regel, die angibt, wann die optimale Lösung gefunden wurde. Das liegt daran, dass die Bewertung einer Lösung schwierig ist, weil es (meistens) keine klare Festlegung aller gewünschten Eigenschaften gibt (es fehlt also ein Qualitätsmodell). • Lösungen für bösartige Probleme sind nicht richtig oder falsch, sondern gut oder schlecht. Es gibt keine wirklich falsche Lösung, nur weniger oder besser brauchbare. Daher ist es schwierig, den Suchraum wirksam einzugrenzen. • Teilaspekte des Problems können nicht unabhängig voneinander gelöst werden. Die Lösung für einen Teilaspekt des Problems kann neue Probleme in anderen Teilaspekten verursachen oder deren Lösung unmöglich machen. Beim Entwurf handelt es sich um ein Problem, bei dem sowohl dialektische Barrieren als auch Interpolations- und Synthesebarrieren vorliegen. Der Entwurf gehört also in die „schlimmste“ Problemklasse. Das Operatoreninventar ist hochgradig offen, es sind also fast immer Synthesebarrieren vorhanden. Selbst wenn irgendwann klar ist, welche Operatoren zu verwenden sind, ist ihre konkrete Verwendung immer noch ein Interpolationsproblem. Welche Ansätze ein Entwerfer verfolgt, hängt so von seiner Intuition, seinem Wissen und seiner Erfahrung ab. Dabei kommen auch Gewohnheiten und Denkbarrieren zum Tragen. Ein Ansatz, um das Syntheseproblem in ein Interpolationsproblem zu überführen, ist es, ein möglichst großes Operatoreninventar von Mustern (Architekturmuster, Entwurfsmuster etc.) anzulegen. Die dialektische Barriere entsteht dadurch, dass die Spezifikation zwar die Kriterien für den Zielzustand vorgibt, es aber immer noch beliebig viele geeignete Zielzustände gibt. Es gibt also eine große Anzahl von Wahlmöglichkeiten, die der Entwerfer beim Entwickeln einer Lösung zu einer gegebenen Menge von Anforderungen hat (Boehm, 1976). Der Entwerfer ist daher gezwungen, verschiedene Alternativen auszuarbeiten. Unter den so entstehenden alternativen Lösungsansätzen ist es schwer zu wählen. An die Frage: Welches ist die beste Alternative? schließt sich gleich die Frage an: Wie können die Alternativen bewertet werden, um statt einer gefühlsmäßigen eine möglichst objektive Antwort zu erhalten? Ein Ansatz dazu ist die Verwendung eines Qualitätsmodells, das die Zielkriterien, die der Entwurf zu erfüllen hat, klar definiert. Dadurch wird das dialektische Problem näher an ein Interpolationsproblem herangebracht. Entwurfsausbildung Eine einfache Lösung für den Umgang mit der fundamentalen Komplexität des Entwurfs gibt es nicht. Man kann allerdings bei der Ausbildung der Entwerfer ansetzen, um diese so gut wie möglich auf ihre Aufgabe vorzubereiten. Brooks (1987, S. 18) stellt fest: “Great designs come from great designers.” Nach Brooks wäre es am besten, großartige Entwerfer auszubilden und nur diese einzusetzen. Einen solchen Entwerfer zeichnen aus (Curtis et al., 1988; Visser, Hoc, 1990):
4.5 Probleme des Entwurfs 41 • die Vertrautheit mit dem Anwendungsbereich (siehe auch Adelson, Soloway, 1985; Dvorak, Moher, 1991), • die Fähigkeit, die technische Vision den anderen Projektmitgliedern mitzuteilen, da der Entwurf oft durch Kommunikation mit anderen entsteht, • die Identifikation mit dem Projekterfolg und • eine opportunistische Vorgehensweise, d. h. Entscheidungen zu vertagen, so lange die benötigten Informationen noch nicht vorliegen, und auf Grund vorliegender Informationen zukünftige Entwicklungen (z. B. zu erwartende Erweiterungen) vorwegzunehmen. Leider haben aber nur wenige Entwickler das Potential, großartige Entwerfer zu werden. Brooks (1987, S. 18) meint: “We can get good designs by following good practices”, also ist das wohl der Weg, den gewöhnliche Entwerfer einschlagen sollten. In der Ausbildung sind die guten Praktiken zu lehren, z. B. in Form von Entwurfsregeln. Zusätzlich sollte vermittelt werden, welche bewährten Lösungen es gibt und unter welchen Umständen sie funktionieren, z. B. in Form der bereits erwähnten Muster. Aber auch Lösungen, die nicht funktionieren, sollten dokumentiert und weitergegeben werden (Petroski, 1992, 1994), z. B. in Form von Anti-Mustern (antipatterns; Koenig, 1995; Brown et al., 1998). Das Wissen über mögliche Lösungsansätze sollte eingebettet sein in einen Rahmen, der angibt, welche Eigenschaften ein guter Entwurf hat. Dieser Rahmen, der nichts anderes als ein Qualitätsmodell ist, kann dann bei der Entscheidung herangezogen werden, wann eine der bewährten Lösungen angebracht ist und wann nicht. Pancake (1995, S. 42) schreibt: „The difficulty in both teaching and learning OT [=object technology] is that the quality of an OO design is difficult to evaluate.“ Das Problem liegt also in der Bewertung. Gerade der Bewertung nimmt sich diese Arbeit aber an. Erfahrung und Intuition sind für einen guten Entwerfer sehr wichtig (Budgen, 1994). Der Erwerb von Erfahrung ist aber langwierig und teuer: Man muss viele Systeme entwerfen und aus den gemachten Fehlern lernen. In der Regel werden aber die Systeme für reale Projekte entworfen und danach auch implementiert. Das kann zu enormen Fehlerfolgekosten führen, wenn schlecht entworfene Systeme überarbeitet werden müssen. Für den Erwerb der praktischen Erfahrung ist daher zu Beginn ihrer Berufspraxis die Beschäftigung als Lehrling bei einem guten, erfahrenen Entwerfer sinnvoll (McBreen, 2001). Auf diese Weise wird das oben skizzierte Lernen durch Instruktion mit Lernen durch Imitation kombiniert.
- Seite 1: Bewertung der Qualität objektorien
- Seite 5 und 6: Zusammenfassung In der Software-Ent
- Seite 7 und 8: Inhaltsverzeichnis 1 Danksagung....
- Seite 9 und 10: 12 Zusammenfassung und Ausblick....
- Seite 11 und 12: Kapitel 1 Einführung Design is one
- Seite 13 und 14: 1.2 Zielsetzung 3 Messverfahren. Da
- Seite 15 und 16: 1.4 Übersicht 5 Das allgemeine Qua
- 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: 4.5 Probleme des Entwurfs 39 Aufgab
- 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 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
4.5 Probleme des Entwurfs 41<br />
• die Vertrautheit mit dem Anwendungsbereich (siehe auch Adelson, Soloway, 1985;<br />
Dvorak, Moher, 1991),<br />
• die Fähigkeit, die technische Vision den an<strong>der</strong>en <strong>Projekt</strong>mitglie<strong>der</strong>n mitzuteilen, da<br />
<strong>der</strong> Entwurf oft durch Kommunikation mit an<strong>der</strong>en entsteht,<br />
• die Identifikation mit dem <strong>Projekt</strong>erfolg und<br />
• eine opportunistische Vorgehensweise, d. h. Entscheidungen zu vertagen, so lange<br />
die benötigten Informationen noch nicht vorliegen, und auf Grund vorliegen<strong>der</strong><br />
Informationen zukünftige Entwicklungen (z. B. zu erwartende Erweiterungen)<br />
vorwegzunehmen.<br />
Lei<strong>der</strong> haben aber nur wenige Entwickler das Potential, großartige Entwerfer zu werden.<br />
Brooks (1987, S. 18) meint: “We can get good designs by following good practices”,<br />
also ist das wohl <strong>der</strong> Weg, den gewöhnliche Entwerfer einschlagen sollten. In<br />
<strong>der</strong> Ausbildung sind die guten Praktiken zu lehren, z. B. in Form von Entwurfsregeln.<br />
Zusätzlich sollte vermittelt werden, welche bewährten Lösungen es gibt und unter<br />
welchen Umständen sie funktionieren, z. B. in Form <strong>der</strong> bereits erwähnten Muster.<br />
Aber auch Lösungen, die nicht funktionieren, sollten dokumentiert und weitergegeben<br />
werden (Petroski, 1992, 1994), z. B. in Form von Anti-Mustern (antipatterns; Koenig,<br />
1995; Brown et al., 1998). Das Wissen über mögliche Lösungsansätze sollte eingebettet<br />
sein in einen Rahmen, <strong>der</strong> angibt, welche Eigenschaften ein guter Entwurf hat.<br />
Dieser Rahmen, <strong>der</strong> nichts an<strong>der</strong>es als ein <strong>Qualität</strong>smodell ist, kann dann bei <strong>der</strong> Entscheidung<br />
herangezogen werden, wann eine <strong>der</strong> bewährten Lösungen angebracht ist<br />
und wann nicht. Pancake (1995, S. 42) schreibt: „The difficulty in both teaching and<br />
learning OT [=object technology] is that the quality of an OO design is difficult to<br />
evaluate.“ Das Problem liegt also in <strong>der</strong> <strong>Bewertung</strong>. Gerade <strong>der</strong> <strong>Bewertung</strong> nimmt<br />
sich diese Arbeit aber an.<br />
Erfahrung und Intuition sind für einen guten Entwerfer sehr wichtig (Budgen, 1994).<br />
Der Erwerb von Erfahrung ist aber langwierig und teuer: Man muss viele Systeme<br />
entwerfen und aus den gemachten Fehlern lernen. In <strong>der</strong> Regel werden aber die Systeme<br />
für reale <strong>Projekt</strong>e entworfen und danach auch implementiert. Das kann zu enormen<br />
Fehlerfolgekosten führen, wenn schlecht entworfene Systeme überarbeitet werden<br />
müssen. Für den Erwerb <strong>der</strong> praktischen Erfahrung ist daher zu Beginn ihrer<br />
Berufspraxis die Beschäftigung als Lehrling bei einem guten, erfahrenen Entwerfer<br />
sinnvoll (McBreen, 2001). Auf diese Weise wird das oben skizzierte Lernen durch<br />
Instruktion mit Lernen durch Imitation kombiniert.