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

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

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

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

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

Организация компонентов

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

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

Стандартные элементы

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

В UML определены пять стандартных стереотипов (см. «Приложение В»), применимых к компонентам:

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

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

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

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

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

Примечание UML не определяет пиктограмм для этих стереотипов, хотя в «При -ложении В» предлагается некоторая общепринятая нотация.

Типичные приемы моделирования Исполняемые программы и библиотеки

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

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

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

Моделирование исполняемых программ и библиотек осуществляется следую­щим образом:

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

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

3. Если для вас важно управлять стыковочными узлами системы, смоделируй­те важнейшие интерфейсы, которые одни компоненты должны реализовы­вать, а другие - использовать.

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

Например, на рис. 25.5 показан набор компонентов, входящий в состав инстру­ментальной программы, работающей на одном персональном компьютере. Мы видим одну исполняемую программу (animator. ехе с помеченным значением, обозначающим номер версии) и четыре библиотеки (diog.dll, wrfrme.dll, render, dll и raytrce .dll). Для изображения компонентов использованы стандартные элементы (см. «Приложение В») для исполняемых программ и биб­лиотек. На диаграмме представлены также зависимости между компонентами.

Примечание Непосредственный показ зависимости между двумя компонента­ми - это на самом деле свернутая форма представления реальных отношений между ними. Компонент редко зависит от другого ком­понента напрямую; чаще он импортирует один или несколько ин­терфейсов, экспортируемых вторым компонентом. Можно было бы, к примеру, изменить представленную на рис. 25.5 диаграмму, явно указав интерфейсы, которые реализует (экспортирует) render. dll и использует (импортирует) animator. ехе. Но для просто­ты эти детали можно скрыть, показав лишь, что существует за-виси^лость между компонентами.

По мере разрастания модели вы обнаружите, что многие компоненты объ­единяются в концептуально и семантически связанные группы. В UML для мо­делирования таких групп можно использовать пакеты (см. главу 12).

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

Таблицы, файлы и документы

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

Моделирование таблиц, файлов и документов осуществляется так:

1. Выявите те вспомогательные элементы, которые являются частью физичес­кой реализации системы.

2. Смоделируйте их в виде компонентов. Если в вашей реализации появляют­ся новые виды артефактов, введите подходящий новый стереотип.

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

Так, на рис. 25.6, расширяющем предыдущий, показаны таблицы, файлы и до­кументы, которые являются частью развернутой системы, построенной вокруг программы animator, ехе. Мы видим один документ (animator .hip), один простой файл (animator. ini) и одну таблицу базы данных (shapes . tbi). Для их изображения используются соответствующие стандартные элементы UML.

Моделирование баз данных (см. главы 8 и 29) может усложниться, если прихо­дится иметь дело с несколькими таблицами, триггерами и хранимыми процедура­ми. Для визуализации, специфицирования, конструирования и документирования

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