Типичные примеры применения

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

При моделировании статического вида системы с точки зрения реализации диаграммы компонентов, как правило, используются в четырех случаях:

• моделирование исходного кода. В большинстве современных объектно-ориен­тированных языков программирования код пишется в интегрированных сре­дах разработки, которые сохраняют исходные тексты в файлах. Диаграммы компонентов можно применять для моделирования управления конфигури­рованием этих файлов, которые представляют собой компоненты - рабочие продукты;

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

• моделирование физических баз данных. Представляйте себе физическую базу данных как конкретную реализацию схемы, существующую в мире битов. Схемы, по сути дела, описывают API для доступа к хранимой информации; модель же физической базы данных (см. главу 8) представляет способы хранения этой информации в таблицах реляционной базы данных или на страницах объектно-ориентированной БД. Для представления этих и иных видов физи­ческих баз данных вы можете пользоваться диаграммами компонентов;

• моделирование адаптивных систем. Некоторые системы абсолютно статич­ны - их компоненты появляются на сцене, принимают участие в выполне­нии, а затем покидают сцену. Другие системы более динамичны; они вклю­чают мобильных агентов или компоненты, которые мигрируют с целью выравнивания нагрузки и восстановления после сбоев. Для представления таких систем применяются диаграммы компонентов совместно с некоторы­ми другими диаграммами UML.

Типичные приемы моделирования Исходный код

При разработке программы на языке Java исходный код обычно сохраняют в файлах с расширением java. Программы, написанные на языке C++, обычно хранят исходный код в заголовочных файлах с расширением . h и в файлах реали­зации с расширением . срр. При использовании языка IDL для разработки при­ложений СОМ+ или CORBA один, с точки зрения проектирования, интерфейс распадается на четыре исходных файла: сам интерфейс, клиентский заместитель (Proxy), серверная заглушка (Stub) и класс-мост (Bridge class). По мере роста объема приложения, на каком бы языке оно ни было написано, эти файлы придет­ся организовывать в группы. Затем, на стадии сборки приложения, вы, вероятно станете создавать различные варианты одних и тех же файлов для каждой новой промежуточной версии, и захотите поместить все это в систему управления кон­фигурацией.

В большинстве случаев нет необходимости моделировать этот аспект системы напрямую. Вместо этого вы сообщаете среде разработки, что надо следить за файла­ми и их отношениями. Иногда, однако, бывает полезно визуализировать исходные файлы и связи между ними с помощью диаграмм компонентов. Применяемые та­ким образом диаграммы компонентов обычно содержат только компоненты - рабо­чие продукты со стереотипом file (см. главу 25), а также отношения зависимости между ними. Например, вы могли бы выполнить обратное проектирование набора исходных файлов для визуализации сложной системы зависимостей между ними при компиляции. Можно пойти и в другом направлении, специфицировав отно­шения между исходными файлами и подав затем эту модель на вход средства компиляции, например make в ОС UNIX. Точно так же можно использовать диа­граммы компонентов для визуализации истории набора исходных файлов, хра­нящихся в системе управления конфигурацией. Получая информацию от этой системы, например о том, сколько раз некоторый файл извлекался для редактиро­вания на протяжении определенного периода времени, вы вправе воспользоваться ею для раскрашивания диаграмм компонентов. Это поможет выявить среди исход­ных файлов «горячие точки», в которых архитектура системы наиболее часто под­вергается модификации.

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

1. С помощью прямого или обратного проектирования идентифицируйте пред­ставляющие интерес наборы исходных файлов и смоделируйте их в виде компонентов со стереотипом file.

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

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

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

В качестве примера на рис. 29.2 показано пять исходных файлов, из которых signal. h - заголовочный. Приведены три его версии начиная с самой последней. Каждая версия помечена значением, содержащим ее номер.

Этот заголовочный файл (signal .h) используется двумя другими файлами Onterp. срр и signal. срр). Один из них (interp. срр) зависит при компиля­ции от другого заголовочного файла (irq.h). В свою очередь файл device, срр зависит от interp. срр. При наличии такой диаграммы компонентов легко просле­дить, что произойдет при изменениях. Так, изменение исходного файла signal .h потребует перекомпиляции Jpex других файлов: signal. срр, infcerp. срр и, транзитивно, device. срр. Из той же диаграммы видно, что файл irq. h такое измене­ние не затронет.

Подобные диаграммы легко генерируются путем обратного проектирования на

основе информации, хранящейся в системе управления конфигурацией.