TU Wien:Objektorientierte Programmiertechniken VU (Puntigam)

Aus VoWi
Zur Navigation springen Zur Suche springen

Daten[Bearbeiten | Quelltext bearbeiten]

Vortragende Andreas Krall• Franz Puntigam
ECTS 3
Alias Object-oriented Programming Techniques (en)
Letzte Abhaltung 2022W
Sprache Deutsch
Abkürzung OOP
Mattermost objektorientierte-programmiertechniken • Register • Mattermost-Infos
Links tiss:185A01, eLearning
Zuordnungen
Bachelorstudium Wirtschaftsinformatik
Bachelorstudium Medieninformatik und Visual Computing
Bachelorstudium Medizinische Informatik
Bachelorstudium Software & Information Engineering


Inhalt[Bearbeiten | Quelltext bearbeiten]

Erlernen von Paradigmen der Objektorientierten Programmierung

Benötigte Vorkenntnisse[Bearbeiten | Quelltext bearbeiten]

Grundlegende Programmierkenntnisse sind notwendig. Programmieren grundsätzlich bzw. Java im Speziellen im Rahmen dieser Übung zu lernen, kann deren Aufwand explodieren lassen. Man sollte auch die Vorlesung Einführung in die Programmierung 2 erfolgreich abgeschlossen haben, da einige Konzepte aus dieser LVA vorausgesetzt werden.

Ablauf[Bearbeiten | Quelltext bearbeiten]

Es sind acht Programmieraufgaben in Java zu erledigen, im Normalfall eine pro Woche. Für das (lange) dritte Beispiel hat man drei Wochen Zeit. Das Ganze läuft in Gruppenarbeit mit jeweils drei Leuten pro Gruppe ab. Um positiv zu sein, braucht man mindestens die Hälfte der Punkte von den Beispielen, muss das Abgabegespräch absolvieren und die mündliche Prüfung bestehen.


WS 18/19:

Es sind 9 Programmieraufgaben in Java in Gruppen zu je drei Personen zu erledigen. Dafür steht meist eine Woche, manchmal auch zwei Wochen zur Verfügung.

Die ersten drei Aufgaben stellen eine Art Eingangsphase dar und hängen inhaltlich zusammen. Der Fokus hierbei liegt darauf, in der Gruppe arbeiten zu lernen; Unterstützung durch den Tutor fällt geringer aus, als früher (siehe oben), hängt jedoch immer noch von der Selbsteinschätzung der Gruppe ab. Für die ersten drei Übungen gibt es insgesamt bis zu 100 Punkte, die durch den jeweiligen Tutor vergeben werden.

Die restlichen sechs Übungen widmen sich dem Vorlesungsinhalt, wobei es bei der Bearbeitung hilfreicher ist, sich am Skriptum, als an der Vorlesung zu orientieren. Die Bewertung führt bei diesen Aufgaben Puntigam oder Krall durch, hierbei werden bis zu 100 Punkte pro Übung vergeben.

Git Repository

Man bekommt einen SSH account. Man kann die Git Bash oder ein vergleichbares Terminal öffnen und sich mit folgendem Befehl verbinden 

ssh o<matrikel>@g0.complang.tuwien.ac.at

Dann muss man das Passwort mit dem passwd Befehl ändern.


Um auf das git repository (ssh://gitolite3@g0.complang.tuwien.ac.at/oop<gruppe>) zugreifen zu können muss man erst seinen privaten SSH key per SSH herunterladen. Starte das Terminal neu und führe folgende Befehle aus: 

cd ~
mkdir .ssh
scp o<matrikel>@g0.complang.tuwien.ac.at:.ssh/id_rsa .ssh
ssh-add

WS 20/21

Es waren wieder 9 Aufgaben zu bearbeiten. Es gab wöchentliche Videos als Downloads die die Vorlesung im Covid-Modus ersetzt haben und schlussendlich ein Abgabegespräch über Zoom und eine mündliche Prüfung über Zoom. Sonst eigentlich gleich zum WS 18/19


WS 21/22

Es gab nur 8 Aufgabenblätter. Die Vorlesungen fanden für Interessierte bis zum Lockdown im November in Präsenz (+Stream und Aufzeichnung) statt. Sonst gleich zum Vorjahr.


WS 22/23: Alle Gruppenmitglieder mussten eine Selbsteinschätzung schreiben (Programmiererfahrung etc.) und ein Gruppenmitglied wird ausgewählt für die Kommunikation mit dem/der Tutor/in.

Die ersten beiden Beispiele werden zusammen mit dem Tutor gemacht (man kann die Art der Betreuung wählen: gemeinsam mit dem Tutor programmieren, wöchentliche Treffen oder nur Abgabe mit Feedback und Nachabgabe ohne Punkteabzug ist alles möglich). Die Beurteilung erfolgt durch den Tutor; sie zählen gemeinsam 100 Punkte. Die anderen 5 Beispiele werden von Puntigam und/oder Krall beurteilt; pro Beispiel gibt es 100 Punkte, bei Nachabgabe zählt das Maximum der beiden Abgaben, wobei bei der Nachabgabe maximal 67 Punkte erreicht werden können.

Tipps[Bearbeiten | Quelltext bearbeiten]

  • Die Beispiele nicht einfach herunterprogrammieren, sondern zumindest ein wenig dabei überlegen.
  • Die ersten Beispiele sind in irgendeiner Weise aufeinander aufbauend - es zahlt sich aus, sich für Beispiele ein gutes Design zu überlegen! Die übrigen Bsp. waren nicht mehr aufbauend (WS18/19)
  • Professor Puntigam hat bei meinem Abgabegespräch eigentlich nix dagegen gesagt, dass ich hauptsächlich mit einem Mitglied aus einer anderen Gruppe gearbeitet habe.
  • Es ist nicht zu empfehlen, die Vorlesungsprüfung hinauszuschieben, dadurch steigt nur der Lernaufwand erheblich, da man sich nochmal in das Ganze einarbeiten muss.
  • Vor dem Programmieren das Beispiel erst mal genau durchdenken. Designfehler am Anfang führen nicht selten dazu, dass man das gesamte Beispiel noch mal bei 0 beginnen muss.
  • Nachdem die ersten 3 Beispiele relativ einfach zu lösen sind neigen viele Studenten dazu das 4. zu unterschätzen. Das führt dann zu Überraschungen bei der Benotung.
  • Auch ein vollständig funktionierendes Programm kann mit weniger als 50% benotet werden, wenn es nicht sauber programmiert wurde. (unnötig viel Code, nicht objektorientiert, ....)
  • Bei den beiden Terminen zur Gruppenfindung zusehen, dass man an halbwegs verlässliche Leute kommt - die LVA-Leitung erklärt zwar, dass Gruppenumstellungen anfangs noch stattfinden können (wenn ein Gruppenmitglied aussteigt etc.), in der Realität steht man aber dennoch sehr oft zu zweit oder gar allein da.
  • Wenn man beim Abgabegespräch andeutet, dass die Arbeit innerhalb der Gruppe nicht immer ganz gleich verteilt war, kann es schnell zu Punkteabzügen bzw. Zusatzpunkten für einzelne Gruppenmitglieder kommen.
  • Unbedingt beachten wofür bei der aktuellen Aufgabe Punkte vergeben und abgezogen werden, das ist teilweise genau gegenteilig zur vorigen Aufgabe.
  • Es ist schwierig von Puntigam konkrete Aussagen zu Fragen zu den Beispielen zu bekommen. Was besser funktioniert ist zu beschreiben was man vor hat und wie man die Aufgabe versteht, da er dann eher sagen muss, dass es falsch, bzw nicht so wie gewünscht, ist.

Zeitaufwand[Bearbeiten | Quelltext bearbeiten]

Moderat bis viel, einige Stunden pro Beispiel (jede Woche ein Bsp - ca. 8x). Kommt allerdings auch stark auf die Vorkenntnisse und die Zusammenarbeit der Gruppenmitglieder an. Es empfiehlt sich, die Bsp. früh anzufangen und gleich am Anfang gut zu planen, sodass man für die nächsten aufbauenden Runden nur wenig auszubessern hat. Die ersten beiden Beispiele (speziell das dritte) sind möglicherweise etwas zeitaufwändiger. Der Prüfungsteil zur Vorlesung ist etwas aufwändiger, weil Prof. Puntigam das Skriptum recht genau prüft. Bei Prof. Krall zumindest reicht ein Tag zum Vorbereiten.

Andere Darstellung: Dem kann ich nicht ganz zustimmen. Trotz Programmiervorkenntnissen haben wir für einige Beispiele an die 10 Stunden benötigt. Am Tag vor der Abgabe waren in den Interneträumen im Freihaus meist bis knapp vor den Freihaus Schließzeiten noch einige OOP Gruppen fleißig am Werkeln.

Noch eine Meinung (WS19): Der Aufwand war doch schon sehr hoch. Besonders, wenn man die VO auch besucht hat. Insgesamt locker doppelt so hoch, wie vorgesehen.

WS09/10: Die Beispiele sind viel Arbeit. Ich stelle mir vor, dass es noch anstrengender ist, wenn die Gruppe nicht gut zusammenarbeitet. Von dem Aufwand her sind die paar ECTS zu wenig. Ich persönlich habe den Lernaufwand für die Prüfung nicht sonderlich hoch gefunden (am Tag davor das Skriptum 1x lesen und ausgearbeitete Verständnisfragen ein paar mal durchlesen => Ergebnis: Sehr Gut :-))

WS20/21: Der Aufwand der Beispiele hat stark variiert. Die ersten drei Aufgabenblätter haben bei uns relativ lange gedauert, umso mehr wenn man die Nachbearbeitung nach der Erstbewertung mitzählt. Die restlichen Arbeitsblätter waren vom Aufwand her eigentlich sehr angenehm in meinen Augen. Ein wichtiger Tipp ist, dass wirklich zur gleichen Zeit im Team die Aufgabe gelöst wird. das kann den Aufwand um Stunden verringern. Genauso ist eine sorgfältige Planung eigentlich der Hauptteil. Lieber ein zwei Stunden mehr in die Planung zu investieren, als dann 2 Stunden umsonst gecodet zu haben und alles neu schreiben zu müssen weils doch nicht geht. Punkteabzüge waren bei uns auch bei kleinen Fehlern ziemlich hoch. Meine Gruppe hat es geschafft, eine sehr gute Leistung abzuliefern mit etwa 6-7h Arbeit pro Mann und Blatt. Ich habe aber auch von Gruppen gehört, die weit länger gebraucht haben.

WS20/21: Ähnliche Meinung wie der/die Kolleg_in: Meine Gruppe hat mit durchschnittlich 6-9h Arbeit pro Kopf pro Arbeitsblatt einen 1er geschafft. Beim letzten sind wir doch über 11h gesessen, zwischendurch gab es eines mit minimalem Aufwand von ca. 3h. Ich glaube, dass uns sorgfältige Planung (1-2h pro Blatt) und gemeinsame Coding Sessions (CodeWithMe) einiges an Zeit erspart haben. Für die Prüfung (Puntigam) habe ich das Skript einmal durchgelesen und die Wiederholungsfragen ausgearbeitet: knappe 20h für einen 2er (geht aber sicher schneller und mit besserer Note, wenn man mündlich gut ist)

Abgabegespräch & Prüfung[Bearbeiten | Quelltext bearbeiten]

Programmieraufgaben Punktedurchschnitt[Bearbeiten | Quelltext bearbeiten]

Während dem Semester sind Programmieraufgaben zu lösen (siehe Materialien). Eine Woche nach Abgabe der gelösten Programmieraufgaben bekommt man Feedback in Form einer E-Mail. In diesen E-Mails wird jeweils auch die durchschnittlich erreichte Punkteanzahl über alle Abgaben zu der jeweiligen Aufgabe angegeben. Um den nächsten Semestern einen möglichen Überblick der Schwierigkeit der einzelnen Aufgaben zu geben, werden in der folgenden Tabelle die durchschnittlich erreichten Punkte je Angabe und Semester angegeben.

Anmerkung: Manche Aufgaben (vor allem am Anfang) werden zusammengelegt, wobei hier dann die max. Punkteanzahl für alle drei gilt.

Achtung: Die Punkte sind erst vorläufig und können sich noch im Zuge des Abgabegesprächs verändern. Beachte auch, dass die Punkte nicht eins zu eins die Schwierigkeit widerspiegeln sondern Faktoren wie andere Abgaben, Tests, Prüfungen, etc. einen Einfluss auf den Punktedurchschnitt haben könnten.

Semester (max. Punkte) A1 A2 A3 A4 A5 A6 A7 A8 A9 Durchschnitt gesamt
2022W (100) - 62 70 95 91 80 75 78.8

Abgabegespräch[Bearbeiten | Quelltext bearbeiten]

Habt ihr die Beispiele selbst programmiert, ist das Ganze kein Problem. Es ist auch ok, wenn ihr z.B. sagt, dass ihr die Beispiele aufgeteilt habt. Ihr müsst also nicht erzählen, ihr habt alles selber programmiert, wenn's nicht stimmt. Es ist nicht nötig, für das Gespräch irgendetwas zu lernen (hat Puntigam selber so gesagt). Es geht eigentlich nur darum, zu klären, wie die Kommunikation in der Gruppe so verlief.

Prüfung[Bearbeiten | Quelltext bearbeiten]

Wird (wie das Abgabegespräch) entweder von Krall oder von Puntigam durchgeführt.

Krall[Bearbeiten | Quelltext bearbeiten]

WS12/13: Nicht zu unterschätzen! Das Skriptum wird recht genau geprüft. Die Fragen bestehen aus Stichwörtern, am besten sagt man alles, was einem dazu einfällt. Fehlt einem etwas für Prof. Krall wichtiges, wird genauer nachgefragt. Weiß man nicht weiter, gibt Prof. Krall einen Tipp oder lässt einen Kollegen einen Tipp geben. Gelegentlich wird auch in die Runde gefragt, ob das, was der Kollege gesagt hat, korrekt sei; sagt man "nein", wird man aufgefordert, zu korrigieren (und kann sich so Fehler bei eigenen Fragen ausbessern). Im Allgemeinen bekommt man drei Fragen, steht man dann jedoch zwischen zwei Noten mit Prüfung und Laborübung (Beispiel: Prüfung 2er, Laborübung 3er) bekommt man eine vierte Frage; beantwortet man sie richtig, wird es die bessere Note, ansonsten die schlechtere Note. Beliebte Fragen sind:

  • Ersetzbarkeitsprinzip
  • Zusicherungen (!!! auch History Constraints !!!)
  • Generizität allgemein
  • mögliche Übersetzungen von Generizität
  • kovariante Probleme/binäre Methoden
  • Überladen/Multimethoden
  • ein Entwurfsmuster beschreiben

Auf jeden Fall bekommt jeder ein Entwurfsmuster und eine Frage aus Generizität. Alles in allem doch sehr empfehlenswert.

WS13/14: Es ist nicht zu unterschätzen, aber wenn man sich "halbwegs" gut auskennt und von den Themengebieten eine Ahnung hat, kommt man sicher durch. Zeitaufwand würd ich auf ca 10-20 Stunden, je nach Vorwissen, schätzen!

Feb 2015: Es wurde detailliert nachgefragt, wenn man die Kapitel aber verstanden hat, dann sollte es kein Problem sein. In unserer Runde hat jeder einen 2er bekommen. Parallel zu unserer Prüfung hat Puntigam auch geprüft, jedoch hat er die Leute einzeln geprüft, nicht in einer Gruppe. Im Informatikforum bzw. auch hier wurden von vielen Studenten die Lieblingsfragen/themen genannt, die sollte man sich besonders anschauen. Meiner Meinung nach kann man zB. das erste Kapitel im Skriptum fast streichen, wichtig ist, dass man sich auf das Wesentliche konzentriert.

Feb 2017: Sehr angenehmes Prüfungsklima. Er fragt zuerst sehr allgemein, z.B. "Zusicherungen", und wenn ihm etwas fehlt, fragt er nochmal genauer, z.B. "und in Untertypen?", wobei es sich auf die Note nicht negativ auswirkt, wenn man nicht alles auf einmal aufsagt. Man sollte sich beim Beantworten der Fragen keinen Stress machen und eher auf Richtigkeit achten. Sollte man eine Frage nicht richtig beantworten können, wird die Frage weitergereicht. Alles in allem sehr humane Prüfung, wenn man gut vorbereitet ist (2x Skriptum + Fragen lesen = Einser, 1x lesen und verstehen = 1-3, je nach Frage).

Jan 2018: In Herrn Kralls Büro herrscht zur Prüfung ein sehr angenehmens und ruhiges Klima. Es steht offenbar nicht sonderlich auf Smalltalk und legt direkt mit der ersten Frage los sobald er die Studierendenausweise kontrolliert hat. Er lässt einem genug Zeit zum antworten, auch wenn es nicht direkt aus der Pistole geschossen kommt und hilft einem auch auf die Sprünge, wenn etwas nicht sofort klar ist oder fragt in die Runde. Der Stoff aus dem Skriptum wird mmn ziemlich genau abgefragt, bei manchen Themen geht es wirklich ins Detail (z.B. Generics und History-Constaints). Es ist auf jeden Fall sehr empfehlenswert die Fragen am Ende der Kapitel im Skriptum auszuarbeiten, da man viele von ihnen bei der Prüfung wiederfindet. Herr Krall versucht, den ganzen VO-Stoff durch abzufragen. Die Benotung scheint relativ objektiv zu sein.

WS20/21: Die mündliche Prüfung hat über ein Online-Meeting stattgefunden. Herr Professor Krall listet bei den Fragen verschiedene Stichwörter auf, worauf der/die Studierende diese Fachbegriffe erklären soll und ein kohärentes Bild darstellen soll. Ihm geht es also darum, dass man den Inhalt verstanden hat und die richtige Fachterminologie verwenden kann. Falls man über die Themen jeweils 1-2 Minuten lang reden kann, sollte man keine Probleme haben. Herr Professor Krall stellt teilweise Fragen nach dem Erklären der Themen, um zu sehen, ob das Gesagt auch verstanden wurde. Die Benotung ist sehr objektiv. Es sei aber noch angemerkt, dass bei einer Notenunklarheit eine 4. Frage gestellt wird, die so im Skriptum nicht unbedingt vorkommt. Hier ist es also wichtig, sich mit Java auszukennen. Mit einer Vorbereitungszeit von 4 Tagen (Lernzeit: ~20h) sollte man den Stoff gemütlich lernen können.

Puntigam[Bearbeiten | Quelltext bearbeiten]

Ich finde, er fragt und benotet sehr fair, allerdings würde ich sehr empfehlen, auch wirklich das Skriptum zu lernen. Nur die Übungsbeispiele gut gelöst zu haben reicht auf keinen Fall aus, um die Prüfung auch gut zu machen. Ein Kollege hatte ein klares Sehr Gut auf die Übung, hat sich jedoch die Theorie nicht so angeschaut (Prüfungsnote 4) und bekommt deshalb im Endeffekt einen Dreier. Ich fand die Prüfung trotz guter Note ein bisschen stressig. Vermutlich liegt das auch am Zeitdruck für die Prüfungen, jedenfalls hat Puntigam gleich wie aus der Pistole geschossen recht spezifische Fragen gestellt. Man sollte sich dadurch nicht verunsichern lassen und meinen, genauso knapp und schnell antworten zu müssen. Als ich mir bei manchen Fragen nicht ganz sicher war, hab ich so meine Gedanken zu dem Thema erläutert und er hilft dann eh auch ein bisschen. Hauptsache, man lässt sich nicht aus der Ruhe bringen, sondern man atmet zuerst mal durch und ordnet die Gedanken. Also ich würde sagen, Puntigam fragt nicht einfach ein paar Fragen und schreibt dann die Note hin, sondern er schaut wirklich, ob man das verstanden hat. Wer wirklich versteht, was im Skriptum steht, hat nichts zu befürchten. Die Wiederholungsfragen im Skriptum sind übrigens sehr hilfreich zur Vorbereitung auf die Prüfung.

WS09/10: Ein sehr angenehmes Prüfungsklima. Man sollte mit je einer Frage zu den Basics (Ko/Kontra/Invarianz, auch in Bezug auf Zusicherungen), einer zur Generischen Programmierung (Homo/Heterogene Übersetzung vor allem) und zu einem Designpattern (Factory, Visitor und Decorator scheint er besonders zu mögen). Mich hat er auch gefragt, was Multimethoden sind. Ein heißer Tipp sind die Fragen im Skriptum, bei denen "häufige Prüfungsfrage" dabeisteht! Ihr könnt fix damit rechnen, dass ihr zumindest eine von diesen Fragen gestellt bekommt.
Wenn ihr bei ihm das Gefühl erwecken könnt, dass ihr die Sachen durchschaut habt, fragt er auch kaum nach. Kleine Denkfehler werden durchaus vergeben; er hilft einem dann rasch vom Holzweg runter. Prädikat: Empfehlenswert.

WS13/14: Fragt sehr theoretisch, worauf ich nicht vorbereitet war. Ich musste deswegen ein zweites Mal antreten und es kamen wieder fast die selben fragen. 1. Kandidat (erster Links von Puntigam): Ersetzbarkeitsprinzip, Multimethoden, Factory Pattern. 2. Kandidat (Mitte): Zusicherungen und welche Client und Server einhalten müssen (Tipp: Bsp. für Historyconstraint welches der Server einhalten muss: Zähler -> darf nur größer werden), zweite Frage habe ich vergessen, Decorator Pattern. 3. Kandidat (erster Rechts von Puntigam): Parametrisierungsarten (sowohl statisch als auch dynamisch), Aspektorietierte Programmierung, Iterator Pattern. Der Platz rechts von Puntigam scheint gefährlich. Von mir aus gesehen die schwersten Fragen. Bei meinem ersten Versuch bin ich dort gesessen und durchgefallen und bei meinem zweiten Versuch ist ebenfalls die Kandidatin auf dem Platz durchgefallen. Also viel Spaß beim Raufen um die anderen beiden Plätze...

WS14/15: Die Prüfung würde ich nicht als fair bezeichnen. Es ist zwar schwer einen 5er zu bekommen, wenn man sich das Skriptum zumindest angesehen hat. Für einen Einser muss man es aber sehr detailliert (wirklich sehr detailliert können). Die Noten zwischen 2 und 4 könnten genauso gut gewürfelt werden. Wenn man Glück hat reicht einmal Skriptum durchlesen für einen 2er, wenn nicht helfen auch viele Lernstunden nicht, etwas besseres als einen Vierer zu bekommen. (Hängt von der Stimmung des Professors ab)

Feb 2016: Die Prüfung fand als Einzelprüfung statt. Die Fragen zielten (meiner Meinung nach) unnötig auf Details ab (vor allem auf Schlagworte; z. B. namespace beim Thema Remote Proxy), die nicht unbedingt hängen bleiben, wenn man das Skriptum nur einmal liest oder nur die ausgearbeiteten Prüfungsfragen durchgeht, die hier im Vowi zur Verfügung stehen. Inhaltlich wurden 4 unterschiedliche Themenbereiche abgefragt. Die Benotung empfand ich fair.

WS17/18: Einzelprüfung. Es werden sofort spezifische, theoretische Fragen gestellt (Erste Frage: Wie verhalten sich Vorbedingungen in Untertypen?), man bekommt aber genug Zeit zum Nachdenken und wenn man etwas nicht weiß, gibt's auch einen Tipp. Das Skriptum sollte man schon gut können, nicht nur die Kapitel, die für die Übung relevant waren, sondern wirklich alles. Das Wissen aus der Übung reicht auf gar keinen Fall. Ins allerletzte Detail wird zwar nicht geprüft, aber oberflächliches Wissen ist nicht genug. Meiner Meinung nach reichen 2-4 Tage konzentriertes Lernen für eine (sehr) gute Note aus. Ich habe es nicht so empfunden, dass man für einen 1er alles sehr detailliert können muss, mir wurden zumindest kleinere Fehler verziehen.

WS18/19: Einzelprüfung: Die Fragen beziehen sich stark auf das Skriptum und gehen ziemlich ins Detail, wobei es aber eindeutig mehr um Verständnis als um stures Auswendiglernen geht. Mit ausschließlich oberflächlichem Wissen ist es unmöglich eine gute Note zu erreichen, da es keine "leichten" Fragen gibt. Wenn man sich mit dem Skriptum aber ausreichend auseinandersetzt (lesen, wiederholen, Fragen durcharbeiten, ...) kann man sich darauf verlassen, entsprechend benotet zu werden. Alles in allem würde ich die Prüfung als fair, wenn auch anspruchsvoll, bezeichnen.

WS19/20: Die Prüfung war sehr nett. Eigentlich fast wie ein normales Gespräch. Es gab kein Angabeblatt und auch keine lange Vorbereitungszeit. Man durfte aber schon kurz überlegen, was man sagen möchte. Der Professor hat viel mitgeholfen wenn man nichts mehr sagen konnte (mit weiteren Fragen, damit man in die richtige Richtung kommt). Es wurde definitiv Wert auf Verständnis gelegt, nicht auf auswendig Gelerntes. Nach ca. 10 Minuten war die Prüfung auch schon wieder vorbei. Habe zur Vorbereitung eigentlich nur das Skript einmal durchgelesen und einige der Fragen am Ende jedes Kapitels beantwortet.

WS20/21: Es wurde auf Verständnis geprüft und es ging auch wieder ins Detail. Solang man alle Fragen am Ende des Kapitels lernt und die Antworten auch versteht sollten bei der Prüfung keine großen Überraschungen kommen. Die Atmosphäre bei der Prüfung war entspannt und der Professor war sehr freundlich.

Dauer der Zeugnisausstellung[Bearbeiten | Quelltext bearbeiten]

Im Normalfall bekommt man das Zeugnis meist noch am selben Tag des Prüfungsantritts (Nachdem alle Slots dran waren).

WS05/06: mündliche Prüfung am 06.03.2006, Zeugnis erhalten am 07.03.2006 (ca. 1 Tag)

WS07/08: mündliche Prüfung am 03.03.2007, Zeugnis erhalten am 04.03.2007 (ca. 1 Tag)

WS08/09: mündliche Prüfung am 22.02.2008, Zeugnis erhalten am 23.02.2008 (ca. 1 Tag)

WS09/10: mündliche Prüfung am 26.01.2010, Abgabegespräch am 27.01.2010, Zeugnis am 28.01.2010 (ca. 1 Tag)

WS11/12: mündliche Prüfung am 31.01.2012 10.40 Uhr, Zeugnis am 31.01.2012 17.00 Uhr (ca. 6 Stunden)

WS11/12: mündliche Prüfung am 25.06.2012 11:00 Uhr, Zeugnis am 25.06.2012 14:00 Uhr (ca. 3 Stunden)

WS12/13: mündliche Prüfung am 25.01.2013 10:00 Uhr, Zeugnis am 25.01.2013 16:00 Uhr (ca. 6 Stunden)

WS13/14: mündliche Prüfung am 31.03.2013 14:50 Uhr, Zeugnis am 31.03.2013 15:50 Uhr (weniger als eine Stunde wenn man die Prüfungsdauer abzieht)

WS14/15: mündliche Prüfung am 23.01.2015 11:00 Uhr, Zeugnis am 23.01.2015 11:50 Uhr (weniger als eine Stunde)

WS15/16: mündliche Prüfung am 28.01.2016 14:00 Uhr, Zeugnis am 28.01.2016 17:05 Uhr (ca. 3 Stunden), mündl. Pr. 10.02.2016, Prof. Krall - ca. 3 Stunden

WS16/17: mündliche Prüfung am 20.02.2017 16:00 Uhr, Zeugnis am 20.02.2017 17:35 Uhr (ca. 1,5 Stunden)

WS17/18: mündliche Prüfung am 23.01.2018 11:00 Uhr, Zeugnis am 23.01.2018 12:00 Uhr (weniger als eine Stunde)

WS18/19: mündliche Prüfung am 24.01.2019 12:00 Uhr, Zeugnis am 24.01.2019 16:15 Uhr (ca. 4 Stunden)

WS19/20: Das Zeugnis wurde wieder innerhalb weniger Stunden ausgestellt (ca 2h)

WS20/21: mündliche Prüfung am 27.01.2021 16:30 Uhr, Zeugnis am 27.01.2021 17:25 Uhr (weniger als eine Stunde)

WS21/22: mündliche Prüfung am 31.01.2022 11:00 Uhr, Zeugnis am 31.01.2022 16:15 Uhr (ca. 5 Stunden)

WS22/23: mündliche Prüfung am 03.02.2023 15:45 Uhr, Zeugnis am 03.02.2023 16:50 Uhr (ca. 1 Stunde)

Links[Bearbeiten | Quelltext bearbeiten]

Highlights / Lob[Bearbeiten | Quelltext bearbeiten]

noch offen

Verbesserungsvorschläge / Kritik[Bearbeiten | Quelltext bearbeiten]

  • Für die ersten drei Beispiele reicht das Wissen aus Programmkonstruktion aus, dafür sind sie in Summe sehr aufwändig, da relativ viel Funktionalität verlangt wird. Ich hatte den Eindruck, dass das Ziel ist, die Teilnehmerzahl für die "richtigen" Beispiele (4+) zu reduzieren.
  • WS10/11: Viele Aufgabenstellungen sind unklar, schlecht formuliert oder überhaupt komplett wirr. Zwei kurze Auszüge:
    • "Die über den Iterator zugänglichen assoziierten Objekte entsprechen Iteratoren des Typs AssocIter, welche (so wie hier für den Wurzelknoten beschrieben) über die Label der Kanten iterieren, die von dem Knoten ausgehen, der über die Kante erreichbar ist, dessen Label zuletzt von next zurückgegeben wurde." (Aus WS10/11 Aufgabe 5)
    • "Erstellen Sie eine Menge von Fuhrparks von jeweils einigen Fahrzeugen – wirklich eine Menge von Fuhrparks, nicht nur eine Ansammlung einzelner Variablen." (Aus WS10/11 Aufgabe 6)
    • Dies wäre an sich nicht sonderlich schlimm - wenn die Aufgaben dann nicht aufbauend auf solchen Sätzen beurteilt werden. Zitat aus einer Beurteilung: "- 6 Menge von Fuhrparks fehlt" --emptyvi
Vielleicht liegt es ja an mir, aber ich finde die zitierten Saetze ziemlich klar und eindeutig. -- Mati 13:01, 23. Dez. 2010 (CET)
Für Angehende mag's etwas unklar wirken, aber ich finde die Aufgaben ebenfalls verständlich. --thomas 14:42, 23. Dez. 2010 (CET)
Hm.. Soweit ich das sehe verbirgt sich im ersten Satz doch sogar ein logischer Fehler.. Knoten haben keine Labels - "dessen Label" bezieht sich aber offenbar auf Knoten. Imho sollte dort "deren" stehen, damit der Satz zumindest irgendwie Sinn ergibt. Im zweiten Satz ist es meiner Meinung nach (und wenn man sich die entsprechenden Threads im informatik-forum durchliest war unsere Gruppe dabei bei weitem nicht alleine) völlig unklar was gewollt ist. Will man eine Liste von Fuhrparks? Soll man selber einen eigenen Container Fuhrparkmenge erstellen? --emptyvi

Imho liegt der Schlüssel zur Weisheit für den zweiten Satz beim "nicht nur eine Ansammlung von Variablen". Gewollt war denke ich eine wie auch immer geartete Collection die mit einer Schleife mit Fuhrparks gefüllt wird. Im Gegensatz zu einigen Fuhrparks die eigene Variablen haben.

WS20/21: es wär super, wenn Fragen im Forum nicht so ausschweifend beantwortet werden, dass man sich nachher weniger auskennt als vorher. auch das skriptum ist irgendwie mehr auf das formulieren schöner Sätze ausgelegt, als auf Verständnis der Themen (musste es mir zweimal durchlesen)

WS20/21: Es wäre super, wenn nicht auf so veraltete, schlecht Technologien gesetzt werden würde. Alles von SSH Private Keys von Server runterkopieren bis zu wahnsinnig schlechtem Java Code durften wir hier erleben. Auch die Bewertungen sind willkürlich und witzig. Man muss immer erraten, was der Professor sich genau vorstellt, ansonsten macht man garantiert etwas falsch. Egal ob der Code perfekt geschrieben ist, wenn Puntigam dieses Mal eigentlich keine Extra-Methoden fürs Testen haben will, dann ist es schlecht. Im Skriptum steht, dass Interfaces abstrakten Klassen zu bevorzugen sind. Jedoch, wenn man Interfaces verwendet, bekommt man Punkteabzüge für zu viele public Methods.

WS21/22: Fuck this shit - hoffentlich wird nie neue LVA besser

Materialien

Neues Material hinzufügen

A

B

D

E

F

G

S

U

W

Z

Abgerufen von „https://vowi.fsinf.at/index.php?title=TU_Wien:Objektorientierte_Programmiertechniken_VU_(Puntigam)&oldid=179289“