Einen schönen guten Tag. Können Sie mich hinten einigermaßen verstehen?
Danke. Mein Name ist Heinz Zülikoven. Ich freue mich
, dass ich heute hier die SE2-Vorlesung halten darf.
Ich freue mich deshalb, weil ich vor ganz vielen Jahren
die Idee zu dieser Vorlesung hier umsetzen konnte.
Ich habe das dann viele Jahre mit Axel Schmolitzky zusammen gemacht.
Den kennen Sie ja gut und mittlerweile da ich noch
so knapp zwei Jahre hier an der Uni habe,
macht Axel das ja mittlerweile aus meiner Sicht viel besser,
als ich es je gemacht habe.
Aber ich freue mich, dass ich heute hier ein Thema vortragen darf,
was mir oder uns als Softwaretechniker sehr am Herzen liegt.
Zu meinem Hintergrund, seit 91, bin ich hier an
der Uni Professor für Softwaretechnik. Mittlerweile heißt Man Lehrstuhl Softwarearchitektur
. Das heißt, damit ist das Thema genannt,
mit dem wir uns hauptsächlich beschäftigen, also mit der Architektur großer Softwaresysteme.
Ich habe mich vor über zehn Jahren als Halbzeitprofessor reduzieren lassen,
um in der anderen Hälfte Geschäftsführer der kleinen Firma C1-WPS zu sein oder sein zu können.
Dort beschäftigen wir uns, sie werden es kaum reiht,
Softwarearchitektur und der Weiterentwicklung großer Softwaresysteme. Das ist also auch so der Hintergrund,
auf dem diese SE1, SE2-Vorlesungsreihe entstanden ist,
ihnen in diesen zwei Semestern das Handwerkszeug zu vermitteln,
dass sie in die Lage versetzen soll,
hinterher gute Informatikerinnen,
Informatiker mit Anwendungsbezug
zu sein
Heute haben wir gemeinsam vor uns das Thema Objektorientierte Modellierung.
Ich möchte Ihnen einen Überblick geben über das,
was aus unserer Sicht eigentlich für Sie die Aufgaben der nächsten Jahre und Jahrzehnte sind,
was Sie in Ihrem Studium,
wenn Sie sich für diesen Bereich Software-Technik, Software-Architektur interessieren,
was Sie in Ihrem Studium bewegen wird und wenn Sie einen entsprechenden Beruf haben,
was im Beruf aus Sie zukommt.
Im Wesentlichen ist das heute eine Vorlesung,
die Ihnen einen Überblick gibt über das, wo man sehr,
sehr lange drüber arbeiten könnte und wo sie vermutlich auch sehr viel Zeit noch investieren werden.
Ich möchte erst mal so ein bisschen etwas erzählen über das ganze Thema objektorientierte Methoden,
was wir bis jetzt den SE1 und SE2 eigentlich überhaupt nicht behandelt haben.
Ich möchte sagen, wie ordnet sich das, was Sie
bis jetzt gemacht haben in so einem größeren Zusammenhang ein?
Wie ist das zu verstehen? Auch so ein kleiner historischer Blick darauf.
Und dann möchte ich Ihnen eine Sichtweise der objektorientierten Softwareentwicklung nahebringen,
die wir seit vielen Jahren sehr erfolgreich an der Uni und in der Praxis
entwickelt und eingesetzt haben und möchte das Ganze mit so einem kleinen kontrastiven Beispiel abrunden.
Literatur, komme ich noch zu, ich komme jetzt zum eigentlichen Thema, die Einordnung.
Was Sie mit uns bis jetzt weitestgehend gemacht haben,
passt in diesem Klötzchenspiel hier unten in diese Ecke rein.
Also die Frage, gegeben eine hoffentlich relativ klare Aufgabenstellung,
Wie setze ich diese Programmieraufgabe, handwerklich sauber in ein lauffähiges Programm um?
Das war das zentrale Thema in SE1 und das ist weitestgehend
das Thema in SE2. Dazu haben wir kleine Ansätze vermittelt,
nicht nur wie kodiere ich in Java oder in einer objektorientierten Programmiersprache,
sondern wie komme ich von einer Aufgabenstellung zu einem programmierbaren Programm.
Das ist aber nur ein sehr kleiner Ausschnitt dessen,
was die Frage des Entwurfs ist und was es bedeutet oder bedeuten könnte,
größere Programme zu entwerfen,
das will ich Ihnen heute wenigstens in Ansätzen zeigen.
Wir haben bis jetzt in der Lehrveranstaltung eigentlich noch gar nicht
die Frage mit Ihnen diskutiert, wie gehe ich denn vor,
um überhaupt meine Aufgabe als Informatiker oder Informatikerin zu verstehen?
Wie gehe ich vor, um in einer Alltagssituation zu verstehen,
was dort Sache ist und wo meine Aufgabe im Job liegt
Oder mit anderen Worten, wie gehe ich bei der Analyse vor?
Wie identifiziere ich Probleme und wie komme ich dann,
wenn ich das identifiziert habe von der Analyse zu einem passenden Modell,
bevor ich anfange, anfange zu programmieren?
So, ein Thema, was wir mit Ihnen am Ende dieses Semesters
ein bisschen behandeln werden und was eben Softwareentwicklungspraktikum dann zum ersten Mal
ganz explizit auf Sie zukommt, liegt auf der nächsten Ebene.
Nicht nur, was muss ich handwerklich machen oder welche Art von Modellen
muss ich bauen, sondern die sehr, sehr spannende Frage.
Wenn ich nicht alleine für mich am Rechner sitze und programmiere,
sondern muss in einem kleineren oder größeren Team arbeiten.
Ich muss in einer Organisation arbeiten. Ich muss in einem Projekt
arbeiten. Wie mache ich das? Das ist das,
was sie in ihrem Studium, in ihrem ersten Projekt erleben werden,
für viele so auf einmal so ein Aha-Erlebnis. Moment mal,
da haben wir ja noch gar keine Ahnung von,
wie wir uns hier mit 10, 15,
20 Leuten so organisieren sollen, so abstimmen sollen,
dass am Ende des Semesters etwas vorführbares, vorzeigbares dabei herauskommt.
Ganz eigenes Thema, einige Anmerkungen heute dazu
Und weil wir ja hier an der Universität sind,
will ich zumindest darauf hinweisen,
dass man sich mit objektorientierter Programmierung auch modelltheoretisch befassen kann.
Das heißt, dass ich die Frage stellen und beantworten kann,
so ein Objektorientiertes Modell, was hinter einer Sprache wie Java steht,
wie sieht denn das aus?
Wie kann ich denn das formalisieren? Wie kann ich so
ein Modell darstellen und wie kann ich andere Modelle entwickeln?
Das ist natürlich eine Frage,
die eine universitäre Informatik beantworten muss,
die über den Rahmen dieser Lehrveranstaltung
natürlich hinausgeht
Blick zurück, Blick ziemlich weit zurück,
nämlich in die 60er Jahre,
um in Axel wird das das ein oder andere Mal sicherlich schon angedeutet haben,
um ihn deutlich zu machen,
was sie hier machen mit Java und objektorientierter Programmierung,
auch wenn es manchmal so scheint,
ist jetzt nicht ein neues Ding der letzten drei oder vier Jahre,
sondern wenn man so ein bisschen zurückschaut in die Geschichte der Informatik und die ist ja noch nicht so alt.
Etwas, was ziemlich früh aufkam und ich möchte deshalb diesen Blick zurückwerfen,
weil erstens dabei zwei Namen auftauchen oder auf zwei Forschergruppen,
die die objektorientierte Softwareentwicklung sehr geprägt haben.
Und weil es, glaube ich, mal ganz interessant ist
zu sehen, was hat die Leute motiviert?
Sprachen zu entwerfen und zu implementieren,
die wir im Prinzip in der Art heute noch benutzen.
Ganz am Anfang der objektorientierten Programmierung stehen unsere Freunde aus Skandinavien,
genauer gesagt aus Norwegen. Ole Johann Dahl und Christen Nügor,
die an einem Rechen- und Forschungszentrum in Norwegen gearbeitet haben.
Und die sich mit Fragen der Simulation beschäftigt haben.
Sie waren mehr auf der Rechnerseite, aber ihr Thema,
sie haben an einem Institut gearbeitet, was sich mit Simulation befasst hat.
Und dort war die Aufgabe, wurde herangetragen,
der Hafen von Ostlo sollte neu konzipiert, neu gebaut werden.
Und an diese Forschergruppe wurde die Frage gestellt,
wie können wir diesen Hafen planen, wie können wir den Hafen simulieren,
dass wir ihn groß genug bauen, dass wir genug Lagerhallen haben,
dass die Straßen und die Schienenwege in den richtigen Dimensionen sind.
Und diese beiden Hören haben gemerkt, das ist eine so komplexe Aufgabe,
dass ich nicht einfach eine mathematische Formel oder Funktion entwerfen kann,
wo ich Eingabegrößen hineingebe und Ergebnisse zurückbekomme.
Also so ein ganz klassisches mathematisches Modell,
um anhand von Eingangsgrößen bestimmte Ausgangswerte zu brechen.
Ein Hafen lässt sich nicht in so eine geschlossene Formel packen. So,
damit wäre ihre Aufgabe erst einmal leider zu Ende gewesen,
aber dann ist ihnen die Idee gekommen, wir machen das mal ganz anders.
Wir machen jetzt nicht eine große Formel,
wie sieht der Hafen von Oslo in Zukunft aus,
sondern wir bauen wie wie in einem, ja, wie mit einem Spielzeugkasten.
Wir bauen den zukünftigen Hafen von Oslo mit Softwareobjekten.
Wir bauen nicht das nicht mit Spielsteinen oder kleinen Modelleutos ein Modell schiffen,
sondern wir bauen diese einzelnen Teile in Software nach.
Wir bauen kleine Schiffe, wir bauen kleine Softwarelastwagen, wir bauen uns Software,
Lagerhallen und dann lassen wir das Ganze loslaufen und sehen mal,
was passiert. Haben sie gemerkt, da gibt es,
die Idee ist gut, aber sie haben keine Programmiersprache,
um das einfach ausdrücken zu können und da kommt 1964 sind die beiden auf die,
heute muss man sagen, geniale Idee bekommen.
Eine Programmiersprache zu bauen, in der man Softwareobjekte erzeugen kann.
Sollte ihnen bekannt vorkommen. Also das ist die eine Idee. Die andere Idee,
hier auf der anderen Seite USA, Alan K., Xerox,
der als Student in ihrem Alter ein bisschen älter als sie,
seine Dissertation geschrieben hat und in Zeiten als Rechner noch so groß waren,
dass das, was sie heute locker hier reinkriegen,
das hätten sie damals nicht in diesen Hörsaal reingekriegt
Und Alan Kay hat seine Dissertation geschrieben über das Diner Book. Steiner Book,
der hat ja damals die Idee beschrieben, die Vision gehabt,
wie sieht ein Rechner aus, den ich mit mir herumtragen kann,
wo ich keine Bücher brauche, sondern alles damit lesen kann.
Und wo ich Bilder sehen kann,
wo ich Musik mithören kann, kommt ihnen irgendwie bekannt vor.
Das hat er aber nicht vor drei Jahren geschrieben, das hatte 69 geschrieben.
Und damals hat er, weil er gesagt hat,
die Hardware habe ich nicht, dafür habe ich entwickelt,
schon mal die Programmiersprache und diese Programmiersprache hieß dann Smalltalk, die er konzipiert hat.
Also kann man sagen, not bad, krasse Ideen.
Beide haben ein Anwendungsthema, ein Anwendungsproblem als Vision oder als Praxis gehabt, um auf Objektorientierung zu kommen. So,
die Zeit wollte ich investieren, so einen Blick zurück,
was sehr spannend ist und was eben nur in der Informatik passieren kann,
ist, dass es so Leute,
die das mal konzipiert haben, ganz in den Anfängen,
dass ja bei Chris Nügor leider nicht mehr,
aber bei Alan K., diese Leute können sich noch treffen,
die Alan K. lebt noch, also und ganz gut.
Also das ist ja in anderen Bereichen, also sagen wir Germanistik oder so,
Mittelhochdeutsche Dichter trifft man nicht mehr so häufig.
Gut, in der Informatik ist das anders. Also wir können noch die Leute kennen,
die sowas gemacht haben und die ersten,
die sich dann systematisch nicht mit Programmiersprachen, sondern wie geht man vor? Wie entwirft man objektorientiert,
die das beschrieben haben, die sehen sie hier,
ich will jetzt nicht im 1-0 durchgehen,
ich will nur sagen, das war so die Diskussion,
80er, Anfang der 90er Jahre,
da gab es so massenhaft Bücher, wie analysiert man objektorientiert,
wie entwirft man objektorientiert, wie programmiert man,
es gab einen heftigen Richtungsstreit,
es war viel in der Diskussion
Der große Einschnitt kam, zum Glück, sagen die einen,
leider sagen die anderen, als die UML,
die sie ja so mit Kästchen und Pfeilen kennen,
Klassendiagrammen, Objektdiagramme, gibt es noch jede Menge andere.
Als die UML, als die vereinheitlichende Modellsprache der Informatik entwickelt wurde,
eigentlich auf Zwang der Industrie, die gesagt hat, Leute,
jedes Jahr eine neue Methode, jedes Jahr ein neues Modellierungsmittel,
das hält ja keiner im Kopf aus.
Wir brauchen was,
was wir praktisch einsetzen können und Die Industrie hat eigentlich gesagt,
wir sperren mal drei, vier führende Vertreter, unterschiedlicher Methoden,
die sperren wir mal zusammen und die lassen wir nicht eher raus,
bis die mit einer gemeinsamen Methode überkommen.
In Kurzform und übertrieben, aber so war die Story und die Herren Boot,
Jakobsen und Rambo haben dann das erste Buch rausgebracht über die Unified, Bodeling Language.
Und das könnte man sagen, mit allen Effekten, die hinterher kamen,
war weitestgehend das Ende der Methodendiskussion wie modelliert man ein Objekt orientiert.
Also was wir heute davon sehen, mitbekommen,
was wir auch im weiteren Studium mitbekommen, sind die UML, die unterschiedlichen UML-Modelle.
Einige haben sie davon gesehen, aber damit war die große Diskussion,
wie macht man es überhaupt weitgehend reduziert.
Heute finden Sie auf aktuellen Konferenzen in aktuellen Büchern eher kleinere Themen,
nicht so grundsätzlich. Also viele werden es von Ihnen schon gehört haben,
agile Vorgehensweise, Extreme Programming, Scrum,
auch was, was Ihnen im Softwareentwicklungspraktikum begegnen wird,
wie geht man leichtgewichtig und in Zyklen vor.
Oder ganz wichtiges Thema, wie testet man systematisch? Oder etwas,
was Sie hier auch in der Vorlesung sehen oder gesehen haben oder noch sehen werden,
wie kann man seine Programmierung durch Entwurfsmuster auf ein neues Niveau heben.
Wenn ich heute da drauf schaue oder wenn wir drauf schauen,
kann man sagen, das, was zurzeit diskutiert wird,
das orientiert sich zum einen an dem Verhalten von Menschen in ihrer Arbeit.
Da werde ich ein Beispiel zu bringen
Das geht, die zweite Strömung geht aus von den Datenbanken,
die heute unter jeder Anwendung eigentlich liegen,
die unter jeder Größe und kommerziellen Anwendung,
die also sich die Frage stellen,
welche Daten muss ich im Endeffekt interaktive Software hin oder her abspeichern,
um mein Unternehmen, mein Geschäft,
meine Prozesse vernünftig laufen zu lassen und zu unterstützen.
Ich werde für beides in der zweiten Hälfte ein Beispiel bringen,
damit das ein bisschen für sie
auch lebendiger ist
Noch ein Thema, was uns sehr wichtig ist und was
sie im Weiteren in der Anwendungsorientierten Informatik sehr beschäftigen wird,
ist die Frage, mit welchen Modellen gehen wir um.
Und ein Modell, mit dem sie jetzt anderthalb Semester umgegangen sind,
ist das ausführbaren Modell der Software,
das sie kodiert haben und dass sie auf dem Rechner laufen lassen.
Nämlich ein Text in Programmiersprache ist ja auch ein Modell.
Hat den großen Vorteil, es ist ein ausführbares Modell,
aber wenn sie davor sitzen und das im Tutorium oder in der Übung jemanden erklären,
dann erklären sie ja auf der Ebene von Textzeilen,
was sie damit gemeint haben.
Also sie erläutern ein Modell und wie es funktionieren soll. Es gibt,
also deshalb haben sie nicht nur hier auf der rechten Seite ein laufendes Anwendungssystem,
sondern auch immer noch ein Modell von diesem Anwendungssystem.
Und sie haben auch schon Klassendiagramme gesehen, haben,
ist ihnen ja nichts Neues. Also man kann also auch außer Programmtexten
andere Modelltypen für Programme bauen. Ich möchte Sie heute darauf hinweisen,
dass ein weiterer Typ von Modellen ganz wichtig geworden ist.
Das hat man in der Softwareentwicklung auch noch nicht so urlanger erkannt,
dass man da eigene Modelle haben will, nämlich ein Modell des Gegenstandsbereichs.
Da werde ich gleich was zu erläutern, damit ihnen das
auch etwas deutlicher wird, was damit gemeint ist. Also in kurzen Worten,
man will nicht nur ein Modell haben für das Programm,
was man baut, sondern auch ein Modell haben,
dieses Ausschnitts von Realität, für den sie das Programm bauen sollen,
sodass sie den Zusammenhang diskutieren können,
was hat diese Versicherungsgesellschaft mit diesem Stück Programm zu tun und umgekehrt.
So, wenn ich also, wenn ich mir als Softwareentwickler
Meistens sogar zeitlich am Anfang erstmal ein Bild machen muss,
für welchen Gegenstandsbereich oder für welche Domäne oder für welche Branche
oder für welche Organisation arbeite ich eigentlich.
Wenn ich das verstehen will, dann reden wir darüber,
dass wir den Gegenstandsbereich analysieren wollen. Wir wollen nämlich verstehen,
in welchem Kontext unser zukünftiges System eingesetzt werden soll.
Das kann eine ganze Organisation sein, aber meistens ist eine ganze Organisation,
nehmen wir mal an, Universität, ist viel zu groß,
dass ich ein Stück Software für eine ganze Universität mit allen ihren verschiedenen Aufgaben entwickeln kann.
Also schaue ich mir einen Bereich an, eine Abteilung.
Manchmal schaue ich mir auch nur einen einzelnen typischen Arbeitsplatz an,
den ich unterstützen soll
Ich muss den soweit verstehen, dass ich weiß, was dort fachlich passiert.
Das ist eine Aufgabe, die hört sich zunächst mal relativ alltäglich an.
Aber wenn sie mit Leuten reden oder wenn sie selbst schon
berufliche Kontakte und Praxis haben, werden sie feststellen, je nachdem,
für welchen Gegenstandsbereich sie als Softwareentwicklerinnen und Entwickler arbeiten sollen,
steckt darin ein Riesenpaket an Aufgaben.
Wir haben also Studenten, die für uns arbeiten, zusammen mit dem Desi,
also diesem Beschleunigungszentrum für Elementarteilchen, Barenfeld und Co..
Das ist eine spannende Aufgabe, aber um allein zu verstehen,
wie eine solche Beschleunigungsanlage funktioniert und daraus der Anteil der Kälteaggregate
ist man als Person wochenlang gefordert, ehe man überhaupt weiß,
wo der Open und unten ist.
Dann hat man doch keine Ahnung, was da an Software notwendig ist. Ja,
also im Gegenstandsbereich zu verstehen und die Fachlichen Zusammenhänge zu verstehen,
ist nicht so einfach,
weil die Leute ja nicht nur sehr komplizierte und komplexe Dinge tun,
sondern die sprechen auch ihre eigene Sprache
Sich zum ersten Mal mit einem Projekt zu tun hatte,
für den Hamburger Hafen, für ein Container-Terminal
, haben die Leute, die dort gearbeitet haben,
immer gesagt, sie brauchen für ihre Besprechung eine Segelliste.
Haben sie schon mal auf einem Container-Terminal ein Segelschiff gesehen?
Ist auch schon etwas länger her, ja. Aber Segelliste
, da hat mir überhaupt nichts gesagt. Ja,
Segelliste ist ein Dokument, da ist als Strich
die Kaimauer dargestellt und so als Klötzchen obendrüber die Schiffe,
die in der Zeit an dieser Kaimauer anlegen werden
Mit ihrer Länge, dass man also sehen kann,
wie viel zu einem Zeitpunkt nebeneinander passen.
Weil das ganz früher auch für Segelschiffe zutraf, heißt dieses
Dokument heute noch Segelliste. Wenn man das nicht weiß,
weiß man überhaupt nicht, über was die Leute reden.
Denn wenn einer auf dieses Stück Papier mit den Kästchen drauf zeigt und sagt,
das ist die Segelliste für, also ich habe gar nichts verstanden.
Gut. Ganz wichtig, was mache ich?
Was machen Sie? Was müssen Sie machen, wenn Sie
einen solchen Gegenstandsbereich analysieren wollen? Das erste,
dass man überhaupt weiß, wo oben und unten ist,
ist, Sie sollten eine Idee davon haben,
welche Ziele und Zwecke dort verfolgt werden.
Nehmen wir mal so einen Container-Terminal.
Das kann man sich so ein bisschen ansehen, anhören.
Es geht darum, dass Container auf Schiffen ankommen.
Die müssen entladen werden. Dann müssen die irgendwo teilweise zwischengespeichert
werden. Dann kommen die auf Lastwagen oder dann kommen die
auf kleinere Schiffe oder dann kommen die auch auf Züge.
Und umgekehrt müssen Container, die da gespeichert sind, in die Schiffe reinkommen.
Also das muss ich also mindestens verstanden haben,
bevor ich weitere Fragen stellen kann, wenn ich nicht weiß,
wozu dieser ganze Laden gut ist, dann ist das sehr verwirrend.
Ich muss die Aufgaben verstanden haben und ich muss verstanden haben,
dass eine Aufgabe auf unterschiedliche Art und Weise gelöst werden kann.
Wenn Sie die Aufgabe bekommen,
fahren Sie bitte von hier nach Stellingen zu den Übungen,
werden nicht alle hintereinander genau das Gleiche tun und genau den gleichen Weg gehen.
Die einen werden mit dem Bus fahren,
die anderen mit dem Fahrrad, dritter haben ein Auto,
was auch immer.
Sie lösen die Aufgabe auf ihre Art und Weise
Das muss man auch mal verstanden haben. Und das,
was von Ihnen meistens gefordert wird im Zusammenhang mit Leuten aus der sogenannten Vorabteilung,
ist, dass Sie sich unterhalten können darüber,
was ist eine sinnvolle Art und Weise,
die Aufgabe zu lösen und was ist eine nicht so sinnvolle Art und Weise.
Also wenn Sie von hier aus die Aufgabe gehe nach Stellingen und Sie,
dass du rechtzeitig bei den Übungen bist,
dadurch beginnen zu lösen, dass Sie hier zu Fuß losgehen,
könnte das keine sehr effiziente Lösung sein.
Sie kommen zwar irgendwann an, aber vielleicht erst nach der Übung. Also diesen Unterschied muss man verstehen,
Ein bisschen was über die Art und Weise, wie Menschen arbeiten,
werde ich ihnen gleich noch erzählen und dass dabei Arbeitsplätze eine wichtige Rolle spielen.
Ist auch. Für uns ganz interessant, also hier auch ein kleines Modell über,
so auf einer Meta-Ebene, über das, was ich Ihnen gerade erzählt habe.
Also es gibt in ihrem Anwendungsbereich, es gibt Aufgaben,
die Aufgaben werden abgearbeitet durch unterschiedliche Prozesse und an den Prozessen sind letztlich Menschen immer wieder beteiligt,
wobei uns im Regelfall nicht die einzelne konkrete Person interessiert,
also nicht sie oder sie, sondern das,
was sie in ihrer Aufgabe dort als Rolle,
man sagt auch als Akteur erledigen, also dass sie dort eingestellt sind,
beispielsweise als Yard-Manager an diesem Container-Terminal.
Sie sind also zuständig für das Management des B- und Endladen von Schiffen,
das wäre so ein Akteur am Arbeitsplatz und meistens in den allermeisten Fällen,
wenn jemand arbeitet und sitzt nicht nur da,
und denkt vor sich hin, da ist es schwierig,
wenn ich sie so ansehe, dann ist es schwierig zu erkennen,
arbeiten, sie denken sie oder haben sie gerade weißes Rauschen und hoffen,
dass die Zeit vorbeigeht.
Also arbeiten kann man meistens daran erkennen,
dass Leute irgendetwas tun, dass sie mit Gegenständen hantieren,
dass sie Formulare ausfüllen oder dass sie irgendwas in den Rechner
eintippen oder dass sie irgendeinen Kran bewegen.
Ja, also hier ein kleines Modell und unsere Vorstellung,
was es bedeutet, so ein Gegenstandsbereich zu analysieren und
zu verstehen
Ich habe das jetzt noch mal zusammengefasst. Sie haben einen
Gegenstandsbereich, jedes Projekt muss sich erst mal damit befassen,
wie groß ist mein Gegenstandsbereich? Muss ich,
um meine Aufgabe zu erledigen, die ganze Universität analysieren?
Oder reicht es, dass ich mir die Personalverwaltung ansehe?
Oder reicht es, dass ich mir innerhalb der Personalverwaltung
den Arbeitsplatz ansehe, wo die technischen Mitarbeiter betreut werden?
Das muss ich am Anfang meines Projekts hier genau wissen,
sonst entweder ich verstehe nichts oder ich mache mir zu
viel Arbeit
Wir haben kurz über die Aufgaben gesprochen. Prozesse setzen diese Aufgaben
in die Tat um. Und es gibt immer wieder Menschen,
die in diesen Aufgaben, mit diesen Aufgaben beschäftigt sind.
Die arbeiten üblicherweise an Arbeitsplätzen in der Universität,
im Studium sitzt man meistens an irgendwelchen Schreibtischen oder auf irgendwelchen Bänken und Vortischen.
Im Hafen sitzt man weniger rum, sondern läuft rum oder fährt rum.
Da kann man also sagen, es gibt also nicht nur
den Schreibtisch-Arbeitsplatz, sondern es gibt andere.
Man sieht, dass die Leute Materialien durch die Gegend tragen,
die sie bearbeiten,
weitergeben,
Das ist das, was wir verstehen. Das ist jetzt
mal so eine etwas verallgemeinernde Sicht. Was brauche ich,
um anwendungsorientiert zu analysieren? So, wie mache ich das
? Ganz kleiner Überblick, haben Sie sich bis jetzt hier
auch nicht systematisch hier bei uns mit beschäftigen müssen.
Ist aber ganz wichtig, wenn Sie es dann tun.
Das einfachste, was eigentlich jedem von uns einfällt, ist,
man geht zu den Leuten, die die Arbeit machen und spricht mit denen.
Man macht Interviews. Einfach offensichtlich Ganz so einfach ist es
dann doch nicht. Es gibt viele Organisationen,
in denen haben sie gar keinen einfachen Zugang als Softwareentwicklerin oder
Softwareentwickler zu den Leuten, die die Arbeit machen.
Ich erinnere mich an das eine oder andere Krankenhausprojekt,
wo schon die Krankenhausleitung eine sehr genaue Meinung dazu hat,
ob sie eine Chirurgin oder einen Anästhesisten ausgiebig interviewen dürfen oder nicht
Das ist schon mal so das Allererste. Also die Interviews einfach,
aber man muss sich ja überlegen, wie geht man davor?
Eigenes Thema. Zweites Thema, wenn sie bestimmte Dinge nicht
bei der Arbeit beobachten können. Nehmen wir mal an,
in der Bank, sie sollen in der Bank arbeiten,
im Kundengeschäft, Kreditvergabe,
dann wird es weder der Bänker noch der Bankkundin gefallen,
wenn sie bei einer Kreditvergabe daneben sitzen, sich Notizen machen.
Aber was können sich stattdessen machen?
Sie können Rollenspiel machen. Dass sie die Kundin oder
den Kunden spielen
Kospitieren, sehr aufwendig, dauert es sehr lange,
ist sehr effizient von dem, was sie mitbekommen,
aber es sollte nur erwähnt werden,
wird in einigen Fällen, wo es nicht anders geht,
macht man das wirklich auf.
Und heute gibt es immer wieder aus der Ethnografie,
ist das rübergekommen in den Informatik, so Ansätze mit Videokameras und irgendwas,
Arbeitssituationen zu beobachten, aufzunehmen, hinterher zu analysieren.
Ist also das mit dem,
das hat mit Informatik im engeren Sinn überhaupt nichts zu tun,
werden Sie sich mit beschäftigen,
wenn Sie das im Projekt machen
So, und dann bauen sie also Modelle von diesem Anwendungsbereich
, da gibt es da so ganz unterschiedliche Ansätze.
Ich zeige Ihnen mal hier ein Beispiel, so mit kleinen
Strichfiguren und Nummern dran und Reihenfolgen und so verallgemeinerten Gegenständen.
Also Sie sehen den in der Mitte den FB-Planer, den Fachbereichsplaner,
der gibt ein Leertableau unter der Nummer 4, dann an die Fachbereichs Leerplanungsbeauftragte.
Also hier haben wir mal in einem Seminar analysiert,
wie werden die Lehrpläne erstellt und abgestimmt und dann hinterher so umgesetzt,
dass sie hier eine Lehrveranstaltung zu einem bestimmten Tagesordnung zu einem bestimmten Tag in der Woche haben.
So, das ist also so ein Bild, da sieht man Abläufe mit,
als modellhaften Figuren und Gegenständen ist eine Möglichkeit, das darzustellen.
Die UML hat für die gleiche Aufgabe Akteure und ihre Aufgaben diese Notation verwendet,
Anwendungsfalldiagramm, ich weiß nicht,
ob sie sich schon eins gesehen haben im weiteren Studium,
werden sie sowas sehen,
da ist das jetzt auf einer etwas allgemeineren Ebene.
Sie sehen auch da den Lehrveranstaltungsplaner und der hat mit
der Aufgabe Pflegung Pflege der Lehrveranstaltung zu tun.
So wird das dargestellt. Wollte ich nur mal zeigen,
das sind also Modelle,
die mit dem Programm im engeren Singen nichts zu tun haben,
mit dem sie sich rumschlagen müssen.
Etwas formaler mit Kontrollflüssen und oder Entscheidungen,
ein anderer Typ von Diagrammen, Aktivitätsdiagramm aus der UML.
Damit können sie also auch Arbeitsvorgänge modellieren. Ist wieder der gleiche,
die gleiche Frage, wie kann ich das,
was ich da gesehen habe, so dokumentieren,
dass zumindest ich und andere in meinem Team
das verstehen
Ja. Sowas ähnliches haben sie schon gesehen, so ein bisschen Begriffsdiagramme,
auch UML, wenn die wesentlichen Begriffe, die sie identifiziert haben,
wie Sägeliste oder hier Lehrtableau, wenn sie die in den Zusammenhang stellen müssen.
Brauchen wir jetzt nicht darauf einzugehen, ich will Ihnen nur sagen,
das sind also Modelle oder Modelltypen,
mit denen Sie sich gegebenenfalls auseinandersetzen müssen, bis Sie dann irgendwann,
wenn Sie alles genug verstanden und analysiert und diskutiert haben,
in einer Form angekommen sind, relativ weit unten,
will ich mal sagen,
in der Detaillierung Ihres Modells,
wo es um Oberbegriffe und Unterbegriffe und sowas wie Exemplare geht,
wo wir also schon ziemlich nah an einem objektorientierten Modell
dran sind
Okay, die Frage, die ich jetzt in der letzten Stunde,
die da Vorlesungen versuchen will, so ein bisschen zu beleuchten,
ist, wie gehe ich denn vor,
wenn ich meinen Gegenstandsbereich analysiert habe,
um zu einem vernünftigen Modell meines Anwendungssystems zu kommen,
sodass hinterher hier wirklich, wenn sie es lesen könnten,
Java-Klassendiagramme stehen, ja, also wie komme ich von dem,
dass da Leute draußen arbeiten und ich habe eine bestimmte Aufgabe,
die ich erfüllen soll, wie komme ich denn systematisch dazu,
solche Diagramme zu bauen und das hinterher zu kodieren.
Weil am Anfang, das ist so die Standarderfahrung,
die jeder macht, in seinem ersten Softwareprojekt,
dann hat man so halbwegs verstanden, um was es denn da geht.
Sagen wir auf unserem Container-Terminal, wir haben so halbwegs verstanden,
dass es jetzt darum geht, dass Container,
die aus dem Schiff rausgebracht worden sind,
mit diesen Katzen und dann sind die mit diesen komischen Fahrzeugen,
da sind sie jetzt drauf,
die einzelnen Container und die sollen jetzt zu einem bestimmten Lagerplatz kommen.
So, das ist unsere Aufgabe. Wir sollen also die Aufgabe lösen,
dass ein Container mit einer bestimmten Containernummer auf diesem Hof an einen bestimmten Platz gebracht wird.
Das sollen wir unterstützen, diese Aufgabe. Und das
fachlich verstanden zu haben und sich jetzt vorstellen,
daraus ein Programm zu bauen, ist für viele am Anfang nur Fragezeichen.
Wie komme ich dahin? Wie mache ich das? Nicht,
dass ich das jetzt hier für Sie in einer Stelle beantworten könnte,
aber ich will Ihnen zumindest zeigen,
wie man so in etwa objektorientiert dabei vorgehen kann.
Wir haben uns dazu lange und viele Gedanken gemacht und auch
ein dickes Buch zugeschrieben und dem Kind auch einen Namen gegeben,
der sogenannten Werkzeug- und Materialansatz.
Das ist das, was sie hier so in ganz,
so als kleine Prise Salz kennenlernen, im Rest dieser Lehrveranstaltung,
was sie auch so ein bisschen in der Übung machen werden.
Und was hinter dieser Grundidee steckt,
Werkzeug und Material als Ausgangspunkt für den Entwurf von Softwaresystemen zu nehmen,
das will ich jetzt ihnen versuchen zu erläutern.
Es gibt zwei Grundannahmen, die wir haben. Zum einen,
wir interessieren uns für die Aufgaben und Prozesse,
die draußen in der Wirklichkeit ablaufen, die passieren.
Wir orientieren uns an dem, was draußen ist, das nennt man Anwendungsorientierung.
Und zum Zweiten, wir versuchen, die Dinge,
die wir erkennen, die wichtig sind im Anwendungsbereich,
Struktur erhaltend oder strukturähnlich in Software nachzubauen.
Das will ich Ihnen ein bisschen erläutern, damit Sie diese Idee verstanden haben.
So, das erste ist, wir orientieren uns an dem,
was wir draußen in der Realität vorfinden.
Ich habe vorhin schon gesagt, Aufgaben können auf unterschiedliche Art und Weise erledigt werden.
Ich kann auch ganz selten oder überhaupt nicht in die Köpfe von Leuten,
die arbeiten, hineinschauen. Ich kann also nicht sehen,
was sie sich denken, während sie ihre Aufgaben erledigen.
Aber ich kann eins machen, das ist immer ein sehr,
sehr guter Ausgangspunkt. Ich kann mir ansehen, mit welchen Dingen Menschen arbeiten.
Ich kann mir die Notizen ansehen, die sie sich machen.
Ich kann mir ansehen, ob sie sich von den Skripten,
die Folien im Rechner ansehen oder ob sie sich das vielleicht ausdrucken.
Früher haben wir die Skripten ausgedruckt. Machen sie sich in
diese Skriptennotizen rein oder machen sie es nicht? Das heißt,
ich gucke mir die Gegenstände an und stelle dumme Fragen.
Ich kann sie fragen, sie haben das hier so und
so notiert. Sie haben diese Notiz gemacht. Wozu ist
das gut
Ja, und darüber können wir ein Gespräch entwickeln,
was sie mit diesen Dingen machen und weshalb sie das machen.
Das ist immer ganz nützlich, ja, weil ich kann,
ich habe einen Ansatzpunkt, um zu erkennen,
wie lege ich los, um meinen Entwurf zu gestalten. So,
und eine Sache ist auf jeden Fall schon immer mal sehr beruhigend und wichtig,
wenn ich die Dinge, die hier in materieller Form vorliegen,
die anderen Menschen brauchen, um ihre Arbeit zu erledigen,
wenn ich diese Dinge nehme und baue die eins zu eins in Software nach,
dann kann ich keinen sehr,
sehr großen Fehler machen
Also, nehmen wir mal an, sie sitzen irgendwo in einer Firma,
in einer Behörde und dort müssen sie Formulare,
die ihre Kunden ihnen zugeschickt haben, so früher,
ja, Papier, ja, diese Formulare müssen sie bearbeiten.
Wenn ich sie in ihrer Arbeit unterstützen soll, mache ich keinen großen Fehler,
wenn ich ihnen diese Papierformulare am Rechner elektronisch zur Verfügung stell.
Möglichst ganz primitiv eins zu eins. Ja,
das ist zwar nicht geschickt,
das ist nicht das Beste, was mir einfällt,
ja, ich bin dann auf jeden Fall nicht bei den
40 Prozent Softwareprojekten angekommen mit meinem Team,
die kein verwertbares Ergebnis liefern
Ja, und das ist immerhin eine ganz schöne Menge.
Also etwa 40 Prozent aller Softwareprojekte, die aufgelegt sind,
werden ergebnislos oder mit Nicht-einsatzfähigen Programmen oder nicht verwendbaren Programmen abgebrochen.
Das heißt, wenn sie diese Gegenstände,
die Leute in ihrer Arbeit brauchen, elektronisch in irgendeiner vernünftigen Weise nachbilden,
haben sie keinen ganz, ganz groben Fehler gemacht.
Die Leute werden wenigstens nicht arbeitsunfähig, wenn ihr System eingeführt wird.
Und das ist schon, wie ich sagte, ziemlich viel.
So, also Wir gucken uns die Gegenstände an als Ausgangspunkt
unserer Diskussion und überlegen, was tun die Leute,
wie verändern sie diese Gegenstände und was wollen sie an diesen Gegenständen sehen?
Also wenn ich irgendwo drauf schreibe oder ich mache eine Skizze,
dann verändere ich den Gegenstand. Und wenn ich mir nur
ein Formular ansehe oder ich sehe mir nur eine Containernummer an,
ja dann entnehme ich dem Ding Informationen.
Und das nennen wir Umgangsformen, also wie gehe ich mit den Dingen um?
Wenn ich das schon mal verstanden habe, habe ich schon einiges verstanden. So,
und dann gibt es Kann ich meine Gegenstände in unterschiedliche Kästchen tun so geistig,
kann sagen, okay,
es gibt Sammlungen von Gegenständen wie Ordner und es gibt Gegenstände,
damit kann ich andere Gegenstände bearbeiten, wie den Bleistift.
Es gibt auch Gegenstände, über die reden alle,
beispielsweise in der Bank, aber die kann ich nicht anfassen.
Also wenn jemand über Währung redet, Währung als solche kann ich nicht anfassen.
Aber ein Umrechnungsfaktor für Währung ist in der Bank eine ganz wichtige Angelegenheit.
Das ist also ein Gegenstand, der ist etwas komplizierter,
weil er nur in den Köpfen weitestgehend existiert.
Da muss ich erstmal drauf kommen.
Okay, ich habe ein paar Regeln aufgeschrieben,
will ich jetzt nicht weiter durchgehen, bringt ihnen jetzt nichts,
aber wenn sie in der Übung sich das später nochmal,
wenn sie Übungsaufgaben in der Art haben,
wenn sie sich das nochmal ansehen, dann werden sie entdecken,
aha, da sind so ein paar Faustregeln, wie ich,
wenn ich Gegenstände, die ich in Software gießen will,
wenn ich die modelliere, auf was ich dabei achte.
Also, dass ich in der Objektorientierung eine Sammlung,
in der ich Dinge unterbringen will, explizit modellieren muss.
Ich kriege eine Sammlung nicht freihaus,
also wenn sie eine Sammlung von Formularen oder eine Sammlung von,
sagen wir, Fotos haben, dann müssen sie diese Sammlung explizit bauen,
entwerfen und nicht nur einfach sagen, dann mache ich eine Linklist.
Ja, also solche Dinge werden sie dann merken, gucken sie mal drauf,
aha, ja, es gibt so ein paar Faustregeln,
die muss ich beachten, wenn ich also modellieren soll.
Und unser Ansatz heißt deshalb Werkzeug und Materialansatz,
weil wir uns ein bisschen umgesehen haben bei den Arbeitswissenschaftlern,
bei den Arbeitssoziologen, die sich schon lange mit Arbeit beschäftigen,
schon sehr viel länger,
als wir uns damit beschäftigen und auch zu Ergebnissen gekommen sind und die uns gesagt haben,
also wenn Menschen arbeiten, sinnvolle Arbeit verrichten,
dann tun sie das meistens in der Form,
dass sie Gegenstände bearbeiten, die zum Arbeitsergebnis werden.
Also das, was sie hinterher abliefern müssen,
das nennt man üblicherweise nicht nur in Fabriken oder im Handwerkmaterial.
Und dass sie dieses Material mit anderen Dingen bearbeiten.
Also ob sie jetzt einen Stift nehmen oder die Tastatur vom
Rechner oder sie nehmen einen Schraubenzieher oder was auch immer.
Meistens können sie sehr genau sagen, wenn sie arbeiten,
was brauchen sie werkzeugartig und was ist ihr Material, was zum Arbeitsergebnis wird. Und dieser Dieses Paar,
Werkzeug und Material, wenn sie sich darüber Gedanken machen,
was brauchen Menschen an Werkzeugen und an Materialien,
auch in der Büroarbeit, um ihre Arbeit zu erledigen,
dann haben sie ein sehr gutes Hilfsmittel, um vernünftige Entwürfe zu machen,
weil jeder von uns über seine Sozialisation eigentlich eine Vorstellung hat,
was ist ein Werkzeug und was sind Materialien,
die ich bearbeite.
Und das gilt auch in abstrakten Zusammenhängen. Also kann man Softwaresysteme bauen als interaktive Systeme,
die eine Sammlung von sinnvollen Werkzeugen bereitstellen, um damit die Materialien,
die ihr Arbeitsergebnis sein sollen, bearbeiten zu können.
So, damit das jetzt nicht so auf der völlig abstrakten Ebene bleibt,
will ich Ihnen zwei Beispiele zeigen,
die tatsächlich gebaut worden sind, die so laufen.
Was Sie hier sehen, ist das Ergebnis von zwei
studentischen Projekten
Heute würde man sagen, Bachelor-Projekt, das ist noch zu Zeiten des Diplomstudiums.
Zwei Jahrgänge haben das gearbeitet, bearbeitet. Was sie vor sich sehen,
ist im Wesentlichen ein Pausenplaner für eine Schule, für Behinderte, Schülerinnen und Schüler.
Dort hat die Pausenaufsicht eine besondere Bedeutung, weil schon rein rechtlich gesehen,
aber natürlich auch sozial gesehen, es sehr wichtig sind,
dass die Kids in den Pausen nicht unbetreut sind.
Und die Leitung dieser Schule, die wir hier in Hamburg als Partner in der Zusammenarbeit hat,
hat gesagt, Unsere Schulleiterin hat jeden Monat,
verbringt er eine unendliche Zeit vor so einem Pinboard,
wo sie versucht, die Pausenaufsicht für den nächsten Monat zu klären.
Dann ist jemand in Urlaub oder in Weiterbildung und kurzfristig passieren ständig Sachen,
da ruft jemand morgens an,
er ist krank und dann gibt es bestimmte Regeln,
weil damals gab es noch die Zivis, die Zivildienstleistenden,
natürlich, die können auch Pausenaufsicht machen,
aber es dürfen nur maximal zwei Zivis sein,
dann muss eine richtige Lehrperson bei sein,
sonst geht das mit der Versicherung in die Hose,
wenn was passiert und so.
Und was haben wir gemacht
Werkzeugmaterial. Wir haben gesagt,
okay, die Schulleiterin hat vor so einem Pinboard,
das war ihr Arbeitsmaterial, wo sie Montag, Dienstag,
Mittwoch, Donnerstag ihre Schultage hatte und auf der anderen Seite
die tausend Orte und dann hatte sie so Namenskärtchen und dann hat sie die draufgepappt.
Hab gesagt, also das ist sie gewöhnt. Also wenn
wir das nachbauen als ihr Arbeitsmaterial, dann sind wir schon gar nicht so falsch.
Stimmt, das war schon eine gute Idee. Aber dann haben wir gesagt,
statt jetzt hier rechts nur eine Liste der Aufsichtspersonen zu haben,
die man so nehmen kann und in die Raster tun kann.
Wir machen ein bisschen Intelligenz da rein, in die Werkzeuge,
in diesem Mauswerkzeuge, die wir gebaut haben, beispielsweise,
wir lassen nicht zu, dass die gleiche Person zur gleichen Zeit auf zwei Pausenhöfen eingesetzt wird.
Das wäre ja ziemlich blöd. Wir lassen auch nicht zu,
dass zwei Pausen aus Aufsichten belegt werden auf einem Pausenhof von nur Zivildienstleisten.
Das lassen wir auch nicht zu. Und wir zeigen hier rechts
wenn wir diese Belegung machen oder ermöglichen, wir zeigen an,
welche Person hat schon, wie viel Pausen beaufsichtigt,
weil Pausen beaufsichtigen ist nicht so der beliebteste Job an dieser Schule.
Können Sie sich vorstellen. Das heißt, die Idee,
Werkzeug, Material, wir haben als Material die Gegenstände genommen,
als Ausgangspunkt, die Lehrpersonen schon kannten und haben die Werkzeuge so als so kleine Maus-Tools hier so oben.
Ich kann so ein Namenskärtchen nehmen und über meinen Wochenplan ziehen und sehe,
wenn sich das Teil rot verfärbt, er sich das da nicht fallen lassen darf.
Eine Idee vor der Pause hier, Zweite Idee,
gerade frisch aus der Presse, aus unserer Softwareentwicklungspresse.
Wir haben für den Hamburger Hafen für die Verwaltung des Hamburger Hafens genannt Hamburg,
Port Authority, haben wir ein Portmonitor gebaut.
Als wir in die nautische Zentrale der HPR gekommen sind,
haben wir gesehen, oh, da kann man ein bisschen was mit IT machen.
Die hatten nämlich eine riesen Hafenkarte,
also so groß wie So breit wie diese Wand,
drei Meter hoch, hatten die eine Wandkarte ausgedruckt.
Das war deren Planungswerkzeug. Und dann haben sie
so kleine Klebezettel gemacht und damit haben sie diese Klebezettel,
die haben sie auf diese Karte draufgepappt.
Dann sind schon mal die Klebezettel runtergefallen oder jemand hat Klebezettel vergessen.
Wäre normalerweise nicht so schlimm, wenn das nur eine Karte wäre und Zettel wäre,
aber damit machen die die Planung beispielsweise die Einfachrouten für die Containerschiffe.
Ja, wenn jemand den Zettel übersehen hat,
dass gerade in dieser Fahrstraße ein Schwimmbagger festgemacht hat,
um irgendwas zu reparieren, dann ist das ziemlich blöd,
wenn da so ein riesen Container kommt,
weil die Teile können so furchtbar schlecht rückwärts fahren,
wenn sie in der falschen Gasse angekommen sind.
So, was haben wir gebaut? Wir haben hier im Hauptteil,
sehen Sie, eine elektronische Hafenkarte,
da hat man uns sehr schnell den Zahn gezogen,
dass man da irgendwas, ich sag's mal,
Google Maps-artiges verwenden kann, weil die gesagt haben,
das meint ihr doch nicht im Ernst, Google Maps,
das ist ja,
als würden sie mehr mit so einem Pinsel versuchen,
ein Porträt zu zeichnen,
das muss Zentimeter genau sein
Karte und sowas gibt es normalerweise nicht im Netz, da muss man spezielle Geografieinformationssysteme anschließen,
was wir hier gemacht haben. Und da kann man dann,
sie sehen den farbigen Bereich, eine Baustelle,
die zurzeit aktiv ist, markieren und dann kann man,
wenn man da drauf geht, sich Fotos anzeigen lassen,
die gemacht worden sind, aktuell von dieser Baustelle,
dass man auch sieht,
wie sieht denn das aus und rechts für die Nautica,
die da arbeiten,
halt wichtige Informationen,
was an dieser Baustelle passiert und wie die mit speziellen Sehzeichen
ausgeflackt ist,
beschildert ist
Auch hier, wenn Sie sich jetzt die Frage stellen,
was ist Werkzeug, was ist Material?
Ich denke, das ist dann relativ offensichtlich.
Wir haben halt sehr viel Kartenmaterial und Material über die Baustellen.
Und wir haben so kleine Werkzeuge, mit denen kann man halt
bestimmte Seestraßenmarkierungen da unterbringen. Oder man kann Fotografie nehmen,
die in der Eingangsbox sind und einer Baustelle zuordnen, solche Dinge. Okay,
nur so als eine Vorstellung, ein Arbeitsplatz für jemanden,
der als Nautiker in der nordischen Zentrale der HPA arbeitet,
der die Aufgabe hat, die Baustellenverwaltung Hamburger Hafen zu machen,
sieht einen Arbeitsplatz so aus als eine sinnvolle Sammlung von Materialien und Werkzeugen.
Und jetzt 5 Minuten Pause. Holtin. Zum Abschluss ein
Beispiel bringen, wo es auch um die Frage geht,
wie komme ich von einem kleinen Anwendungsproblem zu einem Stück Software.
Und ich wollte ihn zwei Vorgehensweisen daran deutlich machen.
Die eine habe ich hier schon vorhin angedeutet,
die ist strukturorientiert und die zweite
ist verhaltensorientiert
Aus zwei Gründen. Zum einen repräsentiert es,
oder vielleicht ist es ein ganz gutes Beispiel,
um die zwei unterschiedlichen Schulen zu zeigen,
die heute in der Entwicklung von Anwendungssoftware immer noch sehr vorherrschend sind.
Diese strukturorientierte Sichtweise, die ich vorhin so ein bisschen in Verbindung gebracht habe,
mit den Daten, die man abspeichern will und die man für wichtig hält.
Und das zweite würde ich zuordnen, dieser Anwendungsorientierten, Verhaltensorientierten Art,
Objektorientierte Systeme zu analysieren, zu modellieren und zu konstruieren.
Also das, was wir versuchen, ihn hier in SE1 SE2 nahe zu bringen.
Wenn Sie das an diesem einfachen Beispiel verstanden haben,
werden Sie sehr viel, denke ich,
in Ihrer Praxis wiedererkennen und sagen, aha,
als einfaches Beispiel habe ich das schon mal gehört und
vielleicht habe ich mir auch schon da meine Gedanken gemacht,
was da gut und was da vielleicht nicht so gut ist.
Der zweite Grund, weshalb ich das vorstelle, ist so ein bisschen,
sagen wir, Selbstkritik. Sie sehen hier unten Ein Literaturhinweis,
1987 habe ich mit meinem Kollegen im Team,
damals waren wir Mitarbeiter so einer praxisnahen Forschungseinrichtung,
Gesellschaft für Mathematik und Datenverarbeitung, hieß das Ding.
Also als die Informatik noch nicht so richtig Informatik hieß,
hat man dem Ding so den Namen gegeben, Mathematik und Datenverarbeitung.
Und wir haben uns mit objektorientierter Programmierung befasst mit Smalltalks. Sie erinnern sich vielleicht,
ich habe vorhin Smalltalk genannt, einer der ersten Hype,
O-O-Sprachen und haben einen Beitrag in einem Buch geschrieben,
wie entwirft und programmiert man gut objektorientiert.
Und da haben wir dieses Beispiel genommen, dass Bibliotheksbeispiel,
ja, und wenn ich heute mir das durchlese,
ich habe noch ein vergilbtes Sexemplar in meinem Bücherregal,
dann denke ich, okay, wir sind damals in alle Falkruben reingefallen,
die die Objektorientierung so für einen offen hält.
Also insofern so ein bisschen Selbstkritik für die zwei Ansätze.
Okay, Bibliotheksystem immer noch ein Klassiker,
wir haben jahrelang Studierende in den Übungen hier mit dem Bibliotheksystem gepeinigt,
mit Interviews, mit unseren Bibliothekarinnen.
Also Immer wieder ein Klassiker. Ich will jetzt mal
dieses Beispiel so ein bisschen kontrastiv vielleicht überzeichnet hier vorstellen,
damit sie auch so etwas deutlicher sehen, auf was es mir dabei ankommt.
So, wir haben uns damals das Bibliotheksbeispiel so genommen,
dass wir von dem ausgegangen sind, was wir am besten kannten, nämlich uns selbst.
Beliebter, beliebte Vollgrube für Softwareentwickler und Entwicklerinnen,
nimm dich selbst als Mittelpunkt der Welt und was du von der Welt verstanden hast,
das wird für die anderen auch schon stimmen.
Also haben wir uns gefragt, Dazu verwenden wir Bibliotheken,
naja, wir verwenden Bibliotheken, um dort Bücher und Artikel auszuleihen,
um für unsere Texte, die wir schreiben, bibliografische Angaben da reinzubringen oder Referenzen.
Also haben wir uns nicht damit befasst, was macht eine Bibliothek,
sondern was machen wir mit den Dingen, die in der Bibliothek sind.
Und da ist also nicht ein Bibliothekssystem bei rausgekommen,
sondern da ist ein System rausgekommen zum Bibliografieren,
also um Literaturangaben in Texte reinzubringen und zu verwalten.
Das ist das, was wir gesehen haben
Mich heute ein ganz typisches Beispiel. Wir haben uns nicht mit der großen Bibliothek befasst,
die es damals in der GMD gab,
sondern wir haben uns damit befasst,
was wir von dieser Bibliothek wussten und gesehen haben.
Und dafür haben wir ein System gebaut. Spannend. Ja,
wir haben uns also gefragt, welches System könnte nützlich sein,
um wie biografische Daten zu verwalten und welche relevanten Daten braucht man,
um Bibliografien anzulegen.
Das heißt also, wir haben schon von vornherein so
unser Blickwinkel verengt auf die Frage,
welche Daten sind fachlich sinnvoll,
wenn man
Bibliografien anlegen und verwalten will
Gut, und dann sind wir also an die Arbeit gegangen und haben gesagt,
okay, was brauchen wir denn in Literaturangaben und haben festgestellt,
wir brauchen Bücher, wir brauchen Zeitschriften,
wir brauchen technische Reports, das ist so das Hauptmaterial,
mit dem wir arbeiten und manchmal brauchen wir nicht ein ganzes Buch,
sondern einen Artikel aus einem Buch und wir brauchen auch nicht eine ganze Zeitschrift,
sondern einen Zeitschriftenartikel.
Als nächstes ist die Frage, was ist ein Buch,
naja, Das ist relativ klar,
ein Buch, wir haben uns nicht mit philosophischen Fragen,
weil es ist ein Buch als solches befasst,
sondern was braucht man von einem Buch?
Man braucht ein Kürzel, weil das ist ja aus einer Bibliothek,
Autorenliste, Titel, Verlag, Ottia, Prima.
Entsprechend haben wir uns gefragt, was charakterisiert einen technischen Report oder
was charakterisiert eine Zeitschrift, ein Buchartikel und einen Zeitschriftenartikel.
Ja, das war ja, wir waren mal ganz glücklich,
hat zwar eine Zeit gedauert, bis wir uns darauf geeinigt hatten,
aber das sah ja schon mal ganz gut aus.
Das heißt, wir hatten also die wesentlichen Gegenstände als Daten
identifiziert, die unser Bibliografiesystem haben sollte
Objektorientiert waren wir ja, ja,
wir hatten ja Smalltalk, Klassen, Oberklassen, wunderbar,
wir haben uns die Gemeinsamkeiten angesehen, der Dinge,
die wir modelliert hatten und haben also festgestellt, aha,
wenn wir uns also jetzt ein Buch ansehen, das hat Kürzelautorenliste,
Titel, Verlag, gehen wir mal auf Zeitschrift, Kürze,
Verlag haben wir auch, sieht schon ganz gut aus,
technischer Report, Kürzel, Autorenliste, Titel, oh,
das sieht sehr gut aus, Gemeinsamkeiten, was macht man mit Gemeinsamkeiten, Oberklassen?
Völlig klar, ja, unser Bibliografiesystem besteht Aus diesen konkreten Klassen,
und da bauen wir schöne Oberklassen dazu,
wir bauen nämlich hier unten unsere primären Klassenbuch, technischer Report,
Zeitschrift, die haben Autorenlistentitel, Verlag, Autorenlisten,
Titel, Reportangaben, Institutionen, Zeitschriften nahmen Jahrgang Nummer Verlag,
und dann haben wir den Artikel, der ist gekennzeichnet,
Autorenlistetitel, Seiten Verlag, und gemeinsam,
das haben wir dann Literaturangabe genannt,
alle die Dinge haben gemeinsam,
oder diese Klassen haben gemeinsam einen Kürzel,
einen Ort und ein Ja
Und dann waren wir ganz stolz, wir haben sogar unter Artikel,
haben wir unseren Buchartikel und unseren Zeitschriftenartikel untergebracht,
die haben nämlich gemeinsam das,
was ein Artikel ausmacht und die differenzieren sich dadurch,
dass ein Buchartikel noch einen Herausgeber und einen Buchtitel hat und einen Zeitschriftenartikel,
den Namen der Zeitschrift, Jahrgang und Nummer.
Klasse. Eigentlich kann man das Ding so schon runterprogrammieren,
unser Bibliografiesystem, Oberklassen, auf drei Ebenen,
fachlich unser Modell, was wir vorgefunden haben,
haben wir übertragen in was, was wir wirklich programmieren können,
haben die gemeinsamen Attribute rausgezogen, waren wir also pumpenglücklich.
Okay, schauen Sie sich das mal so an,
ob Sie das auch so gemacht hätten,
ob Ihnen das so gut vorkommt,
ja.
Zeichnet natürlich noch zwei Schritte verweisen, besser stärker Artikel, wenn man einzeln auf Instagram zeichnet.
Also, hier kommt jetzt der Vorschlag, ich wiederhole das nochmal.
Es werden weitere Gemeinsamkeiten identifiziert und die Frage gestellt,
sollten wir nicht beispielsweise die Gemeinsamkeit Autorenliste und Titel
in eine weitere Oberklasse rausziehen und die zweite Anregung,
wenn ein Buchartikel ja Teil eines Buches ist,
sollten wir nicht gleich vorsehen,
dass wir von Buch eine Referenz haben,
beispielsweise auf Buchartikel
Also so kann man, sie merken schon,
wenn man sich einmal auf diese Idee eingelassen hat,
dann fällt einem das eine oder andere noch ein.
Und in der Tat, es gibt also auch Entwürfe,
die genau das berücksichtigt haben.
Okay, also sie merken, in welche Richtung das geht.
Wir waren also ganz zufrieden, haben uns auch munter an
die Arbeit gemacht. Dann fiel auf einmal auf,
hey, einer von uns hatte eine Buchreihe als Referenz angegeben
Buchreihe haben wir noch nicht so richtig reingebracht, bis jetzt.
Also nehmen wir Buchreihe dazu. Buchreihe brauchen wir also. Naja,
objektorientiert neben die vorhandenen Klassen an der richtigen Stelle die Klasse eingehängt.
Das sehen Sie jetzt hier auf der linken Seite, die Buchreihe.
Die hat einen Herausgeber, einen Titel und einen Verlag,
aber ui, eine Buchreihe hat kein Ja.
Mist. Also Mussten wir aus der Oberklasse das Jahr rausnehmen,
weil das Jahr war nur bei diesen hier,
bei Artikel zeitschrifttechnisch Report und Buch kennzeichnet, aber nicht für Buchreihe.
Okay, da haben wir also gemerkt, hm, haben wir nicht weit genug geguckt.
Ein zusätzliches Element, was wir dachten, dass einfach dazukommt,
verändert unseren Entwurf bis in die Oberklasse rein.
Das ist nicht gut. Also da merkt man schon,
hm, ob das so clever war, wie wir das gemacht haben.
Also uns ist es damals nicht aufgefallen,
dass das nicht so clever war, was wir gemacht haben.
Aber hier merkt man schon, Was wir hier rausziehen können,
ist, sollte es im praktischen Einsatz dieses Systems,
sollte es die Notwendigkeit geben, die bibliografischen Gegenstände,
mit denen man arbeitet, zu erweitern,
müssen wir uns die Frage stellen, wie erweiterbar ist dieser Entwurf?
Und wir haben gerade gemerkt, dadurch, dass uns die Buchreihe aufgefallen ist,
dass unser Entwurf nicht so wirklich gut erweiterbar ist,
weil wir müssen nicht nur eine einzelne Klasse hinzufügen,
wir müssen Oberklassen verändern.
Wir müssen Oberklassen verändern und entsprechend in Unterklassen die Korrektur nachziehen,
sonst läuft das System merkwürdig. Auch so Ideen,
das Ja oben zu lassen und bei Buchreihe einfach leer zu lassen.
Das hat schon, ja, in agiler Softwareentwicklung, würde man sagen,
das sind so Bad Smells, das riecht ranzig. Ja,
also wenn man schon solche Tricks machen muss,
wie irgendwo das Attribut Ja auf Null setzen,
aber nicht eigentlich null meinen, nicht das Ja null,
sondern meinen, dass null was Besonderes heißt,
nämlich hier gibt es kein Ja,
wenn sie anfangen,
sowas zu bauen,
dann sollten irgendwo
die Alarmglocken läuten
Dann sollten Sie sagen, wenn ich ehrlich bin, ist dieser Entwurf ziemlicher Mist.
Wenn ich mit solchen Tricks mir größere Korrekturen ersparen muss,
ja, wer versteht das noch? Ich sage das deshalb,
weil wir haben Dutzende Programme gesehen,
wo die Entwickler über die Jahre scheinbar sprechende Attribute verwendet haben,
um dort was ganz anderes reinzukorrigieren,
zu kodieren, an Daten unterzubringen,
weil sie das Softwaresystem nicht mehr
richtig verändern konnten
Ja, wir haben so Sachen gehabt,
dass es drei möglich, dass es Adresse 1,
2 und 3 gab, aber da wurden jetzt,
weil drei Adressen hat in dieser Firma selten jemand von den Kunden gehabt,
auf der dritten Adresse hat die Vertriebsabteilung irgendwie so vertriebsrelevante Texte reingeschrieben.
Ja, das heißt, es war bekannt unter den Entwicklern,
Vertriebsinformationen stehen im Feld Adresse
3. Ganz üble Hacks
Wenn man versucht, automatisch über diese Adressbestände zu gehen und diese Adressen zu sortieren und sortiert,
dann auch noch über das Feld Adresse 3,
kommt ziemlich viel Müll bei raus.
Nur so, das ist jetzt nicht hier so ein Mickey-Maus-Beispiel,
wo irgendwelchen Leuten in einer Wissenschaftsinstitution irgendwas Merkwürdiges eingefallen ist.
Okay, an dieser Stelle genug mit diesem Beispiel,
ich will jetzt eine andere Sichtweise in nahelegen. Das ist die Sichtweise,
die wir dann hier an der Uni in den Übungen versucht haben,
nahe zu bringen. Das heißt, wir haben hier versucht,
schon mal die Herangehensweise an die Aufgabe zu verändern und nicht zu sagen,
ich als Entwickler, wie gehe ich denn mit einer Bibliothek um,
aha, Literaturhinweise für meine Artikel?
Nein, wir sind in unserer Instituts oder Fachbereichsbibliothek gegangen,
haben dort mit den Leuten geredet und haben gesagt,
was ist denn hier so, was steht denn hier so an?
Was sind eure Aufgaben? Mit was habt ihr es zu tun?
Wer sind die Akteure? Jetzt kann ich mir das für die Uni vorstellen,
aber ich kann mir das auch in einer Firma vorstellen,
dass es dort eine Bibliothek gibt, haben der Verwaltungsaufwand,
der lästige Aufwand soll minimiert werden, ist immer wieder ein Thema.
Also wie können die Leute, die dort arbeiten in der Bibliothek,
das, was sie eigentlich für sie machen sollen, effizienter machen,
nämlich sie beraten, bestimmte Bücher zu finden oder bestimmte Bücher auszuwählen,
statt sich mit der Verwaltung von Buchbeständen rumzuschlagen?
Also wie kann man das unterstützen? Also so eine ganz andere Herangehensweise,
um dann zu fragen,
wenn wir die Aufgaben in einer Bibliothek so halbwegs verstanden haben,
die zweite mindestens so wichtige Frage zu stellen, Entschuldigung,
Welche Aufgaben von denen, die wir identifiziert haben gemeinsam,
sollen denn als erste durch IT, durch Anwendungssysteme unterstützt werden?
Eine ganz, ganz wichtige Frage, die sie in jedem Projekt stellen sollten,
weil oft werden sie mit Pflichtenheften konfrontiert,
wo irgendjemand reingeschrieben hat, was sie so alles programmieren sollten.
Und keiner hat sich so richtig die Frage gestellt,
was sind die relevanten Aufgaben und welche von diesen Aufgaben sollen denn überhaupt unterstützt werden?
Wo macht es Sinn? Was schaffen wir zeitlich?
Was schaffen wir mit den vorhandenen Leuten im Team.
Was schaffen wir mit dem vorhandenen Geld? Und was macht
für den Anwendungsbereich überhaupt Sinn? Und das ist eine sehr grundlegende Erfahrung,
die, wenn sie einmal auf diese Idee gekommen sind,
so heranzugehen, das wird ihre Arbeit entscheidend verändern.
Gut, wir haben also Interviews geführt,
wir haben mit den Leuten gesprochen, wir haben festgestellt,
das ist nochmal ganz einfach, es gibt Benutzer,
es gibt als Akteur die Rolle Bibliothekar und es gibt Lieferanten,
die die Bücher die Zeitschriften anliefern.
So, was sind die großen Aufgabenbündeln? Es gibt zwei große Aufgabenbündel. Das eine,
mit dem die Leute, die in der Bibliothek arbeiten,
die Bibliothekar, viel zu tun haben,
ist die richtigen Bücher und Zeitschriften günstig zu beschaffen.
Ist etwas, da bekommen sie nur ganz wenig mit,
weil sie gehen davon aus und dürfen davon ausgehen,
unser Fachbereich Bibliothek ist sehr gut organisiert und sehr gut sortiert,
dass schon zu einer Lehrveranstaltung die Bücher da sind,
zu Beginn des Semesters,
die sie auch brauchen
Davon, dass wir als Lehrende mit unserer Bibliothek aushandeln,
welche Bücher wir im nächsten Zyklus von SE1,
SE2 verwenden und dass die rechtzeitig beschafft werden und bei wem
sie beschafft werden, kriegen sie nichts mit.
Also das ist ein Aufgabenpaket, an dem sind sie eigentlich nicht beteiligt.
Aber sie sind beteiligt an dem zweiten Aufgabenpaket, nämlich,
dass sie Bücher ausleihen wollen,
entweder mittlerweile in gedruckter Form oder in elektronischer Form.
Das heißt, da haben sie,
da kommen sie jetzt als Benutzer ins Spiel
So, das heißt, die Frage, die sich dann stellt,
für welchen Bereich wollen wir überhaupt hier Software bauen,
für beide Bereiche oder für einen Bereich, naja,
für das, was wir gemacht haben in den Übungen,
haben wir uns natürlich den Bereich rausgenommen,
der ihnen dann auch vielleicht ein bisschen bekannter ist.
Also was passiert insgesamt so in diesem Ausleihvorgang, in dem Ausleihsystem?
Okay, da gibt es bestimmte Teilaufgaben,
die man erkennen kann. Sie können Bücher ausleihen zurückgeben.
Okay, das ist das Standardgeschäft
Sie können ein Buch, was sie haben wollen,
aber was sie im Moment nicht da ist, vorbestellen.
Da erwarten sie, dass das funktioniert. Und
wenn Bücher nicht da sind und sind länger nicht da,
was bei Studieren natürlich faktisch nie vorkommt,
man muss sowas haben wie ein Mahnwesen, dass die Leute,
die verbummeln, die Bücher zurückzugeben, dass die irgendwann dann tatsächlich zurückkommen.
So, das sind also jetzt die Teilaufgaben,
die mit der Ausleihe zu tun haben, im weitesten Sinne.
Und wenn sie das verstanden haben, haben sie jetzt schon mal
ziemlich viel mehr verstanden
So, jetzt überspringe ich die Analyse dessen, wie läuft Ausleihe,
wie läuft Rückgabe, wie läuft Vorbestellung, wie läuft Mahnung.
Das müssen Sie ja auch ansatzweise verstanden haben,
wenn Sie dazu irgendetwas bauen wollen.
Ich gehe mal einen ganzen Schritt weiter im Entwurf und sage,
was kommt denn dabei raus, wenn Sie das halbwegs verstanden haben?
Welche Gegenstände sind denn auf einmal wichtig,
mit was arbeiten die Leute dort?
Naja, wir entdecken wieder unser Buch,
unseren technischen Report und unsere Zeitschriften
mal als drei Beispiele
Auch sie als Studierende oder ich als Dozent gehe mit diesen Dingen
in meiner Arbeit um und will die haben von der Bibliothek.
Und die Bibliothek muss sie ausleihen, muss sie zurücknehmen,
muss sie in die Regale stellen, was auch immer.
Das ist eins, was wichtig ist. Gegenüber diesem strukturorientierten Ansatz,
den wir vorhin haben, haben wir aber festgestellt,
für die Leute in der Bibliothek ist jetzt gar nicht so wichtig,
dass ein Buch einen Titel hat oder ein Autor,
sondern die unterscheiden die Dinge,
die sie ausleihen und die,
die sie nicht ausleihen
Das ist für deren Arbeit das Wichtigste, Unterscheidungsmerkmal.
Wenn Sie sich mit Bibliotheken etwas allgemeiner beschäftigen,
werden Sie sehen, dass das für die meisten Bibliotheken gilt,
dass es einen Unterschied gibt zwischen den Exemplaren, den Gegenständen,
den Büchern, den Zeitschriften, die Sie ausleihen können und die,
die in der Bibliothek bleiben müssen.
Weil damit macht man verschiedene Sachen. Also ist der Oberbegriff,
den wir jetzt als erstes geprägt haben,
nicht irgendwie was Abstraktes, bibiografisches Exemplar oder so,
sondern Sammelgut
Weil, Sammelgut ist der Begriff, den die Bibliothekar und Bibliothekarin selbst verwenden.
Das ist nichts, was wir uns ausgedacht haben.
Also, was merken wir uns? Vorhin haben wir die Begriffe vergeben,
so wie sie uns eingefallen sind, wie wir die Dinge genannt haben.
Und hier als Ergebnis unserer Analyse und Entwurfsarbeit
haben wir Begriffe verwendet, die in der Bibliothek gebräuchlich sind.
Ein ganz wichtiger Unterschied. Und wir haben gesehen,
dass das, was als Gemeinsamkeit für den Bereich,
den wir uns angesehen haben, was als Gemeinsamkeit,
für die Leute dort wichtig ist, ist,
dass sie Sammelgut haben,
was sie ausleihen können
Und dazu ist ganz wichtig, ein ganz wichtiger Gegenstand,
die sogenannte Ausleihkarte. So, ohne Ausleihkarte funktioniert nichts.
Also im Sinne ihrer Referenz. Ich muss eine Ausleihkarte haben und
die muss ich in Beziehung setzen können zu dem Sammelgut.
Wenn das nicht zusammenpasst, dann gibt es zwar Bücher und Zeitschriften,
aber ich weiß nicht, wo sie sind und wer sie hat.
Also ist die Beziehung zwischen Ausleihkarte und Sammelgut ganz wichtig und auf der anderen Seite,
damit überhaupt klar ist, wer hat bestimmte Dinge, muss eine Beziehung hergestellt werden zum Benutzer als Akteur auf der anderen Seite. Ganz wichtig jetzt,
auch das merkt man dann, das,
was wir versuchen, ihnen auch nahe zu bringen,
ist, sie modellieren jetzt auf der rechten Seite,
wenn da Benutzer steht, modellieren sie jetzt nicht einen Menschen,
also da ist jetzt nicht der Mensch gemeint, sondern das,
was von der Person als Modell für die Bibliothek wichtig ist,
also sozusagen sie als Person sind für die Bibliothek und für den Ausgleichvorgang nur insofern wichtig,
als dass ein kleines Modell von ihnen existieren muss und wenn
das ihr Bibliotheksausweis ist,
der sie als Person repräsentiert im Modell für die Ausleihe
Also, ganz wichtig in der Objektorientierung,
so wie wir da rangehen, modellieren wir nicht reale Menschen,
sondern wir modellieren ein Modell von unseren Menschen.
Das heißt, wir müssen verstehen, welches Modell macht sich
eine Bibliothekarin von uns als den Benutzern der Bibliothek.
Die will nämlich nur bestimmte Dinge von uns wissen.
Das ist ganz wichtig, diesen Unterschied festzuhalten. So,
wenn wir das jetzt schon mal als simples Grundmodell haben,
dann sind wir schon einen ganzen Schritt weiter.
Und dann Können wir natürlich, dann können wir natürlich
weitergehen in unserem objektorientierten Entwurfen, uns fragen.
Wir haben verstanden, dass mit dem Sammelgut und das ist Buch,
Report und Zeitschrift gibt, mal als simple Unterteilung.
Und dann macht es auch auf einmal Sinn zu sagen,
ja, was charakterisiert denn für den Ausleihvorgang ein Buch?
Die Autorenliste Titelverlag ja. Da sind wir jetzt auf der Ebene
der fachlichen Werte oder Daten angekommen, der fachlichen Daten,
die wir brauchen, um in der Bibliothek arbeiten zu können.
Aber Sie sehen, das ist nicht das,
was uns auf der obersten Ebene interessiert,
sondern auf der obersten Ebene interessieren uns andere Dinge
Das ist jetzt der Knackpunkt, auf den ich sie aufmerksam machen will.
Das ist ja auch eine Frage, bitte. So,
sie, okay, sie stellen also die Frage,
wäre es nicht trotzdem sinnvoll gewesen,
die den Titel über diese drei konkreten,
nennen wir es ruhig, Klassenentwürfe nach oben zu ziehen.
Zwischensammelgut und so, ja, kann man sich jetzt drüber unterhalten?
Gibt es Argumente dafür? Es gibt Argumente daneben,
dagegen,
auch daneben
Wenn ich aus meiner Erfahrung reden sollte, würde ich sagen,
sich über Datenstrukturen in oberen Klassen Gedanken zu machen, ist immer ein Problem.
Ja, also ich würde sowas Schwergewichtiges wie Daten,
würde ich nie sehr weit oben in meinem Klassenbaum unterbringen.
Sie vertun sich nichts, wenn Sie hier unten die Duplikate haben.
Das schadet nichts. Ja, Sie machen, Sie verbauen
sich eventuell nicht Dinge, die wir gleich sehen werden.
Denn worauf ich Sie aufmerksam machen will, der Trick,
auf den man kommen muss,
Und der den ganzen Entwurf hier von dem Entwurf vorher grundsätzlich unterscheidet,
ist, dass sich die Designer dieses Entwurfs Gedanken gemacht haben,
was tue ich mit diesen Gegenständen?
Das heißt, oben stehen jetzt nicht Strukturen,
sondern oben steht Ausleihen, zurückgeben, malen, verlängern, vorbestellen.
Weil das tut man mit allen Sammelgütern. Und ich muss
im Ersten verstanden haben, was bedeutet es auszuleihen,
zu mahnen und vorzubestellen.
Und es ist nicht mein primäres Problem zu verstehen,
was ist ein Verlagsname
Ja, also auf die Idee zu kommen,
in meine Oberklassen etwas umgangsorientiertes,
eine Verhaltensform reinzuschreiben und nicht Set und Get,
das unterscheidet einen guten, fachlich orientierten Entwurf von einem technischen Entwurf.
Ja, sie können unten das Ding runterprogrammieren mit Settern und Gettern.
Je nach Programmierumgebung kriegen sie das sogar generiert,
schreiben sie keine Zillet Codes selbst.
Das ist nur kein guter fachlicher Entwurf,
weil sie dem Ding der Klasse nicht ansehen,
was man
damit machen kann
Unser berühmtes Beispiel, was wir sicherlich schon gesehen haben,
es ist kein guter Entwurf für ein Girokonto bei der Bank,
wenn dieses Girokonto die Operationen hat, Sätze,
Saldo und Gibsaldo, statt einzahlen und auszahlen.
Da wird jeder Banker, jede Bankerin wird krank bei dem Gedanken,
dass sie den Kontostand mit Zetter und Ghetto-Operationen direkt verändern könnten.
Also, das Merkmal eines guten fachlich orientierten Entwurfs ist,
dass sie fachlich orientierte Operationen, Umgangsformen wie auch immer haben.
So, und jetzt gehen wir einen Schritt weiter. Jetzt stellen wir fest,
unser erster Prototyp, damit ist schon ganz gut gelaufen.
Das war, wir haben auch eine nette Oberfläche gebaut und damit konnte man schon arbeiten.
Und jetzt kommt aus dem fachlichen Zusammenhang jemand und sagt,
hey, Bücher ist 60s, DVD späte 80s,
DVD ausleihen ist für uns Tagesgeschäft.
Was machen wir jetzt damit? Und jetzt sehen wir auf einmal
Die Umgangsformen für die DVD, die sind richtig erkannt,
weil natürlich ausleihen, zurückgeben, mahnen, verlängern,
vorbestellen, trifft auch für eine DVD zu.
Ja, da haben wir noch nicht reingeguckt, welche Daten
eine DVD charakterisieren. Das ist uns auch ziemlich egal,
weil das tut uns an der Stelle nicht weh.
Das heißt, unabhängig von der Frage,
wie wir von den Daten her eine DVD charakterisieren,
merken wir, unser Entwurf,
unser fachlich orientierter Entwurf verhält sich gegen Erweiterungen angenehm,
sehr viel angenehmer als dieser strukturorientierte Entwurf,
den wir vorher hatten
Damit lasse ich das jetzt mal so im Raum stehen.
Sie haben eine Frage, bitte.
Also Sie fragen jetzt nach Zeitschriften, Artikel und Buchartikel.
So, das ist jetzt eine Frage,
die sich auf der fachlichen Ebene schon sehr interessant stellt.
Weil, ja? Das ist eine Überlegung,
die dann in der Diskussion kommt,
in der Bibliothek,
leihe ich nicht
einen einzelnen Artikel aus
Ja, also ich gehe ja nicht hin und reiße aus
dem Sammelband die 20 Seiten raus, die mich interessieren.
So, das heißt also... Okay, also sie kommt jetzt,
also sie sagen, also wenn ich sie richtig verstanden habe,
natürlich interessiert sie ein bestimmter Artikel in einem Buch.
Also wollen sie auch darauf zugreifen. Sehr spannend,
aber dann sind wir auf dem richtigen Weg in der Diskussion. Es ist jetzt nicht die Frage,
ob das eine richtig oder falsch ist, sondern das Argument,
das man nicht einen einzelnen Artikel ausleihen kann,
ist genauso richtig, wie ihre Anforderung,
dass sie als Student für ihre Hausarbeit einen bestimmten Artikel lesen
wollen und nicht die ganze Zeitschrift oder das ganze Buch.
So, und dann müssen wir halt überlegen, wie kriegen wir das hin?
Ich will jetzt nicht eine Lösung aus der Tasche ziehen,
aber ihnen so die Richtung zeigen. Ich will also nach
etwas fragen können, was auf der Ebene Artikel läuft.
Also ich brauchte vermutlich für bei meiner Zeitschrift und bei
meinem Buch für solche Sammelwerke noch eine Liste,
sagen wir ein Inhaltsverzeichnis oder sowas
Das muss ich abfragen können. Aber in dem Moment,
wenn ich ausleihe, muss ich leider das ganze Buch oder das ganze Exemplar der Zeitschrift ausleihen.
Und das müssen sie jetzt zusammenbringen. Das ist hier noch
nicht gelöst, aber vielleicht haben sie jetzt eine Idee,
an welcher Stelle sie was machen würden.
Und das ist, wenn ihnen das so im Hinterkopf bleibt,
wie wir uns das ausgedacht haben, wie wir das diskutiert haben,
dann ist das erreicht, was wir heute vermitteln wollen.
Es gibt natürlich eine Reihe von technischen Merkmalen,
die sie berücksichtigen müssen
Schon allein die Frage, kann ich mit diesem Bibliothekssystem nur
am Rechner innerhalb der Bibliothek arbeiten oder können Sie von Ihren Rechnern
hier in der Uni oder von zu Hause aus bestimmte Dinge auch tun?
Hat natürlich Auswirkungen auf Ihren Entwurf. Also Technik und das
Abspeichern von Daten ist nicht irrelevant. Wir wollten Ihnen nur nahelegen,
so der Weg, wie man einen fachlichen Entwurf bauen kann,
der relativ nah an den Gegenständen ist, die und den Aufgaben,
die in einem Anwendungsbereich sinnvoll sind.
Wir haben eine Reihe von Themen ganz kurz angesprochen.
Es gibt eine weitere große Liste von Themen, die dazugehören.
Einige werden sehen in ihrem Studium innerhalb des Bachelorstudiengangs noch kennenlernen.
Andere sind dann eher Diskussionen für ein weitergehendes Studium im Master
oder in ihrem Job. Ja, vielen Dank,
dass Sie mit dabei waren und vielen Dank für Ihre Aufmerksamkeit