Содержание


Переход к SOA

Часть 1. От бизнес-процессов к архитектуре на базе моделей сервисов с использованием IBM WebSphere Business Modeler и IBM Rational Software Architect

Comments

Серия контента:

Этот контент является частью # из серии # статей: Переход к SOA

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Переход к 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, описывающего обработку клиентских заказов
Рисунок 1. Часть бизнес-процесса в WebSphere Business Modeler, описывающего обработку клиентских заказов
Рисунок 1. Часть бизнес-процесса в WebSphere Business Modeler, описывающего обработку клиентских заказов

UML-представление бизнес-процесса включает в себя диаграмму моделей применения (UML use case), описывающих каждый процесс, и участников (UML Actors) для каждой роли, участвующей в модели применения. Это представление показывает связь между ролями и процессами на высоком уровне абстракции, что удобно для обзора бизнес-процесса. На рисунке 2 показаны модель применения и участники бизнес-процесса обработки заказа клиента.

Рисунок 2. Модель применения бизнес-процесса обработки заказа клиента
Рисунок 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), показывающая связи между моделью применения, интерфейсом и деятельностью
Рисунок 3. UML-диаграмма сотрудничества для бизнес-процесса обработки заказа клиента (Customer Order Handling business process), показывающая связи между моделью применения, интерфейсом и деятельностью
Рисунок 3. UML-диаграмма сотрудничества для бизнес-процесса обработки заказа клиента (Customer Order Handling business process), показывающая связи между моделью применения, интерфейсом и деятельностью

Совет:
Связь между элементами модели Бизнес-анализа в WebSphere Business Modeler с их UML-аналогами более подробно обсуждается в статье Джима Амсдена о моделировании бизнес-сервисов из серии "Modelling SOA" авторства (см. раздел Ресурсы).

Рисунок 4. UML-представление модели из WebSphere Business Modeler в Rational Software Architect
Рисунок 4. UML-представление модели из WebSphere Business Modeler в Rational Software Architect
Рисунок 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. Создание трансформации бизнес-процесса в модель сервисов
Рисунок 5. Создание трансформации бизнес-процесса в модель сервисов
Рисунок 5. Создание трансформации бизнес-процесса в модель сервисов

Рисунок 6 иллюстрирует пример модели в WebSphere Business Modeler и цели, которой может быть любой проект в Eclipse или папка, куда Вы хотели бы поместить результат трансформации.

Рисунок 6. Указание источника трансформации
Рисунок 6. Указание источника трансформации
Рисунок 6. Указание источника трансформации

UML-модель сервисов, созданная при трансформации, представляет декомпозицию сервисов из модели анализа для каждого бизнес-процесса. Вы можете настроить тип декомпозиции в пользовательском интерфейсе при настройке трансформации и применять его к конкретным бизнес-процессам. Структура декомпозиции зависит от целевой предметной области (язык реализации, среда развертывания и т.д.).

Декомпозиция каждого сервиса формируется определенным расширением. Хотя механизм трансформации поставляется с тремя расширениями, не обязательно ограничиваться только ими (высокоуровневая модель UML, базовая декомпозиция SCDL и пустая реализация - без трансформации). Механизм трансформации позволяет клиентам создавать собственные расширения. Мы рассмотрим далее каждое из этих стандартных расширений более подробно.

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

Верификация соглашений (contract) при отслеживании требований

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

Бизнес-процесс в модели спецификации представляется как элемент UML-диаграммы сотрудничества (collaboration). Элементы сотрудничества модели спецификации трансформируются в элементы UML- компонентов (UML Component) в архитектурной модели решения. Трансформация снабжает сгенерированные компоненты портами, которые определяют интерфейсы сервисов, необходимые бизнес-процессу или предоставляемые им.

Также трансформация генерирует в каждом компоненте элемент CollaborationUse. Элемент CollaborationUse обеспечивает связь между исходным элементом сотрудничества в модели спецификации и элементом UML- компонента (далее просто Компонентом) модели сервисов. Трансформация создает UML-привязки между портами компонента и ролями сотрудничества (collaboration roles). Порт и ролевые привязки, установленные с помощью элемента CollaborationUse, определяют роли в требованиях соглашения, которые играют участники в сервисном ПО. Это позволяет отслеживать связи между решением и бизнес-требованиями, которые это решение удовлетворяет, а также дает способ проверки, что решение действительно удовлетворяет бизнес-требованиям, представленным в бизнес-модели WebSphere Business Modeler.

Обратите внимание на пример на рисунке 7, где показана верификация соглашений для бизнес-процесса обработки клиентских заказов и связанной с ним модели сервисов.

Рисунок 7. Пример диаграммы составной структуры
Рисунок 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. Указание типов декомпозиции бизнес-процессов в настройках трансформации
Рисунок 8. Указание типов декомпозиции бизнес-процессов в настройках трансформации
Рисунок 8. Указание типов декомпозиции бизнес-процессов в настройках трансформации

Как иллюстрирует рисунок 9, расширение Реализации по умолчанию генерирует декомпозицию, где поведение описывается элементом деятельности, скопированным из модели бизнес-анализа.

Рисунок 9. Расширение Реализации по умолчанию
Рисунок 9. Расширение Реализации по умолчанию
Рисунок 9. Расширение Реализации по умолчанию

Замечание:
Вариант без трансформации (Do Not Transform) предлагается для случая, когда Вы не хотите трансформировать конкретный процесс. Это расширение означает просто игнорирование этого процесса.

Реализация «только каркас» (Skeleton Only) трансформирует поведение в структуру, создавая общую декомпозицию для CSDL (см. рисунок 9). Для каждой роли сотрудничества создается внутренний компонент, чтобы любая предварительная обработка (например, получение прокси) происходила до вызова соответствующего этой роли участника (возможно, другого сервиса). Такая модель может использоваться трансформацией UML в SOA для генерации результатов, которые можно развернуть с помощью IBM® WebSphere® Integration Developer.

Рисунок 10. Декомпозиция SCDL, созданная расширением Skeleton Only
Рисунок 10. Декомпозиция SCDL, созданная расширением Skeleton Only
Рисунок 10. Декомпозиция SCDL, созданная расширением Skeleton Only

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

Пример создания собственной декомпозиции будет представлен в следующей статье этой серии - "Переход к SOA: Часть 2. Создание собственных расширений для инструментария трансформации бизнес-процессов в модели сервисов в IBM Rational Software Architect" (см. раздел Другие статьи этой серии в оглавлении).

О чем Часть 2

Эта статья будет посвящена интеграции артефактов WebSphere Business Modeler в среду Rational Software Architect и инструментарию для обеспечения взаимосвязи бизнес-моделей и моделей анализа и проектирования ПО. В части 2 будет представлен пошаговый пример создания собственной декомпозиции процессов для трансформации бизнес-процессов в модели сервисов. Она ориентирована на читателей, знакомых с созданием трансформационных расширений.


Ресурсы для скачивания


Похожие темы

  • Оригинал статьи: "Transformation to SOA: Part 1. From business process to service model architecture using IBM WebSphere Business Modeler and IBM Rational Software Architect" (EN)
  • В качестве дополнительной полезной информации прочитайте серию из пяти статей Джима Амсдена (Jim Amsden) о разработке ПО на базе сервис-ориентированной архитектуры:

    • Статья Modeling SOA: Part 1. Service identification (EN) расскажет вам, как использовать UML-модели, расширенные с помощью UML-профиля IBM Software Service Profile, для проектирования SOA-решений, привязанных к бизнес-требованиям, но независимых от реализации решения. Автор описывает цели и задачи бизнеса и реализованные для их решения бизнес-процессы; далее он описывает, как использовать эти процессы для определения подходящих для бизнеса сервисов, необходимых для удовлетворения требований, которые они представляют.
    • Статья Modeling SOA: Part 2. Service specification (EN). Автор продолжает повествование о SOA-решении, подробно моделируя спецификацию каждого сервиса. Эти спецификации определяют соглашения между потребителями и поставщиками сервисов. Соглашения включают предоставляемые и требуемые интерфейсы, роли, которые эти интерфейсы играют в спецификации сервиса, и правила или протокол взаимодействия этих ролей.
    • Статья Modeling SOA: Part 3. Service realization (EN). В третьей статье объясняется, как реализуются Web-сервисы на базе SOA. Реализация сервиса начинается с решения о том, какой компонент будет предоставлять этот сервис. Это решение тесно связано с такими аспектами, как доступность сервиса, распределение, безопасность, объем транзакций и степень связанности. После того, как эти решения приняты, вы можете смоделировать, как каждая функциональная возможность сервиса будет реализована и как требуемые сервисы будут использоваться. Далее вы можете с помощью инструментария трансформации из UML в SOA из состава IBM Rational Software Architect создать реализации Web-сервисов, которые уже могут использоваться в IBM WebSphere Integration Developer для реализации, тестирования и развертывания законченного решения.
    • Статья Modeling SOA: Part 4. Service composition (EN). Эта четвертая статья описывает, как собирать и связывать сервисных провайдеров, смоделированных в статье «Part 3. Service realization»? и определять их взаимодействие, формируя законченное решение, удовлетворяющее бизнес-требованиям. Получившийся компонент станет участником сервисных взаимодействий; при этом он сам будет охватывать сервисы, предоставленные существующими компонентами Invoicer, Productions и Shipper, в итоге предоставляя возможность обработки заказов. Также будет показано, как этот компонент будет удовлетворять входным бизнес-требованиям.
    • Статья Modeling SOA: Part 5. Service implementation (EN). В этой заключительной статье серии автор описывает, как разрабатывать конкретную реализацию, удовлетворяющую архитектурным и проектировочным решениям, основанным на модели сервисов. Мы сгенерируем решение под конкретную платформу, применив для создания Web-сервиса из SOA-модели подход разработки на базе моделей (model-driven development) и инструментарий трансформации UML в SOA из состава IBM Rational Software Architect.
  • В разделе о SOA и Web-сервисах на developerWorks имеются все ресурсы, необходимые для овладения сервис-ориентированной архитектурой.
  • Посетите раздел SOA-решений (EN) раздел SOA-решений.
  • В разделе ПО Rational на developerWorks приведена техническая информация и оптимальные методики использования продуктов Rational Software Delivery Platform.
  • Подпишитесь на рассылку раздела ПО Rational на developerWorks, чтобы своевременно получать всю информацию в этой области (EN). Раз в две недели вы будете получать свежие новости о технических ресурсах и оптимальных методиках для платформы Rational Software Delivery Platform.
  • Скачайте ознакомительную версию IBM Rational Software Architect, Version 7 (EN).
  • Скачайте ознакомительные версии продуктов IBM (EN) и испытайте в действии инструментарий и промежуточное ПО DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational, SOA и web-сервисы
ArticleID=390296
ArticleTitle=Переход к SOA: Часть 1. От бизнес-процессов к архитектуре на базе моделей сервисов с использованием IBM WebSphere Business Modeler и IBM Rational Software Architect
publish-date=05192009