Архитектура определяет важнейшие компоненты системы и их взаимодей& ствие. Она не описывает их устройство.

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

Хорошая архитектура оставляет пространство для маневра; она позво% ляет изменить свое решение. В ней может быть определено, что компо% ненты сторонних разработчиков будут заключены в оболочки абстракт% ных интерфейсов, а потому не составит труда заменить одну их версию другой. Можно предложить технологии, позволяющие выбирать между различными реализациями во время развертывания. По мере того как проект набирает силу, становится ясным, какие варианты реализации нужно выбрать, что не всегда очевидно на ранних стадиях. Удачная ар% хитектура должна быть гибкой, чтобы быстро менять решения во время начальной неопределенности. Архитектура – первая точка, где проис% ходит уравновешивание противодействующих сил; она показывает, ка% кие уступки мы делаем в пользу одного качества и в ущерб другому.

Хорошая архитектура оставляет пространство для маневра, расширения, модификации. Но ее общность не переходит разумных границ.

Архитектура должна быть ясной и недвусмысленной. Предпочтитель% нее хорошо знакомые архитектурные стили и известные структуры (подробнее о них см. в следующем разделе). Архитектура должна быть простой для понимания и легкой для работы.

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

доверие.

Архитектурные стили

Форму в архитектуре определяет функция.

Луис Генри Салливен

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

Определить архитектуру необходимо, если вы собираетесь создать хо% роший программный продукт. Без планирования архитектуры вы за% ранее обрекаете свою разработку на гибель.

Каждая компонента представлена одним блоком в стопке. Расположе% ние их в стопке показывает, что где находится, как связаны между со% бой компоненты и каковы возможности одних компонент «видеть» другие. Блоки могут размещаться бок о бок на одном уровне и иметь высоту, охватывающую два уровня. Известным примером служит се% миуровневая эталонная модель OSI для систем сетевой связи (ISO 84). Интереснее семиуровневая модель бисквита «Гудлифс», показанная на рис. 14.1.

На нижнем уровне стека располагается аппаратный интерфейс, если система действительно взаимодействует с физическими устройствами.

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

Влюбой момент можно выкинуть находящиеся внизу уровни и вста% вить новую реализацию низлежащего уровня – система продолжит ра% боту, как прежде. Это важный момент: он означает, что вы можете вы% полнять один и тот же код C++ на любой платформе, поддерживаю% щей вашу среду C++. Можно перейти на другую аппаратную платфор% му, не меняя код приложения, – уровень ОС (например) переварит все технические отличия. Удобно.

Верхние уровни пользуются открытыми интерфейсами уровней, нахо% дящихся непосредственно под ними. Смогут ли они пользоваться от% крытыми интерфейсами еще более глубоко расположенных уровней, зависит от того, как вы определите уровни. Иногда диаграмму подра% батывают так, чтобы она отражала такую возможность, как в случае

Сливки

Заварной крем

Малиновое желе

Кусочки фруктов

Херес

Бисквит

Чашка

Рис. 14.1. Семиуровневая эталонная модель бисквита «Гудлифс»

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

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

Архитектура с каналами и фильтрами

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

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

Архитектура каналов и фильтров требует четкого определения струк% туры данных, которые проходят через фильтры; неявно возникают на% кладные расходы в связи с повторяющимся кодированием выходных данных для передачи по каналу и обратным анализом их на входе ка% ждого фильтра. По этим причинам поток данных обычно организован очень просто – в формате простого текста.

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