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

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

глубоко развитые возможности интеграции с другими программными продуктами, входящими в состав Microsoft Office, а также с любыми программными Продуктами, поддерживающими технологию OLE;

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

Нельзя не отметить, что, существенной причиной такого широкого распространенная MS Access является и мощная рекламная поддержка, осуществляемая фирмой Microsoft. В процессе разработки данного продукта на рынок представлялись его различные версии. Наиболее известными (в некотором смысле этапными) cтали Ассеss 2.0, Ассеss 7.6 (он впервые был включен в состав программного комплекта MS Office). Позже появились версии Ассеss 97 (в составе NS Office) и Ассеss 2000 (в составе МS Office 2000).

Важным средством, облегчающим работу с Ассеss для начинающих пользователей, являются мастера -- специальные программные надстройки, предназначенные для создания объектов базы данных в режиме последовательного диалога. Для опытных и продвинутых пользователей существуют возможности более гибкого управления ресурсами и возможностями объектов СУБД в режиме конструктора.

Специфической особенностью СУБД Ассеss является то, что вся информация, относящаяся к одной базе данных, хранится в едином файле. Такой файл имеет расширение *.mdb. Данное решение, как правило, удобно для непрофессиональных пользователей, поскольку обеспечивает простоту при переносе данных с одного рабочего места на другое. Внутренняя организация данных в рамках mbd-формата менялась от версии к версии, но фирма Microsoft поддерживала их совместимость снизу вверх, то есть базы данных из файлов в формате ранних версий Access могут быть конвертированы в формат, используемый в версиях более поздних.

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

Чтобы проектируемая АРМ была эффективной необходимо соблюдение следующих принципов создания системы:

Системность

Гибкость

Устойчивость

Эффективность

Согласно принципу системности, АРМ следует рассматривать как системы, структура которых определяется функциональным назначением.

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

Важным средством, облегчающим работу с Ассеss для начинающих пользователей, являются мастера -- специальные программные надстройки, предназначенные для создания объектов базы данных в режиме последовательного диалога. Для опытных и продвинутых пользователей существуют возможности более гибкого управления ресурсами и возможностями объектов СУБД в режиме конструктора.

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

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

Функционирование АРМ может дать желаемый эффект при условии правильного распределения функций и нагрузки между человеком и машинными средствами обработки информации, ядром которой является компьютер [8].

1.2.5 Выбор и обоснование технических средств

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

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

- Его реорганизация путем использования новых возможностей информационных технологий.

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

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

1. Соответствие принятому стандарту информационного обеспечения бизнес-процесса (эталонному процессу);

2. Соответствие целям участников;

3. Стоимость реализации экземпляра бизнес-процесса с учетом стоимости затрат на информационные технологии;

4. Время процесса как косвенная характеристика его стоимости.

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

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

Рисунок 3. Схема формирования агрегированной оценки

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

1. Протяженностью во времени (или конечным числом моментов времени в случае дискретного процесса).

2. Множеством входных переменных (множеством начальных состояний процесса).

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

4. Множеством промежуточных состояний процесса. Процесс переходит в промежуточное состояние после завершения очередной элементарной его функции (операции).

5.Внутренней структурой совокупности элементов бизнес-системы, реализующих данный процесс (организационной структурой процесса);

6. Множеством управляющих воздействий. Каждое управляющее воздействие выбирается лицом, принимающим решение о способе выполнения элементарной бизнес-функции.

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

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

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

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

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

1. изменение состава и структуры бизнес-процессов, подлежащих автоматизации;

2. изменение требований к интерфейсу и эргономике системы;

Можно выделить два стандартных подхода к обеспечению адаптивности информационной системы:

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

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

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

1. Информация для поддержки управленческих решений стратегического характера.

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

3. Учетно-операционная информация о конкретных операциях банка.

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

Рисунок 4. Схема адаптивной реструктуризации информационной системы

Технологические блоки, наличие которых позволяет решать задачи адаптации:

- изменение состава информации и структуры информационной базы;

- изменение состава рабочих мест и функционального наполнения рабочего места пользователя;

- изменение интерфейсов ввода и корректировки информации;

- изменение фильтров и запросов на получение информации;

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

- генератор операций над бизнес-объектами;

- изменение алгоритмов обработки информации;

- изменение логики исполнения бизнес-процессов.

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

При построении методики нас будет интересовать структура и изменение характеристик трех компонент бизнес-процесса: интерфейса, бизнес-логики и данных [7].

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

Остановимся несколько подробнее на способе реализации расширяемой метасхемы. Ее основными характеристиками являются:

- Объектно-ориентированный подход к реализации;

- Иерархически организованный словарь классов объектов;

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

- Возможность определять новые реквизиты классов объектов, присутствующих в схеме данных;

- Определение правил ведения и изменения классов объектов и их реквизитов (область определения, возможность индексирования, обязательность, наследование и т.п.);

- Реализация стандартных и нестандартных методов ввода, просмотра, выбора, проверки определенных (в том числе вновь определенных) классов объектов и реквизитов;

- Реализация механизмов экспорта и импорта объектов;

- Реализация механизмов экспорта и импорта описания расширенной метасхемы. Описывающую логическую структуру базы данных АБС в универсальных реляционных таблицах, строки которых содержат описательную информацию о ряде объектов (сущностей) информационной системы. При этом ядро схемы базы данных системы - классы объектов, реквизиты и связи между ними, которые имеют четко формализованную семантику и которым наиболее часто происходит обращение - реализуется в рамках обычной реляционной модели СУБД Progress, а часть классов и реквизитов - в рамках расширенной метамодели. Это дало возможность определять новые классы объектов, их реквизиты и связи без необходимости изменения физической модели данных [9].

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

Рисунок 5. Реализация расширения схемы данных

Для реализации расширенной метасхемы в структуре данных присутствуют следующие сущности:

- словарь классов;

- методы классов;

- словарь реквизитов классов;

- классификатор значений реквизитов.

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

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

Обычно выделяют входной интерфейс - интерфейс ввода информации и выходной интерфейс - интерфейс вывода информации.

Можно выделить три способа организации входного интерфейса:

- Ручной ввод информации;

- Автоматизированный ввод с генерацией части информации на основании типовых схем настроек;

- Автоматический ввод информации на основе электронных документов.

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

Одной из наиболее актуальных задач в сфере создания и развития банковских информационных систем является разработка единых форматов электронного обмена данными (ЭОД).

В настоящее время в банковских системах наиболее известны следующие форматы ЭОД:

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

- DBF-файл, содержащий необходимый стандартный заголовок и записи с содержимым описанных в заголовке полей;

- SWIFT-ориентированный;

- На основе стандарта UN/EDIFACT;

- На основе XML.

Последний формат имеет наибольшие перспективы. Его можно рассматривать как перспективный инструмент для выработки межкорпоративного стандарта представления метаданных. Корпоративные системы с появлением XML приобретают новый уровень гибкости.

С помощью наиболее распространенных форматов обмена электронными документами можно сделать выводы:

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

- В целях обеспечения универсального интерфейса от ИС банка требуется обеспечить возможность организации интерфейса с внешними системами с использованием всех перечисленных форматов, быть может, UN/EDIFACT;

- Очевидна перспектива использования XML-формата в качестве основного.

В информационной системе ТОО «АвтоБот» используется система со следующей характеристикой:

Система: Microsoft Office 2007.

Монитор: 17” LG L1730B (1280*1024/75Hz)

Процессор: Intel Pentium D820 2800GHz

Клавиатура: PS/2 ASUS AS-KBA000 SK1788.

Мышь: РS/2 Genius NetScroll +Eye, optical.

Оперативная память: DIMM DDR II 512Mb <PC-3200>

Жесткий диск: 80Gb

Сканер: HP ScanJet 5590, A4, 1200*1200, 12 sec, USB, 48 bit.

Принтер: Canon LBP-2900 A4, 600*600dpi, 12ppm, 2Mb, USB.

- Вычислительная сеть разделена на четыре сегмента. Сегментирование реализовано с помощью коммутатора 3Com SuperStack II Switch 1100 (12 коммутируемых портов 10, и два коммутируемых порта на 10/100 без дополнительных модулей).

- Сегмент 1 - центр обработки данных.

- Сеть - 100 Мбит/c на концентраторе 3Com OfficeConnect Fast Ethernet Hubs (12 портов).

- Кабель - витая пара категории 5 (не СКС).

- Два сервера Pentium III 533 МГц, ОС Windows NT 4.0 - обработка данных АБС.

- Один сервер Pentium III 500 МГц, ОС Windows NT 4.0 - файл-сервер.
- Несколько обслуживающих ПК Pentium III, ОС Windows NT 4.0 Workstation.

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

- Сеть - 10 Мбит/c на концентраторе 3Com OfficeConnect Ethernet Hubs.
- Кабель - витая пара категории 3 (не СКС).

- Рабочие станции - ПК, ОС Windows NT 4.0 Workstation.

- Защита данных - программный RAID и не слишком регулярное архивирование данных на CD. Защита от сбоев электропитания отсутствует.
- Внешнее соединение - выделенный канал в интернет 64 кбит/c, маршрутизатор Cisco 1050. Программный межсетевой экран, прокси-сервер и кэш-сервер установлены на компьютере Pentium III, 450 МГц, ОЗУ 256 Мбайт, ОС FreeBSD [10].

2. Проектная часть

2.1 Информационное обеспечение комплекса задач

2.1.1 Инфологическая (информационная) модель (схема данных) и ее описание

В базе данных отображается информация об определенной предметной области (ПО). ПО - это часть реального мира.

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

Требования, предъявляемые к инфологической модели:

- Адекватное отображение (язык для представления ИМ должен обладать достаточными выразительными возможностями)

- Непротиворечивость (не должна допускаться неоднозначная трактовка модели)

- Легко расширяемость (обеспечение ввода новых данных без изменения ранее определенных)

- Гибкий язык (язык должен быть применим как при ручном, так и при автоматизированном проектировании)

- Понятность всем пользователям

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

Форма информационного обеспечения системы - локальная. Все данные хранятся на магнитных дисках в дисковом файле таблицы Table (*.DBF). На основе этих данных созданы электронные формы для удобного заполнения данными.

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

Средства создания ЭД, подготавливаемым заранее, хранящихся в базах шаблонов документов и используемым затем для заполнения и последующего использования [11].

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

2.1.2 Используемые классификаторы и системы кодирования

Перечень выполняемых операций:

- Возможность ведения справочника «Районы»;

- Возможность ведения справочника «Водители»;

- Возможность ведения справочника «Улицы»;

- Возможность добавления нового заказа;

- Возможность расчета километража заказа;

Возможность сформирования цены заказа в зависимости от районов отправки и прибытия;

- Возможность учета состояния такситов (свободен, в пути, возвращается);

- Возможность сформирования отчета по всем водителям;

- Возможность сформирования отчета по каждому водителю;

- Возможность сформирования отчета по перемещениям;

- Возможность сформирования отчета по вызовам;

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

2.1.3 Характеристика входной информации

Входная информация представлена в таблицах 2.1-2.3

Таблица 2.1. Описание входных документов

Идентификатор	Форма представления	Периодичность выдачи	Сроки выдачи	Получатель	Назначение
1	2	3	4	5	6
Исходная форма для работы с системой	Экранная форма	При входе в систему	Немедленно после входа в систему	Пользователь, вошедший в систему	Предоставление возможности выбора необходимого модуля для дальнейшей работы
cards	Экранная форма	По запросу пользователя	Немедленно	Запросивший пользователь	Информация о автомобилях
dosking	Экранная форма	По запросу пользователя	Немедленно	Запросивший пользователь	Информация о расстояниях между районами города
regions	Экранная форма	По запросу пользователя	Немедленно	Запросивший пользователь	Информация о телефонном коде района
stаtes	Экранная форма	По запросу пользователя	Немедленно	Запросивший пользователь	Информация о состоянии водителя
travels	Экранная форма	По запросу пользователя	Немедленно	Запросивший пользователь	Информация о путевом листе водителя
ulicy	Экранная форма	По запросу пользователя	Немедленно	Запросивший пользователь	Информация о улицах и присвоенных им телефонных кодах

Таблица 2.2 . Структурные единицы входных сообщений

Наименование	Идентификатор выходного сообщения	Формат
1	2	3
Уникальный код	ID	Строка
Модель автомобиля	Model.	Строка
Номер автомобиля	Nomer	Число
Фамилия водителя	Voditel	Строка
Номер телефона	Telefon	Число
Номер сотового телефона	Sot_Tel	Число
Название района	Source	Строка
Название района	Destination	Строка
Расстояние между районами	Length	Число
Название района	Rеgion_name	Строка
Код телефона	Tel_code	Число
Фамилия водителя	Voditel	Строка
Дата и время заказа	Time_Send	Дата/время
Отправка	Time_Out	Число
Район выбытия	From_Region	Строка
Район прибытия	To_Region	Строка
Промежуточный район	To_Address	Строка
Время пути	Way_Time	Число
Цена	Price	Число
Место посадки	Place	Строка
Код состояния водителя	State	Число

Таблица 2.3. Перечень и описание входных документов

Документ	Периодичность выдачи	Сроки выдачи	Получатель	Назначение
Документы по вызовам	По запросу пользователя	Немедленно	Запросивший пользователь	Отчет по вызовам
Документы по водителям	По запросу пользователя	Немедленно	Запросивший пользователь	Информация по водителям
Документы по районам	По запросу пользователя	Немедленно	Запросивший пользователь	Информация по районам
Документы по перемещениям	По запросу пользователя	Немедленно	Запросивший пользователь	Отчет по перемещениям

2.1.4 Нормативно - справочная информация

К нормативно - справочной информации, используемой в АИС кредиты, относятся:

Справочник Клиенты;

Справочник Виды кредитов;

Справочник График гашения;

Справочник Расчетные Счета;

Справочник Залог;

Справочник Пользователи.

Основными функциями Справочников являются:

обеспечение проверки кодированных значений признаков при вводе данных;

декодирование значений признаков при выводе данных на экран дисплея;

хранение постоянной информации, связанной с определёнными значениями признаков;

оформление пояснительным текстом таблиц, получаемых в результате решения комплекса задач [13].

2.2 Технологическое обеспечение

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

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

Обеспечение высокой степени достоверности полученной информации;

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

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

Технологический процесс состоит из совокупности технологических операций.

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

Основными операциями, составляющими технологический процесс, являются:

Ввод данных в базу данных (БД);

Вывод данных из БД;

Корректировки БД;

Поиска и выбора информации в БД;

Контроля ввода/вывода данных;

Сортировка данных в БД;

Системы защиты информации в БД;

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

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

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

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

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

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

2.2.2 Схема технологического процесса сбора, передачи, обработки и выдачи информации

Рисунок 7. Схема работы программы

2.3 Программное обеспечение комплекса задач

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

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

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

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

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

Пакет Delphi - продолжение линии компиляторов языка Pascal корпорации Borland. Pascal как язык очень прост, а строгий контроль типов данных способствует раннему обнаружению ошибок и позволяет быстро создавать надежные и эффективные программы. Корпорация Borland постоянно обогащала язык. Когда-то в версию 4.0 были включены средства раздельной трансляции, позже, начиная с версии 5.5, появились объекты, а в состав шестой версии пакета вошла полноценная библиотека классов Turbo Vision, реализующая оконную систему в текстовом режиме работы видеоадаптера. Это был один из первых продуктов, содержавших интегрированную среду разработки программ. [6]

Delphi содержит полноценный текстовый редактор типа Brief, назначения клавиш в котором соответствуют принятым в Windows стандартам, а глубина иерархии операций Undo неограниченна. Как это стало уже обязательным, реализовано цветовое выделение различных лексических элементов программы. Процесс построения приложения достаточно прост. Нужно выбрать форму (в понятие формы входят обычные, диалоговые, родительские и дочерние окна MDI), задать ее свойства и включить в нее необходимые компоненты (видимые и, если понадобится, неотображаемые): меню, инструментальные панели, строку состояния и т. п., задать их свойства и далее написать (с помощью редактора исходного кода) обработчики событий. Object Browser. Окна типа Object Browser стали неотъемлемой частью систем программирования на объектно-ориентированных языках. Работа с ними становится возможной сразу после того, как вы скомпилировали приложение.

Projeсt Manager - это отдельное окно, где перечисляются модули и формы, составляющие проект. При каждом модуле указывается маршрут к каталогу, в котором находится исходный текст. Жирным шрифтом выделяются измененные, но еще не сохраненные части проекта. В верхней части окна имеется набор кнопок: добавить, удалить, показать исходный текст, показать форму, задать опции и синхронизировать содержимое окна с текстом файла проекта, т. е. с головной программой на языке Pascal.

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

Visual Component Library (VCL) Богатство палитры объектов для построения пользовательского интерфейса - один из ключевых факторов при выборе инструмента визуального программирования. При этом для пользователя имеет значение как число элементов, включенных непосредственно в среду, так и доступность элементов соответствующего формата на рынке.

Delphi - это комбинация нескольких важнейших технологий:

Высокопроизводительный компилятор в машинный код

Объектно-ориентированная модель компонент

Визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов

Масштабируемые средства для построения баз данных

Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений в архитектуре “клиент-сервер”. Этот компилятор в настоящее время является самым быстрым в мире, его скорость компиляции составляет свыше 120 тысяч строк в минуту на компьютере 486DX33. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на Си или ручного написания кода (хотя это возможно).

В процессе построения приложения разработчик выбирает из палитры компонент готовые компоненты как художник, делающий крупные мазки кистью. Еще до компиляции он видит результаты своей работы - после подключения к источнику данных их можно видеть отображенными на форме, можно перемещаться по данным, представлять их в том или ином виде. В этом смысле проектирование в Delphi мало чем отличается от проектирования в интерпретирующей среде, однако после выполнения компиляции мы получаем код, который исполняется в 10-20 раз быстрее, чем то же самое, сделанное при помощи интерпретатора. Кроме того, компилятор компилятору рознь, в Delphi компиляция производится непосредственно в родной машинный код, в то время как существуют компиляторы, превращающие программу в так называемый p-код, который затем интерпретируется виртуальной p-машиной. Это не может не сказаться на фактическом быстродействии готового приложения [17].

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

В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. Для начала - неплохо. Но если возникнет необходимость в решении какой-то специфической проблемы на Delphi, советуем, прежде чем попытаться начинать решать проблему “с нуля”, просмотреть список свободно распространяемых или коммерческих компонент, разработанных третьими фирмами, количество этих фирм в настоящее время превышает число 250, хотя, возможно, я не обо всех знаю. Скептики, возможно, не поверят мне, когда я скажу, что на Delphi можно одинаково хорошо писать как приложения к корпоративным базам данных, так и, к примеру, игровые программы. Тем не менее, это так. Во многом это объясняется тем, что традиционно в среде Windows было достаточно сложно реализовывать пользовательский интерфейс. Событийная модель в Windows всегда была сложна для понимания и отладки. Но именно разработка интерфейса в Delphi является самой простой задачей для программиста [18].

автоматизированная система контроль

2.3.2 Описание программных модулей

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

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

1) Реляционная модель данных - удобный способ представления данных предметной области;

2) Язык SQL - универсальный способ манипулирования такими данными.

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

- Сама предметная область;

- Модель предметной области;

- Логическая модель данных;

- Физическая модель данных;

- Собственно база данных и приложения.

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

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

Логическая модель данных. На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

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

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

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

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

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

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

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

2.3.3 Инструкция пользователя

Для запуска программы необходимо запустить файл «Taxi_Control.exe». Откроется заставка программы, а затем главное окно программы (рисунок 8).

Рисунок 8. Главное окно программы «Таксопарк»

Главное окно программы одержит 2 вкладки:

Данные - предназначена для просмотра справочников, необходимых для работы таксопарка: Районы, Водители, Отчеты (рисунок 9);

Рисунок 9. Вкладка «Данные»

При нажатии «Районы» во вкладке «Данные» выходит окно, содержашее информацию по районам города, которую при необходимости можно редактировать (рисунок 10).

Рисунок 10. Окно настройки районов города

Данная форма состоит их двух табличных окон:

- в первом указаны районы и присвоенный им телефонный код для аутентификации при вызове;

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

Всё это можно редактировать, например: добавим район Юность и стыкующиеся с ним районы Новостройка и Комсомольский (рисунок 11,12,13)

Рисунок 11. Добавление района

Рисунок 12. Редактирование стыкующихся районов

Рисунок 13. Полученный район «Юность» со стыкующимися районами

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

Рисунок 14. Удаление района

При выборе вкладки «Водители» выходит окно, содержащее необходимую информацию о водителях таксопарка (рисунок 15).

Рисунок 15. Окно «Водители»

Также имеются команды редактирования информации по водителям. Выберем команду «Добавить» и внесем водителя Серикова со всей необходимой информацией (рисунок 16).

Рисунок 16. Добавление новой записи- водителя Серикова

При этом новая запись по водителю автоматически отображается в главном окне в окне «Водитель» (рисунок 17).

Рисунок 17. Отображение нового водителя

Вкладку «Отчеты» рассмотрим чуть позже.

На главной форме имеется команда «Новый заказ», при нажатии по которой курсор автоматически переходит в окно ввода телефонного номера заказчика, именуемого клиентом. После чего заполняется адрес отправки и адрес прибытия. Хочется отметить, что в адресе отправки и адресе прибытия для удобства имеюмся ниспадающие меню (рисунок 18).

Рисунок 18. Заполнение адреса отправки

При этом автоматически появляется районы данных адресов, в данном случае: адрес отправки - ул. Утепбаева, 50в - появляется район Новостройки; адрес прибытия ул. Глинки, 21 - появляется район Цемпоселок (всё это необходимо для подсчета километража пути, цены поездки и уточнения ближайшей машины таксопарка) (рисунок 19).

Рисунок 19. Появление районов адресов отправки и прибытия

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

Рисунок 20. Изменение статуса и цвета водителя на отправлен

По истечении просчитанного времени (в данном случае 5 минут) меняется статус водителя, а именно Алексеева на занят (пасс) и меняется цвет с красного на желтый (рисунок 21).

Рисунок 21. Изменение статуса водителя

По истечении подсчитанного ИС времени статус водителя поменяется на «возвращается» и соответственно цвет «зеленый» (рисунок 22)

Рисунок 22. Изменение статуса водителя Алексеева

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

Для удобства пользователя кнопки продублированы на главной форме: Водители, Районы, Отчеты и добавлены кнопка Состояние для показа и изменения статуса водителя (рисунок 23).

Рисунок 23. Изменение состояния водителя

Перейдем к отчетности. Для составления отчетности выбираем кнопку «Отчеты», после чего появляется окно составления отчета (рисунок 24).

Рисунок 24. Создание отчетов о поездках

Выберем дату отчетности 18.06.2010, всех водителей, нажимаем «Создать», появляется отчет в формате MS Word, который мы можем распечатать и подшить в папку отчетов (рисунок 25).

Рисунок 25. Сформированный отчет по вызовам

Теперь создадим отчет от всем перемещениям за 9.06.2010 г. (рисунок 26).

Рисунок 26. Создание отчета по всем перемещениям

Рисунок 27. Сформированный отчет по всем перемещениям

Создадим отчет по одному водителю, например Ахметову (рисунок 28, 29).

Рисунок 28. Создание отчета по водителю Ахметову

Рисунок 29. Сформированный отчет по водителю Ахметову

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

3. Экономическое обоснование работы

3.1 Смета затрат

Затраты времени при выполнении работ на стадии “Технический проект”;

Затраты времени при выполнении работ на стадии “Рабочий проект”;

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

Сложность контроля входной и выходной информации;

Использование типовых проектных решений, типовых программ, стандартных модулей.

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

расчет объема инвестиций на программное обеспечение;

расчет фонда оплаты труда;

расчет калькуляции затрат на программное обеспечение;

расчет общей и сравнительной экономической эффективности разработанной программы [19].

3.2 Основные технико-экономические показатели

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

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

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

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

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

Исходными данными является сборник "Нормы времени" и рекомендованный утвержденный проектным и внедренческим центром организации труда. Нормы времени предназначены для обоснования трудоёмкости разработки задач, нормирования труда разработчиков, определения продолжительности разработки и необходимой численности специалистов на создание комплекса задач (задачи) для персональных ЭВМ [20].

Нормы времени рассчитаны в зависимости от факторов, наибольшим образом влияющих на трудоемкость разработки:

количества разновидностей макетов входной информации;

количества разновидностей форм выходной информации;

степени новизны комплекса задач (задачи);

сложности алгоритма.

К основным показателям экономической эффективности относятся следующие (3.1):

Ток = К/П,	(3.1)

м?нда?ы Ток - основной показатель ЭЭ

К- цена программы;