Eskimo project, техническое задание

1.Общие сведения

1.1 Полное наименование системы и ее условное обозначение

Полное название - "Сервер для обеспечения работы сетевых сервисов".
Условное обозначение - "Eskimo project".

1.2 Наименование компаний разработчика и заказчика (пользователя) системы и их реквизиты

Наименование компании заказчика - "Лаборатория НГУ - SWsoft".
Наименование компании разработчика - "Лаборатория НГУ - SWsoft".

1.3 Плановые сроки начала и окончания работы по созданию системы

Начало работ: 11 июля 2005 года
Окончание работ: 15 августа 2005 года

1.4 Порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей).

Система будет оформлена, как независимый отдельно устанавливаемый продукт. Дополнительно будет представлен набор дополнительных сервисов, устанавливаемых отдельно и клиентов для каждого из этих сервисов. Кроме исходных текстов программ , заказчику будет предоставлена техническая документация (Javadoc) на все компоненты сервера и отдельно устанавливаемые сервисы, написанные в "Лаборатория НГУ-SWsoft"

2. Назначение и цели создания системы

Плагин - отдельный модуль определенной структуры, написанный на языке Java (java classes), устанавливаемый отдельно от компонент сервера, который предоставляет своим клиентам некоторый сервис (некоторую функциональность).
Сервис - экземпляр плагина.
Обработчик - специальный класс, экземпляры которого занимаются обслуживанием клиентских входящих соединений.
Группа сервисов - набор экземпляров сервисов, который характеризуется портом, названием и IP-адресом сервера.

2.1 Назначение системы и основные термины данного технического задания

Разрабатываемая система относится к серверным системам. Назначением системы является обеспечение работы сетевых сервисов, созданных сторонними разработчиками. Упрощение написание сетевых приложений.

2.2 Цели создания системы

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

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

3. Характеристики объекта информатизации

3.1 Краткие сведения об объекте информатизации

Объектом информатизации является деятельность по обслуживанию клиентов по сети.

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

4.1 Требования к системе в целом

Исходя из целей создания и назначения системы, можно определить основные требования, предъявляемые к системе в целом. К таким основным относятся следующие требования:
1) Система создается как независимый компонент
2) Система должна предоставить сервису интерфейс взаимодействия с клиентом на основе потоков. (именно так будет пониматься в дальнейшем "упрощенный интерфейс")
3) Система должна иметь собственную (независимую от других систем) базу данных. Система должна сохранять информацию в конфигурационном файле о своих настройках и настройках сервисов, получаемую при установке плагина. Система должна сохранять данные своего внутреннего состояния и состояния сервисов в собственной БД, предоставляя соответствующий API сервисам для доступа к ней. Система должна проверять корректность параметров собственной конфигурации и конфигурации сервисов на основании имеющихся описаний, распространяемых с плагинами.
4) Система должна предусматривать возможное расширение типов плагинов (например, HTTP-сервисы)
5) Сервисы должны объединяться в группы, характеризующиеся портом и IP-адресом, сервера, обслуживающего клиентов.
6) Система должна предусматривать возможность работы каждой группы сервисов на отдельном TCP-порту и на некотором определенном IP-адресе.
7) Система должна позволять запуск и остановку групп сервисов и сервисов по отдельности.
8) Система должна отображать доступные для изменения настройки как собственные, так и своих сервисов. Редактирование их также необходимо.

4.1.1 Требования к структуре и функционированию системы

4.1.1.1 Перечень подсистем и их назначение

Предполагается, что система будет состоять из двух основных частей:
1) Сервер
2) Набор плагинов

Сервер будет предоставлять возможность развёртывания сетевых сервисов и контроля параметров этих сервисов.

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

4.1.1.2 Требования к характеристикам взаимосвязей создаваемой системы со смежными системами

Под смежными системами в данном случае подразумеваются сетевые сервисы (плагины). Плагин представляет собой набор классов на языке Java2. Основные его части:
1. Класс-загрузчик. Экземпляр которого проверяет совместимость с клиентом, предоставляет информацию серверу о сервисе.
2. Класс-обработчик. Является производным от Runnable. Экземпляр этого класса создается для каждого входящего клиентского соединения, Этот класс непосредственно занимается обслуживанием клиента.

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

Плагин должен предоставлять информацию серверу о версии своей реализации, номере сборки, и своем названии, например "Сервис регистрации".

Сервис должен подтверждать совместимость с клиентом, путем сравнения версий.

Сервис предоставляет серверу специальный обработчик, который и обслуживает клиентов сервера.

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

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

Сервер предоставляет сервису интерфейс доступа к конфигурации и сохранению своего (сервиса) внутреннего состояния. Оба этих интерфейса схожи с интерфейсом реестра Windows. (древовидная структура, возможность чтения конфигурации и чтения / записи внутреннего состояния.)

4.1.1.3 Требования к режимам функционирования системы

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

4.1.1.4 Перспективы развития, модернизации системы

К основным направлениям развития системы можно отнести, такие:
1) Написание дополнительных плагинов для различных областей применения
2) Написание Web-интерфейса управления сервером, написание модуля, управляющего сервером из командной строки.
3) Расширение набора типов плагинов: HTTP-сервисы, Raw TCP - сервисы. HTTP - сервисы работают на 80-TCP порту и представляют некоторый аналог .Net Web- Services, а Raw TCP - сервисы могут работать на некотором порту в единственном экземпляре и не поддерживают передачу метаинформации на этапе установки соединения.
4) Написание более совершенной документации (руководства администратора, руководства разработчика, написание соответствующих примеров реализации).

4.1.2 Требования к численности и квалификации персонала

4.1.2.1 Требования к численности персонала (пользователей) ИС

Функционирование системы не зависит от численности пользователей.

4.1.2.2 Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков

Пользователи
Система должна нормально функционировать вне зависимости от квалификации пользователей.

Администраторы
Требования, предъявляемые к администраторам системы:
1) Знание той ОС, на которой будет устанавливаться сервис.
2) Базовые знания о платформе Java2 Standard Edition\ Java2 Enterprise Edition

4.1.3 Требования безопасности

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

Файлы конфигурации доступны для изменения только администратору системы.

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

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

4.1.5 Требования к эргономике и технической эстетике

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

4.2 Требования к функциям (задачам), выполняемым системой

4.2.1 Функции подсистем

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

Плагины:
Функции плагинов целиком зависят от цели их создания.

5. Состав и содержание работ по созданию (развитию) системы

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

N	Содержание работ	Сроки выполнения	Отчетность
1	Создание архитектуры системы	До 11 июля	Создание каркаса основных модулей системы, без реализации.
2	Доработка существующего прототипа сервера, для того, чтобы он соответствовал требованиям ТЗ	К 18-20 июля	Предоставить бета-версию сервера
3	Разработка протоколов и написание плагинов	До 15 августа	Выпуск бета-версий плагинов
4	Подготовка документации и презентации	15-17 августа	Демонстрация бета-версии системы целиком

6. Порядок контроля и приемки системы

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

7. Требования к составу и содержанию работ по подготовке объекта разработки к вводу системы в действие

1. Создание программного обеспечения подсистемы;
2. Тестирование на местах и исправление выявленных недочетов.

8. Требования к документированию

Вместе с системой планируется поставлять следующую документацию:
1) JavaDoc.