Моделирование процессов интеграции информационных систем

• Автор: Вин Зо
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2007
• Место защиты: Москва
• Количество страниц: 98 с. : ил.

1. Моделирование процессов интеграции

1.1. Обзор технологий интеграции информационных систем

1.1.1. Координация данных

1.1.2. Основы интеграции с использованием XML и web-сервисов

1.2. Роль и место тестирования в процессе интеграции

1.2.1. Виды тестирования

1.2.2. Тестирование взаимодействия процессинговых систем при интеграции

1.3. Постановка задачи диссертации

Выводы

2. Модели, используемые при моделировании процессов интеграции

2.1. Моделирование взаимодействия интегрируемых подсистем на базе

раскрашенных сетей Петри
2.1.1. Сеть Петри как инструмент моделирования
2.1.2. Сеть Петри для подсистемы-клиента и подсистемы-сервера
2.2. Программные эмуляторы
2.2.1. Организация сценариев моделирования
2.2.2. Тестовая база данных
2.2.3. Как формируются сообщения
2.2.4. Как проверяются получаемые сообщения
Выводы
3. Компоненты эмулятора
3.1. Коммуникация в эмуляторе
3.1. СУБД для эмулятора
Выводы
4. Моделирование процессов интеграции на примере локальной платежной сети
4.1 Интеграция банка в локальную платежную сеть
4.2. Сеть Петри для взаимодействия процессинговых систем
4.2.1. Модуль для подсистемы-клиента (Acquire)
4.2.2. Модуль для подсистемы-сервера (Issuer)
4.2.3. Иерархическая сеть, связывающая Acquire и I s suer
4.2.4. Анализ полученных результатов
4.3. Эмулятор локальной сети процессинговых систем
4.3.1. Формирование сообщения-запроса
4.3.2 Синтаксический анализ сообщения
4.3.3 Семантический анализ сообщения-ответа
4.3.4 Схема тестовой базы данных
4.3.5 Реализация эмулятора на базе VB 6
Выводы
Заключение
Список литературы
Приложение

Современные информационные системы обслуживают бизнес, для которого бесконечные изменения и усовершенствования — необходимая составляющая конкурентоспособности. Многочисленные реорганизации компаний требуют перестройки информационных систем, при этом временные и бюджетные ограничения заставляют разработчиков отдельных проектов добавлять к этой и без того сложной сети новые связи и новые приложения, которые никак нельзя назвать открытыми. Все это приводит к ситуации, в которой приложения, вновь вводимые сегодня, завтра попадут в разряд «унаследованных» [1].
Одним из приемов борьбы со сложностью предметной области является декомпозиция. Создавать локально функционирующие подсистемы, ориентированные на поддержание работы определенных подразделений предприятия, проще, быстрее, дешевле. Результат виден быстрее. Однако, так как на предприятиях практически все взаимосвязано и взаимозависимо, в реально функционирующих информационных системах приходится как-то обеспечивать взаимодействие разрозненных приложений. Используются методы интеграции «по данным», методы на основе приема/посылки сообщений между приложениями. Продвинутые методы интеграции основаны на использовании автономных «информационных брокеров», берущих на себя роль посредников в обмене сообщениями между приложениями. Вслед за интеграцией по данным стали говорить об интеграции процессов и т.д. В настоящий момент на рынке предлагаются целые платформы интеграции, например, [2], маркетинговые материалы по которым обещают решить все имеющиеся проблемы, и заложить основу для решения проблем будущего. Активно обсуждаемая сервис ориентированная архитектура [3], позволяющая строить составляющие бизнеса из базовых конструктивных блоков, фактически требует построения информационных подсистем в виде отдельных служб, услуги которых доступны в режиме 24*7.
В процессе интеграции автономных, слабо связанных информационных подсистем вырабатывается некоторый протокол их взаимодействия, который требует тщательного тестирования. Это тестирование практически невозможно, по крайней мере, нецелесообразно проводить в процессе реального взаимодействия подсистем. Практика интеграции, например, процессинговых подсистем банков при вступлении последних во всемирные платежные сети или в локальные платежные сети активно использует программные эмуляторы для этих целей [4].

Целью диссертации является исследование и разработка методов и инструментальных программных средств для моделирования процессов взаимодействия локальных информационных подсистем предприятий, получаемых при их интеграции.
Актуальность выбранной темы определяется тенденцией разработки программных комплексов как сервисов (SAAS - Software As A Service) [38], что требует дополнительных усилий при тестировании взаимодействия сервисов.
Для достижения поставленной цели в диссертации решены следующие задачи:
1. Проанализированы современные технологии интеграции информационных систем.
2. Проанализированы роль и место тестирования в процессе интеграции.
3. Разработана методика моделирования процесса интеграции на основе использования информационно-программных эмуляторов интегрируемых подсистем.
4. Разработана модель информационно-программного эмулятора на основе использования сетей Петри.
5. Разработано экспериментальное приложение, в котором продемонстрированы разработанные методы на примере моделирования процесса интеграции процессинговых систем.
Для решения поставленных задач в диссертации использованы методы моделирования программных систем с помощью сетей Петри, методы и средства объектно-ориентированного проектирования и программирования. Для реализации экспериментального приложения использованы средства реляционных и постреляционных баз данных и XML-технологии.
В диссертации получены следующие новые научные результаты:
1. Разработана методика моделирования процесса интеграции на основе использования информационно-программных эмуляторов интегрируемых подсистем.
2. Разработаны модели и средства для построения программной и информационной компоненты для моделирования процесса интеграции.
Основные научные результаты, выносимые на защиту:
1. Предлагаемая методика моделирования процесса интеграции на основе использования информационно-программных эмуляторов интегрируемых подсистем.
2. Модели и средства для построения программной и информационной компоненты для моделирования процесса интеграции.

В этом случае тестовая база данных должна содержать шаблон сообщения, которое отправляет локальная платежная сеть, и шаблона для проверки сообщения, получаемого от процессинговой системы «нового» банка. Реально отправляемое эмулятором сообщение генерируется непосредственно перед отправлением в зависимости от ситуации.
Рис 4.1. Вместо локальной платежной сети используется эмулятор в режиме Acquire.
Теперь приведем пример ситуации, когда эмулятор выступает в режиме Issuer. Владелец пластиковой карты, выпущенной «старым» банком, который входит в локальную платежную сеть, хочет снять деньги. При этом он пользуется банкоматом, принадлежащим «новому» банку, который включается в локальную сеть. Процессинговая система «нового» банка отправляет в «старый» банк транзакцию авторизации (Рис 4.2). Реально это осуществляется через головной банк, так как только через головной банк она может связаться с банком, выпустившим пластиковую карту. В свою очередь головной банк, получив транзакцию-ответ от «старого» банка, выпустившего карту, отправляет ее в «новый» банк. Вот именно этот последний канал и требуется проверить, для чего вместо локальной платежной сети следует использовать эмулятор в режиме Issuer, чтобы не задействовать для тестирования всю локальную сеть.