Спецификация: варианты использования для CRUD

Question

Я пишу спецификацию требований к продукту. В этом документе я должен описать способы взаимодействия пользователя с системой на очень высоком уровне. Некоторыми из этих операций являются «Создать-Читать-Обновить-Удалить» для некоторых объектов.

Вопрос в том, как правильно писать сценарии использования этих операций? Могу ли я написать только один вариант использования с именем «Управление объектом x», а затем включить эти операции в состав вариантов использования? Или мне нужно создать один вариант использования для каждой операции, для каждого объекта? Проблема, которую я вижу с последним подходом, состоит в том, что я буду писать довольно много страниц, которые, по моему мнению, не способствуют пониманию проблемы.

Какая лучшая практика?

Answer 1

Первоначальная концепция вариантов использования заключалась в том, что они, как актеры и определения классов, и - честно говоря, все - наследуются, а также имеют отношения <<uses>> и <<extends>>.

Имеет смысл использовать суперкласс Use Case ("CRUD"). Многие варианты использования являются тривиальными расширениями "CRUD" с типом сущности, подключенным к сценарию использования.

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

Не стесняйтесь использовать наследование, чтобы упростить и нормализовать ваши варианты использования. Если вы используете инструмент UML, вы заметите, что в Use Cases есть стрелка «наследования».

Answer 2

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

(a) Если вы действительно делаете общий обзор взаимодействия, то накладные расходы очень малы

(b) Я считаю полезным указать набор общих вариантов использования для изменения «ресурсов», а затем расширения / переопределения определенных шагов для конкретных объектов. Очевидно, что общее поведение фиксируется в общих случаях использования ресурсов.

По мере развития вашего понимания домена (то есть, когда бизнес-пользователи предъявляют к вам больше требований), вы, скорее всего, добавите к CRUD, а не удалите его.

Answer 3

Я чувствую представление - если оно имеет смысл и читается - не имеет значения. Соответствие спецификации UML во всех деталях особенно не имеет значения.

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

• C: Какая форма операций вставки существует. Можете ли вы вставить строки не полностью заполнены? Можете ли вы вставить строки без идентификатора? Можете ли вы получить последний вставленный идентификатор? Вы можете отменить вставку выборочно? Что происходит при сбое дублирующихся ключей или ограничений? Есть ли эквивалент REPLACE INTO?

• R: По каким полям вы можете выбрать? Вы можете сделать произвольную группировку, заказы? Можете ли вы создать совокупные поля, псевдонимы? Как вы можете получить встроенные (имеет много и т. Д.) Данные? Как указать глубину рекурсии, пределы?

• U, D: см. R + C

Answer 4

Имеет смысл различать случаи рабочих процессов и жизненные циклы ресурсов / объектов. Они взаимодействуют, но они не одинаковы; имеет смысл указать их обоих.

Сценарии использования или более расширенные спецификации рабочего процесса обычно описывают, как дело может проходить через рабочий процесс системы. Обычно это включает взаимодействие с различными различными ресурсами. Эти взаимодействия часто можно охарактеризовать как C, R, U или D.

Жизненные циклы ресурса предоставляют модель процесса того, что может случиться с конкретным (типом) ресурса (объекта). Они часто являются тривиальными «цветочными» моделями, которые говорят: любой из C, R, U, D может случиться с этим ресурсом в любом порядке, поэтому они сами по себе не очень интересны.

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