CC BY
37
образования выполняются операции утончения и утолщения множеств, представляющие собой контурное описание объектов. Проведенные эксперименты показали целесообразность использования морфологической обработки изображений как для обнаружения текстовых зон, так и для восстановления самих контурных изображений.
Библиографический список
1. Гонсалес, Р. Цифровая обработка изображении / Р. Гонслес, Р. Вудс ; пер. с англ. под ред. П. А. Чочиа. М.: Техносфера, 2005.
M. N. Favorskaya, A. G. Zotin, A. N. Goroshkin
THE MORPHOLOGICAL PROCESSING OF COUNTOUR IMAGES IN RECOGNITION SYSTEMS OF TEXT SYMBOLS
The analysis of mathematical morphological operations for two-level and gray-level images processing is discussed. The duality correlations of widening and pressure operations, also closing and opening operations towards to addition and central reflection operations are proved. The results of using morphological operations for images processing are considered.
Принята к печати в декабре 2006 г.
УДК 681.34
И. А. Капчинский, Ю. Д. Цветков, С. А. Чикизов
ТЕХНОЛОГИЯ СОМ+ ДЛЯ РЕАЛИЗАЦИИ МУЛЬТИВЕРСИОННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ
Рассмотрена мультиверсионная методология разработки программного обеспечения. Сформулированы требования к разработке мультиверсионной программной системны. Представлена технология СОМ+, позволяющая реализовать независимость мультиверсионных модулей на этапе исполнения.
Программное обеспечение (ПО), являясь неотъемлемой составляющей коммерческих и специальных инфор-мационно-управляющих систем (ИУС), активно используется во многих областях науки и производства. Однако, ввиду многих причин, чрезвычайно сложно создать безупречный программный продукт [1]. А поскольку компьютеры применяются для решения все более сложных проблем в ИУС, то растет вероятность логических ошибок, присутствующих в программном обеспечении.
Мультиверсионность исполнения программных компонентов обеспечивает функционирование системы независимо от скрытых ошибок отдельных версий. Основным достоинством мультиверсионного программного обеспечения является то, что сбой системы может произойти только в единственном случае - в случае сбоя существенного числа модулей. Мультиверсионное программирование в ИУС предполагает, что возникновение сбоя в функционально эквивалентных модулях происходит в различных точках, благодаря чему этот сбой может быть обнаружен и исправлен. Независимость сбоев различных модулей является одной из основ мультиверси-онного программного обеспечения [2].
Использование множественных версий основано на предположении о том, что построенные различными проектировщиками, различными инструментальными средствами проектирования, с реализацией различных алгоритмов ит.д. компоненты должны иметь и разные ошиб-
ки [3]. Поэтому если одна версия производит сбой на специфическом вводе, то, по крайней мере, одна из альтернативных версий должна обеспечить корректный вывод.
При разработке мультиверсионной системы необходимо выполнение следующих требований:
- динамического подключения модулей;
- требования инкапсуляции;
- требования межмодульной защиты, что обеспечивает безопасное взаимодействие модулей в рамках программной системы;
- требования независимости модулей от языка программирования, что отчасти, вытекает из требования об инкапсуляции.
Разделение программного обеспечения на независимые модули является наиболее важным методом для обеспечения отказоустойчивости. Без модульной декомпозиции также невозможно и построение мультиверсионно-го программного обеспечения. Выполнение требований к мультиверсионным модулям гарантирует отказоустойчивость как при проектировании, так и, что особенно важно, при практической реализации модульной архитектуры программной системы.
Основным методом разработки модулей программного обеспечения был и остается объектно-ориентированный подход. Несколько лет назад эволюция объектноориентированных технологий породила компонентную архитектуру. Последние научные достижения в этой об-
ласти имеют большое значение для разработчиков муль-тиверсионных программных приложений. Наличие новых средств компонентного конструирования ускоряет процесс разработки сложных многоуровневых приложений.
Существуют два наиболее перспективных стандарта компонентного программного обеспечения [4]:
- COM (Component Object Model) - компонентная объектная модель. Это архитектура, разработанная корпорацией «Microsoft» и позволяющая создавать и поддерживать программные объекты и компоненты. Потенциально только эту технологию могут поддерживать различные языки программирования;
- CORBA (Common Object Request Broker Architecture)
- общая архитектура брокера объектных запросов. Этот стандарт был предложен консорциумом OMG для организации взаимодействия распределенных объектов. Архитектура CORBA позволяет выполнять в сети программы, написанные на любом языке, независимо от того, на какой платформе они запускаются. В архитектуре CORBA клиент выполняет запрос к общему интерфейсу, который называется брокером объектных запросов ORB, который пересылает запрос соответствующему объекту, а затем возвращает клиенту полученные результаты.
Для реализации среды и модулей мультиверсионного программного обеспечения, с учетом сформулированных выше требований, авторами предлагается использовать технологию COM. Она заключается в следующем.
Программа-клиент использует при своей работе объект (объекты) некоторой другой программы (сервера) так, словно этот объект является частью самого клиента. Основную роль при этом играет интерфейс объектов, под которым подразумевается поименованное множество функционально связанных методов (операций) объекта. Интерфейс может формироваться, как правило, при помощи IDL (Interface Definition Language) - специального С++-подобного языка описания интерфейсов. В результате клиент получает именно интерфейс затребованного объекта. Сервер же представляет собой программу, содержащую, кроме всего прочего, еще один или несколько объектов СОМ. Сервер СОМ может создавать реализации объектов из нескольких классов, каждый из которых представляет различные варианты поведения объекта.
СОМ-клиент взаимодействует с СОМ-сервером через указатель на интерфейс и использует этот указатель для вызова методов сервера. При этом клиент и сервер могут сосуществовать и взаимодействовать тремя различными способами:
- клиент и сервер выполняются на одном компьютере в рамках единого процесса;
- клиент и сервер запускаются на одной машине в рамках разных процессов;
- клиент и сервер - разные программы на различных компьютерах в составе сети.
Развитие технологии компонентного проектирования имеет очень важное значение для разработки программного обеспечения. Помимо того, что компонентное конструирование ускоряет процесс разработки сложных многоуровневых приложений, оно открывает дополнительные возможности для разработки отказоустойчивых мультиверсионных программных систем.
Базовая программная модель технологий COM и COM+ является идентичной. Компоненты разрабатываются в одинаковом порядке: описываются интерфейсы, для обеспечения автоматизации реализуется IDispatch, реализуется код для регистрации, т. е. в рамках новой парадигмы делается то же, что делалось и ранее. Однако в дополнение к этому появились новые сервисы, значительно расширяющие возможности приложений.
Технология COM возникла как компонентная технология уровня изолированной рабочей станции. Потом, с реализацией распределенной COM в Windows NT 4.0, получившей обозначения DCOM, эта технология стала развиваться в направлении поддержки удаленных обращений к компонентам. Для обеспечения работы серверных компонентов и устранения некоторых недостатков DCOM был создан сервер транзакций MTS. А потребность в унификации и объединении COM, DCOM и MTS в одну согласованную технологию, понятную и удобную для реализации приложений корпоративного уровня, способствовала разработке приложений COM+.
Приложение COM+ является основной единицей для защиты и администрирования компонентов. COM+ - это множество COM-компонентов, которые выполняют согласованные функции:
- COM-класс представляет собой именованный набор интерфейсов (одного или нескольких). Интерфейс -это группа логически взаимосвязанных функций, называемых методами;
- COM-объект - созданный экземпляр COM-класса;
- COM-компонент - это бинарная единица кода, функцией которого является создание COM-объекта.
Таким образом, можно сказать, что каждый из компонентов состоит из интерфейсов, которые в свою очередь состоят из методов. COM-класс идентифицируется уникальным идентификатором CLSID с интерфейсом IID.
Инструментарий администрирования сервисов компонентов может использоваться для включения новых компонентов в распределенное приложение, установки свойств и атрибутов, определяющих их поведение. Создание логических групп компонентов в виде COM+^ри-ложений позволяет получить следующие преимущества:
- определение пространства развертывания COM-компонентов;
- общее конфигурирование COM-компонентов, включая службу безопасности, балансировку загрузки компонентов, диспетчеризацию очередей сообщений компонентов;
- сохранение атрибутов компонентов, обеспечиваемое операционной системой, а не разработчиком;
- загрузка компонентных DLL в процесс по усмотрению разработчика;
- создание и управление потоками выполнения компонентов;
- осуществление доступа к контексту объекта за ресурсами, которое позволяет автоматически ассоциировать их с контекстом объекта.
Разработка COM+^риложений включает разработку COM-компонентов, содержащих логику приложения, интеграцию их в COM+^риложение и его администрирование при развертывании и поддержке.
Создание COM-компонентов осуществляется в следующем порядке:
- определение COM-классов и их воплощение;
- группировка классов в компоненты;
- определение множества COM+^ервисов, необходимых для компонента;
- разработка COM+^риложения;
- интеграция компонентов в, уже существующее или новое COM+^риложение;
- определение правильного множества атрибутов для каждого класса. Эти атрибуты представляют зависимости компонентов от используемых сервисов (транзакции, очереди ит. д.);
- установка системы защиты (права и роли классов, методов, интерфейсов);
- конфигурация переменных окружения для классов и приложений;
- подготовка приложения для распространения и развертывания;
- администрирование COM+^риложений;
- инсталляция приложения на компьютере администратора;
- установка переменных окружения (членов групп-ролей и т. д.);
- создание брокеров (proxy) приложения (если приложение должно быть доступно удаленным);
- тестирование приложения;
- задание параметров кластеризации.
Технология COM+ позволяет увеличить надежность и
масштабируемость приложений, применяя балансировку нагрузки компонентов и компоненты с поддержкой очередей.
Взаимодействие программ, предоставляющих информацию, изменяющуюся во времени (издатели), с программами, которым необходимы данные об этих изменениях (абоненты), уже давно представляет сложную проблему для разработчиков распределенных приложений.
В технологии CОM подписчик (абонент) обеспечивает издателя интерфейсом, а издатель вызывает метод этого интерфейса, когда происходит что-то его интересующее. Такой подход используют элементы управления ActiveX для генерации событий в своих контейнерах. Это так называемое жестко связанное событие (tightly coupled event), когда подписчик знает точно, у какого издателя запрашивает извещение (контейнер знает идентификатор CLSID) и механизм для соединения с ним (ICONNECTIONPOINTCONTAINER и интерфейсы CONNECTIONPOINT).
Жестко связанные события хорошо работают в приложениях масштаба одной рабочей станции, но имеют ряд недостатков, когда используются в системах масштаба предприятия. Например, может потребоваться, чтобы подписчик был способен делать свои запросы во время когда издатель дезактивирован, чтобы издатель был способен начать работу с подписчиком во время инициирования события. Решить эту проблему может использование компонентов с поддержкой очередей вместо прямых соединений для посылки извещений о событиях. Еще одна проблема, возникающая в связи с жестко связанными событиями, состоит в том, что подписчик должен знать
точный механизм взаимодействия с каждым издателем и эти механизмы могут радикально отличаться.
В технологии СОМ+ служба событий - это сервис операционной системы, который согласовывает и связывает издателя и подписчиков. Эта служба обеспечивает инфраструктуру, которая делает простыми публикацию и подписку к данным.
Издатель - это любая программа, делающая СОМ-вызовы, которые инициализируют события, а абонент (подписчик) - это СОМ+-компонент, который принимает СОМ-вызовы, представляющие собой события издателя. Абонент осуществляет интерфейс как COM-сервер, а издатель делает вызовы как СОМ-клиент. Событие - это одиночный вызов метода СОМ-интерфейса, инициированный издателем и доставленный службой событий (event service) нужному подписчику (подписчикам). Единственным отличием в работе СОМ+-службы событий от классической СОМ является наличие промежуточной службы событий, отслеживающей множество подписчиков, которые ожидают вызова, и направляющей вызовы этим подписчикам, при этом специфическая информация об издателе не нужна.
Создание одиночного запроса события известно как возбуждение события (в технологической документации термин «публикация» используется в качестве синонима для термина «возбуждение»). Соединение между издателем и подписчиком осуществляется классом события. Класс события - это СОМ+-компонент, содержащий интерфейсы и методы, которые издатель вызывает для инициирования события и которые должен реализовывать подписчик, если он желает получить извещение о событии. Интерфейсы и методы, обеспеченные классом события называются интерфейсами события и методами события.
Средствами СОМ+-библиотек типов устанавливаются, какие СОМ+-интерфейсы и методы должен содержать класс события. Классы событий хранятся в СОМ+-ката-логе, они помещаются туда или непосредственно про-граммами-издателями или административными инструментальными средствами. Подписчик объявляет о своем намерении принимать события от издателя, регистрируя подписку в службе событий СОМ+.
Подписка - это структура данных, которая обеспечивает службу событий информацией о получателе события. Она определяет, от какого класса события и от какого интерфейса или метода в этом классе события подписчик хочет получить вызов. Подписки хранятся в СОМ+-катало-ге. Их помещают туда или непосредственно программы-подписчики или административные инструментальные средства. Постоянные подписки будут сохранены и после рестарта операционной системы, а временные - нет.
Когда издатель хочет инициировать событие, он использует стандартные объектные функции создания объекта требуемого класса события типа CoCreate или CreateObject. Этот объект, известный как объект события, содержит реализацию системы событий требуемого интерфейса. Затем издатель вызывает метод события для инициирования события подписчиком. Система событий просматривает СОМ+-каталог и находит всех подписчиков, которые имеют зарегистрированные подписки к это-
му интерфейсу и методу. Далее эта система соединяется с каждым подписчиком и вызывает в каждом указанный метод. Поскольку обычно извещения о событии получают один и более подписчиков, то методы событий не могут возвращать никакого значения, кроме Success или Failure типа HRESULTs. Те же самые ограничения касаются и методов интерфейса очередей компонентов. Таким образом, любой СОМ-клиент может стать издателем, а любой СОМ+-компонент - подписчиком. При этом ни том, ни в другом случае он не обязан ничего знать о действиях, выполняемых службой событий.
Еще одно значительное усовершенствование, которое обеспечивает технология СОМ+, лежит в области защиты.
С появлением DCOM как части Windows NT 4.0 защита стала реальным результатом для разработчиков компонентов. DCOM-поддержка удаленного вызова сделала реальным проектирование распределенных приложений, но стоимость создания защищенных приложений при этом сильно увеличилась. Сервер транзакций МТS смог немного решить эту проблему, введя концепцию системы защиты на основе прикладных ролей (role-based security) - так называемую роль-основанную защиту. Эта система позволяет разработчикам приложений создавать различные классы полномочий, или ролей. Каждый пользователь приложения относится к одному или нескольким классам полномочий. Роль-основанная защита позволяет разработчику сосредоточиться на проблемах безопасности прикладного уровня вместо нижнего уровня. Однако сервер МТS смог обеспечить лишь достаточно ограниченную поддержку удаленного вызова. Технология СОМ+ позволила решить эту проблему.
СОМ+-служба безопасности, как и МТS, обеспечивается посредством концепции ролей (конечно, если это не удовлетворяет требованиям связываемого приложения, можно продолжать писать NT-код защиты нижнего уровня). В случае когда роль-основанная защита не эффективна (например, система защиты на основе экземпляров объектов(per-instance security)), СОМ+ обеспечивает обширную поддержку для impersonation and cloaking. Цель архитектуры защиты СОМ+ состоит в том, чтобы в максимально возможной степени изолировать проблемы безопасности нижнего уровня.
При разработке защищенного СОМ+-приложения нужно начать с создания системы авторизации. Эта система описывает различные роли и их разрешенные действия в пределах приложения. После установки прикладной системы защиты приложение следует разделить на отдельные компоненты. Каждому пользователю приложения будет назначена одна или более ролей, указывающих уровень их полномочий или доступа.
Используя технологию СОМ+, можно назначать роли определенным компонентовам, интерфейсам и методам в пределах создаваемого приложения. Клиентский доступ к каждому из этих объектов управляется СОМ+ во время выполнения. Это мощная методика, с помощью которой СОМ+ осуществляет систему доступа для приложения. Другой важной особенностью является то, что установка и обслуживание этой системы осуществляется декларативно, т.е. внешне для кода компонента. Так как СОМ+ обеспечивает детали контроля доступа нижнего
уровня, то система может управляться административно намного позже разработки самого приложения. Потребителям роли даны, компонентам, интерфейсам и методам роли назначены.
Использование декларативной роль-основанной защиты будет работать во многих прикладных сценариях, но в случаях, где это не делается, можно добавить логику защиты компонентов, как это было показано выше в коде МТS. Программно ролевая защита в СОМ+ усилена объектами контекста вызова. Эти объекты связаны с каждым вызовом и содержат информацию относительно числа вызывающих программ в вызывной цепочке, а также о подлинности каждой вызывающей программы.
СОМ+-архитектура защиты содержит и другие полезные особенности, которые облегчат создание защищенных приложений, хотя большинство приложений будет пользоваться преимуществом встроенной поддержки роль-основанной защиты. При проектировании СОМ+-приложения необходимо убедиться, что система досту-паразработана, а затем разложить приложение на отдельные части, основываясь на том, каким образом различные клиенты будут обращаться к имеющимся прикладным ресурсам. При условии выполнения этой последовательности шагов СОМ+ решит большую часть проблем безопасности, которые могут возникнуть при разработке распределенного приложения.
Таким образом, использование технологии СОМ+ позволяет существенно упростить управление программным обеспечением в организациях с распределенными подразделениями, при этом обновление программных модулей и исправление в них ошибок значительно упрощается. Эта технология позволяет ускорить анализ данных, а также снизить затраты на их обработку. Предложенная методика построения мультиверсионных программных систем, отличающаяся от существующих использованием технологии компонентовного программирования, позволяет исключить взаимное влияние мультиверсионных модулей друг на друга и на среду исполнения [5].
Библиографический список
1. Чэппел, Д. Технологии АСхуеХ и OLE / Д. Чеппел. М. : ВНУ, 2000.
2. Аниконов, А. В. Программно-аппаратное обеспечение отказо- и катастрофоустойчивых систем управления и обработки информации : моногр. / А. В. Аниконов, М. Ю. Слободин, Р. Ю. Царев. М. : МАКС-пресс, 2006.
3. Русаков, М. А. Современные методы надежностной оценки сложных программных систем : моногр. / М. А. Русаков, Р. Ю. Царев, С. А. Шаболин. СПб. : Инфо-Да, 2005.
4. Соммервилл, И. Инженерия программного обеспечения / И. Соммервилл. М. : Вильямс, 2002.
5. Программная система «КУХ vL0» (Среда мульти-версионного исполнения программных модулей) : прогр. для ЭВМ / И. В. Ковалев, Д. А. Поздняков, А. А. Ступина, И. С. Титовский. Зарег. в ВНТИЦ 2004, № 50200400994.
I. А. Kaptchinsky, Ju. D. Tzvetkov, S. A. Tchikizov
TECHNOLOGY COM+ FOR REALIZATION OF THE MULTI-VERSION SOFTWARE OF CONTROL INFORMATION SYSTEMS
It is considered multi-version methodology of software development. Requirements to multi-version software development system are formulated. It is offered to use the component technology COM+ allowing to realize of the multiversion modules independence at the stage of execution.
Принята к печати в декабре 2006 г.
УДК 372.8:37
X. X. Хуснутдинова, Н. Т. Рустамов
КОРПОРАТИВНО-РЕЛЯЦИОННЫЙ подход К ИНФОРМАТИЗАЦИИ ОРГАНИЗАЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ
Рассмотрены проблемы функционирования и управления регионально распределенными организационными структурами. Предложен один из возможных методов информатизации процесса управления такими структурами.
В современных условиях, когда организационные системы уже выходят за рамки конкретного города или региона, а часто - и за рамки одной страны, функционирование и управление этими системами значительно усложняется [1]. И информатизация таких систем имеет определенные особенности.
Рассмотрим организационную структуру (фирму), имеющую разветвленную сеть филиалов по Узбекистану. Предположим, что головной офис находится в городе Ташкенте, а филиалы - в городах Самарканде, Карши, Андижане, Фергане (рис. 1). Значительная разбросанность этих филиалов создает большие сложности в управлении и контроле за деятельностью фирмы.
Рис. 1. Региональное расположение организационной структуры (фирмы)
Основной проблемой при функционировании подобной системы является управление (в смысле общего управления). Как известно, оно осуществляется на основе информации, передаваемой из филиалов. Проблема заключается в организации сбора и обработки информации о ходе выполнения управляющих воздействий со всех филиалов и ее концентрации в центральном офисе, при сохранении данных о региональной принадлежности конкретной информации. В современных условиях при стремлении к всеобщей стабильной деятельности предприятий и организаций ощущается острая необходимость в таких системах, которые позволяют визуализировать
оценки деятельности каждого сотрудника этих организаций. Но при использовании систем данного класса встает ряд проблем. Одна из них состоит в том, как сохранять информацию о конкретном регионе при объединении всей совокупности данных с регионов в единую базу данных для дальнейшей обработки и визуализации. Поэтому ниже будет предложен один из возможных методов информатизации, позволяющий устранить эти проблемы [2].
Основой идеологии этого метода являются реляционные таблицы, в которых хранятся и кодируются все данные, поступающие с региональных удаленных таблиц (таблицы Т1, Т2, Т3 и Т4) (рис. 2).
Информация, поступающая с региональных таблиц, кодируется по принадлежности к тому или иному району и используется в центральной таблице уже в закодированном виде. Информация кодируется в текстово-численном виде либо только численном виде, что уменьшает объем хранимых данных и ускоряет процесс их анализа. Для операции идентификации региона существуют кодировочные таблицы, в которых хранится информация о конкретном регионе и его частные характеристики.
При необходимости визуализации данные проходят через модуль визуализации, который для идентификации и визуализации конкретного региона использует также данные из кодировочной таблицы. Кодировка позволяет группировать все данные, связанные с регионом Т1 (в центральной таблице они будут иметь код1), поэтому не составляет труда сгруппировать эти данные по конкретным признакам и представить результаты в графическом виде (рис. 3).
Все вышеизложенное позволяет сохранять и визуализировать как информацию о пространственном расположении объекта, так и его статистические данные.
Использование этого метода делает систему более гибкой. Так, если к полученным данным присоединить дополнительную информацию по данному региону, то графические данные можно представить следующим образом:
