uns dieses kleine System angeguckt, so schwierig das auch war,
ja, und haben hier vorne so ganz viele Bilder gemalt,
ja, also so ein bisschen werde ich euch bei der Erinnerung daran versuchen abzuholen und euch ein paar neue Sachen erzählen.
Die Frage ist ja, wie wird es, wie entsteht überhaupt Software?
Wenn man sich das anguckt, was die Leute jahrzehntelang gemacht haben,
dann gab es irgendwelche Anforderungen von den Anwendern und irgendwie auf wundersame Weise ist daraus ein System entstanden,
ja, die Softwareentwickler waren, hatten was Magisches, die waren Zauberer,
die haben also das gekonnt aus diesen Anforderungen, ein Softwaresystem zu machen.
Und wenn man Glück hatte, konnte man es nachher
auch benutzen
So, das habe ich euch letzte Woche ja auch schon so ein bisschen erzählt,
wo ich gesagt habe, und dann kam die Software-Krise,
dann haben die Leute sich also zusammengesetzt und gesagt,
das müssen wir organisieren, so geht das nicht.
Wir wollen also nicht weiterhin diese unvorhersehbare, unplanbare,
nicht wiederholbare Art der Softwareentwicklung haben, das ist außerdem auch teuer,
sondern wir wollen etwas Planbares haben. Ich vermute,
dass wenn ihr eure Studium beendet habt oder dass ihr das jetzt auch schon erlebt,
wenn ihr in Firmen seid, dass es sowas noch gibt,
also weil ich habe das in letzter Zeit auch noch oft gesehen,
dass ich in Firmen komme
Und dann, ja, wir haben ein Problem und dann sage ich,
okay, und wo, was für ein Problem ist das hier?
Ja, hier hat jemand Software entwickelt und wir wissen gar nicht,
wie er das gemacht hat und was er da gemacht hat und wo und so weiter.
Ja, also das Problem gibt es immer noch,
wenn ihr in so eine Firma kommt,
wenn ihr euch irgendwo bewerbt und in so eine Firma kommt,
dann würde ich euch immer empfehlen, geht gleich wieder weg.
Das wird nämlich total anstrengend nachher. Gut,
dann hat die Softwareentwicklung einen ersten Schritt gemacht und hat sich Methoden überlegt,
wie man systematisch vorgehen kann,
wie man irgendetwas nachverfolgbares,
etwas erklärbares,
etwas Dokumentierbares machen kann
Und hat also Methoden entwickelt zum Beispiel, auch die objektorientierte Programmierung,
also dass man Programme so strukturiert in größere Einheiten,
dass die Objekte möglicherweise ein Abbild von den Dingen aus der Realität sind,
dass man etwas simuliert.
Also das war schon mal ein guter Schritt.
Andere Leute haben eher funktionale Dekompositionen gemacht,
also Zerlegung von Systemen in kleinere Teile,
immer kleiner zerlegen und irgendwann kommt man unten an und weiß,
was dieses eine Ding da soll.
Das war schon viel besser als das Planlose, was man vorher hatte,
aber man musste das für jedes Projekt neu machen.
Man musste sehr viel Erfahrung haben, um das im nächsten
Projekt für diese eine, für dieses eine neue System wiederholen zu können
Und man konnte auch erst nachher sehen,
ob das eine gute Idee war. Ja,
also man konnte nicht vorher irgendeinen Satz von Kriterien haben und sagen,
okay, das System wird gut werden, weil wir haben Erfahrung.
So, und da kommt die Softwarearchitektur ins Spiel.
Mit Softwarearchitektur meint man also einen Plan, den man vorher
schon haben kann darüber, wie das System nachher aussehen kann.
Man hat also einen groben, grobes Konzept von dem System.
Man hat Abstraktionen über das System. Das ist auch das,
worum es heute eigentlich hauptsächlich gehen wird,
dass man bei Architektur etwas Abstraktes schafft.
Ja, wenn ihr überlegt, Wie groß waren die Systeme,
die er bis jetzt gebaut habt?
So Klassen? Könnt ihr das mit den Händen noch zeigen?
Oder? Eine Klasse, cool. Hast du SE1 gemacht?
Da musst du woanders gewesen sein. Aber das würde mich mal interessieren.
Wer hat schon Systeme mit mehr als zehn Klassen gebaut?
Melden, bitte. Mit mehr als 100 Klassen. Okay,
da wird es schon dünn. Ich weiß gar nicht,
ob ich das gestern schon erzählt habe,
aber falls ihr als Informatiker euch gesetzlich kranken versichert,
dann geht ihr ja vielleicht auch zur Technikerkrankenkasse.
Deren System, was ihr da benutzt,
das hat 32.000 Klassen
Ja, also richtig, richtig viel, ja.
Und da ist es gut, wenn man mehr Struktur hat als nur Klassen.
Ja, wir haben letzte Woche eine Sache kennengelernt,
mit der man Struktur machen kann in einem System.
Könnt ihr euch daran erinnern, was wir letzte Woche hatten?
Als größere Einheit oberhalb von Klassen? Ein Wort könnt ihr
mir zuschreien, deswegen frage ich das.
Paket, ja, wie heißt das in Java-Paket?
Nee, ne? Das heißt Package, ne?
Ja. Also, wir haben sozusagen schon etwas gelernt,
was Struktur schafft und in Richtung Architektur geht
Gut, aber Architektur will eben auch noch mehr, das will auch abstrakte Ideen,
die man vorher sich ausgedacht hat. Also man hat,
man sagt, ich will zum Beispiel meine Architektur in Schichten haben,
ja, da werden wir noch was drüber lernen, aber solche Ideen,
die kann man wiederverwenden für immer wieder, neue Systeme.
Und den Vorteil, den man davon hat, ist,
dass man sehr viel langfristiger planen kann,
man kann also sagen, okay,
wir bauen erst diesen Teil in unserem Plan, ja,
und dann den Teil,
es ist auch für andere Leute hoffentlich leichter zu verstehen und
man kann es auch vorher schon analysieren,
ob das funktionieren wird und man kann
diesen Plan wiederverwenden
Gut, die Softwaretechnik hat lange darum gerungen, eine Definition für Architektur herzustellen.
Also was ist eigentlich Architektur? Und das ist die Definition,
auf die man sich schließlich geeinigt hat in einem Standard von einer dieser ganzen Organisationen.
Eine Struktur, eines Softwareproduktes umfasst Elemente. Am Anfang haben
die Komponenten gesagt in dieser Definition, aber dann haben sie,
dann kamen die Komponenten orientierte Softwareentwicklung auf und dann haben sie
sich lieber auf das Wort Elemente zurückgezogen.
Ihre extern wahrnehmbare Eigenschaften und die Beziehungen zwischen den Elementen
Was könnten denn Elemente sein in einer Architektur? Wenn ihr
an das kleine Ding denkt, was wir letztes Mal hatten.
Also es gibt irgendwelche Sachen, die haben Beziehungen und haben Eigenschaften.
Hatten wir sowas? Dann nickt jemand, kriege ich auch
eine Antwort
Was hatten wir letztes Mal für Elemente in unserem kleinen Software-System?
Oder wenn ihr selber programmiert, was habt ihr da für Elemente?
Mit Eigenschaften, ganz, ganz einfach.
Ihr habt da Klassen in den Systemen, die ihr baut.
Die haben Beziehungen untereinander und was könnten denn die Eigenschaften sein?
Ja, Zustände, aber kann ich das denn von außen
sehen, was das Ding für einen Zustand hat?
Das habe ich nicht verstanden. Man kann es abfragen,
genau, also die Eigenschaften, das ist eigentlich die Schnittstelle
von einer Klasse
Und wenn man das dann auf die nächsthöhere Ebene auf die Package-Ebene bringt,
dann hat man da das Package als Element.
Man hat Beziehungen zwischen den Packages, die sich in
den Klassen widerspiegeln und man hat auch bei den Packages-Eigenschaften.
Denn wenn ihr das jetzt noch näher kennenlernen werdet,
wie Packages funktionieren, kann man da auch öffentliche und verborgene Sachen machen.
Also das ist kein Zauberkram, was diese Definition sagt.
Sie sagt nur, dass wir irgendwelche Elemente haben,
auf welcher Ebene auch immer.
Also auf verschiedenen Ebenen
So, jetzt steht da so schön, jedes System hat
eine Architektur, aber sie muss nicht bekannt sein.
Das ist ein großes Problem in der Informatik. Es gibt
eine Reihe von Systemen, die man sich anschauen kann,
wo die Entwickler nicht mehr da sind oder die Architekten,
die es mal gab.
Und man weiß nicht, was die sich dabei gedacht haben.
Was war die Architektur? Es gibt ein ganzes Fachgebiet,
das nennt sich Reverse Engineering,
wo man sozusagen aus dem Source Code wieder herauskriegt,
was eigentlich die Idee hier war
So, man könnte sich natürlich immer denken,
dann bauen wir das einfach neu,
aber wenn ihr tatsächlich mal vor so einem System gesessen habt,
was die Leute benutzen, dann werdet ihr gemerkt haben,
es ist nicht so einfach, es einfach neu zu bauen.
Ja, wir haben ganz, ganz viele alte Software in Deutschland,
das habe ich euch ja auch schon gesagt,
die sich nicht einfach mal eben erneuern lässt.
Ich war also vor zwei Wochen bei der Deutschen Bank und
habe da mit den Leuten gesprochen und die haben gesagt,
also sie sind jetzt ungefähr bei 50 Prozent,
wo sie die ganzen alten Kobol-Systeme mit Java abgelöst haben.
Und da ist noch ganz schön viel zu tun und Geld reinzustecken.
Und wenn sie fertig sind, dann ist Java auch schon wieder veraltet.
Ja, also dann kann man wieder von vorne anfangen.
Deswegen ist es wichtig, sich mit alten Systemen
zu beschäftigen und rauszukriegen, was für eine Struktur die
eigentlich haben
So, jetzt ist es so, dass Architektur nicht nur eine Struktur ist.
Ich werde euch gleich noch Beispiele davon zeigen,
sondern es sind immer verschiedene Strukturen, die man auf eine Architektur legen kann.
Man kann zum Beispiel mit der Brille,
wie ist eigentlich die Statik hier da drauf, gucken,
man kann aber auch gucken, wie verhält sich das System dynamisch.
Also wir haben ja letztes Mal auch verschiedene Diagrammarten kennengelernt und ich habe euch gefragt,
was macht das Klassendiagramm, das Klassendiagramm zeigt, die Programmstücke,
die ich programmiert habe und das Objektdiagramm zeigt,
wie das System zur Laufzeit aussieht.
Das sind zwei verschiedene Sichten auf das gleiche System im Endeffekt
Schöne Architekturen. Natürlich hat die Softwaretechnik immer die Analogie zum Gebäudebau. Ja,
man versucht sozusagen, sich immer darauf zu beziehen und zu sagen,
okay, bei den Gebäuden gibt es auch bestimmte Randbedingungen,
bestimmte Architekturen, die sich bewährt haben.
Also kaum jemand wird heute ein Haus ohne Fenster
bauen zum Beispiel oder Treppenhäuser braucht man einfach unbedingt,
sonst kann man nicht in die höheren Stockwerke und man braucht auch Türen zwischen den Räumen,
weil wir können immer noch nicht beamen und solche Sachen.
Also es gibt sozusagen feste Grundsätze für den Bau von Gebäuden
Die lassen sich auch natürlich in der Softwaretechnik finden.
Obwohl Software natürlich ein Fehl flexibleres Element ist. Ja,
also wenn ich in einem Haus von einem Zimmer ins andere will,
dann muss ich einfach durch alle Räume gehen, die dazwischen sind.
Und in der Software kann ich einfach von einer Klasse aus
eine andere benutzen, ohne dass ich irgendwo durchgehen muss.
Ja, also das ist schon was anderes,
aber es hat was Ähnliches, weil es auch auf gewisse Weise anfassbar ist.
Ja, also Software ist natürlich nicht so anfassbar wie Häuser,
aber es hat was Ähnliches.
Gut, wenn man an die Architektur eines Hauses denkt,
dann gibt es da auch verschiedene Sichten drauf.
Ich habe euch hier mal ein paar aufgebaut.
Es gibt zum Beispiel die Sicht, von der ich eben
hauptsächlich geredet habe, das Haus muss funktional sein.
Also man muss ein Badezimmer haben, man muss ein Treppenhaus haben,
man muss Fenster haben und zwar in jedem Raum und nicht nur in manchen.
Man muss irgendwie das mit der Luft gut hinkriegen,
das muss gedämmt sein. Also man muss mit dem Haus irgendwie,
also man muss da drin leben können, sonst will man es nicht haben.
Es muss dicht sein, damit nicht die ganze,
damit da kein Regen reinkommt, das wollen wir alle nicht haben,
dass wir nachher Schimmel in der Wohnung haben oder sowas.
Es muss energieeffizient sein heutzutage. Der Statiker sagt,
also wenn es nicht stabil ist, dann geht das hier gar nicht.
Ja, da könnt ihr noch so viele Ideen haben
Es muss sicher sein, ja, es dürfen also keine Kabel
irgendwo draußen rumhängen und vielleicht kommt ihr eher damit, dass sie sagt,
ja, mun, ich will es aber auch bezahlen können.
Also da könnt ihr noch so viel mit Sicherheit und sonst was kommen.
Also Sicherheit muss sein, aber möglicherweise mit Schönheit oder so, ja, ich will ein bezahlbares Haus. So,
und wenn, wenn ihr mal mit euch echten Architekten zu tun gehabt habt,
dann werdet ihr das auch gesehen haben,
die haben tatsächlich verschiedene Pläne, ja, es gibt einen Plan,
einen Grundriss, also sowas wie hier oben,
ein Grundriss, aber es gibt eben auch solche Pläne,
die zeigen, wie die Kabel verlegt werden,
wo das Wasser langläuft und das kann man gar nicht alles
in einen Plan reintun
Das ist unmöglich. Und es gibt eben durchaus auch Sichten,
die sich möglicherweise entgegenstehen. Also wir hatten eben schon Schönheit und Bezahlbarkeit
. Da kann man, das mag manchmal so sein,
dass man sich das eben einfach nicht leisten kann,
dass das Haus noch schöner ist.
Man will aber natürlich durchaus auch zwischen diesen verschiedenen Sichten Konsistenz haben,
weil es nützt ja nichts, wenn der eine denkt,
hier ist eine Wand,
da baue ich jetzt mal eine Wasserleitung durch und der andere denkt,
da kommt aber ein Fenster hin.
Das wird schwierig. Also man muss dafür sorgen,
dass diese verschiedenen Sichten zusammenpassen.
Diese verschiedenen Pläne
Und sowas machen wir in der Softwarearchitektur auch. Wir schaffen
uns verschiedene Sichten auf ein System mit jeweils unterschiedlichen Schwerpunkten.
Und je nachdem, welche Sicht wir gerade haben,
kommt ein anderer Aspekt in den Vordergrund.
Und andere werden vernachlässigt. Ich zeige euch gleich Beispiele dafür
. Und dadurch, dass wir diese Sichten haben,
diese verschiedenen Sichten, tun wir natürlich eine Sache,
die unheimlich wichtig ist bei großen Systemen.
Wir reduzieren die Komplexität. Wir gucken also nur aus
einem Blickwinkel daraus. Und das ist auch das, was
die Architekten beim Bau machen. Die reduzieren die Komplexität,
um einfach nur auf einen Teil der ganzen Sache
zu gucken
So, auch hier in der Software-Technik ist das natürlich so,
die Sichten sind nicht voneinander unabhängig, also bestimmte Informationen tauchen immer mehrfach auf.
Und man sollte versuchen, die Sichten konsistent zu halten,
sonst baut der eine, geht der eine davon aus,
dass er diesen Drucker ansprechen kann und der andere geht davon aus,
dass es nur ein lokaler Drucker ist und schon funktioniert das ganze System nicht.
So, grundsätzlich sind solche Sichten immer als Grafen,
werden immer als Grafen in irgendeiner Form dargestellt,
der größte Teil von denen, also die Bilder,
die wir letzte Woche gemacht haben,
könnte man auch als Sichten auf ein Software-System betrachten, ja,
die wir hier mit UML an die Wand gemalt haben.
Da zeige ich euch auch gleich noch
ein Bild zu
Das sind die typischen Sichten, die man bei Softwarearchitektur hat.
Man spricht darüber, dass man eine statische Sicht hat.
Das ist das, was ihr auch schon so ein bisschen kennt.
Also eine statische Sicht, bei der wir so etwas haben,
wie Subsysteme, also Teilsysteme,
ihr könnt euch das jetzt erstmal als Package vorstellen.
Ja, wir haben also Packages in unserem System.
Wir haben Schnittstellen zwischen denen und wenn ihr das Wort Schicht
schon mal irgendwo gehört habt,
dann wird euch das nicht so ganz erschrecken.
Aber wir haben normalerweise in Systemen
auch Schichten
Also wir haben Teile des Systems, die ganz unten sind,
wo wir zum Beispiel die Datenhaltung machen,
da drüber eine Schicht, die eher so Funktionalität hat,
Business-Logik oder sowas und ganz oben die Oberfläche, das Gui.
Und in die Richtung werdet ihr ja dieses Semester auch gehen. Ihr werdet ja,
nachdem ihr diese Medienverwaltung hinter euch gebracht habt,
ich weiß gar nicht,
ob ihr da jetzt schon angekommen seid,
aber ihr werdet ja so zwei oder drei Projekte machen,
werdet ihr auch ein Kinosystem bauen und in dem werdet ihr
auch natürlich eine Oberfläche haben und andere Teile des Systems,
die weiter unten sind.
Also daher kommt das Wort Schicht
Ich gehe mal auf die Suche nach dem Schwamm.
Hier ist er nicht. Auch der ist da.
Ja, das ist ja... Das ist auch gut.
Also ein typisches Bild von der statischen Sicht auf ein System
sieht so aus. Ich habe hier unten eine Schicht.
Da sind die Datenbankzugriffe zum Beispiel drin. Und
dann habe ich da drüber eine Schicht,
in der sind alle Klassen,
die was mit der Business-Logik
zu tun haben
Und darüber habe ich eine Schicht, die Macht, die Oberfläche.
Und ich will, dass die sich nur von oben
nach unten irgendwie benutzen und nicht in der anderen Richtung.
Also das wäre eine statische Sicht auf ein System.
Wir hatten letztes Mal zumindest zwei von solchen Sachen auch,
wenn ihr euch erinnert, in diesem kleinen Beispiel,
was wir letztes Mal angeguckt haben,
man kann es nicht lesen.
Ihr guckt so verknattert, weil ihr es nicht lesen könnt.
Zu klein oder meine Schrift?
Ich verstehe kein Wort. Das, was ich geschrieben habe
, sieht man nicht. Okay. Noch mehr aufdrücken?
Okay, nee, das ist nicht schön. Okay,
auch die Tafel wird mir nicht mehr viel helfen.
Ich habe hierhin geschrieben, Business Logic, ja,
falls es jemand aufschreiben will, Business Logic,
da habe ich Oberfläche hingeschrieben und da habe ich DB-Zugriff,
Datenbankzugriff hingeschrieben.
Die statische Sicht ist die eine und das ist auch die,
mit der ihr erstmal am meisten zu tun haben werdet.
Aber auf der anderen Seite gibt es auch noch
eine fachliche Sicht auf Architektur. Das ist im Grunde,
was für Anforderungen gibt es an das System,
wie wird das System für Kooperation eingesetzt,
wie benutzbar ist es für den Anwender.
Also all diese Fragen,
die auch in den Bereich Softwareergonomie gehören,
die gehören in die fachliche Sicht auf Architektur
Wenn ihr mit größeren Systemen zu tun bekommen werdet,
dann werdet ihr euch auch über die Verteilungssicht Gedanken machen.
Also die Frage, was kommt eigentlich auf den Server?
Was kommt auf den Client oder muss ich noch
einen extra Server für die Datenbank haben? Ja,
also die Verteilung des Systems auf verschiedene Hardware,
das ist der Fokus von der Verteilungssicht,
was für Netzwerkprotokolle verwende ich, was für Netzwerke verwende ich überhaupt.
Also da geht es um diese Sache und dann noch
die Laufzeitsicht, wo es eben hauptsächlich um die Performance geht
Es gibt in der Informatik ganz, ganz viele Leute,
die sich Gedanken gemacht haben über diese Sichten. Ja,
also das, was ich euch hier jetzt hingemacht habe,
diese vier Sichten, sind die,
die wir hier in SDE und in OOPM verwenden.
Da seht ihr Namen von wichtigen Leuten, die was über Softwarearchitektur geschrieben haben,
die haben ganz viele andere Sichten definiert, die sie einfach anders nennen.
Mir reicht es, wenn ihr die da oben kennt,
also wenn ihr einfach wisst, dass es das gibt,
ja, und wir werden die im Laufe des Semesters noch mit etwas füllen.
Es ist mir nur wichtig, dass ihr wisst,
okay, es gibt auch noch andere Leute,
die ihre Meinung dazu gesagt haben
Wo kommen jetzt diese Sichten eigentlich im Laufe eines Projektes vor?
Ich habe am Anfang zu Projektbeginn Anforderungen. Ja,
da haben wir am Anfang auch hier schon drüber gesprochen.
Und diese Anforderungen muss ich in irgendeiner Weise strukturiert aufschreiben,
zusammenfassen. Und das tue ich in der fachlichen Sicht.
Da schreibe ich also auf, was das Produkt soll,
was für Funktionen es haben wird, was für Geschäftsprozesse ich damit abdecken will.
Ja, also zum Beispiel über das kleine System,
was wir letzte Woche hatten, was ja dazu da war,
um so eine Wortprüfung zu machen, könnte man eben aufschreiben,
okay, Funktion ist, dass es Worte überprüfen kann.
Man kann es beim Schreiben von Texten benutzen. Ja,
und dann würde man noch beschreiben, vielleicht so in einer
Art eines Szenarios, wie die Leute damit arbeiten sollen.
Also was passiert, wenn sie auf die Knöpfe drücken,
so von der Idee her? Also das ist die funktionale Sicht.
Wenn man dann tatsächlich anfängt zu programmieren, dann sollte man vorher
einen Bauplan des Programms haben, also die statische Sicht.
Ja, was beschreibt, welche Teile ich haben werde,
in welche größeren Einheiten das System strukturiert wird.
Und dann brauche ich auch noch die Verteilungssicht ganz sicherlich,
um mir Gedanken zu machen, wie das dann auf Rechner verteilt werden soll.
Bei diesem kleinen Beispiel, was wir da letzte Woche hatten,
würde ich mir wahrscheinlich über Performance wenig Gedanken machen.
Ja, weil das ist ein System, was auf dem Client laufen wird.
In einem Word-System oder sowas. Das hat keine Performance-Probleme,
deswegen ist die dynamische Sicht hier jetzt nicht mit auf diesem Bild.
Und all das hat Einfluss auf den Programmcode, der nachher dann entsteht.
Gut. Und wir haben letzte Woche UML-Diagramme kennengelernt und
die habe ich jetzt an dieser Stelle mal zugeordnet,
diesen Sichten
Es gibt immer auf der einen Seite OML-Diagramme,
die die Struktur eines Systems beschreiben und andere, die das Verhalten beschreiben.
Also, was die einzelnen Objekte miteinander treiben oder die einzelnen Systemteile.
Und ich habe sie hier den verschiedenen Sichten zugeordnet,
damit ihr so den Zusammenhang so ein bisschen erkennen könnt.
Also, wenn man sich über die statische Sicht Gedanken macht,
dann macht man immer und die Struktur dessen,
dann wird man Klassendiagramme aufzeichnen, Paketdiagramme, Komponentendiagramme.
Also das, was ich hier so versucht habe,
an die Tafel zu malen,
Geht so ein bisschen in die Richtung von einem Paketdiagramm,
sieht natürlich nicht genauso aus, mit diesen Reitern immer.
Aber irgendwelche größeren Strukturen darzustellen, das kann man mit diesen Diagrammen machen.
Wenn man das Verhalten beschreibt, dann wird man in der
statischen Sicht Zustandsdiagramme verwenden, Zeitdiagramme, Aktivitätsdiagramme.
Ich habe euch letzte Woche ja auch gesagt,
welche ich von denen wichtig fand,
bei den Strukturdiagrammen für die statische Sicht, habe ich euch gesagt,
ich würde euch immer Klassendiagramme und Paketdiagramme empfehlen.
Da solltet ihr wissen,
was das ist
Und bei den Verhaltensdiagrammen benutze ich in der Regel Zustandsdiagramme und die anderen eigentlich nicht,
weil die in den Kontexten, wo ihr Software entwickelt, eigentlich eher nicht vorkommen.
Da müsstet ihr schon irgendwelche Hardware nah an Sachen machen, damit ihr Zeitdiagramme und sowas braucht. So,
für die Verteilungssicht gibt es nur ein einziges Diagramm,
das habe ich euch letzte Woche aber auch gezeigt,
ja, also mit diesen Kästen,
in denen dann die einzelnen Jazz ablaufen, ja,
das ist ein sehr wichtiges Diagramm für Software, um zu zeigen,
ne, wo auf welche Hardware-Plattformen läuft welcher Teil,
für die Verhaltenssicht gibt es in OML keine Unterstützung in diesem Fall,
ja,
also für das Verhalten von Softwaresystemen
Für die Laufzeitsicht haben wir auf der einen Seite Objektdiagramme,
mit denen wir die Struktur von Softwaresystemen darstellen können.
Wir haben noch Kompositionsdiagramme, die ich euch letzte Woche nicht
weiter vorgestellt habe, weil sie auch zu denen gehören,
die man nicht so oft braucht.
Und auf der anderen Seite, was das Verhalten angeht,
in der Laufzeitsicht, sind Sequenztiergramme unheimlich wichtig.
Ich weiß nicht, ob ihr euch daran erinnert.
Ich habe euch letzte Woche das gezeigt mit so einzelnen Linien,
wo die Objekte leben und wie die sich miteinander unterhalten,
also über Pfeile dann miteinander kommunizieren.
Das waren die Sequenzdiagramme, die kann man hier einsetzen,
um die Laufzeit darzustellen
So, Kommunikationsdiagramme und Interaktionsübersichtsdiagramme sind ja auch nur der Vollständigkeit
da, die werdet ihr nicht brauchen. Gut,
für die fachliche Sicht hat die OML auch keine Unterstützung,
jedenfalls nicht für die Struktur, sondern nur für das Verhalten,
da gibt es Use-Case-Diagramme.
Das sind diese Bilder, wo so Männlein sind,
die dann so Beziehungen zu solchen größeren Elipsen haben.
Ihr werdet andere Sachen kennenlernen bei uns.
Ihr werdet im Rahmen des Projektes, was ihr macht,
da ein Glossar schreiben auch, also mit Glossaren zu tun haben.
Ihr werdet, also fachliches Begriffsmodell, das sollte eine Heinz
oder Axel schon mal zu euch gesagt haben. Also,
dass man tatsächlich die Begriffe aus dem Anwendungsbereich in ein Modell tut und strukturiert und sagt,
okay, das sind die Umgangsformen für diesen Gegenstand,
das sind die Umgangsformen für jeden Gegenstand.
Und für das Verhalten verwenden wir bei uns sehr viele Dinge,
die textuell sind tatsächlich. Das heißt, wir schreiben Szenarien,
wir schreiben Visionen davon, wie das System nachher aussehen soll.
Das kann ich euch immer nur mal empfehlen. Wenn ihr
mal Software entwickeln sollt, Also ganz neu entwickeln sollt.
Also wenn ihr das Glück habt, das zu tun,
dann solltet ihr euch mal hinsetzen und aufschreiben,
wie ihr euch vorstellt, dass jemand mit dem System arbeitet.
Das verbirgt sich hinter dem Wort Vision. Das ist immer wieder erstaunlich,
wenn man merkt, was man alles nicht bedacht hat,
wie diese Software benutzt werden soll.
Ja, und dann steht da noch das hübsche Wort,
exemplarische Geschäftsprozessmodulierung. Das ist auch was,
was wir hier machen, um größere Arbeitszusammenhänge zu modellieren.
Das werdet ihr gegen Ende eures Bachelors oder im Master
dann irgendwann mal kennenlernen,
wie man sowas macht
So, ich habe hier noch, unabhängig von den Sichten,
euch mitgebracht, Einfluss, Flussfaktoren auf Softwarearchitektur.
Bei mir wichtig ist, dass euch klar ist,
dass das natürlich alles seinen Einfluss hat.
Ich kann mich nicht hinstellen und kann einfach sagen,
ich male jetzt meine Softwarearchitektur auf, weil ich das so hübsch finde.
Sondern es gibt viele Dinge, die das immer beeinflussen.
Also ich muss wissen, auf was für einem Basissystem
baue ich jetzt diese Software? Wird das ein Websystem,
wird das ein Fettclient, muss ich vielleicht sogar auf den Großrechner,
weil die Bank, bei der ich entwickle,
alles auf dem Host laufen lassen will,
das ist mit Java ja auch möglich heute
Habe ich irgendwelche Altsysteme, die ich einbinden muss?
Das hat ganz andere Auswirkungen auf die Software. Ich muss sehen,
was ich für einen Zugang zu diesem Altsystem kriege.
Ich muss also möglicherweise über bestimmte Hardware-Protokolle da drauf und muss dann auch bedenken,
dass ich sozusagen getrennt von diesem System bin.
Also ich bin nicht mehr in einem Prozessraum,
sodass ich dieses Altsystem wie ein Teil von mir verhält,
sondern ich muss immer wieder Anfragen stellen und wenn es mir nicht antwortet,
muss ich mir in meiner Architektur eine Lösung ausdenken, was ich mache.
Also ich bin gerade in einem Projekt,
wo eine neue Software in der,
bei der Hala hier draußen in der Packhalle eingeführt wird,
wo die Leute Container packen.
Ja, also da kommen Lehrcontainer an und die Ware wird
geliefert mit LKWs, so in solchen größeren Einheiten.
Und das muss also jetzt in diese Container reingepackt werden.
Und die haben bisher mit Excel-Listen und all sowas gearbeitet.
Und das wollen sie jetzt verbessern. Sie wollen also eine
Softwareunterstützung und haben sich eine Software von einem Anbieter gekauft.
Ganz modernes Ding mit schöner Oberfläche und man kann überall klicken und wunderbar.
So, aber das nützen einem ja wenig dieses System jetzt
alleine zu benutzen, wenn man die Daten alle nicht hat.
Ja, also es gibt natürlich ein System an diesem Terminal,
ein sogenanntes Container-Basissystem, in dem alle Containerdaten drin sind.
Und das System weiß auch, wann der Container gekommen ist,
ob er schon da ist, ob er nicht da ist,
ob er leer ist, ob er voll ist und wo er hin soll und wann.
Und all diese Dinge, weiß dieses Container-Basissystem. Bisher haben
die Leute mit dem Container-Basissystem gearbeitet. Sie wollen aber jetzt
das neue System benutzen, weil es sie besser unterstützt.
Wie kriege ich jetzt die Daten da rein? Dieses hübsche
Container-Basissystem hat eine JMS-Schnittstelle. Das ist ein Kürzel für Java-Messaging-System
. Also da kann man Nachrichten hinschicken und kriegt Antworten
Dieses System schickt auch ständig Updates über diesen Kanal.
Der Container hat sich geändert, der Container hat sich geändert.
Die erste Idee war, na dann schließen wir uns doch da an.
Immer, wenn ein Container-Update kommt, dann wollen wir
den auch haben. Und dann habe ich gesagt,
das ist vielleicht so erstmal theoretisch eine gute Idee,
aber da sind 17.000 Container auf dem Terminal.
Ja, und wir wollen, also wenn da 40,
400 Stück auf ein Schiff verladen werden,
dann gibt es auch 400 Updates innerhalb von einer halben Stunde.
Und zwischendurch gibt es noch eine ganze Menge mehr,
wollt ihr die wirklich alle haben?
Ihr braucht ja in eurer Packhalle nur einen ganz kleinen Teil
dieses Ausschnittes
Ja, das stimmt. Nee,
das ist ja auch, da müssen wir immer gucken,
welche wollen wir eigentlich, welche Daten und so.
Das ist ja ganz schrecklich. Die Datenbank wird riesengroß.
Nee, das wollen wir nicht. Okay, das war schon mal
eine gute Idee. Denn was wollen wir dann machen?
Ja, dann wollen wir das vielleicht über eine Anfrage machen.
Sag ich, ist eine gute Idee. Also,
wenn man eine Containernummer eingibt, dann gibt es eine Nachricht an
das andere System. Und das schickt die Containerdaten zurück.
Genau, super. Wunderbar. Dann sage ich,
und was passiert, wenn das nicht antwortet?
Weil irgendwas, weil es die Containernummer nicht hat,
der hat sich falsch getippt da oben.
Oh, ja. Also, wir brauchen einen Fehlerkanal.
Was machen wir dann damit? Gut, dann hat das
System einmal die Containerdaten. Dann denkt natürlich dieses Parkallensystem,
jetzt habe ich die Containerdaten. Und dann sage ich,
okay, und was ist,
wenn sich dann was ändert in dem anderen System
In dem Container-Basissystem, wenn sich an den Container dann was ändern,
von denen ich jetzt eine Kopie habe in meinem neuen System.
Ja, das wollen wir dann wissen. Ja, sag ich
, das glaube ich. Aber wie und wann und warum
? Ja, dann soll der uns ein Update schicken.
Ja, woher soll der denn wissen,
dass er jetzt euch ein Update hat? Wir könnten versuchen,
das Container-Basissystem zu ändern und die Container-Tabelle um ein Feld zu erweitern.
Das wurde mal von der Packhalle abgefragt. Dieser Container und
wenn sich da was ändert, gibt es ein Update.
Dann sage ich, ja, das könnten wir versuchen.
Das wird aber extrem teuer, weil dieses Container-Basissystem,
wenn man das ändert, weil man nie weiß,
was dann passiert, muss man es ganz,
ganz durchtesten.
Das ist eine komplexe Angelegenheit
Oh ja. Was würde denn das kosten? Sag ich ja
, so 200.000 Euro oder so. Oh, nee,
dann wollen wir das lieber doch nicht. Ja gut,
dann sag ich, wie wäre es denn,
wenn jemand dann irgendwas aufruft, wo dieser Container drin ist,
dass man dann die Daten nochmal anfragt.
Oh ja, das wäre eine gute Idee. Ja,
aber so, ne, so arbeitet man sich von Höckschen zu Stöckschen,
um irgendwie mit diesen Altsystemen oder mit dem Zustand klarzukommen,
den man da hat.
Ja, also das sind dann so Sachen,
mit denen man zu tun hat. Gut,
ihr könnt auch nicht in eine Organisation gehen,
also ich kann zum Beispiel nicht zu meiner Parkhalle gehen und sagen,
wir machen die Architektur jetzt so,
weil ich finde das toll
Total schick, ja, dass wir da nicht über JMS,
sondern über ein Remote-Procedure-Call oder so direkt drauf zugreifen auf das Einsystem,
dann sagen mir die Haller-Architekten, ja,
das hast du dir vielleicht hübsch ausgedacht hier,
aber das geht gar nicht, das passt nicht zu unseren Entwicklungsstandards.
Ja, so. Und in dem Beispiel eben hatte ich auch schon so eine nicht funktionale Anforderung,
ne, also man will nicht,
dass die Datenbank in diesem neuen System unendlich groß wird,
weil die sich alle Container merken muss, die darüber kommen,
die sowieso niemand in der Pakalerie zu Gesicht bekommt, ja,
weil die einfach nur angeliefert werden und direkt aufs Schiff gehen und niemand interessiert sich.
Also nicht funktionale Anforderungen wirken sich natürlich auch auf die Architektur auf und das,
wo wir eben darüber auch schon geredet haben,
Wie soll das System verteilt werden?
Ja, ich kann mir eine total tolle Architektur ausdenken.
Für Xing oder für irgendjemand, für eBay oder für Fligger oder keine Ahnung, für wen.
Aber das funktioniert nicht, weil ich brauche ganz, ganz,
ganz viele Rechner, um die ganzen Anfragen überhaupt zu realisieren.
Wo ich gerade Xing sage, am 27. April,
das ist ein Dienstag,
wird ein Mensch von Xing in einem Seminar bei uns einen Vortrag halten über Performance by Xing,
wie die da ihre Software performant machen,
damit die Anwender da bleiben, die User da bleiben.
Wir machen da auch, wir haben Aushänge bei uns rumhängen.
Wir haben es, glaube ich,
sogar auf unserer SPT-Seite
Halte das für ziemlich spannend. Also wenn ihr mit der
Information was anfangen wollt oder dann noch Fragen zu habt,
dann könnt ihr mich gerne fragen.
Gut, also das sind alles Einflussfaktoren auf Softwaretechnik, die man bedenken muss.
Und natürlich hat auch der Anwendungsfall Auswirkungen auf die Architektur.
Ihr habt jetzt schon mit Eclipse gearbeitet. Es ist nicht
mehr ganz so, oder? Ja? Habt ihr jetzt
? Okay. Das ist ja ein Fett-Client, ja?
Also ihr habt auf eurem, auf eurem Desktop, habt ihr das Ding installiert?
Ja, das ist keine Weboberfläche oder sowas. Das ist auch genau die richtige Architektur für diese Art von Anwendungskontext. Wenn ihr euch vorstellt,
dass ihr irgendwann tatsächlich mal in so einem Projekt seid und mit mehreren Leuten an Software arbeitet,
dann wird es einem Server geben, auf dem die ganze,
auf denen der ganze Source liegt und ihr werdet sagen,
ich will jetzt an dieser Datei arbeiten,
ich hole sie mir runter, ich check sie aus,
sie ist bei mir auf meinem Rechner,
ich bearbeite sie und wenn ich fertig bin, spiele ich sie zurück.
Das ist eine Art,
also das ist die typische Art Software zu entwickeln und das ist auch sinnvoll,
wenn ihr euch vorstellt, Leute, die in einer Bank arbeiten und Daten eingeben,
dann ist viel wichtiger, dass diese Daten schneller auf den Server kommen,
für so eine Art von Anwendungskontext oder wenn ihr selber eure Bank bedient,
ist so eine Web-Oberfläche viel besser, wo die Daten aufnehmen,
wo eigentlich alles auf dem Server bleibt.
Ihr holt gar nichts zu euch. Ihr kriegt nur so
eine ganz dünne Datenschicht, kriegt ihr zu euch rüber,
bearbeitet die und schickt sie gleich wieder zurück und dann sind sie wieder drüben.
Also es würde keinen Sinn machen, wenn ihr mit eurem Elektronik-Banking arbeitet,
eure gesamten Kundendaten all eure Konten und Kredite und was ihr sonst noch habt,
alles auf den Kleinen drüber zu schaufeln,
nur damit ihr eine Überweisung machen könnt.
Es ist was ganz anderes, als Software zu entwickeln.
Und das hat natürlich Einfluss auf die Architektur,
wie das nachher aussieht
Und natürlich, das ist das, was da unten steht,
hat auch die Erfahrung der Leute,
die jetzt mit der Architektur was zu tun haben oder das System bauen,
immer noch viel Einfluss darauf, was passiert.
Ja, ich habe vorhin zu euch gesagt, ja,
früher, als es noch keine Architektur gab, da hing es nur von der Erfahrung ab.
Auch jetzt hängt es natürlich noch von der Erfahrung ab. Habe ich Leute,
die schon mal ein System gebaut haben, da auf meinem Container-Terminal,
von dem ich eben schon erzählt habe,
haben sie ein neues, eine neue Software zur Transportsteuerung eingesetzt,
ja, und die Leute,
die das gebaut haben,
die hatten vorher eine Software für Kofferbänder
an Flughäfen gebaut
Ja. Und die hatten, also Koffer sind was anderes als Container,
einmal von der Größe her und auch von der Geschwindigkeit,
mit der da irgendwelche Nachrichten kommen zu denen.
Ja, also die Container, für die gibt es immer schon Daten im Voraus.
Es gibt eine ganze, die Menge ist einfach viel größer,
die auf so einem Terminal umgesetzt werden muss.
Und diese Leute haben einfach mit ihrer bis daherigen Erfahrung von
Koffern und Kofferbändern auf diese Container geguckt und haben etwas gebaut,
was niemals die Menge der Nachrichten verarbeiten konnte,
die da durch so ein Terminal laufen. Ja,
weil jedes Gerät immer sagt, ich bin jetzt hier,
ich habe den Container hier hingestellt, ich bin jetzt hier,
also wenn ihr mal in Hamburg am Hafen seid,
dann seht ihr,
dass sie so große Lagerkräne haben und die sagen alle
fünf Meter,
wo sie sind
Und wenn da von 29 Stück da sind,
dann muss man damit umgehen können, dass so viele Nachrichten kommen.
Man muss die verarbeiten können. Und die Architektur war dafür einfach
überhaupt nicht ausgelegt. Also die Erfahrung macht viel aus.
Gut, es ist drei. An dem Punkt machen wir jetzt
unsere Pause. Hut euch fünf Minuten aus, trinkt was
. Und so weiter. Gut, alle wieder da,
dann machen wir mal weiter. Ich habe eben sozusagen als Abschluss
vom ersten Teil Euch was zu den Einflussfaktoren auf Softwarearchitektur erzählt,
so ein paar, so ein bisschen Beispiele gemacht.
Und wir wollen uns jetzt in die statische Sicht auf Software hineinbewegen.
Ihr müsst ein bisschen klein, leiser sein, sonst schimpfen die anderen wieder.
Oh, super. Okay. Die statische Sicht,
da gucke ich auf die Klassen und wie die gebaut sind.
Und da gibt es gar nicht viel.
Es gibt die Klassen selbst, die Klassen benutzen sich untereinander.
Also es gibt bestimmte Beziehungen, so was programmiert ihr schon,
dass eine Klasse eine andere benutzt
Ich glaube, das habe ich letztes Mal schon gefragt,
was bedeutet eigentlich, dass eine Klasse eine andere benutzt?
Ich glaube, wir haben letztes Mal das zusammen aufgezählt.
Eine Klasse hat eine andere als Exemplarvariable, sagt die Exemplarvariable dazu?
Ja, gut. Oder nicht? Mhm. Aber
ihr wisst, was ich meine, ja.
Also bei einer Klasse ziemlich weit oben steht Private irgendwas anderes.
Das ist benutzen. Benutzen ist aber auch,
wenn ich natürlich eine lokale Variable habe von irgendeinem anderen,
von irgendeiner anderen Klasse und benutzen ist, wenn ich das als Übergabeparameter habe oder so.
Ja, das ist alles benutzen. Die Klasse braucht
die andere
So, was ihr noch nicht kennt, ist die Vererbungsbeziehung,
aber ich glaube, die wird euch nächste Woche unterkommen.
Also Klassen können von anderen erben. Ihr habt sowas schon mal mit Interfaces gemacht,
glaube ich. Ihr habt sowas gemacht wie Implements. Ja,
das ist, ja, ich weiß nicht,
ob Axel mir jetzt den Hals umdreht,
aber das ist so eine ähnliche Beziehung, ja,
eine Klasse implementiert, eine andere Klasse.
Also Vererbung, werdet ihr kennenlernen. Ich glaube,
ihr habt noch nicht mit Inner Classes gearbeitet, oder?
Inner Classes? Sagt euch das was?
Wer nickt in SE1
In der Classes in SE1, nein. Okay. Ich glaube,
die werdet ihr nicht meine SE2 kennen. Ihr könnt aber mitnehmen,
das Wissen, dass Klassen auch Klassen enthalten können.
Für verschiedenste Kontexte braucht man das. Vielleicht werdet ihr das
bei der Gui-Programmierung, wird euch das unterkommen.
Also, es gibt Enthaltenseinsbeziehungen. Klassen enthalten Klassen. So.
Und dann gibt es oberhalb von Klassen irgendwelche Strukturen, ja?
Man kann dazu irgendwas sagen. Ich sage dazu immer Subsystem,
ja, und Subsysteme enthalten Klassen. Und Subsysteme sind wieder
in Subsystemen enthalten. Und das ist alles sehr hierarchisch,
ja? Also ganz oben kann man einen Kasten machen,
das System,
Das enthält dann bestimmte Subsysteme, die enthalten wieder Subsystemdiverse.
So wie, wenn ihr in Windows euren Dateibaum anguckt,
genau so ist das.
Nicht anders. So, jetzt kriegt ihr natürlich alle ein Fragezeichen.
Was meint sie jetzt mit Subsystem? Das ist natürlich,
also diese Darstellung ist sozusagen programmiersprachenunabhängig. Wenn ihr Java programmiert,
dann ist die erste Ebene an Subsystemen Packages.
Die heißen da Packages. Wenn ihr C-Sharp programmiert,
dann heißt die erste Ebene von Subsystemen Directories oder Namespaces
oder was auch immer ihr da gerade dann macht.
Oder wenn ihr Ziel Plus Plus programmiert,
dann sind das
auch Verzeichnisse
Also das ist sozusagen ein Blick auf die statische Sicht,
der von eurer Programmiersprache unabhängig ist. Ja, aber
die Übertragung ist nicht schwer, das ist ein Package.
Ja, und ein Package enthält Klassen. Ja,
und sowohl Klassen als auch Subsysteme haben eine Schnittstelle,
ja, über die man sie benutzen kann.
Mit Schnittstellen hattet ihr ja schon zu tun,
ihr habt private und öffentliche Methoden gehabt an euren Klassen und
auf um Gottes Willen niemals die Exemplarvariablen öffentlich gemacht und solche Sachen,
das habt ihr alles gelernt, ne, dass die da nicht hingehören.
Gut. So, und das ist das linke Bild.
Also das sind alle Elemente und Beziehungen,
die man in der statischen Sicht jemals finden wird.
Was anderes gibt es da nicht. Ja,
es kann sein, dass jemand kommt und sagt,
ich nenne das Ding Komponente
da oben
Dann ist es nur ein anderer Name. Oder es kann sein,
dass jemand kommt und sagt, ich nenne das Ding Modul.
Auch schön, auch nur ein anderer Name.
Bedeutet immer dasselbe etwas, wo diese ganzen Sachen drin sind
und das kann wieder in etwas enthalten sein.
Einfach nur eine Strukturierung. So, hier ist mal
ein Beispiel. Da oben sieht man das ganze Ding.
Also es gibt eins, zwei, drei, vier,
fünf Klassen. Die Klassen sind immer in Subsystemen hier.
Die ist alleine, hier sind zwei zusammen.
Da gibt es irgendwelche Beziehungen dazwischen, die benutzen sich,
der erbt von dem.
Und diese beiden Subsysteme sind wieder in einem größeren Subsystem und
die beiden auch. So, so könnte man
ein System beschreiben
Und was man jetzt macht, weil ich habe euch ja gesagt,
wenn ihr an die Techniker-Krankentasse denkt, 32.000 Klassen,
das Bild ist zu groß, das kriegen wir nie gemalt.
Also wir abstrahieren, wir lassen was weg.
Genauso wie wenn ihr in Windows im Dateiexplorer Verzeichnisse zumacht.
Wir machen was zu. Das heißt,
wir lassen die Klassen einfach weg und gucken auf das System,
was wir da eben hatten und sagen,
wir haben zwei Subsysteme und die enthalten jeweils zwei Subsysteme.
Und da gibt es Beziehungen zwischen. Wer die macht,
interessiert uns nicht. Die sind da irgendwo drin.
Und dann kann man noch eine Ebene höher gehen,
wenn einem das immer noch zu viel ist.
Also und so schafft man sich in der Architektur,
in der statischen Sicht abstrakte Sichten auf ein System
Gut, das ist sozusagen die Grundlage gewesen,
eben dafür das, was ich euch jetzt erzähle,
denn ich will euch ein paar grundlegende Dinge zeigen,
was uns hilft, wenn wir Software entwickeln,
um die statische Sicht zu strukturieren.
Es gibt eine ganze Reihe von Best Practices,
so nennt man das, in der Softwaretechnik, also Sachen,
über die Leute 1000 und 35.000 Mal geschrieben haben,
wie gut es ist, wenn man die Software so baut.
Da werde ich euch drei Sachen sagen, die ihr als
Schlaglichter so, die ihr vielleicht auch schon nachempfinden könnt.
Dann gibt es etwas sehr,
sehr Schönes in der Softwaretechnik, das ist 1995 entstanden,
da hat jemand eine Doktorarbeit geschrieben über Designpattern,
hat er
das genannt
Und das hat eingeschlagen wie eine Bombe, ja,
ich weiß gar nicht, was er für eine Note dafür gekriegt hat,
aber das Ding ist, als Buch rausgekommen und sofort haben alle gesagt,
das ist, das ist super, ja,
weil endlich hat das einen Namen, was wir immer machen, ja,
ich habe meine Diplomarbeit mit einer anderen Studentin zusammen im gleichen Labor sitzend geschrieben,
also programmiert, ne, und als wir diese Designpattern hatten,
da konnte ich mit ihr über das reden,
was ich machte und was sie machte, ohne zu verstehen,
was sie da nun fachlich tat, ja,
die hat irgendwas gebaut für irgendeine Bank und ich habe ein Hilfesystem gebaut,
das hat alles nichts miteinander zu tun, konnte sagen,
guck mal,
hier habe ich einen so ein Problem zwischen diesen Klassen.
Das ist doch dieses Muster. Warum funktioniert das nicht?
Ja, also man hatte eine andere Sprache.
Da werde ich euch ein bisschen was zu zeigen.
Und noch eine Ebene höher sind dann Architekturstile.
Das ist also dann so das richtig Tolle,
wenn man in eine Firma kommt, die ja in Architekturstil hat,
wo man in einen so ausdifferenzierte Idee davon kommt,
wie Softwaresysteme gebaut werden können,
dass man sozusagen gleich anfangen kann zu programmieren.
Das zeige ich euch jetzt
So, das ist eine Best Practice, die ich euch sehr ans Herz legen möchte.
Es geht darum, dass wenn man irgendetwas programmiert,
eine Klasse, ein Package, eine größere Einheit,
dass man darauf achtet, dass dieses etwas nur eine Zuständigkeit hat.
Das ist eine Entwurfsphilosophie, die schon relativ alt ist,
die ist Ende der 80er Jahre entwickelt worden und es geht darum,
das steht hier so schön auf Englisch,
Objects are not just simple bundles of logic and data,
they are responsible members of an object community.
Also was das ausdrücken will, ist, wenn ihr eine Klasse baut,
guckt sie euch genau an, Was ist die Aufgabe dieser Klasse?
Es ist keine gute Idee. Also ich habe es bei mir
in mehrere Systeme von meinen Leuten angeguckt und da gibt es immer eine Klasse, die heißt Start-up.
Die ist dafür zuständig, die ganzen anderen Sachen hochzufahren.
Also ich starte da den Server und jetzt starte ich mal die Oberfläche und solche Sachen.
Und was man noch so alles im Hintergrund braucht. So,
das ist natürlich eine Klasse, die im System relativ weiß oben ist,
weil die alles kennt und startet.
So, dann hatten meine Leute das Problem,
Sie mussten irgendwo so ein paar Konstanten haben,
also die Adresse von irgendeinem Drucker oder sowas oder irgendeinem Port,
keine Ahnung was, wohin damit?
Tja, in den Service, ach nee,
der andere braucht das auch, in die Klasse,
nee, die andere braucht es auch, oh,
tu mir das doch mal in die Start-up-Klasse.
Ist doch, die gibt es ja sowieso nur einmal.
Ist doch eine gute Idee. So,
dann hat er diese Klasse auf einmal zwei Aufgaben.
Einmal, ich mache jetzt doch an diesem Bild weiter,
ihr müsst das ertragen.
Einmal war sie hier, also ich male sie ganz groß
und schreibe
ganz groß
Und ganz ordentlich, ne? Kann man lesen? Ja
. Start-up, eine Klasse, ja? Startet alles.
Hier, da und da, fährt die Datenbank hoch.
Nee, das natürlich nicht. Aber solche Sachen,
ja, alle, was man alles so braucht.
Und jetzt braucht man aber noch so ein paar Konstanten.
Und dann habe ich gesagt, haben meine Leute,
die hier reingebaut, ja? Irgendwie eine zum Beispiel,
die heißt vielleicht, oh, jetzt sieht man schon wieder nichts mehr.
Printer, ja? So. Und jetzt brauchten ganz viele hier
unten diesen Printer, ja, und haben jetzt,
benutzen jetzt alle die Klasse hier.
Ja, um sich diese Konstante zu holen
Ich weiß nicht, ob ihr das sehen könnt, aber das gibt einen Kuddelmuddel,
der benutzt die und die benutzen wieder ihn und wir haben so eine Wollmaus,
ja, und das kriegt man nie mehr auseinander, ja.
Also ich kann kaum hergehen und sagen, ich nehme jetzt
diese Schicht hier unten weg und baue da was Neues ein, das geht nicht. So,
und das liegt daran, dass die Leute gesagt haben,
dieser Start-up-Klasse zwei Aufgaben gegeben haben, zwei Zuständigkeiten,
nämlich einerseits das System hochzufahren und andererseits Ressourcen zur Verfügung zu stellen,
ja, also es ist viel, viel besser,
eine zweite Klasse zu haben die irgendwo hier unten ist,
die Resources heißt, wenn ich das dann noch richtig schreiben könnte,
und das alles hierhin zu machen, ja?
Denn hat der seine Aufgabe und der hat seine Aufgabe und
es ist kein Gemisch. Ich war mal bei einer Firma,
die hatte ein Problem mit einem Softwaresystem,
das war auch so ein Wollknäuel, ja,
und dann habe ich, dann sagte der Entwickler,
ja, gucken Sie mal,
das ist da schrecklich.
Ich habe mal
eine bessere Version gebaut
Und ich habe so ein Tool, mit dem man
sich das angucken kann. Und diese bessere Version war genauso
ein Wollknäuel. Und dann habe ich zu ihm gesagt,
gucken Sie mal, das ist aber nicht schön,
dass die sich alle so gegenseitig hier benutzen.
Und dann sagt er, ach, das mögen sie nicht.
Dann sage ich, nee, das mag ich nicht,
weil dann kriegen sie das nie mehr auseinander.
Und dann hat er gesagt, ja,
dann tue ich einfach diese Methode von hier nach da.
Ich nehme die aus der Klasse weg und tue die in die Klasse rein.
Und dann ist es doch viel besser. Und dann habe ich
so gemerkt, okay, der Mann wusste nichts davon,
dass Klassen mehr sein können als Behälter von Methoden.
Also es geht nicht darum, irgendwie so, ach,
das hat nur 20 Methoden, tue ich noch eine dazu,
nehme hier eine weg oder so.
Sondern es geht um Klassen,
die Zuständigkeiten haben
Es gibt auch für dieses Grundprinzip,
also mit dem die Softwaretechnik schon seit 30 Jahren ringt jetzt,
was ist denn mit dem Licht?
Sitzt jemand auf dem Schalter oder was ist das?
Es geht immer an und aus. Naja, es gibt noch
andere Namen darüber. Die habe ich euch hierhin getan.
Es gibt ein ganz altes Prinzip von Daikstra,
das hieß Separation of Concern. Das ist genau dasselbe.
Das ist das, was ich hier eben gemacht habe.
Was sind die Aufgaben, die müssen getrennt werden?
Modularität von dem guten Panas ist auch genau dasselbe.
Ich will Module haben, die eine Aufgabe haben.
Und dann gibt es noch so ein ganz tolles Wort,
Da wird Axel euch auch noch was Längeres zu erzählen,
aber ihr habt es dann schon mal gehört und es ist euch,
das ist immer gut, finde ich,
wenn man ein Wort schon mal gehört hat,
beim nächsten Mal ist es nicht mehr so schrecklich.
Wisst ihr, was, was die Kursion eigentlich ist in der Physik?
Nee. Dass so Wassertropfen tatsächlich als Tropfen zum Beispiel auf
so einem Blatt zusammenbleiben und nicht blubb, der Zusammenhalt von etwas.
Dass die Wasseroberfläche sich zum Beispiel über einem Glas so herausdehnt.
Ja, das ist Kohäsion. Und das will man eben
auch haben. Man will den Zusammenhalt der Klassen stärken.
Das bedeutet Kohäsion, ja. Wie sehr gehört
eine Klasse zusammen
Woher rennt ist sie? Vielleicht habt ihr das mal gehört,
so einen Satz, ja? Wie kohärent ist etwas?
Wie sehr gehört es zusammen? Ja,
und das hat direkt was mit diesen Aufgaben zu tun,
denn diese beiden Jobs hier, die gehören ganz sicherlich nicht zusammen.
Ja, man wird also dann in der Klasse einen Teil von Methoden haben,
die sich mit irgendwelchen Exemplarverjammeln beschäftigen und einen anderen Teil von Methoden,
die sich mit anderen Exemplarvariablen beschäftigen.
Und schon hat man eine Klasse, die keine Kohäsion hat,
die nicht eine Zuständigkeit hat.
Über Robert Martin werde ich euch nächste Woche noch was erzählen,
der hat eine ganze Reihe sehr hübsche Prinzipien aufgeschrieben und eins davon ist das Single Responsibility Principle.
Und das geht genau in dieselbe Richtung.
Ich will eine Verantwortung pro Klasse haben
Also wenn, ich könnte ja anstatt der Klausur am Ende des Semesters
mir all die Softwaresysteme angucken, die ihr gebaut habt.
Bis zum Ende des Semesters. Und dann kann ich ja
mal gucken, ob ihr diese Prinzipien eingehalten habt.
Und okay, es war nur so eine Idee.
Geht natürlich nicht. Gut. In eine ähnliche Richtung geht
diese Best Practice. Man soll keine großen Einheiten bauen.
Es gibt in der Softwaretechnik so etwas, wo man,
ich weiß nicht, ob euch das schon mal untergekommen ist,
dass ihr ein Softwaresystem angeguckt habt und gedacht habt, Das ist komisch.
Das nennt man einen Bad Smell. Also das sieht
irgendwie nicht gut aus. So vom Gefühl her,
wenn man ein bisschen programmiert, dann guckt man auf irgendwann und denkt,
ich habe euch zum Teil von unserem Software-Technik-Praktikum erzählt,
was wir im Sommer machen, wo wir auch so agil arbeiten.
Und da kriegen die Leute am Anfang ein kaputtes System und müssen
sich das mal so angucken und müssen sich dem nähern.
Also es gibt einen Bad Smell God Class. Das heißt,
dass man in seinem System irgendwo eine Klasse hat,
die jeden kennt, die alles macht, die alles beherrscht.
Das solltet ihr bitte vermeiden. Wenn ihr auf so
ein System stoßt, dann werdet ihr feststellen,
das ist eigentlich gar kein objektorientiertes System
Sondern das ist eins nach der strukturierten Programmierung. Wir starten
Main und von Main wird dann dieses aufgerufen und dann dieses.
Es ist aber nichts, wo Objekte miteinander interagieren, wirklich.
Der hat den Effekt, dass Methoden über mehrere Bildschirmseiten gehen,
Klassen sind riesig groß.
Ich zeige euch mal eine Auswertung dazu. Man kann sich
also Softwaresysteme daraufhin angucken, wie die Größenverteilung ist.
Ich weiß, dass es unscharf ist und vielleicht schlecht
zu lesen, ich erkläre euch,
was das ist
Dieses hier ist ein Diagramm, in dem man sieht,
wie viele Zeilen Code in den einzelnen Klassen sind.
Ja, da steht jetzt Lines of Code pro File.
Ja, aber in Java ist ja ein Pfeil immer eine Klasse.
Und was man da sieht, ist hier die Größe,
ja, also es gibt Klassen, die haben null Zeilen,
da gibt es zwölf Stück, dann gibt es ganz viele,
die sind so bis zu 400 Zeilen groß.
Und hier ist so eine Grenze, ne, eine Grenze von tausend Zeilen.
Und dieses Tool, mit dem ich das ausgewertet habe,
das sagt, tausend Zeilen sind okay. Ja,
tausend Zeilen kann eine Klasse haben, was größer ist,
ist nicht gut und was kleiner ist, ist okay.
Ja, und hier gibt es noch so ein paar
ganz kleine Böbbel und ein paar Zahlen.
Hier gibt es also so ein paar Klassen,
die sind größer
Dieses System, von dem diese Auswertung stammt,
ist ein gutes System. Und das freut mich auch,
wenn ich Software entwickle und sowas zeigen kann,
weil ich kann Ihnen sagen, guck mal,
so viel ist innerhalb der typischen Grenzen.
Ihr habt echt gut gearbeitet. Ihr habt eine
tolle Zerlegung gemacht. Ihr habt euer System klein zerlegt.
Es gibt nur so ein paar böse Dinge hier.
Und nur die gucken wir uns jetzt an.
Also welche vier Klassen sind hier so groß.
Diese Auswertung hier zeigt, wie viele Methoden,
wie viele Zeilen Code in den Methoden sind.
Auch das, das ist wirklich gut gelungen.
Da ist die Grenze bei 100 Zeilen. Also Methoden,
die länger als 100 Zeilen sind,
sind einfach zu groß.
Und das hier rechts ist ganz hübsch.
Das ist die zyklomatische Komplexität. Das ist ein Maß,
das misst, wie viel Pfade es durch eine Methode gibt.
Ja, also ihr kennt ja schon If, Zen,
Els, Case Statements, solche Sachen.
Und damit kann man ja unglaubliche Verwurstelungen, Ungetüme bauen.
Und diese Metrik misst also, wie viel Pfade es durch
eine Methode gibt und sagt, also zehn ist okay.
Wenn eine Methode eine zyklomatische Komplexität von zehn hat,
wie viele Testfälle muss ich denn
dann programmieren
Das war jetzt mal eine schwere Frage, oder?
Unser Filmemacher sagt zehn, genau. Ich muss genauso
viele Testfälle bauen, wie ich Pfade habe, ja.
Ich war mal in einer Bank, die hatte eine Methode,
die hatte eine zyklomatische Komplexität von 637.
Das fand ich hübsch. Das Ding hat geprüft,
ob die Kontonummer, die man eingegeben hat, zur Bankleitzahl passt.
Es gibt nämlich bestimmte Nummernkreise, Logiken darüber,
wie Kontonummern von irgendwelchen Banken aussehen müssen. Also wenn ihr
bei einer ganz neuen Bank ein Konto eröffnet und dann versucht,
bei Amazon was zu kaufen, dann kann es sein,
dass Amazon ein System zu euch sagt, kann irgendwas nicht stimmen.
Das passt nicht zusammen. Weil möglicherweise diese Logik
noch nicht angepasst ist, das zu berechnen.
Also, was ich euch damit eigentlich sagen will,
ist, seht zu, dass euer System ausgewogen ist.
Dass nicht irgendwas ganz Großes und alles andere ganz klein oder sowas.
Sondern dass ihr eine Ausgewogenheit in eurem System habt.
Jetzt haben wir eben immer über die Elemente gesprochen.
Ihr erinnert euch über die Klassen. Es gab ja auch in
der Architektur noch das andere, die Beziehung zwischen den Dingern.
Und wenn man sich um die kümmert,
dann redet man über den Kopplungsgrad,
den man in einem System hat
Wenn ihr euch vorstellt, ihr müsst eine Klasse ändern,
die wiederum von 100 Klassen benutzt wird und selbst 50 andere kennt,
dann ist der Kontext ziemlich groß,
um den ihr euch kümmern müsst.
Und das ist anstrengend. Denn auch all diese Tests müssen
angepasst werden und so. Also ich hoffe,
ihr geht hier nicht weg, ohne für euer Leben gelernt zu haben,
dass ihr Tests schreiben müsst.
Müsst ihr schon Tests schreiben? Und ist das doof oder gut?
Naja, bei den kleinen Teilen ist das vielleicht noch nicht so doof.
Aber sobald man mit einem größeren System zu tun hat,
ist es herrlich.
Es ist herrlich
Ihr könnt in eurem Kopf, wenn ihr gut seid,
30.000 Lines of Code, könnt ihr euch,
könnt ihr euch merken, was die tun.
Aber das ist schon eine sehr hohe Grenze.
30.000 Lines of Code, wenn jede Klasse 1.000 Zeilen hat,
sind das ungefähr 30 Klassen. Kann man schnell ausrechnen.
Mehr könnt ihr euch nicht merken. Das heißt,
wenn das System größer ist und ihr etwas ändert,
wisst ihr nicht, was ihr getan habt.
Ihr wisst nicht, welche Auswirkungen das habt. Und ich habe,
also als ich das erste Mal ein System hätte,
was zu 80 Prozent abgetestet war, es war so gut.
Man konnte nachts schlafen, man wusste,
es ruft einen keiner an, man wusste,
man kommt am nächsten Tag wieder und jemand anders hat was
gemacht und das System funktioniert immer noch
Herrlich. Ich kann es euch nur empfehlen. Die Erfahrung ist
wirklich gut. Und die andere ist auch nicht schlecht,
dass man mal so ein anderes System an der Backe hatte.
Gut, hier geht es jetzt darum, einerseits zu sagen,
okay, ich will eine Zuständigkeit pro Einheit, die ich mache.
Ich will ausgewogene Größen haben und ich will auch bei
der Kopplung zwischen diesen Einheiten einen Ausgewogenheit haben. Ja,
ich will nicht, dass irgendwo in meinem System eine Klasse existiert,
die jeder kennt und die wir rum alle kennt.
Ja, das ist nämlich dann ein sogenannter Bottleneck.
Kann man auch messen, solche Sachen natürlich.
Und ich habe euch hier noch eine Auswertung mitgebracht.
Das war total spannend. Die habe ich für meine Doktorarbeit gemacht.
Da habe ich mir 24 Systeme angeguckt, in unterschiedlicher Größe.
Hier unten ist immer die Größe der Systeme aufgetragen.
Das hier ist das System von der Technikerkrankenkasse. Das,
was hier aufgeschrieben sind, sind die Reel,
also die Relevant Lines of Code.
Also nur der Teil vom Source, der wirklich ausgeführt wird.
Also keine Kommentarzeilen, keine Leerzahlen. Deswegen ist die Zahl
nicht vier Millionen. Deswegen steht da nur 1,4 Millionen.
Das ist die Technikerkrankenkasse, das ist das Eclipse-System.
Oh, das ist eine von irgendeinem Projektpartner, den wir haben.
Ich weiß es nicht. Also kleinere, größere. So,
und dann habe ich mal gerechnet und habe versucht auszurechnen,
was ist die durchschnittliche Anzahl an Zeilen pro Klasse
Und ich hatte gedacht, dass große Systeme größere Klassen haben.
Aber das, was ihr seht, ist nicht der Fall.
Dieses Thema hatten alle durchschnittlich 50 Zeilen Code pro Klasse,
was auch realistisch ist, wenn bei Hunden,
also vorhin hatten wir das mit 100,
also das sind nur die Relevanten.
Also ungefähr so groß, manche ein bisschen größer.
Und es gab zwei Systeme, die sind hier oben gewesen.
Ja, die hatten also riesige, große Klassen.
Und dann habe ich die Anzahl der Beziehungen pro Klasse gemessen.
Und wie ihr seht, haben die meisten Klassen so um die zehn Beziehungen.
Das ist sozusagen hier so oben zehn, elf Beziehungen.
Und diese zwei Systeme, die schon so große Klassen hatten,
die hatten auch ganz viele Beziehungen
Das hat mich gewundert, ehrlich gesagt. Ich habe gedacht,
ja, wenn man was größer macht, stopft man da
alles rein und da muss man ja auch mit weniger anderen was zu tun haben.
Aber das stimmte nicht, weil,
und was dadurch für mich ganz offensichtlich wurde, war,
die Leute haben hier kein objektorientiertes System gebaut, ja,
sondern sowas mit so einer Godclass, die eben jeden kennen muss,
so groß sie auch sein mag oder so groß die anderen sind,
die muss alle kennen, ja.
Das heißt, wenn ihr anfangt, große Klassen zu bauen,
dann wird das wahrscheinlich dazu führen,
dass wir auch ganz viel Kopplung in eurem System hat.
Also lasst das lieber gleich bleiben, ja,
und achtet auf solche Sachen
So, dann habe ich euch noch ein paar Worte zu Entwurfsmustern versprochen.
Ich habe ja eben schon die groß angepriesen. Das war
1995 wirklich beeindruckend, dass jemand auf diese Idee kam.
Und das hat natürlich auch seine Entsprechung in der Architektur.
Ja, auch da gibt es typische Muster,
die man immer wieder findet. Es gibt zum Beispiel
wie hier in diesem Bild immer wieder Rosetten in Kirchen.
Es gibt bestimmte Arten von Türmen,
die auf bestimmte Art und Weise
immer wieder gebaut sind
Ja, also was Tunentwurfsmuster eigentlich, das sind Lösungen,
bewährte Lösungen für typische Probleme.
Ja, und ich kann euch nur empfehlen,
wenn ihr in irgendeine Firma kommt und die macht zum Beispiel Kommunikationssoftware,
irgendwas für Telekommunikation. Dann sucht nach einem Buch,
es gibt garantiert ein Buch mit Entwurfsmustern für Telekommunikationssysteme.
Ja, und lest euch das durch. Oder wenn ihr
in eine Bank kommt, dann braucht ihr einen Entwurfsmuster für Oberflächensysteme.
Ja, es gibt Bücher immer zu all diesen Sachen.
Steht das nicht in eurem Ausdruck, doch es steht in
eurem Ausdruck.
Ich zeige euch ein Muster, das haben wir letzte Woche
schon in unserem Beispiel gehabt. Ihr braucht euch jetzt nicht
merken, welche Arten von Entwurfsmustern es gibt und so.
Das ist nicht wichtig. Ich will euch nur eins zeigen
und Axel wird euch dann nächste Woche noch mehr zeigen.
Klick. Das ist das Entwurfsmuster Fassade. Ich weiß nicht,
ob ihr euch noch erinnert, wie wir letzte Woche das Klassendiagramm gemalt haben von den Systemen,
was wir hatten, aber das kam dabei raus.
Es gibt oben ein Paket, in dem diese beiden Oberflächen sind,
der Word-Prozessor, wenn ihr euch erinnert,
wo wir die Worte eingegeben haben und der Administrator,
wo das Dictionary nachher drin war und es gab hier unten so ein paar Klassen,
die das alles verarbeitet haben und eine Klasse,
he his belling for said, die wir da hatten.
Jetzt halt in diesem Bild heißt sie nur for said.
Das ist ein Entwurfsmuster, mit dem man versucht,
ein Teil eines Systems durch so eine Fassade,
durch so eine Klasse abzuschotten gegen den Rest.
Sodass man jetzt hier noch weitere Systeme draufsetzen kann,
die auch alle über die Fassade arbeiten.
Und wenn ihr also ein Buch lest,
in dem dieses Entwurfen uns da beschrieben wird, ja?
Ja, das kann man natürlich so sehen.
Das ist ein guter Punkt. Das könnte man so sehen
. Was sage ich jetzt dazu
Oh, aber der verrate ich nicht. Er hat gesagt,
ob das nicht zufällig ein Bottleneck wäre, was man da jetzt hat.
Ob die Fassade nicht ein Bottleneck wäre, ist ja auch eine sehr schlaue Bemerkung,
weil ich euch vorher gesagt habe, ihr sollt keine Bottlenecks schreiben.
Also der Punkt ist, aus meiner Sicht,
dass dieses Bottleneck sich natürlich eigentlich auf das gesamte System bezieht.
Und dieses mit der Fassade ist so gedacht,
ich habe mehrere Subsysteme und jedes hat seine eigene Fassade.
Dann wird das nicht so ganz so bottleneckig, aber so
ein bisschen vielleicht. Aber dass man Schnittstellen für Systemteile hat,
die dann die Funktionalität zur Verfügung stellen,
wird durch dieses Muster hier noch ein bisschen verstärkt und ist eine wichtige Sache.
Ja, weil sonst greift nachher jeder in jeden Teil in dieses System rein.
Ja, und das will ich verhindern durch so eine Fassade.
Das führt uns direkt zu den Vorteilen von so einer Fassade.
Also die Idee dahinter, also was die Leute auch schreiben,
die diese Muster ausarbeiten, ist, dass sie sagen,
wenn man so etwas tut, wenn man Fassaden für einzelne Subsystemteile schreibt,
dann verringert man die Komplexität.
Weil jemand, der dieses Subsystem benutzen will,
muss sich nur mit der Fassade beschäftigen.
Der muss also nicht die ganzen Teile innen drin verstehen,
wie sie zusammenarbeiten, sondern der kann Dienste benutzen,
die in dieser Fassade spezifiziert sind.
Das ist gut.
Das verringert die Komplexität
Man braucht weniger Objekte zu handhaben, man braucht mit weniger zu kommunizieren.
Und die Kopplung ist natürlich auch loser dadurch. Also jemand
könnte herkommen in diesem Beispiel hier und den Word-Prozessor würde es
nichts stören, wenn wir hier unten Sachen austauschen würden.
Ja, der würde immer noch mit seiner Fassade kommunizieren.
Ich müsste ihm keine neuen Klassen bekannt machen,
all diese Dinge brauche ich nicht tun.
Die ich tun müsste, wenn er die alle direkt benutzt.
Gut, also man kann Sachen verstecken und verbergen dadurch.
Und deswegen ist dieses Muster gut. Wenn ihr so ein Musterbuch in die Hand kriegt,
dann werdet ihr sehen, das Ding hat immer einen Namen,
es hat immer eine Beschreibung, es hat immer irgendeine Struktur,
es sind Beispiele dabei, Vorteile, Nachteile.
Da kann man
eine Menge von lernen
Ja. So, und das, was eine Ebene höher
im Verhältnis zur Architektur, zu Entwurfsmustern steht, sind die Architekturstile.
Ja, das kann man auch direkt aus dem Bauwesen übernehmen,
dass man also feststellt, es gibt gleichartige Bauten.
Ja, es gibt gotische Kathedralen oder es gibt romanische Kathedralen
oder noch irgendwelche anderen Kathedralen, moderne vielleicht.
Ja, also man hat sozusagen für den Gesamtaufbau eines Softwaresystems
Regeln festgelegt,
wie das aussehen soll
Und das ist die hohe Kunst, dass man tatsächlich einen Architekturstil hat,
den man für sein gesamtes Software-System anwenden kann, nicht nur für einen Teil.
Und das ist auch die Unterscheidung zu einem Entwurfsmuster. Ein Entwurfsmuster,
das ist immer so ein kleiner Teil,
also so vier, fünf, sechs Klassen,
wie die zusammenarbeiten und ein Architekturstil bezieht sich immer auf das gesamte System und nicht nur auf Teile.
Die sind häufig domänenspezifisch, das bildet sich auch zum Teil heraus. Ich habe also auch viele,
es gibt ein paar in der Literatur bestriebene Architekturstile,
es gibt aber auch ganz viele Firmen, die haben einen hausinternen Architekturstil,
wo sie neue Leute erstmal die erstmal schulen,
damit sie verstehen, wie die Systeme da gebaut werden.
Und dann kann man an den Systemen weiterarbeiten.
Das ist unheimlich hilfreich, weil die neuen Entwickler sich dann
eigentlich nur noch um das Verständnis der Fachlichkeit kümmern müssen.
Also wenn man verstanden hat,
was für ein Architekturstil da eingesetzt wird in einem System,
dann braucht man nur noch verstehen, nur noch in Anführungsstrichen,
wie das hier eigentlich funktioniert mit diesen Containern.
Das ist kompliziert genug oder wie das da funktioniert mit
den Paketen oder was auch immer.
Also eine Architekturstil ist eine prinzipielle Lösungsstruktur,
die für ein gesamtes Softwaresystem durchgängig und unter weitgehendem Verzicht auf Ausnahmen
angewendet werden sollte
Ganz, ganz, ganz einfaches Beispiel eines Architekturstils wäre,
dass man sagt, es gibt kleinen Serverarchitekturen. Ja,
das kann man auch als, jedenfalls, wir kehren zurück zum Thema kleinen Serverarchitektur,
ist ein Architekturstil, ja, den ihr bestimmt in eurem Leben immer wieder begegnen werdet.
Die Idee ist einfach nur, ich habe eine Klasse,
ein Package, eine Komponente, ein Modul,
etwas, was ein Server ist und was Dienste anbietet,
ja, wenn es ein Package wäre,
dann könnte das zum Beispiel eine Fassade haben, ne,
nur um das nochmal wieder aufzugreifen,
die dann bestimmte Methoden anbietet, ja,
bestimmte Dienste,
sagt man dann auch,
die können andere verwenden
Und der Client ist derjenige, der das dann verwendet.
Und der Punkt dabei ist,
dass der Client den benutzt und nicht andersrum, ja?
Also das ist sozusagen das Stilhafte daran.
Man hat zwei Elemente und man hat eine,
man hat festgelegt, dass Beziehungen nur in der Einrichtung gehen.
In der Regel geht das über irgendein Netzwerk oder sowas,
ja, über irgendein Protokoll, dass der Client bei dem Server sich irgendwelche Dienste anfordert.
Und das kann eben auch über JMS-Nachrichten,
also über Nachrichten, über irgendeine Technologie funktionieren.
Das muss kein direkter Aufruf sein
Was macht so ein Architekturstil? So ein Architekturstil, der gibt euch,
gibt einem eigentlich einen Vokabular an die Hand, ja,
dass man weiß, welche Arten von Elementen gibt es,
ja, eben hatten wir zwei Arten von Elementen.
Es gibt Client-Elemente und Server-Elemente, ja, die haben auch einen Namen.
Ich nenne die natürlich dann für mein System,
was ich baue, meinetwegen Kontonummern-Server, ja,
und der Client ist vielleicht ein Zahlungs- oder ein Kontoeröffnungswerkzeug,
irgendwas in der Art, ja,
aber ich kann die Elemente benennen und es gibt eine semantische Anreicherung,
also was ist die Bedeutung hier,
ja,
die Bedeutung ist hier,
dass der eine den anderen verwendet und
dieser Dienste zur Verfügung stellt
Und es gibt Regeln dafür, wie die sich benutzen oder gegebenenfalls auch mit Vererbung arbeiten.
Und es gibt also verschiedene Regeln darüber, wer wen benutzen darf,
wie sich, wie diese Elemente miteinander verknüpft sind, wie ihre Zusammenarbeit ist.
Und ich zeige euch jetzt einen Architekturstil,
den wir hier in der Uni Hamburg entwickelt haben und der sich,
den man auch so nennen kann.
Den werdet ihr auch in eurem Projekt kennenlernen, auf eine,
auf die eine oder andere Art. Wenn ihr nach einem Architekturstil baut,
den wir hier in Hamburg entwickelt haben, der Werkzeug und Material heißt,
dann werdet ihr in eurem System Klassen entdecken,
die man als Fachwerte bezeichnet, die man als Materialien bezeichnet,
als Services und als Werkzeug.
Ja? Also, ihr baut irgendwelche Klassen und man könnte sagen,
okay, was ist das für eine Art von Klasse?
Das ist ein Material. Und dieses hier ist ein Service
und dieses hier ist ein Fachwert. Fachwerte habt ihr vielleicht auch
schon mal gebaut. Kleine Einheiten, die irgendeinen Typ darstellen,
also zum Beispiel eine Kontonummer könnte einfach wert sein.
Ja, Kontonummer, habt ihr vielleicht irgendwas Vergleichbares schon mal gebaut?
Ja, Benutzernummer könnte ein Fachwert sein.
Geldbetrag könnte ein Fachwert sein, ja
Und ein Material könnte sein, der Kunde oder das Konto,
ja, Sparkonto, Girokonto, irgendwie sowas.
Und ein Service ist so etwas Diensthaftes, ja,
ein Kontonummernservice, ein Konto, Verwaltungsservice, ein Kreditservice,
was auch immer man so braucht.
Und das Werkzeug ist das, womit die Leute arbeiten an der Oberfläche,
ja, was sie verwenden, um ihre Arbeit zu machen.
Also zum Beispiel ein Kontowerkzeug zum neuen,
oder wenn ihr Online-Bankig-Banking macht, das,
was ihr da an der Oberfläche habt und um eure Überweisungen auszufüllen oder so,
das sind Werkzeuge.
Und die sind dann nochmal untergliedert, aber das ist nicht
so wichtig
Ja, aber was so ein Architekturstil macht, ist,
ergibt euch vor, was für Klassenkategorien ihr haben werdet nachher in eurem System.
Und da schließt sich auch nochmal der Kreis zu diesem Beispiel hier.
Ich habe euch vorhin von diesem Start-up und Ressourcen-Thema erzählt,
ne? Das ist aufgefallen in einem System,
was die Leute nach diesem Architekturstil gebaut hatten.
Wenn man so einen Architekturstil hat und die Leute damit bauen,
dann muss man sich in der Regel die Klassen gar nicht angucken,
die in die Kategorien passen, sondern die, die nicht reinpassen.
Das Start-up-Ding passt nämlich nicht in diese Kategorisierung.
Das ist sozusagen über
Das passt zu keiner Kategorie. Und in der Regel verursachen
diese Klassen Probleme. Wenn ihr mal in ein größeres System guckt,
dann werdet ihr garantiert immer irgendwo einen Teilbereich finden, der Youtil heißt.
Utilities. Da tun die Leute immer alles rein,
wo sie nicht wissen, wo es hingehört.
Das heißt, wenn man sich die Architektur anguckt,
dann sieht das immer da wie Kraut und Rüben aus.
Oder die Leute haben Klassen gebaut, die heißen,
hümm, hümm, hümm, Manager.
Das ist auch ganz beliebt. Manager sind auch irgendwie Sachen,
wo keiner weiß, was die eigentlich sollen.
Die muss man sich auch immer genau angucken.
Das hat natürlich nichts mit den echten Managern zu tun.
Aber nein
Okay. Damit kommen wir zum Ende, zusammenfassend.
Was habt ihr heute gelernt? Was sollt ihr mitnehmen?
Ihr sollt wissen, dass es sich bei Architektur um Elemente,
ihre Beziehung und ihre externen Eigenschaften handelt. Ihr sollt mitnehmen,
dass es verschiedene Sichten auf Architektur gibt, auf Softwaresysteme.
Und ihr solltet so ein bisschen im Hinterkopf behalten,
aha, sie hat uns schon mal gesagt,
es gibt Architekturstile, es gibt Entwurfsmuster,
es gibt Best Practices.
Okay,
schönes Wochenende