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

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

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

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

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

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

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

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

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

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

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