ВУЗ: Пермская государственная сельскохозяйственная академия имени академика Д. Н. Прянишникова
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлен: 18.10.2018
Просмотров: 1693
Скачиваний: 17
СОДЕРЖАНИЕ
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Вопрос 2. Типы и форматы прецедентов
Прецеденты типа "черный ящик" и системные обязанности
Прецедент П 1. Оформление продажи
Основной успешный сценарий (или основной процесс)
Расширения (или альтернативные потоки)
Список технологий и типов данных
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«Пермская государственная сельскохозяйственная академия
имени академика Д.Н. Прянишникова»
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
направление 230700 «Прикладная информатика»
Лабораторное занятие № 4
Тема: Модель прецедентов: описание прецедентов
Учебные вопросы:
-
Задачи и описание.
-
Типы и форматы прецедентов.
-
Задачи и рамки прецедента.
Вопрос 1. Задачи и описания
В контексте UP модель прецедентов (Use-Case Model) относится к дисциплине "Требования".
Требования – это весь набор прецедентов, т.е. модель функционирования системы и ее окружения.
Введем некоторые неформальные определения.
У потребителей и конечных пользователей есть свои задачи (которые в контексте UP называют потребностями), решение которых должна обеспечить компьютерная система.
Прецедент – это набор сценариев использования, в котором каждый экземпляр сценария представляет собой последовательность действий, выполняемых системой для достижения ощутимого для конкретного исполнителя результата.
Прецеденты – это механизм упрощения этапа формулировки требований для всех заинтересованных лиц. По существу это рассказы об использовании системы в процессе решения поставленных задач.
Основная идея состоит в исследовании и формулировке функциональных требований путем написания историй "из жизни системы". Эти истории помогают сформулировать различные задачи и представляют собой сценарии использования системы.1 Сила механизма прецедентов состоит в возможности масштабировать уровень сложности и формальности описания в зависимости от реальных потребностей.
Сценарий (scenario) – это специальная последовательность действий или взаимодействий между исполнителями и системой. Его иногда также называют экземпляром прецедента (use case instance). Это один конкретный сценарий использования системы либо один проход прецедента, например, сценарий успешной покупки товаров за наличный расчет, либо сценарий неудачного завершения покупки из-за прерванной транзакции по обработке данных кредитной карточки.
Основное внимание при описании прецедента нужно сконцентрировать на вопросе: "Как использование системы обеспечивает ощутимый для пользователя результат или решает его задачу?", а не на обдумывании системных требований в терминах свойств или функций. Прецеденты определяют пожелания или соглашения относительно поведения системы.
Описания прецедентов – это текстовые документы, а не диаграммы. Моделирование прецедентов – это процесс написания текста, а не рисования. Однако для иллюстрации имен прецедентов и исполнителей, а также их взаимоотношений в UML определены обозначения для диаграммы прецедентов.
Вопрос 2. Типы и форматы прецедентов
Прецеденты типа "черный ящик" и системные обязанности
Прецеденты типа "черный ящик" (black-box use cases) – это самый типичный и рекомендуемый тип прецедентов. Они не описывают внутреннюю работу системы, ее компоненты или дизайн. Наоборот, системе вменяются некоторые обязанности (responsibilities). Этот метафорический термин широко применяется в объектно-ориентированном проектировании: программные элементы имеют обязанности и взаимодействуют с другими элементами со своими обязанностями.
Определяя обязанности системы через прецеденты типа "черный ящик", можно указать, что должна делать система (функциональные требования), не расписывая, как это делать (не выполняя проектирование). Позднее, на этапе проектирования, создается решение, удовлетворяющее разработанной спецификации.
Стиль черного ящика |
Другой стиль (белый ящик) |
Система регистрирует покупку |
Система записывает сведения о покупке в базу данных. Или, еще хуже: система генерирует оператор SQL insert для данной продажи... |
Прецеденты описываются в различных форматах, в зависимости от потребностей, т.е. выделяют несколько степеней формализации описания прецедентов.
-
Сжатый – аннотация в виде одного абзаца. Обычно она описывает только главный успешный сценарий. Пример такого описания приведен выше для прецедента Обработка продажи (Process Sale).
Сжатый формат описания прецедента Обработка продажи (process sale).
Покупатель подходит к кассе с выбранными товарами. Кассир с помощью POS-системы регистрирует каждый товар. Система отображает информацию о каждом наименовании товара и вычисляет общую сумму. Покупатель вводит требуемую информацию; система ее верифицирует и регистрирует. Система выполняет инвентаризацию. Покупатель получает товарный чек и покидает магазин с покупками.
-
Свободный – неформальный стиль описания. Описание прецедента занимает несколько абзацев и охватывает различные сценарии. Примером такого описания является рассмотренный выше прецедент Возврат товара.
Свободный формат прецедента Возврат товара (Handle Returns), включающего некоторые альтернативные сценарии.
Основной успешный сценарий.
Покупатель подходит к кассе с товарами, подлежащими возврату. Кассир использует POS-систему для регистрации каждого возвращаемого товара...
Альтернативные сценарии.
-
Если в авторизации кредитной карточки отказано, кассир информирует об этом покупателя и предлагает ему другой способ оплаты покупки.
-
Если идентификатор товара в системе не обнаружен, система уведомляет об этом кассира и предлагает ему вручную ввести идентификационный код (возможно, штрих-код поврежден и его сложно считать).
-
Если у системы возникают сложности при коммуникации с внешней системой вычисления налога.
-
Развернутый – наиболее подробный стиль описания. При таком подходе детально описываются все шаги и варианты развития сценария, а также предусловия и результаты.
Развернутые описания прецедентов структурированы и содержат большое количество деталей. Их полезно использовать для углубления понимания целей, задач и требований. Такие описания можно обсуждать на семинарах по определению требований на начальной стадии проекта вместе с системным аналитиком, экспертами предметной области и разработчиками.
Для развернутого описания прецедентов существуют различные шаблоны форматирования. Однако чаще всего используется шаблон, приведенный на Web-узле www.usecases .org. Рассмотрим пример развернутого описания прецедента Оформление продажи для POS-системы «ТТ».
Прецедент П 1. Оформление продажи
Основной исполнитель. Кассир.
Заинтересованные лица и их требования:
-
Кассир. Хочет точно и быстро ввести данные, не допуская ошибок в платеже, поскольку недостача вычитается из его зарплаты.
-
Продавец. Хочет получить свои комиссионные от продажи
-
Покупатель. Хочет купить товары и быстро оформить покупку с минимальными усилиями. Хочет получить подтверждение факта покупки для возможного возврата товара.
-
Компания. Хочет аккуратно записать транзакцию и удовлетворить интересы покупателя. Хочет удостовериться, что служба авторизации платежей зафиксировала все данные о платеже. Заинтересована в обеспечении устойчивости к сбоям; хочет продолжать регистрировать продажи, даже если серверные компоненты (например, служба удаленной проверки кредитоспособности) недоступны. Хочет автоматически обновлять бухгалтерскую документацию и вести складской учет.
-
Государственные налоговые службы. Хотят получать налог от каждой продажи. Таких служб может быть несколько, в том числе национальная и местная.
Предусловия. Кассир идентифицирован и аутентифицирован.
Результаты (Постусловия). Данные о продаже сохранены. Налоги корректно вычислены, Бухгалтерские и складские данные обновлены. Комиссионные начислены. Чек сгенерирован. Авторизация платежа выполнена.
Основной успешный сценарий (или основной процесс)
-
Покупатель подходит к кассовому аппарату POS-системы с выбранными товарами.
-
Кассир открывает новую продажу.
-
Кассир вводит идентификатор товара.
-
Система записывает наименование товара и выдает его описание, цену и общую "стоимость. Цена вычисляется на основе набора правил.
Кассир повторяет действия, описанные в п.п. 3-4, для каждого наименования товара.
-
Система вычисляет общую стоимость покупки с налогом.
-
Кассир сообщает покупателю общую стоимость и предлагает оплатить покупку.
-
Покупатель оплачивает покупку, система обрабатывает платеж.
-
Система регистрирует продажу и отправляет информацию о ней внешней бухгалтерской системе (для обновления бухгалтерских документов и начисления комиссионных) и системе складского учета (для обновления данных).
-
Система выдает товарный чек.
-
Покупатель покидает магазин с чеком и товарами (если он что-то купил).
Расширения (или альтернативные потоки)
*а. При каждом выходе системы из строя.
Для ввода системы в строй и корректной обработки платежа нужно обеспечить восстановление всех транзакций и событий с любого шага сценария:
1. Кассир перезапускает систему, регистрируется и предлагает восстановить предыдущее состояние.
2. Система восстанавливает предыдущее состояние.
2а. Система определяет аномалию, повлекшую сбой.
-
Система уведомляет об ошибке кассира, регистрирует ошибку и переходит в начальное состояние.
-
Кассир начинает новую продажу.
За. Неправильный идентификатор.
1. Система уведомляет об ошибке и отменяет ввод данного наименования товара.
3б. В рамках одной категории существует несколько различных наименований товара, и идентифицировать конкретное наименование не нужно (например, 5 пакетов леденцов).
1. Кассир может ввести идентификатор категории товара и количество единиц.
3в. Покупатель просит кассира отменить покупку одного из товаров.
1. Кассир вводит идентификатор товара для удаления из продажи.
2. Система отображает обновленную промежуточную стоимость.
3г. Покупатель просит кассира отменить продажу.
1. Кассир отменяет продажу.
3д. Кассир приостанавливает продажу.
1. Система записывает сведения о продаже таким образом, чтобы они были доступны с любого терминала POS-системы.
4. Сгенерированная системой цена товара не устраивает покупателя (например, у него есть дисконтная карта и он рассчитывает на более низкую цену товара).
-
Кассир вводит команду об изменении цены.
-
Система вычисляет новую цену.
5а. Система выявляет сбой при коммуникации с внешней службой вычисления налога.
1. Система перезапускает службу с данного узла POS-системы и продолжает работу.
1а. Система определяет, что служба не перезапускается.
-
Система сигнализирует об ошибке.
-
Кассир может вручную вычислить и ввести сумму налога либо отменить продажу.
5б. Покупатель сообщает о положенной ему скидке (например, для сотрудников данного предприятия или постоянных покупателей).
-
Кассир отправляет запрос на скидку.
-
Кассир вводит идентификационные данные покупателя.
-
Система представляет сумму скидки, вычисленную на основе дисконтных правил.
5в. Покупатель сообщает об открытом в данном магазине кредите на фиксированную сумму и просит оформить продажу с его помощью.
-
Кассир отправляет запрос на оформление платежа с использованием открытого кредита,
-
Кассир вводит идентификационную информацию о покупателе.
-
Система снижает стоимость покупки (вплоть до 0) и уменьшает оставшуюся сумму кредита.
6. Покупатель сообщает, что хочет оплатить покупку наличными, но у него недостаточно денег.
1 а. Покупатель использует альтернативный способ платежа.
16. Покупатель просит кассира отменить продажу. Кассир отменяет продажу в системе.
7а. Оплата наличными.
-
Кассир вводит предложенную покупателем сумму.
-
Система вычисляет положенную сдачу и открывает кассу с наличностью.
-
Кассир складывает поученные деньги и выдает сдачу покупателю.
-
Система регистрирует платеж наличными.
7б. Оплата по кредитной карточке.
1. Покупатель вводит информацию о своей кредитной карточке.
2. Система отправляет запрос на авторизацию платежа внешней системе службы авторизации платежей и запрашивает подтверждение платежа.
2а. Система определяет сбой при взаимодействии с внешней системой.
-
Система сигнализирует об ошибке кассиру.
-
Кассир просит покупателя изменить тип платежа.
3. Система получает информацию о подтверждении платежа и сообщает об этом кассиру.
3а. Система получает информацию об отказе в выполнении платежа,
-
Система сообщает об отказе кассиру.
-
Кассир просит покупателя изменить тип платежа.
4. Система регистрирует платеж по кредитной карточке, включая информацию о подтверждении платежа.
5. Система предоставляет механизм ввода подписи для платежа по кредитной карточке.
6. Кассир просит покупателя подписать чек на оплату по кредитной карточке, Покупатель вводит подпись.
7в. Оплата чеком.
7г. Оплата по дебитной карточке.
7д. Покупатель предоставляет купоны.
1. До обработки платежа кассир вводит информацию о каждом купоне, в соответствии с которой система снижает стоимость покупки. Система регистрирует предъявленный купон для нужд бухгалтерии.
1а. Купон действует не для всех выбранных товаров,
1. Система сигнализирует об ошибке кассиру.
9а. Генерация чека.
1.Система выводит формы и чеки для каждого товара.
9б. Покупатель просит выдать ему подарочный чек (без указания цены).
1. Кассир вводит запрос на подарочный чек, и система выдает его.
Специальные требования
-
Сенсорный экран с интерфейсом пользователя для большого плоского монитора. Текст должен быть виден с расстояния один метр.
-
Отклик службы авторизации в 90% случаев приходит в течение ЗО секунд.
-
Каким-то образом нужно обеспечить робастное восстановление информации в случае сбоя при доступе к удаленным службам, таким как система складского учета.
-
Возможность локализации (представления на различных языках) отображаемого текста.
-
Возможность добавления новых бизнес-правил на шагах 3 и 7 в процессе функционирования системы.
Список технологий и типов данных
За. Идентификатор товара считывается со штрих-кода (при наличии последнего) лазерным сканером или вводится с клавиатуры.
3б. Идентификатор товара может определяться по схемам кодирования UPC, EAN, JAN или SKU.
7а. Информация об открытом кредите вводится с помощью считывающего устройства или с клавиатуры.
7б. Подпись при оплате чеком ставится на бумажном документе. Однако ожидается, что в течение двух лет большинство покупателей будут требовать цифровые устройства считывания подписи.