Diskussion:Anwendungsfall
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).
Ein Use Case im Softwaredesign beschreibt KEINEN Geschäftsprozess!
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
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) Beantworten
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), 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) Beantworten