Okay, willkommen zurück zur Einführung in das Software Engineering. Was vielleicht toll wäre,

wäre wenn wir hier hinten die Türen zumachen könnten, weil es kommen doch relativ viele

Störgeräusche aus dem Raum vor der Vorlesungssaal. Das wäre echt super. Und dann können wir uns

voll und ganz auf Software Engineering konzentrieren. Dankeschön. Und unser Thema heute wird das Design,

das architektonische Design von Software und wir werden uns quasi einige Entwurfsmuster,

einige Prototypen angucken, wie man Software designen kann und welche typischen Konzepte es gibt. Und ich

denke, dass Sie viele davon schon mal gesehen haben, tatsächlich wahrscheinlich auch benutzt.

Und wir gucken uns an, wie kann man verschiedene Systeme aufeinander aufbauen lassen, welche

Ansätze kann man wählen, um große Software-Systeme in Abstimmung zu bringen und quasi von Grund auf

zu entwickeln. Also letzten Endes ist das die grundlegende Organisation eines Systems,

in dem sich die Komponenten, Beziehungen und die Umwelt ja quasi finden lassen. Und wir werden uns

Prinzipien angucken, wie die das Design und die Evolution von solchen Entwürfen uns quasi

voranbringen. Die Softwarearchitektur ist quasi das Grundgerüst und wenn wir uns für einen

bestimmten architektonischen Entwurf entscheiden, dann kann es uns quasi helfen, uns leichter

zurechtzufinden, auch die Ideen dieser Architektur anderen zu kommunizieren. Und dazu gehört im

Wesentlichen, dass man ein System in seine Komponenten zerlegt und diese Komponenten dann quasi

später in einem weiteren Fortschritt definieren kann. Und dann sollen natürlich auch alle dynamischen

Teile und Interaktionen der Komponenten definiert werden. Und ja letzten Endes braucht man auch eine

gewisse Strategie der Architektur. Das bezieht sich dann darauf, wie die Architektur entwickelt und

angepasst wird. Und wir wissen ja, dass sich Architektur-Entwürfe, die kann man am Anfang

festlegen, aber eventuell ändert sich was ja auch an unseren Anforderungen. Und deswegen sollten wir

bei der Architektur schon darauf achten, dass wir flexibel auf Neuerungen entsprechend eingehen

können. Und ja, also das sind so die grundlegenden Konzepte, die wir für die Softwarearchitektur

im Hintergrund haben sollten. Und ja, tatsächlich wollen wir natürlich nicht nur uns verschiedene

Architekturkonzepte heute angucken, sondern wir wollen natürlich damit auch genau die Anforderungen

erfüllen, die mit denen wir uns jetzt schon beschäftigt haben. Wir haben uns ja vorher mit

der Anforderungsanalyse schon überlegt, wie man prinzipiell herausfinden kann, was soll das System

tun können. Wir haben uns angeguckt, wie wir beschreiben können auf abstrakter Ebene, wie

Interaktionen aussehen sollen. Und wir haben uns auch schon angeschaut, wie man quasi so Softwareentwurf

kommunizieren kann. Wir hatten uns in der letzten Einheit ja auch sehr dediziert mit UML und

Klassendiagramm auseinandergesetzt. Und letzten Endes sollen in der Softwarearchitektur dann genau

diese funktionalen und nicht funktionalen Anforderungen erfüllt werden können. Und das

soll mir quasi eine Blaupause liefern für die Systemimplementierung. Und was eben auch

spannend daran ist, ist, dass wenn ich diese Blaupause habe, dann kann ich quasi typischerweise

kennen die Leute auch diese verschiedenen Ansätze, wie man Softwarestrukturieren kann. Und wenn

man die dann entsprechend definiert, dann fällt es Leuten auch einfacher, die eigentlichen

Klassen dann zu implementieren, weil sie es grundverstanden haben, wie das Ganze verwendet

werden kann. Natürlich eine gute Softwarearchitektur. Wir können natürlich bei null anfangen und sagen,

wir machen das alles komplett neu. Aber wir werden jetzt hier in dieser Lehr-Einheit sehen,

es gibt ein paar sehr gute Muster dafür. Und häufig können wir auf Basis von so einem Muster

anfangen, das eben besonders gut zu dem Problem passt, an dem wir, für das wir Software entwickeln

wollen. Und dann das Muster weiter spezifizieren. Und wenn wir uns die angeguckt haben, werden wir

auch immer die Vor- und Nachteile von diesen Mustern uns überlegen, damit wir quasi schon an

einem frühen Zeitpunkt uns quasi überlegen können, was kann denn schiefgehen. Wie wahrscheinlich ist es,

dass es schiefgeht. Und was sind denn so die größten Probleme. Das heißt, wir können quasi schon

frühzeitig Risiko und Management und damit eben auch Kostenreduzierung erreichen. Natürlich können

wir auch mehrere dieser Muster, die wir jetzt sehen werden, verwenden. Also man muss sich nicht

für eins entscheiden und sagen, das ist alles so. Sondern es können natürlich wieder aus

verschiedenen Komponenten zusammengesetzt werden. Und dafür werden wir uns das jetzt in der Folge

angucken. Tatsächlich wird die heutige Einheit so aussehen. Wir setzen uns erstmal mit den