Okay, sonst noch Fragen, nein. Okay,
also in der ersten Laborphase bauen wir ein Mediatheksystem aus.
Dieses Mediatheksystem kann ich eigentlich mal zeigen.
Wenn ich das jetzt hier zum Laufen kriege,
wenn jetzt mal irgendwas funktioniert heute, dann wäre es jetzt schön.
Schauen wir mal. Zack. Versuchen wir es mal so.
Das ist Eclipse. Wir werden also in den Übungen,
in diesem Semester mit Eclipse arbeiten
Viele von euch werden jetzt jubeln und sagen, herrlich,
endlich Schluss mit Blue Jay. Ja, genau,
wir werden in den Übungen nicht Blue Jay einsetzen,
sondern wir werden Eclipse einsetzen.
Eclipse werde ich auch in der Vorlesung ab und zu einsetzen.
Ich werde aber auch in der Vorlesung weiterhin Blue Jay einsetzen,
weil es an manchen Stellen einfach sehr illustrativ ist,
noch weiter mit Blue Jay zu arbeiten.
Das ist die Mediathek, wie sie dann aussieht, wenn sie fertig ist.
Ich kann die mal hier einfach mal starten.
Dann seht ihr, was ihr hier bauen sollt.
So sieht das aus. Es geht also darum,
um den fachlichen Kontext, Medienverleih, wo man CDs,
DVDs, Konsolen, Videospiele oder ähnliches verleihen kann.
Und es gibt in diesem System, was ihr euch vorstellen könnt,
das läuft in so einer Videothek auf dem Schreibtisch irgendwo,
da steht das System am Counter.
Und dann kann man mit diesem System hier so arbeiten,
kann also hier Kunden auswählen,
man sieht dann hier rechts die Details des jeweiligen Kunden,
der selektiert ist.
Dann kann man hier unten Medien selektieren,
die werden dann auch rechts angezeigt.
Man kann hier unten auch mehrere selektieren,
auch mit Steuerung,
Hier mehrere selektieren und dann kann man die auch möglicherweise auswählen.
Ausleihen kann ich jetzt nicht, weil hier bei manchen der Medien steht nein.
Also es ist nicht ausleihbar, ist gerade verlieben.
Also es gibt ja hier auch eine Rückgabeansicht,
in der dann irgendwie die ausgeliehenen Medien aufgelistet sind.
Dann gibt es eine Vormerkansicht, wo man ein verliehenes Medium vormerken kann.
Ihr kennt das, ihr kommt in die Videothek,
der Film ist nicht da, dann sagt ihr,
oh, ich möchte ihn aber als nächstes haben.
Dann könnt ihr euch hier in die Vormerkkaliste eintragen lassen.
Medienverwaltung ist, wenn neue Medien eingetragen werden müssen.
Das Ding ist schon ziemlich nützlich.
Also man kann damit richtig viel machen.
Das ist tatsächlich
so ein Mini-Mediatheksystem
Und man kann vielleicht auch mal hier zeigen,
wenn ich jetzt hier zum Beispiel auf zwei Medien auswähle für Chuck Norris,
dann kann ich hier tatsächlich jetzt das auch rausleihen.
Kann auf Ausleihen klicken und dann sind die nicht mehr ausleihbar und so.
Das ist, das ist mehr oder weniger die Fachlichkeit.
Das ist der fachliche Kontext,
mit dem wir im ersten Teil des Semesters arbeiten werden.
Okay, ihr solltet die Aufgaben,
die wir dann da rausgeben, auch schön aufeinander folgend abarbeiten.
Ihr solltet dabei immer die Ergebnisse der Vorwoche verfügbar haben,
deswegen ist es gut,
wenn ihr das Netzlaufwerk benutzt,
das kennt ihr aus den Übungen von
Das Z-Laufwerk benutzen, dann ist alles meistens problemlos.
Und immer auch kopieren, also dass immer beide das Teilnehmer
eines Paares diese Daten auch vorliegen haben.
Gut, in der zweiten Laborphase werden wir dann einige Funktionen
da reinbauen in die Mediathek und auch in das Kinoticket-System.
Das zeige ich vielleicht gleich auch nochmal. Was ganz wichtig ist,
ist, dass ihr im Kopf habt,
wie viel Zeit ihr für diese Veranstaltung investieren müsst.
Das ist was, was wir in SE1 auch immer schon
sehr deutlich gesagt haben, das sagen wir in SE2 auch.
Ihr müsst diese zwei Stunden Vorlesung irgendwie mitmachen. Entweder seid
ihr hier oder ihr guckt sich auf ein Video an.
Ihr seid voraussichtlich mindestens drei Stunden in der Übung und ihr
solltet ungefähr drei Stunden Vor- und Nachbereitung rechnen pro Woche.
Das ist das, was wir von euch fordern können.
Das ist sozusagen angemessen für sechs Leistungspunkte. Wir sagen,
acht Stunden pro Woche solltet ihr für SE2 überhaben.
Wenn ihr die nicht investiert, werdet ihr im Laufe des Semesters große Schwierigkeiten kriegen.
Wenn ihr die investiert, sollte es keine Probleme geben.
Wir haben das über Jahre so hingeschnitten, dass das eigentlich
machbar ist. Ihr kennt das aus SE1 und wir
werden das in SE2
weiter versuchen
Es wäre gut, wenn ihr in den ersten fünf Wochen
während der einwöchigen Aufgabe da schon mal so langsam euch so umguckt,
wer denn vielleicht geargert wäre, dass ihr euch in einem Vierer-Team zusammenfindet.
Das wird dann aber nochmal ein bisschen von uns angesagt und auch
ein bisschen angekündigt und vorangetrieben, dass diese Gruppen gebildet werden.
Gut, das ist die SE2-Übungswoche. Ich bin jetzt schon
mehrfach angesprochen worden vorhin, wie es denn aussieht mit Wechseln.
Es gibt eine Vorgabe vom Präsidium, dass die Stine-Anmeldezeiten jetzt
vor der vor dem Beginn der Vorlesungszeit liegen, enden sollen.
Das heißt, ihr könnt jetzt in der Vorlesungszeit nicht mehr
problemlos übers Diene wechseln. Das ist extrem nützlich für uns,
weil wir jetzt hier davor stehen, dass jetzt sowas passiert.
Hier ist eine Gruppe übervoll und alle anderen Gruppen sind mehr oder weniger frei.
Also die ist auch relativ voll, aber da sind also
wirklich freie Termine. Jetzt ist es einfach so,
dass dieser Termin am Dienstag von 11 bis 14 Uhr
so voll ist, dass wir nicht genügend Betreuer haben.
Christian, der Christian Spe, der den Übungsbetrieb plant,
wir haben einfach einen Satz an Betreuern und das ist klar,
die haben nicht alle zu allen Zeiten
Zeit Wir müssen natürlich dafür sorgen, dass ihr genügend Betreuer bekommt.
Das heißt, wenn ihr jetzt in diesem Dienstagstermin seid,
könnt ihr damit rechnen, dass es ziemlich wenig Spaß machen wird.
Ja, es macht keinen Spaß, wenn das zu voll
ist und zu wenig Betreuer da sind. Deswegen,
unbedingt, und das ist auch schon eine Mail rumgeschickt worden,
wenn ihr in diese Gruppe fallt und ihr könnt da wegwechseln,
dann wechselt bitte da weg,
indem ihr eine E-Mail mit dem Wechselwunsch an Silke Peters schickt.
Peters sei der Informatik unihamburg.de und dann nahme Matrickelnummer,
derzeitiger Termin gewünschter Termin.
Das ist jetzt ein dringlicher Wunsch oder eine dringliche Bitte
Irgendwann, wenn es einfach nicht vorangeht, also da niemand wegwechseln will,
dann werden wir sozusagen ein bisschen nachhaltig wechseln lassen müssen.
Also deswegen, ja, versucht da wegzuwechseln,
wenn es euch möglich ist. Aber auch andere Wechselwünsche könnt
ihr da anmelden, wenn es wirklich nicht anders geht.
Ich hatte jetzt zwei Physiker, die gesagt haben,
sie sind am Dienstag drin oder am Freitag,
der eine am Dienstag, der andere am Freitag und die können nur noch am Montag.
Es geht gar nicht anders. Gut,
dann müsst ihr das natürlich auch in einer E-Mail formulieren an
Frau Peters und dann wird sie euch versuchen,
in eine andere Gruppe umzutragen
Okay, ihr seht also, da sind noch ein bisschen freie Plätze.
In den anderen Terminen. Gut. Das ist erstmal das,
was ich zur Organisation sagen wollte. Hätte ich eigentlich für
20 Minuten geplant, jetzt sind es 40 geworden, herrlich.
Gibt es noch Fragen? Erstmal jetzt zu Orga,
zum Ablauf, zum Übungsbetrieb. Das scheint nicht der Fall
zu sein. Gut, dann würde ich sagen,
gibt es jetzt zwei Möglichkeiten.
Wir könnten
eine kurze Pause machen
Wir könnten aber auch durchmachen. Ich habe ja zufällig Sturesi dabei. Abstimmung,
ich mache eine neue Abstimmung, und zwar eine spontane.
Zwei Antworten. Antwort A ist, wir machen eine Pause
, Antwort B ist, wir machen keine Pause.
Also A, Pause, B, keine Pause.
Einfach mal eben abstimmen
Okay, wir sind wieder fast bei 150 Stimmen.
Da sind wir. Stoppen wir mal
und blenden wir mal durch
Auha. Ja, sehr schön. Dann haben wir
eine Chance, dass wir heute früher fertig werden.
Also die knappe Mehrheit war dafür, dass wir keine Pause machen.
Offensichtlich, das gilt nur für heute. Fürs nächste Mal
werde ich auch nochmal fragen. Im Allgemeinen ist es so,
dass die Mehrheit eigentlich für eine Pause ist.
Heute machen wir mal durch. Beim nächsten Mal frage ich nochmal. Ich vermute,
dass es dann vielleicht wieder eine andere Mehrheit gibt,
aber heute bei diesem sagenhaften Wetter wollt ihr möglicherweise auch früh
wieder raus hier
Gut, also wir machen keine Pause, dann mache ich jetzt einfach weiter.
Okay. Das ist jetzt der eigentliche Vorlesungsteil. Ich sage anfangs
ein paar Worte zu den üblichen Verdächtigen, also Symbole,
Literaturhinweise und so weiter. Die Symbole kennt ihr aus SE1,
das ist also auch keine Überraschung, zentrale Begriffe hervorgehoben,
Vertiefungsthemen, eher so, naja, am Rande interessant,
Literaturliste, Zwischensummen,
immer für Zusammenfassung und Ausblick aus Übersicht und Literaturreferenzen
Dann haben wir hier den roten Merker, der irgendwie so ein bisschen was hervorhebt.
Der andere gestreifte Merker, so imperative Grundkonzepte,
das ist hier in SE2 nicht mehr ganz so im Vordergrund.
Java explizit eigentlich gekennzeichnet, als Java-Beispiel. Negativbeispiele mit so
einem radioaktiven Symbol. Und wenn wir was mit der UML
machen, ist das auch markiert. Und softwaretechnische,
also wenn wir so Erfahrungen aus der Praxis der Softwareentwicklung wiedergeben,
dann ist das eben eher mit so einem Zahnradsymbol gekennzeichnet.
Gut, grundlegende Lehrbücher, da habe ich mal so ein bisschen die Literaturliste entübt durchforstet.
Und es gibt ja inzwischen schon die fünfte Auflage von Barnes Kölling,
der ist vererst 1, supergut geeignet.
Der ist für SC2 auch noch geeignet. Also es sind
Inhalte in SC2, die auch in den Barnes Köln diskutiert werden.
Das ist nicht ein Begleitbuch zu dieser Veranstaltung,
aber es ist als Ergänzung sehr empfehlenswert nach wie vor.
Also wer das sich mal beschaffen möchte, weil er einfach
einen anderen Zugang haben will zu ähnlichen Themen, sehr empfehlenswert.
Auch mit Objects-First-Ansatz, also ähnlich wie hier SC1 und SC2.
Dann gibt es ein klassisches Java-Buch und es gibt auch ein spannendes Java-Buch von dem Schiedermeyer,
das ist neu, Programmieren mit Java 2, fortgeschrittene Java-Programmierung,
also alle das, was so über das in SE1 hinausgeht,
aber auch teilweise über das, was wir in SE2 machen,
hinaus, Netzwerkprogrammierung,
XML-Programmierung mit Java und so weiter.
Aber es ist natürlich auch dann Inhalte drin, die dann teilweise hier diskutiert werden.
Reflection ist da mit drin, Pakete und so weiter.
Gut, dann gibt es das Java-Praktikum,
also eine Aufgabensammlung mit Java-Aufgaben, auch in zweiter Auflage inzwischen.
Sehr nützlich, wenn nochmal ein bisschen, sagen wir,
handwerklich ein bisschen üben will.
Dann das übliche Java-Programming Language geht es inzwischen auch in einer
neuen Auflage
Java Unan Nutshell ist nicht mehr ganz so neu.
Effective Java ist mit das beste Buch zu Java für Leute,
die wirklich fit sind in Java.
Also wer wirklich richtig professionelle Software entwickeln will mit Java,
sollte das Buch lesen.
Extrem gut geschrieben und extrem kompetent und sehr, sehr nützlich.
Okay, und dann die Java Language Specification,
die ist jetzt gerade ganz aktuell ganz neu rausgekommen als Beschreibung von Java 7.
Da steht dann tatsächlich definitiv alles so drin,
wie man es im Detail nachlesen möchte
Gut, dann gibt es noch ein paar weitere Grundlagenwerke.
Brauche ich, glaube ich, nicht so wahnsinnig viel zu sagen.
Es ist nichts Neues. Auch das ist mehr oder weniger
Literatur aus SE1, die wir da schon teilweise empfohlen haben.
Wir werden natürlich auch in den Veranstaltungen, wenn wir bestimmte
Themen aufgreifen, nochmal Literaturhinweise geben zu den einzelnen Themen.
Das ist jetzt eher, sagen wir, so ein bisschen grundlegend.
Ja, hier unter anderem auch das Buch von Heinz Züllighofen.
Es gab eine deutsche Ausgabe 1906 1996 oder 1998.
Das ist die englische Version von 2004. Das ist also,
beschreibt sehr umfassend
den Weg
Werkzeug- und Materialansatz, den Heinz mit seinen Kollegen, die letzten Jahre,
Jahrzehnte eigentlich entwickelt hat und ausgearbeitet hat und auch in der Praxis massiv einsetzt.
Das ist auch ein bisschen Grundlage für diese Veranstaltung.
Wir werden also auch mit so ganz leichten Einflüssen beim Ansatz hier arbeiten,
weil es da auch primär um die Konstruktion von interaktiven Anwendungen geht.
Okay. Gut, dann werde ich jetzt mal ein bisschen versuchen zu motivieren,
worum es hier primär in dieser Veranstaltung geht und insbesondere ja
auch den Titel nochmal ein bisschen motivieren.
Ich habe gesagt, die Vorlesung heißt, objektorientierte Programmierung und Modellierung.
Und da kommt der Begriff Modell schon ziemlich stark vor und
den müssen wir uns jetzt mal ein bisschen beleuchten.
Vielleicht erstmal nochmal so als Übersicht, was wir so bisher gemacht haben.
In SE1 haben wir mit einer Programmiersprache, objektorientiert programmiert.
Das heißt also, wie programmieren wir mit Java?
Das war Thema in SE1. Wir haben aber auch schon so ein bisschen modelliert,
in dem Sinne, dass wir uns überlegt haben,
wie kann ich denn ein Stück Software, ein Programm beschreiben,
zum Beispiel mit einer Modellierungssprache wie der UML.
Wir haben tatsächlich technisch die Einheiten eines Softwaresystems,
also Klassen und Beziehungen zwischen den Klassen in der UML modelliert.
Also das war dann sehr technisch orientiert. Da haben wir
tatsächlich schon so ein bisschen modelliert. In SE2,
das war also der Fokus in SE1, HoOP und in SE2,
geht es wie gesagt um Programmierung und Modellierung.
Das heißt, wir werden auch hier wieder natürlich uns weiter ansehen,
wie programmieren wir in Java, also ein bisschen uns die Mechanik der Sprache ansehen.
Was wir aber auch machen werden, und das ist eben halt das,
was jetzt hier so ein bisschen spannend ist, ist,
Frage, wie modellieren wir denn Software, damit sie passt für fachliche Aufgaben?
Ich habe eben dieses Beispiel gezeigt mit der Mediathek.
Das nennen wir die Fachlichkeit einer Anwendung. Das ist der
fachliche Kontext. Also worum geht es denn? Naja,
ich will irgendwie CDs verleihen. Da gibt es dann real
echte CDs oder DVDs. Da gibt es reale Kunden,
die an realen Orten wohnen und Adressen haben.
Und die werden dann irgendwie abgebildet in das Softwaresystem.
Das nennen wir modellieren. Wir machen uns ein Modell von
diesen realen Dingen und holen sie rein in unser Computersystem.
Und das ist etwas, was hier jetzt ansatzweise schon geübt
Aber wir werden uns auch dann dabei ansehen, dass wir
ja auch objektorientierten Entwurf brauchen. Also sobald wir Systeme bauen,
die etwas größer sind, werden wir uns überlegen müssen,
wie wir das Ganze ein bisschen in kleinere Teile zerlegen können,
in handhabbarere Teile.
Also ich habe hier nochmal Eclipse aufgemacht. Mediathek,
das ist zum Beispiel die Vorlage,
mit der ihr arbeiten werdet in den ersten Wochen.
Mehr oder weniger sieht die so aus. Und dann seht
ihr hier, das sind also relativ viele Klassen,
die da einfach in dem System schon drinstecken.
Ja, das ist also, das sind jetzt hier so,
weiß nicht, 40,
50,
60 Klassen
Klar sind auch Testklassen dabei, das doppelt ein bisschen was,
aber da ist schon ein bisschen was da und wir werden
uns eben halt auch damit beschäftigen,
wie bauen wir denn so ein System so,
dass man sich gut darin zurechtfindet.
Das sind tatsächlich Entwurfsfragen. Entwurf heißt auch,
ich muss irgendein Problem lösen und ich kann es auf die
Weise oder auf die Weise machen.
Also immer dann wenig mehrere Möglichkeiten habe,
etwas zu tun, kommen Entwurfsüberlegungen ins Spiel.
Warum mache ich das so und nicht so? Dann muss ich
auch meine Entwurfsbegründen, meine Entwurfsentscheidungen begründen und verteidigen können.
Das sind alles Themen, die wir hier behandeln wollen in
Okay. Das vielleicht nochmal so als Hintergrund,
also die Unterscheidung zwischen Programmieren und Modellieren,
programmieren könnte man als so eine Art Maschinenbau ansehen.
Also ihr könnt tatsächlich Programme schreiben, die übersetzbar sind,
aber die machen irgendwelchen Unfug. Und man kann eigentlich sagen,
ein Quelltext von Java ist wie ein Bauplan für eine Maschine.
Das heißt, ihr beschreibt eigentlich eine Maschine,
die dann irgendwie ausgeführt wird auf der Java Virtual Machine,
ist tatsächlich sehr maschinenartig.
Der Bauplan kann dabei korrekt sein, aber das Ding,
was man baut, kann total absurd sein.
Also Bauplan ist korrekt,
es wird eine Maschine daraus entstehen,
aber diese Maschine macht nichts Sinnvolles
Kann passieren. Aber, damit wir schon mal zumindest wissen,
welche mechanischen Teile haben wir denn,
sollten wir die Programmiersprache sehr gut behaften.
Das heißt, Programmieren heißt in erster Linie Mechanik von irgendwelchen Zahnrädern zu steuern.
Also ihr könnt euch wirklich die Klassen so vorstellen, wie so kleine Zahnräder.
Das ist Programmieren. Also irgendwie ein Programm schreiben,
testen, weiterentwickeln, mit der Mechanik der Bauteile vertraut sein,
wissen, wie Dinge zusammenarbeiten können und funktionieren können und so weiter.
Und demgegenüber sehen wir halt das Modellieren als eine andere Tätigkeit,
die man wirklich auch voneinander unterscheiden kann
Wir haben euch vermittelt, objektorientierte Programmierung. Die Mechanik von
Java-Programmen. Das werden wir auch weiter tun. Aber wir
werden jetzt langsam mal so ein bisschen uns drum kümmern,
naja, wir wollen nicht nur, dass man irgendwas baut,
was irgendwas macht, sondern wir wollen, dass das auch eine sinnvolle Aufgabe erfüllt.
Das ist ein fachliches Problem löst, die Software.
Und dafür muss man natürlich erstmal das Problem verstehen.
Und dann es geeignet abbilden. Das heißt,
irgendwie beim Modellieren machen wir uns ein Abbild von irgendetwas.
Meistens, um irgendwas zu zeigen, zu prüfen, auszuprobieren.
Auch da gibt es dann Modellelemente, es gibt Regeln,
es gibt bestimmte Herangehensweisen und wir werden halt hier objektorientierte Modellierungen
ein bisschen intensiver thematisieren
Hier nochmal so ein bisschen die allgemeine Übersicht,
wie man ein Objekt orientiert, noch andere Dinge tun kann.
Was wir halt in SE2 früher drin hatten und inzwischen nicht mehr mit drin haben,
weil es einfach zu viel ist für diese kleine Veranstaltung,
ist die objektorientierte Analyse.
Also wir geben euch jetzt Aufgaben vor. Wir wissen also,
was weiß ich, es soll das und die und die Funktionalität
soll in diese Mediathek reingebaut werden.
Dann müsst ihr immer noch überlegen, wie ihr das modelliert,
wie ihr das abbildet und wie ihr das auch entwerft in eurem System.
Aber was überhaupt zu tun ist, müsst ihr nicht rausfinden.
Wenn man Realsoftware baut, ist das mit eines der
schwierigsten Probleme
Erst mal in den Anwendungsbereich reinzugehen und so rauszufinden,
was wollen die überhaupt da?
Was soll die Software denn machen? Oder eine Marktanalyse zu
machen, welche Software wird denn am Markt noch gebraucht?
Das sind also ganz andere, ganz andere Fragen.
Wie werden wir hier nicht angehen?
Das wird eher Thema sein in der Vorlesung Softwaretechnik.
Da ist es eine Vorlesung für SSE-Studierende im vierten Semester Pflicht
. Für alle anderen ist es ein Wahlpflichtmodul.
Im nächsten Sommer dann für euch interessant. Gut. Dann
gibt es noch Objekte, wieder Vorgehensmodelle. Also diese Idee,
wenn ich Software baue und ich muss irgendwie bis zu einem
bestimmten Zeitpunkt die Software fertig haben, dann gibt es irgendwo
Und es gibt den Zeitpunkt, wo sie fertig sein soll.
Wie komme ich denn von dem Zeitpunkt dahin?
Wie kann ich das irgendwie strukturieren in geeignete Inkremente oder ähnliches?
Also das sind so Vorgehensmodelle in der Informatik, sehr ausgeprägt.
Auch das thematisieren wir in SPT. Und sowas wie Objekte und
ich hatte Meta-Modelle, also so wie in der UML,
da gibt es zum Beispiel ein Meta-Modell,
also einfach diese Frage, welche Modellierungselemente haben wir denn überhaupt?
Das kann man auch objektorientiert betrachten. Gut.
Also Modelle, es geht also um Modellierung oder Modelle.
Modelle sind sehr zentral in der Wissenschaft und im Ingenieurwesen
Und es geht eigentlich immer darum, dass man irgendwie eine
zu untersuchende Realität hat und dann irgendwie diese Realität abbilden will,
um das verarbeitbar zu haben.
Also wissenschaftlich handhabbar, möglicherweise in einer Theorie handhabbar oder einfach
nur das Modell zu manipulieren. Man kann im Allgemeinen nicht
alle Aspekte der untersuchten Realität abbilden, das ist ganz klar.
Also müssen wir beim Modell bilden, reduzieren.
Wir müssen also Dinge weglassen, müssen teilweise auch Dinge konstruieren,
also zusammensetzen und wir müssen relativ stark abstrahieren.
Das heißt, wir lassen einfach auch Dinge weg
Modelle sind einfach wichtig. Also auch hier in diesem Zitat aus der Stanford Encyclapedia of Philosophy,
Models are one of the Principle Instruments of Modern Science.
Also es ist tatsächlich so, fast alles basiert auf Modellen
und das ist nicht nur eine Informatik so,
sondern hier mal so als Beispiel Atommodelle.
Das sind einfach Modelle der Realität. Ihr könnt davon ausgehen,
dass ein Kern nicht so aussieht oder das ist ein Atom so aussieht.
Das sind einfach nur Modelle, die wir haben.
Und dann gibt es aber Formalisierungen dieser Modelle und mit denen
können wir dann rechnen. Wir können dann sogar Vorhersagen machen,
wir können diese Modelle benutzen und in dem Modell was ableiten und dann feststellen,
oh, in der Realität stimmt das ja tatsächlich auch.
Modell ist, der Modellbegriff ist relativ weit gefasst,
also es gibt da ganz unterschiedliche Ausprägungen und wir verwenden hier einen Modellbegriff,
der, wie ich finde, sehr eingängig ist und auch in der Informatik relativ stark verbreitet ist.
Und das sind dabei drei Entscheidungen, drei entscheidende Eigenschaften bei einem Modell.
Das eine ist, es ist eine Abbildung. Das heißt,
ein Modell ist immer irgendwie ein Modell von irgendetwas.
Also es gibt ein Original. Zu jedem Modell gibt es ein Original.
Dann Ist es so, dass ein Modell immer eine Verkürzung ist?
Das heißt, es erfasst nicht das gesamte Original.
Es gibt nicht so etwas wie vollständige Modellierung. Das ist
irgendwie Quatsch eigentlich. Der Begriff ist schon eigentlich ein Oxymeron.
Also es macht nichts viel Sinn, dass das Original vollständig abzubilden.
Möglicherweise gibt es dann Fälle, wo das doch sinnvoll ist,
aber im Allgemeinen ist es so, dass man bei einem Modell verkürzt,
dass man also Dinge weglässt, Eigenschaften des Originals weglässt,
weil für den Zweck des Modells diese Eigenschaften nicht relevant sind.
Und das ist eben halt der dritte Punkt, das ist der Pragmatismus.
Also ein Modell, wird immer nur für einen bestimmten Zweck gebaut.
Oder ein Modell wird entworfen für einen bestimmten Zweck.
Man möchte irgendwas damit machen. Also für wen, warum,
wozu? Das sind ganz wichtige Fragen bei einem Modell.
Es gibt nicht das Modell von einem Original,
sondern von jedem Original kann es zig verschiedene Modelle geben.
Hier so ein Beispiel, die Pyramiden. Das hier ist
ein Foto der Pyramiden. Ihr könnt mir glauben,
die Pyramiden habe ich nicht hier in den Hörsal geholt.
Das ist also auch schon ein Modell.
Ein Foto ist ein Modell von einem Original.
Blendet Sachen aus. Hier sind irgendwelche Sachen jetzt in dem
Foto nicht zu sehen, die natürlich im Original drin sind
Also auch das ist ein Modell. Nach diesem Ansatz,
nach dieser Definition. Und dann gibt es aber auch wieder
von diesen Modellen jetzt hier weitere Modelle,
also auch Modelle von Modellen, sind denkbar natürlich.
Und dann aber ganz unterschiedliche Zwecke. Also hier möchte man irgendwie
was über die Mantelflächen sagen und den Fußpunkten und die Grundfläche,
was weiß ich. Und hier geht es vielleicht eher darum,
naja, was war denn der Zweck von diesen Pyramiden?
Also anscheinend war es ja nicht anscheinend,
es war ein Gradkammern und dann sieht man hier,
wie bestimmte Gänge da laufen und die Grabkammern an verschiedenen Stellen da untergebracht sind.
Also verschiedene Modelle für verschiedene Zwecke
Das ist ganz wichtig, dass man einfach dieses Konzept von ein Modell ist,
ein Abbild von einem Original immer vor Augen hat.
Also wenn wir jetzt irgendeinen Gegenstandsbereich haben, nehmen wir mal Medienverleih,
CWDs und DVDs, das ist dann der Gegenstandsbereich,
dann gibt es ein Modell des Gegenstandsbereichs.
Und das ist tatsächlich so, wenn ihr die CDs real irgendwo habt,
dann werdet ihr in eurem Modell von dem Gegenstandsbereich möglicherweise
nicht alle Eigenschaften einer CD abbilden.
Zum Beispiel braucht ihr nicht die Cover mit zu modellieren,
also die Farben des Covers oder ähnliches
Es gibt sowas wie iTunes, da sind ja die Cover
auch mit drin, das sieht dann nett aus.
Aber wenn ich die Dinger verleihen will,
in der Mediathek, dann muss ich nur wissen,
welche CD ist es denn oder welche DVD,
da ist die Farben des Covers erstmal nicht wichtig.
Das heißt also, je nachdem, für welchen Zweck ich
das Modell baue, lasse ich bestimmte Dinge weg.
Ich abstrahiere von Teilen. Das heißt also,
der Gegenstandsbereich ist immer die Basis für das Modell des Gegenstandsbereichs.
Das ist immer ganz wichtig, dass man sich überlegt,
dass dieses Modell auch schon zielgerichtet gebaut ist.
Also man hat irgendwie einen Zweck im Kopf,
man möchte zum Beispiel eine Softwareunterstützung für so eine Mediathek,
für seinen Medienverleih haben
Gut, und dann gibt es auch das Modell des Anwendungssystems.
Das ist also die, sagen wir jetzt,
wichtige Unterscheidung, die wir gerne machen.
Modell des Gegenstandsbereichs. Das ist noch komplett unabhängig eigentlich von Software
. Da kann man sagen, ich erkenne in dem Gegenstandsbereich
Medienverleih so Dinge wie, welche Medien gibt es denn?
Es gibt sowas wie Kunden, also sowas wie ein Glossar zum Beispiel.
Das ist etwas, was man sehr häufig hier in diesem Bereich findet.
Modell des Gegenstandsbereichs. Also welche Begriffe sind wichtig, welche
nicht. Und dann bauen wir aber irgendwann ja auch ein
Anwendungssystem und dann machen wir uns ein Modell von dem Anwendungssystem
Und das ist natürlich dann auch wieder so,
das Ganze basiert natürlich dann auf dem Modell des Gegenstandsbereichs,
was wir uns vorher erarbeitet haben.
So, und das wiederum ist aber nur die Basis für das Anwendungssystem.
Da unterscheiden wir auch, weil das Anwendungssystem ist das System,
was wirklich läuft, auf irgendeinem Rechner und üblicherweise in einem Einsatzkontext.
Das ist mit Software fast immer so,
dass man die Software auf einem Entwicklungsrechner entwickelt und ausgeführt
wird sie aber auf ganz anderen Rechnern.
Das heißt, das Anwendungssystem mit Datenbanken, mit Benutzern,
mit Netzzugängen und allem drum und dran,
das findet irgendwo in einem Ansatzkontext,
läuft das ab
Und das hier ist das Modell des Anwendungssystems.
Und warum unterscheiden wir das? Naja,
weil zum Beispiel der Quelltext gehört zum Modell des Anwendungssystems.
Aber auch UML-Diagramme, die wir von einem System machen,
gehören klassisch hier rein in das Anwendungssystem.
Man kann natürlich auch UML-Diagramme machen, hier für den Gegenstandsbereich.
Und man kann auch da Begriffe aus dem Gegenstandsbereich modellieren mit der UML.
Dafür ist sie ja auch gemacht. Aber so ein Klassendiagramm
üblicherweise ist das schon sehr nah dran an dem Anwendungssystem.
Okay, ja, und das heißt,
was ganz wichtig ist,
wenn man modelliert,
man muss abstrahieren
Und Abstraktion ist mit das Wichtigste oder stärkste Hilfsmittel,
das wir haben, um überhaupt Komplexität zu verarbeiten.
Wir müssen ständig eigentlich Dinge ausblenden,
weil sonst würden wir einfach überladen werden mit den Informationen,
die uns da auf uns einstürmen.
Und das Entscheidende bei der Abstraktion ist immer, die Dinge,
die wichtig sind, muss ich erkennen und die Dinge,
die unwichtig sind, muss ich ignorieren.
Also die einen muss ich rausholen, rausarbeiten und die anderen
muss ich irgendwie weglassen. Und wenn wir das gut machen,
dann können wir tatsächlich,
wenn das Modell entsprechend gute Eigenschaften hat,
können wir dann zukünftig
auch Ereignisse vorhersagen
Und das ist eben halt ganz oft so,
dass wir dann auch diese Repräsentationen, die wir da haben,
manipulieren können. Das ist ein Beispiel hier,
ihr seht hier so Dinge wie drei Äpfel,
drei Tomaten und irgendwann haben die Menschen angefangen zu reflektieren darüber,
naja, wir haben hier irgendwie drei von irgendwas und da drei von irgendwas,
was haben die gemeinsam, naja, es sind jeweils drei.
Und dann hat man irgendwann festgestellt, hm,
dann machen wir doch mal irgendwie hier so Stellvertreter,
drei Striche so für die drei irgendwas.
Und dann sind wir heute bei unserer arabischen drei,
die wir abstrakt manipulieren können, in der Mathematik,
wir können die addieren,
multiplizieren,
tolle Dinge damit machen
Abstrakten Ding. Aber ursprünglich waren es einfach mal drei Dinge, irgendwas.
Das ist also diese ganz, ein ganz prominentes Beispiel für Abstraktion.
Wir abstrahieren eigentlich von allen Eigenschaften, außer der Anzahl
und repräsentieren dann den Wert drei mit verschiedenen Symbolen hier.
Ganz wichtig. Und wie gesagt, wenn wir dann
erst mal so Dinge abstrahiert haben und ein Modell haben,
dann wollen wir dieses Modell halt auch üblicherweise manipulieren.
Also wir wollen nicht nur abstrahieren und dann repräsentieren,
sondern auch Transformationsregeln bauen,
um dann vielleicht sogar axomatisch formal an dem Modell was tun
zu können
In der Physik ist das gang und gäbe,
dass man einfach mit solchen Modellen arbeitet zum Beispiel.
Hier nochmal ein Beispiel für die Manipulation von Repräsentation.
Wenn ich also so mir ein Modell der Pyramide gemacht habe,
dann kann ich hier so die klassischen gehemetrischen Dinge anwenden,
die ihr so aus der Schulmathematik kennt.
Also hier, wie man die Höhe berechnet,
wenn man die Grundfläche kennt und so weiter.
Okay, das ist soweit so gut. Hier ist noch
ein weiteres Beispiel. Abstraktion und Modellbildung am Beispiel Kinosaal.
Auch hier wieder ein Foto von einem realen Kinosaal.
Dann hier ein Modell von diesem Kinosaal
Und hier eine mögliche Abbildung in einem Computersystem. Also hier
ist ein Modell des Anwendungsbereichs. Hier haben wir einen vielleicht
schon ein Modell des Anwendungssystems, in dem wir sagen,
naja, alle Sitze, die schon verkauft sind,
die repräsentieren wir mit einer Eins,
also die nicht verkauft sind mit einer Null.
Und haben das einfach in eine Matrix abgebildet. Das ist dann
möglicherweise eine Ray oder ähnliches. Ich habe ja gesagt,
ich wollte nochmal vielleicht das andere System zeigen.
Da haben wir hier unser Kino-Ticket-Verkaufssystem. Ja,
da haben wir also auch ein System für euch gebaut.
Und mit diesen beiden Systemen werdet ihr auch arbeiten in diesem Semester.
Hier ist der Kino-Ticket-Verkauf. Der sieht dann so aus
Dass man hier zwischen verschiedenen Tagen wählen kann. Also ich kann zum Beispiel hier jetzt
auf den nächsten Tag blättern und man sieht hier die Veranstaltung,
die Vorstellung, die laufen in verschiedenen Sälen.
Also hier ist zum Beispiel Saal 2, nochmal zurückblättern,
dann gab es auch hier Saal 1 und Saal 3.
Und man kann also auch hier sehen,
wenn ich jetzt zum Beispiel, das ist Saal 1,
der jetzt hier angezeigt wird, hier, das ist Saal 1,
ich kann jetzt hier auch auf Saal 3 klicken,
der ist dann vielleicht etwas sperrlicher bestuhlt.
Und das heißt also, hier geht es erstmal darum,
dass man die verschiedenen Veranstaltungen in einem Kino,
in einem mit verschiedenen Sitzplätzen und Sälen modelliert.
Und jetzt kann man aber tatsächlich hier anfangen zu verkaufen.
Ich kann jetzt hier Plätze auswählen und kann sagen,
so, jetzt verkaufen wir das nochmal.
Und dann erscheint hier irgendwie sowas wie ein Kassenwerkzeug.
Jetzt hat er irgendwie 27 Euro zu bezahlen, zahlt 30,
kriegt also drei wieder, zack, ist es verkauft.
Und dann kann man hier jetzt weitermachen. Das ist das,
was ihr dann auch ein bisschen bearbeiten werdet in der zweiten Phase von SE2.
Also da sind beides interaktive Systeme und wir haben hier in SE2
einen gewissen Fokus auf das Thema interaktive Systeme.
Das heißt also, wir werden uns primär mit der Modellierung
und auch dem Entwurf von interaktiven Systemen beschäftigen. Okay,
also Modell, Abstraktion vom Original für einen bestimmten Zweck,
dann wollen wir das meist auch entsprechend interpretieren.
Also das ist vielleicht nochmal so ein Zusammenhang,
der nochmal explizit gemacht werden sollte. Wir haben ein Original,
Gegenstände und Beziehungen im betrachteten Ausschnitt der Realität, das Original.
Das Original muss nicht etwas Reales, Physikalisches sein oder etwas Physisches.
Das wisst ihr auch, es gibt genügend Dinge inzwischen auch im Internet,
die überhaupt nicht mehr real sind, sondern eine Mail,
ist eine Mail greifbar, real, nee.
Aber trotzdem ist sie für euch jeden Tag ziemlich wichtig möglicherweise.
Aber wenn wir jetzt sowas haben, wie die Originale,
dann gibt es eine Abstraktionsfunktion, dann habe ich so ein Modell,
also Elemente und Relation in dem Modellbereich und kann dann auch das Original wieder interpretieren,
indem ich das Modell benutze.
Dann gibt es die Möglichkeit, dass ich das Modell manipuliere,
also dass hier Beziehungen entstehen,
dass ich sozusagen das Modell in ein zweites Modell umwandle.
Und bei dieser Modellmanipulation dann wieder auch möglicherweise zurückwirken kann auf
das Original.
Das kann passieren
Das passiert sogar sehr häufig. Da werden wir gerne mal
ein paar Beispiele sehen. Also das heißt,
dass wir das Original tatsächlich verändern, indem wir Modelle manipulieren.
Meistens machen wir es in der Informatik mit den Modellen.
Also es war, klassisch war das immer so,
dass wir in der Simulation, Computer wurden ganz häufig eingesetzt für Simulationen.
Irgendwie ein Ausschnitt der Realität erfassen, modellieren,
abbilden und dann da an dem Modell was machen,
um rauszufinden, ob bestimmte Dinge funktionieren oder nicht funktionieren.
Und vor allen Dingen gefahrlos, damit man nicht in der
Realität was ausprobieren muss. In so einem Modell kann man
schon mal so einen Kernreaktor hochgehen lassen.
Das macht real nicht
so viel Spaß
Also das ist einfach relativ wichtig, dass man da mit Modellen viele Dinge tun kann, die revidierbar sind.
Und bei Software ist das eben halt so ähnlich,
das heißt, wir haben irgendwie unser Programm,
das ein Modell ist von dem Anwendungsbereich,
von den Gegenständen und Beziehungen im Anwendungsbereich, wir abstrahieren,
wir spezifizieren,
wir implementieren und haben dann irgendwie sowas,
dann läuft das Programm ab und es kommt zu einem veränderten
Programmzustand und das wirkt dann auch wieder zurück auf die Realität
oder auf das Original,
sagen wir mal lieber
etwas allgemeiner
Okay, das passiert relativ viel. Also hier haben wir
mal so ein paar Beispiele, das sind Leitstände.
Zum Beispiel vom Daisy oder von der Hala oder von Hamburger Hochbahn,
die genau solche Softwareleitstände haben. Die haben also ein Abbild der Realität,
da fahren draußen Züge und die haben dann da ihre Bildschirme,
wo die Züge dann auch unterwegs sind und können aber dann tatsächlich sehr genau verfolgen,
was da passiert.
Wir können Vorhersagen machen über bestimmte Dinge,
man kann dann möglicherweise erkennen, dass es Probleme gibt,
wenn ein bestimmter Zug ausgefallen ist und so weiter
Aber wir beeinflussen damit auch schon die Umwelt. Also man kann tatsächlich
mit solchen Modellen natürlich auch wieder zurückwirken in die Realität.
Und das ist noch viel stärker so mit dem Internet geworden.
Das heißt, im Internet finden inzwischen so viele Dinge statt,
dass also für viele das Leben eigentlich im Internet stattfindet.
Das heißt, auch virtuelle Gegenstände beeinflussen unseren Alltag sehr stark.
Ich habe eben schon die Mail erwähnt als Beispiel oder Online-Banking.
Das ist ja alles sehr virtuell inzwischen nicht.
Man hat ja nicht mehr die Idee von einem Bankkonto,
wo irgendwo, ich weiß gar nicht,
ob es überhaupt mal ein Modell von einem Bankkonto gab,
die Vorlage für Bankkonten stelle ich mir irgendwie ganz eigenartig vor.
Wahrscheinlich gab es früher mal so einfach so Fächer in Banken,
wo man sein Geld reinlegen kann.
Keine Ahnung. Und das ist aber, wie gesagt,
inzwischen stark virtualisiert. Und das geht sogar so weit,
dass wir inzwischen auch über die Software und über unsere Modelle der Realität,
die die Umwelt auch anders wahrnehmen.
Ich weiß nicht, ob ihr das kennt, Google Goggles.
Man kann irgendwie auch was draufhalten und kann sagen, hier,
was ist das für eine Pflanze und kriegt dann Informationen dazu eingeblendet.
Oder man geht in ein Museum und kann irgendwie auf ein Kunst,
auf ein Gemälde zeigen und dann wird einem dazu was angezeigt.
Ja, was vom Frieda Carlo
Das sind schon relativ umfassende Aspekte. Und das ist eben halt einfach,
deswegen ist für uns der Modellbegriff so zentral, weil so viel passiert da.
Okay, dann habe ich jetzt, ich habe noch
ein bisschen Zeit. Dann, wenn wir jetzt,
sagen wir, akzeptiert haben, wenn wir Software entwickeln,
machen wir eigentlich immer ein Modell von einem Original.
Das Original muss nichts physisches sein, es kann auch was
anderes sein, kann auch wieder selbst ein Modell sein.
Dann abstrahieren wir, wir verkürzen Dinge,
wir lassen Dinge weg,
wir holen Dinge zentral rein
Aber das alle machen, das alles machen wir immer für einen bestimmten Zweck.
Das ist ganz wichtig. Der Pragmatismus steht im Vordergrund,
wir machen nicht Modelle einfach nur so,
sondern wir wollen immer irgendwas erreichen.
Und die Software soll natürlich, die wir bauen,
soll benutzbar sein. Das ist für die Benutzer ganz wichtig,
aber für die Entwickler ist es natürlich auch wichtig,
dass die Software weiterentwickelbar ist. Das ist ein Aspekt,
den wir natürlich als Software-Technik-Gruppe sehr stark auch im Vordergrund sehen.
Also es reicht nicht, eine Software zu bauen,
die irgendwas kann und irgendwas macht,
sondern die muss halt auch
weiterentwickelbar sein,
wartbar sein
Nützt überhaupt nichts, wenn man da irgendwie so ein Ding baut,
was nach zwei Wochen nicht mehr wartbar ist, weil keiner mehr durchblickt.
Und das ist bei großen Softwaresystemen leider so, dass die relativ schnell sehr unübersichtlich werden.
Also dieses weiterentwickelbar, interpretierbar, das ist schon sehr wichtig.
Da müssen wir natürlich auch eine angemessene Formalisierung wählen.
Das heißt, wir können dazu kommen, dass wir sagen,
naja, die Software muss korrekt sein.
Den Korrektheitsbegriff habe ich ja schon in SE1 so ein bisschen thematisiert.
Wann ist denn Software korrekt? Naja,
wenn es die vorgegebene Spezifikation erfüllt,
dann muss die aber auch verständlich sein,
sie muss konsistent sein und wir müssen auch Ganz wichtig,
wenn wir Softwaresysteme bauen und Modelle umsetzen.
Da müssen wir auch gucken, dass die Implementationen,
die wir wählen, effektiv ist.
Also dass tatsächlich das macht, was sie tun soll.
Und das aber auch effizient macht. Es ist einfach wenig sinnvoll,
eine Software zu bauen, die ein bestimmtes Problem in 20 Jahren löst.
Was sich aber eigentlich morgen gelöst haben muss.
Also da gibt es natürlich große Unterschiede, dass es etwas
so Algorithmen und Datenstrukturen haben wir in SE1 so ein bisschen thematisiert.
Komplexität von Algorithmen. Das machen wir hier in SE2 jetzt praktisch
gar nicht mehr. Da gibt es dann ein Modul dazu,
Algorithmen und Datenstrukturen, in denen wir da sehr viel mehr
euch mit beschäftigt
Zwei ganz wichtige Begriffe im Zusammenhang mit Modellen
sind Verifikation und Validation