Акименко Ирина Геннадьевна

Email: akimika@front.ru

Донецкий национальный технический университет
факультет: Вычислительной техники и информатики
cпециальность "Программное обеспечение автоматизированных систем"

  Тема диссертации "Система ввода и отображения графических данных для визуализации механических узлов в реальном времени"
Руководитель: проф., доктор технических наук Башков Евгений Александрович

Объектно-ориентированная методология разработки интегрированных приложений моделирования и визуализации

В статье описывается объектно-ориентированная методология построения интегрированных приложении моделирования и визуализации в различных предметных областях на единой концептуальной, инструментальной и программной основе. Разрабатываемые приложения имеют общую открытую архитектуру, которая включает объектно-ориентированное ядро, инвариантное по отношению к различным областям и проблемам, унифицированный графический интерфейс пользователя и специализированные прикладные библиотеки классов. Объектно-ориентированное ядро поддерживает представление итоговой графической сцены в виде композиции связанных типизированных данных и алгоритмов и реализует общие механизмы составления сценариев работы приложений и их интерпретации. Функциональность приложений определяется главным образом полнотой подключенных прикладных библиотек и семантикой их классов.

1. Введение

В настоящее время компьютерные средства математического моделирования и визуализации научных расчетов получили широкое распространение и составляют неотъемлемую часть современных систем автоматизированного моделирования и проектирования (CAD/CAM/CAE). Разработка таких систем, сочетающих широкую предметную функциональность с развитыми графическими интерактивными вычислительными средствами, обычно требует чрезвычайно высоких затрат и сопряжена с решением целого круга проблем, включающего архитектурное проектирование, интеграцию функционально разнородных компонентов, организацию дружественного пользовательского интерфейса, обеспечение открытости, переносимости, эффективное использование на параллельных вычислительных системах.

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

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

• наличие унифицированного программного ядра, инвариантного но отношению к различным предметным областям, прикладным задачам моделирования и визуализации, применяемым аппаратным платформам;
• модульная организация или, другими словами, возможность построения конкретной прикладной системы из отдельного набора модулей, семантика которых соответствует сущностям рассматриваемой предметной области, способам их представления, программной реализации и, в конечном счете, определяет функциональность всей системы;
• обеспечение гибкой дисциплины связывания экземпляров модулей с целью составления и применения различных сценариев конструирования и функционирования сложных композиционных сцен;
• обеспечение механизмов обобщенной реализации модулей, при которой включаемые в систему новые модули могут взаимодействовать с имеющимися без строгой конкретизации контекста использования, а создание новых модулей может осуществляться на основе разработанных ранее;
• программная реализация модулей на основе современных информационных, графических, коммуникационных стандартов, с использованием, в частности, стандарта представления геометрии (STEP) [1], языка описания сцен виртуальной реальности (VRML) [2], графической библиотеки растеризации изображений (OpenGL) [З], интерфейса распределенных приложений (MPI) [4].

Использование объектно-ориентированного подхода для построения прикладных программных систем в соответствии с вышеперечисленными принципами имеет ключевое значение, поскольку предусматриваемые им механизмы инкапсуляции, наследования и полиморфизма могут быть конструктивно применены как при реализации унифицированного ядра, так и при разработке прикладных библиотек классов [5, 6].

Настоящая работа преследует цель представить объектно-ориентированную методологию создания интегрированных приложений математического моделирования и научной визуализации, опирающуюся на оригинальную открытую модульную архитектуру. В разделе 2 проводится объектный анализ н описывается ядро приложений. Раздел 3 посвящен некоторым аспектам унифицированной разработки интегрированных приложений с использованием данного ядра.

2. Объектно-ориентированное ядро для моделирования и визуализации

Будем рассматривать итоговую графическую сцену приложения как композицию связанных типизированных данных, участвующих во всех процессах данного приложения, включая моделирование, визуализацию и растеризацию, а также алгоритмов, создающих, преобразующих, удаляющих эти данные и реализующих упомянутые выше процессы. Будем различать пассивные объекты-данные, которые контролируют только собственное поведение, и активные объекты-алгоритмы, которые могут управлять поведением других объектов в результате рассылки им сообщений в классическом объектно-ориентированном стиле. Создание итоговой сцены подразумевает определение экземпляров классов данных и алгоритмов, установление связей между ними, составление сценария из отдельных объектов данных и алгоритмов и его интерпретации. Подобный подход, основанный на подразделении объектов на активные и пассивные, отражает основную идею методологии Бэйлина, известную как объектно-ориентированная спецификация требований [7], и успешно зарекомендовал себя при создании приложений вычислительной математики [6].

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

Базовым абстрактным классом ядра является класс Object, который выражает сущность произвольных данных и алгоритмов, участвующих в моделировании и визуализации. Объекты могут вводиться, конструироваться, связываться друг с другом, преобразовываться, запоминаться, визуализироваться, копироваться и уничтожаться в ходе работы приложения. Для единообразного манипулирования различными типами объектов и обеспечения функциональности ядра класс Object инкапсулирует идентификатор, номер версии н свое логическое местоположение в сцене (будет рассмотрено позже). Этими атрибутами обладают все объекты сцены, классы которых являются производными от Object.

Помимо общих атрибутов каждый конкретный объект obj Object имеет свой собственный набор атрибутов, определяющий его внутреннее состояние и поведение, а также набор типизированных соединений. Соединения являются внешними портами объектов, посредством которых они могут быть связаны с другими подобными объектами. Тип конкретного соединения Link Object определяет потенциальную возможность связи данного объекта с любым другим объектом lobj LinkObject, тип которого удовлетворяет типу соединения или, другими словами, является его подтипом LinkObject Link.

Наличие связей в сцене характеризует функциональную зависимость ее объектов и, следовательно, необходимость их совместного рассмотрения и анализа. Каждая установленная связь определяет отношения использования главным объектом других вспомогательных объектов, с которыми он связан. Будем различать одиночные и множественные связи. Одиночная связь определяет отношение использования между нарой объектов, рассматриваемых как основной и вспомогательный. Множественная связь используется в тех случаях, когда основной объект находится во взаимодействии с подмножеством однотипных вспомогательных объектов через одно соединение lobj_i Link0bject_i Link, i = 1,...,n. Число объектов n, объединенных множественной связью, является произвольным и зависит только от конкретного сценария, реализуемого в приложении.

Для различия способов, с помощью которых объекты взаимодействуют между собой, вес соединения и соответствующие им связи подразделяются на входные, выходные и смешанные. Участвуя в связях, основной объект использует данные и методы вспомогательных объектов и, следовательно, может изменять состояния связанных с ним объектов. Предполагается, что основной объект способен изменять состояния вспомогательных объектов через выходные и смешанные связи, и неспособен влиять па состояние входных объектов. Основной объект зависит только от входных и смешанных объектов и не зависит от выходных объектов. Основной и вспомогательные объекты, включенные в смешанную связь, являются взаимозависимыми. Таким образом, могут быть установлены описанные отношения зависимости, основанные на классификации соединений взаимодействующих объектов.

Инкапсулируя описанные выше свойства, класс Object определяет следующие группы методов, общие для всех его конкретных экземпляров:

• создание (конструирование, уничтожение, копирование, чтение из файла, вывод в файл),
• идентификация (идентификация объекта, его класса, базового класса, версии, верификация принадлежности к заданному типу),
• взаимосвязывание (получение количества соединений, их классов и типов, связывание объектов),
• получение информации о сцепе (получение параметров сцены, логическое упорядочивание объектов в сцене).

Основными понятиями ядра являются также объекты-данные dat Data Object и объекты-алгоритмы alg Algorithm Object. Абстрактные классы Data, Algorithm являются производными от Object и наследуют его свойства и поведение. Класс Data выражает сущность разнообразных научных данных, возникающих в приложениях моделирования и визуализации. Объекты-данные являются пассивными объектами, контролирующими только собственное поведение, и поэтому могут иметь только входы. Класс Algorithm представляет различные алгоритмы, преобразования, операции и вспомогательные утилиты, реализующие все процессы в приложениях моделирования и визуализации. Алгоритмы являются активными объектами, контролирующими не только собственное поведение, но и поведение связанных с ними вспомогательных объектов (не обязательно данных). Алгоритмы могут не иметь входов, но обязательно имеют выходные и/или смешанные соединения.

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

На рисунке 1 представлен пример взаимодействия объектов. Данный пример иллюстрирует, каким образом данные и алгоритмы могут связываться и взаимодействовать через типизированные соединения. Иерархия классов определяет отношения наследования между классами данных и алгоритмов. Диаграмма сцены полностью определяет схему связывания и характер взаимодействия объектов. В диаграмме экземпляры данных и алгоритмов показаны, соответственно, как овалы и прямоугольники. Соединения объектов промаркированы точками. Связи между объектами показаны стрелками. Подобная схема может быть представлена в терминах объектно-ориентированной методологии с использованием нотации Буча [8]. Для иллюстративности па рисунке 2 представлены диаграммы классов и объектов в нотации Буча для рассмотренного примера.

Рис. 1. Иерархия классов и схема связывания и взаимодействия объектов

Согласно диаграмме сцены, данные dat1, dat2, dat3 связаны с алгоритмом alg через входные соединения. Множественное соединение link1 типа Data1 обеспечивает одновременную связь с dat1, dat2, удовлетворяющими его типу. Единственный объект dat3 связан через простое соединение link2 типа Data3. Аналогичным образом объекты dat4, dat5 связываются через смешанное соединение link3 и выходное соединение link4. После активизации алгоритм alg обменивается сообщениями с dat1, dat2, dat3, dat4, приводя к конструированию выходного объекта dat5 и обновлению dat4.

Отметим, что принятый способ направления стрелок соответствует потокам данных в сценарии. Это обстоятельство выявляет схожесть с традиционной диаграммой потока данных, широко используемой в системах визуализации и анимации. Однако рассматриваемая диаграмма сценария выражает более общую парадигму "сущности-связи", которая, на наш взгляд, является более предпочтительной вследствие возможностей задания более сложных типов взаимодействия объектов. Задача моделирования и визуализации аттрактора, обсуждаемая ниже, дает пример взаимодействия объектов, которое не может быть представлено парадигмой потоков данных, но может быть специфицировано непосредственно в терминах нашего подхода.

Рис. 2. Диаграммы классов и объектов в нотации Буча

Наконец, класс Scene является контейнерным классом, поддерживающим упорядоченное представление (композицию) всех объектов данных и алгоритмов, включенных в сцену, и обеспечивающим широкую функциональность, необходимую для разрабатываемых приложений. Конструирование результирующей сцены осуществляется в результате непосредственного манипулирования ее объектами и активизации конвейера, составленного из ее отдельных алгоритмов. Алгоритмы конвейера сцены предварительно упорядочиваются и затем активизируются для решения частных задач моделирования и визуализации. В ходе выполнения алгоритмов объекты сцены взаимодействуют друг с другом, что приводит к созданию новых объектов и обновлению уже существующих.

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

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

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

• создание (регистрация класса объекта, создание объекта данного класса, обновление версии объекта, копирование, удаление);
• идентификация (получение объекта по его идентификатору, выбор объектов, принадлежащих заданному типу);
• взаимосвязывание (связывание объекта с заданными вспомогательными, автоматическое связывание объектов);
• интерпретация сценария (получение физического и реального времени, номера итерации; планирование сценария (ранжирование сцены, упорядочивание ее объектов), анализ латентных объектов, запуск отдельных алгоритмов и сценария в целом);
• обработка событий приложения.

Обсудим некоторые особенности манипулирования всей сценой и интерпретации соответствующего ей сценария.

Для упрощения процедуры связывания обеспечивается специальный механизм автоматического связывания объектов. Данный механизм основан на анализе типов, выполняемом для всех объектов сцены, и включении подходящих объектов в связи, помеченные как автоматические. Все приемлемые объекты включатся в множественные связи. Только первые из выбранных объектов включаются в одиночные связи. Подобный механизм оказывается чрезвычайно полезным в тех случаях, когда тип объекта предопределяет некоторые семантические действия, которые следует выполнить автоматически. Например, является удобным отрисовать геометрические объекты автоматически сразу после их конструирования и включения в сцену. В этом случае процедура отрисовки всей сцены может быть реализована как алгоритм с множественным входным соединением типа GeometryData Data. Всякий раз, когда конструируется новый геометрический объект, он связывается с данным алгоритмом и может автоматически отрисовываться без каких-либо дополнительных усилий.

Определяя сценарий, пользователь располагает алгоритмы в той логической последовательности, в которой сцена должна их выполнять. Поскольку для больших сценариев это может вызвать затруднения, сцена позволяет упорядочивать алгоритмы автоматически. 'Гак как классификация соединений объектов соответствует отношениям зависимости между ними, сцена способна анализировать связи между объектами для определения характера их зависимости и упорядочивания их в требуемом логическом порядке. Методы упорядочивания, предоставляемые классом Scene, основаны на ранжировании сцены. Ранжирование преследует цель присвоить каждому объекту пару целых чисел (ранг и индекс), указывающих его местоположение в диаграмме сценария. Подобные диаграммы показывают объекты сцены как геометрические примитивы, соединенные стрелками, и часто используются в системах визуализации и анимации как эффективные средства для графического представления сценариев и их визуального программирования.

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

Способность сцены ранжировать и упорядочивать объекты является очень важной для корректной интерпретации сценария, поскольку алгоритмы должны активизироваться в логическом порядке, приводя к передаче данных через алгоритмический конвейер и получению итоговой картины. Если данный порядок был нарушен, то возможно появление различных типов ошибок, связанных с попытками активизировать алгоритмы без наличия на их входах подготовленных данных.

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

Наконец, класс Scene предоставляет метод для обработки типовых событий приложения. Такие события диспетчеризуются и напрямую рассылаются соответствующим методам сцены.

3. Разработка интегрированных приложений с использованием объектно-ориентированного ядра

Рассмотренное выше объектно-ориентированное ядро обладает, на наш взгляд, достаточной общностью и гибкостью для его использования при создании разнообразных приложений моделирования и визуализации на единой концептуальной, методологической, инструментальной и программной основе. В самом деле, при применении ядра не требуется модифицировать его всякий раз для приспособления к частной задаче, семантике специфических объектов, их отношениям и возможным деталям программной реализации. Лежащие в его основе механизмы связывания и взаимодействия объектов позволяют составлять и интерпретировать сложные сценарии, возникающие в реальных задачах, без какого-либо уточнения семантики конкретных объектов приложения. Следовательно, в большинстве случаев создание приложения сводится к разработке прикладной библиотеки классов для представления используемых научных данных и для реализации методов моделирования и визуализации, специфичных для конкретной предметной области, а также к реализации графического интерфейса пользователя. Принимая во внимание преимущества объектно-ориентированного программирования, реализацию прикладных библиотек классов данных и алгоритмов можно значительно упростить за счет неформального использования принципов инкапсуляции, наследования и полиморфизма.

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

Разработка конкретного приложения может проходить в соответствии со следующей итерационной схемой:

• идентификация классов научных данных и алгоритмов, участвующих в постановке и решении задач моделирования и визуализации, па основе выделения ключевых абстракций предметной области;
• определение семантики выделенных классов, установление отношений общности между ними, таких как "общее - частное", "целое - часть", построение объектных классификаций (иерархий наследуемых классов) для данных и алгоритмов с вершинами в суперклассах Data и Algorithm соответственно;
• установление отношений использования между экземплярами классов на основе анализа семантической зависимости и представление их в виде типизированных входных, выходных и смешанных связей, выделение одиночных и множественных связей;
• идентификация специфических атрибутов, свойств и поведения частных объектов, реализация их классов, для конкретных алгоритмических классов реализация специфических методов выполнения;
• составление и тестирование различных сценариев работы с выделенной системой классов, возможное ее критическое переосмысление, выделение новых типов объектов и, как следствие, возврат к предыдущим этапам разработки. В исключительных ситуациях возможно расширение функциональности классов Scene, Object.

Законченное приложение включает объектно-ориентированное ядро, инвариантное по отношению к различным задачам и предметным областям, расширяемые библиотеки классов, специфичные для рассматриваемой прикладной области, и унифицированный графический интерфейс пользователя. В качестве стандартных инструментальных средств, допускающих перенос разрабатываемых приложений на различные аппаратные платформы с минимальными усилиями, могут использоваться язык программирования Си++, графическая библиотека OpenGL и стандартные интерфейсные библиотеки (такие как Motif, Qt, Gtk).Общая открытая модульная архитектура приложения приведена на рисунке 3. Функциональность закопченного приложения определяется главным образом подключаемыми прикладными библиотеками и семантикой их классов.

Рис. 3. Архитектура приложения

Литература

1. STEP Product Data Representation and Exchange. ISO CD 10303-42. 1994.
2. The Virtual Reality Modeling Language. ISO/IEC 14772-1:1997.
3. OpenGL programming guide: the official guide to learning OpenGL, version I.I/ Mason Woo, Jackie Neider, Tom Davis, 2" ed. Addison Wesley, 1996.
4. MPI: A Message-Passing Interface Standard, Message-Passing Interface Forum, May 5, 1994.
5. Object-Oriented and Mixed Programming Paradigms: new directions in computer graphics / Peter Wisskirchen (ed.). Springer. 1996.
6. Семенов В.Л. Объектная систематизация и парадигмы вычислителмюй математики. // Профаммирование. 1997. №4. с. 14-25.
7. S.C. Bailin. An Object-Oriented Requirements Specification Method. Comm-ACM. Vol. 32. No. 5. 1989.PP.608-623.