22. Нефункциональные требования и пример нефункциональных требований к интернет-системе бронирования авиабилетов. (134, 162, 213)

1. Нефункциональные требования. Описывают характеристики системы и ее окружение, а не поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.

2. Требования предметной области. Характеризует ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.

Данная классификация, приведенная в [20], в значительной степени искусственна, четкой границы между этими типами требований не существует, так как они порождаются исходя из нужд и желаний пользователя.

Нужды заказчика несколько труднее определить, чем его желания. Например, заказчик может захотеть, чтобы музыкальное приложение позволяло компьютерным новичкам гарантированно записывать музыку, но ему также может быть нужна периодическая функция автосохранения для избежания потери результатов работы. Является ли последняя характеристика функциональным требованием, или это часть проектирования? Это зависит от соглашения между разработчиком и заказчиком. Заказчик может согласиться с автосохранением, и тогда такая функция становится функциональным требованием, либо оставить разработчику право решать, как добиться безопасной работы для новичков. В этом случае автосохранение будет не требованием, а элементом дизайна, содействующим удовлетворению требований.

Нефункциональные требования могут относиться не только к самой программной системе. Одни могут относиться к технологическому процессу разработки ПО, другие – содержать перечень стандартов качества, накладываемых на процесс разработки, третьи – указания на использование определенных CASE – средств и описание процесса проектирования, четвертые – обосновывать необходимые ресурсы, организационные возможности организации – разработчика, возможности взаимодействия системы с другими системами, а также вопросы техники безопасности, защиты интеллектуальной собственности и т.п. На рис. 5.3 показана классификация нефункциональных требований.

Нефункциональные требования:

1. Требования к продукту

   1. Требования к эксплуатации

   2. Требования к эффективности

      1. Требования к производительности

      2. Требования к памяти

   3. Требования к надежности

   4. Требования к переносимости

2. Организационные требования

   1. Выходные требования

   2. Требования на реализацию

   3. Требования на стандарты

3. Внешние требования

   1. Требования на взаимодействие

   2. Этические требования

   3. Юридические требования

      1. Требования о сохранении конфиденциальности

      2. Требования по технике безопасности

Нефункциональных требований к интернет-системе бронирования авиабилетов. (хз как((

23. Концептуальные модели: пользовательского интерфейса и предметной области - их назначение и особенности представления. Примеры этих моделей для интернет-системы бронирования авиабилетов. (162, 229)

Подобный анализ объектов и действий помогает управлять реализацией системы, поскольку он указывает наиболее удобный вид иерархии объектов, а также методы работы, которые предусматривает каждый вид. Анализ объектов и действий над ними, также облегчает структуру команд приложения, так как позволяет проектировщику увидеть, какие действия применимы к разным объектам, а какие могут быть спроектированы как обобщенные. В свою очередь, это делает структуру команд более легкой для изучения пользователем, так как вместо того, чтобы осваивать большое количество объектно-ориентированных команд, достаточно изучить несколько обобщенных, применяемых к разным объектам.

К примеру, если бы наше приложение было программой, помогающей клиенту управлять банковским счетом, концептуальная модель пользовательского интерфейса включала бы такие объекты, как проверка, счет, сумма денег и такие действия, как разместить, отозвать, аннулировать, запросить баланс. Концептуальная модель пользовательского интерфейса должна исключать все объекты, не входящие в данную область задач (например, буферы, диалоговые окна, база данных и т.п.), а также такие действия, как: нажатие клавиш, резервное копирование, очистка буфера обмена и т. д. Такое ограничение по количеству выделяемых концептов и действий является естественным для объектного подхода, так как каждый дополнительный концепт, добавленный в область задач, может создать проблемы с его освоением и появлением дополнительных взаимодействий.

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

Разработка концептуальной модели пользовательского интерфейса, как первая стадия проектирования интерфейса, имеет ряд преимуществ. Во - первых, разделение области задачи, или другими словами, организация требований по сущностям концептуальной модели предметной области, с наделением этих сущностей обязанностями, позволяет определить действия, одинаковые для нескольких объектов. Впоследствии это дает возможность использовать один и тот же пользовательский интерфейс для работы с разными объектами. Это, в свою очередь, делает пользовательский интерфейс более простым и последовательным, а значит, и более удобным в изучении и использовании. Во – вторых, такие явления как существование обобщенных действий, типовая структурная иерархия и иерархия включения объектов, в значительной степени облегчают проектирование пользовательского интерфейса.

Таким образом, разработка концептуальной модели пользовательского интерфейса представляет собой методику первоначального представления объектной модели (по крайней мере, для объектов, необходимых пользователю). Далее применяются: методика выделения классов анализа и методика анализа пригодности (диаграммы устойчивости).

Рис.6.31. Концептуальная модель предметной области

для книжного Internet -магазина

24. Варианты использования как методика формирования требований, основанная на сценариях. Опишите основной и альтернативные потоки событий сценария - "Покупка бензина на автозаправочной станции" с помощью одноименного варианта использования.

Варианты использования (use-case) - это методика формирования требований, основанная на сценариях. Они стали основной нотацией в языке объектного моделирования UML при описании объектных моделей систем. Более того, варианты использования применяются для моделирования предметной области, в анализе пригодности (процесс ICONIX), для выявления и моделирования классов, тестов и т.д.

В самой простой форме в варианте использования определены действующие лица - акторы, то есть пользователи, вовлеченные во взаимодействие, и имена типов взаимодействия. Множество вариантов использования охватывает все возможные взаимодействия, которые будут отражены в системных требованиях.

Иногда неясно, является ли вариант использования сценарием или совокупностью сценариев, где каждый сценарий является «нитью», проходящей через вариант использования. В последнем случае возможны сценарии для нормального взаимодействия плюс сценарии для каждого возможного исключительного случая.

В языке UML предусмотрено совместное использование диаграмм последовательностей и вариантов использования, что существенно расширяет информационные возможности графического представления вариантов использования.

Язык моделирования UML фактически является стандартом для объектно-ориентированного представления вариантов использования, применяемых при формировании требований.

Основной и альтернативный потоки событий

Конкретные детали вариантов использования отражены в основном (правильном) и альтернативных (дополнительных) потоках событий.

Поток событий – это поэтапное описание того, что происходит во время выполнения варианта использования.

Поток событий уделяет внимание тому, что делает система, причем описывает это с точки зрения пользователя. Основной и альтернативный потоки событий содержат:

• Процедуру начала варианта использования.

• Различные этапы исполнения варианта.

• Нормальный (основной) поток событий в варианте.

• Все отклонения (альтернативы) от основного потока событий.

• Все потоки ошибок.

• Процедуру завершения варианта использования.

Нормальный поток описывает наилучший сценарий, либо наиболее используемый путь исполнения варианта использования.

Альтернативный поток событий (расширение extended) специфицирует отклонения от основного потока, которые не рассматриваются как ошибочные.

Поток ошибок – девиация от основного или альтернативного потока, которая рассматривается как условие формирования ошибки. Поток ошибок описывает проблемы, которые могут возникнуть в самой программной системе, в процессе исполнения варианта использования.

Рассмотрим пример с вариантом использования «Покупка авиабилета» и обсудим потоки по каждому из сценариев [2].

Основной поток событий

Этапы основного потока событий:

1. Вариант использования начинается с выбора клиентом режима показа информации о рейсах.

2. Система показывает сведения об аэропортах отправления и назначения, а также датах вылета и возвращения (для билета в обратную сторону).

3. Клиент вводит название городов отправления и назначения, дату вылета и возвращения.

4. Система показывает список доступных рейсов, включая стоимость билетов. А1.

5. Пользователь выбирает рейс, на который он хотел бы зарезервировать билет.

6. Система показывает все доступные варианты стоимости билетов на этот рейс.

7. Пользователь выбирает категорию билета для резервирования. А2.

8. Система показывает цену, которую должен заплатить пользователь.

9. Пользователь подтверждает цену.

10. Система запрашивает тип кредитной карточки, ее номер, имя владельца и дату завершения срока действия.

11. Пользователь вводит тип кредитной карточки, ее номер, имя владельца и дату завершения срока действия.

12 Система подтверждает продажу по кредитной карточке. А6. А7.Е1.

13. Система резервирует место для пользователя на выбранный рейс.

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

15. Пользователь подтверждает получение кода.

16. Вариант использования завершается.

Альтернативные потоки событий

А1: Нет нужного рейса. В этом случае:

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

2. Пользователь подтверждает просмотр сообщения.

3. Поток возвращается на этап 2 основного потока событий.

А2: Пользователь выбрал бесплатный билет, предоставляемый членам клуба постоянных клиентов. В этом случае:

1. Система запрашивает идентификационный номер в клубе постоянных клиентов.

2. Пользователь вводит этот номер.

3. Система подтверждает правильность введенного номера. А3.

4. Система подтверждает, что расстояние, которое налетал пользователь на самолетах авиакомпании, позволяет предоставить бесплатный билет. .А4. А5.

5. Цена билета устанавливается в $0.

6. Поток возвращается на этап 8 основного потока.

А3: Неправильный идентификационный номер. В этом случае:

1. Система выводит сообщение о некорректном идентификационном номере.

2. Пользователь повторяет ввод номера или отказывается от запроса на бесплатный билет.

3. Если пользователь повторяет ввод номера, то поток возвращается на этап 1 альтернативного потока А2.

4. Если пользователь отказывается от запроса на бесплатный билет, то поток возвращается на этап 6 основного потока.

А4: Недостаточное расстояние для предоставления бесплатного билета. В этом случае:

1. Система выводит сообщение о том, что расстояние недостаточно для предоставления бесплатного билета. В сообщении указано это расстояние и расстояние, необходимое для предоставления бесплатного билета.

2. Поток возвращается на этап 6 основного потока событий.

А5: Нет бесплатных билетов. В этом случае:

1. Система выводит сообщение о том, что бесплатные билеты на выбранный рейс не предоставляются.

2. Поток возвращается на этап 6 основного потока событий.

А6: Счет пользователя не обнаружен. В этом случае:

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

2. Поток возвращается на этап 10 основного потока событий.

А7: Недостаточно денег на счете. В этом случае:

1. Система выводит сообщение о том, что остаток на кредитной карточке не позволяет завершить транзакцию.

2. Поток возвращается на этап 10 основного потока событий.

25. Всевозможные отношения между вариантами использования на диаграмме вариантов использования. Продемонстрируйте все эти отношения на диаграмме варианта использования " Покупка бензина на автозаправочной станции".

Диаграмма Вариантов Использования показывает некоторые варианты использования в системе некоторых действующих лиц, и отношения между ними. Диаграмма представляет высокоуровневое описание системы (архитектуру системы), причём действующим лицом становится все и всё, что взаимодействует с разрабатываемой системой. Пример диаграммы Вариантов использования показан на рис 5.14. На диаграмме видны системные действующие лица, системные варианты использования и отношения между ними. Данная система предназначена для интерактивных и телефонных продаж авиабилетов, поэтому Клиент и Представитель службы сервиса могут инициировать одинаковые варианты использования. На диаграмме присутствуют включающие и одно расширяющее отношения. Вся функциональность системы может быть представлена набором из восьми вариантов использования: Приобретение билетов, Изменение заказа, Проверка кредита, Отказ от заказа, Просмотр маршрута пользователя, Бронирование номера в отеле, Заказ на аренду автомобиля и Установка расписания авиарейсов.

Одним из основных преимуществ диаграммы Вариантов использования является показ коммуникаций. Клиент получит из диаграммы достаточное количество информации, из вариантов использования он узнает о функциях системы, а по действующим лицам – определит, кто взаимодействует с системой. Полный набор вариантов использования и действующих лиц покажет границы проекта, что позволит выявить все упущенные в нём функции.

Рис.5.14. Пример диаграммы вариантов использования

Варианты использования можно группировать в пакеты и, таким образом, получить высокоуровневую диаграмму Вариантов использования. Можно сформировать одну диаграмму для всех вариантов использования и действующих лиц. Количество и имена диаграмм произвольны.

Диаграммы Вариантов использования служат для документирования: действующих лиц (всего, что находится вне системы), вариантов использования (всего, что находится в пределах системы) и отношений между этими компонентами.