О начале обучения |
Моделирование. Архитектура решения
Комбинация базовой архитектуры и архитектуры решения необходима для того, чтобы ИТ-специалисты могли приступить к реализации решения.
Из базовой архитектуры мы знаем:
- какие компоненты нужно реализовать;
- какие платформы нужно использовать для реализации.
Архитектура решения будет определять:
- интерфейсы, которые нужно реализовать;
- взаимодействия и технологии их реализации;
- качество обслуживания, необходимое для компонентов и взаимодействий.
Создание окончательной архитектурной спецификации – это итеративный процесс. Может оказаться так, что при анализе взаимодействий мы обнаружим, что платформы, выбранные для базовой архитектуры, не поддерживают какие-то параметры качества обслуживания, например необходимую нам производительность или надежность. В таких случаях проектной группе нужно будет найти альтернативные решения, которые могут даже быть связаны с изменением бизнес-процесса.
6.1 Модель взаимодействий
Основа модели взаимодействий имеет два аспекта:
- шаблон коопераций, который мы выбрали в базовой архитектуре;
- бизнес-процесс.
На основе этих аспектов мы можем изобразить приблизительный поток для решения ( рис. 6.1). Показаны взаимодействия, происходящие из бизнес-процессов Claims Investigation, в сочетании с шаблоном кооперации, показанным на рис. 5.22. Шаблоны коопераций были упрощены и изображены так, чтобы их можно было читать слева направо. Рисунок начинает напоминать UML-схему последовательностей.
6.1.1 Описание взаимодействий
Следующая стадия детализации – это более подробное описание взаимодействий с указанием параметров качества обслуживания, в частности являются ли они синхронными или асинхронными, одно- или двусторонними. Все это описано в табл. 6.1. Нам также потребуется словесное описание передаваемого сообщения. Позже нам нужно будет определить интерфейсы компонентов, чтобы можно было точно определить содержимое сообщений в потоках.
Имея эту информацию, мы можем начинать создавать последовательность в Rational Software Architect.
6.1.2 Схема последовательностей
На схеме последовательностей отображается функционирование кооперации. Мы уделяем основное внимание двум моментам: подробному описанию функционирования кооперации RequestExternalReports и интерфейсу, через который она взаимодействует с кооперацией ClaimInvestigation_TOBE.
Архитектору решения нужно создать новую кооперацию для данных функций по ряду причин:
- Архитектор добавил в кооперацию новый компонент (proxyAssessorSystem).
- Кооперацию, созданную в WebSphere Business Integration Modeler, нельзя изменить в Rational Software Architect.
- Мы не собираемся изменять описание бизнес-процесса, согласованного между бизнес-аналитиком и архитектором решения, и включать в него изменения, которые затрагивают только техническую сторону. Если функционирование бизнес-процесса остается тем же, архитектору решения не нужно заново согласовывать контракт с бизнес-аналитиком. Когда архитектор закончит модель PIM, аналитик и архитектор изучат ее и удостоверятся в том, что изменения и расширения, внесенные архитектором, не повлияли на работу модели бизнес-процесса.
Создайте новую кооперацию и перетащите интерфейсы на схему взаимодействий.
- В Model Explorer выберите пункт ITSO Architect Claim Investigation, щелкните правой кнопкой мыши и выберите пункт меню Add UML (Добавить UML) Collaboration (Кооперация) и назовите ее External Claim Assessor.
- Щелкните правой кнопкой мыши по кооперации External Claim Assessor и выберите пункт меню Add Diagram (Добавить схему) Sequence Diagram (Схема последовательностей) и назовите схему Sequence Diagram. Измените имя взаимо- действия с Interaction1 на что-нибудь более понятное, например на Assessor Automation Interactions.
- Заполните схему последовательностей линиями жизни следующих объектов:
- кооперация ClaimsInvestigation_TOBE из модели WebSphere Business Integration Modeler
- интерфейсы AssessorAutomation и proxyAssessorSystem, определенные в составе компонентной модели на рис. 5.8.
- Перетащите элементы Assessor Management, Business Rules Engine, Document Handler
и Assessor из модели WebSphere Business Integration Modeler [пакет RootResourceModel Roles (Роли)].Совет. Перетаскивайте компоненты на схему в том порядке, в котором вы хотите расположить их на схеме. Порядок должен быть главным образом таким: слева направо в порядке потока итераций. После того как вы поместите линию жизни на схему последовательностей, ее будет трудно переместить. Так что стоит определять нужный порядок с первого раза.
- После того как вы заполнили схему последовательностей, вы можете вывести на экран визуализацию кооперации, щелкнув правой кнопкой мыши по кооперации External Claim Assessor и выбрав пункт меню Visualize (Визуализация) Show in Browse Diagram (Показать в обзорной схеме).
Следующий этап – это добавление взаимодействий на схему последовательностей путем добавления на линии жизни синхронных и асинхронных сообщений. Если роли и интерфейсы определены верно, то все операции, необходимые для обозначения взаимодействий будут доступны для выбора. Однако при создании схемы последовательностей часто возникают проблемы в дизайне, и наш дизайн не исключение. В следующие интерфейсы нужно было добавить взаимодействия для обслуживания асинхронных ответов:
- 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). Обратите внимание на использование синхронных и асинхронных потоков.