Научно-исследовательская лаборатория систем ЧПУ
Научно-исследовательская лаборатория систем ЧПУ

Поиск по сайту:
 

Расписание курсов "Программирование SINUMERIK 810D/840D/840Di"



Построение сложных многокомпонентных приложений

Авторы: Владимир СОСОНКИН
Кафедра КСУ, МГТУ "СТАНКИН"
Георги МАРТИНОВ
Кафедра КСУ, МГТУ "СТАНКИН"
Александр ЛЮБИМОВ
Кафедра КСУ, МГТУ "СТАНКИН"


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

Введение в проблему многокомпонентных приложений

Стандартные способы обмена данными между компонентами и, в частности, визуализируемыми компонентами ActiveX, рассчитаны в основном на бизнес-приложения, где количество компонентов редко превышает десяток. Как правило, все ActiveX в таких случаях умещаются на одном экране. Увеличение количества компонентов, участвующих в приложении, нередко наращивает сложность контейнера в геометрической прогрессии.

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

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

В качестве средства хранения и изменения данных в последнее время всё шире используется XML DOM Document. В этом случае представление данных имеет стандартную форму, и имеются разнообразные инструменты для обработки данных (форматирования, фильтрации, визуализации, конвертирования в другие виды представления данных, и т.д.). Далее в статье предполагается, что данные представлены в виде XML DOM Document-а, хотя это не является необходимым условием.

Организация взаимодействия компонентов

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

Обработка событий контейнером

Традиционный способ организации взаимодействия компонентов с помощью обработки событий контейнером проиллюстрирован на Рис. 1


Рис. 1. Стандартное взаимодействие компонентов.

В случае возникновения события в компоненте, например, изменения данных или действия пользователя, компонент "зажигает" событие (fire event). Контейнер компонентов реализует объект-обработчик поступающих событий и обрабатывает события поступающих из компонентов. Если событие нужно другому компоненту, что на практике не редкость, то контейнер перенаправляет событие компоненту, вызывая его методы или изменяя его свойства.


Рис. 2. Пример взаимодействия компонентов через контейнер

Рассмотрим пример, приведенный на Рис. 2. Контейнер содержит два ActiveX компонента: первый, отображающий битовые сигналы электроавтоматики, и второй, показывающий значения сигналов в положении курсора. Когда курсор первого компонента поменяет позицию вследствие навигации клавиш или перемещения мышью, то компонент зажигает событие в контейнере. Обработчик событий контейнера принимает событие, в котором содержатся значения сигналов, соответствующие новому положению курсора и перенаправляет данные второму компоненту, вызывая его методы.

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

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

Обработка событий компонентами

Контейнер можно упростить, если использовать распределённый способ организации взаимодействия компонентов, при котором обработку событий осуществляют сами компоненты (см. Рис. 3).


Рис. 3. Распределённое взаимодействие компонентов

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

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

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

  • простой код контейнера;
  • трудно изменить состав компонентов;
  • трудно изменить функциональность компонентов;
  • практически невозможно использовать компоненты по отдельности.

Использование компонента уведомления в качестве сервера событий

В сложных проектах существует серьёзная проблема организации взаимодействия компонентов. Применение традиционных решений приводят к очень сложному коду контейнера или к жестко привязанным между собой компонентам. Предлагается решение проблемы организации межкомпонентного взаимодействия с использованием компонента уведомления. Архитектура рассматриваемого решения представлена на Рис. 4. Компонент уведомления выступает в роли сервера событий, что предполагает клиент-серверный способ организации взаимодействия компонентов. Остальные компоненты являются клиентами сервера событий и могут подписываться на необходимые для них события, причём эта подписка осуществляется динамически, на некоторый период, определяемый клиентом. Подключение клиентов к серверу события использует механизм ConnectionPoints (см. [5]).


Рис. 4. Клиент-серверное взаимодействие компонентов.

Многообразие COM-интерфейсов, с помощью которых обычно реализуется взаимодействие компонентов, заменено на интерфейсы доступа к данным (стандартные, например, XML DOM интерфейсы), интерфейс подписки на уведомления и интерфейс обратной связи (для приёма уведомлений об изменении данных).

Компоненты разделены на два типа: компоненты, выдающие разрешение на изменение параметра, и компоненты, уведомляемые о фактическом изменении параметра.
Кроме них, в систему вводится компонент уведомления. Этот компонент реализует взаимодействие остальных компонентов.

Запрос на изменение какого-либо параметра конфигурации всегда поступает к компоненту уведомления. При этом инициатор запроса может быть любым компонентом проекта. Процедура изменения значения параметра приведена на Рис. 5.


Рис. 5. Изменение значения параметра

Компонент отсылает запрос на изменение значения атрибута компоненту уведомления. Компонент уведомления запрашивает разрешение на изменение значения атрибута у компонентов, дающих разрешение на изменение. Если разрешение получено, то изменяется атрибут в DOM-документе. После этого рассылается уведомление всем компонентам, подписавшимся на отслеживание измененяемого атрибута.

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

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

Клиент-серверный способ организации взаимодействия компонентов предполагает:

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

Технологии и стандартный инструментарий разработки

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

Расширяемый язык разметки (Extensible Markup Language, XML) - это технология для управления, отображения и организации данных [3].

Индивидуальные свойства (особенностей) XML обеспечивают универсальность его применения во всех приложениях:

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

Следуя некоторым правилам, XML позволяет иерархически организовать данные, которыми компоненты будут обмениваться. Для этого XML использует теги, словарь и типы. Формат XML документа контролируется схемой, выступающей в роли шаблона. Стандарт XML определяется консорциумом W3C [4].

Само по себе иерархическое представление данных в XML формате мало что дало бы нам, если не существовали бы готовые механизмы для работы с ними, такие как XML DOM Document и анализатор MS Parser [5]. Объектная модель документа (Document Object Model, DOM) предоставляет средства для работы с XML-документами, с использованием некоторого кода, а также способы взаимодействия с этим кодом из прикладных приложений.

DOM документ и его интерфейсы

DOM добавляется как слой между XML-анализатором и приложением, которому требуется информация из XML-документа (см. Рис. 6). Анализатор считывает данные из XML-документа и строит DOM, который используется приложениям более высокого уровня, при этом элементы XML-документа описываются как узлы дерева.


Рис. 6. Взаимодействие между XML документом и приложением

XML DOM Document, как объект, создается в памяти компьютера, причем считывание XML-документа в память до начало работы является необходимым условием. С этим объектом компоненты взаимодействуют, получая или изменяя его данные. Содержимое XML DOM-документа можно сохранять в *.xml файле, либо можно считывать из *.xml файла. Каждый XML DOM Document имеет иерархическую структуру. Элементы и атрибуты XML DOM-документa ("вложенные" объекты) сопоставляются с данными, предназначенными для совместного использования компонентами. Файлы схем (*.xsd) содержат информацию о структуре XML DOM-документа, значения "по умолчанию" его атрибутов и элементов, типы атрибутов и элементов и т.д. [6].

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

В свою очередь интерфейсы ядра подразделяются на основные интерфейсы (Fundamental Interfaces) и расширенные интерфейсы (Extended Interfaces). Основные интерфейсы должны присутствовать во всех реализациях, даже в тех, которые не рассчитаны на работу с XML файлами. Расширенные интерфейсы входят в те реализации, которые ориентированы на работу с XML.

С помощью DOM-интерфейсов возможно получить информацию о документе, информацию об узлах и элементах, свойствах атрибутов; осуществить навигацию по дереву; добавить или удалить узел, обработать исключение и т.д.

Редактор XML Spy

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

Один из лидирующих на рынке - это редактор XML Spy фирмы Altova (см. Рис. 7). Редактор осуществляет иерархическое представление данных, контроль за оформлением и редактированием документа, проверку документа на соответствие заданными правилам в схеме и т.д. С помощью вспомогательных окон выводится дополнительная информация из схемы о типах, пределах и документации.


Рис. 7. Редактор XML Spy

В качестве примера на Рис. 7 открыт файл обмена данными между компонентами. Узел ZoomCommand содержит четыре элемента и описывает команды увеличения масштаба изображения. Каждая команда имеет в качестве атрибутов имя (Name) и состояние запуска (Run), оно может принимать значения true или false. Задействованы четыре команды, соответствующие каждому элементу узла. Команды ZoomOn / ZoomOff предназначены соответственно для у величения и уменьшения масштаба изображения. Команда LastZoom возвращает систему к первоначальному масштабу изображения. Команда ActivateZoom включает или выключает режим увеличения экрана. При включении (подаче) команды атрибут состояния запуска (Run) устанавливается в значение "true", а после выполнения команды - опять возвращается в значение "false". Компоненты, подписанные на изменение данного атрибута, получают уведомление об изменении его значения, и выполняют действия, соответствующие команде.
Узел Zooms содержит информацию о текущем увеличении экрана, како размере видимой области и размеры рамки, а также содержит стек сохраненных увеличений. Такая организация данных позволяет создать механизм, хранящий историю увеличения экранов в стеке с возможностью навигации по этой истории.

Специфика реализации

DOM-документ вместе с механизмом уведомления может быть применён не только для организации взаимодействия компонентов, но и для хранения данных, используемых приложением. Такой подход предоставляет единый механизм для обработки всех данных, задействованных в приложении.

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

Механизм персональной подписки на уведомления

Существуют случаи, когда клиент содержит большое множество элементов, сопоставленных различным параметрам XML-документа, (например, дерево). При получении "обобщенного" уведомления об изменении значения какого-либо параметра возникает проблема нахождения элемента управления, которого пришедшее уведомление касается. Поиск элемента при каждом получении такого уведомления приводит к резкому падению производительности приложения. Для выхода из описанной ситуации разработан механизм персональной подписки на уведомления, показанный на Рис. 8.


Рис. 8. Механизм персональной подписки на уведомления

Компонент уведомления имеет возможность создавать объекты персональных клиентов, которые могут быть сопоставлены одному элементу или атрибуту XML DOM-документа. Приемник уведомления генерирует события, связанные только с сопоставленным ему элементом или атрибутом XML DOM-документа. Таким образом, каждый элемент управления компонента может самостоятельно получать уведомления о событиях, касающихся только его, и тем самым автоматически решается проблема нахождения элемента. Этот механизм не исключает возможности использования "обобщенных" событий.

Реализация приёмников событий

Код приёмников событий, используемых в библиотеках MFC и ATL, отличается большим размером и низким быстродействием, поскольку традиционно в качестве приёмника событий используется объект окна. Это было неприемлемо для реализации механизма персональных уведомлений. Что и стало причиной разработки максимально упрощенного кода приёмников событий. Принципиальная схема работы модифицированных приёмников событий приведена на Рис. 9.


Рис. 9. Схема работы приёмников событий

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

Основные отличия обработки событий традиционных решений состоят в следующем:

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

Реализация приемников событий не исключает возможности использования традиционных механизмов приёма и обработки событий.

Выводы

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

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

Список литературы

  1. Сосонкин В.Л., Мартинов Г.М. Концепция числового программного управления мехатронными системами: реализация диагностической задачи управления. Мехатроника. 2001. №3. C. 2-6.
  2. Дэвид Хантер и др. Введение в XML /Пер. с англ.-М.: Издательство "Лори", 2001.-638 стр.: ил.
  3. http://www.w3.org
  4. http://msdn.microsoft.com
  5. XML и SOAP: программирование для серверов BizTalk.Новейшие технологии /Пер. с англ.-М.: Издательство торговый дом "Русская Редакция", 2001.-496 стр.: ил.

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