Определение

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

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

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

В идеале, дизайн отражает реализацию и, таким образом, можно ссылаться просто на компоненты, т.к. каждый компонент имеет дизайн и реализацию.

UML ([UML04]) так определяет "компонент":

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

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

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

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

заменяемость компонентов

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

Существуют другие более сильные типы заменимости. Они перечислены ниже.

заменяемость исходных файлов

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

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

заменяемость на уровне развертывания

Если два класса развернуты в одном исполняемом файле, то каждый из классов не заменяем независимо в развернутой системе.

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

Динамическая заменяемость

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

Прозрачность расположения

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

Моделирование компонентов

Компонент UML служит для построения моделей. Он предоставляет следующие возможности:

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

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

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

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

RUP рекомендует использование компонентов как представителей подсистем дизайна. Дополнительная информация находится в разделах Рабочие продукты: Подсистемы дизайна, Задача: Подсистемы дизайна и Рекомендации: Подсистемы дизайна. Также обратитесь к определениям в разделеКонцепция: Структурные классы.

Создание экземпляра компонента

Во время работы системы можно явно или неявно создавать экземпляр компонента.

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

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

Представление UML 1.x

UML 1.5 определяет "компонент" следующим образом:

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

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

С точки зрения моделирования компоненты сравниваются с подсистемами UML в UML версии 1.5, т.к. они обладали модульностью, инкапсуляцией и экземплярами, способными запускаться во время работы системы. RUP считает компонент построения моделей UML версии 1.5 альтернативной нотацией для представления Подсистем дизайна. Дополнительная информация находится в разделах Рабочий продукт: Подсистемы дизайна и Рекомендации: Подсистемы дизайна.

За дополнительной информацией обратитесь к разделу Различия между UML 1.x и UML 2.0 .