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

6.3 Контракты архитектора

Архитектор создает два продукта – PIM и PSM (см. рис. 3.7).

PIM

В модели PIM (модель, независимая от платформы) архитектор решения должен совместно с бизнес-аналитиком рассмотреть перечисленные ниже материалы, чтобы удостовериться в том, что реализация будет функционировать в соответствии с моделью бизнес-процесса.

• Общий обзор требований к решению, возможно с использованием шаблона RUP, например документа Vision. Обращайтесь к разделу 5.2, "Шаг 0. Сбор требований".
• Компонентная архитектура ( рис. 5.8).
• Соответствия рабочей системы ( рис. 5.22).
• Функционирование решения, отображаемое на схеме потоков или на схеме последовательности ( рис. 6.1 или рис. 6.3 и 6.4).
• Модель данных, зафиксированную в форме потоков, которыми обмениваются компоненты. Это описывается в разделе messages в WSDL (см. напр. рис. 6.9).

PSM

В модели PSM (модель, специфическая для платформы) архитектор решения распределяет требования по инфраструктуре системы так, чтобы решение работало, и связывает решение с различными технологиями, чтобы ИТ-специалисты могли вести реализацию. Архитектор решения должен предоставить архитектору инфраструктуры и ИТ-специалистам следующие материалы по PSM (в дополнение к PIM):

• связь с продуктами ( рис. 5.23 или рис. 5.24);
• связи WSDL, а также типы портов (PortType) и сообщения ( рис. 6.8). Заполнением определения службы занимается архитектор инфраструктуры;
• соответствия рабочей системы ( рис. 5.22);
• функционирование решения, отображаемое в виде схемы потоков или схемы последовательностей ( рис. 6.1 или рис. 6.3 и 6.4).

Создание компонентов Java Beans (которым мы занимались в разделе "Генерация каркаса EJB для Web-службы") выходит за рамки абсолютно обязательной для архитектора работы над PSM. Это было бы полезно для связывания WSDL-определений интерфейсов и UML-модели, но данной цели можно достигнуть и при помощи комментариев к интерфейсам.

Команда разработки должна решить, будет ли оправданной дополнительная работа архитектора по созданию каркаса EJB. Возможно, она будет оправданна для служб, которые будут создаваться в форме EJB, Java Beans или объектов C++, но будет бесполезной для служб, являющихся оболочками существующих компонентов или созданных с помощью других технологий, например в WebSphere Business Integration Message Broker. Навыки по правильному созданию компонентов больше относятся к компетенции ИТ-специалиста, который будет реализовывать компоненты, а не архитектора.

6.4 Обеспечение доступа к материалам

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

Откройте перспективу Resources (Ресурсы) в Rational Software Architect и выберите проект ITSOLGI Architecture WSDL. Выделите все WSDL-файлы, щелкните правой кнопкой мыши и выберите пункт меню Export (Экспорт) Zip file (zip-файл) Next (Далее). Установите опции Compress (Сжатие) и Create directory structure for files (Создавать структуру директорий для файлов) и убедитесь в том, что отмечены все нужные файлы. Укажите имя создаваемого файла, например ClaimInvestigation WSDL files, и нажмите Finish (Готово) ( рис. 6.23).

Рис. 6.23. Экспортированные WSDL-файлы

6.5 Заключение

В этой лекции архитектор решения занимался детализацией архитектуры системы, созданной в "Моделирование. Архитектура системы" , "Архитектура системы", формируя тем самым функционирование системы. Архитектура решения описывается схемами последовательностей, схемами WSDL-интерфейсов и схемами компонентов.

В WSDL-схемах обеспечивается высокий уровень детализации, от физических транспортных методов и адресов размещаемых компонентов до определения взаимодействий и схем сообщений, используемых при взаимодействиях. Конечно, на данной стадии не обязательно указывать все детали.

Схемы компонентов имеют двоякое применение. Они связывают исходные определения интерфейсов с детализованными спецификациями интерфейсов, применяемыми в реализации, а также (для компонентов, реализуемых как Java Beans или классы С++) их можно использовать для построения и последующей генерации объектов, реализующих модель.

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