In diesem Video geht es um die Erstellung von Use-Case-Diagrammen und Use-Case-Beschreibungen.
Ich möchte das anhand eines kleinen Beispiels machen,
indem ich einfach eben ein solches Diagramm und eine Beschreibung erstelle
und dabei laut denke, um sie auf dem Weg mitzunehmen.
Voraussetzung dafür ist, dass sie das Thema 1,2 der Vorlesung
von Professor Riebisch kennen. Das ist die Use-Case-Modellierung mit OML
, sowie das Thema 1,4 der Vorlesung von Dr. Gritzern.
Das ist das Kanu-Modell der Kundenzufriedenheit. Zudem sollten sie zunächst
das Textdokument Szenarien und Anwendungsfälle lesen, dass sie im Material
zur Übung finden.
Ich werde in diesem Video das gleiche Beispiel verwenden
Diese Folie sollte Ihnen dann bekannt vorkommen. Dort geht es
um die Identifikation von Use Cases. Zunächst sammeln Sie die Kundenwünsche
und analysieren vor allem Textdokumente und suchen eben nach Informationen,
was wirklich jemand mit dem System tut.
Also werben mit Tätigkeitsbeschreibung. Wir werden uns Gedanken machen müssen,
was echte Use Cases sind, also wie man Einzeltätigkeiten zusammenfasst
oder eben was überhaupt zum System dazu gehört.
Zunächst nehmen wir erstmal alles auf,
was uns irgendwie einfällt und müssen dann überlegen,
wie wir das sinnvoll darstellen und zusammenfassen können
Die beiden unteren Punkte sind dann die konkreten Tätigkeiten,
nämlich das Erstellen der Use-Case-Beschreibung. Und dies Erstellen eines Use-Case-Diagramms.
Ich werde das für dieses Video nacheinander machen und auch in umgekehrter Reihenfolge,
nämlich zunächst das Use-Case-Diagramm, vorstellen und dann die Use-Case-Beschreibung.
Bei einer tatsächlichen Tätigkeit ist es natürlich sinnvoller,
beides parallel zu erstellen,
aber dann müsste ich im Video
ständig hin und her springen
Ich habe hier einmal einen UML-Editor geöffnet,
das ist in diesem Fall die Webapplikation vor allem Dialgrams.net,
beziehungsweise Draw IO, aber das Verfahren ist für alle Editoren
natürlich gleich und die sehen auch alle ziemlich ähnlich aus.
Was wir zunächst anlegen können, ist ein sogenannter Frame,
das ist quasi der Rahmen für so ziemlich jedes für jedes UML-Diagramm,
das es gibt,
das zeigt uns quasi an,
was ist das für ein Diagramm und für den Anfang reicht es aus,
wenn wir eben die Art des Diagramms OC für Use Case
in die Ecke schreiben
Was wir als nächstes brauchen, ist das System.
Das ist nichts Spezielles für UML, sondern einfach ein Rechteck.
Alles, was innerhalb dieses Rechtecks ist, ist im System.
Alles, was außerhalb des Rechtecks ist,
ist außerhalb des Systems. Wenn wir möchten,
können wir unserem System auch noch hier ein Namen geben,
was natürlich vor allem sinnvoll ist, wenn wir mehrere Systeme entwickeln.
Das muss nichts Wichtiges sein, das kann auch einfach
Filmsystem sein. Oder wenn wir einen Namen haben,
können wir den auch vergeben, nennen wir unser System nochmal MyMovies.
Was jetzt natürlich für das Use-Case-Diagramm dazugehört,
sind Use-Cases, die gehören in das System
Meistens zumindest. Und Akteure, die sich außerhalb des Systems befinden.
Das sind die zentralen Elemente. Nun müssen wir uns natürlich Gedanken machen,
was überhaupt ein Use-Case ist und was überhaupt ein Akteur ist.
Bei den Use-Cases hatten wir schon gesagt,
wir suchen nach Tätigkeiten, nach Tätigkeitsbeschreibung,
können da aber natürlich viel zu allgemein sein.
Also wir könnten ein Use-Case-System benutzen, verwenden und der sagt uns überhaupt nichts.
Auf der anderen Seite können wir viel zu sehr ins Detail gehen.
Wenn wir also Buchstaben eingeben als eigenen Use-Case haben,
dann werden wir hunderte,
vielleicht tausende Use-Cases
für ein einzelnes System brauchen
Wir brauchen also irgendetwas dazwischen. Auch bei den Akteuren
müssen wir uns überlegen, was eigentlich ein Akteur ist.
Denn das, was hier steht, Actor oder zu Deutsch Akteur,
ist sehr allgemein. Das hilft uns wenig, zu sagen,
was für eine Rolle diese Person oder diese Personengruppe im System einnimmt.
Auf der anderen Seite, na. Wollen wir auch hier nicht
zu spezifisch werden. Das heißt, ich möchte nicht für
jeden möglichen Benutzer und jede Benutzerin einen eigenen Akteur hier anlegen.
Was eher gedacht ist, ist sowas wie,
Hier ist ein Benutzer des Systems mit normalen Zugriffsrechten zum Beispiel,
während auf der anderen Seite.
Ein Administratorin tätig ist. Die können dann auch auf verschiedene
Weisen mit dem System interagieren. Das heißt zum Beispiel,
hier könnte jemand Daten ansehen und in einem anderen Use Case
könnte man Daten verändern.
Und dann haben wir unterschiedliche Berechtigungen, also ein einfaches Use
Case Diagramm mit zwei Akteuren
könnte so aussehen
Dass eben ein Use-Case von beiden Akteuren, also an einem Use-Case
beide Akteure beteiligt sind und an einem anderen Use-Case nur einer der Akteure.
Gut, jetzt wollen wir aber zu unserem Beispiel,
nämlich diesem kleinen Filmsystem,
dafür können wir das Ganze nochmal wegnehmen hier und uns erstmal anschauen,
was für Use-Cases haben wir denn.
Also was für Tätigkeiten soll jemand mit dem System vornehmen können?
Und in der Textbeschreibung stand da schon das Beispiel,
dass es eben ein System ist,
um die private Filmsammlung zu erfassen.
Also muss ich
irgendwie einen Film erfassen können
Nun könnte man überlegen, dass vielleicht zusammen auch mit der Use-Case-Beschreibung,
die wir heute aber erst im Nachhinein machen,
was denn das bedeutet, wie das abläuft.
Das heißt, in irgendeiner Weise,
wenn ich dem System einen neuen Film hinzufügen möchte,
muss ich natürlich sagen, dass ich das möchte,
gebe ein paar Daten ein und das System macht das.
Klingt doch soweit ganz simpel. Vielleicht gibt es da noch
ein paar weitere Fälle, die wir mit aufnehmen möchten,
aber wir können hier erstmal filmen hinzufügen als einen Use-Case betrachten.
Für jeden Use-Case Ist nun natürlich die Frage,
wer ist damit in Verbindung zu setzen?
Also welche Akteure vor allem? Und was für Akteure hat unser Filmsystem?
Gut, es ist die Verwaltung einer privaten Filmsammlung.
Also ist der Filmsammler oder die Filmsammlerin natürlich ein Akteur.
Und damit haben wir den ersten Use Case. Nun hatte ich
eben auch gesagt, dass das Kanon-Modell der Kundenzufriedenheit relevant sein könnte.
Denn auch wenn eine Anforderung nicht explizit aufgeschrieben ist,
könnte sie natürlich erforderlich sein. Also wenn ich einen Film hinzufügen möchte,
bringt mir das reichlich wenig,
wenn ich dann nicht wenigstens auch die Filme ansehen kann,
die ich denn habe.
Das heißt, ich bräuchte einen weiteren Use Case Filmliste anzeigen
Ja. Die Anordnung innerhalb dieses Diagramms ist natürlich nicht wirklich relevant für die Bedeutung.
Es hilft natürlich beim Verständnis des Diagramms, wenn das jemand lesen soll.
Also sollten sich nicht zu viele Linien kreuzen und inhaltlich ähnliche Elemente sollen zusammenstehen. Gut,
jetzt können wir noch drüber nachdenken,
wir können einen Film hinzufügen und die Filmliste anzeigen,
naja, vielleicht vertippen wir uns,
wollen Filmbeschreibungen ändern oder ein Film geht kaputt,
wir werfen ihn weg oder wir verschenken ihn,
dann wollen wir den Film aus der Liste auch wieder entfernen.
Also sollte zumindest Film entfernen dabei sein. Und dann kann man,
wenn es auch nicht besonders nutzerfreundlich ist,
bei einem Tippfehler den Film entfernen und zumindest nochmal neu anlegen.
Das heißt, das ist unser erstes kleines Use-Case-Diagramm für das Beispiel Filmsystem.
Und dann springen wir einmal rüber in die Use-Case-Beschreibung.
Die kommt dann noch hinzu. Das heißt,
wir möchten diese Basiselemente der Use-Case-Beschreibung erstmal nur ausfüllen,
nämlich Akteure, Durchführung, Alternativen,
Bemerkungen und möglicherweise zugehörige Glossareinträge
Wir werden im Verlaufe des Übungsthemas eins auch auf weitere Elemente,
wie beispielsweise Ausnahmen, Vorbedingungen und Nachbedingungen zu sprechen kommen.
Gut, hier oben gehört eine ID rein,
das heißt, wir nummerieren unsere Use Cases einfach durch,
damit wir schneller eine Referenz darauf haben können,
da wir jetzt gerade erstmal nur einen betrachten,
ist das einfach mal Use Case 1.
Und wir nehmen jetzt als Beispiel das Hinzufügen eines Films. Gut,
die Akteure, die beteiligt sind, sind natürlich diejenigen,
die auch im Use Case Diagramm verknüpft sind,
in diesem Fial ist es
die Filmsammlerin
Unter der Durchführung überlegen wir uns,
was denn dabei passiert, wenn dieser Use-Case ausgeführt wird.
Das heißt, wir möchten jetzt einen Film hinzufügen.
Also möchten wir irgendwie dem System sagen, füge diesen Film hinzu.
Also in irgendeiner Weise, sagen wir mal,
erstmal ganz grob, Eingabemaske öffnen und Daten eingeben.
Und dann könnten wir immer sagen, das ist Schritt 1.
Und Schritt 2 wäre dann, bestätigen.
Und System nimmt das auf. Also irgendwie Eintrag wird erstellt
Das ist in ganz knapp,
ganz nahbarer Form eben die Durchführung von dem Use-Case.
Und jetzt wollen wir das noch ein bisschen ausformulieren und können
uns dabei einfach mal Gedanken machen, was dabei passiert.
Also, wenn wir schon einen oder mehrere Akteure dabei haben,
dann sollten wir auch immer mal überlegen,
was tut denn der Akteur und was tut das System?
Und in diesem Fall ist der Akteur die Filmsammlerin,
also öffnet die Filmsammlerin. Eine Eingabemaske und trägt dort Daten
ein. Gut, was heißt denn das?
Was trägt die Filmsammlerin dort ein? Was brauchen wir für
einen Film? Das haben wir jetzt entweder in der Beschreibung
Oder wir müssen uns zumindest mal sinnvolle Gedanken machen.
Also wir wollen ja in diesem ganzen Prozess des Use-Case-Diagramms,
der Use-Case-Beschreibung nichts erfinden.
Wir stellen keine Anforderungen an ein zu entwickelndes System,
sondern wir haben in der Regel jemanden, der oder die das tut.
Und wir wollen diese Anforderungen verstehen und so weit umsetzen in unsere Systeme,
dass wir eben ordentlich gut vernünftig entwickeln können.
Also wir überlegen uns jetzt nichts irgendwie,
was da vielleicht noch relevant sein könnte, sondern was wirklich nötig ist.
Also die Filmsammlerin öffnet eine Eingabemaske und trägt dort zumindest mal
die Namen des Films ein.
Das Erscheinungsjahr ist vielleicht noch nicht schlecht,
denn es gibt garantiert einige Filme mit gleichem Namen
Und vielleicht können wir noch mal die Spielzeit ergänzen,
so als mal absolutes Minimum. Vielleicht gibt es da nämlich
verschiedene Versionen oder es gibt noch einen Director's Cut.
Er trägt dort Namen, Erscheinungsjahr und Spielzeit ein.
Nun könnte jetzt noch eine weitere Anforderung irgendwo anders herkommen oder
man hat da vielleicht noch irgendwie optionale Elemente,
die könnte man einfach dazuschreiben.
Also die Eingabe, Maske bietet zudem vielleicht auch die Möglichkeit an.
Also über eine weitere Schaltfläche.
Meine Bilddatei für ein Cover auszuwählen
Gut, das wäre der erste Punkt und jetzt haben wir
den zweiten noch, bestätigen Eintrag wird erstellt.
Auch wieder hier die Frage, wer tut denn was?
Gut. Die Filmsammlerin bestätigt die Eingaben, zum Beispiel durch
einen Klick auf einen Button. Und das System wiederum,
das ist dann eine andere Zuständigkeit, er stellt einen neuen Eintrag.
Denn das tut nicht die Filmsammlerin. Niemand trägt irgendwo in
eine Datenbank Handisch etwas ein oder wir schreiben nicht Bits auf
die Festplatte,
sondern das übernimmt jetzt
das System
Gut, wir haben unsere erste kleine Durchführung. Wir können jetzt
noch mal überlegen, was kann denn da noch passieren?
Also wir werden später noch mal überlegen, was kann denn schief gehen?
Also wo haben wir vielleicht eine Ausnahmesituation, einen Fehlerfall?
Aber jetzt bleiben wir mal beim Positiven. Was kann denn
noch vorkommen? Wenn wir jetzt schon Erscheinungsjahr und Spielzeit und Namen angeben und ich schon sagte,
dass wir verschiedene Versionen des gleichen Films vielleicht haben,
dann könnte unser System ja vielleicht das auch erkennen.
Das heißt, wenn das Ganze sehr ähnlich aussieht,
da fragt uns das System, möchtest du den vielleicht abbrechen,
weil wir das schon haben?
Oder möchtest du das als Alternativversion hinzufügen? Oder ist das
wirklich ein neuer Film, der nur zufällig genauso heißt?
Also, wir können dann eine Alternative anlegen zu Schritt 2.
Die nennen wir mal 2A. Also,
falls bereits ein Film mit gleichem Namen und gleichem Erscheinungsjahr,
also... Vorhanden ist, dann soll uns das System das sagen.
Also, dann wird das einfach mal angezeigt.
Und hier kam dann der Akteur,
Die Filmsammlerin, etwas auswählen. Was kann sie auswählen?
Sagen wir mal alternativ. Version ist eine Schaltfläche.
Und dann verknüpft das System die beiden Einträge miteinander,
sodass wir vielleicht hin und her springen können zwischen der US-Version und der europäischen Version.
Und eben, wenn wir die EU-Version anschauen,
einen Link da haben, hier noch Alternativversionen anzeigen.
Und natürlich brauchen wir, wenn wir eine Auswahlmöglichkeit schon haben,
noch eine weitere, also zudem besteht die Option anderer Film.
Also ist dann doch nicht eine andere Version,
sondern wirklich was ganz anderes
Und dann erstellen wir einfach einen ganz normalen neuen Eintrag.
Die Option abbrechen wäre ja schon fast so was wie ein Fehlerfall,
also wir führen 100 Prozess nicht zu Ende,
das betrachten wir dann später, wenn wir uns um Fehlerfälle Gedanken machen.
Gut, machen wir noch Bemerkungen und Glossar-Einträge. Gut,
Glossar-Einträge, das hängt dann davon ab, was eben domänenspezifisch ist,
was wir als wichtige Begriffe in unserem System verwenden wollen,
die wir vielleicht auch erklären, damit alle Entwickler und Nutzerinnen und Nutzer das Gleiche darunter verstehen.
Hier wäre zum Beispiel die Frage, was ist ein Film
Ist ein Film, jetzt eine konkrete Ausgabe des Films
oder sind zwei Versionen eines Films wirklich zwei Filme?
Wir können ja mal sagen, es gibt einen Film und
einen Filmeintrag. Wir haben den Begriff Alternativversion eingeführt,
wo wir dann nämlich zwei verschiedene Versionen miteinander verlinken.
Und vielleicht ist die Spielzeit auch noch ein eigener Begriff,
weil es dort verschiedene Interpretationen von gibt.
Dann müsste das jeweils ins Glosser aufgenommen werden
Gut, dann haben wir noch die Bemerkung.
Da kommt alles rein, was in kein anderes Feld passt,
aber dennoch in irgendeiner Weise sinnvoll ist.
Also vielleicht für die Durchführung, nicht essentiell, aber eine Zusatzbeschreibung.
Vielleicht bietet uns ja die Eingabemaske noch etwas,
was jetzt für die Durchführung nicht relevant ist,
aber eben hier schon erwähnt werden sollte.
Denn zum Beispiel können wir sagen, in den Feldern für
Erscheinungsjahr und Spielzeit. Wir wissen ja schon mal relativ gut,
was dort stehen sollte, denn das sind keine Buchstaben,
das sind keine komischen Sonderzeichen,
sondern eigentlich sind das Ziffern
Spielzeit wird dann in Minuten vielleicht angegeben,
vielleicht erklärt das gerade unser Glossar-Eintrag.
Und das Erscheinungsjahr sollte natürlich auch nicht 1998 ausgeschrieben sein,
sondern eine Zahl. Wenn wir das hier einmal zusammenfassen,
dann passt das auch gerade auf eine Seite, als Kurzversion.
Und wir haben neben unserem ersten kleinen News-Case-Diagramm auch noch eine kleine Use-Case-Beschreibung erstellt.
Und genau das ist die Aufgabe für die erste Vorbereitungsaufgabe zum Thema Eins,
der Übung zur Softwaretechnik.
Viel Erfolg dabei