Информационно-справочная система "Страховая компания"

Размещено на http://www.allbest.ru/

Содержание

Введение

1. Содержательный обзор предметной области

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

2.1 Диаграмма прецедентов модели «Страховая компания»

2.2 Диаграмма деятельности модели «Страховая компания»

2.3 Диаграмма классов модели «Страховая компания»

2.4 Диаграммы последовательности и кооперации модели «Страховая компания»

2.5 Разработка профиля реляционной базы данных «Страховая компания»

3. Реализация модели «Страховая компания»

Заключение

Библиографический список



Введение

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

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

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

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

· к увеличению числа сотрудников страховой компании;

· к увеличению расходов на ведение страхового бизнеса;

· к отсутствию гибкости в управлении страховой компанией;

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

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

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

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

Цель данной курсовой работы: Разработка информационно-справочной системы «Страховая компания».

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



1. Содержательный обзор предметной области

графический моделирование визуализация

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

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.

UML обеспечивает:

· иерархическое описание сложной системы путем выделения пакетов;

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

· детализацию требований к системе путем построения диаграмм деятельностей и сценариев;

· выделение классов данных и построение концептуальной модели данных в виде диаграмм классов;

· выделение классов, описывающих пользовательский интерфейс, и создание схемы навигации экранов;

· описание процессов взаимодействия объектов при выполнении системных функций;

· описание поведения объектов в виде диаграмм деятельностей и состояний;

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

· описание физической архитектуры системы.

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

В данной системе используются следующие сущности:

· Клиент - субъект, использующий услуги компании.

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

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

· Выплаты - осуществление страховой компанией выплаты страхового возмещения

· Вид страхования- страхование конкретных однородных объектов в определённом объёме страховой ответственности по соответствующим тарифным ставкам.

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

С учетом введенных терминов разрабатываемая систем должна обеспечивать:

· организацию полного и достоверного учета всех данных клиента и договора заключенного с ним;

· устранение дублирования при вводе информации и, возникающих при этом механических ошибок;

· удобный интерфейс пользователю;

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



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

UML - это не просто набор графических символов. За каждым из них стоит хорошо определенная семантика (см. "The Unified Modeling Language Reference Manual"). Это значит, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим - или даже инструментальной программой.

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

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

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

В UML различают восемь основных типов диаграмм:

1. Диаграмма прецедентов или вариантов использования (UseCaseDiagram);

2. Диаграмма видов деятельности (Activity Diagram);

3. Диаграмма взаимодействия (Interaction Diagram);

4. Диаграмма классов (Class Diagram);

5. Диаграмма состояний (State Diagram);

6. Диаграмма кооперации (Collaboration Diagram);

7. Диаграмма компонентов (Component Diagram);

8. Диаграмма развертывания (Deployment Diagram).

2.1 Диаграмма прецедентов модели «Страховая компания»

Диаграмма прецедентов (UseCase Diagram) - это диаграмма, описывающая функциональность информационной системы, которая будет видна пользователям системы.

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

UseCase диаграмма используется для:

1. определения общих границ и контекста моделируемой предметной области на начальных этапах проектирования системы;

2. формулировки общих требований к функциональному поведению проектируемой системы;

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

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

Проектируемая система представляется в виде множества сущностей или актёров, взаимодействующих с системой с помощью вариантов использования.

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

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

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

Была разработана диаграмма прецедентов, состоящая из 3 актеров и 10 вариантов использования. Основными действующими лицами являются клиент, страховой агент, база данных. Они выполняют действия: заключить договор, консультироваться, расторжение договора, уведомление об окончание срока полиса, создание нового клиента, поиск по данным клиента, удаление данных о клиенте, поиск по номеру договора, проверка данных: проверка по базе РСА, проверка подлинности документов.

Элементы диаграммы прецедентов (прецеденты и актеры) связаны отношениями (Рис 1.). В данной диаграмме использованы отношения ассоциации и отношения включения.

Рис.1. Диаграмма прецедентов «Страховая компания»

2.2 Диаграмма деятельности модели «Страховая компания»

Диаграмма деятельности (activity diagram) - это, по существу, блок-схема, которая показывает, как поток управления переходит от одной деятельности к другой.

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

Рис. 2. Обслуживание клиента. Диаграмма деятельности.



2.3 Диаграмма классов модели «Страховая компания»

Диаграмма классов (Static Structure diagram) - основная диаграмма для создания кода приложения. При помощи диаграммы классов создается внутренняя структура системы, описывается наследование и взаимное положение классов друг относительно друга. Здесь описывается логическое представление системы. На данной диаграмме не указывается информация о временных аспектах функционирования системы. Диаграмма классов (Рис 3.) представляет собой некоторый граф, вершинами которого являются элементы, которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи.

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

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

Атрибут - это элемент информации, связанный с классом. Из диаграммы видно, например, атрибут класса ID является закрытым, т.е. он не виден никаким другим классам. Остальные атрибуты этого класса - видимые.

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

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

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

Изменение структуры класса T_ADR влечет за собой изменение класса персона через структуру соответствующего атрибута (адрес).

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

Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Интерфейс может представлять поведение класса или компонента полностью или частично; он определяет только спецификации операций (сигнатуры), но никогда - их реализации. Графически интерфейс изображается в виде круга, под которым пишется его имя. Интерфейс редко существует сам по себе - обычно он присоединяется к реализующему его классу или компоненту. Интерфейс всегда предполагает наличие некоторого «контракта» между стороной, которая декларирует выполнение ряда операций и стороной, которая эти операции реализует.

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

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

Рис.3. Диаграмма классов «Страховая компания»



2.4 Диаграммы последовательности и кооперации модели «Страховая компания»

Для диаграммы последовательности (англ. sequence diagram) ключевым моментом является динамика взаимодействия объектов во времени. При этом диаграмма последовательности (Рис 4.) имеет как бы два измерения. Одно представлено слева направо в виде линии жизни (lifeline) (период времени существования) отдельного объекта, участвующего во взаимодействии, а второе - вертикальной временной осью, направленной сверху вниз. Взаимодействие объектов реализуется посредством сообщений, посылаемых одними объектами другим. Сообщения появляются в том порядке, в котором они показаны - сверху вниз.

Рис.4. Ввод данных о клиенте. Диаграмма последовательности.

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

Ниже приведена диаграмма кооперации (Рис 5.)для рассмотренного варианта использования

Рис.5. Ввод данных о клиенте. Диаграмма кооперации.

2.5 Разработка профиля реляционной базы данных «Страховая компания»

На основе диаграммы классов модно создать профиль базы данных. При этом следует иметь ввиду, что объектно-ориентированная модель системы и профиль баз данных далеко не одно и то же. Реляционная модель (Рис 6.) не поддерживает наследования, имеет типы данных, соответствующие используемой СУБД, для обеспечения связей между таблицами используются специальные кодовые поля.

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

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

Рис. 6. Диаграмма профиля БД Страховая компания



3. Реализация модели «Страховая компания»

Access - это реляционная система управления базами данных (СУБД), входящая в пакет MS Office.

Все составляющие базы данных, такие, как таблицы, отчеты, запросы, формы и объекты, в Access хранятся в едином дисковом файле, который имеет расширение .mdb.

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

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

На главной форме «Страховая компания» размещено 12 кнопок:

· Агент

· Выплаты

· Клиент. Юридическое лицо

· Клиент. Физическое лицо

· Договор

· Страховой случай

· Вид страхования

· Должность

Представлена главная форма автоматизированной системы (Рис 7.)

Рисунок 7. Главная форма

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

Рисунок 8. Форма «Агент»



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

Рисунок 9. Форма «Выплаты»

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

Рисунок 10. Форма «Сортировка Агент»

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

Рисунок 11. Форма «Сортировка Договор»

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

Рисунок 12. Форма «Сортировка Выплаты»

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

Рисунок 13. Форма «Страховой случай»

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

Рисунок 14. Форма «Сортировка Страховой случай»



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

Рисунок 15. Форма «Физическое лицо»

В форме «Сортировка Физическое лицо» (Рис 16.) можно осуществлять переход по запросам сортировка таблицы «Физическое лицо» по ФИО, начинающимся с “П”; группировка таблицы «Физическое лицо» по ФИО, виду страхования; группировка таблиц по ФИО клиента, паспортным данным, дате, платежу, виду страхования; переход на главную форму; назад к исходной форме. Это очень удобно и позволяет пользователю этой системы сэкономить время, что повышает производительность.

Рисунок 16. Форма «Сортировка Физическое лицо»

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

Рисунок 17.Форма «Юридическое лицо»

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

Рисунок 18. Форма «Сортировка Юридическое лицо»



Заключение

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

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

В результате выполнения поставленных задач:

· был проведен анализ предметной области;

· рассмотрены базовые этапы разработки модели информационной системы «Страховая компания»: разработку концепции, вида с точки зрения прецедентов, вида с точки зрения проектирования, реляционного профиля баз данных;

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



Библиографический список

1. Кондрашова, С.С. Информационные технологии в управлении: Учебное пособие. - К.: МАУП. 1998. - 138 с;

2. Мифоров, А.А. Информационные технологии в экономике. Учебник: М., 2000.- 300 с;

3. Петров, С.К. Информационные технологии сегодня. Учебное пособие.- М. «ТДК», 2003. - 250 с;

4. Червенчук И.В. Моделирование информационных систем с помощью UML: Учебное пособие по курсу «Информационные системы и процессы, моделирование и управление». - Омск: Изд.-во ОГИС, 2006. - 48с;

5. С.И. Бобровский «Система UML моделирования ModelMart»;

6. Уэнди Боггс, Майкл Боггс «UML и Rational Rose. Упражнения.»;

7. А.М. Вендров «Практикум по проектированию программного обеспечения экономических информационных систем», 2002;

8. А. Леоненков «Самоучитель UML. 2-е издание», 2004;

9. Ручкин К.А."Менеджмент в России и за рубежом"№1.-Донецк, 2007;

Размещено на Allbest.ru

...