Структурный подход к проектированию информационных систем (стр. 6 из 7)

3.2.4. Построение DFD-диаграммы

Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота вашей организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0. [5]

Диаграмма DFD показана на рис. 21:

Рис.21. DFD-диаграмма «Беседа с клиентом»

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

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

3.2.5. Построение диаграммы дерева узлов и FEO-диаграммы

Дерево узлов - представление отношений между родительскими и дочерними узлами модели IDEF0 в форме древовидного графа. Диаграмма узлов использует традиционное дерево иерархий, в котором верхний узел (блок) соответствует контекстной диаграмме, а нижний уровень — декомпозицию потомков. [9]

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

Рис. 22 Диаграмма дерева узлов

FEO-диаграмма — это диаграмма-иллюстрация отдельных фрагментов модели и для иллюстрации альтернативной точки зрения, либо для специальных целей, которые не поддерживаются явно синтаксисом IDEFO. FEO-диаграммапозволяетиллюстрировать различные сценарии, показывать различные точки зрения, отображать отдельные детали, которые явно не поддерживаются синтаксисом IDEF0. [4] FEO-диаграмма показана на рис. 23.

Рис. 23. FEO-диаграмма

3.3. Описание модели TO-BE

Итак, в нашей модели отражены все основные процессы для функционирования системы. Однако, существуют недочеты, в частности в процессе проведения консультаций. На поиск нужной клиенту информации сотрудник затрачивает время, может потребоваться повторное обращение. Это не всегда может понравиться клиенту. Поэтому целесообразно введение процесса on-line консультаций, что значительно ускорит процесс (рис.24).

Рис. 24. Модель TOBE

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

ГЛАВА 4.Построение модели данных в Erwin

ERwin - средство разработки структуры базы данных (БД). ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. [5]

4.1. Построение логической и физической модели данных

В Erwinсуществуют 2 уровня моделирования: логический и физический.

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

Рис. 25. Логическая модель данных

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

Таблица 5

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

Для каждой сущности определим набор атрибутов.

Сущность «Клиент» содержит следующие атрибуты: «идентификационный номер клиента» – первичный ключ; «№ автомобиля», «№ договора», «Код сотрудника»– внешние ключи, а так же атрибуты «ФИО», «Дата рождения», «Адрес» и «Паспорт», описывающие личные данные клиента.

Сущность «Договор» содержит следующие атрибуты:

- № договора (первичный ключ);

- № автомобиля;

- Дата страхования

- Сумма страхования.

Сущность «Автотранспорт» содержит информацию о имеющемся автотранспорте клиента и включает следующие атрибуты:

- № авто (первичный ключ);

- Цвет;

- Марка авто;

- Год выпуска.

Сущность «Полис» включает следующий набор атрибутов:

- № полиса (Первичный ключ);

- № договора (Внешний ключ);

- Дата выдачи;

- Срок окончания.

Сущность «Сотрудник» содержит информацию о штате сотрудников и включает следующие атрибуты:

- Код сотрудника (Первичный ключ);

- ФИО;

- Дата рождения;

- Паспорт.

Сущность «Взносы» содержит следующие атрибуты:

- № квитанции (Первичный ключ);

- Дата взноса;

- Сумма;

- № договора (Внешний ключ).

Приведем пояснения к каждой связи между сущностями.

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

Тип связи между таблицами «Автотранспорт» и «Клиент» - один к одному, т.е. каждый клиент имеет по 1 экземпляру автотранспорта для страхования по одному договору.

Тип связи между таблицами «Договор» и «Полис» - один к одному, т.е. по каждому договору клиенту выдается один полис.

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

Тип связи между таблицами «Договор» и «Взносы» - один ко многим, т.к. по каждому договору от клиента поступает несколько взносов.

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

Рис. 26. Физическая модель данных

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

4.2. Прямое и обратное проектирование

Процесс генерации физической схемы базы данных из логической модели данных называется прямым проектированием. Создадим пустую базу данных "Страхование" в СУБД MSAccess. Основным назначением базы данных "Страхование" будет автоматизация функции по учету клиентов и заключения договоров. С помощью встроенных функций Erwin создадим базу «Страхование». База данных «Страхование» будет включать 6 таблиц. (Рисунок 27)

Рис.27. База данных «Страхование»

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

Рис. 28. Схема данных

Процесс генерации логической модели из физической базы данных называется обратным проектированием. Создадим новую логико-физическую модель в Erwin. При помощи меню Tools/ Reverse Engineer From можно задать источник обратного проектирования – базу данных. При помощи кнопки Browse выбираем файл, содержащий базу данных. [5]Результат

обратного проектирования показан на рисунке 29.

Рис. 29. Обратное проектирование

Таким образом, можно сказать, что ERwin является мощным и одновременно простым в использовании средством проектирования баз данных. Кроме того, программа Erwin совместима с большинством используемых в настоящее время СУБД, что является несомненным достоинством программы.

Заключение

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