UML - Use Case - include-Beziehung zwischen 2 Anwendungsfällen

[fireGlurak]

Hallo,

ich habe in meiner Software u. A. 2 Anwendungsfälle:

-Neuen Kunden anlegen

-Kundendaten einsehen

Ich weiß nicht genau wie ich die Beziehung zwischen den beiden Anwendungsfällen modellieren kann. Es ist ja so, dass die Kundendaten nur eingelesen werden, wenn der Kunde angelegt wurde. Also eigentlich eine include-Beziehung von Neuen Kunden anlegen zu Kundendaten einsehen. Allerdings würde dies ja dann bedeuten, dass jedes Mal wenn ich die Kundendaten von irgendeinem Kunden einsehen will, erst einen neuen Kunden anlegen müsste. Wie kann ich dies also so modellieren, dass es ersichtlich ist, dass die Kundendaten von dem Kunden nur eingesehen werden können, wenn dieser existiert ?

 

[mihe7]

Gar nicht (bzw. wenn überhaupt per Kommentar). Das Anwendungsfalldiagramm ist kein Ablaufdiagramm.

Abgesehen davon deutet "Kundendaten einsehen" eher darauf hin, dass es sich dabei nicht um einen Anwendungsfall handelt, sondern um einen einzelnen Schritt anderer Anwendungsfälle.

 

[fireGlurak]

wenn überhaupt per Kommentar

Ok

Abgesehen davon deutet "Kundendaten einsehen" eher darauf hin, dass es sich dabei nicht um einen Anwendungsfall handelt, sondern um einen einzelnen Schritt anderer Anwendungsfälle.

Habe ich mir schon fast gedacht. Ich habe manchmal Schwierigkeiten herauszufinden was genau ein Anwendungsfall ist und was nicht. Grundsätzlich spricht man ja von einem Anwendungsfall,wenn eine Interaktion zwischen Anwender (oder einem anderern Akteur) und dem System herrscht. Beim Einsehen von Kundendaten interagiert der Nutzer ja schließlich auch mit dem System (die werden ja nicht "einfach so" angezeigt). Könnte man dann evtl. sagen, dass man immer dann von einem Anwendungsfall sprechen kann, wenn sich der Systemzustand nach der Interaktion, wie es beim Anlegen/Ändern/Löschen von Kunden der Fall ist, geändert hat ?

 

[mihe7]

Ich habe manchmal Schwierigkeiten herauszufinden was genau ein Anwendungsfall ist und was nicht.

Das geht nicht nur Dir so

Grundsätzlich spricht man ja von einem Anwendungsfall,wenn eine Interaktion zwischen Anwender (oder einem anderern Akteur) und dem System herrscht.

Würdest Du einen Anwendungsfall "Feld ausfüllen" modellieren? Warum nicht? Oder wann evtl. schon? Eine der Fragen ist immer, auf welcher Ebene man sich bewegt. Anwendungsfälle werden meist im Rahmen der Anforderungsanalyse ermittelt, also auf der höchstmöglichen Ebene. Da spielen Kinkerlitzchen keine Rolle.

Könnte man dann evtl. sagen, dass man immer dann von einem Anwendungsfall sprechen kann

Nein, man kann so etwas aber als relativ starkes Indiz nehmen.

Beim Einsehen von Kundendaten interagiert der Nutzer ja schließlich auch mit dem System (die werden ja nicht "einfach so" angezeigt).

Ja, Du darfst das aber nicht aus Sicht des Entwicklers sehen. Die Frage wäre für mich, was ist der Hintergrund/der verfolgte Zweck des Anwenders, sich die Kundendaten anzusehen.

Ein Anwendungsfall muss in der Regel ein Ergebnis liefern, das für einen Akteur/Stakeholder einen greifbaren Wert darstellt.

Mal ein Beispiel: Du schreibst ein Programm zur Erstellung von Rechnungen. Da müssen Kunden inkl. Kontaktdaten verwaltet werden. Der Sinn ist die Pflege der Stammdaten, um Rechnungen schreiben und versenden zu können. Es geht hier aber nicht darum, dass der Anwender das System als Auskunft verwendet (auch wenn er das tun wird - weil er es kann).

Etwas deutlicher wird es, wenn wir vom Kunden weg zur Rechnung hin gehen. Hier gäbe es analog einen Anwendungsfall "Rechnung einsehen" Und analog dazu die gleiche Frage: wozu?

Es kann zum Beispiel sein, dass der Kunde mit einer Rechnung nicht einverstanden ist, dann muss man sich die Rechnung nochmal ansehen. Der Anwender benutzt die Anwendung also in dem Fall (die Formulierung ist nicht rein zufällig), dass er eine Rechnung prüfen muss. Dem entsprechend wäre der Anwendungsfall also z. B. "Rechnung prüfen" und ein Schritt davon wäre es, dass das System die Rechnungsdaten anzeigt. Die Prüfung kann nun dazu führen, dass die Rechnung storniert werden und neu ausgestellt werden muss (das könnte man dann als extension point "Rechnung korrigieren" modellieren) oder dass ein Missverständnis aus der Welt geschafft wurde. Der Anwendungsfall führt aber dazu, dass der Anwender seine Aufgabe erledigt hat.