Ist TIME ein Akteur in einem Anwendungsfall?

Question

In Ordnung, auf eine wahre falsche Frage:

a) Die Akteure eines Systems werden nur durch Menschen oder andere Software-Komponenten dargestellt.

Ich sagte TRUE, und der Lehrer markiert es als falsch, nicht weil er der Ansicht, dass ich Hardware-Komponenten verpasst (was ich denke, ich würde teilweise zugeben), sondern weil sie auf seine Worte:

„TIME ist auch ein Schauspieler."

Wie würde ein Use-Case-Diagramm TIME als einen Schauspieler betrachten?

Bitte beziehen Sie sich auf eine Bibliographie, die Zeit einen Schauspieler berücksichtigt. Ich habe keine gefunden, und wahrheitsgemäß denke ich, dass es keinen Sinn ergibt. Die Zeit agiert nicht von selbst, es ist entweder ein System oder eine Person, die nach einem Zeitplan arbeitet.

Answer 1

Die UML-2-Use-Case-Diagramming Richtlinien hier ...

http://www.agilemodeling.com/style/useCaseDiagram.htm

... zeigen, wie Zeit dargestellt werden können.

Ich vermute jedoch, dass Sie Ihren Lehrer bitten sollten zu erklären, wie die Zeit ein Akteur ist und wie er in einem Use Case-Diagramm dargestellt wird, denn schließlich werden sie Ihre nächste Aufgabe markieren und ihre Interpretation übertrumpft alle anderen: -)

Oh, und Wikipedia sagt Zeit ein Schauspieler ist, so ist es wahr sein muss:

http://en.wikipedia.org/wiki/Use_case

Answer 2

Ein Akteur kann als jemand oder etwas angesehen werden, das einen Anwendungsfall startet. Geplante Aufgaben werden mit "Zeit" gestartet. In diesem Sinne ist "Zeit" ein Akteur, weil es einen Anwendungsfall auslöst.

Beispiel:

Ein Bericht muss jeweils 6 Stunden erzeugt werden. Also muss die Zeit "6 Stunden" ein Akteur sein, weil die generierte Aufgabe alle 6 Stunden gestartet wird.

Answer 3

Die Zeit interagiert mit dem System. Z.B. Die Zeit vergeht und das System muss etwas basierend auf dieser "Aktion" tun.

Answer 4

ich mit Zeit als Schauspieler zustimmen. Wenn ein Anwendungsfall im System zu einem bestimmten Zeitpunkt ausgelöst wird, modelliere ich die Zeit als Akteur und verknüpfe sie mit diesem Anwendungsfall. Die Zeit kann in diesen Szenarien als externe Entität (und somit als Akteur) betrachtet werden.

Answer 5

Ich stimme nicht zu, dass die Zeit ein Akteur ist. Was Sie wirklich denken müssen, ist, wer von der Aktion profitieren wird und die funktionale Beschreibung, die die Erstellung und Ausführung des Zeitplans festlegt, einfügt. Werfen Sie einen Blick auf diesen Artikel:

Dr. Use Case

Answer 6

Ja TIME kann Schauspieler in einem Anwendungsfall sein. Aber sollte nicht primäre Akteur sein.Sie ist wirklich die Definition von Schauspieler in einem Anwendungsfall zu verletzen.

Primary actor is someone/thing which has a goal for interacting with the system. 

Welche Art von Ziel hat die Zeit?

Time ------> RunPayroll 

Wer profitiert von der Gehaltsabrechnung? Vielleicht versteckt Time Actor einen echten Schauspieler.

Payroll Administrator (primary actor) ---> RunPayroll --> Time (Supporting actor) 

Aber das gibt impresion dass Run Payroll Anwendungsfall manuell durch Payroll Administrator aufgerufen? Schließlich entwickeln wir ein Automatisierungssystem?

Aber bedenken Sie, dass, wenn wir die Payroll Administrator als primäre Schauspieler verwenden, dann können wir alle Systemfunktionen erfassen, die die Lauf der Lohn umgeben. Dazu gehören Funktionen, mit denen der Administrator für Gehaltsabrechnung und Diskrepanzen, manuelle Eingriffe, und Feiertage festlegen kann. [Lieber Dr. Use Case: Ist Clock Schauspieler]

Sie können diese schöne Ibm Artikel erhalten von Dear Dr. Use Case: Is the Clock an Actor?

Answer 7

ich mit @Novalis Zeit zustimmen Schauspieler sein kann, aber nicht primäre Schauspieler, weil Jeder Stakeholder ist ein Akteur und die Zeit kann für den Nutzen oder Verlust eines Stakeholders verantwortlich sein, so dass er als sekundärer Akteur oder welcher Name auch immer angegeben werden kann.

Answer 8

Bis ich besser weiß, dass ich Zeit als Schauspieler ein wenig verwirrend finden, vor allem, weil Schauspieler Akt und Zeit auf die Tatsache zurückzuführen ist, dass die Dinge im Wandel sind: die Erde um die Sonne dreht, Kristalle pulsiert. Wir transformieren die aggregierte Nebenwirkung dieser Änderungen mit Wechsel-zu-Zeit-Konverter Tools (d. H. Uhren!) In die von Menschenhand erstellte Skala nennen wir: Zeit.

Answer 9

Ich stimme auch zu, dass Time in diesem Zusammenhang kein Hauptakteur ist. Ich möchte ein paar Erklärungen hinzufügen, um die Idee zu unterstützen, dass "Zeit als Schauspieler" sehr oft keine gute Idee ist.
(1) Geben wir dem Ding einen anderen Namen und eine brauchbare Definition. Die Zeit kann gemessen werden. Aber es ist ein sehr komplexes wissenschaftliches Problem, genau das Konzept als solches zu definieren. Für den täglichen Gebrauch macht es wenig Sinn, eine Interaktion damit zu beschreiben. Eine Beschreibung und ein Name für die Rolle, die besser zu mir passt, ist etwas, das die Zeit misst und in der Lage ist, darüber zu informieren, z. Zeitdienst
(2) Wir können die Zeit überall messen. Zeit ist nicht nur draußen in der Umwelt. Nur wenn der Benutzer verlangt, dass unser Zeitprovider nicht Teil des zu erstellenden Systems sein soll, sollten wir eine Interaktion mit einem sekundären Akteur TimeService und einer Schnittstelle dafür beschreiben. Aber meistens ist TimeService eine der Klassen oder Komponenten, die die Anwendungsfälle realisieren und implementieren und als Akteur in einem UC-Diagramm fehlen.
For more details: this is a short text I wrote about it.

Answer 10

In my answer zu einem similar question, ich sagte, dass sie Art und Weise zu modellieren, die zu einem bestimmten Zeitpunkt ausgeführt werden soll, ist ein Schauspieler namens ‚Scheduler‘ zu schaffen, die eher ein Platzhalter ist und nicht erwähnt, eine Technologie . Die Idee ist, dass es eine Person oder Komponente geben muss, deren Aufgabe es ist, die Zeit zu überwachen und dann einen bestimmten Anwendungsfall zu initiieren. Der Anwendungsfall besagt, dass dieser Anwendungsfall zum Zeitpunkt X beginnt, abhängig von den Anforderungen des Anwendungsfalls.Ja, die Zeit ist ein Faktor, der modelliert werden kann, aber die Art und Weise, wie der Lehrer vorgeht, scheint für mich eine Strecke zu sein, denn die Zeit selbst ist es egal, was passiert, wenn es so ist. Er verallgemeinert sich in dem Versuch, alle Arten von Anwendungsfällen in sein Modellierungskonzept einzupassen.

In der postulierten Diskussion mit dem Ausbilder würde ich fragen: "Ist die Zeit selbst - kein anderer Mechanismus, Person oder Software - die Entität, die auf das System einwirkt?" Die naheliegende Antwort ist "Nein", aber die Idee ist, dass es ein beliebiger Akteur sein kann, der a) Zeit messen kann und b) weiß, dass bestimmte Anwendungsfälle zeitempfindlich sind.

Ich mag die article in @Igor's answer, da es wirklich einen großen Teil des Problems abdeckt, die Zeit zu einem Hauptakteur zu machen.

Schauspieler werden normalerweise durch eine Art Substantiv dargestellt, so dass ein Kompromiss darin besteht, eine Uhr als den Schauspieler anstelle von Kapital-T 'Zeit' zu verwenden. Wie andere Poster stimme ich zu, dass es unwahrscheinlich ist, dass Sie den Lehrer überzeugen, aber es lohnt sich, die Diskussion zu führen, weil es hilft zu verstehen, wie er über das Modellieren im Allgemeinen denkt.

Obwohl ich merke, dass es zu spät ist für die Klasse, die diese Frage erzeugt hat, poste ich diese Antwort in der Hoffnung, anderen zu helfen, die das Problem der Modellierung in einem Anwendungsfall kennengelernt haben oder einen Professor getroffen haben eigene Meinung zum Modellieren mit UML Use Cases.