Студопедия Главная Случайная страница Задать вопрос

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

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





 
 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 
 

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

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

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

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

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

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

 






Дата добавления: 2015-04-16; просмотров: 257. Нарушение авторских прав

Studopedia.info - Студопедия - 2014-2017 год . (0.085 сек.) русская версия | украинская версия