7.2. Проектирование архитектуры

Ниже в этом разделе мы намерены рассмотреть метод проектирования архитектуры, позволяющий удовлетворить как требования к качеству, так и функциональные требования. Его мы называем атрибутным методом проектирования (Attribute-Driven Design, ADD). Исходными данными для ADD является набор сценариев атрибутов качества, а также знания об отношениях между реализацией атрибутов качества и архитектурой. Метод ADD правомерно рассматривать как расширение большинства других методов разработки — в частности, рационального унифицированного процесса (Rational Unified Process, RUP). RUP включает этапы, связанные с высокоуровневым проектированием архитектуры, за которыми следуют действия, направленные на детальное проектирование и реализацию. В результате встраивания ADD в RUP этапы высокоуровневого проектирования подвергаются некоторым изменениям, однако весь последующий процесс остается без изменений.

Атрибутный метод проектирования

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

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

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

Метод ADD мы продемонстрируем на примере архитектуры линейки продуктов для открывателя гаражной двери в рамках домашней информационной системы. Предположим, что в обязанности открывателя входит поднятие и опускание Двери тремя способами: согласно положению переключателя, с пульта дистанционного управления (ПДУ), а также средствами домашней информационной системы. Будем также иметь в виду, что с помощью последней можно проводить Диагностику неисправностей открывателя.

Пример входных данных

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

В примере с гаражной дверью участвуют следующие сценарии атрибутов качества:

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

♦ Отличаются и процессоры, применяемые в разных продуктах. Архитектура продукта для каждого конкретного процессора должна напрямую выводиться из архитектуры линейки продуктов.

♦ Если в пространстве, занимаемой гаражной дверью, во время ее опускания обнаруживается препятствие (человек или любой другой объект), она должна остановиться (или, согласно другому варианту, полностью открыться) в течение 0,1 с.

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

Начало процесса ADD

Мы уже говорили об архитектурных мотивах. Метод ADD, предусматривающий предварительное выявление мотивов, может начаться лишь тогда, когда они станут известны в полном объеме. Вполне возможно, что в процессе проектирования приоритеты среды архитектурных мотивов придется реорганизовать — подобные явления вызываются, во-первых, новыми интерпретациями требовании, а во-вторых, их изменением. В любом случае, процесс не начнется до тех пор» пока в отношении основных требований не появится хоть какая-то ясность.

В следующем разделе мы приступим к непосредственному рассмотрению метода ADD.

Этапы ADD

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

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

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

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

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

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

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

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

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

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