Diskussion:Anwendungsfall

Urheberrechtshinweis

Falls der von mir zur Verfügung gestellte Text weiter "verfremdet" oder erweitert wird, dann kann der Urheberrechtshinweis entfallen.

M.E. ist die Verwendung von Sequenzdiagrammen oder Aktivitätendiagrammen im Rahmen der UML innerhalb eines Anwendungsfalls nicht oder nur sehr selten angebracht. Einerseits verstehen die Fachanwender sowas erfahrungsgemäß nicht ohne weiteres, andererseits kann eine Aufeinanderfolge mehrere Dialoge ehe als eine Sequenz von Anwendungsfällen betrachtet werden - je nach Granulierung des einzelnen Anwendungsfalls. Diese Diagramme werde eher neben Anwendungsfällen genutzt. -- Karlscharbert 03:36, 23. Dez 2003 (CET)

Hallo Karl,
da diese Zeilen unter GNUFDL veröffentlicht wurden, ist der Satz überflüssig. Ich habe deinen Verweis in die Literatur verschoben. Lieben Gruß, Conny 15:57, 18. Mär 2005 (CET).

Geschäftsprozess ist falsch

Ein Use Case beschreibt einen Anwendungsfall, keinen Geschäftsprozess! Geschäftsprozesse sind etwas ganz anderes (müssen nichtmal mit der SWE zu tun haben!). Geschäftsprozesse enthalten auch Aktionen die nicht Teil des zu modellierenden Systems sind, und können auch Personen/Rollen und Resourcen beinhalten, die nicht direkt am System beteiligt sind.

Diese Definition finde ich persönlich viel treffender: "Ein Use Case beschreibt eine abgeschlossene ununterbrochene Abfolge von Aktionen eines Akteurs am System mit Ergebnis von fachlichem Wert"

(Anmerkung: Nachdem sich nun fast ein Jahr niemand zu dieser Diskussion geäußert hat, ändere ich den Artikel ab. Weiter oben hatte zumindest nohc eine 2. Person den gleichen einwand)

Anwendungsfalldiagramm am Beispiel eines Prüfungssystems mit den Anwendungsfällen „Klausuranmeldung“ und „Raumreservierung“

Die Zeichnung die hier abgebildet wird, ist so nicht ganz korrekt. Wenn ein Use Case einen anderen beinhaltet (included), sollten diese mit einem Pfeil verbunden werden. Der Use Case an der Pfeilspitze ist in dem anderen enthalten. In korrekter UML Notation sollte der Pfeil gestrichelt sein.

Richtig, siehe auch Diskussion: Anwendungsfalldiagramm.

-- Gubaer 15:49, 17. Jul 2005 (CEST)

Anwendungsfall und Anwendungsfall (UML)

die beiden Lemmata behandeln dasselbe Modell und können IMO zusammengelegt werden Nopherox 14:05, 25. Jan 2006 (CET)

Beteiligte Akteure (actors) ist falsch

Akteure können niemals Personen sein. Ein Akteur ist nicht die Person, sondern, z.B., der Button der gedrückt wurde oder ein Event der ausgelöst wurde.

Sorry aber das ist totaler Blödsinn. Bei UseCases geht es nicht um Buttons oder Events (sind keine Flussdiagramme oder Sequenzbeschreibungen!). Ein UseCase ist unabhängig von irgendwelchen Programmiersprachen. Es hindert mich keiner daran, einen UseCase fürs Autofahren zu schreiben, wozu ich keinen Button brauche.

Ein Akteur kann eine Rolle, eine Person oder ein anderes System sein

Definition: ununterbrochen

Aus welchem Grund sollte ein Use Case nicht unterbrechbar sein?

Ganz pragmatisch: weil er dann nicht mehr granular ist und zu komplex wird. Wenn man eine Unterbrechung braucht, bewegt man sich meist eher wieder im Bereich von Sequenzdiagrammen und internen Abläufen und modelliert nichts aus Sicht eines Akteurs. --Benutzer:Baitronic 3.11.06

Wieder mal Geschäftsprozess

"Der Bezug zur Systemtheorie zeigt jedoch, dass Use Cases und (Geschäfts-)Prozesse jeweils eine andere Sicht auf das zu modellierende System beschreiben: Use Cases beschäftigen sich mit der Frage, was die Umwelt vom System erwartet, (Geschäfts-)Prozesse zeigen, wie das System intern operiert, um die Anforderungen der Umwelt zu erfüllen. Diese Abgrenzung gilt unabhängig von der Art des zu modellierenden Systems insbesondere für Unternehmen und Software gleichermaßen."

Machen wir's doch bitte nicht zu kompliziert. Das ist keine wissenschaftliche Abhandlung über Systemtheorie. Bitte beschreiben wir es so, wie es in der Praxis benutzt wird (IMO zurecht) - Und in der Praxis sind Use Cases und Geschäftsprozesse nicht nur eine andere Sicht auf die gleiche Sache, sondern zwei grundverschiedene Dinge.

GP: kein Abgeschlossenes System, mehrere Rollen und Akteure beteiligt, kann unterbrochen sein (beispielsweise um auf Kundenantwort zu warten bevor er fortgesetzt wird), beschreibt organisatorische Abläufe, auch außerhalb eines Systems und über Abteilungsgrenzen hinweg.

Z.B. Ein Geschäftsprozess "Angebotserstellung" beschreibt den kompletten Ablauf in einem Unternehmen um ein Ziel zu erreichen, von der Anfrage bis zum Angebot und bezieht viele Abteilungen/Rollen/Unterprozesse im Unternehmen mit ein. Ein UseCase kann Teile eines Geschäftsprozess übernehmen (innerhalb eines im GP eingegliederten Systems), aber er IST kein GP.

-- Baitronic 3.11.06

Um noch ein bisschen zu verwirren, möchte ich den Begriff Geschäftsanwendungsfall erwähnen. Dieser beschreibt auch einen organisatorischen Ablauf, jedoch wird die Frage nach einer systemtechnischen Lösung noch nicht gestellt. Wie bei einem Geschäftsprozess ist eine zeitliche Unterbrechung zulässig. (Oestereich 2006) Nach meiner Auffassung handelt es sich dabei um einen Anwendungsfall, der sich auf eine bestimmte Domäne bezieht, sich also nicht über Abteilungsgrenzen hinweg bewegt.

Abgrenzung Geschäftsprozess und Anwendungsfall

(in Kürze)

In der Praxis wird der typische Anwendungsfall in einen Systemanwendungsfall und einen Geschäftsanwendungsfall unterteilt.

Ein Systemanwendungsfall beschreibt die Interkation zwischen Akteur und dem System. Von Implementierungsdetails wird abstrahiert.

Ein Geschäftsanwendungsfall beschreibt einen geschäftlichen Ablauf in einem Unternehmen.

Ein Geschäftsprozess kann sich aus einem oder mehreren fachlich zusammenhängenden Geschäftsanwendungsfällen zusammensetzen. Ein Geschäftsprozess ist meist komplexer und kann sich über Abteilungsgrenzen hinweg bewegen.

---

mab '08

Zwei Mal dasselbe?

Ich bin der Ansicht, dass man bei der Suche "Anwendungsfall" über die Verknüpfung "Anwendungsfall (UML)" zu ein & demselben Beitrag kommen sollte wie bei der Suche "Anwendungsfälle" & "Use case" oder "Use cases". Der Beitrag besteht derzeit einmal für den Anwendungsfall & einmal für die Use cases. (nicht signierter Beitrag von Sae1962 (Diskussion | Beiträge) 10:02, 22. Jan. 2007)

Eine Möglichkeit wäre, dass man "Anwendungsfall (UML)" integriert -> evtl. als Unterkapitel ----Erkan Yilmaz (bewerte mich!, Diskussion) 20:18, 22. Jan. 2007 (CET)

Aufbau eines Anwendungsfalles

Laut Artikel basiert die Beschreibung auf A.Cockburn. Womöglich sind ja Cockburn und ich unabhängig voneinander auf dieselbe Idee gekommen, jedenfalls kenne ich Cockburns Buch nicht. Die in der Wiki aufgeführte Darstellung stammt tatsächlich in dieser Form von mir (in einer frühen Version des Artikels, die "Erweiterungspunkte" stammen nicht von mir), ich hatte sie 2003 schon auf meiner Website und 2005 in mein Buch aufgenommen. Ungeachtet dessen lasse ich den Artikel wie er ist. -- Karlscharbert 23:50, 17. Feb. 2007 (CET)

Ich würde sogar noch weiter gehen und sagen, dass Cockburn in seinem Buch eine ganz andere Gliederung vorschlägt als die im Artikel beschriebene. Kann sich jeder davon überzeugen, da ein Draft von Cockburns Buch online verfügbar ist. (Auf der englischen Wikipedia-Seite verlinkt.) -- 91.23.167.213 20:21, 22. Mai 2007 (CEST)

Man kann auch einfach in den englischen Use Case Artikel schauen, da ist nämlich die Gliederung nach Cockburn erfasst. War schon etwas verwirrt, warum hier Cockburn drüber steht, aber kein Cockburn drin ist. Wäre es evtl sinnvoll, den Aufbau nach Cockburn einzufügen? --Cornixx (Diskussion) 20:38, 29. Jan. 2013 (CET)

Überarbeitung

Habe gerade 'Use Cases effektiv erstellen' und 'Use Cases vs. Geschäftsprozesse' gelesen und dementsprechend den Artikel etwas genauer gemacht. Was jetzt noch fehlt, ist eine sauberere Einbindung der Literaturreferenzen, sowie eine Überarbeitung der methodischen Hinweise. -- XPhil 12:45, 21. Mär. 2009 (CET)

Grafik

In der Grafik 1, das als Beispiel eines Use Cases dienen soll, fehlen die Pfeile. Die Grafik in der Form ist falsch, weil der Empfänger laut der Grafik auch dem Sender eine Nachricht schreiben kann. Dazu ist er aber nicht spezifiziert. Der Empfänger soll laut Grafik nur Daten empfangen und nicht auch senden dürfen. (nicht signierter Beitrag von X-behind (Diskussion | Beiträge) 22:24, 21. Jul 2010 (CEST))

Ja, die Grafik war falsch. Die Linien zwischen Akteuren und Anwendungsfällen sind jedoch niemals Pfeile. Ich habe eine abgeänderte Version der Grafik hochgeladen, in der der Akteur "Empfänger" entfernt wurde. Elektrolurch Kontakt 13:50, 2. Feb. 2012 (CET)

Use Case vs. User Story

siehe Diskussion:User Story --Siehe-auch-Löscher 10:06, 8. Aug. 2011 (CEST)

Done --Hamburger 11:48, 25. Okt. 2011 (CEST)

Use Case vs. Geschäftsprozess

Use Case und Geschäftsprozess grenzen sich für mich trivial einfach ab: ein Use Case betrifft eine Benutzung eines einzigen Systems, z.B. Geldautomat. Geschäftsprozess betrifft alles, was drum herum auch noch geschieht, z.B. von der Bank zum Supermarkt wechseln und mit dem Geld einkaufen. Damit ist der Geschäftsprozess eine Ebene höher und systemübergreifend! Ein Geschäftsprozess beinhaltet also mehrere Use Cases mit mehreren Systemen und mitunter auch Schritte, die ohne Systeme stattfinden.

-- TvE, 23.04.2013 (nicht signierter Beitrag von 80.228.111.17 (Diskussion) 13:01, 23. Apr. 2013 (CEST))

Es mag ja sein, dass sich das für dich „trivial einfach abgrenzt“.

• Das wird allerdings nicht allgemein in dieser Weise gesehen.
• Das hängt insbesondere auch damit zusammen, dass es keine unverrückbare Abgrenzung „eines einzigen Systems“ gibt.
  • Der Geldautomat ist auch irgendwie mit meinem Konto verbunden, und er reagiert in seinem Verhalten empfindlich auf die Minuszeichen und roten Zahlen bei meinem Kontostand.
  • Der Geldautomat ist also auch Teil eines Systems „Kontoführung“.
• Es sind aus Sicht vieler Beteiligter (des Geldinstituts, des Kunden, des Einzelhändlers) unterschiedliche Sichtweisen auf Teile eines Gesamtsystems.
• Es gibt keine einfache und vollständige und einheitliche Beschreibung komplexer Systeme mit vielen Akteuren und Komponenten.

VG --PerfektesChaos 14:07, 23. Apr. 2013 (CEST)

Defekter Weblink

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Der folgende Weblink wurde von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieses Fehlers finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• https://af3.fortiss.org/attachments/19/Morys2010.pdf
  • Netzwerk-Fehler (7) andere Artikel, gleiche Domainhttp://giftbot.dwl.invalid/https://af3.fortiss.org/attachments/19/Morys2010.pdf

– GiftBot (Diskussion) 00:10, 28. Nov. 2015 (CET)

Definition Use Cases bezüglich Akteur

Man könnte in der Definition verbessern, dass es mehrere Akteure sind: "Ein Anwendungsfall (engl. use case) bündelt alle möglichen Szenarien, die eintreten können, wenn mindestens ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes fachliches Ziel (engl. business goal) zu erreichen. (nicht signierter Beitrag von Wasstruma (Diskussion | Beiträge) 12:16, 17. Feb. 2017 (CET))

Use Case

Use Case linkt hierher nach "Anwendungsfall". Laut Beschreibung hier ist UC aber etwas weitgehend anderes...?! Vielleicht kann das mal jemand verständlich bei Use Case beschreiben. Danke, --Markus (Diskussion) 16:09, 25. Jan. 2021 (CET)

??????????

„Laut Beschreibung hier ist UC aber etwas weitgehend anderes“

• Wo steht das?
• Als erste fünf Wörter lese ich momentan: „Ein Anwendungsfall (engl. use case)“
• Das Lemma ist die sehr gebräuchliche Eindeutschung von use case und für den IT-Bereich synonym.

VG --PerfektesChaos 14:50, 26. Jan. 2021 (CET)