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

 

Рисунок 23 - Отношения между пакетами сервисной модели

 

В пакете Messages cмоделированы сообщения, используемые сервисами. Пример сообщения ClaimRequest (заявка на обслуживание клиента) представлен на рисунке 24.

 

Рисунок 24 - Модель сообщения ClaimRequest

 

 

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

Для разработки спецификации сервиса были созданы стереотипизированные профилем <<ServiceSpecification>>  интерфейсы, а также операции интерфейсах, использующие созданные на предыдущем шаге сообщения. Выделение спецификаций сервиса основывалось на полученных спецификациях после трансформации UML-модели в сервисную модель. На рисунке 25 выделено полученное трансформацией объявление спецификации «Записать на приемProtocol».

 

 

 

Рисунок 25 - Полученная путем трансформации спецификация «Записать на приемProtocol»

 

В рабочем проекте сервисной модели была создана данная спецификация, графическое представление которой изображено на рисунке 26. Спецификация сервиса отражает операции, выполняемые сервисом, а так же входные и выходные параметры.

 

Рисунок 26 - Спецификация «IClaimRecorder» (в трансформированной модели «Записать на приемProtocol»)

 

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

Провайдер сервиса представлен  на рисунке 27.

 

Рисунок 27 - Провайдер сервиса «ApproveClaimProcessing»

1.8 Разработка базы данных

1.8.1 Трансформация UML-модели в логическую модель данных

 

Для разработки модели данных была также использована UML-модель бизнес процессов. В инструменте IBM RSA была проведена трансформация “UML to Logical Data Model” UML-модели в логическую модель данных в перспективе Modelling.

Полученная логическая модель данных обеспечивает представление логических объектов данных бизнес-деятельности без деталей реализации.

В результате трансформации  модель классов была переведена в  объекты модели данных. Отображение  из модели классов (источник) в логическую модель данных (назначение) представлено в таблице 6.   Следует отметить, что[18]:

• класс не имеет первичного ключа, он имеет скрытый OID (идентификатор объекта). Он преобразовывается в свернутый ключ (surrogate key);
• простая ассоциация преобразовывается в не идентифицирующую взаимосвязь, если ассоциация заканчивается кратностью либо 0.1, либо 1; в противном случае она преобразовывается во взаимосвязь "многие ко многим";
• свойство может иметь в качестве типа ссылку на класс, имеющую идентичную агрегации семантику. Следовательно, ссылка на класс преобразовывается в не идентифицирующую взаимосвязь;
• класс ассоциации представляет собой концепцию, которая не существует в логической модели данных. Он преобразовывается в логический объект и две взаимосвязи для сохранения семантики класса ассоциации.

 
Таблица 6 - Отображение модели классов UML в логическую модель данных

Модель классов UML (Источник)	Логическая модель данных (назначение)
Модель/пакет	Пакет
Класс	Логический объект
Свойство	Атрибут
Недоступен (OID)	Свернутый ключ
Обобщение	Обобщение
Композиция	Идентифицирующая взаимосвязь
Агрегация	Не идентифицирующая взаимосвязь
Ассоциация	Не идентифицирующая взаимосвязь  или взаимосвязь «многие ко многим»
Ссылка на класс	Не идентифицирующая взаимосвязь
Класс ассоциации	Один логический объект и две  взаимосвязи
Предопределенный примитивный  тип UML	Предопределенный тип данных
Примитивный тип	Атомарный домен
Перечисление	Атомарный домен

 

На рисунке 28 представлен результат трансформации в UML-модели в логическую модель данных. Полное дерево проекта представлено в Приложении Ж.

 

Рисунок 28 - Результат трансформации UML-модели в логическую модель данных

 

Получены следующие  логические объекты:

• Заявление анкета;
• История болезни;
• Контакты застрахованного;
• Застрахованный;
• Пакет документов для застрахованного;
• Программа страхования по застрахованному;
• Договор об оказании услуг;
• Контактная информация;
• Квитанция;
• Страховой полис;
• Запись о приеме;
• Медицинская карта больного;
• Дата-время записи;
• Заявка на обслуживание;
• Отчет по полисам;
• Отчет по квитанциям;
• Программа страхования.

На рисунке 29 представлен фрагмент логической модели данных, полученной после трансформации.

 

Рисунок 29 – Фрагмент логической модели данных в IBM RDA

 

При сравнении исходной и полученной модели были сделаны следующие выводы:

• свернутый ключ генерируется для каждого логического объекта;
• для обобщения выполняется наследование ключа;
• для композиции выполняется миграция ключа;
• для агрегации выполняется миграция ключа;
• для миграции ключа по умолчанию имя атрибута дочернего внешнего ключа генерируется путем добавления в качестве префикса названия роли предка к имени атрибута родительского первичного ключа.

1.8.2 Получение окончательной логической модели данных

 

В силу того, что дипломный  проект предполагает реализацию трех сервисов (сервис «Клиент», сервис «Страховой полис», сервис «Программа страхования»), окончательная логическая модель данных имеет следующие логические объекты (в скобках указаны наименования объектов логической модели полученной после трансформации):

• Contacts (Контакты застрахованного);
• Persons (Застрахованный);
• StaffCompany;
• Positions;
• Companies;
• Reference;
• Claims (Заявка на обслуживание, Запись о приеме);
• Policy (Страховой полис);
• Programs (Программа страхования);
• ProgOfMed;
• ProgPol (Программа страхования по застрахованному).

Преобразованная логическая модель данных представлена на рисунке 30.

 

Рисунок 30 - Окончательная логическая модель данных

1.8.3 Разработка физической модели данных

 

Путем трансформации (рисунок 31) логическая модель данных была преобразована в физическую модель.

 

Рисунок 31 - Запуск процедуры трансформации логической модели данных в физическую модель

 

Физическая модель предназначена  для СУБД DB2 версии 8.2, данная информация указывается в настройке трансформации (рисунок 32).

 

Рисунок 32 - выбор СУБД, версии СУБД

 

Полученная физическая модель данных представлена на рисунке 33.

 

Рисунок 33 - Физическая модель данных

 

1.8.4 Генерация базы данных на основе физической модели данных

 

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

Полученный sql-скрипт был запущен на сервере баз данных с параметрами подключения, представленных на рисунке 34.

 

Рисунок 34 - параметры подключения к базе данных INSDIPLO

 

Дальнейшее наполнение управление базой данных проводится с использованием инструмента «Центр управления IBM DB2», представление полученной базы данных показано на рисунке 35.

 

 

Рисунок 35 - Представление базы данных в инструменте “Центр управления IBM DB2”

1.9 Реализация сервисов

 

Для реализации сервисов был выбран продукт IBM Data Studio. Это унифицированная инструментальная платформа, содержащая набор функциональных возможностей для разработки, администрирования и управления серверами баз данных. Одной из возможностью данного продукта является способность генерировать основанные на Web-сервисах методы доступа к базе данных.

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

Разработка сервисов проходила с использованием технологии Data Web Services (DWS)[19]. DWS позволяет создавать готовые к развертыванию Web-сервисы, DWS поддерживает интегрированную среду тестирования, позволяющую развернуть и проверить сгенерированные сервисы. DWS автоматически генерирует WSDL-файл (Web Services Description Language) с описанием Web-сервиса.

Исходный код сервисов представлен в приложении  Е, полученные к сервисам WSDL описания представлены в приложении Д.

Тестирование полученных сервисов производилось в среде IBM Data Studio. На рисунке 36 представлен запрос о вводе входного параметра на вход метода GETCLIENTBYTYPE сервиса ClientWS.

 

Рисунок 36 – Ввод входных параметров для методы сервиса

 

Результат выполнения выводится в консоль. На рисунке 37 представлен результат выполнение метода GETCLIENTBYTYPE – были отобраны записи, удовлетворяющие входному параметру «застрахованный».

Рисунок 37 – Результат выполнения метода GETCLIENTBYTYPE сервиса ClientWS

1.10 Выводы

 

В п.п. 1.1 – 1.2 проведено обоснование выбора сервис-ориентированной архитектуры, выбор инструментальных средств разработки и проектирования. СОА архитектура была выбрана в соответствии с проблемами, стоящими перед страховой компанией. Анализ средств проектирования и разработки позволил получить оптимальный набор продуктов для реализации поставленных в дипломной работе задач.

 В п.п. 1.3 описаны методы и стандарты, используемые в ходе дипломного проектирования.

В п.п. 1.4 в соответствии с описанной в п.п. 1.3. моделью требований разработаны требования к реализуемому решению.

В п.п. 1.5 описан процесс моделирование бизнес-процессов для страховой компании. Представлены результаты анализа бизнес-процессов. Предложены новые схемы бизнес-процессов и представлены модели бизнес-процессов «как должно быть». Представлено сравнение результатов выполнения существующих процессов и процессов «как должно быть».

В п.п. 1.6-1.7 представлен процесс получения UML-диаграмм для реализуемых сервисов.

В п.п. 1.8 рассмотрен процесс создания базы данных. Представлены модели данных – логическая модель, физическая модель. На основе физической модели данных сгенерирована схема базы данных для СУБД IBM DB2.

В п.п. 1.9 представлена техника реализации выбранных сервисов. Представлены результаты тестирования сервиса.

 

2 Экономическая часть

2.1 Экономическая эффективность от внедрения сервисов, реализованных на базе  сервис-ориентированной архитектуры.

 

Стратегический эффект может быть оценен при помощи следующих  показателей:

1)Абсолютный показатель снижения годовой трудоемкости обработки информации в результате внедрения системы (∆Т).

2)Абсолютный показатель изменения годовых затрат на обработку информации в результате внедрения прототипа (∆С).

3)Относительные показатели снижения годовой трудоемкости и годовых затрат на обработку информации в результате внедрения системы:

• Коэффициент изменения трудовых затрат (Кт):
• Коэффициент снижения затрат (Кс):

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

• Индекс изменения трудовых затрат (Iт):
• Индекс изменения стоимостных затрат (Iс):

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

4)Расчетный коэффициент эффективности единовременных затрат на разработку и внедрение SOA-решения для основных бизнес-процессов страховой компании (Ер).

5)Срок окупаемости единовременных затрат на разработку и внедрение системы (Ток).

 

 

 

2.1.1 Абсолютный показатель изменения годовой трудоемкости обработки информации в результате внедрения SOA-решения для процесса заключения договора страхования