Необходимо включить контрольный журнал и журнал ошибок в мою диаграмму вариантов использования

Question

Наша команда поддержки приложений предлагает внедрить контрольный журнал, расширенную регистрацию ошибок и новое пакетное задание для внутренней обработки некоторых данных. Прежде чем реализовать это, я хочу внести изменения в мою диаграмму вариантов использования. Я думаю, что контрольный журнал должен быть примером использования, но не уверен насчет регистрации ошибок. Должно ли это рассматриваться как вариант использования. Эта ссылка http://www.umlchannel.com/en/uml/item/24-use-case-actor-system-timer говорит, что в прецеденте иногда может быть НЕТ актера. Можем ли мы рассматривать регистрацию ошибок как вариант использования без актера? Могу ли я рассматривать пакетное задание как сценарий использования, в котором пакетный планировщик выступает как субъект?

Мне нужно еще одно уточнение: я знаю, что актер может быть человеком или другой системой. Можем ли мы рассматривать событие (которое взаимодействует с решением посредством варианта использования) как субъект?

Answer 1

Вариант использования должен иметь актера, поскольку в основном он просто описывает добавленную стоимость для своего актера. Автор ссылочной статьи здесь просто неправ.

P. 637 из спецификации UML 2.5:

Каждый UseCase определяет какое-то поведение, которое субъект может выполнять в сотрудничестве с одним или несколькими субъектами.

...

Предметом UseCase может быть система или любой другой элемент, который может иметь поведение, например Компонент или Класс. Каждый UseCase указывает единицу полезной функциональности, которую субъект предоставляет своим пользователям.

NB. Хотя UML является "истинным источником", он не очень хорошо знаком с вариантами использования. Вместо этого я настоятельно рекомендую Биттнер / Спенс.

Есть несколько способов приблизиться к Log error "вариант использования". Один будет <extend> случаи использования с Log error, Но на самом деле есть несколько недостатков с этим. Log error может дать дополнительную ценность в долгосрочной перспективе (улучшения системы и исправление ошибок), но это не априорная добавленная стоимость. Также вы просто загромождаете свои диаграммы вариантов использования.

Второй способ - изменить перспективу и включить саму "систему" ​​в качестве актера. Но это анти-паттерн. Так что не рекомендуется.

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

Ваши дополнительные вопросы:

• Пакетное задание не является вариантом использования, но оно может быть реализовано как пакетное задание, а планировщик может быть действующим лицом.
• Нет, событие - это событие, а не актер. Событие может инициировать цепочку действий, являющихся частью варианта использования.