Если несколько актеров имеют одни и те же цели в списке действующих лиц

Question

Крейг Ларман утверждает, что создание актера [/ User] -Головый список в виде таблицы/сетки является хорошим методом поиска примеров использования во время анализа требований. (Применение UML и паттернов - стр. 69 ff)

Некоторая простая таблица из двух столбцов должна быть достаточной для обеспечения хорошего обзора для этого примера; представьте себе следующий список Actor-Гол:

ActorGoal

AdminCreate User
" Read User
" .. (full CRUD)
" CRUD Entry
" Assign Entry (to User)
" ..

User Create Entry
" .. (full CRUD)
" CRUD himself?
" ..

Администратор может делать то, что Пользователя может + больше как управление пользователями из S ystem у NDER D АЗВИТИЯ или назначения записей в них.

Администратор и Пользователь четко разделяют некоторые цели (можем ли мы использовать термин «Использовать дело еще?»).

Im не совсем уверен, куда идти отсюда с точки зрения уточнения этого списка артистов.

Мой мозг говорит мне, что я могу сэкономить время и усилия повторного использования/абстракции здесь, так что я, скорее всего, в конечном итоге один общий суперкласс реализации CRUD запись поведения, где Администратор расширяет функциональные возможности, Управление целями (CRUD User, assign и т. Д.).

Но я знаю, что это скорее вопрос дизайна, чем анализа.
Я также знаю, что могу написать пример использования для этого отдельно: мне не нужно указывать, кто именно его использует, мне просто нужно знать, что это какой-то объект, который придерживается данного контракта [/ interface].

Когда пришло время подумать об абстракции?
Неужели я слишком часто себя чувствую, делая это прямо сейчас?
Должны ли мы оставить список Актер-Гол, как указано выше, и проверить его как «полный» Артефакт?

Поскольку классическая цель списка Actor-цель состоит в том, чтобы обеспечить некоторый краткий обзор для нашего следующего артефакта - диаграмма прецедентов - мы могли бы начать переход прямо здесь ?:

Использование Case Diagram делает все повторное использование часть намного более видимая (по крайней мере для меня). Было бы целесообразно принять избыточность прямо сейчас и позаботиться об этом на более поздних этапах (например, дизайн)?

Цените свой ввод!

EDIT: Кроме того, я не совсем уверен, о Пользователе CRUDing себя .. Но давайте не усложнять и прилипает к основному вопросу.

Answer 1

Это отличная идея определить примеры использования кандидатов в списке целей, как вы описали.

Проблемы при выявлении случаев использования

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

• некоторых опрошенных пользователей/бизнеса-специалисты описывают очень подробные пошаговые цели (соответствующие системным функциям), в то время как другие будут описывать довольно высокие цели целей пользователя. Поэтому вам понадобится третий столбец для идентификации goal level каждого варианта использования.

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

  • администратор утверждал manage authorizations и бизнес-пользователей утверждал manage authorization. Был ли такой же вариант использования? Нет: оказалось, что первый maintained assignment of authorizations в системе и второй был наделен полномочиями decide on authorizations assignment and request them от администратора.
  • покупатель объяснил, что для заказа на поставку кому-то необходимо до register a good receipt до оплаты счета.Складский клерк объяснил, что на складе они manage stock movement. Последнее, однако, оказалось, что те движения, где хорошие поступления, хорошие проблемы и переводы акций.

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

В общем случае необходимо провести кросс-проверку и согласование перед совместным использованием/повторным использованием вариантов использования. Повторное использование слишком быстро может потерять больше времени, чем ожидалось.

Прецедент диаграммы

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

Обычно рекомендуется not to abuse use case diagrams for functional decomposition (см. also here). Таким образом, диаграмма вариантов использования добавит немного больше тому, что у вас уже есть в списке.

Кроме того, <<Include>>, <<Extend>> и отношения обобщения должны использоваться едва ли, потому что они стремятся быстро сделать диаграмму трудно понять.

И, наконец, действительно ли абстракция и повторное использование происходят на уровне прецедента? Является ли это релевантным для участников вне системы? Если нет, то больше о деталях проектирования и реализации. Поэтому я бы предложил рассмотреть их больше в модели класса, которую вы создадите (или получите) для реализации вариантов использования.