Программный компонент

Термин «компонент» происходит от латинского componere («составлять»). В программной инженерии понятие компонента употребляется в различных смыслах. Часто это слово ошибочно используется как синоним модуля, что подчеркивает схожесть обоих понятий (см. раздел «Компонентные интерфейсы»).

В 1996 году на Европейской конференции по объектно-ориентированному программированию (ECOOP) программный компонент был определён следующим образом:

«Программный компонент — это элемент сборки с контрактно определёнными интерфейсами и исключительно явно заданными контекстными зависимостями. Программный компонент может распространяться независимо и использоваться третьими сторонами в их собственных сборках.»^[1]

В более общем виде и в контексте нового подхода компонентно-ориентированной разработки можно дать другое определение компонента:

«Программный компонент — это программный элемент, соответствующий компонентной модели и способный без изменений связываться и выполняться с другими компонентами в соответствии со стандартом композиции.»^[2]

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

Интерфейс компонента — это определённый контракт (англ. interface) между компонентом и остальной частью программного обеспечения. Интерфейс можно рассматривать как договор между компонентом и программной системой. Благодаря явному описанию контекстных зависимостей становится ясно, насколько компонент независим от окружающей среды.

Интерфейсы и чётко определённые условия контекста обеспечивают повторное использование компонента. Чем меньше контекстных зависимостей у компонента, тем меньше требований нужно соблюдать для его применения. Следовательно, чем меньше зависимостей, тем проще повторное использование; в то же время низкая степень зависимости позволяет независимо развивать и сопровождать компонент. Однако высокая независимость компонентов зачастую приводит к появлению избыточности — разработчику приходится искать компромисс.

Интерфейс компонента можно сравнить с контрактом между компонентом и программной системой. Интерфейс задаёт, как компонент может быть повторно использован, и определяет, как другие компоненты могут с ним взаимодействовать.

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

Могут выделяться различные типы интерфейсов. Примеры разных видов интерфейсов компонентов:

• Графический пользовательский интерфейс (GUI), также известный как человеко-машинный интерфейс (HMI): позволяет пользователю взаимодействовать с компонентом с помощью графического интерфейса (например, мышь, экран).
• Командная строка (CLI): особенно актуальна, когда компоненты должны вызываться системой без участия пользователя, например, для выполнения повторяющихся задач по расписанию; взаимодействие — через ввод команд в терминал.
• Данные-интерфейсы: позволяют компоненту читать и записывать собственные данные; обычно к такому интерфейсу обращаются из внутреннего кода программы.
• Программный интерфейс (API): предоставляет программисту или другим компонентам доступ к функциональности и сервисам компонента через программные вызовы. В дальнейшем под интерфейсом чаще всего подразумевается именно API компонента.

Один компонент может иметь несколько интерфейсов одного типа — например, чтобы интегрироваться в разные системы, что расширяет возможности повторного использования.

Разработка компонентов направлена на снижение издержек и повышение гибкости в разработке продуктов^[3]. Возросшие затраты на создание компонента окупаются за счет его повторного использования. Использование компонентов ускоряет процесс разработки, поскольку в идеале сводится к их компоновке и настройке (см. также модульность).

Компоненты могут содержать ошибки. Отсюда вытекает ещё одно требование: независимость компонента означает, что он должен самостоятельно обрабатывать свои ошибки, становясь замкнутой единицей^[4]. В случае ошибки её легче локализовать. Исключение из этого правила возможно только тогда, когда соответствующее поведение оговорено контрактом интерфейса. Таким образом, ошибка в компоненте не приводит к некорректной работе всей системы компонентов, поскольку поведение определено контрактом. Всё это также способствует снижению расходов на поддержку и разработку.

В зависимости от формы повторного использования программные компоненты условно делятся на следующие типы:

blackbox

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

whitebox

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

greybox

Промежуточные формы между blackbox и whitebox.

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

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

По мнению специалистов, компонентные технологии в программном обеспечении являются краеугольным камнем программных разработок ближайших лет^[4]. Существует несколько стандартов; помимо CORBA, большинство из них являются специфичными для конкретных языков программирования, приложений или платформ, формируя так называемые компонентные миры или рынки. Примеры таких миров:

• Microsoft (.NET Framework, .NET, COM, DCOM, OLE, ActiveX, COM+)
• Object Management Group (CORBA)
• Sun Microsystems (JavaBeans, серверлеты, апплеты, Enterprise JavaBeans)
• OSGi Alliance (OSGi)

Для компонентно-ориентированной разработки существуют специальные интегрированные среды разработки и языки программирования, например:

• Advanced Component Framework
• BlackBox Component Builder
• Component Pascal