Содержание к диссертации
Введение
Глава 1. Сферы применения, методы и инструментальные средства создания адаптивных программных систем на основе трехмерной графики 10
1.1 Особенности и сферы применения трехмерных адаптивных приложений 10
1.2 Существующие методы разработки адаптивных программных систем 16
1.3 Существующие инструментальные средства для создания трехмерных адаптивных приложений 26
1.4 Обзор технологии моделирования изменчивости 31
Выводы по главе 1 39
Глава 2. Модели и методы структурно-параметрического синтеза и функционирования трехмерных адаптивных приложений 41
2.1 Общая структура трехмерного адаптивного приложения как модель его морфологического множества 41
2.2 Теоретико-множественное представление общей структуры трехмерного адаптивного приложения 46
2.3 Математическая модель изменчивости трехмерного адаптивного приложения 56
2.4 Метод структурно-параметрического синтеза трехмерных адаптивных приложений 62
Выводы по главе 2 69
Глава 3. Разработка алгоритмического и программного обеспечения системы структурно-параметрического синтеза трехмерных адаптивных приложений 70
3.1 Алгоритм верификации системных конфигураций трехмерного адаптивного приложения 70
3.2 Алгоритм автоматического ситуационного выбора системных конфигураций в процессе выполнения 77
3.3 Особенности реализации трехмерных адаптивных приложений и требования, предъявляемые к исходным данным
3.4 Архитектура системы структурно-параметрического синтеза трехмерных адаптивных приложений 86
3.4.1 Общие сведения об архитектуре системы 86
3.4.2 Модуль работы с изменчивостью 89
3.4.3 Модуль визуального программирования 94
3.4.4 Модуль компоновки 99
3.4.5 Модуль исполнения 101
3.4.6 Модуль авторизации и учета пользователей и модуль формирования выходных данных 103
Выводы по главе 3 105
Глава 4. Программная реализация и методические аспекты применения разработанной системы 107
4.1. Тестирование алгоритма верификации системных конфигураций 107
4.2. Альтернативный вариант представления диаграммы характеристик 117
4.3. Применение разработанной системы для создания тестирующего приложения 121
4.4. Сравнительная оценка временных и экономических затрат при создании
приложений 137
Выводы по главе 4 140
Заключение 141
Список литературы 144
- Существующие инструментальные средства для создания трехмерных адаптивных приложений
- Теоретико-множественное представление общей структуры трехмерного адаптивного приложения
- Алгоритм автоматического ситуационного выбора системных конфигураций в процессе выполнения
- Альтернативный вариант представления диаграммы характеристик
Существующие инструментальные средства для создания трехмерных адаптивных приложений
Трехмерные адаптивные приложения (ТРАП) — класс программного обеспечения, объединяющего в себе следующие свойства: 1) визуализация основных данных с помощью трехмерных моделей, 2) интерактивность, 3) адаптивность. Под интерактивностью в свою очередь следует понимать функционирование программы в режиме информационного обмена с пользователем. Приложения, относимые к классу ТРАП, как правило, отличаются высокой степенью интерактивности. Во многих случаях подобные программы требуют от пользователя своевременного и точного выполнения последовательностей определенных действий (виртуальные тренажеры, компьютерные игры, обучающие программы).
Адаптивность в данном случае проявляется в двух аспектах: как способность программной системы изменять алгоритм функционирования в зависимости от действий пользователя, работающего с ней, и как способность оптимально функционировать при различном аппаратном обеспечении и условиях внешней среды.
Адаптация, связанная с действиями пользователя, наиболее актуальна для приложений, применяющихся в сфере образования и подготовки специалистов, для реализации индивидуальной траектории обучения пользователя. Наиболее «сложные» интеллектуальные обучающие программы способны оценивать различные личностные характеристики пользователя, а также оценивать уровень его знаний и умений по различным показателям, что в дальнейшем позволяет им предлагать разные стратегии обучения людям с разными характерологическими чертами и способностями [1,2,3].
Способность адаптироваться под различное аппаратное обеспечение особенно важна для приложений, использующих трехмерную графику: чем ниже производительность системы, на которой осуществляется запуск программы, тем менее детализированные модели будут визуализироваться приложением.
Определенной актуальностью в данном случае обладает вопрос о «переносимости» приложения с одной программно-аппаратной платформы на другую, что обусловлено одновременным наличием у современного среднестатистического пользователя нескольких устройств, на которых можно осуществить запуск программного обеспечения. Так, начиная прохождения виртуального теста, использующего трехмерные модели, на персональном компьютере, пользователь может иметь возможность завершить его, используя портативное мобильное устройство.
Исходя из перечисленных характеристик, можно выделить следующие основные классы адаптивных программных систем на основе трехмерной графики: 1) компьютерные тренажеры и виртуальные симуляторы, 2) среды имитационного моделирования, 3) системы виртуальной реальности, 4) сложные видеоигры. Наиболее полно сфера разработки и применения адаптивных программ на основе трехмерной графики в настоящее время представлена виртуальными тренажерами. К числу тренажеров, обладающих свойствами адаптивности и трехмерности, можно отнести следующие системы:
1. «LapSim» [4] — виртуальный тренажер по эндохирургии. Обладает высокой степенью интерактивности, обеспечивает высококачественное трехмерное цифровое изображение внутренних органов, а также настройку индивидуальной программы обучения.
2. «EYESI» [5] — платформа виртуальной симуляции для отработки практических навыков интраокулярной микрохирургии. Также позволяет адаптиро вать симулятор для индивидуальных требований пользователя и объективно оценить степень подготовки обучаемого.
3. «NeuroTouch» [6] — виртуальный симулятор, предназначенный для отработки хирургических вмешательств по поводу опухолей головного мозга. Обеспечивает реалистичное моделирование биомеханики тканей, имитирует объемное трехмерное изображение, которое хирург наблюдает в микроскоп.
Помимо указанных виртуальных тренажеров, существует еще ряд достаточно востребованных в настоящее время систем подобного назначения. К ним можно отнести виртуальные симуляторы для лапароскопии «SEP SimSurgery» [7] и «Lap Mentor» [8], виртуальную гибридную операционную «ORCamp» [9], ангио-графический симулятор «CathLabVR» [10] и т. д.
Эффективность применения подобных тренажеров в сфере подготовки специалистов-медиков очевидна. В то время как получение теоретических знаний по профессии не представляет больших затруднений, приобретение практического опыта затруднено и может быть связано с риском для жизни пациентов [11]. Использование симуляционного обучения позволяет не только снизить данный риск, но и дополнить и улучшить клинические навыки у студентов. В настоящее время симуляционное обучение активно используется при подготовке специалистов в Балтийском федеральном университете имени И. Канта [12]. Проведенная в 2015 году добровольная аккредитация симуляционно-аттестационных центров показала высокий уровень развития симуляционных обучающих технологий в России [13].
Помимо медицины, виртуальные тренажеры нашли широкое применение в сфере управления техническими средствами. К такому классу тренажеров можно отнести автомобильный тренажер «ОТКВ-2М» [14], а также симулятор военной и гражданской техники «Скорпион» [15], отличительной особенностью которого является возможность моделирования различных виртуальных ситуаций при минимальных временных и финансовых затратах.
Теоретико-множественное представление общей структуры трехмерного адаптивного приложения
Описание таких сложных процессов, как изменчивость, невозможно без лежащего в основе математического аппарата. Несмотря на то, что адаптивность программных систем является в целом значительно менее подверженным влиянию посторонних факторов свойством, чем в случае с техническими системами, ее формальное определение также является достаточно непростой задачей. Для ее решения необходима разработка специализированной математической модели.
Теоретико-множественное представление общей структуры адаптивного приложения, подробно описанное в предыдущем разделе, удобно использовать для построения указанной модели. Следует выделить следующие функции, которые данная модель должна выполнять:
1) предоставлять возможность ручного и автоматического синтеза отдельных состояний работы адаптивной программы; 2) обеспечивать возможность полноценной верификации структурных решений, полученных в результате ручного или автоматического синтеза состояний работы программы;
3) обеспечивать возможность переключения между составленными пользователем или сгенерированными автоматически состояниями в процессе выполнения программы с учетом ряда показателей, характеризующих аппаратную конфигурацию устройства, на котором осуществляется запуск программы, состояние среды выполнения и действия пользователя по отношению к системе;
4) обеспечивать возможность автоматической генерации состояний не только в процессе проектирования приложения, но и в процессе выполнения с учетом показателей, приведенных в предыдущем пункте;
5) обеспечивать возможность учета обширного списка разнородных объектов, составляющих программную систему: трехмерных моделей, текстур, программных функций, переменных и т. д. (все перечисленные объекты подлежат реогранизации в процессе реализации адаптивного поведения);
6) обеспечивать свойство инвариантности к предметной области, т.е. математическое и алгоритмическое обеспечение, предложенное в работе, должно иметь широкую сферу применения;
7) обеспечивать экономность, работу в реальном времени и прозрачность для пользователя алгоритмов самоадаптации, базирующихся на предложенной модели.
Таким образом, требуемая математическая модель должна обеспечивать возможность алгоритмизации основных процессов изменчивости без перекомпиляции исходного кода. Такая модель должна настраиваться пользователем под нужды предметной области (т. е. из общей абстрактной модели преобразовываться в уточненную модель), и на основе полученной уточненной модели должна производиться настройка алгоритма, реализующего процесс адаптивного поведения системы. Свойство инвариантности к предметной области возможно обеспечить за счет корректного использования модели морфологического множества адаптивной программной системы. С учетом приведенных требований предлагается следующая математическая модель: M = (F,S,X ) , (2.3) где F — представление общей структуры приложения в форме ориентированного гиперграфа, полученного на основе диаграммы характеристик и описываемого формулой (2.1); S = {S1,S2,...,Sk} — конечное множество конфигураций диаграммы характеристик, каждая из которых является описанием определенного состояния адаптивной системы (подграфом исходного гиперграфа, определяемого формулой (2.2)); X — матрица переходов между состояниями приложения.
Таким образом, предложенная математическая модель представляет собой кортеж из трех элементов, описывающий структуру каждого состояния, входящего в состав программной системы, и связь между элементами данной структуры. Включение в математическую модель переменной F , обозначающей исходный гиперграф, обусловлено необходимостью проведения с исходными данными процедуры верификации. При помощи специального алгоритмического обеспечения, более подробно описанного в главе 3, данную модель можно впоследствии использовать для перехода от общей структуры программы, заданной морфологическим множеством всех возможных его компонентов, к конечной структуре, синтезируемой как на этапе проектирования приложения пользователем, так и впоследствии в процессе выполнения на основе имеющихся обратных связей. Итоговую структуру адаптивной программной системы, полученной в результате синтеза, можно представить в виде ориентированного графа следующим образом: D = (V,E,H) , (2.4) где V = S ={S1,S2,..,Sk }полностью соответствует переменной S в (2.3) и представляет собой множество возможных состояний адаптивной программы, каждое из которых является гиперграфом;
Алгоритм автоматического ситуационного выбора системных конфигураций в процессе выполнения
При выполнении данной диссертационной работы на этапе анализа требований к системе основное внимание уделялось выяснению того, что именно должно быть сделано. На этапе разработки следует решить вопрос, как именно реализовать решения, принятые на этапе анализа.
Сначала разрабатывается общая структура (архитектура) системы. Архитектура системы определяет ее разбиение на модули, задает контекст, в рамках которого принимаются проектные решения на дальнейших этапах разработки.
Первое, что необходимо сделать, начиная разработку системы, — определить ее разбиение на некоторое количество компонентов — модулей. Модуль — это набор классов и отдельных объектов, зависимостей, операций и ограничений, которые взаимосвязаны и имеют достаточно хорошо определенный интерфейс с другими модулями. При разбиении программной системы на модули для каждого модуля указывается реализуемая им функциональность. На рисунке 3.2 представлена архитектура предлагаемой системы. Как видно из рисунка, система состоит из двух подсистем — подсистемы разработки и подсистемы запуска. Каждая из подсистем реализует свой собственный набор модулей, но некоторые модули (например, модуль визуализации) являются общими для обеих подсистем. Основная программа координирует работу представленных модулей.
Приведем краткое описание составляющих систему модулей. В целом система разделена на следующие модули:
1. Модуль загрузки и создания интерфейсов. Основное назначение данного модуля — построение средств управления приложением. С помощью данного модуля разрабатываются как различные визуальные интерфейсы программы (формы с элементами управления), так и осуществляется закрепление вызовов пользовательских функций за кнопками клавиатуры.
2. Модуль визуального программирования. Предоставляет необходимый интерфейс для быстрого создания пользовательских функций. Возможна также загрузка функций из сторонних библиотек.
3. Модуль загрузки и создания геометрических объектов. Необходим для загрузки в проект трехмерных моделей и создания объектов-ограничителей и объектов-состояний.
4. Модуль загрузки и создания медиаданных. Необходим для загрузки в проект видео- и аудиофайлов, записи анимации. Работает с рядом наиболее рас пространенных форматов, среди которых можно выделить MP3, Wave, OGG, JPG, BMP, PNG. Для записи, хранения и воспроизведения анимационных последовательностей система использует собственный внутренний формат.
5. Модуль работы с переменными и событиями. С помощью него осуществляется объявление пользовательских переменных и создание объектов-событий.
6. Модуль компоновки ТРАП. Осуществляет сборку приложения и сохранение его в файл проекта.
7. Модуль работы с изменчивостью. Включает в себя следующие модули:
7.1. Модуль работы с моделью характеристик. Позволяет пользователю визуально проектировать общую модель характеристик, описывающую структуру программы. Также осуществляет преобразование данной модели в гиперграф.
7.2. Модуль синтеза структуры ТРАП на уровне состояний. На основе разработанной модели характеристик и полученного в результате ее преобразования гиперграфа данный модуль позволяет определить структуру и поведение приложения на отдельном этапе работы. Также с помощью задания матрицы переходов определяются взаимосвязи между состояниями.
8. Модуль визуализации сцены. Необходим для отображения основных геометрических объектов приложения. Отвечает за визуализацию как базовых (трехмерные модели) объектов, так и вспомогательных объектов сцены.
9. Модуль воспроизведения интерфейсов. Необходим для отображения и реализации функционирования разработанных пользователем интерфейсов.
10. Модуль авторизации и учета пользователей. Необходим для создания приложений, требующих для работы с ними авторизации пользователей и хранящих в персональной базе данных ряд сведений о них.
11. Модуль формирования выходных данных. Используется для создания отчетов по работе программы с конкретным пользователем. 12. Модуль воспроизведения ТРАП. Основной модуль подсистемы запуска ТРАП. Отвечает за реализацию среды выполнения приложения и включает в себя следующие модули:
13. Модуль извлечения входных данных. Необходим для загрузки проекта адаптивной программы в подсистему, корректного извлечения трехмерных моделей, медиаданных, функций и т. д.
14. Модуль исполнения ТРАП. Отвечает за запуск приложения и за его функционирование. Включает в себя также модули:
14.1. Модуль выполнения функций. Отвечает за работу созданных пользователем или загруженных из сторонних библиотек функций.
14.2. Модуль адаптивности. Координирует работу приложения на уровне состояний. Отвечает за работу с матрицей переходов, параметрический синтез и расчет специальных коэффициентов.
В совокупности приведенные модули полностью реализуют требуемую функциональность предлагаемой системы. В последующих разделах приведено описание наиболее важных с точки зрения требуемого функционирования системы модулей.
На рисунке 3.3 представлена функциональная схема модуля работы с изменчивостью. Данная схема отражает разбиение описываемого модуля на два подмодуля — модуля работы с моделью характеристик и модуля синтеза структуры адаптивной программы. Также схема описывает всю функциональность, реализуемую этими модулями. Разработка линии адаптивного поведения программы осуществляется в следующие этапы: 1. Создание пользователем объектной иерархии программной систему, загрузка соответствующих объектов в проект. 2. Построение общей диаграммы характеристик на основе загруженных объектов. 3. Преобразование полученной диаграммы характеристик в гиперграф.
Альтернативный вариант представления диаграммы характеристик
Для полноценного тестирования системы необходимо разработать пример, который в полной мере использовал бы функциональные возможности системы, но который в то же время был бы достаточно компактным для возможности наглядного описания в тексте диссертационной работы.
В качестве такого примера была выбрана реализация специальной методики для диагностирования наглядно-действенного интеллекта «Кубики Коса» [125].
Оригинальный вариант тестирования Коса состоит из 16 равных по своему размеру кубиков с гранями различных цветов. В каждом наборе для тестирования имеются также карточки с узорами, упорядоченные по уровню сложности. Испытуемому предлагается сложить кубики таким образом, чтобы рисунок на верхней поверхности кубиков в точности соответствовал узору на карточке.
Задания следуют в порядке возрастающей трудности, это обеспечивается последовательностью выполнения следующих условий: 1. Построение фигуры возможно только из одноцветных сторон кубиков. 2. Для построения следует использовать несколько двухцветных граней. 3. Фигуру можно сложить только из двухцветных сторон или из сочетания двухцветных и одноцветных. 4. Образец повернут на 45 (стоит на ребре). 5. Для составления фигур необходимо использовать с каждым разом все большее количество кубиков. 6. Образцы постепенно становятся менее симметричными. 7. Увеличивается количество цветов на образце. 8. Образец не ограничивается рамкой, поэтому на краях сливается с фоном. Образцы-рисунки предъявляются испытуемому в определенной очередно сти, тестирование прекращается после пятого неудачного решения.
В отличие от оригинальной методики Коса, предполагающей использование заранее определенных заданий (узоров), разрабатываемое приложение предполагает генерацию оригинального узора на каждом этапе собственной работы.
При анализе структуры приложения, реализующего данную методику, можно выделить следующие объекты приложения, затрагиваемые изменчивостью:
1. Текстуры кубиков. Чем более высокий уровень сложности достигается пользователем в процессе работы с приложением, тем более разнородной делается текстура отдельного кубика; упрощенные текстуры заменяются на более сложные аналоги, включающие большее количество цветов, появляются также дополнительные текстуры.
2. Сложность узора на карточке с заданием. При повышении уровня сложности ТРАП более сложными и разнородными становятся также и задания, предлагаемые пользователю. Реализация данного типа изменчивости сводится к выбору функции, генерирующей описание узора.
3. Количество задействованных при составлении узора кубиков, т.е. размерность рабочего поля. Чем выше уровень сложности, тем большее количество элементов будет задействовано при автоматическом составлении тестового задания.
4. Дополнительные ограничения, в число которых входят, например, ограничения на тип используемых граней.
Первым этапом в проектировании данного приложения будет разработка пошаговой логики приложения и выделение основных типов составляющих его объектов.
Рассматриваемое приложение включает в себя следующие основные типы объектов:
1. Трехмерные модели. Разрабатываемая программа имеет простую модельную структуру: для того, чтобы реализовать задуманную функциональность, достаточно трех базовых моделей — модели кубика, модели рабочего стола и модели подставки под кубик.
2. Текстуры. Разрабатываемое приложение будет включать в себя текстуры трех различных типов.
3. Объекты-ограничители. Контейнеры в трехмерном пространстве, необходимые для осуществления проверки на то, находится ли трехмерный объект (в данном случае кубик) в необходимой области сцены. Для реализации задуманного необходимо описать ограничитель одного типа, копии которого будут создаваться в дальнейшем для реализации массовых проверок.
4. Объекты-состояния. Также необходимы для определения того, нужным ли образом расположена трехмерная модель (кубик) в пространстве. В отличие от объекта-ограничителя, с помощью которого производится проверка на то, в нужной ли области сцены расположена модель, используются для определения того, повернут ли объект на необходимый угол относительно собственной системы координат. Так как узор складывается из граней кубиков, «смотрящих вверх», необходимо задать шесть соответствующих объектов-состояний (в соответствии с общим числом граней).
5. Основная программная функция. Так как все шаги работы приложения достаточно однотипны, в данном случае не будет иметь альтернатив. Данная функция будет иметь различные уровни детализации, что обусловлено необходимостью выбора различных алгоритмов генерации узора. Более подробно логика работы данной функции будет расписана далее.
6. Дополнительные переменные. К числу таких параметров относятся количество используемых кубиков и параметр, отвечающий за накладываемые ограничения.
7. Таймер. Необходим для учета времени, которое пользователь затрачивает на выполнение каждого задания, и расчете на его основе коэффициента t.
8. Двумерные изображения, каждое из которых соответствует определенному объекту-состоянию. Речь идет об отдельных элементах текстур, соответствующих граням кубика. Данные объекты используются в последующем в интерфейсе, отображающем узор, который должен собрать из кубиков пользователь.
9. Ряд дополнительных интерфейсов, в частности, интерфейс визуализации тестового задания (узора).
Непосредственную разработку приложения с помощью системы следует начинать с загрузки необходимых моделей и текстур, написания и загрузки из сторонних библиотек функций, создания дополнительных геометрических объектов. На рисунке 4.9 изображено окно просмотра основных объектов трехмерной сцены, которое также является основным окном подсистемы создания приложения. Можно видеть основные трехмерные модели, входящие в структуру программы, а также созданный объект-ограничитель. Объекты-состояния не имеют специфического образа визуализации — для того, чтобы просмотреть, как будет выглядеть трехмерный объект в том или ином состоянии, необходимо выбрать состояние из дерева объектов и выбрать пункт «Просмотреть состояние» в выпадающем меню. После данного действия трехмерная модель, связанная с выбранным состоянием, повернется на необходимое число градусов относительно начального положения.