Моделирование. Архитектура решения

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

Из базовой архитектуры мы знаем:

• какие компоненты нужно реализовать;
• какие платформы нужно использовать для реализации.

Архитектура решения будет определять:

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

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

6.1 Модель взаимодействий

Основа модели взаимодействий имеет два аспекта:

• шаблон коопераций, который мы выбрали в базовой архитектуре;
• бизнес-процесс.

На основе этих аспектов мы можем изобразить приблизительный поток для решения ( рис. 6.1). Показаны взаимодействия, происходящие из бизнес-процессов Claims Investigation, в сочетании с шаблоном кооперации, показанным на рис. 5.22. Шаблоны коопераций были упрощены и изображены так, чтобы их можно было читать слева направо. Рисунок начинает напоминать UML-схему последовательностей.

увеличить изображение
Рис. 6.1. Поток в решении

6.1.1 Описание взаимодействий

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

Имея эту информацию, мы можем начинать создавать последовательность в Rational Software Architect.

6.1.2 Схема последовательностей

На схеме последовательностей отображается функционирование кооперации. Мы уделяем основное внимание двум моментам: подробному описанию функционирования кооперации RequestExternalReports и интерфейсу, через который она взаимодействует с кооперацией ClaimInvestigation_TOBE.

Архитектору решения нужно создать новую кооперацию для данных функций по ряду причин:

1. Архитектор добавил в кооперацию новый компонент (proxyAssessorSystem).
2. Кооперацию, созданную в WebSphere Business Integration Modeler, нельзя изменить в Rational Software Architect.
3. Мы не собираемся изменять описание бизнес-процесса, согласованного между бизнес-аналитиком и архитектором решения, и включать в него изменения, которые затрагивают только техническую сторону. Если функционирование бизнес-процесса остается тем же, архитектору решения не нужно заново согласовывать контракт с бизнес-аналитиком. Когда архитектор закончит модель PIM, аналитик и архитектор изучат ее и удостоверятся в том, что изменения и расширения, внесенные архитектором, не повлияли на работу модели бизнес-процесса.

Создайте новую кооперацию и перетащите интерфейсы на схему взаимодействий.

1. В Model Explorer выберите пункт ITSO Architect Claim Investigation, щелкните правой кнопкой мыши и выберите пункт меню Add UML (Добавить UML) Collaboration (Кооперация) и назовите ее External Claim Assessor.
2. Щелкните правой кнопкой мыши по кооперации External Claim Assessor и выберите пункт меню Add Diagram (Добавить схему) Sequence Diagram (Схема последовательностей) и назовите схему Sequence Diagram. Измените имя взаимо- действия с Interaction1 на что-нибудь более понятное, например на Assessor Automation Interactions.
3. Заполните схему последовательностей линиями жизни следующих объектов:
   • кооперация ClaimsInvestigation_TOBE из модели WebSphere Business Integration Modeler
   • интерфейсы AssessorAutomation и proxyAssessorSystem, определенные в составе компонентной модели на рис. 5.8.
4. Перетащите элементы Assessor Management, Business Rules Engine, Document Handler и Assessor из модели WebSphere Business Integration Modeler [пакет RootResourceModel Roles (Роли)].
   Совет. Перетаскивайте компоненты на схему в том порядке, в котором вы хотите расположить их на схеме. Порядок должен быть главным образом таким: слева направо в порядке потока итераций. После того как вы поместите линию жизни на схему последовательностей, ее будет трудно переместить. Так что стоит определять нужный порядок с первого раза.
5. После того как вы заполнили схему последовательностей, вы можете вывести на экран визуализацию кооперации, щелкнув правой кнопкой мыши по кооперации External Claim Assessor и выбрав пункт меню Visualize (Визуализация) Show in Browse Diagram (Показать в обзорной схеме).

Рис. 6.2. Кооперация External Claim Assessor

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

• Assessor Automation:
  • ReturnAvailability;
  • ReturnAssessmentConfirmation;
  • ReceiveAssessmentReport;
• proxyAssessorSystem:
  • ProxyReturnAvailability;
  • ProxyAssesmentConfirm.

Для этого было две причины:

• В потоках 6 и 7 мы хотели получить от оценщика помимо отчета об оценке (потоки 8 и 9) подтверждение, что он будет выполнять оценку.
• Существует только одна комбинация потоков (потоки 6, 7, 8 и 9), которую нельзя смоделировать в виде пар вызов/ответ (два ответа подтверждение и посылка данных, получаются в ответ на запрос). Строго говоря, нам в действительности не были бы нужны все эти новые интерфейсы, если бы мы могли полностью положиться на асинхронное промежуточное ПО, такое, как WebSphere MQ, WebSphere MQ Workflow и WebSphere Business Integration Server Foundation. Например, планируется, что выполнение запроса о доступности оценщика займет 2 часа. На уровне бизнеса это очевидное взаимодействие типа запрос/ответ и его можно эффективно реализовать на промежуточном программном обеспечении WebSphere. Однако оказывается, что некоторые транспортные уровни, например http:/SOAP, не являются подходящей реализацией такой схемы, поскольку они должны быть заблокированы на весь срок взаимодействия. Оказывается нерациональным заставлять систему оценщика реализовывать ответ в пределах одной единицы работы.

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

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

увеличить изображение
Рис. 6.3. Схема последовательностей External Claim Assessor: левая сторона

увеличить изображение
Рис. 6.4. Схема последовательностей External Claim Assessor: правая сторона