Und schon ist es wieder 14.15 Uhr an einem Mittwoch in Deutschland.
Das bedeutet, objektorientierte Programmierung, heute Vorlesung 6. Für mich
ist jetzt schon bergfest aller Hälfte des Semesters ist um.
Das hängt damit zusammen. Fred und ich haben uns überlegt,
dass wir für die nächsten Themen unsere Taktung ein klein wenig verändern werden.
Und zwar darf ich heute 90 Minuten zu Ihnen sprechen und
als Revanche wird Fred nächste Woche 90 Minuten zu Ihnen sprechen
Das heißt, ich darf jetzt mal den Bogen spannen von,
wo sind wir denn jetzt eigentlich? Und wie kriegen wir es hin?
Das ist das Thema der nächsten zwei Einheiten am Mittwoch.
Wie kriegen wir es hin, dass die Strukturierungsmittel,
die sie jetzt im technischen, was die Bausteine anbetrifft,
wie kriegen wir es hin, dass sie diese Bausteine auch sinnvoll verwenden?
Die Bausteine, Klassen, Die Beziehung, in denen Klassen zueinander stehen können, benutzt Beziehung, Vererbungsbeziehung. Und das Strukturierungsmittel oberhalb von Klassen,
dass wir ihnen beim letzten Mal,
worüber Fried und ich beim letzten Mal gesprochen haben,
Pakete, will heißen, die Idee,
wie kann man Klassen gruppieren, so das sinnvolle,
größere, zusammenhängende Einhalten entstehen, die es ihnen und denjenigen,
die mit ihnen zusammen ein größeres Stück Software entwickeln,
dieses Stück Software so zu strukturieren,
dass eine hohe innere Produktqualität sichtbar wird oder erkennbar wird.
Und das ist das Thema, über das ich heute mit Ihnen,
wo ich versuchen werde, Ihnen mal so einen Eindruck davon zu geben,
was ist da eigentlich so in den letzten Jahrzehnten?
Was ist da so passiert? Unter dem Stichwort,
der ja sogenannten objektorientierten Modellierung, also das ist so eine Ebene über dem Handwerkszeug,
das sie bis jetzt kennengelernt haben, der Objektorientierten Programmierung.
Und hier sehen Sie so einen kleinen Fahrplan, was wir
heute darüber uns gemeinsam erarbeiten werden. Ich werde mal,
wie üblich, nicht wie üblich, aber so,
wie ich das eigentlich dann auch häufiger tue,
mal so einen kleinen Blick in die Geschichte werfen,
wie ist das alles so, was waren die Motive,
um sich mit dieser Fragestellung der objektorientierten Modellierung zu beschäftigen.
Und wir werden dann so gegen Ende der Vorlesung,
werden wir so einen Satz von Entwurfsregeln hier miteinander besprechen,
die es ihnen erlauben, die Frage zu beantworten,
in welche Pakete packe ich denn jetzt eigentlich, welche Funktionalität,
wenn sie so eine Aufgabenstellung, wie das da sehen,
das wird uns jetzt so zwei, drei Vorlesungen lang begleitend.
Ich weiß gar nicht, ob das für sie auch in
den Übungen zutrifft. Wenn wir so die Aufgabenstellung haben,
wir wollen eine Bibliothek unter Verwendung von IT,
etwas effizienter organisieren, was steht uns da,
also welche Mittel können wir ihnen mit an die Hand geben,
welche Entwurfsregeln,
sodass sie ein wohlstrukturiertes Stück Software herstellen
So, zunächst mal so, der Blick in die Geschichte,
also objektorientierte Programmierung, sehen Sie so die Zahlen,
die in dem Zusammenhang häufiger genannt werden,
sind so auf der rechten Seite 1964, 1967,
das ist die Entstehung der Programmiersprache Simular,
also ist mit diesen Jahreszahlen verbunden und so unter dem Abschnitt Name-Dropping der Name,
der dort immer wieder so Ihnen begegnen wird,
wenn Sie sich da mal so in die Geschichte oder in die Referenzen aktueller objektorientierter Literatur vergraben ist,
Christen Lügart.
Der hatte damals, der stand mit dem Team,
mit dem er damals gearbeitet hat, stand er vor der Aufgabe,
die sollten irgendwas, nicht irgendwas, sollten ein System bauen,
mit dem der Hafen von Oslo, ID-technisch unterstützt wird.
Und die Mittel, die sie damals zur Verfügung hatten,
waren also die, das war schon fortschrittlich für die damalige Zeit,
also sogenannte Programmiersprachen der dritten Generation.
Die Programmiersprachen werden ja klassifiziert in Generationen, erste Generation Assembler,
zweite Generation schon eine Abstraktion von so ein paar von den Liederen,
maschinennahen Konzepten, so Sprachen wie Fordran oder Kobol.
Die dritte Generation von Programmiersprachen, also die sogenannten Allgäu-Sprachen,
Algorithmic Blanguage, Sprachen sind ja dadurch charakterisiert, dass sie schon eine Syntax haben,
die mit der ihnen ja auch schon aus SE1 so ein klein wenig bekannten Bakus-Nauer-Form beschrieben werden kann.
Also wo die Unterscheidung zwischen Syntax die Programmiersprache hat,
eine beschreibbare Grammatik, die Semantik wird auch,
also mit Mitteln der formalen, der theoretischen Informatik beschrieben.
Also diese Art von Sprachen hatten die damals, das eine von denen zur Verfügung. Was die merken ist,
Also die Art und Weise, wie wir,
also was sie modellieren konnten, so das,
was einem so ein Sprach mit uns zur Verfügung steht,
Sequenz, Fallunterscheidung, Wiederholung ist unangemessen, um,
also jetzt sich zu überlegen,
ein Schiff kommt in den Hafen und ich will dieses Schiff,
will ich da an einer Stelle anlegen lassen,
wenn ich das Schiff jetzt drehe, sowas,
welche Auswirkungen hat das?
Und die sind dann eben auf diese unfassbar geniale Idee der
objektorientierten Programmierung gekommen und habe in dem Zusammenhang auch eine Modellierungsmethodik quasi miterfinden müssen,
wie sie über die, ich will es nicht übertreiben,
aber über die Welt ihrer Anwendung nachdenken, damit sie zu solchen Einheiten kommen,
die in, mit den Mitteln dann einer objektorientierten Programmiersprache umgesetzt werden können.
So eine vergleichbare Problematik, ja wirklich, man muss schon
ein paar Schritte zur Seite gehen, um da die Vergleichbarkeit zu entdecken.
Das ist hier auf der linken Seite Smalltalk,
der Erfinder von Smalltalk, der Urvater von Smalltalk,
Alan Kay, der damals bei einer Firma namens Zerox Park,
glaube ich,
Der hat also die Idee gehabt, also da steht, Computing is simulation.
Also was er, was er haben wollte als Arbeitsgerät,
war etwas, so sie sehen diese Kinderzeichnung da oben links.
Er wollte, dass man auf dem Computer Materialien bearbeiten kann und
so sehr der Leitsatz, den er dazu formuliert hat,
war, do not automate the work,
you are engaged in automate the materials.
Und das ist ein Gedanke, den ich an verschiedenen Stellen
jetzt hier in dieser Vorlesung aufgreifen werde.
Es wird uns darum gehen, so bei der Objektorientierten Modellierung,
Arbeitsmaterialien zu modellieren, die dann andere Menschen,
die Benutzer ihrer Programme bei ihrer Arbeit, bei den Arbeitsprozessen verwenden können.
So, jetzt, wenn das mal so die Grundidee ist,
Materialien zu modellieren, die in Arbeitsprozessen verwendet werden können.
Jetzt ist sozusagen die Diskussion darüber eröffnet, wie können wir,
wie können wir das hinbekommen. Und sie brauchen sich da
keine Sorgen zu machen Also sie sind nicht die Ersten,
also die, die sich mit dieser Frage beschäftigen.
Sie sehen hier mal so einen kurzen Abriss durch die Geschichte der Objektorientierten,
der objektorientierten Modellierungsmethoden. Also das am Anfang so Simular,
da halt Lügert und andere,
haben sich im Kern mit der Frage der Objektorientierten Programmierung beschäftigt,
weil eben so das, was sie heute selbstverständlich nutzen,
damals noch nicht zur Verfügung stand.
Und die Frage, die sich eben danach in der Folge gestellt ist und das,
womit ich diese Vorlesung jetzt angefangen habe,
wie setzen wir das Zeug Anführungsstrichen das Zeug methodisch ein.
Und jetzt kann man mal so,
die Namen müssen sie nicht auswendig lernen, aber so das Ganze hilfreich,
mal so ein paar von denen mindestens mal gesehen zu haben,
der hier Grady Bootch ist so einer der ersten gewesen,
der sich mit Object Oriented Design beschäftigt hat.
Okay, also der Design-Gedanke, so wie gestalte ich objektorientierte
Systeme und dazu parallel, also die andere Seite der Medaille,
wie kann eine Vorgehensweise aussehen, mit der ich objektorientierte Programme herstelle.
So, Bert Krankenmeier. Den hat sie schon kennengelernt.
Und zwar hat er sich mit dem Vertragsmodell,
so ist er uns hier in dieser Runde schon,
über den Weg gelaufen. Der hat also eine eher,
sagen wir mal, technisch formal getriebene Sichtweise auf objektorientierte Modellierung,
weil er so was, ich bin mir nicht sicher,
ob das Zitat, ob das so wörtlich in seinem Buch drinsteht,
aber ich habe das mindestens, ich versuche es,
das mal vorsichtig zu formulieren.
Ich habe das so gelesen, also nicht,
dass er das geschrieben hat.
Ich habe das so gelesen, die Objekte liegen auf
der Straße
Okay. Das ist wahr. Wenn man es genauso wahr,
wie wenn ihn in einer, wenn ihnen jemand sagt,
das Geld liegt doch auf der Straße.
Ja, das ist für manche ist das so.
Für die meisten von uns ist es nicht so.
Und insofern ist die Aussage, die Objekte,
also wir sind doch da, ist etwas verkürzt.
Und dass das verkürzt ist, kann man schon allein daran sehen,
also wie viele andere Leute sich in der Folge noch damit beschäftigt haben,
also über Systems, Analysis, Object Oriented Systems, Analysis zu sprechen.
Hier ist es wieder Analysis and Design. Jetzt irgendwo kommt
auch nochmal, also hier Modeling and Design. Und die Zeit,
die sie da sehen, So diese 80er und bis rein in die 90er,
ist dann im Nachhinein, ist sie bezeichnet worden,
als die Zeitspanne der sogenannten Method Wars, die Methodenkriege.
Also wo sich Leute wirklich, nicht wirklich,
aber dann doch, also darüber, sagen wir mal,
konstruktiv auseinandergesetzt haben, welche unterschiedlichen Ansätze gibt es,
um große objektorientierte Softwaresysteme herzustellen.
Das ist jetzt möglicherweise
eher interessant für Historiker
Sich damit näher zu beschäftigen. Sie kriegen in ihrem Studium noch an verschiedenen Stellen namentlich,
also wenn sie sich für Softwaretechnik interessieren,
kriegen das Ergebnis dieser Methodenkriege noch vermittelt und an ein,
zwei Stellen haben wir das auch schon uns angeschaut,
die Unified Modeling Language ist das Ergebnis,
sozusagen der Friedensschluss, den es dann gegeben hat,
aus diesen Methodenkriegen in Anführungsstrichen,
es hat also so zwischen den,
also vielen der beteiligten Akteure dann so eine Einigung gegeben,
um die sogenannte Unified Method und in dem Zusammenhang die Unified Modeling Language ein Friedensschluss gegeben,
der auf dies hier die UML als Ergebnis hinaus lief.
Der Prozess, der zur UML,
das ist ja nur in Anführungsstrichen eine Menge von Diagrammen,
der Prozess, der parallel dazu definiert worden ist,
ist der Unified Process.
Damit werden wir uns also auch nur ansatzweise hier beschäftigen.
Wie gesagt, also das sind Themen,
die so vor allem in der Softwaretechnik und später in
der Softwarearchitektur
vertieft werden
Damit sie eine Vorstellung davon bekommen, also was damit eigentlich gemeint ist,
worüber sich diese Leute eigentlich gestritten haben. Also so nach dem Motto,
ich weiß nicht, ob ich denen,
ob ich die Bemerkung schon mal gemacht habe,
also das Studium hier, der Informatik,
wahrscheinlich in anderen Studiengängen auch, so sie erfahren von uns mitunter Dinge,
von denen sie gar nicht wussten, dass sie sie nicht wissen wollen.
Worüber die sich und so eine der großen Wegscheiden bei diesem
objektorientierten Methoden, sind sie hier,
also man kann entweder anwendungsorientiert oder Struktur orientiert auf
die Welt schauen
Das, was wir ihnen hier nahelegen werden,
ist eine sogenannte, ist eben diese anwendungsorientierte Sichtweise.
Wir schauen uns Arbeitsprozesse an und aus diesen Arbeitsprozessen nehmen wir Gedanken auf,
wie objektorientierte Systeme aussehen können, die genau diese Arbeitsprozesse beziehungsweise
dann die effizientere Form davon unter Verwendung von IT-Systemen gestaltet werden können und sollen.
So, und da kommen jetzt schon so ein paar Begriffe vor,
die im Weiteren immer mal wieder auftauchen werden und die wir so aus unterschiedlichen Perspektiven betrachten und verdichten werden,
also Arbeitsprozesse Menschen sind in Aufgaben, Schmidt Aufgaben beschäftigt,
bei der Aufgabenerledigung, verwenden Sie Gegenstände und wir werden uns einen anwendungsorientierten Zugang zu diesen Gegenständen verschaffen.
Und die Idee, die auch immer mal wieder auftreten wird, ist,
also wir wollen diese Gegenstände dann, also so modellieren,
dass sie auch in unseren Softwaresystemen als solche erkennbar werden.
Und das, was der Begriff,
der da eine Rolle spielen wird, ist die sogenannte Strukturähnlichkeit,
weil, nehmen wir nochmal dieses Dinerbook ganz vom Anfang,
was wir entdecken wollen in der Welt da draußen,
sind Gegenstände, mit denen Menschen umgehen.
Wir verstehen das, wie sie damit umgehen und versuchen,
Abbilder zu schaffen, die in unseren Objektorientierten Systemen eine Rolle spielt.
So, wenn ich jetzt von objektorientierten Systemen spreche,
dann meine ich damit eine ganz bestimmte Klasse von Anwendungssystemen und das ist interaktive Anwendungssoftware.
Das ist so der Gegenstandsbereich, auf den diese Methode,
über die wir jetzt im Folgenden sprechen, auf die,
die angewendet werden,
also vorrangig angewendet werden soll
Das Buch zum Film sehen Sie hier,
gibt es auch in, also ich weiß nicht,
wie viele Exemplaren, gibt es das in Ihrer Bibliothek,
im Informatikum, in Stellingen. Da kann man sich,
also so fünf Zentimeter dick kann man sich durchlesen,
was denn der sogenannte Werkzeug und Materialansatz der Softwareentwicklung,
was der, also das ist eine anwendungsorientierte Methode,
was der dazu sagt,
wie große Softwaresysteme
strukturiert werden sollen
Ich habe es schon von den Grundprinzipien gesprochen, anwendungsorientierung ist das eine.
Strukturähnlichkeit zwischen Gegenstandsbereich und dem, was im Anwendungssystem modelliert werden soll, ist das andere Grundprinzip.
Jetzt haben Sie ja schon so das eine oder andere Diagramm kennengelernt. Also zum Beispiel Klassendiagramme. Und ich würde Ihnen zutrauen,
dass so sie mit diesem Mittel,
also ich traue ihnen alles zu,
dass sie mit diesem Mittel Klassendiagramm gehen sie jetzt so nach dem Motto,
ich habe verstanden, was da draußen,
sagen wir mal, in der Bibliothek,
was da los ist und ich weiß jetzt auch schon,
welche Klassen ich modellieren möchte und habe also so ein Vererbungsdiagramm und so ein paar Benutztbeziehungen zwischen Klassen und jetzt zeigen sie das,
also dem armen Bibliothekar und sagen, ist das deine Arbeit?
Was glauben Sie,
was der
dann sagen wird
Ja, nein, vielleicht, weiß nicht. Möglicherweise sagt er,
ja, wenn du das sagst, dann wird es schon stimmen.
Das ist, lass uns mal drauf ankommen. Jetzt,
bevor ich jetzt weitermache, erzähle ich Ihnen noch ein kleines,
oder mache ich mit Ihnen jetzt noch ein kleines Experiment?
Das Experiment geht so, ich hoffe,
keiner von Ihnen kippt jetzt in Ohnmacht,
wenn ich das Wort Blut in den Mund nehme.
Wir spielen jetzt Folgendes. Ich sage, ich zeige Ihnen
eine Blutprobe. Jetzt träufle ich da was drauf
Und je nachdem, wie das gerinnt,
also ist das Blutgruppe A oder B oder so.
Ich habe noch einen, ich erzähle das jetzt nur ihnen,
ja, nur ihn. Sie hören jetzt bitte mal weg.
Jetzt zeige ich Ihnen das und träufle ich wieder was drauf.
So, das ist jetzt B, nächste Blutprobe,
Teufel fasst drauf, Blutgruppe A, B und so.
So, jetzt nach einer Zeit lang haben Sie das verstanden,
wie das so geht.
Was ich Ihnen nicht erzähle, ist,
ich sage Ihnen immer
die Wahrheit
Und Sie haben das jetzt einfach so verstanden, wie das geht.
So, jetzt komme ich zu Ihnen. Jetzt hören Sie
mal weg. Ich zeige Ihnen also eine Blutprobe,
ich kann das jetzt ein bisschen kürzer machen,
Sie kennen ja die Geschichte schon, aber trotzdem zugehört.
Ich zeige Ihnen jetzt eine Blutprobe, treufel was drauf,
sage, das ist Blutgruppe A. Okay, dann mache ich das wieder.
So, und jetzt passiert bei Ihnen genau dasselbe wie bei denen.
Also so langsam kriegen Sie eine Idee davon,
also so je nachdem, wie das zerläuft.
Also kann ich die Blutgruppe erkennen. Jetzt mache ich was
Gemeines. Das sind diese Psychologen, die sind echt gemeint.
Ich lüge sie manchmal an. Das verrate ich Ihnen
aber nicht
Das wäre ja blöd. Das wäre ja keine Lügen mehr.
So, was passiert jetzt bei Ihnen? Also ich sage Ihnen immer,
dass hier ist also diese Blutgruppe und dann sagen,
dann denken Sie, ich habe es verstanden und ich sage,
nee, ist nicht, das ist was anderes.
Und dann so, jetzt passiert sowas bei Ihnen im Kopf
, so der Rauch kommt so langsam raus.
Sie müssen anfangen, ein etwas komplizierteres Modell zu entwickeln.
Über das Phänomen, wie erkenne ich eine, wie erkenne ich eine Blutprobe?
Das spiele ich jetzt noch eine Zeit lang mit Ihnen und irgendwann,
also sagen wir mal, so kriegen Sie so bei 90,
95 Prozent der Blutproben sind wir uns einig,
was es ist
Jetzt kommt der entscheidende Teil des Experiments.
Ich nehme, sie sind jetzt ungefähr gleich viele.
Ich nehme aus jeder Gruppe, nehme ich jetzt ein,
und sagt dann so, was ist das für eine Blutgruppe?
Und was man dann, statistisch, relevant, nachweisen kann,
ist, es in den Diskussionen zwischen denen und denen,
die da häufiger gewinnen darüber, welche Blutgruppe es wirklich ist,
es wirklich ist.
Wie kann man sich das erklären? Und die naheliegendste Erklärung ist,
Die da haben ein komplizierteres Modell über, also das,
wovon sie reden. Sie... B. So ganz einfach.
Also ein intuitives Verständnis haben sich nicht viel Gedanken darüber gemacht.
Es war ja auch einfach. Sie mussten,
weil ich sie so tückischerweise immer mal wieder angelogen habe,
wenn das so ist, dann ist das vielleicht so,
dann ist es wohl das.
Okay, sie können viel besser darüber reden.
Und jetzt vergucken wir mal, womit wir sie
in Zukunft also beschäftigt sein werden
Sie sind mit Softwareentwicklung beschäftigt und Softwareentwicklung ist wirklich so eins,
das kann ich, glaube ich, echt so formulieren.
Ist eins der letzten Abenteuer. Weil,
wenn wir jetzt bei der Medizin bleiben, ein Mediziner,
der behauptet, ah, okay. Und dann gibt er
jemandem mit Blutgruppe B dieses andere Blut, dann stirbt der Patient.
Friede seiner Asche. Wenn dir das dreimal hintereinander passiert,
überlegst du, vielleicht sollte ich meine Theorie,
welche Blutgruppe es ist, sollte ich die nochmal überdenken.
Ich hoffe, das passiert, dass das Realen im echten Leben
irgendwie anders funktioniert, aber bitte. So, der Architekt,
er kann behaupten, diese Brücke bleibt stehen oder der Bauingenieur.
Und wenn die zusammenfällt, dann fällt die zusammen.
Bei den Softwareentwicklern ist das anders. Wenn sie sagen,
das ist ein adäquates Modell zur Unterstützung der Arbeit von Anwendern,
dann stirbt keiner, das fällt nichts zusammen und sie sind eloquent genug,
um zu sagen, das ist das Modell ihrer Arbeit.
Und nicht das, was so ein armer Benutzer glaubt,
was das Modell seiner Arbeit sei
Hat er sich nämlich nicht überlegt. So,
und jetzt sind wir in diesem Spiel,
das ist also so einer unserer ganz großen aktuellen Altforderen,
Martin Fauler sagt, also diese Ärzte und Bauingenieure,
die haben es im Vergleich zu uns,
haben die es einfach, weil die haben einen natürlichen Feind,
sei es das Blut oder die Schwerkraft oder irgendwas,
was so natürlich ist, wir haben nur uns als Feinde.
Und das ist unnatürlich. Das ist eklig. Das ist,
also Softwareentwicklung hat, also so Gegensatz zur landläufigen Meinung,
hat das ja nichts mit, also nichts ist jetzt auch übertrieben,
hat es weniger mit Mathematik zu tun auch, aber es ist viel,
also von Mensch zu Mensch und dann eben auch,
also der Entwickler hat das,
was man so in der Psychologie, ein Modellmonopol nennt,
darüber, wie Arbeit gestaltet werden soll.
Und deswegen lege ich Ihnen das jetzt auch hier so,
versuche ich mit Herzblut,
Blutgruppe B, habe ich,
glaube ich,
mit Herzblut ans Herz
Wenn Sie also da rangehen und fachliche Aufgaben analysieren,
dann sind Sie diejenigen, deren Pflicht es ist,
in der Sprache der Anwender, sich deren Geschäftsprozesse,
deren Aufgaben zu erschließen, um daraus adäquate, anwendungsorientierte Modelle zu machen.
Dazu zwingt sie ja niemand. Das ist nur etwas,
was ich Ihnen jetzt so nach ein paar Jahren Berufserfahrung auch sagen kann,
dass das also bei der Analyse einzelne Arbeitsplätze bei der Analyse dessen,
was Zwischenarbeitsplätzen passiert, das ist,
was Sie mit Ihrem objektorientierten Gedankengut immer im Hinterkopf haben sollten,
die Prozesse der Anwender und die Gegenstände, die die verwenden,
das ist so der Ausgangspunkt.
So, jetzt gucken wir auf diese Gegenstände,
die also vielleicht so in der Anwendungswelt eine Rolle spielen und dann entdecken wir,
also sowas wie, also mein Lieblingsgegenstand,
also für alle Zeiten, das kann ich, glaube ich,
mittlerweile sagen, das ist natürlich der Ordner.
Ordnung muss sein und dann kann ich,
also mir jetzt auch anschauen, also kann ich auch unterschiedlich da rangehen,
um mal so einen Ordner, um dabei zu bleiben,
zu modellieren, weil ich kann den strukturell nach seinen strukturellen Bestandteilen,
kann ich den beschreiben.
Ich kann mir aber auch anschauen, wie wird dieser Ordner in den Arbeitsprozessen,
die ich beobachte, die ich also mit den Anwendern,
den zukünftigen Anwendern aufnehme, wie wird denn mit dem umgegangen?
Und dann komme ich dazu, dass ich also verschiedene Arten
von Gegenständen mit ihren Sondierenden und verändernden Umgangsformen, dass ich die modellieren kann.
Und das ist jetzt mal so zunächst mal so eine Grundidee,
also Gegenstände, die wir in der, also realen Das sollte ich eigentlich nicht sagen.
Also so in der physikalisch vorhandenen Welt, also entdecken,
dass die so eine gute Ausgangslage sind,
um so immer wieder mal Alan K. im Hinterkopf,
um so eine Ausgangsbasis dafür zu finden, wie ein,
also aus welchen Elementen einen zukünftigen, ein zukünftiges Anwendungssystem bestehen könnte.
Und das hat, jetzt habe ich gesagt, so in
der realen Welt, also so diese physikalisch vorhandene Welt.
Also ich meine, wir haben alle schon mal sowas,
wenn ich da dieses Dollarsymbol hinmale,
dann hatten wir zwar alle schon mal so eine Dollar Note nicht alle,
aber viele von uns schon mal so ein Dollar.
Da kann ja auch ein Euro sein in der Hand,
die, das macht auch keinen Unterschied eigentlich,
aber das ist so die,
ob das Zeug jetzt tatsächlich physikalisch vorhanden ist oder ob es nur so eine Idee ist, ein Konzept, über das wir sprechen.
Es gibt immer diese Ebene von, ich kann beschreiben,
wie damit im Arbeitsalltag umgegangen ist und anders,
also unser Standardbeispiel, das Konto,
keiner von uns hat jemals ein Konto gesehen
Nie. Trotzdem weiß jeder von uns, wie mit einem Konto
umgegangen werden muss. Und insofern ist diese symbolische Schicht,
die legen wir auch über diese ganzen Gegenstände, die sind dann insofern sogar tückischer,
weil scheinbar ist das klar, wie damit umgegangen wird.
Aber dieser Schein trügt an vielen Stellen. So,
jetzt kommen wir zum objektorientierten Bibliothekssystem und sie sehen also ganz viele Gegenstände,
mit denen umgegangen wird und so jetzt eine Herangehensweise,
die ich ihnen auch nicht empfehle, ist,
also so am Eingang der Bibliothek sich aufzustellen und alle Gegenstände aufzusammeln und sie dann Objekt orientiert zu beschreiben,
das ist keine gute Idee.
Viel besser ist die Idee, sich zu überlegen,
welche Aufgaben werden in einer Bibliothek eigentlich erledigt und der Begriff der Aufgabe,
der wird sie, also mindestens diese Vorlesung wird er sie noch,
also verfolgen bis in den Schlaf hinein.
Die Aufgabe ist ja, laut Duden das Ziel oder
die Pflicht, die ein Mensch vor sich sieht.
Das heißt also, der Zusammenhang zwischen Aufgabe und Menschen
wollen also Arbeiten erledigen und mit bei der Erledigung verwenden sie Gegenstände.
Das ist die eine Fragestellung und die andere Fragestellung ist,
und jetzt schauen wir uns an,
welche Aufgaben sollen eigentlich durch dieses dieses Anwendungs- und Anwendungssystem,
das sie zu programmieren haben, welche Aufgaben davon sollen unterstützt werden.
Und jetzt kommen die... So, so. Das war also
das Ergebnis der Method Wars. Die müssen sich ganz schön behakt haben.
Dieses Symbol wird sie den Rest ihres Berufslebens begleiten.
Nehme ich jedenfalls mal an. Das ist das Akteurssymbol der Unified Moteling Language.
Warum das also listisch nicht so aufwendig gestaltet worden ist.
Es hängt damit zusammen, dass das früher auch noch
viele Nadeldrucker gab und Druckbarkeit, war ein Kriterium.
Also es hat keine wesentlichen ästhetischen Gesichtspunkte. So,
einer der Diagrammtypen, der Unified Modeling Language, ist das sogenannte Use-Case-Diagramm.
Auf Deutsch heißt Use-Case Anwendungsfall. Und die erste Frage,
die bei einer Objektorientierten, bei einer Anwendungsorientierten Analyse gestellt wird,
ist, wer ist an welchen Aufgaben beteiligt?
In unserem Fall Wer tut was, mit wem in der
Bibliothek und so auf der obersten Ebene sehen wir also,
das ist ja jetzt auch schon eine Form, also der Modellierung. Wahrscheinlich wird,
sollte das jetzt nicht so beurteilen, aber so das,
was möglicherweise bei einer Befragung, der in der Bibliothek beschäftigten Menschen,
der Benutzer, rauskommt, ist,
wir unterscheiden grundsätzlich zwei Arten von Prozessen, nämlich die,
die mit der Beschaffung von, ich sag mal,
Zeug in der Bibliothek zu tun hat und mit dem den Prozessen,
die mit der Verwaltung, sprich also dem Ausleihen,
zu tun hat.
Und was wir unterscheiden können,
ist, der Bibliothekar redet mit dem Lieferanten darüber,
was beschafft werden soll und der Bibliothekar redet mit dem Benutzer darüber.
Also wie das denn jetzt nur geht, etwas vorzubestellen, etwas auszuleihen.
Sie sehen das hier. Das sind die Teilprozesse,
in denen also Bibliothekar und Benutzer miteinander beschäftigt sind.
So, jetzt habe ich Ihnen dieses schöne Blutgruppenbeispiel.
Ich hoffe jedenfalls. Schöne Blutgruppenbeispiel gesagt. Das ist schon vergleichsweise grenzwertig,
weil Es ist an der Stelle,
soweit wie ich Ihnen das jetzt hier auch erzählt habe,
ist schon unklar, was bedeuten eigentlich, also diese Pfeile,
bedeuten die etwas oder ist das jetzt auf der Ebene von,
hängt irgendwie zusammen mit, was vergleichsweise schwache Semantik wäre.
Nun, das ist also so jetzt unter uns,
die wir also gewohnt sind mit solchen formalen Modellen umzugehen,
denke ich, liest sich das,
also wie eine Zeitung mit großen Buchstaben, das,
was das aussagt, ist,
sowohl Bibliothekar als auch Benutzer sind bei all diesen Subprozessen bei diesen Teilaufgaben,
sind sie beteiligt.
Und in einem nächsten Schritt müsste man sich jetzt anschauen,
also wenn man diese Arbeitsprozesse wirklich aufnehmen möchte,
wenn man die wirklich analysieren möchte,
wie geht denn das, ein Buch vorzubestellen?
Welche Gegenstände sind daran beteiligt? Welche Aufgaben werden mit diesen Gegenständen durchgeführt,
um eine Vorbestellung durchzuführen? Für den Moment können wir jetzt einfach erstmal so behalten,
anwendungsorientierte Modellierung bedeutet, ich will, also eigentlich diese W-Fragen,
will ich beantwortet bekommen, wer tut was, mit wem, wozu, womit.
Wenn ich das, wenn ich das verstanden habe,
dann, so bin ich schon mal einen großen Schritt weiter,
weil ich habe unter anderem,
habe ich das in der Frage, also mit der Frage,
womit habe ich auch schon mal so ein Stück weit,
bin ich in die Richtung gegangen,
dass ich so in einem Begriffsmodell aufgesammelt habe,
welche Gegenstände spielen eigentlich eine Rolle,
wenn ich solche Geschäftsprozesse,
wenn ich
solche Geschäftsprozesse erhebe
Die Behauptung, die hier steht,
die es sogar war, also ich habe aus,
während ich also mit dem Bibliothekar darüber gesprochen habe oder auch mit Benutzern der Bibliothek darüber gesprochen habe,
was tut ihr, wenn ihr mit der Bibliothek zu tun habt,
dann habe ich also solche Begriffe aufgesammelt wie Buch oder der technische Report oder Zeitschrift.
Und möglicherweise hat mir auch irgendjemand, wir haben ja schon über objektorientierte Programmierung,
das Konzept der Vererbung, haben wir auch schon gesprochen,
möglicherweise haben auch die Bibliothekare ihnen, Begrifflichkeit des Sammelgutes nahegebracht.
Und dann können Sie ja jetzt,
und das ist so eine Form des Dialogs,
die gar nicht so unüblich ist, so wenn das solche,
ich habe das ja auch damals, als ich über Vererbung,
als dass ich Vererbung motiviert habe, so drüber gesprochen,
dass die dann schon so darüber sprechen, ja, ja,
wir verwenden also sowas wie Ausleihkarten bei uns in der Bibliothek,
um festzuhalten, was ist ausgeliehen, was muss gemahnt werden.
Und das, wozu halt Ausleihkarten gut sind, Achtung,
wozu die gut sind. Und auf jeder Ausleihkarte kann ich sehen,
wer hat denn dieses Sammelgut gerade ausgeliehen, nämlich ich brauche sowas wie einen Benutzer.
So, und so entstehen diese bei einer anwendungsorientierten Analyse,
ich will nicht behaupten, dass diese Begrifflichkeiten oder dass diese Zusammenhänge dann auf der Straße liegen.
Aber das ist dann ihre Aufgabe im Rahmen einer aufgabenorientierten,
anwendungsorientierten Analyse aus den Geschäftsprozessen, die Beziehung zwischen den Gegenständen herzustellen,
die bei der Aufgabenerledigung verwendet werden.
So, und dann kommen sie halt möglicherweise dazu,
in einem weiteren Schritt, das kann doch,
ich will nicht sagen, dass die so sequenziell hintereinander sind,
aber während sie solche Begriffshierarchien modellieren.
Das Sammelgut. Was kann ich denn damit tun? Und wenn jetzt ein,
dann haben wir ja auch gelernt, Ober- und Unterbegriff,
unterscheiden sich in der Regel dadurch, also der Oberbegriff mit dem,
lege ich fest, was man mit allen seinen Unterbegriffen tun kann.
Also das Buch, das kann ich ausleihen, zurückgeben, mal einen verlängerten vorbestellen.
Und das gilt eben dann auch für den technischen Report und die Zeitschrift,
weil das im Begriffsverständnis eben Unterbegriffe des gemeinsamen Oberbegriffes Sammelgut sind.
Die Diskussion darüber, wir sehen hier noch,
die Attribute sind notiert, dienen aber nicht der Klassifikation.
Das, was für die Klassifikation entscheidend ist,
in einem solchen Modellierungsprozess, ist, dass die Umgangsform,
sprich also die öffentlich sichtbaren Operationen an einer Klasse, dass die gemeinsam sind.
Das ist für die Klassifikation spielen die Attribute, sprich also die Datenfelder,
die Private oder Protected sind, spielen dabei keine Rolle.
So, und so geht das dann weiter. Hier steht jetzt also auch das,
jetzt hat man also so einen ursprünglichen Entwurf mal gemacht und ob der tragfähig ist,
das kann man eben, Das weiß man in dem Moment,
in dem man eben gemacht hat,
weiß man das natürlich nicht.
So ein Zeichen für die Tragfähigkeit oder dann eben auch die,
wie sagt man, Tragunfähigkeit oder Untragfähigkeit eines solchen Entwurfes ist,
jetzt kommt jemand daher und sagt,
also wir wollen eben auch DVDs ausleihen in der Bibliothek verwenden können.
Und dann ist eben die Frage,
ob also so eine DVD auch als Sammel gut klassifizierbar ist
oder ob man dann an seiner,
bis dahin gebildeten Struktur
etwas verändern muss
Ein Mittel um einen tragfähigen Entwurf herzustellen, ist die Aufgabenorientierte Analyse.
Also die Fragestellung, wie werden die Gegenstände im Beruf im Arbeitsalltag verwendet,
um dann über die Ebene der Umgangsformen zu sehen, wo können sich solche Gemeinsamkeiten herausbilden.
Und das ist jetzt so, man sieht ja diesen Vererbungsdiagramm auch keine Reihenfolge der Entstehung mehr an. Aber das erfahrungsgemäß ist es viel tragfähiger bei den Blättern,
also das, was sich jetzt als Blätter des Vererbungsbaums darstellt,
bei den Blättern anzufangen und zu sagen, naja gut,
es gibt also tatsächlich Zeitschriften,
die sich halt nicht anfassen und dasselbe gilt auch für alle die Konzepte,
die hier auf dieser Ebene sind,
um dann zu fragen, was haben die denn gemeinsam,
statt umgekehrt ranzugehen, ich überlege mir jetzt mal,
was man mit einem Sammelgut tun kann, um dann daraus zu schließen,
passt Buch, also als Unterbegriff zu diesem Oberbegriff,
also erst die Verwendung und dann die Wiederverwendung,
das ist eigentlich so von der Sprachbildung ja auch naheliegend,
erst verwendbare Konzepte modellieren, um dann zu schauen,
also wo gibt es Anteile,
die wiederverwendet werden können.
So, jetzt haben wir die Ebene,
so Gegenstände können modelliert werden. Und das ist schon mal,
also es ist ein guter Anfang, ist,
wie sie sich aber mit Blick auf die Uhr vorstellen können,
doch nicht das Ende der Geschichte.
Ich führe jetzt so noch ein weiteres Konzept ein,
das uns helfen wird, Anwendungssysteme und ihren Blick auf die
Welt der Arbeit in solchen Aufgabenorientierten zusammenhängen.
Ihren Blick auf diese Welt zu strukturieren können. Und das
ist das Konzept der Wurfsmetapher. So, da stecken jetzt
zwei Begriffe drin. Der hintere Begriff ist die,
ist der der Metapher, die ja bekanntlich ein bildhafter Vergleich ist.
Wo gibt es denn Metaphern im Umgang mit den Geräten, die sie da verwenden?
Da sehe ich ein Apple-Symbol, das macht eigentlich auch keinen Unterschied.
Auch auf Windows rechnen hat die Metaphorik des Mülleimers Einzug gefunden.
Er ist natürlich kein Mülleimer in ihrem System, oder?
Nee, aber sie wissen, wie man mit einem Mülleimer umgeht.
Dass das nicht selbstverständlich ist, Wer von Ihnen kennt noch Atari-Computer?
Ein paar, okay. Das war damals,
jetzt kommen wir der Geschichten von früher, als die,
als es noch offen war, welches System sich durchsetzen würde,
gab es also so, so wie heute Windows und Max,
gab es halt also so viele Leute,
die hatten Max und viele Leute, die hatten Ataris.
Und dann, ich hatte also ein Mac, weiß auch nicht mehr warum.
Und ich war es gewohnt, ein Dokument in den Papierkorb
zu schieben Und irgendwann fiel mir halt auf,
ach Gott, das brauche ich doch noch mal,
dann habe ich es aus dem Papierkorb wieder rausgeholt.
Weil ich wusste ja, also bevor ich nicht sage,
Papierkorb entleeren, ist das da noch drin.
Und dann habe ich irgendwann mal, also war mein Mac nicht da oder so.
Und dann habe ich mich mal an einen Atari gesetzt.
Und so in dieser Art und Weise damit gearbeitet.
Das Dokument in den Papierkorb getan. Und dann, ich
brauche das doch noch mal. Und es war weg. So,
das ist für mich, das war keine böse Absicht,
aber das, was ich für mich dann als tückisch herausgestellt hat,
ist, dass das Papierkorbsymbol im Atari war ein Schredder
Das heißt, er hat es also gleich vernichtet.
Das kann man ja machen. Man muss es nur wissen
. Und insofern ist also so, die Metaphern,
die also in diesen, gerade in diesen Desktop-Systemen verwendet werden,
sind eine unheimlich tragfähige und kurzsprachige, effiziente Form der Darstellung,
wie kann ich handlungssicher scheinbar handlungssicher an manchen Stellen.
Also wie kann ich damit umgehen? Welche Effekte kann ich damit erzielen?
Und sie werden jetzt auch noch so im Verlauf ihres Studiums,
werden sie so ganz verschiedene Ansätze Softwareentwicklung kennenlernen,
unter anderem auch noch so was wie,
also so Vorgehensmodelle wie Extreme Programming oder Scrum.
Und die legen ihnen mehr oder weniger nahe,
dass sie bei ihrem System entwürfen, tragfähige Metaphern verwenden,
weil Metaphern so ein unheimlich effizientes Sprachmittel sind.
Und wenn sie in ihre Softwaresysteme Metaphern nachvollziehbar so hineinmodellieren,
dann erhöht es die Chance,
dass ihre Anwender mit diesen Systemen schnell und sicher umgehen können.
Und die Entwurfsmetaphern, die wir hier im Wesentlichen verwenden werden,
sind die das Werkzeug und Materialansatzes, das ist kurz wam.
Ich werde auch noch das Geheimnis lüften,
warum der Werkzeug und Materialansatz nicht Wumm-Ansatz heißt, sondern Wann-Ansatz.
Die, die wir verwenden, sind halt, also das,
was wir hier kennenlernen werden, ist im Wesentlichen Werkzeug und Material.
Das heißt, die Idee, unsere Anwender sollen Alan Kay lässt grüßen,
Materialien auf dem Rechner wiederentdecken können,
mit denen sie unter Verwendung von Werkzeugen arbeiten können.
Das sind so die Entwurfsmetametaphorik, die jetzt diesen interaktiven Anwendungssystem,
mit denen wir uns im Rahmen dieser Vorlesung beschäftigen,
die Entwurfsmetaphern, die so stilbildend sind.
So, jetzt stand auf der letzten Folie auch,
es gibt immer auch eine konstruktive Wendung. Weil das eine ist ja,
ich kann ein Stück Software, kann ich dadurch erklären,
dass ich dem Anwender sage,
da ist ein Behälter und dieser Behälter,
das ist so was Materialalziges und den kannst du aufmachen und
dann kannst du was reintun und dann ist es in dem
Behälter drin
Solange du das nicht wieder rausholst, bleibt es auch da drin.
Das kann man ja verstehen, weil sich diese Metaphorik des Behälters,
dass sich die bei der Gestaltung,
also ein spezieller Behälter ist dann eben der Mülleimer,
dass ich einem anwender auf der Ebene erklären kann,
so wie er sich ein nachvollziehbares Benutzungsmodell machen kann über das,
was ich ihm implementiere.
Das andere, das, was jetzt die,
was damit gleichzeitig mit dem Konzept der Entwurfsmetapher verbunden ist,
ist, Naja, ich bin ja Softwareentwickler.
Ist ja gut und schön, wenn ich das dem Anwender erklären kann.
Und jetzt kommt die Strukturähnlichkeit von vorhin wieder. Ich möchte
auch Software-Materialien und Software-Werkzeuge in meiner, in meinem Code identifizieren können.
Und jetzt kommt, wird das Bild für Sie hoffentlich langsam runter.
Arbeitsgegenstände, die ich entdecke, kriegen also eine durch Entwurfsmetapher,
in diesem Fall, also Materialien, kriegen die ihren Widerpart in Software.
Ich möchte, ich möchte, dass Sie Software, Materialien implementieren.
Und diese Softwarematerialien haben als Ausgangspunkt häufiger Materialien,
die im Anwendungsbereich, im Gegenstandsbereich vorhanden sind,
als das, also haben das häufiger, Punkt.
So anders ist es bei Werkzeugen. So,
das war hier so eine Definition, Gegenstände, mit denen
Menschen im Rahmen einer Aufgabe und Materialien verändern oder sondieren.
Aha. Also nehme ich mal so als Material
ein Stück Papier und als Werkzeug nehme ich den Bleistift.
Jetzt werden sie, so nehmen wir mal sowas
wie Word
Das ist ja die Papier-DNA4-Idee,
also die luked da ja auch an jeder Stelle raus.
So bloß, also so ein Bleistift finden Sie, also kaum irgendwo.
Sie finden doch keine Kugelschreiber oder sonst irgendwas.
Die Werkzeuge sind häufig so Abbildungen von, oder sind häufig die Art,
wie ein Werkzeug gestaltet wird, ist eher davon abhängig,
was sind die wiederkehrenden Arbeitshandlungen an den Gegenständen.
Und wenn die wiederkehrende Arbeitshandlung an einem Stück Papier ist,
es zu beschriften,
dann muss ich mir halt so das elektronische Äquivalent
eines Schreibers erfinden
Und das ist dann eben über die Tastatur möglich, was völlig anderes ist,
als also das, was man so in der analogen Welt ist.
Aber die Idee, so der wiederkehrenden Arbeitshandlung an Materialien,
die ist häufig grundlegend für also die Erfindung von Werkzeug.
Also insbesondere dann eben Softwarewerkzeug, was jetzt so für sie vorhanden ist,
ist so eine Idee, interaktive Anwendungssoftware, die kann ich hoffentlich,
also ich hoffe, dass sie diesen Gedanken haben,
es sollte uns, wenn es darum geht,
Menschen bei der Erledigung ihrer Aufgaben zu unterstützen, eine Möglichkeit geben.
Ich schaue, welche Gegenstände verwenden die.
Wie werden die bearbeitet? Welches Werkzeug muss ich erfinden,
um eine glatte, glatte Erledigung dieser Aufgaben zu ermöglichen? So,
ein Beispiel, dass ich Ihnen, also ich habe angefangen,
habe ich mit Schiffen und ich höre jetzt also diesen Teil der Vorlesung auch auf mit Schiffen,
so ein System, dass wir dessen Konstruktion,
wir begleiten, wir begleitet haben,
wird hier in Hamburg bei der Hamburg Port Athority eingesetzt.
Es ist der sogenannte Port Monitor
Und was man, was sie hier sehen, ist ja so
ein Ausschnitt des, ein Ausschnitt der schönsten Stadt der Welt.
Was ist denn das eigentlich? Das ist doch der, also,
dass das die Cap San Diego, könnte sein, ne?
Ja, muss aber nicht. Wie dem auch sei, jedenfalls da am Hafen. Und das,
was die da im Hafen tun, also soweit wie ich da reinschaue,
also die Nautiker, da kommt, also dieses ganz,
ganz große Containerschiff und dann müssen die gucken, Wie parke ich das denn ein?
So das, was die tatsächlich tun,
weil das also ein sehr effizientes Mittel ist,
die haben so kleine Schiffsmodelle und mit diesen Schiffsmodellen,
also simulieren die dann, also die Fahrtbewegungen,
die das Schiff dann zu einem bestimmten Zeitpunkt mit einem bestimmten Tiedenhub,
wo kann es hinfahren, also wo ist gerade eine Baustelle,
so damit die lotsen, klare Anweisungen kriegen.
Und das ist ja, als ich die Geschichte gehört habe,
da ging bei mir ja dann so richtig so der Pufflove-Shirt-Reflex los,
das sind Materialien, Arbeitsgegenstände.
Und jetzt gucke ich doch mal, wie müsste ein Softwarewerkzeug
aussehen, die in ihrer Arbeit also besser unterstützt werden.
Weil ich möchte jetzt auch dann mal so Simulationen, Achtung, Alan Kay, durchführen können. Also wenn ich diese Baustelle da jetzt,
also im Zeitraum tee minus 1, themen minus 0,5,
wenn ich die da hinbaue,
welche Auswirkungen hat das denn dann eigentlich auf die Möglichkeit,
Schiffe zu rangieren, so mit einem Vorlauf von, ich weiß ja,
welche Schiffe kommen, dann kann ich mit der Werkzeugmaterialmetaphorik,
kann ich also wunderbar deren Arbeitsprozesse auch auf einer IT-technischen Ebene so unterstützen,
dass also die Handlungssicherheit, was einen extrem hohes Gut im Hafen ist,
Um ein IT-System so zu konstruieren,
dass die Handlung diese Sicherheit der beteiligten Akteure erhalten bleibt.
Wenn nicht sogar erhöht wird. So, also so ist diese Grundidee,
die lässt sich nicht nur an so etwas wie dem Bibliotheksystem,
sondern auch, also in solchen Kontexten und eigentlich fast allen Kontexten,
wo es um interaktive Anwendungssoftware geht, lässt sich diese Grundidee anwenden.
Wobei, eine weitere Interpretation von Wamm,
Da hatten wir mal Peter Wegener zu Besuch in Hamburg,
Peter Wegener, ist derjenige,
der objektorientierte Programmierung mal so im Konzert der Programmierparadigmen eingeordnet hat,
also auch so ein Big Shut in dieser ganzen Szene.
Und dem haben wir dann mal Wamm erläutert,
also in Werkzeugautomat, Materialansatz und schaute uns daran und sagte,
ich weiß, wofür Wamm steht.
Wamm ist ein Weltanschauungsmodell, clever.
Wirklich clever,
der Typ
Und das stimmt. So das, wozu ich sie einlade
mit diesem Konzept der Entwurfsmetaphern, setzen sie doch mal,
wenn sie ein Stück Anwendungssoftware schreiben sollen, stecken sie mal die Wammbrille.
Setzen sie mal die Wammbrille auf und fragen sich,
wo kann ich denn Materialien entdecken?
Mit welchen Werkzeugen könnten diese Materialien bearbeitet werden? So das Anwende,
diese Werkzeuge in die Hand nehmen und die Materialien verändern und sondieren.
Ich will Ihnen nicht sagen, dass die Welt so ist,
um Gottes Willen, was ich Ihnen sagen möchte,
ist, ich gebe Ich gebe Ihnen hiermit die Möglichkeit,
sich auch die Welt mal durch diese Brille anzuschauen und zu überlegen,
ob das nicht eine sinnvolle Herangehensweise ist, um Arbeitsprozesse mit IT zu unterstützen.
Der zweite Teil der Vorlesung geht jetzt darum,
jetzt wissen wir das alles,
so hat er die Wammbrille aufgesetzt und ich weiß,
also hier sind ein paar Werkzeuge, da sind ein paar Materialien,
Werkzeuge, Bearbeiten, Materialien, Materialien werden von Werkzeugen bearbeitet.
Jetzt muss ich es realisieren. Und wir werden im Rahmen von SE2
nicht mit dieser Art von Brille durch die Gegend laufen und wir beschäftigen auch nicht mit dieser Anfang-Aufgabenstellung,
obwohl ich ständig merke, dass es fred in den Fingern juckt,
sich auch mit Number Crunching zu beschäftigen,
aber dafür ist der Wamm-Ansatz so nicht geeignet.
Wir beschäftigen uns mit interaktiven Anwendungssystemen, die sind dadurch gekennzeichnet,
dass sie eine grafische Benutzungsoberfläche haben, eine grafische Benutzungsschnittstelle und das,
was ich Ihnen verspreche, ist, dass sie am Ende dieses Emesters wissen,
wie man solche interaktiven Software-Systeme bauen kann und welche Mittel dafür zur Verfügung stehen.
So, bei diesen interaktiven Anwendungssystemen unterscheiden wir grundsätzlich zwei Arten von Benutzungsoberflächen. Die heißen,
politisch korrekt, Rich und Finn Clients, die heißen nicht Rich und Pur Clients,
sondern das sind Rich Clients, das sind die Systeme,
die laufen typischerweise auf einem Desktop oder auf einem Laptop,
wo die Verarbeitung, also dass die eigentliche Ressingleistung durch das Gerät erbracht wird,
auf dem diese Software auch läuft.
Demgegenüber gibt es, also alles, was so im,
also typischer, nicht typischerweise, also alles, was in Browsern läuft,
das sind die Sin-Clients, weil da wird die eigentliche Verarbeitung,
die eigentliche Rechenleistung, wird nicht auf dem Rechner erbracht,
auf dem also diese Software grafisch repräsentiert wird,
sondern wird auf einem entfernten Rechner erbracht.
Also typischerweise dann auf etwas, was als Webserver oder allgemeiner als Server bezeichnet wird.
Jetzt ist die nächste Frage, womit beschäftigen wir uns hier?
Und da gibt es eine ganz einfache Antwort, darauf,
wir beschäftigen uns hier im Rahmen der Vorlesung mit Dest,
mit der Konstruktion von Oberflächen für Desktop-Systeme.
Und warum tun wir das, weil es schwieriger ist?
Wenn Sie das können, dann können Sie die anderen Systeme auch programmieren.
Also wir bohren lieber gleich das dicke Brett,
dann ist die Implementierung von Weboberflächen, ist dann für Sie eine Art von Analogieschluss.
Insofern, also werden Sie bis zum Ende des Semesters,
werden Sie Desktop-Topses, die Konstruktion von Desktop-Systemen, Bridge Clients werden Sie verinnerlicht haben.
Jetzt steht hier noch so der letzte Satz,
der Abnäher sollte sich noch kurz was zu sagen
Wir werden in anderen Lehrveranstaltungen, so werden wir auch über Kriterien sprechen, an welchen Stellen eignen sich besser Rich-Client-Systeme, an welchen Stellen eignen sie sich besser, Fin-Client-Systeme. Da ist schon was dran,
aber dass diese Grenzen verschwimmen, und das war also,
sagen wir mal, so vor zehn Jahren,
gab es also glasklare Sätze von Kriterien,
nach denen man also nicht entscheiden konnte, aber die einem geholfen haben,
diese Entscheidung zu treffen zwischen Rich oder Fin-Client, in dem Moment,
in dem der Browser sich mehr und mehr zum Betriebssystem entwickelt,
so verschwinden auf diese Grenzen und die Realität Reaktivität von Finn Kleins,
was lange Zeit ein Problem gewesen ist,
ist also auch mit allem,
was mit sogenannter Ajax-Technologie zu tun hat,
so diese Beschränkungen entfallen immer mehr.
Aber wie gesagt, damit beschäftigen wir uns später.
Jetzt nur noch mal kurz ein paar Beispiele,
so was so des Top-Rich-Clients sind Beispiele für Thing-Clients.
Wir beschäftigen uns hier nur mit dieser Art,
also wenn sie die Konstruktionsprinzipien, die sich damit verbunden sind,
wenn sie die verinnerlicht haben, dann denke ich,
können sie auch Arten von Anwendungen schreiben,
die so auf die Browser basiert sind.
Das ist eine sehr generelle Aussage,
das bringt auch seine eigenen Unwägbarkeiten mit sich,
aber das sind eigentlich so die Unwägbarkeiten des Alltags,
die da eine Rolle spielt.
Das ist technisch ist das eigentlich einerlei. So, Qualität,
ja, Tröppchen vor Tröppchen. Wir haben schon häufiger darauf,
also ich wir schon an verschiedenen Stellen darauf hingewiesen,
Wenn es denn die Randbedingungen ihres Projektalltags erlauben,
geht es darum, hochwertige, qualitativ hochwertige Software zu schreiben.
Zwei Qualitätsbegriffe, also zwei Argu von Qualität, denke ich,
spielen dabei eine Rolle. Das eine ist äußere Produktqualität,
also das, was so für den Anwender an Funktionalität Zuverlässigkeit, Robustheit eine Rolle spielt.
Und wir haben also zum Beispiel so im Rahmen des Vertragsmodells,
also als über das Vertragsmodell gesprochen haben, schon so das ein oder andere Mittel kennengelernt,
um diese Art von Qualität erreichen zu können.
Das zweite, Die zweite Art von Qualität,
innere Qualität oder innere Produktqualität, so das,
was also die Weiterentwickelbarkeit, Verständlichkeit, Wartbarkeit, das,
was sie hier sehen, eines Stück Softwares ausmacht.
So, die dritte Art von Qualität, die Prozessqualität,
das ist etwas, womit wir uns jetzt heute schon so ein klein wenig beschäftigt haben.
Die dritte Art von Qualität wird sich, und das machen wir,
damit mache ich dann jetzt aber auch den Deckel drauf,
auf dieser Prozessqualität, beschäftigt sich damit,
wie muss ein Entwicklungsprozess gestaltet sein, um zwei,
um diese beiden Qualitätsarten, äußere und innere Qualität erreichen zu können.
Das hat unter anderem damit zu tun,
mit einem Effekt, der ist vergleichsweise spät beschrieben worden,
nämlich so von einem anderen ganz großen, altvorderen David Parners.
Er ist 1994, hat er das Phänomen beschrieben, dass Software-Aging, Software altert.
Wie kann das sein? Software altert. Na gut,
das ist eine Form von Metaphorik, die er hier gewählt hat. Das,
was Dave Parners in diesem Artikel beschreibt, ist,
Ja, wir entwickeln ein Stück Software und das entwickeln wir
für über einen längeren Zeitraum für einen bestimmten Kontext,
in dem diese Software dann eingesetzt wird.
In dem Moment, dass ich verkürze die Geschichte jetzt ein bisschen,
in dem Moment, in dem diese Software ausgeliefert wird,
wenn sie denn ausgeliefert wird, sagen wir mal,
wo also der Startknopf gedrückt wird,
hat sie hoffentlich eine Struktur,
innere Qualität,
die dem Problem angemessen ist
Sie soll auch von mir aus eine äußere Qualität haben,
die dem zu lösenden Problemen, die der Aufgabenstellung angemessen ist.
Und was dann passiert ist, es gibt ein Betriebssystem-Update.
Was kann denn noch passieren? Die Datenbank, für das
Ding ursprünglich gebaut worden ist, die existiert nicht mehr.
Es muss eine neue her. Jemand möchte auch,
dass das Ganze über ein Mobiltelefon bedient werden kann
So, jetzt habe ich ausschließlich technische Gründe genannt, die dazu führen,
dass jemand anfängt, ich sage jetzt mal, diese Software weiterzuentwickeln.
Jemand, der aber von mir aus solle,
die interne Struktur dieser Software durchaus gut kennen,
aber diese Software wird jetzt nicht mehr so qualitativ hochwertig weiterentwickelt, in der Regel,
wie das am Anfang der Fall gewesen ist, also in der eigentlichen Entwicklungszeit.
Und jetzt passiert etwas, das werden sie dann auch erleben,
wenn sie auf so ein Stück Software schauen,
dass schon so ein paar Jahre, also diese Art von Änderungen mitgemacht haben,
dass die beteiligten Entwickler ihnen sagen, nach der Frage,
warum ist das so oder so realisiert ist,
die dann sagen, das ist historisch gewachsen.
Ja, das ist ein gutes Argument. Sagen wir mal
ein nachvollziehbares Argument. Ja, wir mussten dann schnell noch
das machen. Und das führt dazu,
dass die strukturelle, die interne Qualität dieser Software,
dass die mit der Zeit schlechter wird.
Und das ist das,
was Dave Paders als Altern bezeichnet
Und das, was er fordert in diesem Artikel,
ist, naja gut, das Ding soll gewartet werden.
Er fordert dann Maßnahmen, die dazu dienlich sind,
die hoffentlich ursprünglich hohe Qualität dieses Stück Software aufrecht zu erhalten.
So, ein Mittel dazu. Und ich habe jetzt gerade,
als ich das so aufgezählt habe,
was sich alles so im Umfeld ändern kann.
Ich habe ja jetzt nur von technischen Änderungen gesprochen.
Was ich natürlich auch ändern kann, ist das fachliche Umfeld,
in dem diese Software eingesetzt wird.
Seien des Gesetzesänderungen
Das Organisatorische Bestimmung, sei es, dass die,
das ist zu Fusionen kommen, zu Übernahmen.
Die Welt da draußen ist ja bunt und vielfältig. Eine Grundidee,
das ist etwas, das sollten sie,
sollten sie sich, also für den Rest ihres Programmiererlebens,
sollten sie sich das, also auf die Fahnen schreiben,
trennen sie Fachlogik und technische Anliegen in ihrem,
in den von ihnen zu schreibenden Softwaresystem.
Weil es ist so sicher, wie das Arm in der Kirche,
dass sich die zugrunde liegende Technologie für ihre Software verändert wird.
Und es ist genauso sicher, dass sich der fachliche Kontext ändern wird.
Bloß die beiden sind relativ unabhängig voneinander. Ich sage jetzt betont,
relativ unabhängig voneinander, es hat schon was miteinander zu tun,
aber die Grundidee ist, das eine implementieren wir hier,
die Fachlogik und den umgebenden technischen Kontext, den implementieren wir woanders.
Und wie sie das machen, das lernen sie dann im Master,
wenn sie sowas Lehrveranstaltungen wie Software, Architecture besuchen.
Nur also noch vielleicht so als kleine Motivation, Das Konzept des Kontos,
das ist ja so, wie alt ist das?
paar hundert Jahre. Das ist einfach, also ziemlich stabil.
Versus, also ich möchte meinen Kontostand unbedingt wieder so vor
zehn Jahren der Fall war, unbedingt auf einem Mobiltelefon.
Da mussten ja auf einmal, mussten alle so Apps haben,
die so mit denen sowas möglich ist,
dass man das auf einem Mobiltelefon abfragt, dass es vergleichsweise neu.
Und so aktuell ist es dann nun auch wieder nicht mehr.
Also die Idee, diese beiden Anliegen, die in jedem Stück Software implementiert sein müssen.
Diese beiden Anliegen voneinander zu trennen, ist ziemlich tragfähig. Das ist jetzt,
also wir werden jetzt so über den Werkzeugmaterialansatz sprechen,
also gerade Materialien, also dass die Gegenstände, die des Anwendungsbereichs,
die also mit der zugrunde liegenden Technik überhaupt nichts zu tun haben,
also mit der das dann nachher realisiert wird.
Da gibt es also Verwandte, Ansätze,
die sich auch, also so mit der Object-oriented Design,
Modellierung beschäftigen, das ist ja das Thema dieser Vorlesung,
die nennen das dann eben Domain-Optics, mehr Innenobjekte oder Geschäftsobjekte.
Das sind verschiedene Leute, die unabhängig voneinander so relativ unabhängig
voneinander auf denselben, auf dieselben Gedanken gekommen sind.
Und deswegen ist also die Idee, glauben wir,
dass so der Stand der Kunst, der Stand der Wissenschaft,
dass Anwendungs-, die Modellierung anwendungsfachlicher Klassen ohne,
ohne dass man die so verunreinigt mit technischen,
mit technischen Randbedingungen.
Diese Idee ist schon nicht schlecht. Demgegenüber die
technischen Klassen. Wozu sind die gut
Aus Sicht der Anwendung, es ist alles Hilfsklassen. Gut,
aber das ist eben, also ohne diese Hilfsklassen geht gar nichts.
Die technischen Aspekte sind hiermals so genannt, so klassisch sind
es eigentlich zwei Aspekte, die dabei berücksichtigt werden müssen.
Das eine ist, ich habe dann also ein tragfähiges Modell
der Anwendungswelt so in Form von Materialien und vielleicht auch weiß ich,
welche Werkzeuge ich brauche, um diese Materialien zu bearbeiten,
aber erstens muss das Zeug an der Oberfläche dargestellt werden.
Das heißt, ich brauche irgendeine Art von,
in der Regel Bibliothek,
mit der ich
die Oberflächen realisiere
Das ist die Oberfläche und ich brauche, um Persistenz zu behandeln.
Sprich, kein Bankmitarbeiter möchte morgens als allererstes alle Kunden
der Bank wieder eintippeln, damit die da sind.
Ich brauche was, um Persistenz, sprich Dauerhaftigkeit zu realisieren.
Das wird typischerweise mit Datenbanken, wird das realisiert. Das sind,
also hier stehen noch so Verteilungsaspekte, das ist dann also
gerade bei realistischen Softwaresystemen die Unterteilung zwischen Client und Server, was wird wo implementiert?
Wie können die miteinander kommunizieren? Ich brauche diese technischen Aspekte,
ich muss mich darum kümmern, aber bitte in einem anderen Paket,
sag ich mal, als das die,
als das Paket, in dem die Gegenstände modelliert werden,
die den fachlichen Kern meiner Applikation bilden.
So, und jetzt sehen Sie, warum,
also ein weiterer Grund, auch Wartungsfragen werden dadurch leichter beantwortbar.
Und es gibt so diese, es gibt so natürlich unterschiedlichste Statistiken,
aber sagen wir mal so, es gibt viele Statistiken,
die sagen so,
was von der Kante,
so 80 Prozent seiner Lebenszeit befindet sich
ein Softwaresystem in der Wartung
Nur 20 Prozent der Zeit, also wird es,
und das kann jetzt manche sagen, 90, andere sagen 70,
aber das ist ein, wohin man auch schaut,
dass ein Programm so das Qualitätsmerkmal Wartbarkeit hat, also spielt im Alltag eine große Rolle.
Unsere Entwurfsregeln gehen jetzt da, werden jetzt,
die ich Ihnen jetzt noch vorstellen werde, die basieren darauf,
dass diese Trennung zwischen Fachlichkeit und Technik,
dass die eingehalten wird und sie nehmen auch Bezug auf die Konzepte,
die ich jetzt also schon eingeführt habe,
nämlich Werkzeug und Material und zwei werde ich Ihnen noch,
obendrauf spendieren, um Anwendungssysteme zu strukturieren.
Die das Motiv dafür, dass wir das jetzt hier so machen,
ist, wir möchten ihren Gestaltungsspielraum verkleinern.
Das hört sich jetzt erst mal an wie, um Gottes Willen,
Freiheit, Forschung von Lehre, Forschung und Lehre, Wissenschaft.
Wo bin ich hier hingeladen? Keine Angst. Ich will
sie nicht so, ich will sie nicht daran hindern,
an den Stellen kreativ zu sein,
wo es Kreativität braucht
Woran ich sie aber hindern möchte,
ist unter dem Deckmantel unter der Flagge der Freiheit an Stellen
Unfug zu machen, wo das einfach nicht hingehört.
Und das, was wir ihnen hier beibringen, ist,
wenn sie so wollen, eine Architektur-Blaupause für die Konstruktion,
objektorientierter Anwendungssoftware. Und was sie aus dieser Blaupause machen,
ob sie da jetzt ein hübsches Werkzeug, ein hässliches Werkzeug,
ein verwendbares Material oder ein unverwendbares Material machen,
Das sei mal ihrer Kreativität an heimgestellt.
Bloß wir machen Ihnen eine Ansage dazu,
wie ein Wohlstrukturiertes, interaktives Anwendungssystem aussehen soll.
Und das sieht so aus und nicht anders.
Solange Sie hier sind, wie heißt es so schön,
solange du deine Füße unter meinem Tisch stehst, werden Software-Systeme so gebaut.
Wenn Sie dann Ihren Bachelor haben, dann können Sie machen,
was Sie wollen. Aber so. Welche Elemente,
welche Elementtypen gibt es in diesem Entwurfsregeln.
Fangen wir mal hier an bei den Materialien. Da sind
wir nämlich von weggekommen. Also damit haben wir angefangen,
realisieren, veränderliche Anwendungsfachliche Gegenstände. Okay, das können wir.
Das ist also das ganz normale Zeug, in Anführungsstrichen.
Klassen, davon Objekte. Ich sage zu jedem Einzelnen
dieser Elementtypen nachher noch was im Detail.
Jetzt erstmal nur der grobe Überblick. Materialien dürfen Fachwerte benutzen
. Da machen wir später noch eine ganze Vorlesung drüber.
Für den Moment
Fred hat ganz am Anfang schon mal,
also ganz am Anfang von SC1 schon mal darüber gesprochen,
es ist keine gute Idee, Geld als Float zu modellieren.
Und es ist auch keine gute Idee, Kontonummern als Intenture zu implementieren oder als dringend.
Die Idee, die mit Fachwerten verbunden ist, geht dahin,
wir möchten in der Lage sein, Elemente des Anwendungsbereichs,
die Anwendungsbereichs, die eine Wertsemantik haben,
auch als Werte in Objektorientierten Programmen implementieren zu können.
Das können wir mit dem normalen Instrumentarium einer Objektorientierten Programmiersprache nicht,
weil die Objekte, die wir von Klassen erzeugen,
haben immer das Charakteristikum, sie sind veränderbar.
Werte sind aber nicht veränderbar. Der Wert 42 bleibt der Wert
42. Und wenn ich 42 plus 3 als Operation aufrufe,
dann ist es der 42 Verzeihung egal
Was da jetzt bei rauskommt, die 42 bleibt die 42.
So, mit dieser Grundidee wollen wir dann auch Werte,
wie Geldbeträge modellieren können. Und das ist so,
wie man das konstruktiv hinkriegt,
das werden wir uns in der Vorlesung über Fachwerte anschauen,
so für unsere Entwurfsregeln gilt, Materialien können Fachwerte benutzen.
Und Materialien können auch andere Materialien benutzen.
Also benutzen im Sinne von Kenntnis
So, jetzt kommen zwei L,
jetzt kommen noch zwei Elementtypen dazu, Services,
bieten Materialübergreifend fachliche Dienstleistungen an die Systemball zur Verfügung steht.
Aha. Was könnte das denn sein? Sagen wir mal
so was wie ein Druckservice. So Druckservice hat man noch gerne.
Da gibt es genau einen von und man weiß genau,
was kann man mit dem machen.
Da steht einmal systemweit zur Verfügung und dann über der regelt
das ganze Drucken. Das ist die Idee eines Services.
Die ist eigentlich ganz einfach, oder
Werkzeug, das ist, ich hatte es schon fachlich darüber gesprochen,
das ist die grafische Benutzungsschnittstelle, die das Interaktive bearbeiten von Materialien ermöglicht.
Das sollte aus dem vorangegangenen, sollte das hoffentlich nachvollziehbar sein.
Wir brauchen so, nach der Methodik,
der wir hier entwickeln, braucht es immer ein Softwarewerkzeug,
das unter Verwendung eines Services sich ein Material besorgt und dann
kann der Benutzer interaktiv dieses Material,
das seinerseits noch also Fachwerte verwenden kann,
um sich selbst
zu implementieren
Kann der Benutzer dieses Material bearbeiten und sondieren?
Das wäre jetzt mal so in einem Satz gesagt,
ist, dass die, sind das erstens die Entwurfselemente,
über die sie verfügen, die und keine anderen.
Und zweitens, wie diese Entwurfelemente miteinander zusammenhängen dürfen.
Und sonst nicht. Wie gesagt, das ist so eine
Blaupause. Das soll sie, sollte ihnen jetzt zunächst mal
einen Orientierungsrahmen geben. Also wie, welche Struktur
interaktive Software haben kann
Hier jetzt der Zusammenhang zu dem, worüber wir letzte Woche gesprochen haben. Wenn,
und das ist ja so, Software im Autor-Kritiker-Zyklus,
Sie schreiben ein Stück Software und die anderen kommen daher und sagen,
also ich muss mir das, ich muss, kann,
will mir das jetzt mal anschauen.
Und das, wozu, also man,
also das ist extrem ineffizient, wenn einem zunächst mal erklärt werden muss,
wie die Paketstruktur und das dahinterliegende Gedankengut eigentlich prinzipiell aussieht.
Deswegen machen wir uns das
ganz einfach
Das, was Sie in Zukunft implementieren, hat diese Struktur.
Dass man sich nicht jedes Mal den Aufwand gönnen muss.
Also das betrifft ja nicht nur uns. Das betrifft ja
auch die Austauschbarkeit, also von Ihnen in Ihren Teams,
dass man sich nicht jedes Mal neu orientieren muss,
wie ist die grundsätzliche Struktur der Anwendungssoftware, die da jemand geschrieben hat.
So, jetzt sehen Sie das da.
Werkzeugmaterial, Service, Fachwert, jeweils ein eigenes Java-Paket.
Und dann bist du also schon mal,
also wenn das so meine Erwartungshaltung ist und die wird erfüllt,
dann habe ich schon mal ein positives Gefühl gegenüber dem,
was Sie
da implementiert haben
Sie sehen dann noch so weitere Hinweise, wie fachlich motivierte Schnittstelle,
aber insbesondere das hier. Vertragsmodell, Vorbedingung, die Verwendung von Vorbedingungen.
Es gibt nach unserer festen Überzeugung kaum ein Mittel,
mit dem sie das, was sie eigentlich programmieren wollten,
besser ausdrücken können, als über den Gedanken,
die Gedanken, die sie sich gemacht haben,
über welche Vorbedingungen gegebenenfalls Nachbedingungen,
hat sich ja darüber gesprochen,
warum Nachbedingungen im Rahmen von SE2
eine untergeordnete Rolle spielen
Über welche Vorbedingungen ihre Operationen verfügen,
um schon mal eine Aussage darüber zu machen,
wie soll diese Klasse verwendet werden,
in welchen Zuständen können sich Objekte dieser Klasse befinden,
in welchen Zuständen können welche Operationen aufgerufen werden,
wenn sie das über das Vertragsmodell ausdrücken,
dann sollte es ihnen auch leicht möglich sein,
es ist nicht nur dann, aber dann insbesondere Testklassen zu schreiben,
die dieses, also die Inten, also die erstens zeigen,
es gibt Es gibt keine anwesenden Fehler.
Wissen können nur die Anwesenheit nicht die Abwesenheit von Fehlern überprüfen.
Also es gibt keine Anwesenden Fehler und wir können die intendierte Verwendung der Klasse,
die getestet wird, über die Testklasse schon mal nachvollziehen.
So, Materialien,
da hatte ich jetzt eigentlich schon am meisten drüber gesprochen,
ausschließlich fachliche Aufgaben kennen ausschließlich andere Materialien und Fachwerte.
Jedes Material ist eine eigene Klasse
Ja, das ist so die, in Bibliotheksystem,
die Beispiele haben sie gesehen, also die ganzen verschiedenen Sammelgüter,
die werden jeweils als eine Klasse implementiert und die Entwurfsregel,
die sich leicht implementieren lässt, ist das,
oder die sich leicht nachvollziehen lässt,
dass Materialien kennen nur andere Materialien und Fachwerte.
So, Fachwerte, das ist das, was ich gerade schon gesagt habe,
nochmal hier in der verschriftlichten Form, Werte sind unveränderlich
Und was wir mit dem Konzept der Fachwerte versuchen, ist die,
also uns zur Verfügung stehende Basismaschine eigentlich zu erweitern, um fachlich motivierte Konzepte.
Das heißt, wenn ich nämlich erstmal in der Lage bin,
also über Säure anwendungsfachlich motivierte Gegenstände wie eine Wert, Entschuldigung,
wie eine ISBN-Nummer zu sprechen, dann erzeugt das ja echt Handlungssicherheit.
Also zwar ein erhebliches Maß an Handlungssicherheit,
weil ich weiß, genau weiß,
wenn ich mal eine ISBN-Nummer als Parameter hier irgendeiner Methode übergebe,
ich brauche mir überhaupt keine Gedanken mehr darüber machen,
ob das Ding
so taktisch korrekt ist
Ob das eine valide ISBN-Nummer ist. Versus, ich übergebe eins dringend und
der Parameter heißt ISBN-Nummer. Dann muss ich also sowohl derjenige,
der diese Methode benutzt, Gedanken darüber machen,
wie viel Aufwand muss ich da reinstecken, dass der andere glaubt,
also ich übergebe ein fachlich korrektes Element eines Werttyps und derjenige,
der aufgerufen wird, muss ich auch Gedanken darüber machen,
das Geisteskind ist derjenige gewesen, der mich aufruft.
Muss ich hier jetzt noch Überprüfungen machen? Und wenn das nicht so gut eingespielte Teams sind,
dann führt das halt dazu, dass Fehler,
sich möglicherweise erst an Stellen zeigen,
also wo sie schon längst so einen Schaden angerichtet haben,
der viel kleiner wäre, gewesen wäre,
wenn man ihn an der Stelle entdeckt hätte,
wo er aufgetreten ist, nämlich dass jemand einfach eine falsche ESBN-Nummer wahrscheinlich eingegeben hat.
Und all diese Fragestellungen oder viele von diesen Fragestellungen lassen sich
durch das Konzept der Fachwerte und nachher bei Websystemen auch Fragen der Sicherheit,
also sowas wie SQL Injection, so eine der beliebtesten Angriffsformen,
also ist tot, keine Gedanken mehr drüber machen,
wenn man so ein Konzept wie Fachwerte implementiert.
Deswegen spendieren wir da auch, also Fred und ich,
Ihnen noch eine ganze Vorlesung zu dem Thema.
So, fachliche Services, vorletzte Elementtyp. So,
hier sehen Sie nur noch so die Kriterien,
nach denen man so einen Service-Service designen kann oder so,
dass man überhaupt auf die Idee kommt,
so etwas wie einen Service in einem Softwaresystem
zu implementieren
Kundenstamm, also eine Kundenverwaltung. Oder von mir aus
auch eine Sammelgutverwaltung, die eine Aussage darüber machen kann,
ob ein bestimmtes Werk in ihr enthalten ist.
Im Prinzip. Und wenn es enthalten ist,
dass man fragen kann, ist es ausleihbar.
Das würde ich doch so als Serviceleistung eines Sammelgut-Services erwarten.
Der Rest sind eigentlich nur noch so, sind so,
nicht mal Arginalien, ist der falsche Begriff.
Aber das, also Reservices lief für Referenzen auf originalen Materialien
nicht auf Kopien
Man sich auch erst mal fragen wahrscheinlich oder fragen Sie sich
jetzt, wow, was soll denn das?
Nur mal so als Beispiel. Ich implementiere jetzt einen Service,
der heißt Aktenschrank. Oder nennen wir ihn dann eben Aktenschrank Service.
Und sie verwenden diesen Service und dann ist die Frage,
die Sie mir stellen, ist,
also ist die Akte Gritzern in dem,
in dir enthalten und ich sage,
Und dann sagen sie, gib mir mal die Akte Gritzern raus.
Dann fragen sie mich nochmal, ist die Akte Gritzern in dir enthalten?
Und dann sage ich, nein. Gut, Handlungssicherheit,
okay. So, jetzt kommt der nächste Services,
können ja dann auch von verschiedenen Menschen verwendet werden,
kommt der Nächste und sagt, ist die Akte Gritzern drin?
Nein. Was jetzt nett wäre, ist,
wenn ihr Aktenservice, wenn der, Achtung,
der einen Aktenausgabeverbleibsnachweis beinhalten würde, für die Akte Gritzern.
Das ist doch schön, oder?
Und so funktionieren Services
Also sie sind von verschiedenen Anwendern von verschiedenen,
also Klienten, sage ich jetzt mal,
sind die benutzbar und die fassen eine Dienstleistung sinnvoll zusammen,
sodass man so Handlungssicherheit darüber gewinnt, wie die Dienstleistung,
die mit diesem Service verbunden sind, wie die realisiert worden sind.
Bei den Originalen Kopien, wenn das jetzt so ein Arbeitszusammenhang ist,
also in dem häufiger, sagen wir mal,
nur lesend auf einen vom Service verwaltetes Material zugegriffen werden muss,
dann könnte man ja auch sagen, okay,
ich gebe die Akte Gritzern raus, ich behalte aber eine Kopie.
Und wenn jetzt nochmal jemand kommt und sagt,
ist die Akte Gritzern da, sage ich, nein,
aber so pragmatisch, ich kann dir eine Kopie geben,
willst du die Kopie haben?
Du sagst, ja, will ich, dann nehme ich die Kopie.
Weil die Kopie kann er dann in den Mülleimer schmeißen oder sich mit demjenigen,
der die Akte hat, darüber einigen,
was denn jetzt als Original zurückgestellt werden können.
Aber das ist so die Art von Handlungsmöglichkeiten erstellen
Deswegen steht hier, also bei uns in SE2 machen wir
uns das Leben einfach. Wir geben nur die Referenzen auf
die Originalmaterialien raus. Und wenn dann nochmal jemand kommt,
ist in ihrem Fall auch eher unwahrscheinlich,
weil sie keine verteilten Software-Systeme schreiben, dann sagt es,
oder wenn ein anderes Werkzeug meinetwegen darauf zugreifen will,
dann sagen sie, nee, ist nicht, ist schon draußen.
So, das konstruktiv aufwendigste, der konstruktiv aufwendigste Elementtyp,
und da werden wir auch noch
eine ganze Vorlesung zu spendieren
Das sind die Werkzeuge. Die Werkzeuge,
die typischerweise aus mehr als einer Klasse bestehen,
also selbst schon in dem kleinen Kontext,
in dem wir uns hier damit beschäftigen, ein Werkzeug wird,
also ist erstmal wohlzu, ist es gut, zur Benutzerinteraktion,
eine fachliche Aufgabe wird damit, wird damit beschrieben,
ein Werkzeug wird konstruktiv aus einer Werkzeugklasse,
also das steht da, ist das implementiert,
was das Werkzeug eigentlich tut und als einer UI-Klasse,
User-Interface-Klasse, in der die grafische Oberfläche implementiert
Also das ist so der Elementtyp Werkzeug, besteht immer mindestens aus diesen beiden Klassen.
Und die benutzt Beziehung zwischen dem Werkzeug und den anderen Elementtypen lässt sich jetzt hier auch genauer festhalten,
nämlich die Werkzeugklasse, kann auf Services, von denen besorgt sie sich,
typischerweise die Materialien, die aus unter anderem aus Fachwerten bestehen,
damit die an der Oberfläche dargestellt und manipuliert werden können.
So sehen, also so sieht diese Konstruktion aus,
So, das hier wird in großer detailtiefe,
wird das also Fred nächste Woche mit Ihnen mal ein kleines Wamm-System,
ein kleines Wamm-System implementieren und dann werden Sie auch nochmal live und direkt,
so wie Sie das kennen, werden Sie feststellen,
wie kommt denn oder werden Sie,
wer dreht Ihnen zeigen,
wie kommt denn ein Werkzeug zu einem Material?
Wie findet diese Zuordnung, in welcher Reihenfolge,
mit welchen Verantwortlichkeiten,
also wie findet das statt
Und wir werden uns dann in zwei Wochen damit beschäftigen oder
ab der Vorlesung in zwei Wochen damit beschäftigen,
wie die grafischen Oberflächen für solche Werkzeuge implementiert werden können.
Und ein Thema wird dabei auch,
also neben Fachwerten eine Rolle spielen,
nämlich welche sogenannten Mikroarchitekturen können wir verwenden,
um große Softwaresysteme noch ein Stückchen weiter zu strukturieren.
So,
meine Namen und Herren
Ich habe jetzt Bergfest. Ich habe nämlich jetzt meine sieben Vorlesungen gehalten.
Sie sind nächste Woche dann dran. Ich komme nächste Woche.
Ich komme nächste Woche. Ich höre nämlich Fred gerne zu.
Dem live beim Denken zuzugucken, finde ich es immer so,
als würde man einem munteren Bergquell zuschauen.
Das ist eine. Das habe ich echt gerne. Dann hoffe ich,
sie kommen nächste Woche zahlreich und gucken Fred beim Denken zu.
Und ich stehe in zwei Wochen wieder her und dann freue
ich mich, wenn sie mir zugucken.