Im dritten Abschnitt geht es um die Begriffe Entwurf und Entwurfsmuster.
Entwurf als Entwurf bezeichnen wir den Übergang vom fachlichen Modell zum technischen Modell,
vom Problemraum zum Lösungsraum. Das ist die Tätigkeit des Entwerfens,
also der Tätigkeit des Entwurfs. Dabei reichern wir das,
was wir als fachliches Modell schon entwickelt hatten,
Struktur und Verhalten durch technische Merkmale, Charakteristika an,
die notwendig sind, damit das System am Ende spielt,
damit das System realisierbar ist,
technisch realisierbar sein kann
Und dieses, dabei gehören Modelle oder Elemente des Objektorientierten Entwurfs
unbedingt mit dazu. Wir bearbeiten ja mit einem Objektorientierten Programmiersprache,
also haben wir diese Konzepte wie Klassen, wie Implementationsvererbung,
Typvererbung und solche Dinge, brauchen wir dazu.
Zusätzlich sollten wir die wesentlichen Zusammenhänge als Modelle darstellen,
zum Beispiel im Klassendiagramm oder in Verhaltensdiagrammen der UML.
Wir haben Es ist empfiehlt sich möglichst ähnliche Strukturen für Problemraum
und für Lösungsraum anzustreben. Möglichst sage ich,
weil das ist das Ideal, weil wir Änderungen haben.
Das ist der Hintergrund. Dazu,
wir beziehen uns hier auf Frage 3,
ich springe mal zurück zu der Folien mit den Fragen.
Die Frage 3, nein, Frage 4,
warum ist die Ähnlichkeit angestrebt? Das ist das,
was wir hier auf dieser Folie gerade haben,
weil wir
Änderungen immer erwarten müssen
Software muss ständig geändert werden, weil sich die reale Welt
für die Software, die Unterstützung liefert, immer ändert.
Und solche Änderungen passieren aus verschiedenen, in verschiedenen,
aufgrund verschiedener Ursachen, zum Beispiel Funktionen ändern sich, Geschäftsregeln ändern sich,
Organisationsstrukturen in Unternehmen, die werden umstrukturiert, werden zusammengelegt.
Da wird man etwas ausgegliedert, als in GmbH oder wie
auch immer. Das ändert sich. Und nicht zuletzt,
ich habe es ja aber in Klammern gestellt,
weil es das nicht das wesentlichste Punkt ist.
Auch es gibt auch technische Updates. Ja,
es gibt eine neue Version von Windows,
eine neue Version der Gui-Klassen oder so etwas
Ziel ist es, dass wir Änderungen mit geringem Aufwand durchführen.
Deswegen vereinfachen. Wir wollen den Umfang, den Aufwand für
das Realisieren solcher Änderungen vereinfachen. Und das geht sehr gut,
wenn wir eine einheitliche Struktur haben auf der technischen Lösungsseite,
wie auf der fachlichen Seite.
Also wenn es so eine richtige 1 zu 1 Entsprechung hier geben würde,
wären diese Änderungen hier mit geringem Aufwand verbunden.
Das ist die Antwort auf die Frage 4. Das ist der Grund,
warum wir versuchen, so eine Identität herzustellen, das zu erreichen.
Das versuchen ganz viele Entwurfsmethoden und die Wammbetonte Wammen,
die wir hier vorstellen,
macht das ebenso
Wenn wir uns das Entwurf von Problemraum zu Lösungsraum als Übergang vorstellen,
ja, wenn wir also mal sagen, der Problemraum,
das sind die Anforderungen, der Einsatzkontext und der Lösungsraum,
das ist das Entfertige Softwaresystem,
so wollen wir eigentlich von da nach da gehen.
Ganz so direkt geht das nicht oder es ist jedenfalls bei großen Systemen nicht möglich,
weil wir Arbeitsteilung organisieren müssen und die Arbeitsteilung muss irgendwie klar werden,
wir müssen Informationen mitgeben,
was machen denn die anderen und deswegen
ist es ganz gut,
dass über Modelle
zu tun
Analysieren den Problemraum in der realen Welt,
der erst mal bei den Anwendern da ist.
Die Leute, die das machen, Requirements, Engineering,
das hatten wir vorhin schon kurz erwähnt.
Wir analysieren, was sind objektorientierte Strukturen? Das heißt,
objektorientierte Analyse. Und wir entwickeln dabei ein Modell des Problemraums.
Das stellt erst mal alles Wesentliche aus dem tatsächlichen Problemraum dar,
die wesentlichen Zusammenhänge, zum Beispiel welche Funktionen gibt es,
welche Datenstrukturen sind da, welche Organisationsstrukturen, also Struktur und Verhalten.
Das hatten wir schon gesagt. Wir hatten schon gesagt,
welche UML-Modelle dazu geeignet sind. Und dann wollen wir daraus
Modell des Lösungsraums entwickeln und das durch Programmierung, also Programmierregeln anwenden,
Entberufsmuster anwenden, in eine technische Lösung überführen, die lauffähig ist.
Und dafür gibt es eben Entwurfsregeln, wir werden den Begriff Entwurfsmuster gleich einführen,
dass Beobachtermuster, haben sie in der letzten Vorlesung kennengelernt.
Ja, so, wir haben das,
was diese blauen Pfeile hier darstellt, ist ein Prozess,
eine Folge von Schritten, die auch so unterrichtet werden kann,
die man so nachlesen kann in einem Buch,
die natürlich verallgemeinert ist für die konkrete Situation,
muss man die Lösung vielleicht noch ein bisschen anpassen
Jedenfalls gibt es hier Entwurfsregeln. Es gibt Entwurfsmuster als Bausteine.
Hier gibt es Programmierregeln und wiederum Entwurfsmuster. Während hier ist
das eine spezielle Fachdisziplin, wo man das lernen kann.
Wann ist ein Entwurf gut? Warum ist ein Entwurf,
sollte ein Entwurf gut sein? Zunächst erst mal,
wir wollen versuchen, diese Änderungen, die immer zu erwarten sind,
diese Änderungen mit ihm geringen Aufwand durchzuführen.
Die meisten dieser Änderungen passieren während der Phase der Erwartung Erwartung auf Englisch,
der heißt der Begriff Maintenance, Wartung bezieht sich auf Tätigkeiten,
die die Änderungen vornehmen nach der Fertigstellung.
Das passiert im Wesentlichen in Form oder mit dem Ziel der Erweiterung,
mit dem Ziel der Korrekturen und mit dem Ziel der Portierung und Adaption.
Ungefähr zu einem Drittel, also ein Drittel, sind Erweiterungen,
weil die Menschen neue Anforderungen, das Softwaresystem haben.
Es gibt Korrekturen, weil noch Fehler im System sind,
das ist ein weiteres Drittel und ich passe es angegebene Umstände an,
ein neuer technisches Sachverhalte, neue Plattformen, aber auch geänderte Strukturen,
das wären oder grenzende Leistungsanforderungen, das wäre hier Portierung, Aktion.
Leider ist es so,
dass nicht die Autoren das vornehmen und deswegen sich noch erinnern,
ach, ich habe das damals so und so gemacht,
sondern meistens machen das unterschiedliche Personen und manchmal dauert das viele Jahre bis Software,
wie Software weiterentwickelt werden sollen.
Und wir hatten in Vorlesung 1 schon was darüber gesagt,
was große und kleine Systeme sind,
vielleicht erinnern sie sich und wir hatten auch was dazu gesagt
Weißt du, warum, wo die Änderungen herkommen, die
wir machen müssen? Wenn wir diese Änderungen nicht machen können,
diese wir eben hier im Kasten gesehen haben,
die in Vorlesung 1 schön erklärt wurden,
wenn wir die Änderungen nicht machen können,
können wir die Software nicht mehr verwenden.
Also wenn das Finanzamt irgendeine Form von Steuer kennzahlen möchte,
die müssen wir für jede Transaktion berechnen.
Ja, da müssen wir das tun. Wenn wir das
nicht machen können, können wir dieses Softwaresystem nicht verwenden.
Wir müssten ein Neues kaufen oder eine andere Lösung finden.
Also wir haben nicht die Wahl, diese Änderung vielleicht wegzulassen,
weil dann die Software nicht mehr
nutzbar ist
Und wir wollen deswegen Änderungen mitgeben,
weil diese Änderungen mal wiederkommen, Änderungen mit geringem Aufwand.
Und wir wollen deswegen beim Entwurf die Änderungen so gestalten,
dass sie sehr freundlich, änderungsfreundlich sind,
dass da sehr wenige Aufgaben haben, weniger auf ein Veränderungen haben.
Soweit zum Entwurf und wir machen das meistens in heutzutage
in Form iterativ, inkrementeller Schritte. Also man nähert sich
schrittweise der Fertigstellung an. Man macht für kleine Portionen,
führt man es immer wieder durch, mit dem Vorteil,
dass man jedes Mal auf Veränderungen oder neue Erkenntnisse
besser reagieren kann
Ja, wir hatten dieses 1 zu 1 schon gesagt,
ist das gleiche Bild nochmal. Ja,
aber diese 1 zu 1 Änderungen sind meistens nicht in dieser einfachen Form vorkommen,
wie sie jetzt gerade eben auf der Folie hatten,
dass es nur in der naiven Situation so ein bisschen hellow world-mäßig ist das so,
dass das fachliche Element so ganz einfach in das Technische überführt werden kann.
In der Realität haben wir auf der Seite hier wiederverwendbare Lösungen,
die schon einen ganzen Blumenstrauß von Features aufweisen
Schon ganz viel mitbringen und natürlich auch ihre eigene Struktur mitbringen.
Dazu meine ich, wie solche Sachen wie ein Guyframework oder
das wäre ein Datenbankmanagement-System verwenden oder dass wir Webservices aufrufen,
die einen Teil der Konvertierung oder Verarbeitungsaufgaben machen.
Außerdem haben wir auf der fachlichen Seite meistens keine ganz einfachen Strukturen,
sondern zum Beispiel komplexe fachliche Strukturen, Sachen, die kompliziert zusammenhängen.
Oder dass wir Anforderungen haben,
die auf ganze Systeme in Auswirkungen haben, wie Security,
das müssen sie überall im System beachten.
Wenn wir große Transaktionen haben, gehen die meistens mal über
viele fachliche Objekte hinweg. Oder sowas wie Ando-Funktion,
die möchte ich auch quer über das ganze System haben
Häufig haben wir auch, was es zusätzlich zu Komplexität führt,
Verknüpfung mit weiteren Software-Systemen, mit denen eine Zusammenarbeit notwendig ist.
Und zum dritten müssen wir noch sagen, ja,
es gibt auch historische Veränderungen, wie man das macht,
wie man neue Architekturen spielen eine Rolle.
Manchmal hat man auch einfach unter Zeitdruck,
wenn ich das nicht so ordentlich gemacht,
gewachsene Strukturen umschreibe das so ein bisschen.
Ja, also da können auch durchaus Sachen sein,
die wir eigentlich nicht wollen, wie Modularität es verletzt wird.
Und wir haben
enge Kopplungen oder Copy-Paste-Entwicklungen hat zu Clones geführt
Und es kommt darauf an, diese Komplexität der Realität,
die nicht so einfach eins zu eins ist, dass wir die beherrschen,
dass wir möglichst gut an dieses eins zu eins der fachlichen,
dieser fachlich technischen Mapping rankommen, was uns helfen soll.
Bei diesem Übergang von Problemraum zu Lösungsraum, wo wir den Entwurf einsetzen,
Entwurfsprinzipien einsetzen, haben wir auch die Möglichkeit, Entwurfsmuster einzusetzen.
Entwurfsmuster hatten wir in der letzten Vorlesung schon eins kennengelernt,
das Entwurfsmuster, Beobachter, vorher haben sie schon über das MVC-Medalview Controller gesprochen,
in dieser Veranstaltung zunächst jetzt erstmal,
jetzt sprechen wir nur noch über, nicht mehr konkret,
über das Beobachter muss man wie letztes Mal,
da schauen Sie bitte ruhig nochmal nach,
sondern wir sprechen jetzt darüber, was sind Muster allgemein.
Muster sind Abstraktionen, die wiederholt auftreten, in einem bestimmten,
nicht willkürlichen Kontext. Und es ist eine Lösung,
eine Lösung to a recording problem, zu einem Problem,
was immer wieder auftritt. Und es ist allgemein,
es ist abstrakt, es ist nicht ganz konkret,
ja, es gibt immer verschiedene Möglichkeiten,
so ein Muster,
sein Wurfsmuster zu implementieren
Ja, zu begriffen, Entwurfsmuster hat die englische Übersetzung Designpattern,
das ist diese technische Lösung.
Architekturstil ist da eigentlich auch sowas ähnliches wie ein Entwurfsmuster,
aber nur vom Einsatz her eine Ebene höher,
nämlich systemübergreifend wird das eingesetzt.
Eine Heuristik ist eine Ebene tiefer, etwas kleineres ist eine Herangehensweise.
Heureka, ich habe es gefunden,
wird Archimetes zubesprochen als Ausdruck,
daher kommt das Wort Heuristik,
es geht um Lösungsfindung
Ja, und hier steht vor allem das Vorgehen im Vordergrund.
In wo ist Prinzipien, hätten wir schon gesagt, werden auch in solchen Mustern mit verarbeitet.
Das sind Regeln für gute Lösungen, also Best-Practice zum Beispiel. Ja,
und dann haben wir manchmal wiederverwendbare Bausteine, also Dinge,
die wir nun kaufen können oder gar benutzen,
weil sie in so einer eigenen Firma entstanden sind,
wo die Implementierung schon vorhanden ist und ein weiterer Begriff,
der noch manchmal vorkommt, wenn das hier Design Pattern ist,
gibt es auch Pattern Languages, da sagt man,
das ist aber nicht irgendwie eine Fremdsprache,
sondern das ist die Menge aller Vokabeln,
damit die Menge aller Muster,
die wir hier vorhaben
Dieser Begriff, Entwurfsmuster stammt aus Architekt, aus der Architektur von Gebäuden.
Christoph Alexander war ein Architekt, der, hier sehen Sie die Jahreszahl,
1979, also schon eine ganze Reihe von Jahren her,
der wiederkehrende Lösungen beobachtet hat beim Bau von Gebäude,
wo Gebäuden, die dann gut bei Menschen ankommen.
Ja, und er hat das versucht zu sammeln,
solche Muster zu sammeln und irgendwann ist ein Informatiker draufgestoßen und sagt,
ja,
sowas primär auch gebrauchen und hat diese eben mit Sachen
populär gemacht und es gab eine richtige Welle,
als ganz viele Entwurfsmuster
entwickelt worden sind
Was ist so ein Entwurfsmuster? It's pattern,
this cribes a problem with it, which a curse,
over and over again in our environment.
Also ein wiederholt auftretendes Problem, ja. And then discribes
a core of the solution, to that problem.
Also der Kern der Lösung. Damit heißt es schon,
es sind nicht alle Details dabei.
Es ist nur der Kern. In such a way,
that you can use it, this stilution,
in medientimes over with out ever doing the same twice.
Also man hat ganz viele Möglichkeiten,
so eine Implementierung vorzunehmen
Und er schreibt auch, wie das aufzuschreiben, es gibt da auch Empfehlungen.
Er sagt, das ist eine dreiteilige Beschreibung,
ein DCs Umfeld, die Problemstellung und die Lösung.
Was haben die Informatiker draus gemacht? Sie haben noch mehr
als solche drei Teile. Und zwar haben sie
das als strukturierten Text so eine Beschreibung eingeführt.
Das ist die Standardbeschreibung von Entwurfsmustern, wo der Name drinsteht.
Das Problem, das gelöst werden soll, der Kontext,
in dem das Problem erwartet werden soll und die Lösung bzw.
deren Eigenschaften
Ja, man kann also sagen, ja,
im ersten Teil wird die Ziele und Motivation beschrieben.
Im zweiten Teil, wie arbeitet das korrekt?
Also wer ist alles beteiligt, was für Strukturen existieren da
und da unten die Konsequenzen der Anwendbarkeit, also positiv und negativ.
Das beantwortet hier gleich die Frage 5. Ich springe nochmal zurück
zur Folie 3, wo die Fragen stehen.
Ja, hier erläutern Sie das Beschreibungsschema für Entwurfsmuster.
Das ist, nein, wir waren schon etwas weiter
Das ist, ja, ich bin noch nicht weit genug, Moment.
Genau, hier waren wir, also das war das Beschreibungsschema.
Wir hatten das Entwurfsmusterbeobachter in der letzten Vorlesung, ja,
mit Interfake-Beobachter und beobachtbar,
da wollen wir aber nicht nochmal drauf eingehen,
aber nur zur Erinnerung, da gab es was Konkretes,
wo wir genau das hatten, ja,
und diese Entwurfsmuster,
wie eben das Beobachtermuster zum Beispiel,
haben eine ganze Reihe von Beschreibungen
Wiederkehrende Lösung. Das heißt, sie sind erfolgreiche Lösungen.
Deswegen verwendet man sie gerne wieder. Immer wieder und
sie sind deswegen verfügbare Bausteine, die man verwenden kann,
um große Systeme, Strukturen, große Systeme zu bauen.
Wir haben den Begriff Architekturen dafür. Man kann sie anpassen,
weil sie eben noch diese abstrakte Darstellung haben,
wo sie nur sagen, das sind die Beteiligten,
aber bitte die Implementierung darf abweichen.
Doch es gibt für die Implementierung eine Empfehlung. Und Wiederverwendung spielt auch
eine Rolle. Das heißt, wir nutzen das Wissen,
was da ist, nutzen wir an verschiedenen Stellen.
Es tritt immer wieder auf und wir haben deswegen die Möglichkeit,
Wiedererkennungseffekt zu haben und damit ist es ein bisschen einfacher.
Diese Wiedererkennbaren vereinheitlichen Lösungen erleichtern die Einarbeitung,
sie erleichtern das Verständnis, sie erleichtern die Wissenserwerb.
Wir haben nicht mehr so viele verschiedene Lösungen,
weil es gewisser Weise vereinheitlicht wird und dadurch wird es einfacher,
die Komplexität zu beherrschen.
Und Entwickler, die viele solche Muster kennen können,
gleich mit den Mustern, wenn sie sich über Strukturen austauschen.
Hier, das ist das Beobachtermuster und hier ist das Kleinservermuster,
das kann man gut dann zur Kommunikation benutzen
Und natürlich ist es so, diese Lösungen sind erprobt,
nicht Bananensoftware, reift beim Kunden. Nein,
wir haben erprobte Lösungen, diese Muster, und die wiederverwendbaren Bausteine sind,
wiederverwendbar im Sinne von Teil der Lösung werden. Ja,
und es ist schon klar, was die für Eigenschaften haben,
die Positiven und die Negativen, und gegen die Negativen kann man gleich vorbeugen, schon was tun.
Das ist noch eine hervorragende Sache. Es gibt eine ganze Reihe Vor- und Nachteile,
die man in diesem Schema mit hatte, das war unter Konsequenzen,
das war ganz vorher dargestellt in diesem Schema, ja,
hier die Konsequenzen, hier unten dargestellt und das war jetzt ein Beispiel von der letzten Vorlesung,
wo auch Vorteile und Nachteile dargestellt werden, wollen wir aber nicht nochmal im Einzelnen durchgehen.
Ich möchte Sie darauf verweisen, dass es Bücher gibt,
wo man das nachlesen kann, Quellen im Web,
wo man sowas nachlesen kann,
das erste und das bahnbrechende Buch war das von der sogenannten Gang vor,
also die waren vier Leute, Gamera-Helden, Johnson,
Fliesidis, die dieses Buch zusammen geschrieben haben,
sich dann von einer sehr guten Entwicklertruppe,
die so ein Distalligent-Framework entwickeln sollte,
das Projekt war zwar nicht so super erfolgreich,
aber sie haben dabei die Pattern entdeckt oder entwickelt
Viele zitieren vor allen Dingen dieses Buch,
aber sie sehen an der Jahreszahl, das ist schon sehr alt.
Es hat sich seitdem auch nicht so viel getan,
wo sich mehr getan wird, hat, ist Frank Burschmann von Siemens,
hat mit wechselnden Co-Autoren insgesamt fünf Bücher im Weile-Verlag herausgebracht.
Hier ist jetzt mal eins, die Nummer zwei von den Fünfen, Muster für verteilte Verarbeitung.
Also so hat er verschiedenen Fokus für die ganzen Sachen gegeben.
Und das ist natürlich ein wunderbarer Katalog, um etwas zu finden.
Weitere Kataloge beziehen sich auf bestimmte Sprachen, auf bestimmte Plattformen,
wie zum Beispiel sowas wie ein Katalog über Design-Paddles für ESP
dort nett oder sie schabt oder für JavaScript.
Soweit ist das erstmal ein Hinweis, wo sie weitersuchen können,
wenn sie interessiert sind, Muster kennenzulernen.
Diese Bücher gibt es auch in der Bibliothek teilweise als online auch.
Und als letztes möchte ich noch einen Vorschlag machen,
wie sie langsam ihren Vorrat, einen Entwurfsmustern auffüllen können,
langsam Entwurfsmuster sammeln.
Ich hatte schon, letzte Woche haben wir das Beobachtermuster gesehen,
als ein Beispiel,
wie kann man
das machen
Müssen sie natürlich irgendwie erst mal was wissen. Ja,
sie sollten wissen, was Ziele sind,
was Struktur sind, was Eigenschaften sind.
Und das könnte eben aus einer Vorlesung stammen,
wie hier aus unserer, wo man ein paar wenige Pattern mal haben.
Aber es gibt Bücher und die Webkataloge,
die hier gerade auf der vorgehenden Folie unten genannt waren.
Sowas können sie auch gut finden. Wenn Sie,
nachdem Sie die überhaupt kennengelernt haben, empfiehlt sich,
ein kleines Beispiel zu verwenden, wo man die mal einbauen kann.
Und da kann man merken, okay,
das und das ist ein bisschen einfacher,
das und das ist
ein bisschen schwierig
Dann könnte man versuchen, nachdem sie richtig verstanden hat,
in einem existierenden System an einer Stelle erstmal so ein Ding
einzusetzen und mal schauen, ist es denn verständlicher geworden?
Ist es denn so gut? Und da nach und nach
kann man dann das sein Wissen da komplettieren,
kritischere Dinge dahin bauen, weil wir wissen ja schon,
es funktioniert und wie es funktioniert.
Und wenn sie selbst die Implementierung machen oder beteiligt sind jedenfalls,
dann haben sie auch diese Erfahrung aus erster Halt.
Soweit zu unserem vorgesehenen Stoff erstmal in diesem Teil.
Vielen Dank für Ihre Aufmerksamkeit