CC BY
32
Сервер Клиент ВМК
Сервер модели активной подводной лодки
Клиент модели активного ГАК
АРМО ГАК
Клиент ВМК
Клиент модели активной подводной лодки
Сервер модели активного ГАК
Рис. 2
чительно увеличивает объем работ, однако дает большие преимущества. Как правило, к адекватности моделирования активного объекта предъявляются более высокие требования по сравнению с моделированием пассивного объекта. Повышение адекватности моделирования требует большей производительности вычислительных ресурсов. Благодаря разделению крупных моделей на более мелкие их серверы могут располагаться на от-
дельных узлах сети. На рисунке 2 показано отделение модели активного гидроакустического комплекса (ГАК) от модели активного объекта подводной лодки. Естественно, модель подводной лодки не содержит в себе никакой реализации имитатора ГАК.
Разделение на отдельные модели дает дополнительную гибкость в написании более крупных обобщающих моделей. Появляется возможность модификации моделей отдельных систем без изменения других компонентов.
Соединение двух и более тренажных комплексов, разработанных по рассмотренной технологии, не будет требовать никаких затрат, при этом возможно адекватное моделирование самых различных объектов.
Список литературы
1. Башмаков А.И., Башмаков И.А. Разработка компьютерных учебников и обучающих программ. - М.: Филинъ, 2003.
2. Бичаев Б.П. Морские тренажеры (Структуры, модели, обучение). - Л.: Судостроение, 1986. - 383 с.
АРМО 1
АРМО N
ОПТИМИЗИРУЮЩИЕ СТРАТЕГИИ ВИЗУАЛИЗАЦИИ ДАННЫХ В ТАКТИЧЕСКОМ ТРЕНАЖЕРЕ
И.В. Новиков; А.И. Егоров (НИИ «Центрпрограммсистем», г. Тверь, [email protected])
Ключевые слова: тактический тренажер, визуализация данных,
В современном тактическом тренажере одним из основных компонентов является пост руководства обучением (ПРО). Помимо основополагающих функций, ПРО выполняет задачи визуализации результатов имитационного процесса. При проектировании подобного рода компонентов возникают проблемы, связанные с пошаговым моделированием имитационного процесса, в частности, с временными затратами на визуализацию, которые не должны превышать шаг моделирования (дискретизации). Как следствие, возникает необходимость создания единой системы визуализации данных, учитывающей аспекты дискретизации.
Для эффективной визуализации ПРО в НИИ «Центрпрограммсистем» (г. Тверь) разрабатывается компонентно-ориентированная библиотека пользовательского интерфейса - IML UI (Interface modeling library for User Interface).
В концепции компонентной модели ПРО каждый моделируемый объект тактической обстановки может предоставлять пользовательский интерфейс, который характеризуется множеством элементов управления (ЭУ). Каждый ЭУ в IML UI определяется набором атрибутов (позиция, имя, идентификатор, текст, пользовательские данные) и совершаемых над ним операций. ЭУ образуют
льзовательский интерфейс, паттерн «стратегия».
иерархию (дерево): каждый ЭУ создается в некотором другом элементе, называемом родительским. Взаимодействие между моделями тактического тренажера и ЭУ осуществляется путем последовательного выполнения предопределенных операций. Множество таких операций выполняются синхронно в каждый момент с определенным шагом. Эффективная реализация этих операций может существенно повысить производительность ПРО.
Рассмотрим основные операции, производимые над ЭУ, то есть определим интерфейс взаимодействия. Помимо базовых операций (получение интерфейсов, модификация основных атрибутов), введем дополнительные, список которых вместе с соответствующим методом программного интерфейса выглядит следующим образом:
1) вычисление (оценка) размера ЭУ - Esti-mateSize;
2) обновление расположения дочерних элементов - UpdateLayout;
3) обновление части экрана (прямоугольника) - InvalidateCtrl;
4) рисование ЭУ на физическом устройстве -DoPaint;
5) поиск в дереве ЭУ по заданным значениям атрибутов - ГМСоп^о1.
Кроме того, введем операции над контейнерными (содержащими дочерние элементы) ЭУ:
6) добавление элемента - AddItem;
7) получение элементов по индексу - GetItem;
8) получение количества дочерних элементов - GetItemCount;
9) удаление элементов из контейнера - Re-moveItem и RemoveAll.
Каждый разрабатываемый ЭУ реализует базовые операции и при необходимости предоставляет дополнительные операции, оформленные по правилам 1МЬ в виде программного интерфейса.
Многие ЭУ имеют алгоритмически сложную реализацию рассмотренных операций (1-9), поэтому проектирование классов модуля 1МЬ Ш основано на стратегиях [1], что позволяет создавать новые классы ЭУ со сложным поведением, используя множество небольших объектов (называемых стратегиями), каждый из которых отвечает только за один функциональный или структурный аспект (рис. 1). Функциональный аспект затрагивает определенный набор операций 1-9. Стратегии можно реализовывать по-разному, поскольку их интерфейсы полностью находятся в компетенции разработчика.
Реализация элемента управления
Атрибуты ЭУ
Операции над элементом управления EstimateSize UpdateLayout InvalidateCtrlDoPaint FindControl
Стратегии выполнения double buffer strategy
frame buffer strategy
Рис. 1. Реализация элемента управления на основе стратегий
Особое внимание следует уделить операциям 1 и 2, которые выполняются при изменении размеров окна, так как технология динамического позиционирования ЭУ (dynamic layout) является неотъемлемой частью модуля IML UI. Необходимость разработки оптимизирующих стратегий обусловлена ресурсоемкостью этих операций. Рассмотрим стратегии рисования и стратегии обновления ЭУ при модификации данных.
Опишем возможные стратегии отрисовки ЭУ (реализация операций 1-4). Процесс начинается с того момента, как ОС Windows пошлет активному окну сообщение о необходимости перерисовки. Затем процедура обработки очереди сообщений (window proc) делегирует обработку сообщения объекту типа «стратегия рисования», который в свою очередь совершит операцию рисования DoPaint обходом дерева ЭУ в глубину. Для того чтобы предотвратить мерцание изображения на экране (image flickering), часто применяется техника двойной буферизации (double buffering) [2].
Данная техника требует дополнительного изображения в памяти, максимальный размер которого может достигать размера экрана. При хорошем разрешении (1 600x1 200 с глубиной цвета 32 бита) размер изображения будет превышать 7,5 Мб. Следовательно, техника дает преимущества только для небольших областей экрана, причем контролируемого размера.
Правильно подобранная стратегия помогает избежать перерасхода ресурсов памяти. Если контейнерный ЭУ нарисован на растровой области в памяти, то все его дочерние элементы тоже будут использовать этот разделяемый буфер. К тому же данный подход не требует операций очистки фона, так как эту процедуру автоматически могут выполнять контейнеры элементов непосредственно при рисовании, подготовив фон для своих дочерних элементов. Оптимизация на уровне ресурсов осуществляется сокращением количества используемых в каждый момент объектов ОС, таких как дескрипторы окон, контексты устройств и т.д. При возможности ресурсы ОС кэшируются объектом «стратегия», тем самым сокращая количество системных вызовов, эффективно применяя парадигмы «не создан, пока не востребован» и «освобожден только после выполнения всех операций» с помощью механизма подсчета ссылок [1].
При этом другая реализация поведения объекта «стратегия» может использовать или рисование напрямую на экран, или аппаратные возможности видеоконтроллера. Скажем, для отображения динамически изменяемого во времени процесса в системе имитационного моделирования возможна реализация стратегии рисования, использующая буфер кадров дисплея (display frame buffer).
В силу того что выбор стратегий зависит не только от типа и параметров ЭУ, в рамках IML UI реализован комплексный механизм выбора оптимизирующей стратегии визуализации, который после оценки значения атрибутов ЭУ (ширина, высота, частота обновления) принимает решение в зависимости от представленных на компьютере аппаратных средств.
Проектирование на основе стратегий может эффективно применяться и при создании контейнерных ЭУ (операции 6-9). Пользователь рассчитывает на то, что после добавления очередного элемента в контейнер происходит его обновление, то есть последовательное выполнение операций 2-4. Однако при добавлении целого множества из N элементов управления в одном цикле будет совершено N операций обновления, хотя требуется только одна. Разработка на основе стратегий позволяет выбрать политику обновления ЭУ при модификации данных.
В качестве примера возьмем элемент управления «Список» (ListControl), который является контейнерным, так как содержит дочерние компоненты - элементы списка. По умолчанию при добав-
лении очередного элемента в список генерируется событие перерисовки (аналогично в стандартных списках Windows). Предположим, нам необходимо каждую секунду добавлять 1 000 строк в список. В первом приближении можно организовать следующий цикл для объекта list (используется синтаксис в стиле C++ с учетом введенных операций, вызываемых через точку), выполняющий последовательно 1 000 операций:
for(i=0; i<1000; i++) {
list.AddItem(...);
}
Предполагая, что операция добавления элемента обновляет список, с ростом количества элементов в списке будет увеличиваться время выполнения всей задачи, в лучшем случае по линейному закону. Оптимизация заключается в достижении константного времени выполнения задачи. Для решения необходимо определить множественные (или групповые) операции как атомарные и не выполнять обновление элемента до окончания выполнения последней (1 000-й) операции. Чтобы сделать групповую операцию атомарной, введем 2 дополнительные операции над ЭУ: операцию перехода в режим модификации данных -BeginUpdate и операцию выхода из режима модификации данных - EndUpdate.
Выберем следующую простую стратегию обновления списка на основе блокировок (lock strategy). Сохраним счетчик выполняемых операций, начальное значение которого равно нулю (lock=0). При очередном вызове BeginUpdate счетчик ссылок увеличивается, а семантика операции EndUpdate будет следующей: если счетчик операций равен 0, то выполняем последовательно операции 2 и 3 (UpdateLayout и InvalidateCtrl). Выбранная стратегия реализует механизм отложенного выполнения операций обновления. Обновление происходит только после завершения последней операции EndUpdate. // lock=0
list.BeginUpdate( lockStrategy ); // lock=1 for(i=0; i<1000; i++) {
list.AddItem(...); // обновление не происходит, так как
lock>0 }
list.EndUpdate(); // lock=0
Таким образом определена пользовательская операция добавления 1 000 элементов на основе стратегии со счетчиком обновлений в виде отдельной функции, в теле которой будут выполнены операции 1 и 2 всего один раз против тысячи. В зависимости от реализации списка получим различное время выполнения. Вычислительные эксперименты по оценке времени одной из реализаций списка представлены в таблице. При этом в результате применения оптимизирующей стратегии время на решение задачи было сокращено в 25 раз. Следует обратить внимание, что уже на пятой секунде время выполнения последовательных
операций с обновлением превысило 1 секунду. Тем самым добавление очередной порции элементов на шестой секунде значительно превысит допустимое время выполнения, что может привести к снижению общей производительности. Таким образом, в системах моделирования, где критичным параметром становится время выполнения всех операций, выбор оптимизирующей стратегии является решающим фактором, определяющим эффективность визуализации.
Сравнительная оценка времени выполнения операций
Время, Выполнение Выполнение Количество
с операции групповой элементов
последовательно, мс операции, мс в списке
0 - - 0
1 288 26 1000
2 413 26 2000
3 629 26 3000
4 851 26 4000
5 1073 26 5000
Общее 3254 130 5000
Получив необходимый результат для отдельного ЭУ, последовательно сгруппируем операции обновления для достижения константного времени обновления экрана целиком (рис. 2).
Групповая операция обновления
Операция обновления 1
Операция обновления 2
Рис. 2. Стратегия группировки операций обновления экрана ПРО
Подобная оптимизирующая стратегия может быть разработана в силу того, что в контексте обновления можно выполнять поочередно операции, модифицирующие данные, представленные в ЭУ.
Развитие предлагаемых стратегий выполнения операций над ЭУ позволяет решить проблему со снижением производительности тактического тренажера при увеличении количества отображаемых визуальных компонентов. Достижение необходимой производительности заключается в достижении постоянного времени обновления, а далее - в сокращении времени выполнения операций над ЭУ до показателя, много меньшего шага моделирования.
Список литературы
1. Andrei Alexandrescu. Modern C++ Design: Generic Programming and Design Patterns Applied. - Addison Wesley, 2001.
2. Jonathan Knudsen. Java 2D Graphics. - O'Reilly, 1999.
