1.3. Информационные потребности пользователя

Основные требования, которые предъявлялись к модулю:

1) Открытие файлов на чтение и запись. Имена должны быть единообразными согласно принятой в проекте относительной системе именования.

2) Возможность перебора (итерирования) файлов внутри директории безотносительно их реального местонахождения.

3) Возможность подключать хранилища из сети, зип-архивов с шифрацией и без, из исполняемых файлов Win32.

4) Возможность существования нескольких файлов с одинаковым именем (в разных подсистемах) с возможностью ручного или автоматического выбора вариантов.

5) Контроль исключительных ситуаций в процессе работы. Недопущение аварийного прекращения работы из-за некорректных данных или действий пользовательского кода.

6) Как можно более простой и функциональный программный интерфейс.

1.1.4. Требования, предъявляемые системе

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

Состав выполняемых функций

Создаваемый модуль должен обеспечивать «прозрачное» выполнение файловых операций, проводимых клиентским кодом, в том числе:

1) Открытие файла на чтение и предоставление входного потока на него стандартной библиотеки С++, согласно относительной системе именования, принятой в структуре данных проекта.

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

3) Перебор файлов внутри директории безотносительно типу файлового хранилища. Механизм должен быть построен по идеологии итераторов стандартной библиотеки С++.

Для эффективного управление списком файловых хранилищ (в дальнейшем – «подсистем») модуль должен обеспечивать следующие операции:

1) Наличие системы виртуальных директорий для организации разветвленных виртуальных пространств именования файлов.

2) Возможность монтирования подсистемы (дисковой директории, зип-архива, сетевого диска, ресурсного exe/dll) в виртуальную директорию.

3) Ручное и автоматическое («сборка мусора») демонтирование и удаление подсистем.

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

1) Система должна позволять сосуществовать нескольким файлам, доступным по одинаковому имени (в разных подсистемах).

2) Необходимо предоставить инструмент в compile-time для выбора варианта файла по естественным критериям (дата файла, размер и т.п.).

3) Необходимо наличие механизма автоматического выбора варианта файла.

Требования к надежности

Для обеспечения стабильности работы модуля необходимо:

1) Максимальное применение отработанных стандартных средств и библиотек.

2) Анализ действий пользователя на корректность перед совершением операций в ядре модуля.

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

Реализовывать модуль следует на языке С++. Модуль должен максимально основываться на стандартной библиотеке языка С++ и использовать идеологию STL. В качестве входных и выходных типов данных должны использоваться базовые и стандартные библиотечные типы С++. Для обработки наборов данных необходимо пользоваться алгоритмами стандартной библиотеки С++.

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