Лекция. Границы архитектурного проектирования по. План

Гибкий подход к проектированию архитектуры ПО

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

Давайте начнем с разработки архитектуры для представления клиенту данных в базе данных. Это отдельное приложение для передачи данных одному пользователю. На рисунке 2.5 показан возможный дизайн, в котором клиентский графический интерфейс пользователя получает критерии поиска данных от клиента и представляет выбранные данные клиенту в графическом пользовательском интерфейсе. Модуль поиска и обработки данных извлекает данные из базы данных в соответствии с критериями клиента и предварительно обрабатывает извлеченные данные. Эти два модуля должны работать в разных потоках одного и того же процесса.
Теперь предположим, что спецификация требований изменилась, и приложение должно работать на сервере для представления данных через Интернет нескольким клиентам с соответствующим клиентским программным обеспечением. Соединитель между клиентским модулем GUI и модулем поиска и обработки данных теперь имеет новый сетевой атрибут, как показано на рисунке 2.6. Поскольку все клиенты будут использовать одно и то же клиентское программное обеспечение для доступа к серверу данных, модули могут быть реализованы на одном языке программирования с использованием технологии удаленного вызова методов. Если оба модуля реализованы на Java, то для реализации сетевого соединителя можно использовать Java RMI. Если оба модуля реализованы в Windows, то Microsoft. NET удаленный вызов может быть использован для реализации сетевого разъема.

В обоих этих примерах соединитель между клиентским модулем GUI и модулем поиска и обработки данных является одним инициатором, сетевым и на основе сигнатур.
Теперь предположим, что мы решили поддерживать клиентские устройства с графическим интерфейсом сторонних производителей и представлять данные в форматах, настраиваемых на сервере. Поскольку у нас нет контроля над технологиями реализации клиентского графического модуля, соединитель на основе сообщений и протоколов может обеспечить необходимую гибкость. Мы используем HTTP в качестве протокола уровня приложения поверх сетевого соединения TCP/IP между клиентским модулем GUI на стороне клиента и модулями на стороне сервера. Для гибкого представления данных, которое можно изменять на сервере, мы используем язык разметки HTML, чтобы указать, как представлять данные клиенту и отправлять клиентские запросы на сервер по протоколу HTTP. В результате мы представляем два уровня представления данных: уровень представления данных на стороне сервера, реализованный модулем генератора HTML на сервере, для динамического создания файлов HTML; и уровень представления данных на стороне клиента, реализованный модулем представления HTML на стороне клиента, для визуализации данных пользователю в соответствии с разметками HTML. Это показано на рисунке 2.7.

Теперь предположим, что нам нужно поддерживать значительные возможности обработки данных на сервере. Мы применяем подход «разделяй и властвуй» к архитектуре ПО и делим серверное ПО на три уровня: