Коллеги, добрый день. У меня к вам есть совсем нубовский вопрос. Сильно не пинайте.

Представим себе такую ситуацию. Например, есть абстрактный справочник "Автомобили", каждая запись которого содержит порядка 20-25 атрибутов. Пользователь может просматривать список всех автомобилей, при этом отображается только часть атрибутов. Выбрав конкретный автомобиль и нажав на кнопку, пользователь может просматривать и изменять все атрибуты выбранного автомобиля. Cистема ведет историю изменений.

Так вот. Пользователь может просмотреть историю изменений конкретного автомобиля. При этом UseCase "Просмотреть историю изменений" фактически будет состоять из двух шагов: 1. пользователь инициирует, 2. система отображает. Корректно ли создавать такой UseCase?

Сомнения возникают только из-за того, что историю можно будет просмотреть из двух UseCase'ов "Просмотреть список АО" и "Просмотреть/редактировать информацию об АО".

Спасибо.

Это смотря зачем пишутся юзкейсы. Смотрим на самое первое слово - "целесообразно". Цель создания описания в чём состоит?

Я бы отразил это в виде альтернативного потока сценария

to greesha: чтобы потом на основе кейсов написать требования

to bas: вот тут и возникают сомнения. надо будет в двух кейсах писать альтернативные потоки - "Просмотреть список АО" и "Просмотреть/редактировать информацию об АО". может все-таки лучше создать кейс "Просмотреть историю"?

Как пишет господин Крэг Ларман, а он вторит Алистеру Коберну, ВИ могут быть разного уровня: бизнеса, пользователя и подфункция.
Первый уровень охватывает какой-то бизнеспроцесс
Второй некоторую цель пользователя
Третий некую функцию системы, которую удобно выделить в ВИ

Оттолкнемся от цифры 2 - т.е. цель пользователя. Здесь Ларман предлагает такие критерии :
1. одобрение руководством "Чем вы занимались целый день?" - просматривал историю изменения!
2. элементарный бизнес-процесс - задача, которую выполняет один человек в одном месте в одно время в ответ на некоторое бизнес-событие, добавляющая измеримое бизнес-значение и переводящая данные в некоторое устойчивое состояние. - можно ли отнести ваш юзкейс к этому понятию?
3. размер - прецедент охватывает не единственное действие, а несколько шагов

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

Мне кажется в вашем случае, вариант мог бы выглядеть так.
предусловие - загружен справчоник автомобилей
1. клиент выбирает автомобиль (есть варианты - через поиск или выбирает из активного списка)
2. система отображает информацию о запрошенном автомобиле
3. клиент запрашивает историю изменений
4. система отображает историю изменений для данного автомобиля
в альтернативных процессах возможны нюансы, так же и ВИ может быть представлен по разному, но один шаг - это плохо (под шагом я понимаю стимул-реакция)

to bas: вот тут и возникают сомнения. надо будет в двух кейсах писать альтернативные потоки - "Просмотреть список АО" и "Просмотреть/редактировать информацию об АО". может все-таки лучше создать кейс "Просмотреть историю"?

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

to Galogen: спасибо за такой развернутый ответ.

Мне кажется в вашем случае, вариант мог бы выглядеть так.

Фактически, вы предлагаете мне немного поднять уровень детализации  - ваш кейс включает в себя 3 моих. И этот вариант хорош.

это вы уже ударились в структурирование

не совсем понял почему ударился просто в ходе описания возник такой вопрос


Может быть просто я не понимаю чего-то, что вам кажется элементарным?

не совсем понял почему ударился просто в ходе описания возник такой вопрос

не обращайте внимание на слово ударился:) Просто сначала выделяем ВИ уровня пользователя и быстро их прописываем, потом анализируем и если нужно структурируем, т.е. выделяем некоторые повторяющиеся наборы в отдельный ВИ.

Если следовать Коберну, то Ваша ошибка, что Вы пошли по стилю Якобсона - т.е. сразу стали рисовать и структурировать. Кобрен же говорит - ВИ - это тексты, а диаграммы это так иллюстрации на тему и они скорее опциональны, чем первичны.

Есть такой шаблон CRUD ВИ, который включает несколько основных альтернативных потоков: создание записи, посмотр записи, изменение записи, удаление записи + дополнительные сценарии - например поиск и просмотр истории.
Поскольку в Вашем случае эти манипуляции делают разные пользователи, наделенные разными правами, возможно рассмотрение каждого отдельного ВИ - либо объединить их, но как предлагал Виталий использовать предусловие в виде ВИ - проверка прав - как вы понимаете важный и довольно сложный компонент.

Хотя разделив данный ВИ, вы можете реализовать часть его. Т.е. можно ввести данные, но нельзя их скажем удалить. Что кажется не совсем корректным

Ну вот, пока писал, Эд все и рассказал Оставлю свой пост для истории.

А можно нескромный вопрос - что такое АО?

И я не понял почему у Вас 2 таких странных ВИ - "Просмотреть список АО" и "Просмотреть/редактировать информацию об АО". М.б. Вам сделать ВИ - "Работать со списком АО"? У вас это будет CRUD ВИ, в кот. будет входить и просмотр списка и просмотр\редактирование\удаление конкретной записи и просмотр истории изменения?

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

У меня есть кейс - "Вход в систему" - пользователь вводит логин-пароль, система проверяет, назначает права и открывает главное меню.
Есть несколько групп кейсов (пакетов) - по числу пунктов главного меню. Предусловие во всех - пользователь вошел в систему. Среди них есть группа кейсов - "Работа с автомобилями".

Группа "Работа с автомобилями" включает кейс "Просмотр списка", от которого отходят (extend) кейсы - "Создать", "Удалить", "Просмотреть/изменить"(в котором в альтернативном потоке идет запись истории), "Просмотреть историю".

И вот когда я начал это все описывать, получилось что "Просмотреть историю" - включает 2 шага. И тут я задумался...

Про CRUD я читал в свое время, и держу его в голове (потому что создание-просмотр-изменение-удаление встречается очень и очень часто, особенно при работе со справочниками). И, в принципе, в данном случае я его и использую.

Только вопрос встал непосредственно при описании всех кейсов. Если делать один большой CRUD - он будет труден для восприятия и будет включать кучу альтернативных.
Если идти тем путем, которым я пошел - некоторые кейсы получаются отличные, а некоторые - в два шага.

Вот теперь и думаю, что выбрать.

to bas: АО - это ачепятанный АМ , он же А/М, он же автомобиль.

Таки да.  Вопрос у меня стоит - писать один большой CRUD-кейс, или много маленьких.

А вы как думаете, что лучше?

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

З.Ы. чисто так для себя - а зачем редактировать историю изменений?

to bas: историю менять не надо спешил, недописывал.

Должно быть:
Группа "Работа с автомобилями" включает кейс "Просмотр списка", от которого отходят (extend) кейсы - "Создать АМ", "Удалить АМ", "Просмотреть/изменить АМ"(в котором в альтернативном потоке идет запись истории АМ), "Просмотреть историю АМ".

Система простая. Значит буду писать несколько маленьких. Значит будет и кейс "Просмотреть историю" из двух действий.

Всем большое спасибо!

ВИ "Просмотр списка" ни о чем не говорит. Нужно назвать хотябы "Просмотреть список а\м" (в названии ВИ главным словом всегда должен быть ГЛАГОЛ).

Группа "Работа с автомобилями" включает кейс "Просмотр списка", от которого отходят (extend) кейсы - "Создать АМ", "Удалить АМ", "Просмотреть/изменить АМ"(в котором в альтернативном потоке идет запись истории АМ), "Просмотреть историю АМ".

Я бы, имхо, говорил не о кейсах, а о сценариях. Кейс - это набор сценариев объединенных единой темой.

В любом случае стараемся делать настолько просто, насколько это нужно для проекта. Если проще и понятнее для всех расчленить кейс Работа со списком автомобилей - делайте это, тем более если в каждом таком выделенном ВИ, есть свои уникальные исключения. Если же они одинаковые и приводят к одинаковым результатм - можно описать один ВИ