Разработка программного модуля для компьютерной игры. Дипломная (ВКР). Информационное обеспечение, программирование.
💣 👉🏻👉🏻👉🏻 ВСЯ ИНФОРМАЦИЯ ДОСТУПНА ЗДЕСЬ ЖМИТЕ 👈🏻👈🏻👈🏻
Информационное обеспечение, программирование
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!
Похожие работы на - Разработка программного модуля для компьютерной игры
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Скачать Скачать документ
Информация о работе Информация о работе
Нужна качественная работа без плагиата?
Не нашел материал для своей работы?
Поможем написать качественную работу Без плагиата!
.1.3. Информационные потребности пользователей
.1.4. Требования, предъявляемые к системе
.2.1. Структура входных и выходных данных
.2.3. Выбор платформы проектирования и его обоснование
.2.4. Проектирование архитектуры модуля
.2.5. Конфигурация технических средств
.2.8. Результаты экспериментальной проверки
.1.1. Концепция Unified Modeling
Language
.1.3. Связь с объектно-ориентированными языками
.2. Идеология STL в
применении к архитектуре модуля8
.3. Специализированный инструментарий
.3.1. Средства
работы с zip-архивами
.4.3. Планирование модульных тестов
.4.4. Примеры тестирования
.4.5. Методы “грубой силы” и их применение при отладке
программы
Раздел 3. Организационно-экономический раздел
.1. Цели определения себестоимости и цены модуля
.2. Методы определения себестоимости
.4.2. На основе отчислений с продаж («роялти»)
Раздел 4. Раздел производственно-экологической безопасности
.2. Анализ работы за компьютером с точки рения
производственной безопасности
.3. Инженерный расчет освещенности машинного зала
Современные компьютерные игры - крупные и сложные программные комплексы.
Затраты только на программную разработку часто измеряются сотнями
человеко-месяцев. По объему задействованных технологий, привлеченных средств и
уровню профессиональной подготовки разработчиков игровая индустрия давно заняла
отнюдь не последнее место в мире IT.
Разработка аппаратной базы в секторе персональных компьютеров уже
довольно долго стимулируется именно игровой индустрией. Развитие многих
программных технологий, в частности, всех мыслимых способов отрисовки
трехмерных изображений, идет именно благодаря играм.
Одной из отличительных черт игры как компьютерного приложения является
работа с огромным количеством ресурсов. Текстуры, музыка, видео, скрипты часто
исчисляются гигабайтами, особенно в последнее время. Имеет место проблема
организации ресурсов, в частности, информации на диске. Применение СУБД в
данном случае сопряжено с техническими и экономическими сложностями:
) Для представления данных в табличном или объектном виде чаще всего
нужна их обработка. Сама по себе СУБД - отдельное приложение, с которым нужно
устанавливать связь, разделять ресурсы и т.д. Редактирование данных на этапе
разработки вызовет сложности. Также тяжело решить некоторые специфичные
проблемы, речь о которых пойдет ниже.
) Современные быстродействующие СУБД стоят довольно больших денег, и в
случае с распространением игры как товара, как правило, требуется отдельное
лицензирование.
Чаще всего разработчики реализуют иерархические структуры на диске. В
силу внешних причин отдельные части ресурсов могут быть заархивированы и/или
зашифрованы. Часть ресурсов может быть оставлена на ключевом носителе (сейчас в
этой роли часто выступает оптический диск), который тоже может быть защищен по
какой-либо технологии (оптический диск - StarForce, LaserLock и другие). Также ресурсы могут быть
размещены на сетевом сервере, что накладывает свои требования к доступу,
верификации и иногда к защите. Ситуация в индустрии диктует ещё одно
требование: необходима возможность работы с несколькими параллельными версиями
ресурсов - это нужно для корректной установки патчей (пакетов исправлений и
дополнений) и пользовательских модификаций. В результате разработчики часто
оказываются перед распределенным комплексом весьма сложных по структуре
хранилищ. Кроме того, необходимость знать о типах хранилищ и особенностях
работы с ними, вызывает резкое усложнение кода и затрудняет его повторное
использование.
В данной работе рассмотрен известный подход к организации подобных
хранилищ, названный «виртуальная файловая система». Основные положения этого
подхода:
) Любые обращения к файловой системе идут по виртуальному «дереву»
каталогов, начиная с корня (root).
) Любое файловое хранилище - носитель, архив, сетевой каталог и т.п. -
может быть присоединено (замонтировано) к дереву как «ветка», соответственно,
часть полного пути до файла будет располагаться в дереве, а часть - в ветке.
) Под «файлом» подразумевается любой потоковый источник информации, это
могут быть дисковый файл, устройство или программно сформированные данные в
памяти.
Этот подход был заложен в операционных системах UNIX. Он отличается высокой гибкостью и прозрачностью в
использовании. Его реализация позволяет полностью инкапсулировать код,
отвечающий за непосредственную работу с разнородными хранилищами, и
предоставить единый интерфейс на все файловые операции.
Используя этот подход, был разработан модуль, задачей которого является
прозрачная работа с файловыми ресурсами вне зависимости от хранилища, из
которого они получены - дисковый каталог, сеть, архив, зашифрованное хранилище,
exe-файл или dll-файл. Архитектура модуля предусматривает максимально простое
подключение к существующим проектам, а так же простое расширение функционала:
) Увеличение количества типов поддерживаемых файловых подсистем
(хранилищ). Предусмотрен специальный интерфейс, реализуя который можно
реализовать и подключить новую подсистему.
) Наращивание механизмов эвристики по выбору вариантов файлов в случае
использования параллельных веток. Предусмотрен механизм передачи внешнего
функтора для сравнения файлов.
Модуль реализует работу с алгоритмами архивации zip, шифрованием по алгоритму CRC32, с сетью и с ресурсами исполняемых файлов Win32.
Выбор средств разработки определялся удобством интеграции в существующие
проекты, а также быстродействием результирующего модуля. В силу того, что
программирование в MiSTland ведется
на языке С++, модуль также был реализован на C++ и с использованием идеологии STL. Из инструментальных средств, выбор пал на Microsoft Visual Studio 7.1, STLport,
BOOST и zlib. Проектирование велось в Rational Rose, для не-UML схем использовался Microsoft Visio.
Предлагаемый модуль является dll-библиотекой, подключаемой к любому
проекту через интерфейс на языке С++, и обеспечивающий требуемый функционал,
используя стандартные потоки языка C++.
В технологической части и программной документации освещены этапы решения
задачи, принципы тестирования и отладка. Отдельная глава посвящена вопросу
надежности.
В организационно-экономическом разделе рассчитаны себестоимость
разработки модуля и его цена.
В производственно-экологическом разделе рассмотрены вредные факторы,
присутствующие на рабочем месте программиста, психофизиологические факторы,
требования к освещенности помещения, шуму, электро- и пожаробезопасности,
спланировано само рабочее место и организация работы программиста с
компьютером.
В специальном разделе пояснительной записки к дипломному проекту я опишу
основные стадии разработки программного модуля «VFS»: постановка задачи, предварительные НИР и
техническое задание. На этапе эскизного проектирования будут определены
требования к входным и выходным данным, составлен общий алгоритм работы модуля.
При техническом проектировании будет определена архитектура модуля,
детализированы функциональные требования, разработаны основные алгоритмы
работы, описана конфигурация технических средств.
Общая проблематика файловых хранилищ была освещена во введении. Поясню
основные принципы работы с файловыми ресурсами в игровых проектах, так сказать,
«изнутри».
Большинство модулей, так или иначе нуждающихся в файловом вводе,
принимают информацию в виде потока, реализованного силами CRT или STL. В силу широкого использования в индустрии средств STL, решения на базе CRT используются всё реже, поэтому
закладываться на их использование я не стал - таким образом, стандартным
форматом ввода-вывода де-факто в модуле стали std::basic_istream и std::basic_ostream.
Первой задачей модуля является прозрачность в предоставлении файлового
потока по имени. Проблемой является физически разделенное размещение данных - в
разных каталогах, на разных носителях, в разных форматах. Модуль должен
обеспечивать единое пространство имен, связывающее все разрозненные хранилища,
и изолирующее от пользовательского кода реальное размещение данных. Подобное
поведение модуля обычно называют «прозрачностью» в отношении пользовательского
кода. Естественно, структура имен файлов в модуле должна соответствовать
общепринятой (директория/файл), чтобы не усложнять логику работы с ним.
Второй задачей модуля является представление в стандартном виде (как
потока STL) файловых данных, полученных из
различных по внутренней структуре файловых хранилищ. Как правило, приходится
сталкиваться с заархивированными, зашифрованными данными, сетевыми
устройствами, платформенно-зависимыми хранилищами (например, данные, «зашитые»
в исполняемые файлы Win32 как
ресурсы). В данном контексте сложность составляют ограничения, налагаемые
структурой хранилищ.
Третьей задачей модуля является поддержка наличия нескольких файлов,
доступных по одному и тому же имени. Выбор между ними должен осуществляться при
помощи эвристики системы незаметно для пользовательского кода, а так же при
помощи явного указания программистом критерия сравнения файлов. Такой
функционал необходим для поддержки нескольких параллельных версий ресурсов -
например, в случае исправлений или пользовательских модификаций.
Из постановки задачи следует, что требуемый модуль является
самостоятельной подключаемой библиотекой, поэтому в предварительных НИР следует
изучить имеющиеся примеры ПО аналогичного назначения. В силу специфики задачи подобные
системы как отдельные программные модули, как правило, реализуются только в
стенах софтверных компаний, имеющих в таких модулях необходимость -
потенциальный рынок таких систем невелик. Подобные системы были разработаны для
внутреннего использования конкурентами MiSTland, а так же самой MiSTland для её ранних проектов.
Необходимость в повторной разработке была вызвана недостаточной гибкостью и
переносимостью ранее разработанного модуля, а так же трудностью его поддержки.
Таким образом, доступными для изучения оказались только свободно
распространяемые средства и общеизвестные концепции родом из мира open-source.
Библиотека boost::filesystem является свободно распространяемой в
рамках пакета BOOST, продвигаемого комитетом по
стандартизации C++. Эта
библиотека призвана облегчить «сборку» пути до файла и некоторые операции с
путем. Также она делает небольшую обертку (паттерн Wrapper) над стандартными потоками C++, позволяя удобнее указывать путь. Есть возможность обхода
файлов внутри директорий при помощи механизма, совместимого с итераторами
стандартной библиотеки С++. Работа с различными форматами представления пути
успешно инкапсулирована внутри.
Эта библиотека реализует часть требуемого в ТЗ функционала, конкретно -
единообразное представление клиентскому коду данных файлов и возможность
итерирования файлов. Она никоим образом не решает проблемы распределенных
хранилищ, но её код открыт (в соответствии с условиями распространения
библиотеки BOOST), поэтому она может служить
замечательным образцом внешнего программного интерфейса. Крайне полезны детали
её реализации, касающиеся универсального представления пути и конвертирования
различных его форматов, а также механизма итерирования веток файловой системы.
Задача абстракции от конкретного типа хранилища наиболее полно решена на
данный момент в системе 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
Требования, предъявляемые системе
Исходя из поставленной задачи и проведенных предварительных НИР, были
сформулированы требования к разрабатываемому модулю.
Создаваемый модуль должен обеспечивать «прозрачное» выполнение файловых
операций, проводимых клиентским кодом, в том числе:
) Открытие файла на чтение и предоставление входного потока на него
стандартной библиотеки С++, согласно относительной системе именования, принятой
в структуре данных проекта.
) Открытие файла на запись или его создание с предоставлением исходящего
потока стандартной библиотеки С++, согласно той же системе именования.
) Перебор файлов внутри директории безотносительно типу файлового
хранилища. Механизм должен быть построен по идеологии итераторов стандартной
библиотеки С++.
Для эффективного управление списком файловых хранилищ (в дальнейшем -
«подсистем») модуль должен обеспечивать следующие операции:
) Наличие системы виртуальных директорий для организации разветвленных
виртуальных пространств именования файлов.
) Возможность монтирования подсистемы (дисковой директории, зип-архива,
сетевого диска, ресурсного exe/dll) в виртуальную директорию.
) Ручное и автоматическое («сборка мусора») демонтирование и удаление
подсистем.
Для обеспечения гибкости работы модуля необходимо наличие следующих
особенностей:
) Система должна позволять сосуществовать нескольким файлам, доступным по
одинаковому имени (в разных подсистемах).
) Необходимо предоставить инструмент в compile-time
для выбора варианта файла по естественным критериям (дата файла, размер и
т.п.).
) Необходимо наличие механизма автоматического выбора варианта файла.
Для обеспечения стабильности работы модуля необходимо:
) Максимальное применение отработанных стандартных средств и библиотек.
) Анализ действий пользователя на корректность перед совершением операций
в ядре модуля.
Требования к информационной и программной совместимости
Реализовывать модуль следует на языке С++. Модуль должен максимально
основываться на стандартной библиотеке языка С++ и использовать идеологию STL. В качестве входных и выходных типов
данных должны использоваться базовые и стандартные библиотечные типы С++. Для
обработки наборов данных необходимо пользоваться алгоритмами стандартной
библиотеки С++.
Для продления «жизни» модуля (продолжительного его применения в различных
проектах) необходимо также обеспечить расширяемость (подключение новых
механизмов эвристики, новых типов подсистем и т.д.).
.2.1
Структура входных и выходных данных
Рис. 1.1. Структура входных и выходных данных
На рисунке 1.1. поясняется, что является входными и выходными данными
модуля.
Для начальной инициализации VFS клиентский код монтирует подсистемы. Происходит это так: создается
объект подсистемы, например, дисковой, инициализируется каталогом на диске,
который должен быть представлен этой подсистемой, а также указанием необходимых
атрибутов доступа (пароли, права), а потом передается ядру VFS вместе с желаемым расположением в
дереве виртуальных директорий. После монтирования одной и более подсистем VFS становится работоспособной.
Дальнейшие действия клиентского кода могут быть такими:
) Запрос на чтение или запись по имени. Передаваемые данные - имя и
желаемые параметры потока. Ядро VFS
запустит алгоритм поиска файла с таким именем в виртуальном дереве. Подробно
алгоритм будет рассмотрен ниже.
) Запрос на перебор файлов внутри виртуальной директории. Передаваемые
данные - путь и маска поиска. Ядро VFS идентифицирует все файлы, чьё имя соответствует маске поиска (считается,
что все такие файлы лежат в одной виртуальной директории) и выдаст наружу
объект, позволяющий вести перебор аналогично контейнеру STL. Подробно этот алгоритм также будет
рассмотрен ниже.
) Получение информации о файле: существование, атрибуты. В отдельную
ветвь на рисунке это не выделено, поскольку реализуется силами кода,
получающего файловый поток.
Рис. 1.2. Диаграмма прецедентов работы модуля
Общая схема работы модуля выглядит следующим образом:
) В случае работы со списком подсистем клиентский код должен создать
подсистему, определиться с её виртуальным путем и передать её ядру. Происходит
монтирование - включение подсистемы в виртуальное дерево. Работу по «сборке
мусора» при завершении работы ядро берет на себя.
) В случае запросов к общему интерфейсу - собственно, основному
интерфейсу VFS - во всех случаях запускается
универсальный механизм создания итератора, он формирует специфической структуры
список дескрипторов, подходящих под маску поиска и путь (маской поиска может
выступать конкретное имя файла), с которым далее может происходить следующее:
а) В случае запроса на итерирование виртуальной директории список
дескрипторов возвращается клиентскому коду.
б) В случае запроса потока применяется дефолтный или заданный клиентским
кодом механизм отбора дескриптора, этот дескриптор передается подсистеме, к
которой он принадлежит, и она своими силами открывает стандартный поток на
файл.
в) В случае запроса параметров файла так же применяется механизм отбора
дескриптора, он так же передается подсистеме, к которой он принадлежит, и она
обеспечивает выдачу требуемых данных.
г) В случае попытки удаления файла запускается механизм поиска
дескриптора, после чего файл, соответствующий дескриптору, удаляется.
1.2.3
Выбор платформы проектирования и его обоснование
В силу специфики разработки, выбор как операционной системы, так и
инструментальных средств был продиктован принятыми в MiSTland техпроцессами.
В качестве операционной системы для платформенно-зависимого кода была выбрана
Windows 98/Me/XP, т.к. именно
под эти ОС создаются проекты MiSTland. Код дисковой подсистемы базируется на библиотеке CRT, реализация которой существует на
большинстве известных программных платформ. На весь остальной код налагалось
такое ограничение: модуль должен быть выполнен на языке С++ (ISO/IEC 14882) с использованием идеологии STL, для удобства подключения (весь
остальной код также пишется на С++) и для удобства сопровождения любым
программистом MiSTland.
В качестве сред разработки были выбраны:
) Microsoft Visual Studio .NET
7.1 - одна из объективно лучших интегрированных сред для Win32, имеющая такие сильные стороны,
как:
а) Удобство и гибкость при создании различных приложений под Win32.
б) Её компилятор практически стопроцентно поддерживает стандарт С++, чем
не отличаются многие другие компиляторы.
в) Наличие мощного и удобного интегрированного отладчика,
поддерживающего, в том числе, удаленную отладку.
г) Наличие удобного и всеобъемлющего справочного руководства - MSDN.
д) Удобный интерфейс, использующий большинство известных наработок в
области Win32 GUI.
) Rational Rose - также одна из объективно лучших интегрированных
сред по проектированию на языке UML.
Её сильные стороны таковы:
а) Полная поддержка стандарта UML 1.3, на котором и велось проектирование.
б) Удобные графические инструменты.
в) Возможность проверять семантическую целостность диаграмм - своего рода
компилятор.
г) Возможность экспортировать проекты на UML в код целого ряда целевых ООП - языков, в том числе,
конечно же, и в код С++.
Как дополнительные инструменты были задействованы Microsoft Visio - для не-UML схем - и следующие программные библиотеки:
) STLport - одна из реализаций STL, наиболее распространенная в
индустрии, свободно распространяемая. Поддерживается силами членов Комитета по
стандартизации С++. Платформенно независима. В отличие от реализации Microsoft, поставляемой вместе с MSVS, полностью соответствует стандарту
С++.
) BOOST - открытая библиотека, в которую
вошли те инструменты, которые не были включены в стандартную библиотеку С++.
Аналоги найти сложно. Отличается стилем кодирования, очень близким к интерфейсу
STL, а также использованием идиом STL, таких, например, как «итератор».
) zlib - свободно распространяемая
библиотека, реализующая архивацию и распаковку архивов формата ZIP алгоритмами deflate и inflate
(наиболее распространенные, другие сейчас практически не встречаются).
Отличается простотой использования и гибким программным интерфейсом.
1.2.4
Проектирование архитектуры модуля
Ниже описаны архитектурные решения, примененные в модуле.
На рисунке 1.3 изображена общая диаграмма классов VFS. На диаграмме не указаны детально
члены классов во избежание нагромождения. Здесь прослежены инкапсулированность
основных членов классов, основные зависимости с указанием типа связей, их
мощности и направлением раскрытия. Интерфейсные классы выделены стереотипом interface. На диаграмме не присутствует
никаких вспомогательных классов, прямо не участвующих в основных алгоритмах
работы. Ниже детально рассматриваются особенности проектирования каждого из
классов-участников диаграммы.
На рисунке 1.4 изображена диаграмма интерфейсного класса fs, который является основным
программным интерфейсом модуля. Строго говоря, классом fs не является. Реализован он как пространство имен с
вложенными в него самостоятельными функциями. Никаких данных за ненадобностью fs не хранит, поэтому его внешние связи
ограничены такой их разновидностью, как «зависимость» (dependency).
Зависимость от класса system
обусловлена работой алгоритмов get_files, get_descriptor и mount, которым требуется доступ к дереву
виртуальных директорий, хранящемуся в system.
Зависимость от классов file_id, io_file и iterator обусловлена использованием их как
аргументов и возвращаемых значений.
На рисунке 1.5 изображена диаграмма класса system, который является ядром VFS. Класс использует несколько модернизированный паттерн
«синглетон», или «одиночка». Этот паттерн (устоявшаяся схема проектирования)
характерен тем, что на весь проект гарантированно существует только один
экземпляр класса. В С++ это реализуется как статический член класса - экземпляр
объекта, доступ к которому осуществляется статической же функцией.
Инициализация и уничтожение экземпляра происходят как у статической переменной.
Конструктор и деструктор такого класса объявляются приватными. Для большей гибкости
существует разновидность этой схемы, когда есть открытые статические функции
создания и уничтожения единственного объекта, а функция доступа снабжается
идентификацией попытки доступа к неинициализированному объекту.
Для облегчения возможной замены реализации класса system, а также для сокрытия некоторой
части интерфейса, основные функции-члены system сделаны абстрактными, а реализует их скрытый
наследник system_impl.
В качестве контейнера, реализующего дерево, используется шаблонный класс lcrn_tree из внутренней библиотеки MiSTland. В нем определен итератор,
используемый в интерфейсе system.
В узлах дерева содержатся объекты типа directory, поэтому system связан с этим классом агрегированием. Также system непосредственно агрегирует объект
класса сache.
В программном интерфейсе system
реализованы функции создания, уничтожения и доступа для объекта-одиночки,
функции доступа к дереву (итераторы на начало и конец), а также функции mount() и unmount(), реализующие одноименные алгоритмы.
Рис. 1.6. Диаграмма класса directory
На рисунке 1.6 изображена диаграмма класса directory, представляющего виртуальную
директорию. Класс предназначен для хранения списка подсистем и манипулирования
им. Директория хранит своё имя и собственно список, реализованный контейнером std::list, это обуславливает агрегирование классов std::string, std::list и sub_fs.
Как было сказано выше, директория физически хранится в дереве system, поэтому класс directory агрегирован классом system.
На рисунке 1.7 изображена диаграмма класса sub_fs,
который является интерфейсом хранилища (подсистемы). Класс предоставляет
следующий интерфейс:
) Получение физического расположения подсистемы.
) Доступность подсистемы на запись.
) Существование файла в подсистеме.
) Атрибуты файла: размер, доступ, время создания, директория ли он.
) Создать итератор по пути и маске поиска.
) Открыть файл на запись или на чтение.
) Создать реальные директории по пути.
) Как было сказано выше, подсистему агрегирует класс directory. Создаваемый объект sub_fs_iter имеет ссылку
на sub_fs.
Рис. 1.8. Диаграмма класса sub_fs_iter
На рисунке 1.8 изображена диаграмма класса sub_fs_iter, который является итератором
подсистемы. Объекты данного класса, используются алгоритмами get_files и get_descriptor. Основные методы - получение
текущего дескриптора и оператор инкремента. Содержит ссылку на «свою»
подсистему.
На рисунке 1.9 изображена диаграмма класса file_id,
который является дескриптором файла в VFS. Класс содержит своё полное имя и ссылку на подсистему. В текущей
реализации в интерфейсе file_id есть набор методов для получения
атрибутов файла, которые являются делегированием соответствующих из подсистемы.
Для полноты картины стоит упомянуть вспомогательные классы io_file и iterator, диаграммы которых помещены на рисунки 1.10 и 1.11. Класс io_file служит для предоставления потока на файл, хранит в
себе исходящий либо входящий поток и экземпляр file_id.
Класс iterator служит для построения контейнеров
дескрипторов в реализации алгоритмов get_files и get_descriptor.
Рис. 1.10. Диаграмма класса io_file
Рис. 1.11. Диаграмма класса iterator
1.2.5
Конфигурация технических средств
Ограничения на конфигурацию технических средств накладываются проектом в
целом. В проектах MiSTland, согласно
тестированию, VFS никогда не занимала сколько-нибудь
значительного объема памяти (это связано с небольшими объемами её собственных
данных) и не отбирала сколько-нибудь заметное количество процессорного времени.
Наиболее серьезно, как показали тесты, машину нагружает распаковка архива.
Требования к программному обеспечению - наличие Windows 98 и старше в случае использования подсистемы
ресурсов исполняемых файлов Win32.
На рис. 1.12 изображен алгоритм работы кода, собирающего
последовательность файлов по маске поиска. Этот алгоритм используется при
формировании списка итерирования и при нахождении отдельного файла для открытия
потока либо для получения его свойств.
Рис.1.12. Схема алгоритма get_files
Необходимо пояснить работу алгоритма. Клиентский код предоставляет путь
до искомой последовательности и маску поиска (допустимо конкретное имя файла),
а также осуществляет выбор механизма сортировки дескрипторов файлов с
одинаковыми виртуальными именами. Используется идиома «предикат»,
заимствованная из STL. Может
использоваться предикат по умолчанию, либо же предоставленный пользовательским
кодом. Потом запрашивается ядро VFS, у
ядра запрашивается дерево виртуальных директорий. Дерево обходится начиная от
корня, при каждой итерации выделяется текущая директория, в соответствии с ней
корректируется путь поиска: путь директории считается виртуальной частью пути
поиска, остальная часть - реальной, соответственно реальная часть пути должна
быть передана подсистемам. Из директории берется список замонтированных в неё
подсистем, к каждой подсистеме формируется запрос на существование файла с
именем «реальная часть + маска поиска». Для этого используется собственный
итератор подсистемы. Все найденные таким образом дескрипторы сохраняются в
контейнер со структурой, несколько напоминающей графический эквалайзер
(рис.1.13).
Рис. 1.13. Схема контейнера файлов виртуальной директории
Похожие работы на - Разработка программного модуля для компьютерной игры Дипломная (ВКР). Информационное обеспечение, программирование.
Реферат Экология Наука Xx Века
Скорость Распространения Волны Различных Типов Волн Реферат
Курсовая работа по теме Особенности проектирования простейших цифровых устройств
Реферат На Тему Государственное Устройство, Форма Правления И Общественный Функции Государства Республики Беларусь
Сочинение Бедная Мама
Рисунки И Таблицы В Курсовой
Курсовая работа по теме Методы и средства совершенствования техники передач на нападающий удар в волейболе
Павел Воля Описание Внешности Сочинение 7 Класс
Курсовая работа по теме Судебная власть Российской Федерации
Реферат На Тему Выдача Трудовой Книжки При Увольнении Работника По Законодательству Республики Беларусь
Алгебра 10 Гдз Контрольная Работа
Реферат: Совершенствование кредитования населения
Реферат: Ремонт и зимовка суден
Сочинение Миниатюра Каким Я Себе Представляю Базарова
Ютуб Я И Другие Итоговое Сочинение
Цели И Задачи Реферата О Солдатской Фляжке
Реферат: Госбанк СССР. Скачать бесплатно и без регистрации
Курсовая Работа На Тему Расчет Показателей Надежности Простейшей Системы Электроснабжения Вероятностными Методами
Реферат по теме Система оздоровления Поля Брэгга здоровый позвоночник
Сочинение На Английском На Тему Здоровье
Курсовая работа: Рынок корпоративных облигаций: тенденции и перспективы развития
Доклад: О доказательствах бытия Бога
Реферат: Формальная определенность норм права и ее пределы