Als nächstes sprechen wir über den Abschnitt 1-2. Darum,
wie man Anforderungsmodellierung mit der OML macht.
Bevor wir dahin gehen, schauen wir kurz mal an,
woraus ein Anforderungsmodell besteht. Dieses Anforderungsmodell, von dem
wir zuletzt gesprochen hatten, besteht aus mehreren Teilen.
Es soll ja insgesamt die Gesamtheit der Anforderungen des Kunden darstellendes Auftraggebers.
Und da haben wir zunächst das Problembereichsmodell, das ist etwas statisches.
Es stellt die Zusammenhänge da Ja. Ich stelle die Struktur
da, zum Beispiel Datenstruktur. Zum Beispiel organisatorische Strukturen,
zum Beispiel Strukturen eines Systems. Dazu verwenden wir typischerweise
das UML-Klassendiakra
Außerdem gibt es Anwendungsfallmodelle, die heißen, auf Englisch, Use-Case-Modell.
Use-Case-Diagramme werden dafür genutzt. Und diese Use-Case-Diagramme haben wir hier
in dem Newsca hier drüben nochmal Das UML USK ist Diagramm.
Die anderen Sachen kommen auch noch gleich dran, Aktivitätsdiagramm und so weiter.
Das Schnittstellenmodell, was unten ganz unten dargestellt ist,
ist für die Nutzerschnittstelle.
Und für Datenschnittstellen oder sowas zu Nachbarsystemen
All diese Teile gehören zusammen und das,
was wir hier, was wir hier sehen,
das ist ein Klassendiagramm und dieses Symbol hier ist die Teil ganzes Beziehungen.
Wir kommen noch drauf, wenn wir das Klassendiagramm behandeln.
Eigentlich sollten sie das, sollten sie das bereits kennen.
Ich male es mal hier unten noch hin,
in Rot,
damit man
das separat hat
Das Ganze und das Teil und diese Beziehung heißt Aggregation.
Oder wenn Sie es lieber in Deutsch mögen, Teil ganzes Beziehung.
So dieses Diagramm zeigt erstmal, woraus besteht das.
Wir brauchen Informationen zur Struktur. Das wäre das hier oben
Wir brauchen Informationen zu verhalten, das wäre das.
Und wir brauchen Informationen zu Schnittstellen, zur Umgebung und zu Menschen als Bedienung.
Soweit das Anforderungsmodell. Und nun zur Frage, wie erstellen wir das?
Die verschiedenen, die drei Teile sehen wir hier wieder.
Dieses Diagramm ist auch ein Diagramm der UML.
Vielleicht kennen Sie das. Kurz nachdenken? Na,
haben Sie einen Tipp? Das ist tatsächlich ein Aktivitätsdiagramm
der UNL
Ein UML-Aktivitätsdiagramm? Tatsächlich hat mir das auf dem Bild eben schon mal stehen,
auf dem Bild eben war das hier für die Darstellung des Verhaltens.
Und zwar haben wir tatsächlich hier in dem Nachbar,
in dem Leben, in der nächsten Folie,
haben wir ja dargestellt, wie die Reihenfolge sein soll.
Und zwar ist die Reihenfolge eher beliebig. Diese Elemente,
die wir hier oben sehen und hier unten,
sie ahnen schon, dass die Pfeile die Reihenfolge beschreiben,
aber dieses Wichtig ist es,
dieses Symbol zu kennen
Das heißt hier Ausblicken, das heißt Synchronisieren und Synchronisieren meint,
es geht erst weiter, wenn alle drei erledigt sind.
Also das heißt, das Problembereichsmodell erstellt ist,
das Anwendungsfallmodell und das Schnittstellenmodell, erst dann geht es weiter.
Aber hier ist keine Aussage darüber getroffen, wann,
in welcher Reihenfolge die drei Sachen sind.
Diese Struktur, es geht hier um,
das ist übrigens der Anfang, das ist das Ende.
Also diese Struktur hier von oben nach unten und dann
also aufsplitten und unten wieder synchronisieren von drei Sachen,
das ist, so zeichnet man,
wenn die Reihenfolge beliebig sein soll im UML-Aktivitätsdiagramm
So, wir sehen also hier,
man muss alle drei Modelle erstellen und die Reihenfolge ist beliebig.
Reihenfolge beliebig bedeutet, sie haben die Wahl. In der
Tat ist es so, dass man die Möglichkeit hat,
je nachdem vorzugehen, wie das am besten passt.
Und man sollte sich in der Praxis danach richten, was der Auftraggeber,
der Kunde, der Ansprechpartner auf Seiten des Auftraggebers zuerst möchte.
Das hängt sehr davon ab, in welcher Umgebung sie sind,
zum Beispiel, wenn es sehr datenlastige Systeme sind,
um die es geht,
wie es zum Beispiel in der Finanzwirtschaft häufig der Fall ist,
bei Banken und Versicherungen, dann würde man zuerst über Datenstrukturen sprechen.
Das wäre die Datenstrukturen. Sie erinnern sich beim vorherigen Bild
, die Datenstrukturen waren hier beim Problembereichsmodell dabei.
Dann würde man hier mit dem Problembereichsmodell beginnen. Zuerst das Problembereichs,
wenn zum Beispiel Garten oder Organisationsstrukturen im Vordergrund stehen.
Na, das war ein bisschen falsch. Soweit,
das wäre die erste Variante. Dann sollte man,
das merken Sie schon, womit fangen die Leute an?
Bei großen Unternehmen zum Beispiel, ich weiß nicht,
ob Sie schon in großen Unternehmen gearbeitet haben,
das Organigramm so was ganz Wichtiges.
Bei kleinen Firmen werden sie davon gar keine Kenntnis nehmen,
aber bei großen Firmen, wo ist mein Platz im Organigramm?
Total wichtig, weil das da über die Rolle und die
Zuordnung und so weiter was sagt. Also das wäre so
eine organisatorische Struktur. Aber es gibt auch andere Fälle,
wo es vor allen Dingen um das Verhalten geht.
Und da wäre das, wäre das Anwendungsfallmodell, das über
das Verhalten was sagt. Das würde zum Beispiel hier zuerst vorkommen,
wenn Vorgänge Abläufe oder auch Funktionen im Vordergrund stehen.
Und das Schnittstellenmodell, manche fangen auch tatsächlich mit dem Schnittstellenmodell zuerst an,
die wollen mit ihnen unbedingt über den Aufbau der Dialoge reden.
Die wollen damit darüber reden, was inwieweit es aufgeteilt,
was sieht man wo, weil sie vielleicht vorher mit Formularen
gearbeitet haben oder vorher mit ihrer Aufteilung in den vorhergehenden Systemen ganz unzufrieden waren.
Das ist also dieses Schnittstellenmodell wird zuerst verwendet
Wenn zum Beispiel die Nutzerschnittstelle im Vordergrund steht. So,
je nachdem, womit sie anfangen, es geht,
und das ist nochmal diese Symbolik dieser Synchronisation hier unten,
Sie sind erst dann fertig,
es geht erst dann weiter zum nächsten Schritt oder zum nächsten Anwendungsfall,
wenn Sie alle drei Teile beschrieben haben, die Strukturen,
das Verhalten und die Schnittstelle.
Erst dann sind Sie fertig. Und jetzt wenden wir uns
dem eigentlichen Thema dieses Abschnitts zu US-Case-Modellierung.
Wir haben gerade schon zwei Folien vorher, das auf Deutsch gehabt,
das Anwendungsfall-Diaagramm, das Use-Case-Diagramm, die Anwendungsfälle.
Ja, was ist ein Anwendungsfall? Ein Anwendungsfall bezieht sich
auf Verhalten
Und wir nehmen diese Definition hier und markieren das mal so ein bisschen.
Also ein Use-Case, ein Anwendungsfall, beschreibt eine Menge von Aktivitäten.
Das ist ein wichtiger Begriff hier in dieser Definition. Aktivitäten,
und zwar Aktivitäten eines Systems, nämlich dieses zu bauenden Systems.
Und zwar nicht irgendwelche Aktivitäten, vielleicht nichts Inneres,
sondern nur das, was der Akteur tatsächlich sieht aus Sicht seiner Akteure.
Und das sind welche, die in irgendeiner Form entweder wirklich passieren,
dass man sie sieht oder auf jeden Fall oder sie
mindestens zu einem Ergebnis führen
Zu einem wahrnehmbaren Ergebnis führen. Zum Beispiel die Frage ist
häufig, ist das jetzt was Technisches? Ja,
sie erinnern sich, ein Problemraum, Lösungsraum,
diese Begriffe, die sie früher schon mal gehört haben,
das von SE2, hoffentlich wissen sie das noch,
das Technische und das Fachliche.
Hier geht es ganz klar immer um das Fachliche und das
wahrnehmbare Ergebnis könnte durchaus etwas sein, was mit Technik zu tun hat.
Zum Beispiel, man kann wahrnehmen, dass das System
sich irgendetwas gemerkt hat. Das System weiß noch,
wer zuletzt eingeloggt war. Das System weiß noch,
was meine letzten Einstellungen waren
Ist ein, wir reden nicht darüber,
wie es intern gespeichert ist, aber wir merken,
und das ist das wahrnehmbare Ergebnis,
das ist im System, wird etwas gespeichert.
Dann haben wir hier noch den Satz in der Definition,
ein Use Case ist ansonsten eine komplette, unteilbare Beschreibung.
Da steckt so ein bisschen der Begriff modular drin. Ja,
also Modularität bedeutet ja, dass wir die Dinge zusammenfassen, die zusammengehören.
Das ist so ein bisschen hier damit gemeint. Ja,
und wir haben noch eine weitere Definition,
das Use Case Diagramm, das Anwendungsfalldiagramm,
das zeigt die Beziehungen zwischen Akteuren und Use Cases
Ja, soweit möchte ich sie gar nicht so lange auf die Folter spannen.
Wir schauen uns gleich mal an, wie so ein Use-Case-Diagramm aussieht.
Dazu müssen wir zwei Folien weiterspringen, damit wir so was mal sehen.
Ja, also hier haben wir ein Beispiel, ein Kalendersystem.
Und das, was wir ja sehen, ist ein Use-Case.
Ja, kamen sogar zwei Use-Case, die herkommen.
Das obere stellt erstmal nur ein paar Use-Cases einzeln dar und
ihre Beziehung mit einem Akteur und das untere achtet auch noch Beziehungen zwischen den Use-Cases.
Bevor wir weitergehen, erstmal noch den Blick zurück zur Definition.
Die Definition sagte, das Use-Case-Diagramm, Anwendungsfalldiagramm,
stellt Use-Cases dar und die Beziehung zu Akteuren.
Das ist genau das, was wir hier sehen.
Das sind die Use-Cases, die haben irgendwas mit Tätigkeiten zu tun.
Also hier steht immer ein Verb dabei, Terminabfragen, Termin exportieren,
Termin löschen und sie haben etwas mit einem Akteur zu tun.
Der Akteur in dem Fall, der Benutzer des Kalendersystems.
Und diese Beziehung hat zu tun mit,
das wäre hier so eine einfache Linie.
Schauen wir uns die Definition dazu mal an
Nochmal halt, eins zu weit wollte ich noch nicht springen.
Also nochmal die Aktivitäten eines Systems aus Sicht der Akteure und so weiter
und das Use-Case-Diagramm zeigt die Beziehungen zwischen Akteuren und Use-Cases.
Okay, die Folge Foli überspringen wir gleich nochmal.
Wie kommen wir dazu, die zu finden? Jetzt erstmal
nochmal die Elemente, die wir gerade schon gesehen haben.
Wir haben den Akteur oder Ektor auf Deutsch, auf Englisch genannt,
der Akteur, der ist als Strichmännchen meistens gezeichnet.
Es gibt auch die Möglichkeit, den in einem Rechteck darzustellen,
mit spitzen Pfeilen, von einem spitzen Dreiklammern vorn und hinten und dem Namen drin.
Das wäre genauso möglich. Wir kommen später noch dazu.
Das ist auch ein Ausdrucksmittel der UML,
dass man das auch mit dem Rechteck dazu stellen kann.
Und der Use-Case, den hatten wir auch schon gesehen,
der wird durch eine Ellipse grafisch dargestellt.
Außerdem hatten wir die Kommunikationsbeziehung, das war so eine
einfache Linie ohne Pfeil zwischen dem Akteur und dem Use-Case.
Guck noch mal, ja, also hier die Ellipse,
der Use-Case, die Kommunikationsbeziehung, der Akteur hier als Strichmännchen und die Kommunikationsbeziehung zwischen denen.
Was wir hier noch nicht darauf hingewiesen haben, war dieses Rechteckringsrum.
Dieses Rechteck ist die Systemgrenze, wenn wir uns durchaus mal noch als Erläuterung dazuschreiben.
Manche viele Leute sagen das so. Systemgrenze ist dafür wichtig,
dass man entscheiden kann, was gehört zum Use Case
und was gehört zum entwickelnden System und was nicht.
Es kann durchaus auch Use Cases geben, die man mit aufschreibt,
aber die nicht durch das System unterstützt werden.
Zum Beispiel in analogen Buchhaltung gibt es die jungen Zahlungen und vielleicht
noch eine Prüfung und eine Rückforderung und wie auch immer in der Berechnung.
Aber die Änderungen der Gehaltshöhe, das passiert nicht durch ein System,
sondern zum Beispiel durch den Abteilungsleiter oder durch den Geschäftsführer.
Ja, also das wäre dann ein, das wäre durchaus möglich,
dass wir hier einen Use Case haben,
der irgendwie hier außerhalb liegt und auch noch mit etwas zu tun hat.
Machen wir jetzt hier nicht, mache ich mal wieder weg.
Zusätzlich gibt es noch die Möglichkeit, Beziehungen zwischen Use-Cases darzustellen.
Dieser Fall hier oben, den wir haben,
ist ja wirklich super einfach. Da kann ich mir das
eigentlich sparen. Es wird immer nur dann interessant,
wenn ich ein bisschen kompliziertere Verhältnisse habe und diese komplizierteren Verhältnisse sind,
dass diese Use-Cases miteinander was zu tun haben.
Und wir haben hier zwei Sorten von Pfeilen.
Das sehen Sie hier unten. Wir haben einmal seit
so einem gestrichelten Pfeil, wo dran steht Include.
Und dann gibt es einen anderen gestrichelten Pfeil,
wo was anderes dransteht.
Extent,
das bedeutet offensichtlich
was anderes
Und in den zweiten Diagramm haben wir gleich noch hier so
eine andere Sorte von Akteuren, Akteure mit dem Kästchen,
wo wir diesen in den spitzen Klammern Hector drinsteht und der Name dazu.
Wir gucken doch mal hier, also das wäre die Inklude-Beziehung,
gestrichelte Linie und die Externbeziehung und hier oben dieses Rechteck mit dem Namen drin.
Also all diese Sachen, die wir in der Definition hier oder
der Beschreibung der Teile haben, sehen wir hier auch.
Aber wir wollen kurz drüber sprechen, was diese Beziehungen verdeutlichen.
Erstmal die Inklude-Beziehung, das Inklude kennen Sie als Programmiersprachen,
ja, also Inklude heißt, es wird irgendwie mit einbezogen,
das so wie ein Unterprogramm oder ein Paket oder so etwas
Und tatsächlich ist es hier auch ein Teil von Beziehung.
Und ja, hier ist es zum Beispiel so,
dass das Terminumfall erfassen, da gehören weitere Sachen dazu.
Hier gehört zum Beispiel dazu, dass man die Teilnehmer verständigt oder Kalender aktualisiert.
Das ist so wie eine Art Unterroutine, ein Modul,
ein Suchmodul. Das könnte auch woanders noch Teil sein.
Also bei Terminkonfliktauflösen und Terminen verlegen, könnte es auch durchaus sein,
dass man Kalender aktualisieren als Use-Case auch nochmal hat.
Auch das ist eine modulare, eine unteilbare Beschreibung oder Teilnehmerverständigen.
Aber hier gehört es mit dazu.
Man hat es sozusagen einfach mitbenutzt
So eine Art Wiederverwendung. Das auf dem anderen hier drüben
haben wir dann auch noch, das mit den Extent-Beziehungen.
Extent ist schon ein bisschen schwieriger zu verstehen,
werden inkluded für Programmierer meistens intuitiv ist.
Hier diese Extent-Beziehung kennzeichnet Varianten. Was sind nun Variante?
Manchmal möchte man verschiedene Varianten eines Systems gleich darstellen. Zum Beispiel,
sie haben die Kleine, die Mittlere und die große Variante,
so für den Privatbenutzer, für kleine Unternehmen und für große Unternehmen.
Also das wären für Varianten und wir schauen uns mal an,
was man hier für Varianten hat
Also wenn das System einen Mehrbenutzer fähiges System ist,
dann brauchen wir sowas wie Benutzungsrechte.
Deswegen gibt es bei manchen Programmen irgendwie bei der Programmverwaltung das
vielleicht ohne Nutzungsrechte und häufig aber auch mit Zugriffsrechten.
Oder etwas anderes, wenn die Einstellung komplizierter sind,
habe ich eines separaten Use-Case zum Verwalten dieser Einstellungen.
Also gibt es wahrscheinlich einen separaten Dialog dafür. Und das
ist aber nur bei bestimmten Varianten des Programms nötig, nicht immer.
Und deswegen hat man das hier durch diese Extent-Beziehung dargestellt.
Ja, warum erkläre ich Ihnen
das alles
Wir reden davon, dass wir über Großes,
große Systeme entwickeln wollen. Dass viele Beteiligte sind. Und
diese vielen Beteiligten müssen das gleich, ein gleichartiges Verständnis haben.
Und der Auftraggeber und der Auftragnehmer sollen ein gleichartiges Verständnis entwickeln.
Und deswegen ist es wichtig, eine Symbolik zu verwenden,
die alle gut verstehen. Und diese UML und ermöglicht das,
diese Anwendungsfalldiagramme, Use-Case-Diagramme, die wir hier gerade haben.
Nebenbei bemerkt, welchen Begriff sie verwenden,
ob auf Deutsch oder auf Englisch,
das ist ganz innen überlassen,
auch für die Prüfung ist uns das egal
Um vielleicht noch ein weiteres Wort zur Prüfung.
Wir hatten hier so eine Definition. Ich muss Ihnen sagen,
ich selber finde auswendig lang irgendwie doof. Und ich erwarte
auch nicht von Ihnen, dass Sie das wirklich wiedergeben.
Wichtig ist, dass Sie es sinngemäß wiedergeben können,
denn solche Definitionen braucht man schon. Sie sind nicht sinnlos,
weil man muss schon ganz klar mit jemandem sagen,
das ist ein Use-Case und das ist kein Use-Case.
Zum Beispiel das mit diesem wahrnehmbaren Ergebnis.
Es könnte jemand kommen mit irgendwas Technischem intern und sagen,
das ist ein Use-Case für mich.
Nein, ist es nicht. Use-Case ist etwas aus der
Sicht der Akteure. Deswegen muss man Definitionen durchaus kennen,
aber wie gesagt, für die Prüfung brauchen Sie die
nicht wörtlich
Ja, jetzt zur Folie 15. Die sagt uns, wie
wir Use-Cases denn finden. Vielleicht erinnern Sie sich im vorhergehenden Block,
wo es um Anforderungsbeschreibung, Anforderungsanalyse ging, hatte ich über Techniken gesprochen.
Und bei den Techniken war sowas Sinnloses,
oder wie soll ich sagen, ganz simples, wie Fragestellen dabei.
Ja, tatsächlich geht es hier auch um simple Sachen.
Es ist in vielen Fällen ganz gut Low-Tech zu verwenden,
also etwas Simples, etwas Einfaches, was jeder gut versteht.
Ja, also wir sammeln ihr Kundenwünsche.
Das ist das, was wir bei Suchen tun,
um Use-Cases zusammenzutragen
Außerdem kennen wir, wir können das natürlich durch Befragung tun,
aber es ist auch ganz gut vorhandene Dokumente auszuwerten.
Solche vorhandene Dokumente sind zum Beispiel Arbeitsanweisungen. Oder Beschreibungen von Vorgehensweisen
. Manchmal auch Vertragsdokumente. Oder es gibt ein Softwaresystem,
was wir, was wir schon kennen oder was entwickelt werden soll,
wo es eine Spezifikation dazu gibt.
Also irgendwelche Textdokumente und in diesen Textomenten suchen wir vor
allen Dingen nach Tätigkeiten. Ja, also meistens sind das
Werben mit Tätigkeitsbeschreibung
Aber es würde nicht reichen, jedes Verb zu verwenden,
das wäre viel zu viel und nicht echte Use Cases,
echte sind welche, die in irgendeiner Form verallgemeinert sind,
die also zutreffen für eine ganze Klasse von Benutzern und die
wiederkehren und die wirklich in sich abgeschossen sind.
Deswegen ist dieses Verallgemeinern und Zusammenfassen hier ein wichtiger Punkt. Sie erinnern sich,
ich habe das vorhin als Theoriebildung bezeichnet, ja,
man versucht, etwas zu entwickeln und das ist tatsächlich erfordert,
dass einiges an Gehirnwindungen, dass es einem gelingt,
gute Verallgemeinerungen,
gute Zusammenfassungen zu finden
Und wir möchten versuchen, das relativ vollständig zu machen,
aber nicht komplett, man muss ja irgendwann weiterkommen,
wir dürfen durchaus aufhören und sagen,
okay, das reicht uns erstmal,
wir kommen später zu einer weiteren Verfeinerung.
Diese Use Cases, die wir jetzt gerade haben,
sind ja wunderbar, nur sie enthalten nicht viel Informationen.
Wir gehen nochmal hier zu dem Bild, ja,
also was haben Sie hier schon raus?
Was würde man als Programmierer hier rausbekommen, Terminen exportieren?
Was soll da gemacht werden? Wie soll das gemacht werden
? Das ist doch viel zu wenig Informationen,
um damit programmieren zu können, um eine Software entwickeln
zu können
Deswegen brauchen wir noch mehr und zwar brauchen wir eine Textbeschreibung,
die dazu dient, zur Vervollständigung, eine Vervollständigung zu erreichen.
Und das ist unser nächster Punkt. Die Textbescheidung. Vielleicht sollte ich noch sagen,
die UML, wie wir sie hier kennengelernt haben,
oder wie wir hier ein Diagramm sehen,
Unified Moderling Language, ist Industriestandard.
Sie ist sogar Gegenstand einer Norm.
Sie ist standardisiert durch von einer Norm von der UMG.
Dann schreiben wir das hin. Wir,
UML, da könnt ihr noch mit dazu
Für diejenigen, ich denke, die meisten von ihnen
wissen das schon, aber wir schreiben damit dazu.
Unified. Beuteling. Language. Und die ist bestandardisiert.
UMG heißt Object Management Group. Das ist eine Organisation,
bevor sie sich mit der UML beschäftigt hat,
gar keiner richtig wahrgenommen hat,
aber seit dem Prinzip an Bedeutung gewonnen hat,
zum Beispiel sehr viel auch Rennreich, XML oder andere Sprachen um Standards entwickelt.
Also diese Unified Modeling Language ist ein Industriestandard und ein solches
hilft es uns, weil wir könnten davon ausgehen,
dass viele die UML oder Teile davon kennen.
Und das, was wir hier gerade kennenlernt haben,
ist eins von etwa 15 Diagrammen. Sie kennen das Klassendiagramm
auf jeden Fall schon ein bisschen von Essy 1 und Essy 2.
Und hier ist sozusagen das Nächste, was wir kennengelernt haben.
Ich habe gerade davon gesprochen, dass wir Textbeschreibungen brauchen,
um das zur Vervollständigung mehr Details zu haben.
Und diese Textbeschreibung ist leider
nicht standardisiert
Es gibt also verschiedene Varianten davon, wenn sie ein Buch aufschlagen,
könnte es sein, dass sie ein UML-Buch aufschlagen,
dass sie hier ein bisschen was anderes finden,
in einer Firma, wo sie vielleicht arbeiten,
finden sie wieder ein bisschen was anderes.
Wir haben uns bemüht, ich hoffe, es ist uns gelungen,
dass wir in Vorlesungen Übungen wenigstens das Gleiche haben.
Aber die wesentlichen Elemente sind hier erst mal da und diese
wesentlichen Elemente beziehen sich umfassend zunächst erst mal hier oben,
solche einfachen Sachen wie der Name des Anwendungsfalls und was sind die Akteure?
Diese beiden Punkte sind tatsächlich Sachen, die sie im Diagramm auch finden.
Die Akteure sind durch so eine einfache Linie,
durch diese Kommunikationsbeziehung angebunden und der Name,
das ist das, was in der Elipse drinsteht.
Alle anderen Punkte sind tatsächlich ergänzende Informationen,
die uns helfen, da mehr davon zu haben.
Und zwar haben wir hier zunächst erst mal Vorbedingungen,
Nachbedingungen in Varianten. Diese Vorbedingungen, Nachbedingungen,
das ist etwas, was sie auch von SE2 her kennen,
nämlich etwas, was wir für die Testfallerzeugung und Unitors brauchten
Ja, also vielleicht sagen wir deswegen nochmal dazu,
was das ist, die Vorbedingungen, die müssen erfüllt sein.
Bevor der Use Case startet, sonst startet er gar nicht.
Zum Beispiel, jemand muss schon Kunde in einem Unternehmen sein,
sonst kann er einen bestimmten Use Case gar nicht starten,
sonst kommt er nie dorthin.
Die Nachbedingungen, die müssen erfüllt sein, Wenn der US Case durchlaufen würde.
Ich habe dabei nicht gesagt, dass er erfolgreich durchlaufen würde,
nur überhaupt durchlaufen, vielleicht auch mit einem Fehlerabbruch oder sowas.
Es muss immer Konsistenz hergestellt werden. Zum Beispiel könnte es sein,
dass wenn man Verbindungen hat, dass man diese Verbindung wieder ordentlich beendet,
dass man Konsistenz zwischen Feldern einer Datenbank wiederherstellt oder wenn man auf Betriebssystemebene ist,
Dateien wieder schließt.
In Varianten, da sagt der Name schon,
unveränderliche bleiben Unbeeinflusst von diesem Use Case.
Ein Beispiel für eine Innenvariante ist bei einer Überweisung,
die Summe der beiden Salden, der Geldmengen auf beiden Konten,
die beteiligt sind, bleibt gleich.
Also auf einem einen wären 500 Euro abgebucht, dann kommt die bei dem anderen dazu.
Aber die Summe des Geldes vorher und hinterher sollte gleich bleiben.
Man druckt dabei kein Geld und sollte auch keins verschwinden.
Das wäre also eine Innenvariante. Qualitätsmerkmale, das ist etwas,
was man nicht in jedem Modell in jeder Ausprägung von diesen Use Case Beschreibungen hat,
Wenn zum Beispiel besondere Anforderungen sind, ein Performance,
Sicherheit, Zuverlässigkeit oder ähnliches.
So, die letzten drei Punkte,
die wir hier haben,
die bezeichnen alle
das Verhalten
Und zwar haben wir drei Arten hier bei dieser Form der Use-Case-Beschreibung,
drei Arten von Verhalten, die hier angegeben sind.
Und das ist tatsächlich ganz wertvolle Informationen für den Entwickler.
Während die Vorbedingungen, Nachbedingungen gut dafür sind,
dass der Entwickler Testbedingungen auf Tests aufstellen kann,
sagen diese drei hier unten Ablaufbeschreibungen aus einer fairen Situation Alternativabläufe,
sagen etwas darüber, wie das Verhalten gemacht sein soll.
Ablaufbeschreibung, Durchführung,
das ist der Normalfall
Manche sagen auch, seine Idee, also alles ist toll.
Hier steht schon da drin, das ist der Fehlerfall.
Zum Beispiel die Geldmenge auf dem Konto reicht nicht für eine Überweisung.
Was passiert dann? Oder die Verbindung zur Datenbank ist abgebrochen.
Was passiert dann? Und die alternative Abläufe beschreiben Varianten.
Zum Beispiel, sie wollen ein Buch ausleihen und da wird
eben gesagt, das Buch können sie aber nicht mitnehmen.
Ich nehme sie stattdessen lieber die elektronische Version oder irgend sowas
Und das sind dreimal drei verschiedene Abläufe, die man hier beschreiben kann.
Und wenn wir jetzt überlegen, was wir vorher hatten,
ohne diese Use-Case-Beschreibung, nämlich nur die ersten beiden Punkte hier,
den Namen des Anwendungsfalls und zu welchen Akteuren die gehört,
so ist das doch relativ wenig Information.
Mit dieser Use-Case-Beschreibung wird es doch mal deutlich mehr. Ja,
damit haben wir ein Diagramm der UNL kennengelernt und dieses Diagramm
hilft uns dabei, Anforderungen in einer gutlesbaren Form zu beschreiben.
Und sie sollten versuchen, solche Sachen wie zum Beispiel hier
solche Beziehungen tatsächlich auch zu benutzen.
Nicht das Ganze, weil sonst die Gefahr besteht,
dass man das nur als Text beschreibt und Text ist nun
mal mehr missverständlich als so etwas mit klarer Definition.
Was bedeutet Include, was bedeutet Extent?
Damit sind wir erstmal mit diesem Abschnitt fertig.
Vielen Dank