Einen wunderschönen guten Tag, liebe Studierende. Wenn Sie mich hören können,
machen Sie doch mal so. Naja. Muss man das
noch irgendwie lauter machen oder ist das, geht das?
Weil ich höre hier vorne, ich höre mich gut.
Ja, ich rede ja sowieso im Wesentlichen zu mir selbst.
Und ich stelle mich mir mal kurz vor.
Mein Name ist Guido Gritzan
Ich bin ein Vertretungsprofessor am Arbeitsbereich Softwaretechnik und bin wie mir
der freundliche Herr gerade schon sagte, der dritte,
der ihn im Rahmen dieser Veranstaltung, was vorlesen wird.
Ich glaube, wir sehen uns noch zweimal.
Das ist ein Angebot, keine Drohung. Und heute darf
ich Ihnen was erzählen über strukturierung, interaktiver Anwendungssysteme.
Na, das kann ja
heiter werden
So, wir haben dafür anderthalb Stunden Zeit, weiß ich,
extrem gemütlich finde. Was sie nicht wissen, ist,
dass morgen wird der Fachbereich besucht von einer hochgestellten
Hamburger Persönlichkeit und verschiedene Arbeitsbereiche des Fachbereichs dürfen dieser Persönlichkeit,
Forschungsergebnisse präsentieren.
Und wir haben dafür je Arbeitsbereich
150 Sekunden
Da muss jedes Wort sitzen. Diese Pflicht habe ich jetzt im Moment nicht.
Ich kann jetzt hier schön... Ach, Kinder, Strukturierung
, interaktive Anwendungssysteme. Das ist ein Thema. So,
wir gucken uns das in den folgenden Schritten an.
Wer von Ihnen hat seit gestern die Folien runtergeladen?
Wow. Herzlichen Glückwunsch. Ich habe leider keinen Preis für
Sie. Ja, gut, dann eben nicht
Ich stehe immer noch da, ich werde sie nicht nach
der Vorlesung löschen. Was sie dort finden,
ist eine Teilmenge dessen, was ich heute vortragen werde.
Ich habe so ein paar Folien hier noch eingebaut,
die einer näheren wissenschaftlichen Betrachtung nicht standhalten und deswegen auch nicht für,
ach so, da kann ich sie Herrn Videografen,
kann ich sie eigentlich bitten zwischendurch, die Aufnahme zu stoppen?
Ja, ich meine das nämlich heraus,
dass ich da immer anfangen am Ende,
würde sagen, jetzt geht es mal.
Okay, dann stoppen sie jetzt
In den 85 Minuten können sie dann weitermachen. Ich dachte
nur über eine Belohnung für diejenigen nach, die tatsächlich hier hingekommen sind.
So, jetzt haben wir mal Konstruktionsregeln für einfache, interaktive Systeme.
Jetzt wo wir hier bei den Chemikern sind,
die haben es ja im Vergleich zu uns,
also so wenig wie ich von Chemie verstehe,
oder sagen wir, wenn wir bei den Medizinern wären,
wäre es genauso.
Die haben es im Vergleich zu uns Informatikern,
haben die es ja einfacher
Das ist so ein Mediziner,
der kann ja da hingehen und sagen, diese Medizin hilft.
Und das behauptet er dann. Und dann gibt es halt
ein Experiment. Und wenn die Hälfte stirbt, dann hat
er halt gelogen. Oder nicht mehr. Nicht gelogen,
sondern sagen wir mal, die Behauptung wurde falsifiziert.
Versus, so ein Informatiker kann ja da hingehen und sagen,
das hier ist die ultimative Programmiersprache
Es gibt da keinen Gegenbeweis in dem Sinne,
wie ich den gerade so zitiert habe oder bei den Chemikern,
irgendwas ist total ätzend und jemand behauptet, das sei es nicht.
Es lässt sich durch ein Experiment, lässt sich das eben nachweisen.
Und unser Eins steht halt da und muss sich mit diesen
ganzen Klassendiagramme, das kennen Sie schon, nicht wahr?
Handhoch. Danke. Ja, wir kennen uns ja noch nicht so gut.
Deswegen muss ich so ab und zu mal so ein paar
Kontrollfragen stellen. Da kann jetzt jemand daherkommen und sagen,
das ist die wunderbarste Art, mit der man Klassendiagramme notieren kann.
Und dann steht man da, der behauptet das und man selber versteht das nicht.
Und dann passiert sowas. Ihnen ist ja sozusagen die Gnade
der späten Geburt in mehrfacher Hinsicht so zuteil geworden.
Eine Gnade, derer sie sich nicht bewusst sind,
ist, dass sie die sogenannten Methodenkriege,
die haben vor ihrer Geburt oder kurz nach ihrer Geburt, haben die stattgefunden.
Da haben sich so Leute in meinem Alter damals darüber,
also unfassbar in die Haare bekommen, wie man Klassendiagramme malt,
wie man Zustandsdiagramme malt, ob man dafür Rechtecke nimmt,
Quadratte, weiß der Satan, was dann noch so alles in der Diskussion war, dass jetzt alles vorbei.
Der Gedanke, den ich jetzt so versuche,
mit Ihnen innerhalb der nächsten 85 Minuten zu entwickeln, ist,
der Designspielraum, den wir haben, wenn wir große,
interaktive Softwaresysteme entwerfen und implementieren, ist durch nichts begrenzt.
Also keine Natur, die irgendwas dagegen hätte, den hellen Wahn zu implementieren.
Es ist halt durch die Bearbeitungsfähigkeit des Rechners ist es begrenzt.
Und das, was sich hier abspielt. Und das
ist einerseits eine Chance. Andererseits ist es eine Gefahr,
weil Softwareentwickler, das schaue ich jetzt auf sie,
neigen insbesondere in Situationen zu Kreativität, wo es keine Kreativität braucht.
Wir müssen jetzt innerhalb ihres Studiums,
müssen wir so in ein paar Leitplanken zur Kenntnis bringen,
anhand derer sie mit ihren Kolleginnen und Kollegen von der Softwareentwicklungsseite,
aber auch gegenüber ihren Anwendern, so ihre unfassbare Kreativität in geordnete Bahnen lenken.
Und ein Bestandteil dieser Ausbildung liegt heute vor ihnen und deswegen
werden wir also einen großen Teil dieser Vorlesung damit verbringen,
die Konstruktionsregeln für einfache, interaktive Systeme, so ein klein wenig auszuarbeiten.
Zunächst mal, so wir sind ja hier schließlich an einer Hochschule,
ein bisschen Begriffsarbeit, was sind interaktive Softwaresysteme,
häufige Interaktionen mit der, also mit Neudeutsch, den Benutzenden.
Das unterscheidet sich von einer Klasse von Softwaresystemen,
mit denen wir uns, also und sie sich in ihrem
weiteren Studium so gut wie überhaupt nicht beschäftigen werden.
Das sind die technisch eingebetteten Systeme, interaktive Softwaresysteme sind Softwaresysteme,
die sozial eingebettet sind, sozial.
Jetzt nicht im Sinne von sozialpädagogisch, sondern sozial bedeutet,
es ist menschliches Arbeitshandeln, das durch diese Softwaresysteme wahlweise automatisiert
wird oder unterstützt wird.
Das ist so der Gegenstand der weiteren Betrachtung
Ja, wenn die in Arbeitshandeln eingebettet sind,
dann haben diese Systeme heutzutage so gut wie durchgehend eine grafische Benutzungsoberfläche,
also was anderes, findet man eigentlich kaum noch.
Diese Art von Benutzungsoberfläche kann unterschiedlich ausgeprägt sein,
womit wir in Forschungsprojekten heutzutage gerne experimentieren, sind sogenannte Multitouch-Tische,
also Tische, die so die Größe eines Fernsehers haben,
wo dann also verschiedene Leute dran parallel gemeinsam kooperativ arbeiten können,
das ist eine ganz andere Art von so grafischer Datenverarbeitung,
als man das hat, wenn man hier mit, also sowas Desktop-artigem umgeht.
So. Die Systeme, mit denen wir uns hier beschäftigen,
sind also im Gegensatz zu dem, was ich gerade gesagt habe,
also diese technisch eingebetteten Systeme oder auch also die Systeme,
die sie brauchen, wenn sie Fachbereich Chemie lädt nicht dazu ein,
dass sie brauchen, um irgendwelche Moleküle und deren Reaktionen zu berechnen,
sind so vergleichsweise reichen unintensiv.
Es kommt vielmehr darauf an, dass die,
weil sie ein menschliches Arbeitshandeln eingebettet sind, dass sie,
nein, es kommt nicht darauf an,
die Aktivität dieser Systeme besteht im Wesentlichen darin, zu warten.
Wir warten darauf, dass dieses biologische Konstrukt vor der,
das vor der Bildschirm-Oberfläche sitzt,
endlich mal wieder zu einer Aktion sich durchringen kann.
Und die könnte durchaus was anderes sein,
als ständig mit der Maus im Kreis herum zu fahren.
Ich bin ganz froh, dass sich dieses Ding hoffentlich keine
Gedanken darüber macht. Was macht er denn jetzt als nächstes?
So, jetzt, wer von ihnen weiß,
was political correctness ist
Ja, bitte. Das muss ich noch beantworten.
Ja. Nächste Frage. Was ist das? Ja,
dass man mit seiner Art und Weise,
wie man sich gibt, den Normen spricht.
Und ja, das ist eigentlich die Kurzfassung so.
Also einem gewissen Normengrenzwert sein Verhalten anpasst. Einen Normengrenzwert einhält. Aha,
sagt ihr, Kommilitonik gerade. Ja, Ausprägung davon sind,
dass ich sie nicht mehr als Studenten anspreche, sondern als Studierende.
Das ist die geschlechtsneutrale Form und da kein Bias reinzubekommen.
So, früher, bevor also Political Correctness Mode geworden ist,
sprach man von Fettclients und Fin-Clients. Und die Fettclients,
von denen darf man jetzt nicht mehr sprechen,
weil die Organisation der Übergewichtigen sich diskriminiert gefühlt hat.
Deswegen heißen die heute Rich Clients. Die anderen heißen deswegen
nicht pur Clients, das sind immer noch die Fin-Clients.
Scheinbar hat also die, also nur so mal zur Genese
dieser Begrifflichkeiten
Also wir unterscheiden im Großen und Ganzen bei diesem grafischen System,
mit denen wir uns im Weiteren beschäftigen werden, zwei Arten.
Dass die eine Art Rich Clients sind diejenigen,
wo jede Menge Verarbeitungslogik auf dem Rechner implementiert ist,
auf dem diese Anwendung auch läuft.
Die müssen, was ihre Rechenkapazität anbetrifft,
müssen die Rich sein oder leistungsfähig,
weil sonst können also diese ganzen Operationen auf diesen Klienten nicht
ausgeführt werden
Es ist mit verschiedenen Vor- und Nachteilen verbunden. Der Vorteil liegt auf jeden Fall darin,
dass also die Unmittelbarkeit der Reaktions,
der Reaktion ist bei diesen Rich Clients gegeben,
eben weil also direkt auf jedes Maus-Move-Event, auf jedes Ereignis,
das bei diesem Rechner ankommt, kann unmittelbar reagiert werden.
So, demgegenüber, die Find Clients,
bei denen keine eigene Verarbeitungslogik auf dem Rechner stattfindet,
auf dem diese Applikation präsentiert wird, diese,
diese Fin-Clients lassen die eigentliche Verarbeitungslogik typischerweise auch von einem entfernt arbeitenden Server verrichten.
Thin-Clients sind Applikationen, die ansonsten heutzutage im Wesentlichen auch,
also in einem Browser, ablaufen.
Das war über Jahre, um nicht zu sagen,
Jahrzehnte war das eine ziemlich starke Trennung zwischen diesen beiden Welten
und so wie das am Ende dieser Folie auch steht,
fängt es an, dass diese Grenzen verschwimmen.
Die verschwimmen insbesondere deswegen Weil die Finn-Clients tendenziell reicher werden,
weil immer mehr Anwendungen auch,
also um so das eigentliche Merkmal von Rich-Client-Applikationen implementieren,
nämlich Verarbeitungslogik direkt im Browser ablaufen zu lassen,
beziehungsweise im Browser zu implementieren.
Und dadurch dieses Gefühl der unmittelbaren Rückkopplung für den Benutzer,
auch mit Finn-Klein-Technologien implementiert werden kann. So,
der Gestaltungsspielraum, den wir als Softwareentwickler,
wenn sie die entsprechenden Technologien beherrschen, dieser Gestaltungsspielraum ist,
also wie gerade schon am Anfang gesagt,
ist der
sehr groß
Und sie sind vermutlich, nicht nur vermutlich,
also wir denken, dass sie gut beraten sind,
diesen Gestaltungsspielraum zunächst auch mal,
also nachdem man ihn kennengelernt hat, für ein konkretes Entwicklungsprojekt,
diesen Gestaltungsspielraum dann auch wieder kleiner zu machen,
damit also nicht so ein Effekt eintritt.
Wir können zwar alles Mögliche implementieren,
aber wir schaffen es nicht für ein einzelnes Projekt,
die Entwurfsentscheidung so zu treffen,
dass dieses Projekt on time on budget in
einer bestimmten Art und Weise zu einem befriedigenden Ende führt
So,
Sie sehen jetzt hier mal noch ein paar Beispiele für,
also diese Unterscheidung zwischen Rich und Thin-Clients,
die ist also insbesondere, sage ich zu häufig,
ist also gerade mit dem Aufkommen von Cloud-basierten Lösungen,
also Lösungen,
in denen Rechenkapazität,
so in einer teilweise unbekannten Umgebung zur Verfügung gestellt wird,
wird diese Unterscheidung
auch immer unklarer
Weil es eben heutzutage möglich ist. Also einerseits durch die Rechenleistung,
die entfernt zur Verfügung steht, als auch durch immer höhere Leitungskapazität.
Also Finn Clients, so auszugestalten, dass sie wirken wie das,
was man früher an lokaler Rechenkapazität zur Verfügung hatte.
Sie sehen hier auch noch so ein paar Vor- beziehungsweise Nachteile ein, da wollte ich noch mal explizit drauf eingehen. Also dass hier,
dass hier jeweils ein individueller Installationsaufwand notwendig ist für Rich Client Applikationen,
ist für alle Organisationen, deren Aufgabe darin besteht,
eine Anwendung einer großen Anzahl von Benutzern zur Verfügung zu stellen,
ist ein echter Faktor, was die Entscheidung anbetrifft,
bauen wir die nächste Generation von Anwendungen als Rich oder als Findclient-Applikation,
weil gerade in sicherheitskritischen oder leicht angreifbaren Kontexten ist also die Notwendigkeit jeweils lokal,
etwas zu installieren zu müssen, ist ein,
also ich will nicht sagen, ist ein ständiger Albtraum,
aber kann häufig in einer albtraumartigen Situation Emden.
Nichtsdestototrotz beschäftigen wir uns in SE2, im Wesentlichen,
also mit der Konstruktion von Desktop-Systemen.
Und das hat einen einfachen Grund. Wenn Sie Desktop-Systeme,
interaktive Desktop-Systeme bauen können, dann haben Sie sozusagen die Königsklasse
der Applikationen, können Sie dann implementieren.
Der Rest ist einfacher
Also kümmern wir uns lieber gleich um das Komplizierteste. Dann können Sie das,
was bei den einfacheren Applikationstypen, also den Thin-Client-Applikationen,
dann können Sie vieles von dem werden Sie feststellen,
brauchen wir jetzt nicht mehr,
weil dort bestimmte bestimmte Features, bestimmte Eigenschaften, Folgensystemen,
keine Rolle spielen, keine Rolle mehr spielen.
Und sie, so das gesamte Konstruktionswissen,
das sie haben, dahingehend abklopfen können,
ob das für diese Art von Systemen
noch gebraucht wird
Das Versprechen ist dann also, sie kriegen hier das Rüstzeug,
das Handwerkszeug vermittelt, mit dem sie hochkomplexe,
interaktive Rich Clients bauen können, in der Art,
dass das so ein nachvollziehbares Look and Feel hat und
auch gleichzeitiges und auch gleichzeitig innere Softwarequalitätsmerkmale aufweist.
Und das ist ja das eigentliche Thema, über das
wir heute sprechen. Also interaktive Desktop-Systeme, Rit,
das sind Rich Clients, wir wollen uns darum kümmern,
wie können diese Systeme
gebaut werden
Ein Thema, das wir hier nicht,
oder zwei Themen, vielmehr, die wir hier,
zwei Themen, die wir hier nicht bearbeiten werden,
ist, die Systeme, die sie bauen,
sind im Großen und Ganzen Gedächtnis frei.
Die erinnern sich nicht daran, dass sie es gestern benutzt haben,
was für eine typische Anwendung eher hinderlich ist.
Also wenn sie morgens ihren Kontostand abfragen und er ist immer null,
dann wundern sie sich auch, möglicherweise keine schlechte Idee,
nachdem sie gestern so viel abgehoben haben,
ist es heute wieder null
Aber Scherz beiseite. Wir kümmern uns nicht um Fragen der Persistierung von Daten.
Das kommt später. Das machen dann die entsprechenden Kollegen,
die sich mit so Persistenztechnologien, Datenbanken beschäftigen.
Das ist auch kein Hexenwerk. Also aber wir beschäftigen uns damit nicht,
weil es den Fokus der Veranstaltung ein wenig verwischen würde.
Das zweite, womit wir uns nicht beschäftigen,
ist die Verteilungsproblematik
Die Verteilungsproblematik, die tritt nämlich genau dann auf. Also erstens,
wenn sie Anteile von dem, was sie bauen,
auf verschiedenen Arten von Rechnern ablaufen lassen wollen,
also ein bisschen Verarbeitungslogik auf dem Klienten,
ein bisschen Verarbeitungslogik auf einem Server,
möglicherweise so die Datenbank ist noch auf einem noch entfernter liegenden Mainframe-System,
Fragestellungen, die sich aus dieser Art von Verteilung,
die aus dieser Art von Verteilung resultieren,
werden wir jetzt hier jetzt auch nicht behandeln.
Wir tun so,
als würde die Welt aus dieser sowas wie diesem Gerät bestehen,
ein Stück Hardware,
wo in einem Prozessraum sämtliche Funktionalität implementiert ist und man könnte dann so weit gehen,
wenn man noch ein Stück Datenbank hinten dran bauen würde und das lief immer noch auf so einem Rechner,
dann hätte man einen sogenannten Ultra-Rich-Client implementiert.
Hier steht auch, warum wir uns im Rahmen von SE2
nicht damit beschäftigen, sie haben ja noch drei Semester,
in denen sie was lernen können und ich verspreche ihnen,
das ist Angebot das entsprechende Angebot ist.
Dazu ist ab dem spätestens dritten Semester steht Ihnen das auch zur Verfügung.
So, Konstruktionsregeln werden wir heute darauf eingehen.
Nachdem Sie sich die Folien in, die ich gestern liebe,
voll ins Comsi gestellt habe, nicht angeschaut haben,
werden Sie auch nicht feststellen,
dass diese Folie nicht drin ist.
Ich liebe es mehrfach zu verneinen
Wir führen sie ja langsam an die Welt der Softwareentwicklung da
draußen außerhalb des Elfenbeinturms heran. In drei bis sechs Semestern,
wenn sie also ihren Master hier gemacht haben,
dann kommen sie in ein Entwicklungsteam und dieses ein mögliches Szenario.
Kommen Sie möglicherweise in ein Entwicklungsteam und die arbeiten seit
sechs Monaten mit acht Leuten an einem Stück Software.
Und das möglicherweise tun die das auch noch,
acht Monate, vielleicht auch noch acht Jahre,
soll es auch geben
Die Art und Weise, wie sie im Moment
Software bauen oder die bauen dann solche Kathedralen.
Das baut halt kein Mensch alleine. Die Konstruktionsaufgaben,
mit denen sie sich im Moment beschäftigen, haben eher so diesen Charakter.
Ich krempel die Ärmel hoch. Sie haben noch keine große besondere formale Qualifikation.
Auftraggeber und Konstrukteur sind meist eine Person. Es gibt eine Variante dieser Folie,
da heißt es dann, also das Auftraggeber und Benutzer sind meistens eine Person,
aber ich glaube, in sowas würde auch keiner,
selbst keiner von uns, darin wohnen wollen. Und das ist halt,
also wenn das so die Konstruktionsaufgaben wären, mit denen,
die sie sich da draußen im späteren Berufsleben zu beschäftigen hätten,
dann könnten wir jetzt hier das Licht ausmachen, rausgehen,
uns in die Sonne setzen und sagen, wir wissen eigentlich genug,
das machen auch einige und dann stellt man halt später fest,
nee, sorry, das war jetzt vielleicht doch nicht genug.
Man sagt also so, diese Art von Software, also die wir sie jetzt,
also mit den Mitteln, die sie bis jetzt kennengelernt haben,
also schreiben können, ist die, die vergleichsweise einfach zu schreiben ist.
Also Software, die ist klein, also nur klein,
das ist klein bei Software, also klein ist,
wenn sie das meinetwegen innerhalb von zwei Tagen implementiert haben,
Ritten by One Person,
okay, von mir aus auch ein Programming Pair,
over short period of time, habe ich schon genannt,
used by that one person, aha, used ones,
na, vielleicht gucken sie sich das Programm,
das sie geschrieben haben,
ja auch nochmal an oder zeigen es ihren Eltern,
and then throw the way,
Ist einfache Software. Da ist also die Qualität,
insbesondere die innere Qualität ist da, also egal, gleichgültig.
Alles andere, also Software, die von mehr als einer
Person über eine längere Zeit und von anderen benutzt wird,
mehrfach und nicht weggeschmissen wird und man das Gegenteil aufzubauen,
das ist schwierig.
Und das ist für uns, das ist jetzt die,
das ist einerseits schwierig, andererseits ist das ja ihre Lebensversicherung.
Sie sind jetzt, wie alt sind Sie denn so?
So um und bei 20, nicht
Plus minus. Das heißt also,
wenn ich so die demografische Entwicklung mal so vorwegnehme,
sie dürfen also noch so ungefähr 50 Jahre arbeiten,
bevor sie dann nicht in Rente gehen, streichen sie das aus dem Protokoll.
Ich wollte hier nicht politisch werden. Wir wollen also nicht Hundehütten bauen,
sondern sie wollen mit anderen wollen sie sowas bauen.
Etwas, das dann auch mal einen Winter und ein paar Regengüsse überlegt.
Und was man daran schon sehen kann,
also da müssen unterschiedliche Berufsgruppen arbeiten und sie sind diejenigen,
die hier zu, also nicht zu Architekten,
aber dann doch möglicherweise zu sowas wie Softwarearchitekten ausgebildet werden,
die dann mit anderen Berufsgruppen,
also so etwas in einem Planungs- und Entwicklungsprozess herstellt.
Da ist das Formale und technische Wissen,
das bringen wir ihnen hier im Studium bei.
Das, was Sie hier sehen, das Erfahrungswissen,
also wie das dann angewendet wird,
das können wir Ihnen hier nur ansatzweise beibringen
Weil wir mit Ihnen ja keine realen Entwicklungsprojekte durchspielen können.
So in diesen Zusammenhängen bei, also wo jetzt hier,
bei diesem Beispiel ist es ja offensichtlich,
wenn Sie da Pfusch am Bau produzieren,
da können Menschenleben gefährdet sein und spätestens dann hört der Spaß ja auch endgültig auf.
Wenn durch Ihre Software, also Menschenleben gefährdet werden könnten,
Gott bewahre, dann haben Sie also nicht nur ein moralisches,
sondern vermutlich auch noch ein juristisches Problem.
Also Qualität innerhalb von Softwareentwicklungssystemen spielt spätestens dann
eine Rolle
Welche Arten, sagen wir mal, Qualität, ja.
Natürlich, ist doch klar. Qualität wollen wir haben,
wer will schon qualitativ minderwertige Software schreiben. Und jetzt müssen wir aber ein bisschen genauer hingucken,
was kann denn bei Softwaresystemen eigentlich,
also welche Arten von Qualität lassen sich denn da über,
lassen sich denn da unterscheiden,
weil ich habe das gleich auch nochmal ein bisschen aufgeblättert,
welche Arten von grundsätzlichen Überlegungen man machen kann,
wenn man über Qualität spricht.
Was bedeutet das denn, wenn wir über Entwicklungen,
also von Software sprechen und das so qualitativ hochwertig machen,
damit es nicht nur ein hohler Anspruch ist.
Das heißt so, wir stehen hier und die Absolventen der Universität Hamburg-Softwareentwicklung,
1, 2, 3, also haben natürlich gelernt,
was also qualitativ hochwertige Software ist.
Und der erste, die erste Unterscheidung, die wir hier vornehmen,
ist, dass also zwischen äußerer und innerer Qualität unterschieden wird.
Die äußere Qualität ist die Art von Qualität,
die im Wesentlichen unsere, die Benutzenden unserer Software interessiert,
nämlich wie liegt dieses Stück Software dass wir für die,
dass wir für die implementieren, wie liegt es in der Hand?
Also tut es das, was es tun soll,
ist es zuverlässig, das heißt also stürzt es nicht,
also dauernd ab, zeigt Verhalten, dass ich nicht erwarte,
das ist das ganz große Thema der Benutzbarkeit oder der Neudeutsch Usability,
könnte auch sagen, der Gebrauchstauglichkeit und ist das also effizient benutzbar?
Also effektiv tut es das, was es tun soll,
effizient tut es das gut, schnell, was auch immer,
das Effizienzkriterium ist, tut es das so, wie ich es erwarte.
Diese Art von äußerer Qualität ist, vergleichsweise unabhängig von der
inneren Qualität eines Stück Software. Wenn Sie mir erlauben,
also ich will jetzt hier keinen Glaubenskrieg anzetteln,
also wenn Sie mir erlauben, für den Moment kurz zu behaupten,
das Ding hier liegt vergleichsweise gut in der Hand.
Es hat also eine, für mich hat es eine hinreichende,
ausreichende Gebrauchsqualität, eine äußere Funktionqualität.
Ich habe ja nicht die blasseste Ahnung,
so wie das Ding von innen aussieht
Ist das so 150.000 Zeilen Spaghetti-Code, mit dem das implementiert worden ist.
Oder haben sich da Leute über die innere Qualität dieser Software einen Gedanken gemacht?
Ist die Software, die gebraucht wurde, die geschrieben wurde,
um diese hohe Gebrauchstauglichkeit zu implementieren, ist die verständlich?
Ist sie wartbar? Das heißt, vor allem ist sie
weiterentwickelbar. Gibt es eine Art von Modularität,
sprich eine Art von Einheitenbildung, Modulen, Paketen, Klassen?
Sie kennen so Instrumentarium der Modularisierung im Kleinen, sodass ich entscheiden kann,
aha, also dieses Stück Software aus dem großen Stück Software,
das ist für eine bestimmte Funktionalität zuständig.
Wir wollen jetzt, also wenn wir jetzt im Weiteren über Qualität sprechen,
wollen wir also mindestens diese beiden Qualitätsausprägungen voneinander unterscheiden.
Sind hier, das kommt jetzt gleich auch nochmal,
sie sehen so, welche Arten von Qualität noch unterschieden werden können.
Und wenn ich jetzt also wieder mal so zeitlich vorgreife,
wenn sie da in das Entwicklungsteam kommen, Finden Sie hoffentlich nicht,
dass da als Grundlage vor mit der Aufgabe, Sie mal zu,
dass du das innerhalb der nächsten drei Wochen um 50 Prozent schneller machst.
Oh, ja. Das sind doch Aufgaben,
so nach dem Motto, du bist doch jetzt Master.
Jetzt zeig mal, was du drauf hast.
Heu. Gott sei Dank sind die Zeiten nicht so,
dass sich doch jemand trauen würde,
ihnen diese Art von Aufgabe zu geben,
weil dann gehen sie halt zu jemand anders
Und sehen zu, dass sie da ihr Wissen anbringen. Aber jetzt ganz unabhängig davon,
was das da mal gewesen ist, was das mal werden könnte,
um die innere Qualität eines Stücks Software beurteilen zu können,
brauchen wir irgendeine Form von Darstellung, die es uns erlaubt,
über die Qualitätsmerkmale, die ich gerade gesprochen habe,
das also zu thematisieren, das zu vergegenständlichen.
Und wenn die Software, die wir bauen,
sowohl weder diese Qualitätsmerkmale Inhaltet noch sie in einer bestimmten Art
und Weise darstellbar sind, dann haben wir ein Problem.
Dieses Problem können, das führt dann für Würde,
wenn wir das nicht, also schon halbwegs gelöst hätten,
letztendlich dazu führen,
dass wir im Großen und Ganzen unwartbare Software schreiben.
Das wollen wir nicht. Also mindestens wollen wir das nicht
so unwissentlich tun. Es gibt durchaus Situationen,
in denen das heißt, was haben wir heute,
15. Mai,
am 31. Mai muss dieses Portal für diesen Kunden stehen
Punkt, tut es, aber Chef, es wird also dann vielleicht nur sechs Monate halten.
Egal, es muss unsere Konkurrenz ist am 31. Mai,
wird sie dieses Ding an die Rampe fahren und deswegen müssen wir das auch haben.
Wir haben jetzt keine Zeit, qualitativ innere Software zu schreiben,
die eine interne hohe Qualität hat, diesen Anspruch verwirklichen wir beim nächsten Projekt.
Thing us drossed. Also das sind so,
man sollte sich mindestens darüber bewusst sein, was man tut und nicht denken,
ich hau da jetzt was rein und es hat hohe Qualität.
Und dann macht man sich und anderen eher etwas vor.
Es gibt noch eine dritte Qualität,
die werde ich aber heute nur wirklich an dieser,
also eine dritte Qualität, die unterschieden wird, äußere Qualität,
Gebrauchstauglichkeit, interne Qualität, darüber beschäftigen wir uns gleich im Wesentlichen.
Es gibt noch eine dritte Qualität, die unterschieden wird,
die für die Entwicklung von Softwaresystemen eine Rolle spielt und das ist die Prozessqualität.
Mit Prozess ist hier gemeint der Entwicklungsprozess eines Stück Software von einer Wie
auch immer gearteten Anforderungsdefinitionen bis zu einem tatsächlich produktiv einsetzbaren System.
Die Entwicklungsprozesse, sie werden, wenn sie sich für Softwaretechnik interessieren,
werden sie das noch so ausgebreitet bekommen.
Prozessqualität wird im Wesentlichen über die Befolgung von unterschiedlichen Vorgehensmodellen erreicht.
Vorgehensmodelle in der Softwareentwicklung dienen dazu, den Entwicklungsprozess zu strukturieren.
Und je nachdem, wie ausgeprägt dieses Verhalten,
nämlich das Verfolgen eines Vorgehensmodells eines Entwicklungsprozesses ist, je nachdem,
wie ausgeprägt das ist,
kann man einer Organisation auch einen Reifegrad zuweisen.
Da kommen dann externe Prüfer und schauen, wie also die Software entwickelt wird.
Und diese Reifegradstufen sind nach dem sogenannten Capability Maturity Modell zu
Deutsch Reifegrad Modell, werden die unterschieden.
Also von etwas euphemistisch, individuell ausgeprägt. Jeder baut die Software,
wie er denkt, dass die gebaut werden soll.
Also jetzt von dem Entwicklungsprozess her bis hin zu einer Stufe,
die als Optimizing oder Deutsch optimierend betrachtet gekennzeichnet wird
Die da heißt, es gibt einen strikten,
quantifizierbaren Entwicklungsprozess, der, also führt alle Beteiligten nachvollziehbar ist
und nach einer bestimmten Zeit zu einem bestimmten Ergebnis führt.
Ich habe jetzt schon davon gesprochen, dass also der Zusammenhang zwischen
interner und äußerer Qualität so etwas ist, der Zusammenhang ist nicht zwingend.
Sie können aus einer hohen internen Qualität nicht auf eine
äußere Qualität schließen und auch umgekehrt nicht.
Genau so Fragil ist der Zusammenhang zur Prozessqualität.
Wenn Sie eine hohe Prozessqualität in Ihrem Unternehmen haben,
kann das bedeuten, dass Sie, nehmen wir mal ein Beispiel,
wie hießen die denn?
Die Schildbürger. Genau. Die Shitbürger konnten ja Häuser,
konnten ja Häuser bauen und unter anderem konnten sie eben auch Häuser ohne Fenster bauen.
Das kann man jetzt, was den Prozess des Haus bauens
ohne Fenster anbetrifft, den kann man natürlich hochgradig optimieren.
Man sagt, also wir können mit gleichbleibender Qualität können wir
diese Häuser bauen
Das hat also dann mit der Gebrauchstauglichkeit,
das ist kein Thema des Prozesses, diese Häuser zu bauen.
Und die Leute, die sich mit solchen Reifegrad-Modellen beschäftigen,
die beschäftigen sich zum Beispiel auch mit dem Einkauf von Ressourcen für solche Projekte.
Das ist dann das CMMI. Also das ist noch mit dem Einkauf.
Der Einkauf von Ressourcen ist dann da auch noch mit,
wird da auch noch mit behandelt. Das heißt also,
um auf die Schildbürger zurückzukommen,
wir können also in einem optimalen Prozess Häuser ohne Fenster bauen
und wir können auch noch den Einkaufsprozess für die Säcke um das Licht in die Häuser zu bringen, optimieren.
Und dann haben wir einen optimalen Prozess für genau dieses Produkt erreicht.
Jeder von uns weiß, das ist nicht im Sinne des Erfinders. Das heißt also,
dieses Wissen um diese drei Qualitätsmerkmale erfordert sie als diejenigen,
sagen, also einen Moment mal, wir haben hier gerade ein Schwergewicht auf diesem Qualitätsmerkmal.
Lass uns doch mal lieber darüber reden,
ob nicht also die Gebrauchstauglichkeit, sprich ein paar Fenster in dieses Gebäude,
eine höhere Rolle spielen sollte bei unseren Aktivitäten
Versus also jetzt noch, also den Einkaufsprozess für Säcke zu
Off-Schoren und ihn damit noch billiger zu machen.
Was sie für den Moment mitgenommen haben,
ist, wir haben diese Unterscheidung in drei Qualitätsmerkmale.
Sie können jetzt, das können Sie im Wesentlichen nochmal dann
zu Hause oder wo auch immer, nachlesen.
Es gibt also verschiedene Qualitätsbegriffe, die hier zusammengebracht werden müssen,
um ein sinnvoll einsetzbares Stück Software mit einer hohen inneren Qualität herzustellen.
Einen Punkt, den ich jetzt noch gar nicht betrachtet habe,
ist so ein Kosten nutzenbezogener Ansatz. Das werden wir im
Laufe dieser Vorlesung, werden wir das auch nicht weiter thematisieren.
Das ist dann eine Frage der Softwaretechnik. Also diese betriebswirtschaftlichen Aspekte noch mit einzubeziehen,
also zu welchem Zeitpunkt in einem Entwicklungsprozess soll welcher nutzen,
welcher Return on Investment erzielt werden können, um den eigentlichen Zweck,
der mit der Herstellung eines Stück Softwares eines Stücks Software verfolgt wird,
um diesen Zweck zu erreichen.
So, wir können jetzt, das sind jetzt,
ach, da kann man eigene Vorlesungen drüber halten.
Also was bedeutet denn jetzt eigentlich Wartbarkeit von Software?
Die sehen also diese ganzen verschiedenen Kriterien, also die zur Wartbarkeit oder auch hier Portierbarkeit führen.
Das soll jetzt erstmal der Zweck dieser Darstellung ist jetzt erst mal im Wesentlichen,
ihnen klarzumachen, da draußen existiert eine unfassbar vielfältige Welt,
die sich mit den Problemen bei der Herstellung und des Einsatzes von Softwaresystemen beschäftigt,
weil alle, die alle diese Grafiken,
sind Antworten auf Probleme, die schon mal aufgetreten sind.
Das Software testbar sein muss, weiß ich nicht,
ob das nicht eine Selbstverständlichkeit ist, ist im Industriellen Alltag,
also wird man das häufig nicht,
wird man das häufig nicht vorfinden das,
was wir jetzt hier so als Entwurfsregeln etablieren werden im Laufe der nächsten Zeit.
Also das ist einfach noch nicht der Stand der Technik draußen
in der Welt. Damit es nicht zu einfach wird.
Man könnte sie könnten jetzt so denken,
ich schreibe ein Stück Software und dann ist auch gut.
Weil das ist für einen kurzen Moment, ist es dann
auch gut. So wie das da steht,
ist es eigentlich aber auch nicht richtig.
Die Software verändert sich natürlich
überhaupt nicht
Mal implementiert worden ist, was sich aber sehr wohl verändert,
ist die Welt, in der diese Software läuft.
Die Welt, die einerseits aus, also der Fachlichkeit besteht,
für die diese Software implementiert worden ist und zum Zweiten,
die Welt, in der sie, also technisch abläuft.
Ich weiß nicht, inwieweit in Heinz Zülikoven schon,
also Anekdoten aus der Welt der Industrie erzählt hat.
Was ich typischer, was ich nicht typischer,
was ich gerne erzähle, sind also diese vielen kleinen Organisationen,
die heute noch Programme haben,
die in DOS-Boxen laufen
Wissen Sie noch, was das Boxen sind? Okay,
das war so der Vorläufer von Windows. Das ist so
ein Zeilenorientiertes Betriebssystem. Also noch mit so ein richtiges Betrieb,
das ist auch Quatsch, streichen Sie das.
Also Software, die sich nie an die sich verändernden
technischen Randbedingungen angepasst hat, in der sie läuft.
Und die Leute kriegen jetzt so langsam aber sicher,
kriegen die so das P in den Augen
Für Panik, weil sie wissen einfach nicht,
wie lange läuft diese Software noch?
Wie lange wird es diese Art von Unterstützung noch geben?
Dieses Problem ist mindestens so schwerwiegend wie das Problem,
die fachlichen Randbedingungen, meinetwegen die gesetzlichen Randbedingungen,
unter denen ein Stück Software eingesetzt wird, ändern sich.
Und ich muss jetzt dafür sorgen, dass meine Software compliant bleibt.
Also weiterhin im Rahmen, der sich verändernden gesetzlichen Bestimmungen läuft.
Und das bedeutet, Software, die sich da nicht anpassen kann,
die wird so, die wird auch sterben in dem Sinne.
Irgendwann ist gut, dann muss ein neues Stück Software daher.
Und es gibt also durchaus profitable Organisationen, die sich damit beschäftigen.
Das ist Software so lange am Leben zu erhalten,
bis ein Stück Ersatzsoftware, also hochgezogen worden ist.
Das ist eben die Frage,
also will ich einen Altbau,
will ich den
so lange weiter renovieren
Dass ich darin wohnen bleiben kann oder verrottet er irgendwann.
Und dann muss ich ein Neubau daneben setzen. Also insofern ist Software,
auch wenn die als solche überhaupt nicht altern kann,
ist also der Gegenstand, für den sie geschaffen worden ist,
der ändert sich und die Technologie.
Insofern gibt es auch bei Software einen ständigen Zwang,
sich zu verändern, beziehungsweise nicht sich zu verändern,
sondern sie aktiv, also am Altern zu hindern.
Damit ist also Dave Panas,
der Name wird ihnen auch noch an verschiedenen Stellen
im Studium beginnen
Regnen. Der hat also diese Beobachtung in diesem,
in dieser Keynote so in die Welt gebracht.
Und seitdem haben wir so eine Metapher mehr. Wir beschäftigen
uns im Rahmen dieses Werkzeugmaterialansatzes mit Entwurfsregeln, die genau,
nicht nur, aber auch diese diese Art von Problemen adressieren.
Und wir beschäftigen uns dann eben mit der Frage,
Vorgehensmodell,
das ist ein Punkt
Aber auch, also Konstruktionshinweise für interaktive Systeme. Damit bin ich wieder am Anfang,
nämlich den Designspielraum kleiner zu machen oder diesen Einspielraum wenigstens mal ein wenig zu strukturieren.
Dieser Designspielraum oder das Elend fängt eigentlich schon damit an,
also dass ich die ganze Zeit hier von Software-Systemen spreche,
ohne dass ich ihnen mal eine Definition von Systemen geliefert habe.
Software-System, interaktives Software-System, na gut,
aber was dieses System in Software-Systemen bedeutet, Darüber herrscht also mindestens heute,
wird da auch noch der Mantel des Schweigens gelegt.
Im Großen und Ganzen heißt das Softwaresystem ja erstmal nur, oder System, if
you don't know, what it is call it assystem.
So ein System wird es schon sein, nicht wahr?
So, und es geht dann noch weiter, if
you don't know, how it works, call it a process. Also,
und wenn sie dann vom System Entwicklungsprozess sprechen,
dann heißt es im Großen und Ganzen, sie wissen nicht,
was sie bauen und sie wissen noch nicht,
wie sie es bauen wollen,
aber Systementwicklungsprozess hört sich erstmal nicht schlecht an,
oder?
Das kann man ja mal
so sagen
Davon wollen wir wegkommen. Es gibt,
also wir werden ihnen so Regeln präsentieren oder sie mit Regeln vertraut machen,
dass sie nicht mit diesen Nebelkerzen, um sich,
was macht man mit Nebelkerzen, dass sie diese Nebelkerzen zünden müssen,
sondern dass sie ganz konkret von Arbeitsgegenständen und Arbeitsschritten sprechen können,
die dazu führen, dass qualitativ hochwertige Software entsteht.
Ich komme jetzt mal gleich zu den,
zu ein paar grundlegenden Regeln,
die erste und Ich will nicht sagen, wichtigste Regel,
aber doch eine ziemlich fundamentale Regel besteht Arin,
ein Stück Software ist für etwas gut.
Und das ist die Fachlogik. Wozu wird dieses Stück Software
überhaupt geschrieben? Und dann muss dieses Stück Software halt irgendwie
an den Mann, an die Frau gebracht werden.
Und das bedeutet, es braucht ein Stück Technik,
dass diese Fachlogik in unserem Kontext im Wesentlichen repräsentiert,
So, mit Persistenz und Verteilung wollten wir uns ja im Rahmen der Veranstaltung nicht beschäftigen.
Und diese beiden Anliegen, die in jedem Stück Software realisiert werden müssen, sollen mit voneinander getrennt werden. Und der Zweck,
warum wir das tun,
ist, wenn ihre Anwender mit ihnen sprechen,
dass eine bestimmte Funktionalität wahlweise fehlt oder anders implementiert werden soll,
anders, nicht implementiert, sich an das präsentieren soll,
ob das anders geregelt werden soll,
dann sollen sie ganz grundsätzlich in ihrem in der Menge von Klassen,
wenn sie eine Objektorientierte Programmiersprache verwenden,
in der Menge von Klassen so eine Strukturierung vor ihrem geistigen Auge haben,
die da heißt, hier ist die Anwendungslogik implementiert worden und hier habe ich die Klassen,
die dazu gut sind, diese Anwendungslogik an der Oberfläche zu präsentieren.
Das Ganze, wenn das Ganze so ein einziger Haufen ist,
dann können sie,
wenn sie wortgewandt sind und die entsprechenden Argumentationsknicke kennen,
können sie behaupten,
das ist eine
hochgradig integrierte Software
Sehr schnell. Das ist aber was Wartbarkeit anbetrifft,
ist, dass ein Scheinargument, also Trennung von Fachlogik und
technisch motivierten Klassen, ist ein grundsätzliches Anliegen.
Hier steht jetzt, ich möchte nahe am Anwendungsbereich,
das sind also was diese Klassen tun,
ist jeweils mit den Anwendern diskutierbar,
weil man da ja Fachlogik implementiert
Die sind sehr konkret meistens, also pro Projekt werden die auch individuell hergestellt.
Wiederverwendung ist ja der heilige Gral der Softwaretechnik, der Softwareentwicklung.
Ich weiß nicht, ob die anderen ihnen schon,
also diese Begrifflichkeit, also auseinandergenommen hat,
Wiederverwendung ist ein sehr schönes Zusammengesetztes deutsches Wort.
Und Wiederverwendung bedeutet, man hat erstmal etwas,
das ist verwendbar. Und wenn man was verwendbares hat,
dann kann man das
auch möglicherweise wiederverwenden
Und jetzt gucke ich mal auf sie. Sie sind jung
und sie sind motiviert und sie wollen möglicherweise zunächst mal etwas wiederverwendbares implementieren,
was später dann von vielen verwendet werden kann.
Und diesen, das ist eine Aufgabe,
die ich Ihnen stellen würde, wenn ich Sie zur Verzweiflung bringen möchte.
Ich sage es Ihnen. Und ich werde es Ihnen,
wenn wir uns nochmal begegnen, dem Studium möglicherweise auch nochmals sagen,
schreiben Sie lieber mal ein Stück
Verwendbare Software. Und dann können Sie gucken,
ob Sie das an einer anderen Stelle wiederverwenden können
Wofür tun Sie sich den Gefallen und schreiben Sie nicht erst etwas,
was wiederverwendet werden soll, um daraus etwas Verwendbares zu machen?
Aber das ist so, das kann ich jetzt,
also glaube ich, ich habe nur noch sechs Jahre arbeiten,
also jetzt werde ich auch noch die nächsten sechs Jahre,
wenn ich das den jungen Menschen hoffentlich jedes Jahr erzählen kann,
mal gucken,
also wie weit das ankommt.
Okay, eines ist ein anderes Thema. So, Molly,
das zur Modellierung, Anwendungsfachliche Klassen. Ich kann jetzt,
das hier ist ja so eine Thematik,
die Sie schon bereits aus SE1,
glaube ich,
Was wollen wir denn eigentlich, also der Gegenstandsbereich,
über der so als solcher, hier hat er eine schöne scharfe Grenze,
worüber wir im Wesentlichen sprechen, ist das Modell des Gegenständes,
Gegenstandsbereichs, also zum Beispiel diese fachlichen Modelle von Objekten,
diese fachlichen Modelle von Gegenständen,
die wir hier in diesem Bereich vorfinden.
Die können wir dann verwenden, um daraus ein Modell des Anwendungssystems,
das dann lauffähig in seinem Einsatzkontext sich darstellt,
herzustellen.
Dieses Modell, darüber reden wir im Weiteren,
weil an dieses Modell haben wir die,
für dieses Modell werden wir die Entwurfsregeln anwenden bzw. Entwurfsregeln vorstellen,
sodass man nicht über irgendetwas spricht,
was zwar mit Hilfe einer objektorientierten Programmiersprache implementiert worden ist,
sondern ganz konkret sagen, welche Kriterien wollen wir anliegen,
anlegen, um ein hochqualitativ hochwertiges Modell des Anwendungssystems zu haben.
So, ein Element dieses Modells des Anwendungssystems
ist sein fachlicher Kern. Dieser fachliche Kern,
das ist jetzt nur noch mal eigentlich eine andere Darstellung dessen,
was ich am Anfang gesagt habe, will technisch eingebettet werden,
um ihn eben in unserem Fall an der Oberfläche eines Rich-Client-Systems präsentieren zu können.
Diese, der Werkzeugmaterialansatz legt ihn jetzt nahe,
dass sie, was den fachlichen Kern anbetrifft,
also folgende Fragen beantworten können
Welche Materialien werden bearbeitet, wobei Materialien Gegenstände sind,
die zum Teil des Arbeitsergebnisses werden. Gibt es Werte,
also Dinge, die Werte, Dinge, das Wertartige,
Konstrukte, die in diesem Kontext immer wieder auftauchen?
Und gibt es möglicherweise so etwas wie fachliche Dienstleistungen,
Services, Dienstleister, die dazu dienen,
Materialien einer Bearbeitung,
für eine Bearbeitung
zur Verfügung
zu stellen
Ja. Daneben gibt es die technischen Klassen,
beziehungsweise die Klassen, die dazu notwendig sind, diese Fachlogik,
die jetzt zunächst mal völlig unabhängig von einer Interaktion implementiert wird,
diese technischen Klassen, die es braucht,
um das Ganze zum Laufen zu bringen und es auch zu repräsentieren.
Das ist aus Anwendungssicht, sind es im Wesentlichen Hilfsklassen.
Also Hilfsklassen hört sich so unwichtig an. So ist es
nicht gemeint. Es soll nur nochmal klarstellen,
dass der wesentliche Zweck für ein Softwareentwicklungsprojekt ist,
dass eine bestimmte Fachlichkeit implementiert wird und nicht, also das,
also ein Stück Technologie von ihnen implementiert wird und in diesem Gesicht,
unter diesem Gesichtspunkt sind die technischen Aspekte natürlich zweitrangig.
Dazu werden wir dann auch, also Konstruktionsregeln, Konstruktionsregeln präsentieren,
die vor allem eben darauf abzielen, dass also diese Trennung aufrechterhalten wird,
damit sie auch in anderen in anderen Kontexten,
in anderen technischen Kontexten, dieselbe Fachlichkeit laufen lassen können.
So, jetzt schauen wir uns das mal, schauen wir uns das schon mal an.
Wie sieht denn die Benutztbeziehung zwischen diesen vier Element-Typen,
die wir in den Softwaresystemen, in diesen kleinen Rich-Client-Systemen,
die wir hier implementieren, wie sehen diese,
wie können da so erste Entwurfsregeln aussehen? So,
das erste ist, wir sprechen also jetzt nicht mehr von irgendwas,
also Softwaresystem, diesem vermeintlichen irgendwas, wenn wir etwas bauen,
sondern die Begrifflichkeit, die sie verwenden sollen,
um ein Stück Software zu charakterisieren,
muss Wo es hört sich so müssend an.
Sollte sich mit diesen vier Begriffen hier ausdrücken lassen.
Materialien realisieren veränderliche, anwendungsfachliche Gegenstände. Mein Lieblingsmaterial habe ich
Ihnen gerade schon genannt, das Konto.
Was tun Sie typischerweise mit Ihrem Konto? Wer von Ihnen
hat ein Konto? Was? Wie? Konto.
So, Sparkasse, so dieses Zeug.
Klar, jeder, das ist ein, ich weiß nicht,
ob es schon den Status eines Menschenrechts hat,
aber es ist vergleichsweise ungewöhnlich, keins zu haben.
Was tun Sie mit Ihrem Konto? Jetzt sagen Sie nicht überziehen.
Bevor es überzogen ist, müssen Sie was anderes getan haben.
Geld abheben. Unfassbar. Jemand anders muss dann einzahlen,
wahlweise das BAföG-Amt ihre Eltern Menschen, die sie erpressen.
Was man halt so macht, nicht, um an Geld zu kommen.
Dann haben wir schon zwei. Geld abheben und einzahlen.
Zwischendurch, so machen sie noch was anderes.
Sie gucken ab und zu mal nach, oder?
Hat das BAföG-Amt bezahlt? Ist es Schutzgeld eingegangen?
Ist der Ferrari schon abgebucht? Ich erzähle jetzt mehr
über mich als über ein Konto
So. Aber unser Konto ist also ein veränderbarer Anwendungsfachlicher Gegenstand.
Fachwerte, anwendungsfachliche Werte, sie sind unveränderlich. Im Rahmen
eines Kontos, was begegnet einem denn da an unveränderlichen Werten?
Ja, nicht der Kontostand. Der ist ziemlich veränderlich.
Ja, bitte. Oh ja, die Kontonummer.
Und jetzt die Fachwerte sind so, so das Sediment,
jedes, also jedes Interaktiven, nicht nur jedes Interaktiven,
eigentlich von jedem Stück anwendungsfachlich motivierter Software.
Weil der Fachwert, so ein Stück Weltwissen in einer Unveränderlichen Art und Weise verkörpert.
Und Sie sehen das hier in der Benutzungshierarchie ist der Fachwert
ganz unten, was das höchste Lob ist,
weil alle beziehen sich auf diesen Fachwert
Material, kann Fachwerte benutzen und Services, die Materialien benutzen können natürlich
auch Fachwerte benutzen. Und deswegen sind die notwendig darauf angewiesen,
dass Fachwerte, so sie es mal modelliert worden sind,
eine sehr, sehr stabile Basis bilden,
auf der sie sich dann ihre eigenen Dienstleistungen,
auf der sie ihre eigenen Dienstleistungen implementieren können.
Und die benutzt Beziehungen, die sie jetzt hier sehen,
also von Werkzeug benutzt Service,
benutzt Material,
benutzt Fachwert
Das sind jetzt keine Beispiele für benutzt Beziehungen. Das sind
die einzigen benutzt Beziehungen, die zwischen diesen vier Elementtypen erlaubt sind.
Andere sind nicht erlaubt. Und jetzt kriegen sie hoffentlich so einen ersten Eindruck davon,
in diesem gigantischen Designspielraum, den sie so vor sich sehen,
mit, sie können mit Java oder einer anderen Sprache ihrer Wahl,
können sie ja implementieren und an Beziehungen setzen, was sie lustig sind,
solange sie sich hier bewegen Werden sie die SE2-Entwurfsregeln benutzen.
Und wir sagen ihnen, das ist nicht,
um sie zu quälen, sondern um sie zu disziplinieren.
Das ist natürlich dasselbe. Sie können mit der Freiheit,
die Ihnen die objektorientierte Programmiersprache bietet, nichts anfangen.
Das ist jetzt keine persönliche Beleidigung. Es ist nur,
verzeihen Sie mir, aber Softwareentwicklung braucht diese Art von Regeln,
womit ich jetzt sagen möchte, das ist nicht die einzige Art von Regel,
in ihrem späteren Berufsleben anwenden werden.
Also die, die wir hier in ihr beibringen,
aber nach bestem Wissen und Gewissen ist das eine nachvollziehbare,
für viele Arten von Problemstellungen, beide Herstellung interaktiver Software,
für viele Arten ist es eine gute Menge von grundsätzlichen Regeln.
Und wenn Sie ein anderes Regelsystem haben, bitte,
aber so ein paar Regeln braucht es,
um diese Software zu bauen, die nicht einfach ist,
die ich am Anfang charakterisiert habe
So, Services, um das noch zu sagen,
materialübergreifend fachliche Dienstleistungen, die systemweit zur Verfügung stehen. Ja,
also sowas zum Beispiel, wie ein Kontoservice,
den man fragen kann, gibt es ein Konto unter der Nummer
und der sagt dann ja und dann sagt man, na gut,
dann gib mir doch mal das Konto mit der Nummer.
Wobei, also die Kontonummer, wie schon gesagt,
ist natürlich ein Fachwert.
Das Konto ist ein Material und die anfordernde Stelle in diesem
kleinen Beispiel
wäre dann
ein Werkzeug
So wollen wir uns also die Welt,
ein klein wenig gestalten, damit also in der Frage,
also wenn es denn dann mal zu einer Architektur-Diskussion kommt.
Also der Dialog nicht so abläuft. Darüber macht man sich im Alltag
oder sie in ihrem Programmieralltag machen sich da eben auch,
können sich da noch keine wirklichen Gedanken darüber gemacht haben.
Also wie unterschiedlich, also solche Diagramme denn dann auch,
also interpretierbar sind. Und sie können halt in dem Moment,
wo sie so über Entwurfsregeln gemeinsam verfügen, Können Sie mit dem entsprechenden Programmiererfahrungshintergrund,
können Sie auch also sehr viel effizienter miteinander Software entwickeln,
als Sie das ohne diese Arten von Regeln je könnten?
Ja, wobei, also die Antwort ist ja nicht schlecht.
So. Okay. Ja, Dieses sind so dies und das,
also zu den Entwurfsregeln, dass ein Werkzeug,
ein interaktives Werkzeug nicht nur aus einer Klasse besteht, ist selbstverständlich.
Das kann aus mehreren Klassen bestehen. Was ich Ihnen jetzt schon verraten kann, ist,
dass also Ihre Tutoren, die studentischen Hilfskräfte und wissenschaftlichen Mitarbeiter,
die mit Ihnen die Programmierübungen betreuen, dass die darauf achten werden,
dass also für jeden Elementtyp, das ist ein eigenes Java-Paket gibt,
weil die haben ein, also ich meine,
sie auch, die haben ein ureigenstes Interesse da dran,
dass die Qualitätssicherung, die durch diese externen vorgenommen wird,
dass die schnell und zügig abläuft.
Und wenn man sich an ein paar Regeln hält und die gelten halt
nicht nur für diesen Übungsbetrieb, sondern dann für Softwareentwicklung im Allgemeinen,
dann ist es halt einfacher, Qualitätssicherung zu betreiben.
Die fachlich motivierte Schnittstelle bei Materialienfachwerten und Services,
wir werden ihnen die Aufgaben erstmal so strukturieren,
dass es ihnen hoffentlich einfach fällt,
also dass genau das zu tun Ja.
Das Vertragsmodell haben Sie schon in SE1 gehört, oder?
Ja, nein, vielleicht, was?
Wie? Aha, in SE2 haben Sie schon das Vertragsmodell.
So, die Konsistenzsicherung von Materialien, Fachwerten und Services
wird über das Vertragsmodell sichergestellt. Und sehen Sie sich vor,
also nur Verträge mit Not Null oder sowas zu machen und Testklassen,
die sich als Kumpanen der zur testenden Klasse weisen, werden wir auch enttarne.
Ich fühle mich extrem unwohl in der Rolle.
Wir werden sie kontrollieren, wir machen ein Tun.
Das ist ja nicht der Zweck der Übung. Der Zweck der Übung ist,
sie haben so ein Stück Software geschrieben,
dann kommt jemand daher und sagt,
das Versicherungsvertragsgesetz hat sich geändert und wo ist das denn überall in unserer Software,
also wo wird sich diese Änderung abspielen?
Also wo müssen wir jetzt also Hand anlegen und dann sagen
sie, Weiß ich auch nicht.
So, es ist irgendwie kompliziert, oder?
Hat sich seit 100 Jahren nicht geändert, dieses Gesetz.
Und sie haben gesagt, es wird sich auch nie ändern.
Und jetzt ändert es sich doch. Ja,
aber in sechs Monaten läuft die Frist ab.
Da muss die Software umgestellt sein. So,
und dann brauchen sie Vertragsmodell, um schauen zu können.
Also, befindet sich meine Software immer in einem konsistenten Zustand. Testabdeckung,
um sicherzugehen, dass wenn sie etwas geändert haben,
dass dann nicht also an Stellen ihre Software umfällt,
also an die sie nie gedacht haben und so weiter und so weiter.
Also, das sind eigentlich alles so so lebenserhaltende Maßnahmen,
mit denen ich hier über die ich hier spreche.
Also das können Sie eins zu eins so mit ins Berufsleben übernehmen. So,
hier werden jetzt noch so ein paar, die Entwurfsregel,
die ich Ihnen in der einen Grafik, also überblicksartig dargestellt habe,
werden jetzt hier nochmal ein klein wenig verdichtet.
Was ist also mit den Materialien so im Allgemeinen und im Besonderen
so aus sich hat und insbesondere nämlich dass Materialien selber nur Materialien und Fachwerte kennen.
Und ansonsten für sie die Welt, also für sie Materialien,
die Welt abgeschlossen ist. Vor allem,
weil es ein Material nie, also von welchem Werkzeug es bearbeitet,
interaktiv bearbeitet werden kann oder ob es sich gerade in einem Service befindet,
das ist für Materialien ziemlich uninteressant. Ich möchte,
das wird in den Übungen, das ist jetzt eher so ein Ausblick,
das wird in den Übungen, glaube ich, nicht vorkommen,
nur wenn wir schon über Materialien sprechen, möchte ich mit Ihnen über eine Art von Materialien auch kurz gesprochen haben.
Das sind Behälter. Behälter sehen hier, was wir unter Behältern verstehen, Sammlungen von Gleichartigen oder Zusammengehörigen Materialien. Die sind auch,
also in der Regel, nicht nur in der Regel,
die sind fachlich motiviert und ich möchte Ihnen hier mal so ein Beispiel zeigen,
so wie wir das in einem Projekt für,
wie wir das in einem Projekt schon mal umgesetzt haben,
da geht es darum, dass so so Fördermittelanträge,
verwaltet werden, also der Anwendungskontext, ist also,
ist der Anbau von Getreide oder die Verwaltung von Weideflächen für Kühe und was da sonst noch so rumweidet.
Und was man also der zentrale Gegenstand, mit dem die
in diesem Anwendungskontext arbeiten, ist also der sogenannte Förderantrag.
Und dieser Förderantrag, das ist ein Behälter,
Also wir betrachten den als Behälter, man könnte auch sagen,
das ist so eine Art von Akte derart,
dass die dieser Behälter eine Aussage über seinen Zustand machen kann.
Und das ist etwas, was man mit diesen,
mit dieser Art von Material, also kann man sehr viel,
sehr aussagekräftig arbeiten, wenn nämlich dieser Förderantrag sagt,
nun ja, ich befinde mich jetzt in dem Zustand,
also ich bin jetzt gerade mal eröffnet worden,
dann bedeutet das,
dass auf gar keinen Fall,
also schon eine Summe ausgezahlt werden kann,
weil davor müssen noch ein paar andere Zustände
erreicht werden
Das ist, was ich alles, was ich jetzt sage,
ist völlig unabhängig von dem interaktiven Kontext, in dem das jetzt eingesetzt wird.
Man kann über diese Antragsmappe, diesen Förderantrag,
so kann man sehr viele Aussagen,
also auch im Dialog mit, also Anwendern, darüber machen,
wie sich diese Software im Einsatz, also in ihrem Zustandsübergängen,
wie die sich verhalten sollen.
Und insofern sind, also stehen noch ein anderes Beispiel,
hier, insofern sind also, sind Behälter eine ausgezeichnete Art von Materialien, deren Einsatz so
An verschiedenen Stellen, an verschiedenen Stellen sehr sinnvoll sein kann.
So Regeln für Fachwerte. Ich möchte eigentlich in keinem Software-System sehen,
das bleiben wir bei der Kontonummer,
dass die wahlweise als String oder als Intager definiert ist.
Nein, will ich nicht sehen. Nein,
ich will, dass eine Kontonummer, eine Kontonummer ist.
Weil mit meiner Kontonummer weiß ich, bestimmte Sachen kann ich machen.
Andere Sachen kann ich nicht machen. Ich kann Kontonummern
nicht sagen, wenn es als Intager definiert wäre,
welchen Sinn ergibt es
Kontonummern zu addieren
Keinen. Welchen Sinn ergibt es von Kontonummern 1 abzuziehen?
Auch keinen. Also es ist kein Intager.
Es ist eine Menge von Zahlen und die kann ich vielleicht
mal positives Beispiel zu nennen, kann eine Prüfziffer bilden.
Weil nicht jede Zahl ist eine Kontonummer. Da gibt es
also eine Systematik. Da gibt es ein fachliches Regelwerk,
also wie eine kontonummer bestimmt werden kann. Und dann ist meine Hoffnung,
dass ein Pixel hinter der Oberfläche,
wenn jemand also ein paar Zahlen eingetippt hat, wird also geprüft,
ist das eine valide Kontonummer dann wird ein Wert erzeugt.
Vom Typ Kontonummer. Und der kann auch durch das weitere System verarbeitet werden.
Das erzeugt, beziehungsweise das erhöht bei allen Beteiligten die Handlungssicherheit.
Wenn ich von dieser Stelle aus an sicher gehen kann,
das ist eine valide Kontonummer, mit der ich es zu tun habe,
dann braucht sich auch keiner im Entwicklungsteam gemüsigt fühlen,
das nochmal zu prüfen.
Da kommt ein Intager an, der behauptet,
er sei eine Kontonummer,
ist aber
gar keine
Und das erzeugt Handlungsunsicherheit. Also wenn man so früh wie möglich
solche Fachwerte erzeugen und mit diesen Fachwerten dann in der weiteren Verarbeitung umgehen.
So, es steht hier auch schön, Fachwerte bilden die grundkonstanten
in einem Anwendungssystem. Und wie diese Fachwerte gebaut werden können,
also wie die konstruktiv, wie man das konstruktiv umsetzen kann,
das steht da drupp in einer der nächsten Vorlesungen
ausführlich ansehen
Im Moment haben sie noch ein Problem. Das Problem besteht darin,
so Fachwerttypen, die sie kennen, sind halt so was
wie Integer oder Character. Und dann gibt es ansonsten Objekttypen,
aber die haben keine Wertsemantik, sondern nur streichen sie das nur,
sondern die unterliegen einer Referenz immer einen Tick.
Und das ist genau das, was wir nicht haben wollen. Also bei Fachwerten,
die sollen sich verhalten wie Werte, also mit einer Wertsemantik,
wie sie das bisher kennen aus dem Umgang mit,
wie gesagt, Integern,
Bools,
Booliens oder Charactern
So ein Entwurfsprinzip, das dabei noch eine Rolle spielt,
das ist eine Strukturähnlichkeit, die Grundidee,
wenn sie mal bis jetzt, also Behälter,
Materialien und Fachwerte betrachten,
sie wollen die sogenannte semantische Lücke zwischen dem Anwendungsbereich und dem,
was sie technisch realisieren, wollen sie kleinhalten.
Also wenn im Anwendungsbereich von einem Ordner die Rede ist,
dann möchten sie in ihrem technischen System so idealerweise auch eine klasse Ordner finden,
das ist möglicherweise so direkt dann auch nicht möglich.
Aber das ist mindestens also diese Art von Nähe,
die sie anstreben, das auf der Ebene von Materialien und Fachwerten,
dass da eine gewisse strukturelle Ähnlichkeit vorhanden ist,
so wie das hier in den Folien auch motiviert, motiviert wird.
So, ups, Alter, das habe ich jetzt gemacht.
Das war mein Schreibtisch. Der sieht nur auf den ersten Blick
unordentlich aus. Der Schreibtisch ist Im Sinne der Begrifflichkeit,
der Elementtypen, was ich bis jetzt dargestellt habe,
was ist denn das eigentlich?
Was ist mein Schreibtisch? Wer ist für Werkzeug?
Wer ist für Fachwert? Wer ist für Service
Wer ist für Material? Wer möchte, der sich
die Frage nochmal wiederhole? Ich stimme dem Kommilitonen zu,
der sich für Material entschieden hat. Mein Schreibtisch ist natürlich ein Material,
das war eine besondere Art von Material, ein Behälter.
Und wie das auf den Folien gerade stand, Behälter,
ist nicht notwendigerweise eine Müllkippe, kann aber eine sein,
jedenfalls für den unbedarften Betrachter.
Für mich ist er ja
ein Ordnungskriterium dahinter
Dass ich jetzt nicht erläutern werde. Ich werde ihnen viel
mehr noch erläutern, die fachlichen Services, dass das ist.
Die Services, sie sehen hier, dass die eigentliche Definition ist,
es sollen fachliche Dienstleistungen angeboten werden und zwar systemweit.
Also Materialübergreifende Operationen, wie das Beispiel Kundenstamm oder eine Kontenverwaltung.
Und diese Art von Begrifflichkeit oder diese Art von Beispielen legt schon nahe,
Das nur jeweils ein Exemplar von einem Service existiert werden,
von den Materialien typischerweise mehrere existieren.
Wenn die Services Referenzen auf Materialien liefern,
dann tun sie das auf die Originale und nicht auf Kopien.
Also wird sie in den Übungen dann auch weiter beschäftigen,
wenn ein Service ein Material herausgibt, ja wo ist es denn dann?
Wie sind es hier so aus dem, die ganze Begrifflichkeit liegt ja nahe,
also der Service, der Kontoservice gibt das Konto her,
so ist es dann noch im Kontoservice oder Es ist jetzt im Werkzeug.
Und was ist denn keine besonders esoterische Frage,
sondern es ist ja dann auch die Frage,
wenn ein Service ein Konto mal herausgegeben hat,
kann ein anderes Werkzeug dann auch noch kommen und sagen,
gib mir mal das Konto, lass mich mal das Konto bearbeiten.
So, und jetzt kommen Sie so mit dieser Art von Beispiel hoffentlich,
ahnen Sie, also mindestens dunkel, welche Komplexität,
also dies es mit sich bringt,
Systeme zu bauen,
die sich benutzungskonform verhalten
So, Services werden von Werkzeugen benutzt, kennen diese aber nicht.
Das geht auch aus der Benutztbeziehung, die sie grafisch gesehen haben, hervor.
So Services kennen nur andere Services, Materialien und Fachwerte.
Das ist jetzt insofern ein neuer Punkt,
weil aus der Grafik gerade ging nicht hervor,
dass Services auch andere Services kennen können.
Das, denke ich, ist aber kein,
es ist jetzt nur eine Konkretisierung,
keine Erweiterung dieser Entwurfsregeln
Dass Services, andere Services kennen können, um komplexere Dienstleistungen zu erbringen,
denke ich, ist auch ein nachvollziehbarer Gedanke.
Technisch werden diese Services an einer Stelle erzeugt und miteinander in Beziehungen gebracht.
Also das ist dann so eine, das kann man gerne
in einer solchen Start-up-Klasse, kann man das implementieren.
So, der letzte Element-Typ, für den es Regeln gibt,
beziehungsweise so nähere Bestimmungen, Werkzeuge, sie implementieren eine,
die grafische Oberfläche, die grafische Schnittstelle für die Realisierung der Benutzerinteraktion.
Und für den Moment gilt, also ein Werkzeug übernimmt genau
eine fachliche Aufgabe und das eine Aufgabe ist, naja gut,
also es ist in einem kurzen Satz gut beschreibbar.
Ja, das hinreichend weich formuliert, kurz mit nicht näher definiert,
ob das 50 oder 80 Worte sind,
gut beschreibbar
Sagen wir mal, es ist mehr so ein Appell an sie,
dass sie also sagen können sollten,
also wozu ist ein Werkzeug gut und wenn sie das können,
dann können sie ein Werkzeug in jeweils zwei Klassen implementieren,
die Werkzeugklasse und die UI-Klasse.
Die Werkzeugklasse, da steckt also so die Funktionalität so
ein bisschen des Werkzeugs drin und die UI-Klasse,
da stecken die Gui-Komponenten,
also die eigentliche grafische Oberfläche wird darin implementiert
So, jetzt gibt es noch ein paar relevanten,
noch ein paar Entwurfsregeln, also wie kriegen wir das insbesondere,
wie kriegen wir das ganze Zeug in Anführungsstrichen, oder wie kriegen wir das zusammen?
Die Werkzeuge kriegen halt Materialien,
also als Konstruktorparameter oder also die Werkzeuge besorgen sich die Materialien selbst,
also wir wissen uns, das sind jetzt so für den Hausgebrauch,
sind das so Regeln, um einfach klar zu bekommen,
wie, nicht nur, wie werden diese Systeme statisch konstruiert,
sondern wie sollen sie auch dynamisch, Da gibt es Regeln,
dass wir besser nachvollziehen können, wie funktioniert eigentlich so ein System.
Und das alles steht immer unter dem Gesichtspunkt. Ich möchte nicht
für jedes Stück Software, also den einen maximalen Einarbeitungsaufwand haben,
wenn ich mich da dran setze, weil ich überhaupt nicht weiß,
wenn das Geisteskind waren diejenigen, die dieses Stück implementiert haben.
Wenn sie sich an diese Regeln hier halten,
dann können sie auch, also Gott bewahre,
den Code anderer Leute leicht lesen und verstehen und höre und
sage,
wieder möglicherweise wiederverwenden
So, womit ich im Großen und Ganzen am Ende dieser
Vorlesung angekommen bin, ja, ist auch spät genug.
Noch scheint die Sonne und sie sind jetzt also im Unterschied
zu vor der Vorlesung, wissen sie jetzt, die Welt,
in der sie sich bewegen, besteht aus diesen vier Elementstypen.
Und diese vier Elementtypen, von denen wissen sie von jedem Einzelnen,
was es ist, wozu es gut ist und wie sie
mit den anderen Elementtypen in Verbindung gebracht werden kann.
Und mit diesen Worten entlasse ich sie und hoffe,
ich sehe sie demnächst wieder und wünsche ihnen viel Spaß bei
der Anwendung dieser Entwurfswege.
Schönen Tag noch