Определение архитектуры приложений с помощью Rational Software Architect: Часть 2. Итеративное уточнение архитектуры

Этот цикл статей посвящен методам создания моделей для описания и распространения архитектуры сложных программных систем. Он иллюстрирует процесс разработки архитектуры системы интернет-сети ресторанного обслуживания (Online Catering) для вымышленной компании Yummy Inc. С помощью итеративного подхода создается описание основных действий по созданию архитектуры, необходимых для определения сложной программной системы с помощью IBM Rational Software Architect. В первой статье этого цикла объяснялось, как создать концепцию архитектуры на ранних этапах проекта. Во второй части мы покажем, как эта архитектура итеративно уточняется с помощью Rational Software Architect. Обе статьи предполагают, что читатели знакомы с методологией итеративной разработки.

Введение

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

1. Выявление значимых требований
2. Определение предполагаемой архитектуры
3. Определение исходной модели развертывания
4. Определение модели домена

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

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

5. Уточнение архитектурных механизмов: технические концепции удовлетворения архитектурно значимых требований, определенных на первом шаге.
6. Уточнение элементов проекта: архитектурно значимые элементы проекта.
7. Уточнение архитектуры развертывания: единицы и топологии развертывания.

Итеративное совершенствование архитектуры

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

Электронная книга: Загрузите из блога автора электронную книгу Эволюционная архитектура ― с помощью Rational Software Architect v8.

Уточнение архитектурных механизмов

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

Для наглядности можно связать эти классы с аналитическим стереотипом. Для представления класса, действующего в качестве интерфейса к системе, используется стереотип Boundary . Компонент, осуществляющий контроль над другими классами, описывается классом Control . Класс, содержащий данные, определяется стереотипом Entity .

Графическое представление этих аналитических стереотипов приведено на рисунке 1.

Рисунок 1. Аналитические стереотипы

На рисунке 2 аналитический стереотип показан в применении к значимому требованию к системе. В примере Yummy Inc. требование к системе обработки заказов включает в себя несколько элементов (аналитических классов), таких как клиент, меню и обработка платежей.

Рисунок 2. Аналитические элементы пакета обработки заказов

После определения аналитических классов (рисунок 2) также может потребоваться определение статических и динамических аспектов некоторых значимых требований.

Затем для каждого значимого сценария определяются его статические и динамические аспекты. Rational Software Architect помогает архитектору ПО решить эту задачу, предоставляя шаблон реализации сценариев использования.

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

Рисунок 3. Шаблон реализации сценариев использования для функций заказа по меню.

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

Рисунок 4. Схема классов для функции заказа по меню

Рисунок 5. Циклограмма для функции заказа по меню

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

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

Уточнение структурной модели

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

Если аналитическая модель абстрактна, то структурная модель должна быть ближе к реальной реализации. Обычно архитектор определяет набор целей и ограничений, связанных с технологией, используемой для реализации решения. Структурную модель , как правило, не разрабатывают с нуля. Это развитие той аналитической модели, которая уже определена (рисунки 2 и 3).

В нашем примере система ресторанного интернет-обслуживания Yummy Inc. разрабатывается на платформе Java EE. Для обеспечения персистентности данных используется API Java Persistence (см. раздел Ресурсы), логика приложения реализуется с помощью Session Beans, а доступ к службе доставки осуществляется с помощью Web-сервисов.

При создании архитектуры и проектировании рекомендуется определять разные уровни решения и способ их взаимодействия. N -уровневая архитектура Java EE способствует разделению задач между уровнями.

В перспективе Architectural Layers системы Rational Software Architect шаблон структуры содержит представление, на котором можно определить зависимости между уровнями (рисунок 6).

Рисунок 6. Представление Architectural Layer Dependencies для системы Online Catering

Когда архитектурные уровни определены, архитектор выполняет первую итерацию проектирования. Шаблон проекта Rational Software Architect содержит готовую структуру для этого. В спецификации компонента обычно есть интерфейсы и данные, используемые для взаимодействия с этим компонентом (рисунок 7). Как правило, это первое, что определяет архитектор ПО. Для каждого компонента важно указать данные, которыми он манипулирует, и его интерфейс, включая доступные операции.

Рисунок 7. Пакеты проектов для системы Online Catering

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

Для некоторых компонентов сложной программной системы может понадобиться углубленное проектирование. Помните, что структура детализируется только в том случае, если это помогает группе в реализации и выпуске приложения. На рисунке 8 представлена подробная схема классов, составленная с конкретной целью. Группа хочет создать Java-код из структурной модели с использованием некоторых преобразований, которые обеспечивает Rational Software Architect (подробнее о преобразованиях см. в разделе Ресурсы).

Рисунок 8. Подробная схема классов для генерации кода

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

Уточнение архитектуры развертывания

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

Инструменты планирования процесса развертывания Rational Software Architect позволяют создавать топологии, демонстрирующие отношения между ИТ-ресурсами. Также можно планировать и проверять сценарии развертывания (подробнее о планировании и автоматизации процесса развертывания с помощью Rational Software Architect см. разделе Ресурсы).

Rational Software Architect помогает выполнить анализ развертывания на разных уровнях абстракции. Можно создавать логические топологии для принятия решений по операционной архитектуре сложной программной системы (рисунок 9). Логическая топология описывает систему на высоком уровне абстракции. В ней указывают, как организованы и связаны компоненты приложения и где они должны размещаться. Обратите внимание, что для лучшей прослеживаемости блоки, соответствующие решению, иногда не создаются с нуля, а выводятся из UML-элементов.

Рисунок 9. Пример логической топологии для системы Online Catering

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

Рисунок 10. Пример подробной модели развертывания системы Online Catering

Поэтапное построение системы

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

Постоянное обдумывание архитектуры является частью усилий по разработке, и группа не должна писать новый код или изменять существующий, не подумав о том, как это изменение повлияет на приложение в целом. Популярный метод изменения существующего кода называется рефакторингом (см. раздел Ресурсы). Rational Software Architect предоставляет богатый набор инструментов для облегчения разработки и рефакторинга кода. С помощью инструмента рефакторинга можно изменить структуру кода (рисунок 11). А функция архитектурного обнаружения позволяет выделить в коде приложения шаблоны и антишаблоны (рисунок 12). Обе функции помогают улучшить код и выявить проблемы на ранних стадиях разработки программного обеспечения.

Рисунок 11. Инструмент рефакторинга в Rational Software Architect

Рисунок 12. Поиск шаблонов

Если при обдумывании архитектуры вы создали какие-то модели, то их можно преобразовать в код. Rational Software Architect содержит набор преобразований для создания кода Java, элементов Java EE или артефактов SOA (рисунок 13). Можно также генерировать модели из существующего исходного кода.

Рисунок 13. Преобразования в Rational Software Architect

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

Заключение

Гибкие методы проектирования способствуют применению коротких итераций для построения системы шаг за шагом. Если подход Big Design Up Front (см. BDUF в разделе Ресурсы) оказался неэффективным и применяется главным образом в водопадных моделях, то это не означает, что из гибких проектов нужно выкинуть планирование архитектуры и структуры. Проектирование должно быть продуманным и последовательным. Продуманным, потому что уже в начале проекта можно предвидеть некоторые технические требования, основываясь на очереди нерешенных задач (планирование архитектуры). Последовательным, потому что в ходе итераций разработки проект адаптируется и обогащается при решении новых технических задач, с которыми сталкивается группа.

В первой статье этого цикла мы сосредоточились на типичных задачах планирования архитектуры и согласования технической концепции с предъявляемыми требованиями. В этой, второй статье мы описали, как архитектура уточняется в ходе итераций разработки. Rational Software Architect предоставляет шаблоны моделей для описания архитектуры сложной программной системы с разных точек зрения на протяжении всего жизненного цикла проекта (рисунок 14).

Рисунок 14. Модели для различных архитектурных представлений

Обдумывание архитектуры ― это непрерывный процесс, который группы опытных разработчиков внедряют в свою работу. Он не всегда приводит к созданию формальной схемы. Имейте в виду, что если UML не подходит для вашего контекста, то ничто не мешает использовать вместо него эскизы Rational Software Architect, как если бы вы рисовали на доске. Эскизы Rational Software Architect носят менее формальный характер, чем UML-схемы, но могут служить хорошей альтернативой для конкретного проекта.

Загрузка