Разработка сервисов для информационной системы страховой компании на базе SOA-архитектуры

 

Рисунок 8 - Процесс оформления полиса

 

Рассмотрим отчёт Средняя стоимость роли (рисунок 9, 10).

 

Рисунок 9 - Отчёт: средняя стоимость роли «Агент»

 

Рисунок 10 - Отчёт: средняя стоимость роли «Менеджер»

В год при 8-ми часовом  рабочем дне и 5 дневной рабочей  неделе компания затрачивает на страхового агента 324 800 рублей, на менеджера по работе с агентами на 58% больше. Таким образом стоимость действия «внесения данных о клиенте в БД» требует больших затрат компании, т.к. его выполняет менеджер. Кроме того по данным отчёта было выявлено, что время простоя агента составляет 25 %.

 

1.5.4 Моделирование бизнес-процессов «как должно быть»

 

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

Сценарий данного бизнес-процесса следующий.

 Клиент заходит  на Web-портал страховой компании:

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

Заказ поступает в  систему работы с заявками на страхование:

• так как большинство договоров являются типовыми, они утверждаются автоматически и отправляются на оформление и доставку

Если требуется пересмотр  и согласование данных, то эта заявка направляется менеджеру, так же в  случае необходимости менеджер перезванивает  клиенту

Расчёт стоимости полиса также осуществляется приложением

Если полис утверждён, то данные заносятся в базу

Доставка полиса клиенту

На рисунке 11 представлена модель  бизнес-процесса «как должно быть».

Рисунок 11 - Модель процесса «Как должно быть»

1.5.5 Анализ модели «как должно быть». Сравнение результатов

 

Была проведена имитация данного процесса и получены следующие  результаты (таблица 6):

 

Таблица 6 - Сравнение результатов имитаций

	Процесс «как есть»	Процесс «как должно быть»
Длительность процесса	47 минут	5 минут 15 минут 25 минут
Стоимость процесса	206, 25 рублей	50 рублей
Время простоя агента/менеджера	120 минут (25%)	30 минут (на 40 заявок в день) (6,25%)

 

В случае модели прямого страхования расходы страховой компании существенно снижаются на операциях продажи и регистрации проданного полиса. Время обработки заявки на получение полиса существенно снижается до 5-25 минут. А клиенту в этом случае предоставляется более низкий тариф. Ключевым показателем эффективности (КПЭ) для данного процесса был выбран параметр длительности процесса. Из таблицы видно, что даже при самом длительном процессе во втором случае КПЭ составляет 25, что в два раза ниже, чем в модели «как есть» (в данном случае показатель необходимо было снизить).

 

1.6  Разработка UML-модели системы

1.6.1 Трансформация модели бизнес процессов в UML-модель

 

Полученная модель бизнес-анализа  из WebSphere Business Modeler преобразуется в UML-представление на основе ролевой трактовки бизнес-процесса. При этом бизнес-процесс рассматривается как взаимодействие необходимых для выполнения задач ролей и сервисов, вовлеченных в процесс. Каждую роль можно рассматривать как UML-интерфейс, определяющий операции для задач и сервисов, за которые эта роль отвечает[16].

UML-модель показывает связь между ролями и процессами на высоком уровне абстракции, что удобно для обзора бизнес-процесса. На рисунке 12 показан фрагмент полученной UML-модели бизнес-процессов, полная UML-модель представлена в приложении В.

Рисунок 12 – UML-модель бизнес-процессов

 

Таким образом, на основе модели бизнес-процессов были получены следующие артефакты для UML в разрезе каждого процесса:

• Актеры (BusinessActors);
• Прецеденты (Use Cases);
• Ассоциации (Associations);
• Классы-сущности (BusinessEntity).

На рисунке 13 представлены артефакты для процесса «Заключение договора страхования».

Рисунок 13 - Артефакты  для процесса «Заключение договора страхования»

 

Полученная модель является контрактом для сервиса, который представляет собой представление бизнес-процесса, созданное при открытии модели WebSphere Business Modeler при помощи IBM Rational Software Architect с использованием трансформации бизнес-модели в UML-модель.

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

1.6.2  Модификация полученной в результате трансформации UML-модели

 

Полученное UML-представление элементов (контракт) - это то, что создано представителями бизнеса и что люди, работающие с ИТ должны в дальнейшем проектировать и применять. Он предназначен только для чтения (но не модифицирования) в Rational Software Architect, поскольку сотрудники ИТ подразделений не должны модифицировать контракт, продиктованный бизнесом.

Исходя из этого, был  создан новый проект UML и модель, где использованы некоторые элементы, перешедшие из WebSphere Business Modeler в импорт UML. Это позволило поддерживать трассируемость в соответствии с требованиями, приводящими в действие проект.

На основе полученного  контракта и сущностей <<BusinessEntity>>  были созданы потенциальные классы предметной области, которые представлены на рисунке 14.

 

Рисунок 14 - Потенциальные  классы предметной области

 

Обеспечена связь классов UML-модели с сущностями контракта за счет трассировки, фрагмент трассировки представлен на рисунке 15.

Рисунок 15 - Соответствие классов UML-модели бизнес-сущностям контракта

 

Используя артефакты <<BusinessActor>> и <<BusinessUseCase>> полученного контракта, были построены USE-case диаграммы в разрезе каждого процесса. На рисунке 16 представлена диаграмма вариантов использования, построенная на основе артефактов процесса «Заключение договора страхования».

Рисунок 16 - Диаграмма  вариантов использования процесса «Заключение договора страхования»

 

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

Рисунок 17 - Артефакты  контракта для диаграммы активностей  варианта использования «Заключение дмс – web-сервис»

 

На основе полученных артефактов (диаграмм вариантов использования  и диаграмм активностей) проведена  детализация USE-Case диаграмм, на рисунке 18 изображен фрагмент диаграммы вариантов использования.

Рисунок 18 - Фрагмент диаграммы вариантов использования

 

Данный UML-проект связан с проектом требований, что позволило ассоциировать каждый прецедент с UC требованием, который в свою очередь связан с соответствующими требованиями возможностями (FEAT) за счет трассировки в проекте требований. На рисунке 19 представлена связь прецедентов UML-модели и требований UC.

Рисунок 19 - Связь требований UC и прецедентов UML-модели

 

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

1.7 Разработка сервисной модели

1.7.1 Трансформация в сервисную модель

 

Для дальнейшей идентификации  и моделирования сервисов UML-модель была трансформирована в сервисную модель. Сервисная модель UML с профилем для программирования сервисов  UML 2 Profile for Software Services (UPSS). Данный профиль определяет стереотипы, которые используются для моделирования сервисной архитектуры[17]:

• <<serviceSpecification>>;
• <<serviceCustomer>>;
• << serviceProvider>>;
• <<service>>.

Преимущество использования шаблона профиля сервисов в том, что он обеспечивает заранее встроенную структуру с отдельными пакетами для сообщений, координации совместной деятельности, элементов сервиса и диаграмм. Он также содержит строительные блоки, называющиеся проектировочными элементами многократного использования для каждого из понятий (стереотипов), определяемых профилем, таких, как сервис, провайдер или сообщения. Документация по профилю сервисов и о том, как использовать шаблон, также в него включена.

Цель инструмента трансформации  бизнес-процессов в модель сервисов в Rational Software Architect состоит в создании начальной модели SOA-решения (модели по умолчанию).

UML-модель сервисов, созданная при трансформации, представляет декомпозицию сервисов из модели анализа для каждого бизнес-процесса. На рисунке 20 представлен фрагмент дерева в Project Explorer в IBM RSA полученной сервисной модели.

Рисунок 20 - Фрагмент дерева проекта сервисной модели в IBM RSA

 

Полное дерево проекта  трансформированной сервисной модели представлено в приложении Г.

1.7.2 Идентификация сервисов

 

На основе полученной после трансформации модели сервисов и списка высокоуровневых требований возможностей (FEAT) была произведена идентификация сервисов, в результате чего были выделены следующие сервисы:

• Сервис «Страхователь»;
• Сервис «Клиент»;
• Сервис «Программа страхования»;
• Сервис «Страховой полис»;
• Сервис «Страховой случай»;
• Сервис «Отчетность»;
• Сервис «Медицинское учреждение».

В данной дипломной работе для реализации выбраны следующие  сервисы:

1. Сервис «Клиент»;
2. Сервис «Страховой полис»;
3. Сервис «Страховой случай».

В пунктах 1.7.2.1-1.7.2.3 представлена концепция выделенных сервисов.

1.7.2.1. Сервис «Клиент»

Сервис «Клиент» позволяет  производить действия с сущностью Клиент и рядом связанных сущностей.

Сервис имеет следующие  методы:

1. Добавить клиента.
2. Создать клиента из страхователей.
3. Изменить данные клиента.
4. Удалить клиента.
5. Получить страхователя по клиенту.
6. Данные по клиенту.
7. Найти клиента.
8. Список полисов по клиенту.

1.7.2.2 Сервис «Страховой полис»

Сервис «Страховой полис» позволяет производить действия с сущностью Страховой полис и рядом связанных сущностей.

Сервис имеет следующие  методы:

1. Добавить полис.
2. Изменить данные по полису.
3. Удалить полис.
4. Получить данные по полису (клиента, страхователя, программы страхования и т.д.)
5. Найти полис.

 

 

1.7.2.3. Сервис «Страховой случай»

Сервис «Страховой случай»  работает с сущностью Заявка на обслуживание и рядом связанных сущностей.

Сервис имеет следующие  методы:

1. Добавить заявку на обслуживание.
2. Изменить данные заявки на обслуживание.
3. Удалить заявку на обслуживание.
4. Подтвердить заявку на обслуживание.
5. Поиск заявки на обслуживание по параметрам.
6. Просмотр заявки на обслуживание.

Концепция сервисов добавлена  в проект требований как документ .doc (рисунок 21).

 

Рисунок 21 - Концепция сервисов в  дереве проекта требований

1.7.3  Моделирование сервисов

 

Для моделирования сервисов была создана  UML-модель с профилем для программирования сервисов  UML 2 Profile for Software Services (UPSS). Профилированная модель имеет структуру, которая представлена на рисунке 22.

 

 

Рисунок 22 - Структура проекта модели сервисной модели

 

Сервисная модель содержит три пакета, а именно: Messages (сообщения), Services (сервисы), Service Specifications (спецификации сервисов).  Данные пакеты имеют следующие отношения: пакет Service Specifications требует реализации пакета Messages, пакет Servises требует реализации пакета Service Specifications. Графическое представление отношений на рисунке 23.