Представления распределения

Диаграмма размещения в UML представляет собой граф с узлами, соединенными посредством коммуникативных ассоциаций. Соответствующий пример приводится на рис. 9.13. Если узел содержит экземпляры того или иного компонента, значит, этот компонент существует или исполняется именно на нем. В составе компонентов могут находиться объекты, что, опять же, указывает на принадлежность данного объекта данному компоненту. Если соединение одних компонентов с другими обозначается пунктирной стрелкой зависимости (иногда — через интерфейсы), значит, один из этих компонентов обращается к службам других; при необходимости обозначения точной зависимости можно создать специальный стереотип. Помимо прочего, на диаграмме типа размещения можно показать, на каких узлах могут исполняться те или иные компоненты — для этого предназначены пунктирные стрелки со стереотипом «supports».

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

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

Вложенность символов в составе символа узла свидетельствует о композиционной ассоциации между узловым и внутренними классами или о композиционной связи между узловым и внутренними объектами.

Заключение

Грош цена той архитектуре, в которой никто не может разобраться. Этап документирования завершает процесс разработки архитектуры. На этом этапе архитектор ставит перед собой две задачи: во-первых, описать архитектуру в целях ознакомления с ней настоящих и будущих заинтересованных лиц, а во-вторых, избавить себя от необходимости отвечать на тысячи вопросов.

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

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

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

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

Дополнительная литература

Значительная часть материала этой главы приводится в адаптированном виде по изданию [Clements 03]. В нем анализ архитектурной документации дается в более подробном виде. В документе [IEEE 00] изложен универсальный для всего сообщества стандарт документирования архитектуры, который, находясь в согласии с вышеприведенными данными, основывается на несколько отличной терминологии.

Добротных справочников по UML довольно много, однако наиболее удачным и полным до сей поры считается самый первый, хрестоматийный труд [Rum- baugh 99]. Рабочая группа OMG в настоящее время трудится над новой версией UML, ориентированной на более полное отображение программной архитектуры систем. Следить за ходом работ помогает сайт http://www.omg.org/uml/.

Дискуссионные вопросы

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

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

3. Какая документация требуется для проведения анализа производительности?