Разработка архитектуры страхового корпаративного приложения

Каркас состоит из пакетов service, model, controller, view. Их декомпозиция показана на рисунке 1. Классы этих пакетов поясняются далее. Все классы являются открытыми, если не указано иное. По пометкам на языке UML (выделены на рис. 1) можно сделать вывод, что все классы каркаса не являются абстрактными.

Рис. 1. Каркас страхового корпоративного сервиса

Пакет service спроектирован как хранилище различных сервисов по вычислению различных значений полиса и самого полиса. Данный пакет позволяет описать возможные вычислительные сервисы и обработчики событий. Пакет обрабатывает запросы из пакета controller по запросу. Метод handleEvent класса «Рассчитать по- лис» вызывается, чтобы производить вычисления по расчёту стоимости полиса.

Пакет model содержит классы Полис, объект страхования и статус страхования, в которых даётся описание полиса страхования.

Этот пакет содержит классы Полис, объект страхования и статус страхования, в которых даётся описание полиса страхования.

Класс Полис имеет метод setName.

Предусловия – нет; постусловия – нет; инварианты – нет; Псевдокод:

IF не задан параметр aName OR не задан параметр maxNumChrisInName. Установить имя по умолчанию и показать его в системном окне.

Архитектура пакетов, описываемых в этом разделе, приводиться на рисунке 2.

Рис. 2. Схема обработки запроса на расчёт

Пакет controller спроектирован как хранилище различных методов-контроллеров по вычислению различных значений полиса и самого полиса. Данный пакет позволяет описать возможные запросы и обращаться к соответствующим сервисам и обработчикам событий для дальнейшей обработки информации [2]. Метод handleRequest класса «Расчитать полис» вызывается, чтобы передать объект полиса в метод handleEvent соответствующего сервиса и произвести вычисления по расчёту стоимости полиса.

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

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

Для хранения страниц, которые служат для отображения рассчитанной информации по полису и страниц для заполнения информации по полису и дальнейшего расчёта, так же возможность отправлять запросы на соответствующие им контроллеры будет создан пакет View [3].

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

Все классы в данных пакетах являются открытыми, таким образом, интерфейсы складываются из всех методов их классов.

Все события прослушиваются, после нажатия на кнопку «Рассчитать» на контроллер отправляется запрос с объектом полиса на контроллер по адресу «рассчитать полис».

Таким образом в статье был продемонстрирован пример создание архитектуры независимого программного обеспечения способного как к самостоятельной работе, так и к интеграции с более крупными ПО для расширения существующего функционала [4].

Рис. 3. Диаграмма обработки запроса на расчёт

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

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

ширением существующего функционала.