Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование предметной области «Ведение договоров по страхованию автотранспортных средств» с помощью UML (Описание предметной области)

Содержание:

ВВЕДЕНИЕ

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

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

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

ГЛАВА 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.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 Диаграмма вариантов использования

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

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

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

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

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

Рисунок 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.

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

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