Файл: Лаб. занятие № 4+.doc

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«Пермская государственная сельскохозяйственная академия

имени академика Д.Н. Прянишникова»














ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

направление 230700 «Прикладная информатика»




Лабораторное занятие № 4


Тема: Модель прецедентов: описание прецедентов


Учебные вопросы:

  1. Задачи и описание.

  2. Типы и форматы прецедентов.

  3. Задачи и рамки прецедента.
















Вопрос 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. Оформление продажи

Основной исполнитель. Кассир.

Заинтересованные лица и их требования:
  • Кассир. Хочет точно и быстро ввести данные, не допуская ошибок в платеже, поскольку недостача вычитается из его зарплаты.
  • Продавец. Хочет получить свои комиссионные от продажи
  • Покупатель. Хочет купить товары и быстро оформить покупку с минимальными усилиями. Хочет получить подтверждение факта покупки для возможного возврата товара.
  • Компания. Хочет аккуратно записать транзакцию и удовлетворить интересы покупателя. Хочет удостовериться, что служба авторизации платежей зафиксировала все данные о платеже. Заинтересована в обеспечении устойчивости к сбоям; хочет продолжать регистрировать продажи, да­же если серверные компоненты (например, служба удаленной проверки кредитоспособности) не­доступны. Хочет автоматически обновлять бухгалтерскую документацию и вести складской учет.


  • Государственные налоговые службы. Хотят получать налог от каждой продажи. Таких служб может быть несколько, в том числе национальная и местная.
Предусловия. Кассир идентифицирован и аутентифицирован.
Результаты (Постусловия). Данные о продаже сохранены. Налоги корректно вычислены, Бухгал­терские и складские данные обновлены. Комиссионные начислены. Чек сгенерирован. Авторизация платежа выполнена.

Основной успешный сценарий (или основной процесс)

  1. Покупатель подходит к кассовому аппарату POS-системы с выбранными товарами.

  2. Кассир открывает новую продажу.

  3. Кассир вводит идентификатор товара.

  4. Система записывает наименование товара и выдает его описание, цену и общую "стоимость. Цена вычисляется на основе набора правил.

Кассир повторяет действия, описанные в п.п. 3-4, для каждого наименования товара.

  1. Система вычисляет общую стоимость покупки с налогом.

  2. Кассир сообщает покупателю общую стоимость и предлагает оплатить покупку.

  3. Покупатель оплачивает покупку, система обрабатывает платеж.

  4. Система регистрирует продажу и отправляет информацию о ней внешней бухгалтерской системе (для обновления бухгалтерских документов и начисления комиссионных) и системе складского учета (для обновления данных).

  5. Система выдает товарный чек.

  6. Покупатель покидает магазин с чеком и товарами (если он что-то купил).


Расширения (или альтернативные потоки)

*а. При каждом выходе системы из строя.

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

1. Кассир перезапускает систему, регистрируется и предлагает восстановить предыдущее состояние.

2. Система восстанавливает предыдущее состояние.

2а. Система определяет аномалию, повлекшую сбой.

  1. Система уведомляет об ошибке кассира, регистрирует ошибку и переходит в началь­ное состояние.

  2. Кассир начинает новую продажу.

За. Неправильный идентификатор.

1. Система уведомляет об ошибке и отменяет ввод данного наименования товара.

3б. В рамках одной категории существует несколько различных наименований товара, и идентифи­цировать конкретное наименование не нужно (например, 5 пакетов леденцов).

1. Кассир может ввести идентификатор категории товара и количество единиц.

3в. Покупатель просит кассира отменить покупку одного из товаров.

1. Кассир вводит идентификатор товара для удаления из продажи.

2. Система отображает обновленную промежуточную стоимость.

3г. Покупатель просит кассира отменить продажу.

1. Кассир отменяет продажу.

3д. Кассир приостанавливает продажу.

1. Система записывает сведения о продаже таким образом, чтобы они были доступны с любого терминала POS-системы.

4. Сгенерированная системой цена товара не устраивает покупателя (например, у него есть дис­контная карта и он рассчитывает на более низкую цену товара).

  1. Кассир вводит команду об изменении цены.

  2. Система вычисляет новую цену.

5а. Система выявляет сбой при коммуникации с внешней службой вычисления налога.

1. Система перезапускает службу с данного узла POS-системы и продолжает работу.

1а. Система определяет, что служба не перезапускается.

  1. Система сигнализирует об ошибке.

  2. Кассир может вручную вычислить и ввести сумму налога либо отменить продажу.

5б. Покупатель сообщает о положенной ему скидке (например, для сотрудников данного предпри­ятия или постоянных покупателей).

  1. Кассир отправляет запрос на скидку.

  2. Кассир вводит идентификационные данные покупателя.

  3. Система представляет сумму скидки, вычисленную на основе дисконтных правил.

5в. Покупатель сообщает об открытом в данном магазине кредите на фиксированную сумму и просит оформить продажу с его помощью.

  1. Кассир отправляет запрос на оформление платежа с использованием открытого кредита,

  2. Кассир вводит идентификационную информацию о покупателе.

  3. Система снижает стоимость покупки (вплоть до 0) и уменьшает оставшуюся сумму кредита.

6. Покупатель сообщает, что хочет оплатить покупку наличными, но у него недостаточно денег.

1 а. Покупатель использует альтернативный способ платежа.

16. Покупатель просит кассира отменить продажу. Кассир отменяет продажу в системе.


7а. Оплата наличными.

  1. Кассир вводит предложенную покупателем сумму.

  2. Система вычисляет положенную сдачу и открывает кассу с наличностью.

  3. Кассир складывает поученные деньги и выдает сдачу покупателю.

  4. Система регистрирует платеж наличными.

7б. Оплата по кредитной карточке.

1. Покупатель вводит информацию о своей кредитной карточке.

2. Система отправляет запрос на авторизацию платежа внешней системе службы авторизации платежей и запрашивает подтверждение платежа.

2а. Система определяет сбой при взаимодействии с внешней системой.

  1. Система сигнализирует об ошибке кассиру.

  2. Кассир просит покупателя изменить тип платежа.

3. Система получает информацию о подтверждении платежа и сообщает об этом кассиру.

3а. Система получает информацию об отказе в выполнении платежа,

  1. Система сообщает об отказе кассиру.

  2. Кассир просит покупателя изменить тип платежа.

4. Система регистрирует платеж по кредитной карточке, включая информацию о подтверждении платежа.

5. Система предоставляет механизм ввода подписи для платежа по кредитной карточке.

6. Кассир просит покупателя подписать чек на оплату по кредитной карточке, Покупатель вводит подпись.

7в. Оплата чеком.

7г. Оплата по дебитной карточке.

7д. Покупатель предоставляет купоны.

1. До обработки платежа кассир вводит информацию о каждом купоне, в соответствии с которой система снижает стоимость покупки. Система регистрирует предъявленный купон для нужд бухгалтерии.

1а. Купон действует не для всех выбранных товаров,

1. Система сигнализирует об ошибке кассиру.

9а. Генерация чека.

1.Система выводит формы и чеки для каждого товара.

9б. Покупатель просит выдать ему подарочный чек (без указания цены).

1. Кассир вводит запрос на подарочный чек, и система выдает его.

Специальные требования

  • Сенсорный экран с интерфейсом пользователя для большого плоского монитора. Текст должен быть виден с расстояния один метр.

  • Отклик службы авторизации в 90% случаев приходит в течение ЗО секунд.

  • Каким-то образом нужно обеспечить робастное восстановление информации в случае сбоя при доступе к удаленным службам, таким как система складского учета.

  • Возможность локализации (представления на различных языках) отображаемого текста.

  • Возможность добавления новых бизнес-правил на шагах 3 и 7 в процессе функционирования системы.

Список технологий и типов данных

За. Идентификатор товара считывается со штрих-кода (при наличии последнего) лазерным скане­ром или вводится с клавиатуры.

3б. Идентификатор товара может определяться по схемам кодирования UPC, EAN, JAN или SKU.

7а. Информация об открытом кредите вводится с помощью считывающего устройства или с клавиатуры.

7б. Подпись при оплате чеком ставится на бумажном документе. Однако ожидается, что в течение двух лет большинство покупателей будут требовать цифровые устройства считывания подписи.