Wir haben bis jetzt in diesem Kapitel ein Modell basiertes Requirements Engineering,
darüber gesprochen, was Requirements sind im ersten Abschnitt.
Wir haben darüber gesprochen, wie wir mit Use-Case-Modellen im Use-Case Diagrammen der UML-Anforderungen darstellen.
Und jetzt im letzten Abschnitt im Voragenten 4-3 darüber gesprochen,
wie Problembereiche und Lösungsbereich bei der Entscheidungsfindung beide betroffen sind,
beide sich abwechseln.
Obwohl wir im Bereich der Antwortungen sind,
werden wir schon Dinge im Lösungsbereich tun.
Das ist nicht nur bei agilen Sym-Systemen so
Wir können noch nicht auf viele Modelle zurückgreifen. Erst im
späteren Fall auf der Lehrveranstaltung werden wir Modelle, Modellierungssprachen,
Diagramme behandeln aus UML und Süßemeldi, die wir hierfür benötigen.
Aber ich möchte schon trotzdem den Rahmen jetzt in diesem Abschnitt bieten.
Und zu dem Rahmen gehört auch, dass wir darüber sprechen,
in welcher Reihenfolge wir etwas machen. Der Abschnitt 4.4,
da geht es darum, wie ein Beispielssszenario ablaufen soll.
Dieses Szenario soll uns einfach nur den Rahmen,
die Folge von Tätigkeiten darstellen,
die wir begehen,
um diese Modelle einzusetzen
Dabei werde ich immer wieder Vorgriffe machen auf Modelle,
die wir eigentlich noch gar nicht auf Diagramme,
die wir noch gar nicht behandelt haben, lassen Sie sich davon nicht stören.
Trotzdem möchte ich, bevor wir so richtig starten,
Sie auf das Buch verweisen, da muss ich schnell mal hier umschalten.
Wir haben, um Ihnen das kurz einzublenden, ja,
wir sind jetzt im Abschnitt 4.4 des Buches,
da geht es genau um das, was Sie hier hier oben,
Ops, hier so, um irgendwie über mir sehen.
Das werden wir jetzt auch besprechen,
dass ich möchte Sie ermutigen, nehmen Sie das Buch,
um etwas nachzulesen, Wir haben das in der Bibliothek zur Verfügung,
auch als digitale Kopie, können Sie das verwenden.
Doch wieder zurück, wir machen weiter. Ohne Buch,
wir werden auf die Fragen später noch eingehen.
Doch ich möchte mal beginnen mit dem Szenario. Auf diese
Folie zeigt zwar die Überschrift, aber schon das erste vom Element.
Ich fange mal an mit einer, mit einer neuen Folie,
mit einem neuen, mit einem leeren Glatt, würde ich mich,
dass Sie auch dazu einladen, dass wir das Szenario kurz skizzieren.
Was ist denn
der Ablauf
Im Modell basierte Anforderungsbeschreibung wollen wir hier durchführen und wir machen
das in der Reihenfolge, dass wir zunächst Problemanalyse durchführen.
Wir nun malieren das auch mal, das ist vielleicht besser,
Problemanalyse als zweites entwickeln wir eine Basisarchitektur
Als drittes Systemidee im System, Ziele.
Das vierte sind das Beschreiben der Stakeholder und der Anforderungen dieser Stakeholder
Das ist sozusagen der Kern, das sind ja eigentlich,
es geht ja um die Anforderungsbeschreibung im Abschnitt 5 oder im Teil den 5,
beschreiben wir das Drumherum des Systems, der Systemkontext.
Das sechste ist dann verfeinert, die Abläufe genauer,
das sind die Anwendungsfälle. Wir hatten vorhin den englischen Begriff US-Cases,
sie können bitte ganz frei entscheiden,
ob sie das im Englischen oder im Deutschen wollen und zusätzlich
weitere Ablaufdetails in Aktivitäten
Und als Siebentens beschreiben wir noch das Fachwissen,
das sind also eher Fakten und Regeln und last but not
least betten wir das Ganze ein in Szenarien,
die weitere Abschnitte des Verhaltens beschreiben.
Damit haben wir so ziemlich umfassende Modelle erstellt,
am Ende, wir wollen das jetzt hier gemeinsam in deiner
Kürze durchgehen und dabei immer schon mal einzelne Diagramme zeigen,
die wir dir später nochmal im Detail besprechen werden,
woraus das Diagramm besteht
In den Abschnitten UML und SüßemL. Wir beginnen mit der Problemanalyse.
Immer geht es uns dabei darum,
ein vollständiges Modell zu bekommen, vollständig im Sinne von widerspruchsfrei.
Wir gehen mal zurück, nochmal zu diesen Prüfkriterien,
der Antwortungsbeschreibung, die wir hier hatten.
Also genau das, was hier steht,
wir wollen am Ende Eindeutigkeit, Vollständigkeit haben, Überprüfbarkeit, Widerspruchsfreiheit.
All das kriegen wir mit einem natürlich sprachlichen Text nicht hin.
Aber mit Modellen, die verschiedenen Aspekte beleuchten,
gelingt es uns doch sehr weitgehend zu merken,
oder fehlt noch was,
oder oh,
das steht im Widerspruch zu etwas anderem
Wir können das nicht ganz ausschließen, dass uns Sachen durch die Lappen gehen,
aber wir können doch weitgehend diese Informationen, diese Ziele erreichen und das Ganze immer.
Eigentlich wollen wir das Ganze ohne Vorgriff auf technische Entscheidungen machen,
aber es müssen schon einige Basisentscheidungen getroffen werden,
die die fachliche Struktur umsetzen in eine Lösung, damit wir überhaupt weiterkommen.
Also wir treffen auch während der Gestaltung mehr in der Strukturierung
der Antwortung, treffen wir Entscheidungen über das System.
Lassen Sie uns starten mit der Lebenanalyse,
diese Problemanalyse beschäftigt sich damit, dass wir erfassen,
welche Aufgaben gehören zum System dazu und dazu eignet sich besonders gut eine Fromm des Workshops,
den wir Problemanalyse-Workshop nennen und dazu ist der Vorschlag eine tabellarische Darstellung zu erwenden,
um diese Informationen zu beschreiben.
Ja, und zwar immer Problemstellung und Lösung dazu.
Wobei Lösungen durchaus etwas sehr noch Abstraktes ist.
Also wir sehen jetzt hier, diese tabellische Darstellung beginnt damit,
dass wir hier drüben auf der linken Seite darstellen.
Was ist ein Problem? Das ist natürlich wieder Text.
Und hier etwas, eine Perspektive umreißen. Diese Perspektive ist
zunächst natürlich sehr vage. Es ist eigentlich die Lösungsidee.
Die Vision sagt ja schon, dass es irgendwie was Projiziertes in
der Zukunft, da ist noch nicht viel Konkretes dabei.
Zusätzlich brauchen wir Informationen darüber, wer sind die Beteiligten.
Der Begriff Stakeholder steht ja dafür für einen Beteiligten am Entwicklungsprozess,
den wir hier brauchen. Wen wir also mit berücksichtigen müssen,
Und dann haben wir die erwarteten Ergebnisse und jeweils auf der
rechten Seite die Lösung bezüglich der Dinge,
wie man sie vereinfachen kann bezüglich der Risiken.
Und ganz oben hatten wir die Vision. Das ist die Struktur,
die man, die wir da vorschlagen,
weiteres zu diesem Workshop, gibt es auch noch,
wir gehen da nicht so furchtbar tief drauf ein.
Ich möchte ja lediglich den Rahmen umreißen,
wie wir hier Modelle einsetzen. Der Einsatz von Modellen,
das wir ändern sich vielleicht ganz an den Anfang.
Ich hatte bei der Definition immer
diesen Zweck genannt
Deswegen brauchen wir, müssen wir hier dieses,
ich gehe noch mal zu diesem Ablauf hier.
Ja, der Zweck ist es eigentlich, wofür brauchen wir Modelle?
Wir brauchen Modelle für die Problemanalyse. Wir brauchen Modelle für
die Basisarchitektur, für Systemitierung, für die Anforderungen,
die die Stakeholder uns geben, für den Kontext.
All dafür brauchen wir Modelle und das ist dann der Zweck dieser Modelle. Das heißt,
dass wir hier über diese acht Schritte eines Beispielszenarios sprechen,
das brauchen wir, sonst könnten wir nicht entscheiden,
welche Modelle für uns hilfreich sind.
Deswegen spreche ich das hier auch mit ihm durch,
aber kurz, weil wir wollen ja uns auf
die Modelle konzentrieren
Der Beispiel für so ein Problemanalyse-Workshop könnte so sein,
dass wir zum Beispiel, wir wollen sowas wie Smart Home machen.
Ja, wir wollen also unsere Einrichtungen unserer Technik im Haus zusammenhängen,
steuern, wenn die Sonne scheint, soll die Shalousie runtergehen.
Wenn der Sturm tobt, soll die Shalousie wieder hochgehen,
damit sie nicht kaputt geht. Wenn wir nach Hause kommen sollen,
die Musik spielen und wenn es tagsüber zu heiß wird,
sollen die Shalousien runtergehen,
damit die Blumen nicht so viel abkriegen und die Blumen überhaupt,
wenn sie Wasser brauchen, sollen gegossen werden.
All sowas. Ja, solche netten,
sie würden sagen, spielt die Spielereien oder andere sagen,
neue Produktideen wollen wollen wir durchaus in einem Beispiel hier mal darstellen.
Und dann ist natürlich die Frage, wer ist denn hier alles beteiligt?
Also das ist ein Beispiel für in diesem,
wenn wir das so uns zu Smart Homes vornehmen,
ist das die Problemstellung erstmal ganz global.
Und dann, bevor wir das verfeinern,
müssen wir überlegen, wer ist alles beteiligt.
Das müssen nicht unbedingt Personen sein. Ja,
die Geräte Standards werden von einer Gruppe von Personen entwickelt und
die dann hier dafür stellen oder Geräteherstellers auch wieder eine Rolle.
Ja, dann haben wir, fangen wir an mit der
Vision der Lösung, die in diesem Workshop rauskommt.
Wir gehen nicht so ganz detailliert auf den Workshop ein
Ja, da steht erstmal das, was die Vision ist,
sie passt sich an die Bedürfnisse der Bewohner an,
sie kann ohne technische Kenntnisse verwendet werden.
Ja, da steht nicht ganz konkret drin, ja,
ohne technische Kenntnisse, Super Usability oder passt sich an attraktiv
und weil wie die Kommunikationsprozesse sind.
Nein, soweit steht es nicht, das ist sehr allgemein. Die Realisierung,
dessen weitere Anforderungen an das System, es soll Assistenten geben,
es soll die Installation und die Benutzung beides unterstützt werden.
Man sollte auch über die Grenzen eines solchen Systems nachdenken,
sonst wird es unbezahlt
Und die Entwicklung wird nie fertig. Hier zum Beispiel,
dass man Ausschlüsse macht, nicht alle Geräte sollen da,
also nicht alle Hersteller. Und man braucht Fachwissen dazu.
Das sind so die kritischen Punkte. Und man hat dann schon mal diskutiert,
was die Idee ist. Das ist sozusagen der erste Schritt,
der uns hilft und diese tabellarische Form hier kann das gut aufnehmen.
Hier steht auch die Quelle drunter, sie finden das im Buch
ein bisschen genauer noch erklärt. Für uns ist wichtig,
dass wir zunächst erst mal beginnen,
das Ganze einzugrenzen Und wenn ich noch mal zurückverweisen darf,
ja, das, was wir jetzt hier gesagt haben,
das ist vor allen Dingen auf der Problembereichsseite.
Nichts davon sagt etwas über die Lösung aus.
Doch als nächsten Schritt sollten wir darüber,
da sollten wir umreißen, wie sollte die Lösung prinzipiell aussehen?
Das heißt, wir kommen zu der Basisidee, zu der Basisarchitektur.
Diese Basisarchitektur, die hilft uns dann zu sagen,
was sind denn die grundlegenden Bestandteile,
damit wir uns mit den Antwortungen auf etwas aus der Struktur
beziehen können
So, ich habe ja mal ein Bild mitgebracht aus dem Buch,
was wie die ganzen Folgenbilder aus dem Buch sind,
die haben, sie taucht immer der Name Slimline auf,
Slimline für die schlanke Linie, die einfache Produkte für die Hausautomatisierung,
für diese Smart Home darstellt, ja,
und wir haben, was hier gezeigt wird,
ist jetzt schon mal ein Diagramm der SISML,
wir greifen da mal vor, das sind Blöcke,
das ist ein Blogdiagramm, das Symbol zeigt hier eine Verfeinung,
sie müssen sich das jetzt noch nicht merken,
wir kommen noch dazu,
das sind die Schnittstellen von diesem Blog Hier und hier,
da steht noch was dran.
Hier gibt es noch weitere Blöcke, ja, also den Sensor,
der vielleicht die Helligkeit misst oder die Temperatur oder sowas, ein Aktuator.
Gut, das ist etwas, was tatsächlich eine Handlung ausführt,
eben die Jalousie hochschaltet und das Licht ein und das Radio
an oder was auch immer.
Und das ganze Gerät soll diese Plattform,
das System soll eine Anzeige teilhaben und ein Steuerungsteil.
Es soll gekoppelt sein mit externen Geräten, ja,
also vielleicht noch hier eine App,
die irgendwo läuft oder etwas,
was auf dem Smartphone läuft
Diese Darstellung, wenn sie wollen, ist schon etwas Technisches.
Ja, aber sie umgibt erstmal den Rahmen. Sie sagt,
erlaubt uns überhaupt zu sagen, wo sind die Systemgrenzen?
Wo sind wesentliche Schnittstellen, über die wir mehr Informationen brauchen?
Zum Beispiel müssen wir wissen, was für Informationen liefert dieser Sensor?
Wie soll der Austausch stattfinden? Welche Bedienenfunktionen sollen hier drauf sein?
Wie sollen die hier interagieren? All solche Fragen kann man erst stellen,
nachdem man überhaupt so ein grundlegendes Bild gemacht hat.
Wie gesagt, das ist ein Diagramm der SISML,
wir werden noch darauf zurückkommen,
das war jetzt der zweite Schritt hier,
Vielleicht sollten wir das hier, doch, basisrechtlich durch,
steht rüber. Und jetzt kommen wir als nächstes System-Idee-System-Ziele.
Das hatten wir in unserer Tabelle ja schon drin,
indem wir so eine Vision haben hatten.
Ja, also hier hatten wir schon diese Vision schon ein bisschen drin.
Vision hat was mit Zielen zu tun. Tatsächlich ist es so,
dass wir die Systemziele noch etwas genauer darstellen können.
Und wir versuchen dafür auch, Modelle zu verwenden.
Mit der Systemaidee und den Systemzielen ist eine ganz wichtige Kommunikationsanforderung
Bei der Anführungsanlyse hatten wir ganz vorher ganz zu Anfang gesagt,
es soll ein gemeinsames Verständnis erreicht werden.
Und dieses gemeinsame Verständnis muss natürlich unbedingt die Systemziele umfassen.
So, wenn wir jetzt gesagt haben,
ja super, wir machen das mit Modellen,
so ist das so etwas vages wie eine Vision,
wie Ziele schwer in grafische Darstellung zu fassen.
Deswegen ist es durchaus ganz okay, dass man das textuell darstellt.
In den Modellierungssprachen sind fast immer Möglichkeiten für eine Text,
für einen Textblock da.
Also man nimmt so ein Ding und schreibt hier etwas rein.
Hier in dem Fall sogar so ein bisschen strukturiert,
System-Idea und dann kommt ein Text
So wie wir das in der Programmiersprache auch kennen, als es dringend mit Anführungszeichen eingezogen.
Und das ist durchaus okay, dass man das so macht.
Und wir sollten versuchen, auch das gleich den Stakeholdern zuzuordnen, denn die verschiedenen Stakeholder können durchaus unterschiedliche Ziele haben. Ja,
also der CIO, der Firmenchef, der kann andere Vorstellungen haben,
weil er den Markt im Blick hat und Gewinnziele,
Entwicklungsziele, strategische Kooperationen mit anderen Unternehmen, ja,
dass dann am Ende sagt, okay,
im Netzwerkschnittstelle will ich da so und so bedienen oder ich will den Standard unterstützen sowas,
oder ich kenne die Anforderungen, ja,
und wir können durchaus auch noch weitere Stakeholder, wir können sagen,
was ist der, was ist aus Sicht des Endkunden wichtig,
was ist aus Sicht des Systemlieferanten wichtig,
was ist aus Sicht des Operatings wichtig,
wenn wir dann vielleicht noch gefahren Überwachung oder sowas mit hinzunehmen.
Dieser zweite Punkt, das System,
oder war es schon der dritte, nein, der dritte System,
wie die Systemziele, ist also vorrangig, textuell dargestellt,
hilft uns aber beim gemeinsamen Verstehen, die Strukturierung,
die Zuordnung erfüllt auch so eine Forderung,
dass wir nachprüfen können.
Zum Beispiel gibt es denn für jeden Stakeholder
auch solche Ziele
Die Stakeholder sind auch das Nächste,
was wir hier in unserem Szenario in unserem Ablauf weitermachen,
nämlich die Stakeholder und deren Anforderungen sind das,
was wir jetzt weiter verfolgen, was wir weiter zusammenfassen.
Und dabei haben wir hier von unserem Beispiel,
haben wir verschiedene Stakeholder aufgelistet, ja, der Besitzer,
der Anwender, der Gerätehersteller,
durchaus auch andere externe Leute, der Wetterdienst,
der Firmenchef oder die Standard,
das Standardisierungskonkonsortium
Wir geben den Prioritäten im Sinne,
wie wichtig sind deren Anforderungen. Sie erinnern sich vielleicht,
oder ich gehe nochmal zurück zu diesen Kriterien, ja,
für die Anforderungsbeschreibung, die ja am Ende unserer Richtschnur des Handelns ist.
Ja, wir wollen hier das verfolgen. Ja,
hier war die Rückverfolgbarkeit und es war noch irgendwo Herkunft.
Diese Begründung, diese Herkunft ist es am Ende,
was uns hilft, Prioritäten zu vergeben.
Und diese Prioritäten brauchen wir insbesondere in Fällen,
wo wir widersprüchliche Anforderungen konkurrierende Anforderungen.
Der eine will das,
der andere will das
Und dann helfen, helfen uns diese Prioritäten,
zu entscheiden, welche Anforderungen ist denn für uns wichtiger,
welche kümmern wir uns zuerst und welche müssen gegebenenfalls zurücktreten,
wenn wir uns nicht beides erfüllen können.
Hier hat man noch zusätzlich deren Aufwand und die Aufwand für
diese Anforderungen mit hineingestellt und dann noch gesagt,
auf welcher Seite sind die denn?
Was daran, wenn sie fragen, ist denn jetzt Modellierung,
was sind Modelle? Ja, das Modell ist ihr,
dass wir Bezüge herstellen. Ja,
weil wir zum Beispiel diesen Immobilienbesitzer im Use Case Diagramm als Akteur
drin haben oder CEU oder der Wetterdienst als beteiligter Partner.
Das Modell erlaubt es uns, diese Dinge im Use-Case-Diagramm darzustellen.
Ich glaube, jetzt kommt hier eins, genau,
hier kommt ein Use-Case-Diagramm, wo wir zum Beispiel sagen,
ja, hier ist ein Sensor als Beteiligter.
Wir hatten weiter vorher auch darüber Use-Case Diagramme besprochen. Ja,
also hier war der Benutzer ein Administrator in diesem Kalenderbeispiel.
So, da wir soweit zu den Stakeholdern und ihren Anforderungen
und weitermachen wir mit dem System Kontext.
Das ist das Nächste, das ist das,
was außen herum ist
Ja, wir hatten bei der Basisarchitektur, das war der zweite Punkt,
da hatten wir ja schon gesehen, ja okay,
da gibt es Sachen, die außen herum sind.
Und wenn das unser System steht,
hier steht es auch drin, gibt es eine Kennzeichnung,
dass dieser Block ist unser System, um das es geht,
dann müssen wir genauer untersuchen, was ist denn das,
was außen ist.
Das hilft uns dann, die Schnittstellen richtig zu identifizieren,
Informationen über die Schnittstellen zu sammeln. Ja,
wir hatten bis jetzt den Blick übers Ziel und Stakeholder
auf das System gerichtet und jetzt geht es um den
Kontext darum
Schauen wir uns den Kontext etwas genauer an. Wir haben hier wieder
das System. Wir haben jetzt hier innen drin keine Details,
aber dafür haben wir genauer, was außen ist.
Ja, wir haben also zum Beispiel wieder den Sensor,
den wir schon gesehen hatten, im Diagramm vorher in der Basisarchitektur.
Das Smartphone hatten wir auch noch. Aber jetzt gibt es
noch weitere Auswärtstage Sachen, die man außen hat,
dieses External System, die Applikation, das war vorhin auch da.
Aber das Internet, innernetbasierte Systeme, die irgendwo in
der Cloud oder woanders sind, hatten wir nicht dabei.
Und den Aktuator, also das Stellenwerkzeug,
was er tut,
das beeinflusst wirklich Handlungen auslöst
In unserem Smart Home. Das hatten wir auch nicht dabei
. Außerdem sind hier noch Stakeholder richtig mit dargestellt,
weil sie direkt mit Anforderungen verbunden sind,
die dann als Use-Case-Träger oder Trigger hier Kommunikationspartner mit drin sind.
Selbst der Anwendungsentwickler, der am Ende die Anforderungen umsetzen muss,
ist hier mit dabei. Das ist, zeigt uns oder
dieses Diagramm zeigt uns nur den Überblick.
Natürlich müssen wir hier genauer wissen, welche Schnittstellen das sind.
Wenn wir hier zurückgehen, ist der nächste Punkt dann zu sagen,
wie in der Wie agieren die denn?
Wie spielen die denn zusammen? Und jetzt kommen wieder diese
Use-Cases. Wir hatten eben schon eine Anforderung als Use-Case,
jetzt kommen diese Use-Cases wieder, die wir vorhin im Abschnitt 2 schon,
4-2 schon hatten.
Ja, die Anwendungsfälle spielen jetzt hier wieder rein.
Und diese Anwendungsfälle sind es, die dann sagen,
was machen die verschiedenen Stakeholder mit uns?
Ja, also das ist so ein Beispiel für Anwendungsfälle,
ein Diagramm mit Anwendungsfällen haben wir jetzt hier dargestellt.
Ja, wir haben den Bewohner und gibt es ein Use-Case
mit dem Haus betreten. Da passiert etwas mit Sensorenaktoren,
vielleicht das Smartphone, wie etwas Informationen einzustellen oder etwas abzurufen.
Ja, andere Use-Case-Hausphasen und so weiter. Sie kennen das
schon, was wir bei 4-2 behandelt haben.
Use-Cases sind Lipsen, da gibt es die Kommunikationsbeziehung.
Da gibt es die Akteure als Strichmännchen. Ja,
und das ist jetzt eine Information, die weitergeht und die genauer sagt,
was ist denn hier passiert denn hier zwischen System und Bewohner?
Ja, wir wollen schrittweise Informationen zusammentragen und diese Informationen in Form von Modellen packen.
Werden wir hier dieses Diagramm als Klassendiagramm sokratisch noch akzeptieren.
Ja, Kästchen und Linien, das kennen Sie vermutlich alle schon irgendwoher.
Und dieses Swiss Case Diak haben wir tatsächlich schon behandelt haben,
hatten wir dieses MLD Akramme noch nicht. Dieses Anwendungsfall Diagramm
hat mir dieses Use Case Diagramm, wissen Sie, sollte,
hat, jeder Use Case sollte hinterlegt sein durch genauere Abläufe.
Das waren diese Use Case Beschreibungen. Ich springe mal zurück
zu 4-2. Wir haben ja die Folien hier noch dabei.
Da gab es diese Use Case Beschreibung, ja,
wo wir gesagt haben,
für jeden Use Case hinter so einer Alypse liegt als Textbeschreibung so ein strukturierter Text,
wo ich Vorbedingungen, Nachbedingungen noch mal drinstehen und hier gerade drei verschiedene Typen von Ablaufbeschreibungen.
Diese Ablaufbeschreibungen helfen uns natürlich, das Systemverhalten zu verstehen und
tatsächlich auch hier zu beschreiben. Tatsächlich treffen wir hier Entscheidungen.
Wie reagiert das System im Fehlerfall? Obwohl wir weit weg sind von Implementierung,
wir sind ja erst beim Beschreiben der Anforderungen, enttreffen wir Entscheidungen,
wie das System sich verhält, zum Beispiel im Fehlerfall.
Wir gehen aber wieder zurück zu dem, was wir hier in unserem Ablauf machen.
Also wir hatten Anwendungsfälle beschrieben und wenn wir jetzt das Verhalten beschreiben,
kann es sein, manches von den Verhalten ist sehr einfach,
dann sind das wirklich nur ein paar Stichpunkte.
Wenn es komplizierter wird, brauchen wir tatsächlich dafür vielleicht auch Diagramme.
Und so ein Diagramm möchte ich hier kurz mal darstellen.
Das ist die nächste Folie. Hier im Ablauf,
das ist ein Aktivitätsdiagramm der UML.
In dem Fall erweitert durch die Sys-Emmel ein bisschen.
Wir haben hier einen Startknoten, dann gibt es hier Aktivitäten.
Wir werden noch auf dieses Diagramm eingehen. Und hier kann man den Steuerfluss sehen,
also das ist die Reihenfolge und hier den Datenfluss,
wo man sagt, welche Ports,
welche Pins,
was wird da übergeben
Wie gesagt, wir kommen noch weiter drauf. Das ist
ein Diagramm, was es grundsätzlich in der UML gibt,
das Aktivitätsdiagramm, praktisch das verfeinert ein bisschen genauer.
Man könnte diesen ganzen Darstellungen natürlich als Text machen. Man könnte sagen,
dass da Normalablauf, hier schon mit einem Sonderfall noch dabei.
Aber wenn das ein bisschen komplizierter wird,
ist es schon besser, Missverständnisse auszuräumen,
indem man das grafisch oder eben auch textuell jedenfalls strukturiert darstellt.
So, das war in unserem Ablauf der Punkt Anwendungsfälle
und Aktivitäten
Damit haben wir schon relativ viel beschrieben. Ja, wir
wissen, wie die grundlegende Architektur aussieht. Wir wissen,
die Ziele, die Anforderungen jedes Denkholders, wir wissen,
was ist drumherum, die Schnittstellen, wie es arbeitet,
das System mit diesen Partnern zusammen.
Aber es gibt noch Sachen, die übergreifend sind,
die der Entwickler wissen muss, berücksichtigen muss,
das sind zum Beispiel Regeln, Fachwissen, so etwas.
Zu dieses Fachwissen kann man natürlich am besten mit Text beschreiben.
Begriffe erläutern im Sinne eines Klosars oder auch Regeln beschreiben,
wenn dann, was passiert da,
das kann man durchaus strukturiert tun
Aber wir können auch Diakrammer benutzen, um sowas darzustellen.
Zum Beispiel so ein Diagramm, in dem Begriffe zusammengefasst werden.
Wir haben hier zum Beispiel so etwas,
dass wir das Konzept des Benutzers erläutern.
Was ist ein Benutzer? Das ist jetzt hier in Textform
. Ja, es gibt also in der UML,
und das ist im ML so ein Element, das nennt sich Notiz.
Da kann man durch diese umgeknickte Ecke als Text auf einem
Papier sozusagen verdeutlicht. Und ich kann hier darstellen,
was passiert denn, was macht dieser Benutzer?
Und das ist hier als fachliches Konzept
Gekennzeichnet, indem man hier dieses Domain-Glas drangeschrieben hat,
dass das hier mit den stoppelten Spitzenklammern, die uns hier immer wieder auftauchen,
auch was zu sagen hat, dazu werden wir noch kommen.
Ich verrate schon mal so viel, das ist ein Stereotyp,
eine genaue Kennzeichnung von einem Diagramm-Element. Also das ist eines der Elemente,
die wir haben,
aber wir können auch die Sachen noch darstellen als ein Diagramm,
wo die verschiedenen Begriffe zueinander die verschiedenen Konzepte zueinander im Bezirk stehen,
ja, also der Benutzer, der hat Regeln,
die Regeln gehören zu Geräten und die Geräte verfügen über Sensordaten die dann am Ende in den Regeln verarbeitet werden können.
Sowas kann man noch darstellen, wenn die Zusammenhänge komplizierter sind.
Könnte man das noch machen, dass man genauer sagen kann als im Text,
welches fachliche Konzept hat da mit welchem anderen zu tun?
Das kann man dann durchaus am Ende verwenden,
um zum Beispiel Sichtbarkeitsregeln zu bearbeiten, zu sagen,
wer darf den wen sehen?
Also die brauchen sich ja nicht zu sehen,
aber über Gerät wäre die Verbindung dann nämlich trotzdem dargestellt.
Das wäre das fachliche Modell,
das Fachwissen repräsentiert einerseits als Text und andererseits hier als Modell
Springen wir wieder zurück zu unserem Ablauf. Da fehlte es nicht mehr viel,
sondern es fehlt nur noch, dass wir weiteres Verhalten darstellen wollen.
Und da können wir Szenarien dazu benutzen, in Ergänzung zu den Szenarien,
die wir als Anfettungsfell, Anforderungsanwendungsfälle und Aktivitätsdiagrammen hier schon hatten.
Für diese Szenarien lassen sich ganz gut Sequenzdiagramme verwenden,
eine andere Form von Verhaltensdiagrammen,
in diesem Fall durch die UML definiert, als Diagramm der UML.
Auch hier werden wir, verschiebe ich einfach,
das noch ein bisschen weiter nach hinten.
Die Elemente können wir noch später noch im Detail anschauen,
die es hier gibt. Auf jeden Fall kann ich sagen schon mal,
das sind Zeitachsen, die von oben nach unten laufen.
Hier sind Nachrichten, die die Systeme von miteinander austauschen.
Es geht wieder hin, es geht zurück.
Man kann die Reihenfolge hier ein bisschen genauer beschreiben.
Man wird das nur für einzelne Szenarien machen,
wo ein Aktivitätsdiagramm die Informationen nicht über das Zusammenspiel nicht so darstellt.
Aber dieses Diagramm zeigt uns immer nur ein Zusammenspiel.
Nicht die alle, dann wäre das zu unübersichtlich.
Wichtige Abläufe, wichtige Szenarien kann ich hier noch präziser beschreiben.
Damit haben wir sozusagen den Bogen schon geschlagen,
aber ich möchte gerne mit Ihnen nicht aufhören,
bevor wir noch sagen,
was hilft uns
das Ganze
Das ist der Rebisch hier mit ganz vielen Diagrammen um die Ecke gekommen.
Wozu brauche ich die? Wir brauchen die natürlich vor allen Dingen dann,
wenn die Zusammenhänge komplex sind, wenn es uns ohne diese Darstellung
explizite Zusammenhänge von Darstellung nicht gelingt, etwas zu beschreiben.
Und ich bringe jetzt mal zu den Fragen,
die wir bis jetzt noch gar nicht betrachtet haben und möchte mit ihnen anhand dieser Menge an Darstellung,
die wir jetzt hier im Szenario gesehen haben,
in dem Ablauf gesehen haben, mit ihnen diskutieren,
was da eine Rolle spielt, wie das zusammenhängt.
Und ich hoffe, wir kommen da noch zu einer
interaktiven Diskussion, dann,
wenn wir uns darüber unterhalten
Zu den Fragen, da haben wir, ja,
die Frage 6 hatten wir schon behandelt,
als wir UML, Use-Case Diagramme und die Use-Case-Beschreibungen haben.
Sie wissen noch ganz genau, ja,
dass Use-Case Diagramme sagt nicht so viel und diese Beschreibung sagen über Vor- und Nachbedingungen,
Informationen, die ich beim Test brauchen kann und über diese verschiedenen Abläufe Informationen,
die mir helfen, das Ganze zu prüfen, zu implementieren.
Warum haben wir denn jetzt die Stakeholder in Modelle auch noch reingepackt? Ja,
wir hatten also hier dieses Diagramm, ich muss mal dein Stückchen vorgehen,
dass dieses Diagramm mit dem Systemkontext, wo ist es nochmal?
Ich kann es Ihnen gleich hoffentlich gleich zeigen.
Also wir hatten zum einen die Stakeholder hier so aufgelistet.
Und wir hatten aber auch noch die Stakeholder, ach ja,
hier in diesem Diagramm waren Sie mit dem Systemkontext.
Warum haben wir die Stakeholder hier drin? Ja, weil
die Stakeholder mit anderen Forderungen verbunden sind. Also jeder Stakeholder hat hier Anforderungen,
die Anforderungen sind im System,
in der Menge der Antwortungsbeschreibungen mit ihm verbunden,
sodass wir immer noch sagen können,
wenn wir Prioritäten setzen wollen,
wem von neben nehmen wir denn was
Das wäre die Antwort auf diese Frage mit dem Stakeholder.
Gehen wir weiter. Die Fragen setzen sich fort. Wir
haben Beziehungen zwischen den Modellen. Und diese Beziehungen zwischen den Modellen,
wir hatten diese Kategorien von Werkzeugen im vorhergehenden Abschnitt.
Und sie erinnern sich ja, diese Werkzeuge mit dem Repositorie.
Das Repository, ich schalte mal um zu dem Bildchen dazu.
Das ist die Folie aus dem Abschnitt Werkzeuge.
Da hatten wir ja diese Modellierungswerkzeuge mit dem Repositorie.
Das ist die Kategorie C hier
Die, wo die, in dem sind die Modellelemente alle zusammengeführt.
Das heißt, und nun springe ich wieder zurück zu unserem Bild,
was wir gerade hatten. Da war das, die Systemarchitektur,
die uns das darstellt, nein, wo ist es denn?
Da muss ich nochmal schauen. Wir hatten dieses, das System,
Baustein, den hatten wir zum Beispiel hier in der Basisarchitektur oder hier im Systemkontext.
Und dadurch, dass wir das immer über Repository haben,
ist, dass jedes Mal das gleiche Modell-Element.
Wir stellen nur das in einer anderen Sicht dar.
Hier mit mehr Details, die wird dann später hinzugefügt haben.
Und das gelingt uns auf diese Weise, das Verhalten,
die Strukturen, die Beziehungen immer weiter zu ergänzen.
Wir haben die Informationen im Repository, die wir nach und nach vervollständigen.
Und das geht natürlich nur mit diesen Werkzeugen, wo die Informationen zusammengeführt werden.
Das war also die Antwort auf die Frage, Moment, jetzt muss ich mal hier vorspringen, war das nochmal Genau. Hier,
ja, also die Beziehungen zwischen den verschiedenen Modellen,
das war bei dem Repositive, bei dieser Kategorie C,
das war die Möglichkeit, dass wir dort auch Prüfungen machen können,
was ist denn was von den Modellelementen ist denn vielleicht noch gar nicht verbunden oder welche Beziehung gibt es denn da oder gibt es da Beziehungen,
Verbindungen, wo wir sagen können, das ist jetzt übergriffig irgendwie,
wir sollten das besser voneinander trennen,
eine bessere Struktur entwickeln, um unabhängige Module zu gewalten.
Die nächste Frage 9 bezieht sich auch auf diesen Systemkontext,
warum stellen wir Dinge, die eigentlich gar nicht zu unserem System gehören,
trotzdem da, Das ist die Frage, was brauchen wir daraus?
Der Zweck der Modellierung, das sollte uns klar sein,
welche Informationen wollen wir denn darstellen?
Wir springen wieder zu diesem Bildsystemkontext, was hier angesprochen wird.
Ja, also gemeint ist das, was hier außenrum ist.
Wir brauchen diese Schnittstelle, wir brauchen Informationen über diese Schnittstelle,
indem wir beschreiben, was macht dieser PC und wie arbeitet er mit unserem System zusammen?
Was passiert auf dem Smartphone? Wie arbeitet es mit unserem System zusammen?
Was für einen Austausch an Nachrichten, an Daten, was passiert hier?
Was für eine Reihenfolge gibt es da ein bestimmtes Protokoll?
Gibt es bestimmte Use-Cases, die hier gemeinsam bearbeitet werden.
Das Gleiche mit dem Sensor oder dem Aktuator. Also dafür
hilft uns dieses Diagramm, den vollständigen Blick zu bekommen.
Die nächste Frage bezieht sich auf Modelle für Problemraum und Lösungsraum
. Ich hatte bei dem Zickzack-Pattern durchaus gesagt, ja,
manche Sachen davon sind Lösungsraum, um diese Frage zu beantworten,
nebenbei müssen sie natürlich jetzt wieder wissen, was ist Problemraum,
was ist Lösungsraum, das sollten wir durchaus,
das ist eine Frage,
die immer wieder kommt,
die wir unbedingt klar beantworten müssen
Also das hatte ich hier auf diese Folie so ein bisschen
hier oben mit reingequetscht. Sie sollten in der Lage sein,
klar zu unterscheiden, Problemraum, das sind die Anforderungen,
die konzeptionelle Beschreibung, was es zu bauen, Lösungsraum,
wie es etwas zu bauen, die technische Lösungen.
Wie unterscheiden sich, das ist der Kern dieser Frage jetzt,
wie unterscheiden sich die Jagramme zwischen Entscheidungen über technische Lösungen und Anforderungen?
Wenn Sie jetzt denken, ja, bei Anforderungen sind nur technische Inhalte,
bei hier Unsinn nur technische Inhalte,
es sind keine technischen Inhalte, klingt das erstmal naheliegend,
aber dabei liegen sie durchaus falsch,
weil manchmal gibt es auch Anforderungen,
die durchaus technische Anforderungen sind
Denken Sie daran, dass wir Rahmenbedingungen haben?
Ich springe mal ganz an den Abschnitt Anfang von Abschnitt 4,
als wir gesagt haben, was sind diese drei Typen von Anforderungen?
Wo waren die das hier? Ja, da gab es
diese Rahmenbedingungen. Und die Rahmenbedingungen, das sind durchaus technische
Dinge, die eine Rolle spielen. Also,
es reicht nicht zu sagen, technisch und nicht technisch,
sondern die Modelle unterscheiden sich letztlich nur dadurch,
dass bei den einen technische Entscheidungen drin sind,
während bei den anderen sind es nur Gegebenheiten,
die aus der Aufgabenstellung kommen
Unterschied. Ansonsten haben wir tatsächlich fast die gleichen Modelle,
fast die gleichen Diagramme. Wir können ein Zustandstiagramm,
wir können eine Aktivitätsdiagramm auch in Komponentendiagramm machen,
sowohl über die fachlichen Dinge, die im Problemraum der Aufgabenstellung existieren,
als auch in den Sachen,
die wir dann bei der technischen Lösung, als jetzigen Zeitpunkt betrachtet,
später machen werden.
So, die letzte Frage machen wir im nächsten Abschnitt,
wenn es um ausführbare Spezifikationen geht