Понятие об интеграции программного обеспечения. Компонентная архитектура приложений

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

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

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

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

Преимущества использования компонентной архитектуры:

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

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

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

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

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

Программа или компонент, использующие другой компонент, называются клиентом (client). Клиент подсоединяется к компоненту через интерфейс (interface).

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

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

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

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

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

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

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

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