Главная страница

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


Скачать 0.63 Mb.
НазваниеРазработка службы курьерской доставки в мобильном приложении
Анкордипломная работа
Дата24.04.2023
Размер0.63 Mb.
Формат файлаdocx
Имя файлаДаар.docx
ТипРеферат
#1086258
страница4 из 13
1   2   3   4   5   6   7   8   9   ...   13

Раздел 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, которая является оптимальной, так как удовлетворяет всем поставленным требованиям.

1   2   3   4   5   6   7   8   9   ...   13


написать администратору сайта