Суть программной архитектуры

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

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

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

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

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

Можем ли мы взять любую из этих структур в отдельности и назвать ее архитектурой? Нет, не можем — и это несмотря на то, что все они содержат архитектурные сведения. В состав любой архитектуры эти структуры входят наравне со многими другими. В этой связи, очевидно, что, поскольку в составе архитектуры может содержаться несколько структур, в ней должны присутствовать несколько элементов (например, блок реализации и процессы), несколько вариантов взаимодействия между элементами (например, разбиение на составляющие и синхронизация) и даже несколько контекстов (например, время разработки и время прогона). Представленное определение не устанавливает сущность архитектурных элементов и отношений. Является ли программный элемент объектом? процессом? библиотекой? базой данных? коммерческим изделием? Он может быть чем угодно, причем возможности не ограничиваются вышеприведенными вариантами.

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

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

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

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

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

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

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

Синонимичным «архитектурному образцу» является общеупотребительный термин архитектурный стиль (architectural style).

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

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

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

Рисунок 4.2 – Отношения между эталонными моделями, архитектурными образцами, вариантами эталонной и программной архитектуры

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

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