Allgemeine Übungshinweise für SWE1
Stilrichtlinien für die Übungsabgabe
Bitte bei der Ausarbeitung einer Übung beachten.
Wenn eine Übung diesen Stilrichtlinien nicht entspricht, so behalten
wir uns vor diese Übung nicht zu bewerten. Diese Übung wird dann
als nicht abgegeben gewertet.
-
Generelle Form einer abgegebenen Übung
-
Der Übungszettel selbst ist als Deckblatt zu verwenden (falls zuwenige
Übungszetteln ausgeteilt wurden, bitte vom Kollegen kopieren oder
von der Übungsseite im Internet herunterladen)
-
Auf diesem Übungszettel ist der Vor- und Nachname, sowie Matrikelnummer,
Gruppennummer und der Übungsleiter anzugeben. Die Bearbeitungsdauer
ist freiwillig auszufüllen (Um den Schwierigkeitsgrad der Übung
einschaetzen und in weiterer Folge die Übungen dem allgemeinen Wissensstand
angleichen zu können).
-
Die Übungen sind entweder links oben oder auf der rechten Seite zu
klammern (sodass die Übung ähnlich einem Buch lesbar ist). Verpackungen
in Klarsichtfolien sind unerwünscht. Ungewöhnliche Klammerungen
(z.B. auf mehr als einer Seite) gibt u.U. Punkteabzug!
-
Disketten sollen nicht mit abgegeben werden (Werden generell ignoriert,
bzw. wenn die Diskette die Korrektur der Übung stört (z.B. durch
eine zu "intensive" Befestigung an den Übungszetteln) gibt es Punkteabzug!)
-
Die Aufgaben können handschriftlich oder als Computerausdruck abgegeben
werden, wenn es sich um 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 Zeilenumbrüche in Programmen (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
-
Kommentare (nicht übertreiben, soll den Algorithmus erklären,
nicht unwichtige Programmteile uebermässig kommentieren, wichtige
Programmteile erklären, ...)
-
Variablen-, Prozedur- und Klassennamen sollen sprechend sein
-
Vorgegebene Schnittstellen (Parameter, Typen, Namen, etc.) nicht ändern
-
Handschriftliches und Zeichnungen
-
Muss lesbar bzw. erkennbar sein (Im Zweifelsfall am Computer schreiben
;-)
-
Skizzen sind zur Erklärung in Ordnung, ja sogar erwünscht
-
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 (Was ist die Idee des Algorithmus? - Ist als Hilfe zur
Korrektur gedacht und sollte bei einem komplexeren oder ausgefeilten Algorithmus
unbedingt mit angegeben werden. Enthält der Algorithmus Fehler, etc.
und ist somit für den Tutor nicht nachvollziehbar, so kann die Lösungsidee
einige Punkte retten)
Die Lösungsidee ist zu allen Programmierbeispielen mit abzugeben!
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 (siehe oben).
-
Bei allen anderen Algorithmen ist die Lösungsidee ebenfalls Pflicht.
Der Grund liegt darin, dass dies eine Einführungs-Übung ist und
Programmieren gelernt werden soll. Zum Programmieren (d.h. zu einem guten
Programmierstil) gehört es auch sich vor dem Schreiben des Programmcodes
(in Java) sich zuerst genauestens dem zu lösenden Problem bewußt
zu werden und sich dann Ideen zur Lösung zu überlegen/abwägen/auswählen/...
. Das hat direkte Auswirkungen auf die Qualität des daraufhin zu schreibenden
Programmcodes.
Später in ihrem Studium 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 und mehrere Personen
(grössere Projekte) eine Lösungsidee zu schreiben.
Deshalb: Früh übt sich, ... .
-
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). Fehlt die Testausgabe, oder sind die Tests mangelhaft
(zu wenig oder sinnlos), wird das Beispiel nicht bewertet!
Korrektur der Übungen
-
Die abgegebenen Übungen werden (in der Regel) binnen einer Woche korrigiert
und im Physikgebäude, 1. Stock, auf den Briefkästen zur Abholung
ausgelegt
-
Die Korrektur der Übungen soll mehrere Ziele verfolgen
-
Zur Bewertung (Um eine Übungsnote festlegen zu können)
-
Als Rückmeldung (Wie kann man was evtl. besser machen? etc.)
-
Bei Fragen zur Korrektur der Übungen, bitte direkt an den Übungsleiter
wenden (z.B. per eMail, oder vor/nach der Übungsstunde)
-
Abschreiben führt zu einer Zurückweisung der ganzen Übung
aller Beteiligten. Ausserdem ist Abschreiben beim Übungstest nicht
möglich (Spätestens dann sollte man aber Beispiele mit ähnlichem
Schwierigkeitsgrad wie in den Übungen selbständig lösen
können!).
Tip: Ein fehlerhaftes bzw. unvollständiges selbstgemachtes Beispiel
(evtl. mit anschliessender Rückmeldung vom Tutor) bringt für
den Übungstest 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
Was soll/kann da alles drinstehen:
-
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/Ü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 in der Lösungsidee sind dort gut aufgehoben)
-
Wenn ja, was sind die einzelnen Schritte, die ich machen müesste/musste
um zur Lösung zu kommen?
-
Beschreibung der einzelnen Schritte bzw. 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 sogar 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.
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.
-
Nach dem Schreiben der Lösungsidee sollte beim Schreiben des Programms
(theoretisch) die Java Syntax das größte Problem sein.