Разработка программного модуля для компьютерной игры
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
87;) модуль должен обеспечивать следующие операции:
) Наличие системы виртуальных директорий для организации разветвленных виртуальных пространств именования файлов.
) Возможность монтирования подсистемы (дисковой директории, зип-архива, сетевого диска, ресурсного exe/dll) в виртуальную директорию.
) Ручное и автоматическое (сборка мусора) демонтирование и удаление подсистем.
Для обеспечения гибкости работы модуля необходимо наличие следующих особенностей:
) Система должна позволять сосуществовать нескольким файлам, доступным по одинаковому имени (в разных подсистемах).
) Необходимо предоставить инструмент в compile-time для выбора варианта файла по естественным критериям (дата файла, размер и т.п.).
) Необходимо наличие механизма автоматического выбора варианта файла.
Требования к надежности
Для обеспечения стабильности работы модуля необходимо:
) Максимальное применение отработанных стандартных средств и библиотек.
) Анализ действий пользователя на корректность перед совершением операций в ядре модуля.
Требования к информационной и программной совместимости
Реализовывать модуль следует на языке С++. Модуль должен максимально основываться на стандартной библиотеке языка С++ и использовать идеологию STL. В качестве входных и выходных типов данных должны использоваться базовые и стандартные библиотечные типы С++. Для обработки наборов данных необходимо пользоваться алгоритмами стандартной библиотеки С++.
Для продления жизни модуля (продолжительного его применения в различных проектах) необходимо также обеспечить расширяемость (подключение новых механизмов эвристики, новых типов подсистем и т.д.).
1.2 Конструкторская часть
.2.1 Структура входных и выходных данных
Рис. 1.1. Структура входных и выходных данных
На рисунке 1.1. поясняется, что является входными и выходными данными модуля.
Для начальной инициализации VFS клиентский код монтирует подсистемы. Происходит это так: создается объект подсистемы, например, дисковой, инициализируется каталогом на диске, который должен быть представлен этой подсистемой, а также указанием необходимых атрибутов доступа (пароли, права), а потом передается ядру VFS вместе с желаемым расположением в дереве виртуальных директорий. После монтирования одной и более подсистем VFS становится работоспособной. Дальнейшие действия клиентского кода могут быть такими:
) Запрос на чтение или запись по имени. Передаваемые данные - имя и желаемые параметры потока. Ядро VFS запустит алгоритм поиска файла с таким именем в виртуальном дереве. Подробно алгоритм будет рассмотрен ниже.
) Запрос на перебор файлов внутри виртуальной директории. Передаваемые данные - путь и маска поиска. Ядро VFS идентифицирует все файлы, чьё имя соответствует маске поиска (считается, что все такие файлы лежат в одной виртуальной директории) и выдаст наружу объект, позволяющий вести перебор аналогично контейнеру STL. Подробно этот алгоритм также будет рассмотрен ниже.
) Получение информации о файле: существование, атрибуты. В отдельную ветвь на рисунке это не выделено, поскольку реализуется силами кода, получающего файловый поток.
1.2.2 Общая схема работы модуля
Рис. 1.2. Диаграмма прецедентов работы модуля
Общая схема работы модуля выглядит следующим образом:
) В случае работы со списком подсистем клиентский код должен создать подсистему, определиться с её виртуальным путем и передать её ядру. Происходит монтирование - включение подсистемы в виртуальное дерево. Работу по сборке мусора при завершении работы ядро берет на себя.
) В случае запросов к общему интерфейсу - собственно, основному интерфейсу VFS - во всех случаях запускается универсальный механизм создания итератора, он формирует специфической структуры список дескрипторов, подходящих под маску поиска и путь (маской поиска может выступать конкретное имя файла), с которым далее может происходить следующее:
а) В случае запроса на итерирование виртуальной директории список дескрипторов возвращается клиентскому коду.
б) В случае запроса потока применяется дефолтный или заданный клиентским кодом механизм отбора дескриптора, этот дескриптор передается подсистеме, к которой он принадлежит, и она своими силами открывает стандартный поток на файл.
в) В случае запроса параметров файла так же применяется механизм отбора дескриптора, он так же передается подсистеме, к которой он принадлежит, и она обеспечивает выдачу требуемых данных.
г) В случае попытки удаления файла запускается механизм поиска дескриптора, после чего файл, соответствующий дескриптору, удаляется.
1.2.3 Выбор платформы проектирования и его обоснование
В силу специфики разработки, выбор как операционной системы, так и инструментальных средств был продиктован принятыми в MiSTland техпроцессами.
В качестве операционной системы для платформенно-зависимого кода была выбрана Windows 98/Me/XP, т.к. именно под эти ОС создаются проекты MiSTland. Код дисковой подсистемы базируется на библиотеке CRT, реализация которой существует на большинстве известных программных платформ. На весь остальной код налагалось такое ограничение: модуль должен быть выполнен на языке С++ (ISO/IEC 14882) с использованием идеологии STL, для удобства подключения (весь остальной код также пишется на С++) и для удобства сопровождения любым программистом MiSTland.
В качестве