Интеграция программного обеспечения что это

Обновлено: 02.07.2024

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

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

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

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

Как правило, интеграционное тестирование проводится уже по завершении модульного тестирования для всех интегрируемых модулей. Однако это далеко не всегда так. Существует несколько методов проведения интеграционного тестирования:

восходящее тестирование;
монолитное тестирование;
нисходящее тестирование.

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

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

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

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

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

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

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

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

тестирование с поздней интеграцией;
тестирование с постоянной интеграцией;
тестирование с регулярной или послойной интеграцией.

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

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

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

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

функциональное тестирование;
тестирование производительности;
нагрузочное или стрессовое тестирование;
тестирование конфигурации;
тестирование безопасности;
тестирование надежности и восстановления после сбоев;
тестирование удобства использования.

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

Исходной информацией для проведения перечисленных видов тестирования являются два класса требований: функциональные и нефункциональные. Функциональные требования явно описывают, что система должна делать и какие выполнять преобразования входных значений в выходные. Нефункциональные требования определяют свойства системы, напрямую не связанные с ее функциональностью. Примером таких свойств может служить время отклика на запрос пользователя (например, не более 2 секунд), время бесперебойной работы (например, не менее 10000 часов между двумя сбоями), количество ошибок, которые допускает начинающий пользователь за первую неделю работы (не более 100), и т.п.

Функциональное тестирование. Данный вид тестирования предназначен для доказательства того, что вся система в целом ведет себя в соответствии с ожиданиями пользователя, формализованными в виде системных требований. В ходе данного вида тестирования проверяются все функции системы с точки зрения ее пользователей (как пользователей-людей, так и "пользователей" - других программных систем). Система при функциональном тестировании рассматривается как черный ящик, поэтому в данном случае полезно использовать классы эквивалентности. Критерием полноты тестирования в данном случае будет полнота покрытия тестами системных функциональных требований (или системных тест-требований) и полнота тестирования классов эквивалентности, а именно:

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

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

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

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

Все требования, относящиеся к производительности системы, должны быть четко определены и обязательно должны включать в себя числовые оценки параметров производительности. Т.е., например, требование "Система должна иметь приемлемое время отклика на запрос пользователя" является непригодным для тестирования. Напротив, требование "Время отклика на запрос пользователя не должно превышать 2 секунды" может быть протестировано.

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

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

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

Стрессовое тестирование очень важно при тестировании web-систем и систем с открытым доступом, уровень нагрузки на которые зачастую очень сложно прогнозировать.

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

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

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

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

Выделяют следующие группы свойств программной системы, подлежащие проверке (некоторые группы свойств укрупнены для сокращения списка):

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

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

Тестирование удобства использования. Отдельная группа нефункциональных требований - требования к удобству использования пользовательского интерфейса системы. Этот вид тестирования будет рассмотрен в следующей лекции.

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

Авторы

Другие статьи автора

Статьи по теме

Кроме того, на решение задачи интеграции оказывают влияние следующие факторы:

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

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

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

Интеграция данных

На сегодняшний день практически в любой организации возникает задача получения различного рода консолидированной отчетности, на основе которой умудренные опытом бизнес-аналитики делают выводы о текущих тенденциях бизнеса и принимают те или иные стратегические решения. Как правило, для получения подобного рода отчетности строятся громадные хранилища, в которые собираются данные из всех основных корпоративных ИС, будь то ERP, CRM или автоматизированная банковская система. Основой же для построения хранилищ практически всегда является система, которая, получая на вход данные в самых разных форматах, преобразовывает их в нужную форму и загружает в хранилище. И когда необходимо серьезное преобразование данных на их пути из одной системы в другую, на помощь приходит технология ETL (Extract, Transform, Load).

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

Пример: абонентам одного из телеком-операторов, являющимся обладателями карт лояльности, полагаются бонусные баллы за оплату тех или иных услуг, например, минут разговора, отправленных SMS и MMS, интернет-трафика и т.п. Количество типов таких услуг и соответствующих алгоритмов начисления баллов – несколько десятков. Количество абонентов, имеющих карты лояльности, – десятки, а то и сотни тысяч. Совершенно очевидна необходимость системы, которая в автоматическом режиме выгружала бы данные об абонентах и предоставленных им услугах, рассчитывала бы баллы, полагающиеся каждому, и передавала бы их в учетную систему программы лояльности.

Нужно отметить, что исходные данные для расчетов находятся в нескольких БД, включая абонентскую базу и базу платежей. Алгоритмы расчета бонусов представляют собой наборы операций, сложность которых может быть совершенно разной – от простейших запросов к единственному источнику до сложной последовательности различных преобразований данных, полученных одновременно из нескольких систем, включая неограниченное количество условных переходов.

Эта задача может быть решена с помощью использования технологии ETL. Построенное решение по определенному расписанию будет запускать сложнейшие расчетные процедуры, в результате формируя данные по начисленным баллам. Более подробно о других решениях, построенных на базе этой технологии, вы можете прочитать во второй части – в № 1, 2013.

Как уже говорилось ранее, интеграционные задачи возникают практически при любом внедрении бизнес-приложений, но есть классы систем, в основе которых изначально лежит интеграционное решение. Примером здесь могут быть платформы класса ECM (Enterprise Content Management), ориентированные на обработку большого количества документов и любой неструктурированной информации, вплоть до аудио- и видеофайлов, а также данных из интернет-источников (более подробно – во второй части, в 1 1, 2013). В основе такого решения лежит хранилище, в которое посредством интеграции помещается информация любого требуемого типа. Перечислим некоторые виды такой интеграции. Во-первых, это сбор электронных документов из бизнес-приложений – контрактов, приказов и распоряжений, ордеров и т.п. К этому же типу задач можно отнести сбор в единое корпоративное хранилище электронных писем, отправляемых или получаемых сотрудниками. Во-вторых, это помещение в хранилище оцифрованных бумажных документов. В этом случае необходима интеграция со средствами сканирования и распознавания. И третий пример – это сбор информации из открытых источников, например, интернета. Представим себе сотрудника отдела маркетинга, ответственного за процесс формирования имиджа компании в СМИ. Одной из его задач является сбор данных об упоминаемости компании в различных источниках, в первую очередь в интернете. Ее решение может быть построено на основе автоматического сбора, структурирования информации по различным признакам (темам, авторам, источникам и т.п.) и ее помещения в единое хранилище. Совершенно очевидно, что такое решение требует интеграции с интернет-источниками.

Интеграция приложений

Интеграция бизнес-процессов

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

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

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

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

Критерий интегрируемости приложений

Представим, что вдруг кто-то, в какие-то времена (не обязательно сейчас, это могло быть и несколько лет назад) вдруг решил бы разработать свое собственное приложение таким образом, чтобы оно было максимально интегрируемым в некие глобальные приложения, на тот момент неизвестные и неопределенные. Что можно было бы посоветовать такому разработчику?

В первую очередь, вне зависимости от внутренней архитектуры приложения, этот человек должен был бы позаботиться о том, чтобы весь значимый прикладной функционал был доступен программно. На практике это означало бы, что для выполнения любой значимой внешне доступной прикладной операции можно было бы написать на любом (максимум) или на одном (минимум) языке программирования программу. Однако для этого данное приложение должно быть оснащено интерфейсом прикладного программирования (Application Programming Interface, API); будем для краткости называть его в рамках этой статьи программным интерфейсом. Таким образом, мы приходим к понятию индекса качества программного интерфейса. Его можно измерять в диапазоне от нуля до единицы, от полного отсутствия какого бы то ни было программного интерфейса до наличия исчерпывающе полного (в смысле доступности прикладной функциональности) программного интерфейса.

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

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

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

Анатомия приложений

Анализ внутренней конструкции приложений — обязательный этап в оценке степени интегрируемости тех приложений, которые предполагается связывать в рамках того или иного проекта. Этот анализ усложняется тем, что обычно разработчики приложений стараются скрыть детали внутренней конструкции приложений от интегратора (строго говоря, они и не обязаны ничего предоставлять интегратору), так как обладают авторским правом на разработанный ими программный продукт и от них никто и ничто (кроме советских ГОСТов) не требует предоставлять даже программный интерфейс, не говоря уже об анатомии приложения. Тем не менее, определенные заключения по анатомии приложения сделать все-таки можно и нужно.

История болезни

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

Причина заболевания

Диагностика

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

Промышленные приложения

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

Хотя, если рассуждать логически, все должно было бы быть устроено как раз наоборот. Допустим, компания разработала новое бизнес-приложение и выходит с ним на рынок. Помимо великолепных функциональных характеристик (они в первую очередь и интересуют потенциальных заказчиков), компания рекламирует и полнофункциональный и отлично документированный интерфейс прикладного программирования, представляющий для потенциальных заказчиков ценность с точки зрения интегрируемости нового приложения в их информационные системы. Однако в жизни происходит не так. Повсеместно рекламируется прикладной функционал, ведь целевая аудитория маркетинговой кампании — это управленцы, финансисты, производственники, специалисты по логистике и т.д. В тендерах на приобретение промышленных приложений конкурс проводится с безусловной ориентацией на прикладной функционал, технические требования обычно формальны и сводятся к поддержке общеупотребительных стандартов коммуникаций прикладного уровня. И ни слова о наличии хорошо документированного программного интерфейса! Нет такого требования в тендерах! А раз нет, то и нечего требовать от разработчиков прикладного программного обеспечения соответствия критерию интегрируемости, ведь заказчику-то это и не нужно (было бы нужно, то он уж обязательно бы позаботился об этом требовании, вписал бы его огромными буквами в запрос для предложения). Почему так происходит — тема следующего раздела.

Функциональный подход мешает интеграции

Интеграция на этапе разработки

Мы уже говорили, что лучшее решение задачи интеграции — это отсутствие какой бы то ни было интеграции. Звучит парадоксально, но, тем не менее, подход вполне реализуем, если считать, что интеграция осуществляется заранее, на этапе разработки полнофункционального комплекса бизнес-приложений. В свое время в Oracle, вдохновленные этой идей, разработали интегрированный набор приложений, который и сейчас сохранил свое название — Oracle E-Business Suite. Смена парадигмы была отражена даже в названии — от множества приложений (Oracle Applications) перешли тогда к единому набору Oracle E-Business Suite. Основная идея состояла в том, чтобы вообще отказаться от интеграции силами заказчика, переложить всю заботу об интеграции с плеч заказчика на плечи разработчика бизнес-приложений 2 .

Технологически задача интеграции решалась за счет использования единой централизованной базы данных (и соответственно, модели данных), а также единого технологического стека (СУБД — Oracle Database, сервер приложений — Oracle Application Server) и единой модели управления потоками работ.

Рис. 1. Гелиоцентрическая модель

Рис. 2. Другие модели интеграции

ESB расширяет исключительно плодотворную идею интеграционной шины предприятия за счет использования сервисов. Во многом — и концептуально, и технологически — ESB опирается на продукты класса Message Oriented Middleware (MOM), добавляя к традиционной транспортной среде, которая обеспечивалась продуктами наподобие IBM MQSeries или Oracle Advanced Queuing, применение сервисов со стандартизованными интерфейсами как универсальной среды интеграции. В этом смысле направление ESB весьма интересно и перспективно. Для российского рынка интеграционных решений, где превалируют задачи передачи данных от одного приложения другому, этот подход станет в течение 2007 года исключительно популярным.

Однако программные продукты категории ESB не решают и не могут решить вопрос ограниченности архитектуры унаследованных приложений и сложности их встраивания в системы с сервис-ориентированной архитектурой (Service-Oriented Architecture, SOA) с целью сделать их элементом композиционных приложений — для этого унаследованные приложения надо переписывать!

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

Что нового в интеграционных решениях

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

Ключевые различия приложений определяются тремя их архитектурными компонентами — моделью данных, которая лежит в их основе, технологическим стеком, на котором реализовано приложение (базовое программное обеспечение — среда времени исполнения, то есть СУБД, сервер приложений и т.д.), а также моделью бизнес-процессов. Различие в моделях бизнес-процессов (равно как и в механизмах их реализации) является главным препятствием для того, чтобы приложения стали частью глобального бизнес-процесса.

Заключение

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

Глеб Ладыженский — директор по технологиям Oracle СНГ. Изложенная в статье точка зрения может не всегда однозначно совпадать с позицией корпорации.

2 Сейчас, после приобретения PeopleSoft, J.D. Edwards, Siebel и других компаний, в Oracle вновь вернулись к термину Oracle Applications, так как теперь в ее арсенале несколько бизнес-приложений.— Прим. автора.

‒ Интеграция на уровне брокеров. Преимуществом данного метода является универсальность: как правило, в любой ситуации можно реализовать дополнительный программный модуль, который может обращаться в другие системы различными способами. Например, такой модуль может обращаться к одной системе через базу данных (БД), а к другой с помощью RPC (англ. Remote Procedure Call — Удалённый вызов процедур). Недостатками такого подхода интеграции является трудоёмкость и сложность реализации, и, как следствие, высокая стоимость разработки, внедрения и поддержки.

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

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

Недостатком интеграции такого вида является значительная трансформация или комплексный реинжиниринг всей сети процессов, что может повлечь за собой определённые риски. Целесообразно проводить данную интеграцию в случае, если организация готовится к внедрению корпоративной информационной системы (КИС) на платформе популярного решения. Это, в свою очередь, требует унификации и приведения бизнес-процессов к определённому стандарту. Или если организация перестраивает свою деятельность в связи со сменой приоритетов, расширением и освоением новых сегментов рынка.

‒ Интеграция на уровне корпоративных программных приложений. Данный вид интеграции предполагает совместное использование исполняемого кода, а не только внутренних данных интегрируемых приложений. Программы делятся на компоненты, которые затем интегрируются при помощи стандартизованных программных интерфейсов (API) и специализированного связующего программного обеспечения (ПО). Такой подход позволяет создать из этих компонентов универсальную программную платформу (ядро), которая может быть использовано всеми приложениями. Каждое приложение будет иметь только один интерфейс для взаимодействия с этим ядром, что значительно облегчает задачу интеграции. Систему, построенную на таком интеграционном подходе, легче администрировать, поддерживать и масштабировать. Возможность повторного использования функций в рамках имеющейся среды позволяет существенно сократить сроки и стоимость разработки приложений. Обязательным этапом оценки возможности интеграции приложений, которые предполагается связывать в рамках определённого проекта, является анализ внутренней архитектуры приложений. Этот анализ может быть осложнён тем, что, как правило, разработчик приложений, являющихся готовыми программными продуктами, не раскрывает всех деталей внутренней структуры приложений.

‒ Интеграция при помощи Web-сервисов. Данный вид интеграции является передовым и стремительно развивающимся подходом к интеграции приложений. Он базируется на предоставлении стандартного для Web-служб интерфейса доступа к приложениям и их данным. Примером может являться стандартный протокол доступа к объектам — SOAP (англ. Simple Object Access Protocol — простой протокол доступа к объектам). Так, при помощи SOAP, браузер пользователя может одновременно сравнить данные на нескольких выбранных веб-сайтах и представить клиенту сравнительный отчет. Другой пример: сотрудники одного географически распределенного предприятия могут единовременно использовать корпоративные приложения, доступ к которым осуществляется через соответствующие Web-сервисы (портальное решение). Web-сервисы похожи на подход EAI, но с одним главным отличием — EAI-решения, в своём множестве, выпускаются как частные случаи для связи определённых продуктов. Соответственно, подключить к уже используемому EAI-решению еще одну стороннюю систему будет довольно трудной и длительной задачей. По своей природе Web-сервисы существенно более унифицированы и стандартизованы. Поскольку Web-сервисы базируются на общих и единых для Консорциума Всемирной паутины (англ. World Wide Web Consortium, W3C-консорциум) стандартах, они могут работать везде, где используется сеть Интернет.

‒ Интеграция на уровне данных. Данный вид интеграции подразумевает, что несколько программных приложений могут обращаться к одной базе данных или в несколько баз данных, связанных репликациями. Преимуществом такого вида является низкая стоимость интеграции. К недостаткам можно отнести следующее: если база данных не экранирована хранимыми процедурами и не имеет необходимых ограничений и защиты целостности (например, в виде указания каскадных операций и триггеров), то взаимодействие различных приложений с данной БД может явиться причиной ошибок и приводить данные в противоречивые состояния. В случае если БД экранирована и поддерживается целостность хранимых данных, то в одновременно взаимодействующих с одной БД приложениях будут дублироваться части программного кода, выполняющие одинаковые или схожие операции. Кроме того, при внесении изменений в структуру базы, необходимо отдельно переписывать программный код всех приложений, работающих с такой БД.

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

Основные термины (генерируются автоматически): вид интеграции, приложение, SOAP, баз данных, Интеграция, API, EAI, OAPI, RPC, программный код.

Читайте также: