Allgemeine Hinweise für Übungen zu PI2

Stilrichtlinien für die Übungsabgabe

Generelle Form einer abgegebenen Übung

• Der Übungszettel selbst ist als Deckblatt zu verwenden (von der Übungsseite herunterladen)
• Auf diesem Übungszettel sind
  • Vorname
  • Nachname
  • Matrikelnummer
  • Gruppennummer
  anzugeben.
• Die Übungen sind entweder links oben oder an der linken Seite zu klammern (sodass die Übung ähnlich einem Buch lesbar ist). Verpackungen in Klarsichtfolien etc. sind unerwünscht.
• Die Aufgaben können handschriftlich oder als Computerausdruck abgegeben werden, wenn es sich um Lösungsideen, stilisierte Prosa, Ablaufdiagramme, Struktogramme, Schreibtischtests, sonstige Diagramme/Zeichnungen, o.ä. handelt.
• Programmlistings (in Java, betrifft das Programm und evtl. Testprogramme), Testergebnisse (beim Testen von Java-Programmen, betrifft Ein- und Ausgabe), o.ä. müssen als Computerausdrucke abgegeben werden.
• Computerausdrucke müssen lesbar sein, dazu gehört:
  • Lesbares Schriftbild (nicht zu gross oder zu klein, nicht zu blaß)
  • Möglichst keine automatischen Zeilenumbrüche innerhalb einer Anweisung (evtl. Anweisungen sinnvoll auf mehrere Zeilen aufspalten)
  • Möglichst nicht zu viele Anweisungen pro Zeile (meist ist eine Anweisung pro Zeile genau das Richtige)
  • Korrekte Einrückungen
  • Keine Schmier-, Fett- oder sonstige Flecken, vor allem wenn wichtige Teile damit verdeckt werden
• Handschriftliches und Zeichnungen:
  • müssen lesbar bzw. erkennbar sein (im Zweifelsfall am Computer schreiben ;-) )
  • Skizzen sind zur Erklärung in Ordnung, ja sogar erwünscht
• Alle Java-Programme müssen elektronisch per http-Upload abgegeben werden. Im Problemfall wenden Sie Sich bitte an Reinhard Wolfinger.

Was soll eine Übung enthalten?

1. Angabezettel (ausgefüllt wie oben angegeben)
2. Alle gemachten Aufgaben (möglichst in aufsteigender Reihenfolge) wie auf dem Angabezettel gefordert.
   => Angabe sorgfältig durchlesen!
3. Bei Programmierbeispielen sind gefordert:
   • Lösungsidee (s.u.)
   • Listing des Programms (Programmiersprache: Java, Computerausdruck)
   • Listing des Testprogramms, sofern eines zu schreiben war (Programmiersprache: Java, Computerausdruck)
   • Testeingabe, Testausgabe (nicht zuviel und nicht zuwenig, sinnvoll testen! Computerausdruck).

Korrektur der Übungen

• Die abgegebenen Übungen werden (in der Regel) binnen einer Woche korrigiert und im Hochschulfondsgebäde, 3. Stock, auf den Briefkästen zur Abholung ausgelegt.
• Die Korrektur der Übungen soll im wesentlichen als Rückmeldung dienen.
• Bei Fragen zur Korrektur der Übungen, bitte zuerst an den Tutor, der die Übung korrigiert hat, und dann erst an den Übungsleiter wenden (z.B. per eMail einen Termin ausmachen)
• Abschreiben ist sinnlos (führt zum Verlust der Punkte des Abschreibers und des Autors, das kann ja nicht immer zweifelsfrei unterschieden werden)
  Hinweis: Ein fehlerhaftes bzw. unvollständiges selbstgemachtes Beispiel (evtl. mit anschliessender Rückmeldung vom Tutor) bringt für den Übungstest und das Studium mehr als Abschreiben vom Kollegen. Auch wenn man denkt, dass man ein abgeschriebenes Programm versteht, so nützt das nicht viel. Das Schwierigste ist immer der Weg vom Problem zum Programm! Denn um ein bereits bestehendes Kochrezept nachkochen zu können ist kein Universitätsabschluß notwendig.

Zur Lösungsidee

• Bei komplexeren Algorithmen ist es u.U. dem Tutor nicht möglich den Algorithmus (bzw. die Idee davon) nachzuvollziehen
  => mit Lösungsidee (hoffentlich) schon. Eine Lösungsidee kann somit ein Programm überhaupt erst bewertbar machen.
• Bei allen anderen Algorithmen ist die Lösungsidee ebenfalls Pflicht. Zum Programmieren (d.h. zu einem guten Programmierstil) gehört es auch, sich vor dem Schreiben des Programmcodes (in Java) sich zuerst genauestens des zu lösenden Problems bewußt zu werden, und sich dann Ideen zur Lösung zu überlegen/abzuwägen/auswählen/... . Das hat direkte Auswirkungen auf die Qualität des Programmcodes.
  Später in ihrem Studium/Arbeit werden Sie noch lernen, dass es im sogenannten Softwareentwicklungsprozess eine eigene Phase "Design" gibt, in der man im wesentlichen nichts anderes macht als einige Stunden (sehr kleine Projekte), einige Tage (kleine Projekte), ... bis einige Monate (grössere Projekte) eine Art Lösungsidee zu schreiben.
  Deshalb: Früh übt sich, ... .

Was soll/kann die Lösungsidee enthalten:

• Problembeschreibung (zuerst: Angabe sorgfältig durchlesen und zu verstehen versuchen. Überlegen, ob man das Problem verstanden hat)
• Was weiss ich darüber?
• Was ist mir neu/fremd?
  Wenn nötig Zusatzinformationen besorgen, evtl. eine Referenz dazu angeben.
• Was ist mir unklar?
  Falls etwas nicht ganz klar ist oder Informationen fehlen: entweder Kollegen/Tutor/Übungsleiter fragen oder selbständig eine Entscheidung treffen - die Lösungsidee ist der richtige Ort um solche Entscheidungen niederzuschreiben und zu begründen.
• Lösungsansatz (evtl. mehrere Ansätze versuchen)
  • Könnte ich das Problem selbst (per Hand) an einem kleinen Beispiel lösen?
    Evtl. (kleine) Beispiele wirklich durchspielen - Beispiele und Skizzen machen sich in der Lösungsidee sehr gut.
  • Was sind die einzelnen Schritte, um zur Lösung zu kommen?
  • Beschreibung der einzelnen Schritte oder besser: Beschreibung der Abläufe (Bitte keine stilisierte Prosa des Programms!!!).
    Gibt es Teillösungen? Wiederholt sich etwas? Gibt es Alternativen? Gibt es Abhängigkeiten einzelner Abläufe?
    Bei mathematischen Problemen ist auch gegen Formeln oder Definitionen nichts einzuwenden, sofern verständnisfördernd. Skizzen sind in den meisten Fällen sinnvoll und erwünscht (Ein Bild sagt oft mehr als 1000 Worte!). Pseudocode ist nur manchmal sinnvoll, kann aber zum Verständnis beitragen (Wenn schon, dann möglichst abstrakt, wenig/keine Details und nicht zu viel).
• Sonderfälle/Fehlerfälle
• Gibt es Sonderfälle?
• Wie werden Sonderfälle behandelt? Bereiten sie Schwierigkeiten? Wie hoch ist der Aufwand um Sonderfälle zu vermeiden? Gibt es (andere) Ideen, mit denen die Sonderfälle weniger Probleme bereiten?
• Gibt es Fehlerfälle?
• Wodurch können Fehler entstehen? Kann man diese Fehler sinnvoll behandeln? Kann man den Algorithmus so abändern, dass man Fehlerfälle vermeidet (die Fehlerbehandlung sollte aber nicht die Struktur des Algorithmus dominieren)?
• Implementierungsprobleme
• Lässt sich der Lösungsansatz nicht oder nicht gut implementieren, so kann man das auch in der Lösungsidee vermerken und entsprechende Änderungen an der Idee nachtragen.

Was noch zu beachten ist:

• Je nach Schwierigkeitsgrad und Umfang der Übung (Algorithmus) kann die Lösungsidee länger oder kürzer sein.
  1-2 Seiten für eine textuelle Lösungsidee sollten (für diese Übung) eine obere Grenze sein. Es besteht sonst die Gefahr, dass man sich entweder wiederholt oder zu viel um den heissen Brei herumredet (auf die wirklichen Probleme/Ideen konzentrieren!). Hat man (mehrere) Beispiele oder Skizzen kann diese Grenze natürlich (in Maßen) überschritten werden.
• Kommentare im Programm und Lösungsidee haben nicht viel miteinander zu tun. Nicht verwechseln! Kommentare erklären nur den geschriebenen Programmcode und sollen eher eine "Orientierungshilfe" sein.

Beurteilung und Anwesenheit

• Es werden 8 Übungen ausgegeben. Dabei sind insgesamt 156 Punkte zu erreichen. Wer mind. 50% der Punkte erreicht hat, darf zum Übungstest antreten. Die Gesamtnote setzt sich zu jeweils 50% aus den erreichten Übungspunkten und dem Übungstest zusammen. Übungen und Test müssen positiv sein.
• Keine Toleranz für Abschreiben. Wer eine Übung abgibt die abgeschrieben ist, kann nicht positiv beurteilt werden. Als Folge wird ein LVA-Zeugnis mit "nicht beurteilt" ausgestellt.
• Grundsätzlich gilt keine Anwesenheitspflicht. Bei einzelnen Übungen können Beispiele mit dem Vermerk "Präsentation in der LVA" versehen sein. Bei solchen Beispielen ist am Tag der Abgabe Anwesenheit in der LVA erforderlich.