Размещено на http://www.allbest.ru/

Содержание

• Введение
• 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.1) Добавление, изменение учетной информации об автомобилях, удаление автомобиля из БД;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6) Сервер 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), которая осуществляет обработку запросов от клиентов. Хранение заявок на сервере осуществляется ввиду необходимости закрытия или оформления заявки из любого территориально удаленного офиса.

Firebird Embedded Server начал выпускаться с версии 1.5, этот сервер представляет собой Firebird Super server, скомпилированный в виде библиотек DLL. Embedded идеален для однопользовательских приложений - в этом случае не требуется совершенно никаких настроек, и достаточно разместить библиотеки рядом с исполняемым файлом.

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

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

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

Кроме того, Embedded обладает функциональностью обычной клиентской библиотеки (gds32. dll) - если соединение сетевое, то есть, с указанием имени сервера (srv: c: \dir\data. fdb), то библиотека выполняет функции обычной клиентской библиотеки. Если соединение локальное (c: \dir\data. gdb), то библиотека выполняет функции сервера. Для случая соединения вида "localhost: c: \dir\data. 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). Но с учетом архитектурных особенностей Interbase\Firebird это нежелательно: схема взаимодействия транзакций в этих СУБД такова, что заинтересованная транзакция, которой и является пишущая транзакция в неподтвержденном состоянии (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 Реляционная модель главной БД

Генераторы:

CREATE GENERATOR GEN_CLIENT_ID;

CREATE GENERATOR GEN_GOODS_ID;

CREATE GENERATOR GEN_REQUEST_ID;

CREATE GENERATOR GEN_REQUEST_TYPE_ID;

CREATE GENERATOR GEN_ROUTE_ID;

CREATE GENERATOR GEN_USERS_ID;

Таблицы:

Таблица клиентов

CREATE TABLE CLIENT (

CID INTEGER NOT NULL,

NAME VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,DETAIL VARCHAR (300) CHARACTER SET WIN1251 COLLATE WIN1251);

Таблица детализации

CREATE TABLE GOODS (

GID INTEGER NOT NULL,

REQUEST INTEGER,

INV_NUM VARCHAR (50),

NAME VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,CNT INTEGER,

DIMENSION VARCHAR (20) CHARACTER SET WIN1251 COLLATE WIN1251,WEIGHT DOUBLE PRECISION);

Таблица заявок

CREATE TABLE REQUEST (

RID INTEGER NOT NULL,

NAME VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,COMPLETED INTEGER,

CLIENT INTEGER,

REQUEST_TYPE INTEGER,

USER_ADD INTEGER,

USER_CLOSE INTEGER,

DATE_ADD TIMESTAMP,

DATE_COMPLETED TIMESTAMP);

Таблица типов заявок

CREATE TABLE REQUEST_TYPE (

TID INTEGER NOT NULL,

NAME VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251);

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

CREATE TABLE USERS (

UID INTEGER NOT NULL,

NAME 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);

Таблица пунктов маршрута

CREATE TABLE ROUTE (

OID INTEGER NOT NULL,

NAME VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,DATE_PASS TIMESTAMP,

REQUEST INTEGER,

PASSED INTEGER);

Триггеры:

CREATE TRIGGER REQUEST_BI0_DATE_ADD FOR REQUEST

ACTIVE BEFORE INSERT POSITION 0

AS

begin

new. date_add = current_timestamp;

if (new.completed = 1) then begin

new. date_completed = current_timestamp;

end

end

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

CREATE TRIGGER REQUEST_BU0_DATE_COMPLETED FOR REQUEST

ACTIVE BEFORE UPDATE POSITION 0

AS

begin

if (new.completed <> old. с) then begin

new. date_completed = current_timestamp;

end

end

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

Create trigger users_bi for users

ACTIVE BEFORE INSERT POSITION 0

As begin

if (new. uid is null) then

new. uid = gen_id (gen_users_id,1);

end

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

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

CREATE PROCEDURE USERS_INSERT (

PASS VARCHAR (50),

RULES VARCHAR (20),

NAME VARCHAR (100),

LOGIN VARCHAR (50))

RETURNS (

UID INTEGER)

AS

begin

uid = gen_id (gen_users_id,1);

insert into users

(LOGIN, NAME, PASS, RULES, UID)

values

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

suspend;

end^

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

CREATE PROCEDURE USERS_UPDATE (

RULES VARCHAR (20),

PASS VARCHAR (100),

NAME VARCHAR (100),

UID INTEGER,

LOGIN VARCHAR (50))

AS

begin

update users

set

LOGIN =: LOGIN,

NAME =: NAME,

PASS =: PASS,

RULES =: RULES

where

UID =: UID;

end^

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

CREATE PROCEDURE USERS_DELETE (

UID INTEGER)

AS

begin

delete from users where

UID =: UID;

end^

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

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

Генераторы:

CREATE GENERATOR GEN_CAR_ID;

CREATE GENERATOR GEN_DRIVER_ID;

Таблицы:

Таблица автомашин

CREATE TABLE CAR (

CID INTEGER NOT NULL,

NAME VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,CARGO DOUBLE PRECISION,

TRAILER_CNT INTEGER,

PLACE INTEGER,

REQUEST INTEGER);

Таблица водителей

CREATE TABLE DRIVER (

DID INTEGER NOT NULL,

NAME VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,PASSPORT VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,CAR INTEGER);

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

Генераторы:

CREATE GENERATOR GEN_CLIENT_ID;

CREATE GENERATOR GEN_GOODS_ID;

Таблицы:

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

CREATE TABLE CLIENT (

CID INTEGER NOT NULL,

NAME VARCHAR (100) CHARACTER SET WIN1251 COLLATE WIN1251,DETAIL VARCHAR (300) CHARACTER SET WIN1251 COLLATE WIN1251);

Таблица товаров

CREATE TABLE GOODS (

GID INTEGER NOT NULL,

NAME VARCHAR (300) CHARACTER SET WIN1251 COLLATE WIN1251,CLIENT INTEGER,

CNT INTEGER,

REQUEST INTEGER,

INV_NUM VARCHAR (50) CHARACTER SET WIN1251 COLLATE WIN1251,DIMENSION VARCHAR (50) CHARACTER SET WIN1251 COLLATE WIN1251,WEIGHT DOUBLE PRECISION,

IS_OLD INTEGER,

DATE_ADD TIMESTAMP,

DATE_OLD TIMESTAMP,

STAND INTEGER,

SHELF INTEGER);

Триггеры:

CREATE TRIGGER GOODS_BI0_DATE_ADD FOR GOODS

ACTIVE BEFORE INSERT POSITION 0

AS

begin

new. date_add = current_timestamp;

if (new. is_old = 1) then begin

new. date_old = current_timestamp;

end

end

CREATE TRIGGER GOODS_BU0_DATE_OLD FOR GOODS

ACTIVE BEFORE UPDATE POSITION 0

AS

begin

if (new. is_old <> old. is_old) then begin

new. date_old = current_timestamp;

end

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 Экономическое обоснование разработки программы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

t_тз = 20 чел. - дней;

t_тп = 15 чел. - дней;

t_рп = 18 чел. - дней.

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

t_пп=20+15+18;

t_пп= 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 (смотрите выше). Так как материальные затраты на разработку программной продукции , то нормативная прибыль будет равна:

;

;

руб;

R= (Пр/Ц) *100%;

R= (4952,13/19808,53) *100%=25%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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