 | Уровень сложности: средний Николас Беннетт, инженер-программист, IBM
Наталья Балаба-Лясковски, инженер-программист, IBM
19.05.2009 Среда разработки IBM® Rational® Software Architect предоставляет необходимый инструментарий для моделирования SOA-решений на языке моделирования UML при проектировании сервис-ориентированной архитектуры (SOA). В данной серии из четырех статей рассказывается об этой функциональности, предназначенной для SOA-трансформации. В данной статье описывается использование IBM® WebSphere® Business Modeler и Rational Software Architect при трансформации бизнес-процессов в SOA-модель.
Обзор модели анализа бизнес-процесса
Типичный цикл разработки начинается с получения и анализа бизнес-требований и целей. Частью процесса анализа является выявление ключевых сервисов, необходимых для создания SOA-решений, удовлетворяющих бизнес-требованиям.
Задача анализа бизнес-требований обычно возлагается на бизнес-аналитика, который, как правило, используя IBM® WebSphere® Business Modeler, создает модель бизнес-анализа (Business Analysis model), или, как её еще называют, модель спецификации сервисов (Service Specification model); а также оптимизирует и расширяет её с использованием встроенных функций анализа и эмуляции ПО WebSphere. Конечным продуктом этого этапа анализа является модель, описывающая ключевые сервисы (бизнес-процессы), их взаимодействие и то, как они вызываются клиентами или другими сервисами.
Детальное описание моделирования спецификаций сервисов можно найти в статье Джима Амсдена "Modeling SOA: Service Specification" из серии "Modeling SOA" (см. раздел Ресурсы).
Представление бизнес-процесса на более высоком архитектурном уровне
Следующий шаг цикла разработки - переход от модели бизнес-анализа к модели проектирования архитектуры решения (Design Solution Architecture model). Это шаг обычно выполняет архитектор программного решения. На этом шаге помогают средства перехода от бизнес-процесса к модели сервисов, входящие в IBM® Rational® Software Architect.
Вы можете использовать проект моделирования из среды WebSphere Business Analysis в среде Rational Software Architect, если была сконфигурирована возможность интеграции - WebSphere Business Modeler Integration feature. Когда вы откроете этот проект, в памяти создается UML-представление бизнес-модели, которое вы можете использовать как базис для моделирования требований бизнес-операций.
Модель бизнес-анализа из WebSphere Business Modeler преобразуется в UML-представление на основе ролевой трактовки бизнес-процесса. При этом бизнес-процесс рассматривается как взаимодействие необходимых для выполнения задач ролей и сервисов, вовлеченных в процесс. Каждую роль можно рассматривать как UML-интерфейс, определяющий операции для задач и сервисов в WebSphere Business Modeler service, за которые эта роль отвечает. На рисунке 1 показана часть бизнес-процесса в WebSphere Business Modeler, описывающего обработку клиентских заказов (Customer Order Handling business process). На этом рисунке проиллюстрированы дорожки, каждая из которых представляет конкретную роль, участвующую в процессе.
Рисунок 1. Часть бизнес-процесса в WebSphere Business Modeler, описывающего обработку клиентских заказов
UML-представление бизнес-процесса включает в себя диаграмму моделей применения (UML use case), описывающих каждый процесс, и участников (UML Actors) для каждой роли, участвующей в модели применения. Это представление показывает связь между ролями и процессами на высоком уровне абстракции, что удобно для обзора бизнес-процесса. На рисунке 2 показаны модель применения и участники бизнес-процесса обработки заказа клиента.
Рисунок 2. Модель применения бизнес-процесса обработки заказа клиента
На рисунке 3 ниже по тексту показана UML-диаграмма сотрудничества (collaboration) для того же процесса, а также его связи с UML-интерфейсами соответствующих ролей и его UML-моделями применения. На нижеследующих рисунках обратите внимание, что задачи, требующие роли CRMApplication (например, Determine Requester Status) на рисунке 1, преобразованы в операции UML-интерфейса CRMApplication (см. рисунок 3).
В дополнение к диаграммам моделей применения и сотрудничества также показан поведенческий аспект бизнес-процесса (то, как роли взаимодействуют друг с другом при выполнении их задач), представленный как UML-деятельность (UML Activity) в рамках сотрудничества. Каждая задача исходного бизнес-процесса представляется UML-операцией вызова (UML Call Operation), которая совершает нужный вызов, как определено в вышеописанных интерфейсах ролей. , На UML-диаграмме деятельности также показаны последовательность выполнения задач, и управляющие узлы (решения, ветвления, слияния). Диаграмма сотрудничества показывает, какие роли сотрудничают в рамках процесса, а UML-диаграмма деятельности уточняет, как эти роли взаимодействуют друг с другом. Разделы UML-диаграммы деятельности представляют сотрудничающие роли. Эта UML-модель обеспечивает основу описания, определяющего как структурные, так и поведенческие требования, которому должна удовлетворять любая реализация этого бизнес-процесса.
Рисунок 3. UML-диаграмма сотрудничества для бизнес-процесса обработки заказа клиента (Customer Order Handling business process), показывающая связи между моделью применения, интерфейсом и деятельностью
Совет:
Связь между элементами модели Бизнес-анализа в WebSphere Business Modeler с их UML-аналогами более подробно обсуждается в статье Джима Амсдена о моделировании бизнес-сервисов из серии "Modelling SOA" авторства (см. раздел Ресурсы).
Рисунок 4. UML-представление модели из WebSphere Business Modeler в Rational Software Architect
UML-представление модели в WebSphere Business Modeler предлагается рассматривать как соглашение о требованиях, которым должна удовлетворять архитектурная модель решения. Цель инструмента трансформации бизнес-процессов в модель сервисов в Rational Software Architect состоит в создании начальной модели SOA-решения (модели по умолчанию).
Для создания и конфигурирования этой трансформации выберите Modeling >
Transform > Create new configuration menu в перспективе Modelling (см. рисунок 5). Трансформация принимает модель, открытую в WebSphere Business Modeler, в качестве источника и любой проект в Eclipse в качестве цели.
Рисунок 5. Создание трансформации бизнес-процесса в модель сервисов
Рисунок 6 иллюстрирует пример модели в WebSphere Business Modeler и цели, которой может быть любой проект в Eclipse или папка, куда Вы хотели бы поместить результат трансформации.
Рисунок 6. Указание источника трансформации
UML-модель сервисов, созданная при трансформации, представляет декомпозицию сервисов из модели анализа для каждого бизнес-процесса. Вы можете настроить тип декомпозиции в пользовательском интерфейсе при настройке трансформации и применять его к конкретным бизнес-процессам. Структура декомпозиции зависит от целевой предметной области (язык реализации, среда развертывания и т.д.).
Декомпозиция каждого сервиса формируется определенным расширением. Хотя механизм трансформации поставляется с тремя расширениями, не обязательно ограничиваться только ими (высокоуровневая модель UML, базовая декомпозиция SCDL и пустая реализация - без трансформации). Механизм трансформации позволяет клиентам создавать собственные расширения. Мы рассмотрим далее каждое из этих стандартных расширений более подробно.
После того, как модель сгенерирована при трансформации, системный архитектор или архитектор ПО может усовершенствовать модель сервисов, указывая дополнительные детали реализации или ссылаясь на другие сервисы или унаследованные библиотеки для повышения степени многократного использования.
Верификация соглашений (contract) при отслеживании требований
Независимо от конкретной декомпозиции созданная трансформацией архитектурная модель решения (также называется моделью сервисов или моделью реализации соглашений) сохраняет информацию о соглашениях, определенную в модели спецификации. Также передаются детали реализации, необходимые для удовлетворения соглашений.
Бизнес-процесс в модели спецификации представляется как элемент UML-диаграммы сотрудничества (collaboration). Элементы сотрудничества модели спецификации трансформируются в элементы UML- компонентов (UML Component) в архитектурной модели решения. Трансформация снабжает сгенерированные компоненты портами, которые определяют интерфейсы сервисов, необходимые бизнес-процессу или предоставляемые им.
Также трансформация генерирует в каждом компоненте элемент
CollaborationUse. Элемент CollaborationUse обеспечивает связь между исходным элементом сотрудничества в модели спецификации и элементом UML- компонента (далее просто Компонентом) модели сервисов. Трансформация создает UML-привязки между портами компонента и ролями сотрудничества (collaboration roles). Порт и ролевые привязки, установленные с помощью элемента CollaborationUse, определяют роли в требованиях соглашения, которые играют участники в сервисном ПО. Это позволяет отслеживать связи между решением и бизнес-требованиями, которые это решение удовлетворяет, а также дает способ проверки, что решение действительно удовлетворяет бизнес-требованиям, представленным в бизнес-модели WebSphere Business Modeler.
Обратите внимание на пример на рисунке 7, где показана верификация соглашений для бизнес-процесса обработки клиентских заказов и связанной с ним модели сервисов.
Рисунок 7. Пример диаграммы составной структуры
Компонент Customer Order Handling (Обработка пользовательского запроса), представляющий сервис, содержит элемент CollaborationUse типа Collaboration, который адресует элемент сотрудничества Customer Order Handling Collaboration, определенный в модели бизнес-анализа, созданной в WebSphere Business Modeler. Роли Customer Order Handling Collaboration исполняются портами компонентов или привязаны к ним. Каждый порт определяет предоставляемые или требуемые бизнес-процессами интерфейсы, описанные в модели бизнес-анализа. Например, порт, предоставляющий интерфейс сервису (myRole), привязан к роли Collaboration (Сотрудничество), которая представляет собственно сам бизнес-процесс. Другие порты, которые представляют различных участников (возможно, даже другие сервисы), привязаны к своим соответствующим ролям в элементе Collaboration (Сотрудничество). Этим портам (к примеру, PaymentHandling, OrderVerification, CRMApplication и другие) необходимы интерфейсы для взаимодействия с соответствующими участниками. Как требуемые, так и предоставляемые интерфейсы определяются в модели бизнес-анализа, и модель сервисов в Rational Software Architect ссылается на эти интерфейсы, как иллюстрирует Таблица 1.
Таблица 1. Результаты трансформации
| Элемент модели спецификации | Результат трансформации (высокоуровневая архитектурная UML-модель) |
|---|
| Модель или пакет | Трансформация создает одноименные UML-модель или пакет, которые будут содержать вложенные пакеты и сотрудничества (collaborations). Вложенные пакеты или сотрудничества также могут содержать UML-диаграммы деятельности. Интерфейсы, классы и типы данных, а также элементы деятельностей не трансформируются. В случае необходимости создаются связи между сгенерированной моделью и исходной. К сгенерированной модели применяется UML-стереотип <<serviceModel>>.
|
|---|
| Сотрудничество (Collaboration) | Трансформация создает UML-компонент со стереотипом <<serviceProvider>> из примененного к нему UML-профиля Software Services. Сгенерированный компонент имеет те же имя и структуру, что и исходный элемент сотрудничества.Трансформация для каждого компонента создает элемент CollaborationUse. Тип элемента CollaborationUse устанавливается как элемент сотрудничества исходной модели. Каждый порт в сгенерированном компоненте связывается с соответствующей ролью сотрудничества с помощью элемента CollaborationUse. За более подробным описанием созданных трансформацией портов обратитесь к строке, описывающей Collaboration role::type в этой таблице.
|
|---|
| Роль в сотрудничестве (Collaboration role) | Трансформация создает UML-порт для компонента. Этот сгенерированный порт имеет то же имя, что и роль в исходной модели. Каждый порт привязывается к роли с помощью ассоциации использования.
|
|---|
| Тип роли в сотрудничестве (Collaboration role::type) |
Если свойство role::type определяет тот же интерфейс, что реализуется элементом сотрудничества, то интерфейсу, предоставляемому портом, устанавливается свойство role::type.Также этому интерфейсу устанавливается тип порта. Все другие свойства role::type устанавливаются в требуемый внешними участниками интерфейс. Трансформация устанавливает тип порта как UML-класс, который имеет отношение использования интерфейса, определенное в исходной модели. Имя UML-класса в отношении использования такое же, как имя интерфейса в исходной модели, но с суффиксом Protocol.
|
|---|
Выбор процесса декомпозиции
Инструмент трансформации бизнес-процессов в модель сервисов предоставляет расширения для преобразования бизнес-процессов в модель спецификации.
Декомпозиция Реализации по умолчанию (Default Implementation decomposition) описывает поведение процесса, назначая UML-диаграмму деятельности (UML-деятельность) в качестве поведения бизнес-процесса, как определено UML-компонентом (см. рисунок 8). Эта декомпозиция позже может использоваться в трансформации UML в SOA для генерации модулей языка определения сервисных компонентов (SCDL - Services Component Definition Language) с артефактами на языке выполнения бизнес-процессов (BPEL - Business Process Execution Language).
Рисунок 8. Указание типов декомпозиции бизнес-процессов в настройках трансформации
Как иллюстрирует рисунок 9, расширение Реализации по умолчанию генерирует декомпозицию, где поведение описывается элементом деятельности, скопированным из модели бизнес-анализа.
Рисунок 9. Расширение Реализации по умолчанию
Замечание:
Вариант без трансформации (Do Not Transform) предлагается для случая, когда Вы не хотите трансформировать конкретный процесс. Это расширение означает просто игнорирование этого процесса.
Реализация «только каркас» (Skeleton Only) трансформирует поведение в структуру, создавая общую декомпозицию для CSDL (см. рисунок 9). Для каждой роли сотрудничества создается внутренний компонент, чтобы любая предварительная обработка (например, получение прокси) происходила до вызова соответствующего этой роли участника (возможно, другого сервиса). Такая модель может использоваться трансформацией UML в SOA для генерации результатов, которые можно развернуть с помощью IBM® WebSphere® Integration Developer.
Рисунок 10. Декомпозиция SCDL, созданная расширением Skeleton Only
Для создания моделей сервисов, содержащих детали реализации из других предметных областей, клиенты могут создавать и регистрировать собственные расширения трансформации бизнес-процессов в модели сервисов.
Пример создания собственной декомпозиции будет представлен в следующей статье этой серии - "Переход к SOA: Часть 2. Создание собственных расширений для инструментария трансформации бизнес-процессов в модели сервисов в IBM Rational Software Architect" (см. раздел Другие статьи этой серии в оглавлении).
О чем Часть 2
Эта статья будет посвящена интеграции артефактов WebSphere Business Modeler в среду Rational Software Architect и инструментарию для обеспечения взаимосвязи бизнес-моделей и моделей анализа и проектирования ПО. В части 2 будет представлен пошаговый пример создания собственной декомпозиции процессов для трансформации бизнес-процессов в модели сервисов. Она ориентирована на читателей, знакомых с созданием трансформационных расширений.
Ресурсы Научиться
Получить продукты и технологии
Обсудить
Об авторах | | | Николас Беннетт (Nicholas Bennett) – инженер-программист, занимается поддержкой инструментария IBM Rational. |
| | | Наталья Балаба-Лясковски (Natalia Balaba-Liaskovski) – инженер-программист, занимается поддержкой инструментария IBM Rational. |
Выскажите мнение об этой странице
| |
