Введение в аналитические шаблоны и стили проектирования

Стили архитектурного проектирования

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

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

Методологии проектирования –это не проектирование. Они являются платформой, с помощью которой объединяются и структурируются усилия, направленные на создание адекватной программной архитектуры.

Ни методологии, ни языки программирования или другие средства разработки не дают ответа на вопрос, как проектируются информационные системы.

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

Когда есть необходимость представить архитектуру, сначала начинается рассказ о том, как те или иные объекты друг с другом взаимодействуют. Довольно быстро оперативная память слушателя или же самого рассказчика заканчивается, и тогда появляется карандаш или маркер и начинается "картинизация". Процесс осознания архитектуры в этот момент прерывается. То же самое происходит, если на определенном шаге прервать рассказчика вопросом: "А что, если…?". В обоих случаях шансов вернуться к основному сценарию совсем немного. В общем, все довольно быстро запутываются (теряют нить рассуждений) и возвращаются к началу.

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

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

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

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

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

Можно перечислить следующие примеры архитектурных стилей, востребованных при разработке программного обеспечения на текущий момент:

• Стиль "конвейеры и фильтры" является общем стилем обработки данных. Его структура состоит из множества компонентов, каждый из которых выполняет определенные процессы. Результаты выполнения одного процесса могут передаваться как одному, так и нескольким модулям различными способами. Хорошим примером реализации программного обеспечения таким стилем является компилятор, который последовательно выполняет различные виды низкоуровневого анализа, оптимизацию и генерацию кода. Системы, реализованные с помощью такого стиля, являются синхронными программными архитектурами, клиентская часть которых приостанавливает функционирование на время обслуживания собственного запроса сервером.
• Стиль "программа–сопрограмма" является реализацией идей структурного программирования и подразумевает наличие главной управляющей программы (контроллера), отвечающей за процесс функционирования, и ряда сопрограмм, реализующих всю необходимую функциональность. Разновидностью данного подхода считается архитектура "ведущий–ведомый", в которой основная программа и сопрограммы работают одновременно (параллельно). Контроллер выполняет функции диспетчера процесса, в то время как сопрограммы выполняют задания, по завершении которых запрашивают у него новые. Взаимодействие между объектами, включающими (инкапсулирующими)в себя код и данные, осуществляется либо с помощью вызовов процедур, либо при помощи сообщений. Важным условием реализации информационных систем подобным стилем является условие, что вызывающий объект должен знать, где находится вызываемый и набор интерфейсов, которые он может использовать. К основным достоинствам также можно отнести естественную поддержку распараллеливания процессов.
• Для крупномасштабных систем применяют иерархически многоуровневый стиль, в котором каждый из слоев можно рассматривать как набор сервисов для вышележащего слоя. Вышележащий слой является клиентом, а нижележащий – сервером. Этот стиль оправданно применяется для создания стеков протоколов или операционных систем. Главным его достоинством является возможность ведения разработки каждого из слоев независимо. При этом не все алгоритмы можно реализовать в виде многоуровневой структуры, поэтому ее применение не всегда оправдано. Системы, функционирующие по принципу независимых компонентов, используют механизм неявного вызова операторов, то есть взаимодействующие операторы могут работать независимо и располагаться на разных хостах сети. Основным принципом функционирования систем взаимодействия процессов является обмен сообщениями между независимыми процессами.

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

Шаблон vs Антишаблон

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

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

Необходимо обратить дополнительное внимание на то, что, даже не зная конкретных способов реализации того или иного шаблона, можно прийти к выводу о возможности его применения. Это утверждение справедливо и подходит в отношении всех шаблонов проектирования. Более того, как правило, в качестве антишаблонов проектирования могут выступать рассматриваемые тут шаблоны проектирования, примененные в условиях, неоптимальных для выработанного решения.

В качестве примера наиболее популярных антишаблонов проектирования можно привести следующие:

• Случайная сложность. Введение ненужной сложности в систему.
• Действие на расстоянии. Неожиданное взаимодействие сильно разделенными частями системы.
• Слепая вера. Отсутствие проверки правильности исправления ошибки или результата, возвращаемого процедурой.
• Корабельный якорь. Сохранение части системы, которая не используется.
• Занятый волчок. Использование времени процессора в процессе ожидания некоторого события. Обычно это повторяется в постоянной циклической проверке вместо использования сообщений.
• Ошибка кэширования. Забывание сбросить флаг ошибки, когда ошибка обработана.
• Культ грузового программирования. Использование шаблонов и методов без понимания, зачем.
• Кодирование исключениями. Добавление нового кода для обработки каждого особого случая, как только он найден.
• Сокрытие ошибок. Перехват ошибок прежде, чем они будут показаны пользователю. Перехваченные ошибки либо не показываются пользователю, либо отображаются бессмысленные сообщения.
• Обработка исключений. Использование системы обработки исключений для реализации программной логики.
• Жесткий код. Встраивание предположения об окружении системы в ее реализации.
• Поток лавы. Поддерживание нежелательного (избыточного или низкокачественного) кода, потому что удаление его либо слишком дорого, либо имеет непредсказуемые последствия.
• Последовательность циклов и переключателей. Кодирование набора последовательных шагов с использованием цикла с набором переключателей.
• Волшебные числа. Включение необъяснимых чисел в алгоритмы.
• Волшебные строки. Включение строковых литералов в код для сравнения, как типы событий и т.д.
• Мягкий код. Хранение бизнес-логики в конфигурационном файле вместо хранения в исходном коде.
• Спагетти-код. Система, чья структура едва понятна, особенно из-за неправильной структуры кода.

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

При изучении шаблонов полезнее сосредоточиться на общем бизнес-контексте их применения – т.е. на тех проблемах, которые пытаются решить. Это позволяет получить ответы на все необходимые вопросы.