Objektorientierte Programmierung
LVA 185.162, VL 2.0, 2009 W

3. Laborübungsaufgabe

Themen:

Zusicherungen, Analyse des eigenen Programmcodes

Termine:

Ausgabe: 28.10.2009
reguläre Abgabe: 04.11.2009, 13:45 Uhr
nachträgliche Abgabe: 11.11.2009, 13:45 Uhr

Abgabeverzeichnis:

Gruppe/Aufgabe3

Grundlage:

Skriptum bis Seite 69 sowie 88 bis 90, Schwerpunkt auf Abschnitt 2.2

Aufgabe

Welche Aufgabe zu lösen ist:

Entfernen Sie aus einer Kopie des Programmcodes Ihrer Lösung der zweiten Aufgabe (inklusive Testprogramm) Kommentare und versehen Sie den Code mit neuen Kommentaren, die Zusicherungen in natürlicher Sprache (Deutsch oder Englisch) oder einfachen mathematischen Ausdrücken darstellen. Nach dieser Änderung sollen alle Kommentare als Zusicherungen lesbar sein. Als Ausnahmen sind nur die weiter unten beschriebenen speziellen Kommentare sowie organisatorische Kommentare (wie z.B. die Namen der Autoren) erlaubt. Lassen Sie organisatorische Kommentare, die nicht sowieso ganz klar als soche zu erkennen sind, mit ANMERKUNG: oder NOTE: beginnen. Alle notwendigen Zusicherungen sollen explizit im Programmcode stehen (und nicht beispielsweise durch Methodennamen oder die Aufgabenstellung als implizit gegeben angesehen werden). Die Abhängigkeiten zwischen den Programmteilen sollen durch Zusicherungen nicht unnötig verstärkt werden.

Vergewissern Sie sich, dass Clients nur das voraussetzen, was Server durch Zusicherungen versprechen, und Server nur das, was Clients versprechen, also alle Verträge in Ihrer Software eingehalten werden. Prüfen Sie auch nach, ob Zusicherungen überall dort, wo Sie eine Vererbungsbeziehung haben (durch extends oder implements), auch die Bedingungen für die Ersetzbarkeit erfüllen. Falls Sie Inkonsistenzen bemerken, die sich durch geschicktere Formulierung der Zusicherungen nicht einfach beheben lassen - das heißt, Sie haben inhaltliche Fehler entdeckt -, beschreiben Sie die Inkonsistenzen durch spezielle Kommentare, die mit FEHLER: oder ERROR: beginnen. Versuchen Sie auch, in wenigen Worten mögliche Ursachen für die Inkonsistenzen sowie (falls einfach möglich) nötige Programmänderungen zu deren Beseitigung zu beschreiben. Lassen Sie den Programmcode selbst (abgesehen von Kommentaren) aber unverändert.

Finden Sie etwa fünf bis zehn Stellen in Ihrem Programm, an denen

Schreiben Sie an jede dieser Stellen einen Kommentar, der mit GUT: oder GOOD: beginnt. Beschreiben Sie darin kurz, warum Sie diese Stelle gewählt und welche Überlegungen zur guten Lösung geführt haben. Falls Sie nicht mindestens fünf solche Stellen finden, schreiben Sie an den Anfang der Datei Test.java einen Kommentar, in dem Sie wahrscheinliche Gründe dafür nennen.

Finden Sie etwa fünf bis zehn Stellen in Ihrem Programm, an denen der Klassenzusammenhalt oder die Objektkopplung besonders schlecht sind oder durch Verzicht auf dynamisches Binden der Code größer oder unübersichtlicher wurde. Schreiben Sie an jede dieser Stellen einen Kommentar, der mit SCHLECHT: oder BAD: beginnt, und beschreiben Sie kurz, warum Sie diese Stelle gewählt haben. Beschreiben Sie auch kurz, wie diese Schwachstelle Ihrer Meinung nach zustandegekommen ist und wie eine bessere Lösung aussehen könnte. Falls Sie nicht mindestens fünf solche Stellen finden, schreiben Sie an den Anfang der Datei Test.java einen Kommentar, in dem Sie wahrscheinliche Gründe dafür nennen.

Wie die Aufgabe zu lösen ist:

Lassen Sie den Programmcode selbst (abgesehen von Kommentaren) unverändert. Schreiben Sie auf keinen Fall einfach nur Kommentare, die Ihnen gerade in den Sinn kommen, sondern versuchen Sie bewusst, über Vorbedingungen, Nachbedingungen und Invarianten einhaltbare Verträge zwischen Client und Server zu beschreiben. Diese Verträge sollen alles enthalten, was Client und Server voneinander wissen müssen. Andererseits sollen die Verträge keine unnötigen Bedingungen enthalten, um die Abhängigkeit zwischen Client und Server nicht künstlich zu erhöhen. Im Idealfall spiegeln die Verträge Überlegungen wider, die Sie bei der Programmierung im Kopf hatten. Oftmals ergeben sich im Laufe der Zeit Änderungen, durch die diese ursprünglichen Überlegungen nicht mehr zutreffen. Dann sollen die Verträge den endgültigen Stand darstellen.

Obwohl nicht ausdrücklich verlangt, empfiehlt es sich, bei jeder Zusicherung zu vermerken, um welche Art von Zusicherung es sich handelt (Vorbedingung, Nachbedingung oder Invariante). Gerade für weniger geübte Programmierer kann das Vorteile bei der Überprüfung der Zusicherungen bringen.

Es kann durchaus passieren, dass ein Client vom Server etwas anderes erwartet, als dieser bietet, oder umgekehrt. Das ist ein Fehler im Programm, der entweder sofort oder erst nach späteren (dem Vertrag entsprechenden) Programmänderungen zu falschen Ergebnissen führt. Versuchen Sie nicht, solche Fehler durch Tricks in den Verträgen zu beseitigen. Oft ist es tatsächlich möglich, durch komplizierte Formulierungen die Zusicherungen so hinzubiegen, dass das Programm noch korrekt erscheint. Das geht aber fast immer nur auf Kosten der Brauchbarkeit und Wartbarkeit der Software, weil im Vertrag für den Endanwender sinnlose Details und Eigenschaften festgeschrieben werden. Schreiben Sie lieber FEHLER: oder ERROR: Kommentare statt über Tricks Verträge zurechtzubiegen. Solche Kommentare haben garantiert keine Auswirkungen auf Ihre Beurteilung, können Ihnen aber helfen, für Sie typische Fehler, die Sie unter Zeitdruck sicherlich machen, besser zu verstehen.

Es ist empfehlenswert, dass Zusicherungen von der Person geschrieben werden, die auch den entsprechenden Programmcode (aus Sicht des Servers) geschrieben und die entsprechenden Überlegungen vielleicht noch im Kopf hat. Fehler werden aber eher von anderen Personen erkannt, die den Code aus der Sicht eines Clients betrachten. Am wahrscheinlichsten sind Fehler an Schnittstellen, an denen der Code eines Servers und eines Clients von verschiedenen Personen stammt. Diese Stellen sind besonders sorgfältig zu überprüfen.

Auch in Untertypbeziehungen treten häufig Fehler bei den Zusicherungen auf. Vergewissern Sie sich, dass im Untertyp Vorbedingungen nur schwächer und Nachbedingungen sowie Invarianten stärker sein dürfen als im Obertyp.

Durch Zusicherungen festgelegte Verträge sind ein wichtiges Qualitätsmerkmal, das dabei hilft, die Korrektheit bei Ersetzung einzelner Programmteile zu erhalten. Weitere Qualitätsmerkmale können bei der Wartung auch hilfreich sein. Markieren Sie daher alle Stellen, die Ihnen während der Suche nach passenden Verträgen als besonders gut oder schlecht auffallen, durch GUT: oder SCHLECHT: bzw. GOOD: oder BAD: Kommentare.

Falls Ihre Lösung der zweiten Aufgabe noch so unvollständig ist, dass Sie es nicht für sinnvoll erachten, die Lösung der dritten Aufgabe darauf aufzubauen, setzen Sie sich bitte mit Ihrer Tutorin oder Ihrem Tutor in Kontakt und befolgen Sie die von ihr oder ihm gegebenen Anweisungen. Im Zweifelsfall lösen Sie die Aufgabe so wie oben beschrieben.

Warum die Aufgabe diese Form hat:

Programmieren ist mehr als nur das Schreiben von Code. Diese Aufgabe soll Ihnen durch eine festgelegte Vorgehensweise helfen, die Qualität Ihrer eigenen Programme vor allem hinsichtlich Wartbarkeit und Wiederverwendbarkeit abzuschätzen. Sie sollen ein Gefühl für Ihre eigenen Stärken und Schwächen bekommen.

Natürlich sind das Schreiben und Überprüfen von Zusicherungen, die Berücksichtigung von Zusicherungen in Untertypbeziehungen, sowie die Abschätzung von Klassenzusammenhalt und Objektkopplung wichtige Lehrziele, die in dieser Aufgabe geübt werden. Ein wichtiger Aspekt dabei ist die Eigenständigkeit: Sie sollen Verträge in der Software aufgrund eigener Überlegungen entwickeln (jenen Überlegungen, die Sie im Idealfall bereits beim Schreiben des Programmcodes angestellt haben) statt anhand von Vorgaben oder Beispielsammlungen. Das ist zwar ein schwieriger Weg, aber einer, der Ihnen hilft, auch in außergewöhnlichen Situationen zurechtzukommen.

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
            OOP
               1. Aufgabe
               2. Aufgabe
               3. Aufgabe
               4. Aufgabe
               5. Aufgabe
               6. Aufgabe
               7. Aufgabe
               8. Aufgabe
               9. Aufgabe
               Cacao
            Typsysteme
         LVAs 2009 S
         LVAs 2008 W
         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:
Tutoren
Skriptum
Folien
vorige Aufgabe
nächste Aufgabe
Fakultät für Informatik
Technische Universität Wien
Anfang | HTML 4.01 | Datenschutzerklärung | letzte Änderung: 2009-10-28 (Puntigam)