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

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

 

Направление: 09.03.01 "Информатика и вычислительная техника"

 

Выполнил

студент гр. 23504/30                                          ________С.В. Аверин

 

Руководитель

старший преподаватель                                       ________Т. В. Коликова

 

Реферат

Работа содержит __ страниц и __ иллюстраций.

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

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

Оглавление

Реферат. 3

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

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

Введение. 9

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

Цели и задачи. 12

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

Сокращение	Определение
Точка А	Пункт отправления посылки (отправитель или организация-отправитель).
Точка Б	Место получения посылки (получатель или организация-получатель).
Служба	Служба курьерской доставки в мобильном приложении
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 не применяя инструментальные тесты.