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

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

Мы демонстрируем, как использовать шаблоны для электронного бизнеса (Patterns for e-business), которые проведут нас через этапы выбора базовой архитектуры. На первом этапе, этапе сбора требований, с помощью данной методики мы покажем, как модель процесса, созданную бизнес-аналитиком, можно включить в UML-модель, разрабатываемую ИТ-архитектором в ходе процесса выработки понимания бизнес-требований.

В "Моделирование. Архитектура решения" , "Архитектура решения", рассматривается дизайн решения и разработка архитектуры решения.

5.1 Выбор архитектурных шаблонов

Мы выполним шаги, приведенные на рис. 3.10, чтобы выбрать подходящий архитектурный шаблон для решения по работе с внешними оценщиками. Это весьма длительный процесс. Чтобы помочь вам сориентироваться, мы приводим ниже краткое описание этапов.

• Шаг 0. Сбор требований.

  На этих предварительных этапах архитектор решения собирает требования, которые были зафиксированы на семинарах в сотрудничестве с бизнес-аналитиком. Максимально используя возможности интеграции WebSphere Business Integration Modeler и Rational Software Architect, архитектор решения начинает создавать элементы решения, такие, как прецеденты использования, роли и компоненты, которые будут применяться в архитектурной модели.
• Шаг 1. Выбор шаблона бизнес-интеграции.

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

  На следующем этапе мы рассматриваем выбранные шаблоны бизнес-интеграции (мы в итоге выбрали два) и для каждого выбираем шаблон приложения (application pattern). Для этого мы создаем схему сотрудничества, описывающую существующую систему и, применяя новые компоненты и прецеденты использования, конструируем схему сотрудничества планируемой системы, компоненты которой распределены между двумя выбранными нами интеграционными шаблонами. Поскольку между интеграционными шаблонами есть перекрытие, существует определенная свобода при выборе того, какие компоненты включать в каждый из шаблонов приложения.
• Шаг 3. Выбор и объединение шаблонов рабочей системы.

  В шаблонах для электронного бизнеса есть как сервис-ориентированные, так и типичные шаблоны рабочей системы (runtime patterns) для каждого шаблона приложения. Теперь мы связываем компоненты приложений с компонентами шаблона. Здесь тоже нужно принять ряд решений, определяемых такими факторами, как ИТ-стратегия и имеющиеся ограничения. В итоге мы получаем гибридное решение.
• Шаг 4. Применение связей с продуктами.

  Наконец, мы применяем к шаблону рабочей системы связи с продуктами (product mappings). При этом создается наша базовая архитектура, которую мы фиксируем, создавая схему размещения в Rational Software Architect. Базовая архитектура имеет несколько областей применения:

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

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

5.2 Шаг 0. Сбор требований

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

Хотя мы и не использовали Rational Requisite Pro для регистрации требований и интегрирования их в архитектурную модель в Rational Software Architect, вам все же следует принимать это во внимание. Это особенно полезно, если одной из задач директора по информационным технологиям является отслеживание требований. Инструмент Requisite Pro, если использовать его в сочетании с другими инструментами для управления изменениями, такими, как ClearQuest, дает ответы на следующие вопросы:

• Какие требования в каком решении реализуются?

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

Мы собрали все требования в презентацию, которая была изучена руководителями-кураторами и другими членами команды. В следующих разделах мы даем общий обзор требований и показываем, как архитектор решений может использовать возможности интеграции WebSphere Business Integration Modeler и Rational Software Architect для получения информации, необходимой для разработки базовой архитектуры для проектирования решения.

5.2.1 Бизнес-цели

Полное описание бизнес-целей компании LGI приводится в разделе 1.2, "Бизнес-цели". Ниже дается краткий обзор.

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

5.2.2 Прецеденты использования, связанные с бизнесом

При анализе требований, предъявляемых к процессу обработки претензий, было выявлено несколько прецедентов использования (use case). Мы можем применить Rational Software Architect для автоматической генерации визуального представления прецедентов использования, созданных по модели бизнес-процесса, которая была составлена бизнес-аналитиком при помощи WebSphere Business Integration Modeler.

Иллюстрация приводится на рис. 5.1.

Рис. 5.1. Прецеденты использования, связанные с работой с внешними оценщиками

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

Отображение модели бизнес-процесса в прецедентах использования

Модель бизнес-процесса порождает разнообразные UML2-артефакты. На уровне абстракций каждая задача представлена в виде кооперации (collaboration). В решении для работы с внешними оценщиками есть две задачи, которые мы можем отобразить в виде коопераций в Rational Software Architect ( рис. 5.2 и рис. 5.3):

Рис. 5.2. Кооперация ClaimInvestigation_TOBE

Рис. 5.3. Кооперация RequestExternalReports

Специалист по обработке претензий (Claim Handler) – это единственный ресурс-роль, которую бизнес-аналитик использовал в высокоуровневом процессе ClaimInvestigation_TOBE. Автоматизированных задач здесь не было.

С другой стороны, в процессе RequestExternalReports бизнес-аналитик определил наряду с ручными задачами, выполняемыми ролью Claim Handler, несколько ролей, выполняющих автоматизированные операции. Аналитик рассматривал оценщика (Assessor) как автоматизированную операцию.

Следовательно, в соответствии с этими кооперациями есть только два прецедента использования, в которых задействуются ручные операции: роль Claim Handler, выполняющая процесс ClaimInvestigation_TOBE, и роль Claim Handler, участвующая в выполнении операции RequestExternalReports.