Курсовая работа
ГИС- в мире возможностей ТАКСИ
Разработка программной системы диспетчеризации такси
Введение
1. Современные автоматизированные системы диспетчеризации такси
- Система диспетчеризации «РМА»
- Система диспетчеризации «РМК»
- Система диспетчеризации «Везет»
- Сравнительный анализ характеристик систем
- Проектирование и разработка программной системы диспетчеризации такси
- Функциональная модель системы
- Проектирование серверной части на основе архитектуры взаимодействия REST
- Хранилище данных
- Архитектура интеграционного сервера
- Современные концепции спутниковой системы навигации GPS и её использование в данной системе
- Проектирование клиентских частей диспетчера и водителя, используя AJAX архитектуры
- Клиентская часть диспетчера
- Проектирование и разработка Android клиента для водителя
- Реализация геоинформационной системы диспетчеризации Екатеринбургского такси
Заключение
Список использованных источников
Введение
В настоящее время стремительно развиваются географические информационные системы. ГИС – это программные системы сбора, хранения, анализа и графической визуализации пространственных (географических) данных и связанной с ними информацией о необходимых объектах[1]. Полимасштабные, или масштабно-независимые ГИС основаны на множественных, или полимасштабных представлениях пространственных объектов, обеспечивая графическое или картографическое воспроизведение данных на любом из избранных уровней масштабного ряда на основе единственного набора данных с наибольшим пространственным разрешением.
Интеграционные возможности ГИС поистине безграничны. Эти системы позволяют вести учет численности, структуры и распределения населения и одновременно использовать эту информацию для планирования развития социальной инфраструктуры, транспортной сети, оптимального размещения объектов здравоохранения, противопожарных отрядов и сил правопорядка. Не исключением является применение ГИС и в задаче диспетчеризации такси. Данная система является специализированной отраслевой системой для таксопарков, которая объединяет в себе традиционные технологии диспетчеризации такси и инновационные технологии спутниковой навигации GPS[1].
Работа такси напрямую связана с расположением геоинформационных объектов, таксистов и своевременной обработки заказов. В японских такси и в русских такси для этой цели используется навигация через GPS. Наличие такой технологии очень хорошо сказывается на создаваемую систему и позволяет усовершенствовать её функции. Также позволяет мгновенно рассчитывать стоимость проезда. Основная задача такой системы – управление и мониторинг транспортных средств, прием заказов и их автоматическая обработка, контроль качества работы с клиентами, контроль безопасности[2]. Такое решение для организации диспетчерской службы, приема и доставки позволяет с максимальной эффективностью использовать парк транспортных средств, оптимизировать процесс доставки и повысить производительность офиса.
С развитием транспортной сети и дорожной инфраструктуры в городе все более популярным и удобным средством передвижения становится такси.
В связи с этим создание автоматизированной системы диспетчеризации такси в современном обществе становится всё более актуальным.
Именно увеличение спроса на данный вид услуги стало толчком для развития этой отрасли и как следствие увеличением предложений. Таким образом, в настоящий момент существует большое количество людей, занимающихся данным видом деятельности. В связи с чем, активно развивается конкуренция на рынке данного вида услуг. Заказы постоянно растут, и диспетчерская такси ежедневно сталкивается с огромным количеством заказов, поэтому управление машинами должно быть оптимальным. Требуется снижать вероятность ошибки диспетчеров, автоматизировать их вид деятельности. Обращаясь в службу такси клиенту должна гарантироваться возможность заказать машину и совершить поездку тогда, когда ему это необходимо, а также оперативность подачи машины и прибытие вовремя к месту назначения.
Основная задача диспетчерской службы заключается в принятии и обработки заявки на подачу такси, поиск свободной машины для отдачи заказа, а также сопровождение выполнения заказа. Диспетчер такси - это одна из самых ответственных профессий в службе такси, работа диспетчера такси - это, прежде всего, контроль за работой самого автопарка такси, отслеживание процесса нахождения каждой машины на линии, а также контроль подачи такси по вызову клиента точно в срок. И это далеко не все.
Важный момент в работе диспетчера такси - правильно оформить заказ на такси, передать его водителю и предупредить клиентов, что автомобиль такой-то марки, цвета и с таким-то государственным номером ожидает их в назначенном месте. На первый взгляд можно подумать, что ничего сложного в этой работе нет. Но на самом деле диспетчер такси является главным связующим звеном между клиентом и водителем такси. От работы диспетчера такси зависит судьба компании, количество довольных пассажиров[2].
Стало очевидным, что без ведения клиентской базы, без её сегментации, которая позволила бы предоставлять различные скидки, без контроля и анализа всей деятельности служб предприятия сделать компанию прибыльной и успешно развивающейся при имеющейся конкуренции в данной сфере становится практически невозможным. Для решения всего комплекса возникающих задач и проблем необходима единая информационная система, позволяющая взять под контроль работу диспетчеров служб такси, вести всю историю взаимоотношений с клиентами и многое другое.
1 Современные автоматизированные системы диспетчеризации такси
Диспетчерская — сердце и мозг работы службы такси. Слаженная команда операторов обеспечивает 90% успеха на высококонкурентном рынке пассажирских перевозок. Программная система для такси должна оптимизировать работу каждого сотрудника и обеспечить сбалансированное распределение нагрузки как на диспетчеров, так и на водителей службы. В то же время затраты на поддержание IT- и телекоммуникационной инфраструктуры компании сократятся в несколько раз[2]. Одной важной особенностью, которой должна обладать система для диспетчерской такси - максимально простой интерфейс. Сотрудники смогут обучиться работе с системой за рекордно короткое время. Администрирование комплекса не потребует специальных знаний: большинство настроек выполняется с помощью графических сценариев. Работа водителей ведется с использованием специального программного обеспечения такси gps gprs, устанавливаемого на android смартфон[2]. При этом затраты на связь минимальны в месяц на одного водителя.
Для того чтобы создаваемая система могла конкурировать с другими системами и могла обеспечить сотрудникам максимально комфортную работу, она должна удовлетворять ряду требований.
Для успешной и эффективной работы диспетчера система должна удовлетворять следующим требованиям:
- вызов поступает к диспетчеру такси, у диспетчера на экране монитора открывается автоматически созданная карточка заказа с уже заполненным номером телефона. В случае если владелец телефонного номера ранее обращался в службу такси, в форме заказа будут заполнены все поля с информацией о последних поездках клиента;
- должна определять местоположения автомобилей, а также показывать их статус (свободен, на заказе);
- возможность отдать заказ конкретной машине или группе машин находящихся поблизости заказа;
- рассчитывать стоимость заказа, а также дополнительных скидок, акций;
- возможность создавать отчеты за различные периоды;
- при отдаче заказа возможность указать комментарий с какой-то дополнительной информацией.
С точки зрения водителя транспортного средства система должна соответствовать требованиям:
- получение заказа, и возможность на него ответить(принять, отклонить, уточнить);
- просмотр всех активных заказов;
- изменение статуса работы;
- кнопка связи с заказчиком (удобно уточнять что-то сразу у заказчика, минуя связь с диспетчером и разгружая его);
- мгновенное получение стоимости заказа.
Важную роль играет актуальность такой системы, то есть за счет чего она приносит пользу в отрасли. В данном случае можно выявить большой список:
- повысить эффективность бизнес-процессов и управляемость компании;
- можно обрабатывать гораздо большее количество заказов, не увеличивая штат водителей и диспетчеров;
- программа позволит в режиме реального времени контролировать действия работников;
- моментальный расчет цены;
- расчет акций и скидок;
- полная наглядная информация;
- наличие истории поездок позволяет вести статистику;
- можно контролировать добросовестность клиентов, делать пометки о конфликтных клиентах, предупреждая водителей, о клиентах, которые имеют частый отказ от услуг и прочие характеристики.
Внедрение системы такси является неизбежным шагом развивающейся компании. Для легкости внедрения или интеграции с существующими системами система должна быть легковесной, не требовать много непонятных зависимостей. Должна быть аппаратно-свободной, и перенос системы не занимал бы много времени. Система должна сохранять консистентность данных при различных сбоях, как аппаратных, так и программных. Установка и поддержка серверной части должна быть максимально простой и не требовать круглосуточного наблюдения.
Конечно, такая система не является дефицитной, и уже существуют различные системы, которые решают такую задачу. Рассмотрим наиболее популярные из них.
1.1 Система диспетчеризации такси «МХК»
Первая система называется «МХК». Спектр задач данной системы намного шире требуемой. Система адаптирована под работу операторов с высоким уровнем квалификации. Также система способна записывать разговор со встроенным проигрывателем и возможностью сохранить разговор на жесткий диск. Хотя данная функциональность является излишней в данном случае. Сложный механизм индикации свободных автомобилей (зеленый, желтый и красный) и запутанный интерфейс. Возможно, такой механизм индикации свободных автомобилей и имеет преимущества, но он интуитивно не понятен. Данная система обладает высоким количеством поддерживаемых устройств для водителя, несомненно, это является плюсом, но сейчас у большинства водителей такси уже есть смартфон с gps на борту, и поддержка любых телефонов не имеет огромного преимущества. Нет возможности отдать заявку конкретному водителю, только отсылка заказа по районам. По заверению создателей системы - они имеют уникальную систему поощрений «кнут и пряник», что позволяет удержать ценные кадры и отсеять не качественный персонал. Гибкая система создания отчетов, имеет огромное количество настроек[3]. Над решением, по заявлению компании, работала огромная команда с различными отделами, даже был в наличии отдел R&D, который может позволить себе не всякая компания. Система изобилует возможностями построения различных отчетов, причем отчеты могут иметь как официальный характер, так и вывод различных показателей и диаграмм на экран системы. Решение является комплексным, нельзя выбирать какие-то отдельные модули и покупка идет также только со всем аппаратным и программным обеспечением. Таким образом, данная система имеет очень дорогостоящая. Существует два тарифных плана, но цены близки к миллиону рублей. Также отдельная плата за обслуживание 15, 30, 45 тысяч рублей в зависимости от степени услуг обслуживания[3].
1.2 Система диспетчеризации такси «МВК»
Следующая рассматриваемая система – «МВК». Она включает в себя множество модулей, которые можно выбрать по отдельности, что, несомненно, является плюсом. Также, по заверению создателей, систему можно расширять, но степень расширения достаточно ограничена и возможен конкретный набор расширений. Система не является дорогой относительно других, но у неё дорогая техническая поддержка. Система аппаратно независима, легкая установка. Интерфейс системы нагроможден, и его сможет понять только опытный работник, который проработал с ней много времени. Как видно из рисунка 1.1, она обладает множеством функций. Несомненно, это дает положительные рекомендации данной системе. Но почти весь функционал изображен на главной странице, и поэтому изначально сложно разобраться с наличием большого количества таблиц. Система реализована в виде веб-интрефейса, в качестве карт используются yandex карты. Наличие веб-интерфейса позволяет избавиться от установки разного софта, и работать на любом компьютере имеющем браузер[4].
Рисунок 1.1 - Интерфейс системы «МВК»
По заявлению разработчиков эта система может выдержать до 30000 автомобилей, поддерживает функции автономного поведения, когда, например водитель теряет связь с интернетом, идет общение через SMS.
С приложением водителя дела обстоят намного лучше. Приложение не имеет излишнего функционала. Как видно из рисунка 1.2 оно отображает только необходимую информацию в достаточно удобной форме. Также отображает карту[4].
Рисунок 1.2 - Приложение водителя системы «МВК»
Также из больших плюсов можно отметить, что система не требует специального мобильного ПО. Приложение распространяется под множество платформ и водителю не нужно иметь телефон с определенной операционной системой, как почти в каждой системе.
Для этой системы не нужны отдельные сервера, все работает в “облаке” у создателей системы. С одной стороны это несомненный плюс, так как не требуется дополнительных расходов, с другой это ненадежность существования системы, при её закрытии компания теряет все данные. Об отказоустойчивости серверов можно только догадываться, потому как обслуживать и иметь представление о проблеме и сроках её решения проще, когда управление серверами осуществляется именно в компании[4].
1.3 Система диспетчеризации такси «Везет»
Последняя из рассматриваемых систем – «Везет». Данная система имеет приятный интерфейс и большинство модулей и функционала уже включена в оплату. Есть триал версия для ознакомления. Содержит в себе платежные модули, что позволяет осуществлять безналичный расчет за услуги. На звонок клиента отвечает АТС, которая предлагает ему совершить поездку по одному из ранее использованных маршрутов. В этом случае, система может работать без участия оператора и, соответственно, без нагрузки на службу такси[5]. Нельзя это отнести к положительным или отрицательным сторонам системы, так как наличие этой функциональности с одной стороны разгружает диспетчеров, с другой стороны не все клиенты рады слышать автоответчик, а потом стоять в ожидании диспетчера. Система публикует заказ на сервере. Он становится доступным для исполнения каждому таксисту, у которого есть к нему доступ при помощи мобильного телефона с установленными на нем специализированными приложениями. Полный комплект такой программы стоит 250 тысяч рублей. Есть и более дешевые варианты, но они рассчитаны на совсем маленький набор модулей и без технической поддержки. В данную систему нельзя вносить доработки на заказ, и приходиться выбрать из того, что есть. Данная система не требует конкретного аппаратного обеспечения, но установка и перенос системы по заверению создателей системы не тривиален, и не разрешим местными системными администраторами[5].
Система имеет очень хорошую документацию и руководство пользователя, где прописаны практические все моменты работы программы, с наличием огромного количества скриншотов.
Но в системе есть мелкие недоработки, они не влияют на функционал, но оказывают неприятное воздействие на всю систему в целом. Иногда не понятен функционал нажатий кнопок и что повлечет за этим. На рисунке 1.3 можно увидеть вверху есть вкладка UpdateText 10, которой забыли дать название. По системе можно найти несколько таких моментов, где «забыли» дать нормальное название компонентам системы[5].
Рисунок 1.3 - Система «Везет»
1.4 Сравнительный анализ характеристик систем
В заключении описания существующих решений можно привести таблицу сравнения основных характеристик систем.
Таблица 1.1 - Сравнение основных характеристик систем
|
|
Везет |
МВК |
МХК |
Разрабатываемая система |
|
Простота интерфейса |
+- |
- |
- |
+ |
|
Аппаратная независимость |
+- |
+- |
- |
+ |
|
Разнообразие модулей |
+- |
+ |
+ |
+- |
|
Цена |
- |
+- |
- |
+ |
|
Расширение, доработка системы |
+- |
- |
- |
+ |
Посмотрев на таблицу можно сказать, что все системы схожи тем, что имеют громоздкий интерфейс. Набор модулей у систем весьма впечатляет, и достичь этого показателя очень сложно. Также можно сказать, что системы, которые существуют на рынке весьма дороги, предназначены для конкретной платформы, а некоторые поставляются и вместе с аппаратным обеспечением, что как раз увеличивает цену. Так как системы обладают большим количеством модулей, доработка систем практически невозможна, и многие не предоставляют такой услуги.
2 Проектирование и разработка программной системы диспетчеризации такси
2.1 Функциональная модель системы
При проектировании системы необходимо построить use case диаграмму, она приведена на рисунке 2.1. Диаграмма вариантов использования в UML это диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне[6].
Основное назначение диаграммы это описание функциональности и поведения, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать проектируемую или существующую систему.
При моделировании системы с помощью диаграммы прецедентов были определены действующие лица (актёры), их взаимодействие с системой и ожидаемый функционал системы[6].
В данном случае имеем 2 актёра - диспетчер и водитель. У диспетчера как видно больше прав и обязанностей. Водитель же получает только информацию о заказе и принимает решение, брать его или нет.
Рисунок 2.1 - Use Case диаграмма
Рисунок 2.2 - Диаграмма классов
Далее на рисунке 2.2 представлена диаграмма классов, на ней приведены не все классы, а только те, которые непосредственно реализуют нужный функционал, без вспомогательных классов. Для работы с базой данных был создан интерфейс BaseDAO (DAO расшифровывается как Data Access Object). Его реализует класс AbstactDAO, и он содержит в себе базовую реализацию доступа к данным. От него соответственно наследуются конктерные классы, которые отвечают за доступ к данным заказа, диспетчера, водителей, клиентов. Далее на более нижнем уровне расположены сервисы. Они отвечают за логику обработки данных и знают, что конкретно сделать. Они включают в себя конкретные объекты DAO. Точкой входа служит класс CommonEntryPoint, который играет роль распределения запросов от клиентов (диспетчера и водителя).
С помощь диаграммы прецедентов (вариантов использования) выявляются основные пользователи системы и задачи, которые данная система должна решать. С помощью диаграммы деятельности мы описываем последовательность действий для каждого прецедента, необходимую для достижения поставленной цели.
Одним из основных принципов ООП является способ информационного обмена между элементами системы, выражающийся в отправке и получении сообщений друг от друга. Таким образом, основные понятия диаграммы последовательности связаны с понятием Объект и Сообщение[7].
На диаграмме последовательности объекты в основном представляют экземпляры класса или сущности, обладающие поведением. В качестве объектов могут выступать пользователи, инициирующие взаимодействие, классы, обладающие поведением в Системе или программные компоненты, а иногда и Системы в целом.
На рисунке 2.3 изображена диаграмма последовательностей. На ней показано, в какой последовательности и как происходит взаимодействие между актёрами и системой.
Рисунок 2.3 - Диаграмма последовательностей прецедента «передача заказа»
На диаграмме изображены основные последовательности, такие как поиск клиента, если клиент найден можно приступить к заказу, иначе нужно создать нового клиента. В центре внимания находится последовательность оформления заказа, диспетчер вводит данные о заказе, и система создает его, далее диспетчер выбирает водителя (автомобиль), и идет процесс передачи заказа.
2.2 Проектирование серверной части на основе архитектуры взаимодействия REST
2.2.1 Хранилище данных
В качестве хранения данных выбрана реляционная база данных. Для начала изобразим схему базы данных.
Рисунок 2.4 – Схема базы данных
Каждая таблица необходима для выполнения конкретных функций. Перечислим из них самые важные.
В таблицу "заказы" заносятся все сведения о поступивших заказах: когда и от кого прибыл, какой диспетчер принял, и какой водитель будет исполнять заказ, имя и контактный телефон абонента, места отправления и назначения, статус и стоимость. На основании данных этой таблицы формируются все отчеты данного приложения: Сводный отчет по диспетчерам, Сводный отчет по водителю, "Чёрный список" и отчет диспетчера за смену. Атрибуты и их домены показаны на таблице 2.1.
Таблица 2.1 - Заказы
|
наименование атрибута |
тип данных |
описание |
|
номер заказа |
счетчик |
регистрирует порядковый номер заказа |
|
дата и время поступления заказа |
дата/Время |
генерируется автоматически |
|
дата и время назначения заказа |
дата/Время |
время, на которое назначен заказ |
|
место отправления |
текстовый |
вводиться вручную |
|
место назначения |
текстовый |
вводиться вручную |
|
абонент |
текстовый |
вводиться вручную |
|
телефон абонента |
тестовый |
так как при заполнении используются знаки препинания |
|
стоимость заказа |
денежный |
|
|
фамилия водителя |
текстовый |
|
|
статус |
текстовый |
принимает одно из трех значении: "Выполняется", "Выполнен", "Отменен" |
Таблицы "Водители" и "Диспетчеры" выполняют схожие функции - это хранение данных о сотрудниках, работающих в данном таксопарке, естественно данные различаются по специфике выполняемых операций. Например, у водителей существуют поля, в которых находятся сведения о транспортном средстве, а у диспетчеров наличие полей "Login" и "Password", так как они необходимы для входа в систему. Атрибуты таблиц "Водители", "Диспетчеры"и их домены представлены ниже (Таблица 2.2, Таблица 2.3).
Таблица 2.2 - Водители
|
наименование атрибута |
тип данных |
описание |
|
позывной |
числовой |
идентификационный номер |
|
ФИО |
текстовый |
фамилия водителя |
|
дата рождения |
дата/время |
дата рождения водителя |
|
паспорт |
числовой |
серия паспорта водителя |
|
адрес |
текстовый |
где фактически проживает водитель |
|
марка автомобиля |
текстовый |
марка автомобиля водителя |
|
номер автомобиля |
текстовый |
номер регистрации в ГАИ |
|
цвет |
текстовый |
Цвет автомобиля водителя |
Таблица 2.3 - Диспетчеры
|
наименование атрибута |
тип данных |
описание |
|
Табельный номер |
числовой |
идентификационный номер |
|
ФИО |
текстовый |
фамилия диспетчера |
|
дата рождения |
дата/время |
дата рождения диспетчера |
|
паспорт |
числовой |
серия паспорта диспетчера |
|
адрес |
текстовый |
где фактически проживает диспетчер |
|
login |
текстовый |
ник для входа в программу |
|
password |
текстовый |
индивидуальный код для входа в программу |
В качестве технологии доступа к данным был выбан Hibernate. Это наиболее популярный фреймворк для объектно-реляционного отображения, проверенный многими проектами, поэтому и был выбран.
Целью Hibernate является освобождение разработчика от значительного объёма сравнительно низкоуровневого программирования по обеспечению хранения объектов в реляционной базе данных. Разработчик может использовать Hibernate как в процессе проектирования системы классов и таблиц «с нуля», так и для работы с уже существующей базой данных[8].
Hibernate не только решает задачу связи классов Java с таблицами базы данных, но также предоставляет средства для автоматической генерации и обновления набора таблиц, построения запросов и обработки полученных данных и может значительно уменьшить время разработки, которое обычно тратится на ручное написание SQL. Hibernate автоматизирует генерацию SQL-запросов и освобождает разработчика от ручной обработки результирующего набора данных и преобразования объектов, максимально облегчая перенос (портирование) приложения на любые базы данных SQL[8].
Hibernate обеспечивает прозрачную поддержку сохранности данных, единственное строгое требование для сохраняемого класса это наличие конструктора по умолчанию. Для корректного поведения в некоторых приложениях требуется также уделить внимание методам equals() и hashCode().
Mapping (сопоставление) Java-классов с таблицами БД осуществляется с помощью конфигурационных XML файлов или Java-аннотаций. При использовании файла XML Hibernate может генерировать скелет исходного кода для классов длительного хранения. В этом нет необходимости, если используется аннотация. Hibernate может использовать файл XML или аннотации для поддержки схемы базы данных[9].
Обеспечиваются возможности по организации отношения между классами «один-ко-многим» и «многие-ко-многим». В дополнение к управлению связями между объектами, Hibernate также может управлять рефлексивными отношениями, где объект имеет связь «один-ко-многим» с другими экземплярами своего собственного типа данных.
Hibernate поддерживает отображение пользовательских типов значений. Это делает возможным такие сценарии:
- переопределение типа по умолчанию SQL, Hibernate выбирает при отображении столбца свойства;
- проецирование перечисляемого типа Java на поле БД, будто они являются обычными свойствами;
- проецирование одного свойства в несколько колонок.
В качестве реляционной СУБД выбрана MariaDB. MariaDB - ответвление СУБД MySQL, разрабатываемое сообществом. Толчком к созданию стала необходимость обеспечения свободного статуса СУБД, в противовес неопределенной политике лицензирования MySQL компанией Oracle. Основная цель проекта MariaDB - создание полностью бинарно совместимой с оригинальной MySQL версии СУБД, которая при этом будет иметь значительное количество улучшений в коде, влияющих на производительность. MariaDB разрабатывается как drop-in замена для MySQL, полностью имитируя поведение MySQL[10].
Как видно из рисунка 8, производительность MySQL и MariaDB приблизительно одинакова. Диаграмма позаимствована с официального сайта разработки MariaDB.
Рисунок 2.5 - Производительность СУБД
2.2.2 Архитектура интеграционного сервера
Основой данной системы является интеграционный сервер. Он предоставляет API к которому обращаются клиенты. Архитекрура построена на основе REST. REST - стиль построения архитектуры распределенного приложения. Был описан и популяризован в 2000 году Роем Филдингом, одним из создателей протокола HTTP. Данные в REST должны передаваться в виде небольшого количества стандартных форматов (например HTML, XML, JSON). Сетевой протоколдолжен поддерживать кэширование, не должен зависеть от сетевого слоя, не должен сохранять информацию о состоянии между парами «запрос-ответ». Утверждается, что такой подход обеспечивает масштабируемость системы и позволяет ей эволюционировать с новыми требованиями.Антиподом REST является подход, основанный на вызове удаленных процедур. Подход RPC позволяет использовать небольшое количество сетевых ресурсов с большим количеством методов и сложным протоколом. При подходе REST количество методов и сложность протокола строго ограничены, из-за чего количество отдельных ресурсов может быть большим[11].
REST-приложения часто создаются на основе сервлетов. Сервлеты не предписывают какие-либо конкретные походы к разработке. Как правило, сервлеты получают на обработку запросы, анализируют их заголовки, в том числе URI, чтобы определить, к какому ресурсу выполняется обращение. Ряд API был создан на основе этой простой модели сервлетов. Несмотря на все усилия по формализации, ни один из этих API не превратился в официальный стандарт.
В качестве реализации данного подхода был выбран фреймфорк Apache CXF. Apache CXF — открытый каркас для веб-сервисов Service Oriented Architectures, работающий с несколькими стандартными протоколами. Он задает унифицированный способ описания ресурсов на основе своей модели программирования. Он включает пять основных компонентов: корневые ресурсы, дочерние ресурсы, методы ресурсов, методы дочерних ресурсов и локаторы дочерних ресурсов[12].
Общая схема архитектуры системы представлена на рисунке 2.5.
Рисунок 2.5 - Общая схема архитектуры системы
Для того чтобы диспетчер не вводил каждый раз номер телефона, было решено сделать возможность использовать ASTERISK. Asterisk — свободное решение компьютерной телефонии (в том числе, VoIP) с открытым исходным кодом от компании Digium, первоначально разработанное Марком Спенсером. Приложение работает на операционных системах Linux, FreeBSD, OpenBSD и Solaris и др. Астериск в состоянии выполнять любые задачи связанные с телефонией, ну или практически любые. Есть ряд неудобств, либо ограничений, которые присущи работе с Астериском, постараемся их устранять в процессе ознакомления с системой[19].
С помощью него сервер узнает входящий номер, и выдает информацию по клиенту. Если в организации не предусмотрено использование ASTERISK, то диспетчера всегда может сделать данное действие вручную.
Далее, чтобы уведомлять клиентов, было необходимо использовать какой-то сервер автодозвона. Для этого был выбран CallSoft. Это решение компании Call Office подходит для автоматического информирования по телефону большого количества людей, например, в данном случае очень хорошо подходит под данную задачу.
Система оповещения может работать с одним из устройств по выбору: SIP-шлюз, обычный голосовой модем или GSM-модем с голосовыми функциями, — для оповещения по телефону клиентов. Речевое оповещение имеет высокую эффективность. Можно определить количество дозвонов при одном цикле прозвона или глобальное количество дозвонов для одного телефона с учетом этого количества в базе данных[20].
2.2.3 Cовременные концепции спутниковой системы навигации GPS и её использование в данной системе
GPS является системой навигации, основанной на сети спутников Navstar, выведенных на орбиту Министерcтвом обороны США. Система GPS первоначально была предназначена для военных задач, но в 1980 году правительство США сделало GPS доступной для гражданского использования. GPS работает в любых погодных условиях, в любой точке мира, 24 часа в сутки. Нет абонентской платы или других расходов на использование GPS[13].
Cпутники GPS обходят Землю дважды в сутки по одной и той же точной орбите и передают цифровую информацию. Приемники GPS собирают передаваемую информацию и посредством метода триангуляции вычисляют точную позицию пользователя. По существу, приемник GPS-сигнала сравнивает время, в которое был передан сигнал с временем, когда он был получен. Различия во времени дают возможность вычислить, на каком расстоянии находиться каждый спутник. Теперь, с расстояниями до нескольких спутников, GPS-приемник может определить свои точные координаты на поверхности Земли. GPS-приемник должен получать сигнал хотя бы 3-х спутников, чтобы вычислить двухмерную позицию (ширина и долгота). С четырьмя или большим количеством спутников GPS-приемник может вычислить трехмерную позицию пользователя (ширина, долгота и высота). Как только позиция пользователя определена, GPS-приемник может вычислить другую информацию, например скорость, направление движения, пройденное расстояние, расстояние до точки назначения, синхронизация времени, время восхода и захода солнца и многое другое. Ошибка в определении координат относительно ранее зафиксированной точки составляет всего 10-20 метров, скорости 2 - 3 км/час. В случае измерения координат позиции GPS-приемника относительно только что занимаемой позиции, точность значительно возрастает. Этого вполне достаточно для большинства случаев, хотя при использовании режима дифференциальных поправок точность определения координат может быть существенно выше[13].
Для отслеживания GPS устройств необходимо специальное устройство. Но также можно воспользоваться специальным бесплатным сервисом http://orange.gps-trace.com. На рисунке 2.6 можно увидеть его интерфейс.
Рисунок 2.6 - Сторонний сервис GPS
Используя сторонний сервис, там заводятся все устройства водителей и используя их API с сервера можно получать координаты водителя.
2.3 Проектирование клиентских частей диспетчера и водителя, используя AJAX архитектуры
2.3.1 Клиентская часть диспетчера
В качестве технологии реализации клиента диспетчера был выбран HTML+javascript. Во главе взаимодействия с сервером стоит технология AJAX, она осуществляется на языке javascript.
AJAX - подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером. В результате, при обновлении данных веб-страница не перезагружается полностью, и веб-приложения становятся быстрее и удобнее[14].
AJAX — не самостоятельная технология, а концепция использования нескольких смежных технологий. AJAX базируется на двух основных принципах:
1) использование технологии динамического обращения к серверу «на лету», без перезагрузки всей страницы полностью, например:
- с использованием XMLHttpRequest (основной объект);
- через динамическое создание дочерних фреймов;
- через динамическое создание тега <script>;
- через динамическое создание тега <img>, как это реализовано в google analytics.
2)использование DHTML для динамического изменения содержания страницы.
Действия с интерфейсом преобразуются в операции с элементами DOM, с помощью которых обрабатываются данные, доступные пользователю, в результате чего представление их изменяется. Здесь же производится обработка перемещений и щелчков мышью, а также нажатий клавиш. Каскадные таблицы стилей, или CSS, обеспечивают согласованный внешний вид элементов приложения и упрощают обращение к DOM-объектам. Объект XMLHttpRequest используется для асинхронного взаимодействия с сервером, обработки запросов пользователя и загрузки в процессе работы необходимых данных[14].
В качестве формата передачи данных могут использоваться фрагменты простого текста, HTML-кода, JSON или XML.
Преимущества использования AJAX:
1) экономия трафика. Использование AJAX позволяет значительно сократить трафик при работе с веб-приложением благодаря тому, что вместо загрузки всей страницы достаточно загрузить только изменившуюся часть, или вообще только получить/передать набор данных в формате JSON или XML, а затем изменить содержимое страницы с помощью javascript[14];
2) уменьшение нагрузки на сервер. При правильной реализации, AJAX позволяет снизить нагрузку на сервер в разы. В частности, все страницы сайта чаще всего генерируются по одному шаблону, включая неизменные элементы для генерации, которых требуются обращения к разным файлам, время на обработку скриптов, всё это можно опустить, если заменить полную загрузку страницы генерацией и передачей лишь содержательной части. Дизайн страницы также обычно содержит множество файлов, связанных с оформлением, на повторную обработку которых не надо тратить время, используя AJAX[14];
3) ускорение реакции интерфейса. Поскольку загрузка изменившейся части значительно быстрее, то пользователь видит результат своих действий быстрее и без мерцания страницы (возникающего при полной перезагрузке);
4) возможности для интерактивной обработки. Например, при вводе поискового запроса в Google выводится подсказка с возможными вариантами запроса. AJAX удобен для программирования чатов, административных панелей и других инструментов, которые выводят меняющиеся со временем данные[14].
На рисунке 2.7 можно увидеть сравнение двух разных архитектур запроса клиента к серверу или способа загрузки данных. С левой стороны изображен традиционный подход, при котором уходит HTTP запрос (новая страница, форма с данными), в результате чего всегда возвращается страница полностью, даже если при запросе изменился небольшой участок данных. В правой половине рисунка изображен AJAX подход к запросам. На странице запросы посылаются с помощью javascript, методы возвращают данные, данные также обрабатываются с помощью этого языка, далее они также динамически подгружаются на страницу, без её полной перезагрузки.
Рисунок 2.7 - Сравнение архитектур запросов клиента к серверу
Для более правильной верстки и более удобного пользовательского интерфейса было принято решение использовать Twitter Bootstrap.
Twitter Bootstrap - свободный набор инструментов для создания сайтов и веб-приложений. Включает в себя HTML и CSS шаблоны оформления для типографики, веб-форм, кнопок, меток, блоков навигации и прочих компонентов веб-интерфейсов, включая javascript расширения[15].
Bootstrap использует самые современные наработки в области CSS и HTML, поэтому необходимо быть внимательным при поддержке старых браузеров.
Основные инструменты Bootstrap:
- сетки - заранее заданные размеры колонок, которые можно сразу же использовать, например ширина колонки 140px относится к классу .span2, который можно использовать в CSS описании документа;
- шаблоны - фиксированный или резиновый шаблон документа.
Далее показан простейший пример его подключения.
<!DOCTYPE html>
<html>
<head>
<title>Bootstrap 101 Template</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- Bootstrap -->
<link href="css/bootstrap.min.css" rel="stylesheet" media="screen">
</head>
<body>
<h1>Hello, world!</h1>
<script src="http://code.jquery.com/jquery.js"></script>
<script src="js/bootstrap.min.js"></script>
</body>
</html>
2.3.1 Проектирование и разработка Android клиента для водителя
Android - бесплатная операционная система, основанная на Linux с интерфейсом программирования Java. Операционная система создана альянсом Open Handset Alliance, возглавляемым компанией Google. Для разработки имеются все необходимые инструменты - компилятор, отладчик и эмулятор устройства, а также собственная виртуальная машина Java(DALVIK). Между приложением и ядром существует слой API и слой библиотек на нативном коде[16].
Dalvik Virtual Machine использует свой особенный байткод. Поэтому у Вас не получится запустить стандартный байткод Java на Android. Android предоставляет инструмент «dx», который позволяет конвертировать файлы Java Class в файлы «dex». Android-приложения пакуются в файлы .apk программой «aapt». ADT выполняет автоматическое преобразование из файлов Java Class в файлы dex, и создает apk во время развёртывания[16].
Android поддерживает 2D и 3D-графику, используя библиотеки OpenGL, а также хранение данных в базе данных SQLite.
Каждое Android-приложение запускается в своем собственном процессе и под своим собственным userid, который автоматически генерируется Android во время развертывания. Поэтому приложение изолировано от других запущенных приложений, и неправильно работающее приложение не может беспрепятственно навредить другим Android-приложениям.
На телефоне, в отличие от настольных компьютеров, только одно окно программы занимает экран.
Для начала необходимо рассмотреть жизненный цикл приложения.
Рисунок 2.8 - Жизненный цикл Android приложения
Жизненный цикл приложения в Android жестко контролируется системой и зависит от нужд пользователя, доступных ресурсов и т. д. Например, пользователь хочет запустить браузер. Решение о запуске приложения принимает система. Хотя последнее слово и остается за системой, она подчиняется определенным заданным и логическим правилам, позволяющим определить, можно ли загрузить, приостановить приложение или прекратить его работу. Если в данный момент пользователь работает с определённым окном, система дает приоритет соответствующему приложению. И наоборот, если окно невидимо и система решает, что работу приложения необходимо остановить, чтобы мобилизовать дополнительные ресурсы, будет прекращена работа приложения, имеющего более низкий приоритет. В Android ресурсы более ограниченны, поэтому Android более жёстко контролирует работу приложений[16].
Наше приложение состоит из различных элементов : карта, меню, кнопки и так далее. Их необходимо как-то располагать. Существует множество типов контейнеров, позволяющие располагать элементы разными способами.
Компоновка хранится в виде XML-файла в папке /res/layout. Это сделано для того, чтобы отделить код от дизайна, как это принято во многих технологиях (HTML и CSS). Кроме основной компоновки для всего экрана, существуют дочерние элементы компоновки для группы элементов. По сути, компоновка – это некий визуальный шаблон для пользовательского интерфейса приложения, который позволяет управлять элементами управления, их свойствами и расположением. Кроме того, разметку можно создавать программным способом. В данном случае идет обращение к элементам управления через Java-код, таким образом необходимо присваивать элементам уникальный идентификатор через атрибут android:id. Сам идентификатор назначается через выражение @+id/yourvalue. После этого вы можете обращаться к элементу через код при помощи метода findViewById(R.id.yourvalue)[16].
Создавая пользовательский интерфейс в XML-файле, можно отделить представление приложения от программного кода. Можно изменять пользовательский интерфейс в файле разметки без необходимости изменения вашего программного кода. Например, вы можете создавать XML-разметки для различных ориентаций экрана мобильного устройства (portrait, landscape), размеров экрана и языков интерфейса.
Каждый файл разметки содержит только один корневой элемент компоновки, который должен быть объектом View или ViewGroup. Внутри корневого элемента вы можете добавлять дополнительные объекты разметки или виджеты как дочерние элементы, чтобы постепенно формировать иерархию элементов, которую определяет создаваемая разметка[16].
Взаимодействие с сервером также осуществляется запросами к REST сервисам. Обработка данных идет аналогично клиентской части диспетчера. Для отображение карты используется yandex карта.
Для примера можно показать класс активности(так называется любое окно):
public class MainActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_test);
layout.setonclickListener(onViewClickListener);
imageView.setonclickListener(onViewClickListener);
}
onclickListener onViewClickListener = new onclickListener() {
@Override
public void onclick(View v) {
//todo
}
};
}
Таким образом создается любое окно и навешиваются обработчики.
3 Реализация геоинформационной системы диспетчеризации Екатеринбургского такси
Для более ясной работы, реализованное программное средство имеет несколько основных сценариев поведения:
- заявка на заказ такси;
- завершение заказа;
- уведомление клиентов;
- отмена заказа такси;
- «простой» заказанного такси.
Основной пункт, это заявка на заказ такси, она происходит следующим образом:
1)поступает звонок от клиента, диспетчер вводит в поиск номер телефона(Asterisk);
2) находит данные клиента, если его нет, то просит представиться, и создает нового;
3) спрашивает пункт начала движение и пункт назначения. Сообщает – «Как машина найдется, придет уведомление»;
4) диспетчер нажимает «Добавить заказ», система автоматически ищет ближайшего водителя и отдает заказ ему;
5) водитель принимает заказ (в приложении пишет примерное время прибытия), клиент получает уведомление.
Далее идет дальнейшая обработка заказа, и этап завершения заказа:
- водитель, подъехав к клиенту, в приложении нажимает на кнопку «На месте»;
- клиенту приходит уведомление о том, что можно выходить;
- после того как водитель забирает клиента, нажимает кнопку «В пути»;
- по завершению заказа, водитель из приложения ставит статус «Свободен».
В ходе работы, может возникнуть ситуация отмены такси, и дальнейшие действия будут развиваться следующим образом:
- Клиентом:
1) звонок диспетчеру, диспетчер в программе отменяет заказ, водитель переходит в статус «свободный»;
2) говорит водителю, водитель из приложения отменяет заказ.
- Такси:
водитель отменяет заказ (авария, поломка), переходит в статус «Недоступен».
Также в ходе работы, клиент может запоздать, и случится простой автомобиля, за который необходимо будет заплатить, и это будет совершаться по следующей схеме:
- для расчета простоя берется время ожидания водителя (после нажатия кнопок «На месте» и «В пути»);
- идет уведомление клиента о времени простоя и дополнительной оплате.
При открытии системы, диспетчер видит форму входа, изображенную на рисунке 3.1.
Рисунок 3.1 - Форма входа в систему
После входа в систему диспетчер видит главное окно программы.
В нем он видит карту с текущими водителями, синяя - свободен, красная - занят. Также есть поле ввода, чтобы найти клиента в базе. Можно добавить нового клиента.
Рисунок 3.2 - Главное окно программы
Далее представлено окно, с которым работает диспетчер, на нем есть строка поиска, информация о клиенте, если он выбран, карта с водителями, и интерфейс добавления заказа. На карте, как выше сказано, можно видеть водителей, причем, если значок синий - водитель свободен от заказа, если значок красный - то на заказе.
Рисунок 3.3 - Работа с водителями
При нажатии на любую машину можно просмотреть информацию о водителе. Для примера была занесена информация об именах водителей. Но информация может быть совершенно любой, например марка машины, цвет, номер и прочие примечания. В данный момент отображаются только водители, которые готовы к заказу, то есть у них включено приложение и GPS.
Рисунок 3.4 - Добавление нового клиента
Для добавления нового клиента необходимо нажать кнопку добавить, появится всплывающее окно, в котором необходимо ввести данные. Особое внимание следует уделить полю комментарий, оно является собирательным и содержит информацию, не принадлежащую остальным полям.
Рисунок 3.5 - Поиск клиента
Для поиска клиента необходимо ввести его номер телефона, если телефон не определен (что является очень редким случаем), то можно делать заказ не выбирая клиента.
Рисунок 3.6 - Оформление заказа
Оформление заказа является важным шагом, и включает в себя ввод начальной-конечной точек, и передачу заказа водителю. С точки зрения разработки это тоже интересный этап. Визуальное отображение задается клиентским кодом.
ptp.getDirections = function () {
if (this._start && this._finish) {
var self = this,
start = this._start.geometry.getCoordinates(),
finish = this._finish.geometry.getCoordinates();
if(this._route) {
this._map.geoObjects.remove(this._route);
}
ymaps.geocode(start, { results: 1 })
.then(function (geocode) {
var address = geocode.geoObjects.get(0) &&
geocode.geoObjects.get(0).properties.get('balloonContentBody') || '';
ymaps.route([start, finish])
.then(function (router) {
var distance = Math.round(router.getLength() / 1000),
message = '<span>Расстояние: ' + distance + 'км.</span><br/>' +
'<span style="font-weight: bold; font-style: italic">Стоимость проезда: %sр.</span>';
self._route = router.getPaths();
self._route.options.set({ strokeWidth: 5, strokeColor: '0000ffff', opacity: 0.5 });
self._map.geoObjects.add(self._route);
self._start.properties.set('balloonContentBody', address + message.replace('%s', self.calculate(distance)));
self._start.balloon.open();
});
});
}
};
Также весьма интересна работа и с начальной и конечной точками. Работа с ними осуществляется следующим кодом:
ptp.setStartPoint = function (position) {
if(this._start) {
this._start.geometry.setCoordinates(position);
}
else {
this._start = new ymaps.Placemark(position, { iconContent: 'А' }, { draggable: true });
this._start.events.add('dragend', this._onDragEnd, this);
this._map.geoObjects.add(this._start);
}
this.getDirections();
};
ptp.setFinishPoint = function (position) {
if(this._finish) {
this._finish.geometry.setCoordinates(position);
}
else {
this._finish = new ymaps.Placemark(position, { iconContent: 'B' }, { draggable: true });
this._finish.events.add('dragend', this._onDragEnd, this);
this._map.geoObjects.add(this._finish);
}
this.getDirections();
};
Расчет же стоимости относительно тривиален, и зависит от киллометрожа и минимальной стоимости.
Следующий метод выполняет необходимые расчеты:
ptp.calculate = function (len) {
// Константы.
var DELIVERY_TARIF = 20,
MINIMUM_COST = 60;
return Math.max(len * DELIVERY_TARIF, MINIMUM_COST);
};
Рисунок 3.7 - Передача заказа водителю
Что касается водителя, он имеет свое приложение на Android.
На следующем рисунке представлена форма входа в android приложение для водителя.
Рисунок 3.8 - Экран входа в андроид приложение водителя
Приложение весьма простое для использования. Имеет всего 2 вкладки это : Главная и Заказы. На рисунке 3.9 можно увидеть экран заказы.
Рисунок 3.9 - Экран «заказы» у водителя
На этом экране он видит свой заказ, на карте уже проложен маршрут, также на карте для удобства расположены и другие водители. В этом заказе можно увидеть стоимость, данные о клиенте и также прописано название начальной-конечной точки. На главной странице отображаются произвольные общие новости, и уведомления. Такое может понадобиться, например, для уведомления всех водителей о смене графика, плана работ, опасных ситуациях в городе и прочих новостях.
Заключение
Завершая данную работу можно сказать, что существует огромное количество разнообразных систем диспетчеризации такси. Они имеют огромное количество модулей, реализаций и большую продуманную схему. Несмотря на это, у них также существуют свои недостатки. Был проделан анализ существуеющих решений, который показал, что есть и отрицательные моменты, и создавая систему лишенную их, даже может не делая все пункты замечательными, система имеет право на жизнь.
В ходе работы была спроектирована база данных предметной области, составлены нужные диаграммы, благодаря которым был выявлен нужный функционал, действия, и разработан дальнейший план действия. Была разработана архитектура, способы взаимодействия компонентов системы. Была изучена работа с GPS, благодаря которой был найден сторонний сервис для удобной работы и имеющий свой API для работы с ним, в котором заводятся водители системы.
Также, сталкиваясь с необходимостью еще улучшить автоматизацию рабочего места, были приняты решения произвести работы с Asterisk, и выбран сторонний сервис дозвона, который используется в качестве уведомлений для клиентов.
Итогом данной работы является программное средство, которое содержит базовый функционал для работы диспетчерской, которое может легко дорабатываться в плене функционала и не является сильно громоздким, что делает данное решение подходящем для небольших фирм такси.
Список использованных источников
1 Ципилева Т.А. Геоинформационные системы: Учебное пособие/ Ципилева Т.А. – СПб.: БХВ-Петербург, 2009. – 163 с.
2 Гришин, О.К. Основы диспетчеризация работы такси/ О.А. Гришин, О.К.. – М.: Фирма «Контракт», 2010. – 304с.
3 МХК. Система автоматизации диспетчерских такси нового поколения [Электронный ресурс] – Режим доступа: http://www.teleМХК.ru.
4 МВК. Система автоматизации диспетчерских такси МВК. [Электронный ресурс] – Режим доступа: http://www.taxamobile.ru.
5 Везет. Программный комплекс такси. [Электронный ресурс] – Режим доступа: http://pkautopilot.ru.
6 Орлов С.А. Технологии разработки программного обеспечения / С. А. Орлов, Цилькер Б. Я. - СПб.: Питер, 2012. – 608 с.
7 Пирогов, В.Ю. Информационные системы и базы данных/ В.Ю.
Пирогов, Б.А. Новиков, В.А. Костин. – СПб.: БХВ-Петербург, 2009. – 528 с.
8 Лутц, М. Learning Hibernate: пер. с англ.; Под ред. А. Киселева/М. Лутц. – М.: Символ-плюс, 2011. – 1280 с.
9 Кренли, Р. Изучаем работу с SQL/ Р. Бенедетти, Р. Крэнли. – СПб.: Питер, 2012. – 528 с.
10 Gowda, K. C. Intro in MariaDB / Gowda, K. C., Pattern Recognition, 2013. V. 10. P. 105 – 112.
11 Bezdek, J. C. Restfull Service in Web programming – NY: Plenum Press, 2011.
12 Pilgrim, Apache CXF. First Steps/ M. Pilgrim. – NY: Apress, 2009. – 363.
13 GPS navigation[Электронный ресурс] – Режим доступа: http://gps.about.com.
14 Николас Закас. Ajax для профессионалов / Николас Закас - СПб.: Питер, 2012. – 302 с.
15 Twitter Bootstrap [Электронный ресурс] – Режим доступа: http://bootstrap-ru.com.
16 Перри Никапс. Starting Android develop/ Перри Никапс - СПб.: Питер, 2011. – 601 с.
17 Joshua Bloch. Effective Java (2nd Edition) / Joshua Bloch - Addison-Wesley, 2008. – 346 с.
18 Bezdek, J. C. Java in Action/Bezdek, J. C. – NY: Plenum Press, 2009.
19 Джаред Смит. Asterisk. Будущее телефонии/Джаред Смит. – NY: Plenum Press, 2009.
20 CallSoft - сервис автовозвона [Электронный ресурс] – Режим доступа: http://callsoft.ru.
Скачать: