Системные требования к проекту "Файловый сервер"¶
- Table of contents
- Системные требования к проекту "Файловый сервер"
Введение
h3. Назначение проекта
Проект "Файловый сервер" представляет собой разработку клиент-серверного приложения, предназначенного для решения нескольких проблем, связанных с обращением к файлам со стороны вещательных приложений. Должны быть решены следующие 3 основные проблемы:
- ликвидация задержек при интенсивной работе с файлами по локальной сети, которые возникают из-за проверок прав доступа, работы антивирусных приложений etc.
- обеспечение безопасности хранения файлов, связанное с тем, что у пользователя есть права на запись в файловом хранилище
- проблема с резервированием файлов и перенаправлением на другой сервер при сбое или потере данных
Ссылки¶
Общее описание
h3. Развитие проекта
Файловый сервер должен работать в составе аппаратного-программно комплекса радиостанции и заменить прямое обращение к файловому хранилищу со стороны вещательных приложений "ДЖИНН" на обращение к файловому серверу.
Существующая схема работы должна быть заменена на новую схему работы.
Основные функции¶
- Связь между клиентской и серверной частью.Проект должен быть выполнен в виде 2-х модулей, один из которых устанавливается на сторону клиента, а другой - на сторону сервера. Должно быть обеспечено установление связи между клиентскими и серверными модулями, передача запросов на работу с файлами со стороны клиента и доставка ответов и уведомлений со стороны сервера.
- Формирование и обработка запросов со стороны клиентаНа сторону клиента устанавливается клиентский модуль, который интегрируется в вещательное приложение, устанавливает связь с серверным модулем, все запросы обращения к файловому хранилищу передаёт по сети серверному модулю и получает в ответ обработанные файловым сервером данные, сообщения и уведомления.
- Обработка запросов со стороны сервераНа сторону сервера устанавливается серверный модуль, выполненный в виде стандартного сервиса Microsoft Windows, котрый принимает все запросы обращения к файловому хранилищу от клиентских модулей, обрабатывает их и посылает в ответ обработанные данные, сообщения об ошибках, а также осуществляет мониторинг изменений в файловом хранилище и отсылает соответствующие уведомления клиентским модулям.
- РезервированиеЛюбой серверный модуль может быть сконфигурирован как резервный для работы в паре с другим серверным модулем. В таком режиме он поддерживает своё файловое хранилище полностью идентичным активному серверному модулю. В случае сбоя или потери данных на активном модуле, он берёт на себя функции активного модуля, а активный модуль переключается в режим резервного.
Операционная среда¶
Серверный модуль должен работать в среде MS Windows Server.
Протокол TCP поддерживается при помощи модуля TCP_MANAGER.
Функциональность MS Windows Service поддерживается при помощи модуля BASE_SERVICE.
Клиентский модуль интегрируется в … (или выполняется в виде … на языке …)
Ограничения разработки¶
Связь между клиентской и серверной частью осуществляется по протоколу TCP/IP. Обмен между клиентом и сервером производится в формате NC_CONTAINER. Нужно предусмотреть дальнейшее развитие протокола обмена, которое могло бы осуществляться в формате XML. Вызовы из клиентского приложения осуществляются … Запросы к серверу должны осуществляться параллельно, причём для одного и того же клиента допускается передача нового запроса до окончания обработки предыдущего.
Документация пользователя¶
<Перечислите здесь, какая пользовательская документация должна поставляться в составе данного проекта (руководства пользователя, обучалки, on-line help). Во избежание лишних вопросов и недоразумений можно также указать, в каком формате они будут поставляться.>
Функции системы
h3. Связь между клиентской и серверной частью
h4. Описание и приоритет
Эта функция обеспечивает установление связи между клиентскими и серверными модулями, передачу запросов на работу с файлами со стороны клиента и доставку ответов и уведомлений со стороны сервера. Она имеет первостепенное значение, поскольку на её основе базируется функционирование всего проекта. Просчёты в проектировании и релизации этой функции может серьёзно затруднить проектирование и реализацию остальных функций и компонентов системы. Поэтому ей должно быть уделено особое внимание.
Последовательность взаимодействия¶
<Перечислите здесь список возможных действий пользователя и реакций системы на эти действия. Можно также включить сюда диаграммы и use case-ы для большей наглядности.>
Функциональные требования¶
RQ1: Связь между клиентской и серверной частью осуществляется по протоколу TCP/IP.
RQ2: Обмен между клиентом и сервером производится в формате NC_CONTAINER.
RQ3: Обмен между клиентом и сервером может производится в формате XML.
Формирование и обработка запросов со стороны клиента
h4. Описание и приоритет
Клиентский модуль обеспечивает установку связи с серверным модулем, формирование запросов обращения к файловому хранилищу, получение ответов и данных, передаваемых файловым сервером в процессе обработки запроса, и уведомления об изменениях в файлах, на которые сделана подписка.
Последовательность взаимодействия¶
<Перечислите здесь список возможных действий пользователя и реакций системы на эти действия. Можно также включить сюда диаграммы и use case-ы для большей наглядности.>
Функциональные требования¶
RQ4: Связь осуществляется с помощью TCP client.
RQ5: Интегрируется в ДЖИНН …, вся работа с файлолвым хранилищем осуществляется через клиентский модуль.
RQ6: Модуль должен иметь возможность выполнять все операции самостоятельно, без обращения к серверу.
RQ7: Модуль должен иметь возможность работы с резервной копией файлового хранилища на локальном диске, причём алгоритм работы с ситемой резервирования указывается через параметры команды OPEN_FILE или CREATE_FILE, определённой в FSP.
RQ8: При работе с системой, содержащей резервный сервер, переключается на резервный сервер в случае проблем с активным сервером.
RQ9: Настройка логов осуществляется при помощи… Позволяет задать вывод информации:
- обо всех операциях
- о длительных операциях
- об ошибках
RQ10: Настройка конфигурации сети (активный сервер, резервный сервер) осуществляется…
Обработка запросов на стороне сервера
h4. Описание и приоритет
Серверный модуль обеспечивает получение запросов от клиентских модулей, их обработку и формирование и отправку данных, полученных в результате обработки, сообщений об ошибках. Он также осуществляет мониторинг изменений в файловом хранилище и отсылает соответствующие уведомления клиентским модулям в соответствии с подпиской. В режиме резервного сервера он поддерживает состояние файлового хранилища идентичным файловому хранилищу на активном сервере.
Последовательность взаимодействия¶
<Перечислите здесь список возможных действий пользователя и реакций системы на эти действия. Можно также включить сюда диаграммы и use case-ы для большей наглядности.>
Функциональные требования¶
RQ11: Связь осуществляется с помощью TCP server.
RQ12: Выполняется в виде стандартного сервиса MS Windows.
RQ13: Сервер должен поддерживать одновременное подключение большого, до нескольких тысяч, числа клиентов.
RQ14: Сервер выполняет любые операции, определённые протоколом FSP.
RQ15: Запросы от клиентов обрабатываются параллельно и асинхронно. Т.е. может быть получен новый запрос от клиента до окончания предыдущего запроса, и ответ на более поздний запрос может быть отправлен раньше.
RQ16: Сервер должен хранить и обрабатывать карту подписки клиентов на изменения в файлах.
RQ17: Модуль имеет возможность переключения в режим кэширования. В таком режиме доступ к хранилищу производится ТОЛЬКО через серверный модуль. Файлы кэшируются на чтение и на запись, а настройка осуществляется через…
RQ18: Модуль может работать в режиме резервирования. В этом режиме он не реагирует на запросы клиентов, а просто поддерживает хранилище идентичным активному. Переключение в активный режим осуществляется… Переключение в резервный режим осуществляется после восстановления данных.
RQ19: Настройка логов осуществляется при помощи… Позволяет задать вывод информации:
- обо всех операциях
- о длительных операциях
- об ошибках
RQ20: Настройка конфигурации сети (активный сервер, резервный сервер) осуществляется…
Требования к интерфейсу
h3. Интерфейс с пользователем
Настройка серверного модуля осуществляется…
Программный интерфейс¶
интерфейс клиентского модуля с ДЖИННом осуществляется…
Интерфейс передачи данных¶
RQ21: Протокол обмена клиент-север (File Srver Protocol - FSP) должен включать запросы на следующие операции c файлами в файловом хранилище:
- CREATE_FILE - создание файла
- OPEN_FILE - открытие файла
- READ_FILE - чтение файла
- WRITE_FILE - запись в файл
- CLOSE_FILE - закрытие файла
- LOCK_FILE - блокирование файла
- IS_FILE_EXIST - проверка существования файла
- GET_FILE_LENGTH - определение длины файла
- GET_FILE_POS - получить текущую позицию в файле
- SET_FILE_POS - установить текущую позицию в файле
- GET_FILE_ATTR - получить аттрибуты файла
- SET_FILE_ATTR - установить аттрибуты файла
- SUBSCRIBE_FILE - подписаться на получение уведомления об изменениях в файле
- UNSUBSCRIBE_FILE - отказаться от получения уведомлений об изменениях в файле
RQ22: FSP должен включать ответы на запросы следующего типа:
- FILE_DATA- данные из прочитанного файла
- FILE_ATTR- аттрибуты файла
- FILE_HANDLE - идентификатор файла
- FILE_POS- позиция в файле
- QUERY_STATUS- отчёт об успешности завершения запроса (например, существует файл или нет, подписались на изменения или нет, заблокировался файл или нет etc)
RQ23: FSP должен поддерживать передачу уведомлений типа NOTIFY_CHANGE, в котором передаются данные об изменениях в файле, на который клиент был подписан.
RQ24: Необходимо предусмотреть добавление в дальнейшем других команд FSP.
Другие нефункциональные требования
h3. Требования к производительности
<Если есть какие-то требования к производительности системы, то укажите их здесь и объясните, с чем это связано, чтобы помочь разработчикам определить наиболее оптимальный способ. Для систем реального времени определите временные интервалы. Определите эти требования как можно точнее. Возможно, для каждого компонента будут нужны свои индивидуальные требования.>
Требования по надёжности¶
<Приведите здесь требования, касающиеся возможной потери, повреждения или утечки данных. Определите методы борьбы с ними и методы пресечения попыток повреждения данных. Сошлитесь на стандарты надёжности, которые должны быть соблюдены.>
Требования по безопасности¶
<Определите здесь все требования к системе доступа и защиты продукта. Определите, какие медоты идентификации и авторизации будут использоваться. Сошлитесь на стандарты безопасности, которые должны быть соблюдены.>
Требования по качеству¶
<Определите любые дополнительные требования по качеству, которые важны для пользователей и/или разработчиков. Например: адаптируемость, доступность, правильность, гибкость, совместимость, лёгкость сопровождения, переносимость, надежность, возможность повторного использования, надежность, управляемость, удобство и простота использования. Постарайтесь разъяснить акценты на различные признаки, такие как лёгкость использования по отношению к лёгкости обучения etc>
Другие требования¶
<Добавьте сюда другие требования, которые не покрываются этой SRS. Они могут включать требования к базам данных, локализации, повторного использования etc. Добавьте дополнительные разделв при необходимости.>
Приложение 1: Словарь терминов¶
<Сюда нужно включить список специфических терминов, акронимов и аббревиатур, ежели таковые используются в этом документе. Лучше в алфавитном порядке>
Приложение 2: Анализируемые модели¶
<Это необязательное приложение, куда можно включить различные анализируемые модели, например, диграммы передачи данных, диаграммы классов, диаграммы состояний, диаграммы отношений между объектами etc>
