А. Выбор архитектурных мотивов

Выбор модуля для декомпозиции

Этапы ADD

Начнем с краткого обзора этапов проектирования архитектуры методом ADD.

Затем мы Раскроем их содержание более подробно.

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

2. Уточнение модуля в несколько этапов:

a. выбор архитектурных мотивов из набора конкретных сценариев реализации качества и функциональных требований. На этом этапе определяются наиболее важные в контексте проведения декомпозиции моменты;

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

c. конкретизация модулей, распределение функциональности из элементов Use Case, составление нескольких представлений;

d. определение интерфейсов дочерних модулей. Декомпозиция имеет своим результатом новые модули, а также ограничения на типы взаимодействия между ними. Для каждого из модулей эти сведения следует зафиксировать в документации по интерфейсу;

e. проверка и уточнение элементов Use Case в сценариях качества и наложение, исходя из них, ограничений на дочерние узлы. На этом этапе мы проверяем, все ли факторы учли, а также, в расчете на последующую декомпозицию или реализацию, подготавливаем дочерние модули.

3. Вышеперечисленные этапы следует выполнить в отношении всех нуждающихся в дальнейшей декомпозиции модулей.

Система, подсистема и подмодуль — все это модули. Как правило, декомпозицию начинают с системы; она разбирается на подсистемы, а те в свою очередь — на подмодули.

В нашем примере в роли системы выступает открыватель гаражной двери. На этом уровне существует единственное ограничение — открыватель должен предусматривать возможность взаимодействия с домашней информационной системой.

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

В частности, архитектурными мотивами являются четыре представленных выше сценария. В системах, с оглядкой на которые мы составляли этот пример,

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

Выявление архитектурных мотивов далеко не всегда проходит по нисходящей. Иногда для того, чтобы уяснить все ветвления тех или иных требований, не обойтись без детальных аналитических действий. К примеру, довольно трудно бывает определить роль производительности в контексте конкретной конфигурации системы в отсутствие ее о ыт o'i реализации. Не ознакомившись с механиков гаражной двери и скоростью предполагаемых процессоров, мы вряд ли смогли бы возвести требование по производительности в ранг архитектурного мотива.

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

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