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

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 12.12.2023

Просмотров: 147

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

Раздел 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Общая характеристика организации

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

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

Раздел 2. РАЗРАБОТКА СЦЕНАРИЕВ ПОВЕДЕНИЯ ПРИЛОЖЕНИЙ НА ЭТАПАХ ВЫПОЛНЕНИЯ КУРЬЕРСКОГО ЗАКАЗА

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

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

Раздел 3. ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ СЕРВЕРНОЙ ЧАСТИ СИСТЕМЫ И МОБИЛЬНЫХ ПРИЛОЖЕНИЙ

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

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

3.2.1 SQLite

3.2.2 MySQL

3.2.3 PostgreSQL

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

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

Раздел 4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СЕРВЕРНОЙ ЧАСТИ СИСТЕМЫ И МОБИЛЬНЫХ ПРИЛОЖЕНИЙ

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

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

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

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

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Приложение 1.

Приложение 2.

Раздел 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 очень легко расширять своими процедурами, которые называются хранимые процедуры. Эти функции упрощают использование постоянно повторяемых операций.