Чем является программная архитектура и чем она не является

Рисунок 2. 1— иллюстрация к описанию системы гидроакустического моделирова­ния — претендует на изображение «архитектуры высшего уровня»; как правило, архитектура изображается именно на таких диаграммах. Какие выводы мы мо­жем из нее сделать?

♦ Система состоит из четырех элементов.

♦ Поскольку три из четырех элементов — модель потери опоры (MODP), модель отражения (MODR) и шумовая модель (MODN) — расположены рядом друг с другом, между ними, вероятно, больше сходства, чем между каждым из них и четвертым элементом — процессом управления (CP).

♦ Поскольку данная диаграмма является вполне связной, между всеми ее элементами, по-видимому, присутствует некая взаимосвязь.

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

♦ Каков характер элементов? В чем смысл их разделения? Может быть, они обрабатываются разными процессорами? Или запускаются в разные пери­оды времени? Из чего состоят эти элементы: из процессов, программ или из того и другого? Возможно, диаграмма демонстрирует схему разделения обязанностей между группами разработчиков проекта, или же она все-таки подразумевает разделение в период прогона? Являются ли представлен­ные элементы объектами, задачами, функциями, процессами, распределен­ными программами или чем-то еще?

♦ Каковы обязанности этих элементов? Зачем они нужны? Какие функции они исполняют в рамках своей системы?

♦ В чем значение связей между элементами? Означают ли они, что элементы взаимодействуют друг с другом, управляют друг другом, отсылают друг другу какие-то данные, используют, запускают или синхронизируют друг друга, располагают некоей скрытой (от пользователя) информацией; возможно, отношения между элементами строятся на основе сразу нескольких подобного рода связей? Каковы механизмы взаимодействия между эле­ментами? Что за информация передается посредством этих механизмов?

♦ Чем объясняется такое расположение элементов? С какой стати процесс управления выведен на отдельный уровень? Может быть, он может вызы­вать все остальные элементы, а они его — нет? Возможно, он как блок реализации содержит три нижележащих элемента? Или все значительно проще — все четыре элемента не уместились на одной строке?

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

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

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

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

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

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

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

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

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

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

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

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