Моделирование. Архитектура системы

5.2.4 Компоненты

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

Чтобы создать в модели новые компоненты, выполните следующие шаги:

1. Откройте проект ITSO Architecture и создайте новую схему компонентов Claim Investigation Component Diagram.
2. Перетащите на схему компонентов роли Assessor, Assessor Management, Business Rules Engine и Document Handler.
3. Теперь создайте шесть новых компонентов с именами AssessorManagement, BusinessRulesEngine, AssessorSystem, ClaimsSystem, AssessorAutomation и ClaimsWorkflow. Сделать это можно прямо на схеме, щелкнув правой кнопкой мыши и выбрав пункт меню Add UML (Добавить UML) Component (Компонент).
4. Соедините каждый интерфейс с соответствующим ему компонентом, создав реализующую взаимосвязь. Наведите курсор мыши на компонент и щелкните по маленькой стрелке, указывающей на прямоугольник. Перетащите его на соответствующий интерфейс и отпустите кнопку мыши. Выберите пункт Create New Implementation (Создать новую реализацию). Соедините компоненты AssessorAutomation и ClaimsWorkflow, как показано на рис. 5.7. Мы можем использовать цвета, соответствующие схеме Pattern for e-business, и показать, что компонент Assessor System является частью другой организации.

увеличить изображение
Рис. 5.7. Схема компонентов Claims Investigation

Когда мы выберем шаблоны Patterns for e-business, как будет описано позже в этой лекции, мы обнаружим, что нам нужно добавить в эту схему еще один компонент.

Компонент AssessorSystem не является частью LGI, и для него нужен прокси-компонент, который мы назвали proxyAssessorSystem, который будет выполнять функцию посредника между LGI и оценщиками. Мы снабжаем этот новый компонент другим интерфейсом, отличным от того, который используется компонентом Assessor System. Интерфейсы не могут быть одинаковыми, поэтому это не прокси в общепринятом смысле этого слова. Его нельзя сгенерировать автоматически из реального интерфейса компонента AssessorSystem. Например, задача Request Availability запрашивает информацию о готовности у всех подходящих оценщиков, а каждый оценщик получает отдельный запрос о готовности. И конечно, запросы к оценщикам поступают в разные точки назначения с применением разных транспортных протоколов.

Мы добавляем на схемы компонент proxyAssessorSystem и другую детальную информацию из готовой архитектуры. И все же компонентная архитектура не завершена, пока мы не установим связи для рабочей системы, используя шаблоны для электронного бизнеса, как это описано в разделе 5.5, "Шаг 3. Выбор и объединение шаблонов рабочей системы".

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

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

Для завершения компонентной модели мы выполнили следующие шаги:

1. Были добавлены выполняемые вручную ролью Claim handler задачи, которые бы- ли разделены между системами процесса Claims Workflow и Automated Assessor.
2. В компоненты были добавлены предоставляемые и необходимые интерфейсы. Готовая схема компонентной модели показана на рис. 5.8.

увеличить изображение
Рис. 5.8. Готовая схема компонентов для ClaimInvestigation_TOBE

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

Существующие компоненты

Существующие компоненты при создании нового решения должны изменяться как можно меньше.

LGI Assessor Management System (Система управления оценщиками LGI)

Эта система предоставляет информацию о каждом оценщике и о способах взаимодействия оценщиков с LGI.

Данная система включает следующие операции:

• Identify Assessor (Идентификация оценщика).

  По типу и почтовому коду области нахождения автомобиля, подлежащего оценке, операция Identify Assessor формирует список потенциальных оценщиков с контактной информацией.
• Load/Register Assessor^{2Эти операции не были включены в данный сценарий.} (Загрузка/регистрация данных об оценщике).
• Ranking Assessor^{3Эти операции не были включены в данный сценарий.} (Ранжирование оценщиков).
• Record Selected Assessor^{4Эти операции не были включены в данный сценарий.} (Запись выбранного оценщика).

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

Claims Workflow (Рабочий поток претензий)

Это существующий, выполняемый вручную процесс. Интересующей нас подзадачей является процесс изучения претензии. Специалист по обработке претензий (Claim handler) выбирает претензию, с которой он будет работать, получает внешние отчеты и завершает работу, устанавливая для претензии статус "готовность к принятию решения". Процесс изучения претензии содержит следующие операции:

• Select Report^{5Эти операции не были включены в данный сценарий.} (Выбор отчета).

  Специалист по обработке претензий выбирает претензию из своего списка.
• RequestExternalReports (Запрос внешних отчетов).

  Теперь это автоматизированный процесс, который вызывает автоматизированный подпроцесс работы с внешними оценщиками и возвращает отчет оценщиков.
• Update External Reports^{6Эти операции не были включены в данный сценарий.} (Обновление внешних отчетов).

  Специалист по обработке претензий может получать другие внешние отчеты.
• SetClaimStatus^{7Эти операции не были включены в данный сценарий.} (Установка статуса претензии).

В заключение для претензии устанавливается статус "готовность к принятию решения".

Document Management System (Система управления документами)

Система управления документами хранит все отчеты, сгенерированные в процессе работы с претензиями и полисами. Нас интересует только одна операция – Store the assessment report (Сохранение отчета об оценке).

Новые и измененные компоненты

Из существующих компонентов WebSphere MQSeries и Web Services Gateway создается корпоративная сервисная шина (enterprise service bus), обеспечивающая на основе служб передачу данных к компонентам решения.

Новым компонентом является система бизнес-правил (Business Rules Engine, BRE). Мы не акцентируем внимание на способах использования BRE и применяемых в ней технологиях. Целью этого компонента является повышение удобства для пользователя через совершенствование взаимодействия с внешним оценщиком.

Enterprise Service Bus (Корпоративная сервисная шина)

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

• ProxyRequestAvailability.

  Данная операция, имея доступ к списку оценщиков и к данным об оценщиках, посылает каждому оценщику запрос о том, готов ли он к выполнению оценки. Запрос должен посылаться при помощи метода, согласованного с оценщиком (e-mail, EDI, Web-служба, страница браузера и т. п.).
• ProxyRequestAssessment.

  Данная операция, имея доступ к данным о выбранном оценщике и к данным о претензии, посылает запрос об оценке претензии и сохраняет данные о под- тверждении запроса.
• ProxyAssessorSendReport.

  Получает от оценщика отчет и сохраняет его.

Business Rules Engine (Система работы с бизнес-правилами)

Это новый компонент, позволяющий настраивать процесс оценки в зависимости от задач бизнеса. К нему относятся следующие операции:

• выбор времени оценки на основе типа полиса, имеющегося у клиента;
• применение бизнес-правил для выбора оценщика из списка оценщиков.

5.2.5 Организационные и архитектурные ограничения

За полным описанием целей и ограничений, связанных с ИТ, обращайтесь к разделу 1.3, "Цели и ограничения, связанные с ИТ". Ниже приводится краткое описание.

• ИТ-политики:
  • Использование открытых стандартов;
  • Поддержка используемых каналов;
  • Создание общей инфраструктуры для LGI и DirectCar;
  • Повторное использование существующих приложений;
  • Установка новой инфраструктуры LGI.
• Ограничения, связанные с корпоративной инфраструктурой. Новые приложения должны использовать корпоративную LDAP-директорию для определений ролей и назначения их персоналу
• Возможность выполнять оценку вручную при работе с особыми случаями
• Поддержка разных систем, используемых оценщиками, включая доступ через браузер, электронную почту, EDI и Web-службы, работающие через HTTP и JMS.

5.2.6 Границы решения

Существует ряд аспектов решения, которые мы опустили из-за недостатка времени.

• Моделирование данных.

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

  В нашем решении мы опустили все аспекты, связанные с обеспечением безопасности.
• Директория.

  Мы не реализовывали в масштабе решения директорию для работы с персоналом.
• Пользовательский интерфейс.

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

WebSphere Business Integration Server Foundation не использует общие рабочие списки, и, если не проведена дополнительная работа, специалисту по обработке претензий приходится применять два окна для работы с двумя рабочими списками. Кроме того, специалист должен обеспечивать соответствие этих списков.

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

• Мы не реализовывали мониторинг бизнес-событий для отслеживания обработки претензии.
• Мы не реализовывали никаких функций системного управления для размещения и мониторинга.

Мы ограничили виды соединений с внешними оценщиками только протоколом SOAP/Http:. На практике продукты, используемые в качестве шлюза ESB, должны обрабатывать как минимум доступ через EDI, электронную почту и браузер.