Этот цикл статей посвящен методам создания моделей для описания и распространения архитектуры сложных программных систем. Он иллюстрирует процесс разработки архитектуры системы интернет-сети ресторанного обслуживания (Online Catering) для вымышленной компании Yummy Inc. С помощью итеративного подхода создается описание основных действий по созданию архитектуры, необходимых для определения сложной программной системы с помощью IBM Rational Software Architect (RSA). В первой части этого цикла мы сосредоточимся на типичных задачах проектирования архитектуры и согласования технической концепции с предъявляемыми требованиями. Во второй части говорится о том, как эта архитектура итеративно уточняется с помощью RSA. Обе статьи предполагают, что читатели знакомы с методологией итеративной разработки.
Существует много различных методологий, обеспечивающих ряд гибких практических приемов, которые помогают предприятиям надежно выпускать высококачественное программное обеспечение. Сегодня гибкая разработка ПО ― общепринятая практика, и один из ее основных принципов заключается в освоении итеративных и поэтапных методов. Эта статья посвящена конкретным действиям архитектора программного обеспечения и предполагает, что вы уже владеете гибкими методами и итеративной разработкой (подробнее см. в разделе Ресурсы об IBM agility@scale, IBM Practices, OpenUP и Rational Unified Process).
Основная цель этой статьи - проиллюстрировать, как Rational Software Architect 8 (далее ― RSA) помогает в проектировании и документировании архитектуры. RSA - это платформа коллективной работы для проектирования высококачественной архитектуры ПО. RSA помогает определить модели на различных уровнях абстракции и может использоваться для поддержки практических приемов проектирования программного обеспечения.
Архитектурный анализ: планирование и развитие архитектуры
Архитектурный анализ представляет собой набор мероприятий по созданию и совершенствованию архитектуры программного обеспечения системы. При итеративном использовании такое обдумывание архитектуры помогает ставить и решать задачи при разработке программного обеспечения, не требуя значительных усилий по предварительному созданию архитектуры. Архитектурный анализ имеет решающее значение для любой сложной программной системы. Что бы ни говорили догматики гибкой разработки, успешное проектирование программного обеспечения без архитектурного анализа невозможно.
Архитектурный анализ осуществляется в двух местах. Во-первых, в самом начале проекта, что часто называют итерацией 0 или этапом 0. В ходе этой первоначальной итерации архитектор программного обеспечения планирует архитектуру, основываясь на известных требованиях, а также архитектурных ограничениях, решениях и целях. Архитектурное планирование ― не долгое и громоздкое мероприятие. В зависимости от сложности системы можно уложиться в несколько дней или даже часов.
Чтобы наметить целевую архитектуру своей системы, архитектор программного обеспечения обычно выполняет следующие действия.
- Выявление значимых требований: основные функциональные и нефункциональные требования, оказывающие существенное влияние на архитектуру.
- Определение предполагаемой архитектуры: общая архитектура системы с учетом архитектурных ограничений и целей.
- Определение исходной модели развертывания: топология, отражающая узлы развертывания системы.
- Определение модели домена: ключевые бизнес-объекты и их взаимодействие.
Электронная книга: Загрузите из блога автора электронную книгу Эволюционная архитектура ― с помощью Rational Software Architect v8.
Когда исходный технический проект готов, можно приступать к построению системы на прочной архитектурной основе. На каждом этапе группа разработчиков ставит новые технические задачи и открывает новые возможности для совершенствования проекта. При этом архитектор предлагает новые архитектурные решения. Вот почему ключом к разработке сложной программной системы служит непрерывное совершенствование архитектуры. Архитектура не создается раз и навсегда. Обдумывание архитектуры ― неотъемлемая часть процесса разработки программного обеспечения от начала и до конца проекта.
Как правило, во время этапов разработки выполняются следующие мероприятия по уточнению архитектуры.
- Уточнение архитектурных механизмов: технические концепции удовлетворения архитектурно значимых требований, определенных на первом шаге.
- Уточнение элементов структуры: архитектурно значимые элементы структуры.
- Уточнение архитектуры развертывания: единицы и топологии развертывания.
Итерационные мероприятия описаны во второй статье этого цикла.
Рисунок 1. Итеративный и поэтапный архитектурный анализ
Хотя эта статья не содержит обзора мероприятий, любой опытный программист знает, что архитектура должна регулярно проверяться на соответствие требованиям и потребностям группы. Поэтому нужен эффективный механизм оформления архитектуры и ее передачи различным участникам процесса.
Описание архитектуры с помощью представлений
Проверенный и широко применяемый подход к описанию архитектуры ― использование представлений и разрезов. Представление отражает всю систему целиком с точки зрения набора вопросов или задач. С точки зрения участников процесса представление отражает все критические или важные аспекты системы. Так как разного рода участников обычно бывает много, то чтобы охватить все вопросы, необходимо несколько представлений.
В 1995 году Филипп Крухтен предложил модель для описания архитектуры сложных программных систем: модель представления архитектуры программного обеспечения "4+1" (см. раздел Ресурсы). Большинство идей модели "4+1" вошли в такие процессы разработки, как IBM Rational Unified Process (RUP) или OpenUP. Недавно IEEE 1471 стандартизировал определение представления для решения проблем различных пользователей архитектуры программного обеспечения (IEEE 1471-2000/ISO 42010, см. раздел Ресурсы).
В оригинальной модели "4+1" используются пять видов представлений, которые дают всеобъемлющее представление о системе, как показано на рисунке 2.
Рисунок 2. Модель представления архитектуры "4+1"
Каждое представление модели "4+1" отражает вопросы определенных участников процесса, позволяя им легко находить в архитектуре программного обеспечения то, что им нужно. Эту модель можно настраивать. В зависимости от сложности проекта можно получить только необходимое подмножество предлагаемых представлений. Модель можно также расширять, добавляя другие представления для описания архитектуры с другой точки зрения. Дополнительные представления обычно вкладываются в существующие как подкатегории.
В таблице 1 каждая строка соответствует представлению для определенной аудитории, области и модели.
Таблица 1. Представления архитектуры
|
Представление |
Аудитория |
Приоритетная область |
Модель |
|---|---|---|---|
| Логическое | Проектировщики | Реализация вариантов использования | Аналитическая модель Структурная модель |
| Процессов | Интеграторы | Производительность Масштабируемость Параллелизм |
Модель развертывания Структурная модель |
| Реализации | Программисты | Программные компоненты | Модель реализации |
| Развертывания | Менеджеры по внедрению | Физические узлы | Модель развертывания |
| Сценариев | Все | Функциональные требования | Модель вариантов использования Описание сценариев использования Бизнес-процессы |
| Данных (дополнительно или в составе логического представления) |
Специалисты по обработке данных Администраторы баз данных |
Персистентность данных | Модель данных |
Примечание.
Как правило, представление процессов не столь важно для приложения, потому что вопросами потоков занимается сама платформа. Тем не менее, некоторые из проблем параллелизма можно отразить в модели развертывания, а некоторые из механизмов связи (синхронная-асинхронная) ― в структурной модели.
Прежде чем запустить RSA, убедитесь, что у вас установлен минимальный набор инструментов для работы архитектора. В диспетчере установки должен быть отмечен параметр Architect - Standard , как показано на рисунке 3. Этот предопределенный профиль обеспечивает функции моделирования топологии и UML, необходимые для решения задач, рассматриваемых в этой статье.
Рисунок 3. Стандартный профиль архитектуры
Следующий шаг ― создание новой рабочей области. Запустите RSA и укажите каталог (рис. 4).
Рисунок 4. Окно Workspcae Launcher
RSA предоставляет много различных перспектив для настройки исходного набора и расположения представлений в окне Workbench. Прежде чем двигаться дальше, убедитесь, что открыта перспектива Modeling (рисунок 5).
Рисунок 5. Окно Open Perspective
RSA содержит много готовых шаблонов UML-моделей. В режиме Modeling Perspective можно добавлять модели для документирования архитектуры своей системы (рисунок 6).
Рисунок 6. Шаблоны UML-моделей
Каждый шаблон предназначен для конкретной архитектурной цели. Как правило, чтобы определить каждый аспект системы (вспомните модель представления "4+1"), нужны модели Use-Case, Analysis и Design. В нашем примере можно также создать эскиз архитектуры и топологии для определения целевой среды развертывания. Итак, рабочая область Yummy Inc. содержит следующие модели (рисунок 7). Каждая основана на своем шаблоне RSA.
Рисунок 7. Модели, описывающие представления архитектуры системы Online Catering
Обратите внимание, что мы могли бы использовать другие типы моделей из числа шаблонов RSA, например, модель BPMN (бизнес-процесс) или модель Services (SOA).
Теперь рабочая область RSA готова, и необходимо выполнить несколько действий, о которых мы упомянули выше. Проиллюстрируем, как RSA помогает выполнить пошаговый архитектурный анализ.
Архитектор должен представить первоначальную архитектуру программного обеспечения и набросать архитектурные решения, определяющие процессы разработки и тестирования. Эта работа опирается на опыт, накопленный при создании подобных систем или систем для той же предметной области, который помогает ограничить архитектуру и сфокусировать ее. Ваши выводы должны приводить к информации, позволяющей передать архитектуру проектной группе.
Одна из первых задач, которую надо решить при планировании архитектуры, ― определение значимых требований. Роль архитектора заключается в том, чтобы создать целевую архитектуру, подходящую для удовлетворения потребностей пользователя. Поэтому необходимо пересмотреть сценарии использования, бизнес-процессы или описания опыта пользователей и определить, что может оказать существенное влияние на архитектуру. Опытные архитекторы тесно сотрудничают с руководителями проектов, сообщая им о влиянии на архитектуру тех или иных элементов. Они помогают установить приоритетность задач по скорейшему снятию технических вопросов.
Выявленные требования для Yummy Inc. содержатся в модели сценариев использования RSA (рисунок 8).
Рисунок 8. Требования для системы Online Catering 
Универсального правила выявления значимых требований не существует. Все зависит от конкретной среды, технической инфраструктуры и проектной группы. Требования, оказывающие огромное влияние на архитектуру с точки зрения одной группы, могут показаться тривиальными для другой. Требование отображения простого списка элементов, вероятно, не сильно повлияет на архитектуру. Однако если требуется получать элементы от делового партнера через асинхронную службу связи, необходимо обеспечить необходимые средства связи, поддерживающие такую архитектуру.
В нашем примере Yummy Inc. модель подразделяется на функционально-ориентированные пакеты. В каждый пакет входят соответствующие сценарии использования и субъекты (субъекты, участвующие в нескольких процессах, сгруппированы в универсальный пакет). Приведенная на рисунке 9 схема примера использования иллюстрирует предъявляемые требования. Конечно, ту же информацию можно отразить и на схеме бизнес-процесса или в описании опыта пользователя.
Рисунок 9. Схема сценария использования меню заказов
Определение предполагаемой архитектуры
Когда значимые требования выявлены, архитектор создает общую архитектуру. Сегодня системы редко разрабатываются с нуля. Мы обогащаем существующие приложения, модернизируем устаревшие системы и повторно используем имеющиеся ресурсы. Архитектор применяет накопленный опыт работы с аналогичными системами и обеспечивает рассмотрение всех целей и ограничений. Проект архитектуры принимает во внимание как функциональные (сценарии использования, истории, бизнес-процессы), так и нефункциональные (доступность, производительность, масштабируемость) требования, предъявляемые к системе.
Мы выбрали для своего примера N-уровневую архитектуру (рисунок 10) с Web-приложением, к которому можно обращаться и через Web-сервисы с клиентских устройств разного типа (о многоуровневых приложениях см. в разделе Ресурсы).
Обратите внимание, что эта технологическая схема (рисунок 10), созданная в RSA, на данном этапе довольно проста и может быть выполнена в течение короткого мозгового штурма. На рисунке показаны основные компоненты и стек технологий, выбранных для разработки решения.
Рисунок 10. Эскиз N-уровневой архитектуры для системы Online Catering
Определение исходной модели развертывания
Используя представленный выше эскиз, архитектор может нарисовать картину развертывания модели. Он изображает основные компоненты программного и аппаратного обеспечения и их общее взаимодействие. Схема развертывания принимает во внимание ограничения среды развертывания и служит хорошим средством обмена информацией между группами разработки и инфраструктуры.
Спецификация UML предоставляет набор элементов для определения моделей развертывания. Однако в том, что касается возможностей развертывания, UML оказался ограниченным. В результате он не получил широкого распространения в отрасли, даже среди тех, кто интенсивно использует UML. RSA предоставляет богатый набор инструментов для определения топологий развертывания (логических, физических и примеров развертывания). Достоинства топологий RSA проявляются там, где пасуют UML-модели: в части простоты, многократного использования и отслеживания (подробнее о топологиях развертывания см. в разделе Ресурсы).
На схеме развертывания (рисунок 11) показаны различные компоненты оборудования, необходимые для размещения приложения. RSA содержит банк изображений, помогающих сделать диаграмму более наглядной, и позволяет добавлять свои собственные изображения для обозначения специальных элементов модели.
Рисунок 11. Узлы развертывания системы Online Catering
При создании бизнес-приложений исходная модель домена помогает группе разработчиков изучить основные бизнес-объекты и отношения между ними. Архитектор может получать информацию из различных источников, таких как функциональные требования, сценарии или бизнес-процессы.
Простой способ изучения объектов предприятия в RSA обеспечивает аналитический профиль. Этот профиль содержит три стереотипа, которые можно применять к элементам UML (рисунок 12).
Стереотип Boundary используется для представления класса, действующего в качестве интерфейса к системе. Класс Control описывает компонент, осуществляющий контроль над другими классами. Стереотип Entity определяет класс, содержащий данные.
На этом этапе нам нужны только данные, поэтому используется только стереотип Entity. Важно составить общую лексику реализуемой системы. Это отправная точка аналитической модели, которая создается на следующем шаге.
Шаблон Analysis Model, присутствующий в RSA, готов к применению и содержит специальный пакет Perspective overviews для сбора информации, относящийся к ключевым понятиям (рисунок 13).
Рисунок 13. Пакет Perspective overviews для системы Online Catering
Чтобы составить первый проект модели домена с помощью аналитических стереотипов, архитектор может воспользоваться простой схемой класса (содержащей ключевые бизнес-объекты - рисунок 14).
Рисунок 14. Модель домена Online Catering
Имеются и другие способы определения модели домена в RSA. Во-первых, можно выбрать создание простого эскиза, отражающего бизнес-объекты (рисунок 15).
Рисунок 15. Эскиз модели домена системы Online Catering
Если нужно более формальное представление, в RSA элементы эскиза можно преобразовать в элементы UML с сохранением прослеживаемости между сгенерированным UML-кодом и первоначальным эскизом. Другая возможность ― создание схемы данных. На схемах RSA можно создавать таблицы, столбцы и ключи, отражающие ваши данные, или подключиться к базе данных, чтобы импортировать существующую схему. Выбор способа определения модели домена на самом деле зависит от вашей среды и способа работы проектной группы. Идеального решения не существует, но какое-то, безусловно, будет наиболее подходящим для вас.
На этом этапе мы определили план архитектуры программного обеспечения сложной программной системы. Зная, какие представления полезны для тех или иных субъектов и какие требования оказывают значительное влияние на техническое решение, мы наметили соответствующую целевую архитектуру. За короткое время (итерация 0) мы собрали в RSA ключевую информацию, связанную с технологиями, развертыванием и моделями домена.
Во второй статье этого цикла мы покажем, как использовать RSA для уточнения архитектуры сложной программной системы.
|
Описание |
Имя |
Размер |
Метод загрузки |
|---|---|---|---|
| RSA-модели Yummy | Yummy2011.zip | 84 КБ | HTTP |