Моделируем сервис-ориентированную архитектуру при помощи Rational Software Architect: Часть 3. Моделирование внешней системы

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

Требуемый опыт

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

• сервис-ориентированная архитектура (service-oriented architecture, SOA);
• унифицированный язык моделирования Unified Modeling Language (UML);
• IBM Rational Method Composer (ранее IBM Rational Unified Process (RUP).
• IBM Rational Software Architect V7.0 (рекомендуется пакет исправлений fix 002 или более поздняя версия);

Системные требования

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

• Rational Software Architect Version 7 (рекомендуется пакет исправлений FixPak 003) или более поздняя версия.

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

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

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

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

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

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

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

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

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

В части 1 мы представили учебный пример "Прокат видеодисков", который будет использоваться во всех учебных руководствах данной серии. Мы поместили сервисную архитектуру в инфраструктуру Rational Unified Process и для справки рассказали о стеке SOA-решения IBM. Мы упомянули о различных рабочих продуктах, которые были использованы на входе архитектуры сервиса, а затем воспользовались учебным примером для того, чтобы на примере продемонстрировать два таких продукта: модель архитектуры бизнеса (описана в Части 1 как компонентная модель бизнеса) и модель бизнес-процесса.

В части 2 мы разобрали, что такое модель предметной области и как можно представить ее в Rational Software Architect. Мы на практике приступили к работе с этим инструментом и создали модель предметной области, которая используется в данной серии.

В этом выпуске (Часть 3) мы расскажем о том, как можно использовать модель внешней системы при моделировании по принципу "от краев к центру", на отрезке "снизу вверх".

Цели

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

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

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

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

• сервис-ориентированная архитектура (service-oriented architecture, SOA);
• IBM Rational Software Architect V7.0 (рекомендуется пакет исправлений fix 002 или более поздняя версия);
• унифицированный язык моделирования Unified Modeling Language (UML);
• IBM Rational Method Composer (ранее IBM Rational Unified Process (RUP).

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

Позиционирование внешних систем и анализ по принципу "снизу вверх"

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

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

Позиционирование модели внешних систем

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

Рисунок 1. Отображение модели внешних систем на модель проекта

Воспользовавшись рисунком 1 как образцом, мы примем следующие допущения о модели внешней системы:

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

Сервисная модель также является моделью на уровне проекта. Если провести различие между моделью сервиса и моделью проекта, то модель сервиса будет содержать спецификацию проекта на более высоком уровне абстракции и использовать только SOA-элементы (например, поставщик сервиса, сервис, потребитель сервиса, спецификацию сервиса). Впоследствии модель проекта используется как детализированная модель проекта и содержит как SOA, так и не-SOA артефакты.

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

Примечание:
мы используем слово система в значении, определенном в Rational Unified Process (дополнительную информацию см. в разделе Ресурсы): "Система представляет собой набор связанных элементов, организованных для выполнения конкретной задачи." Везде, где мы используем слово система , его можно заменить терминами подсистема, решение, приложение, композитное приложение или бизнес-приложение.

Анализ по принципу "снизу вверх" в SOA или проекте интеграции

В SOA принцип "снизу вверх" используется для анализа существующих IT-ресурсов (например, унаследованных приложений и систем) и поиска функций, которые могут быть представлены как сервисы для многократного использования с различными целями. Например, в ходе анализа по принципу "снизу вверх" анализируются транзакции имеющейся системы управления информацией (Information Management System, IMS) или программ на языке COBOL.

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

Примечание:
IBM предлагает методы, методики и модели сопряжения, особенно для "преобразований из унаследованных систем в SOA." Кроме того, использование имеющихся инструментов анализа ресурсов, таких, как IBM WebSphere Studio Asset Analyzer, является критически важным, потому что часто никто точно не знает, что именно развертывается и выполняется в системе. Но этот вопрос мы в данной статье рассматривать не будем. Здесь мы всего лишь хотим показать, как следует документировать результат анализа по принципу "снизу вверх" при помощи Rational Software Architect.

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

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

• функции, предоставляемые этим ПО;
• все ограничения, налагаемые им на решение.

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

Несколько примеров:

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

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

Моделируем внешние системы и их интерфейсы

Создаем модель внешней системы в Rational Software Architect

Исходной точкой здесь будет служить учебный проект SOA, который мы создали в результате изучения Части 2; этот проект содержит модель предметной области. Загрузите файл (по ссылке из раздела Загрузка), а затем выполните инструкции по импорту проекта в рабочую область.

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

1. Запустите Rational Software Architect. Используйте рабочую область по умолчанию или создайте новую;
2. После запуска Rational Software Architect закройте окно Welcome, если вы находитесь в новой рабочей области;
3. Выберите из меню команды File > Import;
4. В окне мастера импорта введите слово project в поле Select an import source filter, затем выделите Project Interchange и нажмите кнопку Next (рисунок 2);

Рисунок 2. Импорт обменной информации проекта

5. Нажмите кнопку Browse и выберите папку, в которой вы сохранили файл DVD-Rental-DomainModel-RSA-ProjectInterchange.zip;
6. Установите флажок SOA Tutorial и нажмите кнопку Finish (рисунок 3);

Рисунок 3. Импорт учебного проекта SOA

7. Выберите из меню команды Window > Open Perspective > Modeling, чтобы перейти в перспективу Modeling;
8. Разверните категорию SOA Tutorial > Models и двойным щелчком на модели предметной области Domain Model откройте ее. Появится предупреждение о том, что модель, на которую ссылается предметная область, недоступна; нажмите кнопку OK;
9. На рисунке 4 показано представление обозревателя проектов Project Explorer после описанных действий;

Рисунок 4. Первоначальный вид представления Project Explorer

Мы используем секцию нашей модели проекта в качестве модели внешней системы. Следовательно, сначала необходимо создать новую UML-модель для модели проекта.

10. Выделите проект SOA Tutorial. Нажмите на нем правой кнопкой мыши и выберите из меню команды New > UML Model;
11. В диалоговом окне New UML Model сохраните выделение на элементе Standard template и нажмите кнопку Next;
12. Введите в качестве имени файла Design Model и снимите флажок Create a default diagram в модели;
13. Нажмите кнопку Finish;

Теперь в нашем учебном проекте SOA появилась пустая модель проекта.

14. Выделите элемент Design Model, нажмите на нем правой кнопкой мыши и выберите команды Add UML > Package;
15. Назовите пакет External Systems;
16. Удалите элемент Main diagram из этого пакета, для чего нажмите на нем правой кнопкой мыши и выберите команду Delete from Model. В результате мы получаем новую модель, показанную на рисунке 5.

Рисунок 5. Новый пакет внешней системы (в модели проекта)

Идентифицируем внешние системы

Теперь необходимо понять, какие внешние системы станут частью нашего проекта. Моделируя бизнес-процесс Return Video, мы заметили, что автоматизированная задача Retrieve member's standing должна выполняться путем интеграции с имеющейся системой управления взаимоотношениями с потребителями (Customer Relationship Management, CRM). Предположим, что в результате обсуждения ситуации с владельцем бизнес-процесса вы получили некоторую информацию от старшего разработчика, который отвечает за систему CRM, а именно:

• система представляет собой коммерческий пакет, приобретенный несколько лет назад у небольшого производителя CRM-систем;
• программное обеспечение выполняется на платформе .NET, но имеет API для Web-сервисов;
• вместе с ним поставляется документ в формате PDF под названием "Интеграция с API CRM-систем". В нем приводится описание API для Web-сервисов и инструкции по его вызову.

Это хорошая новость, потому что в PDF-документе должно быть достаточно информации для создания модели внешних систем. Однако это еще надо проверить.

1. Создайте в категории External Systems новый пакет для нашей системы управления взаимоотношениями с клиентами. Присвойте ему имя CustomerRelationshipMgt;
2. Нажмите на этом пакете в представлении обозревателя проекта Project Explorer правой кнопкой мыши и выберите команды Add UML > Subsystem. Дайте подсистеме то же имя - CustomerRelationshipMgt . (Прежде, чем переименовывать, убедитесь, что у вас есть стереотип <<subsystem>>);
3. Переименуйте диаграмму по умолчанию, которая была создана для пакета, в CustomerRelationshipMgt ExternalSystemSpec;
4. Убедитесь в том, что открыта именно эта диаграмма и перетащите на нее новую подсистему при помощи мыши.

Результат описанных действий показан на рисунке 6.

Рисунок 6. Внешняя система CustomerRelationshipMgt

Теперь можно приступить к созданию модели внешней системы.

Идентифицируем предоставляемые интерфейсы

Прочитав документ "Интеграция с API CRM-системы", мы узнали, что система имеет несколько API-интерфейсов на базе Web-сервисов, каждый из которых предлагает отличный от других набор функций для CRM. Однако мы нашли особое API, которое называется Customer Functions API и предоставляет доступ к информации CRM, которая нам необходима. Вместо того, чтобы моделировать все предлагаемые API, ограничимся моделированием того API-интерфейса, который нам необходим. Мы создадим интерфейс для этого API на основе информации в документе:

1. Создайте пакет в пакете CustomerRelationshipMgt . Дайте ему имя Provided Interfaces и удалите диаграмму по умолчанию;
2. Создайте еще один пакет в пакете Provided Interfaces. Назовите его CustomerFunctionsAPI. Переименуйте диаграмму по умолчанию в CustomerFunctionsAPI InterfaceSpec;
3. Нажмите правой кнопкой мыши на пакете CustomerFunctionsAPI , а затем выберите из контекстного меню команды Add UML > Interface. Назовите интерфейс CustomerFunctionsAPI;
4. Диаграмма CustomerFunctionsAPI InterfaceSpec должна быть открыта. Перетащите на область диаграммы новый интерфейс при помощи мыши;

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

Рисунок 7. Диаграмма CustomerFunctionsAPI InterfaceSpec

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

5. Откройте диаграмму CustomerRelationshipMgt ExternalSystemSpec;
6. Выделите интерфейс CustomerFunctionsAPI в представлении обозревателя проектов Project Explorer и перетащите его на только что открытую диаграмму;
7. В панели Palette найдите класс Realization в секции Class. Снова выделите его, а затем нажмите левой кнопкой мыши на подсистеме CustomerRelationshipMgt в области диаграммы и перетащите реализацию к элементу CustomerFunctionsAPI, который только что был размещен на диаграмме;

После этого диаграмма должна выглядеть примерно так, как на рисунке 8.

Рисунок 8. Диаграмма CustomerRelationshipMgt ExternalSystemSpec

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

8. Нажмите правой кнопкой мыши на CustomerRelationshipMgt и выберите команды Filters > Show External View;

Внешнее представление показывает предоставляемый интерфейс в нотации, которая обычно называется lollipop (или lollypop) , потому что ее элементы (кружки с чертой) напоминают леденцы (lollipop) на палочке.

9. Чтобы удалить API CustomerFunctionsAPI с диаграммы, нажмите на этом элементе правой кнопкой мыши и выберите команду Delete from diagram;
10. В обозревателе проектов Project Explorer выделите диаграмму CustomerFunctionsAPI InterfaceSpec. Перетащите ее на открытую диаграмму CustomerRelationshipMgt ExternalSystemSpec , чтобы создать ярлык диаграммы;

Совет:
добавление ярлыков облегчает навигацию по модели. Это особенно полезно в том случае, если модели публикуются в формате HTML.

11. Нажмите левой кнопкой мыши на инструменте Note Attachment в панели Palette (см. рисунок 9) и перетащите элемент "примечание" (note) на область между новым ярлыком диаграммы (который мы только что создали) и кружком с чертой, который представляет элемент CustomerFunctionsAPI в подсистеме CustomerRelationshipMgt.

Рисунок 9. Создание элемента "примечание"

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

Рисунок 10. Окончательный вариант диаграммы CustomerRelationshipMgt ExternalSystemSpec
 

Моделируем информацию и интерфейсы внешней системы

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

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

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

Моделируем представление информации

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

Еще раз просмотрев документ "Интеграция с API CRM-системы", мы узнали, что из всех типов информации, хранящейся в системе управления взаимоотношениями с клиентами, значимыми для Customer Function API являются customer и customer category. Мы также заметим описание атрибутов этих двух типов информации и отметим, что один customer относится к одной customer category.

Давайте добавим эту информацию в нашу модель.

1. Создайте в пакете CustomerRelationshipMgt новый пакет. Назовите его Info Types;
2. Удалите диаграмму по умолчанию и создайте новую диаграмму классов. Задайте для нее имя CustomerRelationshipMgt InfoTypes;
3. Создайте следующие элементы модели:

• Инфотип <<infoType>> Customer Class со следующими атрибутами:
  • customerId: String
  • name: String
  • address: String
  • telephoneNumber: String [0..1]
• Инфотип <<infoType>> CustomerCategory с именем String attribute;
• Ассоциацию A * to [0..1] между Customer и CustomerCategory.

Результат описанных действий показан на рисунке 11.

Если вы не совсем понимаете, как это сделать, прочитайте статью "Часть 2. Моделирование предметной области бизнеса" о создании модели предметной области. Обратите внимание, что <<infoType>> - это ключевое слово.

Рисунок 11. Диаграмма CustomerRelationshipMgt InfoTypes

Хотя в этом примере мы не создавали перечислений и ограничений, как и в модели предметной области, в информационной модели они могут иметь место.

В завершение нам нужно добавить в нашу модель ярлык для диаграммы CustomerRelationshipMgt ExternalSystemSpec (см. рисунок 12).

Рисунок 12. Добавление ярлыка диаграммы в информационную модель

Детализируем интерфейсы

То, что мы смоделировали в предыдущих абзацах - это представление информации, хранимой во внешней системе. Кроме того, нам необходимо обновить созданную ранее спецификацию интерфейса. Мы сделаем это путем детализации операций, имеющихся в интерфейсе. Сигнатура операции выражается параметрами и, по желанию, типом возврата. Они основаны на другой модификации типов: типе параметра. Рассмотрим пример.

Еще раз вернувшись к документу "Интеграция с API CRM-системы", мы нашли описание операций, предоставляемых Web-сервисом. Давайте добавим эту информацию в нашу модель.

1. Откройте диаграмму CustomerFunctionsAPI InterfaceSpec;
2. Нажмите правой кнопкой на папке CustomerFunctionsAPI и выберите команды Add UML > Operation. Назовите операцию retrieveCustomer;

Давайте сначала займемся параметрами операции.

3. Выделите операцию retrieveCustomer;
4. В секции Parameters представления Properties нажмите правой кнопкой мыши на пустом списке и выберите команду Insert New Parameter (рисунок 13);

Рисунок 13. Вставка нового параметра - команда Insert New Parameter

5. Измените имя Name на customerId, а для типа (Type ) выберите значение String;

Теперь надо изменить диаграмму, чтобы на ней отображалась эта информация.

6. Нажмите правой кнопкой на элементе CustomerFunctionsAPI в области диаграммы и выберите команды Filters > Show Signature;

Теперь CustomerFunctionsAPI InterfaceSpec должна выглядеть как на рисунке 14.

Рисунок 14. Операция retrieveCustomer с добавленным параметром

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

7. Создайте новый пакет в пакете CustomerRelationshipMgt и назовите его Parameter Types;
8. Переименуйте диаграмму по умолчанию в CustomerRelationshipMgt ParameterTypes;
9. Создайте новый класс с именем Customer и добавьте к нему ключевое слово parameterType;
10. Добавьте атрибуты, показанные на рисунке 15;

Рисунок 15. Новый пакет Parameter Types

11. Откройте диаграмму CustomerFunctionsAPI InterfaceSpec;
12. Перетащите тип параметра Customer на диаграмму;
13. Выделите операцию retrieveCustomer;
14. В секции General представления Properties нажмите Set return type;
15. Задайте тип возврата Customer, тем самым вы гарантируете, что выбираете тип параметра, которым владеет внешняя система.

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

Рисунок 16. Операция retrieveCustomer с заданным типом возврата

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

Что дальше?

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