Ь. Выбор архитектурного образца

На материале главы 5 мы установили, что каждому атрибуту качества соответствует ряд очевидных тактик реализации (а также образцов, посредством которых эти тактики проводятся в жизнь). Каждая из этих тактик обеспечивает реализацию одного из нескольких атрибутов качества. Шаблоны, в которые они заключены, в свою очередь оказывают воздействие на другие атрибуты качества. Сочетание ряда тактик в архитектурном проектировании призвано сбалансировать все предполагаемые атрибуты качества. Анализ реализации требований к качеству и функциональных требований проводится на этапе уточнения.

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

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

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

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

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

♦ Разумное планирование. Критичные с позиции производительности вычисления следует планировать в расчете на соблюдение требований по времени.

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

2с. Конкретизация модулей и распределение функциональности посредством проекций

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

Конкретизация модулей. В схеме, приведенной на рис. 7.2, участвуют некритичные с точки зрения производительности вычисления; изображены они выше виртуальной машины, ответственной за передачу данных и взаимодействие с датчиками. Поверх виртуальной машины, как правило, исполняется приложение. 

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

К примеру, обязанности, связанные с обнаружением препятствий и остановкой гаражной двери, вследствие наличия требований по времени относятся к категории критичных. Управление поднятием и опусканием двери в нормальном режиме не связано с какими-либо ограничениями по времени, поэтому эти действия, напротив, рассматриваются как некритичные. Туда же относим и диагностику. Итак, конкретизация модуля некритичных с точки зрения производительности действий с рис. 7.2 конкретизируется в виде модулей диагностики и поднятая/ опускания двери, изображенных на рис. 7.3. Кроме того, ряд обязанностей — передача информации, считывание показаний датчиков и управление силовым приводом — отходит к виртуальной машине. Отсюда — два экземпляра виртуальной машины, которые также представлены на рис. 7.3.

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

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

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

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

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

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

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

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

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

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

Уяснить параллелизм в системе помогают нижеследующие элементы Use Case.

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

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

- Запуск системы. Здесь дается отличная перспектива постоянных операций системы и механизмов их инициализации. Данный элемент, кроме тою, упрощает задачу принятия решения относительно стратегии инициализации — это может быть любая модель, включая «все параллельно» пли «все последовательно». Если обратиться к нашему примеру, разумным представляется такой вопрос: зависит ли возможность запуска системы открывателя гаражной двери от готовности домашней информационной системы? Находится ли система открывателя гаражной двери в постоянной готовности? Может быть, она ожидает поступления сигнала или запускается и останавливается каждый раз при открытии и закрытии двери?

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

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

Параллелизм также может быть изменяемым параметром; именно такой случай рассматривается в главе 14, посвященной линейкам программных продуктов. Для одних продуктов подходит последовательная инициализация, для других — параллельная. Если декомпозиция не предусматривает механизма изменения метода инициализации (например, путем обмена компонентов), значит, такую декомпозицию следует скорректировать.

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

Ее применение приводит к декомпозиции виртуальных потоков представления параллелизма на виртуальные потоки в рамках конкретного процессора, с одной стороны, и сообщения, которые, перемещаясь от процессора к процессору, инициируют каждое последующее действие, — с другой. Таким образом, представление размещения оказывается основой для анализа сетевого трафика и выявления потенциальной перегрузки.

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

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

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

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