2.2.4. Отображение обновленного состояния базы данных
Клиентская программа должна отображать обновленное состояние базы (при изменении количества доступных билетов вследствие бронирования, произведенного другими клиентами, или при модификации базы).
2.3 Характеристика пользователей
Предполагаются, что разрабатываемой системой будут пользоваться две категории пользователей.
- администратор – обладает опытом работы с системами, использующими базы данных;
- оператор – специально обучен для работы с апплетом Monitor.
Ниже перечислены ограничения на технологии, используемые при разработке системы.
2.4.1. Использование языка Java при создании клиент-приложения
Данное ограничение вызвано требованием работоспособности клиента в любом браузере, поддерживающем апплеты, в любой операционной системе.
2.4.2. Параллельная обработка запросов, поступающих от клиентов, в серверном приложении
Данное ограничение вызвано необходимостью быстрой обработки запросов сервером и низкого времени отклика.
2.5 Предположения и зависимости
Аналогичные по назначению системы используются достатночно большим числом авиакомпаний. Многие авиакомпании используют аналогичные программные продукты. Реальные системы разрабатываются индивидуально, с учетом всех требований конкретного заказчика. Falcon Manager, напротив, представляет собой экспериментальную систему, не предназначенную для повседневного использования.
Данный документ полагается на то, что разрабатываемая система является образовательным проектом с целью обучить вовлеченных людей ряду технологий. Предполагается, что система не будет использоваться на практике.
Проектируемая система содержит основную часть внешней функциональности реальных систем покупки авиабилетов. В то же время она имеет множество ограничений:
В частности по этим причинам система имеет низкую стоимость разработки.
2.6 Приоритеты требований
Некоторые требования имеют более высокий приоритет и должны быть выполнены первыми.
В разрабатываемом продукте обязательно должна присутствовать клиент-серверная система, позволяющая оператору системы покупать билеты.
Менее важным является наличие системы модификации базы данных для администратора системы. Вместо этого на первом этапе могут быть написаны вспомогательные утилиты, выполняющие заполнение базы данных для тестирования.
3. Специфические требования
В настоящей главе изложены подробные требования к функциональности продукта.
3.1 Сущности, с которыми работает система
Система работает со следующими сущностями:
· аэропорт (характеризуется названием и кодом);
· самолет (характеризуется названием);
· место в самолете (характеризуется кодом и самолетом);
· рейс (характеризуется аэропортами отправления и прибытия, временами отправления и прибытия и самолетом, на котором осуществляется рейс);
· билет (характеризуется рейсом, местом и данными покупателя).
Эти сущности и связи между ними показаны на рис. 1.
Рис. 1. Основные сущности системы
В настоящем разделе описаны функции различных компонентов системы.
Должна быть возможность предоставлять пользователю список всех рейсов, летящих из пункта A в пункт B в определенный день, а также информацию о количестве свободных мест на каждом из этих рейсов.
Должна быть возможность купить билет на указанный рейс. При этом, желательно, чтобы пользователь имел возможность выбрать устраивающее его место из списка непроданных мест.
Не должна возникать ситуация, когда два или более пользователя купили билет на одно и то же место некоторого рейса. В случае попытки пользователя купить уже проданный билет, должно выводиться соответствующее сообщение.
3.2.2 Функции клиента Editor
Должна быть возможность добавлять в систему информацию о новом аэропорте. В случае совпадения кода создаваемого аэропорта с кодом уже существующего аэропорта должно выводиться соответствуещее сообщение.
Должна быть возможность добавления в систему информации о новом самолете. На самолеты не накладываются никакие ограничения.
Должна быть возможность добавления информации о новом месте в самолете. При этом, код места не должен совпадать с кодом одного из уже существующих мест данного самолета. В случае совпадения кодов должно выводиться соответствующее сообщение.
Должна быть возможность добавлять в систему информацию о новом рейсе: аэропорт отправления, аэропорт прибытия, дату/время отправления, дату/время прибытия, самолет. Должна быть возможность менять дату/время отправления и прибытия рейса. При этом, дата/время прибытия должна быть позже даты/времени отправления.
При вводе некорретной информации (например, некорректный код нового аэропорта или некорректная дата) должно выводиться сообщение об ошибке.
Кроме указанных выше функций клиент Editor должен поддерживать ту же функциональность, что клиент Monitor.
Сервер должен предоставлять клиентам достаточно информации, чтобы последние имели возможность функционировать в соответствии с требованиями, указанными в пунктах 3.2.1 и 3.2.2.
Сервер должен оповещать клиентов обо всех изменениях в базе данных, связанных с информацией, отображаемой на клиенте. Таким образом, должна достигаться актуальность всей отображаемой клиентами информации.
3.3 Требования по производительности
Учитывая современные запросы авиакомпаний, сервер должен уметь быстро отвечать на 10-20 запросов в секунду, и поддерживать 50-100 активных подключений.
После того, как написана программа, максимальное количество клиентов, которые одновременно могут посылать запрос на сервер (т.е. активных клиентов) зависит от аппаратного обеспечения сервера, на котором запущена база данных. Здесь уместно говорить скорее не о максимальном количестве клиентов, а о времени отклика сервера при данном количестве клиентов (впрочем, после некоторого порогового значения количества клиентов очередь на сервере начнет неограниченно расти, и сервер «упадет»). Эти величины можно получить или опытным путем (используя специальную программу, моделирующую подключение и деятельность большого количества клиентов), или теоретическим – также используя программу для моделирования сети массового обслуживания.