Objektorientierte Programmierung
LVA 185.162, VL 2.0, 2008 W

Hinweise zur Beurteilung der 4. Übungsaufgabe

Einleitung:

Die vorläufige Beurteilung der 4. Aufgabe (reguläre Abgabe) ist ausgesprochen schlecht ausgefallen. Diese Seite soll die häufigsten und wichtigsten Fehler, die dabei gemacht wurden, aufzeigen, weitere Hinweise zum Erkennen und zur Vermeidung der Fehler geben, die wahrscheinlichsten Gründe für das Zustandekommen der Fehler erklären und das Beurteilungsschema kurz erläutern.

Bei einer nachträglichen Abgabe ist zu beachten, dass die Beanstandung konkreter Fehler der regulären Abgabe keine direkten Rückschlüsse auf eine korrekte Lösung zulässt. Durch das Ausbessern dieser Fehler wird die Lösung nicht notwendigerweise richtig, sondern kann andere (nicht selten noch schwerwiegendere) Fehler enthalten. Versuchen Sie daher, die Gründe für Ihre Fehler und die richtige Lösung zu verstehen.

Schwerwiegendste Fehler:

Die Aufgabe ist so aufgebaut, dass die Untertypbeziehungen zwischen den geforderten Typen eindeutig sind. Das wurde leider nur selten erkannt. Außerdem wurden einige Empfehlungen in der Aufgabenstellung, die bei der Erkennung falscher Lösungen helfen sollten, nicht beachtet. Folgende Klassen von Fehlern können unterschieden werden:
Untertypbeziehung angenommen, wo keine besteht:
Das ist der häufigste Grund für starke Punkteabzüge. Durch die genaue Beschreibung der geforderten Typen besteht wenig Spielraum beim Entwurf geeigneter Untertypbeziehungen. Trotzdem wurden alle möglichen Arten von Untertypbeziehungen angenommen, die nach dem Ersetzbarkeitsprinzip gar nicht existieren können. Die Methode print ist hauptsächlich davon betroffen. Starke Punkteabzüge kommen vor allem daher, dass falsche Untertypbeziehungen ein wichtiger Grund für schwerwiegende Softwarefehler und nicht wartbaren Code in praktisch eingesetzten Systemen sind.
Keine Untertypbeziehung angenommen, wo eine bestehen könnte:
Das kommt nicht so häufig vor, führt aber auch zu starken Punkteabzügen, da das Erkennen von Untertypbeziehungen der wichtigste Schwerpunkt dieser Aufgabe ist. Die Punkteabzüge sind weniger stark als im umgekehrten Fall, da solche Fehler zwar die Wartung erschweren, aber nicht zu falschem Verhalten der Software führen.
Uminterpretation der Aufgabenstellung:
Mehrfach wurde die Aufgabenstellung so uminterpretiert (das heißt, die Vorgaben in der Aufgabenstellung bewusst und durch Kommentare dokumentiert abgeändert), dass der Zweck der Aufgabe nicht mehr erreicht werden kann. In solchen Fällen gibt es starke Punkteabzüge, da angenommen werden muss, dass die Uminterpretation eine Ursache im Nichtverstehen der korrekten Untertypbeziehungen hat. Außerdem enthällt in fast allen dieser Fälle auch die Lösung der uminterpretierten Aufgabe schwerwiegende Fehler in den Untertypbeziehungen.
Keine, nicht hinreichende oder zu ungenaue Zusicherungen:
Untertypbeziehungen beruhen zum größten Teil auf Zusicherungen. Bei den meisten Lösungen waren die Zusicherungen in der einen oder anderen Form mangelhaft. Vor allem haben sich nur die wenigsten Gruppen die Mühe gemacht, die Nachbedingungen auf print deutlich zu machen, auf die es in dieser Aufgabe letztlich am meisten ankommt. Für mangelhafte Zusicherungen wurden nicht sehr viele, aber doch merklich Punkte abgezogen. Man muss aber annehmen, dass grobe Fehler in den Unterypbeziehungen häufig eine Ursache in mangelhaften Zusicherungen haben und daher entscheidende Punkteabzüge durch bessere Zusicherungen vermeidbar gewesen wären.
Fehlende oder unzureichende Tests der Ersetzbarkeit:
In sehr vielen Fällen wurde die Ersetzbarkeit gar nicht oder auf nur absolut unzureichende Weise getestet. Durch geeignete Tests hätten die gröbsten Fehler in den Untertypbeziehungen aufgedeckt werden können. In einigen Fällen haben Tests sogar Fehler aufgedeckt, aber die falschen Untertypbeziehungen wurden trotzdem nicht als solche erkannt. Für mangelhafte Tests wuden zwar häufig aber nur moderat Punkte abgezogen.
Konzentration auf Unwesentliches:
In einigen Lösungen wurde viel Aufwand für Nebensächlichkeiten betrieben. Beispielsweise wurde umfangreich überprüft, ob die Bedingungen beim Setzen der Größe erfüllt sind, obwohl das (bei Interpretation der Bedingungen als Vorbedingungen) gar nicht nötig gewesen wäre. Dafür wurden natürlich keine Punkte abgezogen, da es sich ja um keine Fehler im Sinne der Aufgabenstellung handelt. Indirekt hat die Konzentration auf Unwesentliches aber den Blick auf das Wesentliche verstellt und möglicherweise falsche Untertypbeziehungen nicht erkennen lassen.

Ersetzbarkeit:

Folgende Hinweise beziehen sich nur auf einige wenige Beziehungen zwischen den in dieser Aufgabe vorgegebenen Typen, die exemplarisch dargestellt werden. Es werden nicht alle denkbaren Beziehungen angesprochen.
Ist BlackBox Untertyp von GreyBox?
Um diese Frage zu beantworten, brauchen wir nur die beiden Beschreibungen (genauer: die Zusicherungen) der Typen gegenüberstellen. Die Frage ist entsprechend dem Ersetzbarkeitsprinzip mit Ja zu beantworten, wenn die Nachbedingungen und Invarianten in BlackBox jenen in GreyBox entsprechen, aber möglicherweise genauer sind (also auf mehr Details eingehen), und die Vorbedingungen in GreyBox jenen von BlackBox entsprechen, aber möglicherweise genauer sind.

Wir betrachten (vereinfachte) Nachbedingungen auf print: In einer Instanz von BlackBox gibt print ein Rechteck bestehend aus einem Zeichen aus, das zuvor mit setFrameChar festgelegt werden kann, während print in einer Instanz von GreyBox ein Rechteck ausgibt, dessen Randzeichen über setFrameChar festgelegt werden kann, dessen Füllzeichen aber immer gleich bleibt. Alleine daraus können wir schon folgern, dass BlackBox kein Untertyp von GreyBox ist: Ein Aufruf von setFrameChar gefolgt von einem Aufruf von print muss in BlackBox etwas anderes ausgeben als in GreyBox (außer in dem Spezialfall, in dem das Argument von setFrameChar gleich dem im Konstruktor von GreyBox gesetzten Zeichen ist). Da sowohl BlackBox als auch GreyBox genau festlegen, was ausgegeben werden muss, und sich die Ausgaben unterscheiden, kann zwischen diesen Typen keine Untertypbeziehung hergestellt werden.

Einige Gruppen haben die Nachbedingungen von print (vielleicht unabsichtlich) so abgeändert, dass sich auch das Füllzeichen einer GreyBox durch einen Aufruf von setFrameChar im angenommenen Untertyp ändern kann. In diesem Fall wäre eine Untertypbeziehung gegeben. Manchmal war die Nachbedingung auch so unklar beschrieben, dass man ein solches Verhalten durchaus hineininterpretieren könnte. Da aber die eigentliche Aufgabe nicht gelöst wurde, wurden in solchen Fällen genau so viele Punkte wie für eine falsche angenommene Untertypbeziehung mit der Aufgabe entsprechenden Zusicherungen abgezogen - und oft noch zusätzliche Punkte für schlechte Zusicherungen.

Ist WhiteBox Untertyp von GreyBox?
Diese Untertypbeziehung ist tatsächlich gegeben: Eine Instanz von WhiteBox entspricht einer Instanz von GreyBox, wobei das Leerzeichen als Füllzeichen verwendet wird. Dadurch entsprechen einander auch die Zusicherungen aller Instanzmethoden der beiden Klassen, wenn das Füllzeichen entsprechend gesetzt ist. Diese Beziehung wurde häufig richtig erkannt.
Ist GreyBox Untertyp von WhiteBox?
Anders gefragt: Sind GreyBox und WhiteBox äquivalent? Eine Instanz von WhiteBox entspricht einer von GreyBox nur dann, wenn das Leerzeichen als Füllzeichen verwendet wird. Daher ist nicht jede Instanz von GreyBox auch eine von WhiteBox, und GreyBox ist kein Untertyp von WhiteBox.

Fehlerursachen:

Die tatsächlichen Ursachen für die schwerwiegendsten Fehler können nur vermutet werden. Folgende Punkte spielen aber sicherlich eine Rolle:
Verwechslung von Untertyp- mit is-a-Beziehungen:
Viele Teilnehmer haben den Umgang mit is-a-Beziehungen schon in anderen Lehrveranstaltungen gelernt. Solche aus der realen Welt abgeleitete Beziehungen sind vor allem in einer frühen Designphase wichtig, um Softwareeinheiten in Relation zueinander zu setzen und dadurch zu brauchbaren Fakorisierungen zu kommen. Häufig lassen sich is-a-Beziehungen zu Untertypbeziehungen weiterentwickeln, aber nicht immer. Diese Aufgabe wurde absichtlich so gewählt, dass is-a-Beziehungen kaum zu Untertypbeziehungen weiterentwickelt werden können, damit Verwechslungen zwischen diesen Beziehungen möglichst ausgeschlossen werden. Es geht in dieser Aufgabe nicht darum, intuitiv abzuschätzen, ob und wie je zwei Typen zueinander in Beziehung stehen könnten (das wäre eine is-a-Beziehung), sondern ausschließlich darum, ob die Beschreibung eines Typs auch der Beschreibung eines anderen Typs (für alle möglichen Verwendungsfälle) entspricht. Wer das Gefühl hat, dass die Aufgabe je nach Sichtweise verschiedene Lösungen haben kann, hat diese beiden Arten von Beziehungen mit großer Wahrscheinlichkeit miteinander verwechselt. Untertypbeziehungen sind (bei ausreichend klar formulierten Zusicherungen) im Gegensatz zu is-a-Beziehungen immer eindeutig.
Verwechslung von Untertyp- mit Vererbungs-Beziehungen:
Einige Teilnehmer haben Untertypbeziehungen offensichtlich mit Vererbungsbeziehungen verwechselt. Dadurch lassen sich beispielsweise Kommentare wie jener erklären, dass ColoredBox ein Untertyp von GreyBox sei, weil nur eine Methode zum Setzen des Füllzeichens hinzukommt. Ein solcher Kommentar ist komplett falsch und hat gar nichts mit Ersetzbarkeit zu tun.
Verlassen auf Erfahrung und Intuition statt auf konkrete Grundlagen:
Bei dieser Aufgabe haben offensichtlich auch Gruppen, deren Mitglieder schon einiges an Programmiererfahrung haben, versagt. Ein Mitgrund dürfte darin liegen, dass diese Gruppen die Aufgaben nur nach Intuition lösen, ohne auf den in den Vorlesungen und im Skriptum behandelten Stoff einzugehen. Eine typische Folge davon ist beispielsweise die Verwechslung von Untertyp- mit is-a-Beziehungen. Alle zur Lösung dieser Aufgabe notwendigen Grundlagen wurden in den Vorlesungen ausführlich behandelt. Es fehlt aber gelegentlich der Mut, den neu erlernten Stoff auch in die Praxis umzusetzen, und es erscheint fälschlicherweise sicherer, sich auf (unzureichende) eigene Erfahrungen zu verlassen, als sich auf ein ungekanntes Gebiet zu begeben. Jetzt ist der Punkt gekommen, wo das Vorwissen alleine bei vielen Teilnehmern nicht mehr ausreicht, um die Aufgaben gut zu lösen. In einigen Fällen haben Testergebnisse sogar klare Verletzungen der Ersetzbarkeit gezeigt - ein deutlicher Hinweis darauf, dass der Begriff der Ersetzbarkeit ganz und gar nicht verstanden (oder vielleicht noch nicht einmal der entsprechende Abschnitt im Skriptum angeschaut) wurde.
In falscher Selbstsicherheit gewogen:
Die Aufgabe erscheint sehr einfach, ist es aber nicht. Davor wurde mehrfach gewarnt. Anscheinend hat es so manche Gruppe verabsäumt, aufgrund der scheinbaren Einfachheit genauer hinzuschauen. Das oben angesprochene Verlassen auf eigene Erfahrung und Intuition dürfte auch dazu beigetragen haben.
Zuwenig Selbstvertrauen:
Bei einigen Gruppen dürfte auch der gegenteilige Effekt eine Rolle gespielt haben: Durch zuviel Respekt vor der Aufgabe haben es manche nicht gewagt, Zusicherungen in ihren eigenen Worten zu formulieren und haben damit auf ein wichtiges Kontrollinstrument verzichtet. Sicher haben sich viele eher auf irgendwelche in Forumsdiskussionen oder sonst irgendwo im Internet angebotene (falsche, unvollständige oder einfach nicht auf die Aufgabenstellung zugeschnittene) Informationen als auf das eigene Wissen verlassen. Dadurch ist vermutlich so manches Problem, das seinen Ursprung in falscher Selbstsicherheit gehabt hat, auf die Gruppen mit wenig Selbstvertrauen übertragen worden.
Hinweise ignoriert:
In der Aufgabenstellung wurden mehrere Hinweise dazu gegeben, wie die Korrektheit der Lösung sichergestellt werden kann. Diese wurden in manchen Bereichen aber komplett ignoriert. Beispielsweise hat kaum jemand die Zusicherungen auf print von einer Oberklasse (nicht dem vorgegebenen Interface) in die Unterklasse übernommen. Gerade dadurch hätten widersprüchliche Beschreibungen bei falschen Untertypbeziehungen auffallen müssen. Untertypbeziehungen wurden, wenn überhaupt, meist nur sehr oberflächlich getestet. Die Hinweise sind (auch bei allen folgenden Aufgaben) so angelegt, dass die bedeutendsten Fehler damit leicht selbst gefunden werden können.

Beurteilungsschema

Für ein abgegebenes Programm, das sich übersetzen lässt, gibt es 100 Punkte. Davon werden für Fehler im Programm Punkte abgezogen. Generell gibt es mehrere Klassen von Fehlern mit je einer eigenen maximalen Anzahl von abgezogenen Punkten: Einige Fehlerklassen stehen in enger Beziehung zueinander. Diese werden in der Beurteilung berücksichtigt. Wenn beispielsweise wichtige fehlende Zusicherungen zu einem Punkteabzug von 9 Punkten führen, dann wurden für eine falsche Untertypbeziehung nur mehr 30 Punkte abgezogen, wenn die mangelhaften Zusicherungen als Mitverursacher der falschen Untertypbeziehung angesehen werden können. Ebenso wurden für fehlende Tests falscher Untertypbeziehungen nur 6 Punkte abgezogen, da Probleme im Umgang mit Untertypbeziehungen schon in den deutlich stärkeren Abzügen für Fehler in den Untertypbeziehungen berücksichtigt sind.
Complang
Puntigam
   Kontakt
   Research
   Lehre
      OOP
      Typsysteme
      EP2
      FOOP
      Prog.spr.
      frühere Lehre
         LVAs 2017 W
         LVAs 2017 S
         LVAs 2016 W
         LVAs 2016 S
         LVAs 2015 W
         LVAs 2015 S
         LVAs 2014 W
         LVAs 2014 S
         LVAs 2013 W
         LVAs 2013 S
         LVAs 2012 W
         LVAs 2012 S
         LVAs 2011 W
         LVAs 2011 S
         LVAs 2010 W
         LVAs 2010 S
         LVAs 2009 W
         LVAs 2009 S
         LVAs 2008 W
            OOP
               Laborübung
               1. Aufgabe
               2. Aufgabe
               3. Aufgabe
               4. Aufgabe
                  Beurteilung
               5. Aufgabe
               6. Aufgabe
               7. Aufgabe
               8. Aufgabe
               9. Aufgabe
               Cacao
            Typsysteme
            Seminar
         LVAs 2008 S
         LVAs 2007 W
         LVAs 2007 S
         LVAs 2006 W
         LVAs 2006 S
         LVAs 2005 W
         LVAs 2005 S
         LVAs 2004 W
         LVAs 2004 S
         LVAs 2003 W
   Links
Sitemap
Kontakt
Schnellzugriff:
Laborübung
4. Aufgabe
Skriptum
Folien
Fakultät für Informatik
Technische Universität Wien
Anfang | HTML 4.01 | Datenschutzerklärung | letzte Änderung: 2008-11-10 (Puntigam)