Hier, dieses Buch. Effective Software Architecture heißt das.
Kann ich euch auch nur empfehlen im Schrank zu haben.
Von ihm habe ich diese Abbildung von den UML-Diagrammen
auf die verschiedenen Sichten. Ihr erinnert euch,
wir haben letzte Woche über Architektur geredet und Übersichten auf Architektur,
statische Sicht, fachliche Sicht, Verteilungssicht, dynamische Sicht oder Laufzeitsicht.
Und er schreibt sehr viel auch über diese Sichten und über
vernünftige Darstellungsformen und hat eben in seinem Buch die UML-Diagramme da
auch zugeordnet
Ich glaube, das habe ich jetzt in jeder Vorlesung,
habe ich über diese UML-Diagramme und ihre Zuordnung zu den Sichten gesprochen.
Das passiert natürlich auch nicht von ungefähr,
würde ich mal behaupten, dass das immer.
Wieder passiert Gesundheit im Übrigen. Gut. Und was Gernot
auch getan hat, was auch ganz schön ist,
der hat mehrere so Bücher geschrieben, die heißen immer kompakt.
Architektur, Kompakt, Magilität, Kompakt.
Also das sind so ganz kurze Bücher,
die einfach nur so ein paar Schlagworte auf ein Thema werfen
Da kann man sich, glaube ich, sogar im Buchladen
hinsetzen und die schnell durchlesen, ohne dass man sie kauft.
Also ich kann euch nur empfehlen, mal in solche auch zu schauen,
weil er auch wirklich in der Lage ist, Sachen gut darzustellen.
So, und er hat verschiedene Webseiten, die sicherlich interessant sind.
Und das hier ist eine sehr spannende Sache.
Ich habe ihn noch nie gefragt, warum das 42 heißt,
aber ihr kennt ja die 42 wahrscheinlich, ne?
Den Spaß mit der 42? Hat euch den Heinz oder Axel
nicht erzählt? Das ist der Sinn des Lebens, die 42.
Es gibt das Buch Hitchhiker through the Galaxy und da bauen die Menschen einen Rechner,
der ihnen die Frage nach dem Sinn des Lebens beantworten soll.
Und der Rechner rechnet also erst mal aus, dass er
3000 Jahre brauchen wird, um eine Antwort zu berechnen.
Und dann sagen die Menschen, okay,
dann machen wir das so und bewachen also 3000 Jahre diesen Rechner und bilden,
vielleicht sind es auch nicht 3000, ist auch egal.
Aber jedenfalls werden kurz bevor die Antwort kommen soll,
wird also auch ein, werden also Menschen auch darauf vorbereitet,
dass sie jetzt die Antwort auf die Frage nach dem Sinn des Lebens entgegennehmen sollen, sollen.
Und dieser Rechner heißt Deep Thought. Und in dem Moment,
wo er also mit der Antwort fertig ist,
sagt er also, ich bin fertig.
Und die Menschen, die vor ihm stehen, sagen,
ja, gib uns die Antwort.
Und Deep Thord sagt, sie wird euch nicht gefallen.
Das ist uns egal. Gib uns die Antwort.
Und dann sagt Deep Thord, die Antwort lautet 42.
Und dann ist man natürlich ganz begeistert. Über das viele
Geld, was man ausgegeben hat für dieses wunderbare Programm.
Gut, aber auf Arc 42 findet man Templates,
also Vorlagen, mit denen man Softwaresysteme beschreiben kann.
Das wird später im Laufe des Vortrags auch nochmal vorkommen.
Aber wenn ihr mal in einer Organisation kommt,
und feststellt, es gibt eigentlich keine vernünftige High-Level-Dokumentation darüber,
was das System da tut, dann erinnert ihr euch vielleicht,
dass ich euch davon erzählt habe, dass man da sowas finden kann.
Ja, in vielen größeren Organisationen wird sowas heute schon eingesetzt,
aber das ist durchaus auch bedenkenswert für kleinere Firmen. Ja,
was meint Gernot mit der Frage, also aus Nachbarsgarten können wir lernen,
das Bild habt ihr schon mal von mir gesehen,
es gibt in echt ganz beeindruckende Architekturen und die Gebäudearchitekten
haben natürlich über die Jahrtausende von Vorbildern gelernt und genauso etwas ähnliches müssen wir in der Softwaretechnik auch tun.
Ja, also wir müssen auch von Vorbildern lernen,
aber wir haben es natürlich nicht so einfach,
weil wir können nicht einfach mal eben um die Ecke gehen und uns irgendein wunderhübsches Gebäude angucken,
sondern wir müssen die Softwaresysteme in Projekten tatsächlich zu sehen bekommen.
Ich habe euch aber so ein paar Sachen versucht beizubringen,
die uns helfen können, also die uns sozusagen Vorbild sein können.
Was erinnert ihr denn noch so,
was ich euch die letzten Wochen erzählt habe,
was man als gutes Vorbild nehmen kann,
wenn man
ein Softwaresystem baut
Hat jemand was gesagt oder habe ich es mir nur eingebildet?
Worüber haben wir denn die letzten Wochen gesprochen? Ich bin so gemein,
aber ihr müsst euch immer erinnern, das ist eine zusammenhängende Vorlesung.
Habe ich euch in den letzten Wochen irgendwas erzählt,
wie man gut Software baut? Ja, super,
testen, aber das war jetzt nicht die richtige Antwort.
Siehst du, ist gemein, habe ich euch voll gelinkt.
Was habe ich
euch noch erzählt
Keine Ahnung, Abhängigkeiten möglichst. Ja,
lose Kopplung war das Schlagwort in dem Fall.
Sehr schön. Ja, ich finde das immer beeindruckend,
was so hängen bleibt, beziehungsweise nicht hängen bleibt.
Von Woche zu Woche. Ich sage einfach mal was.
Ich habe euch so ein paar Prinzipien letzte Woche erzählt, oder?
Ne? Prinzipien von dem Robert Martin, die sind natürlich was Gutes.
Ich habe euch vorhin Entwurfsmustern was erzählt und von Architekturstilen in der Woche
davor allerdings, das ist natürlich schon ein bisschen länger her.
Und ich habe euch sowas erzählt, was Best Practices sind
beim Entwurf, ja, oder bei der Konstruktion.
Also ich habe euch so ein paar Hinweise gegeben,
was eine gute Architektur sein könnte.
Aber natürlich sind das keine echten Systeme,
sondern das sind nur Muster oder Anleitungen, das ist völlig klar.
Es gibt auch abschreckende Beispiele. Ich habe euch auch gesagt,
wie man sowas in der Softwaretechnik nennt.
Wisst ihr das noch, wie das hieß?
Was, was nicht gut ist? Also das eine,
was ihr wissen solltet, ich habe euch erzählt,
dass man über Bad Smells spricht, wenn man auf Softwaresysteme guckt,
dass man also ein Softwarestück hat,
was irgendwie stinkt
Es riecht nicht gut. Da ist irgendwas kaputt.
Das ist ein Bad Smell. Oder man sagt dazu
auch Anti-Pattern. Also ein schlechtes Pattern, eins,
was, wie man etwas nicht bauen soll.
Das Dumme in dem aktuellen Zustand der Softwareentwicklung ist,
dass ihr hauptsächlich solche Dinger sehen werdet in eurem Leben erstmal.
Ihr werdet hauptsächlich auf kaputte Software-Systeme stoßen. Aber ihr seid natürlich die Generation,
die das dann alles gerade rückt und die nächste Generation,
die kriegt dann lauter gute Vorbilder.
So wollen wir
mal hoffen
Gut. Also in der Regel sind die Systeme abschreckend.
Und die Frage ist jetzt, was können wir tun?
Also was ist sozusagen das, was ein Software-Architekt eigentlich können muss,
um in seinem Beruf erfolgreich zu sein,
um gute Vorbilder zu bauen für die Leute,
die später kommen?
Was ist ein Software-Architekt? Tja. Also notwendige Voraussetzungen für
ein Software-Architekt ist,
dass er Technologie beherrscht
Daran werdet ihr nicht drum rumkommen. Ich weiß,
dass man hier irgendwie studieren kann,
ohne eine Zeile Source Code geschrieben zu haben,
ohne sich besonders mit den Features von Eclipse auseinandergesetzt zu haben,
ohne jemals irgendwas Verteiltes gebaut zu haben oder parallele Programmierung geradezu noch,
seid nicht so dumm.
Es geht nicht nur um die Noten, sondern es geht darum,
dass ihr das nachher könnt und hier an der Uni müsst ihr es nicht bezahlen.
Es wird euch einfach beigebracht, also neben den Studiengebühren,
die müsst ihr aber eh bezahlen,
wenn ihr einen Abschluss haben wollt.
Wenn ihr nachher irgendwo in einer Firma hockt,
dann muss euer Chef oder ihr selbst
die Fortbildung bezahlen
Nehmt alles mit, was ihr kriegen könnt.
Der Bereich mit Guido Grützern und Axel und Heinz und mir,
wir machen regelmäßig in den Semesterferien so drei,
vier Tage, sogenannte Summer Schools oder auch Winter Schools,
wenn sie im Winter sind.
Also immer in den Ferien, wo man eine Technologie einfach lernen kann.
Da gibt es zum Beispiel auch eine zu UBAP.
Das ist die Programmiersprache, die im SAP-System ist.
Es ist gut, das mal erlebt zu haben, was das bedeutet.
Also ich kann euch nur ans Herz legen, gerade euer Studium zu nutzen,
so viel Technologie wie nur möglich, euch anzueignen.
Tut das wirklich. Sonst kommt ihr da raus und könnt
nur Java und der nächste, also die Jobmöglichkeiten sind begrenzt
und Architekte werdet ihr sowieso nicht dafür, damit.
Okay, aber das ist nur, ja, guck mal,
das alles müsst ihr lesen, damit ihr euch mit Technologie auskennt.
Schön, Skala auch, ja.
Gut. Technisches Fundament. Ja. Viele, viele,
viele, viele, viele Bücher gibt es alles,
aber es gibt es alles geschrieben.
Das ist das Schöne.
Oder zum Lernen in der Uni
Also, damit ihr ein guter Software-Architekt werden könnt, müsst
ihr Software entwickelt haben. Ich habe mit Softwarearchitekten zu tun
gehabt, die noch nie eine Zeile Code geschrieben haben.
Und das ist ganz schrecklich. Die lesen irgendwo was und
dann erzählen sie dir nächstes Mal, es muss alles mit
dem Fassade-Pattern gemacht werden, was ich euch beigebracht habe.
Oder es muss alles jetzt mit diesem und diesem Schlagwort gemacht werden.
Aber die Leute haben keine Vorstellung davon und das merkt auch
jeder Softwareentwickler in dem Team, wo der Architekt davor sitzt.
Die Leute merken das. Wenn ihr nicht wisst,
was es bedeutet, irgendwas zu programmieren.
Ihr müsst programmieren können
So, jetzt wollen wir uns mal die Aufgaben angucken,
die so ein Softwarearchitekt hat.
Ihr müsst also konstruieren können, das heißt implementieren können,
auf die eine oder andere Art und Weise.
Aber ihr solltet da nicht stehen bleiben, denn ein Softwarearchitekt,
der muss auch die Anforderungen verstehen in dem Anwendungsgebiet, wo er gerade arbeitet.
Sonst endet er als Technologe, sonst ist er jemand,
der alleine sich mit Technologie auskennt und eigentlich
gar keine Hinweise geben kann,
wie konstruiert werden muss
Also in meinem letzten Projekt war es unglaublich wichtig zu verstehen,
was diese Systeme eigentlich sollen, um mich damit auseinanderzusetzen,
wie die Nachrichten zwischen den Systemen fließen sollen.
Also man muss verstehen, wie ein Container auf ein Terminal kommt,
um sich den Nachrichtenfluss wirklich, also den richtigen Nachrichtenfluss aneignen zu können.
Ja, also wir hatten dann die Tester,
die sagten, das funktioniert hier immer nicht.
Ja, ich mache in dem einen System dies und dann
passiert in dem anderen System aber das.
Und gestern war es aber anders und heute
Morgen war es so und jetzt war es eben so.
Ja, das kann natürlich mit unglaublich viel zu tun haben.
Und wenn ich alleine nur weiß,
dazwischen gibt es ein JMS-Protokoll und die Schnittstelle ist asynchron oder sowas,
das nützt mir überhaupt nichts, um nachvollziehen zu können,
woher hier der Fehler kommt.
Ich muss also mich mit den Anforderungen auseinandersetzen
Tja, und das ist ganz wichtig. Ich muss kommunizieren
können, um das alles in den Griff zu bekommen.
Ich muss in der Lage sein, mit Menschen zu reden.
Ich weiß nicht, ob ihr auch zu dem,
ob ihr euch zu dem, zu der Generation 160 Zeichen zählt oder sowas.
Ja, ich bin auch ein großer Fan von SMS,
wenn ich asynchron irgendwelche Hinweise an Leute geben will oder wenn ich abends
um acht meine Mitarbeiter nicht mehr anrufen kann oder will oder darf, wie auch immer.
Aber ich bin mehr und mehr auch,
ist mir klar geworden, ich muss die Leute anrufen.
Ich muss mit ihnen persönlich reden. Also E-Mail ist schön
und gut
Aber also ich sage es euch nur,
wenn ihr was von mir wollt,
dann kommt lieber vorbei oder ruft mich an.
E-Mails sind solche Menge, das kriegt keiner in den Griff.
Also ihr müsst kommunizieren. Und das letzte Wichtige dabei noch ist,
man muss bewerten können. Man muss in der Lage sein,
das, was man vor sich sieht, einschätzen zu können.
Und ich habe dann gemerkt, oh,
hier fehlt auch noch ein Pfeil, natürlich.
Eins meiner Lieblingsthemen hier ist das. Ja,
die Implementation bewerten zu können, das ist ganz wichtig.
Da werde ich nachher auch noch was zu sagen.
Aber man muss eben auch in der Lage sein,
einen Entwurf bewerten zu können, also nur auf ein Papier gucken zu können hier.
Und zu bewerten,
ob die Anforderungen überhaupt relevant sind und zu kommunizieren mit
den Leuten
Ja. All diese Sachen, also die Kommunikation zu bewerten,
die da zwischen den Leuten herrscht.
Und einzuschreiten, wenn etwas schief geht. Wir werden uns
das jetzt im Detail nochmal angucken, was jedenfalls nicht reicht,
ist das. Ich habe euch zwar eben gesagt,
ihr sollt hier in der Uni so viele Technologien lernen wie nur möglich,
aber ich sage euch auch gleich, das wird nicht ausreichen.
Ihr müsst auch noch mehr lernen. Es ist ein ineffizienter
Lernfokus, wenn ihr euch nur auf das Implementieren beschränkt.
Ich weiß zum Beispiel, dass es in der Uni
mehrere Dinge gibt, wo man lernen kann,
im Team
zu arbeiten
Teamarbeit, also in Gruppen. Für mich war das
sehr erhellend. Ich habe mal so einen Kurs mitgemacht,
der ist auch in Stellingen immer Freitag, Samstag oder so.
Da sollten wir uns in Teams finden und dann kriegten wir irgendeine Aufgabe.
Ich weiß gar nicht, was wir sollten. Wir sollten irgendwas berechnen,
irgendeinen Algorithmus aufschreiben und dann fingen diese Gruppe an zu diskutieren.
Also ich saß da irgendwie mit vier Leuten und ich habe
dann ein bisschen mitdiskutiert,
aber es ging überhaupt nicht voran und dann habe ich mir
irgendwann einen anderen geschnappt und dann haben wir
die Lösung gemacht
Und wir waren total stolz. Und dann sagte der Supervisor
hinter zu uns, ja, aber darum ging es gar nicht.
Es ging ja nicht darum, eine Lösung zu machen,
sondern es ging darum, als Gruppe zusammenzuarbeiten, als Team.
Ich weiß nicht, ob euch das in euren kleinen Übungsgruppen
zu zweit jetzt im Impere schon so geht.
Aber das ist natürlich nicht der Sinn der Sache vom Kommunizieren,
dass man den anderen sozusagen überfährt mit seiner Lösung.
Und das wird euch, glaube ich, dann jetzt auch einholen,
wenn ihr in kleinen Gruppen nachher das Projekt macht.
In Teamarbeit ist nicht so einfach hinzukriegen
Gut, also, was müssen wir alles können?
Wir müssen Anforderungen verstehen, wir müssen konstruieren können,
keine Frage, wir müssen kommunizieren können und wir müssen bewerten können.
Die gucken wir uns jetzt nochmal alle einzeln an und ich erzähle noch
ein paar Sachen dazu, was ich dafür besonders wichtig halte.
Das erste ist, ihr müsst verstehen, Domain Knowledge,
also ihr müsst verstehen, was da für eine Fachlichkeit herrscht,
wo ihr hinkommt.
Also es gibt Leute, die zum Beispiel Architekten für ein bestimmtes Anwendungsgebiet sind.
Also mein Kollege zum Beispiel ist hauptsächlich im Versicherungs- und Bankensektor unterwegs.
Und das ist total entscheidend, dass er weiß,
was gibt es eigentlich für Sparten in der Versicherung?
Wie ist das in den Banken eingeteilt?
Was sind die grundsätzlichen Prozesse? Da steckt eine große,
große Menge hinter. Und es gibt auch viele Firmen,
die haben sich sozusagen auf einen Sektor fokussiert.
Ich weiß nicht, ob ihr das manchmal wahrnehmt.
Es gibt Firmen, die arbeiten nur im Logistikbereich.
Also die haben sich auf eine Domäne und es gibt
auch viele Firmen, die arbeiten nur im Bankenbereich.
Also ohne das wird es
nicht gehen
Und dazu muss man eigentlich die direkte Erfahrung haben.
Also es hilft leider wenig Pflichtenhefte zu lesen. Also wenn
ihr in eine Firma kommt und ihr sollt etwas implementieren dort,
was man mit neuen Leuten immer gerne macht.
Man gibt ihnen also ein Pflichtenheft und sagt, bau mal,
weil man will, also mach erstmal einen Entwurf,
mach eine Schätzung und dann baue das mal.
Ja, so ein Pflichtenheft für so ein kleines Teil.
Ist gerade auch wieder einem Kollegen von mir passiert,
der neu in eine andere Firma gekommen ist, also als Externer.
Und dann sollte er also erstmal aus einem Pflichtenheft einen Entwurf
machen und eine Schätzung. Wenn ihr irgendwie könnt,
versucht, über das Pflichtenheft hinaus diese Anwender kennenzulernen.
Fragt euren Chef, ob ihr nicht mal mit jemandem reden könnt,
der das nachhat, der die Arbeit macht.
Dann gibt es immer erstmal große Dramen. Nein, das geht
auf gar keinen Fall. Der hat keine Zeit und so.
Aber ihr müsst es irgendwie hinbekommen. Ihr müsst es irgendwie hinbekommen,
mit den Leuten zu arbeiten, die da sozusagen die Stakeholders sind.
Also die arbeiten nachher mit eurem Werkzeug tun.
Ich war mal, ich habe mal, war das auch,
ja, das war auch eine Versicherung.
Da habe ich mal eine Schulung gemacht,
so wie entwickelt man objektorientierte Systeme und wie geht man da vor?
Und dann hatte ich also so zehn Entwickler da sitzen und haben gesagt,
so und jetzt machen wir mal Anforderungsermittlung. Das heißt,
wir holen uns mal einen Anwender und machen mal Interviews mit dem.
Wir haben nämlich schräg angeguckt und haben gesagt, muss das sein?
Also wir wissen doch viel besser, was die da machen.
Wir haben doch die Systeme gebaut. Die benutzen die Januar
, die wissen ja gar nicht. Ich habe gesagt,
ja, ja, mag ja sein. Wir holen die
jetzt aber her, weil das lernen wir jetzt so.
Und dann war also eine Anwenderin zum Interview da und das ging so los.
Und dann hat sie erzählt, was sie wirklich macht mit dem System. Ja,
also es ging darum, dass wenn Versicherungen eingegangen sind,
dann hat die die eingetippt, die ganzen Daten von den Kunden und dann mussten bestimmte Briefe verschickt werden.
Und die Frau hat uns also erzählt,
dass in gewissen Konstellationen sie, also nachdem sie das eingegeben hat,
in die Poststelle geht, damit der Brief nicht verschickt wird,
den sie quasi gerade ausgelöst hat, weil sie noch weitere Bearbeitungen machen muss.
Die kann sie aber erst am nächsten Tag machen,
nachdem diese eingegebenen Daten in die andere Datenbank übertragen worden sind und dann ändert sich der Brief,
dann kommt ein neuer Brief und sie will halt nicht,
dass der Kunde erst den einen Brief kriegt,
in dem drin steht, dass er aber nur so und so viel Prenzprozent kriegt,
sondern sie will, dass er gleich den anderen Brief kriegt.
Und der geht aber erst nach einem Tag,
weil die Daten nur nachts verarbeitet werden
Ja, und diese zehn Entwickler da,
die haben Bauklötze gestaunt, weil sie das gar nicht wussten.
Die konnten sich das nicht vorstellen. Ja,
also Pflichtenherfte werden in der Regel von Leuten geschrieben,
so, dass da drinsteht, wie es idealerweise funktioniert.
Und es ist in der Regel nicht so. Ja,
also versucht, an die Anwender ranzukommen, mit denen zu reden.
Das muss man als Architekt wissen und sich auch trauen.
Ja, kommunizieren, habe ja schon gesagt, wie wichtig das ist.
Das geht mal so, ne, so geht das.
Ja, ist auch völlig okay, ja. Lieber so,
als als ganz entfernt, ja, also schon sind alles Macs.
Ja, Gernot Starke ist ein Apple-Fan.
Also so, ich habe die dann jetzt nicht ausgetauscht.
Auch all diese Möglichkeiten der Kommunikation halte ich für unglaublich wichtig.
Ich habe also gestern Abend ein Go-To-Meeting gehabt,
um 9 Uhr abends mit Leuten aus Chicago,
die unsere Möglichkeiten, aber Systeme zu analysieren, gerne kennenlernen wollten.
Und das war natürlich total praktisch. Ich konnte also mit denen
reden übers Internet und musste da nicht hinfahren und konnte denen
meinen Bildschirm zeigen und ein bisschen zeigen, was da alles funktioniert.
Also alles wunderbar
Aber das könnte auch dabei rauskommen. Also es ist natürlich trotzdem wichtig,
dass ihr mit den Leuten redet und dass ihr das gut hinkriegt.
So soll es jedenfalls nicht sein. Insofern möchte ich euch empfehlen,
guckt euch an, was andere Leute machen, wie die kommunizieren.
Also versucht zu lernen von guten Vorbildern, geht auf irgendwelche Kommunikationsseminare,
sonst werdet ihr später irgendwann von den anderen Leuten überholt.
Sonst sitzt ihr später in der Ecke und macht,
keine Ahnung, verwaltet die Hardware oder programmiert ist an euer Lebensende.
Kann man auch wollen, aber die Erfahrung zeigt,
dass die Leute das dann meistens doch irgendwann nicht mehr wollen.
Also ihr könnt ja dann später mal checken, ob es
so gelaufen ist, aber ich weiß das noch sehr genau.
Wir haben bei uns in der Firma immer einmal im Jahr
so ein großes Kundenmeeting. Da kommen so 70 Kunden und
wir haben so Vorträge und so bis vor fünf,
sechs, sieben Jahren fand ich das schrecklich.
Ich fand es so schrecklich. Mit diesen ganzen Kunden da,
die ich dann, wo ich dann nur die Hälfte,
und was soll ich mit denen reden und so.
Und dann irgendwann plötzlich ein, ich weiß nicht warum,
aber ganz plötzlich war wieder dieser Event und ich war da und
ich hatte unendlich viel Spaß mit all diesen Leuten zu reden.
Mit all diesen Kunden, die auch nicht anders waren als das Jahr zuvor.
Also es gibt irgendwo so Ende der 30er,
Anfang der 40er so eine Schranke, wo man keine Lust mehr hat.
Es hat letztens auch ein Kollege zu mir gesagt, ja,
ich mache bei dieser Firma Erwartung und ich fand das auch immer toll mit diesem Entwickeln.
Aber ich habe irgendwie keine Lust mehr. Jetzt das nächste
neue Framework kennenzulernen und noch wieder, was jetzt hip ist.
Und jetzt müssen wir, keine Ahnung, jetzt müssen wir
GWT lernen und Ajax machen und es kommt immer wieder,
immer wieder was Neues
Irgendwann will man was anderes machen und darauf muss man sich vorbereiten.
Also, üben, üben, üben, üben.
Und was da noch ganz besonders dazugehört ist,
nehmt bitte jede Gelegenheit wahr, einen Vortrag zu halten.
Stellt euch nach vorne und wenn ihr noch so viel Angst
habt und geht in die Seminare, haltet Vorträge über,
egal was, man kann das nur über Übung lernen.
Man muss es irgendwann tun. Sonst kann man nicht hier
vorne stehen irgendwann. Und kann auch nicht vor irgendeinem Vorstand
präsentieren oder sonst was
Das gehört auch zu kommunizieren. Vorträge halten zu können,
zu wollen, sich zu trauen. Na,
und was noch zu kommunizieren gehört,
da sind wir wieder bei einem Teil meines Lieblingsthemas,
ist in der Gebäude, in der Gebäudearchitektur,
gibt es eine unglaubliche Menge an standardisierten Notationen darüber,
wie man Architektur macht.
Und das ist was, was wir ja auch versuchen in
der Softwarearchitektur uns abzugucken.
Also Gebäudearchitekten haben Pläne für das,
was sie da machen
Das habe ich euch ja auch versucht ein bisschen zu vermitteln,
dass ihr das in der Architektur auch braucht.
Wir brauchen auch standardisierte Notationen, Strukturen,
irgendwelche Normen für Syntax, Semantik und Gliederung.
Und das gehört auch in den Bereich Kommunikation.
Ich habe jetzt eben darüber gesprochen, redet mit Leuten,
versucht mit Leuten zu reden, haltet Vorträge. Und das letzte,
oder das dritte, was noch auf euch zukommt, ist,
ihr müsst auch schreiben können und verständliche Bilder machen können.
Das kann man in Vorträgen üben, ja,
kriege ich das hin, irgendeinen Inhalt sinnvoll darzustellen,
aber spätestens in der Bachelorarbeit,
aber ihr müsst auch Seminararbeiten schreiben oder sowas,
ne,
In eurem Leben, ne? Jetzt mehrfach, okay.
Macht das. Holt euch Feedback. Ich habe
meine ganzen Arbeiten früher immer so geschrieben,
dass ich die einem Kommunitonen zum Lesen gegeben haben.
Und ja, man muss das üben. Das kann keiner von so
. Und bei der Masterarbeit wird es nachher noch schlimmer.
Und bei der Doktorarbeit wird es dann so richtig schlimm.
Ja. Gut. Also wir haben in der Architektur irgendwelche Pläne,
Normen und in der Softwaretechnik haben wir das auch.
Ihr habt UML schon gelernt
Ich habe euch versucht zu vermitteln, dass ich keinen Anhänger von Diagramm-Akribie bin oder sowas.
Aber ich möchte, dass ihr wisst, was ihr da ausdrückt.
Und wenn ihr ein Bild von der Statik macht,
dann macht ein Klassendiagramm und wenn ihr ein Bild von dem
Objekten im System nachher, also von der Dynamik macht,
dann macht ein Objektdiagramm und nicht falsch rum oder durcheinander.
Gut, also es gibt UML, es gibt auch noch andere Notationsformen.
Ich habe euch hier das Arc 42 mit aufgeschrieben.
Das ist also auch dazu da, um zu kommunizieren,
um für die anderen Leute
was vorzuhalten
Was aber noch ganz, ganz wichtig ist und was ich
euch gerne vermitteln will, ist, es nützt nichts,
diese Bilder oder diese Texte irgendwo auf dem Rechner zu malen,
zu schreiben und auf irgendeinem Laufwerk abzulegen irgendwo.
Ja, das ist zwar schon gut und die anderen Mitglieder im Team können das auch finden,
aber das geht verloren, das müllt weg, ja,
man sieht es nicht mehr. Es ist ganz wichtig,
dass ihr, wenn ihr in irgendein Projekt kommt,
dass ihr etwas schafft oder hoffentlich auch findet, etwas,
was man aufhängen kann an der Wand, dass alle sehen,
Was für eine Software haben wir hier?
Ich war mal bei SAP in Waldorf und habe mir da
Teile von dem Net-Weaver-System angeguckt und die vermessen.
Und in jedem Raum war eine große Tapete des ganzen Systems.
Und man konnte sagen, ich entwickle hier, da bin ich.
Das ist meins. Versucht, sowas zu schaffen. Ich weiß nicht,
ob ihr in euren Firmen, wo ihr seid,
irgend so etwas habt, wo man sieht,
was sind hier eigentlich für Systeme,
wer entwickelt wo.
Wir nennen das IT-Landschaft
Und das wird im Moment mehr und mehr wichtig,
dass man die IT-Landschaft eines Unternehmens aufmalen kann.
Dafür gibt es keine Standardnotationen. Das macht jeder,
wie er will. Da sind meistens so Bubbles und
dann sind Pfeile dazwischen und die Dinger haben Namen.
Damit man verstehen kann, aus was für Teilen ein Softwaresystem besteht.
In der Regel muss ein Architekt dafür sorgen,
dass man so etwas hat.
Das ist nicht von Soda
Wenn es feste Strukturen gibt, feste Dokumentationen,
dann werdet ihr schneller in dem, was ihr tut.
Ihr könnt schneller kommunizieren. Ihr senkt das Risiko,
dass das Projekt irgendwie schief geht und ihr erhöht die Verständlichkeit.
Also ich habe ja lange in so einem größeren Projekt so,
also es ist noch kein Großprojekt, aber so 60,
70 Leute, die das Ganze wuppen müssen,
dass das System ins Betrieb geht, sind schon eine ganze Menge.
Und ich habe mir regelmäßig also Pläne ausgedruckt und die bei mir an die Wand gehängt,
wenn die Leute nämlich bei mir reinkamen und sagten,
ich komme nicht klar, wann soll das fertig sein,
wo sind wir hier, dann muss man auf etwas zeigen können.
Und das muss immer gleich aussehen, am besten,
ja, also auch Projektpläne, Denn das höchste Risiko,
was man in größeren Projekten hat, ist,
dass die Leute nicht wissen,
wo sie sind und was sie tun sollen.
Also so eine Verwirrung, die dazu führt,
dass man in sein Büro geht, die Tür zumacht und das macht,
was gerade so am einfachsten ist.
E-Mails beantworten zum Beispiel. Aber nur welche, die nicht kritisch sind.
Ihr werdet mehr über agile Softwareentwicklung lernen hier bei uns.
Und eine der entscheidenden Messages von all diesen Methoden ist,
man muss das Schwierigste zuerst machen.
Das, was einem am unangenehmsten ist,
wo man so guckt und denkt, oh,
das wird ein ganz übler Brocken
Was ist denn die normale menschliche Tendenz, wenn man vor sowas steht?
Die normale menschliche Tendenz ist zu sagen, oh,
oh, da hinten, ich mache erst mal das hier.
Das ist einfach, ja, wenn ihr mal ein Architekt seid,
dann erinnert ihr euch hoffentlich daran und macht das Schlimmste zuerst.
Aber euer Team, mit dem ihr das dann macht,
wird unglaublich glücklich sein. Weil wenn ihr das Schlimmste
zuerst macht, wird es hinterher alles ganz einfach.
Nur das muss man sich trauen. Und wenn man solche Sachen darstellt,
dann ist es natürlich noch besser, aber ich meine,
jetzt bin ich ein bisschen abgeschwoffen in die Risiken weg von den Strukturen.
Ja, Risiken kann man auch erkennen, ohne Bilder zu
Tja, und dann wäre es natürlich toll,
wenn man andere Architekturen angucken könnte.
Wir leben ja zum Glück im Zeitalter des Open Source.
Das heißt, man kann sich andere Systeme angucken.
Aber das hat seine Tücken. Und wir leben im Zeitalter
, wo überall ganz viel tolle Software rumsteht.
Das gibt es einmal bei den hübschen Gebäuden.
Ich zeige euch noch diese schönen Bilder.
Da würde man gerne mal hin
Oder das zum Beispiel, das ist klasse.
Das ist ein Haus, was keine Heizung braucht,
weil durch die besondere Anordnung der Fenster außen ist dieses Haus in der Lage,
je nach, egal welche Temperatur von außen herrscht,
in ein angenehmes Klima herzustellen.
Fand ich total cool. Kann man sich im Internet angucken
. Das wäre doch klasse, oder? Wenn wir
ein Software-System bauen könnten, was keinen Strom braucht.
Naja, okay. Das ist vielleicht ein bisschen übertrieben.
Wasser brauchen die Leute trotzdem noch da drin. Und ihr
kennt eine ganze Reihe bestimmt von diesen ganz berühmten Systemen. Ja,
das wäre doch erstmal ein Anfangspunkt, mal zu gucken,
okay, wie machen denn die Flickers eBays,
YouTubes und Twitters dieser Welt das?
Wie machen die das
Wir hatten letzte Woche auch den Kollegen von Xing bei uns,
der erzählt hat, wie macht Xing das eigentlich?
War sehr spannend. Und dann sieht man immer solche Sachen.
Ja, das Internet, das Internet. Und davor irgendwelche
Server, die entscheiden, wo die Anfrage jetzt hinkommt,
die man da gestellt hat.
Vielleicht will man nur irgendwelche gecasheden Daten lesen,
weil man zum Beispiel das Xing-Prop-Profil von irgendjemandem anders aufruft,
dann wird man wahrscheinlich hier landen in diesem Bereich
Oder man will irgendetwas eingeben, weil man jetzt bei Web.de,
naja, bei Fligger will man halt ein Foto hintun,
ja, man will nicht nur welche angucken,
sondern man will ein Foto hintun,
dann wird man wahrscheinlich hier landen, eher auf der PHP-Seite,
also man kann daraus schließen, Fligger ist in PHP gebaut,
ja, das ist ja schon mal eine interessante Information.
Und dann gibt es irgendwelche, also Unmengen von irgendwelchen Servern,
die irgendwas clustern, irgendwas aufheben, speichern.
Oh, hier auch noch so ein Ding.
Und hier gibt es irgendwelche Anwendungen in.net auch noch offensichtlich.
Also, das solltet ihr beides lernen,
wenn ihr irgendwann mal bei Fligger arbeiten wollt.
Na, und hier hinten die ganzen Search Engines,
die auch noch dazugehören
Total coole Architektur. Großes System, sehr großes System,
muss in einer Sekunde 40.000 Fotos hergeben,
100.000 Cash-Operationen machen und 130.000 Datenbankanfragen verarbeiten.
Ist bestimmt ein tolles Vorbild,
nur dummerweise werdet ihr wahrscheinlich nie
sowas bauen
Also was soll man davon lernen? Für die Arbeit,
die man nachher macht. Ihr werdet wahrscheinlich nicht
bei Flickr arbeiten. Außer ihr seid, ihr kriegt,
habt noch irgendeine coole Idee und baut irgendwas ganz Neues.
Dann könnte es sein, dass ihr Google-ähnliche oder Flickr-ähnliche Erfahrungen macht,
aber dann werdet ihr wahrscheinlich, wenn es so weit ist,
dass das System so groß ist,
eh nur noch das Geld verdienen und nicht mehr die Architektur machen.
Aber ganz davon abgesehen, also das ist zwar hübsch,
aber es ist wenig hilfreich.
Trotzdem finden Menschen aus der IT sowas immer unglaublich interessant und deswegen
hat Gernot Stärke etwas sehr Hübsches gemacht, finde ich.
Das zeige ich euch auch.
Der hat gesagt, er hätte eine Kohlheitsvermutung
Also eine Vermutung darüber, was besonders cool ist.
Technisch, technische Themen, komplexe Themen, die sind cool.
Ich weiß nicht, ob das euch so auch so geht.
Und das gehört auch zu den Sachen,
die man als Architekt im Blick behalten muss.
Die Leute wollen unheimlich gerne neue Technologie ausprobieren.
Ja, Spring kenne ich schon. Strats kenne ich schon
. Ich will jetzt SWT machen. Hast du schon mal
SWT gemacht? Nö, aber das ist doch spannend.
Glan,
glänzende Augen
Ich würde meinen Leuten das sogar erlauben, aber nur unter einer Voraussetzung.
Denn in einem Projekt kann man eigentlich nur eine Unbekannte gebrauchen.
Wenn mein Team also in dem Anwendungsbereich schon mal ein System
gebaut hat, wenn also die Fachlichkeit keine Unbekannte ist,
dann würde ich eine Unbekannte erlauben.
Ich würde aber nicht erlauben, neue Datenbankmapping, neue Oberfläche,
neue Entwicklungsumgebung und noch neu, also wir, neue Source-Code-Verwaltung oder irgendwas.
Ja, das muss man sich als Daumenregel so merken.
Eine coole Sache, mehr nicht,
tut mir leid
Die anderen coolen Sachen müsst ihr alle im Studium ausprobieren, okay?
Coolheit ist nämlich ein potenzielles Risiko. Das ist mal so eine
, mal so aufgetragen. Hier geringes Risiko, ja,
hohes Risiko. Obercool, ne? Sieht ungefähr so aus
. Also wenn ihr in meinen Projekten arbeitet, Ja.
Sorry. Sonst geht es zu Flicker, okay?
Nein, natürlich versuchen wir, obercoole Sachen zu machen.
Wir haben bei uns im Moment ein Forschungsprojekt,
das von der Stadt Hamburg gefördert wird, wo wir uns mit generischen Leitständen beschäftigen.
Also ich weiß gar nicht, habe ich von den Leitständen
schon was erzählt? Also wenn ihr durch den Elbtunnel fahrt,
dann wisst ihr das wahrscheinlich gar nicht, aber da oben sitzen Leute,
die gucken dauernd auf irgendwelche Bildschirme und gucken,
wie der Autozufluss ist, in welchem Zustand ihre Tunnel sind,
wo sie jetzt was sperren und all so ein Kram.
Oder wenn ihr bei der Hochbahn, also guckt euch sowas mal an,
versucht mal eine Führung zu bekommen,
dass hier so ein Leitstand zum Beispiel beim HVV sehen könnt.
Das sind nämlich richtig tolle Geschichten heutzutage. Es geht ja jetzt
nicht mehr so sehr darum, irgendwelche Daten in Systeme reinzukriegen.
Das ist nämlich gar nicht mehr cool. Sondern was cool ist,
ist Systeme zu beobachten. Ich war bei der DHL,
also bei der DHL hat 33 Verteilerzentren in Deutschland, wo Pakete verteilt werden.
Also da kommen dann irgendwelche Laster an und bringen,
was alles eingesammelt worden ist an Paketen. Zum Beispiel,
wenn ihr bei Amazon was bestellt,
dann kommt so ein großer Laster dahin gefahren und hat natürlich
ganz viele Pakete da drin und die müssen jetzt verteilt werden
wieder an die Zusteller
Und dann werden also diese ganzen Pakete
da auf eine Bandstraße getan und auf dieser Bandstraße kreisen,
also diese Pakete und werden immer an verschiedenen Stellen so runtergekippt.
Und das ist erst mal hardwaretechnisch total interessant,
weil das Ding ist bestimmt inzwischen schon zehn Jahre alt und das funktioniert immer noch.
Das ist also Holz und Metall und das ist natürlich pflegenswert.
Aber sie haben einen Leitstand, in dem sie das ganze
System angucken können und immer sehen können, wo irgendwas schief geht.
Dann wird es rot, dann muss irgendjemand,
da ist ein Stau an irgendeiner Stelle, ein Paket hat sich verhakt,
dann muss schnell da einer hin und muss das da rausholen,
reparieren, umbauen.
Ganz spannender Leitstand,
sowas mal anzugucken
Und das ist natürlich toll. Also das ist sozusagen hier
, glaube ich, irgendwo. Ja, sag ich jetzt
mal. Also wir bei uns haben ein Leitstandsprojekt,
wo wir mit verschiedenen Projektpartnern zusammenarbeiten, also mit der Hala,
mit der Hamburg Port Authority der HPA, die dafür sorgt,
wie die Schiffe durch die L bekommen und dass sie nicht gegeneinander fahren.
Also diese riesen Pötte, die passen nämlich nicht mehr aneinander vorbei.
Wir waren heute Morgen bei der Hala und da sagte die eine Kollegin lapidar,
naja, da müssen sie die Elbe halt mal wieder ausbaggern.
Dann passt es wieder. Also das ist sozusagen deren Interesse.
Und wir gucken auch beim Desi, also bei diesem unter Hamburg verlaufenden Elektro-Synchro-Tonnen.
Auch die haben natürlich einen Leitstand. Und da setzt man schon relativ coole Technologien an,
vor allen Dingen, weil man eben oberhalb von irgendwelchen Systemen sitzen muss,
die da schon sind und sich da andocken muss und gucken muss,
wie das alles funktioniert.
Aber das sind Forschungsprojekte, ja? Also wenn ihr forscht,
wenn ihr zum Beispiel eine Doktorarbeit schreibt oder in irgendein Forschungsprojekt kommt,
ja, dann könnt ihr die obercoolen Sachen machen,
aber ihr werdet es leider nie erleben,
dass das Ding auch jemand mal richtig benutzt.
Denn dafür muss es hier runterwandern
So ist das leider. Lässt sich nicht ändern. Also das Ziel von so einem Forschungsprojekt,
also bei uns zum Beispiel,
ist natürlich auch irgendwann an den Punkt zu kommen,
dass die Firmen sich so sehr,
so sehr für dieses tolle neue Teil da interessieren,
dass sie es dann auch gerne haben wollen.
Und dann wird man daraus genauso ein Gähn-Projekt machen und das umsetzen.
Es gibt manchmal tolle Firmen,
also zum Beispiel bei Xing ist das so, ich vermute,
also bei Google ist das natürlich auch so,
die haben sozusagen eingeplant, dass ihre Leute auch forschen.
Ja, also dass die etwas machen,
wo sie mal was Obercooles tun dürfen.
Das machen wir bei uns auch
Dass die Vater einkaufen. Genau. Mhm. Ja.
Ja. Das ist einfach der Siniko-Potenzial, der Großbrüder,
der, der, der. Genau. Also das ist,
genau auf den Punkt wollte ich nämlich jetzt auch hinaus,
dass man auch als Architekt in diese Richtung gucken muss,
dass man seinen Leuten vielleicht nicht in dem Projekt,
aber am Rande oder zu bestimmten Zeiten erlaubt,
super coole Sachen auszuprobieren.
Denn genau darüber kriegt man neue Ideen und auch Verbesserungen.
Aber wir haben zum, ich weiß nicht,
ob ihr Maven kennt, das ist so ein Tool,
mit dem man das Building von Softwaresystemen
leicht machen kann
Es hat eine ganze Weile, fanden das alle super spannend,
aber es war noch nicht wirklich reif,
dass man das wirklich in einer großen Firma einsetzen konnte.
Dann haben das mehrere Leute von uns immer mal wieder ausprobiert.
Hier, Erfahrung, da, Erfahrung. Und jetzt ist es total cool,
dass wir Leute haben, die Maven können,
weil Maven ist jetzt an dem Punkt,
wo man es auf dem Markt gut verwenden kann.
Und wir haben Leute, die sich damit auskennen.
Aber die haben das nicht in bezahlter Arbeit gelernt, leider Gottes.
Also jedenfalls nicht in von Kunden bezahlter Arbeit. Ja,
das ist immer so ein Wabons-Spiel. Wir haben bei uns
in der Firma sowas, das nennt sich Slack.
Ja, die Leute dürfen also slacken,
die dürfen also eine bestimmte Zeit mal etwas tun,
was kein Geld bringt,
wo sie
was Neues lernen
Ich weiß zum Beispiel, dass das Eclipse-Entwicklungsteam,
das hat immer einmal im Jahr ein Release oder alle halbe Jahr,
was weiß ich, weiß es nicht,
auf jeden Fall zu einem festen Zeitpunkt ein Release.
Und davor wird gebaut, gebaut, gebaut, gebaut.
Und danach gibt es eine Zeit,
wo die Leute aufräumen dürfen und neue Technologien sich angucken können,
wo sie einfach ihre Ruhe haben.
Das muss man aber natürlich bei einem Management auch durchsetzen.
Genauso schwierig wie Refactoring ist das durchsetzbar. Gut. Also,
wenn ihr bei einer Firma seid, die nur sowas tut hier,
dann solltet ihr alle Anzeichen erkennen,
wann ihr abspringen müsst
Weil sich das nicht mehr finanzieren lässt. Also so werdet ihr dann schon merken.
Das ist auch noch so ein bisschen was in die Richtung.
Nützlichkeit. Ja, was bedeutet Nützlichkeit? Fragt man sich
hier, jetzt malt er nicht mehr, wie schade.
Ist nicht mehr nützlich. So, ja. Die Nützlichkeit
ist hoch, wenn ich langweilige Sachen mache. Ja,
also wenn ich immer wieder eine Software schreibe,
also am besten ist ja,
also im Grunde geht das in die Richtung,
ich entwickle ein Produkt.
Ja, ich habe ein Produkt und das kann ich
ganz oft verkaufen. Das ist ja überhaupt nicht mehr cool,
das immer wieder zu installieren und zu warten und so
wie langweilig.
Aber das bringt viel Geld
Also ihr müsst irgendjemanden finden, der euch für diese,
hier für diese interessanten und nutzlosen Sachen Geld gibt.
Ja, das werdet ihr als Architekt der Projektverantwortlichung,
hat wahrscheinlich nur in abgespecktem Rahmen machen können.
Tja, das müsst ihr als Architekt auch wissen.
Ich habe ja gesagt, ihr sollt Technologie lernen,
ihr müsst aber auch Architektur, Muster und Stile kennen und können.
Da gibt es auch ganz viele schöne Bücher.
Was kann ich euch denn empfehlen?
Oh,
dieses hier total
Wenn ihr mal mit Verteilten an, also natürlich kann ich
euch alle empfehlen, das ist überhaupt keine Frage.
Aber wenn ihr mit Nachrichten basierten Systemen zu tun habt.
Oder hier, das ist auch,
das ist von Martin Fauler, das ist auch wirklich klasse.
Grundmuster von Architekturen. Also das ist auch so
ein allgemeineres Buch. So. Ja, das ist auch
gut hier
Der Lahmen ist auch sehr spannend. Und außerdem muss man
alles gelesen haben, was Frank Buschmann geschrieben hat.
Das muss man alles gelesen haben,
weil Frank Buschmann ist Architekt bei Siemens und auf jeder Konferenz.
Und wenn man seine Bücher nicht kennt, dann wird er sauer.
So. Und hier zum Beispiel, wenn ihr sicherheitsrelevante Systeme schreibt,
dann guckt doch in, was ist denn das jetzt hier,
malt nicht mehr.
Dann guckt da in dieses Buch. Und die beiden muss ich zugeben,
habe ich nicht gelesen, muss ich mal tun jetzt,
glaube ich,
die da den und den.
Ich kann euch nur empfehlen,
lest die nächsten Jahre so viel ihr könnt, weil irgendwann,
wenn man sozusagen in diese Kunden- und Management-Geschichte rüber wechselt,
dann hat man keine Zeit mehr zu lesen.
Das ist total frustrierend. Dann muss man immer zu seinen Mitarbeitern sagen,
lies mal, mach mir ein paar Folien,
die die Zusammenfassung von dem da sind.
Also, oder macht mal einen Vortrag in einem Seminar über das
da und dann. Gut. Aber sowas müsst ihr können,
um mit denen umkonstruieren zu können und mit euren Leuten
nachher auf Software-Systeme gucken zu können.
Ihr müsst aber aufpassen, dass ihr nicht den Hammer-Effekt,
den Hammer-Effekt erliest,
liegt,
kennt ihr
den Hammer-Effekt
Einige kennen ihn. Wenn man gelernt hat,
wann mit einem Hammer ein Nagel in die Wand haut,
dann sieht nachher die ganze Welt aus wie ein Nagel.
Und man haut überall mit dem Hammer drauf. Also man hat
sozusagen einen Lösungsweg. Also wenn mich jemand was fragt,
wo ist denn das und das, wie ist die Telefonnummer,
wie wird das Wetter morgen, was mache ich dann?
Ihr ahnt es wahrscheinlich, ich greife zu meinem iPhone.
Also sozusagen mein Hammer ist mein iPhone,
da ist alles drin, was da nicht drin ist,
das gibt es eigentlich
gar nicht
Okay, moderne Zeiten. Aber es ist wirklich wichtig,
ich bin von einer, einem eher dokumentengetriebene Softwareentwicklung,
also so Banken und sowas,
wo man Konten hat und die Daten alle im System sind,
bin ich ja in diesen Hafenkontext gewechselt.
Und das ist fachlich, das ist einfach eine ganz andere Welt.
Die Architekturen müssen dort ganz anders sein, weil es
sehr viel wichtiger ist, dass alles sehr zeitnah passiert.
Ich weiß nicht, ob euch das auch immer noch so geht.
Ich gebe mir Überweisung ein in meine Online-Banking von einem Konto auf
ein Unterkonto und das wird dann erst am nächsten Tag ausgeführt.
Da denke ich immer, Wow. Ja,
mit einem Container könnte man sowas nicht machen.
Der muss taggleich verarbeitet werden, ja. Also da sind
ganz andere Restriktionen und deswegen muss man sehr gut aufpassen,
wo man da hingelangt, ob man nicht mit seinem Hammer
aus dem letzten Projekt auf das nächste draufhaut.
Das bringt nicht so wirklich viel. Tja, und
jetzt kommen wir zu dem Punkt bewerten. Ihr müsst,
das hat viel mit Kommunizieren zu tun, ja?
Weil das Bild, da sieht ja nicht so wirklich so aus,
als würde sich die Frau auf konstruktive Kritik freuen,
sagen wir mal so
Auch so ein Schlagwort konstruktive Kritik ist was ganz Schweres.
Also jemandem, das muss man sich, muss man gut vorher planen.
Wenn man jemanden kritisieren will, dann muss man damit anfangen,
dass man ihm ersten Mal was Positives sagt über seine Leistung,
sagt, was alles gut ist an dem,
was er gemacht hat und dann ganz vorsichtig sagen,
was vielleicht nicht so ganz gelungen ist und am besten noch eine Lösungsidee haben,
dann kommt das an.
Sonst wird es schwierig mit der konstruktiven Kritik.
Ich weiß nicht, ob der das hinkriegt,
aber könnte sein
Also um Software bewerten zu können, müsst ihr die Struktur von den Systemen
erkennen können und dann Möglichkeiten haben, das zu bewerten.
Ich habe euch schon so ein paar Sachen ja beigebracht,
wie man Softwaresysteme bewerten kann.
Letzte Woche haben wir was gemessen. Was haben wir
denn gemessen?
Mhm. Genau. Wir hatten so Auswertungen über die Größe
und wie die miteinander verknüpft waren.
Genau, sehr schön. Oder wie die Kopplung war.
Oh ja, genau. Das habe ich letzte Woche erzählt
. Dass man, wie hieß denn dieses Prinzip?
Das Lizkov Substitution Principle war das. Dass die Subklasse,
die Verträge der Superklasse erfüllen muss und wenn in einem System
ganz viel Instance Off ist,
dann ist das gar nicht schön
Ich gucke auch immer in den Systemen,
wie oft da das Wort To-Do drin vorkommt.
Was glaubt ihr denn? Finde ich das gut oder schlecht?
Ihr könnt ja mal oder machen. Schlecht. Viele finden
das schlecht. Okay, tja, tut mir leid.
Ich finde das natürlich gut, wenn da To-Do drinsteht,
weil Systeme, wo Leute daran entwickeln,
unter To-Dos reinschreiben, sind Systeme, die noch leben.
Da hat noch jemand Ideen,
wie man das besser machen kann
Also ich meine, wenn die Datümer natürlich alle aus 2005 stammen,
die dahinter stehen, hoffentlich, hinter dem To-do,
dann ist das natürlich nicht so schön.
Aber grundsätzlich ist es schön, wenn in Systemen To-dos drin stehen.
Es gibt in Eclips die Möglichkeit, sich die To-dos anzeigen zu lassen.
Wisst ihr das schon? So eine Liste. Schreibt mal irgendwann ein To-do rein,
ja, irgendwo so, in euer System und dann guckt,
ob ihr diese Perspektive da findet,
die gehört in den unteren Bereich, wo man die To-dos sieht.
Was ich auch nicht so gerne finde, ist Hack zum Beispiel.
Hack finde ich nicht so gerne. Kommt aber auch immer mal
wieder vor. Dann weiß man wenigstens, dass jemand wusste,
was er da tut und er es hingeschrieben hat.
Ein Hack, ihr wisst, was ein Hack ist,
oder? Irgendwo, wo jemand eine Abkürzung gegangen ist,
obwohl er wusste, dass das eigentlich nicht richtig ist.
H-A-C-K, ein Hack. Spreche ich so amerikanisch, ne
? Ja. Hack. Warte bitte. Ich habe es
immer noch nicht verstanden. Oh. Ich war mal,
ich hatte mal eine ganze Weile einen australischen Freund und das ist lustig,
weil man dann lernt man so australische Wörter,
die es im Amerikanischen gar nicht gibt
Also auf Australisch heißt eine Bettdecke zum Beispiel Dyna.
Wenn man das zu einem Amerikaner sagt,
dann sagt er, was, wovon redest du?
Ja. Also insofern daher kommt vielleicht das Hack.
Die reden so ganz rob da in Australien. Gut,
also wenn irgendwo in einem Softwaresystem das Wort Hack zu finden ist,
ist das einerseits gut, weil der Mensch wusste,
was er tut und das dahin geschrieben hat.
Andererseits ist es natürlich auch frustrierend,
weil der Hack dann nicht gelöst worden ist.
Aber das kann ich euch trotzdem empfehlen. Also wenn ihr
in einer Software etwas baut und das Gefühl habt,
das ist nicht fein,
was ihr da tut,
dann schreibt es wenigstens hin
Damit ihr es später noch wisst. Ich weiß nicht,
ob ihr die Erfahrung schon gemacht habt, aber ich habe das,
glaube ich, auch schon mal erzählt.
Mir ist das ganz, ganz oft passiert,
dass ich irgendwas programmiere, sei es schön oder schlecht,
ja, und denke, das werde ich nie vergessen,
was ich da jetzt gemacht habe.
Ja, und dann gucke ich da nach zwei Monaten wieder rein und ich weiß noch,
dass ich gedacht habe, dass ich nie vergessen werde,
was ich da gemacht habe, aber ich weiß nicht mehr was.
Es ist einfach weg, ja,
schreibt es euch auf, es hilft nichts, ja,
das geht auch in diese Richtung Notation und irgendwie dokumentieren
Gut. Wenn man Systeme bewerten will und entscheiden will,
wie die sind, dann muss man nach Strukturen in diesen Systemen suchen.
Und wenn es geht, auch nach den Entscheidungen.
Und diese Entscheidungen sind auch so ein Punkt.
Strukturen kann ich finden. Ich habe euch ja so Bilder
gezeigt von Systemen, wie die miteinander verknüpft sind.
Wir können das in OML aufmalen. Aber was ist mit den Entscheidungen
? Die sind ganz schwer natürlich im Source-Code zu finden,
warum die Leute irgendwas irgendwie gemacht haben. Ja,
das ist irgendein Bild von einem Software-System von einem Tool, was source-forge-matrix heißt.
Und da sieht man irgendwelche Klassen oder es sind vielleicht auch,
nee, das sind die Klassen hier,
das sind die Klassen
Das sind auch Klassen. Das ist, glaube ich,
ein Package, was auch immer. Ich kenne das Tool nicht,
mit dem das gemacht worden ist,
aber auf jeden Fall sieht man irgendwelche Beziehungen zwischen den Dingern.
Es sieht ja alles ganz spannend aus, ne?
Die haben aber alle keine Pfeile. Also man weiß,
ach doch, ich vermute, das ist so.
Das ist ein Paket hier und das sind alle Klassen,
die dazugehören. Und die sind so angeordnet,
dass was zusammengehört, auch nah beieinander ist.
Also was sich viel benutzt, ist nah beieinander.
Und dann kann man sehen, wie die Beziehungen zwischen den
einzelnen Teilen sind. Also die Roten sind hier zum Beispiel
sehr verteilt irgendwie,
Huch, nee, da. Na gut,
also man kann so visuell deutlich machen, wie das System
zusammengesetzt ist und kann zum Teil bewerten, was das für eins ist.
Das ist das JDK, betrachtet mit dem Tool Code, Code City. Also sozusagen Java,
ja, wenn ihr auf eurem Rechner Eclipse installiert,
dann braucht ihr ja auch immer eine Virtual Machine und die Programmiersprache,
denn ihr benutzt ja sowas wie String, ja,
aus Java lang oder was ihr alles so sonst noch benutzt,
ja.
Demnächst benutzt ihr irgendwelche Oberflächen, also Swing oder sowas,
das ist alles im JDK drin und was man hier sieht,
sind die Pakete,
also ein Paket,
ein Paket
Ja, die Anzahl der Zeilen Code ist,
glaube ich, die Höhe, so die Höhe.
Aber vielleicht ist es auch genau andersrum. Ich weiß es nicht.
Und die Anzahl der Klassen ist wahrscheinlich irgendwie die Breite und der Methoden.
Also man kann so visuell so Sachen darstellen, ja,
die einem, wenn man darin geübt ist,
unheimlich viel helfen, so ein System auch zu bewerten.
Denn besonders ausgeglichen sieht das jetzt nicht aus.
Du hast ja vorhin gesagt, wir haben auch darüber geredet,
wie viel ist in den einzelnen Klassen drin.
Ich hoffe, ihr erinnert euch. Ich habe gesagt,
baut ausgeglichene Systeme. Das sieht nicht besonders ausgeglichen aus.
Manches ist ganz klein und strubbelig hier und anderes ist groß
und dick
Gut, aber wir benutzen es alle. Scheint ja zu funktionieren.
Andere Bilder von Systemen, das ist zum Beispiel eine Architektur,
die mit dem Tool Coverty aufgemalt worden ist.
Also da kann man dann so Schichten. Ihr erinnert euch
ja, ich habe euch letzte Woche von Schichten erzählt.
Also hier gibt es zum Beispiel unten eine Schicht aus diesen zweien hier.
Und dann gibt es da drüber eine Schicht, die.
Und dann hier einen großen Haufen, das gehört alles zusammen,
weil das ist in einem oder drin sind Widerschichten und Teile und Teile von Schichten.
Also dass man sich das sozusagen aufmalen kann und sowas ähnliches ist hier
auch auf der rechten Seite passiert mit einem meiner Lieblingstools,
mit dem Software-Tomograf.
Wisst ihr, was
ein Tomograf ist
Ihr wart noch nie, ihr hattet noch keinen Bandscheibenvorfall.
Ihr seid noch zu jung. Doch,
ein Tomograf ist so eine Röhre,
wo man reingeschoben wird und das schneidet einen in Scheiben,
also natürlich nicht in echt.
Also das macht Bilder so von Scheiben von einem.
Und dann kann man sehen, wo ist die Bandscheibe vorgefallen?
Sondern weiß man wenigstens, wo es ist und warum es weh tut.
Es hilft nichts. Also weil das nur guckt,
ja, aber immerhin guckt es.
Und das macht dieses Tool auch bei Software. Das schneidet
das System in Teile. Also hier sind sozusagen eine Schicht,
die sind hier quer, noch eine Schicht,
noch eine Schicht
Noch eine Schicht. Und noch eine Schicht.
Und was man hier sieht, sind die wirklichen Beziehungen.
Also das sind so und so viele Beziehungen von hier
nach da. Und hier zum Beispiel ist ein Zyklus,
die benutzen sich gegenseitig. Und was ihr da seht,
ist, dass Spring Framework, das ist ein sehr,
sehr viel in Java verwendetes Framework Spring, heißt das,
wie der Frühling.
Ja, mit dem kann man gut Datenbank-Mapping machen.
Man kann aspektorientierte Programmierung machen.
Aspektorientierte Aspekt
Das ist eine Idee, aspektorientierte Programmierung ist die Idee,
dass man, ihr kennt ja schon Interfaces, Interfaces kennt ihr schon lange.
Und wenn ihr so ein Interface baut, dann stellt ihr
ja irgendjemand eine Schnittstelle zur Verfügung. Und ja,
ich habe euch beigebracht und ich habe euch versucht zu erklären,
dass es sinnvoll ist, für jeden Client ein eigenes Interface zu haben.
Ja, das war ja auch so ein bisschen die Argumentation gegen
das Fassadepattern, die wir eine Zeit lang geführt haben.
Ja, und die aspektorientierte Programmierung sagt,
oh, es gibt so Sachen, zum Beispiel Logging.
Ja, ich will also immer, dass irgendwelche Daten rausgeschrieben
werden oder ich will die Performance von irgendwas beobachten.
Es gibt also so Eigenschaften, die ich ins Systeme reintun will oder zum Beispiel auch,
dass etwas druckbar ist, ja, da will ich nicht,
dass jeder von diesen ganzen Interfacen erben muss. Ja,
weil wenn ich sozusagen will, dass mein ganzes System,
immer wenn jemand, wenn eine Klasse gerufen wird,
dass die dann immer sagt, jetzt bin ich dran und die nächste sagt,
jetzt bin ich dran, wenn die gerufen wird, ja,
dann müssen die ja alle immer von so einem Interface erben,
über das nachher dieses Tool, was das Logging macht,
auf all diese Klassen drauf gucken kann.
Und dann würde ich mir mein System mit unheimlich vielen Sachen verschmutzen,
ja, dass ich alles Mögliche da reinerben muss und die aspektorientierte Programmierung versucht,
das anders zu lösen,
die gibt also auf andere Art und Weise für Klassen an,
dass sie eine bestimmte Schnittstelle erfüllen
Also nur so ein bisschen, damit ihr,
wenn mal jemand, was machen wir mit aspektorientierter Programmierung,
schreit, weil das gerade das neue Schlagwort ist,
dass ihr zumindest wisst, dass es sowas gibt.
Das finde ich immer ganz praktisch, wenn man da was
schon mal gehört hat und nicht heimlich in seinem iPhone auf Wikipedia gehen muss,
um rauszukriegen, was der andere dann nun gerade meint.
Also Spring wird euch bestimmt begegnen in eurem Leben,
hat auch ganz toll, er hat auch wirklich tolle Sachen,
die man unbedingt verwenden muss,
wenn man zum Beispiel sein System nicht komplett verdrahten will,
sondern das Hochfahren der Systemteile entkoppeln will.
Also Spring wird euch begegnen und ich kann euch sagen,
die Architektur sieht ja auch ganz gut aus.
Das meiste, hier gibt es mal so einen,
der gegen die Schichtung geht und hier gibt es auch
noch so ein paar,
aber eigentlich haben die das
gut hingekriegt
Sagen wir mal. So. Ist aber auch testgetrieben entwickelt.
Kann gar nicht so viele Zyklen haben, das Teil.
Auch noch so ein schönes Tool. Sona Jay heißt das.
Auch eins meiner Lieblingstools kann man so hübsche Bilder mitmachen.
Habe ich euch schon mal solche Bilder gezeigt? Hier ist oben,
also das ist die oberste Schicht und hier ist unten.
Da ist nämlich auch Java und sowas. Java sollte
immer unten sein, ist ja logisch irgendwie. So,
und die Bögen auf dieser Seite hier, die gehen von oben
nach unten und die auf der anderen Seite gehen von unten nach oben.
Also welche sind schlecht
Hm? Alle? Oh Gott. Nein. Welche Bögen
sind schlecht? Sebastian? Die von unten nach oben,
genau. Warum sind die von unten nach oben schlecht?
Weil was will man? Man will schichten. Die letzte Generation von Studenten
ist hier weggegangen und hat gelernt, dass man Schichten machen muss.
Das findet man auch überall. Also wenn man in Firmen kommt,
wo so die Generation ab 95 irgendwie entwickelt, ja,
dann findet man Geschichte, Systeme. Die Leute davor,
die so eher aus der Kobol-Zeit kamen und dann Objekt notiert
entwickelt gelernt haben, die haben von Schichten nichts gelernt.
Die machen eher so schnittstellenorientierte Systeme
Seid die nächste Generation, ihr geht weg und lernt,
dass es Schichten gibt und Schnitte. Könnt ihr euch erinnern,
dass ich euch das letzte Mal beigebracht habe, ja?
Jetzt habe ich hier keinen Platz. Habe ich hier irgendwo Platz?
Ja. Schichten, ja? Benutzen von oben nach unten,
klar, und Schnitte oder wie auch immer man das nennt,
und benutzen auch nur in einer Richtung. Ich weiß nicht,
ob ihr euch an die wirren Bilder erinnert,
die wir letzte Woche hatten, mit den Zahlen drauf,
wo man ausrechnen konnte, wie die, das war das,
was ich nämlich vorhin von euch wissen wollte,
Average Component,
Dependency ausrechnen konnte
Average, Component, Dependency. Ja? Also,
wenn euch jemand fragt, vertikale und horizontale Schichten.
Das ist heutzutage das Richtige. Ja? So, zurück.
Guck mal, ist sogar noch da, was ich gemalt habe.
Ist das nicht cool? Ja. Jedenfalls,
das hier ist nicht gut. Es muss alles von oben
nach unten gehen, damit man eine richtige Schichtung habt.
Aber wenn das schon so wäre, hätte man ja
nichts mehr zu tun. Also, hier kann man noch
ein bisschen aufräumen und noch ein bisschen Geld damit verdienen.
Das ist auch sehr schön. Gut, also,
es gibt eine Reihe von Tools, um sowas zu tun.
Das kenne ich gut, das kenne ich gut,
das kenne ich gut
Das kenne ich auch. Oh,
das habe ich auch schon mal gehabt in der Hand.
Wie heißt denn das noch? Das habe ich vergessen.
Haben Sie mich letztens nachgebracht? Friedkmann finden. Die anderen kenne ich
alle nicht, aber sind auch nicht weniger gut deswegen.
Das ist auch so was, woran man sich einfach gewöhnen muss.
Ihr könnt nicht alle Tools für alle Zwecke kennen.
Das geht einfach nicht. Ihr müsst euch gerade, was sowas angeht,
mit einem Tool richtig anfreunden. Also ich kenne Leute,
die jetzt seit zehn Jahren mit Eclipse arbeiten und die
immer noch so einmal im Jahr kommen und sagen,
wow, jetzt habe ich noch einen neuen Shortcut gelernt,
den ich vorher nicht kannte.
Also irgendwas gibt es immer noch zu lernen.
Die Tools sind heute unglaublich komplex Tools, um Software herzustellen,
Tools, um Software zu bewerten.
Ihr werdet damit leben müssen, dass ihr nicht alle kennen
könnt.
So ist das einfach
Also, lernt irgendwelche Systeme zu verstehen, das Dumme ist,
die Tools helfen euch Strukturen zu finden und zu verstehen und so weiter.
Aber die helfen euch nicht, zu wissen,
warum die Leute sich irgendwie entschieden haben. Ja,
also ihr seht sozusagen die Struktur, die hier ist im Quellcode,
aber ihr wisst nicht, warum die das so gemacht haben.
Und das ist das Traurige. Also Ziele und Entscheidungen sind schlecht.
Deswegen ist es auch ganz, ganz, ganz schrecklich,
wenn man niemanden mehr hat, der das System kennt.
Also wenn man irgendwo hingerufen wird,
wir haben hier ein System und wissen nicht mehr,
Ich kenne eine Firma, die ein Software-System hat,
wo sie den Source-Code inzwischen verloren haben.
Also sie haben nur noch das übersetzte System am Laufen.
Das ist aber eins ihrer Kernsysteme. Und die patchen immer
den Bite-Code, um das System zu erweitern oder zu verändern.
Frustrierende Zustände. Yes. Also es ist gut
, so was rechtzeitig zu tun. Bei einem Kunden,
wo ich jetzt gerade bin, da ist ein relativ stabiles,
aber altes System im Einsatz,
was so im Zentrum von allen steht,
wo die ganzen Kundendaten drin verarbeitet werden und die ganzen Abrechnungen
mitgemacht werden
Und die haben einen Mitarbeiter noch,
der sich mit dem System auskennt oder mehr oder weniger.
Es gibt auch Ecken, die er nicht kennt,
der ist 61. Habe ich euch schon mal von dem Truck-Factor erzählt?
Ja. Wie hoch ist der denn in dem Fall?
Der ist eins. Wenn der Mann überfahren wird von einem Truck
, dann ist niemand mehr da, der sich auskennt.
Also, wenn ihr Architekt seid irgendwo, dann sorgt dafür,
dass ihr einen Truck-Factor habt, unter 0,5, wenn es geht.
Weil auch zwei Leute, wenn die Kinder bekommen wollen,
auch in den Sommerferien beide in den Urlaub gehen.
Und dann ist wieder keiner da,
so ein Mist
Naja, also, ihr müsst noch Leute kennen, die sich da auskennen.
Was noch hilft, um der Problematik Herr zu werden,
und das machen wir bei uns viel, ist ein Architekturstil zu haben.
Ja, wenn ihr ein, wenn ihr in eine Firma kommt,
die einen einheitlichen Architekturstil hat,
dann ist das Problem ein bisschen kleiner, ja,
weil in dem Architekturstil sind ganz viele Entscheidungen drin,
wow,
geh weg
Ja, ganz viele Entscheidungen und Stile basieren auf diesem Architekturstil. Das,
was ich euch heute noch mal in Erinnerung gerufen habe mit
den Schichten und den Schnitten, ist auch ein Architekturstil,
aber der ist sehr, sehr schwach.
Ja, der sagt ja nur, was über die Grobstruktur aus.
Der sagt nichts über die Details aus. Also wenn ihr diese ganzen Bücher lest,
die wir da vorhin hatten, mit Architekturmustern und sowas und Entwurfsmustern,
dass die haben eine viel feingranulare Beschreibung als so eine olle Schichtenarchitektur.
Da sind natürlich auch ganz viele Entscheidungen mit dokumentiert.
Also sowas ist immer gut. So. Also die Message ist,
Ihr müsst ganz viel auf verschiedensten Ebenen lernen.
Also ihr müsst lernen zu kommunizieren, zu konstruieren,
Anforderungen zu verstehen und zu bewerten, damit ihr gute Architekten sein werdet.
Und das braucht Zeit. Ja, also ich kann euch nicht versprechen,
dass ihr das nach dem Bachelor sowieso nicht seid,
aber nach dem Master, ja vielleicht,
wenn ihr zwischendurch ein bisschen gearbeitet habt und so,
dann kann das kommen.
Aber man muss ja auch noch Ziele und Träume haben,
ne, muss man ja noch haben dürfen.
Tja, und das Allerwichtigste von all dem,
es kommunizieren können
Ihr müsst mit Leuten reden können. Ihr müsst kommunizieren lernen,
das, und das ist natürlich in so einem Studium,
was eher so technisch ist, ganz schwer.
Also macht euch auf den Weg, dass ihr diese Dinge lernt.
So, jetzt erzähle ich euch noch was.
Was auch Aufgabe von Architekten ist. Wir haben ja eben
gesprochen über konstruieren, bewährten, kommunizieren und die Anwendung kennenlernen.
Eine Sache ist mir noch ganz unglaublich wichtig,
schreien, bestimmt ein paar Leute testen ja das auch.
Aber das geht noch ein bisschen in eine andere Richtung.
Es gibt in den USA eine sogenannte Broken-Window-Theory.
Die wird in Deutschland auch verwendet. Deswegen ist da
ein kaputtes Glas zu sehen. Dabei geht es darum,
ein paar Psychologen haben, sieht man nicht, dass das Glas ist?
Doch. Ein Fahrpsychologen haben einen Jaguar in New York in einen armen Viertel gestellt,
hingestellt und haben gedacht, okay,
der steht jetzt da und wir kommen morgen wieder und dann
sind die Spiegel abgebaut und die Räder und so weiter und so fort
Nichts da. Die kamen also am nächsten Tag wieder,
das Auto war noch heil. Und das ging eine ganze
Woche so. Dann haben die gedacht, das ist ja
komisch. Und haben ein Fenster eingeschlagen von dem Auto.
Und am nächsten Tag war nur noch ein Grippe übrig.
Ja, und was dieses Beispiel sagen will ist,
wenn man auf etwas trifft, was schon kaputt ist,
dann macht man es leichter noch weiter kaputt.
Wenn man aber auf etwas trifft, was gut aussieht,
wo sich jemand Mühe gegeben hat,
was schön ist,
macht man es nicht kaputt
Ich möchte also, dass ihr qualitätsbewusst seid,
dass ihr schöne Systeme baut, wo der Nächste drauf guckt und denkt,
wow, das hat er aber toll gemacht.
Das mache ich jetzt noch hübscher. Das heißt,
ihr schreibt Tests, das heißt, ihr dokumentiert,
das heißt, ihr überlegt euch gute Namen für die Klassen.
Ihr macht Schichten, all diese vielen schönen Dinge.
Die Mühe lohnt sich. Es bleibt wenigstens heil. Okay
. So, das mache ich jetzt mal alles nicht.
Ich gehe mal zur Zusammenfassung
Oh. Das erzähle ich euch auch alles nicht.
Nö. Ich gehe mal zurück. Das ist doof.
Ich wollte was anderes. Qualität, genau, das.
Also, das nehmt ihr von heute mit. Ihr lernt
Technologie, aber ihr müsst auch noch vieles andere lernen.
So, und bevor ihr jetzt einpackt,
ich habe keine Pause gemacht und ich gehe auch früher weg.
Das wisst ihr ja, wir haben um zwei angefangen,
weil ich gleich noch woanders hin muss.
Möchte ich euch sagen, ja, dann gehen wir wieder
nach hinten. Wir sind jetzt, wir sind jetzt hier
Das heißt, wir haben jetzt einen Block hinter uns,
wo es um Softwarearchitektur und statische Systeme,
also die statische Struktur von Systemen und sowas geht.
Und ich will euch noch zwei oder drei Sachen dazu sagen,
was aus diesem Bereich denkbar wäre in einer Klausur abgefragt zu werden.
Nächste Woche kommt Guido. Guido macht auch ganz viele lustige
Sachen. Und was Guido erzählt, ist auch klausurrelevant.
Also es lohnt sich auch nächste Woche zu kommen,
aber dies ist ein anderer Block
sozusagen thematisch
Vorgehen, wie macht man Projekte, wie ermittelt man Anforderungen.
Und hier hinten kommt dann noch so ein Teil Gemischtes.
Was mich sonst noch so alles wichtig finde. Aber das ist
der Teil Architektur hier. Ich kann nicht mehr schreiben.
Und darüber wollen wir jetzt noch ein paar Worte zusammen uns angucken.
Habe ich die Spannung doch noch gehalten, ne? So,
dazu drehe ich jetzt mal meinen Rechner wieder um,
weil ich euch aus den anderen Vorträgen Dinge zeigen will,
die ihr euch nochmal zu Gemüte führen solltet
Zack. Ende. Hallo. So. Also, nö,
nö, nö.
So, jetzt
Das ist der Teil über Softwarearchitektur, den ich vor
zwei Wochen gehalten habe. So, mir wäre wichtig,
dass ihr einen Zusammenhang zwischen dieser Folie hier,
die sagt, was Architektur ist, also eine Struktur.
Nee, okay, dann nicht.
Man muss nicht wieder umschalten, ne?
Ach. Nee
So, zack. Eine Struktur aus Elementen mit externen Wahrnehmungen,
Eigenschaften und Beziehungen. Ja, dass ihr das wisst,
wisst, dass es Sichten gibt,
wir haben jetzt ganz viel über die statische Sicht gesprochen und euch darüber äußern könnt,
was sind also die Elemente in der statischen Sicht und die Beziehung zwischen denen.
Haben wir
das denn hier gelernt
Nö, sagt jemand? Das stimmt natürlich nicht. Natürlich haben wir
das hier gelernt. Ich versuche nur den Zusammenhang für euch
einfacher auffindbar zu machen. Wo ist das Bild? Ist das
nicht hier drin oder ist in einem anderen Vortrag da?
Ah, was steht denn da oben?
Jetzt muss ich wieder umschalten. Ich lerne das noch.
Nee, gar nicht nicht.
So, hier
Elemente und Beziehung. Externe Eigenschaften. Element, Element, Beziehung.
Beziehung, Beziehung, Juhu. Ja? So, aha
. Architektur beschreibt, wie die einzelnen Sichten aufgebaut sind.
Wieder raus. Hallo. Verwerfen. Und dann hatten wir
noch so
eine Folie
Und zwar, wo ist sie jetzt wieder? Da.
Diese hier. Was für Diagramme da zu diesen Sichten gehören?
In diesen Diagrammen stellt man logischerweise die Elemente und die Beziehungen
der verschiedenen Sichten dar. Aha,
ein Klassendiagramm zum Beispiel hat als Elemente die Klassen und als Beziehung,
die benutzt, Paketdiagrammen hat Pakete,
also Packages und die Beziehung zwischen denen.
Ja? Also so
einen Zusammenhang sollte herstellbar sein
So. Es macht sich auch immer gut, wenn man zum Beispiel solche Fragen,
wie ich heute gestellt habe, antworten kann,
was unterstützt denn jemanden dabei, eine gute Softwarearchitektur hinzuschreiben.
Und wenn dann da sowas stehen würde wie Architektur,
Stil, Wasserfallmodell, Eiscreme, boah,
dann wäre es irgendwie gut,
wenn man Architekturstil ankreuzen würde zum Beispiel
Ich denke jetzt so gerade an diese Multiple-Choice-Fragen oder so.
Wir hatten zum Beispiel hier solche Best-Practices, aber es könnte auch sein,
dass man vielleicht irgendwelche Prinzipien mal erklärt, hm?
Bitte was? Genau, was hilft uns,
die statische Sicht zu strukturieren? Uns, oh, uns
. Danke. Wow. Muss ich die Folie reparieren?
XK. Dankeschön. Macht ja gar keinen Sinn sonst
Ja? Also, das ist Best Practices gibt,
dass es Entwurfsmunter gibt, dass es Architekturstile gibt.
So, ja, sowas ist auch gut. Und dieses
hier zum Beispiel wäre schon gut zu verstehen und wiedergeben zu können.
Das ist nämlich der Kern von vielen, was ihr hier lernt, ja.
Ein Ding hat eine Aufgabe, Single, Responsibility,
Principle ist zweimal vorgekommen in der dritten und in der vierten,
ne, in der zweiten und der dritten Vorlesung.
Ich meine jetzt nicht, dass ihr sagt,
und Diextra und Panas und so.
Nein, das meine ich nicht. Aber dass ihr wisst,
was die Idee dahinter ist,
worum geht es denn da
Also Namen braucht ihr nicht können, das interessiert mich nicht.
Das kommt dann irgendwann später. Wie geht es darum,
dass ihr verstanden habt, den Inhalt verstanden habt?
Ja? So diese vier Dinger hier,
die sind schon nicht schlecht. Das braucht ihr nicht,
das war nur meine Auswertung. Also diese Best Practices,
die hier vorkommen, ein Wurf nach Zuständigkeiten,
große Einheiten vermeiden und dadurch das System ausgewogen machen,
wenig Kopplung zwischen den Systemen
zu haben
Ich habe das immer, wenn ich für irgendwas gelernt habe,
so gemacht, dass ich mir alles,
ich weiß noch, also ich habe eine Banklehre gemacht.
Und wir hatten ein Treffen,
wo sich alle Klassensprecher der verschiedenen Klassen getroffen haben,
die in dem Jahr eine Klausur geschrieben haben.
Und alle haben immer erzählt, was für Fragen die Lehrer
mit ihnen gemacht haben. Und ich habe sozusagen die Schnitt,
all diese Fragen gelernt, also die Menge dieser Fragen.
Und alles, was niemand gefragt hat, habe ich weggelassen.
Und das hat er Erfolg. Also ich frage euch das nicht umsonst,
denkt euch einfach ein paar Fragen aus und übt mal damit,
dann wird das schon gelingen,
So, solche Sachen. Ich könnte mir auch sowas vorstellen,
dass da ein Klassendiagramm ist oder ein Paketdiagramm mit Zyklen drin
und dass da die Frage steht,
ob man den auflösen kann irgendwie oder nicht.
Und wenn wie? Sowas könnte ich mir vorstellen.
Solche Sachen, das hatten wir auch. Zyklen hatten wir
. Ich habe euch, glaube ich, gesagt,
Zyklen sind mein Lieblingsthema, habe ich euch, glaube ich,
gesagt, oder?
Das war hier irgendwo.
Am Ende
Da. Da hatten wir eins von diesen Prinzipien.
Ja, und haben mal so was ausgerechnet. Auch eine
total schöne Aufgabe in der Klausur, mal was auszurechnen.
Besser als euch einen Tech schreiben zu lassen.
Da muss ich mich jetzt schon damit quälen,
dass ihr nicht schreiben könnt.
Darauf verzichte ich lieber.
Dann habe ich mal so ein paar Hinweise über diesen Ausschnitt
der Vorlesung gegeben. Dann ist der Tag vorbei.
Ich wünsche euch ein schönes Wochenende. Denkt dran,
morgen ist Feiertag, da kann man nicht einkaufen.
Und ich bin in zwei, in drei Wochen
wieder da.