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. Как было сказано выше, директория физически хранится в дереве system, поэтому класс directory агрегирован классом system.

Рис. 1.7. Диаграмма класса sub_fs

На рисунке 1.7 изображена диаграмма класса sub_fs, который является интерфейсом хранилища (подсистемы). Класс предоставляет следующий интерфейс:

1) Получение физического расположения подсистемы.

2) Доступность подсистемы на запись.

3) Существование файла в подсистеме.

4) Атрибуты файла: размер, доступ, время создания, директория ли он.

5) Создать итератор по пути и маске поиска.

6) Открыть файл на запись или на чтение.

7) Удалить файл.

8) Создать реальные директории по пути.

9) Как было сказано выше, подсистему агрегирует класс directory. Создаваемый объект sub_fs_iter имеет ссылку на sub_fs.

Рис. 1.8. Диаграмма класса sub_fs_iter

На рисунке 1.8 изображена диаграмма класса sub_fs_iter, который является итератором подсистемы. Объекты данного класса, используются алгоритмами get_files и get_descriptor. Основные методы – получение текущего дескриптора и оператор инкремента. Содержит ссылку на «свою» подсистему.

Рис. 1.9. Диаграмма класса file_id

На рисунке 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