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

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

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

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

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

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

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

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

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

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

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

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

В главе 12 некоторые из этих аспектов будут рассмотрены более подробно на примере CASE-средства Rational Rose 98/981.