Разработка базы данных диспетчерского пункта транспортной компании диплом

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

Содержание

Введение

1. Аналитическая часть

1.1 Описание структуры и функционирования предприятия

1.2 Разработка программного продукта

1.3 UML-диаграммы предприятия

1.3.1 Работа офиса

1.3.2 Работа автопарка

1.3.3 Работа склада

1.4 Модель «сущность-связь» БД предприятия

2. Декомпозиция БД предприятия на локальные базы данных

2.1 Модель «сущность-связь» главной БД

2.2 Модель «сущность-связь» БД автопарка

2.3 Модель «сущность-связь» БД склада

3. Реляционная модель БД

3.1 Реляционная модель главной БД

3.2 Реляционная модель БД автопарка

3.3 Реляционная модель БД склада

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

4.1 Вход в программу

4.2 Модуль «Автопарк»

4.3 Модуль «Офис»

4.4 Модуль «Склад»

4.5 Модуль администрирования

4.6 Тестирование программы

4.7 Руководство администратора

Глава 5. Организационно-экономическая часть

5.1 Экономическое обоснование разработки программы

5.2 Расчет трудоемкости и цены разработки

5.3 Определение цены программной продукции

Выводы по главе

6. Информационная безопасность проекта

6.1 Основные понятия и определения оценки объекта

6.2 Профиль защиты

6.3 Описание объекта оценки

6.4 Среда безопасности ОО

6.5 Цели безопасности

6.6 Требования безопасности

6.7 Обоснования

Заключение

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

Приложение А

Введение

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

Целью данной разработки является автоматизация
функционирования автопарка и временного склада товаров, учета заявок клиентов,
заполнения путевых листов. Разработан программный продукт «ИС
Автотранспорт», включающие все основные функции и алгоритмы, необходимые при
составлении данной задачи. При разработке были учтены возможности аналогичных
продуктов «СИОД-ИНФАВТО», «АРМ персонала автотранспортного
предприятия».

Система разработана на языке Object Pascal с применением
интегрированной среды разработки (IDE) Delphi 7 Enterprise, СУБД Firebird
2.0.4, и открытых компонентов IBUpdateSQLW, Ehlib 3.4 Данные средства просты в
освоении и позволяют эффективно разрабатывать любые приложения, в частности,
палитра компонент (VCL) Delphi 7 предоставляет готовые средства для решения
почти всех задач, с которыми можно столкнуться при реализации
автоматизированного рабочего места строителя. Проект «ИС
Автотранспорт» разработан по технологии «клиент-сервер», это
сетевая архитектура, в которой существует 2 типа узлов — запрашивающие узлы
(клиенты) и отвечающие узлы (сервера). Отличительной особенностью такого
механизма является централизованная обработка и хранение данных на сервере,
тогда как клиенты реализуют лишь интерфейс взаимодействия с пользователем, при
помощи пользователь получает доступ к данным сервера, и выполняют несложные
операции.

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

«ИС Автотранспорт» объединяет в себе необходимый
функционал для автоматизации автопарка и дружественный интерфейс взаимодействия
с пользователем. Простота эксплуатации позволяет успешно использовать программу
специалистам, не имеющим навыков работы с компьютером.

Постановка задачи

Разработать модель распределенной реляционной базы данных
автотранспортного предприятия, состоящего из главного производства и нескольких
удаленных филиалов. Части предприятия связаны компьютерной сетью (TCP/IP),
имеют собственные локальные базы данных, могут использовать данные удаленных
узлов. Глобальная информация хранится на центральном узле.

Система должна обладать следующими возможностями:

)        Учет автомобилей (автопарк):

.1)     Добавление, изменение учетной информации об
автомобилях, удаление автомобиля из БД;

1.2)   Добавление, изменение учетной информации о водителях,
удаление водителя из БД;

.3)     Приписка водителей к автомобилю (водительская смена).

2)      Учет заявок (офис):

.1)     Составление, изменение, удаление заявки;

2.2)   Составление, изменение, удаление детализации к заявке;

.3)     Заполнение путеводного листа: добавление, удаление,
изменение пунктов маршрута перевозки с возможностью запоминания времени прохождения
каждого пункта;

.4)     Фильтрация заявок по составному критерию;

.5)     Учет клиентов, производящих заявки.

3)      Учет временно хранящихся товаров для перевозки
(склад):

.1)     Прием, списание, изменение, удаление товара;

3.2)   Фильтрация товаров по составному критерию;

.3)     Учет владельцев товара.

1.
Аналитическая часть

1.1 Описание
структуры и функционирования предприятия

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

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

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

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

1.2
Разработка программного продукта

Система разработана на языке Object Pascal с применением
интегрированной среды разработки (IDE) Delphi 7 Enterprise, СУБД Firebird 2.0.4
и открытых компонент EhLib и IBUpdateSQLW.

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

В качестве системы управления базами данных была выбрана СУБД
Firebird версии 2.0.4. Предпочтение было отдано именно этой СУБД по следующим
причинам:

)        Firebird — ветвь, отделившаяся от Interbase после
появления в 2000 году исходных кодов Interbase 6.0 под лицензией IBPL. Поэтому
Firebird унаследовала весь функционал, что был реализован Inprise Corp (в
последствии Borland) за более чем 20 лет разработки и полностью отвечает
требованиям, предъявляемым к современным СУБД;

база автопарк программный продукт

2)      Будучи основанной на бесплатном коде, Firebird
является полностью бесплатной и открытой СУБД, оставаясь при этом завершенным и
регулярно обновляющимся программным продуктом с оперативной технической поддержкой;

3)      Firebird является одной из наиболее простых и удобных
СУБД в плане развертывания и администрирования;

)        Firebird обладает довольно низкими системными
требованиями (сервер может функционировать даже на i386, 32Mb ОЗУ),
минимальными размерами дистрибутива (~2Mb) и достаточно высокой
производительностью, в том числе на больших объемах данных;

)        Многоверсионная архитектура Firebird позволяет
читающим пользователям не мешать пишущим, что при большом числе запросов
существенно экономит машинное время;

)        Сервер Firebird доступен в 3 вариантах: Classic,
Super, Embedded, благодаря чему эта СУБД подходит под практически любую задачу,
связанную с хранением данных. Classic Server и Super Server имеют
клиент-серверную архитектуру.

Отличие Classic Server от Super Server заключается в том, что
Classic создает процесс для каждого пользовательского соединения, а SuperServer
— один процесс, который обрабатывает запросы клиентов в разных потоках этого же
процесса. Архитектура Classic надежнее, но требует больше памяти, так как кэш
данных и метаданных у каждого процесса (пользователя) свой. SuperServer —
производительнее, имеет общий кэш данных и метаданных, но не распараллеливает
запросы разных пользователей на многопроцессорных машинах. Для перезапуска
процесса SuperServer вместе с ним запускается процесс Guardian, отслеживающий
состояние процесса сервера.

Сервер реализованной системы основан на Firebird Super
Server, что также позволяет ей естественным образом функционировать в
распределенной среде. В данном случае на компьютере-сервере хранится база
данных пользователей и заявок под управлением серверной части СУБД Firebird
(Super Server), которая осуществляет обработку запросов от клиентов. Хранение
заявок на сервере осуществляется ввиду необходимости закрытия или оформления
заявки из любого территориально удаленного офиса.Embedded Server начал
выпускаться с версии 1.5, этот сервер представляет собой Firebird Super server,
скомпилированный в виде библиотек DLL. Embedded идеален для
однопользовательских приложений — в этом случае не требуется совершенно никаких
настроек, и достаточно разместить библиотеки рядом с исполняемым файлом.

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

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

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

Кроме того, Embedded обладает функциональностью обычной
клиентской библиотеки (gds32. dll) — если соединение сетевое, то есть, с
указанием имени сервера (srv: c: dirdata. fdb), то библиотека выполняет
функции обычной клиентской библиотеки. Если соединение локальное (c: dirdata.
gdb), то библиотека выполняет функции сервера. Для случая соединения вида
«localhost: c: dirdata. gdb» используется следующий алгоритм —
производится попытка коннекта к процессу сервера, и если его на данной машине
нет, то происходит соединение через Embedded.

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

Программный продукт получает доступ к СУБД посредством
библиотеки прямого доступа IBX (Interbase Express), входящей в состав VCL
Delphi. Применение библиотеки прямого доступа, которая использует интерфейс
Interbase API (реализованный клиентской библиотекой gds32. dll), упрощает цепочку
доступа к базе данных, в данном случае она состоит из двух звеньев:
приложение-клиент (приложение + gds32. dll) и сервер управления БД.

В отличие от других средств доступа к БД, использующих
промежуточные звенья между клиентом и сервером (BDE, ODBC, ADO, dbExpress),
прямой доступ отличается повышенной производительностью и полной поддержкой
всех особенностей данной СУБД.

Сетевой доступ к серверу осуществляется посредством протокола
TCP/IP по сетевому имени сервера или его IP-адресу.

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

В первой ситуации Firebird EmbeddedServer можно не
задействовать: его функции выполнит SuperServer.

Функционал IBX был расширен дополнительным открытым
компонентом TIBUpdateSQLW, наследованным от TIBUpdateSQL. Компонент
TIBUpdateSQL предназначен для выполнения SQL-запросов на Insert, Update,
Refresh и Delete и подключается к TIBQuery, который и вызывает непосредственно
соответствующие методы. В данном для такой связки приходится использовать
пишущую транзакцию (с параметрами read_committed, rec_version, nowait). Но с
учетом архитектурных особенностей InterbaseFirebird это нежелательно: схема
взаимодействия транзакций в этих СУБД такова, что заинтересованная транзакция,
которой и является пишущая транзакция в неподтвержденном состоянии
(non-committed), удерживает версии записей для всех данных, которые были
прочитаны или изменены в контексте данной транзакции. Эти записи могут устареть
(«мусорные» записи), но удержание не позволяет сборщику мусора
(sweeper) их удалить, что при большой продолжительности транзакции влечет
накопление мусора в базе данных. Как следствие, со временем падает
производительность при обращении к данным.

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

что в будущем может привести к непредсказуемым последствиям и
вылиться в нестабильность работы СУБД. По этой же причине крайне не
рекомендуется использовать для доступа к БД Interbase/Firebird библиотеки BDE,
где возможна только одна транзакция на соединение. Компонент IBUpdateSQLW имеет
дополнительное свойство UpdateTransaction и позволяет использовать отдельную
транзакцию для запросов, изменяющих данные.

Это дает возможность производить чтение данных (в частности,
держать открытыми продолжительные запросы, только читающие данные), через
«читающую» транзакцию с параметрами read, read_committed,
rec_version, которая стартует на сервере сразу же в состоянии commited.
Изменения же данных можно производить кратковременными запросами через пишущую
транзакцию.

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

Для разработки баз данных была применена утилита
администрирования для СУБД Interbase/Firebird/Yaffil HK-Software IBExpert —
наиболее мощный и функциональный программный пакет из существующих. IBExpert
включает средства визуального проектирования БД, автоматизированного
составления сложных SQL-запросов, поддерживает подсветку синтаксиса DDL, имеет
функции управления пользователями и ролями и обладает множеством других
возможностей для эффективной разработки и администрирования баз данных
Firebird. IBExpert полностью бесплатен для жителей России и СНГ.

1.3
UML-диаграммы предприятия

1.3.1 Работа
офиса

1.3.2 Работа
автопарка

1.3.3 Работа
склада

1.4 Модель
«сущность-связь» БД предприятия

2.
Декомпозиция БД предприятия на локальные базы данных

В результате декомпозиции БД было получено 3 базы данных:
главная БД, БД автопарка и БД склада грузов.

2.1 Модель
«сущность-связь» главной БД

2.2 Модель
«сущность-связь» БД автопарка

2.3 Модель
«сущность-связь» БД склада

3.
Реляционная модель БД

3.1
Реляционная модель главной БД

Генераторы:

GENERATOR GEN_CLIENT_ID;GENERATOR
GEN_GOODS_ID;GENERATOR GEN_REQUEST_ID;GENERATOR GEN_REQUEST_TYPE_ID;GENERATOR
GEN_ROUTE_ID;GENERATOR GEN_USERS_ID;

Таблицы:

Таблица клиентовTABLE CLIENT
(INTEGER NOT NULL,VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,DETAIL
VARCHAR (300) CHARACTER SET WIN1251 COLLATE WIN1251);

Таблица детализацииTABLE GOODS
(INTEGER NOT NULL,INTEGER,_NUM VARCHAR (50),VARCHAR (100) CHARACTER SET WIN1251
COLLATE WIN1251,CNT INTEGER,VARCHAR (20) CHARACTER SET WIN1251 COLLATE
WIN1251,WEIGHT DOUBLE PRECISION);

Таблица типов заявокTABLE
REQUEST_TYPE (INTEGER NOT NULL,VARCHAR (100) CHARACTER SET WIN1251 COLLATE
WIN1251);

Таблица пользователейTABLE USERS (

UID INTEGER NOT NULL,VARCHAR (100) CHARACTER SET
WIN1251 COLLATE WIN1251,LOGIN VARCHAR (50) CHARACTER SET WIN1251 COLLATE
WIN1251,PASS VARCHAR (50) CHARACTER SET WIN1251 COLLATE WIN1251,RULES VARCHAR
(20) CHARACTER SET WIN1251 COLLATE WIN1251);

Таблица пунктов маршрутаTABLE ROUTE
(INTEGER NOT NULL,VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,DATE_PASS
TIMESTAMP,INTEGER,INTEGER);

Триггеры:

TRIGGER REQUEST_BI0_DATE_ADD FOR REQUESTBEFORE
INSERT POSITION 0. date_add = current_timestamp;(new.completed = 1) then begin.
date_completed = current_timestamp;

end

Триггер заполняет поля date_add (дата составления заявки) и
date_completed (дата закрытия заявки) вновь создаваемой записи текущей датой на
сервере (константа current_timestamp).

CREATE TRIGGER REQUEST_BU0_DATE_COMPLETED FOR
REQUESTBEFORE UPDATE POSITION 0(new.completed <> old. с) then begin.
date_completed = current_timestamp;

end

Триггер заполняет поле date_completed текущей датой на
сервере, если после обновления записи значение поля completed (заявка закрыта)
изменилось.

Create trigger users_bi for usersBEFORE INSERT
POSITION 0begin(new. uid is null) then. uid = gen_id (gen_users_id,1);

end

Триггер подставляет значение первичного ключа uid таблицы
пользователей Users как текущее значение генератора gen_users, если оно не было
задано при вставке записи.

Хранимые процедуры:

PROCEDURE USERS_INSERT (VARCHAR (50),VARCHAR
(20),VARCHAR (100),VARCHAR (50))(INTEGER)= gen_id (gen_users_id,1);into users

(LOGIN, NAME, PASS, RULES, UID)

(: LOGIN,: NAME,: PASS,: RULES,: UID);

suspend;^

Процедура осуществляет вставку записи в таблицу пользователей
и возвращает значение первичного ключа (uID) вставленной записи.

CREATE PROCEDURE USERS_UPDATE (VARCHAR
(20),VARCHAR (100),VARCHAR (100),INTEGER,VARCHAR (50))users=: LOGIN,=: NAME,=:
PASS,=: RULES=: UID;

end^

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

CREATE PROCEDURE USERS_DELETE (INTEGER)from users
where

UID =: UID;^

Процедура осуществляет удаление записи из таблицы
пользователей.

3.2
Реляционная модель БД автопарка

Генераторы:

GENERATOR GEN_CAR_ID;GENERATOR GEN_DRIVER_ID;

Таблицы:

Таблица водителейTABLE DRIVER (INTEGER
NOT NULL,VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,PASSPORT VARCHAR
(100) CHARACTER SET WIN1251 COLLATE WIN1251,CAR INTEGER);

3.3
Реляционная модель БД склада

Генераторы:

GENERATOR GEN_CLIENT_ID;GENERATOR GEN_GOODS_ID;

Таблицы:

Таблица клиентов (владельцев товара)

CREATE TABLE CLIENT (INTEGER NOT NULL,VARCHAR
(100) CHARACTER SET WIN1251 COLLATE WIN1251,DETAIL VARCHAR (300) CHARACTER SET
WIN1251 COLLATE WIN1251);

Таблица товаровTABLE GOODS
(INTEGER NOT NULL,VARCHAR (300) CHARACTER SET WIN1251 COLLATE WIN1251,CLIENT
INTEGER,INTEGER,INTEGER,_NUM VARCHAR (50) CHARACTER SET WIN1251 COLLATE
WIN1251,DIMENSION VARCHAR (50) CHARACTER SET WIN1251 COLLATE WIN1251,WEIGHT
DOUBLE PRECISION,_OLD INTEGER,_ADD TIMESTAMP,_OLD TIMESTAMP,INTEGER,INTEGER);

Триггеры:

TRIGGER GOODS_BI0_DATE_ADD FOR GOODSBEFORE INSERT
POSITION 0. date_add = current_timestamp;(new. is_old = 1) then begin. date_old
= current_timestamp;TRIGGER GOODS_BU0_DATE_OLD FOR GOODSBEFORE UPDATE POSITION
0(new. is_old <> old. is_old) then begin. date_old = current_timestamp;

end

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

4.1 Вход в
программу

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

Рис. 4.1 Окно авторизации пользователя

В поле «Имя пользователя» необходимо ввести имя
своей учетной записи, в поле «Пароль» — свой пароль для доступа к
модулям системы. После нажатия на «ОК» будет совершена попытка соединения
с сервером Firebird и установки подключения к главной БД. Ход подключения
отображается в окне подключения к базе данных.

Рис. 4.2 Окно подключения к БД

При успешном подключении окно автоматически закроется через 3
секунды. Отсчет времени отображается в окне подключения в реальном времени.

Рис. 4.3 Успешное подключение

При неуспешном подключении будет совершена повторная попытка
через 10 секунд.

При необходимости процесс подключения можно отменить нажатием
кнопки «Отмена».

Рис. 4.4 Произошла ошибка подключения

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

Рис. 4.5 Сообщение о неверном имени пользователя

Рис. 4.6 Сообщение о некорректном пароле

Из окна авторизации можно управлять подключениями к БД при
помощи окна состояния баз данных, которое вызывается по нажатию на кнопку
«Настройка».

Рис. 4.7 Окно состояния баз данных

Из окна состояния баз данных можно произвести подключение к
нужной БД, отключение от БД, а также указать параметры подключения для каждой
из баз данных путем нажатия на кнопку «…», в результате чего на
экране будет отображено оно настройки подключения к БД. Вид подключения можно
задать локальным или удаленным, в первом случае предполагается расположение БД
на локальном диске, в этом случае нет необходимости вводить параметры
удаленного подключения. При использовании варианта сервера Firebird
EmbeddedServer необходимо указывать подключение к БД только как локальное.

Рис. 4.8 Окно настройки, удаленное подключение

Рис. 4.9 Окно настройки, локальное подключение

При локальном подключении возможен вызов диалога открытия
файла базы данных (*. FBD) следующего вида:

Рис. 4.10. Диалог открытия файла БД

Настройки подключения хранятся в файле DB. ini. Работа с
файлом реализована при помощи класса Tin File библиотеки VCL Delphi.

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

Рис. 4.11. Окно выбора модуля

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

Модули системы реализованы в виде фреймов Delphi (TFrame) с
применением механизма наследования фреймов. Один и тот же фрейм может быть
создан любое число раз без необходимости дублирования программного кода, как
это проделано с фреймами клиентов и водителей.

Все фреймы программного продукта унаследованы от TFrmPattern
— фрейма-шаблона, представляющего лишь базовые параметры, общие для всех
фреймов (Align, Anchors и т.д.). Также в классе TFrmPattern определены
абстрактные методы Initialize и Finalize и объявлена переменная ModuleName.
Методы переопределяются в потомках фрейма и служат соответственно для
инициализации (создание вложенных фреймов, открытие запросов и т.д.) и закрытия
фрейма. Методы вызываются перед показом и перед скрытием или уничтожением
фрейма. Переменной ModuleName задается заголовок модуля. Переменной
присваивается значение в переопределенном конструкторе каждого фрейма.

4.2 Модуль
«Автопарк»

Модуль предоставляет возможности по учету автомашин,
водителей, а также мониторингу текущей заявки для каждой автомашины.

Рис. 4.12. Основное окно модуля «Автопарк»

Класс табличного представления TDBGridEh (библиотека EhLib)
данных позволяет изменение высоты строки таблицы и многострочное отображение
данных. Для изменения высоты строки необходимо потянуть левой кнопкой мыши за
край индикатора строки.

По нажатию на кнопки «Добавить» и
«Изменить» произойдет отображение диалогов добавления и изменения
учетной информации об автомашине. Для данных диалогов программа использует
единственный класс формы TfrEditCar, меняя заголовок окна до отображения его на
экране в процедуре добавления и удаления автомашины. Диалог создается каждый
раз, когда происходит вызов процедуры добавления или изменения автомашины, и
удаляется по ее завершению. Заполнение полей ввода происходит автоматически
путем использования DB-aware компонентов (DBEdit и др.).

Рис. 4.13. Диалог добавления автомашины

Рис. 4.14. Диалог изменения автомашины

По нажатию на кнопку «Удалить» происходит удаление
автомашины и сброс значения приписки к данной автомашине у всех приписанных
водителей.

На вкладке «Водители» располагается экземпляр
фрейма, реализующий функциональность работы с водителями TfrmDriver. Фрейм
создается во время выполнения программы.

Рис. 4.15. Вкладка «Водители»

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

Рис. 4.16. Диалог приписки водителя

По нажатию на кнопку «Добавить» или
«Изменить» будет отображен соответствующий диалог.

Рис. 4.17. Диалог добавления водителя

4.3 Модуль
«Офис»

Модуль предоставляет возможности по учету заявок, детализаций
к заявке, клиентов (заказчиков), составлению путеводного листа, а также
фильтрации заявок по критерию.

Рис. 4.18. Основное окно модуля «Офис»

Рис. 4.19. Диалог добавления детализации

Рис. 4.20. Диалог добавления заявки

По нажатию на кнопку «…» будет отображен диалог
выбора клиента.

Рис. 4.21. Диалог выбора клиента

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

Рис. 4.22. Диалог добавление пункта маршрута

По нажатию на кнопку «Фильтр» будет отображен
диалог задания условий фильтрации записей в таблице заявок.

Рис. 4.23. Диалог фильтрации заявок

В зависимости от ввода после закрытия диалога динамически
составляется SQL-запрос фильтрации записей в таблице заявок Request.

Рис. 4.24. Пример фильтрации заявок: отображены только
выполненные

4.4 Модуль
«Склад»

Модуль предоставляет возможности по учету грузов для
перевозки, хранящихся на складе, а также клиентов — владельцев груза.

Рис. 4.25. Основное окно модуля «Склад»

Рис. 4.26. Диалог добавления товара

По нажатию на кнопку «…» будет отображен диалог
выбора клиента, содержащий экземпляр фрейма TfrmClient. В данном случае фрейм
работает с БД склада.

Рис. 4.27. Диалог фильтрации товаров

4.5 Модуль
администрирования

Модуль осуществляет управление пользователями системы. К
модулю имеет доступ только администратор (учетная запись, содержащая в поле
RULES значение «а»). Пользователи хранятся в таблице USERS главной
БД.

Рис. 4.28. Основное окно модуля администрирования

Рис. 4.29. Диалог добавления пользователя

В системе должна существовать, по крайней мере, одна учетная
запись администратора: это пользователь «admin». Имя пользователя
(логин) этой учетной записи изменить невозожно, как и права пользователя, но
можно сменить пароль учетной записи и ФИО администратора. Также запись
администратора нельзя удалить.

Рис. 4.30. Диалог изменения записи администратора

Рис. 4.31. Ошибка удаления записи администратора

4.6
Тестирование программы

После запуска ИС «Автотранспорт» на экране будет
отображен диалог авторизации пользователя. Для успешной авторизации необходимо
соединение с главной базой данных.

Рис. 4.32. Диалог авторизации пользователя

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

Рис. 4.33. Производится подключение к БД

Если подключение с текущими настройками успешно установлено,
будет отображено соответствующее сообщение, и диалог будет закрыт через 3
секунды.

Рис. 4.34. Подключение к БД установлено

Если подключиться не удалось, попытка будет повторяться
каждые 10 секунд. Чтобы отменить циклические попытки подключения, необходимо
нажать на кнопку «Отмена».

Рис. 4.35. Ошибка подключения к БД

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

Рис. 4.36. Диалог ошибки — неверное имя пользователя

Рис. 4.37. Диалог ошибки — неверный пароль

Настроить параметры подключения к БД можно путем нажатия
кнопки «Настройка» в окне авторизации. По нажатию будет отображен
диалог состояния БД. Для настройки параметров необходимо нажать на кнопку
«…» напротив нужной базы данных.

Рис. 4.38 Диалог состояния БД

По нажатию на «…» будет отображен диалог настройки
параметров данный БД. В диалоге можно задать параметры как для локального
подключения, так и для удаленного. В последнем случае в поле «IP-адрес
сервера» может быть введен как IP-адрес, так и доменной имя сервера, где
запущен СУБД Firebird и расположен файл БД. Поле «Путь к файлу БД»
также поддерживает псевдонимы БД, которые могут быть заданы в файле
«aliases. conf» СУБД Firebird.

Рис. 4.39. Диалог настройки параметров подключения —
локальное подключение

Рис. 4.40. Диалог настройки параметров подключения — удаленное
подключение

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

После успешного подключения к БД и проверки имени
пользователя и пароля, на экране будет отображен диалог выбора модуля ИС
«Автотранспорт». В диалоге отображаются только те модули, которые
разрешены администратором системы для данного пользователя. После выбора
нужного модуля, будет произведена его загрузка и подключение к необходимой для
работы базе данных.

Рис. 4.41. Диалог выбора модуля

Выберем в списке модуль «Офис». После загрузки окно
модуля «Офис» имеет следующий вид.

Рис. 4.42. Главное окно модуля «Офис»

Добавим новую заявку.

Рис. 4.43. Диалог добавления заявки

Для добавления нового клиента нажмем «…» и в
диалоге выбора клиента нажмем «Добавить». В диалоге добавления
клиента необходимо заполнить поля.

Рис. 4.44. Диалог добавления клиента

Рис. 4.45 Диалог выбора клиента

После добавления клиента таблица заявок имеет вид:

Рис. 4.46 Состояние таблица заявок

Добавим детализацию к заявке:

Рис. 4.47. Диалог добавления детализации

После добавления детализации таблица детализации имеет вид:

Рис. 4.48. Состояние таблицы детализации

Аналогично добавим еще несколько детализаций к заявке.

Рис. 4.49 Состояние таблицы детализации

Добавим несколько пунктов маршрута для заявки.

Рис. 4.50. Диалог добавления пункта маршрута

После добавления таблица пунктов маршрута примет вид:

Рис. 4.51. Состояние таблицы пунктов маршрута

Для отметки о прохождении пункта маршрута выберем пункт
маршрута «с. Убей» и нажмем на кнопку «Изменить». Будет
отображен диалог изменения пункта маршрута, в котором установим флаг
«Пройден», а также зададим дату и время прохождения пункта маршрута.

Рис. 4.52. Диалог изменения пункта маршрута

После отметки о прохождении таблица пунктов маршрута примет
вид:

Рис. 4.53. Состояние таблицы пунктов маршрута

Для выбора другого модуля системы выберем пункт меню
«Файл — > Выбрать модуль». Выберем модуль «Автопарк»,
основное окно которого имеет вид:

Рис. 4.54. Главное окно модуля «Автопарк»

Добавим новую автомашину

Рис. 4.55. Диалог добавления автомашины

Где поле код заявки — код заявки, которую выполняет данная
автомашина.

После добавления таблица автомашин примет вид:

Рис. 4.56. Состояние таблицы автомашин

Для обновления состояния выполнения заявки для выбранной
автомашины необходимо нажать на кнопку «Обновить». Для обновления
состояния необходимо соединение с главной БД, если оно отсутствует, будет
произведена попытка подключения к ней.

Рис. 4.57. Попытка повторного подключения к главной БД

Припишем водителя к автомашине «ГАЗ «Газель».
Для этого нажмем на кнопку «Приписать» и в появившемся диалоге
выберем водителя.

Рис. 4.58. Диалог выбора водителя

После операции таблица приписанных водителей примет вид:

Рис. 4.59. Состояние таблицы приписанных водителей

Для добавления нового водителя перейдем на вкладку
«Водители», где нажмем на кнопку «Добавить» и в диалоге
добавления водителя введем его личные данные.

Рис. 4.60. Диалог добавления водителя

После добавления водителя таблица водителей примет вид:

Рис. 4.61. Состояние таблицы водителей

Перейдем в модуль «Склад» с помощью главного меню
программы. Основное окно модуля «Склад» имеет следующий вид:

Рис. 4.62. Основное окно модуля «Склад»

Добавим новый товар на склад. Для этого нажмем на кнопку
«Добавить» и заполним необходимые поля.

Рис. 4.63. Диалог добавления товара

После добавления таблица товаров примет вид:

Рис. 4.64 Состояние таблицы товаров

Из главного окна программы также возможно управление базами
данных. Для этого выберем пункт главного меню «Инструменты — Настройка
БД». На экране будет отображен диалог состояния БД.

Рис. 4.65. Диалог состояния БД — все подключения активны

Нажмем кнопку «Отключиться» напротив каждой БД.

Рис. 4.66. Диалог состояния БД — все подключения неактивны

Так как соединение с БД, необходимое для работы текущего
модуля, было потеряно, произойдет выход из текущего модуля и отображение
диалога выбора модуля.

Рис. 4.67. Повторное отображение диалога выбора модуля после
потери подключения

4.7
Руководство администратора

Администрирование ИС «Автотранспорт» производится
посредством модуля управления пользователями, а также при помощи утилит
администрирования СУБД Firebird.

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

Рис. 4.68. Диалог выбора модуля — модуль
«Пользователи»

Выберем в диалоге выбора модуля модуль
«Пользователи».

Для добавления нового пользователя нажмем на кнопку
«Добавить» и заполним необходимые поля диалога.

Рис. 4.69. Диалог добавления нового пользователя

После добавления пользователя таблица пользователей примет
вид:

Попытаемся подключиться вновь возданным пользователем. Для
этого выберем пункт меню «Файл — Завершить сеанс» и в диалоге
авторизации введем новые имя и пароль.

Рис. 4.70. Диалог авторизации — пользователь
«yurio»

Рис. 4.71. Диалог выбора модуля для пользователя
«yurio»

Авторизация прошла успешно, кроме того, пользователю доступны
именно те модули, которые были назначены при его создании. Модуль
«Пользователи» недоступен, потому что пользователю «yurio»
не были назначены права администратора системы (директива «а»).

Администрирование СУБД Firebird производилось при помощи
утилиты HK-Software IB Expert, одной из самых удобных и функциональных в своем
роде. Кроме того, IB Expert распространяется бесплатно для жителей и
юридических лиц, зарегистрированных на территории России и СНГ.

При помощи IB Expert создавались и администрировались БД ИС
«Автотранспорт», также производился контроль скорости исполнения
SQL-запросов, наблюдалась статистика транзакций, проверялись свойства индексов
с целью контроля производительности БД.

Глава 5.
Организационно-экономическая часть

5.1
Экономическое обоснование разработки программы

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

В данном дипломном проекте при разработке программного
обеспечения выполняются следующие расчеты:

1.
Расчет
трудоемкости разработки;

2.
Расчет
цены новой программы (алгоритма).

5.2 Расчет
трудоемкости и цены разработки

Разработка программной продукции, представленной в настоящем
проекте, включает в себя 3 этапа:

1.
Разработка
технического задания.

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

3.
Разработка
рабочего проекта на уровне программирования.

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

_пп=t_тз+t_тп+t_рп,

где t_тз — трудоемкость разработки
технического задания на создание программной продукции;

t_тп — трудоемкость разработки технического
проекта программной проекции, т.е. трудоемкость разработки алгоритма решения;

t_рп — трудоемкость разработки рабочего
проекта.

Исходя из плана разработки программного проекта:

t_тз = 20 чел. — дней;_тп =
15 чел. — дней;_рп = 18 чел. — дней.

Тогда трудоемкость разработки программной продукции:

_пп=20+15+18;_пп= 53 чел. — дня.

5.3
Определение цены программной продукции

Цена программной продукции рассчитывается по формуле:

Ц=К*С+Пр, (1.1)

где С — затраты на разработку программной продукции
(сметная себестоимость);

К — коэффициент учета затрат на изготовление
опытного образца программной продукции как продукции
производственно-технического назначения (К = 1,1.1,2);

Пр — нормативная прибыль, рассчитываемая по
формуле:

Пр= (С+С_м) *р_н, (1.2)

где р_н — норматив рентабельности, (р_н
= 25%);

С_м — материальные затраты, руб. /изд.

Основная заработная плата.

Расчёт основной заработной платы выполняется на основе
трудоёмкости выполнения каждого этапа в человеко-днях и величины месячного
должностного оклада исполнителя. Расчет ведется по формуле:

где  — среднемесячный оклад i-го
исполнителя, руб.;

 — среднее количество рабочих дней в месяце;

 — трудоемкость работ, чел. — дни;

 руб.;

 чел. — дней;

 дня;

 руб.

Дополнительная заработная плата.

На эту статью относятся выплаты, предусмотренные законодательством
о труде за неотработанное по уважительным причинам время: оплата очередных и
дополнительных отпусков, оплата льготных часов подросткам и т.п. (принимается в
размере 20% от суммы основной заработной платы).

Расчет ведется по формуле:

,

где  — коэффициент отчислений на
дополнительную зарплату.

;

;

 руб.

Отчисления на социальное страхование.

Затраты по этой статье определяются в процентном отношении от
суммы основной и дополнительной заработной платы.

В статье учитываются отчисления в бюджет социального страхования,
т.е.:

где  — коэффициент отчислений в единый
социальный налог.

Отчисления в единый социальный налог состоят из отчислений:

—   в пенсионный фонд 14%;

—   отчисления на социальное
страхование от несчастных случаев на производстве и заболеваний 0,2%.

Таким образом,

 руб.

На основе полученных данных рассчитаем сметную себестоимость:

;

;  руб.

Таблица 5.1. Себестоимость программы в действующих ценах, рублей

Наименование статьи	Сметная себестоимость, руб.	Удельный вес, %
Основная заработная плата	14454,55	72,97
Дополнительная заработная плата	2890,91	14,59
Отчисления на соцстрахование	2463,06	12,44
Итого	19808,52	100

Нормативная прибыль.

На основе полученных данных рассчитаем цену программной
продукции по формуле 1.1 (смотрите выше):

;

 руб

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

;

;

 руб;= (Пр/Ц) *100%;= (4952,13/19808,53) *100%=25%.

Выводы по
главе

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

Данный раздел проекта включает в себя расчет трудоемкости разработки,
расчет затрат и определение цены разработки. Трудоемкость разрабатываемого
программного продукта равна 53 чел. — дням, при этом цена разработки составила
26741,50 руб.

Таким образом, разработка экономична и рентабельность
программного продукта соответствует нормативной и составляет 25%.

6.
Информационная безопасность проекта

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

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

—     компьютерную
безопасность;

—     безопасность
информационных систем и процессов;

—     безопасность среды для
реализации информационных процессов.

К основным аспектам проблемы обеспечения информационной
безопасности относятся:

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

—     защита прав граждан на
владение, распоряжение и управление принадлежащей им информацией;

—     защита прав
предпринимателей при осуществлении ими коммерческой деятельности;

—     защита конституционных
прав граждан на тайну переписки, переговоров, личную тайну;

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

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

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

2.      Организационно — техническое обеспечение, которое
представляет собой комплекс координируемых мероприятий и технических мер,
реализующих практические механизмы защиты. Условно эти мероприятия
подразделяются на системообразующие и надзорные (контрольные). Особенностью
надзорных мероприятий является необходимость создания независимого, вне
отраслевого надзора за защитой и уровнем безопасности информации.

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

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

—     предупреждение появления
угроз информации;

—     выявление возможных
направлений и степени нарастания опасности нарушения ИБ;

—     обнаружение реальных
фактов нарушения ИБ;

—     пресечение разглашения,
утечки и несанкционированного доступа к информации, нарушения ее целостности;

—     ликвидация или снижение
уровня ущерба от нарушения ИБ и ее использования соумышленниками.

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

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

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

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

Разработанный программный продукт, непосредственно работает с
базой данных предприятия.

Для Системы управления базами данных (СУБД) важны три
основных аспекта информационной безопасности — конфиденциальность, целостность
и доступность.

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

Произведем оценку безопасности программного продукта согласно
критериям по оценке безопасности ГОСТ 15408/2002.

6.1 Основные
понятия и определения оценки объекта

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

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

Программные ресурсы: прикладное программное обеспечение,
системное программное обеспечение, средства разработки и утилиты. В данном
случае системным программным обеспечением является операционная система
Windows, СУБД Paradox — средство разработки программы.

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

Итак, под объектом оценки (ОО) понимается аппаратно —
программный продукт или система информационных технологий (ИТ) с
соответствующими документами.

Система ИТ — специфическое воплощение изделия с конкретным
назначением и условиями эксплуатации.

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

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

—     административная область
(политика безопасности предприятия);

—     законодательная область
(совокупность законодательных актов, нормативных актов);

—     физическая область
(физическая среда и средства физической защиты);

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

Следующим шагом в оценке является описание следующих
материалов:

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

—     изложение угроз объекту
оценки, причем они рассматриваются с точки зрения различных аспектов: источник
угрозы (нападающий),

—     метод действия, активы, которые
могут подвергнуться нападению, уязвимости, являющиеся предпосылкой для
нападения;

—     изложение политики
безопасности, применяемой в организации.

Для системы ИТ такая политика может быть описана достаточно
точно, а для продукта ИТ могут быть сделаны только рабочие предположения.

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

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

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

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

Рис. 6.1 Последовательность формирования требований
информационной безопасности

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

6.2 Профиль
защиты

В состав профиля защиты (ПЗ) входят:

.        Введение ПЗ (идентификация ПЗ, аннотация ПЗ).

2.      Описание объекта оценки (ОО).

.        Среда безопасности ОО (предположение безопасности,
угрозы, политика безопасности организации).

.        Цели безопасности (цели безопасности для ОО, цели
безопасности для среды).

.        Требования безопасности ИТ (для среды ИТ).

.        Требования безопасности для ОО (функциональные
требования безопасности ОО, требования доверия к безопасности ОО).

.        Замечания по применению.

.        Обоснование (логическое обоснование целей
безопасности, логическое обоснование требований безопасности).

Идентификация ПЗ

Название: Профиль защиты. Контролируемый доступ.

Обозначение: ПЗ КД.

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

Аннотация ПЗ

Профиль защиты с контролируемым доступом, разработанный на
основе Общих критериев версия 2.1, определяет набор функциональных требований и
требований доверия для продуктов информационных технологий. ПЗ КД-совместимые
продукты поддерживают такое управление доступом, которое позволяет ограничивать
действия отдельных пользователей и доступ к данным объектов. ПЗ КД-совместимые
продукты также предоставляют возможности аудита, при котором осуществляется
регистрация важных для безопасности событий.

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

В общем случае ПЗ КД применим для распределенных систем, но
не учитывает требования безопасности, выходящие за рамки потребностей
распределения ресурсов внутри сети.

Стойкость, обусловленная средой

ПЗ КД определен для некой обобщенной среды со средним уровнем
риска для активов. Требования доверия и минимально допустимая стойкость функций
выбраны в соответствии с этим уровнем риска.

ОУД3 (EAL3) является оценочным уровнем доверия к безопасности
ОО, а средняя стойкость функции безопасности является для данного профиля
минимально допустимой стойкостью функций безопасности, реализуемых
вероятностными и/или перестановочными (но не криптографическими) механизмами.

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

—     пользователь;

—     уполномоченный
пользователь;

—     уполномоченный
администратор;

—     политика дискреционного
управления доступом (DAC);

—     посредничество;

—     доступ;

—     полномочие.

Пользователь — лицо, обращающееся к сервисам, предоставляемым
объектом оценки.

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

Уполномоченным администратором является уполномоченный
пользователь, которому предоставлены полномочия на управление ОО.
Предполагается, что эти пользователи используют полномочия только в рамках,
предписанных руководством администратора.

Политика дискреционного управления доступом (DAC) является
основной политикой, которую ПЗ КД-совместимые ОО осуществляют по отношению к
пользователям и ресурсам.

Политика DAC состоит из правил двух типов: те, которые
применимы к поведению уполномоченных пользователей (обозначаемые правилами
доступа), и те, которые применимы к поведению уполномоченных администраторов
(обозначаемые правилами полномочий). Если удовлетворен запрос уполномоченного
пользователя на операцию с объектом, то говорят, что пользователь получил
доступ к объекту. Если уполномоченным администратором предоставлен запрошенный
сервис, то говорят, что пользователь имеет полномочия на запрошенный сервис или
объект. Как и в случае с доступом, полномочия могут быть множественными.
Типичным примером полномочий являются полномочия аудита, которые позволяют
администратору просматривать записи аудита, пользоваться средствами аудита.

6.3 Описание
объекта оценки

ПЗ КД определяет набор требований безопасности, предъявляемых
к объектам оценки. К этим ОО относятся однопользовательские и многопользовательские
информационные системы на базе компьютеров, ПЭВМ и рабочих станций с
операционными системами общего назначения. В такие системы может входить один
хост или множество взаимодействующих хостов в распределенной конфигурации.

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

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

ПЗ КД предполагает, что ответственность за сохранность
данных, защищаемых функциями безопасности объекта оценки, может быть
делегирована пользователям ОО. Все данные находятся под управлением ОО.

Данные хранятся в объектах, и ФБО могут связать с каждым
управляемым объектом описание прав доступа к нему.

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

6.4 Среда
безопасности ОО

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

Предполагается, что для ПЗ КД — совместимого ОО приняты
эффективные меры безопасности в невраждебной среде, если ОО установлен,
управляется и используется корректно.

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

Предположения безопасности:

—     для управления ОО и
безопасностью информации назначены компетентные лица;

—     системный административный
персонал является ответственным, управляемым и невраждебным и строго
придерживается инструкций административной документации;

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

—     любые системы, с которыми
ОО взаимодействует, находятся под таким же управлением и функционируют по тем
же правилам политики безопасности, что и ОО. ПЗ КД — совместимые ОО применимы
только к тем сетевым или распределенным средам, в которых вся сеть работает с
одинаковыми правилами политики безопасности и остается в пределах одной области
управления;

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

—     пользователи осведомлены
о политике безопасности предприятия

Угрозы безопасности:

1.      Раскрытие конфиденциальной информации
(несанкционированный доступ к БД, прослушивание каналов связи).

2.      Компрометация информации (несанкционированное
применение информационных ресурсов).

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

.        Ошибочное использование информационных ресурсов
(чаще всего программные ошибки).

.        Отказ от информации (не признание факта получения
или отправления), отказ от обслуживания (отказ системы).

.        Незаконное проникновение на территорию организации.

.        Компьютерные вирусы и другие вредоносные программы.

Политика безопасности предприятия:

—     управление доступом —
присвоение каждому пользователю персонального идентификатора, опознание
подлинности идентификатора, проверка полномочий (уровень доступа к системе),

разрешение и создание условий для работы, протоколирование
обращения к разрешенным ресурсам, реагирование (сигнализация, отключение,
задержка работ);

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

Вычислительные ресурсы сосредоточены в контролируемой зоне.

Аппаратное и программное обеспечение ОО защищено от
несанкционированной физической модификации.

6.5 Цели
безопасности

Цели безопасности для ИТ

1.      ФБО должны обеспечивать, чтобы только уполномоченные
пользователи могли получить доступ к ОО и его ресурсам. Предусматривается так
же и физическая защита ресурсов.

2.      ФБО должны управлять доступом к ресурсам, который
основан на идентификаторах пользователей. ФБО должны позволять уполномоченным
пользователям определять, какие ресурсы могут быть доступны.

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

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

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

.        ФБО должны быть спроектированы и реализованы таким
образом, чтобы обеспечивалось осуществление политики безопасности организации в
предопределенной среде.

Цели безопасности, не относящиеся к ИТ

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

2.      Ответственные за ОО лица должны обеспечить, чтобы ОО
был поставлен, инсталлирован, управлялся и функционировал в соответствии с
целями безопасности ИТ.

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

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

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

6.6
Требования безопасности

Требования безопасности для среды ИТ

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

Уровень доверия к реализации ФТБ для ИТ — среды должен быть
не ниже уровня доверия к реализации ФТБ объектом оценки.

Функциональные требования безопасности

ОК предусматривают 11 классов функциональных требований:

.        FAU — аудит безопасности;

2.      FCO — связь;

.        FCS — криптографическая поддержка;

.        FDP — защита данных пользователя;

.        FIA — идентификация и аутентификация;

.        FMT — управление безопасностью;

.        FPR — приватность;

.        FPT — защита ФБО;

.        FRU — использование ресурсов;

.        FTA — доступ к ОО;

.        FTP — доверенный маршрут/канал.

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

Класс FAU:

—     генерация данных аудита безопасности,
FAU_GEN;

—     просмотр аудита
безопасности, FAU_SAR;

—     выбор событий аудита,
FAU_SEL;

—     хранение данных аудита,
FAU_STG.

Класс FDP:

—     политика управления
доступом, FDP_ACC;

—     функции управления
доступом, FDP_ACF;

—     защита остаточной
информации, FDP_RIP;

—     защита конфиденциальности
данных при передаче между ФБО, FDP_UCT.

Класс FIA:

—     аутентификация
пользователя, FIA_UAU;

—     идентификация
пользователя, FIA_UID;

—     определение атрибутов
пользователя, FIA_ATD;

—     спецификация секретов,
FIA_SOS;

—     связывание пользователь —
субъект, FIA_USB.

Класс FMT:

—     управление атрибутами
безопасности, FMT_MSA;

—     управление данными,
FMT_MTD;

—     отмена, FMT_REV;

—     роли управления
безопасностью, FMT_SMR.

Класс FPT:

—     тестирование базовой
абстрактной машины, FPT_AMT;

—     посредничество при
обращениях, FPT_RVM;

—     разделение домена,
FPT_SEP;

—     надежные метки времени,
FPT_STM.

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

Таблица 6.1. Зависимости требований

F A U _ G E N.1

F A U _ S A R.1

F A U _ S T G.1

F D P _ A C C.1

F D P _ A C F.1

F D P _ I F C.1

F D P _ I F F.1

F I A _ A T D.1

F I A _ U A U.1

F I A _ U I D.1

F MT _ MS A.1

F MT _ MS A.3

F MT _ MT D.1

F MT _ S MR.1

F P T _ A MT.1

F P T _ S T M.1

FAU_GEN.1

x

FAU_GEN.2

x

x

—

FAU_SAR.1

x

—

FAU_SAR.2

—

x

—

FAU_SAR.3

—

x

—

FAU_SEL.1

x

—

x

—

—

FAU_STG.1

x

—

FAU_STG.2

x

—

FAU_STG.3

—

x

—

FAU_STG.4

x

—

FDP_ACC.1

—

x

—

—

—

—

—

—

FDP_ACC.2

—

x

—

—

—

—

—

FDP_ACF.1

x

—

—

—

—

—

x

—

FDP_RIP.1

FDP_RIP.2

FDP_UCT.1

o

—

o

—

—

—

—

—

FIA_ATD.1

FIA_SOS.1

FIA_SOS.2

FIA_UAU.1

x

FIA_UAU.2

x

FIAUAU.7

x

—

FIA_UID.1

FIA_UID.2

FIA_USB.1

x

FMT_MSA.1

o

—

o

—

—

—

—

x

FMT_MSA.2

o

—

o

—

—

x

—

x

FMT_MSA.3

—

—

—

—

—

x

—

x

FMT_MTD.1

—

x

FMT_MTD.2

—

x

x

FMT_MTD.3

—

x

—

FMT_REV.1

—

x

FMT_SMR.1

x

FMT_SMR.2

FMT_SMR.3

—

x

FPT_AMT.1

FPT_RVM.1

FPT_SEP.1-3

Требования доверия

Требования доверия также подразделяются на классы.

.        Класс АСМ — Управление конфигурацией (УК):

—     средства контроля УК,
ACM_CAP;

—     охват УК объекта оценки,
ACM_SCP.

2.      Класс ADO — Поставка и эксплуатация:

—     поставка, ADO_DEL;

—     установка, генерация,
запуск, ADO_IGS.

3.      Класс ADV — Разработка:

—     функциональная
спецификация, ADV_FSP;

—     детализация вопросов
безопасности в проекте верхнего уровня, ADV_HLD;

—     соответствие
представлений, ADV_RCR.

4.      Класс AGD — Руководства:

—     руководство
администратора, AGD_ADM;

—     руководство пользователя,
AGD_USR.

5.      Класс ALC — Поддержка жизненного цикла:

—     безопасность разработки,
ALC_DVS.

.        Класс ATE — Тестирование:

—     анализ покрытия, ATE_COV;

—     анализ глубины, ATE_DPT;

—     функциональное
тестирование, ATE_FUN;

—     независимое тестирование,
ATE_IND.

7.      Класс AVA — Оценка уязвимостей:

—     неправильное применение,
AVA_MSU;

—     оценка стойкости функций
безопасности ОО, AVA_SOF;

—     анализ уязвимостей,
AVA_VLA.

Далее приведем таблицу сводного описания оценочного уровня
доверия ОУД3. [15]

Таблица 6.2. Сводное описание оценочного уровня доверия

Класс доверия	Компоненты доверия
Управление конфигурацией	ACM_CAP.3 Средства контроля авторизации
	ACM_SCP.1 Охват УК объекта оценки
Поставка и эксплуатация	ADO_DEL.1 Процедуры поставки
	ADO_IGS.1 Процедуры установки, генерации и запуска
Разработка	ADV_FSP.1 Неформальная функциональная спецификация
	ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня
	ADV_RCR.1 Неформальная демонстрация соответствия
Руководства	AGD_ADM.1 Руководство администратора
	AGD_USR.1 Руководство пользователя
Поддержка жизненного цикла	ALC_DVS.1 Идентификация мер безопасности
Тестирование	ATE_COV.2 Анализ покрытия
	ATE_DPT.1 Тестирование: проект верхнего уровня
	ATE_FUN.1 Функциональное тестирование
	ATE_IND.2 Выборочное независимое тестирование
Оценка уязвимостей	AVA_MSU.1 Экспертиза руководств
	AVA_SOF.1 Оценка стойкости функции безопасности ОО
	AVA_VLA.1 Анализ уязвимостей разработчиком

Перекрестные ссылки между компонентами доверия. В таблице 10
объединены как прямые, так и косвенные зависимости. Косвенные зависимости
являются, в конечном счете, результатом последовательного учета всех
зависимостей каждого компонента, приведенного в списке зависимостей. [15]

Таблица 7.3. Зависимости компонентов доверия

Имена компо-нентов	A U T	C A P	S C P	D E L	I G S	F S P	H L D	I M P	I N T	L L D	R C R	S P M	A D M	U S R	D V S	F L R	L C D	T A T	C O V	D P T	F U N	I N D	C C A	M S U	S O F	V L A
CAP.1-2
CAP.3-4			1												1
CAP.5			1												2
SCP.1-3		3													1
DEL.1
DEL.2-3		3	1												1
IGS.1-2						1					1		1
FSP.1-4											1
HLD.1-2						1					1
HLD.3-4						3					2
HLD.5						4					3
RCR.1-3
ADM.1						1					1
USR.1						1					1
DVS.1-2
COV.1-3						1					1										1
DPT.1						1	1				1										1
DPT.2						1	2			1	1										1
DPT.3						1	2	2		1	1							1			1
FUN.1-2
IND.1						1					1		1	1
IND.2-3						1					1		1	1							1
MSU.1-3					1	1					1		1	1
SOF.1						1	1				1
VLA.1						1	1				1		1	1
VLA.2-4						1	2	1		1	1		1	1				1

Здесь курсивом выделены косвенные зависимости, а полужирным
шрифтом — прямые.

Проанализировав все вышеперечисленные требования и цели
безопасности, можно отнести данную автоматизированную систему (АС) по уровню
защищенности от несанкционированного доступа к группе «1»
(многопользовательские системы, в которых одновременно обрабатывается
информация различных уровней конфиденциальности), классу «Г» в
соответствии с руководящими документами Гостехкомиссии России. Обозначим
подсистемы и требования к данному классу.

Таблица 7.4. Подсистемы и требования к классу 1Г

Подсистема	Требования
Управление доступом	Идентификация, проверка подлинности, контроль доступа субъекта в систему
	Идентификация, проверка подлинности, контроль доступа субъекта к терминалам ЭВМ, каналам связи, внешним устройствам
	Контроль доступа к программам
	Контроль доступа к томам, каталогам, файлам, записям, полям записей.
Регистрация и учет	Регистрация и учет входа/ выхода субъектов доступа в/из системы.
	Регистрация выдачи печатных выходных документов
	Регистрация запуска/ завершения программ, процессов
	Регистрация доступа программ субъекта, к терминалам ЭВМ, файлам.
	Учет носителей информации
	Очистка освобождаемых носителей ОЗУ
Обеспечение целостности	Обеспечение целостности программных средств и обрабатываемой информации
	Физическая охрана средств вычислительной техники и носителей информации
	Периодическое тестирование средств защиты информации
	Наличие средств восстановления для средств защиты информации

6.7
Обоснования

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

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

Управление доступом.

Эта политика осуществляется с помощью цели 1 и 2. Цель 4
обеспечивает то, что информация не будет предоставлена пользователям, у которых
нет необходимости знать о ней, когда ресурсы повторно используются. Цель 5
поддерживает эту политику с помощью требования, чтобы уполномоченные
администраторы были способны управлять функциями безопасности, а цель 6
обеспечивает, что функции вызываются и выполняются корректно.

На пользователей возложена ответственность за
действия в системе.

Эта политика осуществляется с помощью цели 3, требующей,
чтобы действия регистрировались в журнале аудита. Цель 5 поддерживает эту
политику с помощью требования, чтобы уполномоченный администратор был способен
управлять функциями безопасности, а цель 6 обеспечивает, что функции вызываются
и выполняются корректно.

Логическое обоснование требований безопасности

.        Пользователи, уполномоченные на доступ к ОО,
определяются процессом идентификации и аутентификации [FIA_UID.1, FIA_UAU.1].
Для обеспечения авторизованного доступа к ОО данные аутентификации защищены
[FIA_ATD.1, FIA_UAU.7]. Эффективность механизма аутентификации должна быть
достаточной для обеспечения того, что неуполномоченные пользователи не смогут
легко получить доступ [FIA_SOS.1].

2.      Дискреционное управление доступом должно иметь
определенные границы управления [FDP_ACC.1]. Должны быть определены правила
политики DAC [FDP_ACF.1], атрибуты безопасности объектов и субъектов,
используемые для установления политики [FIA_ATD.1, FIA_USB.1]. Уполномоченные
пользователи должны быть способны управлять доступом к объектам [FMT_MSA.1] и
отменять доступ [FMT_REV.1]. Защита объектов должна быть непрерывной с момента
их создания [FMT_MSA.3].

.        Относящиеся к безопасности действия должны быть
определены, подвержены аудиту [FAU_GEN.1] и ассоциироваться с отдельными
пользователями [FAU_GEN.2, FIA_USB.1].

Журнал аудита должен быть защищен таким образом, чтобы только
уполномоченные пользователи имели доступ к нему [FAU_SAR.2].

ФБО должны предоставлять возможность аудита действий
отдельного пользователя [FAU_SAR.3, FAU_SEL.1, FIA_USB.1]. Журнал аудита должен
быть полноценным [FAU_STG.1, FAU_STG.4]. Метки времени должны быть надежными
[FPT_STM.1]. Уполномоченный администратор должен иметь возможность управлять
журналом аудита [FAU_STG.3, FMT_REV.1] и просматривать его [FAU_SAR.1].

.        Остаточная информация, ассоциированная с
определенными объектами в ОО, должна быть очищена (убрана из объекта) до
повторного использования объекта [FDP_RIP.2].

5.      Уполномоченному администратору должны предоставляться
ФБО для управления ОО [FMT_SMR.1]. Администратор должен быть способен управлять
возможностями пользователя [FMT_SMR.1, FMT_MTF.1, FMT_REV.1]. Администратор
должен быть способен управлять просмотром журнала аудита [FAU_SAR.1, FAU_SAR.3,
FAU_SEL.1, FAU_STG.3, FAU_STG.4, FMT_MTD.1, FMT_REV.1].

.        ФБО должны осуществлять ПБО [FPT_RVM.1]. При этом
должна быть организована защита от вмешательства, препятствующего выполнению
ФБО [FPT_SEP.1]. ОО должен демонстрировать правильность функционирования
абстрактной машины, положенной в основу ФБО [FPT_AMT.1], что достигается, в
частности, через требования доверия, определенные в ПЗ. Эта цель предоставляет
общую поддержку для других целей безопасности, защищая части ОО, осуществляющие
и поддерживающие ПБО.

Выводы

1.      Программный продукт является автоматизированной
системой.

2.      Сформулированы функциональные требования и требования
к среде.

.        Разработан профиль защиты автоматизированной системы
на основе государственного стандарта ГОСТ 15408/2002.

Данная автоматизированная система по уровню защищенности от
несанкционированного доступа относится к группе «1»
(многопользовательские системы, в которых одновременно обрабатывается
информация различных уровней конфиденциальности), к классу «Г» в
соответствии с руководящими документами Гостехкомиссии России.

Заключение

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

Примененные в ходе решения инструменты, средства и методы
позволили добиться поставленных целей: программный продукт обладает необходимой
функциональностью, удобным интерфейсом и системными требованиями, не выходящими
за рамки средней конфигурации. Произведенный экономический анализ показал, что
разработка и внедрение ИС «Автотранспорт» принесет выгоду
разработчику.

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

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

1.      Конопка
Р. Создание оригинальных компонент в среде Delphi / Пер. с англ. К.: ДиаСофт
Лтд. 1996, 512 с.;

2.      Ковязин
А., Востриков С. Мир InterBase. Архитектура, администрирование и разработка
приложений баз данных в InterBase/Firebird/Yaffil / П.: КУДИЦ-Образ, 2005, 496
с.;

.        Бирш
Т. Firebird. Быстрый старт / Пер. с англ., 2003,19 с.

4.      URL:
http://megalib.com/books/1057/firebird_qsg. pdf
<http://megalib.com/books/1057/firebird_qsg.pdf>

5.      KDV Использование
InterBase eXpress в приложениях / 2007, 32 с.

6.      URL:
http://www.ibase.ru/devinfo/ibx. htm
<http://www.ibase.ru/devinfo/ibx.htm>

7.      KDV Версионность
метаданных/ 2004, 2 с.

8.      URL:
http://www.ibase.ru/devinfo/metaver. htm
<http://www.ibase.ru/devinfo/metaver.htm>

9.      Кузьменко Д.
Генераторы и их использование / 2005, 18 с.

10.    URL: http://www.ibase.ru/devinfo/generator.
htm <http://www.ibase.ru/devinfo/generator.htm>

11.    Штунц К. Жизненный
цикл транзакций / Пер. с англ., 2004, 12 с.

12.    URL:
http://www.ibase.ru/devinfo/utl. htm
<http://www.ibase.ru/devinfo/utl.htm>

13.    KDV Кооперативная
сборка мусора/ 2005, 6 с.

14.    URL:
http://www.ibase.ru/devinfo/garbage. htm
<http://www.ibase.ru/devinfo/garbage.htm>

15.    Харрисон А. Как
работает версионность данных / Пер. с англ., 2001, 14 с.

16.    URL:
http://www.ibase.ru/devinfo/versions. htm <http://www.ibase.ru/devinfo/versions.htm>

17.    Кузьменко Д.
Транзакции в InterBase / 2005, 38 с.

18.    URL:
http://www.ibase.ru/devinfo/ibtrans. htm
<http://www.ibase.ru/devinfo/ibtrans.htm>

19.    Служба поддержки
iBase.ru Выбор компонент доступа / 2006, 9 с.

20.    URL:
http://www.ibase.ru/devinfo/choosecomp. htm
<http://www.ibase.ru/devinfo/choosecomp.htm>

Приложение
А

Текст программы:uMain;

interface, Windows, Messages, SysUtils, Variants,
Classes, Graphics, Controls, Forms,, Menus, ImgList, ActnList, ComCtrls, XPMan,
StdCtrls, IBDatabase;= class (TForm): TStatusBar;: TImageList;: TMainMenu;:
TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;:
TMenuItem;: TMenuItem;: TMenuItem;: TXPManifest;: TLabel;: TActionList;:
TAction;: TAction;: TAction;: TAction;: TAction;: TButton;FormClose (Sender:
TObject; var Action: TCloseAction);FormShow (Sender:
TObject);actSettingsDBExecute (Sender: TObject);actAboutExecute (Sender:
TObject);actLogoutExecute (Sender: TObject);actExitExecute (Sender:
TObject);actChangeModuleExecute (Sender: TObject);

{ Private declarations }FreeFrames;

{ Public declarations }Initialize:
boolean;InitUser (db: TIBDatabase; login, pass: string): boolean;InitFrame:
boolean;SelectFrame: boolean;;: TfrMain;uFrmUsers, uSettings, uDM, uLogin,
uConnect, uFrmPattern,, uAbout, uConstants, uDBState, uFrmPark, uFrmRequest,;

{$R *. dfm}TfrMain. FormShow (Sender:
TObject);Initialize and InitFrameSelectFrameClose;;TfrMain. FormClose (Sender:
TObject; var Action: TCloseAction);;;TfrMain. Initialize;: boolean;: =
ProductName;: = false;: = false;TfrLogin. Create (nil) do trynot Passed do

// отображение окна авторизацииShowModal =
mrCancel then begin: = true;: = false;if dm. DBMain.
TestConnectedIsPositiveResult (ConnectTo (dm. DBMain, ‘Главная БД’))
thenInitUser (dm. DBMain, edtLogin. Text, edtPass. Text) then begin: = true;: =
true;;;;;TfrMain. FreeFrames;Assigned (frmPattern) then begin. Finalize;.
Free;: = nil;;Assigned (frmUsers) then begin. Finalize;. Free;: = nil;;Assigned
(frmPark) then begin. Finalize;. Free;: = nil;;Assigned (frmRequest) then
begin. Finalize;. Free;: = nil;;Assigned (frmStore) then begin. Finalize;.
Free;: = nil;;;TfrMain. InitUser (db: TIBDatabase; login, pass: string):
boolean;: = false;db. TestConnected then tryDM. qRead do beginActive then
Close;. Text: = ‘select * from USERS where UPPER (LOGIN) =: LOGIN’;(‘LOGIN’).
AsString: = AnsiUpperCase (Login);;EOFMessageDlg (‘База данных: ‘ + db.
DatabaseName + #13 + ‘Пользователь не найден: ‘ + Login,
mtError, [mbOK], 0)trim (FieldByName (‘PASS’). AsString) = trim (Pass) then
begindm. User do begin: = FieldByName (‘UID’). AsInteger;: = FieldByName
(‘LOGIN’). AsString;: = FieldByName (‘NAME’). AsString;: = FieldByName
(‘RULES’). AsString;;;: = true;MessageDlg (‘База данных: ‘ + db. DatabaseName + #13 + ‘Неверный пароль: ‘ + Pass,
mtError, [mbOK], 0);;: = false;;;TfrMain. InitFrame: boolean;: = true;;

// Инициализация фреймов для данного пользователя.
listFrames. Clear;DM. User do begin( (pos (‘c’, Rules) > 0) or (pos (‘a’,
Rules) > 0)) then begin: = TfrmPark. Create (nil);. Parent: = self;.
listFrames. AddItem (frmPark. ModuleName, frmPark);;( (pos (‘e’, Rules) > 0)
or (pos (‘a’, Rules) > 0)) then begin: = TfrmRequest. Create (nil);. Parent:
= self;. listFrames. AddItem (frmRequest. ModuleName, frmRequest);;( (pos (‘s’,
Rules) > 0) or (pos (‘a’, Rules) > 0)) then begin: = TfrmStore. Create
(nil);. Parent: = self;. listFrames. AddItem (frmStore. ModuleName,
frmStore);;pos (‘a’, Rules) > 0 then begin: = TfrmUsers. Create (nil);.
Parent: = self;. listFrames. AddItem (frmUsers. ModuleName, frmUsers);;

{else begin: = false;

MessageDlg (‘Ваша учетная запись не имеет прав в системе ‘ +
ProductName + #13 + ‘Обратитесь к администратору. ‘, mtError, [mbOK], 0);
};e: exception do begin: = false;(e. Message, mtError, [mbOK], 0);;;;TfrMain.
SelectFrame: boolean;: = true;

// Скрытие всех фреймовAssigned
(frmUsers) then frmUsers. Visible: = false;Assigned (frmPark) then frmPark.
Visible: = false;Assigned (frmRequest) then frmRequest. Visible: =
false;Assigned (frmStore) then frmStore. Visible: = false;frSelectFrame do
begin

// если инициализирован хотя бы 1 фрейм,

// установка курсора в списке фреймовlistFrames. Items. Count
> 0 then begin. ItemIndex: = 0;. Visible: = false;listFrames. Items. Count > 1 then
begin

// если фреймов несколько, показ окна выбора фрейма

btnChangeModul. Visible: = true;isPositiveResult
(ShowModal)

then lblMain. Caption: = »

// если отменили, выход

else begin. Caption: = ‘Выберите модуль’;: =
false;;;;

// отображение выбранного (или единственного) фреймаDM do
begin

// Вызывается переопределенный Initialize:

// Если соединение с необходимой БД неактивно, то модуль не отображается.

// Отображение происходит при последующем соединении с БД
(повторно вызывается SelectFrame)

if Initialize then begin. Caption: = ProductName
+ ‘ — ‘ + ModuleName + ‘ — ‘ + ‘ [‘ + User. Name + ‘] ‘;: = true;else
MessageDlg (‘Отсутствует соединение с БД, необходимой ‘#13’для работы модуля’, mtError,
[mbOK], 0);;;;;TfrMain. actSettingsDBExecute (Sender: TObject);(TfrDBState.
Create (nil)) do try

// Если произошло изменение подлючений БД, присходит закрытие

// модулей и отображение окна выбора модуля

if not IsPositiveResult
(ShowModal)SelectFrame;Free;;;TfrMain. actChangeModuleExecute (Sender:
TObject);;;TfrMain. actLogoutExecute (Sender: TObject);;;;TfrMain.
actAboutExecute (Sender: TObject);TfrAbout. Create (nil)
doShowmodalFree;;;TfrMain. actExitExecute (Sender: TObject);;;.

unit uFrmRequest;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,

Dialogs, uFrmPattern, PropFilerEh, PropStorageEh,
ImgList, ActnList,

ComCtrls, Grids, DBGridEh, ToolWin, ExtCtrls;=
class (TfrmPattern): TAction;: TAction;: TAction;: TPanel;: TSplitter;:
TDBGridEh;: TPanel;: TToolBar;: TToolButton;: TAction;: TAction;: TAction;:
TToolButton;: TToolButton;: TAction;: TPanel;: TPanel;: TToolBar;:
TToolButton;: TToolButton;: TToolButton;: TToolButton;: TDBGridEh;: TPanel;:
TSplitter;: TPanel;: TToolBar;: TToolButton;: TToolButton;: TToolButton;:
TDBGridEh;: TAction;: TAction;: TAction;actNewRequestExecute (Sender:
TObject);actEditRequestExecute (Sender: TObject);actDelRequestExecute (Sender:
TObject);actNewGoodsExecute (Sender: TObject);actEditGoodsExecute (Sender:
TObject);actDelGoodsExecute (Sender: TObject);actFilterRequestExecute (Sender:
TObject);actNewCPExecute (Sender: TObject);actEditCPExecute (Sender:
TObject);actDelCPExecute (Sender: TObject);

{ Private declarations }

{ Public declarations }Create (AOwner:
TComponent); override;Initialize: boolean; override;Finalize: boolean;
override;;: TfrmRequest;uDM, uConnect, uEditRequest, uEditReqGoods, DB,
uFilterRequest, uEditRoute;

{$R *. dfm}TfrmRequest. Create (AOwner:
TComponent);;: = ‘Офис’;;TfrmRequest. Initialize: boolean;dm. DBMain.
TestConnectedresult: = trueresult: = IsPositiveResult (ConnectTo (dm. dbMain, ‘Главная БД’));result
then begin. LoadProperties;DM do begin. Open;. FetchAll;. Open;. FetchAll;.
Open;. FetchAll;;;;TfrmRequest. Finalize: boolean;. SaveProperties;DM do
begintrnWriteMain. InTransaction then. Rollback;qRequest. Active then qCar.
Close;qReqGoods. Active then qReqGoods. Close;qRoute. Active then qRoute.
Close;;;TfrmRequest. actNewRequestExecute (Sender: TObject);TfrEditRequest.
Create (self) do try: = ‘Добавить заявку’;DM do begin.
UpdateTransaction. StartTransaction;qRequest do begin;. SQL. Text: = ‘select
tID,NAME from request_type’;. Open;. FetchAll;. First;. KeyValue: = qRead.
FieldByName (‘tID’). AsInteger;(‘COMPLETED’). AsInteger: = 0;isPositiveResult
(Showmodal) then beginclientID <> — 1 then FieldByName (‘CLIENT’).
AsInteger: = clientID;(‘USER_ADD’). AsInteger: = User. ID;FieldByName
(‘COMPLETED’). AsInteger = 1 then(‘USER_CLOSE’). AsInteger: = User.
ID;(‘request_type’). AsInteger: = cbRequestType. KeyValue;;.
UpdateTransaction.commit;else begin;. UpdateTransaction. Rollback;;.
Close;;;;Free;;TfrmRequest. actEditRequestExecute (Sender: TObject);complet: integer;not
DM. qRequest. IsEmpty thenTfrEditRequest. Create (self) do try: = ‘Изменить заявку’;DM do begin.
UpdateTransaction. StartTransaction;qRequest do begin;. SQL. Text: = ‘select
tID,NAME from request_type’;. Open;. FetchAll;. Text: = FieldByName (‘CLIENT_NAME’).
AsString;not FieldByName (‘CLIENT’). IsNull then: = FieldByName (‘CLIENT’).
AsInteger;: = FieldByName (‘COMPLETED’). AsInteger;isPositiveResult (Showmodal)
then beginclientID <> — 1 then FieldByName (‘CLIENT’). AsInteger: =
clientID;FieldByName (‘COMPLETED’). AsInteger <> complet
then(‘USER_CLOSE’). AsInteger: = User. ID;;. UpdateTransaction.commit;else
begin;. UpdateTransaction. Rollback;;. Close;;;;Free;;TfrmRequest.
actDelRequestExecute (Sender: TObject);DM do if not qRequest. IsEmpty then begin.
UpdateTransaction. StartTransaction;. Delete;.
UpdateTransaction.commit;;;TfrmRequest. actNewGoodsExecute (Sender: TObject);DM
do beginnot qRequest. IsEmpty thenTfrEditReqGoods. Create (self) do try: = ‘Добавить детализацию’;.
UpdateTransaction. StartTransaction;qReqGoods do begin;(‘CNT’). AsInteger: =
1;(‘WEIGHT’). AsInteger: = 0;isPositiveResult (Showmodal) then
begin(‘REQUEST’). AsInteger: = qRequest. FieldByName (‘rID’). AsInteger;;.
UpdateTransaction.commit;else begin;. UpdateTransaction. Rollback;;;Free;;;TfrmRequest.
actEditGoodsExecute (Sender: TObject);DM do beginnot qReqGoods. IsEmpty
thenTfrEditReqGoods. Create (self) do try: = ‘Изменить детализацию’;. UpdateTransaction.
StartTransaction;qReqGoods do begin;isPositiveResult (Showmodal) then begin;.
UpdateTransaction.commit;else begin;. UpdateTransaction.
Rollback;;;Free;;;TfrmRequest. actDelGoodsExecute (Sender: TObject);DM do if
not qReqGoods. IsEmpty then begin. UpdateTransaction. StartTransaction;.
Delete;. UpdateTransaction.commit;;;TfrmRequest. actNewCPExecute (Sender:
TObject);DM do beginnot qRequest. IsEmpty thenTfrEditRoute. Create (self) do
try: = ‘Добавить пункт маршрута’;.
UpdateTransaction. StartTransaction;qRoute do begin;. Checked: =
false;isPositiveResult (Showmodal) then begincbPassed. Checked then
begin(‘PASSED’). AsInteger: = 1;VarType (edtDate_pass. Value) <> varNull
then(‘DATE_PASS’). AsDateTime: = edtDate_pass. Value;FieldByName (‘PASSED’).
AsInteger: = 0;(‘REQUEST’). AsInteger: = qRequest. FieldByName (‘rID’). AsInteger;;.
UpdateTransaction.commit;else begin;. UpdateTransaction.
Rollback;;;;Free;;;TfrmRequest. actEditCPExecute (Sender: TObject);DM do
beginnot qRoute. IsEmpty thenTfrEditRoute. Create (self) do try: = ‘Изменить пункт маршрута’;.
UpdateTransaction. StartTransaction;qRoute do begin;FieldByName (‘PASSED’).
AsInteger = 1cbPassed. Checked: = truecbPassed. Checked: = false;not
FieldByName (‘DATE_PASS’). IsNull then_pass. Value: = FieldByName
(‘DATE_PASS’). AsVariant;isPositiveResult (Showmodal) then begincbPassed. Checked
then begin(‘PASSED’). AsInteger: = 1;VarType (edtDate_pass. Value) <>
varNull then(‘DATE_PASS’). AsDateTime: = edtDate_pass. Value;FieldByName
(‘PASSED’). AsInteger: = 0;;. UpdateTransaction.commit;else begin;.
UpdateTransaction. Rollback;;;;Free;;;TfrmRequest. actDelCPExecute (Sender:
TObject);DM do if not qRoute. IsEmpty then begin. UpdateTransaction.
StartTransaction;. Delete;. UpdateTransaction.commit;;;TfrmRequest.
actFilterRequestExecute (Sender: TObject);DM do

// with TfrFilterRequest. Create (self) do
tryfrFilterRequest do beginisPositiveResult (Showmodal) then begin. Close;.
SQL. LoadFromFile (ExtractFilePath (Application. ExeName) + ‘ResRequest.
Select. sql’);. SQL. Add (FilterSQL);. SQL. Add (‘ order by rID ‘);. Open;.
FetchAll;. Open;. FetchAll;else begin;;;.

unit uDM;

interface, SysUtils, Classes, DB,
IBCustomDataSet, IBQuery, IBDatabase, IBUpdateSQL,, PropStorageEh, PropFilerEh,
IniFiles, Dialogs;= record: integer;: string;: string;: string;;= class
(TDataModule): TIBDatabase;: TIBTransaction;: TIBTransaction;: TIBQuery;:
TIBQuery;: TDataSource;: TIBUpdateSQLW;: TIBQuery;: TIntegerField;:
TIBStringField;: TIBStringField;: TIBStringField;: TIBStringField;:
TDataSource;: TIniPropStorageManEh;: TIBDatabase;: TIBTransaction;:
TIBTransaction;: TIBTransaction;: TIBTransaction;: TIBDatabase;: TDataSource;:
TIBQuery;: TIntegerField;: TIBStringField;: TFloatField;_CNT: TIntegerField;:
TIntegerField;: TIBUpdateSQLW;: TIBQuery;: TIBUpdateSQLW;: TDataSource;:
TIBQuery;: TDataSource;: TIntegerField;: TIBStringField;: TIBStringField;:
TIntegerField;: TIBQuery;: TIntegerField;: TIBStringField;: TIBStringField;:
TIntegerField;: TIntegerField;: TIBStringField;: TIBQuery;: TDataSource;:
TIBUpdateSQLW;: TIBQuery;: TDataSource;: TIBUpdateSQLW;: TIntegerField;:
TIBStringField;_TYPE: TIntegerField;_ADD: TIntegerField;_CLOSE:
TIntegerField;_TYPE_NAME: TIBStringField;: TIntegerField;: TIntegerField;:
TIBQuery;: TDataSource;: TIBUpdateSQLW;: TIntegerField;_NAME: TIBStringField;:
TIntegerField;: TIntegerField;_NUM: TIBStringField;: TIBStringField;:
TFloatField;: TIntegerField;_NAME: TIBStringField;_NAME: TIBStringField;:
TIntegerField;_OLD: TIntegerField;: TIntegerField;: TIntegerField;:
TIntegerField;: TIBUpdateSQLW;: TDataSource;: TIntegerField;: TIntegerField;_NUM:
TIBStringField;: TIBStringField;: TIntegerField;: TIBStringField;:
TFloatField;: TIBQuery;: TIntegerField;: TIBStringField;_PASS: TDateTimeField;:
TIntegerField;: TIntegerField;DBMainAfterConnect (Sender:
TObject);DBMainBeforeDisconnect (Sender: TObject);DataModuleCreate (Sender:
TObject);DataModuleDestroy (Sender: TObject);DBParkAfterConnect (Sender:
TObject);dbParkBeforeDisconnect (Sender: TObject);qCarDriverAfterOpen (DataSet:
TDataSet);DBStoreAfterConnect (Sender: TObject);DBStoreBeforeDisconnect (Sender:
TObject);

{ Private declarations }: integer;LoadINIDB
(filename: string);SaveINIDB (filename: string);LoadINISQL;SaveINISQL
(filename: string);

{ Public declarations }: TUser;: string;;: TDM;

{$R *. dfm}uConstants;TDM. SaveINIDB (filename:
string);TIniFile. Create (filename) do try(iniDBMainSection, ‘DBName’, DBMain.
DatabaseName);(iniDBMainSection, ‘Param0’, DBMain. Params. Strings
[0]);(iniDBMainSection, ‘Param1’, DBMain. Params. Strings
[1]);(iniDBParkSection, ‘DBName’, DBPark. DatabaseName);(iniDBParkSection,
‘Param0’, DBPark. Params. Strings [0]);(iniDBParkSection, ‘Param1’, DBPark.
Params. Strings [1]);(iniDBStoreSection, ‘DBName’, DBStore.
DatabaseName);(iniDBStoreSection, ‘Param0’, DBStore. Params. Strings
[0]);(iniDBStoreSection, ‘Param1’, DBStore. Params. Strings [1]);;;e: Exception
do MessageDlg (‘Ошибка ini-файла: ‘ + e. Message, mtError, [mbOK], 0);;TDM. LoadINIDB
(filename: string);TIniFile. Create (filename) do try. DatabaseName: =
ReadString (iniDBMainSection, ‘DBName’, »);. Params. Strings [0]: = ReadString
(iniDBMainSection, ‘Param0’, »);. Params. Strings [1]: = ReadString
(iniDBMainSection, ‘Param1’, »);. DatabaseName: = ReadString
(iniDBParkSection, ‘DBName’, »);. Params. Strings [0]: = ReadString
(iniDBParkSection, ‘Param0’, »);. Params. Strings [1]: = ReadString
(iniDBParkSection, ‘Param1’, »);. DatabaseName: = ReadString
(iniDBStoreSection, ‘DBName’, »);. Params. Strings [0]: = ReadString
(iniDBStoreSection, ‘Param0’, »);. Params. Strings [1]: = ReadString
(iniDBStoreSection, ‘Param1’, »);;e: Exception do MessageDlg (‘Ошибка ini-файла: ‘ + e.
Message, mtError, [mbOK], 0);;TDM. SaveINISQL (filename: string);TIniFile.
Create (filename) do try;e: Exception do MessageDlg (‘Ошибка ini-файла: ‘ + e.
Message, mtError, [mbOK], 0);;TDM. LoadINISQL;AppFolder: string;: =
ExtractFilePath (Application. ExeName);. SQL. LoadFromFile (AppFolder +
‘ResRequest. Select. sql’);. SQL. Add (‘order by rID’);. RefreshSQL.
LoadFromFile (AppFolder + ‘ResRequest. Refresh. sql’);. SQL. LoadFromFile (AppFolder
+ ‘ResReqGoods. Select. sql’);. RefreshSQL. LoadFromFile (AppFolder +
‘ResReqGoods. Refresh. sql’);. SQL. LoadFromFile (AppFolder + ‘ResCar.
Select. sql’);. RefreshSQL. LoadFromFile (AppFolder + ‘ResCar. Refresh.
sql’);. SQL. LoadFromFile (AppFolder + ‘ResCarDriver. Select. sql’);. SQL.
LoadFromFile (AppFolder + ‘ResDriver. Select. sql’);. RefreshSQL.
LoadFromFile (AppFolder + ‘ResDriver. Refresh. sql’);. SQL. LoadFromFile
(AppFolder + ‘ResStoreGoods. Select. sql’);. SQL. Add (‘order by gID’);.
RefreshSQL. LoadFromFile (AppFolder + ‘ResStoreGoods. Refresh. sql’);;TDM.
DBMainAfterConnect (Sender: TObject);. StartTransaction;;TDM.
DBMainBeforeDisconnect (Sender: TObject);trnReadMain. InTransaction then
trnReadMain.commit;trnWriteMain. InTransaction then trnWriteMain.
Rollback;;TDM. DataModuleCreate (Sender: TObject);. IniFileName: =
ExtractFilePath (Application. ExeName) + iniControls;(ExtractFilePath
(Application. ExeName) + iniDB);;;TDM. DataModuleDestroy (Sender:
TObject);(ExtractFilePath (Application. ExeName) + iniDB);;TDM.
DBParkAfterConnect (Sender: TObject);. StartTransaction;;TDM.
dbParkBeforeDisconnect (Sender: TObject);trnReadPark. InTransaction then
trnReadPark.commit;trnWritePark. InTransaction then trnWritePark. Rollback;;TDM.
qCarDriverAfterOpen (DataSet: TDataSet);. FetchAll;;TDM. DBStoreAfterConnect
(Sender: TObject);. StartTransaction;;TDM. DBStoreBeforeDisconnect (Sender:
TObject);trnReadStore. InTransaction then trnReadStore.commit;trnWriteStore.
InTransaction then trnWriteStore. Rollback;;.

unit uFrmPark;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, uFrmPattern, ImgList, ActnList, ComCtrls, DB,
IBCustomDataSet,, IBUpdateSQLW, IBQuery, Grids, DBGridEh, ToolWin,,
PropStorageEh, ExtCtrls, uFrmDrivers, StdCtrls, DBCtrls;= class (TfrmPattern):
TAction;: TPageControl;: TTabSheet;: TToolBar;: TToolButton;: TDBGridEh;:
TToolButton;: TAction;: TAction;: TToolButton;: TPanel;: TAction;: TAction;:
TTabSheet;: TDBGridEh;: TSplitter;: TToolBar;: TToolButton;: TToolButton;:
TPanel;: TPanel;: TSplitter;: TAction;: TPanel;: TPanel;: TGroupBox;: TLabel;:
TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;:
TLabel;: TButton;actNewCarExecute (Sender: TObject);actEditCarExecute (Sender:
TObject);actDelCarExecute (Sender: TObject);actRemoveDriverExecute (Sender:
TObject);actAssignDriverExecute (Sender: TObject);tabDriversShow (Sender:
TObject);actUpdateReqStateExecute (Sender: TObject);

{ Private declarations }

{ Public declarations }Create (AOwner:
TComponent); override;Initialize: boolean; override;Finalize: boolean;
override;;: TfrmPark;: TfrmDrivers;uDM, uConnect, uEditCar, uAssignDriver;

{$R *. dfm}TfrmPark. Create (AOwner:
TComponent);;: = ‘Автопарк’;;CarAfterScroll;frmPark do begin. Caption: =
dm. qCar. fieldByName (‘cID’). AsString;. Caption: = »;. Caption: = »;.
Caption: = »;. Caption: = »;;;TfrmPark. Initialize: boolean;dm. DBPark.
TestConnectedresult: = trueresult: = IsPositiveResult (ConnectTo (dm. dbPark, ‘БД Автопарк’));result
then begin

@dm. qCar. AfterScroll: = @CarAfterScroll;: =
TfrmDrivers. Create (nil);. Parent: = tabDrivers;. Visible: = true;: =
frmDrivers. Initialize;result then begin. LoadProperties;DM do begin. Open;.
FetchAll;. Open;. FetchAll;;;;;TfrmPark. Finalize: boolean;. SaveProperties;DM
do begintrnWritePark. InTransaction then. Rollback;qCar. Active then qCar.
Close;qCarDriver. Active then qCarDriver. Close;qDriver. Active then qDriver.
Close;;Assigned (frmDrivers) then begin. Finalize;. Free;: = nil;;;TfrmPark.
actNewCarExecute (Sender: TObject);TfrEditCar. Create (self) do try: = ‘Добавить автомашину’;DM do begin.
UpdateTransaction. StartTransaction;qCar do begin;. Text: = ‘0’;_cnt. Text: =
‘0’;isPositiveResult (Showmodal) then begin;. UpdateTransaction.commit;else
begin;. UpdateTransaction. Rollback;;;;Free;;TfrmPark. actEditCarExecute
(Sender: TObject);not dm. qCar. IsEmpty thenTfrEditCar. Create (self) do try: =
‘Изменить автомашину’;DM do begin.
UpdateTransaction. StartTransaction;qCar do begin;isPositiveResult (Showmodal)
then begin;. UpdateTransaction.commit;else begin;. UpdateTransaction.
Rollback;;;;Free;;TfrmPark. actRemoveDriverExecute (Sender: TObject);DM do if
not qCarDriver. IsEmpty then begin. Transaction. StartTransaction;qWritepark do
begin. Text: = ‘update driver set driver. CAR = NULL where dID =: dID’;(‘dID’).
AsInteger: = qCarDriver. FieldByName (‘dID’). AsInteger;;;.
Transaction.commit;. Close;. Open;;;TfrmPark. actAssignDriverExecute (Sender:
TObject);TfrAssignDriver. Create (self) do tryDM do beginqCar do
beginisPositiveResult (Showmodal) and (dID <> 0) then begin. Transaction.
StartTransaction;qWritePark do begin. Text: = ‘update driver set driver. CAR =:
CAR where DID =: DID’;(‘dID’). AsInteger: = dID;(‘CAR’). AsInteger: = qCar.
FieldByName (‘cID’). AsInteger;;;. Transaction.commit;. Close;.
Open;;;;Free;;TfrmPark. actDelCarExecute (Sender: TObject);DM do if not qCar.
IsEmpty then begin. UpdateTransaction. StartTransaction;. Delete;.
UpdateTransaction.commit;;;TfrmPark. tabDriversShow (Sender: TObject);DM do
begin. Close;. Open;;;TfrmPark. actUpdateReqStateExecute (Sender: TObject);dm.
DBMain. TestConnected or IsPositiveResult (ConnectTo (dm. dbMain, ‘Главная БД’))DM. qRead
do begin. LoadFromFile (ExtractFilePath (Application. ExeName) + ‘ResCar.
Request. sql’);(‘RID’). AsInteger: = dm. qCar. FieldByName (‘request’).
AsInteger;;. Caption: = dm. qCar. FieldByName (‘CID’). AsString;. Caption: =
FieldByName (‘rID’). AsString;. Caption: = FieldByName (‘client_name’).
AsString;. Caption: = FieldByName (‘request_type_name’). AsString;not
FieldByName (‘completed’). IsNull thenFieldByName (‘completed’). AsInteger =
0txReqCompleted. Caption: = ‘Не выполнена’txReqCompleted.
Caption: = ‘Выполнена’;;

endMessageDlg (‘Отсутствует соединение с БД, необходимой
‘#13’для работы модуля’, mtError, [mbOK], 0);

end;.

unit uFrmUsers;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, uFrmPattern, ImgList, ActnList, ComCtrls, StdCtrls,
ExtCtrls,, DBGridEh, ToolWin, PropFilerEh, PropStorageEh, DB, DBGrids;= class
(TfrmPattern): TDBGridEh;: TPanel;: TLabel;: TLabel;: TToolBar;: TToolButton;:
TToolButton;: TToolButton;: TAction;: TAction;: TAction;: TAction;: TAction;:
TLabel;: TLabel;: TLabel;: TPanel;: TDataSource;actNewUserExecute (Sender:
TObject);actEditUserExecute (Sender: TObject);actDelUserExecute (Sender:
TObject);actSaveUserExecute (Sender: TObject);actCancelUserExecute (Sender:
TObject);

{ Private declarations }

{ Public declarations }

{ModuleName: string;: integer; }Create (AOwner:
TComponent); override;Initialize: boolean; override;Finalize: boolean;
override;;: TFrmUsers;uDM, uSettings, uConstants, uConnect, uEditUsers;

{$R *. dfm}TFrmUsers. Create (AOwner:
TComponent);;: = ‘Пользователи’;;TFrmUsers. Initialize: boolean;dm. DBMain.
TestConnectedresult: = trueresult: = IsPositiveResult (ConnectTo (dm. DBMain, ‘Главная БД’));result
then begin. LoadProperties;DM do begin. Open;. FetchAll;;;;TFrmUsers. Finalize:
boolean;. SaveProperties;DM do begintrnWriteMain. InTransaction then.
Rollback;qUsers. Active then qUsers. Close;;;TFrmUsers. actNewUserExecute
(Sender: TObject);uID: integer;DM doTfrEditUsers. Create (self) do try: = ‘Добавить пользователя’;isPositiveResult
(Showmodal) then begin. StartTransaction;qWrite do begin. Text: = ‘select *
from users_insert (: pass,: rules,: name,: login) ‘;(‘name’). AsString: =
edtName. Text;(‘rules’). AsString: = edtRules. Text;(‘pass’). AsString: =
edtPass. Text;(‘login’). AsString: = edtLogin. Text;;: = FieldByName (‘uID’).
AsInteger;;;.commit;qUsers do begin;;;(‘uID’,uID, []);;;;Free;;TFrmUsers.
actEditUserExecute (Sender: TObject);uID: integer;DM doTfrEditUsers. Create
(self) do try: = ‘Изменить пользователя’;qUsers do
begin. Text: = FieldByName (‘name’). AsString;. Text: = FieldByName (‘rules’).
AsString;. Text: = FieldByName (‘pass’). AsString;. Text: = FieldByName
(‘login’). AsString;AnsiUpperCase (FieldByName (‘login’). AsString) =
‘ADMIN’begin. Enabled: = false;. Enabled: = false;;;isPositiveResult
(Showmodal) then begin. StartTransaction;qWrite do begin. Text: = ‘execute
procedure users_update (: rules,: pass,: name,: uid,: login) ‘;(‘uid’).
AsInteger: = qUsers. FieldByName (‘uID’). AsInteger;(‘name’). AsString: =
edtName. Text;(‘rules’). AsString: = edtRules. Text;(‘pass’). AsString: = edtPass.
Text;(‘login’). AsString: = edtLogin. Text;;;.commit;qUsers do begin: =
FieldByName (‘uID’). AsInteger;;;;(‘uID’,uID, []);;;;Free;;TFrmUsers.
actDelUserExecute (Sender: TObject);uID: integer;DM do if not qUsers. IsEmpty
then beginAnsiUpperCase (qUsers. FieldByName (‘login’). AsString) <>
‘ADMIN’ then begin. StartTransaction;qWrite do begin. Text: = ‘execute
procedure users_delete (: uid) ‘;(‘uid’). AsInteger: = qUsers. FieldByName
(‘uID’). AsInteger;;;.commit;qUsers do begin: = FieldByName (‘uID’). AsInteger;;;;(‘uID’,uID,
[]);

EnableControls;;else MessageDlg (‘Невозможно удалить запись
администратора! ‘, mtError, [mbOK], 0);;;TFrmUsers. actSaveUserExecute
(Sender: TObject);fID: integer;DM doqUsers dotrnWriteMain. InTransaction then
beginModified then qUsers. Post;: = FieldByName (‘uID’).
AsInteger;.commit;;;;(‘uID’,fID, []);;;;TFrmUsers. actCancelUserExecute
(Sender: TObject);fID: integer;DM doqUsers dotrnWriteMain. InTransaction then
beginModified then CancelUpdates;: = FieldByName (‘uID’). AsInteger;.
Rollback;;;;(‘uID’,fID, []);;;;.

unit uSettings;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, PropFilerEh, PropStorageEh, ExtCtrls,
iniFiles;= class (TForm): TGroupBox;: TComboBox;: TLabel;: TLabel;: TEdit;:
TLabel;: TEdit;: TEdit;: TLabel;: TPanel;: TButton;: TButton;: TButton;:
TOpenDialog;FormShow (Sender: TObject);cmdConnectionChange (Sender:
TObject);btnLocateDbClick (Sender: TObject);FormCloseQuery (Sender: TObject;
var CanClose: Boolean);FormClose (Sender: TObject; var Action: TCloseAction);

{ Private declarations }: string;

{ Public declarations }: string;, iniSection:
string;SaveINI (filename, section: string);LoadINI (filename, section:
string);;: TfrSettings;uDM;

{$R *. dfm}isInt (str: string): boolean;: =
true;(str);E: EConvertError do result: = false;;;TfrSettings. SaveINI
(filename, section: string);TIniFile. Create (filename) do try(section,
‘cmdConnectionIndex’, cmdConnection. ItemIndex);(section, ‘labelIPVisible’,
labelIP. Visible);(section, ‘labelPortVisible’, labelPort. Visible);(section,
‘edtIPVisible’, edtIP. Visible);(section, ‘edtPortVisible’, edtPort.
Visible);(section, ‘edtIP’, edtIP. Text);(section, ‘edtPort’, edtPort.
Text);(section, ‘edtDB’, edtDB. Text);;;e: Exception do MessageDlg (‘Ошибка ini-файла: ‘ + e.
Message, mtError, [mbOK], 0);;TfrSettings. LoadINI (filename, section:
string);TIniFile. Create (filename) do try. ItemIndex: = ReadInteger (section,
‘cmdConnectionIndex’, 0);. Visible: = ReadBool (section, ‘edtIPVisible’, true);.
Visible: = ReadBool (section, ‘edtPortVisible’, true);. Visible: = ReadBool
(section, ‘edtIPVisible’, true);. Visible: = ReadBool (section,
‘edtPortVisible’, true);. Text: = ReadString (section, ‘edtIP’, »);. Text: =
ReadString (section, ‘edtPort’, »);. Text: = ReadString (section, ‘edtDB’,
»);;e: Exception do MessageDlg (‘Ошибка ini-файла: ‘ + e. Message, mtError, [mbOK],
0);;TfrSettings. FormShow (Sender: TObject);

begin

// к этому моменту должны быть заданы iniFilename, iniSection

LoadINI (iniFilename, iniSection);cmdConnection.
ItemIndex = 0ConnectionString: = edtDB. Text // Локальное подключениеConnectionString: =
edtIP. Text + ‘/ ‘ + edtPort. Text + ‘: ‘ + edtDB. Text; // Удаленное: =
ConnectionString;;TfrSettings. cmdConnectionChange (Sender: TObject);(sender as
TComboBox). ItemIndex = 0 then begin. Visible: = false;. Visible: = false;.
Visible: = false;. Visible: = false;: = edtDB. Text;. Visible: = true;begin.
Visible: = true;. Visible: = true;. Visible: = true;. Visible: = true;.
Visible: = false;: = edtIP. Text + ‘/ ‘ + edtPort. Text + ‘: ‘ + edtDB.
Text;;;TfrSettings. btnLocateDbClick (Sender: TObject);dlgLocateDb. Execute and
(dlgLocateDb. FileName <> ») then. Text: = dlgLocateDb.
FileName;;TfrSettings. FormCloseQuery (Sender: TObject;CanClose:
Boolean);ModalResult = mrOK then begin: = false;(cmdConnection. ItemIndex = 1)
and (length (edtIP. Text) = 0)MessageDlg (‘Ошибка ввода’#13’Поле «IP-адрес сервера» не может быть пустым’, mtError,
[mbOK], 0)(cmdConnection. ItemIndex = 1) and (length (edtPort. Text) =
0)MessageDlg (‘Ошибка ввода’#13’Поле «Порт» не может быть пустым’, mtError,
[mbOK], 0)length (edtDB. Text) = 0MessageDlg (‘Ошибка ввода’#13’Поле «Путь к файлу БД» не может быть пустым’, mtError,
[mbOK], 0)begin. InitialDir: = ExtractFilePath (dlgLocateDb.
FileName);(iniFilename, iniSection);cmdConnection. ItemIndex =
0ConnectionString: = edtDB. TextConnectionString: = edtIP. Text + ‘/ ‘ +
edtPort. Text + ‘: ‘ + edtDB. Text;: = true;;;;TfrSettings. FormClose (Sender:
TObject; var Action: TCloseAction);ConnectionString =
ConnectionStringLastModalResult: = mrCancel;;.

unit uDBState;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls, IBDAtabase;= class (TForm):
TPanel;: TButton;: TGroupBox;: TLabel;: TButton;: TButton;: TButton;: TLabel;:
TGroupBox;

Label2: TLabel;: TLabel;: TButton;

btnConnectDBPark: TButton;: TButton;: TGroupBox;:
TLabel;: TButton;: TButton;: TButton;: TLabel;btnDBMainClick (Sender:
TObject);FormShow (Sender: TObject);btnDBParkClick (Sender:
TObject);btnDBStoreClick (Sender: TObject);btnConnectDBMainClick (Sender:
TObject);btnConnectDBParkClick (Sender: TObject);btnConnectDBStoreClick
(Sender: TObject);btnDct1Click (Sender: TObject);btnDct2Click (Sender:
TObject);btnDct3Click (Sender: TObject);FormClose (Sender: TObject; var Action:
TCloseAction);

{ Private declarations }:
boolean;TestConnected;TryConnect (DB: TIBDatabase; FormCaption: string);

{ Public declarations };: TfrDBState;uDM,
uSettings, uConstants, UConnect;

{$R *. dfm}TfrDBState. TryConnect (DB:
TIBDatabase; FormCaption: string);(DB, FormCaption);;: = true;;TfrDBState.
TestConnected;DM do beginDBMain. TestConnected then begin. Font. Color: =
clGreen;. Caption: = ‘Активно’;else begin. Font. Color: = clRed;. Caption: = ‘Неактивно’;;DBPark.
TestConnected then begin. Font. Color: = clGreen;. Caption: = ‘Активно’;else begin.
Font. Color: = clRed;. Caption: = ‘Неактивно’;;DBStore. TestConnected
then begin. Font. Color: = clGreen;. Caption: = ‘Активно’;else begin. Font.
Color: = clRed;. Caption: = ‘Неактивно’;;;;TfrDBState. FormShow (Sender: TObject);;: =
false;;TfrDBState. btnDBMainClick (Sender: TObject);cs: string;(TfrSettings.
Create (nil)) do try: = ExtractFilePath (Application. ExeName) + iniDB;: =
iniDBMainSection;isPositiveResult (ShowModal) then begindm. DBMain.
TestConnected then begin. DBMain. Close;;;. DBMain. DatabaseName: =
ConnectionString;;Free;;;TfrDBState. btnDBParkClick (Sender:
TObject);(TfrSettings. Create (nil)) do try: = ExtractFilePath (Application.
ExeName) + iniDB;: = iniDBParkSection;isPositiveResult (ShowModal) then
begindm. DBPark. TestConnected then begin. DBPark. Close;;;. DBPark.
DatabaseName: = ConnectionString;;Free;;;TfrDBState. btnDBStoreClick (Sender:
TObject);(TfrSettings. Create (nil)) do try: = ExtractFilePath (Application.
ExeName) + iniDB;: = iniDBStoreSection;isPositiveResult (ShowModal) then
begindm. DBStore. TestConnected then begin. DBStore. Close;;;. DBStore.
DatabaseName: = ConnectionString;;Free;;;TfrDBState. btnConnectDBMainClick
(Sender: TObject);(dm. DBMain, ‘Главная БД’);;TfrDBState. btnConnectDBParkClick (Sender: TObject);(dm.
DBPark, ‘БД Автопарк’);;TfrDBState.
btnConnectDBStoreClick (Sender: TObject);(dm. DBStore, ‘БД Склад’);;TfrDBState.
btnDct1Click (Sender: TObject);dm. DBMain. TestConnected then begin. DBMain.
Connected: = false;;: = true;;;TfrDBState. btnDct2Click (Sender: TObject);dm.
DBPark. TestConnected then begin. DBPark. Connected: = false;;: =
true;;;TfrDBState. btnDct3Click (Sender: TObject);dm. DBStore. TestConnected
then begin. DBStore. Connected: = false;;: = true;;;TfrDBState. FormClose
(Sender: TObject; var Action: TCloseAction);modified then ModalResult: =
mrCancel else ModalResult: = mrOk;;.

unit uFrmStore;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,

Dialogs, uFrmPattern, PropFilerEh, PropStorageEh,
ImgList, ActnList,

ComCtrls, Grids, DBGridEh, ExtCtrls, ToolWin;=
class (TfrmPattern): TDBGridEh;: TToolBar;: TToolButton;: TAction;: TAction;:
TAction;: TPanel;: TToolButton;: TToolButton;: TAction;:
TToolButton;actNewGoodsExecute (Sender: TObject);actDelGoodsExecute (Sender:
TObject);actEditGoodsExecute (Sender: TObject);actFilterGoodsExecute (Sender:
TObject);

{ Private declarations }

{ Public declarations }Create (AOwner: TComponent);
override;Initialize: boolean; override;Finalize: boolean; override;;:
TfrmStore;uDM, uConnect, uEditStoreGoods, uFilterStoreGoods;

{$R *. dfm}TfrmStore. Create (AOwner:
TComponent);;: = ‘Склад’;;TfrmStore. Initialize: boolean;dm. DBStore. TestConnectedresult:
= trueresult: = IsPositiveResult (ConnectTo (dm. DBStore, ‘БД Склад’));result
then begin. LoadProperties;DM do begin. Open;. FetchAll;;;;TfrmStore. Finalize:
boolean;. SaveProperties;DM do begintrnWriteStore. InTransaction then.
Rollback;qStoreGoods. Active then qStoreGoods. Close;;;TfrmStore.
actNewGoodsExecute (Sender: TObject);TfrEditStoreGoods. Create (self) do try: =
‘Добавить товар’;DM do begin.
UpdateTransaction. StartTransaction;qStoreGoods do begin;(‘IS_OLD’). AsInteger:
= 0;(‘CNT’). AsInteger: = 1;isPositiveResult (Showmodal) then beginclientID
<> — 1 then FieldByName (‘CLIENT’). AsInteger: = clientID;;.
UpdateTransaction.commit;else begin;. UpdateTransaction.
Rollback;;;;;Free;;TfrmStore. actEditGoodsExecute (Sender: TObject);not dm.
qStoreGoods. IsEmpty thenTfrEditStoreGoods. Create (self) do try: = ‘Добавить товар’;DM do begin.
UpdateTransaction. StartTransaction;qStoreGoods do begin;. Text: = FieldByName
(‘CLIENT_NAME’). AsString;not FieldByName (‘CLIENT’). IsNull then: = FieldByName
(‘CLIENT’). AsInteger;isPositiveResult (Showmodal) then beginclientID <>
— 1 then FieldByName (‘CLIENT’). AsInteger: = clientID;;.
UpdateTransaction.commit;else begin;. UpdateTransaction.
Rollback;;;;;Free;;TfrmStore. actFilterGoodsExecute (Sender: TObject);DM
doftFilterStoreGoods do beginisPositiveResult (Showmodal) then begin. Close;.
SQL. LoadFromFile (ExtractFilePath (Application. ExeName) + ‘ResStoreGoods.
Select. sql’);. SQL. Add (FilterSQL);. SQL. Add (‘ order by gID ‘);. Open;.
FetchAll;else begin;;;TfrmStore. actDelGoodsExecute (Sender: TObject);DM do if
not qStoreGoods. IsEmpty then begin. UpdateTransaction. StartTransaction;.
Delete;. UpdateTransaction.commit;;;.

unit uFrmClient;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,

Dialogs, uFrmPattern, PropFilerEh, PropStorageEh,
ImgList, ActnList,, IBCustomDataSet, IBUpdateSQL, IBUpdateSQLW, DB, IBQuery,
Grids,

DBGridEh, IBDatabase, ActnMan, ActnColorMaps,
ToolWin, ExtCtrls;= class (TfrmPattern): TDBGridEh;: TDataSource;: TIBQuery;:
TIBUpdateSQLW;: TIBStringField;: TIBStringField;: TToolBar;: TToolButton;:
TIBTransaction;: TAction;: TAction;: TAction;: TIntegerField;: TToolButton;:
TToolButton;: TPanel;actNewClientExecute (Sender: TObject);ectEditClientExecute
(Sender: TObject);actDelClientExecute (Sender: TObject);

{ Private declarations }: TIBDatabase;Create
(AOwner: TComponent); override;Initialize: boolean; override;Finalize: boolean;
override;;uDM, uConnect, uEditClient;

{$R *. dfm}TfrmClient. Create (AOwner: TComponent);;:
= ‘Склад’;;TfrmClient.
Initialize: boolean;

// К этому моменту свойство DB должно быть заданоDB.
TestConnectedresult: = trueresult: = IsPositiveResult (ConnectTo (DB, ‘База данных’));result
then begin. LoadProperties;DM do begin. DefaultDatabase: = DB; // Пишущая транзакция. Transaction:
= DB. DefaultTransaction; // Читающая транзакция. Database: = DB;. Open;. FetchAll;;;;TfrmClient.
Finalize: boolean;. SaveProperties;DM do begintrnWriteClient. InTransaction
then. Rollback;qClient. Active then qClient. Close;;;TfrmClient.
actNewClientExecute (Sender: TObject);TfrEditClient. Create (self) do try: = ‘Добавить клиента’;.
UpdateTransaction. StartTransaction;qClient do begin;. Text: = »;. Text: =
»;isPositiveResult (Showmodal) then begin(‘NAME’). AsString: = edtName.
Text;(‘DETAIL’). AsString: = edtDetail. Text;;. UpdateTransaction.commit;else
begin;. UpdateTransaction. Rollback;;;Free;;TfrmClient. ectEditClientExecute
(Sender: TObject);not qClient. IsEmpty thenTfrEditClient. Create (self) do try:
= ‘Изменить клиента’;.
UpdateTransaction. StartTransaction;qClient do begin;. Text: = FieldByName
(‘NAME’). AsString;. Text: = FieldByName (‘DETAIL’). AsString;isPositiveResult
(Showmodal) then begin(‘NAME’). AsString: = edtName. Text;(‘DETAIL’). AsString:
= edtDetail. Text;;. UpdateTransaction.commit;else begin;. UpdateTransaction.
Rollback;;;Free;;TfrmClient. actDelClientExecute (Sender: TObject);not qClient.
IsEmpty then begin. UpdateTransaction. StartTransaction;. Delete;.
UpdateTransaction.commit;;;.

unit uFrmDrivers;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,

Dialogs, uFrmPattern, PropFilerEh, PropStorageEh,
ImgList, ActnList,

ComCtrls, Grids, DBGridEh, ToolWin, ExtCtrls;=
class (TfrmPattern): TToolBar;: TToolButton;: TToolButton;: TToolButton;:
TDBGridEh;: TAction;: TAction;: TAction;: TPanel;actNewDriverExecute (Sender:
TObject);actEditDriverExecute (Sender: TObject);actDelDriverExecute (Sender:
TObject);

{ Private declarations }

{ Public declarations }Create (AOwner:
TComponent); override;Initialize: boolean; override;Finalize: boolean;
override;;uDM, uEditDriver;

{$R *. dfm}TfrmDrivers. Create (AOwner:
TComponent);;: = ‘Водители’;;TfrmDrivers. Initialize: boolean;dm. DBPark.
TestConnected then begin. LoadProperties;DM do beginqDriver. Active then
qDriver. Close;. Open;. FetchAll;;: = trueresult: = false;;TfrmDrivers.
Finalize: boolean;. SaveProperties;;TfrmDrivers. actNewDriverExecute (Sender:
TObject);TfrEditDriver. Create (self) do try: = ‘Добавить водителя’;DM do begin. UpdateTransaction.
StartTransaction;qDriver do begin;isPositiveResult (Showmodal) then begin;.
UpdateTransaction.commit;else begin;. UpdateTransaction.
Rollback;;;;Free;;TfrmDrivers. actEditDriverExecute (Sender: TObject);not dm.
qDriver. IsEmpty thenTfrEditDriver. Create (self) do try: = ‘Изменить водителя’;DM do begin.
UpdateTransaction. StartTransaction;qDriver do begin;isPositiveResult
(Showmodal) then begin;. UpdateTransaction.commit;else begin;.
UpdateTransaction. Rollback;;;;Free;;TfrmDrivers. actDelDriverExecute (Sender:
TObject);DM do if not qDriver. IsEmpty then begin. UpdateTransaction.
StartTransaction;. Delete;. UpdateTransaction.commit;;;.

unit uConnect;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls, IBDatabase;= 10;= 3;= class
(TForm): TButton;: TLabel;: TTimer;: TLabel;TimerTimer (Sender:
TObject);FormShow (Sender: TObject);FormClose (Sender: TObject; var Action:
TCloseAction);

{ Private declarations }: string;: TIBDatabase;TryConnect:
boolean;

{ Public declarations };: TfrConnect;: integer;:
boolean;ConnectTo (DB: TIBDatabase; FormCaption: string): integer;

{$R *. dfm}uDM;ConnectTo (DB: TIBDatabase;
FormCaption: string): integer;(TfrConnect. Create (nil)) do try: = db;: =
FormCaption;: = ShowModal;Free;;;TfrConnect. TryConnect;t: integer;: =
false;fDB. Connected then begin. CloseDataSets;. Connected: = false;;.
Connected: = true;fDB. TestConnected then: = true;E: Exception do begin.
Caption: = ‘Ошибка подключения’; // + e.
Message;: = false;;;;TfrConnect. TimerTimer (Sender: TObject);. Caption: =
»;(i);(i = 0) then beginClosingModalResult: = mrOKbegin. Caption: = ‘Подключение. ‘;

Update;TryConnect then begin

// Подключение успешно, отсчет до закрытия окна. Caption: = ‘Подключение
установлено’;;

btnCancel. ModalResult: = mrOK;. Caption: = ‘Закрыть [‘ + inttostr
(WaitClose) +’] ‘;: = WaitClose;: = true;begin. Caption: = ‘Ошибка подключения’;;

i: = WaitConnect; // Ошибка подключения, сброс таймера

end;;// i <> 0, отсчетClosingbtnCancel.
Caption: = ‘Закрыть [‘ + inttostr
(i) + ‘] ‘t2. Caption: = ‘Повтор через ‘ + inttostr
(i) + ‘ секунд’;;TfrConnect.
FormShow (Sender: TObject);: = 1;. ModalResult: = mrCancel;. Caption: = ‘Отмена’;. Caption: =
‘Подключение. ‘;. Caption:
= »;: = false;. Enabled: = true;;TfrConnect. FormClose (Sender: TObject; var
Action: TCloseAction);. Enabled: = false;;.

unit uFilterRequest;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls, DBCtrls;= class (TForm):
TPanel;: TButton;: TButton;: TLabel;: TEdit;: TLabel;: TCheckBox;:
TComboBox;FormClose (Sender: TObject; var Action: TCloseAction);FormShow
(Sender: TObject);

{ Private declarations }MakeFilter: boolean;

{ Public declarations }: string;;: TfrFilterRequest;uDM;

{$R *. dfm}TfrFilterRequest. MakeFilter:
boolean;: = false;: = »;length (edtName. Text) > 0 then: = FilterSQL + ‘
(UPPER (c. name) LIKE »%’ + AnsiUpperCase (edtName. Text) + ‘%») and
‘;Integer (cbRequestType. Items. Objects [cbRequestType. ItemIndex]) <> 0
then: = FilterSQL + ‘ (r. request_type = ‘ + inttostr (Integer (cbRequestType.
Items. Objects [cbRequestType. ItemIndex])) + ‘) and ‘;not (cbCompleted. State
= cbGrayed) thencbCompleted. CheckedFilterSQL: = FilterSQL + ‘ (r.completed =
1) and ‘FilterSQL: = FilterSQL + ‘ (r.completed = 0) and ‘;length (FilterSQL)
> 0 then begin: = ‘ where ‘ + FilterSQL;(FilterSQL, length (FilterSQL) —
4);;;TfrFilterRequest. FormClose (Sender: TObject;Action:
TCloseAction);;;TfrFilterRequest. FormShow (Sender: TObject);.
SetFocus;cbRequestType. Items. Count = 0 then begin. Clear;. AddItem (‘Нет’, nil);.
ItemIndex: = 0;dm. DBMain. TestConnected thenDM. qRead do begin. Text: =
‘select tID,NAME from request_type’;;;;not EOF do begin. AddItem (FieldByName
(‘NAME’). AsString, pointer (FieldByName (‘tID’). AsInteger));;;;MessageDlg (‘Отсутствует соединение с БД, необходимой ‘#13’для работы модуля’, mtError,
[mbOK], 0);;;.

unit uEditStoreGoods;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, Mask, DBCtrlsEh, ExtCtrls, DBCtrls;=
class (TForm): TPanel;: TButton;: TButton;: TGroupBox;: TLabel;: TLabel;:
TLabel;: TLabel;: TLabel;: TDBEditEh;: TDBEditEh;: TDBEditEh;: TDBEditEh;:
TDBEditEh;: TGroupBox;: TEdit;: TButton;_OLD: TDBCheckBox;: TLabel;:
TDBEditEh;: TGroupBox;

Label7: TLabel;: TDBEditEh;: TLabel;

edtShelf: TDBEditEh;btnAssignClientClick (Sender:
TObject);FormCreate (Sender: TObject);FormCloseQuery (Sender: TObject; var
CanClose: Boolean);

{ Private declarations }

{ Public declarations }: integer;;:
TfrEditStoreGoods;uDM, uAssignClient, uConstants;

{$R *. dfm}TfrEditStoreGoods.
btnAssignClientClick (Sender: TObject);TfrAssignClient. Create (self) do try: =
dm. DBStore;isPositiveResult (Showmodal) then begin: = cID;. Text: =
cNAME;;Free;;TfrEditStoreGoods. FormCreate (Sender: TObject);: = —
1;;TfrEditStoreGoods. FormCloseQuery (Sender: TObject;CanClose: Boolean);: =
true;(ModalResult = mrOK) then begin(length (edtName. Text) = 0) then begin

MessageDlg (‘Поле «Наименование» не может быть
пустым! ‘, mtError, [mbOK], 0);: = false;else(not IsInt (edtCnt. Text)) then begin(‘Поле
«Количество» должно содержать целое числовое значение’, mtError,
[mbOK], 0);

CanClose: = false;;;;.

unit uFilterStoreGoods;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls;= class (TForm): TPanel;:
TButton;: TButton;: TLabel;: TEdit;: TLabel;_OLD: TCheckBox;: TEdit;: TLabel;:
TEdit;FormShow (Sender: TObject);FormClose (Sender: TObject; var Action: TCloseAction);

{ Private declarations }MakeFilter: boolean;

{ Public declarations }: string;;:
TftFilterStoreGoods;

{$R *. dfm}TftFilterStoreGoods. MakeFilter:
boolean;: = false;: = »;length (edtName. Text) > 0 then: = FilterSQL + ‘
(UPPER (g. name) LIKE »%’ + AnsiUpperCase (edtName. Text) + ‘%») and ‘;length
(edtRequest. Text) > 0 then: = FilterSQL + ‘ (g. request = ‘ + AnsiUpperCase
(edtRequest. Text) + ‘) and ‘;length (edtClient. Text) > 0 then: = FilterSQL
+ ‘ (UPPER (c. name) LIKE »%’ + AnsiUpperCase (edtClient. Text) + ‘%») and
‘;not (cbIS_OLD. State = cbGrayed) thencbIS_OLD. CheckedFilterSQL: = FilterSQL
+ ‘ (g. is_old = 1) and ‘FilterSQL: = FilterSQL + ‘ (g. is_old = 0) and
‘;length (FilterSQL) > 0 then begin: = ‘ where ‘ + FilterSQL;(FilterSQL,
length (FilterSQL) — 4);;;TftFilterStoreGoods. FormShow (Sender: TObject);.
SetFocus;;TftFilterStoreGoods. FormClose (Sender: TObject;Action:
TCloseAction);;;.

unit uAssignClient;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls, IBDatabase;= class (TForm):
TPanel;: TButton;: TButton;FormShow (Sender: TObject);FormClose (Sender:
TObject; var Action: TCloseAction);

{ Private declarations }

{ Public declarations }: TIBDatabase;: integer;:
string;;: TfrAssignClient;

{$R *. dfm}ufrmClient, DB;frmClient:
TfrmClient;TfrAssignClient. FormShow (Sender: TObject);

begin

// свойство DB должно быть уже задано

cID: = 0;: = TfrmClient. Create (nil);. Parent: =
self;. DB: = DB;frmClient. Initializebegin. Visible: = true;. gridClient.
SetFocus;

endbegin(‘Отсутствует соединение с БД, необходимой ‘#13’для
работы модуля’, mtError, [mbOK], 0);

Close;;;TfrAssignClient. FormClose (Sender:
TObject;Action: TCloseAction);frmClient do if qClient. Active then begin: =
qClient. FieldByName (‘cID’). AsInteger;: = qClient. FieldByName (‘NAME’).
AsString;updClient. UpdateTransaction. InTransaction then. UpdateTransaction.
Rollback;. Close;;Assigned (frmClient) then begin. Finalize;. Free;: = nil;;;.

unit uEditRoute;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, DBCtrlsEh, StdCtrls, ExtCtrls, Mask, DBCtrls,
dateutils;= class (TForm): TLabel;: TDBEditEh;: TPanel;: TButton;: TButton;:
TGroupBox;_pass: TDBDateTimeEditEh;: TLabel;: TCheckBox;FormCloseQuery (Sender:
TObject; var CanClose: Boolean);FormShow (Sender: TObject);cbPassedClick
(Sender: TObject);

{ Private declarations }

{ Public declarations };: TfrEditRoute;

{$R *. dfm}uDM, Math;TfrEditRoute. FormCloseQuery
(Sender: TObject;CanClose: Boolean);: = true;(ModalResult = mrOK) then
begin(length (edtName. Text) = 0) then begin

MessageDlg (‘Поле «Наименование» не может быть
пустым! ‘, mtError, [mbOK], 0);: = false;;;;TfrEditRoute. FormShow
(Sender: TObject);_pass. Enabled: = cbPassed. Checked;;TfrEditRoute.
cbPassedClick (Sender: TObject);cbPassed. Checked then begin_pass. Enabled: =
true;VarType (edtDate_pass. Value) = varNulledtDate_pass. Value: =
now;edtDate_pass. Enabled: = false;_pass. Enabled: = cbPassed. Checked;;.

unit uEditCar;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, Mask, DBCtrlsEh, ExtCtrls;= class
(TForm): TLabel;: TLabel;: TLabel;: TDBEditEh;: TDBEditEh;_cnt: TDBEditEh;:
TPanel;: TButton;: TButton;: TLabel;: TDBEditEh;FormCloseQuery (Sender:
TObject; var CanClose: Boolean);

{ Private declarations }

{ Public declarations };: TfrEditCar;uConstants,
uDM;

{$R *. dfm}TfrEditCar. FormCloseQuery (Sender:
TObject;CanClose: Boolean);: = true;(ModalResult = mrOK) then begin(length
(edtName. Text)
= 0) then begin(‘Поле «Наименование» не может быть пустым! ‘, mtError,
[mbOK], 0);: = false;else(not IsInt (edtCargo. Text)) or (not IsInt
(edtTrailer_cnt. Text)) then begin(‘Поля «Вместимость», «Число
прицепов»‘#13’должны содержать целое числовое значение’, mtError, [mbOK],
0);

CanClose: = false;;;;.

unit uLogin;

interface, Windows, Messages, SysUtils, Variants,
Classes, Graphics, Controls, Forms,, Mask, StdCtrls, DB, Grids, DBGrids,
PropFilerEh, PropStorageEh,;= class (TForm): TLabel;: TLabel;: TEdit;: TMaskEdit;:
TPropStorageEh;: TPanel;: TButton;: TButton;: TButton;FormShow (Sender:
TObject);btnSettingsClick (Sender: TObject);FormClose (Sender: TObject; var
Action: TCloseAction);

{ Private declarations }

{ Public declarations };: TfrLogin;: string;

{$R *. dfm}uDM, uConnect, uSettings, uConstants,
uDBState;TfrLogin. FormShow (Sender: TObject);. SetFocus;.
LoadProperties;;TfrLogin. btnSettingsClick (Sender: TObject);(TfrDBState.
Create (nil)) do try;Free;;;TfrLogin. FormClose (Sender: TObject; var Action: TCloseAction);.
SaveProperties;;.

unit uEditRequest;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, Dialogs, StdCtrls, ExtCtrls, Mask, DBCtrlsEh,
DBCtrls;= class (TForm): TLabel;: TPanel;: TButton;: TButton;:
TDBLookupComboBox;: TLabel;: TDBCheckBox;: TButton;: TEdit;btnAssignClientClick
(Sender: TObject);FormCreate (Sender: TObject);

{ Private declarations }

{ Public declarations }: integer;;:
TfrEditRequest;uDM, uAssignClient;

{$R *. dfm}TfrEditRequest. btnAssignClientClick
(Sender: TObject);TfrAssignClient. Create (self) do try: = dm.
DBMain;isPositiveResult (Showmodal) then begin: = cID;. Text: =
cNAME;;Free;;TfrEditRequest. FormCreate (Sender: TObject);: = — 1;;.

unit uEditClient;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls, Mask, DBCtrlsEh;= class
(TForm): TLabel;: TLabel;: TPanel;: TButton;: TButton;: TEdit;:
TEdit;FormCloseQuery (Sender: TObject; var CanClose: Boolean);

{ Private declarations }

{ Public declarations };: TfrEditClient;

{$R *. dfm}TfrEditClient. FormCloseQuery (Sender:
TObject;CanClose: Boolean);: = true;(ModalResult = mrOK) then begin(length
(edtName. Text)
= 0) then begin(‘Поле «Наименование» не может быть пустым! ‘, mtError,
[mbOK], 0);: = false;;;;.

unit uSelectFrame;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls;= class (TForm): TPanel;:
TButton;: TButton;: TListBox;listFramesDblClick (Sender: TObject);FormShow
(Sender: TObject);

{ Private declarations }

{ Public declarations };: TfrSelectFrame;

{$R *. dfm}TfrSelectFrame. listFramesDblClick
(Sender: TObject);

//

{showmessage (inttostr ( (Sender as TListBox).
ItemAtPos (mouse. CursorPos, false)));(Sender as TListBox). ItemAtPos (mouse.
CursorPos, true) <> — 1} ModalResult: = mrOK;;TfrSelectFrame. FormShow
(Sender: TObject);. SetFocus;;.

unit uFrmPattern;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, ComCtrls, ImgList, ActnList, PropFilerEh,
PropStorageEh;= class (TFrame): TActionList;: TImageList;: TStatusBar;:
TPropStorageEh;

{ Private declarations }

{ Public declarations }: string;

ModuleID: integer;

// Абстрактный метод инициализации модуля, переопределяется в
потомках

// Должен возвращать true, если открыта необходимая БД или
false, если закрыта

function Initialize: boolean; virtual; abstract;

// Абстрактный метод завершения работы модуля,
переопределяется в потомках

function Finalize: boolean; virtual; abstract;;:
TfrmPattern;

{$R *. dfm}.

unit uEditUsers;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls;= class (TForm): TPanel;:
TButton;: TButton;: TLabel;: TEdit;: TLabel;: TEdit;: TLabel;: TEdit;: TLabel;:
TEdit;: TLabel;: TLabel;: TLabel;: TLabel;: TLabel;FormShow (Sender: TObject);

{ Private declarations }

{ Public declarations };: TfrEditUsers;

{$R *. dfm}TfrEditUsers. FormShow (Sender:
TObject);

// edtName. SetFocus;;.

unit uEditReqGoods;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls, Mask, DBCtrlsEh;= class
(TForm): TLabel;: TDBEditEh;: TPanel;: TButton;: TButton;: TLabel;: TDBEditEh;:
TLabel;: TDBEditEh;: TLabel;: TDBEditEh;: TLabel;: TDBEditEh;

{ Private declarations }

{ Public declarations };: TfrEditReqGoods;uDM;

{$R *. dfm}.

unit uEditGoods;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls, Mask, DBCtrlsEh;= class
(TForm): TLabel;: TDBEditEh;: TPanel;: TButton;: TButton;: TLabel;: TDBEditEh;:
TLabel;: TDBEditEh;: TLabel;: TDBEditEh;: TLabel;: TDBEditEh;

{ Private declarations }

{ Public declarations };: TfrEditGoods;uDM;

{$R *. dfm}.

unit uFrmRoute;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,

Dialogs, uFrmPattern, PropFilerEh, PropStorageEh,
ImgList, ActnList,

ComCtrls, ExtCtrls, ToolWin, Grids, DBGridEh;=
class (TfrmPattern): TDBGridEh;: TToolBar;: TPanel;: TAction;: TAction;:
TAction;

{ Private declarations }

{ Public declarations };: TfrmRoute;

{$R *. dfm}.

unit uEditDriver;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls, ExtCtrls, Mask, DBCtrlsEh;= class
(TForm): TLabel;: TDBEditEh;: TPanel;: TButton;: TButton;: TLabel;: TDBEditEh;

{ Private declarations }

{ Public declarations };: TfrEditDriver;

{$R *. dfm}uDM;.

unit uConstants;

interfaceSysUtils;= ‘Автотранспорт’;= ‘DB.
ini’;= ‘SQL. ini’;= ‘DBMain’;= ‘DBPark’;= ‘DBStore’;= ‘Controls. ini’; // гриды и тдisInt (str:
string): boolean;isInt (str: string): boolean;: = true;(str);E: EConvertError
do result: = false;;;.

unit uAbout;

interface, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,, StdCtrls;= class (TForm): TLabel;

{ Private declarations }

{ Public declarations };: TfrAbout;

{$R *. dfm}.

метки: Данные, Компания, Разработка, Диспетчерский, Транспортный, Предприятие, Организация, Сущность

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

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

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

Целью данной работы является проектирование базы данных для информационной системы «Грузоперевозки». В процессе разработки были поставлены следующие задачи: проанализировать предметную область, разработать концептуальную модель базы данных, разработать логическую модель базы данных, используя средства Visual FoxPro, реализовать физическое проектирование базы данных.

Наш выбор FoxPro обусловлен, прежде всего, разносторонностью этой СУБД, удобством, как для разработчика приложений, так и для обычного пользователя. Наличие в ней языка программирования позволяет создавать сложные системы обработки данных, ориентированные на конкретные задачи и даже под конкретного пользователя. С другой стороны, в ней отражены и в разной мере используются многие современные технологии программирования: ActiveX, COM, SQL, ODBC, OLE, DCOM, API и ISAPI, и многое другое. При всем этом она сохранила совместимость со старыми версиями под DOS, созданными еще фирмой Fox Software. Если еще добавить, что FoxPro реализован также в средах Macintosh и Unix, то наш выбор становится обоснованным.

14 стр., 6791 слов

Разработка базы данных для автоматизированной системы управления …

… работу одного экземпляра базы данных на нескольких узлах grid, позволяя управлять нагрузкой и гибко масштабировать систему … структуры курсового проекта: В данной работе рассматривается … СУБД MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. …

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

Имеются автотранспортные предприятия общего пользования и ведомственные.

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

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

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

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

Компания X осуществляет заказные грузоперевозки. Компания X обладает своим автопарком. Существуют организации-отправители и организации-получатели. Отправители N подают в компанию заявку на осуществление перевозки. Отправитель N и компания X заключают договор, в котором оговариваются груз (наименование), сроки доставки, способ, оплата за услуги. После компания X составляет квитанцию, в которой указан груз, дата погрузки (отправки), дата доставки и транспорт. Указанный транспорт отправляется на склад отправителю N и забирает указанный товар. В указанные сроки груз должен быть доставлен получателю M. Если оговоренные сроки не соблюдены, то компания X обязана выплатить неустойку отправителю N, размер которой оговаривается в договоре. По факту доставки груза отправителю N отправляется подтверждение приема груза, а также на расчетный счет отправителя N с расчетного счета получателя M переводиться стоимость груза. Затем отправитель N со своего расчетного счета переводит стоимость услуги на счет компании M.

24 стр., 11939 слов

Учет и анализ реализации продукции (работ, услуг) на предприятии …

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

Основным предметом грузоперевозки является груз. Груз — перемещаемый (перевозимый, транспортируемый) товар. Существует несколько классификаций грузов, благодаря которым осуществляется организация процесса транспортировки. Основная классификация грузов одного класса включает:

1. опасные грузы, к которым относят предметы, материалы и вещества, которые при перевозке могут создавать угрозу или нанести вред здоровью человека, а также окружающей среде;
2. скоропортящиеся грузы, к которым относят товары, которые ограничены сроком годности и особыми условиями хранения (например, пищевые продукты);
3. негабаритные грузы, для которых характерны нестандартные размеры, затрудняющие их транспортировку;
4. тяжеловесные грузы, особенностью которых — высокие весовые параметры транспортируемого товара;
5. живой груз, для транспортировки такого груза необходимы определенные условия ТС. [5]

Каждый груз в данной ИС характеризуется следующими параметрами:

1. Шифр груза;
2. Наименование груза;
3. Количество;
4. Стоимость.

Шифром груза является его идентификационный номер – штрих код.

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

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

Физическое лицо – это человек, гражданин РФ., Юридическое лицо — созданная и зарегистрированная в установленном законом порядке организация., Каждый грузоотправитель обладает рядом основных характеристик:

1. Шифр грузополучателя;
2. Имя;
3. Адрес;
4. Расчетный счет.

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

Именем для физических лиц является их фамилия, имя и отчество, а для юридических – название организации.

Адресом является регистрационный адрес лица.

У организаций имя может быть одинаковым, а адрес разным – филиалы либо отдельные помещения, принадлежащие организации (склады).

В тоже время шифр тоже будет разным.

27 стр., 13327 слов

Технология перевозок грузов в международном сообщении

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

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

Грузополучатели так же обладают рядом свойств:

1. Шифр грузополучателя;
2. Имя;
3. Адрес;
4. Расчетный счет.

Каждый грузополучатель обладает своим уникальным шифром.

Состояние грузоперевозки характеризует квитанция, в которой указаны какой груз, откуда и куда направлен.

В каждой квитанции указывается следующее:

1. Номер квитанции;
2. Груз;
3. Транспорт;
4. Дата погрузки;
5. Дата разгрузки;
6. Статус (Доставлен, Не доставлен);
7. Грузоотправитель;
8. Грузополучатель.

Каждая квитанция фиксирует только один процесс грузоперевозки, по которому перевозят один вид груза.

На рисунке 1 представлена схема организационной структуры компании X, Рисунок 1- Схема организационной структуры биржи труда, Функции и должностные обязанности:

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

Отдел по приему заказов – осуществляет прием заказов на перевозку грузов. Здесь же заключается договор на выполнение услуги грузоперевозки в соответствие с Гражданским Кодексом РФ.

Консультант – предоставляет консалтинговые услуги в области транспортных грузоперевозок.

Регистратор заказов – собственно этим человеком подготавливаются все необходимые документы для заключения сделки.

Сущность — некоторый обособленный объект или событие моделируемой системы, имеющий определенный набор свойств — атрибутов. Отдельный элемент этого множества называется «экземпляром сущности». Сущность может обладать одним или несколькими атрибутами, которые однозначно идентифицируют каждый образец сущности, и может обладать любым количеством связей с другими сущностями. [1]

Для базы данных было разработано 4 сущности ГРУЗ, ГРУЗООТПРАВИТЕЛИ, ГРУЗОПОЛУЧАТЕЛИ, КВИТАНЦИИ., Общая информация о сущностях представлена в таблице:, Таблица 1- Сущности БД

метки: Данные, Транспортный, Компания, Разработка, Диспетчерский, Водитель, Система, Заказ

В последнее время стало появляться большое количество фирм оказывающих услуги по перевозу различных грузов. Каждая фирма имеет в своём подчинении несколько машин, штат сотрудников, включая грузчиков и водителей различного стажа. Многие из руководителей фирм уже давно пришли к мнению, что сайт в сети неотъемлемый инструмент по привлечению новых клиентов в наше время.

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

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

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

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

Исходя из поставленной цели выделим следующие задачи:

 Изучение предметной области  Разработка архитектуры корпоративной информационной системы

 Разработка структуры баз данных

 Разработка интерфейса

 Составление технической документации

 Составление руководства пользователя

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

1. Общие сведения

1.1 Полное наименование системы и ее условное обозначение

Корпоративная информационная система для транспортной компании, краткое название системы «КИС для ТК».

1.2 Наименование предприятия разработчика и заказчика

Разработчиком выступает студент четвертого курса института космических и информационных технологий направления «Программная инженерия». Заказчиком выступает ООО «Вторресурс 24».

31 стр., 15411 слов

Разработка системы автоматизации рабочего места диспетчера такси

… автоматизированное рабочее место диспетчера такси. Целью дипломной работы является разработка системы автоматизации рабочего места диспетчера такси, позволяющей автоматизировать работу диспетчеров, по учету и … тарифах Таблица 3.4 — Входные данные по тарифам Вид поездки … 3.1.2 Перечень выходных данных Поступившие заказы Таблица 3.5 — Выходные данные по заказу № Дата/Время Позывной Город отпр. …

1.3 Перечень документов, на основании которых ведется разработка

Программный продукт создается на основании задания выпускной квалификационной работы. Документы были утверждены кафедрой информатики в начале 2015/2016 учебного года.

1.4 Плановые сроки начала и окончания работ по созданию системы.

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

1.5 Порядок оформления и предъявления заказчику результатов работы

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

1.6 Сведения об источниках финансирования

[Электронный ресурс]//URL: https://drprom.ru/referat/na-temu-razrabotka-bazyi-dannyih-dispetcherskogo-punkta-transportnoy-kompanii/

Финансирование отсутствует, т.к. ПО разрабатывается в рамках выпускной квалификационной работы.

1.7 Шифр темы или шифр договора

Шифр отсутствует, т.к. ПО разрабатывается в рамках выпускной квалификационной работы.

2. Назначение и цели создания системы

2.1 Назначение системы

Корпоративная информационная система предназначена для автоматизации основных бизнес-процессов транспортной компании [5].

Система позволяет сотрудникам компании вести учёт совершённых заказов на транспортировку грузов в электронном виде; клиентам компании предоставляется возможность оставления заказа на сайте; все данные хранятся на едином удалённом сервере и используются для обработки и формирования статистики [6].

2.2 Цели создания системы

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

3. Характеристика объекта автоматизации

3.1 Краткие сведения об объекте автоматизации или ссылки на

документы, содержащие такую информацию.

Объект автоматизации – транспортная компания «Грузовоз 24». Подробная информация находится в разделе «Руководство к корпоративной информационной системе».

3.2 Сведения об условиях эксплуатации объекта автоматизации и

характеристиках окружающей среды

Данную систему предлагается использовать в частном бизнесе по предоставлению транспортировочных услуг, а точнее в транспортной компании «Грузовоз 24». КИС адаптировано для использования в операционных системах Windows 7 и современных браузерах.

4. Требования к системе

4.1 Требования к системе

4.1.1 Требования к системе в целом

4.1.1.1 Перечень подсистем, их назначение и основные

характеристики

Корпоративная информационная система состоит из трёх модулей, с разграничением прав доступа:

• Приложение для ОС Windows «Учёт заказов для водителей» включает в себя возможности по ручному вносу сведений заказов, по автоматическому получению сведений из сайта и средствам модуля REST-API;
• приложение выводит статистику по количеству заказов, по самому выгодному водителю, по источнику заказов и другую.

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

12 стр., 5895 слов

Теоретические основы настройки и оптимизация производительности …

… ИССЛЕДОВАНИЯ: Раскрыть понятие операционная система. Изучить основы настройки и оптимизации производительности операционной системы XР. Изучить основы настройки и оптимизации производительности ОС Windows 7. Сделать сравнительный анализ настройки и оптимизации производительности Операционных Систем Windows. Методы исследования: изучение, анализ, сравнение, наблюдение, Курсовая работа состоит из …

REST-API создаётся для единого доступа всех приложений к базам данных [3].

КИС представляет собой единую системы, состоящую из нескольких модулей, разграниченных правами доступа [7].

Информационный обмен происходит посредством работы с базой данных MySQL и REST-API, в которой находятся все необходимые данные для каждого модуля. Просмотреть структуру БД можно в Приложении 1.

4.1.1.2 Требования к характеристикам взаимосвязей создаваемой

системы со смежными системами.

Система должна взаимодействовать с БД MySQL посредством RESTAPI.

4.1.1.3 Требования к режимам функционирования системы

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

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

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

4.1.2 Требования к численности и квалификации персонала системы и

режиму его работы

4.1.2.1.1Требования к численности персонала

Для использования КИС необходим лишь один диспетчер, отвечающий за ввод полученной информации и формирования автоматических отчётов при надобности.

4.1.2.2 Требования к квалификации персонала, порядку его

подготовки и контроля знаний и навыков

Пользователь должен обладать базовыми навыками работы в операционных системах Windows 7 и операционных системах Windows, разработанных позднее. Отдельные курсы повышения квалификации и подробный инструктаж необязателен. Интерфейс и функционал КИС прост и интуитивно понятен.

4.1.3 Показатели назначения

Система предназначены для эксплуатации в операционных системах Windows 7 и операционных системах Windows, разработанных позднее.

4.1.4 Требования к надежности

Система и ее модули должны работать без сбоев в полном функционале. В случае возникновения аварийной ситуации КИС должна завершать работу, сохраняя последние произведенные операции с данными. Вероятность безотказной работы должна составлять минимум 0,97, т.е. система должна корректно функционировать в 97% случаев. Стабильная работа системы не гарантирована на устройствах, не попадающих в перечень устройств необходимых для работы, описанных в п. 4.1.3

4.1.5 Требование к безопасности

Использование системы безопасно, т.к. она не работает с личными данными пользователя, сохраненными в БД.

4.1.6 Требование к эргономике и технической эстетике

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

4.1.7 Требования к защите информации от несанкционированного

доступа

Для удаления данных из КИС требуется ввести пароль. Пароль знает только разработчик КИС и Директор компании-заказчика.

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

4.2.1 Перечень всех функций и задач

В приложении для ОС Windows «Учёт заказов для водителей» имеется несколько основных функции:

14 стр., 6676 слов

Автоматизация системы учета заказов на предприятии

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

 Добавление водителя

 Добавление заказа водителю

 Изменение водительских данных

 Изменение данных заказа

 Удаление заказа

 Удаление водителя.

Сайт компании должен иметь следующие функции:

 Заказ такси

 Оставление отзыва о компании

 Предоставление контактов для связи

 Ознакомление с ценами и автопарком

 Ознакомление с услугами компании

4.2.2 Требования к качеству реализации каждой функции

Все функции модулей должны быть реализованы в соответствии с ТЗ (раздел «Техническое задание»).

Необходимо предусмотреть возможность модернизации системы (добавление/изменение/удаление функций из системы).

4.2.3 Перечень и критерии отказов системы

Сбои и отказы системы вероятны только при использовании программного обеспечения, не входящих в список ПО, описанного технического задания.

1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Анализ предметной области.

Транспортная компания – это небольшое предприятие, которое предоставляет услугу по перевозке грузов различных видов. Перевозка может осуществляться как с грузчиками, так и без. Грузчики исполняют роль помощников при транспортировке грузов от начальной точки расположения (квартира, офис и т.д.) до машины, и в обратную сторону. В частности в компании «Грузовоз 24» имеется возможность заказать следующие виды транспорта:

 «Газель 2 тонны»

 «Мебельная будка 3 тонны»

 «Мебельная будка 5 тонн»

 «Кран-воровайка»

 и другие

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

1. Учёт водителей и заказов. Данная программа отвечает за

учёт заказов, их создание, редактирование, за назначение их

конкретному водителю и последующий расчёт долга водителя.

Программа делается специально для ОС Windows 7 и выше.

2. Сайт ТК «Грузовоз 24». Сайт представляет собой

информационный ресурс в сети Интернет, который знакомит

посетителя с имеющимися в распоряжении компании грузовыми

машинами, доступными для заказа. Объясняет по средствам

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

возможность сайта – это онлайн-заказ такси.

3. Rest-API. Специальный сервис/модуль, который

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

учёту водителей и заказов [4].

Так же была создана диаграмма UseCase. Суть диаграммы вариантов использования состоит в следующем. Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система (в данном случае клиент транспортной компании), которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру (клиенту).

17 стр., 8100 слов

Проектирование и реализация хранилища данных для анализа бизнес …

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

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

Рисунок 1 – диаграмма вариантов использования

Вся структура предприятия имеет следующий вид

Рисунок 2 – организационная структура транспортной компании

Основным направлением деятельности транспортной компании является предоставление услуг по транспортировки грузов различного типа.

Для более полного понимания работы компании необходимо представить описание основного бизнес-процесса транспортной компании – перевозка груза.

Рисунок 3 – Бизнес-процесс заказа транспортировочных услуг

Для полного понимания принципа формирования долга водителя рассмотрим пример.

Водитель получает заказ на перевозку груза по тарифу 500 рублей за час работы. У водителя на выполнение работ ушло 2 часа. Водитель должен получить 1000 рублей за выполненную работу. Но так как он получил заказ от ТК, то он обязан вернуть согласно тарифу заказа фиксированную сумму, не зависящую от времени выполнения заказа. Для данного тарифа эта сумма – 150 рублей. Эта сумма записывается как долг водителя и может накапливаться до определённого в индивидуальной договорённости лимита. Водитель может погашать долг, как авансом, так и оплатой по завершённым заказам. Все взносы водителя фиксируются диспетчером.

1.2 Функциональная модель бизнес-процессов

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

Рисунок 4 – Контекстная диаграмма «Транспортировка грузов»

Взаимодействие системы с окружающей средой описывается с помощью входов («Заявка по телефону», «Заявка с сайта»), выходов («Выполнение работ», «Отмена заказа») и управления («Устав», «Законы РФ»).

 Заявка по телефону – клиенты, звонящие по телефону напрямую

диспетчеру.

 Заявка с сайта – СМС-сообщение содержащие минимальные

необходимые данные для подбора машины и оформления заказа

(откуда, куда везти; телефон для связи; дата и время подачи

машины; количество грузчиков).

 Выполнение работ – подача машины в пункт А, погрузка вещей в

машину, проезд до точки Б, выгрузка вещей из машины.

 Законы РФ – законы по защите прав потребителей и всероссийские

нормы на осуществление коммерческой деятельность.

 Отмена заказа – отмена заказанной транспортировочной услуги.

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

9 стр., 4134 слов

Создание базы данных аэропорта

… этой работы является создать базу данных в СУБД ACCESS. Которая должна будет автоматизировать работу служащих аэропорта. 1. Предметная область 1.1 Описание ER-модели Аэропорт Билет Пассажиры Самолет Рейс ∞ Свойство таблиц 1. Аэропорт. …

Рисунок 5 – диаграмма декомпозиции «Транспортировка грузов»

Процесс функционирования транспортной компании для бизнеспроцесса «Транспортировка грузов», как можно видеть на рисунке выше, состоит из 5 основных этапов:

 Запись данных на бумаге – этап, который выполняется лишь при

условии звонка по телефону.

 Получение СМС с данными о заказе – этот этап не требует переноса

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

этап.

 Занос данных в таблицу Excel – все полученные от клиента данные

заносятся для учёта заказов в электронные таблицы Excel.

 Обзвон подходящих водителей – обзваниваются несколько

подходящих под параметры заказа водителя. Если водитель найден,

то он приступает к выполнению заказа, если нет, то заказ отменяется.

 Не найден водитель или заказчик отменил заявку – заказчик может

на любом этапе отменить заявку. Водитель может отказать от заявки

по собственным соображениям, но лишь, перед тем как начать её

выполнение.

После внедрения КИС этап получения заказа сайта был частично автоматизирован. После получения заказа с сайта диспетчеру остаётся лишь найти соответствующего требованиям водителя и сообщить клиенту о принятие заказа к выполнению. Информация, полученная от клиента, по средствам формы заказа на сайте автоматически заносится в систему.

1.3 Выбор технологии реализации ПО

Qt 5.5.1

Для реализации модуля КИС «Учёт водителей и заказов» был выбран Qt – кроссплатформенный инструментарий разработки ПО на языке программирования C++ [1].

Выбор данного инструмента разработки был обусловлен требованиями заказчика, описанными в техническом задании на реализацию КИС. Так же были рассмотрены другие инструменты для разработки. В их числе: MFC, WinAPI, WPF.

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

Отличительная особенность Qt от других библиотек — использование Meta Object Compiler (MOC) — предварительной системы обработки исходного кода. MOC позволяет во много раз увеличить мощь библиотек, вводя такие понятия, как слоты и сигналы. Кроме того, это позволяет сделать код более лаконичным. Утилита MOC ищет в заголовочных файлах на C++ описания классов, содержащие макрос Q_OBJECT, и создаёт дополнительный исходный файл на C++, содержащий метаобъектный код.

MySQL 5.5.11

Так как КИС планируется быть не высоконагруженной, то выбор СУБД пал на MySQL – решение для малых и средних приложений. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Была выбрана версия 5.5 как одна из самых стабильных на время начала реализации проекта.

7 стр., 3407 слов

Использование баз данных и СУБД для обработки информации

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

REST-API

Языки программирования: C++, PHP, JS.

2. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

2.1 Определение сущностей

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

 Drivers – таблица, содержащая данные о водителях

 Orders – таблица, содержащая данные по заказам; является основной

таблицей

 Pay_types – таблица, содержащая типы оплат

 Car_types – таблица, содержащая типы грузовых машин

Физическая модель данных зависит от конкретной СУБД, в ней содержится информация обо всех объектах базы данных. Поскольку стандартов на объекты базы данных не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД и ее диалекта SQL.

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

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

Рисунок 6 – Физическая модель базы данных

2.2 Определение ключевых элементов и атрибутов сущностей

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

Атрибут — это информационное отображение свойств объектов. Каждый объект характеризуется рядом основных атрибутов. Каждый атрибут в модели должен иметь уникальное имя — идентификатор. Атрибут, при реализации информационной модели на каком — либо носителе информации часто называют элементом данных, полем данных или просто полем.

Ключевым элементом данных называется такой элемент, по которому можно определить значения других элементов данных.

Первичный ключ — это атрибут (или группа атрибутов), которые единственным образом идентифицируют каждую строку в таблице.

Атрибуты и первичные ключи сущностей для информационной

модели, включаемые в состав базы данных, приведены ниже:

Drivers – таблица, содержащая данные о водителях.

Таблица 1 – Таблица Drivers

№ Наименование поля Содержание Тип поля 1 id Идентификатор водителя Счётчик 2 fio Фамилия, имя и отчество водителя Строковый 3 type Тип машины водителя Строковый 4 dolg Долг водителя Числовой 5 phone Телефон водителя Строковый

Рисунок 7 – Таблица Drivers

Orders – таблица, содержащая данные о закзах.

Таблица 2 – таблица Orders

№ Наименование поля Содержание Тип поля 1 id Идентификатор заказа Счётчик 2 otkuda адрес, откуда нужно забирать грузы Строковый 3 kuda адрес, куда нужно транспортировать грузы Строковый 4 phone телефон заказчика Строковый 5 gruzchiki количество грузчиков Числовой 6 gruz_tarif тариф грузчиков Строковый 7 cash сумма, которую должен будет вернуть водитель Строковый 8 driver идентификатор водителя Числовой 9 others дополнительная информация, комментарий Строковый 10 order_date дата для выполнения заявки Строковый 11 order_time время для выполнения заявки Строковый 12 driver_tarif тариф водителя Строковый 13 gruzovik тип грузовик из таблицы Числовой 14 type состояние оплаты долга водителем Строковый 15 pay_type тип оплаты водителем долга Числовой

13 стр., 6340 слов

Автоматизация базы данных для ООО «ОриенБанк»

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

Рисунок 8 – Таблица Orders

Pay_types – таблица, содержащая типы оплат.

Таблица 3 – таблица Pay_types

№ Наименование поля Содержание Тип поля 1 id идентификатор типа оплаты Счётчик 2 name название типа оплаты Строковый

Рисунок 9 – Таблица Pay_types

Car_types – таблица, содержащая типы грузовых машин.

Таблица 4 – таблица Car_types

№ Наименование поля Содержание Тип поля 1 id Идентификатор типа грузовика Счётчик 2 name Название типа грузовика Строковый 3 price Стоимость одного часа работы грузовика Числовой

Рисунок 10 – Таблица Car_types

3. РАЗРАБОТКА ПРОГРАММНОЙ СРЕДЫ

3.1 Разработка интерфейса пользователя

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

 Предпроектный анализ

 Сбор требований

 Проектирование интерфейса

 Дизайн интерфейса

 Подготовка спецификации

3.2 Предпроектный анализ

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

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

Сценарий взаимодействия приложения для ОС Windows с сайтом при помощи REST-API:

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

14 стр., 6705 слов

Контрольная работа: Организация рабочего места водителя

… местом для отдыха водителя. 4.1.5 Водителям, осуществляющим перевозки для учреждений здравоохранения, организаций коммунальных служб, телеграфной, телефонной и почтовой связи, продолжительность ежедневной работы … (контрактом), заключенным с водителем; и) время присутствия на рабочем месте водителя, когда он не управляет … облученность водителя от стен кабины и двигателя — не более 35 Вт/м2, а от окон …

3.3 Сбор требований

На следующем этапе необходимо подготовить подробный перечень функциональности (user stories).

Перечень функциональности (user stories) — это подробный список того что пользователь может делать в системе. Вся функциональность будущего продукта разбивается на простейшие возможности в виде «<�кто> <�что делает> <�с чем>». Каждая из функций имеет приоритет, определяющий важность для общего успеха продукта. Кроме того, для функции описываются критерии приемки — реакция на действия пользователя, при которых она считается правильно работающей. Это позволяет максимально детализировать все процессы, происходящие в системе и, как следствие, учесть их.

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

3.4 Проектирование и дизайн интерфейса

В программе, для ОС Windows, «Учёт водителей и заказов» было решено в основном окне программы, выводить всю самую необходимую информацию: список водителей и их долгов, общий долг всех водителей, кнопки печати общего отчёта по водителям, кнопку отправки смс с долгами водителям, а так же снизу есть кнопка для добавления водителя. Так же напротив каждого водителя есть кнопки: добавление заказа, редактирование информации о водителе, погашение долга водителя. Для большей наглядности было принято решение заменить названия кнопок на картинки подходящие по смыслу. Все функции главного окна продублированы в верхнем контекстном меню.

Рисунок 11 – Основное окно программы «Учёт водителей и заказов»

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

Рисунок 12 – Окно просмотра заказов водителя в программе «Учёт водителей и заказов»

Для добавления заявки водителю нужно нажать на изображение зелёного знака плюс в главном окне напротив нужного водителя. Окно добавления заказа водителю аналогично окну редактирования заказа водителя. Рисунок 13 – Окно добавления заказа в программе «Учёт водителей и заказов»

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

Рисунок 14 – Окно погашения долга водителя в программе «Учёт водителей и заказов»

Для просмотра статистики нужно в основном окне программы в верхнем меню выбрать пункт «статистика» и выбрать подпункт «окно статистики» или нажать сочетание клавиш Ctrl+S. Окно статистики показывает общее количество водителей в штате и количество выполненных заявок всеми водителями. Также имеет пока что три кнопки: У кого больше всего заказов? Кто приносит больше всего прибыли? Откуда приходят клиенты?

Рисунок 15 – Окно статистики в программе «Учёт водителей и заказов»

ЗАКЛЮЧЕНИЕ

В процессе создания корпоративной информационной системы транспортной компании были использованы следующие технологии: Qt5, C+ +, Php, MySQL, JavaScript, Java, AndroidSDK.

Доступ к приложениям может получить любой пользователь, имеющий ПК, web-браузер и подключение к сети Интернет, что обеспечивает максимальное удобство для конечного потребителя [2].

Поставленные задачи были полностью реализованы и протестированы.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

[Электронный ресурс]//URL: https://drprom.ru/referat/na-temu-razrabotka-bazyi-dannyih-dispetcherskogo-punkta-transportnoy-kompanii/

1. Qt Documentation [Электронный ресурс] – Режим доступа: http://doc.qt.io/ Дата обращения: 15.04.2016

2. Руководство по PHP [Электронный ресурс] – Режим доступа: http://php.net/manual/ru/ [Дата обращения: 29.05.2016]

3. Использование HTTP методов для создания RESTful сервисов [Электронный ресурс] – Режим доступа: http://www.restapitutorial.ru/ lessons/httpmethods.html [Дата обращения: 05.06.2016]

4. Архитектура REST [Электронный ресурс] – Режим доступа: https://habrahabr.ru/post/38730/ [Дата обращения: 01.06.2016]

5. Корпоративная информационная система: определение и структура. Современные подходы к построению корпоративных информационных систем [Электронный ресурс] – Режим доступа: http://e-educ.ru/ism14.html [Дата обращения: 03.04.2016]

6. КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ [Электронный ресурс] – Режим доступа: http://iablov.narod.ru/igupit/ kislec.htm [Дата обращения: 26.04.2016]

7. Корпоративные информационные системы. Информационные технологии предприятий | Лекция | НОУ ИНТУИТ [Электронный ресурс] – Режим доступа: http://www.intuit.ru/studies/courses/13833/ 1230/lecture/24069 [Дата обращения: 19.05.2016]

СПИСОК СОКРАЩЕНИЙ

БД – база данных

ОС – операционная система

ТЗ – техническое задание

СУБД – система управления базами данных

КИС – корпоративная информационная система

АИС – автоматизированная информационная система

ФИО – фамилия, имя, отчество

Приложение А.

Федеральное агентство по образованию

Государственное
образовательное учреждение высшего
профессионального образования

Обнинский
государственный институт атомной
энергетики

ИАТЭ НИЯУ МИФИ

Факультет
Естественных Наук

Кафедра прикладной
математики

Название работы:

Проектирование и реализация приложения базы данных на тему «Транспортная компания» отчет

Студент:		Плеханов А.А.
(подпись, дата)	(подпись, дата)	(инициалы, фамилия)
Группа:    М2-С08
(шифр группы)
Руководитель
Ст.преподаватель кафедры ПМ		Уханов Д.И.
(ученая степень, звание)	(подпись, дата)	(инициалы, фамилия)

Обнинск,
2011

Содержание

1.ВВЕДЕНИЕ 3

1.1.
Описание предметной области 3

2.ПОСТАНОВКА
ЗАДАЧИ 4

3.
ФАЗЫ РАЗРАБОТКИ И РЕАЛИЗАЦИИ ПРОЕКТА 5

3.1.
Анализ и планирование требований 5

3.1.1. Модель вариантов использования 5

3.1.2. Формирование словаря предметной
области 7

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

3.1.4.
Описание выбранной технологии доступа
к БД………………………………..9

3.2.
Проектирование 10

3.2.1. Концептуальная модель 10

3.2.1. Логическая модель 11

3.2.3. Физическая модель 12

4.
ЗАКЛЮЧЕНИЕ

4.1.
Определение и оценка результатов проекта
и перспектив его развития 13

5.
ЛИТЕРАТУРА 14

1.Введение

1.1. Описание предметной области

Что
такое грузоперевозка? Это значит, что
некий груз из точки А нужно доставить
в точку Б. Так было всегда, так и
сегодня. Ведь практически во все времена
перевозка грузов имела большое значение
для экономики государств и отдельного
человека. 

Мировая история грузоперевозок началась
не двести и даже не тысячу лет назад.
По-существу начало истории грузоперевозок
следует искать еще в те времена, когда
человек впервые начал использовать
животных для перевозки грузов. Еще много
столетий назад торговые караваны
перевозили грузы практически через всю
Европу и десятки различных государств. 

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

1. То
   время, когда человек изобрел колесо.
   После этого, сам процесс грузоперевозки стал
   намного проще.

2. Период, в котором
   человек сумел приручить некоторых
   животных (появился домашний скот).
   Человеку не надо было тратить столько
   сил, сколько он тратил раньше на
   перевозку, изнуряя свой организм.

3. Естественно —
   изобретение и изготовление транспортных
   средств. Это позволило увеличить время
   грузоперевозки в несколько раз и,
   опять-таки, уменьшило затраты человеческих
   сил. В настоящее время, когда технологии
   с каждым днем становятся все совершенней
   и совершенней, перевозить грузы можно
   в любых количествах и на любые расстояния.

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Чемоданов А.С., Шмаков И.В., студенты БПОУ «ОАТК»,

руководитель Шаркова О.В.

     В настоящее время доминирующим направлением в использовании компьютеров является накопление и обработка информации. Такое перераспределение основных функций, выполняемых вычислительной техникой, вполне понятно — гражданский бизнес гораздо более распространен, чем военные и научные вычисления, а снижение стоимости компьютеров сделало их доступными для предприятий и частных лиц. Спрос на грузовые автомобильные перевозки определяется динамикой и структурой изменения объемов производства. В нашей стране около 80% общего объема грузов перевозится автомобильным транспортом: доставка груза потребителю (заказчику), обслуживание клиентов. Создание информационных систем требует детальных знаний о работе автоматизируемой предметной области.

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

Объектом исследования является предметная область предприятия по грузовым перевозкам.

Предмет исследования – возможности СУБД Access для автоматизации деятельности на предприятии.

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

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

—       изучить особенности работы предприятия,

—       определить объекты автоматизации документооборота по грузовым перевозкам,

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

—       разработать базу данных,

—       разработать интерфейс пользователя.

     Методы исследования: наблюдение за осуществлением грузовых перевозок, беседа с работниками предприятия, теоретический анализ деятельности предприятия для определения объектов автоматизации, практическое создание БД.

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

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

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

—       клиент заказывает товар через менеджера,

—       менеджер оформляет заказы,

—       заказы получает водитель,

—       водитель осуществляет грузовые перевозки по доставке товаров клиентам.

     Разработанная модель предметной области в дальнейшем будет использовать для создания проекта базы данных «Грузовые перевозки».

     Создание базы данных выполнено в СУБД MS Access 2007, т.к. это наиболее распространенная и понятная широкому кругу пользователей система управления базами данных, позволяющая легко структурировать и хранить данные любого типа. Система Microsoft Access является одним из основных компонентов Microsoft Office и предназначена для работы с реляционными базами данных.

     В ходе проектирования базы данных были определены объекты и их атрибуты, на основе которых созданы таблицы. Между таблицами БД определены связи, которые помогают избежать избыточности данных. Тип связи — «один ко многим». 

     Для обеспечения деятельности пользователей с базой данных созданы запросы на выборку.

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

     Исследование предметной области проводилось в рамках изучения дисциплины «Основы проектирования баз данных». При выполнении проекта изучены особенности работы предприятия по осуществлению грузовых перевозок, определены объекты и процессы автоматизации, разработана инфологическая модель для дальнейшего проектирования базы данных. В результате исследования предметной области «Грузовые перевозки» выделены основные объекты для построения инфологической модели и ER-диаграммы. По результатам проектирования разработана база данных и создано приложение для организации деятельности предприятия, осуществляющего грузоперевозки заказанных товаров. Дружественный и интуитивно-понятный интерфейс пользователя позволяет просматривать необходимые сведения из базы данных, добавлять заказы, формировать отчеты и при необходимости выводить информацию на печать. Задачи, поставленные для проекта БД, решены, значит цель работы достигнута.

     Практическая ценность работы состоит в том, что в процессе исследования предметной области был получен опыт проектирования модели базы данных независимо от выбора конкретной СУБД. Средствами СУБД MS Access 2007 создана база данных «Грузовые перевозки». При необходимости база данных может быть упакована в установочный файл программой Access Runtime 2007.