Файл: Учебное пособие.doc

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

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

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

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

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

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

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

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

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

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

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

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

4.1.3.2.Архитектурные структуры и представления

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

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

Архитектурные структуры подразделяются на три общие группы, в каждую из которых включается элементы определенного характера.

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

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

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

Программные структуры

Наиболее распространенные и полезные программные структуры изображены на рис. 5.3. Им посвящен ряд последующих разделов.

Рисунок 4.3 – Стандартные структуры программной архитектуры

Модуль

Модульные структуры делятся на следующие разновидности.

Декомпозиция. В качестве блоков выступают модули, между которыми установлены отношения «является подмодулем...»; таким образом, крупные модули в рекурсивном порядке разлагаются на меньшие, и процесс этот завершается только тогда, когда мелкие модули становятся вполне понятными. Модули в рамках этой структуры часто используются в качестве отправной точки для последующего проектирования — архитектор перечисляет блоки, с которыми ему предстоит работать, и в расчете на более подробное проектирование, а также, в конечном итоге, реализацию распределяет их между модулями. У модулей во многих случаях есть связанные продукты (например, спецификации интерфейсов, код, планы тестирования и т. д.). Структура декомпозиции в значительной степени обеспечивает модифицируемость системы — при этом складывается ситуация, когда наиболее вероятные изменения приходятся на долю нескольких небольших модулей. Довольно часто декомпозиция задействуется как основа для организации проекта, включающая структуру документации, планы интеграции и тестирования. Иногда блоки этой структуры получают оригинальные названия (от пользующихся ими организаций). К примеру, в ряде стандартов министерства обороны США определяются элементы конфигурации компьютерных программ (Computer Software Configuration Items, CSCI) и компоненты компьютерных программ (Computer Software Components, CSC), которые представляют собой не что иное, как блоки модульной декомпозиции.

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

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

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

Компонент и соединитель

Среди структур данного вида выделяются следующие.

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

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

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