Разработка программного модуля для компьютерной игры
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
?мные модули, как правило, реализуются только в стенах софтверных компаний, имеющих в таких модулях необходимость - потенциальный рынок таких систем невелик. Подобные системы были разработаны для внутреннего использования конкурентами MiSTland, а так же самой MiSTland для её ранних проектов. Необходимость в повторной разработке была вызвана недостаточной гибкостью и переносимостью ранее разработанного модуля, а так же трудностью его поддержки. Таким образом, доступными для изучения оказались только свободно распространяемые средства и общеизвестные концепции родом из мира open-source.
BOOST filesystem
Библиотека boost::filesystem является свободно распространяемой в рамках пакета BOOST, продвигаемого комитетом по стандартизации C++. Эта библиотека призвана облегчить сборку пути до файла и некоторые операции с путем. Также она делает небольшую обертку (паттерн Wrapper) над стандартными потоками C++, позволяя удобнее указывать путь. Есть возможность обхода файлов внутри директорий при помощи механизма, совместимого с итераторами стандартной библиотеки С++. Работа с различными форматами представления пути успешно инкапсулирована внутри.
Эта библиотека реализует часть требуемого в ТЗ функционала, конкретно - единообразное представление клиентскому коду данных файлов и возможность итерирования файлов. Она никоим образом не решает проблемы распределенных хранилищ, но её код открыт (в соответствии с условиями распространения библиотеки BOOST), поэтому она может служить замечательным образцом внешнего программного интерфейса. Крайне полезны детали её реализации, касающиеся универсального представления пути и конвертирования различных его форматов, а также механизма итерирования веток файловой системы.
UNIX VFS
Задача абстракции от конкретного типа хранилища наиболее полно решена на данный момент в системе Linux (и в большинстве используемых ныне *nix-систем) комплексом под названием VFS (Virtual File System). Аналогичные операции в других доступных для изучения операционных системах - рассматривались системы семейства Windows - производятся не с той гибкостью, которой бы хотелось достичь в проектах MiSTland. Использовать систему VFS непосредственно не представляется возможным, поскольку VFS является неотъемлемой частью ядер операционных систем *nix, однако интерфейс и логика работы VFS, несомненно, являются удачными и проверенными долговременным использованием.
Кратко о VFS в реализации *nix - систем:
Существует виртуальное дерево, каждый лист которого является ячейкой, с которой может быть ассоциирован список неких файловых хранилищ - разделов или директорий на диске, съемных носителей, сетевых дисков и т.д. Структура каталогов ассоциированного (в терминологии VFS - замонтированного) хранилища становится для VFS естественным продолжением имен ветки виртуального дерева. Работа с каждым хранилищем на физическом уровне инкапсулирована кодом VFS и может быть изменена или дополнена путем модификации кода, компиляции модуля VFS и интеграции системой патчей в ядро ОС.
Каждому файлу в VFS соответствует идентификатор (в терминологии VFS - dentry), по которому VFS определяет, к какому физическому хранилищу принадлежит файл и из которого, соответственно, можно запросить атрибуты, содержимое файла, права доступа, число активных копий и т.п. VFS ведет учет идентификаторов файлов, организуя их в хэш-очереди. Файлом, кстати, в зависимости от реализации хранилища, может быть представлен специальный файл устройства, канал (pipe), сетевой сокет.
Все файловые операции - чтение, запись, удаление - реализованы на уровне VFS, которая спускает вызовы реализациям, предназначенным для работы с конкретными типами хранилищ.
1.1.3 Информационные потребности пользователя
Основные требования, которые предъявлялись к модулю:
) Открытие файлов на чтение и запись. Имена должны быть единообразными согласно принятой в проекте относительной системе именования.
) Возможность перебора (итерирования) файлов внутри директории безотносительно их реального местонахождения.
) Возможность подключать хранилища из сети, зип-архивов с шифрацией и без, из исполняемых файлов Win32.
) Возможность существования нескольких файлов с одинаковым именем (в разных подсистемах) с возможностью ручного или автоматического выбора вариантов.
) Контроль исключительных ситуаций в процессе работы. Недопущение аварийного прекращения работы из-за некорректных данных или действий пользовательского кода.
) Как можно более простой и функциональный программный интерфейс.
1.1.4 Требования, предъявляемые системе
Исходя из поставленной задачи и проведенных предварительных НИР, были сформулированы требования к разрабатываемому модулю.
Состав выполняемых функций
Создаваемый модуль должен обеспечивать прозрачное выполнение файловых операций, проводимых клиентским кодом, в том числе:
) Открытие файла на чтение и предоставление входного потока на него стандартной библиотеки С++, согласно относительной системе именования, принятой в структуре данных проекта.
) Открытие файла на запись или его создание с предоставлением исходящего потока стандартной библиотеки С++, согласно той же системе именования.
) Перебор файлов внутри директории безотносительно типу файлового хранилища. Механизм должен быть построен по идеологии итераторов стандартной библиотеки С++.
Для эффективного управление списком файловых хранилищ (в дальнейшем - подсистем