Дискуссионные вопросы. Дополнительная литература

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

Заключение

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

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

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

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

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

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

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

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

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

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

Глава 10

Дата добавления: 2015-04-25