Моделируем сервис-ориентированную архитектуру при помощи IBM Rational Software Architect: Часть 1. Учебный пример, инструменты и бизнес-видение

Перед началом работы

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

О данной серии

В этой серии подробно рассматривается моделирование сервис-ориентированной архитектуры (service-oriented architectures, SOA) при помощи инструмента IBM® Rational® Software Architect. Хотя изначально это программное решение предназначалось для разработчиков архитектуры программного обеспечения и для поддержки их деятельности, оно может оказаться полезным также специалистам, выполняющим другие роли в процессе разработки программного обеспечения, в том числе тем, кто вносит свой вклад в разработку архитектуры ПО, например, бизнес-аналитикам или тем, кто использует эту архитектуру в качестве отправной точки собственной деятельности, например, проектировщикам программного обеспечения и разработчикам (занимающимся реализацией архитектуры, проектированием и созданием ПО). Кроме того, в этой серии объясняются многие основные концепции SOA, которые могут заинтересовать и других специалистов. См. в разделе Ресурсы ссылку на часть 2.

Эти учебные руководства концентрируются на трех темах:

• Архитектура: описывает, из чего состоит архитектура и как она вписывается в общий процесс разработки программного обеспечения;
• Сервисы: создают архитектуру SOA-системы (сервисы - основное понятие этой архитектуры);
• Модели: демонстрируют, как Rational Software Architect поддерживает использование принципа разработки, управляемой моделями (MDD) при детализации сервис-ориентированной архитектуры.

Серия начинается с описания архитектуры программного обеспечения и определения места сервисов в архитектуре. Затем рассказывается о программном продукте Rational Software Architect, его функциях и инструментах, имеющих отношение к SOA- и архитектуре.

Учебный пример с воображаемым бизнесом по прокату DVD-дисков через интернет, который используется на протяжении всей серии статей, помогает проиллюстрировать главные задачи:

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

О данном учебном руководстве

В данном учебном руководстве, которое представляет собой 1 часть серии, вводится учебный пример фирмы по прокату видеодисков, который используется во всех статьях серии. Кроме того, в нем рассказывается об инструменте Rational Software Architect (версия 7 и более поздние) и о функциях, которые мы будем использовать для моделирования сервисной архитектуры. И, наконец, рассказывается об использовании следующих двух моделей на входе деятельностей по моделированию сервисов: карты компонентного моделирования бизнесов (CBM) и модели бизнес-процесса.

Цели

Изучив данное учебное руководство, вы сможете:

• рассказать о бизнес-мотивах, лежащих в основе работ по созданию SOA-архитектуры для компании DVD2U;
• рассказать о Rational Software Architect;
• рассказать в общих чертах о том, как можно использовать Rational Software Architect для моделирования сервис-ориентированной архитектуры;
• назвать модели, которые используются на входе деятельностей по разработке сервис-ориентированной архитектуры;
• рассказать, что представляет собой карта компонентного моделирования бизнеса (CBM);
• описать бизнес-процесс Return Video , который использовался в этом проекте.

Необходимые условия

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

• нотация моделирования бизнес-процессов (Business Process Modeling Notation, BPMN);
• IBM WebSphere Business Modeler;
• сервис-ориентированная архитектура (service-oriented architecture, SOA);
• Rational Software Architect .

Требования к системе

• Rational Software Architect версии 7 (рекомендуется пакет исправлений fix 002) или более поздняя версия;
• WebSphere Business Modeler, версия 6.0.2 или более поздняя.

Учебный пример Video Rental

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

DVD2U - это фирма по прокату и продаже DVD-дисков, основанная в 1998 году. Бизнес компании заключается в предоставлении клиентам видеофильмов, которые трудно было найти в обычных магазинах видеофильмов, например, фильмы на иностранных языках или не пользующиеся широким спросом. С начала своей деятельности компания DVD2U сделала два крупных приобретения, в результате одного из которых она получила обширную базу клиентов компании, занимающейся традиционной продажей видеофильмов, другое приобретение дало фирме много DVD-дисков на иностранных языках, но совсем немного новых клиентов.

Из разговора с генеральным директором компании мы узнали, что около года назад он запустил новый интернет-проект. Вот механизм его работы: чтобы стать участниками сервиса, пользователи регистрируются на Web-сайте и оплачивают подписку на месяц. Участники составляют список нужных им фильмов из ассортимента, предоставленного компанией DVD2U, в режиме онлайн, как правило, такой список содержит около ста названий. Затем компания DVD2U пересылает DVD-диски участникам сервиса по обычной почте. Просмотрев фильм, участник возвращает DVD-диск по почте в предоплаченном почтовом конверте. Получив просмотренный DVD-диск, фирма DVD2U отправляет участнику следующий диск по списку.

В зависимости от типа (и стоимости) подписки участника фирма допускает выдачу со склада ограниченного количества дисков DVD за один раз (как правило, участники выбирают популярный план на 3 DVD). Компания DVD2U приветствует идею интернет-сообществ и стремится к созданию подобного сообщества на своем интернет-сайте; в таком сообществе участники могут общаться, оценивать фильмы, писать обзоры и даже знакомиться с пользователями, которые смотрели те же фильмы, что и они сами. По мнению пользователей, Web-сайт DVD2U очень эффективен для знакомства!

Однако гендиректор отметил: несмотря на то, что онлайновый сервис проката представляет собой прекрасную бизнес-возможность, с этим сервисом связан ряд проблем. Например, клиенты жалуются на то, что, по их впечатлению, они никогда не получают самые популярные фильмы из своих списков, иногда новый DVD-диск приходит только через несколько недель после того, как они отправили уже просмотренный диск по почте; иногда Web-сайт не функционирует, и они не могут обновить свои списки фильмов.

МЫ рассмотрели ряд других специфических проблем с используемым IT-решением:

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

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

Разработка процесса и методов

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

• Рабочий продукт: основной рабочий продукт для данной серии - это модель сервисов. Она представлена в виде UML-модели в Rational Software Architect. Модель сервисов описывает архитектурно-значимые элементы SOA при помощи UML-профиля для программирования сервисов (UML Profile for Software Services, UPSS). В части 1 данной серии рассказывается о программе Rational Software Architect и о профиле UPSS. В части 2 подробно описывается модель сервисов;
• Дисциплина: на рисунке 1 показаны дисциплины унифицированного процесса IBM Rational Unified Process (RUP), а также фазы и методы процесса разработки программного обеспечения. Бизнес (моделирование), Анализ, Проектирование и Реализация можно интерпретировать как уровни абстракции.
• Фаза: основной объем архитектурных деятельностей приходится на фазу проекта Elaboration (Уточнение). В ходе Начальной фазы (Inception) разработчик архитектуры отбирает архитектурно-значимые требования. В фазе Уточнение (Elaboration) создается "общий вид" архитектуры и представительный набор детализированных артефактов с акцентом на прецеденты высокого риска. Все остальные детали архитектуры будут созданы в ходе итераций в фазе Конструирования (Construction);
• Роль: разработчик архитектуры программного обеспечения выполняет основные задачи, которые иллюстрируются в данной серии учебных руководств. Эта роль отвечает за принятие основных технических решений, обеспечивающих создание системы, удовлетворяющей всем требованиям. Результат принятых решений уточняется в архитектуре программного обеспечения. Однако стоит отметить, что задачи, описываемые в этой части серии учебных руководств, в основном выполняются разработчиком архитектуры бизнеса и аналитиком бизнес-процессов;
• Деятельность: основная деятельность, о которой подробно рассказывается в данной серии, относится к моделированию сервис-ориентированной архитектуры (для краткости, SOA или сервисной архитектуры). Подключаемый модуль RUP for SOMA (Service-Oriented Modeling and Architecture, сервис-ориентированного моделирования и архитектуры), который добавляет к классическому процессу RUP SOA-контент, называет эту деятельность Детализацией сервисов.
• Инструмент: инструмент, который разработчики архитектуры программного обеспечения используют для моделирования - это Rational Software Architect. Rational Software Architect версии 7 и более поздних версий содержат больше функций для работы с SOA, чем предыдущие версии. Об этих функциях будет рассказано в данной части учебного руководства. Кроме того, в этой части используется еще один инструмент, WebSphere Business Modeler Advanced Edition (версии 6.0.2 и более поздних версий), при помощи которого бизнес-аналитики моделируют бизнес-процессы.

Рисунок 1. Дисциплины RUP

Стек SOA-решения

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

Рисунок 2. Стек SOA-решения

На данном рисунке имеется 5 функциональных уровней (снизу вверх):

• уровень операционных систем представляет имеющиеся информационные ресурсы (далее внешние системы) и показывает, что предыдущие инвестиции в IT являются значимыми и должны использоваться в SOA;
• на уровне компонентов сервисов представлены сервисы, возможно, через использование одного или более приложений уровня операционных систем. Как видно из рисунка 2 потребители и бизнес-процессы не имеют прямого доступа к компонентам - они имеют доступ только к сервисам. Существующие компоненты могут повторно использоваться внутри системы или, если это имеет смысл, использоваться SOA;
• уровень сервисов представляет сервисы, развернутые в конкретной среде. Эти сервисы представляют собой управляемые сущности, которые можно обнаруживать по специальной методике. Они объединяются поставщиком сервиса и потребляются потребителями сервисов;
• уровень бизнес-процесса представляет операционные артефакты, которые реализуют бизнес-процессы как хореографии сервисов;
• уровень потребителей представляет каналы, которые используются для доступа к бизнес-процессам, сервисам и приложениям.

4 нефункциональных уровня:

• уровень интеграции: предоставляет функции посредничества, маршрутизации и транспорта запросов сервисов правильно выбранному поставщику сервисов;
• уровень качества сервиса: предоставляет функции для удовлетворения нефункциональных требований SOA (например, надежности, доступности);
• уровень архитектуры информации: предоставляет функции поддержки данных, метаданных и интеллектуальных ресурсов предприятия;
• уровень управления: предоставляет функции поддержки управления операционным жизненным циклом бизнеса в SOA.

В нашей серии рассказывается о центральном уровне, уровне сервисов. Во второй части этой серии мы перейдем к детализации элементов модели рабочего продукта сервисной модели. В части 1 (то есть, в данном учебном руководстве) рассказывается об уровне бизнес-процессов. Такой подход часто называют подходом" сверху вниз" . Детализированные элементы проекта принадлежат к уровню компонентов сервисов. Использование унаследованных (не-SOA) систем из уровня операционных систем называют подходом " снизу вверх ". Мы рекомендуем комбинировать эти два подхода (такой подход называется "от краев к центру"): моделирование бизнес-процессов "сверху вниз" будет определять набор функций решения, а анализ имеющихся ресурсов "снизу вверх" обнаружит функции, предоставляемые внешними системами (не-SOA) вместе с любыми накладываемыми ими ограничениями. Обратите внимание на то, что имеющиеся модели сервисов могут описывать доступные имеющиеся функции SOA.

Эти модели используются на входе деятельности моделирования сервисов.

Следующие модели используются для осуществления деятельности моделирования сервисов:

• компонентная модель бизнеса: стратегическое деление организации на компоненты на бизнес-уровне;
• модель бизнес-процессов: поток задач, бизнес-элементы, которые передаются от задачи к задаче и роли, выполняющие эти задачи; кроме того, эта модель указывает, где необходима автоматизация;
• модель предметной области: консолидированное представление бизнес-информации;
• модель прецедентов системы: взаимодействия между действующими лицами (людьми и системами) и IT-системой, о которой идет речь;
• модель внешних систем: не-SOA системы, которые можно использовать;
• модель сервисов (аналитический уровень): группы идентифицированных и проверенных концептуальных сервисов.

В этом учебном руководстве, первом в данной серии, мы расскажем о компонентной бизнес-модели и модели бизнес-процессов.

Rational Software Architect версии 7 и более поздних версий

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

Rational Software Architect создан на основе Eclipse, платформы с открытым исходным кодом, а версия 7 построена на Eclipse версии 3.2. Программа поддерживает совместную работу разработчиков при помощи следующих технологий:

• разработка с использованием ресурсов (Asset-Based Development, ABD);
• инжиниринг с использованием шаблонов (Pattern-Based Engineering, PBE);
• унифицированный язык моделирования Unified Modeling Language (UML);
• Java™ Standard Edition;
• Java™ Enterprise Edition;
• спецификация многократно используемых ресурсов (Reusable Asset Specification, RAS);
• профили взаимодействия Web-сервисов (Web Services Interoperability, WS-I).

Rational Software Architect объединяет инструменты IBM® Rational® Software Modeler и IBM® Rational® Application Developer в интегрированную среду. Кроме того, программа представляет функции интеграции с другими продуктами, такими, как WebSphere Business Modeler, IBM® Rational® Clear Case®, CVS (система управления параллельными версиями), IBM® Rational® ClearQuest® и IBM® Rational® RequisitePro®.

Если вы - новичок в Rational Software Architect, можно порекомендовать вам ознакомиться с обучающим курсом на странице Welcome программы (она показана на рисунке 3), которое открывается при запуске Rational Software Architect с новой рабочей областью. Можно также вызвать эту страницу, выбрав в меню команды Help > Welcome.

Рисунок 3. Страница Welcome программы Rational Software Architect

На странице Welcome можно включить и отключить функции Rational Software Architect в зависимости от роли (в правом нижнем углу); кроме того, на этой странице имеются ссылки на информацию о Rational Software Architect, распределенную по следующим категориям:

• Overview (Обзор): описание функций, поддерживаемых Rational Software Architect;
• Tutorials (Учебные руководства): учебные руководства по использованию основных функций в области UML-моделирования или разработки приложений;
• Samples (Примеры): учебные проекты (примеры) содержат модель или код, демонстрируя основные функции инструментов в той же области, которая описывается в соответствующем учебном руководстве;
• What"s new (Новое): описание основных преимуществ функций данной версии;
• First steps (Первые шаги): в этой категории представлены пошаговые инструкции по выполнению основных задач, поддерживаемых Rational Software Architect;
• Web resources (Web-ресурсы): ссылки на полезные интернет-ресурсы, главным образом, на Web-сайты IBM® developerWorks®или ibm.com;
• Migrate (Миграция): информация по импорту проектов из других версий (например, Rational Software Architect версии 6) или инструментов (например, IBM® Rational Rose®).

Если вы - разработчик архитектуры программного обеспечения и не так давно начали использовать в работе Rational Software Architect, то мы настоятельно рекомендуем вам ознакомиться с материалами, которые находятся в следующей категории: Overview > Modeling Basics > Modeling life cycle support > Integrations for the development life cycle.

Выполните следующие шаги:

1. Установите программу Rational Software Architect (Rational Software Architect) версии 7 (см. ссылку на страницу загрузки в разделе Ресурсы), если это не было сделано ранее;
2. Запустите Rational Software Architect, выбрав из меню команды Start > All Programs > IBM Software Delivery Platform > IBM Rational Software Architect > IBM Rational Software Architect (Пуск > Программы > IBM Software Delivery Platform > IBM Rational Software Architect > IBM Rational Software Architect);
3. В диалоговом окне Workspace Launcher укажите каталог для рабочей области (например, C:\rsa-workspace) и нажмите кнопку OK.
4. После этого запустится Rational Software Architect, и вы увидите окно приветствия Welcome (рисунок 3);
5. Изучите документацию, о которой говорилось в данном разделе.

Перспектива для моделирования Modeling

В смысле пользовательского интерфейса (User Interface, UI) перспектива в Eclipse представляет собой набор представлений, объединенных в группы, поддерживающие определенные роли или деятельности. В Rational Software Architect имеются встроенные перспективы (например, перспективы Modeling, Plug-in Development или Java), кроме того, можно создавать новые перспективы. В данном учебном руководстве мы проведем большую часть времени в перспективе Modeling, показанной на рисунке 4.

Рисунок 4. Перспектива Modeling в Rational Software Architect

В перспективе Modeling 4 основных представления:

• представление Project Explorer (Обозреватель проектов), в котором можно наблюдать элементы модели и диаграммы, сгруппированные по проектам, моделям и пакетам;
• в представлении Diagram Editor (Редактор диаграмм) можно просматривать или изменять диаграммы, а также создавать, удалять или обновлять элементы моделей;
• представление Outline (Схема) позволяет увидеть, какая часть большой диаграммы в настоящее время отображается в представлении диаграммы;
• в представлении Properties (Свойства) отображается подробная изменяемая информация по выбранному элементу модели.

Выполните следующие шаги:

1. В окне Welcome нажмите и отпустите левую кнопку мыши на ссылке Go to the workbench, как показано на рисунке 5;
2. По умолчанию вы попадете в перспективу Resource. Перейдите в перспективу Modeling, выбрав из меню команды Window > Open Perspective > Modeling.

Это ваше последнее действие в Rational Software Architect в 1 части учебного руководства. Пока можно завершить работу программы.

Рисунок 5. Go to the workbench - ссылка для перехода в рабочую область
 

Новые функции SOA в версии 7

В составе 7 версии программного продукта Rational Software Architect появились две новые SOA-функции. Обращаем ваше внимание на то, что в 6 версии эти функции были доступны как дополнительные ресурсы на Web-сайте developerWorks. По мере того, как SOA становилась все более востребованной технологией, эти функции были интегрированы в продукт и в настоящее время поддерживаются в полной мере; в данном учебном руководстве мы ими воспользуемся:

• профилем для программирования сервисов UML 2 Profile for Software Services (UPSS): этот профиль определяет стереотипы, которые используются для моделирования сервисной архитектуры (например, "serviceSpecification", "serviceConsumer", "serviceProvider" и "service"). В следующих выпусках данной серии учебных руководств будет рассказываться о каждом из этих стереотипов по мере их использования в сервисной модели.
• преобразованием UML - WSDL: основной особенностью технологии MDD является возможность использовать преобразования для генерации целевой модели или кода из исходной модели или кода. Rational Software Architect предоставляет поддержку готовых преобразований, а также инфраструктуру для создания пользовательских преобразований. Преобразование UML to Web Services Definition Language (WSDL) (UML-язык определения Web-сервисов, WSDL) позволяет генерировать схемы WSDL и XLM на основе UML-модели. В нашем примере на входе преобразования будет использоваться модель сервисов. Поскольку модель сервисов описывает архитектурно-значимые компоненты системы, она будет использована для генерации архитектурно-значимых компонентов реализации. Дальнейшая детализация будет добавлена моделью проекта, которую можно использовать для генерации дополнительных деталей реализации (внутренняя реализация архитектурно-значимых компонентов).

На момент написания статьи мы пользовались версией 7 с пакетом исправлений fix 001. Рекомендуется пользоваться программой с последним пакетом исправлений, доступным на момент изучения учебного руководства.

Компонентная модель бизнеса

По определению, которое приводится в серии статей, посвященных терминологии SOA, компонентная модель бизнеса IBM (Component Business Model) представляет собой стратегический метод, позволяющий предприятиям сосредоточиться на основных компетенциях - компонентах бизнеса, которые отличают его от конкурентов, наблюдать за потреблением ресурсов и выбрать наиболее правильное соответствие между бизнес-целями и задачами информационных систем.

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

Учтите, что создание полномасштабной компонентной модели бизнеса обычно находится за рамками проекта разработки программного обеспечения: как правило, она создается в ходе работ по определению бизнес-стратегии и изменений. Если такая входная информация недоступна, то иногда имеет смысл создать базовую карту компонентной бизнес-модели, чтобы создать контекст для работ по бизнес-моделированию в проекте разработки программного обеспечения. Преимущество такой практики заключается в том, что CMB-карта предоставляет полезный контент для определяемых бизнес-процессов. Кроме того, она может использоваться как контрольная точка для проверки охвата моделируемых процессов: в полной ли мере учтен объем бизнеса, охваченного процессами?

На рисунке 6 показана карта компонентной модели бизнеса (Component Business Model Map) для компании DVD2U.

Рисунок 6. Карта компонентной модели бизнеса компании DVD2U

Компоненты бизнеса (функциональные области) могут принадлежать к одному из трех уровней ответственности (строк карты):

• Стратегический (Стратегия);
• Управленческий (Руководство);
• Исполнительский.

DVD2U обладает четырьмя бизнес-компетенциями (столбцы карты):

• Складская деятельность: запасы, поставки и возвраты;
• Продажи: почтовые продажи, продажи со склада и промоутерская деятельность;
• Прокат: прокат со склада, по интернету или почте;
• Маркетинг: формирование цен, маркетинговая компания и реклама.

Проведя семинар по компонентной модели бизнеса, мы узнали, что бизнес-компонент Online Rentals (в иерархии Rental, Execute) является основным интересующим нас бизнес-компонентом. В компонентной модели бизнеса он называется горячим компонентом , поэтому на рисунке 6 обозначен звездочкой. Следовательно, компонент Online Rentals представляет собой функциональную область бизнеса, для которой в программе работ компонентной модели бизнеса будут выделяться люди, процессы, системы и, самое важное, сервисы.

Модель бизнес-процесса:

На рисунках 7 и 8 изображена схема бизнес-процесса Return Video , который принадлежит к бизнес-компетенции Online Rentals. Это бизнес-процесс, задающий масштаб SOA-проекта, для которого мы моделируем архитектуру в наших учебных руководствах.

Рисунок 7. Бизнес-процесс Return Video (1 из 2)

Согласно рисунку 7, процесс протекает следующим образом:

1. Участник сервиса DVD2U, воспользовавшись предоплаченным конвертом, возвращает видеодиск на склад DVD2U;
2. По желанию участник заходит в свою учетную запись в системе DVD2U через Web-браузер и обновляет список фильмов, отмечая, какой фильм он отправил по почте (сдал);
3. После этого система возвращает информацию о репутации участника;
4. Через день или два сотрудник DVD2U, отвечающий за возврат дисков, получает видеофильмы;
5. Затем упомянутый сотрудник проверяет состояние DVD-диска.

Рисунок 8. Бизнес-процесс Return Video (2 из 2)

Согласно рисунку 8, процесс протекает следующим образом:

1. Если участник, сообщивший о возврате видеофильма, имеет хорошую репутацию, то система обновляет профиль участника, чтобы сообщить, что следующий фильм из списка подлежит выдаче;
2. Проверив видеодиск, сотрудник, занимающийся получением дисков, делает запись в системе о возврате видеофильма;
3. Система добавляет копию видеофильма в общий запас хранилища.

Обратите внимание, что в объеме работ по моделированию бизнес-процесса идентифицированы и кодифицированы следующие моменты:

• Роли: участник (Member, верхняя дорожка (swim-lane)) и сотрудник, отвечающий за получение дисков (Receiving Clerk, средняя дорожка);
• Автоматизированные процедуры (классификаторы): Human Only (человек, оранжевый), Human-System (человек-система, синий), System-Human (система-человек, голубой, не показан), and System Only (система, серый);
• IT-системы (классификаторы): Membership Management (Управление членством), Stock Management (Управление складом) и Member Management (управление участниками) (все в составе Customer Relationship Management (Управление взаимоотношениями с клиентами). Обратите внимание, что распространенной альтернативой использованию классификаторов для моделирования IT-систем является моделирование их как отдельных ресурсов в WebSphere Business Modeler.

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

Выполните следующие шаги:

1. Установите программу WebSphere Business Modeler Advanced Edition (версии 6.0.2 или более поздней), если это не было сделано ранее.
2. Запустите программу WebSphere Business Modeler.
3. В открывшемся диалоговом окне нажмите кнопку Browse, а затем создайте папку для рабочей области WebSphere Business Modeler (например, C:\temp\wbm-workspace). Нажмите кнопку OK;
4. Откроется главное окно WebSphere Business Modeler и автоматически запустится мастер Quick Start. Дайте новому проекту имя DVD2U Online Rentals и нажмите кнопку Finish.

Теперь мы импортируем предоставленную модель бизнес-процесса.

1. Выберите из меню команды File > Import;
2. В окне мастера импорта выберите WebSphere Business Modeler Import и нажмите кнопку Next;
3. Выберите WebSphere Business Modeler Project (.mar, .zip) и нажмите кнопку Next;
4. Нажмите кнопку Browse и укажите каталог, в котором вы сохранили файл архива. В секции Files выберите файл DVD-Rental.mar. Выберите проект DVD2U Online Rentals. Установите флажок Overwrite existing elements и нажмите кнопку Finish;
5. Изучите модель и обратите внимание на диаграммы, которые упоминались в данном разделе.

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

Заключение

В данном учебном руководстве мы подготовили почву для моделирования сервис-ориентированной архитектуры при помощи Rational Software Architect. В этой части серии мы использовали подход "сверху вниз" и описали компанию DVD2U, ее бизнес и проблемы этого бизнеса. Затем мы позиционировали архитектуру программного обеспечения и SOA в процессе разработки и рассказали о главном предмете данной серии с использованием стека SOA-решения. Далее в учебном руководстве описывается инструмент Rational Software Architect и его новые SOA-функции. Затем, после перечисления моделей, которые использовались на входе деятельности по разработке архитектуры сервиса, были описаны две модели бизнеса для этого проекта: карта компонентного моделирования бизнеса DVD2U и бизнес-процесс Return Video. Это всего лишь начало, во второй части будут подробно описаны другие входные модели и начата работа над первоначальной структурой архитектуры программного обеспечения. Поэтому не забывайте следить за событиями на Web-сайте developerWorks!