
- •Раздел 1. Специальный раздел
- •1.1. Исследовательская часть
- •1.1.1. Постановка задачи
- •1.1.2. Предварительные нир
- •1.3. Информационные потребности пользователя
- •1.1.4. Требования, предъявляемые системе
- •1.2. Конструкторская часть
- •1.2.1. Структура входных и выходных данных
- •1.2.2. Общая схема работы модуля
- •1.2.3. Выбор платформы проектирования и его обоснование
- •1.2.4. Проектирование архитектуры модуля
- •1.2.5. Конфигурация технических средств
- •1.2.6. Алгоритмы работы модуля
- •1.2.7. Методика тестирования
- •1.2.8. Результаты экспериментальной проверки
- •2.1. Проектирование на языке uml
- •2.1.1. Концепция Unified Modeling Language
- •2.1.2. Виды диаграмм uml
- •2.1.3. Связь с объектно-ориентированными языками
- •2.2. Идеология stl в применении к архитектуре модуля
- •2.2.2. Контейнеры stl
- •2.2.3. Алгоритмы stl
- •2.2.4. Потоки
- •2.4.1. Умные указатели
- •2.3. Специализированный инструментарий
- •2.4.2. Типы тестов
- •2.4.3. Планирование модульных тестов
- •2.4.4. Примеры тестирования
- •2.4.5. Методы “грубой силы” и их применение при отладке программы
- •3.1. Цели определения себестоимости и цены модуля
- •3.2. Методы определения себестоимости
- •3.3. Расчет себестоимости vfs
- •3.4. Методы расчета цены
- •3.4.1. Расчет цены по стоимости изготовления
- •3.4.2. Расчет цены на основе роялти
- •3.4.3. Расчет цены на тиражируемый продукт
- •3.5. Расчет цены vfs
- •3.6. Выводы
- •4.2.1. Психофизиологические факторы
- •4.2.2. Электромагнитные излучения
- •4.2.3. Освещение рабочего места
- •4.2.4 Электробезопасность
- •4.2.5 Микроклимат
- •4.2.6. Зашумленность
- •4.3. Инженерный расчет освещенности машинного зала
- •4.4. Экологическая безопасность
- •4.5. Пожарная безопасность
- •4.6. Выводы
- •Список литературы
1.2.5. Конфигурация технических средств
Ограничения на конфигурацию технических средств накладываются проектом в целом. В проектах MiSTland, согласно тестированию, VFS никогда не занимала сколько-нибудь значительного объема памяти (это связано с небольшими объемами её собственных данных) и не отбирала сколько-нибудь заметное количество процессорного времени. Наиболее серьезно, как показали тесты, машину нагружает распаковка архива.
Требования к программному обеспечению – наличие Windows 98 и старше в случае использования подсистемы ресурсов исполняемых файлов Win32.
1.2.6. Алгоритмы работы модуля
На рис. 1.12 изображен алгоритм работы кода, собирающего последовательность файлов по маске поиска. Этот алгоритм используется при формировании списка итерирования и при нахождении отдельного файла для открытия потока либо для получения его свойств.
Рис.1.12. Схема алгоритма get_files
Необходимо пояснить работу алгоритма. Клиентский код предоставляет путь до искомой последовательности и маску поиска (допустимо конкретное имя файла), а также осуществляет выбор механизма сортировки дескрипторов файлов с одинаковыми виртуальными именами. Используется идиома «предикат», заимствованная из STL. Может использоваться предикат по умолчанию, либо же предоставленный пользовательским кодом. Потом запрашивается ядро VFS, у ядра запрашивается дерево виртуальных директорий. Дерево обходится начиная от корня, при каждой итерации выделяется текущая директория, в соответствии с ней корректируется путь поиска: путь директории считается виртуальной частью пути поиска, остальная часть – реальной, соответственно реальная часть пути должна быть передана подсистемам. Из директории берется список замонтированных в неё подсистем, к каждой подсистеме формируется запрос на существование файла с именем «реальная часть + маска поиска». Для этого используется собственный итератор подсистемы. Все найденные таким образом дескрипторы сохраняются в контейнер со структурой, несколько напоминающей графический эквалайзер (рис.1.13).
Рис. 1.13. Схема контейнера файлов виртуальной директории
Контейнер является списком, элементами которого являются списки дескрипторов с одинаковыми виртуальными именами, отсортированных в соответствии с переданным предикатом.
На рисунке 1.14 изображен алгоритм работы кода, получающего дескриптор файла по введенному имени. Работа аналогична алгоритму get_files, за исключением таких деталей:
1) В системе существует кэш для одиночных запросов, поэтому перед запуском сканирования дерева проверяется он – в случае совпадения имен искомого и закешированного дескрипторов выдается закешированный.
2) Наружу вместо контейнера выдается первый его элемент.
На рисунке 1.15 изображен алгоритм работы кода, монтирующего и демонтирующего подсистемы.
При монтировании клиентский код должен создать подсистему и передать её ядру VFS вместе с виртуальным путем, по которому должна находиться эта подсистема. У ядра запрашивается дерево и обходится в поиске директории с именем, совпадающим с желаемым виртуальным путем. Если такая находится, подсистема монтируется в неё. Если нет, берется директория с наиболее длинным подходящим виртуальным путём и в ней создаются недостающие директории, в последнюю из них монтируется подсистема. При демонтировании подсистемы VFS, конечно, ограничивается только поиском по дереву.
Рис. 1.14. Схема алгоритма get_descriptor
Рис. 1.15. Схема алгоритма mount