In der Vorlesung 7 knüpfen wir an die Sechs an,
wo es auch schon im Entwurf ging.
Diese haben wir jetzt Modellierung und Entwurf genannt. Es beginnt damit,
dass wir uns heute mit objektorientierten Modellen für Problemraum und Lösungsraum
beschäftigen und dann Modelle für Struktur und Verhalten vorstellen.
Dabei werden einige UML-Elemente aus einigen UML-Diagrammen dargestellt. Und wir werden
den Begriff Entwurf einführen als Übergang von Problemraum zu Lösungsraum.
Doch sie werden merken, vieles davon kennen sie schon.
Und das Entwurfsmuster kennen sie auch schon vom letzten Mal. Entwurfsmuster,
das Entwurfsmuster, Beobachter, hatten wir beim letzten Mal erklärt,
wie es funktioniert, wie es aufgebaut ist.
Heute stellen wir es vor, was ist daran wiederverwendbares Wissen.
Wir werden einige Fragen wieder dazu haben. Doch verstatten tun wir
mit, ach ja gut, es gibt noch Literaturempfehlungen.
Man sollte UML als Standardwerkzeug benutzen und dazu sind klassische UML-Bücher.
Notwendig ist, sie sehen, dass eine Jahreszahl,
das sind gar nicht notwendigerweise die neuesten Ausgaben.
Sie dürfen da gerne was nehmen, was schon gebraucht war
Auf jeden Fall ist es eine Empfehlung,
ein eigenes OML-Buch zu besitzen, an dem,
wo man sich dann nach und nach die Diagramme aneignen kann,
indem man sie aus diesem Buch benutzt.
Okay, der Begriff Objektorientierung verdient doch ein einzeln,
ein Wort der Erläuterung. Ja, es ist also ein Begriff,
der schon ziemlich alt ist, aus unserer Perspektive.
Ja, sie wurde für Simulationszwecke, wurde der Begriff,
wir wollen die Objekte in dem Programm nachbilden, eingeführt.
Das war damals alles andere als üblich.
Man programmierte mit Funktionen und Datenstrukturen
Doch könnte sich die Objektorientierung als Leitlinie, nämlich als Leitidee,
ich nehme etwas aus der realen Welt und überführe das in eine Programmestruktur,
als Leitidee, konnte sich das in den 80er Jahren umsetzen.
Und deswegen haben wir heute, sprechen wir heute von objektorientierter Programmierung.
Um Dinge darzustellen, um Modelle darzustellen,
um Zusammenhänge zu veranschaulichen, wurde die UML,
die Unified, Modeling Dangmage eingeführt und ein Standard, 1992,
1992 wurde die geschaffen und dazu gab es eine Vorgehensweise,
eine Vorgehensweise, wie man das entwickelt.
Das ist die Unified Method, die wollte 1994 herausgegeben als
Buch erst mal. Heute ist es so, dass UML2
im Wesentlichen als Industriestandort anerkannt ist. Es sind immer,
finden immer noch Weiterentwicklungen statt und Weiterentwicklungen sind vor allen Dingen,
wie gehen wir in agilen Vorgehensweisen um,
was sind Entwurfsmuster und wie wirkt sich das auf Testen und Qualitätssicherung aus.
Als Wiederholung, die Begriffe hatten wir schon, Problemraum,
Lösungsraum. Problemraum hier der linke Teil,
konzeptionelle Beschreibung
Rechts, die technische Lösungsraum, die technische Lösung.
Das können wir uns an dem Wort Lösung schon denken.
Das Was und das Wie, alleinstehend,
habe ich die Erfahrung gemacht, könnte es missverständlich sein,
besser ist zu sagen, was will der Kunde,
was sind die Anforderungen und wie realisiere ich das?
Also lieber ganzes Sätze als nur was oder wie,
die Realisierung ist dann die Umsetzung so, dass es technisch läuft.
Wir sollten diese Sachen voneinander trennen, das ist die Empfehlung,
weil wir die Nachteile, weil die Vermischung einige Nachteile hat.
Ich möchte sie nur darauf hinweisen, dass diese Trennung in Problemraumlösungsraum
alles andere als ganz normal ist. Das haben sich die Informatiker mühevoll erarbeitet,
in anderen Disziplinen, im Maschinenbau, in der Elektronik,
habe ich das noch nicht so in der Klarheit gesehen.
Man versucht es zu trennen, weil die Vermischung Nachteile mit sich bringt. Dazu gehört,
wenn ich gleich bei der Beschreibung das und was der Mensch möchte,
was der Auftraggeber möchte, wenn wir da gleich auf Lösungselemente vorgreifen, treifen wir Entscheidungen vor.
Und Entscheidungen könnten dann, wenn die schon getroffen sind,
ohne dass wir gut abgewogen haben, wofür sie sind,
können sie die Suche nach besseren Lösungen, nach optimalen Lösungen verhindern.
Wenn wir die trennen, haben wir es einfacher,
explizite Entscheidungen zu treffen, dass wir explizit sagen, okay,
Problem warum sagt das, wie überführen wir das denn in eine Lösung?
Es ist nicht ganz so einfach, diese Zuordnung herzustellen,
zu festzustellen, ja, das ist jetzt Problem rum,
das ist Lösungsraum, weil wir können nicht nur sagen,
ja, alles Technische ist jetzt Lösungsraum, nein,
es gibt auch manchmal bei den Antwortungen Dinge,
die technischen Charakter tragen
Auf jeden Fall können wir uns merken, Problemraum hat mit dem Einsatzkontext
zu tun. Problemreiter heute mit fachlichen Dingen zu tun.
Fachlichen Dinge sind auf Seiten des Auftraggebers häufig entwickelt worden oder
auf der Zielseite werden sie formuliert wenigstens.
Da haben wir Struktur und wir haben Verhalten.
Das sind zwei grundsätzliche Pole, ohne die geht es nicht.
Wir haben nicht nur Struktur, aber Verhalten kann nicht ohne Struktur sein.
Was gehört dazu? Zur Struktur gehören erstmal Abbildungen von
fachlichen Dingen,
wahrliche Gegenstände
Und deren Zusammenhänge. Das ist erstmal die Grundlage dessen,
was Struktur sind, insbesondere die Zusammenhänge sind für Struktur geeignet.
Natürlich gibt es auch Strukturen zwischen Daten,
da steckt das Wort schon drin, Datenstrukturen oder Struktur,
Strukturen, technische Systeme, in denen die Schnittstellen miteinander haben.
Außerdem gibt es als drittes zu nennen die organisatorische Strukturen.
Das klingt erstmal für Sie vielleicht ein bisschen abgefahren,
aber große Organisationen, wo viele Menschen sind,
brauchen eine Struktur,
damit man weiß,
wer ist denn
für was verantwortlich
Da gibt es eben Niederlassungen,
da gibt es im Servicecenter und da gibt es in den Organisationsstrukturen,
gibt es Menschen, die bestimmte Rollen haben,
da gibt es den Konfigurationsmanager zum Beispiel oder den Vertriebsmanager oder so.
Die Leute, die eine bestimmte Rolle in einem bestimmten Ablauf haben.
Diese Rollen und die Beziehungen brauchen wir dann als,
weil wir die abbilden über Objektorentierung,
bilden wir sie als fachliche Repräsentanten,
als fachliche Akteure in unserem Softwaresystem ab,
damit die Softwaresysteme
diesen Firmenprozess gut unterstützen
Ja, soweit zur Struktur, das Verhalten,
was sich auf die Struktur bezieht, sind also fachliche Prozesse, sind Abläufe.
Dazu gehören, dass wir eben detailliert Szenarien beschreiben.
Szenarien sind verallgemeinerte Aktionen, vor allem allgemeinerte Formen von Abläufen,
die also in ähnlicher Form immer wiederkommen.
Die Aktivitäten sind ihren Elemente und manchmal haben wir auch Ereignisse und Zustände,
die sehr stark bestimmen, wie das Ganze reagiert. Wichtig ist,
wenn wir das beschreiben, dass wir Begriffe verwenden,
die der Auftraggeber auch verwendet, wir eindeutig sagen können,
ja, so haben wir es verstanden und der Auftraggeber kann dann dazu sagen,
ja, so ist es richtig verstanden.
Um dieses Verstehen durchzuführen, um den Auftrag,
um den Anwendungsbereich kennenzulernen, versuchen, Entwickler zu verstehen,
was passiert in diesem Problemraum.
Sie fundalisieren, was machen die Menschen dort?
Was sind die fachlichen Aufgaben, die die machen?
Planen die ein Gebäude, bleiben die Infrastruktur einer Stadt,
setzen die einen chemischen Prozess in Gang oder überwachen den oder
so etwas
Ja, dass zunächst erstmal diese Gegenstände, die Aufgaben,
die Darkbrenn sind, dann analysiert man die Prozesse,
die ablaufen, die fachlichen Prozesse, die Aufgaben.
Und sie aber achten darauf, wiemit wird damit gearbeitet?
Wie ist der Zusammenhang zwischen Struktur und Verhalten? Einschließlich wies es,
wie ist der Zusammenhang zwischen solchen Prozessen? Und man versucht,
das Ganze zu veranschaulichen und dazu sind bei komplexen Zusammenhängen Modelle
sehr gut geeignet, aber Modelle des Problemraums,
diese Unterscheidung, Problemraum,
Lösungsraum sollten wir bei Modellen
unbedingt treffen
So, hier mal mit ein paar Begriffen. Das sind also kein irgendwie UML-Diagramm,
sondern einfach nur, wie hängen Sachen zusammen? Wir haben Aufgaben,
die Aufgaben werden durch Prozesse erledigt, hier gelb eingeführt,
an manchen Prozessen ist niemand weiter beteiligt,
die laufen automatisch, aber es gibt Prozesse,
an denen Menschen beteiligt sind, hier gerade drei Akteure,
von denen der Mittlere mit den beiden anderen kooperiert und wir haben Gegenstände,
die von Prozessen benötigt werden.
Wenn Sie jetzt an Material und Werkzeug denken,
da liegen Sie ganz richtig, genau diese Zusammenhänge bilden wir
mit der Methode Wamm, mit Werkzeug und Material ab.
Soweit zu dem allgemeinen Vorgehen, was finden wir da vor?
Wir finden organisatorische Strukturen vor, zum Beispiel eine Abteilung.
Menschen tun dabei etwas, sie arbeiten mit Materialien,
die Prozesse werden von Personen durchgeführt und für Arbeitsmaterialien hier also einen Plan eines Gebäudes zum Beispiel,
eines Bauwerks wird mit Werkzeugen gearbeitet,
hier ein Werkzeug,
was irgendwie was misst,
Flächen berechnet oder so etwas
Wenn wir eine solche Analyse des Problemraums durchführen, sollten wir sehr genau zuhören.
Wir sollten das gut aufnehmen. Wir sollten versuchen, Widersprüche
zu erkennen. Und das ist Gegenstand einer anderen Disziplin,
einer Disziplin der Informatik. Ich möchte es bei der Gelegenheit
einführen. Requirements Engineering, nennen die sich Anforderungserhebung.
Und da gehören solche Sachen wieder mit dazu,
dass man bestimmte Analysetechniken hat, wie man mit Anwendungen umgeht.
Man möchte ja auch die Uhren ausgesprochenen Sachen erfahren,
von denen die alle denken, sie ist selbstverständlich.
Und wir haben es, wir kriegen dann Ärger,
wenn wir es hinterher vergessen haben
Interviews mit den Leuten gemacht, Rollenspiele. Man lässt sich
Sachen erklären oder man macht vielleicht sogar videogestützte Analysen. Wir verschworen,
das zu vervollständigen, weil wir hören ja nicht alles,
sondern wir versuchen daraus ein Modell zu bilden,
was das Ganze abbildet und solche Modelle, das sind dann Modelle.
Das Problem war, wir kommen gleich auf Beispiele. Und wir wollen prüfen,
ob wir es richtig verstanden haben, das kann man sehr gut damit machen,
indem man dem Nutzer einen Prototypen präsentiert, der scheinbar etwas tut,
praktisch kommt es ja nicht darauf an,
dass da wirklich eine Berechnung durchgeführt wird,
sondern praktisch kommt es darauf an zu sehen,
ah ja,
da ist ein Feld und das Feld ergibt sich aus
dem und dem
So, und wir versuchen dabei, solche Modelle des Problemraums und zu erstellen und Prototypen zu bauen,
soweit das mit einfachen Mitteln möglich ist. Ja,
der Problemraum, wenn wir ein Modell des Problemraums darstellen,
soll dieses Modell aller Aspekte darstellen,
die wichtig sind für die Entwicklung des Anwendungssystems,
die also einen Zusammenhang haben, mit dem ein Anwendungssystem,
mit dem Softwaresystem, was wir entwickeln wollen.
Dann hilft es uns, wenn das so ist,
können wir dieses Modell dann benutzen, Aufgaben daraus zu lesen,
um rauszulesen, was für Aufgaben werden durchgeführt, mit welchen Gegenständen,
was für Prozesse laufen ab und welche Begriffe treffen dafür zu.
Und wir können das Modell in verschiedenen Modellen,
also Modellierungssprachen darstellen, hier vor allen Dingen Diakrammer der UML,
zu denen wir gleich kommen werden.
So, als Abschnitt dieses Abschnitts,
als Ende dieses Abschnitts möchte ich Ihnen ein kleines Quiz präsentieren.
Dieses Quiz sollen Sie bitte beantworten. Wir werden
das Quiz in der interaktiven Fragerunde zur Vorlesung am nächsten Mittwoch
Beantworten. Ja, was für Sachverhalte gehören da dran?
Eins, zwei gehören dazu, zu einem Bibliotheksystem.
Sind sie Problemraum oder sind sie Lösungsraum?
Und das von 1 bis 4, die Daten,
die Speicherung des Bibliotheksbestands, erfolgt in der Relationalen Datenbank mit MySQL,
die ISBN kennzeichnet genau eine Ausgabe eines Buches.
Das ist eine fachliche Aussage. Das ist eine Festlegung,
Vorbezahlung der Mahnengebühren, erfolgt keine erneute Ausleitung,
aber man könnte sagen,
das ist eine Geschäftsregel
Und die Ausleihhistorie wird als doppelt verkettete Liste verwaltet.
Das ist auch eine Festlegung. Und jetzt ist die Frage,
Problemraum oder Lösungsraum? Noch ein Blick zurück zu den Fragen
. Wir hatten die Frage, treibeantwortet? Nein, das
war hier das Nächste. Die Frage 1 beantwortet Unterschiede,
Problemraum, Lösungsraum. Das war vorrangig auf der Folie 7.
Hier war etwas zum Einsatzsonntext gesagt, zum Lösungsraum habe ich
bis jetzt noch nichts gesagt.
Das kommt auf den nächsten Folien. Soweit erstmal zum
ersten Abschnitt und im nächsten Abschnitt geht es um Modellierung