Страховая компания диаграмма развертывания

компании

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

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

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

Так,
модульная информационная система
ІNSTRAS-4 предназначена для комплексной
автоматизации учета в страховых и
перестраховочных компаниях. Основное
назначение ІNSTRAS-4 – повышение
конкурентоспособности страховой
компании за счет важного улучшения
управляемости. Замыкает все данные и
все бизнес-процессы в страховой компании
в единое информационное пространство,
согласовывая и оптимизируя их. Обеспечивает
комплексную автоматизацию всех ключевых
отделов и служб страховой (перестраховочной)
компании. Представляет собой могущественный
инструмент преобразований и
совершенствования работы компании,
создания и вывода на рынок новых страховых
продуктов. Разрешает организовать
бесперебойный обмен информацией с
филиалами, агентствами и точками продаж.
Включает интерфейс к наиболее популярным
на украинском рынке программам
бухгалтерского учета. Допускает
минимальные расходы на приобретение,
внедрение, поддержку, сопровождение и
развитие.

Для
использования в страховом маркетинге
предлагается еще целый ряд программных
продуктов. Например, Marketіng Expert и БЕСТ
Маркетинг – для стратегического
планирования, Касатка и Маркетинг Микс
– для стратегического и оперативного
планирования. Программа Marketіng Analytіc
предназначена для анализа, прогноза,
планирования и содержит в себе элементы
CRM. Программа Sales Expert обеспечивает
управление прямыми продажами.
Специализированные программные продукты,
предназначенные для решения задач
планирования, имеют и другие встроенные
маркетинговые инструменты, используемые
для SWОТ-анализа и ряда других маркетинговых
операций в процессе обработки данных.
В той или иной мере вышеперечисленные
программные продукты можно применять
с целью прогнозирования и разработки
сценариев развития событий в интересах
решения маркетинговых задач страховой
компании.

Рынок
ІТ-технологий предлагает и другие
информационные решение. Например,
система Contact Manager является универсальным
средством администрирования рабочего
времени и управления системой сбыта.
Она позволяет эффективно контролировать
деловую активность сотрудников системы
продаж на всех уровнях руководства,
отслеживать историю контактов специалистов
агентской сети – от первого телефонного
звонка к заключению договора. Contact
Manager интегрирован с системой операционного
учета договоров. Возможна интеграция
с технологиями саll-центра, бизнес-планирования
и отчетности.

Новая
версия информационной системы UNІCUS EASY
ОСАГО v. 1.6. представляет собой
автоматизированное рабочее место (АРМ)
работника страховой компании и позволяет
выполнять следующие операции:
полнофункциональную продажу полисов
ОСАГО; урегулирование убытков; учет
бланков строгой отчетности; экспорт
данных в формате XML во внешние информационные
базы.

Система
ІCІ (Іnsurance Company Іnformatіon System), которая
выпускается фирмой T-systems, адаптируется
к разнообразнейшим бизнесам-моделям и
может рассматриваться как промежуточный
вариант между индивидуальным и стандартным
программным обеспечениями. В этой
системе комплексной автоматизации,
разработанной специально для страховых
компаний, есть такие современные функции,
как CRM, управление документооборотом,
ведение статистики и другие. Эта система
легко интегрируется с уже имеющимися
в страховой компании бэк-офисными
решениями. Программа Connect Іnsurance,
разработанная австрийской компанией,
работает по принципу “tіme to market” (процесс
от возникновения идеи о новом страховом
продукте до его выхода на рынок) и
модернизации системы продаж страховой
компании без внесения изменений в
существующую ІT архитектуру.

Но
надо помнить, что интегрированные
информационные системы типа Іnsurance
Company
используются, в основном, большими
страховыми компаниями, так как имеют
высокую рыночную стоимость и потому
недоступны для мелких страховых компаний.
Для автоматизации своей деятельности
мелкие страховые компании используют
или системы собственных разработок,
или недорогие системы, которые предлагают
ограниченный набор возможностей.

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

Разработка
информационной системы традиционно
проводится в три этапа: объектно-ориентированный
анализ предметной области; концептуальное,
логическое и физическое моделирование
информационной системы; программная
реализация разработанной модели.

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

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

Проектирование
начинается с формулирования требований
к разрабатываемой системе, определения
функций, которые она должна реализовывать,
и задач, которые она должна решать. На
основе этих данных формируется диаграмма
вариантов использования (рис.125). В нашем
случае диаграмма вариантов использования
(«прецедентов») основывается на
требованиях, функциях, задачах страховой
компании, которые должна выполнять
разрабатываемая система. Согласно
диаграмме, прецедент «Работа с данными»
является основой для прецедентов:
получение данных; введение данных;
модификация данных; просмотр данных;
контроль правильности введенных данных.

Прецедент
«Обработка данных» является основой
для прецедентов: просмотр данных; сверка
данных; формирование отчета; выдача
исходной информации.

Прецедент
«Работа с исходной информацией» является
основой для таких прецедентов: просмотр
данных; обработка исходной информации;
формирование отчетов.

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

Рисунок 125 – Диаграмма
вариантов использования

Анализ
предметной области процесса функционирования
небольшой страховой компании изображен
на рис. 126.

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

Рисунок 126 — Диаграмма ассоциаций
классов

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

Рисунок 127 – Диаграмма детализации
классов

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

Рисунок 128 – Диаграмма
последовательности

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

На
рис. 129 показана диаграмма кооперации
работы страховой компании. Диаграмма
описывает последовательность информации,
которая поступает объекту в виде
сообщения. В нашем случае некоторые
сообщения являются дочерними относительно
других. Они представлены с использованием
десятичной точки для обозначения уровня
вложенности. Так, объект «Оператор
ввода» может передать обработанные
данные объекту «Бухгалтер» только после
того, как получит бухгалтерские данные
от этого же объекта. Так как без
бухгалтерских данных невозможно
сформировать конечные данные. В свою
очередь, конечные данные объект «Группа
конечных пользователей» от объекта
«Оператор ввода» получает только после
передачи исходящих
данных от
объекта «Бухгалтер».

Рисунок 129 –
Диаграмма кооперации

Диаграмма
состояний отображает, как объекты
изменяют свое состояние в ответ на
события, которые происходят. При включении
компьютера происходит загрузка. Поэтому
включение компьютера является
переключающим событием, которое приводит
к переходу интерфейса в состояние
инициализация, а загрузка – действие,
которое происходит во время перехода.
Результатом выполнения действий в
состоянии инициализации есть изготовление
переключающего события, которое вызывает
переход в состояние роботы. При щелчке
по кнопке завершения работы осуществляется
переход в состояние завершения работы,
и в конечном итоге компьютер выключается.
Состояние регистрации нового страхового
полиса в базе является подчиненным.
Система находится в состоянии «Ожидание
ввода данных», пока оператор ввода не
введет соответствующее условие. Дальше
активизируются состояния «Обработка
данных» и «Сохранение данных». Итоговое
состояние – «Визуализация результатов».

Диаграмма
деятельности реально описывает все,
что происходит во время операции или в
процессе. В нашем случае диаграмма видов
деятельности разбивается на «плавательные
дорожки» – параллельные сегменты,
которые отвечают ролям (рис. 130).

Рисунок 130 – Диаграмма деятельности

На
диаграмме компонентов в нашем случае
для работы с данными необходим компонент
«Таблица», а для представления данных
таблицы – интерфейс «Работа с данными».
В свою очередь, работа с данными может
содержать просмотр данных, регистрацию
новых данных, редактирование данных,
формирование отчета по заданному
условию. Выделим следующие интерфейсы:
«Просмотр», «Редактирование», «Выбор»,
«Автоматический подбор» и «Отчет» (рис.
131).

Система
была реализована в среде программирования
Borland
Delphi
и внедрена в отделении страховой компании
[22-25]. Проведенный расчет экономической
эффективности показал, что срок
окупаемости системы составит 0,15 года.

Рисунок 131 – Диаграмма компонентов

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Время на прочтение
8 мин

Количество просмотров 44K

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

Задача архитектора решений ― четко донести проект системы до бизнеса, руководителей проектов и разработчиков. Нельзя просто нарисовать одно изображение, это невозможно и не принесет никому пользы. Вместо этого лучше сгруппировать различные проблемы и создать набор диаграмм, описывающих каждое представление. Конечно, есть миллиард способов сделать это. Как выбрать подходящий? За время работы в качестве архитектора решений я чаще всего использовал 5 диаграмм: контекстную диаграмму C4, диаграмму контейнеров, развертывания, последовательности и вариантов использования. В этой статье я рассмотрю подробно каждую из них.

Контекстная диаграмма

Веб-сайт, посвященный модели С4 (Context, Container, Component and Code), довольно хорошо объясняет свои диаграммы, я же поделюсь своим представлением, как эта модель работает.

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

Пример

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

Как рисовать

• Определите пользователей.

• Определите внешние системы.

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

• Добавьте связи между системой, пользователями и внешними системами.

• Напишите содержательные комментарии по каждому компоненту.

Инструменты

Существуют различные инструменты, которые можно использовать для создания контекстной диаграммы. Существуют трафареты C4 для OmniGraffle, примеры C4 для LucidChart, шаблоны есть также в draw.io. Чтобы использовать диаграммы как код, попробуйте PlantUML.

Допустим, мы хотим нарисовать такую диаграмму для цифровой платформы необанковского обслуживания с помощью uml:

@startuml
!includeurl https://raw.githubusercontent.com/RicardoNiepel/C4-PlantUML/master/C4_Context.puml
' uncomment the following line and comment the first to use locally
' !include C4_Context.puml


Person(customer, "Customer", "A bank client")
System(abc_system, "Digital Platform", "Allows freelancers and business owners see their transactions.")

System_Ext(idnow, "IDNow", "System for KYC and Qualified Eletronic Signatures")
System_Ext(pay, "Google Pay/Apple Pay", "Google Pay and Apple Pay systems")
System_Ext(dms, "DMS", "Document Management System")
System_Ext(crm, "CRM", "CRM")
System_Ext(current, "Existing Banking System", "Banking Backoffice")

Rel(abc_system, pay, "uses")
Rel(customer, abc_system, "Uses")


Rel_L(abc_system, idnow, "integrates")
Rel_Neighbor(abc_system, dms, "uploads files")
Rel_D(abc_system, crm, "integrates")
Rel_U(abc_system, current, "uses")

@enduml

Мы определяем человека, систему, внешние системы и отношения между ними. Предикаты Person, System и System_ext имеют 3 параметра: ключ, заголовок и описание. Предикат Rel также имеет 3 параметра, но они разные: ключ одной сущности, ключ другой и тип отношений между сущностями.

Нарисовать контекстную диаграмму можно любым удобным инструментом. Здесь можно найти несколько отличных примеров.

Важно

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

Я боролся с контекстной диаграммой для одной банковской системы. Она должна была включать только недавно созданную систему и одного клиента, который не принесет никакой ценности. После согласования я добавил API Gateway и существующий Auth Provider, который мы собирались использовать. Таким образом, контекстная диаграмма стала обретать смысл и позволяла опустить эти элементы из диаграмм нижнего уровня.

Алексей, архитектор решений

У нас в разработке была образовательная система. На момент выпуска Alpha мы поняли, что аналитическая система не получает данные от клиентского приложения. Если бы у нас была контекстная диаграмма, мы бы не сделали такой ошибки. К счастью, это было легко исправить.

Джон, архитектор решений.

Резюме

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

Диаграмма контейнеров

Контейнеры здесь не означают обязательно докер-контейнеры. Контейнер — это любой развертываемый объект или хранилище данных с точки зрения C4. Это может быть мобильное приложение, веб-сайт, виртуальная машина, докер-контейнер, база данных или хранилище объектов; все, что вы можете развернуть. По моему опыту эта диаграмма – самая сложная, а потому привлекает к себе особое внимание. Это, можно сказать, главная диаграмма, над которой нужно работать!

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

Пример

Как рисовать      

• Определите список сущностей: микросервисы, хранилища, внешние сервисы.

• Поместите их на диаграмму.

• Добавьте комментарии о назначении каждого компонента и технологии, которую он реализует.

• Добавьте соединения со стрелками.

• Добавьте значимые метки к каждой стрелке.

• Подберите цвет схемы.

• Создайте легенду.

Инструменты

То же, что и для контекстной диаграммы: Draw.io, OmniGraffle, LucidChart и другие.

Важно

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

• Когда количество микросервисов превысит однозначное число, ваши линии соединения начнут пересекаться. В академических книгах говорится, что для удобочитаемости нужно избегать пересечений. К сожалению, это не всегда возможно. Но не расстраивайтесь, диаграмму можно сделать удобочитаемой, используя разные цвета или ширину линий или разные стили линий (пунктирные, сплошные и т. д.).

• Если вы используете специальный инструмент, (как я), вам необходимо включить блок легенды. Сами по себе стрелки и цвет непонятны — легенда объясняет всё это.

• Очень распространенный вопрос, когда используешь облака, включать ли вы управляемые сервисы, такие как очереди сообщений? Я обычно отвечаю: «Нет». Это усложняет диаграмму, делает её нечитабельной. Если некоторые сервисы обмениваются данными через очередь сообщений, отобразите её с помощью стрелки отдельного типа.

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

Илья, архитектор предприятия.

Резюме

Диаграмма контейнера даёт представление о том, из каких развертываемых элементов состоит серверная часть, и как эти компоненты взаимодействуют друг с другом.

Диаграмма последовательностей

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

Пример

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

Как рисовать

• Выберите функцию (вход, покупка и т. д.).

• Определите сущности, участвующие в этом процессе.

• Поместите их на диаграмму.

• Добавьте взаимодействие (стрелки).

• Добавьте ценные комментарии к каждой стрелке.

Инструменты

К сожалению, OmniGraffle не подходит для диаграмм последовательности. Поэтому для создания этой диаграммы я использую draw.io и LucidChart. Последний вариант является хорош тем, что вы можете рисовать диаграмму вручную или использовать диаграмму последовательности UML.

Важно

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

• Диаграмма последовательности также полезна для QA инженеров. Она дает представление о том, где могут быть обнаружены потенциальные проблемы, и служит источником истины для тестовых случаев.

Проект шёл уже несколько месяцев, а некоторые части системы не были готовы к долгожданной функции. Стейкхолдеры были недовольны. Мы обсудили вопрос и договорились проектировать архитектуру до начала разработки. Диаграммы последовательностей очень помогли: мы получили полную картину до написания кода, а не после.

Владимир, Архитектор решений

Резюме

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

Диаграмма развертывания

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

Есть несколько разных вещей, которые необходимо отобразить.

• Вычислительные ресурсы. Это могут быть виртуальные машины, докеры, кластеры Kubernetes и облачные функции. Мобильные устройства и настольные компьютеры также можно рассматривать как вычислительные ресурсы.

• Хранилища. Постоянные хранилища данных, такие как реляционные базы данных и базы данных nosql, хранилища двоичных файлов, таких как изображения, музыка и видео, хранилища больших данных и так далее.

• Ресурсы обмена сообщениями. Установки Kafka / RabbitMQ, Google Cloud pub / sub, AWS SQS и другие.

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

• Зоны доступности. Вы можете думать о них как о центрах обработки данных.

• Узлы инфраструктуры. DNS-серверы, балансировщики нагрузки, брандмауэры, сети CDN

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

Как нарисовать

• Разместите основные блоки: браузеры, мобильные устройства, общедоступное облако, центры обработки данных.

• Разместите вычислительные ресурсы и ресурсы хранения.

• Добавьте узлы инфраструктуры.

• Добавьте сети.

• Добавьте сетевые вызовы между узлами.

• Добавьте ресурсы мониторинга.

Пример

В C4 нотации есть дополнительная диаграмма развертывания:

Обратите внимание на имена вычислительных ресурсов, их типы и номера узлов.

Другой пример для облака AWS:

Инструменты

Существует множество инструментов для создания схемы развертывания. OmniGraffle, LucidChart, Draw.io и другие прекрасно справляются с этой задачей, если установлены соответствующие шаблоны.

Важно

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

Резюме

Диаграмма развертывания дополняет понимание системы с точки зрения внешнего вида.

Диаграмма вариантов использования

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

Как рисовать

• Нарисуйте прямоугольник. Это будет граница системы.

• Определите, кто будет работать с системой.

• Добавьте варианты использования внутри системы с помощью овалов.

• Добавьте связи между участниками и вариантами использования.

Примеры

Инструменты

Архитектор может нарисовать диаграмму с помощью любого графического редактора и того же набора инструментов, что и для других диаграмм. Omnigraffle, LucidChart, Draw.io работают хорошо. Помните, что эта диаграмма является структурированной, поэтому вы можете использовать UML для её создания. В этом помогает PlantUml или LucidChart.

Резюме

• Используйте контекстную диаграмму, чтобы отобразить представление системы на самом высоком уровне.

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

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

• Документируйте конкретные бизнес-кейсы с помощью диаграмм последовательности.

Содержание:

ВВЕДЕНИЕ

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

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

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

ГЛАВА 1 Аналитическая часть

1.1 Описание предметной области. Постановка задачи.

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

Если в период действия договора наступает страховой случай, компания (после проверки обстоятельств) производит выплату клиенту страховой суммы. На этом действие договора прекращается. Если страховые обстоятельства не наступают до окончания срока действия договора, он утрачивает силу. В таком случае компания обычно предупреждает клиента о скором истечении срока действия договора, предлагая ему перезаключить этот договор.

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

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

• расчет суммы взносов и подготовку к печати договора страхования;

• возможность выбора видов страхования из перечня действующих;

• составление перечня действующих договоров;

• формирование отчета по видам страхования;

• составление извещений клиентам об истечении сроков действия договоров в ближайшие две недели;

• подсчет и подготовка к печати отчета по итогам работы страховой компании за заданный период времени.

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

Область применения

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

Таблица 1

Определения, акронимы и сокращения

номер	термин	значение
1	сотрудник	работник предприятия выполняющий определенные действия, имеющий фамилию, имя и отчество
2	удаленные пользователи	инспекторы, агенты страховой компании, проверяющие, т. е. сотрудники, которые по долгу службы проводят рабочий день не в собственном офисе
3	Сценарий	некоторая последовательность действий, иллюстрирующая поведение системы
4	Страховщики	страховые организации, которые вправе осуществлять обязательное страхование гражданской ответственности владельцев транспортных средств в соответствии с разрешением (лицензией)
5	Страхователи	лица, заключившие со страховщиком договор обязательного страхования
6	ОСАГО	обязательное Страхование Автогражданской Ответственности
7	ДСАГО	добровольное страхование автогражданской ответственности
8	Полис ДСАГО	полис добровольного страхования автогражданской ответственности перед третьими лицами
9	страховой случай	наступление гражданской ответственности владельца транспортного средства за причинение вреда жизни, здоровью или имуществу потерпевших при использовании транспортного средства, влекущее за собой в соответствии с договором обязательного страхования обязанность страховщика осуществить страховую выплату
10	страховые тарифы	ценовые ставки, установленные в соответствии с настоящим Федеральным законом, применяемые страховщиками при определении страховой премии по договору обязательного страхования и состоящие из базовых ставок и коэффициентов
11	Класс	Описание набора объектов, обладающих одинаковыми свойствами
12	компенсационные выплаты	платежи, которые осуществляются в соответствии с настоящим Федеральным законом в случаях, если страховая выплата по обязательному страхованию не может быть осуществлена
13	Интерфейс	Набор операций, используемых для определения сервисов, предлагаемых классом или компонентом
14	ИБ	Информационная база организации
15	Сигнал	Асинхронное сообщение, передаваемое между объектами
16	Прецедент	Описание последовательностей действий, осуществляемых системой для предоставления пользователю результата
17	Реализация	Устройство механизма или системы
18	Ограничения	Расширяют семантику элемента, обеспечивая возможность добавлять новые правила
19	Помеченные значения	Обеспечивают возможность определять новые элементы модели UML на основании уже существующих элементов
20	СУБД	Система управления базой данных

Возможности системы

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

• добавление информации о новых клиентах страховой фирмы;

• добавление новых видов страхования уже существующим в информационной базе клиентам;

• формирование данных для оценки статистики случаев ДТП клиентов;

• поиск наиболее подходящих параметров страхования;

• предоставление информации, необходимой для консультации клиентов

Формулировка проблемы

Таблица 2

Для	Сотрудников
Которые	Производят ввод, анализ данных
Является	Инструментом, предоставляющим своевременный ввод новых данных, поиск и анализ текущего состояния клиентов
Который	Значительно упростит работу сотрудников компании и ускорит оказание услуг клиентам

Описание заинтересованных лиц и пользователей

Потенциальные потребители

Сотрудники, клиенты страховой фирмы.

Таблица 3

Заинтересованные лица

Наименование лица	Кого представляет	Роль
Сотрудник	Организацию	Работник фирмы
Пользователь	Физическое лицо	Клиент

Таблица 4

Пользователи

Наименование	Описание
Сотрудник	Работник организации
Клиент	Физическое лицо, являющееся клиентом организации

Пользовательская среда

Распространенная операционная система Windows 7/Vista/XP

Интерфейс в виде таблиц, а так же специальных форм ввода данных.

Таблица 5

Основные потребности заинтересованных лиц/пользователей

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

1.2 Предлагаемые мероприятия по улучшению технологии решения задачи

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

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

Для данного способа также характерны следующие недостатки:

Невысокая скорость и точность выполнения расчетов.

Неэффективное использование рабочего времени.

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

Бюрократия – увеличивающийся «поток» бумажной работы.

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

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

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

Таблица 6

Возможности продукта

Достоинство	Свойство системы
Автоматизация информационных процессов, связанная с обслуживанием клиентов банка.	Централизованное хранение информации о клиентах страховой фирмы и оперативный доступ к ней.
Удобный поиск и ввод новых значений	Возможность внесения изменений в ИБ сразу после заключения договора, изменения данных о клиентах, используя доступ в интернет
Удобство в использовании	Работа с наглядными таблицами и формами ввода данных для поиска необходимого номера

Проектные ограничения

Система должна функционировать в среде наиболее распространенных операционных средств, необходим доступ к сети интернет.

Стоимость проекта

Стоимость проекта не может превышать 1 000 000 рублей

Лицензирование и установка

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

Функциональные возможности продукта

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

Вход в систему

Осуществляется по средствам вызова приложения и регистрации пользователя в системе.

Требования к качеству

Готовность:

Система находится в режиме готовности после ее запуска. Система работает 6 дней в неделю под постоянным наблюдением системного администратора готовым устранить ошибки системы. 7-ой день недели предназначен для профилактики и резервного копирования системы.

Удобство использования:

работа с таблицами и формами ввода.

Сопровождаемость:

сопровождается системным администратором, который следит за работой ИС.

Приоритеты

Отсутствуют

Прочие требования к продукту

Отсутствуют

Используемые стандарты

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

ISO 16071 — эргономика взаимодействия «человек-система». Руководящие указания по доступу к интерфейсам «человек-машина»

ISO 16982 — эргономика взаимодействия человек-система. Методы, основанные на удобстве применения, для обеспечения проектирования, ориентированного на человека

Системные требования

32-разрядный (x86) или 64-разрядный (x64) процессор с тактовой частотой 1 гигагерц (ГГц) или выше;

1024 мегабайт оперативной памяти (ОЗУ);

Интегрированная видеокарта с 256 Мб памяти;

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

Требования к окружающей среде

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

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

Требования к электропитанию:

Системный блок и монитор должны подключаться к сети электропитания через специальные электрические розетки, имеющие заземляющие контакты. Заземляющие контакты розеток должны быть объединены и надежно заземлены.

Электропитание ПК осуществляется от однофазной сети переменного тока напряжением 220 (20 В с частотой 50 — 60 Гц. Для питания ПК необходимо использовать отдельную электролинию, к которой не должно быть подключено сильноточное и коммутационное оборудование. Согласно Правилам устройства электроустановок.

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

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

Требования к документации

Руководство пользователя

Руководство пользователя является отдельным приложением к системе, с полным описанием использования информационной системы страховой фирмы.

Диалоговая помощь

Приложение имеет краткую справку, по работе с системой.

Руководство по установке, конфигурированию

Инструкция по установке и конфигурированию предоставляется вместе с продуктом в виде текстового файла.

Маркировка и упаковка

Маркировка отсутствует, поставляется на информационном носителе.

ГЛАВА 2 Проектная часть

2.1 Выбор средства для моделирования предметной области решаемой задачи

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

Язык UML объединил наиболее известные методы OOA/OOD и очень быстро приобрел широкую популярность среди разработчиков программного обеспечения.

Основными «строительными блоками» UML являются диаграммы, которые условно можно разделить на две категории:

структурные модели, описывающие структуру системы, классы, компоненты, подсистемы и т.д.;

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

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

Моделирование бизнеса с помощью UML предполагает по-следовательное построение двух видов моделей:

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

объектной модели (аналога структурной модели), описывающей внутреннее устройство бизнеса — объекты, участвующие в выполнении бизнес-процессов, их взаимодействие.

Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

– диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);

– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

диаграммы поведения системы (behavior diagrams):

диаграммы взаимодействия (interaction diagrams):

диаграммы последовательности (sequence diagrams) и

кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;

диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей; – диаграммы реализации (implementation diagrams):

диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;

диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

Существует достаточно много CASE-инструментов моделирования и проектирования систем и баз данных (не только с помощью UML). В данном учебном пособии для примера моделирования системы выбран программный инструмент моделирования StarUML [7]. Данная программная платформа имеет свободную лицензию и доступна для установки с официального сайта StarUML [7]. StarUML поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0, а также подход MDA (модельно- настраиваемая архитектура), предлагает настройку параметров пользователя для адаптации среды разработки, поддерживает расширения, предоставляет различного рода модули, расширяющие возможности StarUML.

Инструмент поддерживает возможность добавить плагины к базовой системе. Несмотря на то, что записано на языке Delphi, эти плагины могут быть записаны на любом COM-совместимом языке, таком как C++, Delphi, C# и VB.

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

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

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

Из прочих достоинств можно выделить:

— Генерация кода в языки: C#, Java, С++

-Поддержка работы с фреймворками

-Удобный графический редактор

-Полное соответствие стандарту UML 2.0

— Возможность расширения функционала (про это написано отдельное руководство разработчика)

-Экспорт документации в форматы: DOC, PPT, TXT, XLS…

— Поддержка паттернов

— Импорт проектов Rational Rose

— Приятный размер дистрибутива

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Диаграмма вариантов использования

Рисунок 1 Диаграмма вариантов использования

Действующие лица:

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

Варианты использования:

1. Ввод данных о новом клиенте – вариант использования дает возможность агенту заполнить данные о новом клиенте.
2. Заключение нового договора — вариант использования позволяет агенту заключить новый договор, с уже существующим в БД клиентом.
3. Продление уже существующего договора – вариант использования позволяет страховому агенту продлить страховой договор, то есть оформить аналогичный договор на предстоящий период.
4. Обновление данных — данный вариант использования позволяет агенту отредактировать данные о клиенте и внести изменения в БД.
5. Получение сгруппированной информации – различного вида отчеты и формы, содержащие данные, необходимые для анализа текущего состояния организации.
6. Расчет стоимости полиса – вариант использования позволяет клиенту провести расчет возможной стоимости страховой услуги в данной организации.

Диаграмма последовательности.

Рисунок 2 Диаграмма последовательности

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

На данную диаграмму помещены следующие объекты:

• Страховой агент – действующее лицо;
• «ZapyskProgrammi» — содержит форму авторизации в программе
• «ZapyskGlavnoiFormi» – содержит форму главного меню, необходимого для навигации по системе.
• «OtkritieFormiPoiska» – содержит форму в которую необходимо ввести данные о клиенте, для поиска его в базе данных.
• «OpenFormClient» – основная форма работы с клиентскими данными: отображает личные данные клиента, а так же данные о личном транспорте и оформленные страховки.
• «DataBase» – содержит информацию о клиентах и заключенных договорах.
• «PrintPolis» — процедура, выполняющая печать полиса.

Сообщения между объектами на диаграмме:

• «Authorization» — авторизоваться в программе;
• «Access Denied» — доступ запрещен;
• «Soobshit ob oshibke» — системное сообщение пользователю, о том что авторизация не удалась;
• «OpenMenu» – открыть форму главного меню;
• «OpenSearch» – открыть форму поиска клиента по различным параметрам;
• «SearchBD» – запрос к базе данных на поиск клиента, по указанным параметрам;
• «ReturnSearch» — возврат на форму поиска, в случае если процедура поиска не удалась;
• «Soobshit klient otsytstvyet» — выдача системного сообщения об отсутствии клиента в базе;
• «ReturnMenu» — возврат в меню;
• «OpenClientBD» — открытие клиентской формы, после удчано выполненного запроса;
• «OpenClient» — открытее клиентской формы для внесения в БД нового пользователя;
• «AddNewClientBD» — запись нового клиента в базу;
• «AddEditClientBD» — сохранение в БД измененных данных о клиенте;
• «PrintPolis» — печать сформированного полиса.
• «CloseProgramm» — завершение работы с программой

Кооперативная диаграмма

Рисунок 3 Кооперативная диаграмма.

Иерархия классов системы

Класс (class) — это описание группы объектов с общими свойствами (атрибутами), поведением (операциями), отношениями с другими объектами и семантикой. Таким образом, класс представляет собой шаблон для создания объекта.

• Каждый объект является экземпляром конкретного класса и не может быть экземпляром нескольких классов.

Рисунок 4 Иерархия классов системы.

Рисунок 5 Главная диаграмма классов.

Описание классов

Классы пакета Boundaries.

Рисунок 6 Диаграмма классов пакета Boundaries.

Класс Client содержит следующие атрибуты.

Имя	Описание	Тип
ID	Идентификационный номер клиента	Integer
Fam	Фамилия клиента	String
Im	Имя клиента	String
Otch	Отчество клиента	String
Adress	Место жительства	String
desc	описание	String
NomerDogovora	Знак автора	String
Data zaklucheniya	Дата заключения договора	Date

Операции класса Client

Имя	Описание
OpenClientBD ()	В результате данной операции происходит открытие формы клиента с результатом запроса по поиску конкретного человека, заключившего договор с организацией
Open Client ()	Открытие клиентской формы из меню, для добавления нового клиента

Класс Menu содержит атрибуты.

Имя	Описание	Тип
CloseForm	В данном атрибуте содержится логическое выражение, Отражающее закрытие формы меню	Boolean

Операции класса Menu

Имя	Описание
OpenMenu ()	Открытие формы главного меню, в котором осуществляется работа с системой, производится открытие форм, таких как клиент и поиск
Return Menu ()	Операция возврата в главное меню, после закрытия форм клиент и поиск

Класс Search содержит следующие атрибуты.

Имя	Описание	Тип
Fam	Фамилия клиента	String
Im	Имя клиента	String
Otch	Отчество клиента	String
NomerPolisa	Номер страхового свидетельства	Integer
NomerAvto	Номерной знак транспортного средства	String

Операции класса Search

Имя	Описание
OpenSearch ()	Открытие формы поиска из главного меню
Return Search ()	Операция возврата на форму поиска, обнаружения отсутствия клиента в базе
Soobshit ob ots	Выдача системного сообщения пользователю, об отсутствии клиента в БД

Классы пакета Entities.

Рисунок 7 Диаграмма классов пакета Entities.

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

Операции класса BD

Имя	Описание
AddNewClientBD ()	Отправка запроса на добавление нового клиента организации
AddEditClientBD ()	Отправка запроса на внесение в базу изменений об уже существующем клиенте
SearchBD ()	Формирование результирующей информации и выдача данных о запрашиваемом клиенте на соответствующей форме клиент

Классы пакета Control

Рисунок 8 Диаграмма классов пакета Control

Класс Open содержит следующие атрибуты.

Имя	Описание	Тип
LogIn	Логин пользователя	String
Password	Пароль пользователя	String
Access	Доступ разрешен, либо запрещен	Boolean

Операции класса Open

Имя	Описание	Сигнатура
Authorization	Проверка правильности ввода данных пользователем при входе в систему, операция возвращает значение логического типа.	+ Authorization (): Boolean

Классы пакета View

Рисунок 9 Диаграмма классов пакета View

Класс Print не содержит никаких атрибутов, так как данный класс реализует только печать страхового договора.

Операции класса Open

Имя	Описание	Сигнатура
PrintPolis	Операция реализует печать полиса, данные берутся из БД

Рисунок 10 Диаграмма классов «страховой агент»

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

На диаграмме имеются два специальных состояния — начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние.

Рисунок 11 Диаграмма состояний «страховой агент»

/

ЗАКЛЮЧЕНИЕ

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

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

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

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

В ходе ее разработки мною были изучены основы языка моделирования UML и построены следующие диаграммы:

• диаграмма вариантов использования;
• диаграмма последовательности;
• кооперативная диаграмма;
• диаграмма классов;
• диаграмма состояний;
• диаграмма компонентов;

В качестве среды разработки информационной подсистемы был использован программный продукт Rational Rose Enterprise Edition.

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1. Леоненков А. В., «Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose, М. Интуит.ру, 2006 – 320с.
2. 11. Мартин Фаулер, Кендалл Скотт, «UML. Основы», Символ-Плюс, Санкт-Петербург, 2007 – 192с.
3. 12. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон, «Язык UML. Руководство пользователя», СПб ДМК Пресс, Санкт-Петербург, 2004 – 432с.
4. 13. Вендров А.М., «Проектирование программного обеспечения экономических информационных систем», М. Финансы и статистика, 2006 – 544с.
5. http://bugabooks.com/book/8-avtomatizirovannye-it-v-yekonomike/73-104-avtomatizirovannaya-informacionnaya-sistema-straxovoj-firmy-i-texnologiya-ee-funkcionirovaniya.html, АИС страховой фирмы и технология ее функционирования;
6. Мартин Фаулер, Кендалл Скотт, «UML. Основы», Символ-Плюс, Санкт-Петербург, 2007;
7. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон, «Язык UML. Руководство пользователя», СПб ДМК Пресс, Санкт-Петербург, 2004;
8. Автоматизированные информационные технологии в экономике: Учеб. для вузов / М. И. Семенов, И. Т. Трубилин, В. И. Лойко, Т. П. Барановская; Под ред. И. Т. Трубилина.- М.: Финансы и статистика, 2003.- 414 с.
9. Марка Д., МакГоуэн К. Методология структурного анализа и проектирования SADT (Structured Analysis & Design Technique): Пер. с англ. М.: МетаТехнология, 1993. – 240 с.

УДК 004

РАЗРАБОТКА МОДЕЛЕЙ ОПИСАНИЯ ДЕЯТЕЛЬНОСТИ СТРАХОВОЙ КОМПАНИИ

Новикова Татьяна Борисовна¹, Самойлова Светлана Сергеевна², Вахрушев Владислав Игоревич^3
1Магнитогорский государственный технический университет им. Г.И. Носова, кандидат педагогических наук, доцент кафедры БИиИТ
²Магнитогорский государственный технический университет им. Г.И. Носова, студент группы ФИПИб-13
³Магнитогорский государственный технический университет им. Г.И. Носова, студент группы ФИПИб-13

Аннотация
В данной статье представлено моделирование процессов деятельности страховой компании с использованием различных методологий.

Ключевые слова: моделирование процессов деятельности, модель описания деятельности, страховая компания

---

MODELLING THE DESCRIPTION OF ACTIVITIES OF THE INSURANCE COMPANY

Novikova Tatyana Borisovna¹, Samoilova Svetlana Sergeevna², Vakhrushev Vladislav Igorevich^3
1Nosov Magnitogorsk State Technical University, Ph.D., Associate Professor, Department of business Informatics
²Nosov Magnitogorsk State Technical University, student
³Nosov Magnitogorsk State Technical University, student

Abstract
This article presents a simulation of an insurance company by using different methodologies.

---

Библиографическая ссылка на статью:
Новикова Т.Б., Самойлова С.С., Вахрушев В.И. Разработка моделей описания деятельности страховой компании // Современная техника и технологии. 2016. № 11. Ч. 2 [Электронный ресурс]. URL: https://technology.snauka.ru/2016/11/11435 (дата обращения: 24.02.2023).

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

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

Если вы устанавливаете систему в “облаке”, вы можете вообще пропустить UML и использовать что-то вроде наших шаблонов архитектуры AWS для достижения одной и той же цели.

Что такое диаграмма развертывания

Диаграмма развертывания – это тип UML-диаграммы, которая показывает архитектуру исполнения системы, включая такие узлы, как аппаратные или программные среды исполнения, а также промежуточное программное обеспечение, соединяющее их.

Диаграммы развертывания обычно используются для визуализации физического аппаратного и программного обеспечения системы. Используя его, вы можете понять, как система будет физически развернута на аппаратном обеспечении.

Диаграммы развертывания помогают моделировать аппаратную топологию системы по сравнению с другими типами UML-диаграмм, которые в основном описывают логические компоненты системы.

Обозначения схемы развертывания

Чтобы нарисовать диаграмму развертывания, вам необходимо сначала ознакомиться со следующими обозначениями диаграммы развертывания и элементами диаграммы развертывания.

Узлы

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

Артефакты

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

Коммуникационная ассоциация

Это представлено сплошной линией между двумя узлами. Он показывает путь связи между узлами.

Устройства

Устройство – это узел, который используется для представления физического вычислительного ресурса в системе. Примером устройства является сервер приложений.

Спецификации Развертывания

Спецификации развертывания – это файл конфигурации, например текстовый файл или XML-документ. В нем описывается, как артефакт развертывается на узле.

Как нарисовать диаграмму развертывания

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

Шаг 1: Определите цель вашей схемы развертывания. Для этого необходимо определить узлы и устройства в системе, которые вы будете визуализировать с помощью диаграммы.

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

Шаг 3: Определите, какие другие элементы, такие как компоненты, активные объекты необходимо добавить для завершения диаграммы.

Шаг 4: При необходимости добавляйте зависимости между компонентами и объектами.

Примеры диаграммы развертывания

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

Схема развертывания для системы управления библиотекой

Диаграмма развертывания для системы управления больницей

Диаграмма развертывания для системы управления гостиницей

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

В этом учебном пособии по диаграммам развёртывания мы рассмотрели все, что вам нужно знать – от того, что такое диаграмма развёртывания до элементов диаграммы развёртывания – чтобы нарисовать диаграмму развёртывания самостоятельно. Используйте наш инструмент UML-диаграммы для получения мощных возможностей, которые облегчат отрисовку UML-диаграммы.

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

Простое руководство по схемам компонентов

Простое руководство к деятельности Диаграммы

Легкое руководство к диаграммам классов

Полное руководство по руководствам по диаграммам последовательностей

И не забудьте оставить свои мысли в разделе комментариев ниже.