Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Варианты Использования (Use Case) => Тема начата: Galogen от 13 Июня 2007, 09:47:33
-
Коллеги, хотел прояснить ситуацию насчет вариантов использования типа create, read, update, delete (CRUD).
К примеру - имеем вариант использования Управление клиническими записями, которые включают такие возможные потоки событий как
создание новой клинической записи
редактирование имеющейся
чтение - просмотр имеющихся
удаление имеющейся.
Мы видим, что все эти потоки событий будут несколько отличаться друг от друга, но в реальности базируются на одном классе (или группе классов).
Это может выглядеть так:
Журнал клинических записей - кнопки создания новой, редактирования выделенной. просмотр выделенной или удаление выделенной. Т.е. есть только начальная разница - в 3 последних случаях нужно сначал выбрать запись, а в первом случае ее создавать.
С другой стороны можно определить например 2 ВИ: создать новую и редактировать (чтобы это не значило)
В общем как разрешается задача CRUD ВИ?
-
См. книгу Gunnar Övergaard, Karin Palmkvist - "Use-Cases Patterns and Blueprints", глава 20. CRUD.
-
См. книгу Gunnar Övergaard, Karin Palmkvist - "Use-Cases Patterns and Blueprints", глава 20. CRUD.
Ссылочку не дашь где ее взять?
-
вот какая-то добрая душа выложила: http://slil.ru/24506864
-
аналогично .. по крайней мере два варианта описания CRUD в ВИ подхода есть у Алистера Коуберна .. если не ошибаюсь, главной русской книжке по прецедентам
-
Хочу обновить эту тему.
Поскольку все равно до конца не укладывается как правильно и корректно применять подход к написанию CRUD ВИ, стоит ли связываться.
Есть паттерн, описанный в названной в данной теме книге Gunnar Övergaard, Karin Palmkvist - "Use-Cases Patterns and Blueprints", глава 20. CRUD.
Пример не плох, но не идеален. Не рассказано как описывать исключения и альтернативные ситуации с если.
ниже пример, который содержит определенные неточности, но который может послужить темой обсуждения. Как бы вы его реализовали?
Имя: Изменить записи о читателях
ID: 1
Краткое описание: Вариант использования описывает операции с
регистрационным
списком
Действующие лица: Библиотекарь
Предусловие: -
Постусловие: Записи читателя изменятся в соответствие с выполненным
действием
Основной поток:
• Система запрашивает требуемое действие
• Библиотекарь выбирает действие, после чего выполняется один из подчиненных потоков (Добавить/Удалить/Изменить/Перерегистрация читателя)
ID: 1.1 Добавить читателя
• Система запрашивает фамилию, имя и отчество читателя
• Библиотекарь вводит запрашиваемые данные
• Система создает новую запись о читателе в регистрационном списке
• Система возвращает номер читательского билета зарегистрированного читателя
ID: 1.2 Удалить читателя
• Система запрашивает номер читательского билета
• Библиотекарь вводит номер
• Система ищет читателя в регистрационном списке, после чего удаляет записи, ему соответствующие
ID: 1.3 Изменить данные читателя
• Система запрашивает номер читательского билета
• Библиотекарь вводит номер
• Система ищет читателя в регистрационном списке, после чего запрашивает новые данные
• Библиотекарь вводит новые данные о пользователе
• Система сохраняет изменения
ID: 1.4 Перерегистрация читателя
• Система запрашивает номер читательского билета
• Библиотекарь вводит номер
• Система ищет читателя в регистрационном списке, после чего обновляет его дату регистрации
Альтернативный поток событий
ID: 1.5 Читатель не найден
Если обнаруживается, что введенный номер читательского билета не соответствует ни одному читателю, то система выдаст сообщение об ошибке и предложит ввести номер заново либо отменить действие. При отмене выполнение варианта использования завершается
-
Я своим студентам настойчиво рекомендую писать «Обновить» вместо «Изменить», т.к. это лучше показывает цель — обеспечить актуальность информации. Т.е. результативный Update вместо функционального Edit.
-
"Обновить данные читателя" а добавление, удаление, чтение описать в альтернативных сценариях(если оно нужно).
Перерегистрация = "Обновить данные читателя"
-
... как правильно и корректно применять подход к написанию CRUD ВИ, стоит ли связываться.
А применять в каком случае? Описать подробно разработчику или учесть для себя что есть действия?
Также важен вопрос о доступности всех операций всем. Или например, частично (редактировать может только тот-то).
Если много проверок, ограничений и сложные действия , то лучше CRUD описать по отдельности каждое действие пользователя.
И как сказано на BeamTeam (http://beamteam.ru/2011/07/use-case-crud/) универсального решения нет.
-
Я своим студентам настойчиво рекомендую писать «Обновить» вместо «Изменить», т.к. это лучше показывает цель — обеспечить актуальность информации. Т.е. результативный Update вместо функционального Edit.
Денис, а в каком месте обновить вместо изменить? в названии всего ВИ или и в его частях?
-
"Обновить данные читателя" а добавление, удаление, чтение описать в альтернативных сценариях(если оно нужно).
Перерегистрация = "Обновить данные читателя"
Не совсем понял вашу мысль, уважаемый.
-
Денис, а в каком месте обновить вместо изменить? в названии всего ВИ или и в его частях?
Весь use case «Обновить реестр читателей», внутри — «Обновить карточку читателя».
-
А применять в каком случае? Описать подробно разработчику или учесть для себя что есть действия?
Также важен вопрос о доступности всех операций всем. Или например, частично (редактировать может только тот-то).
Если много проверок, ограничений и сложные действия , то лучше CRUD описать по отдельности каждое действие пользователя.
И как сказано на BeamTeam (http://beamteam.ru/2011/07/use-case-crud/) универсального решения нет.
В типовом случае типа работы со справочником: ввод, изменение и уадление данных по такой-то теме.
Мне беспокоит структура. В CRUD по идее есть несколько альтернатив и каждая из них основной поток, к которому будут исключения.
Как это реализовать правильно, оставаясь в парадигме описания Рекомендации по написанию спецификаций вариантов использования (http://www.uml2.ru/faq/use-cases/399-recommendations-for-use-case-specification) и Как моделировать альтернативные потоки? (http://www.uml2.ru/faq/use-cases/418-)
Поскольку у меня нет большой практике реальных проектов ведомых по use cases, а в учебных эту проблему решаем путем простой декомпозиции, то и есть непонятки использования
-
Весь use case «Обновить реестр читателей», внутри — «Обновить карточку читателя».
Понял согласен
-
Измененный вариант: с учетом предложений Дениса и Rruzz. Удалил перерегистрацию, объединив с обновлением карточки
Имя: Обновить реестр (список) читателей
ID: 1
Краткое описание: Вариант использования описывает операции с регистрационным списком
Действующие лица: Библиотекарь
Предусловие: -
Постусловие: Записи читателя изменятся в соответствие с выполненным действием
Основной поток:
• Система запрашивает требуемое действие
• Библиотекарь выбирает действие, после чего выполняется один из подчиненных потоков (Добавить/Удалить/Обновить карточку читателя)
ID: 1.1 Добавить читателя
• Система запрашивает фамилию, имя и отчество читателя
• Библиотекарь вводит запрашиваемые данные
• Система создает новую запись о читателе в регистрационном списке
• Система возвращает номер читательского билета зарегистрированного читателя
ID: 1.2 Удалить читателя
• Система запрашивает номер читательского билета
• Библиотекарь вводит номер
• Система ищет читателя в регистрационном списке, после чего удаляет записи, ему соответствующие
ID: 1.3 Обновить карточку читателя
• Система запрашивает номер читательского билета
• Библиотекарь вводит номер
• Система ищет читателя в регистрационном списке, после чего запрашивает новые данные
• Библиотекарь вводит новые данные о пользователе
• Система сохраняет изменения
Альтернативный поток событий
ID: 1.4 Читатель не найден
Если обнаруживается, что введенный номер читательского билета не соответствует ни одному читателю, то система выдаст сообщение об ошибке и предложит ввести номер заново либо отменить действие. При отмене выполнение варианта использования завершается
-
Я просто люблю рассматривать операции типа CRUD не как ВИ, а как расширения по Коберну.
Типа пытаемся обновить информацию о читателе(вводим фамилию для поиска), а его нету в базе -> по этому событию попадаем в расширение "Читателя нет в списке" -> далее сценарий расширения для добавления читателя.
Но глядя на ваше оформление, я как программист получил ту же самую информацию, поэтому оформление не принципиально.
Меня просто сначала сбило с толку что у вас много ВИ, не сразу увидел где там главный ВИ.