Home
General
Staff
Contact
Partners
Alumni
Research
Areas
Projects
Papers
Books
Reports
Awards
Teaching
Lectures
Exams
B.Theses
M.Theses
PhD Theses
Go Abroad
Misc
Talks
Library
Gallery
Links
Search
Webmaster
|
Allgemeine Hinweise für Übungen zu PID
Stilrichtlinien für die Übungsabgabe
Bitte bei der Ausarbeitung einer Übung beachten. Die Qualität
der Rückmeldungen ist proportional zur Qualität der ausgearbeiteten Übung.
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 Markus Löberbauer.
Was soll eine Übung enthalten?
- Angabezettel (ausgefüllt wie oben angegeben)
- Alle gemachten Aufgaben (möglichst in aufsteigender Reihenfolge)
wie auf dem Angabezettel gefordert.
=> Angabe sorgfältig durchlesen!
- 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.
Die Lösungsidee ist zu allen Programmierbeispielen wünschenswert.
Begründung:
- 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.
Je nach Problemstellung kann man zu den obigen Punkten mehr, weniger
oder evtl. auch gar nichts schreiben. Des weiteren gibt es noch viele andere
Dinge, die vor dem Implementieren noch überlegt/abgeklärt/entschieden/...
werden müssen. Alles das gehört auch in die Lösungsidee.
Nach dem Schreiben der Lösungsidee sollte beim Schreiben des Programms
(theoretisch) die Java Syntax das größte Problem sein.
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.
|