So, dann würde ich euch bitten,
langsam das Reden einzustellen, damit wir anfangen können.
Juhu, es ist die letzte Vorlesung SE2.
Das will ich hören, das will ich hören.
Sehr schön. Übersicht für etwas, was wir heute machen wollen.
Ich werde noch ein paar Folien aus dem Skript vortragen,
die solltet ihr aber eigentlich euch nochmal in Ruhe durchlesen.
Ich werde also jetzt nicht alles,
was da noch so an Folien zum Testen war,
Hier auflegen und auch nicht ausführlich besprechen.
Also da gern noch mal ein bisschen nachlesen. Aber ich werde
das Thema Test noch mal so ein bisschen exemplarisch hier beleuchten.
Dann plane ich einen Rückblick, insbesondere auf die Laborphase 2,
also auf den Übungsbetrieb. Also wie war dieses Semester?
Wir haben da ja wieder ein bisschen was gelernt in der Durchführung.
Auch da würde ich gerne das ein oder andere live zeigen.
Und am Ende werde ich noch einen Blick werfen auf
die Ergebnisse der leeren Evoluation. Die sind inzwischen da.
Und das ist immer ganz spannend, mal zu gucken,
was hat sich vom Vorjahr geändert?
Sind wir
besser geworden
Geworden. Und was ist so das Frei-Text-Feedback? Ich werde
auch noch eine Folie da haben zum Thema Klausur,
also da auch nochmal ein paar Worte dazu sagen.
Aber außerdem wollen wir heute mal einen ersten realen Test von einer Software machen,
die für stärker interaktive Vorlesungen eingesetzt werden kann.
So, ja, jetzt wird es cool.
Also ihr seid jetzt quasi dabei,
wie wir das hier das erste Mal in einer Informatikveranstaltung einsetzen.
Und zwar geht es eigentlich um freie Software für interaktive Vorlesungen.
Wolf Posthoffer sitzt da vorne, Bachelorstudent, SSE-Studierende,
der arbeitet gerade in seiner Bachelorarbeit zu diesem Thema,
wie man denn mit freier Software interaktive Software und interaktive Vorlesungen unterstützen kann.
Und um Vorlesungen interaktiver zu machen, eine Möglichkeit ist,
ich kann anonymes Feedback über ein Booting-System einholen.
Das heißt, wir werden jetzt hier gleich ein Vooting-System einsetzen
und ihr habt dann die Möglichkeit, Feedback zu geben,
zu Fragen, die ich stelle.
Die Uni hat so ein Feedback-System angeschafft,
bei dem Fernbedingungen eine Rolle spielen,
die sehen ungefähr so aus,
die habe ich welche
Das sind sogenannte Clicker. Ich weiß nicht,
ob ihr schon mal, wer mit Millionär gesehen habt,
da gibt es auch so Dinge, das Publikum darf dann,
wenn der Publikumsjoker zum Einsatz kommt, da bis dann auch solche Clicker verwenden.
Und auf diesem Clicker sind hier jetzt zehn Tasten,
eigentlich sogar noch ein paar mehr, aber so zehn mögliche Auswahltasten,
A bis J. Und ja, die werden wir gleich mal einsetzen.
Das Problem ist aber natürlich, dass das proprietär ist,
das heißt, das muss man kaufen, das kostet Geld.
Und deswegen haben wir überlegt,
könnten wir das nicht ein bisschen anders machen Studienbüro hat,
insbesondere nicht unser Studienbüro, sondern das E-Learning-Büro, das E-Learning-Büro,
der Viso-Fakultät, hat sich da so ein bisschen mit beschäftigt,
hat auch diese Clicker mal angeschafft.
Und die haben dann gesagt, wäre es nicht ganz cool,
wenn man auch mit einem Smartphone abstimmen könnte in der Vorlesung.
Oder mit einem Laptop. Man könnte hier sitzen und könnte
sozusagen direkt interaktiv Feedback geben. Das wäre natürlich toll.
So ein System haben wir jetzt. Die Lösung von Wolf,
die funktioniert, sie ist prototototypisch, das heißt,
so in der Oberfläche noch ein wenig, sagen wir,
verbesserungsfähig, aber von der Funktionalität scheint alles da zu sein.
Wir wollen das jetzt ja auch testen,
wir haben es schon im kleineren Kreis getestet.
Und ich würde es gerne heute jetzt auch hier mit euch testen.
So, meine allererste Frage an euch ist und bitte einfach
dann mal melden, deutlich die Hand hochheben.
Wer hat kein Smartphone dabei und wer hat keinen Laptop dabei?
Bitte? Also, sagen wir mal so,
ein Telefon, mit dem man ins Internet gehen kann,
eine Webseite sich angucken kann.
Das nenne ich Smart. Das brauchen wir an Smartness
hier für diese Veranstaltung. Also, wer hat jetzt
weder ein Smartphone dabei noch einen Laptop
Wunderbar, das sind ungefähr zehn Leute,
kommt bitte mal nach vorne und holt euch so eine Fernbedienung.
Dann könnt ihr nämlich auch teilnehmen. So,
wir haben 50 Fernbedienungen, die würden wir auch am Ende
gerne wieder alle vorne haben
Also 50 Klicke haben wir. Es wird gleich so sein,
wenn ich das mal hier gleich teste.
Also diese Software von Rolls sieht so aus,
das ist die Software hier, die ich benutze.
Da starte ich so verschiedene Sachen. Ach, ja,
ach, ach, ach. Warum sagt der denn überhaupt nichts?
Mann, Mann, Mann, das ist schon wieder,
ich bin schon wieder so unorganisiert hier. Moment,
jetzt muss ich mal ganz kurz hier, das geht ja gar nicht.
So, da ist ja, steht ja schon alles.
Mann, das habe ich dreimal alles erzählt.
Ich dachte, das wird ihr schon sehen. Also,
Wolf, Arbeit interaktiv, anonymes Feedback, Voting-System,
Clicker, Smartphone, Laptop, heute hier testen.
Alles klar, habe ich ja erzählt.
Diejenigen, die jetzt einen Clicker haben,
wenn ich jetzt diese Software hier benutze,
dann wird es gleich bei der Abstimmung,
wenn ich also hier auf die Abstimmung gehe,
dann wird es so ein Screen erscheinen,
ich kann das hier mal zeigen, hier so meine,
so zum Beispiel an wie vielen SE2-Vorlesungen hast du teilgenommen in diesem Semester,
dann werden hier oben in der Ecke, werden gleich,
wenn Wiederabstimmung starten, werden dann Nummern erscheinen.
Auf diesen Clickern sind Nummern. Wenn ihr die Dinger umdreht,
dann steht da hinten so eine Nummer drauf.
Und wenn ihr eigentlich ganz genau hinguckt,
macht ihr den Batteriedeckel auf und guckt,
ob die Nummer, die da drin steht,
dann immer auf dem Deckel übereinstimmen
Also witzige Studenten haben das irgendwie dann immer mal wieder ausgetauscht.
Weil das ist die Nummer, die dann auch da erscheint.
Das heißt, ihr könnt sehen, ob euer Voting angekommen ist.
Ja, das könnt ihr, also ihr kriegt das Feedback.
Okay, das ist Nummer eins. Also die Leute mit
den Klickern sind erstmal versorgt. Die wüssten jetzt zum Beispiel,
was sie drücken müssten, wenn sie da jetzt antworten müssten.
Aber das ist noch nicht gestartet. Ich muss erst hier
auf den Startbutton klicken. Aber jetzt kommen die anderen.
Wer von euch hat ein Smartphone dabei?
Das sind ziemlich viele. Ha, wie viele von euch
haben ein Barcode-Rieder
Ah, auch ein paar. Sehr schön. Die mit dem Barcode-Reader,
die können jetzt mal versuchen, diesen Barcode zu lesen.
Man nennt ihn auch QR-Code, ja? Ich weiß nicht
, ob das funktioniert. Das ist voll der Beleuchtung,
klappt. Bei einem hat es geklappt. Ja,
ich höre es schon pingeln, sowas scheint zu klappen.
Ja. Ich kann es noch weiter dunkler machen, ja.
Ich kann auch mal die Beleuchtung ein bisschen hier.
Ist das besser
Lasst euch Zeit. Wir wollen das schön vernünftig austesten.
Okay, wer hat jetzt den Barcode nicht lesen können?
Das sind so ein paar. Das macht nichts.
Denn die, die jetzt den Barcode nicht lesen konnten,
können auch eine URL angeben in ihrem Browser
Diejenigen machen, die mit dem Laptop da sitzen.
Wir sitzen mit dem Laptop hier, wer hat denn seinen Laptop aufgeklappt?
Die komplette hintere Reihe da, toll, ja.
Die wollen sich gar nicht in die Karten gucken lassen,
okay. Okay, also dann sieht das so aus,
ich klicke hier wieder drauf, dann kann ich hier mal
eben umschalten auf die Folien und habe hier der Link für Personen ohne Barcode-Scanner.
Tiny URL.com-u-H-H-S-I. Ich glaube, das ist richtig, oder?
Wolf? Ja. So, da müsste jetzt irgendwas stehen,
aber was vermutlich genau diese Frage,
steht da diese Frage auf dem Bildschirm
jetzt?
Toll. Wer hat jetzt diese Frage nicht auf seinem Bildschirm stehen?
Also wer kann das nicht sehen? Den Link nochmal zeigen, ja.
Tiny, you ael.com. Und dann UHHSE. So,
nochmal die Frage, wer kann jetzt noch nicht mit abstimmen?
Wer kann nicht mit abstimmen? Woran liegt es?
Bitte? Er tippt noch die URL ein.
Das wird zukünftig, ich spiele mit dem Gedanken, dieses Konzept einzusetzen in SE1,
weil man in SE1 sehr schön so interaktive Fragen stellen kann.
Ihr kennt ja unsere Multiple-Choice-Fragen aus den Klausuren. Dass dieser Prozess jetzt hier,
den wir jetzt machen, der wird dann wahrscheinlich wegfallen,
weil man dann immer dieselbe Yurale hat für die ganze Vorlesung.
Das heißt, ihr müsst das sozusagen nur einmal zu Anfang,
muss das gemacht werden und dann läuft es die ganze Veranstaltung durch.
Das ist ganz schön. So, also,
jetzt habt ihr alle die Möglichkeit, an dieser Abstimmung teilzunehmen.
Ich werde jetzt auf Start klicken und in dem Moment,
wo ihr, ihr habt auch selber,
wenn ihr jetzt auf dem Smartphone,
habt ihr auch so eine kleine ID bekommen und da sind dann so ein paar Ziffern hervorgehoben,
das sind genau die,
die ihr dann gleich sehen auf dem Bild
Die rauschen zwar durch, aber notfalls kann ich auch wieder scrollen,
um euch zu zeigen, dass eure Voting dabei ist.
Also ich starte jetzt mal. 14. Heute ist die
14. Vorlesung. So, jetzt könnt ihr abstimmen.
So, jetzt kommen schon 11 Stunden, 32 Stimmen.
Ja, das klappt ja wie verrückt.
Ihr seht, hier kommen die ganzen Stimmen rein.
Oh ja, 48 Stimmen. Oh ja, toll.
49 Stimmen, Wahnsinn.
52 Stimmen
Update-Problem. Da war Problem, also das ist hier noch
nicht so richtig, das ist eine Java-Applikation, ja.
Also man kann jetzt hier leider nicht viel sehen, ja, aber...
Okay, es ist ja auch nicht so schlimm.
Es soll ja erstmal nur funktionieren. Also,
wir gucken jetzt einfach mal, wie das so,
also 54 Stimmen, das kommt ja ungefähr hin,
da sind ungefähr 54 Leute da, ich hätte so auf ein paar mehr getippt.
So, jetzt halte ich das wieder an.
Ah, ah, ah, ah, ah.
Oh, zu schnell getippt. Also, nochmal Abstimmung gestoppt.
Jetzt haben wir so 54 Stimmen. Jetzt kann ich mir
als erstes anzeigen lassen, wie die Verteilung war bei den Antworten.
Das klicke ich hier drauf und sehe das hier.
Mann, ob ihr da mal nicht geflunkert habt.
Also, nur noch mal jetzt zum Vergleich.
Die Fragen kann man jetzt leider nicht sehen.
Ich kann aber das wieder ausblenden, so.
Also an mehr als 12e ist die Antwort. Da haben
immerhin 46, 48 Prozent teilgenommen. Das heißt, natürlich,
die, die jetzt hier sind, das sind auch die,
die mehr oder weniger die ganze Zeit dabei waren.
Aber es gibt auch Leute, die haben hier nur an
dieser Vorlesung teilgenommen und dann so eine Verteilung.
So, das war jetzt eine Umfrage
Bei der es keine richtige Antwort gibt. Davon gibt es
noch mehr. Ich kann jetzt hier noch mal auf die
nächste Frage gehen. In welchem Studiengang studierst du denn?
So, ihr seht wieder die Antwortmöglichkeiten. Ich starte die Abstimmung.
Ihr könnt einfach mal eure Stimmen abgeben. Ach ja,
ihr müsst eventuell im Browser die Seite neu laden,
damit ihr die Frage seht.
Also müsst ihr irgendwie so einen Refresh machen.
Wie das in eurer Software geht, weiß ich nicht.
Ah, da kommen schon wieder 25 Stimmen rein.
Sehr schön. 37 Stimmen, toll
44 Stimmen. Großartig. Ja. So, jetzt könnt
ihr auch wieder gucken, ob eure Nummer dabei ist.
52 Stimmen. Ja, jetzt können wir nicht mehr gucken.
Wie ist hier so ein Update-Problem? Ja, gut,
aber 58 Stimmen, immerhin.
Toll. Na, jetzt hier 59 Stimmen. So,
also das, da müssen wir noch ein bisschen dran feiern.
Gut, es sind jetzt 64 Stimmen da.
Toll, toll. Also die ganz schnellen sind die
hier unten
Könnt ihr mal so gucken, wer so dabei war.
Und hier oben sind die, die zuletzt dazugekommen sind.
Ich könnte selber eigentlich auch abstimmen, wo ist mein Smartphone?
Nee, ist egal. Gut. Dann halte ich das
jetzt mal an. 64 Stimmen sind da. Und jetzt
gucken wir mal wieder, wie sich das verteilt hat.
Oha, okay. Also, sonstige sind relativ viele,
25 Prozent. Dann haben wir hier Bachelor-Informatik,
25 Prozent, Bachelor-Wirtschaftsthematik, 25 Prozent ungefähr.
Und der Rest verteilt sich so auf die anderen Studiengänge.
Mal ganz kurz gucken, SSE ist C, 12 Prozent.
Denn? Das ist alle Menschen,
die sonstiges mitfahren
Ja, können sich alle melden, meldet euch mal.
Wer hat Sonstiges gewählt? So viele sind es wahrscheinlich dann
auch. Gut. Okay, also auch hier,
auch hier, gab es keine richtige Antwort.
Ja, abgestimmt. Es hat so Gedanken für uns da.
Ich sag mal, es war einmal. Du kannst du auftippen,
wie du willst, aber es wird nur ein erster Tipp angenommen.
Weißt du, wir beziehen die Enquete 4,
5 Jahre, wir haben jetzt nicht 55 Prozent dargestellt
Naja. Wer weiß, vielleicht haben Leute auch völlig falsche Tasten gedrückt.
Also die können natürlich die Ergebnisse nochmal so ein bisschen jetzt uns genau angucken.
Wir können ja nochmal schauen. Also das sind jetzt bei
64 Stimmen sind 16, 25 Prozent sind ziemlich genau 16 Leute.
Also 16 Leute sollten Sonstiges getippt haben.
Wer hat Sonstiges getippt? 1, 2, 3,
4, hoch die Hand, damit ich das sehen kann.
1, 2, 3, 4, 5, 6
, 7, 8 Das scheint nicht so ganz zustimmen.
Müssen wir noch mal gucken. Dann haben wir Informatik.
Wie viele haben denn Bachelor-Informatik angegeben? 1, 2,
3, 4, 5, 6, 7,
8, 9, 10, 11, 12,
13, 5. Ja, das kommt hin.
16. Das kommt hin. Während Bachelor Wirtschaftsinformatik angegeben? Ah,
1, 2, 3, 4, 5,
6, 7, 8, 9, 10,
11, 12, 13, 14, ja, passt.
Also das mit den Sonstiges waren vielleicht doch mehr,
als ihr zugeben wollt,
keine Ahnung
SSEler sind hier 12,2 Prozent. Das ist ja auch ziemlich
, da müssen 8 sein. 8 SSEler, 1,
2, 3, 4, 5, 6,
7, 8, kommt hin.
Irgendwie sowas. Ja. So, wie gesagt,
auch bei dieser Frage gab es jetzt keine richtige Antwort.
Obwohl man natürlich sagen könnte, SSE,
aber das wäre ein bisschen voreingenommen.
Gut, wir kommen jetzt, ja.
Oh, oha.
Gucken wir mal
Nee, das ist die falsche Frage.
Moment, hier. Mathe ist G oder Haar?
G. Tja, vielleicht wird das nicht richtig dargestellt hier.
Nur eine Stimme. Wer studiert sonst Mathe und mit Informatik als Nebenfach?
Da bist du die einzige, möglicherweise ist das zu wenig,
um es anzuzeigen. Ja, Physik wird auch angezeigt.
Wer ist denn hier Nebenpachphysik? Physik mit Nebenfach Informatik?
Eins? Eins, zwei. Zwei. Seht ihr?
Ja. Also zwei sind dann schon hier, ja,
und dann, also einer ist anscheinend zu wenig
Das sind alles Sachen, ich glaube, da kann man noch dran feilen.
Das ist eher eine prototypische Implementation, wie gesagt.
Gut. Um jetzt mal das ein bisschen interessanter zu machen,
gucken wir uns das mal an für eine richtige Informatikaufgabe.
Wie viele Interfaces kann ein Interface in Java erweitern?
Ich würde euch bitte nicht zu reden, sondern einfach erst
mal abstimmen. Also jeder für sich überlegen, abstimmen,
also viele Interfaces kann Interface in Java erweitern mit Extense.
Keins, genau eins, entweder eins oder keins oder beliebig viele.
So, ich starte die Abstimmung und jetzt kommen
die Stimmen rein
28 Stimmen sind schon da. 34 Stimmen sind da?
Das Update geht so alle 5 Sekunden, 43 Stimmen.
Ihr könnt euch für irgendwas entscheiden. Das ist ja anonym.
Keiner kriegt das mit. 46 Stimmen, sehr schön.
49, go, go, go. 51 Stimmen,
toll. 54 Stimmen. Also wir müssen ein bisschen
die Zeit im Auge behalten, wie lange sowas dauert,
bis das so einfließt hier.
55 Stimmen, sehr schön.
Man kann wieder jetzt
was sehen
Das ist die eine Hälfte und das ist ungefähr die andere.
55 Stimmen, ja, das noch mal reichen. Abstimmung gestoppt. So,
jetzt ist es natürlich erstmal spannend, die Verteilung zu sehen.
Ich gucke mir jetzt die Verteilung an, zack.
Oh. Au. Oh. Okay. Einmal umschalten und Kein Ergebnis
. Schade, schade, schade. Okay. So,
damit muss man leben, dass das irgendwie manchmal nicht so gut funktioniert.
Probieren wir mal das Nächste. Wie nennt man das Ändern
der Implementation einer Operation, einer Unterklasse,
durch die eine andere Methode für dieselbe Operation eingesetzt wird?
Ich starte die Abstimmung und wir schauen mal, ob das da klappt.
Also Abstimmung gestartet. Ist das A, überladen?
B, redeklarieren, C, verifizieren oder D redefinieren
Das hat nicht bestimmt. Also soweit bin ich ganz zufrieden,
das klappt ganz gut, also da kommen immer genügend Stimmen rein.
Okay, 53 Stimmen, ich glaube so in der Größenordnung
bewegt sich das so.
Ich breche jetzt ab, Abstimmung gestoppt.
So, auch mal schauen,
ob es jetzt klappt
Ja. So. Ah, okay, jetzt wird das hier nochmal angezeigt, der Text.
Hast du es noch da reingebaut? Okay. Okay,
man hat jetzt hier so verschiedene,
man sieht hier die verschiedene Antwort, Antwort, also überladen,
sagen immerhin 23 Prozent, redeklarieren, sagen 20 Prozent,
50 Prozent sagen redefinieren und immerhin auch ein paar Prozent sagen,
es ist verifizieren.
Sehr schön. Ja,
und vielleicht klappt es ja jetzt
Tatsächlich mal reale Ergebnisse. Und jetzt kann ich eben halt
auch dann zeigen, was die richtige Antwort ist.
Und man sieht hier, juhu, 52 Prozent haben die Antwort richtig gewählt.
Das nennt sich Redefinieren. Redeklarieren ist ja,
wenn ich die Signatur ändere und überladen heißt,
wenn ich einfach zwei Methoden in derselben Klasse habe mit demselben Namen.
Aber mögliche, nee. Und verschiedener Signatur. Gut. Das einfach
nur mal, dass ihr diese Software mal gesehen habt.
Wir werden jetzt dann so, ich habe noch so ein,
zwei, drei weitere Fragechen. Aber jetzt will ich erst mal
so ein bisschen Inhalt machen und dann können wir sehen,
ob wir das weiter einsetzen können.
Also könnt die Geräte einfach mal kurz zur Seite legen,
aber irgendwie werden die sie gleich wieder nach vorne holen
Okay. Ich will jetzt nochmal so ganz paar Kleinigkeiten erzählen zum Testen, interaktiver Software,
weil man eben halt, wenn man so klassische Testverfahren ansetzt,
da gibt es eben halt bei der Objektorientierung so ein paar Unterschiede.
Wir haben schon das Thema Testen gehabt in der SD2
und wir haben es ja auch in SE1 schon gehabt,
aber jetzt sind nochmal so ein paar Punkte,
die interessant sind, nachdem wir Vererbung,
Vertragsmodell,
Entwurf und so weiter uns angesehen haben,
was man da vielleicht nochmal so
ein bisschen beachten kann
Okay, Literaturhinweise, wie immer, ganz wichtig,
der Robert Binder wieder. Spielen da Linz sowieso. Und
wenn man auch noch ein bisschen mehr bei Unit Tests mit
Java nachlesen will, kann man den Link nehmen.
Gut, dann hier eine Folie voller Text, schrecklich,
also kurz zusammengefasst. Die kleinste sinnvoll testbare Einheit in der
Objekte der Römierung ist die Operation im Kontext einer Klasse.
Wir können also in der Objektorientierung selten eine Operation isoliert testen,
weil die steht immer irgendwie im Zusammenhang mit dem Objekt,
an dem sie klebt und dieses Objekt gehört immer zu einer Klasse.
Man muss also immer den Kontext einer Methode sehen in
ihrer Klasse
Ein typisches Problem, wenn man ein Objekt in dieser Software testen will,
ist die Cupsellong. Wir haben mehrfach darauf hingewiesen,
dass es eine gute Idee ist, Entwurfsentscheidungen zu kapseln.
Das heißt, ihr solltet möglichst viel bei einer Klasse
privat machen und nur euch sehr wohl überlegte Schnittstellen ausdenken.
Das heißt, das,
was ihr wirklich an Dienstleistungen nach außen geben wollt für Klienten,
das wird in öffentlichen Methoden implementiert und
alles andere möglichst privat
Das erschwert aber den Test, wenn ich dann nur Blackbox-Tests mache,
das haben wir ja schon in SC1 gehört,
wenn ich nur die Schnittstelle teste, also das,
was möglich ist, mit so einem Objekt.
Dann wird da häufig nicht alles abgedeckt. Es ist also tatsächlich so,
dass es so einige Ausführungspfade innerhalb der Klasse gibt,
die man vielleicht gar nicht mit testet.
Beim Test ist es aber relativ oft auch zu wissen,
wichtig zu wissen, dass man feststellen kann,
welchen Zustandsraum hat in so einem Objekt wirklich,
also welche Exemplarvariablen können welche Zustände annehmen.
Wie ist die Klasse strukturell eingebettet und
welche Abhängigkeiten ergeben sich daraus
Dafür ist es dann ganz gut,
wenn man auch diesen gekapselten Zustand dann doch irgendwie zugreifen kann.
So, jetzt wollen wir auf der einen Seite das Klienten dann nicht rankommen.
Und auf der anderen Seite wollen wir als Tester da irgendwie rankommen können.
Und da gibt es eben halt verschiedene Möglichkeiten. Man kann diese sondierenden Operationen,
um da auf diese, also um diese Operation,
ich zeige es vielleicht mal live an einem Beispiel,
ist viel einfacher.
Wir starten mal Eclipse. Da nehmen wir doch zum Beispiel
mal die Klasse Geldbetrag
Ich muss hier erst mal alles zumachen. So,
wir betrachten hier Kinoticket-Verkauf, meine persönlich favorisierte Musterlösung.
Und da gibt es hier die Fachwerte. Und da gibt es
hier den Geldbetrag. Und wenn sich das jetzt anguckt,
dann sieht der ungefähr so aus, Geldbetrag hat einen Long als Exemplarvariable.
Das habe ich auch, glaube ich, schon mal gezeigt in der Vorlesung.
So, jetzt gibt es hier einen privaten Konstruktor,
der diesen Gesamtbetrag da, diesen In,
als Int entgegennimmt und dann in Long ablegt.
Und dann gibt es hier, Vorkommaanteil und getten Nachkommaanteil.
Die Lösung, von der ich es übernommen hatte, da war das öffentliche Operationen.
Da konnte man sich von so einem Geldbetrag den Vorkommadanteil,
den Nachkommadanteil geben lassen. Hier ist es jetzt privat gemacht,
weil es für die Schnittstelle eigentlich nicht relevant ist,
weil das im ganzen Rest des Systems nirgends gebraucht wird.
Man musste nirgends getrennt auch Vor- und Nachkommastellen zugreifen.
Das war so zu sagen, Technologie auf Vorrat. Das heißt,
ich habe mich jetzt entschlossen, das nicht an die Schnittstelle zu geben.
Es wird aber intern noch benutzt. Nämlich dann,
wenn das in eine Stringumwandlung dargestellt wird, eine stringende Darstellung umgewandelt wird. Das heißt,
ich bekomme so ein Int als Selektorparameter dann habe ich einen Geldbetrag
und dann möchten wir die Tage two stringen oder lasst mir den formatiert geben,
dann soll er ja so ein Komma dazwischen sein,
dann muss man ja irgendwie wissen, was ist der Vorkommandanteil,
was er denn noch gemacht hat.
Das heißt, man braucht diese Operationen, aber nur intern.
So, jetzt würde ich gerne,
wenn ich das mit einem Wildbox-Test testen will,
also wirklich alles testen will, was da so an Code passiert,
dann würde ich gerne diese beiden Operationen auch testen.
Die sind aber jetzt privat. Ich komme also als Klient
gar nicht rein, auch als Testklasse nicht.
Jetzt kann ich das entweder so machen,
dass ich per Reflection irgendwie die Dochversuche aufzurufen,
da dann irgendwie noch die Rechte ausschalte,
haben wir letzte Woche gelernt,
sehr umständlich,
sehr mühsam
Eine andere Möglichkeit ist, ich sage jetzt einfach hier nicht,
dass diese beiden Operationen private sind, sondern die sind gar nichts.
Die sind default. Ich kann also das hier einfach rausnehmen.
So. Dann sind sie, haben sie die Foldsichtbarkeit.
Das heißt, sie sind innerhalb dieses Paketes sichtbar.
Das heißt, wenn die Testklasse mit im gleichen Paket ist,
dann kann die zugreifen.
Alle anderen Klienten aus Paketen außerhalb können nicht drauf zugreifen.
Kann man machen. Er fordert aber dann wieder Disziplin,
dass dann nicht andere Klassen im selben Paket nicht auch diese Schnittstelle benutzen.
Das ist sozusagen eine Paketinterne Schnittstelle,
die hier entsteht.
Kann man
so machen
Man könnte es auch public machen, aber dann wäre es tatsächlich so,
dann wäre es mit an der Schnittstelle alle Klienten.
Und mancher Klient würde vielleicht sagen, wofür brauche ich das denn?
Also das ist dann, und ich will auch eigentlich nicht,
dass es an der Schnittstelle ist. Also das einfach nur,
das ist so ein Aspekt, den man sich mal angucken kann,
wie man denn diese Kapselungsfragen umgehen kann.
Und das ist halt, durchaus kommt es vor,
dass man für Tests den Zugriffsschutz ein bisschen lockert.
Also wie wir es jetzt hier gemacht haben, mit dem die Vorzugriff.
Okay, das ist mehr oder weniger das,
was auch hier auf der Folie steht.
Dann ist ein weiterer Aspekt, ist so dieser Umgang mit Subtyping.
Also wenn wir Vererbung im Sinne von Subtyping interpretieren. Also wir wollen immer,
dass ein Typ sich verhält wie ein Subtyp eines anderen,
mit all den strengen Regeln, die es ja ans Subtyping gibt.
Es ist dann natürlich so, dass man zwar viele Probleme erstmal,
wenn man so Subtyping-Conformance, viele Probleme,
die man so mit Implementationsvererbung hat, da erstmal nicht mehr hat,
aber trotzdem kann ich natürlich nicht verhindern, dass in einer,
in einem Subtyp die Semantik an der Operation komplett geändert wird.
Da haben wir ja keine Kontrolle drüber. So,
und das heißt also, wenn wir so Typhierarchien haben mit abstrakten Klassen,
mit Interfaces, dann ist das auch nicht ganz so leicht,
das zu testen
Einige von euch, da ist eine Frage. Wenn das auch vorbeigesetzt wird,
das ist einfach eine Doku, das muss ich machen.
Die Frage war, wenn die Sichtbarkeit einer Methode auf Default
gesetzt wird, ob es dann in der Dokumentation wird.
Das hängt davon ab, wie die Dokumentation eingeführt wird.
Man kann bei JavaBock, was eigentlich Man kann auch tatsächlich bei Javadoc sagen,
es sollen auch private Methoden in die Dokumentation mit rein.
Das kann man auch. Man muss dann eben halt Javadoc,
dass bei dem, bei dem Javadoc von,
von der Java API ist, soweit ich weiß, nur protected.
Bis protected wird es, wird es angezeigt.
Aber ich glaube, die Paket, die Vorsichtbarkeit nicht.
Ich bin mir aber nicht sicher. Muss man einfach
mal nachgucken. Gut, das war nochmal zur Sichtbarkeit,
aber jetzt hier die Sache mit der Vererbung.
Was ihr schon erlebt habe, ist, dass es sowas gibt.
Ihr schreibt eine abstrakte Klasse und ihr habt ein Interface und die
sollen irgendwie zusammenspielen. Das Paradebeispiel, was ihr kennt,
ist der gute Beobachter bei den Werkzeugen,
solltet ihr ja beobachtbare Subwerkzeug bauen oder irgendwie eine Klasse beobachtbar.
Wir haben das hier in dieser Lösung, heißt das beobachtbares
Subwerkzeug und Subwerkzeugbeobachter. Ich zeige die beiden mal,
also Subwerkzeugbeobachter ist ein Interface,
sehr einfach
Beachte Änderung. Also alle Beobachter werden im Falle eines Ereignisses
informiert, indem an ihnen beachte Änderungen aufgerufen wird.
So, das ist das eine. Und dann gibt es
noch beobachtbares Subwerkzeug. Und die ist abstrakt. Das eine
ist ein Interface, die andere ist abstrakt. So,
jetzt ist es hier so, man sieht hier,
hier wird eine Menge von Subwerkbeobachtern angelegt und dann wird hier irgendwie dafür gesorgt,
dass die alle informiert werden und so weiter und so weiter.
Und man kann auch Beobachter wieder entfernen. So,
und informiere alle Beobachter, hier werden alle Beobachter informiert.
Das ist ein Stück Code, Der ist ja ziemlich essentiell,
damit das auch wirklich funktioniert. Also wenn wir in so ein System haben,
wie unser Kinosystem oder die Mediathek, wo ganz viel sich Subwerkzeuge,
wo Subwerkzeuge bebeobachtet werden von ihren Kontextwerkzeugen,
dann ist das ein Mechanismus, der sehr wichtig ist,
sehr zentral.
Der muss funktionieren. Und wir wollen natürlich sowas auch testen.
So, wir können jetzt die konkreten Werkzeuge testen.
Das ist aber ziemlich doof, weil die Dinge sind ja interaktiv.
Das heißt, was wir idealerweise machen,
wir bauen eine Testklasse nur für diesen Code.
Und da werdet ihr jetzt sagen, naja,
wie soll ich das denn testen?
Das ist eben gar nicht so schwierig. Man definiert Eine
konkrete Unterklasse von der Abstraktenklasse, die die beerbt und man
definiert eine konkrete Klasse, die das Beobachter-Interface implementiert.
Das sieht dann so aus wie hier auf der Folie.
Ich habe also hier abstrakt beobachtbar, das informiert alle Beobachter.
Und dann habe ich einfach Mock-Klassen. Das heißt,
ich kann Mock- oder Dummy-Klassen bauen und die kann ich wirklich definieren,
nur für den Test.
Ich mache also einen beobachtbaren Mock und einen Beobachter-Mock.
Und dann baue ich die so,
dass ich dann diesen Zusammenhang von mehrere Beobachter registrieren sich,
dann passiert was und dann will man feststellen,
ob die alle
auch benachrichtigt wurden
Das kann man tatsächlich testen. Und das zeige ich jetzt
konkret an diesem Beispiel, obwohl das ja ein relativ kleines Beispiel ist.
Also das hier beobachtbar ist ja wirklich winzig. Das geht
es ja nur darum, dass wirklich alle Beobachter informiert werden.
Aber das kann man sich sehr schön mal im Quelltext ansehen.
Ich habe das also jetzt mal heute Vormittag gebaut.
Das ging tatsächlich relativ schnell. Viel schneller, als ich
befürchtet habe. Hier ist beobachtbares Subwerkzeugtest. So,
also ich habe eine Testklasse,
beobachtbares Subwerkzeugtest
Dann habe ich hier eine Klasse, und ihr seht ihr jetzt schon,
ich habe jetzt hier eine private Klasse innerhalb des Rumpfes dieser Testklasse.
Weil diese Beobachter-Mock-Klasse, die brauche ich ja nur innerhalb der Testlaste.
Die muss also nicht weiter sichtbar werden.
Die ist schön gekapselt in dieser Testklasse. Also mal ein
wunderbares Beispiel für eine statische, geschachtelte Klasse.
Beobachter-Mock, Implements, Subwerkzeugbeobachter. Das ist also ganz einfach,
ich implementiere das Interface. Ich habe dann hier ein Bullyen,
wurde informiert, der ist am Anfang auf Falls.
Dann gibt es eine beachte Änderung, muss ja implementiert werden
für das Interface
Dann wird hier irgendwie dieser Buhl gesetzt. Und dann kann man
als Klient abfragen, ob das Ding auch wirklich informiert wurde.
Wurde informiert, es wird hier irgendwie rausgegeben. Total einfach.
Ich kann also meinen Beobachter irgendwie mir erzeugen und kann sagen,
so, den registriere ich jetzt mal und dann teste ich mal,
ob der auch benachrichtigt wurde.
Genauso habe ich noch eine zweite Klasse. Private Static,
beobachtbar, Mock. Externe, fahres Lobwerkzeug. Und die
macht auch nicht viel, simuliere Änderungen, informiere alle Beobachter.
Die macht sonst nichts. Es geht ja nur darum
zu testen, diese Benachrichtigung funktioniert. Das heißt also,
diese Klasse hier, diese Mock-Klasse ist sehr einfach zu schreiben.
So, und dann gucken wir uns jetzt an,
wie da ein Ditter-Testfall aussehen. Ich habe hier ein,
zwei Testklassen, zwei Testmethoden geschrieben. Einmal Teste registrieren und
auslösen. Also, zuerst erzeuge ich mir zwei Beobachter.
Also zwei konkrete Beobachter. Und dann möchte ich erstmal fragen,
sind die noch nicht informiert? Das wäre ja schön.
Ich möchte sicher gehen, die sind noch nicht informiert worden.
So, dann mache ich mir hier so einen Auslöser,
also irgendwie so ein Ereignis auslöst, also etwas Beobachtbares.
Und dann registriere ich hier die beiden Beobachter bei dem
Und dann will ich erst mal testen,
ob allein durch das Registrieren möglicherweise schon Leute benachrichtigt werden.
Könnte ja sein. Weil er weiß,
was da für fehlerhafte Implemente zu unten sind. Also,
sage ich hier, ist Sird False, wurde informiert.
Ich möchte immer noch, dass die nicht informiert wurden.
Dann sage ich hier Auslöser, simuliere Änderung.
Was macht der, der benachrichtigt alle seine Beobachter?
Und dann hinterher sollte gelten von den beiden Beobachtern, dass sie benachrichtigt wurden.
Ganz einfacher Test. Und genauso habe ich dann hier Teste
de-registrieren und auslösen mir angekündigt. Das heißt, ich habe
das gleiche gemacht, ich habe wieder zwei Beobachter gebaut.
Dann habe ich meinen Auslöser gebaut, dann habe ich die beide registriert.
Dann habe ich bei beiden noch festgestellt, dass sie nicht beobachtet werden.
Das ist identisch wie bisher in der anderen Methode auch.
Und dann habe ich dir gesagt,
ich entferne den einen Beobachter wieder, bevor er informiert wurde,
dann simuliere ich die Änderung, dann würde ich hoffen,
dass hinterher nur noch Beobachter 1 benachrichtigt wurde,
aber Beobachter 2 nicht mehr.
Also das ist so richtig so ganz konsequent einfach mal das durchgespielt,
was man mit so einer Schnittschelle alles machen kann.
Das ist schon ein relativ vollständiger Test. Und wenn man jetzt sieht,
wenn ich das jetzt ausführe hier, Ich glaube,
ich habe das hier sogar irgendwo, ups,
wo ist denn hier meine, was sind die Leister hier?
Das sind ja ganz doch da oben. Hier, beobachtbares
Subwerkzeugtest. Ja, können wir Geldbetrag speichern. Und dann
kommt hier tatsächlich der grüne Balken. Also es lässt sich
tatsächlich so testen. Also auch das nur ein Beispiel,
wie man sowas machen kann und wie man dann
diese Mock-Klassen eigentlich ganz schön wegkapseln kann in diese Testklassen.
Okay. Gab es da Fragen dazu?
Ich glaube, das war
relativ einfach nachzuvollziehen
So, dann ist es natürlich auch so,
wenn man Polymorphie hat, ihr wisst, man kann irgendwie,
startet es eine Variable von einem Typ eines super Typs,
dann kann ich beliebig Exemplare von Unterklassen da benutzen.
Und eigentlich muss ich alle Kombinationen von möglichen Unterklassenobjekten wieder testen.
Das ist relativ aufwendig. Und wenn ich tatsächlich in einer Unterklasse etwas redefiniere,
dann muss ich das redefiniert natürlich testen,
aber ich muss auch eigentlich alles das testen,
was nicht redefiniert wurde,
weil das macht ja immer die Gesamtschnittstelle einer Klasse aus
Was insbesondere immer ganz wichtig ist, wir haben ja gelernt mit Vererbung und
dem Vertragsmittel, also insbesondere mit Subtyping und dem Vertragsmodell.
Wenn ein Subtyp, ein super Typ erweitert, dann darf beim Vertragsmodell,
dürfen keine Vorbedingungen verschärft werden und keine Nachbedingungen abgeschwächt werden.
Aber ich kann Vorbedingungen ja abschwächen. Ich kann ja sagen,
diese Klasse, wenn sie selbst direkt benutzt wird, nicht Polymorph,
sondern einfach direkt, dann kann sie schwächere Vorbedingungen haben.
Das ist zugelassen. Also wenn der Supertyp sagt,
muss im Bereich von 1 bis 10 liegen der Parameter und in dem,
in dem Subtyp kann es ruhig sein,
so kann im Bereich von 1 bis 100 liegen.
Das ist eine Abschwächung der Vorbedingungen und sowas ist möglich.
Dann ist das Ding tatsächlich alleine nutzbar und tatsächlich
auch mit diesem Vertrag nutzbar unter seinem direkten Ding.
Aber über den Supertyp immer noch, über die schärfere Vorbedingung.
Aber das heißt natürlich, soweit eine Reimplementation,
die Vorbedingung des Vertragsmundels abschwächt oder die Nachbedingung verschärft,
muss sich wieder diese neuen Grenzen, wir wissen ja,
beim Testen gucken wir uns über die Grenzen an,
müssen die auch wieder mitgetestet werden.
Okay, das ist also glaube ich, ganz gut nachvollziehbar.
Dann nochmal testen und das Vertragsmodell. Also wir haben ja
jetzt irgendwie Testen und Vertragsmittel beides kennengelernt,
also insbesondere das Vertragsmodell in diesem Semester.
Und da kam mir auch mal so die Frage,
braucht man überhaupt noch Tests, wenn man das Vertragsmodell hat?
Und das ist einfach, es sind verschiedene Dinge,
die ergänzen sich sehr gut. Testklassen werden eben nicht überflüssig
durch das Vertragsmodell. Die Zusicherung des Vertragsmodells machen so einige Aussagen,
welche Vorleistung man erwarten kann, welche Ergebnisse geliefert werden.
Damit hat man also schon mal diese Randbedingungen spezifiziert.
Das ist schon mal ganz gut. Man hat also auch,
man kriegt durch das Vertragsmodell Hinweise,
wo man
vernünftig testen kann
Außerdem ist es aber auch so,
dass im Vertragsmodell häufig so ein implizites Protokoll drinsteckt.
Also welche Operationen darf ich denn erst aufrufen nach einer anderen Operation?
Klassisches Beispiel Datei. Eine Datei in der Programmierung ist üblicherweise,
man muss eine Datei anlegen, da muss man sie öffnen.
Erst dann kann man reinschreiten. Ich kann also nicht
Ride schreiben, bevor ich nicht open aufgerufen habe.
Das ist im Vertragsmodell möglicherweise auch irgendwie festgehalten.
Das heißt also, Requires is open oder so.
Bei Ride als Vorbedingung. Und da ist entweder implizit oder
explizit so ein Protokoll zur Runde gelingt,
aber das kann man eben halt dann wieder wunderbar tatsächlich
auch in einer Testklasse ausimplementieren
Und wir haben ja auch schon gelernt, Testklassen sind sowas
wie ausimplementierte Semantik. Also dass man einfach sagen kann,
naja, genau so soll die Benutzung funktionieren.
Und wir können ja sogar, wenn wir sowas wie
abstrakte Datentyp-Definitionen haben, die Aktionen für die Tests hernehmen.
Welches Protokoll kann sinnvoll anhand dieses Zustandsmodells getestet werden?
Also das ist diese Idee, man versucht, die Zustände,
die da so auftreten können, explizit zu modellieren.
Also wenn wir zum Beispiel sowas haben,
wie das hier, Zustandsdiagramm eines Decks,
dann gibt es irgendwie so einen Anfangszustand,
dann kann man irgendwie sich einen leeren Stack erzeugen,
dann ist der im Zustand leer und dann kann man
auch IsMT abfragen
Und dann gibt es aber auch irgendwie,
wenn man was pusht, gibt es irgendwie den Zustand gefüllt.
Und dann ist natürlich klar, ich kann jetzt zum Beispiel
auf einem leeren Stack, kann ich nicht Pop aufrufen.
Das ist auch hier einfach erkennbar aus dem leeren Zustand.
Da ist es nicht möglich, Pop aufzurufen. Ich kann
nur, wenn das Ding gefüllt ist, Pop aufrufen.
Und ich kann aber, wenn der gefüllt ist,
auch top aufrufen oder Pop oder auch push, kann weiter was drauf pushen.
Und ist Empty, kann ich sowieso immer fragen.
Also sollte es eigentlich auch sein, dass so klassische Prädikate,
die auch für Vorbedingungen verwendet werden, häufig,
dass die eigentlich immer aufrufbar sind für alle Zustände,
in denen so ein sich befinden kann.
Ja, okay. Das war schon jetzt erstmal alles,
was ich so zum Thema OO-Testen sagen wollte.
Wie gesagt, im Skript ist da ein bisschen mehr.
Das könnt ihr euch in Ruhe nochmal durchlesen.
Gibt es jetzt noch Fragen zu diesem Thema Testen hier?
Fein, dann machen wir jetzt fünf Minuten Pause.
So, kleine Heldentat von meiner Seite.
Ich habe hier eben tatsächlich mit der Technik gepatzt
Das mit der Abstimmung hat alles wunderbar geklappt. Das Problem war
nur für diese Clicker, brauchen wir natürlich einen Empfänger.
An dieser Empfänger, der muss an meinen Rechner angesteckt sein
und hier ist er jetzt.
Und er ist jetzt angesteckt, er ist jetzt aktiv.
Das heißt, die, die Clicker hatten,
die wurden eben einfach nicht berücksichtigt. Das erklärt auch,
warum wir dann so wie niedere Zahlen hatten.
Also das war tatsächlich eine Null bei der Mathematik,
weil dein Voting nicht angekommen ist.
Deswegen machen wir jetzt einen weiteren Test. Also hier haben
wir Welche Ausgabe lief die Ausführungsmethode Main des folgenden Java-Programms?
Hier ist das Programm. Kann man das einigermaßen lesen?
Das sieht ein bisschen klein aus. Ihr seht zwei Klassen,
A und B und eine Klasse Test,
die dann in einer Main-Methode sich ein B erzeugt und dann System Outprinteln aufruft.
So. Welche Ausgabe liefert die Ausführung der Main-Methode des folgenden Java-Programms?
Ich starte jetzt die Abstimmung und dann könnt ihr alle
auch mit euren Klickern
mit abstimmen
Leider nein. Ich habe das, das ist jetzt auch improvisiert.
Normalerweise sollten Coach-Nipsel auch in der Software mit angezeigt werden.
Das ist noch nicht eingebaut. Deswegen habe ich jetzt hier so was anderes gebaut.
Das ist, wie gesagt, ein bisschen klein aus.
Ich habe gedacht, das ist ja auch ein bisschen größer.
Man sieht letztendlich eine Klasse A, die hat einen Konstruktor,
in dem steht System Outprint A, dann eine Klasse B,
die von A ererbt, mit einem Konstruktor B,
mit einem Konstruktor, da steht System Outprint B,
jeweils als Trink.
Und dann gibt es halt die Main-Methode,
die dann
ein B erfolgt
So. So, jetzt haben wir aber erst 46 Stimmen hier aufgenommen.
Möglicherweise sind da noch ein paar mehr. Also entscheidet euch,
entscheidet euch, wir dürften eigentlich jetzt so 64 plus 10,
10 Klicker sind irgendwie ausgeliehen.
Das heißt also, dürften so an die 70 Stimmen sein.
Vielleicht trauen sich auch nicht alle, jetzt abzustimmen.
Kann auch sein. 58 Stimmen, ja, es geht
voran. 61, ja, das ist gut.
Wenn wir jetzt irgendwann über 64 sind, dann glaube ich,
dass die Klicker jetzt auch wieder aktiv sind.
63, ja, ja, komm, go,
65, 66, ja. Sehr schön. Also tatsächlich,
die Klicker sind mit dabei. 67, sehr schön.
Okay, ich stoppe jetzt mal die Abstimmung. So,
jetzt bin ich gespannt, was so die Verteilung ist.
Und es geht wieder nicht. Ach, schade,
schade, schade. Na, mal gucken, ob man
das hier irgendwie hin und her blättern kann oder so.
Ja. Ach, wie schade, das funktioniert wieder nicht
Gut, also dann, ja, schade, schade,
schade. Also die Ergebnisse sind aber festgehalten, oder?
Okay, dann gebe ich erst mal die Lösung.
Die richtige Antwort ist C-A-B. So, jetzt wollen wir
mal gucken, wie viele von euch das richtig hatten.
Ich mache das mal zu hier. Dann gucke ich mir
hier, dann kann ich das hier auch zumachen.
Habe ich hier
die Abstimmungsanalyse
Auch da ist er nicht der Wagen.
Das scheint hier wie nicht angekommen zu sein. Okay,
die Software macht noch nicht so ganz das, was wir wollen.
Schade, schade, schade. Aber wir geben ja nicht
auf. Ihr könnt es ja dann gleich nochmal weiter probieren.
Den Quelltext wollte ich nochmal sehen, ja,
das können wir uns nochmal angucken,
aber das wird jetzt Sophia auch nicht ändern
Also, es ist so, es ist ja so.
In Jara steht am Anfang eines jeden Konstrukteaufrufs ein impliziter Superaufruf.
Es sei denn, er steht explizit einer da.
Das heißt, hier bei diesem Konstrukteaufruf steht implizit davor ein Superaufruf.
Das heißt, er führt zuerst den A-Konstrukte aus.
Alles klar. Und direkt danach dann erst den B-Konstruktor.
Deswegen gibt er A, B aus.
Also auch wenn das B erzeugt wird, wird ja immer
der Konstrukte auch von der Klasse A mit aufgerufen.
Es ist ja in Java garantiert immer alle Konstruktoren aller Superklassen
aufgerufen werden. Und zwar in absteigender Reihenfolge von der obersten Klasse
bis ganz nach unten. Das sollte man wissen,
weil sonst kann man vermutlich mit Implementationsvererbung und Java nicht viel anfangen.
Und deswegen ist das eigentlich auch eine ganz schöne Frage.
Okay. Gut, dann kommen wir jetzt mal zum
interessanten Teil. Ein kleiner Rückblick auf das alte SE2. Ich
erzähle jetzt mal
eine Geschichte
Um es ein bisschen spannend zu machen. Naja,
spannend ist es nicht wirklich. SC2, so wie es
jetzt hier durchführt, als Modul gibt es schon seit
2006. Also ist das erste Mal mit dem Bachelor eingeführt worden
und hatte von Anfang an so einen kleinen Geburtsfehler.
Die Korrision war niedrig, weil wir nämlich verschiedene Sachen in einer Veranstaltung machen sollten.
Und auch Teile, die einfach in einem zweiten Semester zu früh waren.
Es gab nämlich zwei Vorlesungen, OPM, das,
was ihr jetzt hier gehört habt, und STE,
Softwaretechnik und Ergonomie. Und da waren Themen drin,
die waren eigentlich für ein zweites Semester schon sehr fortgeschritten.
Also das war nicht so richtig gut sortiert.
Die Inhalte beider vorlesen sollten in einer Übung gebucht werden,
Deswegen gab es fünf Jahre lang eine erste Semesterhälfte,
Laborphase wie ein SE1. Die habt ihr auch jetzt erlebt.
Einwöchige Aufgabenblätter. Und eine Projektphase in der zweiten Hälfte.
Und das war eine richtige Projektphase. Und unsere Erfahrung damit waren,
das war super für die fortgeschrittenen Studierenden,
weil es gab total viel Freiraum und es war anspruchsvoll.
Und also da haben wir von den, sagen wir,
ganz ambitionierten Studierenden immer gutes Feedback gekriegt.
Aber das war katastrophal für die weniger Stutenstudierenden
Wir haben einfach da, die waren komplett abgehängt.
Wir haben sozusagen in der ersten Hälfte noch so kleinenschrittige Übungen
gemacht und in der zweiten Hälfte hieß es so,
hier ist eine Aufgabenstellung, ein paar Anforderungen,
macht selbst einen Entwurf, macht einen Oberflächenprototyp,
macht euch einen Prozess mit eurer Gruppe von sechs Leuten und dann baut mal was.
So ungefähr, so grob. Und dann ist das
eben halt voll gegen die Wand gefahren für die Leute,
die einfach noch nicht genügend Erfahrung hatten.
Weil einfach auch viele noch gar nicht programmieren konnten.
Gut genug. Dieses Modul gibt es nicht mehr.
Wir haben es mühsam abgeschafft. Wir haben also dafür gesorgt,
dass wir ein neues SE2 haben, das nur noch aus OOPM besteht und einer Übung.
Und das alte mit dem STE-Anteil drin, das läuft so aus.
Es gibt noch Wirtschaftsinformatiker,
die das irgendwie noch vom letzten oder vom vorletzten Jahr
noch belegt haben und dann irgendwie einen Studienplan drin haben.
Aber das ist eigentlich raus. Wir können also sagen,
juhu, es gibt ein neues SE2 und das gibt es seit genau zwei Semestern.
Das heißt, im letzten Semester,
im letzten Jahr haben wir es das erste Mal durchgeführt und ihr seid jetzt diejenigen,
die es zum zweiten Mal in dieser Folge 14-tägige Aufgabenblätter und Entwurfsaufgaben.
Also die Idee von dem, was ihr so im ersten Semester erklärt,
so kleine Programmieraufgaben jetzt mal ein bisschen höher.
Ihr sollt auch Entwürfe machen, wenn auch noch sehr klein,
aber Entwürfe und die dann auch vorstellen und dann feststellen,
darauf zu implementieren, ist gar nicht so einfach.
Alle Aufgaben beziehen sich auch jetzt auf Stoff von OPM.
Und die Aufgabenblätter der Landphase 2 in 2011,
also im letzten Jahr, die sahen so aus.
Wir hatten Platz sechs Vormerken in der Mediathek einbauen,
Entwurf, Schnittstellen. Dann Platz sieben war so Gui-Programmierung,
Medienerfassung in der Mediathek,
sondern eine Medienerfassung
gebaut werden
Ihr die gar nicht gemacht in diesem Semester?
Blatt acht, dann Beobachtermuster, Subwerkzeuge im Kinosystem verbinden.
Das habt ihr gemacht, allerdings als Platz sieben.
Und dann habt ihr als Platt acht zur Gummi-Programmierung gemacht und
bleibt neun wieder Fachwerte. Also das ist ziemlich ähnlich.
Ja, also hier 2012 ist das einfach nur ausgetauscht.
Das heißt, also das ist das, was ihr gemacht habt.
Platz sieben Beobachter musst du aber acht, Gummi und Werkzeuge.
Wir haben halt irgendwie gemerkt, im letzten Jahr,
dass die Studierenden Probleme hatten, irgendwie diese Gui-Anbindung mit den Listenern zu bauen.
Da habe ich gedacht, na gut,
dann machen wir es doch in diesem Jahr andersrum.
Wir erklären euch zuerst das Beobachtermuster,
dann ist es möglicherweise einfacher,
das mit den Listenern
zu verstehen
Hat auch ganz gut funktioniert. Wir gehen da jetzt mal im Detail darauf ein.
Auf jeden Fall würde ich sagen, letztem Jahr war das Fazit,
das war das beste SD2, was wir je hatten.
Ich glaube, dieses Jahr war SE2 noch wieder ein Ticken besser,
weil wir wieder an so ein paar Ecken gefeilt haben.
Es gibt inzwischen aber Stimmen, die sagen,
das ist ja gar nicht mehr anspruchsvolle noch.
Die Leute werden gar nicht genug gefordert, das muss
anspruchsvoller werden, das muss schwieriger werden und so weiter.
Wir werden uns gleich die Lehrerevolution angucken, ob das wirklich sinnvoll ist.
Aber es gibt so ein paar Stimmen, die das sagen.
Also das ist alles prima. Was wir unter anderem
neu gemacht haben in SE2, sind diese Präsentationen.
Das heißt, die sehen, dass ihre Ergebnisse präsentieren sollt
In kleiner Form haben wir das ja schon vorher gemacht,
so ein paar, wenn wir Abnahmen gemacht haben,
aber vor einer größeren Gruppe, wie das jetzt gelaufen ist,
ist es ein bisschen anspruchsvoller.
Zwei Aspekte haben wir besonders geübt, das Darstellen von Entwürfen,
also mit UML und präsentieren von lauffähigen Quelltexten.
Auch das ist was, was man ja erlernen muss.
Also Beamer, ich zeige meinen Quelltext, ich mache eine Guide-Tour durch meinen Quelltext.
Das ist nicht so ganz einfach. Das muss man üben,
das ist aber extrem wichtig, wenn man im Team Software entwickeln will.
Was wir dann wieder festgestellt haben, was auch im letzten Jahr schon so war,
einfache UML-Diagramme sind noch nicht so wirklich bei allen so sicher angekommen.
Da muss man nochmal so ein bisschen wiederholen,
wir haben da inzwischen auch einen Fokus draufgelegt,
wir haben auch was gelernt wieder,
dass wir das einfach nochmal wieder in Erinnerung rufen müssen,
wie das mit der UML funktioniert, mit den UML-Diaagrammen,
die wir verwenden hier in SE2, aus SE1 noch.
Okay, Platz 6 in der Einzelkritik, einfach nur vormerken.
Sollte es hinzugebaut werden zum Ausleihen, ist das hier ein weiteres Material?
Hat man eine Vormerkkarte zusätzlich zur Ausleihkarte oder macht man
das Vormerk nur auf die Ausleihkarte mit rauf?
Sind die veränderlich oder unveränderlich? Wo legen wir diese Dinge
ab? Diese Vormerkkarten im Werkzeug oder bei einem Service.
Wir stehen im Service erweitern oder einen neuen Service bauen.
Das war im letzten Jahr, war das tatsächlich noch offen.
Da haben wir gesagt, ja, wir wissen nicht so genau,
ob man einen neuen Service bauen sollte.
Haben dann Leute auch einen neuen Service bauen lassen,
haben dann festgestellt, oh,
das war schwierig
Schwierig. Also so schwierig, dass selbst die Betreuer dann
manchmal davor saßen und sich den in den Hinterkopf gekratzt haben.
Wie war das jetzt noch genau? Also ich habe
von vornherein gesagt, baut keinen eigenen Service.
Aber der Effekt ist natürlich auch, einige Studierende sind ja unterfordert.
Wir haben ja hier irgendwie Leute, die sind unterfordert.
Dann könnte man ja sagen, na gut, wir machen
eine explizite Zusatzaufgabe. Wenn ihr richtig was beißen wollt,
dann baut das mal als zusätzlichen Service rein.
Das ist nämlich gar nicht so einfach,
einen Service da vernünftig zu verdrahten mit dem Bestimmungssystem.
Aber war das im Umfang eigentlich ganz okay. Nach war unser Eindruck,
diese Aufgabe. Im letzten Jahr war das deutlich zu umfangreich,
weil halt so viele in die Sackgasse gelaufen sind.
In diesem Jahr haben wir das deutlich besser gemacht.
Platz 7, Beobachtermuster, fachliches oder technisches Interface,
also heißt es allgemein Beobachter oder heißt das dann irgendwie Subwerkzeugbeobachter?
Kann man darüber diskutieren. Fachliche Klasse oder anonyme innere Klassen,
das ist natürlich jetzt in diesem Jahr so gewesen,
ihr konntet gar nicht mit anonymen inneren Klassen bauen,
weil ihr die noch nicht kanntet.
Weil in diesem Jahr haben wir die Reihenfolge umgedreht.
Wir haben euch zuerst den Beobachter bauen lassen und euch dann
die anonymen inneren Klassen gezeigt für die GUI-Programmierung.
Da haben wir so ein Henne-Ei-Problem, also was ist jetzt besser?
Jetzt dann das andere, schwer zu sagen
Wenn man die starken Gruppen, die haben das eigentlich immer ganz gut gemacht,
die haben einfach die Lösung aus der Mediathek kopiert.
Da gibt es ja schon beobachtbar und Beobachter,
kopiert man rüber, muss es nur richtig einbauen, fair.
Vor allen Dingen, das ist dann leicht, wenn man anonyme innere Klassen benutzt.
Dann kann man nämlich genau auch dann an der richtigen Stelle auf das Richtige reagieren.
Sonst muss man ja irgendwie, wenn man irgendwie dieses Beobachter-Interface implementiert,
muss man ja wieder differenzieren, wer hat denn jetzt gerade ausgelöst?
Weil ja verschiedene beobachtbare Dinge auslösen können.
Okay. Wurde von vielen als zu einfach angesehen,
da könnte man jetzt noch Zusatzaufgaben formulieren,
da haben wir ja auch schon, habt ihr gesehen,
diese Zusatzaufgabe könnte sein, testet mal euer Beobachtermuster,
eure Implementationen baut, also eine Testklasse für abstrakt beobachtbares Subwerkzeug.
Insgesamt über den einen Zu gering ist im Umfang.
Also dieses Beobachtermuster ist dann doch sehr klar von uns vorgegeben,
es ist zu wenig Varianz drin und man baut es und
es ist fertig und das ist irgendwie ziemlich langweilig.
Ziemlich damit. Im letzten Jahr,
Werkzeugkonstruktion geht es also auch so ein bisschen darum,
Layout, dann das Anhängen an diese Listener,
dass man da die richtigen Interface-Implemente mit anonymen inneren Klassen und so weiter.
Da haben wir wieder so ein paar Sachen entdeckt,
also so Umwandlung an der Zeichenkette, in einen Int,
bei vielen noch ein gewisses Defizit aufgezeigt im Umgang mit Exceptions.
Also Exceptions gerade erst in der Veranstaltung gelernt,
ist noch nicht so geschmeidig,
wie man das vernünftig benutzt
Ja, wo wir gerade dabei sind, dann machen wir doch mal
eine kleine Umfrage. Welcher Acception-Kategorie gehört Associan Error an?
Ja, also Assoirsion Error. Ich behaupte jetzt mal,
es gibt eine klasse Assoirsion-Error und ich starte jetzt hier die
Umfrage und ihr könnt euch überlegen, gehört das zu Uncheckt-Exceptions,
Checkt-Exceptions zur Runtime-Acceptions oder gibt es Assoirsion-Errorgan?
Ich heiße die nämlich eigentlich, Ressourcian Vication Error.
Könnte ja sein. Vielleicht ist es ja
eine Fangfrage
Es gibt da wieder Feedback, hier meinen Empfänger,
Blink und da kommen irgendwelche Signale von den Klickern.
Toll, toll, toll. Ich hoffe mal,
dass wir jetzt mal ein Ergebnis sehen, das wäre schön.
Sonst liegt es wann? Ja, es kann gut sein
. Ja, da kommen die Stimmen rein,
da kommen die Stimmen rein, entscheidet euch, entscheidet euch.
49 Stimmen, ja, 50, 50 will ich haben,
ja. Okay, also jetzt stoppe ich das
Zeit wird ja auch knapp, also angehalten. Mal gucken
. Ja, wir haben tatsächlich ein Ergebnis. So,
jetzt sieht man hier auch wieder sehr schön die Verteilung.
Ja, ich klicke mal wieder zurück.
Also check, Unchact Exception sagen 15 Prozent.
21 sagen, das ist eine Check Exception.
35 Prozent sagen, das ist eine Runtime Acception und Assourtion.
Error gibt es gar nicht, weil das heißt,
Assourtion Violation Error, das haben auch einige Leute gesagt.
So, okay, jetzt sage ich,
das ist ein katastrophales Ergebnis
Deswegen könnte man jetzt,
wenn wir jetzt diese Clicker-Software so ein bisschen weiter ausgebaut hätten,
was wir jetzt nicht haben, könnte ich jetzt sagen,
okay, wir verwerfen das Ergebnis,
ihr habt jetzt eine Minute Zeit, euch zu unterhalten.
Ihr dürft euch jetzt gegenseitig überzeugen,
warum das das eine oder das andere ist und warum ich
unzufrieden bin und warum möglicherweise ein anderes Ergebnis besser ist.
Und dann könnte man die Abstimmung nochmal machen.
Könnte man so machen. Machen wir jetzt nicht,
geht mit der Software auch gar nicht.
Ich zeige euch jetzt mal die richtige Lösung.
Das ist nämlich diese. Das ist natürlich ganz schön erschreckend
. Also das sieht jetzt hier nicht so wirklich toll aus
Assoirsion Arrow ist eine Uncheckt Exception. Die Uncheckt Exceptions sind die,
bei denen man, wenn man sie denn,
wenn die vorkommen können in einem Code, muss man keinen Trike Catch drumherum schreiben.
Also man muss keine Vorkehrungen treffen dagegen. Checkt Exceptions sind die für,
haben wir mal irgendwie versucht, hier zu vermitteln,
für die Umgebungsfehler, da, wo man damit rechnen kann,
dass man keine Kontrolle darüber hat.
Aber die Uncheckt Exceptions sind alle Sachen,
so wie die ganzen Arrows, also irgendwie Scientation Arror,
also irgendwie der Stack ist voll, der Hieb ist voll,
so lauter so Sachen, wo man sowieso nichts machen kann.
Das kann ja immer passieren, wenn ich jetzt überall Trike
Catch schreiben müsste für diese Dinge, würde ich mir ein Wort programmieren.
Also diese Unchecks sind die, wo man sagt,
da macht es auch keinen Sinn, irgendwie Code zu schreiben,
der damit umgeht. Während bei den Check-Exceptions ist das sinnvoll.
Wenn ich also auf eine Datei zugreifen will,
die Datei ist nicht zugreifbar, nicht schreibbar,
nicht lesbar, dann muss ich damit auch umgehen können.
Dann wird man auch gezwungen durch diese Acception,
dass man als Programmierer-Code schreiben muss, um damit umzugehen.
Runtime-Acceptions sind auch Uncheck-Exceptions, aber Accession-Error ist keine Runtime-Acception,
sondern ein Error. Also er hat tatsächlich von Error.
Und Social Arror gibt es gar nicht, doch,
Social App gibt es.
So heißt diese
Okay, also da sehen wir, das ist kein besonders gutes Ergebnis.
Also würde ich jetzt sagen, guckt noch mal ins Skript,
ob ihr vielleicht euch noch mal genauer darüber informiert,
wie denn so Exceptions im Java funktionieren.
Okay. Ja, dann Listener-Konzept, Beobachter vorher behandelt,
genau. Die Frage, ob der Bezahldialog Modal sein sollte,
das haben wir ja auch so ein bisschen gestellt, stellt sich eigentlich nicht.
Wir haben das irgendwie dann auch noch mal diskutiert.
Eigentlich ist es fast nicht sinnvoll zu sagen, man macht es nicht modal.
Wenn ihr euch diese Software noch mal anguckt, hier dieses wunderschöne System,
Das macht nicht wirklich viel Sinn, das nicht modal zu machen.
Ich kann es ja mal starten. Ich habe zufällig noch
ein anderes Kino-Ticket-Verkaufssystem. Hat mir ein netter Student zugeschickt,
weil ich ihn darum gebeten habe in den Übungen.
Das zeige ich mal eben ganz kurz hier.
Wenn also hier Plätze auswählen, dann kann ich die verkaufen.
Dann kriege ich hier so ein sehr aufwendig progressives Barzahlungswerkzeug.
Und ich kann jetzt hier zum Beispiel sagen, ich gebe mal 50 Euro an.
Und dann zeigt er mir das Rückgeld an in Scheinen.
Ist das nicht süß? Ja, toll. Also hier
sieht man das. So, aber was man jetzt auch sieht,
wenn man das nicht modal hätte, dann wäre das ziemlich komisch.
Wenn ich jetzt hier rausklicken könnte und jetzt wieder weitere selektieren könnt,
müsst ihr das hier automatisch wieder geupdatet werden,
dann müsste der Preis angepasst werden, das würde,
also das wäre irgendwie insgesamt, das ist sehr viel komplizierter.
Man kann das so bauen,
man kann sozusagen dieses Barzahlungsfenster integrieren, irgendwo rechts oben,
daneben, sodass man dann irgendwie direkt da bezahlen kann und immer dann,
sobald man auf den Platz klickt,
wird dann schon gleich da oben der Bit Prag auch angezeigt,
könnte man so machen.
Haben wir jetzt hier eher gesagt, macht das nicht,
weil das sonst ein bisschen kompliziert geworden wäre. Ach,
man kann hier auch jetzt noch eine Null dran hängen,
dann kommt noch mehr Scheine, ist toll, ne?
Ja, ganz toll, so, jetzt haben wir hier
die drei Plätze verkauft
Also auch das mit den Modalen ist eigentlich ziemlich sinnlos.
Dass man das nicht modal macht. Insgesamt war das
unser Eindruck im Umfang okay. Das war so ähnlich wie
im letzten Jahr. Platt 9, Fachwert, Geldbetrag.
Da haben wir natürlich dann so die Fragen,
wie ist der Konstruktor öffentlich oder privat?
Wenn der privat ist, muss man irgendwelche Selektormethoden implementieren,
also irgendwelche Fabrikmethoden oder so statische Methoden, die man dafür benutzt.
Die arymetischen Operationen kann man als Exemplar oder als Klassenoperation modellieren.
Der Selektor über String oder über Int oder beides
Negative Beträge zulassen. Ganz spannende Frage. Also ich habe das,
inzwischen bin ich der Überzeugung,
dass man bei einem Betrag etwas Negatives nicht zulassen sollte,
weil der Begriff Betrag sagt schon, es ist nicht Negatives.
In der Mathematik ist ein Betrag auch nicht negativ. Und wir haben das also,
ich habe das auch tatsächlich mal gebaut, dieses System,
was ich jetzt hier habe, kennt nur positive Beträge.
Hat den Vorteil, das kann ich vielleicht auch nochmal zeigen,
dass bei dem Fachwert Geldbetrag Test Der Test viel kleiner ist
. Weil ich muss sehr viel weniger Testfälle testen.
Wenn ihr euch darüber, wenn ihr darüber nachdenkt,
wenn ich einen Wertebereich habe für Geldbeträge von minus Integration Max Value,
minus Min Value bis Intiture Max Value,
dann habe ich also negative Werte und positive Werte.
Dann muss ich die als verschiedene Äquivalenzklassen betrachten und muss dann
auch meine Tests so wählen,
dass ich dann mal negativ mit einem positiven Wert addiere,
negativ mit einem Negativen und so.
Ich muss das irgendwie alles testen. Ich habe also
viel mehr Testfälle, die ich on muss.
Das muss ich nicht, wenn das alles positiv ist.
Dann habe ich nämlich nur einen Wertebereich von null bis Intiture
Max Value
Und da kann ich sehr viel einfachere Testfälle schreiben. Wir haben tatsächlich,
ich habe das hier gemacht, ich habe dann diese Testklasse,
die in unserer Musterlösung drin ist, die negative Geldbeträge zulässt.
Ich habe es dann umgebaut, in meine eigene Musterlösung.
Und die Testklasse ist von 480 Zeilen auf 270 Zeilen geschrumpft.
Ich finde, einfacher ist schön. Das ist so eine
Umregel, simple Stupid. Das Kissbetrieb. Wenn ihr einen
einfachen Entwurf habt und einen komplizierten und beide sind gleich von
der Funktionalität, nehmt den einfacheren, nehmt den einfacheren.
Das ist wirklich Nichts ist schlimmer als Komplexität in Software.
Und man kann die unheimlich schnell, unheimlich komplexes kaputt bauen.
Genau. Was wir aber auch wieder gemerkt haben,
ist, in der Aufgabenstellung, wie wir es jetzt haben,
ist es einfach so, euch wird nicht richtig deutlich,
was für einen Vorteil es bringt, diesen Geldbetrag selbst zu bauen, als eine eigene Klasse.
Wir hatten also einfach Gruppen, die haben es dann gebaut,
aber waren eigentlich total genervt.
Die hätten es lieber mit Ins gebaut,
weil das geht dann auch alles viel einfacher.
Man kann dann auch ins addieren, man kann die multiplizieren.
Warum muss ich das denn jetzt alles nachbauen in einem eigenen Typ?
Die Vorteile von solchen Fachwertklassen von solchen Werttypen,
Die werden euch erst deutlich, wenn ihr in einem größeren System das einsetzt.
Das ist leider so. Das ist etwas,
was ein bisschen schade ist. Okay, insgesamt,
wie schon im letzten Jahr, im Umfang etwas zu gering.
Obwohl wir dann auch gemerkt haben,
man kann über so das Bauen einer solchen Fachwettklasse relativ viel diskutieren,
war es dann doch so, dass es ein bisschen zu leicht war.
Okay, hier nochmal so ein schönes Beispiel.
Ein Beitrag aus dem letztjährigen Übungsbetrieb. Könnt ihr euch
auf der Zunge zergehen lassen
Okay, wer kann mir sagen, was da jetzt komisch ist an diesem Ding?
Ja? Ja. Und wenn man daran spielt, auch daran. Ja,
er sagt es richtig,
also da wird ein Inparameter übergeben und es wird geprüft,
ob dieser Inparameter, der nur per Sprachdefinition,
die Werte von indischer Max-Value bis Intager-Min-Value annehmen kann,
da wird jetzt noch geprüft,
ob der in Außerhalb dieser Grenzen kann er gar nicht liegen.
Das garantiert die Sprache. Das ist also eine komplett redundante Prüfung
hier. Und tatsächlich, ja, der Rückgabetyp ist tatsächlich
Bulien mit einem großen B und nicht mit einem kleinen B.
Auch das ist nochmal nette, irgendwie implizite Typumwandlung.
Wo dann hier ein Objekt rauskommt. Also es war ein
ganzes Ding. Ich habe hier noch so ein hübsches,
kleines Frägelchen. Was ist an dieser Equals-Methode problematisch
Diese Equals-Methode hier, Element kommt sofort, zack.
So, dann entstehen wir das noch ein bisschen übereinander.
Also, das ist ganz schön eng hier.
Da, was ist an dieser Equals-Methode problematisch?
Die Abstimmung gäbe es immer frei hier. So,
ihr seht hier eine Equal-Methode in einer Klasse,
sagen wir Geldbetrag.
Denkt drüber nach und dann gebt eure Stimme ab.
Da kann man es auch ein bisschen besser lesen.
Die Schrift ist
ein bisschen größer
Ja, 50 Stimmen, ist doch wunderbar. Entscheidet euch jetzt,
ihr habt noch fünf Sekunden, eins, zwei,
drei, vier, fünf und ich stoppe das.
So, Jetzt hoffe ich mal, dass wir hier ein Ergebnis kriegen.
Bitte? Achso, der Haken ist noch an, ja,
okay. Na, toll, da kommt ein Ergebnis,
sehr schön. Also, die Vorbedingungen sagen,
26 Prozent, der Parametertyp sagen, 37 Prozent,
das Overright-Tag sagen nur 10 Prozent und wenn man ein Viertel sagt,
der Zugriff auf Adapter-Gesamttag.
Okay,
auch wieder fatales Ergebnis
Ich glaube, ihr müsst richtig lernen für die Klausur.
Das glaube ich wirklich. Also, die richtige Antwort ist
diese. Es ist die Vorbedingung. Warum? Also,
wenn man sich den Code hier nochmal anguckt,
das Overright-Tag ist natürlich kein Problem,
weil tatsächlich hier auch der Parameter kein Problem ist.
Weil wenn ich Equels redefinieren will,
also es gibt die Operation Equels aus dem Typ Object.
Und wenn ich jeder Typ ist ein Subtyp von Object,
wenn ich also einen Geldbetrag, dass Equals redefinieren will,
damit das zum Beispiel in Sammlungen eingefügt werden kann und so weiter,
muss tatsächlich der Parameter-Typ Object sein.
Wenn der Parameter Geldbetrag, der Parameter-Typ Geldbetrag wäre,
wäre es kein Redefinieren, sondern wäre es ein Überladen.
Das heißt also, das ist beides okay, overright und Object ist richtig.
Der Zugriff auf other.gesamtbetrag ist möglich. Klassen haben kein,
also Exemplare derselben Klasse, kennen kein Geheimnisprinzip untereinander.
Man kann also direkt auf private Exemplare war ja zugreifen in derselben Klasse,
weil wir sind ja im Code dieser Klasse hier.
Wir sind sozusagen im Geldbetrag. Deswegen kann ich das tatsächlich
genau so machen
Das Problem ist die Vorbedingung. Warum ist die Vorbedingung hier ein Problem?
Richtig, er sagt, Equal hat in Object keine Vorbedingung.
Wenn wir jetzt hier eine haben, ist das eine Verschärfung einer Vorbedingung.
Alle Klienten von Object können auch Nall übergeben.
Wenn wir jetzt in einer Subklasse sagen, nein,
wir dürfen keine Nallreferenzen übergeben werden,
dann kracht das für diese Exemplare dieser Klasse.
Das ist nicht vertragskonform. Der Vertrag sagt, man kann
da alles übergeben. Also darf man das nicht verschärfen.
Das ist eine Verschärfung der Vorbedingungen. Und das darf es
nicht geben
Ist nicht in Ordnung. Okay,
dann war das hier jetzt auch die letzte von diesen Umfragen.
Das ist auch sehr schön. Dann gucken wir uns jetzt
nochmal zehn Minuten die Ergebnisse der Lehrrevolution an.
Ja, das ist ja auch nochmal ganz lustig.
Zeitaufwand für SE2. Das ist schon mal der erste Schock.
Das ist also wirklich schockierend. Im letzten Jahr war das so,
ihr solltet für SE2 angehen, wie viel Zeit ihr investiert.
Da war natürlich auch noch so, da waren ja auch
zwei Vorlesungen dabei. Also SE1, OOPM und STE.
Und da war das Ganze auch umfangreich. Da sieht man,
jeder war schon ein ziemlicher Buckel bei acht bis zehn Stunden
Dann haben wir ja im letzten Jahr umgestellt. Das heißt,
es ist nur noch OOPM und die Übung dazu.
Da war das dann so, wie man das eigentlich so im Grob erwartet.
Ihr wisst, wir erwarten von euch für eine sechs Leistungspunkte-Vorlesung.
Ich glaube, acht Zeitstunden die Woche.
Also acht Zeitstunden solltet ihr auf jeden Fall machen.
Aber die Masse macht vier bis sechs. Manche machen acht
bis zehn, aber das ist relativ geringer Anteil.
Und bei euch ist es jetzt so, dass es noch weniger geworden sind.
Also hier der acht bis zehn Anteil ist noch kleiner geworden
und der vier bis sechs Anteil ist noch größer.
Also ein Drittel von euch braucht nur vier bis sechs
Stunden in
Das ist natürlich komisch, wenn ihr schon allein 90 Minuten Vorlesung habt,
also zwei Stunden Vorlesung plus drei Stunden Übung,
dann sitzt ihr nur noch eine Stunde zu Hause.
Ein bisschen wenig. Kann Wunder, dass ihr dann diese Fragen hier
auch nicht beantworten könnt. Aber das ist tatsächlich so,
das ist dann immer so ein bisschen, oh,
wenn ihr auch keine Zeit investiert, dann kann man nicht erwarten,
dass jetzt besonders viel von den Sachen Stoff umfangen.
Da sind wir inzwischen ganz gut, also 3,4 Mittelwert vor zwei Jahren.
Letztes Jahr 3,2, jetzt wieder 3,2. Man sieht hier,
es ist ein leichter Buckel auf der rechten Seite.
Toll, es ist eigentlich nur das Traumzahlen
Wenn da jetzt der Buckel mehr so auf der linken Seite wäre,
dann würden wir ja letztendlich, würde es ja heißen,
wir machen zu wenig.
Es gibt Leute, die finden, dass es zu wenig ist.
Also hier waren es, früher waren es vier Prozent,
dann waren schon acht Prozent im letzten Jahr und dieses Jahr sind schon fast elf Prozent.
Also Leute, die einfach sagen würden, das ist mir zu wenig.
Ja, sagen wir nicht drastisch zu wenig,
aber schon ein bisschen zu wenig. So,
und dafür ist aber hier der Anteil immer kleiner geworden,
von denen Das sind, finde ich, gesunde Zahlen.
Da kann ich gut mit leben. Das sieht sehr vernünftig
aus. Niveau der Veranstaltung, 3,3,3,2,3,2,
also auch da eine Konsolidierung zur Mitte hin.
Das ist hier auch so, dass das eigentlich ganz gut aussieht,
aber auch hier wieder vier, sieben, zehn.
Also es werden immer mehr, denen das Niveau zu niedrig ist.
Wir machen es hier zu einfach. Das ist,
sagen zumindest, einige Leute. Inzwischen immerhin zehn Prozent.
Das ist ja schon nicht ganz wenig. Andererseits glaube ich trotzdem,
dass wir damit ganz gut fahren, wie wir das machen,
weil wir ja eben halt diese Veranstaltung für alle machen und
nicht nur für alle
Die dann später, die selber an der wissenschaftlichen Schraube weiterdrehen wollen. Gut,
allgemein ist zur Veranstaltung, da gibt es so diese klassischen Fragen,
klar, strukturieren und aufgebaut, inhaltlich sehr interessant,
inhaltlich für das Studium sehr wichtig.
Da waren die Mittelwerte, kann man wahrscheinlich kaum erkennen,
2,3, 2,7, 2,2 und das ist hier so ein
bisschen vom vorletzten zum letzten Jahr ein bisschen besser geworden.
Man sieht das ruckt hier alles so ein bisschen nach links
, das ist schön. Aber wenn wir jetzt gucken,
was vom letzten Jahr zu diesem Jahr sich geändert hat,
dann ist das eher nicht so viel.
Also das ist so eher wieder schlechter geworden
Schade, schade. Also irgendwie kommen wir nicht mehr
ganz so gut bei euch an. Ah, okay.
Müssen wir irgendwie so, also es ist nichts Alarm,
Alarmierendes, aber das ist jetzt auch nicht so,
dass man sagen würde, Mensch, das ist ja wirklich besser geworden.
Dann der Dozent, also das übliche, interessant und lebendig,
gut vorbereitet, macht die Veranstaltung interaktiv.
Ich habe mir heute ganz viel Mühe gegeben, es interaktiv zu machen.
Veranstaltung zu halten, schwierige Sachverhältnisse, verständlich.
Man sieht immer, da schneide ich mir besonders schlecht ab.
Also 1,9 und sonst nochmal 1,6, 1,1, guck mal.
Ja, aber dann schon da eine Verbesserung im letzten Jahr
und hier aber wieder eine Verschlechterung
Ihr seid anscheinend ein kritischer Jahrgang. Also ihr findet das
nicht mehr so toll, was ich hier mache.
Also das ist hier überall so ein bisschen schlechter geworden.
Fast überall, fast überall schlechter geworden. Ja, bitter
. Hart für mich. Hier genauso gut verständliche Aussprache,
nimm Fragen ernst, ist freundlich und Tafelbild und so weiter.
Auch da eine Verbesserung vom Vorletzten zum letzten Jahr,
aber eine Verschlechterung, minimal vom letzten Jahr zu diesem Jahr.
Also auch das nicht so dramatisch. Das sind immer noch
gute Zahlen für eine Pflichtveranstaltung
Ich will mich hier nicht beschweren.
Also wenn ihr das mal vergleicht in der Lehre Evolution,
ist es ja alles dann auch online verfügbar, zumindest im Informatiknetz.
Wenn das dann da vergleicht, dann sieht man schon,
dass da bei anderen Pflichtveranstaltungen... Weil ihr müsst ja eigentlich
hier sitzen, ja. Und dann sind das schon solche,
solche Säulen hier auf der einen, das ist schon sehr,
sehr erfreulich. Also ich kann mich da nicht beklagen.
Dann die Übung, Zeitaufwand für die Übung, Schwierigkeitsgrad,
Aufgabe hat er rechtzeitig, Übungen passieren, vorlesungen,
passen zeitlich sehr gut zur Vorlesung.
Auch da eine deutliche Verbesserung vom vorletzten zum letzten Jahr.
Und jetzt hier, oh, das ist stagniert so.
Also eigentlich ist es so,
die Veranstaltung ist ziemlich genau so
Und das ist auch von eurem Feedback mehr oder weniger genauso.
Und sind sehr gut vorbereitet. Da sieht man hier,
das war 2,94, dann im letzten Jahr war es 2,0,
2,1 und jetzt 1,9 und 2,1.
Also noch eine Verbesserung. Also das ist tatsächlich,
also ein dickes Lob an unsere Betreuer,
die sind wirklich anscheinend gut qualifiziert und ihr seht das so.
Das ist wirklich toll. Dann negativ aufgefallen,
der Punkt ist zwar, ich habe jetzt keine Zeit gehabt,
mir noch die ganzen Freitags auszuarbeiten,
weil ich diese interaktive Geschichte jetzt hier vorbereitet habe
Vor dem Hörsaal schlecht zu erkennen, das war,
glaube ich, auch in diesem Jahr wieder Feedback,
weil dieser Bier so absolut grottig ist.
Hier nicht alles dunkel ist, dann sieht man da nix.
Das ist also, muss man wirklich mal neue Birne hier,
bin ich rechtzeitig in gedruckter Form, das ist vielfach genannt worden.
Dieses Jahr kam das gar nicht. Also ich wollte das jetzt irgendwie noch durchstreichen,
weil wir sozusagen das Feedback vom letzten Jahr haben wir abgearbeitet.
Also die Skripte sind relativ rechtzeitig da und das ist
oft von euch praktisch gar nicht mehr bemerkt worden,
dass die Skripte irgendwie zu spät gekommen sind.
Zu langsame Vorlesungen wie in der Schule, gut,
ich rede jetzt mal ein bisschen schneller
Teilweise zu ausführlich, na gut, zu viele Dozenten,
das war letztes Jahr, da hatten wir drei Dozenten.
Dieses Jahr hatten wir nur nur nur zwei. Okay,
das ist dann auch nicht mehr sozusagen das Problem.
Problem mit den Videos, das ist häufig das Feedback,
auch in diesem Jahr relativ häufig genannt. Es wäre schön,
wenn das schneller da wäre, wenn die Videos schneller verfügbar wären.
Also der Wunsch ist eigentlich so einhellig,
spätestens eine Woche danach sollte das alles da sein.
Das kriegen wir inzwischen auch ganz gut hin.
Aber manchmal hakt es auch ein bisschen. Zu viel Stoff,
gut, zu wenig Stoff, gibt es auch Leute.
Blue Jay statt Eclipse wird gar nicht mehr so,
auch wieder Leute gesagt haben, naja,
warum denn wieder Blueday aus der Kiste geholt?
Ist doch vorbei, SE1 und so.
Aber ich finde ja Blueday nach wie vor,
um Dinge live zeigen zu können, sehr gut geeignet.
Also in keiner anderen IDE kann ich mir ein Exemplar
einer Klasse erzeugen und das mal im Interaktiv benutzen.
Und das ist einfach nur dafür. Fall 2 zu schwierig zu umfangreich,
naja, Zeitaufwand für Platz 6, was war letztes Jahr sehr stark kritisiert?
Verbesserungsvorschläge, Skripte früher, müssen wir nicht mehr.
Keine Wechselweite drin, haben wir auch nicht mehr.
Laborphase 2 überarbeiten, haben wir gemacht. Design Patterns früher
haben wir auch gemacht, der Beobachter kommt jetzt früher, keine Gruppenarbeit. Gut,
das war letztes Jahr, ich weiß nicht,
also diese Vierergruppen, da habe ich eher das Gefühl,
das Feedback war eher positiv, dass ihr sozusagen gesagt habt,
hm, schon mal so als Vorgeschmack auf echte Gruppenarbeit,
ganz angenehm, dass man sich mal so ein bisschen in der Gruppe organisieren muss.
Natürlich ist das Anstrengende, aber es übt eben ungemein, stärker praxisorientiert, ausführlicher.
Das ist auch noch dieses Jahr viel genannt worden.
Das Skript sollte ausführlicher sein. Also es sollte eigentlich eher
ein Skript sein und nicht nur ein Folienskript.
Also da fehlen manchmal so die Erklärungen, Erläuterungen und so weiter.
Das ist auch nach wie vor eure Meinung hier. Gut,
so viel zu leerer Evolution gibt es da noch Fragen.
Ich werde das PDF mit den ganzen Freitexten und allem,
was da so an Tabellen ist,
ins Komsi
Ein paar Worte zur Klausur. Die zwei Minuten sollt ihr noch eben haben.
Am 30.07. ist es um 9.30 Uhr die Klausur, die erste.
Audi Max 1 und 2 und 2 und für A und B,
weil wir haben ungefähr 340 Teilnehmer in diesem Jahr.
Letztes Jahr waren es 280 und das war schon für uns schwer zu handeln.
Dieses Jahr ist dann auch Christian nicht da.
Das heißt, ich werde das irgendwie noch alles zusätzlich machen.
Aber da werden wir uns noch melden,
wie das dann mit der Verteilung auf die Hörseele funktioniert.
Ich will immer ein paar Sachen sagen. Wir bekommen
immer wieder Kritik für die SE2-Klausur. Also ein paar Dinge
möchte ich nochmal deutlich sagen. SC2 ist nicht SE1. Also
wenn ihr immer noch so in Ach, Erinnerung,
SE1 war so schön und da war auch die Klausur so super und so.
Ja, das ist hier anders, weil SE1 hatte keine Voraussetzungen,
aber SE2 setzt SE1 voraus. Und wir haben in SE2 das Problem,
dass die Schere, die am Ende von SE1 ist, noch weiter auseinanderläuft,
also von den Leuten, die in SE1 schon Schwierigkeiten hatten,
die werden jetzt in SE2 auch nicht richtig glücklich.
Das heißt aber, wir müssen natürlich davon ausgehen, dass
ihr SE1 beherrscht. Also eigentlich gehen wir davon aus,
ist die Inhalte von SE1, verstanden sind.
Das heißt, wer damit schon Schwierigkeiten hat,
hat natürlich massiv mehr Schwierigkeiten in der Klausur.
Die Inhalte von SE2 sind deutlich anspruchsvoller.
Sie sind vor allen Dingen abstrakter, haben so Themen wie
Abstraktion gehabt
Also Testen von Objekten wie der Software ist nicht einfach.
Vererbungsführerchen, Subtyping, Co- und Contra-Varianz, Exceptions, Exception,
Hierarchien. Solche Fragen, die wirklich nicht einfach sind.
Das ist einfach so. Und dann ist natürlich auch die Klausur anspruchsvoller.
Und es ist auch nicht mehr ganz so einfach, programmiernahe Aufgaben zustellen,
weil wir machen in diesem Semester ja nicht nur Programmierung,
sondern SE2 geht es auch um Modellierung
zum Beispiel
Es ist auch für uns deutlich schwieriger zu überprüfen,
ob die Inhalte verstehen. Das heißt, es ist
deutlich schwieriger, gute Fragen zu stellen. Ich glaube,
nach wie vor, dass wir das ganz gut machen.
Ich bin, sagen wir, ein bisschen überzeugt von unserem Klausurkonzept,
aber es ist natürlich anders als in NR1.
Und Gegenstand der Prüfung ist der Stoff der Vorlesung.
Und viele glauben immer, gut, ich habe die Übung mitgemacht,
ich habe alles in den Übungen verstanden, das reicht.
Und das ist eben nicht der Fall.
Wir prüfen ganz bewusst auch den Stoff der Vorlesung.
Das heißt, was in den Vorlesungen drankommt, ist relevant.
Also sowas wie Co und Kontra-Varianz,
habt ihr in den Übungen wahrscheinlich nie was mit zu tun gehabt,
aber es ist trotzdem ein Thema,
was in der Vorlesung drankam
Möglicherweise gibt es dann Fragen dazu. Und das ist dann
immer so ein bisschen schade, wenn wir dann hinterher verprügelt werden,
weil wir solche Fragen gestellt haben.
Ich habe ja die Fragen aus der Vorlesung gestellt, das ist ja gemein und so.
Okay, also was ich nur empfehlen kann, ist,
setzt und macht das in Gruppen, in Teams, lernt zusammen.
Das ist so, wenn man sich überlegt,
man nimmt das Skript her und sagt, okay,
was könnte ich denn jetzt mal für eine intelligente Frage stellen?
Das ist mir gar nicht so einfach, sich intelligente Fragen auszudenken.
Und dann stellt man Design Kommilitonen und dann müssen die die beantworten.
Dann kann man darüber diskutieren. Das ist eine gute Frage,
war dann nicht. Das würde ich euch auf jeden Fall
empfehlen, wenn man für so eine Klonlant das empirt machen
Okay, das war's. SC2 wird fortlaufend verändert. Ihr seht das,
wir arbeiten immer weiter dran. Dadurch entstehen leicht mal üble Gerüche.
Ein Refactoring ist eine Richtstrukturierung einer Lehrveranstaltung, die deren Funktionalität erhält.
Ja, ist natürlich Quatsch. Also das,
was ganz wichtig ist, sehr viele Leute machen dieses Modul möglich,
auch teilweise hinter dem Gewissen, die ihr gar nicht wahrnehmt,
in den Übungen durch die Übungskunden,
aber es gibt auch andere Leute,
die hier beigetragen haben.
Heinz war im Forschungssemester,
Petra Becker
Pecher hat beigetragen
Noch ein paar mehr nennen, Leute, Jörg Gratlev,
die einfach viel beigetragen haben in den letzten Jahren,
nicht mehr dabei sind.
Das ist eine ganz wichtige Sache.
Mir hat SE2 wieder viel Spaß gemacht. Ich hoffe,
euch auch einigermaßen. Und ich danke euch für eure Mitarbeit