Okay, auf einer wahren falschen Frage:
a) Die Akteure eines Systems werden nur durch Menschen oder andere Softwarekomponenten repräsentiert.
Ich sagte WAHR, und der Lehrer markierte es als falsch, nicht weil er dachte, dass ich Hardware-Komponenten verpasste (was ich teilweise zugeben würde), sondern weil auf seine Worte:
"Die Zeit ist auch ein Schauspieler."
Wie würde ein Use-Case-Diagramm TIME als einen Akteur betrachten?
Bitte beziehen Sie sich auf alle Bibliographien, die die Zeit als Schauspieler betrachten. 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.
Die UML 2 Use Case Diagramming Guidelines hier ...
... zeigen, wie die Zeit dargestellt werden kann.
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, dass Zeit ein Schauspieler ist, also muss es wahr sein:
Ich stimme nicht zu, dass die Zeit ein Schauspieler 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:
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 alle 6 Stunden erstellt werden. Also muss die Zeit "6 Stunden" ein Akteur sein, weil die generierte Aufgabe alle 6 Stunden gestartet wird.
Ich stimme der Zeit als Schauspieler zu. 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. Zeit kann in diesen Szenarien als externe Entität (und somit als Akteur) betrachtet werden.
Ja TIME kann in einem Anwendungsfall ein Akteur sein. Aber sollte nicht primäre Akteur sein.Sie ist wirklich die Definition von Schauspieler in einem Anwendungsfall zu verletzen.
%Vor%Was für ein Ziel hat die Zeit?
%Vor%Wer profitiert von der Lohnbuchhaltung? Vielleicht versteckt Time Actor einen echten Schauspieler.
%Vor%Aber das gibt den Eindruck, dass der Personalabrechnung-Anwendungsfall manuell vom Abrechnungsverwalter aufgerufen wird? Schließlich entwickeln wir ein Automatisierungssystem?
Aber denken Sie daran, wenn wir das verwenden Gehaltsabrechnungsadministrator als primärer Schauspieler, dann können wir alle erfassen Systemfunktionen, die das System umgeben Lohnabrechnung. Das beinhaltet Funktionen, die die Personalabrechnung ermöglichen Administrator zum Einstellen der Fahrpläne für Lohnabrechnung und zu handhaben Diskrepanzen, manuelle Eingriffe, und Ferien. [Lieber Dr. Use Case: Ist die Uhr ein Schauspieler]
Sie können diesen schönen Ibm Artikel von bekommen Sehr geehrter Herr Dr. Use Case: Ist die Uhr ein Schauspieler?
Ich stimme auch zu, dass die Zeit 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 praktikable 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 Umgebung . 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.
Für weitere Details: Dies ist ein kurzer Text, den ich darüber geschrieben habe.
In meine Antwort zu
In der postulierten Diskussion mit dem Lehrer 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 den Artikel in @Igor's Antwort , da er wirklich einen Großteil des Problems abdeckt, indem er Time zu einem Hauptakteur macht .
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 mir klar ist, dass es für die Klasse, die diese Frage erzeugt hat, zu spät ist, schreibe 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.
Ich stimme der @Novalis Zeit zu, kann aber kein primärer Akteur sein, weil jeder Stakeholder ein Akteur ist und die Zeit für den Nutzen oder Verlust eines Stakeholders verantwortlich sein kann und somit als sekundärer Akteur betrachtet werden kann oder welcher Name auch immer du geben willst.
Bis ich es besser weiß, finde ich die Zeit, ein Schauspieler zu sein, ein bisschen verwirrend, besonders weil Schauspieler act sind, und Zeit ist auf die Tatsache zurückzuführen, dass sich Dinge ändern. Die Erde dreht sich um die Sonne, Kristalle pulsieren. Wir transformieren den aggregierten Nebeneffekt dieser Änderungen mit change-to-time Konverter Werkzeugen (dh Uhren!) In die vom Menschen geschaffene Skala , die wir: time.