3

システムの一部であるスケジューラーが、毎週の電子メールをユーザーに送信する責任があるとしましょう。「スケジューラー」はアクターとして扱われるべきですか、それともユースケースとしてモデル化されるべきですか?

アクターを選択するためのガイドラインには次のように書かれています。「はい」の場合はアクターです。それ以外の場合: システム内で変更できるものですか。「いいえ」の場合は俳優

スケジューラーは人ではありません。また、その機能を変更することもできます。しかし、私の直感では、これは俳優になれると言っています。少しの助けは素晴らしいでしょう。

4

3 に答える 3

1

私はよく、スケジューラやその他の時間関連の外部エージェントをアクターとしてモデル化します。それは筋が通っており、理解しやすく、UML や OO モデリングの一般的な慣行と矛盾するものはなく、ほとんどの実装戦略にうまく適合します。

于 2010-03-05T00:54:46.543 に答える
1

@CesarGonリスクは、ユースケース（図）を要件手法ではなく設計手法として使用することです。要件テクニックとして、システムに対するユーザーの目標と、システムと対話するアクターに焦点が当てられます。TIMEアクターはシステムに対するユーザーの目標を持っていないので、システムに対して目標や関心を持つアクターを見つけようとします。毎週の電子メールが送信されない場合、誰が気にしますか? 二次俳優として追加する TIME 俳優。TIME アクターは、「本物の」アクターがユーザーの目標に到達するのを助けます。

于 2012-06-21T07:42:20.597 に答える
1

より高度なガイドラインでは、次のように述べられています。設計を理解するのに役立つ場合は、図に含めてください。不要なノイズが発生するだけの場合は、除外してください。

また、さらに高いレベルのガイドライン:常識を使用してください。

于 2010-02-11T15:45:08.130 に答える