Адаптивные системы

Все продемонстрированные до сих пор диаграммы компонентов использовались для моделирования статических видов системы. Участвующие в них компоненты проводили всю свою жизнь на одном узле. Хотя такая ситуация является наиболее распространенной, иногда, особенно при работе со сложными распределенными сис­темами, приходится моделировать и динамические представления. Например, не­которая система может реплицировать свои базы данных на несколько узлов и пе­реключаться на резервный сервер в случае отказа главного. При моделировании глобальной распределенной системы, работающей в режиме 24х7 (то есть семь дней в неделю, 24 часа в сутки) вы, скорее всего, встретитесь с мобильными агентами -компонентами, которые мигрируют с одного узла на другой для выполнения некото­рой операции. Для того чтобы моделировать такие динамические представления, вам понадобится комбинировать диаграммы компонентов, объектов и взаимодействия.

Моделирование адаптивной системы производится так:

1. Рассмотрите физическое распределение компонентов, которые могут мигри­ровать с одного узла на другой. Специфицировать положение экземпляра ком­понента можно с помощью помеченного значения location (см. главу 23), изобразив его затем на диаграмме компонентов (хотя, строго говоря, диаграм­ма, содержащая только экземпляры, - это диаграмма объектов, см. главу 15.

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

Например, на рис. 29.5 представлена модель репликации базы данных, изображен­ной на предыдущем рисунке. Мы видим два экземпляра компонента school. db - оба анонимны и имеют разные помеченные значения location. Есть также примечание, в котором явно поясняется, какой экземпляр первичен, а какой является репликой.

При желании показать детали каждой базы данных вы можете изобразить и в канонической форме - в виде компонента со стереотипом database.

Хотя на рисунке это не показано, допустимо воспользоваться диаграммой взаимодействия (см. главу 18) для моделирования динамики переключения с главной сервера на резервный.

Прямое и обратное проектирование

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

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

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

1. Для каждого компонента идентифицируйте реализуемые им классы или кооперации.

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

3. Используйте инструментальные средства для прямого проектирования модели.

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

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

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

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

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

В качестве примера на рис. 29.6 представлена диаграмма компонентов, полу­ченная в результате обратного проектирования компонента ActiveX vbrun.dll. Видно, что компонент реализует 11 интерфейсов. Имея такую диаграмму, вы на­чинаете понимать семантику компонента и можете переходить к исследованию деталей интерфейсов.

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

Советы

Создавая в UML диаграммы компонентов, помните, что каждая такая диаграм­ма - это графическое представление статического вида системы с точки зрения реализации. Ни одна отдельно взятая диаграмма компонентов не должна показы­вать все, что известно о системе. Собранные вместе, диаграммы компонентов дают полное представление о системе с точки зрения реализации, по отдельности же каждая диаграмма описывает лишь один аспект.

Хорошо структурированная диаграмма компонентов обладает следующими свойствами:

• фокусирует внимание на каком-то одном аспекте статического представле­ния системы с точки зрения реализации;

• содержит только те элементы, которые существенны для понимания этого аспекта;

• раскрывает только те детали, которые находятся на выбранном уровне аб­стракции;

• не является настолько краткой, чтобы скрыть от читателя важную семантику.

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

• дайте ей имя, соответствующее назначению;

• располагайте элементы так, чтобы число пересечений было минимальным;

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

• используйте примечания и цвет для привлечения внимания к важным осо­бенностям диаграммы;

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