31. Моделирование вариантов использования. Основной и альтернативные потоки событий. Привести пример моделирования варианта использования «Покупка бензина на автозаправочной станции».
Подготовить диаграмму вариантов использования. Обычно клиент платит за бензин наличными. Кроме отношения <include> добавить отношение расширения <extend>, с помощью которого описывается дополнительное поведение, возникающее, когда клиент платит кредитной картой снаружи или внутри АЗС. Возможны дополнительные услуги АЗС, в виде мойки машины, посещения кафетерия, приобретения авто товаров, продуктов питания и авто принадлежностей и т.п.
Сценарий:
Этапы основного потока событий:
Вариант использования начинается с регистрации пользователя.
Система запоминает пользователя и предоставляет доступ к обеспечению.
3. Клиент выбирает перечень услуг из всех предоставленных.А0
4. Если выбрана заправка пользователю дается чек на заправку. А1
4.1. Если выбрана мойка пользователю дается чек на мойку. А1.1.
4.2. Если выбрана покупка пользователю дается покупка и чек на покупку.А1.2.
5. Пользователь выбирает категорию оплаты.
6 Пользователь подтверждает цену.
10. Система запрашивает тип кредитной карточки, ее номер, имя владельца и дату завершения срока действия.
11. Пользователь вводит тип кредитной карточки, ее номер, имя владельца и дату завершения срока действия.
12 Система подтверждает продажу по кредитной карточке. А3. А4.Е1.
13. Система генерирует и показывает пользователю код подтверждения.
14. Пользователь подтверждает получение кода.
15. Вариант использования завершается.
Альтернативные потоки событий
А0: Клиент выбрал и оплатил услуги через терминал.
А1: Нет бензина. В этом случае:
Система выводит сообщение, что нет бензина.
Пользователь подтверждает просмотр сообщения.
Поток возвращается на этап 2 основного потока событий.
А1.1: Закончилась вода и/или моющие средства. В этом случае:
Система выводит сообщение, что мойка недоступна.
Пользователь подтверждает просмотр сообщения.
Поток возвращается на этап 2 основного потока событий.
А1.2: Нет необходимого товара. В этом случае:
Система выводит сообщение, что мойка недоступна.
Пользователь подтверждает просмотр сообщения.
Поток возвращается на этап 2 основного потока событий.
А2: Счет пользователя не обнаружен. В этом случае:
Система выводит сообщение о том, что счет пользователя не обнаружен.
Поток возвращается на этап 10 основного потока событий.
А3: Недостаточно денег на счете. В этом случае:
Система выводит сообщение о том, что остаток на кредитной карточке не позволяет завершить транзакцию.
Поток возвращается на этап 10 основного потока событий.
Потоки ошибок
Е1: Кредитная система недоступна. В этом случае:
Система выводит сообщение о недоступности кредитной системы.
Поток возвращается на этап 10 основного потока событий.
32. Анализ требований. Уровни требований к информационной системе. Документ об образе и границах проекта в языке объектного моделирования UML. Структура спецификации требований для Вашей курсовой работы. (126-131)
Анализ требований — это процесс сбора требований к программному обеспечению (ПО), их систематизации, документированию, анализа, выявления противоречий, неполноты, разрешения конфликтов в процессе разработки программного обеспечения. В англоязычной среде также говорят о дисциплине «инженерия требований» (англ. Requirements Engineering). Полнота и качество анализа требований играют ключевую роль в успехе всего проекта. Требования к ПО должны быть документируемые, выполнимые, тестируемые, с уровнем детализации, достаточным для проектирования системы.
Виды требований по уровням
Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).
Функциональные требования — охватывают предполагаемое поведение системы, определяя действия, которые система способна выполнять[источник не указан 843 дня]. Описывается в системной спецификации (англ. system requirement specification, SRS).
Определение образа и границы проекта. Документ об образе и границах проекта содержит бизнес-требования к продукту. Описание образа проекта позволит всем заинтересованным лицам в общих чертах понять назначение продукта. Границы проекта определяют, что следует реализовать в этой версии, а что — в следующих. Образ и границы проекта — хорошая база для оценки предлагаемых требований, Образ продукта должен оставаться от версии к версии относительно стабильным, но для каждого выпуска необходимо составлять отдельный документ о границах.
Спецификация требований (спецификация - графический или какой-либо иной формальный способ задания требований) - охватывает функциональные, нефункциональные, требования предметной области и интерфейсные требования.