Спецификация требований

1. Первичный список требований.

1.1. Функциональные требования.

От программной системы требуется предоставление следующих локальных статистик:

1. Количество запросов к электронному каталогу
• За последний месяц по дням
• Учет по месяцам в течение текущего года
• Учет по годам
2. Список запросов по каждому поисковому индексу, в которых результат поиска был нулевой.
3. Список часто встречающихся запросов.
4. Анализ выполнения запросов за определённый период. В отчёте должны быть отражены следующие статистики:
• Количество запросов
• Количество уточняющих запросов
• Количество сложных запросов
• Количество результативных ответов
• Количество ответов с нулевым результатом

Использовать следующие поисковые индексы:

• Автор
• Автор рец. произв.
• Вид документа
• Географическая рубрика
• Дата ввода
• Дата издания
• Заглавие

Статистические данные пунктов 1 - 3, необходимо предоставлять через веб-интерфейс.
Статистики в последнем пункте должны быть доступны с АРМ Администратора.

1.2. Системные ограничения.

• Предоставление результатов запроса за разумное время.
• Использование хранимых процедур СУБД Oracle для обработки запроса.
• Минимизация использования ресурсов сервера.

2. Модель требований.

2.1. Модель предметной области.

Определены два типа пользователей. Первые получают статистику через веб интерфейс, а вторые кроме доступа через веб интерфейс имеют доступ к дополнительным статистикам через АРМ Администратора. Отчёты, доступные через АРМ Администратора, представлены в виде файла электронных таблиц Excel.

Пользователи могут выбирать нужные им отчёты. Некоторые отчёты требуют введения определённых данных. После ввода необходимых данных формируется запрос, который отправляется на сервер. Обработав запрос, СУБД Oracle выдаёт результат, отформатированный средствами языка разметки гипертекста.

2.2. Функциональная модель.

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

2.3. Сценарии использования системы.

2.3.1. Пользователь.

Пользователь вводит определенные данные в поля запроса на форме интерфейсе. После ввода необходимых данных формируется запрос, который обращается к серверу. Обработав запрос, сервер выдаёт результат, отформатированный средствами SQL Plus и представленный с помощью языка разметки гипертекста.

2.3.2. Администратор.

Администратор может воспользоваться web-интерфейсом, тогда его действия идентичны действиям пользователя. Но кроме этого, администратор может получить дополнительную статистику через АРМ. Администратор формирует запрос посредством АРМ, после чего запрос отправляется на сервер. Обработав запрос, сервер выдает ответ представленный в виде файла электронных таблиц Excel .

3. Высокоуровневая архитектура системы.

3.1. Модель архитектуры.

Используя веб-интерфейс, пользователь делает запрос по одной из статистик. Запрос передаётся консоли SQL*Plus, которая обращается к базе данных посредством процедур на стороне сервера и создаёт отчёт по выбранной статистике. Этот отчёт в дальнейшем отображается в веб-интерфейсе. Модель схематично изображена на следующем рисунке:

3.2. Модели архитектуры сервера.

3.2.1. Прямая модель архитектуры сервера.

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

3.2.2. Модель архитектуры сервера с таймером.

Второй вид архитектуры в отличие от первого использует статистические кэш таблицы. Клиент обращается с запросом к кэш таблицам. Эти таблицы создаются процедурами сервера, используя данные из лог таблицы. Для вызова процедур сервера используется скрипт, который можно настроить на определённое время срабатывания. Это используется для сокращения времени обработки лог таблицы, т.е. кэш таблицы это обработанные части лог таблицы. Каждый раз при вызове хранимой процедуры СУБД вся кэш таблица заполняется заново. За счёт того, что кэш таблицы это разобранное и упрощённое воплощение содержимого лог таблицы скорость выполнения запроса должна увеличится на время, которое уходит на разбор полей лог таблицы.

3.2.3. Модель архитектуры сервера с триггерами.

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

3.2. Детальные требования к основным подсистемам.

Веб интерфейс

Должен генерироваться программой SQL*Plus в HTML формате. Запуск программы SQL*Plus должен выполняться Shell скриптом.

Модуль механизмов создания отчётов

Хранимые процедуры, функции и триггеры должны быть написаны на языке PL/SQL, храниться на сервере, использовать оптимальные алгоритмы разбора.

Таблицы

Количество кэш таблиц должно быть минимальным. Лог таблица должна быть разобрана в реляционный вид.

4. Критерии аттестации системы.

4.1. Тесты функциональности

1. При выборе отчёта о количестве запросов к электронному каталогу пользователь должен иметь возможность выбрать период, за который будет составлена статистика.
2. При выборе отчёта о нулевых запросах пользователь должен получить список запросов, на которые не было получена данных из БД.
3. Если пользователь запросил статистику о часто встречающихся запросах, то он получит список запросов, отсортированный по убыванию частоты появления запроса (50 первых мест).
4. Если пользователь с АРМ запросит данные о статистики он также может выбрать период, за который будет составлена статистика.

---

Связанные документы:	Обзор проекта План проекта График работы (диаграмма Гантта) Спецификация требований Проектирование Тестирование Документ реализации Документ тестирования Взаимодействие с заказчиком Связь с разработчиками Отчёты Прогресс разработки Глоссарий Руководство пользователя