АРМ диспетчера автотранспортного предприятия

Оглавление

Введение 6

1 Анализ технического задания 8

1.1 Общие положения 8

1.2  Требования к составу выполняемых функций 8

1.3 Требования к надежности системы 10

1.4 Исходные данные 10

2 Выбор и обоснование архитектуры системы 11

3 Выбор и обоснование алгоритма программы 13

3.1 Нормальные формы отношений 13

3.2 Выбор и обоснование компонентов 15

3.3 Создание таблиц базы данных 16

3.4 Оформление отчетов 19

4 Описание программы 20

4.1 Общее описание 20

4.2  Инструкция по установке 20

4.2.1 Комплект поставки 20

4.2.2 Минимальные требования 20

4.3 Состав программного продукта 20

4. 4  Описание процедур и функций программы 21

5 Описание пользовательского интерфейса 28

6 Описание средств защиты данных и программ 33

7 Описание тестового примера и отчетной документации, протокол тестирования программ 35

7.1 Отчетная документация 35

7.2 Описание тестового примера 35

7.3 Протокол тестирования программ 35

Заключение 39

Список используемой литературы 40

Приложение А (обязательное) 41

 

 

Введение

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

• обеспечивать получение общих и/или детализированных отчетов по итогам работы;

• позволять легко определять тенденции изменения важнейших показателей;

• обеспечивать получение информации, критической по времени, без существенных задержек;

• выполнять точный и полный анализ данных.

Современные СУБД в основном являются приложениями Windows, так как  данная среда позволяет более  полно использовать возможности  персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход  к среде Windows, где разработчик  программного обеспечения может  в меньше степени заботиться о  распределении ресурсов, но также  сделал программное обеспечение  ПК в целом и СУБД в частности  менее критичными к аппаратным ресурсам ЭВМ.

Среди наиболее ярких представителей систем управления базами данных можно  отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual Foro, Microsoft Visual Basic, а также  баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой  современной СУБД существует аналог, выпускаемый другой компанией, имеющий  аналогичную область применения и возможности, любое приложение способно работать со многими форматами  представления данных, осуществлять экспорт и импорт данных благодаря  наличию большого числа конвертеров. Общепринятыми, также, являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще – диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Поэтому уже не имеет существенного значения на каком языке и на основе какого пакета написано конкретное приложение, и какой формат данных в нем используется. Более того, стандартом стала «быстрая разработка приложений» или RAD (от английского Rapid Application Development), основанная на широко декларируемом в литературе «открытом подходе», то есть необходимость и возможность использования различных прикладных программ и технологий для разработки более гибких и мощных систем обработки данных. Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

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

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

1 Анализ технического задания

1.1 Общие  положения

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

На основе анализа предметной области необходимо разработать структуру базы данных, определить структуру базовых таблиц. База данных должна быть разработана в IBExpert, также необходимо разработать локальную базу данных.

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

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

 

1.2  Требования к составу выполняемых  функций

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

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

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

• Ввод данных;
• Редактирование данных;
• Удаление записей;
• Поиск записей;
• Осуществление определенных запросов по заданным наборам данных;

АРМ диспетчера автотранспортного  предприятия.

Данные программы  предназначены для: автоматизации расчетов, ведения протоколов работы диспетчеров, подготовки отчетов, формирование актов выполненных работ, ведомостей по автотранспорту для каждого из заказчиков, ведение разнарядки и возможностью печати результатов на бланках разнарядки, ведение табеля, редактируемый список ответственных лиц, при расчетах стоимости использование коэффициентов пробега и коэффициентов выходного дня, формирование итоговых отчетов, и многое другое... Обработка неограниченного количества путевых листов за любой период. Возможность экспорта отчетов в формат Microsoft Excel, что делает эту функцию незаменимой в случае необходимости корректировки отчетов. Работа программы в сетевом варианте дает возможность одновременно многим пользователям вносить, просматривать и редактировать данные. Благодаря использованию клиент-серверной архитектуры Firebird программа будет так же уверенно работать на "старых" компьютерах (Pentium II) как и на современных, т.к. основная нагрузка по обработке данных ложится на сервер, при этом нагрузка на сеть при этом минимальна.

 

 

 

 

 

 

 

 

 

1.3 Требования  к надежности системы

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

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

• защита данных от несанкционированного доступа с помощью  идентификации пользователей (имя пользователя и пароль )
• резервное копирование данных;

 

1.4 Исходные  данные

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

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

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

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

 

2 Выбор и обоснование архитектуры  системы

В данном курсовом проекте необходимо разработать сетевую базу данных, основанную на архитектуре Клиент-Сервер.

Архитектура Клиент-Сервер имеет ряд особенностей. Она разделяет функции приложения пользователя (клиента) и сервера. Приложение – клиент формирует запрос к серверу, на котором расположена база данных на языке SQL. Для создания таблиц была использована программа IBExpert.

В разрабатываемой  системе диспетчерской автотранспортного  предприятия анализ проводится на основании предоставленной предприятием всей необходимой информации. Эта система должна:

- быть  максимально объективной;

- безошибочно  решать поставленные задачи;

- выдавать информацию о всех данных, хранящихся в БД.

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

База данных разрабатываемой системы будет состоять из следующих отношений:

• Груз (Идентификатор груза, Рейс, Груз, Компания, Пробег, Цена за 1 км, Доход);
• Прохождение ТО (Идентификатор авто, Регистрационный знак, Дата прохождения ТО, Ответственный за ТО);
• Рейсы (Идентификатор рейса, Рейс, Дата отправления, Дата прибытия, Номер рейса);
• Сотрудники (Идентификатор сотрудника, Номер сотрудника, ФИО сотрудника, Дата рождения, Дата приема на работу);
• Транспорт (Идентификатор авто, Марка авто, Дата выпуска, Цвет, Идентификационный номер, Регистрационный знак);
• Зарплата (Идентификатор должности, Должность, Оклад);
• Путевой лист (Идентификатор путевого листа, Идентификатор сотрудника, Идентификатор авто, Идентификатор рейса, Идентификатор Груза, Дата, Показания спидометра при выезде, Показания спидометра при прибытии).

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

 

3 Выбор и обоснование алгоритма  программы

3.1 Нормальные  формы отношений

3.1.1 Первая нормальная форма  (1НФ)

На начальном  этапе проектирования базы данных строится первая нормальная форма – это обычное отношение БД со свойствами:

• В отношении нет одинаковых кортежей.
• Кортежи не упорядочены.
• Атрибуты не упорядочены и различаются по наименованию.
• Все значения атрибутов атомарны.

В ходе моделирования  на первом шаге в этом отношении БД имеются следующие атрибуты: Идентификатор путевого листа, Дата, Показания спидометра при выезде, Показания спидометра при прибытии, Идентификатор должности, Должность, Оклад, Идентификатор авто, Марка авто, Дата выпуска, Цвет, Идентификационный номер, Регистрационный знак, Идентификатор сотрудника, Номер сотрудника, ФИО сотрудника, Дата рождения, Дата приема на работу, Идентификатор рейса, Рейс, Дата отправления, Дата прибытия, Номер рейса, Идентификатор авто, Регистрационный знак, Дата прохождения ТО, Ответственный за ТО, Идентификатор груза, Рейс, Груз, Компания, Пробег, Цена за 1 км, Доход.

 

3.1.2 Вторая нормальная  форма (2НФ)

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

• Груз (Идентификатор груза, Рейс, Груз, Компания, Пробег, Цена за 1 км, Доход);
• Прохождение ТО (Идентификатор авто, Регистрационный знак, Дата прохождения ТО, Ответственный за ТО);
• Рейсы (Идентификатор рейса, Рейс, Дата отправления, Дата прибытия, Номер рейса);
• Сотрудники (Идентификатор сотрудника, Номер сотрудника, ФИО сотрудника, Дата рождения, Дата приема на работу);
• Транспорт (Идентификатор авто, Марка авто, Дата выпуска, Цвет, Идентификационный номер, Регистрационный знак);
• Зарплата (Идентификатор должности, Должность, Оклад);
• Путевой лист (Идентификатор путевого листа, Дата, Показания спидометра при выезде, Показания спидометра при прибытии).