Курсовая работа (т): Разработка информационной системы управления взаимодействия с клиентами на примере работы санатория

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

. Экспорт через .DBF-файлы (реализован в ранних версиях ERwin и BPwin).

. Экспорт и импорт через файлы формата .EAX - .BPX.

. Синхронизация моделей, хранящихся в репозитории ModelMart при помощи утилиты ModelMart Synchronizer.

Ниже будет рассмотрен второй способ связывания моделей. Для экспорта модели данных из ERwin в BPwin необходимо в ERwin открыть модель и выбрать пункт меню File->Export->To AllFusion Process Modeler. В появившемся диалоге необходимо выбрать имя файла *.eax и нажать кнопку Сохранить.


Затем в BPwin нужно открыть модель процесса, выбрать в меню пункт FiIe/Import/Erwin (EAX)..., выбрать имя файла и нажать ОК. Появится протокол импорта. Нажать на кнопку Ассept.


После внесения данных в модель процессов можно связать сущности и атрибуты со стрелками. Правой кнопкой мыши нужно щелкнуть по стрелке и выбрать в контекстном меню Arrow Data.


Так как работы могут воздействовать на данные. Для документирования такого воздействия необходимо щелкнуть правой кнопкой мыши по работе и выбрать пункт меню Data Usage Editor .


В появившемся диалоге Data Usage Editor в виде иерархического списка показываются все работы модели, стрелки, которые касаются работ, сущности и атрибуты, которые были связаны со стрелками.

Для сущностей задается ассоциация CRUD (Create, Read, Update, Delete), для атрибутов - IRUN (Insert, Read, Update, Nullify). Ассоциации CRUD и IRUN - это правила использования сущностей и атрибутов работами, т. e. то, что могут делать работы с входящими или исходящими данными.

2.5 Расчеты и оценки


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

Рассмотрим первую пользовательскую форму «Клиент».

. Количество внешних вводов: 3 (Добавить, Удалить, Отмена) каждый элемент ввода состоит из 4 элементов данных ( id, opening date, closing date, components).

. Количество внешних выводов: 1 (сообщение уведомления об ошибке, если обязательные поля не заполнены);

. Количество внешних запросов: 1

. Внешних интерфейсных файлов: 0.

Таблица 1


Н

С

В

Итого

Внешние вводы

0 * 3 = 0

3 * 3= 9

0 * 4= 0

9

Внешние выводы

1 * 4 = 4

0 * 4 = 0

0 * 5 = 0

4

Внешние запросы

1 * 3 = 0

0 * 3 = 0

0 * 4 = 0

3

Внутренние логические файлы

0 * 7 = 0

0 * 7 = 0

0 * 10 =0

0

Внешние интерфейсные файлы

0 * 5 = 0

0 * 5 = 0

0 * 7 = 0

0

Общее количество FP

16


Рассмотрим вторую пользовательскую форму «Лечение».

. Количество внешних вводов: 3 (Добавить, Удалить, Отмена) каждый элемент ввода состоит из 5 элементов данных ( id,наименование, стоимость лечения, дата ).

. Количество внешних выводов: 1 (сообщение уведомления об ошибке, если обязательные поля не заполнены);

. Количество внешних запросов: 2

. Количество внутренних логических файлов: 1

. Количество внешних интерфейсных файлов: 0

Таблица 2


Н

С

В

Итого

Внешние вводы

0 * 3 = 9

3* 4 = 0

0 * 6 = 0

12

Внешние выводы

1 * 4 = 0

0* 5 = 0

0 * 7= 0

4

Внешние запросы

2 * 3 = 0

0 * 4 = 0

0 * 6 = 0

6

Внутренние логические файлы

1 * 7 = 0

0 * 7 = 0

0 * 10 =0

7

Внешние интерфейсные файлы

0 * 5 = 0

0 * 7 = 0

0 * 10 = 0

0

Общее количество FP


Рассмотрим третью пользовательскую форму «Путевка».

. Количество внешних вводов: 3 (Добавить, Удалить, Отмена) каждый элемент ввода состоит из 7 элементов данных (id, лечение, количество, номер, транспорт, стоимость).

. Количество внешних выводов: 0

. Количество внешних запросов: 3

. Количество внутренних логических файлов: 1 таблицы (Лечение).

. Количество внешних интерфейсных файлов: 0.

Таблица 3


Н

С

В

Итого

Внешние вводы

0 * 3 = 0

3 * 4 = 12

0 * 6 = 0

12

Внешние выводы

0 * 4 = 0

0* 5 = 0

0 * 7 = 0

0

Внешние запросы

3 * 3 = 9

0 * 4 = 0

0 * 6 = 0

9

Внутренние логические файлы

1 * 7 = 7

0 * 10 =0

0 * 15 =0

7

Внешние интерфейсные файлы

0 * 5 = 0

0 * 7 = 0

0 * 10 = 0

0

Общее количество FP

28


Подсчитаем общую функциональную метрику для всего проекта:

FP = 16 +29+ 28 = 73

Полученную общую метрику необходимо субъективным образом взвесить, используя следующую формулу:

= Общее_количество * (0,65+ 0,01 * å14i=1Fi),

где Fi - коэффициенты регулировки сложности.

Определение системных параметров приложения

Каждый коэффициент может принимать следующие значения: 0 - нет влияния, 1 - случайное, 2 - небольшое, 3 - среднее, 4 - важное, 5 - основное.

Таблица 4

№

Системный параметр

Описание

Коэф.

1

Передача данных

Сколько средств связи требуется для передачи или обмена информацией с приложением или системой?

2

2

Распределенная обработка данных

Как обрабатываются распределенные данные и функции обработки?

3

3

Производительность

Нуждается ли пользователь в фиксации времени ответа или производительности?

3

4

Распространенность используемой конфигурации

Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение?

2

5

Скорость транзакций

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

5

Оперативный ввод данных

Какой процент информации надо вводить в режиме онлайн?

5

7

Эффективность работы конечного пользователя

Приложение проектировалось для обеспечения эффективной работы конечного пользователя?

5

8

Оперативное обновление

Как много внутренних файлов обновляется в онлайновой транзакции?

5

9

Сложность обработки

Выполняет ли приложение интенсивную логическую или математическую обработку?

2

10

Повторная используемость

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

5

11

Легкость инсталляции

Насколько трудны преобразование и инсталляция приложения?

2

12

Легкость эксплуатации

Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления?

4

13

Разнообразные условия размещения

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

2

14

Простота изменений

Была ли спроектирована, разработана и поддержана в приложении простота изменений?

4


В результате количество функциональных указателей равно:

FP = 73 * (0.65 + 0.01*(2+3+3+2+5+5+5+5+2+5+2+4+2+4)) = 73*(0.65+0.49) =83.22

Сопоставление с LOC метрикой

Оценив сложность проекта по функционально ориентированным метрикам необходимо связать их с конкретным языком программирования . Для такой оценки используются LOC-метрики (lines of code, LOC).

Полученные FP пересчитываются в LOC использую среднестатистические показатели.

Таблица 5

Язык программирования

Количество LOC на FP

Assembler

320

C

128

Fortran

106

Pascal

90

C++

64

Java

53

Perl

21

HTML3

15

Visual Basic

32

Visual C++

34

Delphi

29


Разрабатываемая информационная система будет писаться на языке Java. Таким образом, воспользовавшись формулой, получаем LOC системы:≈FP*53 = 83.22*53 = 4414 строк кода.

Заключение

В результате работы была разработана информационная система, которая выполняет следующие функции:

регистрация клиентов;

расчет прайс-листа;

статистический анализ;

каждый сотрудник вовремя получает задание на выполнения своего этапа работ;

оперативный доступ сотрудника ко всей необходимой информации.

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

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

Рассчитаны FP-метрики. Система ориентирована на работу с базой данных достаточно большого объема. Использование этой системы облегчит работу сотрудникам фирмы.

Список литераторы

1.      Моругин С.Л. Проектирование информационных систем. Методические указания по выполнению курсового проекта для студентов специальности 230102 (071900) - Нижний Новгород, НГТУ - 2006

.        Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных. "СУБД", 1995, №3.

.        Лекции профессора Моругина С.Л. по курсу “Проектирование информационных систем”

Приложение А

Рисунок 6. Развернутая модель «Оформление путевки»

Рисунок 7. Развернутая модель «Статистический анализ»

Источник: https://www.bibliofond.ru/detail.aspx?id=784245