さて、真の偽の質問について：
a) システムのアクターは、人間または別のソフトウェア コンポーネントによってのみ表されます。
私が TRUE と答えると、先生はそれを間違っているとマークしました。それは、私がハードウェア コンポーネントを見逃したと彼が考えたからではなく (部分的に認めると思います)、彼の言葉によると:
「TIMEも俳優です。」
ユース ケース図では、TIME をアクターとしてどのように考えますか??
時間を役者とみなす参考文献があれば参照してください。私は何も見つけていません。正直なところ、意味がないと思います。時間はそれ自体では機能しません。システムまたはスケジュールに従って働く人です。
UML 2 ユース ケース ダイアグラムのガイドラインはこちら...
http://www.agilemodeling.com/style/useCaseDiagram.htm
... 時間をどのように表現できるかを示します。
時間はどのようにアクターであり、ユースケース図でどのように表されているかを教師に説明するように先生に依頼する必要があると思います.
ああ、ウィキペディアは時間はアクターであると言っているので、それは真実でなければなりません:
時間が俳優であることに同意しません。あなたが本当に考えなければならないのは、誰がアクションから恩恵を受け、タイムテーブルの作成と実行を設定する機能の説明を入れるかということです. この記事を見てください：
アクターは、ユース ケースを開始する人または何かと見なすことができます。スケジュールされたタスクは「時間」によって開始されます。この意味で、ユースケースを開始するため、「時間」はアクターです。
例：
レポートは 6 時間ごとに生成する必要があります。したがって、生成タスクは 6 時間ごとに開始されるため、時間「6 時間」はアクターでなければなりません。
俳優としての時間を持つことに同意します。システムのユースケースが特定の時点でトリガーされた場合、私は Time をアクターとしてモデル化し、それをそのユースケースに関連付けます。これらのシナリオでは、時間は外部エンティティ (したがってアクター) と見なすことができます。
はい、TIMEはユースケースでアクターになることができます。ただし、主要なアクターであってはなりません。ユース ケースでのアクターの定義に実際に違反しているためです。
Primary actor is someone/thing which has a goal for interacting with the system.
時間はどのような目標を持っていますか?
Time ------> RunPayroll
給与計算を実行することで得をするのは誰ですか? 多分タイムアクターは本物のアクターを隠しています。
Payroll Administrator (primary actor) ---> RunPayroll --> Time (Supporting actor)
しかし、これは給与管理者によって手動で実行された給与計算ユースケースの印象を与えますか? 自動化システムを開発しているのですか？
ただし、Payroll Administrator をプライマリ アクターとして使用すると、給与計算の実行に関連するすべてのシステム機能をキャプチャできることに注意してください。これには、給与計算管理者が給与計算を実行するためのタイムテーブルを設定し、不一致、手動介入、および休日を処理できるようにする機能が含まれます。[Dear Dr. ユースケース: 時計はアクターですか]
Dear Dr. Use Case: Is the Clock an Actor?から素敵な Ibm の記事を入手できます 。
また、この文脈では時間が主要なアクターではないことに同意します。「役者としての時間」というのはあまり良い考えではないことが多いという考えを裏付けるために、いくつかの説明を追加したいと思います。
(1)ものに別の名前と実行可能な定義を付けましょう。時間が計測できます。しかし、概念そのものを正確に定義することは、非常に複雑な科学的問題です。したがって、日常的に使用する場合、それとの相互作用を説明することはほとんど意味がありません。私に適したロールの説明と名前は、時間を測定し、それについて通知できるものです。たとえば、TimeService です。
(2) 時間はどこでも測れる。時間は外の環境だけではない. ユーザーがタイム プロバイダーを構築するシステムの一部にしてはならないことを要求した場合にのみ、セカンダリ アクター TimeService との相互作用とそのインターフェイスを記述する必要があります。しかし、ほとんどの場合、TimeService はユース ケースを実現/実装するクラスまたはコンポーネントの 1 つであり、UC 図のアクターとしては存在しません。
詳細については、これについて私が書いた短いテキストです。
同様の質問に対する私の回答で、特定の時間に実行する必要があるアクティビティをモデル化する方法は、「スケジューラ」と呼ばれるアクターを作成することであると述べました。これは、よりプレースホルダーであり、テクノロジについては言及していません。アイデアは、時間を監視してから特定のユースケースを開始することを担当する人またはコンポーネントが必要であるということです。ユース ケースは、ユース ケースのニーズに応じて、「このユース ケースは X の時点で開始します」と表示します。はい、時間はモデル化できる要素ですが、インストラクターが行っている方法は、時間自体がいつ何が起こるかを気にしないため、私にはストレッチのように思えます。彼は、あらゆるタイプのユースケースをモデリングの概念に当てはめようとして、過度に一般化しています。
インストラクターとの想定された議論の中で、私は「時間そのものは、他のメカニズム、人、またはソフトウェアではなく、システムに作用するエンティティですか?」と尋ねます。明白な答えは「いいえ」ですが、考えとしては、a) 時間を測定でき、b) 特定のユースケースが時間に敏感であることを知っている任意のアクターが存在する可能性があるということです。
Timeを主要なアクターにすることに関する問題の多くを実際にカバーしているため、@ Igorの回答の記事が気に入っています。
アクターは通常、ある種の名詞で表されるため、大文字の T 'Time' の代わりに時計をアクターとして使用するのが妥協策かもしれません。他のポスターと同様に、教師を説得する可能性は低いと思いますが、モデリング全般について教師がどのように考えているかを理解するのに役立つので、議論する価値はあります。
この質問を生成したクラスには遅すぎることはわかっていますが、ユースケースでのモデリング時間の問題に遭遇した他の人を助けることを期待して、または独自の意見を持っている教授に出会うことを期待して、この回答を投稿しますUML ユース ケースを使用してモデル化する方法。
すべての利害関係者は俳優であり、時間は利害関係者の利益または損失に責任を負う可能性があるため、時間は二次俳優またはあなたが付けたい名前と見なすことができるため、@Novalisの時間は俳優になることができますが、主要な俳優ではないことに同意します.
時間はシステムと相互作用します。たとえば、時間が過ぎて、システムはその「アクション」に基づいて何かをしなければなりません。