Проектирование информационной системы ООО экскурсионная фирма «Иван Сусанин»

DFD

DFD (Data Flow Diagrams) — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Исторически сложилось так, что  для описания диаграмм DFD используются две нотации — Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), отличающиеся синтаксисом. На приведенной ниже иллюстрации использована нотация Гейна-Сарсона.

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы — структурной компоненты разрабатываемой системы.

 

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, диаграмма Диаграмма вариантов использования [9].

2.3. Разработка TO-BE модели бизнес-процессов ООО экскурсионная фирма «Иван Сусанин»

Для построения модели бизнес-процессов  компании выбрана система BPwin и соответствующий ей структурный подход. Сущность данного подхода заключается в декомпозиции (разбиении) целой системы на процессы, которые в свою очередь разбиваются на функции и функциональные подсистемы. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. В этом заключается преимущество над методом «снизу вверх» (от отдельных задач ко всей системе), где целостность теряется, возникают проблемы при описании информационного взаимодействия отдельных компонентов.

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

Исправление недостатков, перенаправление  информационных и материальных потоков  организации приводит к построению модели TO-BE («как будет»). Это модель идеальной организации бизнес-процессов.

В данной части работы строится модель TO-BE на основе построенной в предыдущей главе AS-IS бизнес-модели.

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

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

Контекстная диаграмма показана на рисунке 2.1.

Затем контекстная диаграмма  декомпозируется на 3 блока IDEF0: «Исследования и маркетинг», «Предоставление  услуг» и «Отгрузка заказов».

 

Рис. 2.1. Контекстная диаграмма «Деятельность экскурсионной фирмы»

 

Стрелками указываются связи  между этими процессами, а также  производится тунелирование стрелок на контекстную диаграмму. Декомпозиция контекстной диаграммы приведена на рисунке 2.1.

Далее произведена  декомпозиция блока «Продажа и маркетинг» и она декомпозируется на 3 блока: «Предоставление информации о ценах» , «Предоставление информации о экскурсиях и принятие заказов» и «Работа по исследованию рынка»

(рис 2.3) .

Рис. 2.2. Декомпозиция контекстной диаграммы ООО экскурсионная фирма «Иван Сусанин»

Для двух последних  из них строятся диаграммы DFD, которые включают в себя: «Проверка и внесение клиента», «Предоставление информации» (рис. 2.4) и «Разработка прогнозов продаж», «Разработка маркетинговых материалов» ,«Разработка прогноза развития» (рис. 2.5).

Рис. 2.3. Декомпозиция диаграммы «Продажа и маркетинг»

Рис. 2.4. Диаграмма DFD декомпозиции «Предоставление информации о экскурсиях и принятие заказов»

 

Рис. 2.5. Диаграмма DFD декомпозиции «Работы по исследованию рынка»

Работа «Предоставление услуг» декомпозирована на 2 работы IDEF0. Соответствующая диаграмма представлена на рисунке 2.6.

Рис. 2.6. «Диаграмма IDEF0 декомпозиции «Предоставление услуг»

Аналогично разработана  декомпозиция «Отгрузка заказов» Она приведена на рисунке 2.7.

Рис. 2.7. «Диаграмма IDEF0 декомпозиции «Отгрузка заказов»

Одна работа данной диаграммы  была декомпозирована по методологии  IDEF3 для подробного описания последовательности выполнения услуг по  оформлению и продаже Декомпозиция этой работы показана на рисунке 2.8.

Рис. 2.8. «Диаграмма IDEF3 декомпозиции работы «Услуги по оформлению и продаже»

Следует отметить использование  перекрестков разных типов. Перекрестки  асинхронное ИЛИ (O) использовались для распараллеливания работ. Перекрёсток типа асинхронное И (&) использовался для того, чтобы все процессы были завершены. Синхронные И и ИЛИ были использованы для одновременного завершения процессов.

Выводы

Во второй главе рассмотрены  основные характеристики CASE-средств: BPwin Process Modeler и Rational Rose. Выбрана система BPwin в результате анализа. Далее рассмотрены основные методологии BPwin. Разработана модель бизнес-процессов фирмы, произведена декомпозиция отдельных процессов. Подробно декомпозированы процессы приема пациентов. Подробная декомпозиция позволит создать модуль ИС, который отвечает за процесс приема пациентов. Аналогичные модули для других процессов так же могут быть созданы в дальнейшем.

 

 

 

 

 

Глава 3. Программная реализация

Программная реализация объекта автоматизации  «Экскурсионная фирма» произведена в курсовой работе по дисциплине базы данных. Спроектирована и программно реализована база данных (БД) для автоматизации части бизнес-процессов модели TO-BE компании. Выявлены группы пользователей, которые связаны с работой фирмы:

1)администрация

2)сотрудники

3)клиенты

Автоматизации должны быть подвергнуты процессы:

1)Подсчет конечной стоимости услуг

2)Добавление  информации администрацией и сотрудниками

3) Изменение необходимой информации

4) Просмотр отчетов

3.1. Инфологическое и даталогическое проектирование БД

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

• Клиенты - сущность содержит информацию о клиентах фирмы;
• Сотрудники – сущность общую информацию о сотрудниках, работающих в данной фирме;
• Экскурсионные объекты – сущность содержит информацию обо всех экскурсионных объектах, на основе которых составляются сами экскурсии ;
• Экскурсии – сущность содержит информацию о уже полностью подготовленных  экскурсиях
• Автобусы – сущность содержит информацию об автобусах, используемых в экскурсиях;
• Документы – сущность содержит информацию о договорах между клиентом и фирмой;

На  основе выделенных сущностей построена  диаграмма инфологической модели, которая  представлена на рисунке 3.1.

 

 

Объект  экскурсии 

Его идентификатор;

Адрес;

Телефон;

Описание;

Экскурсия

    Уникальный номер

     Название:

    Описание;

     Экскурсовод;

       Фельдшер;

Наличие транспорта;

Количество  объектов экскурсии;

Количество  человек;

Дата начала;

Дата Конца;

Стоимость;

 Клиенты  

Номер договора;

ФИО;

Адрес;

Телефон;

Автобусы 

Номер;

Тип;

Пробег;

Дата техосмотра;

Гос номер;

Сотрудники

Номер трудовой Книжки;

ФИО;

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

Опыт работы;

Оклад;

 Документы

Номер договора;

Фио клиента;

Название    экскурсии;

Длительность;

Cтоимость;

 

Рис. 3.1. Инфологическая модель предметной области «Экскурсионная фирма»

 

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

Клиенты                                     Client

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
ФИО клиента		ClientName	VARCHAR(80)	NOT NULL
Адрес		ClientAdress	DATE	NOT NULL
Номер телефона		ClientPhone	INT	NULL
Номер договора клиента		IdClient (PK)	INT

 

Экскурсионные объекты                                    TripObject

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
Адрес		TripObject Adress	VARCHAR(200)	NOT NULL
Номер телефона		TripObjectPhone	INT	NULL
Описание		TripObjectDescribe	VARCHAR(200)	NOT NULL
Уникальный номер экскурсионного  объекта		IdTripObject(PK)	INT	NOT NULL

 

    Экскурсии                                       Trip

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
Номер экскурсии		IdTrip(PK)	INT	NOT NULL
Название		TripName	VARCHAR(70)	NOT NULL
Количество экскурионных объектов		TOSumm	INT	NOT NULL
Количество участников		ClientSumm	INT	NOT NULL
Стоимость на одного человека		TripOnePay	INT	NOT NULL
Общая стоимость		CollectedMoney	INT	NOT NULL

     Сотрудники                       Employees

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
ФИО;		EmployeeName	VARCHAR(70)	NOT NULL
Трудовая книжка;		IdEmployee(PK)	INT	NOT NULL
Дата рождения;		EmployeeBirthDay	DATETIME	NOT NULL
Телефон;		EmployeePhone	VARCHAR(8)	NULL
Должность;		EmployeeFunction	VARCHAR(20)	NOT NULL
Опыт Работы		EmployeeExperiance	INT	NOT NULL
Оклад;		EmployeePay	INT	NOT NULL

     

Автобусы                                  Bus

Имя атрибута	=>	Имя атрибута	Тип данных	Обязательность
Номер автобуса		IdBus(PK)	INT	NOT NULL
Дата техосмотра		BusInspectionDate	INT	NOT NULL
Пробег		BusMileage	VARCHAR(8)	NOT NULL
Тип		BusBrend	INT	NOT NULL
Гос номер		BusStateNumber	VARCHAR(20)	NOT NULL

 

При переходе от инфологической модели к реляционной были раскрыты связи М:М. Между отношениями «Экскурсионный объект» и «Экскурсия», отношением-связкой в данном случае стало отношение «Тип экскурсии ».  Между «Клиенты» и «Экскурсия» появилось отношение «Участники Экскурсии»

После нормализации была разбита таблица Сотрудники и добавлена таблица Диспетчер, для связи водителей с автобусами.

На  основе проделанной работы построена  даталогическая модель (Рис. 3.2).

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

3.2. Физическое проектирование в  СУБД и реализация ПО

Для программной  реализации информационной системы  выбрана СУБД MySQL. Эта СУБД распространяется под GNU General Public License или под собственной коммерческой лицензией.  MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, PureBasic, Python, Ruby, Smalltalk, Компонентный Паскаль и Tcl библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

C# - объектно-ориентированный язык программирования. Разработан в 1998 – 2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как основной язык разработки приложений для платформы Microsoft .NET. Компилятор с C# входит в стандартную установку самой .NET, поэтому программы на нем можно создавать и компилировать даже без инструментальных средств, вроде Visual Studio.