1.2. Конструкторская часть
1.2.1. Структура входных и выходных данных
Рис. 1.1. Структура входных и выходных данных
На рисунке 1.1. поясняется, что является входными и выходными данными модуля.
Для начальной инициализации VFS клиентский код монтирует подсистемы. Происходит это так: создается объект подсистемы, например, дисковой, инициализируется каталогом на диске, который должен быть представлен этой подсистемой, а также указанием необходимых атрибутов доступа (пароли, права), а потом передается ядру VFS вместе с желаемым расположением в дереве виртуальных директорий. После монтирования одной и более подсистем VFS становится работоспособной. Дальнейшие действия клиентского кода могут быть такими:
1) Запрос на чтение или запись по имени. Передаваемые данные – имя и желаемые параметры потока. Ядро VFS запустит алгоритм поиска файла с таким именем в виртуальном дереве. Подробно алгоритм будет рассмотрен ниже.
2) Запрос на перебор файлов внутри виртуальной директории. Передаваемые данные – путь и маска поиска. Ядро VFS идентифицирует все файлы, чьё имя соответствует маске поиска (считается, что все такие файлы лежат в одной виртуальной директории) и выдаст наружу объект, позволяющий вести перебор аналогично контейнеру STL. Подробно этот алгоритм также будет рассмотрен ниже.
3) Получение информации о файле: существование, атрибуты. В отдельную ветвь на рисунке это не выделено, поскольку реализуется силами кода, получающего файловый поток.
1.2.2. Общая схема работы модуля
Рис. 1.2. Диаграмма прецедентов работы модуля
Общая схема работы модуля выглядит следующим образом:
1) В случае работы со списком подсистем клиентский код должен создать подсистему, определиться с её виртуальным путем и передать её ядру. Происходит монтирование – включение подсистемы в виртуальное дерево. Работу по «сборке мусора» при завершении работы ядро берет на себя.
2) В случае запросов к общему интерфейсу – собственно, основному интерфейсу VFS – во всех случаях запускается универсальный механизм создания итератора, он формирует специфической структуры список дескрипторов, подходящих под маску поиска и путь (маской поиска может выступать конкретное имя файла), с которым далее может происходить следующее:
а) В случае запроса на итерирование виртуальной директории список дескрипторов возвращается клиентскому коду.
б) В случае запроса потока применяется дефолтный или заданный клиентским кодом механизм отбора дескриптора, этот дескриптор передается подсистеме, к которой он принадлежит, и она своими силами открывает стандартный поток на файл.
в) В случае запроса параметров файла так же применяется механизм отбора дескриптора, он так же передается подсистеме, к которой он принадлежит, и она обеспечивает выдачу требуемых данных.
г) В случае попытки удаления файла запускается механизм поиска дескриптора, после чего файл, соответствующий дескриптору, удаляется.
1.2.3. Выбор платформы проектирования и его обоснование
В силу специфики разработки, выбор как операционной системы, так и инструментальных средств был продиктован принятыми в MiSTland техпроцессами.
В качестве операционной системы для платформенно-зависимого кода была выбрана Windows 98/Me/XP, т.к. именно под эти ОС создаются проекты MiSTland. Код дисковой подсистемы базируется на библиотеке CRT, реализация которой существует на большинстве известных программных платформ. На весь остальной код налагалось такое ограничение: модуль должен быть выполнен на языке С++ (ISO/IEC 14882) с использованием идеологии STL, для удобства подключения (весь остальной код также пишется на С++) и для удобства сопровождения любым программистом MiSTland.
В качестве сред разработки были выбраны:
1) Microsoft Visual Studio .NET 7.1 – одна из объективно лучших интегрированных сред для Win32, имеющая такие сильные стороны, как:
а) Удобство и гибкость при создании различных приложений под Win32.
б) Её компилятор практически стопроцентно поддерживает стандарт С++, чем не отличаются многие другие компиляторы.
в) Наличие мощного и удобного интегрированного отладчика, поддерживающего, в том числе, удаленную отладку.
г) Наличие удобного и всеобъемлющего справочного руководства – MSDN.
д) Удобный интерфейс, использующий большинство известных наработок в области Win32 GUI.
2) Rational Rose – также одна из объективно лучших интегрированных сред по проектированию на языке UML. Её сильные стороны таковы:
а) Полная поддержка стандарта UML 1.3, на котором и велось проектирование.
б) Удобные графические инструменты.
в) Возможность проверять семантическую целостность диаграмм – своего рода компилятор.
г) Возможность экспортировать проекты на UML в код целого ряда целевых ООП - языков, в том числе, конечно же, и в код С++.
Как дополнительные инструменты были задействованы Microsoft Visio – для не-UML схем – и следующие программные библиотеки:
1) STLport – одна из реализаций STL, наиболее распространенная в индустрии, свободно распространяемая. Поддерживается силами членов Комитета по стандартизации С++. Платформенно независима. В отличие от реализации Microsoft, поставляемой вместе с MSVS, полностью соответствует стандарту С++.
2) BOOST – открытая библиотека, в которую вошли те инструменты, которые не были включены в стандартную библиотеку С++. Аналоги найти сложно. Отличается стилем кодирования, очень близким к интерфейсу STL, а также использованием идиом STL, таких, например, как «итератор».
3) zlib – свободно распространяемая библиотека, реализующая архивацию и распаковку архивов формата ZIP алгоритмами deflate и inflate (наиболее распространенные, другие сейчас практически не встречаются). Отличается простотой использования и гибким программным интерфейсом.