Файл: Учебное пособие.doc

Принцип этот полезен тем, что он помогает разбить проблему документирования архитектуры на ряд менее обширных элементов:

• выбор значимых представлений;

• документирование представления;

• документирование сведений, относящихся к нескольким представлениям.

4.3.2.1.Выбор значимых представлений

Какие представления следует считать значимыми? Для ответа на этот вопрос необходимо знать заинтересованных лиц и предпочтительные для них способы пользования документацией — лишь располагая этими сведениями, вы сможете составить удобный для них пакет документации. Любой вариант применения архитектуры — как средства постановки задач конструкторов, основы для изучения системы, восстановления ее свойств или планирования проекта — можно свести к отдельному заинтересованному лицу, предполагающему задействовать документацию архитектуры соответствующим образом. Не менее серьезное влияние на выбор представлений для дальнейшего документирования оказывают наиценнейшие для большинства заинтересованных в разработке системы лиц атрибуты качества. К примеру, многоуровневое представление (layered view) сообщает сведения о переносимости системы. По представлению размещения (deployment view) можно судить о производительности и надежности системы. И так далее. За отражение этих атрибутов качества в документации ратуют аналитики (а быть может, и сам архитектор), в задачу которых входит проверка архитектуры на предмет ее им соответствия.

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

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

1. Составьте список возможных представлений. Начните с составления для своего проекта таблицы заинтересованных лиц/представлений. В столбцах выразите применимые к вашей системе представления. Некоторые из них (например, модульное представление и представление вариантов использования) носят универсальный характер; иные (многоуровневое представление, а также большинство представлений из группы «компонент и соединитель» — в частности, клиент-серверное представление и представление совместно используемых данных) подходят только для соответствующим образом спроектированных систем. Разобравшись с содержанием строк и столбцов, заполните все ячейки, отразив в них степень детализации сведений о каждом представлении, необходимую тем или иным заинтересованным лицам: здесь возможны произвольная детализация, обзор, средняя или высокая детализация.

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

3. Расставляйте приоритеты. Представления, оставшиеся после выполнения второго этапа, должны соответствовать потребностям сообщества заинтересованных лиц. Теперь необходимо решить, какие из этих представлений имеют первостепенное значение. Конкретное решение зависит от деталей проекта; впрочем, вы в любом случае должны помнить, что полностью завершать работу над одним представлением, прежде чем приступать к следующему, совершенно не обязательно. Информация, детализированная на уровне обзора, представляет некоторую ценность, так что наши предпочтения — на стороне метода разработки материала «в ширину». Кроме того, интересы одних заинтересованных лиц в ряде случаев ставятся выше интересов других.

4.3.3.Документирование представления

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

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

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

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

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

Кроме того, в каталоге обязательно должны разъясняться все элементы и отношения, значимые для данного представления, но по каким-то причинам не показанные в первичном отображении.

3. На контекстной диаграмме (context diagram) должно быть показано отношение изображенной в представлении системы к своему окружению из словаря представления. К примеру, представление «компонент и соединитель» подразумевает демонстрацию взаимодействия отдельных компонентов и соединителей с внешними компонентами и соединителями через по средство интерфейсов и протоколов.

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

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

• время связывания альтернатив. Одни решения принимаются в период проектирования, другие — в период производства, третьи — в период исполнения.

5. Предпосылки архитектурного решения (architecture background) — это раздел, в котором содержится обоснование отраженного в данном представлении проектного решения. Цель его — объяснить читателю, почему проект выглядит так, как он выглядит, и представить убедительные аргументы его превосходства. В состав этого раздела входят следующие элементы:

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

• результаты анализа, оправдывающие проектное решение и объясняющие последствия модификаций;

• отраженные в проектном решении допущения.

6. Глоссарий терминов (glossary of terms), применяемых в представлениях, и краткое описание каждого из них.

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

4.3.3.1.Документирование поведения

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

Схемы состояний как формализм появились в 1980-х годах и изначально предназначались для описания реактивных систем. Ряд реализованных в них полезных расширений дополняет традиционные диаграммы состояний (такие, как вложенность состояний и состояния «и») и придает выразительность абстракции и параллелизму моделей. Схемы состояний позволяют рассуждать о системе в целом. Предполагается отображение всех ее состояний, а методики анализа в отношении системы приобретают универсальный характер. Становятся возможными ответы на вопросы типа: «Всегда ли время отклика на данный стимул будет меньше 0,5 секунды?»

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

4.3.3.2.Документирование интерфейсов

Интерфейс (interface) — это граница, на которой встречаются, взаимодействуют между собой или передают друг другу информацию две независимые сущности.

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

Под документированием интерфейса подразумевается указание его имени, идентификация, а также отражение всех синтаксических и семантических сведений о нем. Первые два элемента — указание имени и идентификация — обобщенно называются «сигнатурой» интерфейса. Если в качестве ресурсов интерфейса выступают вызываемые программы, сигнатура обозначает их и определяет их параметры. Параметры определяются по порядку, типу данных и (иногда) по принципу возможности изменения их значений программой. Та информация о программе, которая содержится в сигнатуре, обычно приводится в заголовочных файлах С или C++ и в интерфейсах Java.

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