Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Диплом_Frozen / ТЗ на диплом

.doc
Скачиваний:
115
Добавлен:
16.04.2013
Размер:
53.76 Кб
Скачать

6

«Утверждаю»

Зав. кафедрой ИПОВС

Московского государственного института

электронной техники

__________ (А.Э. Нестеров)

«___» __________ 200_г

Техническое задание

на дипломный проект по теме

«Разработка программного модуля

«Виртуальная файловая система» (VFS)»

Специальность – 23010565

Квалификация – специалист

Исполнитель: _________ (Ересов А.Е.)

Руководитель: _________ (Федотова Е.Л.)

Москва 2004

1. Введение

«Виртуальная файловая система» - программный модуль, предназначенный для осуществления файловых операций при использовании в качестве составной части игровых проектов компании «МиСТленд-ЮГ». Данный модуль предполагается применять как интерфейс для прочего кода, инкапсулирующий работу с различными файловыми хранилищами, в том числе архивированными, шифрованными, сетевыми и платформенно-зависимыми: а также эвристику по сравнению файлов. Для унификации кода необходимо придерживаться идеологии STL.

2. Основания для разработки

Документ, на основании которого ведется разработка: распоряжение технического директора ЗАО «МиСТленд-ЮГ».

Наименование разработки и её шифр:

Виртуальная файловая система. ШИФР: VFS

3. Назначение разработки

Предоставить единый интерфейс для файловых операций, инкапсулировать платформенно-зависимый код, эвристику и специфические модули (шифрование, архивирование) в разрабатываемом модуле.

4. Технические требования

4.1. Требования к функциональным характеристикам

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

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

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

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

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

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

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

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

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

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

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

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

На этапе эскизного проектирования системы необходимо также:

1) Определить план мероприятий и этапность наращивания функционала модуля, включая документирование и тестирование.

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

4.1.2. Организация входных и выходных данных

Исходные данные, поступающие в систему, делятся на два потока:

1) Данные о файловых подсистемах, с которыми предстоит работать модулю:

а) тип подсистемы;

б) виртуальный путь до неё во внутренней системе именования;

в) атрибуты физического доступа до подсистемы (имена директорий, архивов, сетевые пути и т.д.);

2) Данные о файлах, запрашиваемых пользователем модуля:

а) имя (возможно – маска поиска);

б) атрибуты.

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

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

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

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

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

4.3. Условия эксплуатации и требования к составу и параметрам технических средств

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

Требуется, чтобы использующие библиотеку модули проекта были реализованы на языке С++ (ANSI/ISO 1997). В составе библиотеки планируются платформенно-зависимые элементы, рассчитанные на работу в среде Microsoft Windows 98 и выше.

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

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

5. Требования к программной документации

Состав разрабатываемой программной документации:

1) текст программы по ГОСТ 19.401-78

2) руководство программиста по ГОСТ 19.504-79

6. Технико-экономические показатели

Необходимо провести стоимостной анализ разработки.

7. Стадии и этапы разработки

Должны быть проведены следующие работы:

1-й этап (преддипломной практики):

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

2-й этап (завершающий):

1) пробные внедрение и эксплуатация модуля в существующем проекте

8. Порядок контроля и приемки

Испытания – тесты отдельных модулей.

Необходимо выполнить тестирование специализированных модулей, как то:

1) «бегунковый» дешифратор для шифрованных архивов. На вход – шифрованный текст, на выходе должен быть расшифрованный. Проверка стабильности при заведомо внедренных ошибках шифрации.

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

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

6

Соседние файлы в папке Диплом_Frozen