So, wir schwingen uns schon mal langsam ein.
Schönen guten Tag. Ich bin's wieder. Vorab eine Frage,
hat Hallo? Ich möchte nicht stören, aber wollte gleich erwähnen.
Hat Axel Schmolitzky in diesem Semester schon mal mit Sturési gearbeitet?
Ja, okay, also ich habe für,
ich erzähle ihnen die Story.
Wir haben ja
ein neues Turési-System
Was dazu führte, dass ich vor,
als ich meine erste Vorlesung gehalten habe,
hatte ich Sturési-Fragen auf einem Client entwickelt,
wo es noch keinen Serverzugang.
Okay, und für die zweite Vorlesung gab es einen neuen Server,
aber der konnte noch keine Multiple-Choice fragen.
Und ich hatte Multiple-Choice-Fragen gemacht und ich konnte die nicht übertragen.
Dann waren wir zwischendurch bei einer Aktion,
dass der neue Server und der neue Kleinen
zwar Multiple-Choice fragen konnten,
aber keine Umlaute
Das heißt, ich hatte Umlaute in meinen Texten,
das ging dann auch nicht. Gestern hatten wir dann alles geschafft,
die Umlaute gingen auf dem neuen Client und auf dem
neuen Server und auch das mit der Webadresse funktionierte auch.
Und dann haben wir den Test gemacht mit den Clickern und dann kam Wolf und sagte,
shoot, mit dem Clicker kann man keine Multiple-Choice-Antworten geben.
Deshalb haben wir heute hier keine Clicker bei,
aber lange Rede, kurzer Sinn, Sie können,
wenn Sie Laptop vor sich haben, unter dieser Adresse
Die Kurzversion, damit sie nicht das ganze Ding hinschreiben müssen,
können sich gleich auf die Frage und Antwortseite bringen und die Vorlesungsall die,
die sie angeben müssen, steht da auch 2012 in Vereins.
Ich gebe gleich auch nochmal, wenn ich umschalte und das klappt alles.
Ich bin schon ganz aufgeregt. Zeige ich Ihnen auch
einen QR-Code, also wer mit irgendwas Handy-Mesken da ist,
kann sich dann auch da reinschalten.
Okay, aber das sind ja nur die Spielereien am Rande,
was ich heute machen möchte,
ist an sich ein sehr umfangreiches Thema
Was wir hier sehr komprimiert behandeln müssen. Und ich hoffe,
wir kommen zusammen durch. Wir werden uns über objektorientierte Modellierungen unterhalten.
Ich gehe mal direkt weiter und sage, okay,
da gibt es also auch Literatur dazu, das sehen Sie nach.
Auf dieses Ding wollte ich kommen. Es geht hier bei
diesem Schaubild, was Sie schon mal gesehen haben,
darum, was man alles so objektorientiert tun kann.
Und wir hatten ja gesagt, im ersten Semester haben wir
uns im Wesentlichen mit objektorientierter Programmierung beschäftigt.
Was wir heute so ein bisschen uns näher ansehen,
sind diese beiden grünen Klötze, objektorientierte Analyse und objektorientierter Entwurf.
Denn was sie eigentlich im Moment ja bis jetzt gemacht haben,
sind ja mehr so Fingerübungen, mehr so Trockenübungen.
Sie haben irgendwas nach Vorlage programmiert. Jemand hat ihnen gesagt,
programmiere das, teilweise bis runter zum Algorithmus und sie haben
das dann programmiert und wenn das dann so lief,
wie das vorgeschrieben war, dann war alles gut.
Aber das ist ja noch nicht the real thing.
Das echte Ding fängt hier an bei der Frage,
da gibt es Leute, nicht sie, sondern andere Die wollen irgendetwas.
Die haben ein Problem, die haben eine Frage,
die haben eine Aufgabe und um diese Menschen zu unterstützen,
auch Anbänder oder Benutzer genannt, sollen sie Software entwickeln.
Und das ist deutlich mehr als zu sagen, Java und Eclipse.
Und was das alles mehr ist, füllt eigentlich ein ganzes Studium aus.
Aber ich möchte heute so eine, zwei,
drei Ideen davon hier ihnen erzählen.
Denn es geht eigentlich um zwei Dinge,
die zusammenpassen müssen
Sie als Entwicklerin und als Entwickler müssen verstehen,
was los ist, was Sache ist, was ihre Aufgabe ist.
Und wenn sie das halbwegs verstanden haben,
dann kommt der ganz große Sprung in die Beantwortung der Frage.
Und wie soll jetzt dieses Software-System aussehen?
Also nicht nur einfach, wie soll der Programmcode aussehen?
Wie stellt sich hinterher das System dar? Und da wollen
wir ein bisschen was zu erzählen und üben hier.
Die Frage nach dem, wozu ist das Ganze gut,
ist jetzt nicht so eine neumodische Fragestellung oder Erfindung.
Ich habe jetzt mal so die zwei Urgesteine
Der objektorientierten Programmierung oder das objektorientierten Ansatzes ihnen hier aufgelegt,
so ganz kurz als Highlights aus der Geschichte.
Alan K. in den 60ern, ja, genialer junger Mensch,
so gerade aus dem Studium raus, beginnt seiner Doktorarbeit,
wollte was ganz Neues, Tolles machen.
Er hatte nämlich damals in den 60ern die Idee,
ich baue einen winzig kleinen Rechner, mit dem man alles machen kann.
Der ersetzt Bücher, der ersetzt Unterlagen,
den trage ich mit dir rum, mit mir rum,
Kinder haben den im Kindergarten in der Schule,
können damit programmieren
Ja. So, das war seine Vision.
Jetzt gab es natürlich Anno 60 plus, keine Rechner,
wo man das auch nur annähernd drauf machen konnte.
Also hat er gesagt, ich baue wenigstens eine Programmiersprache dazu,
daraus ist dann Smalltalk entstanden. Und diese Reactive Engine,
die er sich ausgedacht hat, das ist die Grundlage dessen,
was Objektorientierung im Endeffekt geworden ist. Und seine Idee,
und das möchte ich Ihnen sagen, seine Idee war nicht,
ich brauche mehr Technik, sondern was soll man eigentlich machen?
Man soll jetzt nicht Daten verarbeiten, sondern Rechnen soll nicht Number Crunching sein,
sondern Arbeit mit Computern, das soll Simulation von Dingen,
die wir sonst um uns haben sollen.
Bücher, Arbeitsgegenstände, das war in den 60ern die Idee, hinter Smalltalk.
Zwei norwegische Kollegen, die eine Sprache konzipiert haben,
die erste wirklich objektomorientierte Programmiersprache, Simular, also auch in den 60ern,
wollten auch nicht primär eine neue Programmiersprache, sondern eine Sprache um Hafensimulation zu machen.
Simulation für den Hafen in Oslo, der neu gebaut werden sollte.
Und dabei hatten sie die Idee, nicht eine Formel hinzuschreiben,
also zu schreiben, Funktion Hafen Oslo, Klammer auf,
Klammer zu, 10.000 Parameter, ja, und irgendwas auszurechnen,
sondern, weil man, das konnte keiner.
Wir hatten die Idee, wir bauen die Dinge,
die es im Hafen gibt, in Software nach.
Wir bauen Schiffe, Lastwagen, Hafenanlagen,
die bauen wir in Software nach,
denen geben wir so ein bisschen Verhalten und dann lassen wir diese Softwareobjekte gegeneinander laufen.
Kommt ihnen vielleicht ein bisschen bekannt vor,
war die fachliche Motivation hinter der ersten wirklich objektorientierten Programmiersprache
So, was ist danach gekommen? Danach gab es ganz lange große Diskussionen darüber.
Wie geht man mit diesem Programmiersprachen um? Das heißt,
zum ersten Mal hat man also nicht nur geredet, über wie programmiere ich?
Sondern was mache ich mit dieser Art von Programmiersprachen?
Es gab heiße Diskussionen, es gab jede Menge unterschiedliche Ansätze.
Ich habe Ihnen mal hier die Namen aufgelistet,
wenn Sie bei den einschlägigen Internetbuchhandlungen nachsehen,
wenn Sie einen Großteil dieser Bücher nicht nur finden,
sondern auch immer noch heute in den rängen von IT-Literatur wiederfinden.
Die waren stilbildend, könnte man sagen. Aber es waren
heiße Auseinandersetzungen. Also wenn man in dieser Zeit,
in den 80ern auf einer Konferenz über Objektorientierung war,
dann haben sich die Leute so richtig in die Haare gekriegt und die einen haben gesagt,
was du machst, ist völliger Mist.
Und die anderen haben gesagt, ihr habt ja überhaupt nichts
verstanden von Objektorientierung. Das ging wirklich munter zu. So,
dann kam die UML, also nicht nur Klassen- und Objekthiagramme,
sondern einige große Firmen haben sich zusammengetan und haben gesagt,
diese ganzen unterschiedlichen objektorientierten Ansätze, das bringt es doch alles nicht.
Die einen entwickeln so, dann wechseln sie die Firma,
dann sollen sie
ganz anders entwickeln
Ihr Gurus, die ihr diese Ansätze vertretet,
bitte setzt euch zusammen und kommt erst aus eurem Konferenzraum wieder raus,
wenn ihr in eine gemeinsame Methode gefunden habt.
So eine richtige Methode ist nicht draus geworden, aber zumindest eine gemeinsame Darstellung.
Jetzt bekannt als UML, Unified Modeling Languages. Ich habe
schon mal gesagt, da kann man sich drüber streiten,
aber man kann sich nicht über die Bedeutung streiten, nämlich,
dass das heute so die Standardnotation ist, die wir überall verwenden.
Und eigentlich kann man sagen, dass mit der UML die Diskussion über,
wie entwickelt dürfte man eigentlich objektorientiert, dass diese Diskussion abgeflacht ist.
Also wenn sie in neuere Literatur reinschauen, sehen,
was ist da zurzeit in der Diskussion?
Was ist populär? Natürlich agiles Vorgehen in Projekten,
immer wieder gut für ein neues Büchlein, Design-Patterns,
das, was Erich, Gamma und andere gemacht haben.
Da werden sie ja das eine oder andere hier hören oder
haben schon gehört. Und schließlich so Spezialthemen wie Testen,
Qualität sich sichern und objektorientierte Metriken, um Software zu vermissen.
Das sind also im Moment die Dinge,
die in der Literatur
bekannt sind
Ich will Ihnen heute so zwei Blickrichtungen nahe bringen,
sehr viel an Literatur kann man in eine von den beiden Kisten reintun.
Sehr IT-lastig, die strukturorientierte Sichtweise, die sagt,
ich muss mein Problem auf der technischen Ebene lösen.
Ich habe da Technik, ich habe Daten,
ich habe Programme und ich muss sehen,
dass das alles vernünftig organisiert ist.
Ich übertreibe aber nur, damit das klar ist.
Also die Leute gucken auf Daten und wie sie im Rechner verarbeitet werden.
Die anderen sagen, wir müssen anwendungsorientiert nachdenken und das heißt,
wir müssen aus dem Anwendungsfeld kommen mit unseren Vorgehensweisen
So, das ist jetzt nicht nur eine Glaubensfrage oder
die einen haben die Anzüge an und die anderen,
die Ringelpullis oder so, sondern das beeinflusst sehr stark,
wie hinterher die Software aussieht.
Nicht nur von innen, sondern auch von außen.
Und das wollte ich Ihnen an Beispielen ein bisschen charakterisieren.
Und ich wollte Ihnen auch zeigen, okay,
wir sind hier in der Anwendungsorientierten Fraktion.
Wir haben da auch ein paar Ideen zu,
die haben sich schon explizit oder so eingeträufelt im Laufe der
letzten anderthalb Semester kennengelernt.
Ich wollte das heute nochmal explizit machen
So, das Kind hat auch einen Namen. Wir haben seit vielen,
vielen Jahren dazu publiziert und haben das vor allen Dingen auch
in der Praxis in ganz, ganz vielen Projekten angewendet.
Der Werkzeug- und Materialansatz, Abkürzung wann für Werkzeug, Automat, Material.
Das wird Ihnen hinterher ein bisschen mehr sagen als jetzt.
Das ist also der Ansatz, nach dem wir Software-Systeme entwerfen,
sowohl so ein bisschen in den Übungen als auch dann später
im Studium und eben parallel in vielen kommerziellen,
professionellen Projekten
Ich will da jetzt nicht tiefer drauf eingehen.
Es gibt Lehrveranstaltungen wie die SPT-Lehrveranstaltung. Da wird das thematisch
ein Stück ausgewalzt und auch sonst in ihrem Studium wird ihnen,
dass das eine oder andere Mal noch begegnen,
aber damit sie zumindest so die Grundideen kennen,
nach denen sie dann auch in den Übungen auch im zweiten Teil Software entwickeln könnten oder sollen.
Wollte ich was dazu sagen. So, was ist
anwendungsvolle Türen? Eigentlich was relativ simpel,
wenn man sich einmal auf diesen Standpunkt stellt oder sich damit
vertraut macht
Wir meinen, dass das der wesentliche Ansatz ist,
um qualitativ hochwertige Software zu bauen und nicht nur hochwertig in
der Benutzung, sondern auch in der internen Struktur.
Das möchte ich so ein bisschen verdeutlichen.
Denn der Standpunkt sagt, wenn ich Software entwickle,
dann tue ich das ganz selten für mich alleine.
Wenn ich professionell arbeite, sondern ich soll anderen Menschen irgendein Hilfsmittel bauen.
Ich soll für die Software entwickeln und was wollen die mit Software?
Die wollen nicht, wie ich programmieren, sondern die wollen mit Software ihre Aufgaben erledigen.
Und Software ist dann gut, Wenn die anderen,
die Anwender, die Benutzer, ihre Aufgaben damit gut erledigen können.
Vielleicht besser als vorher, schneller als vorher,
fehlerfreier als vorher oder überhaupt, was sie vorher manuell so nicht konnten.
Und für uns mit diesem Ansatz verbunden ist die Frage,
was muss ich alles machen? Wie muss ich meine Anwendungssoftware gestalten,
damit Menschen in ihren Aufgaben, an ihrem Arbeitsplatz optimal unterstützt werden?
Das ist also die Leitfrage. Wenn ich das nicht positiv beantworten kann,
Ist mir die ganze Diskussion über C-Sharp versus Java relativ schnuppegal.
Also wenn Software schlecht ist, ist es für mich gleich,
ob sie in Java schlecht gebaut ist oder in C-Sharp oder in C-Plus Plus.
Wenn sie Leute bei ihren Aufgaben nicht unterstützt.
Das ist so die Grundidee. Ja. Diesen Werkzeugmaterialansatz,
den haben wir wirklich entwickelt,
sowohl auf der Forschungsatte als auch auf der Praxisseite,
in Zusammenarbeit mit Leuten, die in ihrer täglichen Arbeit,
also nicht für Kommunikationssoftware, Auch nicht für Spielesoftware,
sondern die in ihrer täglichen Arbeitssoftware einsetzen mussten sollten, wollten.
Ganz wichtig ist dann die erste Einsicht, okay,
Anwender haben verschiedene Aufgaben zu erledigen. Und die Frage besteht jetzt,
haben alle die gleichen Aufgaben oder haben sie unterschiedliche Aufgaben?
Und sehr oft,
wenn sie in ein Unternehmen kommen oder in eine Organisation,
wenn sie feststellt, die Organisation als Ganzes verfolgt zwar irgendein Geschäftsziel,
aber die Menschen,
die dort arbeiten,
haben unterschiedliche Aufgaben
Unterschiedliche Arbeitsplätze. Und daraus ergibt es sich schon mal als erstes so,
für uns die Schlussfolgerung zu sagen,
wenn es unterschiedliche Aufgaben und unterschiedliche Arbeitsplätze gibt,
dann darf die Software an sich nicht für alle Uniform aussehen.
Dann dürfen nicht alle vor sich immer nur genau das Gleiche sehen und das Gleiche machen können.
Das ist schon einmal eins. Das andere ist,
wenn man sich damit beschäftigt,
was tun Leute in ihrer Arbeit, dann stellt man fest,
auch wenn so auf einer abstrakten Ebene die Aufgabe einer Organisation
mittel- bis langfristig beschrieben werden kann.
Also eine Autovermietung vermietet Autos, Punkt.
Die hat vor 20 Jahren Autos vermietet und ich nehme an,
in fünf Jahren werden die auch noch Autos vermieten.
Also die werden nicht Hamburger verkaufen. Vielleicht werden sie auch
Herrn Bürger verkaufen, aber sie werden vermutlich weiterhin Autos vermieten.
Was sich entscheidend geändert hat, sind die Bestimmungen und die Prozesse,
wie die Autos vermietet werden. Gib Ihnen ein Beispiel,
weil wir haben hier mit einem großen Autovermieter in Hamburg gearbeitet. Ein Beispiel,
was relativ eingreifend für die ganze Organisation war,
Wir haben mit einem Autovermieter gearbeitet, um an Autos zu kommen,
die die vermitteln können, haben die mit großen Firmen,
also nehmen wir mal, ist ja nun keine Werbung,
ist ja eine große deutsche Firma, VW oder BMW,
haben die sogenannte Buy-Back-Verträge gemacht.
Die Verträge sahen so aus, die haben mit VW ausgehandelt,
wir kaufen zum nächsten Quartal von euch 10.000 Autos,
die setzen wir ein Jahr ein,
dann haben die maximal 25.000 Kilometer gelaufen und wenn diese Autos nicht mehr als 25.000 Kilometer gelaufen haben und keinen schweren Schaden hatte,
dann kauft ihr, liebe Leute von VW,
uns diese 10.000 Autos oder das,
was noch davon übrig geblieben ist,
So, das war das Geschäftsmodell. Das heißt, Autos kaufen,
vermieten, zurückgeben. Irgendwann ist jemand auf die Idee gekommen,
in einem der großen Autokonzerne, er hat gesagt,
das machen wir jetzt anders.
Wir verkaufen euch gerne zum nächsten Quartal 10.000 Autos,
aber was ihr hinterher damit macht, ist euer Bier.
Das heißt, nach wie vor hat dieser Autoverleih Autos vermietet,
aber hatte sich auf einmal darum zu kümmern,
was sie jedes Quartal mit ungefähr 10.000 bis 15.000
Autos machen,
wie sie die wieder loswerden
Ganz andere Aufgaben, ganz andere Arbeitsprozesse. Und das war nicht damit,
dass die Software, die jetzt Autos vermietet und verwaltet,
auf einen Schlag für die gleiche abstrakte Aufgabe konkret ganz anders aussehen muss.
Und das ist das Thema, mit dem wir uns,
wenn wir anwendungsorientiert Software entwickeln, vorrangig auseinandersetzen müssen.
Nämlich, wie bauen wir Software,
die an eigentlich nicht vorhersehbare Änderungen relativ leicht angepasst werden kann.
Denn diese Firma wäre relativ zum Stillstand gekommen oder die wäre zum Stillstand gekommen,
wenn das bedeutet hätte, okay, alle Software,
die ihr habt, haben ja,
könnt ihr die wegwerfen und ihr braucht komplett neue Software,
allen euren Arbeitsplätzen.
Das hätte keine Firma überstanden. Gut. So, jetzt kommt
das große Ereignis. Mal sehen, was jetzt hier passiert.
Ja. Ja. Okay. Jetzt versuchen wir das mal
zusammen. Wer sich hier dieses QR-Codes bedienen will?
Oder vorhin das angegeben hat
Die Internetadresse, der sollte jetzt auf einer Abstimmungsseite lang QR-Code-mäßig
einigermaßen dabei, wird er erkannt.
Einige kämpfen noch. Okay, also sie sollten jetzt
auf einer Abstimmungsseite landen
Jetzt starte ich diese Abstimmung. Und jetzt können Sie also
mehr als eine Antwort geben. Ich hoffe,
Sie können es einigermaßen lesen, können Sie es lesen?
Okay, also überlegen Sie sich, ich habe jetzt
so einiges erzählt, blumige Worte.
Was sind die Merkmale der Anwendungsorientierung? Ich lese nochmal vor
. A, Entwickler müssen die Aufgaben der Anwender verstehen.
B, Anwender müssen die Aufgaben der Entwickler verstehen.
C, die Auswahl der Programmiersprachen und der Technologie
ist zentral
D, der Zweck eines Programms ist entscheidend.
E, Anwendungssoftware soll die Aufgaben und Arbeitsprozesse unterstützen.
F, Aufgaben und Arbeitsprozesse müssen an die Software angepasst werden.
Das ist jetzt nicht so aufgebaut, dass glasklar die
richtigen Antworten von den falschen idiotischen Antworten zu unterscheiden sind.
Also was da steht, ist alles nicht sinnlos.
Nur versuchen Sie mal nachzuvollziehen,
was ich Ihnen über Anwendungsorientierung gesagt habe und was würde aus
Ihrer Sicht
dann Anwendungsorientierung charakterisieren
Für Softwareentwicklung allgemein auch nützlich sein.
Ja. Ich hoffe,
das funktioniert jetzt
Musik Okay. Soweit so gut. Haben Sie soweit
Sie wollen abgestimmt? Wer deckt noch nach?
Ist denn keiner mehr nach? Ich sage jetzt nichts dazu
Abstimmung gestoppt. Wow. Okay, das sind also
die Antworten, die wir gekriegt haben. Also sie sind
der Meinung, Entwickler müssen die Aufgaben der Anwender verstehen.
Zweck eines Programms ist entscheidend. Anwendungssoftware soll die Aufgaben und
arbeitsplatzprozesse unterstützen. Und dann kommt Aufgaben und Arbeitsprozesse, müssen
in die Software angepasst werden. Und dann kommt Anwender,
müssen die Aufgaben der Entwickler verstehen.
Ja, dann schauen wir doch mal
Okay. Weshalb ist das andere nicht unsinnig? Will ich
also auch noch kommentieren? Natürlich ist es auch ganz wichtig,
aber nachrangig wichtig aus Sicht der Anwendungsorientierung, dass Anwender verstehen,
was Entwickler machen, machen können und nicht machen können.
Sie bekommen oft in Projekten,
wenn sie mit sehr unerfahrenen Anwendern arbeiten, kriegen sie so ein,
sagen wir,
Geburtstags- oder Weihnachtswunschzettel
Wer also unerfahrener Anwender ist,
der kennt Software meistens als Spiele-Software oder aus dem Kinderzimmer.
Und die Leute kommen dann mit fantastischen Ideen, was ihre Software
alles können sollte. Das ist das eine. Das andere,
was genauso schlimm ist, ist, wenn sie irgendwo hinkommen,
wo die Leute bis jetzt vor so alten Bildschirmkanonen gesessen haben,
somit zahlenweise Eingabe.
Und sie reden mit denen, was sie an neuer Ausleihverleih-Software haben möchten.
Und die Leute sagen, also was ich mir schon immer gewünscht habe,
ist, dass die Kundennummer nicht rechts unten steht,
sondern auf dem Bildschirm rechts oben.
Das ist auch nicht das, was wir haben wollen.
Also es ist schon ganz gut für die Anwendung auch ein bisschen verstehen,
was die Entwickler können, anbieten können, was sie nicht können.
Aufgaben und Arbeitsprozesse an die Software anpassen, ist natürlich eine Sicht,
die sie ganz, ganz, ganz oft im Unternehmen finden.
Sie finden selten in Projekten eine Situation,
wo sie in eine Firma kommen und das Management sagt ihnen,
also bauen Sie mal eine Software,
dass alle unsere Leute hinterher ganz,
ganz glücklich sind
Ich will nur lächelnde Gesichter sehen, wenn ich an den Arbeitsplätzen vorbeigehe.
So muss die Software sein. Meistens kriegen sie so Anforderungen,
wie eine Sachbearbeiterin kann im Moment am Tag 15 Kreditprozesse hier abfackeln,
das muss auf 20 pro Tag gesteigert werden.
Und die sind deshalb so langsam, weil sie umständlich arbeiten
und deshalb müssen sie in die Software schnellere Prozesse einbauen.
Und die Leute müssen sich an die Vorgaben halten,
was sie im Einzelnen tun
Die anwendungsorientierte Sicht ist weder das Allheilmittel noch das,
was sie heute allgemein und überall finden.
Also, aber das ist ja schon mal ganz gut.
Okay. So. Wenn wir uns also jetzt auf den Standpunkt
der Anwendungsorientierung stellen und loslegen wollen und sagen,
wir wollen Aufgaben von Menschen unterstützen an ihren Arbeitsplätzen,
dann müssen wir im Regelfall analysieren,
was tun die Leute,
weil meistens wissen wir das nicht
Und da fängt das erste große Problem an.
Das Problem besteht darin, dass wir eigentlich nicht jenseits von
Informatik und Programmieren darin ausgebildet sind, andere Arbeitssituationen zu kennen.
Gewinnesten von Ihnen, die im Studium gearbeitet haben,
so aus meiner Erfahrung, arbeitet in ganz anderen Bereichen,
sondern die meisten arbeiten ja sehr IT-ner.
Wenn wir aber jetzt in so einer Autovermietung kommen und sagen,
wir sollen dann eine neue Software für entwickeln,
müssen wir erstmal verstehen, was machen die?
Was haben die für Ziele?
Welche Zwecke müssen sie erreichen
Von diesen allgemeinen Vorstellungen müssen wir bei den Aufgaben drankommen.
Ganz wichtig ist jetzt zu verstehen, dass eine Aufgabe ja
noch nichts Konkretes ist. Wenn ich sage,
du sollst im nächsten Monat 50 Autos verbieten oder 500,
ist ja damit noch nicht klar, was die Person tut,
die ich angesprochen habe.
Sondern wie diese Aufgabe funktioniert, sehe ich ja erst,
wenn ich den Arbeitsprozess erkenne, um diese Aufgabe umzusetzen.
Und sehr schnell, wenn ich irgendwo in der Organisation komme,
bin ich verwirrt, weil ich stelle fest,
eine Aufgabe wird von fünf verschiedenen Leuten auf sechs verschiedene Arten und Weisen erledigt.
So. Was mache ich jetzt mit der Information? Ja,
das Erste, was ich damit mache, ich stelle fest,
ich kann eine Aufgabe auf unterschiedliche Arten und Weise erledigen.
Das kann zu einem gleich guten Ergebnis führen. Oder es
kann zu einem guten und zu einem schlechten Ergebnis führen.
Die nächste Frage ist, kann ich überhaupt einschätzen,
ob das Ergebnis gut oder schlecht ist
Oder ob es gleich gut ist. Ich bleibe bei dieser Autovermietung.
Wir haben halt die Firma mit einer neuen Software ausgestattet,
dass sie ihre Autos auch verwalten und verkaufen konnte.
Wir haben überhaupt nicht eigentlich verstanden, was die Leute
alles machen müssen, um gebrauchte Autos zu verkaufen.
Wir haben auch nicht verstanden, wann machen sie es richtig?
Wann machen sie es falsch? Wir konnten die Software auch
gar nicht vernünftig testen, weil wir beispielsweise nicht wussten,
ob der Algorithmus um den Restwert eines Autos zu bestimmen,
ob der richtig ist oder ob der falsch ist.
Wenn da rauskommt, ein VW 4711 mit so und so viel Laufleistung und leichten Lackschäden,
der neu, sagen wir, 20.000 Euro gekostet hat,
der ist jetzt 10.000 Euro wert. Würden Sie wissen,
ob das eine vernünftige Zahl ist oder ob das Unternehmen,
wenn Sie die Autos für diesen Betrag verkauft,
in zwei Jahren und in einem Jahr bankrott ist?
Also, sehr schwierig, sehr schwierige Aufgabe,
die Sie haben
Wie kann ich überhaupt die Prozesse, die ablaufen, vernünftig analysieren?
Viele Dinge laufen für uns unverständlich. Unsere Idee dabei,
und das ist so ein Merkmal unseres Werkzeugmaterialansatzes ist,
wir gucken uns die Gegenstände an,
mit denen die Leute arbeiten, wenn sie arbeiten.
Weil daran kann man sich im wahrsten Sinne des Wortes festhalten.
Also wir sehen uns an, was tun die mit,
was die füllen, Listen aus,
die füllen Formulare aus, die schreiben Verträge,
die lassen Verträge von anderen gegenzeichnen.
Aha,
das ist so
unser Anhaltspunkt
So, ganz wichtig, außer zu verstehen,
was machen die Leute an ihren Arbeitsplätzen, mit welchen Gegenständen ist,
in einer größeren Organisation werden sehr viel Vorgänge, Dokumente,
Akten, Papiere, physisch oder elektronisch durch die Gegend geschickt.
Wer arbeitet mit wem? Wer gibt was, an wen
weiter und wozu? Macht der eine das Angebot und der
andere kalkuliert es durch oder führt der eine das Verkaufsgespräch und
macht den Vertrag fertig und gibt ihn dann irgendeiner Vorgesetzten,
die den Vertrag nur gegenzeichnen muss, Wozu dient diese Kooperation zwischen Arbeitsplätzen?
Okay. Anwendungsorientiert analysieren heißt als erstes Mal verstehen,
was ist der Bereich, um den wir uns zu kümmern haben?
Eigentlich noch spannender als die Frage, was ist der Bereich,
um den wir uns zu kümmern haben,
ist die Antwort auf die Frage, was ist der Bereich,
um den wir uns definitiv nicht kümmern müssen.
Denn wenn wir uns in unserem Autobeispiel auch noch mit
den Prozessen befassen müssen, die bei dem Autohersteller laufen,
dann haben wir richtig viel zu tun,
weil da verstehen wir noch weniger von
Also wenn wir sagen, unser Anwendungsbereich, der endet an
den Türen der Autovermietung, dann sind wir schon ganz gut dran.
Noch besser ist für uns als Entwicklungsteam, wenn wir jetzt nicht
die ganze Autovermietung betrachten müssen, sondern nur eine Abteilung.
Das wäre noch besser. Dann haben wir wenigstens so ein
etwas eingegrenzten Aufgabenbereich. So, ich habe dann gesagt,
Personen arbeiten an Arbeitsplätzen, die machen unterschiedliches,
sie arbeiten mit Dingen mit Unterlagen oder wie wir sagen
würden Materialien
Diese Personen haben Aufgaben, die werden in Prozessen erledigt,
von verschiedenen Personen. Das muss ich erst mal identifizieren.
Und so ganz unten an der Basis sind die Gegenstände,
die wir identifizieren können, mit denen die Leute dann ihre Aufgaben erfüllen.
Also das muss ich wissen. Nochmal so ein bisschen abstrakter dargestellt.
Eine Aufgabe kann in unterschiedlichen Prozessen erledigt werden, die gleiche Aufgabe.
Beteiligt an diesen Prozessen sind unterschiedliche Personen, aber ich muss
ja von der einzelnen, von der konkreten Person wegkommen.
Ich muss ja so eine kleine Ebene abstrakt darüber sein.
Das heißt also, ich muss mir überlegen,
so ein moderner Begriff ist Akteur.
Welche Akteure gibt es einen Einkäufer? Gibt es einen Verkäufer?
Gibt es einen Controller? Ich spreche zwar mit konkreten Personen,
aber die werden mir sagen,
was sie als Akteur in der Organisation machen und dann die Gegenstände.
Okay, was kann ich tun? Wie gehe ich vor
? Wie gehe ich vor, um zu verstehen,
anwendungsorientiert,
was ist da los
Da gibt es unterschiedliche Möglichkeiten. Das, was den meisten Menschen so am Ersten einfällt,
ist, ich gehe mal dahin und mache Interviews.
Okay, das ist schon mal eine gute Idee. Die DED ist so allgemein,
wie gut oder schlecht, wie schlecht sie ist,
merke ich, wenn ich in irgendeinen Bereich gehe,
sollen wir hier, ich glaube,
in meinem Rücken ein Stück weiter sitzen die Klimaforscher,
mit denen arbeiten wir auch zusammen.
Die sollten wir auch unterstützen, ein bisschen Softwarearchitektur in ihre Anwendungen reinzukriegen,
dann sind wir da hingegangen,
dann haben wir mit den Leuten Interview gemacht,
was macht ihr denn so als Klimaforscher?
Ja, dann haben die uns eine halbe Stunde was über Klimamodelle erzählt und haben gesagt,
danke, jetzt brauchen wir erst mal zehn Kaffee,
um zu verstehen, was wir alles nicht verstehen.
Wir haben nämlich nichts verstanden von dem, was wir uns erzählt haben.
Also wie die verschiedenen Wolken und Wellenmodelle und don't know.
Also Interviews, immer ganz gut,
aber manchmal muss man sich sehr lange vorbereiten,
eben ein Interview führen kann,
den man überhaupt mitbekommt,
was die Leute machen
Exemplarisch, Geschäftsprozessanalyse zeige ich Ihnen gleich ein Bild. Etwas,
was Informatiker und Innen, meistens die Informatiker,
die Innen haben damit aus meiner Erfahrung weniger Probleme,
was die am Anfang immer zum Haarausfall kriegen, finden,
wenn man Rollenspiele einführt.
Rollenspiele, was ist das? Nehmen Sie mal an,
Sie sollen verstehen, wie läuft ein Kreditprozess in der Bank,
wo an Privatkunden Kredite vergeben werden,
können Sie natürlich ein Interview machen mit irgendeiner Kundenberaterin.
Sie können auch sagen, ich spiele jetzt den Bankkunden Heinz Zwillighofen.
Ich setze mich in ein Zimmer mit einer Kundenberaterin und sage,
guten Tag, ich bin Heinz Zwillighofen.
Ich bin an der Uni Hamburg Professor und ich habe im
Monat 150 Euro übrig und möchte mir eine Wohnung kaufen.
Wie machen wir das? Und dann führen wir ein Beratungsgespräch.
Das ist ein Rollenspiel. Sie lernen unglaublich viel dabei,
weil sie nach einer relativ kurzen Zeit,
wenn sie sich erstmal den Schubs gegeben haben,
weil sie relativ schnell vergessen,
dass sie in dem Spiel sind und ihre Partner gegenüber tun das auch,
kann man sehr viel lernen.
Hospitieren vor Ort für komplexere Themen, ganz wichtig,
kostet viel Zeit, viel Aufwand. Und dann immer wieder beliebt,
gerade in Hochschulkreisen, sogenannte ethnografische oder videogestützte Analysen,
also finden Studierende, Wissenschaftler immer total toll mit Kameras und so,
Leute filmen, wie sie arbeiten und das dann auswerten.
Haben wir mal gemacht für eine Dissertation hier in der Staatsbibliothek,
weil die Staatsbibliothek wollte ihre Kundenverwaltung, ihre Leser und Leserinnenverwaltung verbessern,
weil die hatten da Beschwerden bekommen und dann haben wir da Videoanalysen gemacht.
Der reine Wahnsinn, der reine Wahnsinn, kann ich nur sagen.
Werten Sie hinterher mal nach methodischen Gesichtspunkten, beispielsweise 100 Stunden Videomaterial aus,
so gefilmt am Kundentresen von so einer Bibliothek.
Also erst mal muss man die 100 Stunden aufnehmen und dann
muss man die 100 Stunden auswerten und muss irgendwas Systematisches erkennen.
Statistiken drüber machen. Okay. Ja, exemplarische Geschäftsprozess,
Modellierung, So ein Ansatz, der auch bei uns mitentwickelt worden ist,
zusammen mit einer Firma, die sehr viel Prozessmodellierung macht,
die Idee dabei, ich will da gar nicht tiefer drauf eingehen,
das kriegen sie auch irgendwann im Studium mal ein bisschen genauer mit.
Die Idee dabei ist, ich habe so erkennbare Dinge,
wie so Piktogramme von Personen.
Und ich habe Nummern dazwischen und ich erzähle eine kleine Story,
also im, wo fangen wir denn mal an?
Naja, im Schritt der Fachbereichsplaner gibt im Schritt 4
das sogenannte Leertableau an den Fachbereichs Leerplanungsbeauftragten
wahnsinnig spannendes Thema
Ja, wir werden hier Stundenpläne und Lehrveranstaltungen organisiert.
Haben wir mal damit modelliert. Ja, die Situation ist,
man schreibt sich so eine kleine Szene auf, ja,
und spielt die mit den Beteiligten durch.
Was passiert, damit hier insgesamt die Lehrplanung am Fachbereich zustande kommt?
Wer ist beteiligt? Da gibt es also einen Lehrplaner,
Fachbereichsplaner, der steht da in der Mitte und dann gibt es die Lehrveranstalter,
jemanden für mich und dann gibt es das Rechenzentrum, die müssen hinterher,
das irgendwie fürs Netz aufbereiten und in Schritten das so durchgespielt, 1,
2, 3, 4, 5, kann man den Leuten relativ einfach erklären.
Und sie sehen da so mit Pfeilen so elektronische Dokumente, die weitergegeben werden.
Und es gibt Dokumentsymbole, wie das abgesegnete Lehrtableau unter 4.
Das ist also offensichtlich ausgedruckt. Und das wird dann
in Schritt 4 weitergegeben. Gut. Solche Bilder können sie
auch in Workshops mit Leuten zusammen mit unterschiedlichen Leuten entwerfen.
So, das hier ist jetzt eine andere Sicht,
das wollte ich mal so als Kontrast jetzt nicht gut böse.
Ein anständiger Softwareentwickler oder eine Entwicklerin würde nicht so ein Bild
mit Symbolen und Personensymbolen machen, sondern anständiger Softwareentwickler würde ein UML-Diagramm machen.
Ein Aktivitätsdiagramm. Das ist also etwas näher an unserer Begriffswelt
mit und und oder Entscheidungen und man fließt irgendwie so einen Entscheidungsluss oder ist es ein Kontrollfluss?
Man weiß es nicht so genau und dann gibt es also Abfragen,
das sind oben diese Rauten und wenn ja,
dann geradeaus weiter, wenn nein, dann wieder zurück,
ist sehr viel näher an dem, wie wir ausgebildet worden sind,
zu denken, ist aber ziemlich weit weg von dem,
was sie beispielsweise in diesem Fall mit einer Bibliothekarin diskutieren können.
Denn ehe sie der guten Frau erklärt haben,
was der Unterschied zwischen einem exklusiven und einem inklusiven Oder ist,
dann ist es schon ziemlich spät am Nachmittag geworden.
Und wie 2-Oder-Verknüpfung mit einer Unverknüpfung insgesamt zusammenhängen und was das bedeutet,
da brauchen sie dann den nächsten Vormittag für.
Jedes Diagramm hat seinen Sinn. Das eine ist,
würden wir sagen, eher anwendungsorientieren.
Das andere ist eher Technikner. So, jetzt,
kurz vor der Pause, versuche ich wieder hier.
So, Nummer 2. Abstimmung gestartet. Was gehört zur anwendungsorientierten
Analyse? Also was habe ich die letzten 10 bis 15
Minuten hier vorne erzählt? Was gehört dazu? Die Entwickler
analysieren die Arbeitsprozesse der Anwender
Oder B, die Anwender beschreiben ihre Arbeitsprozesse in einem eigenen Dokument.
Jetzt sollte ich sagen, und, oder, oder und.
Und oder die Begriffe des Anwendungsbereichs sind Grundlage der Entwicklung.
D, die Begriffe des Anwendungsbereichs müssen durch die Entwickler vereinheitlicht werden.
E, Arbeitsprozesse werden von den Entwicklern in UML-Modellen
beschrieben und dann mit den Anwendern diskutiert. F,
Arbeitsprozesse werden als Kooperation zwischen Akteuren mit den verschiedenen Materialien beschrieben und gehe,
aus den Arbeitsprozessen werden die unterschiedlichen Datenflüsse herausgezogen und beschrieben.
Was ist aus Ihrer Sicht charakteristisch oder was gehört zu einer anwendungsorientierten Analyse?
Wie gesagt, es sind nicht sinnige und unsinnige Fragen,
sondern die einen sind stärker anwendungsorientiert und die anderen sind nicht so sehr anwendungsorientiert.
Also, Musik Musik Musik Okay. Einige geben noch an
. Gut. Dann schauen wir mal. Aha. Also
, so sieht es aus
Ja, also die Entwickler analysieren den Arbeitsprozess der Anwender,
ganz wichtiges Thema. Die Anwender beschreiben ihre Arbeitsprozesse in einem
eigenen Dokument. Das ist vielleicht nicht das Optimum,
das ist aber das, was sie in vielen Organisationen finden.
Da gibt es also meistens auf der Anwenderseite auch nur eine sogenannte Orga-Abteilung,
die das dann auch für die Anwender tut. Das Problem ist nur,
dass sie damit ein Wechselseitiges Verständnis zwischen Entwicklern und Anwendern natürlich nicht herstellen,
so einfach, sondern Ich habe das erlebt, mehrfach,
man bekommt als Entwicklerteam teilweise so zwei bis drei Aktenordnungen,
von Prozessbeschreibungen, von der Orga-Abteilung.
Und dann sitzen sie mit diesen Aktenordnern da und wissen nicht,
wo oben und unten ist.
Okay, die Begriffe der Anwendung sind Grundlage der Softwareentwicklung,
glaube ich, hieß es. Ja, das ist ganz schön.
Wir werden dann noch gleich ein bisschen was zu sagen,
wenn Sie sich an wirklich den Begriffen des Anwendungsbereichs orientieren,
die Begriffe des Anwendungsbereichs müssen durch die Entwickler vereinheitlicht werden.
Das ist natürlich eine Tendenz, Entwickler und Entwicklerinnen immer gerne haben.
Bin also sehr unterschiedliche Begriffe oder Erläuterung über Begriffe vorherrschen in der Organisation.
Ich erinnere mich, gehen Sie mal in eine Bank,
gehen Sie mal in eine Versicherung und sagen, bei einer Versicherung,
was ist ein Kunde oder in eine Bank und sagen,
was ist ein Konto und je nachdem,
in welcher Abteilung Sie sind, kriegen Sie völlig unterschiedliche Antworten.
Und wenn man so in der Wolle gefärbter Entwickler ist,
dann sagt man,
dieses ganze Durcheinander,
wir bringen da jetzt mal Ordnung rein
Dann wählen sie Begriffe, die hinterher kein Mensch mehr versteht,
außer ihnen selbst. So, Arbeitsprozesse werden von Entwicklern
in UML-Modellen beschrieben und dann mit den Anwendern diskutiert.
Sehr vorherrschend. Die Frage ist nur, was verstehen Anwender davon?
Arbeitsprozesse werden als Kooperation zwischen Personen, Austausch von Dingen beschrieben.
Habe ich was zu erzählt? Und aus den Arbeitsprozessen
werden die unterschiedlichen Datenflüsse herausgezogen und in Programmen umgesetzt.
Zeige ich Ihnen gleich noch ein Beispiel zu, um zu sagen,
Es ist eine sehr häufige Art Software zu entwerfen und zu entwickeln.
Das führt aber zu manchmal Schwierigkeiten. Okay, ja,
das erstmal dazu. Und hallo. Bevor wir auf
dieses Thema kommen, 5 Minuten Pause.
So, okay. Damit ich gleich nicht so furchtbar überziehe,
fange ich schon wieder an,
mich etwas warm zu reden
Spannend, drei Uhren, drei unterschiedliche Uhrzeit,
das ist ja auch schon mal wieder ganz gut.
Ich hatte vorhin gesagt, wenn wir jetzt uns mit
der Analyse der Aufgaben, des Anwendungsbereichs zu beschäftigen,
dann muss das ja mit Sinn und Zweck sein.
Also das eine ist, Sinn und Zweck der anwendungsorientierten Analyse des Anwendungsbereichs ist,
dass wir als Entwickler verstehen, was passierte überhaupt.
Wenn wir das nicht verstanden haben,
können wir
keine Software entwickeln
Aber das Zweite ist, und das ist halt so diese Grundidee des Werkzeugmaterialansatzes,
wenn wir schon die Dinge erkannt haben,
die wesentlichen Begriffe erkannt haben, die wesentlichen Konzepte erkannt haben,
die die Leute in ihrer Arbeit verwenden,
dann können wir die doch als Grundlage unserer Software-Systeme nehmen.
Und zwar nicht nur, dass dann ein Begriff wie Konto anlegen,
den die Leute in der Bank verwenden,
dass so ein Begriff im Menü irgendwo auftaucht,
Sondern ein ganzes Stück weiter,
dass es irgendwo vielleicht eine Klasse gibt, die Konto heißt,
und dass es an der Klasse eine fachliche Operation Konto anlegen oder Anlegen gibt.
Und dass, wenn so ein Ding mit dem Dynautiker im Hafen
die Einkommenden und ausgehenden Schiffe und ihre Verweilzeit an der Kai-Anlage planen,
wenn die sowas Segelliste nennen,
obwohl seit 100 Jahren im Hamburger Hafen vermutlich kein Segelschiff mehr angelegt hatte,
vielleicht ist 100 zu viel,
aber so ungefähr
Dann nennen wir dieses Ding auch in unseren Programmen Sägelliste.
Und nicht Zeit planen oder Kai Belegungsplan. Wir nennen das Sägelliste,
weil dann haben wir einen engen Bezug zwischen den Dingen,
den Begriffen, mit denen die Leute jeden Tag arbeiten und unseren Programmen hergestellt.
Das hat zwei große Vorteile. Der erste Vorteil ist,
wenn ein Nautiker und ein Lotse mit unserem Programm arbeitet und
der sieht irgendwo Sägelliste und dann klickt er da drauf und dann kommt Ein Ding erscheint an der Oberfläche,
was so aussieht wie eine Sägeliste, die er noch auf Papier kennt,
dann wird er sagen, okay, da habe ich eine Vorstellung von.
Das ist die eine Seite. Die andere Seite ist,
wenn jemand kommt und sagt, wir haben uns die Gangplanung für die Sägeliste,
die haben wir uns jetzt anders überlegt.
Wir verteilen die Arbeitsgruppen, Gänge genannt, die verteilen wir
jetzt anders auf die Schiffe. Wenn wir das sauber strukturiert haben,
wenn wir eine Sägeliste haben und an dieser Sägelistende Gangplanung,
dann wissen wir,
an welchen Stellen wir
die Software überhaupt anpacken müssen
Und haben nicht, wie das berüchtigte Jahr 2000-Problem,
tausende Zahlen-Programmcode vor uns, wo wir uns jede zweistellige Integer-Variable ansehen müssen,
ob das eine Jahreszahl ist.
Also das heißt, Strukturähnlichkeit nicht nur an der Oberfläche,
sondern bis runter in die Architektur von Software bietet für alle
Beteiligten über einen längeren Zeitraum, große Vorteile. So,
und deshalb hatte ich vorhin gesagt, wir fangen ja ganz klein an,
wir fangen mit den Gegenständen an, von denen wir erkennen können,
dass sie den Arbeitsprozessen verwendet werden und gucken uns die genauer an.
Und wenn wir die elektrifizieren, haben wir wenigstens keinen ganz, ganz groben Fehler begangen.
Wir haben keinen Fehler begangen in der Art, dass das,
was wir als Software anliefern, hinterher völlig unbrauchbar ist.
Immerhin, auch nach aktuellen Statistiken, ist das das Schicksal
von ungefähr 40 Prozent aller Softwareprojekte, die gemacht werden.
40 Prozent aller Softwareprojekte kommen nie zum Einsatz, weil die
Software aus irgendeinem Grund nicht brauchbar ist. Das heißt,
wenn wir diesen ganz, sagen wir,
idiotenssicheren Ansatz wählen, wir gucken,
mit welchen Gegenständen die Leute ihre Arbeit erledigen und bilden diese Gegenstände
in irgendeiner geeigneten Art und Weise in Software ab und stellen das den Leuten wieder zur Verfügung,
dann können wir gar nicht so daneben liegen.
Also wenn wir so dumme Dinge machen wie bis jetzt,
so wie es früher war,
wenn ich ein Konto bei einer Bank eröffnen will,
dann muss ich ein Kontoeröffnungsformular, musste ich auf Papier ausfüllen.
Wenn ich dieses Ding nehme und als Formular auf den Bildschirm
übertrage, dann liege ich nicht ganz grob daneben.
Werde ich vielleicht heute nicht so primitiv machen,
aber so als Grundidee
Schauen Sie sich an,
welche Gegenstände die Leute in Ihrer Arbeit verwenden und versuchen,
Sie zu verstehen, was Sie damit machen.
Das ist die Grundidee. Und dann werden Sie sehen,
es gibt unterschiedliche Arten, es gibt Sammlungen für andere Gegenstände.
Es gibt Gegenstände, da werden Werte eingetragen.
Es gibt Gegenstände, mit denen bearbeite ich andere Gegenstände.
Und es gibt leider mittlerweile in unserer virtualisierten Welt sehr viel ideelle Gegenstände,
über die Leute zwar reden und von denen sie,
soweit sie Fachleute sind,
auch eine genaue Vorstellung haben,
aber die ich nicht anfassen kann
Sagen wir, das berühmt-berüchtigte Konto. Jetzt vor wenigen Jahren
hat die allerletzte kleine Dorfbank in Bavu geschlossen,
wo es noch einen Menschen, der gab, gab,
der ein Kontohauptbuch hatte, so eine Schwarte,
wo so richtig Konten noch geführt wurden, so mit Namen und Einträgen.
Da konnte man auch zeigen und sagen, das ist ein Konto.
Wenn Sie heute in eine Bank gehen und sagen,
zeig mir mal ein Konto, was sollen die Leute Ihnen zeigen?
Stück Hauptspeicher? Schwierig. Das sind für uns die unangenehmen Gegenstände,
weil wenn ich irgendwelche Formulare oder Dokumente sehe oder Berechnungen auf Papier,
da kann ich was mit anfangen, da kann ich nachfragen,
aber wenn es so um so virtuelle Gegenstände geht, wie Rendite, Rendite, was ist Rendite?
Wie sieht das aus? Riecht das komisch? So. Okay,
das du mal so als Einstieg,
wir nähern uns jetzt so dem Entwurf und ich wollte ja so ein bisschen verdeutlichen,
wie kann das aussehen? Am Beispiel an der Bibliothek,
die meisten, ich will nicht sagen,
die meisten von Ihnen waren ja schon in der Bibliothek,
ich hoffe das, aber ich will ja keiner falschen Hoffnung aussieht.
Aber die meisten sind, wenn sie in Stelligen waren und
zum Mensa gegangen sind, zumindest schon mal an der
Bibliothek vorbeigegangen
Also das Ding, wenn sie reinkommt,
was da links liegt, das ist eine Bibliothek.
Und über Jahre, über Jahre haben wir Studierende,
damit begeistert, dass sie im SE2, beispielsweise,
oder im Projekt ein Bibliothekssystem bauen sollten.
Da gab es Interviews und Entwürfe und Oberflächen, tolle Sachen.
Ja, und ich habe es auch deshalb,
weil das andere Beispiel, jetzt nicht das Böse,
sondern dieses strukturorientierte Beispiel,
gehört zu den ersten Publikationen,
die ich
selbst mit verzapft habe
Also ich rede über den eigenen Mist, wenn ich
über Mist rede. Ja, also wir haben damals,
wir waren so begeistert, dass Smalltalk und objektorientierte Programmierung.
Und dann haben wir Bibliotheksbeispiel gemacht und das war sehr strukturorientiert.
Und ich will Ihnen das kurz erläutern, damit Sie verstehen,
was ich meine, wenn ich das eine.
Oder das andere anspreche. Strukturorientiert. Wie guckt man als begeisterter Smalltalk-Entwickler,
der gerade mal lauffähige, objektorientierte Programmiersprachen in die Finger bekommen hat,
wie guckt man auf die Welt eine Bibliothek?
Naja, in der Bibliothek, die brauchen ein Stück Software,
die brauchen also ein Bibliotheksystem.
Was macht man damit? Man verwaltet Schriften,
weil das ist das, was wir natürlich kannten.
Also in der Bibliothek gibt es Schriften, gibt es unterschiedliche.
Ja, und was ist wichtig? Naja,
Schriften müssen charakterisiert werden. Und das sind die Daten,
die das Bibliotheksystem verwalten muss. Und uns hat interessiert,
wie kann man diese Daten mit einer objektorientierten Programmiersprache vernünftig verwalten,
strukturieren und welche Daten müssen im System gehalten werden und welche nicht.
Das war unsere Idee,
die wir hatten
Was haben wir also gemacht? Wir haben den Anwendungsbereich analysiert
und das ist kein Witz. Wir hatten damals,
wo ich gearbeitet habe, wir hatten eine große Bibliothek,
wir haben natürlich nicht eine einzigen Bibliothekalen gefragt,
sondern Bücher, Schriften, wir kannten uns ja aus.
Wir haben einen aus unserer Sicht fachlichen Strukturorientierten Entwurf gemacht.
Hupf, ich sollte das enfriesen, dann wird das besser.
Okay. Wir haben einen strukturorientierten Entwurf gemacht
Der so aussah. Wieso ist da rechts und links
eins? Don't know. Jetzt ist es wieder da.
Und das ist auch wieder, okay.
Ja. Also, wir haben einen strukturorientierten Entwurf gemacht.
Das sieht, klang uns damals sehr plausibel. Also,
ein Buch wird charakterisiert durch einen Kürzel,
damit man es findet im Katalog
Es gibt meistens mehr als ein Auto, also eine Autorliste,
ein Titel, ein Verlag, Ort, ja, der Erscheinung.
Es gibt technische Reports, es gibt Zeitschriften,
es gibt Buchartikel und es gibt Zeitschriftenartikel, das war also unsere Welt.
Und das sind also die fachlichen Daten, die das charakterisiert.
Hey, haben wir gesagt, das ist ja ganz nah an der Objektorientierung.
Das ist ja ganz nah an der Objektorientierung,
das sind ja eigentlich schon die Klassenentwürfe, die wir haben.
Und jetzt haben wir ja objektorientierte Mittel, Vererbung,
zack, Wir setzen Vererbung ein.
Vererbung deutet aus unserer damaligen Sicht Gemeinsamkeiten rausziehen und in Oberklassen tun.
Also haben wir die gemeinsamen Daten in die Oberklassen gezogen.
Ganz oben ist dann die klasse Schrift gelandet, da war
dein Kürzelort, ja, klasse, haben alle gemeinsam.
Und dann unten drunter spannte sich der Baum auf,
buchtechnische Reportzeitschrift, Artikel, denn einmal Vererbung,
immer Vererbung, es gibt zwei Arten von Artikel,
Buchartikel und Zeitschriftenartikel
Ja, mit dem, was sie charakterisiert. Super,
Entwurf, Vererbung so eingesetzt, dass wir, objektorientiert,
die Gemeinsamkeiten rausgezogen haben.
Und dieses Beispiel haben wir dann auch mit allem drumm und drang
beschrieben in Smalltalk implementiert und waren ganz stolz.
War auch damals mit anderen Artikeln zusammen sehr erfolgreiches Buch,
eines der ersten deutschsprachigen Bücher, über Smalltalk.
Wir waren ganz stolz. Aber dann haben wir entdeckt,
es gibt Buchreihen
Da kommt es nicht auf das einzelne Buch an,
sondern auf die ganze Buchreihe, also Lecture Notes on computing Science beispielsweise.
Wenn man die jetzt beschreiben will, charakterisieren will,
dann stellt man fest, eine Buchreihe hat natürlich nicht ein definiertes Jahr.
Oh, schade. Das heißt, wir waren so stolz
auf unsere rausfaktorisierte Eigenschaft bei Schrift mit dem Jahr.
Das heißt, erstens, wir konnten aus der Oberklasse
Ja rausnehmen und wir mussten die Unterklassen gleich mit verändern
Also eine kleine, punktuelle Änderung, Buchreihe eingeführt,
hat Effekt auf den gesamten Entwurf, auf das gesamte System.
Da kann man schon mal eins draus lernen. Die erste Nachricht,
die rüberkommen soll, ist, bitte bei Vererbung, keine schwergewichtigen Vererbungen,
machen also keine Attribute oder Zustandsfelder, danach die Vererbung aufbauen.
Wenn sich da was daran verändert, das hat so schlimme
Auswirkungen und das hier ist ja nur kleines Miniatursystem.
Also das mit dem Strukturorientierten ist vielleicht nicht so glücklich.
Ich könnte noch jetzt lange drüber weitererzählen, aber ich will
Ihnen sagen, anwendungsorientiert. Wie sieht das aus? Anwendungsorientiert,
das ist ja für heute mal ein Thema oder unser Thema,
zu sagen, okay, hier am Fachbereich gibt es eine Bibliothek,
was passiert da?
Da gibt es so zwei Seiten von Menschen, die einen,
die arbeiten da in der Bibliothek, die anderen nutzen die Bibliothek.
Und was sind die Aufgaben in der Bibliothek und vor allen Dingen,
was sind die Aufgaben,
die denn von so einem Bibliotheksystem unterstützt werden sollen
Also beispielsweise das Einsortieren von Büchern in die Regale,
wollen wir das über Software machen oder wollen wir das nicht über Software machen?
Haben wir jetzt da so Roberts rumlaufen, die,
ja, gibt es bei den Versandhandel, würde ich sagen,
ja, aber für unser Fachbereichsbibliothek overdone. Ja,
so, das heißt also,
wir befassen uns jetzt mit den Aufgaben und sehen,
okay, es gibt verschiedene Akteure,
es gibt den Akteurbenutzerbibliothek,
es gibt auch die Lieferanten und die einen haben mit Ausleihen
miteinander zu tun und die anderen haben mit der Beschaffung
miteinander zu tun
Wir widmen uns heute, weil das haben uns die Leute in der Bibliothek gesagt,
mit dem Teil, der besonders kritisch ist,
nämlich mit dem Ausleihsystem und gucken uns da die Aufgaben genauer an und sehen solche Aufgaben,
die dort erledigt werden müssen zwischen diesen Akteuren.
So, wer das auf der Ebene schon mal verstanden haben,
dann sind wir schon einen ganzen Schritt weiter,
also zu sagen, okay, ich kann die Aufgabe Vorbestellung erledigen,
ich kann die Ausleihe, die Rückgabe und für die Leute wie uns,
die immer vergessen, die Bücher zurückzugeben,
da muss es auch so was geben wie Mahnung.
Das sind die wesentlichen Aufgaben, die in der Bibliothek
unter unserem Blickwinkel ablaufen und die wir unterstützen sollten.
Gut, was sind die Gegenstände? Was sind die Gegenstände,
die auftauchen, wenn wir uns ansehen, was machen die Leute?
Ja, es gibt natürlich zum einen wirklich die Dinge,
die da rumstehen in den Regalen. Wie heißen die Dinge,
die da rumstehen in den Regalen? Die heißen nicht Schriften,
wie wir uns das in dem ersten Beispiel ausgedacht haben,
sondern die Leute in der Bibliothek sagen,
dazu sammel gut
Wäre ich nicht drauf gekommen. Aber die sagen,
da zu sammeln gut. Also heißt das für uns
sammeln gut. Und dann nehmen wir mal beispielsweise,
ein Buch ist ein Sammelbuch, ein Sammelgut, ein technischer Report,
ist ein Sammelgut und eine Zeitschrift ist ein Sommergebot.
Ganz wichtig ist die Ausleihkarte, denn die Ausleihkarte bringt zwei Dinge zusammen.
Welches Sammelgut an welchen Benutzer ausgeliehen werden soll oder ausgeliehen wurde.
Wobei, und jetzt kommt ein ganz wichtiger Einsicht,
wir modellieren jetzt nicht konkrete Menschen als Benutzer
Sondern so für die Bibliothek interessante Abbilder, Modelle von Menschen.
Weil es gab mal eine ganz heiße Diskussion,
Objektorientierung ist böse, weil da werden Menschen modelliert.
Man sollen Menschen nicht modellieren. Gab es eine ernsthafte,
lange Diskussion drüber? Und also hier ist also klar,
für die Bibliothek werden wir jetzt nicht hier jede einzelne Person modellieren,
sondern werden das von uns modellieren,
was aus Sicht der Aufgaben einer Bibliothek interessant ist.
Im Regelfall Name,
vielleicht eine Matrikelnummer oder eine Bibliotheksausweisnummer
Vielleicht noch eine Rufnummer oder eine E-Mail-Adresse.
Irgend so was in der Art. Gut. So,
und jetzt stellen wir uns als Nächstes die Frage,
was brauchen wir an Möglichkeiten mit dem Bibliotheksystem zu arbeiten,
um die Aufgaben zu erledigen?
Naja, das haben wir ja vorhin gesagt.
Also wir müssen Sammelgut ausleihen, können zurückgeben können,
Mann können verlängern können und vorbestellen können.
Das sind die wichtigen Aufgaben, die wir haben.
Und das gilt für jedes Sammelgut,
was in der Bibliothek rumsteht
Und das konkrete Sammelgut hat dann noch charakteristische Merkmale, aber da brauchen wir nichts rauszuziehen.
Das lassen wir mal schwergewichtig unten an den Blättern hängen.
Wenn wir so einen Entwurf haben, dann sind wir schon ein ganzes Stück weiter.
Dann wissen wir nämlich, unser System kann jedes Sammelgut bei der Ausleihe,
beim Zurückgehen, beim Mahnen, beim Verlängern, beim Vorbestellen bearbeiten.
Und wie das dann konkret aussieht, so what? Denn dann merken wir,
wenn wir einen Schritt weiter gehen, Wenn wir feststellen,
weil uns das die Bibliothekalen sagt,
wir leihen jetzt auch CDs oder DVDs oder was auch immer aus,
sagen wir, klasse, ja, das ruiniert nicht unseren Entwurf,
denn auch für eine DVD gilt, man kann sie ausleihen,
zurückgeben, malen, verlängern,
vorbestellen.
Welche Attribute jetzt die CDE oder die DVD beschreiben,
ist uns für unser Gesamtsystem an der Stelle völlig egal.
Das heißt, für die erste kleine Veränderung unseres Systems
hat sich der Entwurf als tragfähig erwiesen
Denken Sie anders mit der Strukturähnlichkeit, was Sie sich Ihnen vorhin gesagt habe.
Wenn jetzt demnächst, weil die Bibliothek überhaupt kein Geld mehr hat,
das Mahnen Geld kostet, dass die Tropfnasen, die es nicht schnallen,
dann irgendwann einen oder fünf Euro abliefern müssen, wenn sie überziehen.
Das heißt, der Mahnvorgang verändert sich,
dann haben wir genau eine Stelle,
wo wir den Mahnvorgang oder die Operation mannen,
verändern.
Auch das ist an sich
eine ganz gute Einsicht
So, das Letzte für heute, für die letzte Viertelstunde.
Wir haben jetzt unser fachliches, unsere fachliche Aufgabe hoffentlich erfüllt.
Wir verstehen, was im Anwendungsbereich getan wird, getan werden soll.
Wir haben uns über Arbeitsprozesse, über zentrale Arbeitsgegenstände Gedanken gemacht.
Wir haben vielleicht sogar schon eine erste Vorstellung über den
fachlichen Kern unserer Software, die fachlichen Klassen.
Aber was haben wir noch nicht gelöst?
Wie soll diese Software aussehen
Wie fühlt sie sich an? Was sehe ich davon?
Also bis hin zu so abgedrehten Sachen, die es heute gibt.
Wie komme ich von Sammelgut zu dem,
was sich an der Oberfläche darstellt? Ich kann nur sagen,
so kann mich noch ganz gut daran erinnern,
die ersten Projekte, die wir gemacht haben,
was hatten wir, wie waren wir orientierungslos bei der Frage,
wie soll die Software aussehen?
Den meisten fällt dann nichts anderes ein,
als dass sie an der Oberfläche irgendwelche Felder,
wo man Daten eingibt oder Daten rauslesen kann, anzeigen.
Aber das ist natürlich Nicht nur oldschool, das ist schon Steinzeit aus heutiger Sicht.
So, aber wie kommen wir da hin? Wie kriegen
wir eine Idee über die Gestalt von Software? Ja,
und da ist eben auch ein wichtiges Anliegen, ihnen zu sagen,
die Gestaltung von Software als eine Designaufgabe gehört zur Softwareentwicklung dazu.
Und im Regelfall werden sie in einem Team arbeiten,
wo jetzt nicht irgendwelche Industriedesigner, die Gestaltung gelernt haben,
ästhetische Gestaltung gelernt haben,
mit ihnen zusammenarbeiten,
sondern sie werden gefordert sein
Der Software eine Gestalt zu geben, dass sie aussieht,
dass man sie handhaben kann. Wie kommt man dahin?
Und das ist eine sehr, sehr schwierige Frage.
Und der Werkzeugmaterialansatz sagt, okay, eine Idee könnte ja sein,
das, was schon einige andere Leute gesagt haben,
was einige andere Schulen gesagt haben, benutzt doch Metaphern.
Metaphern sind klasse, klasse Dinge. Metaphern sind etwas,
was in unserer Sprache drinsteckt,
unsere Sprache lebt dadurch von Müttern,
indem man
sprachliche Bilder verwendet
Wenn man sagt, also das ist ja jetzt diese Idee,
ist der totale Hammer. Dann meint man ja nicht,
dass wirklich jemand mit so einem Vorschlaghammer durch die Gegend läuft.
Sondern wir nehmen das Bild hammer und übertragen das,
was so ein Hammer macht. Ja, ich kann damit zuschlagen,
das gibt eine Delle oder ich haue einen Nagel in die Wand
und ich übertrage diese bildhafte Vorstellung in einen anderen Bereich.
Eine Idee ist ein Hammer. So, und die Idee,
Metaphern für die Gestaltung von Software zu verwenden,
ist schon so alt wie das, was Alan Kay gemacht hat.
Da gab es schon die erste Vorstellung, nicht irgendwelche kryptischen Kürzel einzugeben,
sondern auf dem Bildschirm Dinge erscheinen zu lassen.
Dinge erscheinen zu lassen, die man wiedererkennt, wo man sagt,
hey, das sieht ja aus wie der Papierkorb an meinem Schreibtisch.
Was wird übertragen von dieser Idee? Naja,
in einem Papierkorb kann ich etwas hineinwerfen, ein Dokument.
Aha, statt einer Delete-Operation, die Kommando basiert ist,
habe ich jetzt auf einmal so eine Zeigehandlung.
Ich habe so ein Icon für ein Dokument,
elektronisches Dokument und ziehe das auf diesen Papierkorb.
Und dann kann man auch sehen, wie gut die Leute waren,
die diese Metaphern genommen haben und implementiert haben,
so in den frühen Windows-Zeiten war der Papierkorb kein Papierkorb,
sondern die waren Shredder.
Wenn ich da ein elektronisches Dokument reingeworfen habe, dann war das weg.
Und die Gegenfraktion von Mac und Apple hat ein Papierkorb als ein Papierkorb implementiert,
da konnte ich nämlich ein elektronisches Dokument wieder rausnehmen.
Mittlerweile haben alle was gelernt, aber will ich nur sagen,
also man kann die Metapher gut oder schlecht übertragen
Unsere Metapher im Warmansatz sind Werkzeug, Material, Automat, Behälter, Arbeitsplatz.
Da will ich jetzt noch die letzten zehn Minuten ein bisschen was drüber erzählen,
damit ihnen das ja auch so ein bisschen deutlicher wird.
Als erstes Werkzeug, deshalb Werkzeug. Naja, Werkzeug einfach deshalb,
weil also Arbeitswissenschaftler, Soziologen, Anthropologen sagen, das,
was den Menschen, die einen sagen, das,
was den Menschen zum Menschen gemacht hat oder die anderen sagen,
das, was den Menschen von Primaten unterscheidet, ist,
dass er Werkzeug einsetzt, um seine Ziele zu erreichen.
Da will ich mich jetzt gar nicht darum streiten,
was, was ist auf jeden Fall, ist unstrittig,
dass für menschliche Arbeit Werkzeuge ein ganz, ganz, ganz wichtiger Bestandteil sind.
So, und da muss man gar nicht an Handwerk denken,
sondern eigentlich jede Art von Arbeit wird heute ganz,
ganz selten nur mit den reinen Händen und irgendwelchen Materialien ausgeführt,
sondern wir benutzen werkzeugartige Dinge, um unsere Arbeit zu erledigen.
Es gibt ganz wenig Sachen, die wir nur mit unseren Händen
machen können, ohne dass wir noch etwas Werkzeugartiges benutzen.
Was ist jetzt ein Werkzeug? Weil ich meine Dissertation darüber geschrieben habe,
könnte ich jetzt den Rest des heutigen Tages mitverbringen,
weil ich fand das immer total spannend,
so als verkappter Heimwerker, was ist ein Werkzeug?
Und das fand nicht nur ich spannend,
sondern ganz viele Leute, die sich mit Werkzeugen beschäftigt haben,
haben sich die Frage gestellt, was definiert ein Werkzeug?
Was macht ein Ding dazu, dass es ein Werkzeug ist?
Ja, und es gibt ganz viele Werkzeugbücher,
wo Leute sowas gemacht haben wie hier,
die haben also
die Werkzeuge gruppiert
Haben verschiedene Ordnungskriterien angewendet. Also welche Werkzeuge sind aus Holz?
Welche sind aus Metall? Also nach den Werkstoffen, aus denen
sie gemacht sind. Andere Ordnungskriterien und das Unangenehme war,
was man auch immer an Ordnungskriterien hatte,
es hat nie gereicht, um definierend zu sein.
Das heißt, ich hatte nie ein definierendes Kriterium,
wenn ich irgendein Ding da liegen sehe, irgendetwas,
ich gucke hier in die Kiste rein und hier in der Kiste
ist irgendwas drin.
Das ist ein Gegenstand drin. Und jetzt soll ich
die Frage beantworten, ist das ein Werkzeug oder ist hier
kein Werkzeug drin
Dann hat man gemerkt, ich kann draufschauen, solange ich will.
Ich kann das physikalisch analysieren. Ich kann es schämisch analysieren.
Ich kann es vermessen. Ich werde nicht zu einer Antwort kommen.
Ist das ein Werkzeug oder ist es kein Werkzeug?
Ist Ihnen das schon mal aufgefallen, dass das nicht trivial ist?
Ich gucke mir ein Ding an und kann es nicht beantworten.
Ist das Ding ein Werkzeug oder ist das kein Werkzeug?
Als Eselsbrücke dazu denken Sie an diesen kahllauerhaften Bumerang.
Kein Mensch kann heute sagen, was der Bumerang eigentlich ist
Oder eigentlich wahr. Wir wissen, es ist von der Analyse
her betrachtet ein gebogenes Stück Holz, was bestimmte physikalische Eigenschaften hat.
Mehr können wir darüber nicht sagen. Denn die Kultur,
die das hervorgebracht hat, hat keine Bildsprache gekannt und hat
nur mündliche Überlieferungen gehabt. Und offensichtlich ist verloren gegangen,
das Wissen um, was man mit dem Ding macht.
Weil das ist der Trick dabei. Die Analyse,
die Analyse des Dings bringt mir gar nichts.
Erst wenn ich sehe, was mit dem Ding gemacht wird,
kann ich sagen, aha, dieses Ding ist ein Werkzeug
Und das andere Ding ist kein Werkzeug, sondern das ist ein Material.
Deshalb können wir, wenn wir dazu noch irgendeinen Zugang haben,
historisch oder wie auch immer, anhand dieser Abbildungen erkennen,
was sind denn die Werkzeuge und was sind die Materialien,
die damit bearbeitet werden.
Und da die meisten von uns natürlich noch, zumindest rudimentäre,
handwerkliche Erfahrungen haben, wenn die sein Aha sägen.
Gut, ah, ein Hobel, kann man Holz mit
Bretter mit Plan machen.
Historischer Zugang,
eigene Erfahrung,
ganz wichtig
Weshalb ist das ganz wichtig? Ich gehe mal in anderen Bereichen.
Also es gibt Untersuchungen darüber, dass bestimmte Schichten in der Bevölkerung
heute nicht mehr wissen, wie Nahrungsmittel in Rohform aussehen.
Ja, weil die kennen das immer nur als Fertiggericht und denken,
Tomate ist irgendwas Breiiges, Rotes. Also das heißt,
wenn ich den Zugang zur Bearbeitung dieses Gegenstands nicht habe,
kann ich so lange drauf gucken, wie ich will.
Ich kann das nicht vernünftig konzeptionell in den Griff kriegen.
Also deshalb für uns Werkzeug und Material wird dadurch definiert,
ich den Arbeitsvorrang kenne, in dem es benutzt wird.
Und damit haben wir hier auch so ein bisschen unsere Definition,
so im Kern des Werkzeugmaterialansatzes.
Es steht natürlich Werkzeug und steht Material. Also das eine benutze ich,
Werkzeuge benutze ich, um andere Gegenstände,
nämlich Materialien zu bearbeiten, um damit ein Arbeitsergebnis zu erziehen.
Das ist so im Kern menschlicher Arbeit. Und eigentlich kann man jede menschliche Arbeit,
das ist unsere Idee, daraufhin untersuchen, was sind die Materialien,
die das Ergebnis hinterher bilden und was sind die Werkzeuge,
die ich sinnvoll dazu einsetze,
um das Ergebnis hinzubekommen
Ja. So, damit sie auch noch mal konzeptionell
ein bisschen darüber nachdenken. Job, unsere vorletzte Trockenübung,
hier muss ich erst mal da wieder draufklicken,
wenn mich da draufklicken, dann mache ich alles weiterklicken,
dann muss ich das starten.
So, was sind Merkmale des Entwurfs nach Wamm,
die Gegenstände im Arbeitsprozess spielen eine wichtige Rolle.
Wichtig sind die Daten, die in der Arbeit verwendet werden.
Die Begriffe des Anwendungsbereichs sollen hauptsächlich in den Menüs verwendet werden
Die Begriffe des Anwendungsbereichs sollen in den Programmen verwendet werden.
Anwendungssoftware sollen nach interaktiver Oberfläche, Fachlogik auf dem Server und Datenbank
strukturiert werden. Ein Gegenstand kann anhand objektiver Merkmale als Werkzeug
identifiziert werden oder Werkzeuge und Materialien sind wesentliche Elemente jedes Arbeitsprozesses.
Also, ihre letzte Abstimmungsrunde für heute. Versuchen Sie sich
zu erinnern, weil das hilft Ihnen auch nochmal zu rekapitulieren,
heute gesagt worden.
Gut, das mit den Daten, hatte ich gesagt,
ist zwar wichtig, dass wir sie haben,
aber nicht vorrangig unter Anwendungs- oder Werkzeugmaterialbegriffen.
Natürlich sollen sich die Begriffe des Anwendungsbereichs auch im Menü wir finden,
aber nicht vorrangig, sondern sehr schön ist es,
wenn sie sich insgesamt in der Software wiederfinden.
Die Struktur von Software-Systemen ist wichtig,
aber unter Werkzeugmaterialaspekten nachrangig
Und leider sind wir der Ansicht und andere,
dass man nach objektiven Gesichtspunkten nicht ein Ding als Werkzeug erkennen kann,
sondern nur in seinem Gebrauch.
Okay, ich schließe jetzt das Ganze ab,
indem ich Ihnen noch ein bisschen etwas zeige,
nach der Urhunger noch vier Minuten.
Ich wollte Ihnen zwei Oberflächen zeigen, um das,
was ich hier abstrakt oder halbwegs abstrakt erzählt habe,
nochmal zu konkretisieren. Das erste Beispiel ist ein Pausenplanersystem,
was von Studierenden vor einigen Jahren, ein bisschen her.
Aber für eine Schule entwickelt worden ist,
an dieser Schule sind Behinderte und nicht Behinderte Kinder.
Die haben Pausen und diese Pausen müssen beaufsichtigt werden wegen der behinderten Kinder.
Und dafür muss es halt Lehrkräfte und Hilfskräfte geben,
die Pausenaufsicht machen. Und in dieser Schule war es ein
Riesenproblem, den Pausenplan für eine Woche zu machen.
Und die Schulleiterin hat immer mit Krankheit und irgendwelchen Reisen und weiß der Teufel was,
Stunden zugebracht an der großen Pinnwand, um Pausenplanung zu machen.
Und wir haben über zwei Semester mit Studierenden,
mit dieser Schule zusammengearbeitet. Und das ist im Endeffekt,
da ist dann auch noch damals eine Diplomarbeit zugeschrieben worden.
Dieses eingesetzte System entstanden und ich will ihn jetzt einmal kurz erläutern,
Werkzeug und Material, was ist hier Werkzeug und Materialartig.
Naja, materialartig, das sticht ins Auge.
Wir haben so einen Pausenplan-Schema, so wie die Schulleiterin,
das in ihrem Zimmer an der Wand hatte,
haben wir nachgebaut mit den Bergtagen und den Pausenhöfen,
Pausenstellen.
Und wir haben nachgebaut,
die Namenskärtchen für die Aufsichtsperson
So, das sind also im Wesentlichen,
wir machen es schlicht, das sind die Materialien.
Wir haben Werkzeuge gebaut und das erste Werkzeug ist halt
relativ trivial. Man kann aus dieser Liste von Aufsichtskräften,
kann man sich ein Kärtchen nehmen und auf den Pausenplan ziehen
und in der Pause fallen lassen.
So, jetzt gibt es aber bestimmte Regeln,
die die Schulleiterin natürlich im Kopf hatte und die natürlich nicht verletzt sein durfte.
Also sie darf nicht eine Person zur gleichen Zeit
an zwei verschiedenen Pausenplätzen einsetzen.
Das geht nicht
Das ist offensichtlich. Also das heißt also,
hier muss das System schon signalisieren und dieser Mauszeiger war halt nicht nur ein dummer Mauszeiger,
sondern das war schon ein kleines Werkzeug,
wenn sie mit einer Namenskarte über ein Pausenfeld fährt,
wo diese Namenskarte nicht untergebracht werden durfte,
dass dann das Pausenfeld dahinter rot wird.
Ganz wichtig war, aber das will ich auch noch dazu sagen,
dass die Schulleiterin gesagt hat, daraus dürft ihr aber keinen Automatismus machen.
Denn wenn ich aus irgendeinem Grund Eine Namenskarte zweimal auf zwei Pausenhöfe
zur gleichen Zeit setzen will, dann muss ich das können.
Und dann darf das System das nicht verhindern. Das ist okay,
das dann rot zu flaggen, aber ich muss es,
aus welchem Grund auch immer, machen können.
Also, wenn ich mir mit einem Hammer auf den Daumen
schlagen will, dann wird der Hammer dieses nicht verhindern.
Das ist nicht eingebaut. Ja, okay,
Werkzeug Nummer eins, hat noch viele andere nette Sachen,
will ich jetzt nicht drüber reden. Was aktuell ist,
will ich Ihnen zeigen, das ist durch die Presse gegangen,
gerade Letzte Woche wieder ganz große Pressemitteilung.
Hamburg, Port, Authority. Also die Hafenverwaltung,
die zuständig ist für die Wasserwege, die Anlagen im Hafen,
die Zugverbindungen, die Straßenverbindungen, die verwaltet den Hafen beaufsichtigten Hafen.
Und dort war ein ganz wichtiges Thema. Im Hafen
wird dauernd gebaut und umgebaut und das passieren unvorhergesehene Sachen.
Was macht man damit? Was hatten die bis jetzt
damit gemacht? Die hatten eine große Wandkarte,
die ist in etwa so groß wie jetzt das Bild,
was sie vor sich sehen.
Etwas tiefer
Eine ausgedruckte Karte, wie eine Landkarte, hingepinnt mit einer
Magnetschicht dahinter. Und wenn irgendwas war wie eine Baustelle,
dann sind die hingegangen mit einem Post-it oder mit irgendwas
und haben auf dieser Karte sich Notizen gemacht.
So, eine klasse Idee, aber nur für die Leute,
die gerade zu diesem Zeitpunkt in der nördlichen Zentrale vor
der Karte standen.
Alle anderen hatten natürlich nichts davon
Und Baustellenverwaltung ist insofern wichtig,
das ist jetzt nicht nur irgendwie so eine formale Sache,
wo man einen Bauantrag oder so irgendwas ausfüllen muss,
sondern es ist total wichtig, beispielsweise viele Baustellen werden unter Wasser bedient,
da werden Taucherplattformen hingefahren und da werden Taucher eingesetzt,
die an der Kallmauer arbeiten.
Das muss allen Beteiligten im Hafen inklusive den Lotsen klar sein,
denn wenn die jetzt einen riesen Containerschiff an dieser Stelle vorbeifahren,
dann hat A unter Umständen das Containerschiffenproblem,
weil das an dem Schwimmponton nicht vorbeikommt und was garantiert ein Problem sein wird,
Taucher unter Wasser, denen wird das nämlich nicht so gut gehen.
Ich weiß nicht, wer da mal bei Ihnen so an der Elbe war,
wenn da mal so ein großer Containerschiff vorbeigefahren kommt, was das für eine Welle gibt.
Da hat man ja schon Leute da unten an der Strandperle,
hat man ja schon auf den Tischen stehen gesehen, die das verschätzt haben.
Also, die Idee dabei ist folgende, was wir hatten.
Wir realisieren, ein System zur Baustellenverwaltung, dadurch,
dass wir so an Kartendarstellung als Hintergrund zeigen,
hatten die vorher auch noch nicht an ihren Rechnern. Und die haben Werkzeuge,
womit man jetzt Baustellen markieren kann und Ein ganz wichtiges Werkzeug ist,
diese Baustellen auch zu markieren mit bestimmten Flaggen oder Schildersymbolen,
nämlich die, die im Hafen dann wirklich hingestellt werden müssen,
um zu markieren, Achtung, hier ist ein Taucherponton im Einsatz.
Oder Achtung, hier kommende Baustelle. Und das Letzte,
und damit bin ich dann, damit sie auch so jetzt den Werkzeugmaterial,
wir haben das Ding genommen und haben gesagt,
es gibt unterschiedliche Arbeitsplätze, es gibt einen Arbeitsplatz,
die verwalten auch Baustellen, aber die machen das vor oft Ort.
Das sind Nautica, die sitzen auf so kleinen Hafenwahlkassen,
fahren durch den Hafen und sehen dann, sich Baustellen an,
in welchem Zustand die sind, ob da alles korrekt ist.
Dazu können sie natürlich keinen Arbeitsplatz rechnen, mitnehmen,
sondern dazu nehmen sie so Handhelds mit und auf diesen Handhelds
können sie ortsbasiert sehen, was als nächste Baustelle vor ihnen ist.
Sie können sich die Dokumente und Beflaggungen ansehen und sie können mit so einem Handheld,
kann man das hier machen, sie können Fotos machen.
Und wenn die dieses Foto freigeben,
das kann man nämlich auf einer schwanken Barkasse tun,
man kann nicht wirklich was schreiben,
aber man kann ein Foto machen und man kann das Foto in so einen Ausgangskorb ziehen,
auf beispielsweise im iPad,
dann sehen die Leute in der naudischen Zentrale passend zu dieser Baustelle,
hier unten ist das angedeutet,
als Material weitere Fotos von diesem, von dieser Baustelle.
Und das ganze Ding heißt Portmonitor und die HPA hat damit
einen Preis gewonnen und ist ganz stolz und wir sind ganz stolz,
dass wir dieses Ding mitentworfen haben.
Okay, das zu Anwendungsorientierung, Werkzeugmaterial, vielen Dank,
dass Sie mit dabei waren