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

Оглавление

Введение 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 км, Доход);
    • Прохождение ТО (Идентификатор авто, Регистрационный знак, Дата прохождения ТО, Ответственный за ТО);
    • Рейсы (Идентификатор рейса, Рейс, Дата отправления, Дата прибытия, Номер рейса);
    • Сотрудники (Идентификатор сотрудника, Номер сотрудника, ФИО сотрудника, Дата рождения, Дата приема на работу);
    • Транспорт (Идентификатор авто, Марка авто, Дата выпуска, Цвет, Идентификационный номер, Регистрационный знак);
    • Зарплата (Идентификатор должности, Должность, Оклад);
    • Путевой лист (Идентификатор путевого листа, Дата, Показания спидометра при выезде, Показания спидометра при прибытии).

 

3.1.3 Третья нормальная  форма (3НФ)

Отношение БД находится в третьей  нормальной форме тогда и только тогда, когда отношение находится  во 2НФ и все неключевые атрибуты

взаимно независимы. Атрибуты называются взаимно  независимыми, если ни один из них не является функционально зависимым  от другого. В нашем отношении 3НФ выгляди следующим образом:

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

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

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

Для разработки программного обеспечения  клиентской части автоматизированной системы необходимо использовать различные  компоненты среды программирования Borland Delphi 7. Наиболее важными и необходимыми для рассмотрения являются компоненты InterBase. Палитра компонентов представлена на рисунке 1.

Рисунок 1 - Палитра компонентов  InterBase.

Компонент TIBDatabase.

Компонент TIBDatabase предназначен для  осуществления соединения с базой  данных. Далее представлены его основные свойства:

- DatabaseName - имя сервера и путь  к базе данных (или алиас, если  поддерживается сервером). Например - localhost, server;

- Params - параметры соединения: имя  пользователя, пароль и т.п. 

Если воспользоваться редактором свойств TIBDatabase (двойной клик на компоненте), то упомянутые свойства будут заполнены  автоматически. Например, для базы данных, созданной с default character set win1251 параметры  будут такими:

- user_name=SYSDBA;

- password=masterkey;

- lc_ctype=WIN1251.

TIBTransaction - компонент для явной  работы с транзакциями.

Клиентская часть InterBase допускает  выполнение любых действий только в  контексте транзакции. Поэтому если вы смогли получить доступ к данным без явного вызова IBTransaction.StartTransaction, это значит, что  где-то в недрах IBX этот вызов произошел автоматически. Такое поведение крайне не рекомендуется  использовать. Для корректной работы приложений с базой данных желательно управлять транзакциями вручную, то есть явно вызывать методы StartTransaction, Commit и Rollback компонента TIBTransaction .

Компонент IBQuery.

IBQuery - Набор данных Query представлен в Delphi компонентом Query. Особенностью компонента Query является то, что его записи формируются после выполнения SQL-запроса. В отличие от набора данных Table, компонент Query может содержать записи сразу нескольких таблиц.

Данный компонент удобно использовать при работе с удаленными базами данных.. Если не требуется выполнять "редактирование" записей запроса, то IBQuery можно использовать вместо IBDataSet. Или, как замену IBDataSet можно использовать комбинацию IBQuery + IBUpdateSQL.

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

Были  спроектированы следующие таблицы: Груз, Прохождение ТО, Путевой лист, Рейсы, Сотрудники, Транспорт, Заплата. Они стали основой для БД, весь обмен потоками данных протекает между ними. Для исключения избыточности в некоторые таблицы БД введены поля, являющиеся внешними ключами. Таким образом, получим следующую структуру таблиц:

а) Груз

Название поля

Описание

Тип и длина поля

ID_GRUZA

Первичный ключ

INTEGER

REIS

Рейс

VARCHAR(30)

GRUZ

Груз

VARCHAR(30)

COMPANIA

Компания

VARCHAR(30)

PROBEG

Пробег

NUMERIC(10,2)

PRICE_1KM

Цена за 1 км

NUMERIC(10,2)

DOHOD

Доход

NUMERIC(10,2)


 

б) Прохождение ТО

Название поля

Описание

Тип и длина поля

ID_AVTO

Идентификатор авто (внешний ключ)

INTEGER

REG_ZNAK

Регистрационный знак

VARCHAR(30)

DATE_PROHOGDENIA_TO

Дата прохождения ТО

DATE

OTVETSTVEN_ZA_TO

Ответственный за ТО

VARCHAR(30)


 

 

           в) Путевой лист

 

Название поля

Описание

Тип и длина поля

ID_PUTEV_LIST

Идентификатор путевого листа

INTEGER

ID_SOTRUD

Идентификатор сотрудника (внешний ключ)

INTEGER

ID_AVTO

Идентификатор авто (внешний ключ)

INTEGER

ID_REIS

Идентификатор рейса (внешний ключ)

INTEGER

ID_GRUZA

Идентификатор груза (внешний ключ)

INTEGER

DATE

Дата

TIMESTAMP

POKAZAN_SPID_OUT

Показания спидометра при выезде

NUMERIC(15,2)

POKAZAN_SPID_IN

Показания спидометра при прибытии

NUMERIC(15,2)


 

г) Рейсы

Название поля

Описание

Тип и длина поля

ID_REIS

Первичный ключ

INTEGER

REIS

Рейс

VARCHAR(30)

DATE_OTPRAV

Дата отправления

TIMESTAMP

DATE_PRIBUTIA

Дата прибытия

TIMESTAMP

NOMER REISA

Номер рейса

INTEGER


 

д)Сотрудники

Название поля

Описание

Тип и длина поля

ID_SOTRUD

Первичный ключ

INTEGER

NOMER_SOTRUD

Номер сотрудника

INTEGER

FIO_SOTRUD

ФИО сотрудника

VARCHAR(30)

DATE_ROGDENIA

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

DATE

DATE_PRIEMA_NA_RABOT

Дата приема на работу

DATE


 

е) Транспорт

Название поля

Описание

Тип и длина поля

ID_AVTO

Первичный ключ

INTEGER

MARKA_AVTO

Марка авто

VARCHAR(30)

DATE_VIPUSKA

Дата выпуска

DATE

COLOR

Цвет

VARCHAR(30)

IDEN_NOMER

Идентификационный номер

VARCHAR(30)

REG_ZNAK

Регистрационный знак

VARCHAR(30)


 

            ж) Зарплата

 

Название поля

Описание

Тип и длина поля

ID_DOLGNOSTI

Идентификатор должности

INTEGER

DOLGNOCT

Должность

VARCHAR(30)

OKLAD_RUB

Оклад

NUMERIC(15,2)


 

Для создания этих таблиц использовалось приложение IBExpert -   оболочка, предназначенная для разработки и администрирования баз данных InterBase и Firebird, т.е. реляционная система управления базами данных. В данной работе был использован Firebird.

 

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

Заполненные таблицы, представленные в программе, можно автоматически оформить в отчёт в приложении Microsoft Excel. 

Пример оформления отчета:

 

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

 

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

 

База  данных разработана с использованием сервера Firebird, клиентское приложение разработано в среде Borland Delphi 7. Оно предназначено для создания АРМ диспетчера автотранспортного предприятия. Приложение позволяет работать с записями базы данных, осуществлять. Программа также формирует выходные документы - отчёты.

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

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

База  данных - сетевая, поэтому на рабочем  месте,  использующем данное приложение, должен быть установлен сервер – InterBase. В комплект поставки включается исполняемый файл Project1.exe и собственно файл базы данных.

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

Программа запускается под управлением  операционной системы Windows98\ME\2000\NT4\XP\Vista\7. Для её работы требуется от 4 Мбайт свободной оперативной памяти.

 

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

Программный продукт содержит  исполнительный файл – RIO.exe и следующие модули:

  • Form2 - главная форма приложения;
  • DataModule1- модуль, содержащий компоненты для работы с БД;
  • Unit2 - модуль  добавления, редактирования, удаления записей в таблицах, организация поиска, сортировки и создание отчетов по данным таблиц;
  • Unit3 - модуль сохранения записи при ее добавлении и редактировании в таблице «Груз»;
  • Unit4 - модуль сохранения записи при ее добавлении и редактировании в таблице «Прохождение ТО»;
  • Unit5 - модуль сохранения записи при ее добавлении и редактировании в таблице «Путевой лист»;
  • Unit6 - модуль сохранения записи при ее добавлении и редактировании в таблице «Рейсы»;
  • Unit7 - модуль сохранения записи при ее добавлении и редактировании в таблице «Сотрудники»;
  • Unit8 - модуль сохранения записи при ее добавлении и редактировании в таблице «Транспорт»;
  • Unit9 - модуль сохранения записи при ее добавлении и редактировании в таблице «Зарплата»;
  • Unit10 - модуль, организующий авторизацию БД;
  • Unit11 - модуль, организующий окно «О программе»;
  • Unit12 – модуль, организующий резервное копирование БД.

 

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

Коды процедур и функций программы приведены на примере работы с таблицей «Груз».

1.Добавление записи.

procedure TForm2.Button1Click(Sender: TObject);

var

N:integer;

begin

DataModule1.IBTable1.Last;

N:=DataModule1.IBTable1.FieldByName('ID_GRUZA').AsInteger;

DataModule1.IBTable1.Append;

N:=N+1;

DataModule1.IBTable1.FieldByName('ID_GRUZA').AsInteger:=N;

Form3.show;

end;

 

2.Редактирование записи.

procedure TForm2.Button2Click(Sender: TObject);

begin

DataModule1.IBTable1.Edit;

Form3.show;

end;

3.Удаление записи.

procedure TForm2.Button3Click(Sender: TObject);

АРМ диспетчера автотранспортного предприятия 📙 Курсовая → 🆔 28406

АРМ диспетчера автотранспортного предприятия 📙 Курсовая → 🆔 28406

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