Должен ли планировщик быть актером в диаграмме прецедентов

Question

Допустим, что планировщик, входящий в состав системы, отвечает за отправку еженедельных писем пользователям. Должен ли «планировщик» рассматриваться как актер или должен ли он моделироваться как прецедент?

Рекомендации по выбору актеров говорят: Если: это фактическое лицо, взаимодействующее с вашей системой. Если «Да» его Актер Else: Это что-то, что вы можете изменить внутри системы. Если «Нет» его Актер

Планировщик не является лицом. И вы можете изменить его функционирование. Но моя кишка говорит, что это может быть актером. Немного помогло бы здорово.

Answer 1

Руководящий принцип более высокого уровня: если это поможет вам понять дизайн, включите его в диаграмму. Если это только вводит ненужный шум, оставьте это.

Кроме того, еще более высокий уровень руководства: Использовать здравый смысл.

Answer 2

Я часто моделирую планировщиков и других внешних агентов, связанных с временем, в качестве действующих лиц. Это имеет смысл, это понятно, не противоречит чему-либо в UML или общей практике моделирования OO, и это хорошо подходит для большинства стратегий реализации.

Answer 3

@CesarGon Риск может заключаться в том, что вы используете прецедент (диаграммы) как метод проектирования, а не метод требований. Поскольку основное внимание в технических требованиях будет уделяться задачам пользователя против системы и действующих лиц, взаимодействующих с системой. У участника TIME нет целей пользователя против системы, поэтому я пытаюсь найти актера, у которого есть цель или интерес к системе. Кого волнует, когда еженедельная электронная почта не отправляется? Актер TIME Я добавляю в качестве второстепенного актера. Актер TIME помогает «реальному» актеру достичь цели пользователя.