Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: bustor от 22 Сентября 2008, 16:52:10
-
Коллеги, добрый день. У меня к вам есть совсем нубовский вопрос. Сильно не пинайте. :)
Представим себе такую ситуацию. Например, есть абстрактный справочник "Автомобили", каждая запись которого содержит порядка 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) кейсы - "Создать АМ", "Удалить АМ", "Просмотреть/изменить АМ"(в котором в альтернативном потоке идет запись истории АМ), "Просмотреть историю АМ".
Я бы, имхо, говорил не о кейсах, а о сценариях. Кейс - это набор сценариев объединенных единой темой.
В любом случае стараемся делать настолько просто, насколько это нужно для проекта. Если проще и понятнее для всех расчленить кейс Работа со списком автомобилей - делайте это, тем более если в каждом таком выделенном ВИ, есть свои уникальные исключения. Если же они одинаковые и приводят к одинаковым результатм - можно описать один ВИ
-
У меня есть кейс - "Вход в систему" - пользователь вводит логин-пароль, система проверяет, назначает права и открывает главное меню.
Есть несколько групп кейсов (пакетов) - по числу пунктов главного меню. Предусловие во всех - пользователь вошел в систему. Среди них есть группа кейсов - "Работа с автомобилями".
В определенной степени мне кажется тут на лицо ошибка или ситуация часто типичная в случае когда и разработка и формирование требований в одном лице...
Уже есть образ системы, с меню пунктами и реакцией на их выбор, отсюда и формирование ВИ идет. Может это неплохо, если говорить о реинжиниринге существующей системы.
С другой стороны можно отметить, что описанное вами решение шаблонно. Может это и хорошо? Т.е. есть ВИ вашего типа, который шаблонно ложится вот в такое решение, которое кажется вполне очевидным.
Если я бы реализовал ваш случай я по всей видимости сделал бы некий журнал - список авто, в нем бы сделал выбор нужного действия:
создать новый, изменить, удалить, просмотреть (чтобы не нарушить данные случайными манипуляциями), просмотреть историю
причем это была бы одна форма, которая загружалась бы в разных режимах. На форме были бы кнопки активные или видимые в зависимости от режима формы и прав пользователя