Система сборки и автоматической генерации
программ визуализации для численного
моделирования.

Кукшева Э.А.

Абстракт

В настоящее время у пользователя имеется уже большой выбор различного программного обеспечения для решения различных задач. Хотелось бы заострить внимание на одном очень большом недостатке большинства современных программ - они слишком избыточны. Из-за этого они требуют огромных ресурсов, работа с ними становится сложной, и пользователь, зачастую, просто не может добиться от такой программы того чего он хочет. Производители программного обеспечения стремятся создать максимально универсальные программы, чтобы удовлетворить нужды как можно большего числа пользователей. Но реальному пользователю, как правило, не нужны все эти возможности, да он о многих из них и не подозревает. В конечном счете, универсальность начинает мешать работе пользователя. Конечно, специализированная программа была бы более эффективна, но где взять достаточное количество специализированных программ? И какие они должны быть. Ответ затруднителен. Поэтому, нет пока что достойной альтернативы универсальным программам.

Обычно для разработки программы программист пользуется каким-то языком программирования (например, С/C++, Java, Fortran и т. д.) и, обычно, какими-то библиотечными функциями (например, математической библиотекой или любой другой). Назовем, операторы и функции, из которых создается программа атомарными фрагментами программы, а последовательность атомарных фрагментов пусть будет просто фрагмент. Любой опытный программист, который работает в своей области достаточно долгое время, имеет какие-то готовые части программ (заготовки) √ собственную библиотеку фрагментов программ. И когда ему приходится писать очередную программу, он не пишет ее с нуля, а берет свои заготовки, как-то по новому их компанует, возможно, дописывает что-то, чего у него в запасе нет. Эти заготовки назовем √ блоками. Предположим, что человек накопил столько блоков, что может в своей области написать программу, подавляющая часть которой состоит из заготовок. Тогда получается, что практически, атомарным фрагментом программы можно считать не операторы языка и функции, а готовые блоки. То есть, произошло увеличение атомарного фрагмента программы за счет уменьшения его универсальности. Создание программы из готовых блоков/модулей назовем сборочным программированием (или просто сборка). Блок √ это атомарный фрагмент сборки. В данной работе мы хотим уделить внимание в основном исследованию самого процесса сборки.

Идею сборочного программирования можно применять во многих областях: текстовые редакторы, графические редакторы, электронные таблицы и т. д. Наша предметная область √ сборка и автоматическая генерация программ визуализации в численном моделировании. Под визуализацией мы подразумеваем интерфейсную программу, позволяющую пользователю просматривать свои данные в графическом виде. А так же, манипулировать данными: строить срезы, вырезать кусочки данных, сохранять их, печатать и т. д. В нашем случае, эти программы должны быть в первую очередь приспособлены для работы с данными, полученными численными методами. Назовем атомарный фрагмент сборки в области визуализации √ атомарным визуальным фрагментом. Так как мы говорим о визуализации, то конечно, должны быть атомарные визуальные образы, связанные с графическим представлением данных √ это графики, шкалы, изолинии и т.д. Для того чтобы работать с данными, преобразовывать форматы, вырезать данные, делать обработку данных (например, логарифмирование или Фурье), должны существовать так же фрагменты работы с данными. И конечно, так как мы собираем интерфейсную программу, в распоряжении пользователя должны существовать элементы графического пользовательского интерфейса (GUI). Чтобы сборочная технология максимально раскрыла свои возможности для увеличения производительности разработки программ, сборку нужно производить визуально. Это вполне органично, создавать интерфейсную программу визуализации тоже визуально. Сборка делится на три основных этапа. Первый этап: пользователь собирает визуальный образ будущей программы из визуальных фрагментов. Визуальный образ можно условно назвать эскизом √ внешний вид программы визуализации. На данном этапе расставляются окна с графиками, кнопочки, поля ввода и т.д. Второй этап - связывание фрагментов действиями. Теперь надо добавить реакции на кнопочки, обеспечить работу с данными и т.д. Например, нажали на кнопку ⌠Открыть■, и появляется окно выбора файла.В конце, когда компановка визуального образа и связывание фрагментов закончено, генерируется код этой программы на процедурном языке и, откомпилировав его, мы получаем готовую к выполнению программу визуализации. Это последний, третий этап сборки. Систему, с помощью которой будет выполняться сборка и генерация визуализации, назовем системой визуальной сборки и автоматической генерации программ визуализации.

Опишем общую схему работы этой системы:

Рис. 1

Это система, в которой есть база данных атомарных визуальных фрагментов с возможностью добавления в нее новых элементов. Каждому фрагменту соответствует иконка, все иконки классифицированы и доступны выбору пользователя простым кликом мышки. С помощью компоузера пользователь собирает визуальный образ будущей программы визуализации из этих фрагментов. Выбирает нужные фрагменты из базы данных, расставляет окошки (визуально), кнопочки, графики и т.д. Редактор связей предназначен для создания связей между фрагментами. Редактор свойств позволяет определять свойства фрагментов. Типичный пример свойства √ это цвет фона. Если мы не работали с редактором свойств, то значения свойств устанавливаются по умолчанию. При этом существует промежуточное представление собираемой программы, в котором фиксируются все действия пользователя. Оно может быть сохранено в файле, с тем чтобы, в последующем, продолжить сборку. Из промежуточного представления можно сгенерировать код программы на процедурном языке и откомпилировать ее в готовую к выполнению программу визуализации. Все описанные элементы составляют основу большой интерфейсной программы под названием ⌠Система визуальной сборки и автоматической генерации программ визуализации■. Собрав однажды визуализацию, пользователь всегда может вернуться к ней (если сохранился файл с промежуточным представлением): добавить или убрать какие-то возможности и перекомпилировать ее. Естественно, подобная система будет довольно объемной, но она не будет использоваться повседневно и на каждом рабочем месте. Зато пользователь сможет собрать именно такую программу, которая необходима в данный момент и чтобы она была понятной для него.

Простой пример.

Предположим, что нам нужна небольшая программка для просмотра графиков изолиний для функции двух переменных. Входные данные представлены списком текстовых файлов. Каждый файл содержит табличное представление функции двух переменных:

X

Y

Z = f(X,Y)

x1

y1

Z1

x2

y2

Z2

...

...

...

Сначала нужно решить, какие функциональные возможности и какой интерфейс должна иметь наша визуализация. Допустим, мы хотим, чтобы была возможность видеть имена файлов с данными и, выделяя нужное имя файла курсором, рядом видеть, соответствующий график Ниже приведен эскиз будущего визуального образа:

Рис. 2

Чтобы собрать такую программу визуализации нужно три фрагмента сборки:

  1. Окно выбора директории и файла (слева на рисунке 2). В этом окне можно курсором мыши выбрать директорию и файл.
  2. Атомарный фрагмент рисующий изолинии (справа на рисунке 2).
  3. Атомарный фрагмент, открывающий файл и читающий из него данные представленные тремя колонками, как показано выше.

Представим схему процесса сборки рисунком.

Рис. 3

Пояснение к схеме.

База данных атомарных фрагментов представлена здесь списком, разделенным на четыре типа :

Показано, к каким типам относятся выбранные нами фрагменты, а также пример иконок, которые могут соответственным фрагментам. Для сборки визуального образа будущей программы пользователь выбирает сначала, например, иконку ⌠Выбор файла■ и располагает данное окно слева. Затем выбирает ⌠Изолинии■ и располагает окно справа, так как он хочет чтобы они выглядели в конечной программе. И, наконец, выбирается ⌠Чтение файла■. Здесь он расположен посередине. На самом деле это не важно, так как в конечной программе его не будет видно. На любом этапе сборке можно сохранить визуальный образ в файле промежуточного представления. С помощью редактора связей мы соединяем выходную информацию одного фрагмента с входной информацией другого.

На рисунке ниже показаны входные и выходные данные всех трех фрагментов:

Рис. 4

Теперь при выборе пользователем имени файла, он будет открываться, из него будут считываться данные, и эти данные будут представлены в виде изолиний.

После создания связей остается только запустить генератор, чтобы он сгенерировал программу на процедурном языке, а затем и откомпилировать ее в готовую к выполнению.

Конкретная реализация.

В настоящий момент данная разработка реализуется на языке С++ с помощью библиотеки графического пользовательского интерфейса Qt . Базовой платформой является Unix, хотя Qt позволяет перенос программ и под Windows. Сейчас основное внимание уделяется разработке атомарных фрагментов. В первую очередь нас волновал вопрос, возможен ли вообще данный подход. Разработано именно такое строение фрагмента, чтобы описанная выше схема сборки была реализуема. Также было уделено внимание процессу сборки, особенно созданию связей. Так как разработка собственного компоузера требует значительной затраты времени, использовался стандартный компоузер, поставляемы с Qt. Аналогично дело обстоит с генератором. Мы не ставим целью сейчас разработать эффективный генератор, поэтому используем генератор Qt. Пример, описанный выше, реально был получен сборкой.