Отношения между компонентами

Виды компонентов

Можно выделить три вида компонентов.

Во–первых, это компоненты размещения (Deployment components), которые необходимы и достаточны для построения исполняемой системы. К их числу относятся динамически подключаемые библиотеки (DLL) и исполняемые программы (ЕХЕ). Определение компонентов в UML достаточно широко, чтобы охватить как классические объектные модели, вроде СОМ+, CORBA и Enterprise JavaBeans, так и альтернативные, возможно содержащие динамические Web–страницы, таблицы базы данных и исполняемые модули, где используются закрытые механизмы коммуникации.

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

В–третьих, существуют компоненты исполнения (Execution components); Они создаются как результат работы системы. Примером может служить объект СОМ+, экземпляр которого создается из DLL.

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

В UML определены пять стандартных стереотипов, применимых к компонентам:

executable (исполнимый) – определяет компонент, который может исполняться в узле;

library (библиотека) – определяет статическую или динамическую объектную библиотеку;

table (таблица) – определяет компонент, представляющий таблицу базы данных;

file (файл) – определяет компонент, представляющий документ, который содержит исходный текст или данные;

document (документ) – определяет компонент, представляющий документ.

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

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

Другим случаем отношения зависимости на диаграмме компонентов является отношение программного вызова и компиляции между различными видами компонентов. Для рассмотренного фрагмента диаграммы компонентов (рис. 6.101.) наличие подобной зависимости означает, что исполнимый компонент Control.exe использует или импортирует некоторую функциональность компонента Library.dll, вызывает страницу гипертекста Home.html и файл помощи Search.hlp, а исходный текст этого исполнимого компонента хранится в файле Control.cpp. При этом характер отдельных видов зависимостей может быть отмечен дополнительно с помощью текстовых стереотипов.

Рис. 6.101. Графическое изображение отношения зависимости между компонентами

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

Рис. 6.102. Графическое изображение зависимости между компонентом и классами

Дата добавления: 2014-01-07