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

Question

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

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

Answer 1

A use case must есть актер, так как в основном он просто описывает добавленную стоимость для своего актера. Автор данной статьи здесь просто ошибочен.

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

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

...

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

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

Существует несколько способов приблизиться к «случай использования» Log error. Можно было бы использовать <extend> прецеденты с Log error. Но на самом деле, есть пара недостатков с этим. Log error может дать дополнительную ценность в долгосрочной перспективе (исправления системы и исправления ошибок), но это не добавленная стоимость a-priori. Также вы просто загромождаете диаграммы использования.

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

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

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

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