Разработка программного модуля для компьютерной игры
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
сред разработки были выбраны:
) 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
На рисунке 1.3 изображена общая диаграмма классов VFS. На диаграмме не указаны детально члены классов во избежание нагромождения. Здесь прослежены инкапсулированность основных членов классов, основные зависимости с указанием типа связей, их мощности и направлением раскрытия. Интерфейсные классы выделены стереотипом interface. На диаграмме не присутствует никаких вспомогательных классов, прямо не участвующих в основных алгоритмах работы. Ниже детально рассматриваются особенности проектирования каждого из классов-участников диаграммы.
Рис. 1.4. Диаграмма класса fs
На рисунке 1.4 изображена диаграмма интерфейсного класса fs, который является основным программным интерфейсом модуля. Строго говоря, классом fs не является. Реализован он как пространство имен с вложенными в него самостоятельными функциями. Никаких данных за ненадобностью fs не хранит, поэтому его внешние связи ограничены такой их разновидностью, как зависимость (dependency).
Зависимость от класса system обусловлена работой алгоритмов get_files, get_descriptor и mount, которым требуется доступ к дереву виртуальных директорий, хранящемуся в system.
Зависимость от классов file_id, io_file и iterator обусловлена использованием их как аргументов и возвращаемых значений.
Рис. 1.5. Диаграмма класса system
На рисунке 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. Как было сказано выше, директория физически хран