Диплом_Frozen / доклад

Доброе утро.

Вашему вниманию предлагается дипломный проект на тему «виртуальная файловая система». Целью его являлась разработка встраиваемого программного модуля, инкапсулирующего файловые операции, прежде всего с файлами ресурсов, внутри проекта. Формально задачи были сформулированы так:

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

2. организовать для всех файлов единое пространство имен и предоставить на его основе универсальный инструмент поиска файлов;

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

Изначально модуль разрабатывался для проекта «Альфа Антитеррор».

Небольшой экскурс в предметную область. Компьютерные игры – один из тех видов программного обеспечения, которому для работы требуется огромное количество файловых ресурсов. В современной игре число файлов и их размер исчисляются тысячами и гигабайтами соответственно. В силу технических и экономических причин СУБД использовать нельзя, поэтому ресурсы чаще всего организовывают в виде иерархических структур на диске. Реалии таковы: ресурсы чаще всего должны дробиться. Часть может быть свободно оставлена на диске, часть – в архиве, часть - зашифрована, часть – на сетевом диске, часть – на защищенном носителе (например, компакт-диск с Laser-Lock). Индустрия диктует ещё одно требование: необходимо поддерживать несколько параллельных веток ресурсов для возможности быстрого обновления и пользовательских модификаций (как их сейчас называют, «модов»). Разработчики остальных модулей в результате оказываются перед сложной и разветвленной структурой данных, к тому же, часто меняющейся. Самой общей задачей моего модуля было избавить остальных разработчиков от связанных с этой структурой проблем. На слайде 2 указаны те модули проекта, которым был нужен файловый ввод/вывод.

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

На слайде 4 приведена схема внутренней структуры модуля. Такой подход к организации был применен в операционных системах семейства UNIX, и, чтобы это было понятно интуитивно, было позаимствовано название. Центральным объектом модуля является дерево, узлами которого являются виртуальные директории. [ПОКАЗАТЬ] Каждая директория содержит в себе список хранилищ файлов. [ПОКАЗАТЬ] Каждый файл представлен дескриптором, который можно запросить у хранилища. Как и в UNIX VFS, дескриптор обезличен и, вообще говоря, может представлять собой файл, устройство или сетевой канал. Пространство имен формируется следующим образом: путь до файла складывается из двух частей – первая часть формируется из имен виртуальных директорий вплоть до корня, а вторая – это относительный путь до него в хранилище с именем.

На слайде 5 приведена диаграмма прецедентов, она же Use Case Diagram из языка UML. На этой диаграмме в первом приближении показан функционал модуля согласно возможным прецедентам использования. Программно модуль делится на ядро и общую интерфейсную часть. Для ядра доступны два прецедента: подключить хранилище и отключить его. Прецедент подключения хранилища расширяется до его создания. Для общей интерфейсной части доступны 4 прецедента: получить итератор по маске поиска, получить поток на файл, получить атрибуты файла по его имени и удалить файл. Каждый из этих прецедентов расширяется до задавания параметров поиска и включает в себя прецедент проверки строки поиска на правильность.

На слайде 6 представлена диаграмма классов языка UML, которая описывает программную архитектуру модуля. Этот вопрос очень подробно рассмотрен в пояснительной записке, сейчас нужно остановиться только на двух моментах:

1. центральный класс модуля – system – выполнен по паттерну синглетон или одиночка, поэтому его объект доступен всегда и гарантированно существует в единственном экземпляре [ПОКАЗАТЬ];

2. абстрактные классы sub_fs и sub_fs_iter являются интерфейсами хранилища, и именно их реализации и представляют в модуле дисковые, архивированные и прочие реальные хранилища [ПОКАЗАТЬ].

Слайд 7 посвящен схеме алгоритма поиска файлов по маске, или, согласно терминам модуля, итерирования виртуальной директории. Начальные действия таковы: от пользователя получаются путь с маской поиска и (опционально) алгоритм сортировки файлов с одинаковым именем в виде функтора, запрашивается объект system и выстраивается список виртуальных директорий, чьё имя соответствует хотя бы первой части запрошенного пути с маской. Затем в цикле у каждой директории запрашивается список реальных хранилищ и с каждым хранилищем выполняются следующие операции: корректируется путь поиска (спереди отбрасывается та часть, которая соответствует имени виртуальной директории), и у хранилища запрашивается список файлов с именем, соответствующим скорректированному. Эти файлы раскладываются в контейнер сложной структуры (подробно этот вопрос освещен в пояснительной записке). По завершении обхода списка виртуальных директорий в полученном контейнере файлы с одинаковым именем сортируются переданным алгоритмом, и контейнер передается наружу, где по нему можно перемещаться стандартными итераторами STL.

На слайде 8 изображена схема алгоритма получения одиночного дескриптора. Этот алгоритм аналогичен предыдущему, отличия следующие:

1. используется кэш. Перед собственно поиском объект кэша запрашивается на предмет наличия у него файла с таким же именем;

2. поскольку передается имя, то выходной список по структуре является обычным контейнером, в нем находятся файлы с одинаковыми именами, и эти файлы в нем отсортированы переданным алгоритмом. Наружу выдается первый в списке как наиболее предпочтительный.

На слайде 9 проиллюстрирован процесс отладки. Использовались методы «силовой отладки», заключающиеся в инициированном программистом выводе отладочной информации на экран. При разработке модуля использовались вывод в консоль тестового приложения и в окно output студии.

Для тестирования модуля был применен подход «модульного тестирования», хорошо освещенный в книге Эрика Брауде «Технология разработки программного обеспечения» и принятый как стандарт группы IEEE за номером 1008 от 1987 года. Подробно вопрос освещен в технологической части пояснительной записки. Модульные тесты охватывают тестирование на уровне функций, групп методов классов и пакетов классов. [ПОКАЗАТЬ] Они выполняются непосредственно во время кодирования во всё время разработки. [ПОКАЗАТЬ] Системное тестирование при разработке модуля проводилось в ограниченном объеме, потому как этими вопросами в команде занимались отдельные люди. Из системных проводились тесты на надежность с вычислением средней наработки на отказ, тесты на использование ресурсов компьютера и стресс-тесты.

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

Выводы. В процессе работы были решены все поставленные задачи. Модуль был интегрирован в проекты «Альфа Антитеррор», «Warfare» и «African Alliance».

Благодарю за внимание, доклад окончен.