Реферат: Software Requirements Specifications Document

Требования к проекту « Falcon Manager » (система покупки авиабилетов)

Версия: ( 1 ) Дата: (0 1 /0 5 /2008)

Содержание

1. Введение 3

1.1 Назначение 3

1.2 Масштаб проекта 3

1.3 Список определений, сокращений и аббревиатур 4

1.4 Ссылки 4

1.5 Структура документа 4

2. Общее описание 4

2.1 Структура системы 4

2.1.1 Системные интерфейсы 5

2.1.2 Интерфейс 5

2.1.3 Аппаратные интерфейсы 5

2.1.4 Программные интерфейсы 5

2.1.5 Интерфейсы коммуникации 5

2.1.6 Ограничения по памяти 6

2.1.7 Операции по восстановлению данных 6

2.1.8 Условия работы системы 6

2.2 Функции продукта 6

2.2.1. Хранение информации об авиарейсах и проданных на них билетах 6

2.2.2. Обновление и коррекция информации в базе данных 6

2.2.3. Покупка билетов 7

2.2.4. Отображение обновленного состояния базы данных 7

2.3 Характеристика пользователей 7

2.4 Ограничения 7

2.4.1. Использование языка Java при создании клиент-приложения 7

2.4.2. Параллельная обработка запросов, поступающих от клиентов, в серверном приложении 7

2.5 Предположения и зависимости 7

2.6 Приоритеты требований 8

3. Специфические требования 8

3.1 Сущности, с которыми работает система 8

3.2 Функции 9

3.2.1 Функции клиента Monitor 9

3.2.2 Функции клиента Editor 10

3.2.3 Функции сервера 10

3.3 Требования по производительности 10

1. Введение

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

1.1 Назначение

Настоящий документ описывает требования к системе бронирования авиабилетов Falcon Manager , разрабатываемой (вымышленной) фирмой Paraschenko & Tsarev в рамках курса «Архитектура и разработка распределенного программного обеспечения» по заказу (вымышленной) авиакомпании Falcon Airlines SPb . Настоящий документ предназначен для сотрудников Falcon Airlines SPb и Paraschenko & Tsarev , участвующих в разработке указанной системы.

1.2 Масштаб проекта

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

Задачами системы являются:

1. Поддержка возможностей обновления и коррекции информации в БД (внесение новых рейсов, изменение цен, и.т.п.).
2. Осуществление постоянного мониторинга состояния базы клиентами. После загрузки клиент должен отображать состояние базы в своем окне и обновлять его по мере необходимости (при изменении количества свободных билетов, вследствие бронирования, произведенного другими клиентами или при иных модификациях данных).
3. Поддержка возможности продажи билетов специально обученным оператором.

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

Система Falcon Manager будет применяться для упрощения процесса бронирования и покупки билетов авиакомпании Falcon Airlines SPb . Переход от ручного вненесения изменений в базу данных к применению разрабатываемой системы позволит ускорить процесс покупки билетов в несколько раз, а также на порядок снизить количество ошибок, допускаемых кассирами.

1.3 Список определений, сокращений и аббревиатур

CORBA – Common Object Request Broker Architecture , общая архитектура брокера объектных запросов

OMG – Object Management Group

SQL – Structured Query Language

СУБД – система управления базой данных

1.4 Ссылки

1. OMG ’s CORBA web site. http://www.corba.org/

2. Система бронирования авиабилетов Expedia www.expedia.com

3. СУБД Oracle http://www.oracle.com

4. Sun Java http://java.sun.com/

1.5 Структура документа

Глава 2 содержит описание системы Falcon Manager общими словами без деталей. Она предназначена для ознакомления с проектируемой системой.

В главе 3 содержится детализированное описание функциональности Falcon Manager .

2. Общее описание

Настоящий раздел содержит общее описание разрабатываемой системы.

2.1 Структура системы

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

Ближайшими аналогами разрабатываемой системы являются системы поиска и бронирования билетов, используемые авиакомпаниями Air France (www.airfrance.com), Lufthansa (www.lufthansa.com), British Airways (www.britishairways.com) и другими, а также online системы бронирования билетов Expedia (www.expedia.com) и Yahoo ! Travel (travel . yahoo . com ).

Основным отличием от указанных систем является бо льшая простота использования (которая достигается за счет уменьшения функциональности, не включающей поиск маршрутов перелетов). Таким образом, разрабатываемая система строится по принципу «ничего лишнего», при этом реализуется только базовая (но при этом наиболее востребованная пользователем) функциональность системы бронирования и покупки авиабилетов. За счет этого достигается гораздо меньшая стоимость разработки.

2.1.1 Системные интерфейсы

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

2.1.2 Интерфейс

Серверная часть системы не имеет графического интерфейса, работает в консольном режиме.

Клиентская часть системы должна иметь графический интерфейс. Необходимо разработать два вида клиентов:

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

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

2.1.3 Аппаратные интерфейсы

У системы нет никаких требований к аппаратным интерфейсам, так как она не взаимодействует напрямую ни с каким аппартным обеспечением.

2.1.4 Программные интерфейсы

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

2.1.5.1. Oracle 10g

Разрабатываемая система должна использовать Oracle 10g в качестве сервера баз данных. Для развертывания системы вместе с ней должны поставляться SQL -скрипты, создающие необходимые таблицы базы данных. С базой данных должна взаимодействовать только серверная часть системы.

2.1.5 Интерфейсы коммуникации

Взаимодействие между клиентом Monitor и сервером должно осуществляться с использованием технологии CORBA (http://www.corba.org/).

2.1.5.1. CORBA

Клиент должен быть одновременно CORBA -клиентом, осуществляющим вызовы методов сервера (другого приложения, служащего прослойкой между клиентом и БД) и CORBA -сервером, чьи методы будут вызываться сервером в случае изменений в БД.

2.1.6 Ограничения по памяти

Часть системы, требующая наибольшее количество памяти – это база данных (ее разрабатывать не надо, так как используется СУБД Oracle10g). Для серверной части системы ограничения по памяти могут возникнуть, если она запускается на одном компьютере с СУБД. Такой вариант использования системы вполне вероятен, поэтому память, задействованная сервером не должна превышать 128-256 Мб.

Клиентские приложения должны использовать не более 64 мегабайт оперативной памяти. Это ограничение вызвано особенностями апплетов, написанных на языке программирования Java .

2.1.7 Операции по восстановлению данных

Все данные, генерируемые и используемые системой, хранятся в базе данных. Для того, чтобы сохранить резервную копию данных, можно воспользоваться средствами Oracle (http://www.oracle.com/technology/obe/2day_dba/backup/backup.htm#t2).

2.1.8 Условия работы системы

Перед установкой системы Falcon Manager необходимы следующие приготовления – на компьютер с сервером должна быть установлена СУБД Oracle 10g ; сервер должен быть доступен в глобальной сети и на нем должен работать Web-сервис, необходимый для загрузки с него апплета (также должен быть открыт 80 порт).

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

2.2 Функции продукта

Приведем список основных функций разрабатываемой системы.

2.2.1. Хранение информации об авиарейсах и проданных на них билетах

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

2.2.2. Обновление и коррекция информации в базе данных

Администратор системы должен иметь возможность с помощью специального приложения (апплет Monitor ) корректировать имеющуюся и добавлять новую информацию в базу данных:

- добавлять новый рейс;

- изменять стоимость билета на существующий рейс;

- аннулировать купленные ранее билеты.

2.2.3. Покупка билетов

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

2.2.4. Отображение обновленного состояния базы данных

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

2.3 Характеристика пользователей

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

- администратор – обладает опытом работы с системами, использующими базы данных;

- оператор – специально обучен для работы с апплетом Monitor .

2.4 Ограничения

Ниже перечислены ограничения на технологии, используемые при разработке системы.

2.4.1. Использование языка Java при создании клиент-приложения

Данное ограничение вызвано требованием работоспособности клиента в любом браузере, поддерживающем апплеты, в любой операционной системе.

2.4.2. Параллельная обработка запросов, поступающих от клиентов, в серверном приложении

Данное ограничение вызвано необходимостью быстрой обработки запросов сервером и низкого времени отклика.

2.5 Предположения и зависимости

Аналогичные по назначению системы используются достатночно большим числом авиакомпаний. Многие авиакомпании используют аналогичные программные продукты. Реальные системы разрабатываются индивидуально, с учетом всех требований конкретного заказчика. Falcon Manager , напротив, представляет собой экспериментальную систему, не предназначенную для повседневного использования.

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

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

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

В частности по этим причинам система имеет низкую стоимость разработки.

2.6 Приоритеты требований

Некоторые требования имеют более высокий приоритет и должны быть выполнены первыми.

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

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

3. Специфические требования

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

3.1 Сущности, с которыми работает система

Система работает со следующими сущностями:

· аэропорт (характеризуется названием и кодом);

· самолет (характеризуется названием);

· место в самолете (характеризуется кодом и самолетом);

· рейс (характеризуется аэропортами отправления и прибытия, временами отправления и прибытия и самолетом, на котором осуществляется рейс);

· билет (характеризуется рейсом, местом и данными покупателя).

Эти сущности и связи между ними показаны на рис. 1.

Рис. 1 . Основные сущности системы

3.2 Функции

В настоящем разделе описаны функции различных компонентов системы.

3.2.1 Функции клиента Monitor

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

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

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

3.2.2 Функции клиента Editor

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

Должна быть возможность добавления в систему информации о новом самолете. На самолеты не накладываются никакие ограничения.

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

Должна быть возможность добавлять в систему информацию о новом рейсе: аэропорт отправления, аэропорт прибытия, дату/время отправления, дату/время прибытия, самолет. Должна быть возможность менять дату/время отправления и прибытия рейса. При этом, дата/время прибытия должна быть позже даты/времени отправления.

При вводе некорретной информации (например, некорректный код нового аэропорта или некорректная дата) должно выводиться сообщение об ошибке.

Кроме указанных выше функций клиент Editor должен поддерживать ту же функциональность, что клиент Monitor .

3.2.3 Функции сервера

Сервер должен предоставлять клиентам достаточно информации, чтобы последние имели возможность функционировать в соответствии с требованиями, указанными в пунктах 3.2.1 и 3.2.2.

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

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

Учитывая современные запросы авиакомпаний, сервер должен уметь быстро отвечать на 10-20 запросов в секунду, и поддерживать 50-100 активных подключений.

После того, как написана программа, максимальное количество клиентов, которые одновременно могут посылать запрос на сервер (т.е. активных клиентов) зависит от аппаратного обеспечения сервера, на котором запущена база данных. Здесь уместно говорить скорее не о максимальном количестве клиентов, а о времени отклика сервера при данном количестве клиентов (впрочем, после некоторого порогового значения количества клиентов очередь на сервере начнет неограниченно расти, и сервер «упадет»). Эти величины можно получить или опытным путем (используя специальную программу, моделирующую подключение и деятельность большого количества клиентов), или теоретическим – также используя программу для моделирования сети массового обслуживания.