CC BY
58
доставку операции к целевому объекту и ее выполнение. Операции реализуются разработчиком МК в дополнение к созданному классу объекта. Работа с операцией осуществляется через специально разработанный интерфейс, и в общем случае разработчику НК нет необходимости знать конкретную реализацию операции. Более того, он не знает местонахождение оперируемого объекта. Библиотека ИББЬ предоставляет набор шаблонных классов, позволяющих формировать типовые операции на базе набора параметров. Есть возможность создать операцию с произвольной логикой с нуля.
Все описанные элементы обладают свойствами сохранения и восстановления состояния, логика, глубина и детализация которого определяются разработчиком элемента или типовой реализацией, включенной в иББЬ. Сохранение/восстановление актуального состояния осуществляется посредством иББЬ, что позволяет разработчику НК или МК всегда работать с готовыми элементами. Таким образом, ИББЬ автоматически создает и обновляет модельное окружение, состав и состояние которого для каждого НК или МК определяет разработчик, формируя систему фильтров и осуществляя необходимые операции (рис. 2).
Поддержка свойств сохранения/восстановления дает возможность решать задачи создания срезов состояния всей моделируемой среды и ее возврата на определенный момент. Информация сохраняется в выбранном хранилище данных.
ИББЬ позволяет организовать одновременную работу с несколькими распределенными средами моделирования с возможностью перехода из одной среды в другую. При этом выделяются активная (наблюдаемая) среда и неактивные среды, развивающиеся в фоне. Инструментарий библиотеки позволяет реализовать НК отвлеченно от конкретной среды, с автоматической адаптацией к смене активных сред.
фильтры^ | операций"]
Рис. 2
Если в рамках разработки изделия решаются задачи комплексирования с другими системами, то в таком случае МК является адаптер [3] к сопрягаемой системе.
Библиотека UDSL разработана на языке C++ и является кроссплатформенной. Тестирование UDSL проводилось на ОС Windows 2000/XP, Мобильной системе Вооруженных сил 3.0 и защищенной ОС «Оливия».
Первая версия библиотеки UDSL прошла успешную апробацию в изготовленном тренажере.
Литература
1. IEEE Std P1516.3. IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Federation Development and Execution Process. N.Y.: Institute of Electrical and Electronics Engineers, Inc., 2000.
2. Мэйерс С. Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ. - М.: ДМК Пресс, 2006. - 300 с.
3. Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software. MA: Addi-son-Wesley, 1995. - 355 p.
4. Тарасов В.Б. Агенты, многоагентные системы, виртуальные сообщества: стратегическое направление в информатике и искусственном интеллекте. // Новости искусственного интеллекта. - 1998. - № 3. - С. 5-54.
ОРГАНИЗАЦИЯ ИНФОРМАЦИОННОГО ОБМЕНА В СЛОЖНЫХ РАСПРЕДЕЛЕННЫХ СИСТЕМАХ
А.А. Прохоров; А.Н. Нефедов
(НИИ «Центрпрограммсистем», г. Тверь, prolex@cps.tver.ru)
Ключевые слова: информационный обмен, уровень взаимодействия, подписка, сообщение, сетевой протокол.
Программное обеспечение (ПО), предназначенное для решения разного рода задач распределенного исполнения, требует наличия эффективной и гибкой системы информационного обмена. Опыт разработки такого ПО, а также современные требования к качеству и возможностям изделия со стороны заказчика и пользователя определили ос-
новные задачи, решение которых должна обеспечивать система информационного обмена:
а) предоставление механизмов информационного обмена между функциональными модулями ПО на разных уровнях взаимодействия: в одном процессе, между процессами на одной ЭВМ, компьютерах локальной или глобальной сети;
б) децентрализованная связь компонентов системы по принципу peer-to-peer (узел к узлу) [1,2];
в) параллельное исполнение нескольких экземпляров системы во время сеанса работы ПО;
г) производительность, достаточная для решения задач моделирования дискретных событийных систем;
д) переносимость и возможность связанной работы элементов системы информационного обмена под операционными системами различных семейств, в частности Windows и Linux;
е) возможность комплексирования существующих систем, разработанных на базе такой же системы информационного обмена.
Анализ и апробация существующих решений выявили отсутствие системы информационного обмена, отвечающей всем указанным требованиям, что определило актуальность задачи разработки собственной системы, получившей название СИНОМ.
В основу СИНОМ положена идея организации информационного поля, обмен данными в котором происходит посредством отправки информации, с одной стороны, и декларированием своего желания получать конкретную информацию по определенным правилам, с другой. Контент информационного поля формируется подключенными функциональными модулями ПО (рис. 1). При этом любой новый функциональный модуль, подключившись к существующему информационному полю, получает доступ к его данным, декларируя свои информационные требования, а также возможность дополнить информационное поле своими данными.
потоки информации
Информационное4 поле
- функциональные модули
Рис. 1
Информация представляется в виде сообщений, каждое из которых содержит уникальный идентификатор, уровень распространения (процесс, ЭВМ, локальная сеть, глобальная сеть), приоритет (низкий, средний, высокий) и содержательную часть.
Информационное требование реализуется путем создания подписки, которая содержит идентификатор сообщения, уровень распространения требуемых данных (процесс, ЭВМ, локальная сеть, глобальная сеть) и метод-обработчик сообщения. Дополнительно может быть указано ограничение по частоте получения сообщения (в миллисекундах). Удаление подписки определяет отказ от дальнейшего получения информации.
При таком подходе отправитель и получатель ничего не знают друг о друге, что позволяет устранить жесткую логику связи источника и приемника данных и делает функциональную область ПО легко и независимо расширяемой.
Инфраструктура СИНОМ состоит из библиотеки sinom.dll (sinom.so для Linux) и службы sinom.exe.
Библиотека sinom.dll обеспечивает организацию внутрипроцессного обмена, а также связь со службой sinom.exe. Взаимодействие sinom.dll и функционального модуля ПО осуществляется вызовом методов интерфейса sinom.dll со стороны функционального модуля, а sinom.dll вызывает методы-обработчики указанных функциональных модулей при оформлении подписок.
Взаимодействие sinom.dll со службой sinom.exe осуществляется посредством эмуляции работы по сети, используя интерфейс внутренней петли (протокол TCP с локальной адресацией).
Служба sinom.exe обеспечивает создание и работу peer-to-peer сетевой инфраструктуры для передачи информации между ЭВМ локальной и глобальной сети, а также между процессами в рамках одной ЭВМ. Удаленное взаимодействие служб sinom.exe осуществляется посредством TCP- и UDP-протоколов. Выбор протокола определяется приоритетностью сообщения.
Общий вид сетевого взаимодействия показан на рисунке 2. Из рисунка видно, что схема peer-to-peer используется только на уровне подсетей, то
Процесс 1
Рис. 2
есть служба sinom.exe, запущенная на любой машине подсети, кроме шлюзовой, знает обо всех остальных службах, работающих в этой же подсети. Если подсети соединены через маршрутизатор, то служба на шлюзовой машине «1.x» подсети 1 дополнительно связана со службой на шлюзовой машине «2.x» подсети 2. Если подсети соединены через компьютер «у.у» с несколькими сетевыми картами, то служба, запущенная на этой машине, связана со всеми службами подключенных подсетей. Шлюзовой также является любая машина с подключением к глобальной сети. Соединение реет-ю-реет и соединения вида «подсеть 1 о подсеть 3» (рис. 2) устанавливаются автоматически при запуске программ, использующих СИНОМ. Соединение вида «подсеть 1 о подсеть 2» устанавливается путем явного указания 1Р-адреса в конфигурационном файле.
Информационное взаимодействие различных уровней посредством СИНОМ показано на рисунке 3. Уровни информационного взаимодействия организованы по принципу матрешки и определяются уровнем распространения сообщения, указанным при отправке, и уровнем распространения требуемых данных, указанным при подписке. То есть сообщение не выйдет на новый уровень, если он не указан при отправке или на сообщение нет ни одной подписки этого или более высокого уровня. Здесь представлены следующие уровни взаимодействия.
1. Внутрипроцессный (inpтocess) обмен, при котором сообщение и подписка на него не выходят за пределы процесса. О появлении (удалении) подписки с данным уровнем будут оповещены только функциональные модули процесса. Следовательно, сообщения с тем же идентификатором, отправленные из других процессов, получены не будут.
Рис. 3
global net
2. Обмен в рамках одной ЭВМ (local machine). В этом случае сообщение и подписка не выходят за пределы ЭВМ (не отправляются в сеть). О появлении (удалении) подписки с данным уровнем будут оповещены функциональные модули процессов, запущенных на данной машине. Сообщения с тем же идентификатором, отправленные из другой ЭВМ, получены не будут. Данный уровень включает в себя внутрипроцессный обмен.
3. Обмен на уровне локальной сети (local net). Сообщения и подписки на них не передаются в другие подсети. О появлении (удалении) подписки с данным уровнем будут оповещены все участники информационного поля в рамках подсети. То есть сообщения с тем же идентификатором, отправленные из другой подсети, получены не будут. Данный уровень включает в себя внутрипро-цессный обмен и обмен в рамках одной ЭВМ.
4. Межсетевой обмен (global net). Область распространения сообщений и подписок не ограничена. О появлении (удалении) подписки с таким уровнем распространения будет оповещен каждый модуль sinom.dll в каждой программе данного информационного поля.
В качестве примера рассмотрим информационный обмен между функциональным модулем d.dll, загруженным в программу App_6.exe, которая запущена на ЭВМ_2_1 в локальной сети 2 (рис. 3). Данный модуль подписывается на сообщение с идентификатором 1, желая получать его откуда угодно (global net). О появлении данной подписки в информационном поле оповещаются все, в том числе и функциональная модель модуля 1.dll (App_1.exe на ЭВМ_2_1 в локальной сети 1), который генерирует данное сообщение. Если сообщение 1 имеет уровень ниже global net или подписка на него была удалена в d.dll, оно не выйдет за пределы модуля 1.dll. В противном случае оно будет доставлено в d.dll.
Настройки системы (уровни взаимодействия, порты, адреса шлюзовых машин и т.п.) задаются с помощью конфигурационного файла. Средства настройки позволяют решить вопрос о создании нескольких информационных полей, ничего не знающих друг о друге и исполняемых на одном физическом пространстве сети для сокращения времени обработки циркулируемой информации. Так, например, может быть создано отдельное информационное поле для обмена мультимедийным контентом с целью разгрузить основное информационное поле (в частности, информационное поле моделируемой среды). При этом для функционального модуля всегда остается возможность стать потребителем и источником информации сразу для нескольких информационных полей.
Система СИНОМ разработана на языке C++ [3] на основе объектно-ориентированного и обобщенного подходов [4] и является кроссплатфор-менной. Проведены ее апробация и тестирование
на ОС Windows 2000/XP, Мобильной системе Вооруженных сил 3.0 и защищенной ОС «Оливия». В настоящее время СИНОМ является основой информационного обмена в разрабатываемых изделиях.
Дальнейшее развитие системы заключается в автоматизации процесса создания и отправки сообщений, а также в распараллеливании и обеспечении потокобезопасного взаимодействия функциональных модулей и sinom.dll.
Список литературы
1. Androutsellis-Theotokis S., Spinellis D. A Survey of Peer-to-Peer Content Distribution Technologies. // ACM Computing Surveys. 2004. Vol. 36. - № 4, pp. 335-371.
2. Khan I.J., Wierzbicki A. Foundation of Peer-to-Peer Computing, Special Issue. // Elsevier Journal of Computer Communication. 2008. V 31. Issue 2, pp. 137-161.
3. Stroustrup B. The C++ Programming Language. 3rd. ed. -Addison-Wesley Publishing Company, 1997. - 1040 p.
4. Alexandrescu A. Modern C++ Design: Generic Programming and Design Patterns Applied. - Addison-Wesley. 2001.
ПОДХОД К РАЗРАБОТКЕ КРОССПЛАТФОРМЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
А.А. Прохоров; А.А. Карпов (НИИ «Центрпрограммсистем», г. Тверь,, prolex@pps.tver.ru)
Ключевые слова: целевая операционная система, рабочая среда, граммное обеспечение.
При смене целевой операционной системы (ОС) программного изделия для разработчика существуют два основных варианта организации разработки программного обеспечения (ПО): полностью перевести процесс разработки на целевую ОС; использовать привычную, устоявшуюся рабочую среду (соответственно, и прежнюю ОС) для разработки ПО, а в целевой ОС проводить окончательное тестирование и исправление недоработок, связанных со спецификой ОС и компиляторов.
Первый вариант организации разработки ПО потребует от разработчиков:
- отказаться от используемого длительное время инструментария разработки ПО;
- исследовать рынок готовых технологических программных продуктов для целевой ОС на соответствие требованиям и функциональным возможностям, обеспечивающим разработку ПО в срок с заданным качеством;
- обучить работе с новым технологическим ПО в целевой ОС.
Второй вариант требует от разработчиков меньшего времени на изучение использования нового технологического ПО, так как в основном будет использоваться прежняя рабочая среда.
В данной статье описан подход к организации разработки программного изделия по второму варианту, где защищенная ОС (ЗОС) Мобильная система Вооруженных сил (МСВС) является целевой ОС, а Windows - основной ОС, используемой при разработке ПО.
Рассмотрим задачи, которые необходимо решить при организации разработки ПО в ОС Windows и ЗОС МСВС:
- поддержка коллективной работы с исходным текстом и документацией по проекту (разработка структуры дерева исходного текста проекта
сборка, платформо-зависимая среда, кроссплатформенное про-
и обеспечение работы с репозитарием проекта в обеих ОС);
- обеспечение компиляции одного и того же исходного текста проекта, сборки исполняемых файлов и создание дистрибутива в обеих ОС;
- обеспечение автоматического ежедневного создания дистрибутива программного изделия в обеих ОС;
- поддержка ресурса для фиксации ошибок, выявленных на этапах компиляции, сборки и тестирования программного изделия в обеих ОС;
- поддержка пополняемого информационного ресурса для разработчиков, раскрывающего особенности ведения разработки ПО под ОС Windows и ЗОС МСВС и доступного для чтения и пополнения из обеих ОС.
К платформо-зависимым элементам, используемым при разработке программного продукта, можно отнести графический интерфейс пользователя, векторную и растровую графику, работу с видео и звуком, сетевой обмен и т.д.
Для обеспечения переносимости исходного кода ПО между двумя ОС используется кросс-платформенная библиотека Qt4 (qtsoftware.com), позволяющая избавиться от прямого использования API конкретной ОС -библиотека берет это на себя (рис. 1).
Для компиляции и сборки ПО в ОС Windows используется MS Visual Studio, в ЗОС МСВС - утили-
Исходные тексты разрабатываемого ПО
API кроссплатформенной библиотеки
API Windows
API МСВС
Рис. 1
