Hallo, herzlich willkommen zu dieser neuen Vorlesung SE2,
nachdem wir beim letzten Mal sehr viel über fachliche Modellierung gesprochen haben,
ohne wirklich zu sagen, dass es ist,
geht es heute im Kern um Modellierung und auch dann,
was Entwurf ist und dann kommen wir noch mal zu Entwurfsmustern.
Wir haben, dass die Themen, Problemraum, Lösungsraum,
die Sie auch schon mal gehört haben, etwas zur OML und dann Entwurf.
Die Fragen, wenn wir dann einzeln abarbeiten, ich möchte Ihnen etwas empfehlen,
nämlich, dass sie sich ein UML-Buch zulegen. Das meine ich nicht,
damit sie was Budis im Schrank stehen haben,
sondern weil UML der Industriestandard ist,
mit dem man immer als Informatiker gut verwenden kann,
indem sie sich schrittweise viel besser erschließen können mit sich selbst ein Buch haben,
das sie zu ihrem Arbeitswerkzeug machen können.
Welches sie dabei nehmen, ist eigentlich ganz egal. Wichtig ist,
dass es ihr Ereignis ist, in der sie reinschreiben können,
bunte Pfännchen dran kleben können, sich Notizen machen können,
was also wirklich,
wo sie sich nach einer Weile damit arbeiten,
eben auch Boss kennen
Lass nämlich kurz starten, historisch, UML hat irgendwann begonnen mit Objektorientierung für Simulationen und hat also versucht,
Dinge der realen Welt in einem System, in einem Modell abzubilden.
Und das hat man eben zu den Situationenzwecken benutzt. Da gab es eine Programmiersprache,
Simulat, das man heute als Ursprung der Objektorientierung bezeichnet,
dann war es in den 80er Jahren so ein bisschen ein Hype-Objektorientierung,
war so was wie gut,
so wie heute eben Machine Learning, intelligent als gut geht.
Ja, das gibt immer mal so Hypes und damals war
auch Arbeitsmaterialien und Automatisierung mit Objekten ein ganz wichtiger Punkt.
Es gab verschiedene Darstellungen für Modellierung, für Modelle,
wie man Objekte darstellt und die UML führte verschiedene damals vorhandene Methoden zusammen und 92 haben sich Caributsch über Jackpson,
James Runboot, zusammengeschlossen und haben ihr am gemeinsamen,
in ihrer Methoden zusammengeführt,
sie waren drei recht bekannte Autoren und haben eine gemeinsame Gesage gemacht,
Unified Modeling Langwich,
das sind besten Sachen mit dieser drei Methoden enthielt
Das ist aber nur die Beschreibungsform, wie man dahin kommt.
Das sagt die Unified Method, die dann kurz darauf veröffentlicht wurden.
Heute ist die UML 2 der Industriestandard. Man hat,
sie wird immer auch etwas weiterentwickelt, wie gesagt,
besonders meine Empfehlung als Informatiker,
das sollte man so ein Buch als Arbeitswerkzeug haben,
damit man sich nach und nach auf die UML erschließt.
Sie können eigentlich jede Auflage kaufen. Wichtig ist nur UML
2, muss es sein. Etwas ganz Altes,
NumL1 ist da nicht so richtig geeignet.
Die Begriffe Problemraum und Lösungsraum hatten wir schon mal
Ich möchte noch mal hier sagen, worum es geht,
weil das wollen wir bei der fachlichen und bei
der Medaillierung für technische Lösungen in der Folge machen.
Das entspricht auch dem, das haben wir in unserer ersten Frage hier,
Frage 1, was ist der Unterschied zwischen Problemraum und Lösungsraum.
Wenn wir Problemraum ist, die konzeptionelle Beschreibung,
was ist Konzept, Konzept steht statt,
wenn sie im Mexiko nachkommen, Konzept ist ein Begriff,
ja,
wir meinen damit die fachlichen Dinge der Aufgaben stellen,
die Anforderungen der Requirements
Während der Lösungsraum darstellt, was haben wir daraus gebaut,
hinsieht die, diese technische Lösung, ja, wie sieht die Software so aus.
Informatiker lernen, und das möchte ich Ihnen nahe bringen,
hier auch an dieser Stelle, dass man die beiden Sachen nicht vermischen soll. Ja,
wenn man nämlich bei den Anforderungen, Antwortungen ist das,
was der Auftraggeber sagt, was soll gemacht werden,
wenn man da schon technische Lösungen vorgreift,
ja, Vorgriffauflösungen, zum Beispiel,
es soll unbedingt Myers Duell verwendet werden oder man soll dort unbedingt das Beobachtermuster einsetzen,
weil ein schlauer Berater dem Kunden das ins Ohr gesetzt hat.
Ja, so und so, das ist toll. Ja,
dann schränkt man die Entscheidungen ein, die später vielleicht wichtig sind,
um eine besondere stabile, robuste, performante Lösung zu machen.
Also Freiheitsgrade muss man schon einschränken, aber nicht mit den Anforderungen.
Wenn man sie trennt, haben wir den großen Vorteil,
die Trennung zwischen diesen beiden Sachen, dass man explizit sagt,
okay, für diese Anforderung baue ich diese Lösung.
Und das ist die Entscheidung
Nun ist die Frage, woran erkenne ich denn,
was, natürlich wissen wir, was Anforderungen sind,
aber wenn ich eher ein Modell vorliegen habe,
und das ist der zweite Teil dieser Frage hier,
wodurch unterscheiden sich Modelle bei der Bereiche?
Das ist tatsächlich schwer zu erkennen,
wenn sie ein Stück UML-Modell da haben, ein Beschreibungsstück,
dann können sie kaum erkennen, woran das denn liegt,
aber vor allen Dingen können sie nicht sagen, okay,
wenn etwas Technisches drin ist,
dann ist es auf jeden Fall Lösungsparallösungsraum,
und wenn nichts Technisches drin ist,
dann ist es Anforderungen
Das ist mit dem milchtechnischen und dann ist es Antwortung, das stimmt ganz häufig.
Aber mit dem technischen und dann ist es Realisierung,
das stimmt nicht immer, denn manchmal ist es so,
dass wir technische Anforderungen haben. Zum Beispiel,
die sollen ein bestimmtes Bußprotokoll erfüllen, ja,
weil man mit einer Maschine oder über ein Netzwerk eine Verbindung haben will,
wo man genau dieses Protokoll braucht, ja,
oder ich möchte einen Stecker mit dem, mit dem technischen Standard.
Oder ich möchte die und die technischen Parameter haben oder
sie kaufen sich ein Gerät, was über das B,
aber mit der und der Version unterstützt.
Das ist etwas Technisches, aber es ist eine Leinenforderung
Das heißt, auch auf der Seite des Lösungs des Problemraums
kann es technische Dinge geben, aber die klare Entscheidung ist,
hier technische Lösungen sind Entscheidungen.
Also Entscheidungen sind die Sachen, die sie auf dieser Seite haben.
Entscheidungen für technische Lösungen. Das ist der Unterschied,
also Entscheidungen hier drüben, wenn es nur technisch ist,
das ist kein gutes Entscheidung.
Es gibt Unterscheidungskette. Ja, Problemraum geht also in Anforderungen,
und das ist letztlich der Einsatzkontext eines Softwaresystems
Wir teilen das in die Struktur und Verhalten.
Wir kommen dann später nochmal dazu. Aber wenn wir überlegen,
was gehört zu Struktur, das sind die fachlichen Dinge,
mit denen wir arbeiten und deren zusammenhängen.
Solche fachlichen Dinge können zum Beispiel Daten sein, Datenstrukturen häufig
oder wir haben technische Systeme, mit denen wir zusammenarbeiten.
Und die haben auch miteinander zu tun. Oder manchmal gibt es auch Sachen,
die sind nicht technischer Natur, aber haben auch Strukturen.
Zum Beispiel, es gibt ein Unternehmen,
Abteilungen, die sich gegenseitig, die gegenseitige Arbeitsbeziehungen haben,
Abhängigkeitsbeziehungen hatten
Oder es gibt zwischen den staatlichen Organisationen, gibt es Weisungsbefugnisse,
das und das darf der Bund entscheiden,
das und das dürfen die Länder entscheiden.
Ja, oder in einem Projekt gibt es jemanden,
der uns eine Freigabe geben, eine Person.
Solche Sachen sind Struktur und die organisatorische Art,
die durch Software abgebildet und unterstützt werden müssen.
Das wäre auch Problemraum, und zwar Strukturen.
Verhalten, sagt etwas über Reihenfolge, sagt etwas,
was tatsächlich zur Laufzeit passiert. Das sind also Prozesse,
das sind Abläufe, Ereignisse, Folgen von Sachen oder Aktivität
Für die Beschreibung all dieser Sachen, nehmen wir fachliche Begriffe.
Und wenn wir das ermitteln wollen, dann müssen wir versuchen, das zu verstehen. Ja,
wir müssen die Anwendung verstehen und die Entwickler,
die das können, mit Quirements, Engineering heißt diese Disziplin,
müssen tatsächlich tief eindringen und diese fachlichen Spezialitäten,
die,
wenn es eigentlich nur die Fachrede der Chemie oder der Hafenlogistik oder der Wertpapiergeschäfte oder der Flugbuchungen oder was auch immer,
was für ein Softwaresystem wir halt gerade bauen, verstehen.
Also das ist der Problemraum und da spielt ganz viel
über Begriffe
So, und fachliche Aufgaben zu verstehen, Prozesse zu verstehen.
Also diese Begriffe, die helfen uns am Ende,
Strukturen zu erkennen, aber auch Prozesse zu vervollständigen.
Wie wird gearbeitet und wir versuchen, das Wesentliche zusammenzustellen,
das Wesentliche, das ist das, was ein Modell ausdrückt.
Der Modell drückt nicht die volle Realität aus und nur das
Wesentliche oder Versuchen dort, die Begriffe der Fachsprache mit hineinzugehen.
Also wir haben hier Aufgaben, fachliche Aufgaben,
Prozesse an den Prozessen sind Akteure beteiligt
Die miteinander arbeiten, Gegenstände, wie das bearbeiten.
Und Sie sehen schon hier,
das klingt schon so ein bisschen wie unser Werkzeugmaterialabsatzeinsatz,
den wir in der vergangenen Vorlesung machen wird.
Nee, da ein paar Beispiele.
Wir haben organisatorische Strukturen, eine Abteilung hier dargestellt.
Es gibt Büros und Cafeteria und so weiter und eine Raumplanung.
Aber da brauchen wir auch solche Strukturen. Personen bearbeiten etwas
hier in einem Bürosättigen. Ja, wir bearbeiten sie,
sie müssen dabei zusammenarbeiten. Sie müssen sich Abstimmungen,
sie müssen sich abstimmen, sie müssen Informationen austauschen.
Sie müssen gegenseitig Teilaufgaben übernehmen
Es gibt verschiedene Personen, die gemeinsam solche Arbeitsprozesse erledigen,
in denen die Teilaufgaben in einer bestimmten Folge erledigen.
Und wir verwenden Werkzeuge dazu. Auch wieder Dinge,
wo ihm vielleicht die Ohren klingen, ja, okay,
das ist ja dieses Werkzeugmaterial-Ding,
was wir in der letzten Folge so beohrt haben.
Wenn wir das analysieren wollen, brauchen wir genau diese Techniken des Requirements Engineering.
Ich möchte sagen, da ein bisschen dafür werben,
ist ein sehr interessantes Feld der Informatik. Vielleicht wird das später mal ihr Berufsfeld,
wo sehr viel um Kommunikation geht, sich hineinversetzen in Menschen,
einversetzen, in deren Begrifflichkeit Dinge so erklären,
dass die sich gut verstehen und am Ende Berater sein,
Berater für deren Lösung.
Und dieses Verstehen macht man ganz gut durch Fragetechniken. Man macht Interviews,
man macht Rollenspiele, man ist einfach nur dabei oder man
lässt die Leute laut reden bei den Sachen, die sie tun,
um besser zu verstehen, was sie denn tun.
Dabei erstellen wir dann Modelle des Problemraums, Niederspiegeln,
was sind die wichtigen Zusammenhänge,
diese Modelle diskutieren wir mit den Fachexperten, um zu rauszubekommen,
dass wir etwas, ob wir auch alles verstanden haben.
Oder wir erstellen Prototypen in Teile des späteren Systems oder
des Beobachten Verhaltens widerspiegeln, um dein Feedback zu bekommen.
Ja, das ist es. So ein Modell des Problemraums
soll am Ende so sein, dass es den Einsatzkontext niedergibt.
Das heißt, Kontext im Sinne von Umgebung,
dass es wiedergibt, wie das System in der Umgebung arbeiten kann.
Welche Aufgaben es übernimmt, welche Gegenstände es bearbeitet,
die Prozesse,
die Begriffe
Und jetzt wieder Struktur und Verhalten, wir wollen solche Diagramme verwenden,
die Struktur und Verhalten darstellen, und zwar in einer Form,
dass sie die Informatiker und in gewissen Grenzen auch,
wie fachbeutet der als Anwendungsbereichs, verstehe.
Und als Abschluss dieses Bereichs, Problemraum,
Lösungsraum möchte ich sie hier mit einem kleinen Quiz entlassen,
die Auflösung gibt es gerne in der Fragerunde.
Ich möchte gerne von Ihnen wissen, für vier Sachfalle,
die hier in den Sätzen dargestellt sind, Wie gehören die zum Problemraum?
Oder gehören sie zum Lösungsraum? Ja, denken Sie mal drüber nach,
machen Sie Ihre eigene Lösung dazu und erklären,
versuchen Sie auch zu erklären,
warum Sie das zu dem Problem oder Lösungsraum zuschlagen würden.
Und wir machen dann kleine Auflösung, wie gesagt,
in der Fragerunde zur Vorlesung.
Ja, und dann geht es weiter mit Struktur und Verhaltensorientierten