2.4. Почему программная архитектура так важна?

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

1. Взаимодействие между заинтересованными лицами. Программная архитек­тура — это универсальная абстракция системы, на основе которой все или почти все заинтересованные в системе лица могут искать взаимопонима­ния, вести переговоры, находить компромиссы и просто общаться.

2. Начальные проектные решения. Программная архитектура содержит сведе­ния о том, какие решения были приняты на ранних этапах разработки си­стемы. Значимость подобного рода сводок отнюдь не ограничивается удель­ным весом этих этапов относительно оставшихся операций разработки, размещения и сопровождения. Именно в это время впервые появляется возможность анализа проектных решений, определяющих дальнейшую раз­работку системы.

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

Каждый из этих вопросов мы обсудим отдельно.

Архитектура как средство организации общения между заинтересованными лицами

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

разработчиков, их четкого и управляемого взаимодействия. Архитектор думает о том, какие стратегии позволят ему реализовать все эти задачи.

Архитектура — это общий язык, на котором можно сформулировать, обгово­рить и решить те или иные проблемы, причем сделать это на таком уровне, кото­рый, даже если речь идет о сложных системах, вполне доступен для комплексно­го изучения человеком (см. врезку «Что будет, если нажать эту кнопку?»). В отсутствие такого языка анализ крупных систем на ранних этапах сильно за­трудняется; сложнее становится и принимать значимые решения, определяющие качество и полезность. Как мы увидим на материале части 3, архитектурный ана­лиз одновременно отталкивается от этого уровня общения и вносит в него неко­торые коррективы.

ЧТО БУДЕТ, ЕСЛИ НАЖАТЬ ЭТУ КНОПКУ?

Архитектура как средство организации общения между заинтересованными лицами

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

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

«А что произойдет при нажатии кнопки выбора режима работы?» — внезапно прервал его один из слушателей. Им оказался представитель правительства — предполагаемого коллек­тива пользователей обсуждаемой системы.

«Простите?» — Архитектор не понял вопроса.

«Кнопка выбора режима работы, — повторил человек из правительства. — Что будет, если я ее нажму?»

«Ну-у, при этом запускается событие в драйвере устройства, вот здесь, — начал архитек­тор, манипулируя указкой. — Затем считываются данные в регистре, интерпретируется код события. Если речь идет о выборе режима, то... на доску объявлений будет подан сигнал, та, в свою очередь, сигнализирует объектам, которые на это событие подписались...»

«Нет, вы не поняли. Я имею в виду — что делает система? — Государственный муж вновь прервал докладчика. — Дисплей перезапускается? И что, если это произойдет в ходе рекон­фигурации системы?»

Несколько озадаченный архитектор убрал указку. Вообще-то вопрос не имел отношения к архитектуре, но, поскольку он все-таки архитектор, а положение это обязывает знать все требования, он ответил. «Если командная строка находится в режиме настройки, дисплеи перезапустятся, — изрек докладчик. — В противном случае на пульт управления выводится сообщение об ошибке, а сигнал игнорируется». — Лазерная указка вновь материализова­лась. — «Так вот, что касается механизма перезапуска...»

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

«А что, собственно, должно произойти? — В разговор включился еще один слушатель, адресуя свой вопрос любознательному джентльмену. — Вы что, хотите, чтобы во время пере­стройки режима пользователь получал какие-то данные об этом режиме?»

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

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

Но именно так они и делают. В представленном случае человек, который начал задавать вопросы, просидел два дня, уставившись в схемы функций, операций, пользовательского ин­терфейса и тестирования. Он устал, ему хотелось домой, но именно во время изложения от­чета об архитектуре он понял, что что-то ему непонятно. Прослушав множество отчетов о ва­риантах архитектуры, я убедился в том, что рассмотрение системы под новым углом выводит на поверхность многие неясности. В такой роли для пользователей часто выступает именно архитектура, причем вопросы, которые они начинают задавать, оказываются по своему ха­рактеру поведенческими. Во врезке «Их решение не годится» (см. главу 11) мы рассмотрим пример процесса оценки архитектуры, в ходе которого представители пользователей боль­ше интересовались не тем, как система будет работать, а тем, что она сможет делать, и это совершенно естественно. До представленного момента все их контакты с производителем осуществлялись только через посредство продавцов. Архитектор — настоящий специалист по интересующей их системе, и им довелось с ним пообщаться; вполне объяснимо, что они, нисколько не колеблясь, воспользовались моментом.

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

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

-РСС

В архитектуре излагаются начальные проектные решения

Программная архитектура отражает самые ранние проектные решения относи­тельно системы. Их труднее всего принять, а по мере разработки — скорректиро­вать; при этом последствия наиболее существенны.

Архитектура определяет ограничения реализации

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

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

Архитектура определяет организационную структуру

Мало того что архитектура устанавливает структуру разрабатываемой системы — эта последняя интегрируется в структуру проекта разработки¹ (а иногда, как видно на материале главы 1, даже в структуру компании-разработчика). Стандартный способ разделения труда по разработке крупной системы предполагает распреде­ление отдельных частей системы между несколькими группами конструкторов. Это называется декомпозицией обязанностей по разработке системы. Поскольку в состав системной архитектуры входит высокоуровневая декомпозиция систе­мы, именно она обычно служит основой для декомпозиции обязанностей; та, в свою очередь определяет структуру планирования, определения сроков и бюджета; каналы межгруппового взаимодействия; организацию управления конфигураци­ями и файловой системой; планы и процедуры интеграции и тестирования, и да­же такие мелочи, как организация локальной сети проекта и количество группо­вых попоек. Процесс сопровождения также отражает программную структуру — для сопровождения отдельных структурных элементов создается ряд рабочих групп.

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

¹ Забавная ситуация: в английском языке для обозначения проекта как организационной единицы (project) и проекта как продукта разработки (design) используют два разных слова, в русском -одно. Это доводит муки творчества переводчиков (воздадим им должное!) до невообразимых преде­лов. — Примеч. науч. ред.

Изменить утвержденную архитектуру по управленческим и коммерческим соображениям становится практически невозможно. Это — дополнительный ар­гумент (наряду со многими другими) в пользу комплексной оценки архитекту­ры, которую мы настоятельно рекомендуем проводить перед замораживанием программной архитектуры крупной системы.

Архитектура сдерживает или способствует реализации атрибутов качества системы

Способность/неспособность системы реализовывать предполагаемые (или затре­бованные) атрибуты качества в значительной степени обусловливается архите­ктурой. Отношения между вариантами архитектуры и качеством подробно рас­сматриваются в главе 5; пока что вам следует усвоить следующие постулаты.

• Если система ориентирована на высокую производительность, необходимо следить за временным поведением ее элементов, а также за частотой и объ­емом межэлементного взаимодействия.

• Если приоритетом является модифицируемость, то обязанности между элементами следует распределять таким образом, чтобы вносимые в систе­му изменения не сопровождались далеко идущими последствиями.

• Если система должна стать серьезно защищенной, то особое внимание не­обходимо обратить на безопасность межэлементного взаимодействия и ин­формацию, к которой те или иные элементы имеют право доступа. Кроме того, в архитектуру имеет смысл ввести ряд специализированных элемен­тов (например, надежное ядро).

• Если упор в процессе разработки системы планируется сделать на масшта­бируемости, необходимо обеспечить строгую локализацию использования ресурсов, чтобы тем самым упростить введение элементов с более прогрес­сивными возможностями.

• Если, согласно требованиям проекта, систему следует поставлять поэтап­но, в виде отдельных подмножеств, то особое внимание, опять же, необхо­димо обратить на межэлементное взаимодействие.

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

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

Прогнозирование системного качества путем изучения архитектуры

Можно ли, не дожидаясь окончания разработки и размещения системы, утверж­дать, что те или иные архитектурные решения приняты верно (иначе говоря, что система реализует требуемые атрибуты качества)? Будь ответ на этот вопрос отрицательным, задача выбора архитектуры потеряла бы всякий смысл - ее можно было бы выбирать совершенно произвольно. К счастью, прогнозы относительно качества системы можно делать, отталкиваясь исключительно от результатов оценки ее архитектуры. Методики оценки архитектур наподобие метода анализа компромиссных архитектурных решений (АТАМ, см. главу 11) обеспечивают возможность нисходящего ознакомления с атрибутами качества программных продуктов; возможность эта появляется (но одновременно ограничивается) бла­годаря вариантам программной архитектуры.

Архитектура облегчает анализ изменений и их организацию

Сообщество разработчиков программного обеспечения пытается бороться с тем, что около 80 % издержек на производство типичной программной системы при­ходится на период, следующий за первоначальным развертыванием. Из этого обстоятельства мы можем сделать вывод, что большинство систем находятся именно на этом этапе. Многим программистам и проектировщикам, а возможно, даже большинству из них, никогда не приходилось участвовать в разработке «с чис­того листа» — как правило, в своей работе они ограничены существующим программным кодом. В продолжение своего жизненного цикла программы пре­терпевают изменения; происходят они часто, а реализуются во многих случаях с некоторыми трудностями.

Любая архитектура предполагает разделение всех возможных изменений на три категории: локальные, нелокальные и архитектурные. Для того чтобы внести локальное изменение, достаточно откорректировать отдельный элемент. Нело­кальное изменение требует корректировки ряда элементов, однако базовые архи­тектурные принципы остаются неизменными. Архитектурное изменение затраги­вает сущность взаимодействия между элементами — образец архитектуры — и в большинстве случаев предполагает корректировку всей системы. Локальные изменения, естественно, предпочтительнее остальных; самой эффективной в этой связи следует считать ту архитектуру, в которой наиболее вероятные изменения внести легче всего.

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

Архитектура облегчает эволюционное макетирование

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

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

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

Каждый из этих факторов снижает риск разработки. Если архитектура входит в состав семейства родственных систем, то издержки создания структуры маке­тирования можно разнести на разработку других систем из этого семейства.

Архитектура позволяет более точно рассчитывать стоимость и сроки

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

Архитектура как переносимая модель многократного применения

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

Линейки программных продуктов строятся на основе общей архитектуры

Линейкой, или семейством, программных продуктов называется ряд преимуще­ственно программных систем, для которых характерен общий, управляемый на­бор характеристик, реализующих потребности конкретного сегмента рынка или конкретные задачи и разработанных в установленном порядке на основе общего набора основных активов. Главным из этих активов является архитектура, спро­ектированная в расчете на удовлетворение потребностей всего семейства. Архи­тектор линейки продуктов старается выбрать для нее такую архитектуру (или семейство близкородственных вариантов архитектуры), которая сможет обслу­живать всех ее возможных участников; при этом те проектные решения, которые касаются линейки продуктов в целом, принимаются сначала, а те, которые затра­гивают только отдельных ее членов, — впоследствии. Архитектура определяет постоянные и переменные элементы линейки продуктов. Линейки программных продуктов — мощное средство мультисистемной разработки — на порядки улуч­шают такие характеристики, как срок выхода на рынок, стоимость, продуктив­ность и качество. Значимость архитектуры определяется самой сущностью этой парадигмы. Аналогично прочим капиталовложениям, архитектура линейки про­дуктов становится одним из основных активов компании-разработчика. Анализ линеек программных продуктов приводится в главе 14, а соответствующие кон­кретные примеры — в главах 15 и 17.

Системы можно конструировать на основе крупных элементов, созданных сторонними разработчиками

Раньше программные парадигмы были ориентированы на программирование (programming) как на основной вид деятельности, а проделанная работа измеря­лась в строках кода; архитектурно-ориентированная разработка во многих случа­ях направлена на компоновку (composing) и сборку (assembling) элементов, кото­рые, вероятнее всего, разрабатывались отдельно, а может быть, даже независимо друг от друга. Возможность такой композиции появляется по той причине, что архитектура определяет те элементы, которые можно ввести в систему. В то же время она ограничивает проведение замен (или добавлений), исходя при этом из того, как они взаимодействуют со своей средой, как получают и передают управ­ление, какие данные потребляют и производят, как обращаются к данным и при помощи каких протоколов они осуществляют обмен информацией и совместное использование ресурсов.

Одним из наиболее важных аспектов архитектуры является организация струк­туры ее элементов, интерфейсов и рабочих понятий. Взаимозаменяемость (inter-changeability) считается самым важным принципом этой организации. Запущен­ное в 1793 году Эли Уитни (Eli Whitney) массовое производство мушкетов по принципу взаимозаменяемых частей положило начало эпохе промышленного производства. В отсутствие надежных физических измерений эта идея не внуша­ла доверия. В контексте современного программного обеспечения, пока добиться надежного разграничения абстракций не удалось, принцип структурной взаимо­заменяемости кажется не менее устрашающим, однако от этого он не теряет сво­ей важности.

Готовые компоненты, подсистемы, совместимые интерфейсы передачи дан­ных — все они основываются на принципе взаимозаменяемости. При этом нере­шенными остаются многие проблемы, связанные с разработкой программного обеспечения методом композиции. Когда в качестве компонентов, претендующих на внесение и многократное применение, выступают индивидуальные подсисте­мы, сконструированные на основе противоречащих друг другу архитектурных допущений, интеграция их функций может столкнуться с непредвиденными слож­ностями. Вслед за Дэвидом Гарланом (David Garlan) и некоторыми его коллега­ми эту ситуацию стали называть архитектурным несоответствием (architectural mismatch).

Чем меньше, тем больше: ограничивать словарь проектных альтернатив выгодно

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

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

СИСТЕМНАЯ АРХИТЕКТУРА И ПРОГРАММНАЯ АРХИТЕКТУРА

На протяжении последних 5-10 лет мы часто выступали с сообщениями о программной ар­хитектуре. Все это время среди слушателей находился кто-то, кто спрашивал: «Почему вы говорите о программной архитектуре? Ведь системная архитектура не менее важна!» или «В чем разница между программной и системной архитектурой?»

На самом деле, как выясняется, разница небольшая. То, что мы обычно говорим именно о программной архитектуре, объясняется желанием подчеркнуть важность принимаемых ар­хитектором программных решений, которые распространяются на качество продукта в це­лом.

Случаи, когда в процессе создания программной архитектуры соображения по поводу си­стемы не принимаются в расчет, крайне редки. К примеру, если вы хотите, чтобы архитектура была высокопроизводительной, у вас должно быть хотя бы некоторое представление о ха­рактеристиках той аппаратной платформы, на базе которой она будет работать (скорость процессора, емкость памяти, скорость обращения к диску); кроме того, вы должны знать характеристики всех устройств, с которыми системе предстоит взаимодействовать (тради­ционные устройства ввода-вывода, сенсоры, исполнительные механизмы), а в дополнение к этому желательно найти информацию о характеристиках сети (в первую очередь, о ее про­пускной способности). Если архитектура должна быть сверхнадежной, вам, опять же, при­дется иметь дело с аппаратной частью — в этом случае с интенсивностью отказов, наличием резервирования средств обработки и сетевых устройств. И так далее и тому подобное. Архи­текторы редко обходят стороной вопросы аппаратного обеспечения.

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

И тем не менее мы продолжаем настаивать на употреблении термина «программная ар­хитектура». Почему же все-таки не «системная»? Дело в том, что большинство альтернатив архитектора связано не с аппаратурой, а с программным обеспечением. Речь не идет о том, что решений относительно аппаратной части принимать не надо, — просто она может быть неподконтрольна архитектору (именно такая ситуация складывается при разработке систе­мы, которая должна работать на случайных клиентских машинах с подключением к Интерне­ту); с другой стороны, все решения, касающиеся аппаратуры, могут приниматься другими лицами (по экономическим и правовым мотивам или согласно стандартам); кроме того, ап­паратура имеет обыкновение со временем заменяться.

Все вышеприведенные факторы позволяют нам на вполне законных основаниях сосре­доточиться на программной части архитектуры — именно здесь принимается большинство основополагающих решений, существует множество альтернатив и возможностей добиться успеха (или привести к полному провалу!).

—RK

Архитектура предполагает возможность разработки на основе шаблонов

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

Архитектура помогает в процессе обучения

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