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

4

ВЫПУСКНАЯ РАБОТА БАКАЛАВРА

Тема: Разработка службы курьерской доставки в мобильном приложении



Оглавление

Список иллюстраций

Используемые сокращения и определения

Введение

1. Анализ предметной области

1.1 Концепция Службы

1.2 Анализ существующих решений

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

2.1 Алгоритм формирования заказа и поиска курьера

2.2 Алгоритм выполнения курьерского заказа

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

3.1 Архитектура серверной части системы

3.2 Выбор оптимальной базы данных для разрабатываемой системы

3.3 Архитектура мобильных приложений

3.4 Средства разработки мобильных приложений

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

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

4.2 API для работы с мобильными приложениями

4.3 Структура Android приложения

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

Заключение. Анализ результатов работы



Список иллюстраций

приложение курьерский мобильный серверный

Рисунок 1: анализ существующих решений

Рисунок 2: алгоритм поиска курьера

Рисунок 3: алгоритм выполнения курьерского заказа

Рисунок 4: обобщенная схема MVC архитектуры

Рисунок 5: наглядная разница двух паттернов MVC и MVP

Рисунок 6: структуры разработанной базы данных

Рисунок 7: иерархия классов API

Рисунок 8 метод получения данных о клиенте PHP

Рисунок 9: метод получения данных о клиенте Java

Рисунок 10: классы компонента паттерна MVP - Model

Рисунок 11: классы компонента паттерна MVP - View

Рисунок 12: классы компонента паттерна MVP - Presenter

Рисунок 13: жизненный цикл активности (экрана в android приложении)

Рисунок 14: XML разметка класса WebActivity

Рисунок 15: java код для XML разметки WebActivity

Рисунок 16: меню с функциями управления для клиентского и курьерского приложения

Рисунок 17: управление аккаунтами для клиентского и курьерского приложения

Рисунок 18: экраны для заполнения информации об отправителе и получателе

Рисунок 19: экраны для заполнения более подробной информации о заказе

Рисунок 20: экраны ожидания заказа в клиентском и курьерском приложениях

Рисунок 21: курьер едет в точку “А” в клиентском и курьерском приложениях

Рисунок 22: встроенный в приложение планшет для получения подписи отправителя (получателя)

Рисунок 23: курьерское приложение в развернутом режиме во время выполнения заказа

Рисунок 24: мобильные приложения в режиме выставления взаимных оценок клиентом и курьером



Используемые сокращения и определения

Сокращение	Определение
Точка А	Пункт отправления посылки (отправитель или организация-отправитель).
Точка Б	Место получения посылки (получатель или организация-получатель).
Служба	Служба курьерской доставки в мобильном приложении
HTTP	HyperTextTransferProtocol -- «протокол передачи гипертекста» -- протокол прикладного уровня передачи данных на основе клмент-серверной модели.
API	ApplicationProgrammingInterface. Интерфейс взаимодействия приложений на программном уровне.
MVC	Model-View-Controller (MVC) -- схема разделения данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: модель, представление и контроллер
MVP	Model-View-Presenter (MVP) -- шаблон проектирования, производный от MVC, который используется в основном для построения пользовательского интерфейса.



Введение

Обоснование актуальности

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

Технологии всё глубже внедряются в нашу жизнь. Мы хотим быть в курсе всех интересующих нас событий даже находясь вдалеке от компьютера. В этом нам помогают мобильные телефоны. Мобильный телефон уже давно не является только средством для совершения или принятия звонков, все чаще он используется, как инструмент для решения повседневных задач таких доставка посылки, рабочей документации или наконец просто пиццы. Причем в случае мобильной службы курьерской доставки выигрывают не только клиенты, которые в два клика могут заказать доставку или компании, которым не нужно заниматься поиском курьеров или заключать договор с службами курьерской доставки, но и сами курьеры которые благодаря использованию мобильных технологий могут избежать таких проблем как трата времени на заполнение отчетной документации, а также на постоянные поездки в офис для отчета. Ведь вся информация о состоянии заказа отправляется на сервер и доступна в любой момент. По сути для того чтобы стать курьером, достаточно просто скачать приложение. Это делает работу курьером не навязчивой. Студент может доставить документы по дороге на учебу. Любой человек с автомобилем может доставить посылку по дороге на работу и заработать. Кроме того, если вы, заказали нескольких курьеров по нескольким адресам, больше не нужно лично обзванивать всех получателей и сообщать номер телефона курьера. Номера телефонов отправителя и получателя автоматически попадают на мобильные приложения.

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

Цели и задачи

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

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

1. Рассмотрение существующих решений в данной предметной области и обоснование актуальности данной работы.

2. Разработка основных сценариев поведения службы.

3. Проектирование архитектуры серверной части, а также архитектуры мобильных приложений.

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

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

Краткое содержание работы

Работа содержит 5 глав.

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

Глава 2 описывает алгоритмы формирования и выполнения заказа и описывает модель поведения приложений на разных этапах выполнения курьерского заказа.

Глава 3 включает в себя выбор и проектирование архитектуры серверной части, а также проектирование архитектуры мобильных приложений.

Глава 4 описывает программную реализацию разработанной в предыдущей главе системы приложений.

Глава 5 содержит проверку выполнения разработанных сценариев для реализованной системы.



1. Анализ предметной области

1.1 Концепция Службы

Основная концепция - “Доставка день в день”, организовать курьерскую службу, не потратившись на штат курьеров.

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

Как это работает?

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

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

Если доставка оплачивается наличными при получении, то деньги за доставку курьер оставляет себе, а комиссию Службы он переводит через платежный терминал (например, Qiwi или «Элекснет»).

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

Рейтинг курьера

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

Аудитория

Служба ориентирована на небольшие интернет-магазины и компании, частных предпринимателей, продавцов из Avito, ВКонтакте и Instagram и конечно же обыкновенные люди (доставка цветов, пиццы и т.д.) Эта аудитория не так требовательна к IT-интеграции, поскольку количество заказов невелико и позволяет делать заявки в ручном режиме.

Пионером на рынке краудсорсинговой доставки считается американский стартапPostmates. Он был основан в 2011 году БастианомЛеманом. За четыре года работы компания в несколько раундов привлекла $58 млн инвестиций. Сейчас Postmates осуществляет около 50 тыс. доставок в неделю. Доход Postmates формируется из комиссии в размере 20% от стоимости доставки и 9% от общей стоимости заказа.

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



1.2 Анализ существующих решений

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

1.2.1 Достависта

Проект «Достависта» стартовал в октябре 2012 года. Ключевая бизнес-идея состоит в том, что курьерами работают не профессионалы, а студенты, пенсионеры, все желающие -- они доставляют товар по пути, в удобное для них время. Чтобы стать курьером в «Достависте», надо скачать мобильное приложение (есть в iOs и Android), заполнить в нем свой профиль (персональные данные, загрузить фотографию и скан первого разворота паспорта), а потом ответить на ряд вопросов сервиса по телефону. После этого можно брать заказы, которые оплачиваются наличными. Если курьер хочет работать с заказами, оплачиваемыми безналичным путем, то ему надо заключить с сервисом договор подряда.

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

Плюсы:

- надежность. Существует система страхования товара (0,9%);

- система рейтингов. Для мотивации курьеров;

- собственный call-центр;

- приложения под все основные мобильные платформы (iOS, Android, WindowsPhone).

Минусы:

- сложность регистрации курьеров;

- сложность вывода денег;

- отсутствие клиентского мобильного приложения.

1.2.2 Bringo

В отличие от «Достависты» в Bringo создали сразу два мобильных приложения -- одно для курьеров, другое для заказчиков. Кроме того, у сервиса есть 40 штатных курьеров -- они выполняют заказы, за которые не берутся фрилансеры. Вознаграждение Bringo -- 19% от стоимости доставки. Деньги за свою работу курьер получает на банковскую карту или на виртуальный счет в системе. Он может взяться за выполнение заказа, если сумма на его счету или карте превышает объявленную стоимость доставки -- она блокируется в качестве гарантии. Базовая стоимость доставки в Bringo составляет 180 руб., но растет в зависимости от того, сколько времени курьер проводит в пути (за час уже 390 руб.).

Плюсы:

- наличие штатных курьеров, способных выполнить долго “висящий” заказ;

- приложения под все основные мобильные платформы (iOS, Android, WindowsPhone).

Минусы:

- вознаграждение ниже чем у конкурентов;

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

- работа только по Москве;

- стоимость заказа варьируется от времени.

1.2.3 Пешкарики

Еще один похожий сервис называется «Пешкарики». Его создатель Дмитрий Петров в отличие от своих коллег из Bringo и «Достависты» не понаслышке знал о проблемах доставки для интернет-магазинов. В интернет-бизнесе он с 2003 года, в его активе -- IT-платформа по SEO-оптимизации и интернет-магазин по продаже запчастей для скутеров.

У «Пешкариков» базовая стоимость доставки день в день -- 350 руб., на следующий день -- 220 руб. С этих денег сервис получает 10-15% (новые курьеры платят больше). Плюс продавец выплачивает 1% от объявленной стоимости товара «Пешкарикам», если товар предоплачен, и 2%, если курьер должен получить наличные. В сервисе этот сбор называют страховкой; он делится поровну между «Пешкариками» и курьером.

Плюсы:

- высокое вознаграждение для курьеров;

- приложения под все основные мобильные платформы (iOS, Android, WindowsPhone).

Минусы:

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



Рисунок 1 анализ существующих решений



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

2.1 Алгоритм формирования заказа и поиска курьера

Рисунок 2 алгоритм поиска курьера

Весь процесс классически начинается со стороны клиентского приложения.

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

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

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

Для того чтобы максимально упростить выбор адресов отправителя и получателя, в клиентском приложении интегрирован Google Maps Geocoding API. При поиске адреса через поисковую строку, система по первым буквам подбирает ближайшие адреса в радиусе 25 км. Также пользователь может указать адрес прямо на карте.

Заполнив форму, клиенту будет предложено выбрать метод оплаты (наличные или кредитная карта). Стоимость заказа рассчитывается мгновенно, при любом изменении формы заказа на сервер отправляется запрос с обновленными параметрами заказа, а в ответ возвращается пересчитанная сумма заказа. После выбора способа оплаты и подтверждения клиентом заказа по смс на сервер отправляется запрос о добавлении заказа в базу данных, и поиска курьера. Клиенту приходит Push уведомление о том, что заказ принят к исполнению, на экране виден статус “Поиск курьера”.

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

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

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



2.2 Алгоритм выполнения курьерского заказа

Рисунок 3 алгоритм выполнения курьерского заказа

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

Для обоих приложений алгоритм выполнения делится на четыре этапа:

- курьер едет в точку А;

- курьер прибыл в точку А;

- курьер едет в точку Б;

- курьер доставил посылку.

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

Этап “Курьер выехал в точку А” начинается сразу после подтверждения курьером принятия заказа. Курьерское приложение отправляет запрос на сервер с соответствующим статусом. По прибытии на место, курьер должен уведомить отправителя о том, что он прибыл на место нажав на кнопку “Я на месте”.

В курьерском приложении предусмотрена защита на случай, если курьер случайно или еще по каким-либо причинам раньше нажмет на кнопку. Как было сказано выше, в обычном режиме, координаты пользователя получаются путем пассивного трекинга, но в случае смены статуса, приложение пошлет один точный GPS запрос о местоположении пользователя, и передаст эти данные на сервер. Таким образом если расстояние от устройства курьера до точки “А” будет больше, например, 1000 метров, курьер получит соответствующее уведомление.

Также на этом этапе курьеру будет представлена возможность перейти из приложения в навигатор (на момент написания работы в приложение интегрированы Яндекс навигатор и Citymapper).

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

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

На экране клиентского приложения статус выполнения меняется на соответствующий.

Этап “Курьер выехал в точку B” по функционалу похож на этап “Курьер выехал в точку А”. Курьеру также дается возможность перейти в навигатор. Так в обоих приложения есть возможность связи с курьером (клиентом). В клиентском приложении на протяжении всего этапа происходит отображение местоположения курьера. По прибытии курьера к получателю, он также, как и на этапе “курьер прибыл в точку А”, получает подпись получателя. Чтобы завершить заказ, в приложении, необходимо нажать на кнопку “Доставлено”, при этом на сервер будет отправлен статус о завершении заказа.

На этапе “курьер доставил посылку” оба приложения перейдут в режим оценки. Клиент может, по желанию, оценить клиента и оставить ему отзыв. Что в дальнейшем будет влиять на рейтинг курьера. Курьер соответственно может также оценить клиента.



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

3.1 Архитектура серверной части системы

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

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

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

- возможность быстрого внесения изменений в систему;

- масштабируемость;

- тестируемость;

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

- удобство сопровождения кода.

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

Для обеспечения масштабируемости, тестируемости и конфигурируемости используют архитектуру Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер»). Такая архитектурная модель программного комплекса позволяет отделить графический интерфейс от бизнес логики, а бизнес логику от данных. Таким образом, в классическом варианте, MVC состоит из трех частей. Рассмотрим их подробнее:

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

Модель обладает следующими признаками:

- Модель -- это бизнес-логика приложения;

- Модель обладает знаниями о себе самой и не знает о контроллерах и представлениях;

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

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

Представление обладает следующими признаками:

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

- В мобильном приложении представление необходимо для отображения данных хранящихся в модели.

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

В Android приложении контроллер обычно представляется классом Activity, Fragment или Service



Рисунок 4 обобщенная схема MVC архитектуры

К недостаткам архитектуры MVC можно отнести:

- необходимость использования большего количества ресурсов. Сложность обусловлена тем, что все три фундаментальных блока являются абсолютно независимыми и взаимодействуют между собой исключительно путем передачи данных. Controller должен всегда загрузить (и при необходимости создать) все возможные комбинации переменных и передать их в Model. Model, в свою очередь, должен загрузить все данные для визуализации и передать их во View. Например, в модульном подходе, модуль может напрямую обрабатывать переменные окружения и визуализировать данные без загрузки их в отдельные секции памяти;

- усложнен механизм разделения программы на модули. В концепции MVC наличие трех блоков (Model, View, Controller) прописано жестко. Соответственно каждый функциональный модуль должен состоять из трех блоков, что в свою очередь, несколько усложняет архитектуру функциональных модулей программы;

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

Преимущества MVC:

- единая концепция системы. Несомненным плюсом MVC является единая глобальная архитектура приложения. Даже в сложных системах, разработчики (как те, которые разрабатывали систему, так и вновь присоединившиеся) могут легко ориентироваться в программных блоках. Например, если возникла ошибка в логике обработки данных, разработчик сразу отбрасывает 2-блока программы (controller и view) и занимается исследованием 3-го (model). Соответственно сильно упрощается локализация проблем.

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

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

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

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

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

3.2 Выбор оптимальной базы данных для разрабатываемой системы

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

Самыми распространенными бесплатными системами управления базами данных являются:

- SQLite - очень мощная встраиваемая система управления;

- MySQL - самая популярная и распространенная СУБД;

- PostgreSQL - наиболее продвинутая СУБД.

Проведем сравнительный анализ перечисленных СУБД.

3.2.1 SQLite

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

Преимущества SQLite

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

- Используемые стандарты - хотя может показаться, что эта СУБД примитивная, но она использует SQL. Некоторые особенности опущенны (RIGHT OUTER JOIN или FOR EACH STATEMENT), но основные все-таки поддерживаются

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

Недостатки SQLite

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

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

3.2.2 MySQL

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

Несмотря на то, что в ней не реализован весь SQL функционал, MySQL предлагает довольно много инструментов для разработки приложений. Так как это серверная СУБД, приложения для доступа к данным, в отличии от SQLite работают со службами MySQL.

Преимущества MySQL

- Простота в работе - установить MySQL довольно просто. Дополнительные приложения, например GUI, позволяет довольно легко работать с БД

- Богатый функционал - MySQL поддерживает большинство функционала SQL.

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

- Масштабируемость - MySQL легко работает с большими объемами данных и легко масштабируется

- Скорость - упрощение некоторых стандартов позволяет MySQL значительно увеличить производительность.

Недостатки MySQL

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

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

- Медленная разработка - Хотя MySQL технически открытое ПО, существуют жалобы на процесс разработки.

3.2.3 PostgreSQL

PostgreSQL является самым профессиональным из всех трех рассмотренных нами СУБД. Она свободно распространяемая и максимально соответствует стандартам SQL. PostgreSQL или Postgres стараются полностью применять ANSI/ISO SQL стандарты своевременно с выходом новых версий.

От других СУБД PostgreSQL отличается поддержкой востребованного объектно-ориентированного и/или реляционного подхода к базам данных. Например, полная поддержка надежных транзакций, т.е. атомарность, последовательность, изоляционность, прочность (Atomicity, Consistency, Isolation, Durability (ACID).) Благодаря мощным технологиям Postgre очень производительна. Параллельность достигнута не за счет блокировки операций чтения, а благодаря реализации управления многовариантным параллелизмом (MVCC), что также обеспечивает соответствие ACID. PostgreSQL очень легко расширять своими процедурами, которые называются хранимые процедуры. Эти функции упрощают использование постоянно повторяемых операций.

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

Достоинства PostgreSQL

- Открытое ПО соответствующее стандарту SQL - PostgreSQL - бесплатное ПО с открытым исходным кодом. Эта СУБД является очень мощной системой.

- Большое сообщество - существует довольно большое сообщество в котором вы запросто найдёте ответы на свои вопросы

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

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

- Объектность - PostgreSQL это не только реляционная СУБД, но также и объектно-ориентированная с поддержкой наследования и много другого.

Недостатки PostgreSQL

- Производительность - при простых операциях чтения PostgreSQL может значительно замедлить сервер и быть медленнее своих конкурентов, таких как MySQL

- Популярность - по своей природе, популярностью эта СУБД похвастаться не может, хотя и присутствует довольно большое сообщество.

- Хостинг - в силу вышеперечисленных факторов иногда довольно сложно найти хостинг с поддержкой этой СУБД.

Результаты анализа показывают, что по заявленным возможностям явным фаворитом является PostgreSQL.

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

3.3 Архитектура мобильных приложений

При проектировании архитектуры будем придерживаться паттерна MVP.

MVP (Model View Presenter) паттерн, являющийся производным от известного паттерна MVC (Model View Controller), становится все более значимым при разработке Android приложений.

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

Для создания расширяемых и поддерживаемых приложений необходимо уметь хорошо разделять эти уровни. Данная архитектура хорошо себя зарекомендовала вслучаях, когда, например, приходится брать данные не из базы (или не только из базы), а из web-сервиса? Для того чтобы не «кописастить» весь код (Activity иди Fragment), меняя лишь участки кода который обращается к данным.

MVP делает графическое представление независимым от источника данных. Мы разделим приложение по крайней мере на три уровня, позволяя тестировать каждый из них по отдельности. С MVP мы сможем протестировать большинство логики из Activityили Fragment не применяя инструментальные тесты.

Presenter (предъявитель)

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

View (представление)

Как правило это Activity, Fragment или View, в зависимости от структуры приложения, содержащее ссылку на presenter. В идеале, добавлениеpresenter-а осуществляется с помощью механизма внедрения зависимостей, таких как Dagger, в противном случаи в view должен быть создан объект presenter-а. Единственное, что view будет делать это вызывать методыpresenter-а, каждый раз когда происходит взаимодействие с графическим интерфейсом (нажатие кнопок, свайпы и т.д).

Model (модель)

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

Рисунок 5 наглядная разница двух паттерновMVC иMVP



3.4 Средства разработки мобильных приложений

Приложения для Android пишутся на языке программирования Java. Инструменты Android SDK (SoftwareDevelopmentKit - комплект разработки программного обеспечения) компилируют написанный вами код -- и все требуемые файлы данных и ресурсов -- в файл APK - программный пакет Android, который представляет собой файл архива с расширением.apk. В файле APK находится все, что требуется для работы Android-приложения, и он позволяет установить приложение на любом устройстве под управлением системы Android.

Каждое приложение Android, установленное на устройстве, работает в собственной "песочнице" (изолированной программной среде):

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

- по умолчанию система назначает каждому приложению уникальный идентификатор пользователя Linux (этот идентификатор используется только системой и неизвестен приложению); система устанавливает полномочия для всех файлов в приложении, с тем чтобы доступ к ним был разрешен только пользователю с идентификатором, назначенным этому приложению;

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

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

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

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

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

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

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

AndroidStudio -- это интегрированная среда разработки (IDE) для работы с платформой Android, анонсированная 16 мая 2013 года на конференции Google I/O.

IDE находилась в свободном доступе начиная с версии 0.1, опубликованной в мае 2013, а затем перешла в стадию бета-тестирования, начиная с версии 0.8, которая была выпущена в июне 2014 года. Первая стабильная версия 1.0 была выпущена в декабре 2014 года, тогда же прекратилась поддержка плагина AndroidDevelopmentTools (ADT) для Eclipse.

AndroidStudio, основанная на программном обеспечении IntelliJ IDEA от компании JetBrains, официальное средство разработки Android приложений.

Основные функции AndroidStudio:

- способность работать с UI компонентами при помощи Drag-and-Drop, функция предпросмотра макета на нескольких конфигурациях экрана;

- сборка приложений, основанная на Gradle;

- различные виды сборок и генерация нескольких.apk файлов;

- рефакторинг кода;

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

- встроенный ProGuard и утилита для подписывания приложений;

- шаблоны основных макетов и компонентов Android;

- поддержка разработки приложений для AndroidWear и Android TV;

- встроенная поддержка GoogleCloudPlatform, которая включает в себя интеграцию с сервисами GoogleCloudMessaging и AppEngine;

- способность работать с обновленным компилятором Jack, а также получила улучшенную поддержку Java 8 и усовершенствованную функцию InstantRun;

- В AndroidStudio 3.0 будут по стандарту включены инструменты языка Kotlin основанные на JetBrains IDE.



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

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

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

Рисунок 6 структуры разработанной базы данных

Ниже, представлены основные таблицы, составляющие костяк системы. Все таблицы базы данных можно разделить на три категории:

4.1.1 Категория “Посылка”

Таблица t_order

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

Таблица содержит следующие поля:

- idt_order. Первичный ключ;

- size_x, size_y, size_z. Габариты груза, указывается если груз не является документами (указан параметр idc_packet_type);

- dc_packet_type. Тип документов (А3, А4, А5 и т.д.).

t_packet
idt_packet	int
idc_packet_type	int
size_x	int
size_y	int
size_z	int
weight	int

Таблица t_order

Таблица содержит информацию о текущем заказе.

Таблица содержит следующие поля:

- idt_order. Первичный ключ;

- order_state. Статус заказа (курьер едет в точку “А”, курьер находится в точке “А”, получил посылку и т.д.);

- phone. Телефон отправителя;

- order_number. Уникальный номер заказа, необходим для идентификации заказов курьерами и клиентами;

- sender_name. Имя отправителя или название компании отправителя;

- rec_phone. Телефон получателя;

- rec_name. Имя получателя или название компании получателя;

- cost. Стоимость заказа;

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

- delivery_time. Время доставки посылки, по умолчанию также текущее время. При сохранении значений происходит проверка pickup_time<= delivery_time;

- size_x, size_y, size_z. Габариты груза, указывается если груз не является документами (указан параметр idc_packet_type);

- idc_packet_type. Тип документов (А3, А4, А5 и т.д.);

- weight. Вес посылки;

- addr_a. Адрес точки А;

- lat_a, long_a. Координаты точки Б;

- addr_b. Адрес точки Б;

- lat_b, long_b. Координаты точки Б;

- cost_earn. Сумма выплаты курьеру за вычетом комиссии (20%);

- order_photo. Фотография груза. Храниться строка в виде Url фотографии на сервере;

- is_already_payed. Булевыйфлаг. Истина если заказ уже оплачен по безналичному расчету, ложь если оплата наличными.

t_order
idt_order	int
order_state	int
phone	String
order_number	int
sender_name	String
rec_phone	String
rec_name	String
cost	int
description	String
pickup_time	long
delivery_time	long
size_x	int
size_y	int
size_z	int
idc_packet_type	int
weight	int
addr_a	String
lat_a	double
long_a	double
addr_b	String
lat_b	double
long_b	double
cost_earn	int
order_photo	String
is_already_payed	booblean

4.1.2 Категория “Клиент”

Таблица t_client

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

Таблица содержит следующие поля:

- idt_client. Первичный ключ;

- a_time. Дата регистрации пользователя;

- email. Электронный адрес;

- idt_city. Город проживания;

- first_name, last_name, middle_name. Фамилия имя и отчество пользователя;

- rate. Рейтиг пользователя в баллах от 1 до 5;

- statistic. Статистические данные. Собираются с помощью сервиса FabricCrashlytics (модель телефона, ip, браузер, источник трафика).

t_client
idt_client	int
phone	String
a_time	long
email	String
idt_city	String
first_name	String
last_name	String
middle_name	String
rate	double
statistic	String
avatar	String

Таблица t_pay_method

Таблица содержит информацию о платежной системе клиента.

Таблица содержит следующие поля:

- idt_pay_method. Первичныйключ;

- idt_client. id клиента;

- idc_pay_method_type. id типаметодаоплаты;

- is_default. Булевое значение метода по умолчанию. Истина, если наличными курьеру.

t_pay_method
idt_pay_method	int
idt_client	int
idc_pay_method_type	int
is_default	boolean



4.1.3 Категория “Курьер”

Таблица t_courier

Таблица содержит информацию о курьере.

Таблица содержит следующие поля:

- idt_courier. Первичный ключ;

- first_name, last_name, middle_name. Фамилия имя и отчество курьера;

- phone. Номер телефона;

- idc_courier_status. Статус курьера (работает/отдыхает);

- birthday. Дата рождения;

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

- email. Электронный адрес;

- rate. Рейтинг курьера на основании оценок клиентами;

- achieve. Флаг для присвоения курьера мотивационных статусов (типа “Самый быстрый”, “Самый пунктуальный” и т.д.)

- avatar. Фотография курьера.

t_courier
idt_courier	int
first_name	String
last_name	String
middle_name	String
phone	String
idc_courier_status	int
birthday	String
passport	String
email	String
rate	double
achieve	int
avatar	String

4.2 API для работы с мобильными приложениями

Рисунок 7 иерархия классов API

API доступно по адресу: «https://api.a3technology.ru/ version / section / methodAlias» и имеет следующие методы:

Секция common.

В секции commonпредставлены универсальные методы,которые можно применить как в клиентском, так и в курьерском приложениях. Например, смена аватара.

- calcCost () - Расчет цены из точки А в точку Б;

- rate ($token= '') - Оценить заказ и оставить отзыв;

- setAvatar ($token= '') - Загрузить аватар;

- addOrderPhoto ($token= '') - Загрузка фото заказа;

- addUpdateDevice () - Добавить либо обновить devicetoken.

Секция client

Секция clientсодержит Apiметоды для работы с клиентским приложением.

- sendSmsCode () - Получить пин клиента для авторизации;

- confirmAccountByCode () - Получить токен авторизации;

- getProfile ($token="") - Клиент получает данные профиля;

- addOrder ($token="") - Добавить заказ пользователя;

- confirmOrder () - Подтвердить заказ;

- getOrderStatus ($token="") - Получить статус заказа ;

- getCourierProfile($token="") - Получить данные профиля курьера;

- setProfileData ($token="") - Изменить данные профиля;

- geoLog ($token="") - Записать лог местоположения клиента;

- getOrderHistory ($token="") - Получить count заказов клиента из истории, со сдвигом offset;

- getAddresses ($token="") - Получить список адресов клиента;

- setFaveAddress ($token="") - Добавить или удалить адрес в список избранного;

- trackCourier ($token="") - последняя координата курьера;

- signup () - Зарегистрировать клиента с указанием личной информации;

- getDeliveryOptions () - получить список активных доп. опций заказа;

- bindCard ($token="") - Привязать карту пользователя;

- getBindedCards ($token="") - Получить список привязанных пластиковых карт;

- unbindCard ($token="") - Удалить привязанную карту;

- setCardAlias ($token="") - Изменить пользовательское название карты;

- payWithCard ($token="") - оплатить с помощью карты;

- rejectOrder ($token="") - отменить заказ;

- logout ($token="") - выйти из текущего аккаунта;

- getOrderData ($token="") - Получить данные заказа.

Секция courier

Методы для работы с курьерским приложением.

- signUpRequest () - Запрос курьера на регистрацию Номер телефона должен быть уникальным;

- authorize () - Получить токен, данные профиля и состояния курьера по логину и паролю;

- getProfile ($token="") - Курьер получает данные профиля;

- setActive ($token="") - Управление статусом занятости курьера;

- checkOffer ($token="") - Проверить предложения работы для курьера;

- choiceOrder ($token="") - Выбрать текущий доступный заказ;

- rejectOrder ($token="") - Отклонить текущий доступный заказ;

- getOrderData ($token="") - Подробные данные о заказе;

- setOrderState ($token="") - Управление статусом заказа;

- geoLog ($token="") - Записать лог местоположения курьера;

- getStatus ($token="") - Получить статус курьера;

- getOrderHistory ($token="") - Получить count заказов курьера из истории, со сдвигом offset;

- logout ($token="") - выйти из текущего аккаунта;

- restorePassword () - Получить смс с пин-кодом восстановления пароля;