Исполняемая версия

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

Выпуск версий более сложных приложений уже представляет определенные трудности. Кроме главной исполняемой программы (обычно ехе-файл) нужен ряд, вспомогательных модулей, таких как библиотеки (обычно dll-файлы при работе в контексте СОМ+ или class- либо jar-файлы при работе с языком Java), файлы оперативной справки и файлы ресурсов. Для распределенных систем, вероятно потребуется несколько исполняемых программ и других файлов, разбросанных по разным узлам. Если вы работаете с системой приложений, то может оказаться так что одни компоненты уникальны, а другие используются в нескольких приложени­ях. По мере развития системы управление конфигурацией множества компонентов становится важной задачей, и сложность ее растет, поскольку изменение некоторых компонентов в одном приложении может сказаться на работе других.

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

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

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

1. Идентифицируйте набор компонентов, который вы хотите моделировать. Как правило, сюда войдут все или некоторые из компонентов, размещенные в одном узле, или же распределение таких наборов компонентов по всем узлам системы.

2. Примите во внимание стереотип каждого компонента в наборе. В большин­стве систем имеется лишь небольшое число различных видов компонентов (таких, как исполняемые программы, библиотеки, таблицы, файлы и доку­менты). Для визуального представления этих стереотипов можно восполь­зоваться механизмами расширения UML (см. главу 6).

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

В качестве примера на рис. 29.3 представлена модель части исполняемой версии автономного робота. Основное внимание обращено на компоненты развертывания, ассоциированные с функциями приводов робота и вычислительными операциями. Вы видите один компонент (driver -dll), который экспортирует интерфейс (iDrive), импортируемый другим компонентом (path. dll). driver .dll экс­портирует еще один интерфейс (ISelfTest), который, по всей видимости пользуется другими компонентами в системе, хотя они здесь и не показаны. На диаграмме присутствует еще один компонент (collision, dll), который также экспортирует набор интерфейсов, хотя их детали скрыты: показана лишь зависимость от path.dll к collision.dll. В системе участвует много компонентов. Но данная диаграмма сфокусирована лишь на тех компонентах развертывания, которые напрямую вовлечены в процесс перемещения робота. Заметьте, что в этой компонентной архитектуре вы могли бы заменить конкретную версию driver. dll на другую; при условии, что она реализует те же (и, возможно, некоторые дополнительные) интерфейсы, iath.dll продолжала бы работать правильно. Если вы хотите явно указать операции, реализуемые driver. dll, то всегда можно изобразить его интерфейсы с помощью нотации классов со стереотипом interface.