Другие взгляды на архитектуру

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

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

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

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

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

♦ Архитектура — это компоненты и соединители. Под соединителями име­ется в виду механизм периода прогона, предназначенный для передачи в рам­ках системы сигналов управления и данных. Следовательно, данное опре­деление ориентировано на архитектурные структуры периода прогона. К примеру, соединителем является UNIX-канал. Согласно этой логике, все архитектурные структуры, которые не относятся к периоду прогона (на­пример, рассмотренное выше статическое разделение на ответственные блоки реализации), признаются второстепенными. В то же время в контексте ре­шения системных задач они не менее важны, чем структуры периода прого­на. Рассуждая об «отношениях» между элементами, мы имеем в виду все отношения - те, что реализуются в период прогона, и те, что к нему не относятся.

 

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

Архитектурные образцы, эталонные модели и эталонные варианты архитектуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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