Der nächste Abschnitt in unserer Vorlesung, Softwaretechnik ist der Bereich Problembereichsmodellierung 1.4.
Das knüpft an an die Bestandteile eines Anforderungsmodells,
was wir ganz zu Anfang mal hatten, das Anforderungsmodell besteht aus,
und das war diese kleine Beziehung hier, Teil von,
besteht aus dem Anwendungsfallmodell, was wir zuerst behandelt haben,
dann hatten wir das Aktivitätstiagramm besprochen und jetzt sprechen wir über das Problembereichsmodell.
Das ist der Abschnitt 1.4 in unserer Vorlesung
Und dabei geht es, haben wir diese Fragen 10 bis 13 hier.
Problem, Bereichsmodell und Lösungsbereich. Wie setzen wir das Klassendiagramm
ein und fragen mit der technischen Realisierung, wie technisch dürfen solche Sachen sein?
Auf die werden wir jetzt alles eingehen. Doch wir fangen
an gleich mal mit dem, mit hier der Folie mit der Überschrift.
Ich möchte gern den Begriff Problembereich einführen. Auf Englisch heißt das Problem Domain,
Und dieser Problembereich dreht sich darum,
dass wir unterscheiden müssen und das ist etwas Spezifisches,
was die Informatiker entwickelt haben,
dass wir die Sicht auf ein System, auf separat halten,
von der Sicht auf die technische Lösung.
Dass Sicht auf die Tische öfters Problem, konzeptionelle Beschreibung,
was es zu bauen, dieses Was, das hat zu tun mit der Zielstellung.
Ja, also die Zielstellung ist das Konzeptionelle,
was wir hier, was wir hier meinen,
da könnte man auch durchaus sagen,
das Fachliche
Wir hatten dafür den Begriff Spezifikation genommen. Also man könnte hier
durchaus auch sagen, ich schreibe das mal mit Rot dran.
Fachliche Beschreibung, Konzept ist ja, wenn Sie das im
Wörterbuch mal nachschauen, Konzept ist der Begriff.
Also es geht darum, mit Begriffen des Fachbilds Aufgabenbereichs zu beschreiben,
was ist denn hier zu tun.
Es geht darum, fachliche Zusammenhänge darzustellen
So, während bei dem Lösungsbereich, das ist dabei,
geht es um die Realisierung, das steht hier schon,
ja, also wie ist etwas zu bauen.
Das eine ist die Aufgabenstellung, das schreiben wir hier noch mit dazu.
Wie sie sich hoffentlich vom letzten Mal erinnern,
ist Spezifikation ja ein anderes Wort für Aufgabenstellung,
to Specify, was genau beschreiben, aber was das,
was wir bauen wollen.
Also während es beim Getrüben um die Zielstellung geht,
geht es beim Lösungsbereich um Entscheidungen für die technische Realisierung.
Und natürlich sind das auch interne Sachen,
die man
nur intern sieht
So, lassen Sie uns damit, damit wäre eigentlich schon alles gesagt,
aber wir wollen das mit Brechen, mit Beispielen unterlegen.
Für den Problembereich sind alle die Sachen wichtig,
das Umfeld des Softwaresystems betreffen und die Struktur des Softwaresystems.
Und wenn wir hier mal Beispiele angeben bei beiden,
so wäre das bei dem Problembereich organisatorische Strukturen.
Bei einer Firma wäre das zum Beispiel, es gibt eine Niederlassung,
Es gibt Abteilungen, so etwas in der Art.
Dann, das wäre Struktur, das wäre eher etwas Statisches.
Dann sind es Abläufe, die wir darstellen. Aber um
das von der Technischen Journalisierung darzustellen, sagen wir mal, Abläufe aus Nutzersicht. Diese Abläufe beziehen sich auf Dinge,
die der Benutzer entweder steuert oder wo das System Teil davon ist,
zum Beispiel ein Ablauf wie ein Versicherungsvertrag schrittweise komplettiert wird,
wie er geprüft wird, wie er in bestimmte Kategorien gesortiert wurden,
wie dann berechnet wird, wie viele Gebühr,
der also Tarif heißt das ja, die Tarifhöhe,
wie die Tarife dieses Versicherungsvertrags für den Kunden dann ist.
Dazu gehört auch noch natürlich solche Abläufe auch Sachen im Fehlerfall.
Also Reaktionen auf Fehler und Ausnahmefälle
Das können wir noch mit ihm zunehmen. Dann könnten wir
sowas so sagen wie grundlegende Abläufe in der Firma,
in einer Firma werden häufig als Geschäftsregeln formuliert.
Geschäftsregeln machen häufig das Know-how einer Firma aus, wodurch sie sich von Mitbewerbern unterscheidet.
Ich hatte schon mehrfach sowas wie beim Lieferservice,
wem liefert was man, was auf Rechnung,
oder gar man nimmt dem Engodit ein,
dass er erst was später bezahlen muss,
und bei wem möchte man gar Vorkasse,
weil man denkt,
wer weiß,
ob ich das wiederkriege
Oder vielleicht merken sie es selber bei Online-Bestellungen. Ich weiß nicht,
ob sie Packstationen benutzen oder diese Lockout bei Amazon oder was auch immer.
Manchmal, manche versenden nicht dahin, bei den Packstationen
von DHL, weil da schon Rucksälle vorgekommen sind.
Und wann versende ich was zu solchen Packstationen? Wann nicht
? Das ist schon eine Einschränkung der Flexibilität für den Kunden.
Und das sollte man nur machen, wenn man gute Gründe hat.
Wann macht man was? Das könnte in einer Geschäftsregel stecken
. Dann Strukturen von Daten
Informationen hängen häufig zusammen. Und da hatte ich Strukturen. Wenn Sie denken,
ich schneide Strukturen, ist noch ein bisschen was Technisches.
Häufig hat der Anwender klarer Vorstellung, was gehört alles zu einer Interesse.
Wie ist eine Artikelnummer aufgebaut in großen Organisationen? Verwaltungsorganisationen gibt
man einen klaren Aktenplan, wie die Aktennummer auszusehen hat.
Oder wie strukturiere ich meine Ablage für Streuerfälle
All das sind Sachen, die als Aufgabenstellung an den Entwickler
des Softwaresystems kommen. All sowas gehört zum Problembereich.
Und was man natürlich nicht vergessen soll,
so ein System hat auch immer Schnittstellen zu anderen Systemen.
Schnittstellen nach außen. Zu anderen Systemen und natürlich auch zu Menschen
. Soweit ein paar Beispiele, was alles zum Problembereich gehört
Zum Lösungsbereich, so wie,
wir hatten ja schon eigentlich gesagt,
technische Realisierung eigentlich sagt es,
dass alle auch hier ein paar Beispiele,
das wären zum Beispiel wie ein System aufgebaut ist und zwar
nicht nur aus der fachlichen Struktion,
sondern der technische Aufbau
Und zwar die Sachen, zu weit sie.
Manchmal ist das ja vorher festgelegt durch den der Auftraggeber sagt,
da gibt es den Teil, um den Teil und den Teil.
Zum Beispiel, weil er die Valentin mit Standardlösungen belegen will
oder sowas, dann ist das schon klar.
Wenn es denn Entscheidungen des Entwicklers ist,
dann gehört das hier zum Lösungsbereich.
Also deswegen erkennt sich mal hier soweit nicht durch
die Aufgabenstellung,
durch Spezifikation festgelegt
So, da müssen wir das Bierchen hier ein bisschen verschieben.
Das kriegt man hin, dass sie besser lesen können.
Soweit nicht durch die Spezifikation festgelegt,
das wäre ein Beispiel dann für diese Datenspeicherung.
Oder für diese Daten, die wir hier drüben haben.
Die Datenspeicherung wäre ein Punkt, den wir hier beschreiben,
oder wie läuft die Synchronisation bei verteilter Datenspeicherung ab?
Synchronisation, dann können wir noch etwas sagen, ja,
Schnittstellen natürlich schon,
soweit wir
darüber entschieden haben
Wir haben hier drüben auch durchaus Schnittstellen, ja,
also hier sind auch Schnittstellen dargestellt und da sind jetzt die Schnittstellen,
über die wir im Laufe des Entwurfs beschrieben haben,
da zum Beispiel sind das Schnittstellen zwischen Komponenten.
Das wäre noch denkbar oder wenn wir,
wir haben ja drüben geschrieben, Ausnahmen spielen eine Rolle,
ja, wie sieht denn,
wie wird denn auf diese Ausnahmen reagiert,
das wären zum Beispiel Mechanismen der Ausnahmebehandlung,
Das ist mir der, ich schreibe mal Fehlerbehandlung.
Und vielleicht als letztes zu dem Datenspönnen eine Datenspeicherung in einem Datenbanksystem haben,
dann könnten wir hier, das ist ja auch etwas,
was wir entschieden haben.
Wir haben in Datenbank-Managementsystemen, da haben wir vielleicht über das Datenmodell entschieden. Das ist,
soweit sind Beispiele dazu, Und wenn wir nochmal die Fragen zurückschauen,
dann hätten wir ja jetzt hier die Frage, zehn beantwortet,
dann erläutern sie den Unterschied zwischen Problembereichsmodell und dem Lösungsbereichmodell.
Das wäre das eine. Und jetzt zu den Fragen,
vielleicht sage ich noch was gleich zur Frage, zwölf.
Wenn wir diese beiden Sachen trennen, haben wir eine Reihe von Vorteilen.
Das passt auf die nächsten, auf die nächste Folien.
Das wäre gleich die Antwort auf die Frage zwölf
Und zwar ist ein großer Vorteil dieser Trennung ist,
dass wir Vorgriff auf Lösungen vermeiden.
Denn... Damit würden wir
Oder vielleicht schreiben wir mal der, der Entscheidungsspielräume.
Und das bezeichnen manchmal auch als Lösungsraum. Also wir versuchen,
dies zu trennen, das, was wir auf der vorgehenden Folie haben.
Wir haben einerseits den Lösungsraum, der sagt,
was ist zu machen, dieser fachliche Aufgabenstellung,
bitte ohne technische Zusammenhänge und dann,
wie machen wir das,
das ist das,
was die Entwickler danach machen
Und diese Trennung hier, die ist ganz wichtig,
dass wir diesen Vorteil erreichen,
den Vorgriff zu vermeiden
Bessere Lösungen müssen wir suchen. Das ist unsere Aufgabe als
Informatiker. Wir kennen die Technologie hoffentlich. Wir kennen
die Bandbreite der technischen Möglichkeiten und wir, unsere Aufgabe,
muss es sein, diese technischen Eigenschaften festzulegen.
Und wenn natürlich, manchmal gibt es Auftraggeber,
die wollen schon ganz genau festlegen, die haben von irgendjemandem gehört,
dieses Produkt ist toll und die wollen sie darauf festnagen,
nehmen sie das. Ja, das kann aber sein,
das ist nicht gar nicht das optimale Produkt für diese Aufgabenstellung.
Sie haben davon gehört, viele Versprechungen gehört und vielleicht ist
das Produkt gar nicht so reif oder Support passt nicht oder was auch immer.
Deswegen ist es so wichtig, diese Lösungen noch offen
zu lassen
Es gibt natürlich auch Fälle, wo ganz klar festgelegt ist,
zum Beispiel mit den Schnittstellen, ja,
es gibt hier weitere Systeme, die alle mit MySQL arbeiten.
Na, dann ist klar, dass sie
auch MySQL verwenden müssen als Datenbank oder wie auch immer.
Dann gibt es solche Sachen. Manchmal ist das schon berechtfertigt,
dass man eine Einheitlichkeit hat, in der im Unternehmen,
weil das die Administration vereinfacht, den Lizenzkauf vereinfacht oder was auch immer.
Also deswegen müssen wir diese Einschränkung machen und was wir damit
erreichen wollen oder wo wir was dafür achten müssen, ist,
dass die Anforderungsanalyse Die Anforderungsalyse sollte sich um die fachlichen Zusammenhänge bemühen.
Weil diese Dinge ein höheres Gewicht haben, Sie ändern sich
von der ersten Vorlesung hoffentlich noch an das Gewicht dieser frühen Entscheidungen.
Die Anforderungen richtig zu verstehen, trifft, hilft uns,
die richtigen Entscheidungen für das System zu treffen.
Und bei der Gestaltung der Anforderungen, bei der Strukturierung,
dieser Problembereichsmodelle, da treffen wir Entscheidungen für das System.
Wie sieht das System aus? Welche fachlichen Zusammenhänge,
welche organisatorischen Strukturen werden unterstützt? Wie sind die Abläufe?
Das sind Entscheidungen wie das System handeln soll.
So, das wäre, das wäre der eine Punkt
Aber wir müssen sagen, hier gibt es ein Aber.
Und zwar fehlt diese Trennung in der Praxis häufig schwer.
Rot unterschreiben sollen, aber ja.
Und zwar, warum ist diese Schwierigkeit in der Praxis?
Diese Schwierigkeit besteht darin, dass einerseits beim Erstellen der Anforderungen
vielen Entwicklern schon Lösungen einfallen.
Da wollen sie
diese guten Ideen natürlich aufschreiben
Mein Erfassen von Anforderungen. Ich habe Entwickler bereits Lösungsideen.
Was ist noch hier
Und das ist natürlich eigentlich etwas Gutes,
dass man gute Ideen hat, aber man sollte,
man sollte alle Seiten abgewogen haben und nicht gleich sagen,
ach, wir machen das so und das steht dann in der Aufgabenstörung drin.
Dieses Problem, dieses Anforderungsmodell ist ja Bestandteil der Aufgabenstellung.
Es wird Bestandteil des Vertrages, so wenn das schon drinsteht,
wir müssen mal SQL verwenden, dann hilft uns gar nicht,
dass vielleicht eine Objekte und hier Datenbank besser wäre.
Oder einfach teilt es eine verteilte Datenbank,
was mit Mayos Guell eher schlecht geht. Also dann,
manchmal gibt es Entscheidungen, die noch von mehr Sachen abhängen,
weswegen noch nicht,
dass soweit treffen
Ein weiterer Punkt, warum diese Trennung schwerfällt, ist,
dass wir ja die Trennung eigentlich machen wollen in Aufgabenstellung und technische Details.
Und zu diesen, manchmal gibt es technische Details,
die Teil der Aufgabenstellung sind
Zum Beispiel solche Sachen wie Plattformen, manche sagen dazu auch Technologie-Stack.
Oder Randbedingungen. Oder Schnittstellen, ich schreibe das hier mal
davor. All solche Dinge können technische Zusammenhänge enthalten.
Das ist ein weiterer Punkt. Und ein Punkt,
der zusätzlich hinkommt, es ist eine Prüfung der Anforderungen notwendig.
Wir haben in der vergangenen Woche darüber gesprochen,
was sind Prüfkriterien für eine Anforderungsbeschreibung.
Da war auch Tritt dabei, Erfüllbarkeit
Und für diese Prüfung der Erfüllbarkeit von Anforderungen
werden technische Lösungen geprüft
Also wenn zum Beispiel jemand möchte,
dass dieses System A mit dem System B zusammenarbeiten und sie brauchen,
und die Datenformate passen nicht, dann werden sie ein Adapterwerkzeug dafür aussuchen.
Und sie wollen sicher sein, dass dieses Adapterwerkzeug auch funktioniert.
Und warum, da liegt es ja nahe, dass man
dieses Adapterwerkzeug gleich als technische Lösung festschreibt und da reinschreibt.
Nein, das ist zuzeitig, man sollte das offen lassen,
man sollte suchen, ob es vielleicht noch etwas Besseres gibt.
Ja, also diese sollten wir doch nicht
als Lösung vorgeschrieben werden
So, soweit zu den Unterschieden zwischen Problembereichsmodell und Lösung.
Das wäre sozusagen die Vorteile, die war die Frage 12
hier. Ja, also warum sollte das nicht enthalten?
Weil das ist eigentlich keine Fragen zur Realisierung enthalten.
Das waren genau die Vorteile, die wir gerade genannt haben,
eben da, weil ich noch nicht die Menge,
noch nicht die Entscheidungsschrauben einengt muss,
weil ich vielleicht an Entscheidungen später noch weitere Sachen betrachten muss
So, wenn wir jetzt, ich habe jetzt mal
die Frage 11 und die Zwage 13 sind ein bisschen diffizil.
Die haben beide miteinander zu tun. Hier am Beispiel des Klassendiagramms
, was sollte, wie kann ich denn das erkennen?
Das, was wir hier aufgeschrieben haben, sagt uns,
was schreibe ich denn da rein?
Ja, wir schreiben hier rein, fachliche Zusammenhänge.
Hier schreiben wir interner und Entscheidungen der Realisierung. Ja,
da könnte jemand auf die Idee kommen, okay,
eher die technischen Sachen sind
Das, was ich bei Problembereich habe und er die nicht technischen Sachen,
weil hier steht ja fachlich konzeptionell, da würde man denken,
ach, die nicht technischen Sachen sind das.
Leider trifft das nicht zu, denn häufig haben wir hier
auch bei den Schnittstellen, haben wir häufig auch technische Sachen.
Und bei den Fehlern haben wir manchmal technische Details.
Und manchmal haben wir bei den Anforderungen auch technische Details. Ja,
das, was wir auf der nächsten Folie hatten,
das ist, man kann also nicht davon ausgehen,
dass nur die technischen Sachen nur hier im Lösungsbereich sind.
Und hier sind nur nicht technische Sachen, nein,
das Entscheidende sind diese Entscheidungen, daran können sie das festmachen.
Ja, ich unterstreiche das mal
Und wenn Sie Entscheidungen daran beschreiben, dann ist das richtig gut.
Das ist auch richtig gut als Dokumentation, weil wenn später Änderungen passieren,
ist häufig gerade die Entscheidung, dass, was man festlegen muss.
So, zu der Frage, Klassenmodell,
die wir hier hatten, wie sieht so ein Klassendiagramm aus,
Frage 11 und Frage 13, wodurch unterscheidet sich ein Klassendiagramm,
wenn es Problembereich enthält oder wenn es Lösungsbereich enthält oder man sollte im Lösungsbereich Sachen,
die im Klassendiagramm dargestellt werden.
Dazu schauen wir uns mal gleich ein Beispiel an,
das eigentlich erst kommt. Wenn wir Klassendiagramm-Elemente sehen,
ja, also wir haben zum Beispiel hier solche Sachen,
die sehen schon durchaus, das ist ein Klassendiagramm,
ja, die Kästchen sind Klassen, wir gehen gleich durch,
wenn wir zu den Beziehungen des Klassendiagramms kommen.
Aber das, was wir hier sehen,
sind doch eigentlich lauter Sachen aus Anwendersicht. Ja,
er will, dass seine Terminserie eingetragen ist,
dass ein To-Do-Eintrag drinnen getragen ist, dass der einzelnen Termin drin ist.
Es gibt Benutzer, es gibt Einträge, es gibt Ansicht.
Ja, das sind alles Sachen, die auf der
Aufgabenstörung dasteht
Und deswegen, und das auch zum Beispiel,
dass es hier eine Zeit für einen Beginn und eine Dauer
gibt und eben keine Endezeit, sondern nur Beginnung dauert,
das sind eine Entscheidung, die der Auftraggeber getroffen haben kann.
Das heißt, alles das, was wir hier sehen,
sieht sehr danach aus, als wäre es Problembereichsmodell.
Tatsächlich ist das fast eine unentscheidbare Frage. Ja,
man kann ja nicht wissen, ob das hier,
aber hier steht zum Beispiel eine richtige Typangabe,
könnte jemand sagen, ach ja, ist das jetzt was Technisches?
Nein, vielleicht hat da festgelegt ein Format, was ein westliches Format,
was für Informationen zu einem Termin, weil es dazugehört.
Also dieses Beispiel wäre jetzt ein Klassendiagramm,
was das Problembereichsmodell dann stimmt
Für ein Lösungsmodell würden wir hier vielleicht noch ein paar technische Details haben. Wie wird der,
was für ein Datentyp hat die Dauer oder wie sieht,
wie wird das genau implementiert, wenn es verteilt,
implementiert ist, wie sind die Vor- und Nachbedingungen,
wie sind Prüfungen, all das könnten Sachen sein,
die auf technische Entscheidungen zurückgehen.
Es könnten aber auch Sachen sein, die mit der Aufgabenstellung gekommen sind. Das heißt,
am Ende müssen wir bei Frage 11 sagen,
wo ich unterscheidet sich das, die andere Frage umgefrundete,
wie erkenne ich denn das,
ob ein Klassendiagramm zum Problembereich oder zum Lösungsbereich wird,
ganz sicher kann ich das
nicht sagen
Wenn Sie Entscheidungen finden, ist es auf jeden Fall Lösungsbereich.
Das kann man sagen. Aber manchmal stehen ja Entscheidungen
nicht erklärt, sonst steht nur, so ist es.
Und ja, wissen Sie nicht, ist das die Vorgabe gewesen?
Da wäre das Problembereich. Oder ist es das später,
das gewesen, die Realisierung gewesen, dann ist es der Lösungsbereich.
Was ich ja vielleicht zu diesem,
zu dieser Folie noch anfügen möchte, ist,
dass wir die Entscheidung,
die Entscheidung zwischen beiden Unterscheidungen vom Standpunkt abhängt
Steinpunkt, wo in der Fertigungskette, ja,
also stellen wir uns mal vor, es geht um Verschlüsselung, Verschlüsselung von Nachrichten.
Indem wir ein, sie haben so eine Art Check-Tool,
was man für Online-Arbeiten ja gut gebrauchen kann.
Wir möchten, dass niemand mitlesen kann. Wir machen da halt eine Verschlüsselung. Nun könnte das sein,
dass einerseits wir ganz klar sagen,
da gibt es den und den Verschlüsselungsalgorithmus, den wollen wir nehmen,
zum Beispiel, weil sie bei einer Firmenstandort dasteht,
dann ist das Teil des Problembereichs, ja,
weil wir beschreiben den Algorithmus als Vorgabe, als Randbedingung,
als Kennzeichen der Schnittstellen.
So, damit ist das, obwohl es was Technisches ist,
dadurch festgelegt. Wenn wir selbst Entwickler auf dem Schlüsselungsverfahren sind,
kann es sein, dass die Verschlüsselungsverfahren unser Output ist.
Das heißt, wir bekommen als Aufgabenstellung die und die Datenmenge
mit der und der Geschwindigkeit und so und so gut verschlüsselt.
Und wir entwickeln eine technische Lösung, die in einem Schlüsselverschlüsselungsverfahren gipfelt.
Und dann ist das Das meine ich mit Standpunkt. Wenn ich
der Verschlüsselungsentwickler bin, ist die Verschlüsselung selber meine technische Lösung.
Wenn ich der Entwickler des Mail-Systems bin,
ist das eine Randbedingung, die ich einfach nur benutze,
die ich einfach nur umzusetzen habe.
Okay, Verschlüsselungsalgorithmus 1, 2, 3. Ja, so.
Deswegen hängt das, das meine ich mit Standpunkt,
Standpunkt, Standpunkt, wo in der Fertigungskette.
Wenn es meine Aufgabenstellung bekommt, ist es Lösungsbereich.
Ja, also hier haben wir die Aufgabenstellung stehen. Wenn ich das realisiere,
wenn ich die Entscheidung für die technische Realisierung treffe,
ist es für mich Lösungsbereich
und was davon ist,
hängt davon ab