Рекомендации по построению диаграммы развертывания

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

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

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

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

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

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

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

Если необходимо включить в модель ресурсы Интернета, то на диаграмме развертывания Интернет часто обозначается в форме "облачка" с соответствующим именем. Строго говоря, подобное обозначение не специфицировано в языке UML, однако оно является общепринятым при разработке моделей web-приложений.

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