Перед тем, как создавать приложение, необходимо продумать его архитектуру. Как это сделать правильно рассмотрим в статье.
Упростите жизнь разработчикам
Поскольку самый ценный ресурс — человеческий, любой используемый фреймворк или инструмент должны помогать разработчику оптимизировать свою продуктивность.
Что упростит разработчику жизнь:
- Сделайте приложение максимально простым и понятным;
- Не перегружате его излишней функциональностью — внедряйте только необходимые фичи;
- Используйте общепринятый подход к решению задач;
- Используйте вспомогательные инструменты;
- Сделайте приложение выразительным — каждая задача, решаемая в нём, должна быть очевидной;
- Если вы планируете использовать сторонние библиотеки, то позаботьтесь о том, чтобы они были наилучшими.
Уделите внимание мелочам
- Решайте все задачи, поставленные перед проектом, последовательно;
- Сделайте так, чтобы самые часто встречающиеся задачи выполнялись проще и прозрачней других;
- Сделайте приложение легкорасширяемым;
- Сделайте его настолько простым, насколько это возможно;
Помните о юзабилити
Уровень юзабилити жизненно важен по ряду причин. Он повышает доверие и удовлетворённость клиентов и снижает затраты.
- Исключите из приложения технологии, специфичные для конкретного поставщика;
- Ваше приложение должно поддерживать последние стандарты;
- Обеспечьте приложению быстрый отклик;
- Ваше приложение должно по максимуму использовать графические возможности;
- Добавьте анимацию там, где это уместно;
- Добавьте поддержку A/B тестирования;
- Включите в приложение поддержку аналитики.
Обеспечьте безопасность
Безопасность — это способность системы снизить вероятность злонамеренных или случайных действий за пределами ожидаемого использования системы и предотвратить раскрытие или потерю информации.
- Проходите сторонние пентесты;
- Внедряйте стандарты безопасности везде, где это возможно;
- Следуйте лучшим практикам безопасности.
Обеспечьте надёжность
Надёжность — это способность системы продолжать работать ожидаемым образом с течением времени. Надёжность измеряется как вероятность того, что система не даст сбой и что она будет выполнять свои функции в течение заданного интервала времени.
- Очевидно, что в системе не должно происходить сбоев, но всё же они происходят. Нужно обеспечить журналирование и анализ таких сбоев;
- Система должна быть максимально автономной — если произошёл сбой, будет идеально, если она сама с этим справится;
Мама не понимает, чем вы занимаетесь? Попробуйте объяснить. Начать лучше с основ, например, с разбора того, что такое архитектура приложения.
Это тема сложна для понимания, даже если вы немного разбираетесь в технологиях. Но если коротко, архитектура приложения − это набор методов и шаблонов, которые помогают разработчикам создавать структурированные приложения. В этом материале специалисты из команды Crypterium разбирают тему архитектуры и рассказывают о подходе компании к её разработке.
Давайте в объяснении того, что есть архитектура приложения, отойдем от технических терминов и проведем аналогию с повседневной жизнью. Посмотрите на свое тело. Все, что находится снаружи, − голова и тело, − это front, а всё, что внутри, − сердце, мозг и внутренние органы, − back.
Crypterium занимается разработкой платёжного сервиса. Back-end команда разрабатывает технологии, отвечающие за обмен, передачу, хранение и прочее, а Front-end следят за тем, чтобы пользователю было удобно взаимодействовать с функциями приложения.
Теперь, когда мы разобрались с различием front и back частей, давайте рассмотрим два ключевых подхода, которые используют современные разработчики: API First и Loose Coupling. Они позволяют программистам легко менять структуру приложения. Более того, они делают так, что каждая отдельная часть приложения может быть изменена без затрагивания остальных частей.
Метод API First отвечает за высокую скорость работы и нововведения. Идея в том, чтобы ввести данные и получить в ответ API, необходимый для Front-end и Back-end команд разработки: это позволяет им одновременно писать код и параллельно тестировать его. Преимущества метода заключаются в снижении издержек на разработку, увеличении скорости и снижении рисков.
Пример из жизни: когда вы готовите пасту Болоньезе, вам не нужна сначала паста, потом соус: вы можете готовить их параллельно. В таком случае, еда приготовится быстрее, ничего не успеет остыть, а друзья смогут оценить блюдо в том состоянии, в котором оно и должно быть (а не как обычно).
Одна из функций, за которую команда приложения любит подход API First, называется Swagger − это open-source фреймворк, который помогает разработчикам строить архитектуру, проектировать и создавать документацию для своих приложений. Swagger автоматически генерирует описание API для большинства языков и фреймворков, для обеих − Front-end и Back-end − команд.
Следующий подход называется Loose Coupling, в дословном переводе − слабая связь. И если в жизни примером Loose Coupling может быть отмена свидания в День святого Валентина, то в программировании это наоборот помогает. Если быть точнее, то эта функция упрощает соединение компонентов в сети.
Система Loose Coupling уменьшает риск случайного изменения отдельных объектов, без изменения других − так как в приложении всё взаимосвязано, это может привести к поломкам и уязвимостям. Так вот, благодаря возможности ограничения работы отдельных соединений, система помогает найти и решить проблему быстрее, прямо во время тестирования.
Благодаря принципам API First и Loose Coupling, приложение может выступать микросервисом − приложением, состоящем из независимых служб, способных работать самостоятельно, свободно масштабироваться на разных устройствах.
Микросервисные архитектуры лучше организованы, так как у каждого микросервиса есть определенная задача. Их преимущество ещё и в легкой реконфигурации и перестройке для различных целей. Кроме того, они характеризуются быстрым развертыванием, отказоустойчивостью, горизонтальным масштабированием, низким порогом входа и простотой управления.
Представьте себе умный дом, где все можно контролировать и управлять с помощью одного устройства. Допустим, это устройство − * core *, а управляемыми элементами являются * services *. С помощью основного устройства вы можете открывать окна, включать телевизор или даже закрывать шторы. Так работает архитектура микросервисов.
Но всегда есть альтернативный вариант, верно? Второй тип архитектуры − монолитная архитектура. Это означает, что приложение написано как одна единица кода, чьи компоненты предназначены для совместной работы, используют одни и те же ресурсы и место на диске. Службы в таких приложениях тесно связаны, и при изменении одной из них проблемы могут возникнуть у остальных.
Представьте себе многослойный шоколадный торт. Каждый новый слой делает торт ещё вкуснее, но вы не можете добавить слой с клубникой в середину, не изменив вкус и структуру торта. Можно считать, что у торта − монолитная архитектура.
Мультифункциональные приложения, например, мобильные кошельки, обычно связаны ещё с сотнями различных служб. Чтобы структурировать работу приложения, в Crypterium разделили команду Back-end разработчиков на две. Одна работает только над ядром продукта, вторая − над всем остальным, то есть авторизацией, коммуникацией и так далее.
Каждая команда использует собственные фреймворки. Основная выбрала .NET Core − платформу, которая характеризуется быстрой разработкой, отладкой и тестированием. Вдобавок, она высокопроизводительна, подходит для работы с кросс-платформенными приложениями и ориентирована на микросервисы. В то же время, остальные сервисы разрабатываются с помощью JVM-фреймворка, который, кстати, является прямым конкурентом продукту от Oracle.
Использование сразу двух популярных фреймворков позволяет выбирать из большего количества специалистов на рынке. Для .NET мы используем языки C, а для JVM − Kotlin и Java. Кроме того, эти же языки используются Android-разработчиками.
Команда Front-end специалистов следит за тем, чтобы приложение было удобным, а интерфейс − интуитивно-понятным и быстрым.
Android-версия приложения Crypterium основана на языках Java и Kotlin (как и среда JVM), а приложение iOS − на новом, простом в использовании языке программирования Swift. Функции языка включают в себя контроль доступа, управление памятью, отладку, цепочку вызовов и протокол-ориентированное программирование.
Команда разработчиков Crypterium для iOS, выбрала стиль архитектуры MVVM и роутинг. Благодаря структуре, архитектуры удобны и для разработчиков, и для пользователей.
MVVM − это Model-View-ViewModel, где Model означает информацию о продукте, а View показывает, как клиенты видят продукт. В MVVM есть структура слоев: первый уровень − UI (пользовательский интерфейс). Другие уровни содержат сетевые и логические сервисы. Роутинг отвечает за технические процессы − действия пользователей, перемещения внутри приложения, регулируются именно им.
Давайте разберем пример, когда пользователь хочет отправить криптовалюту на другой адрес. Слой сетевых сервисов содержит информацию о количестве отправленных монет данных и адресе. Когда пользователь подтверждает транзакцию, следующий слой проверяет, достаточно ли монет для отправки на счету, и предоставляет положительный или отрицательный ответ.
Чтобы повысить простоту обслуживания и гибкость приложений, команда Android решила использовать метод под названием «Чистая архитектура». Он гарантирует отсутствие ненужных связей и делает приложение более тестируемым.
Результатом является чистое, новое, свежее, простое в использовании приложение для Android с четырьмя уровнями:
- веб, базы данных, пользовательский интерфейс;
- шлюзы, презентаторы;
- варианты использования;
- юридическая информация.
Архитектура приложений − очень сложная тема, и все, что написано выше, является лишь верхушкой айсберга.
Если вам понравился материал о том, что такое архитектура приложения, посмотрите следующее:
Источник: Объясни это маме − что такое архитектура приложения on Hackernoon
Перед началом разработки приложения indoor-навигации необходимо было продумать его архитектуру и подобрать соответсвующие технологии для её реализации. Эти аспекты будут описаны в следующем подпункте данной главы. Общими усилиями нашей команды, состоящей из трех человек, было выделено два основных критерия, которым должна удлетворять разрабатываемая система навигации. Первое — приложение должно иметь способность получать данные из вне, обрабатывать их и действовать соответсвующим образом. Это требование обусловлено тем, что в будущем планируется внедрить функционал, разрабатываемый компаниями-гигантами, такими как Google, Microsoft и Apple, позволяющий определить местоположение пользователя внутри помещения. Благодаря этому модулю сервер получит возможность получать данные о положении устройства в помещении, обрабатывать их и отправлять обратно пользователю, тем самым освобождая его устройство от различных операций и вычислений. Второе — приложение должно быть кроссплатформенным, чтобы уменьшить количество трудозатрат при разработке и соответствовать современным тенденциям рынка.
Далее будут представлено несколько диаграмм, отображающих поэтапное развитие архитектуры приложения и обуславливающих выбранные технологии.
Первый уровень (рис.1.4.) является самым абстрактным и представляет стартовую точку развития.
Рисунок 1.4. Первый этап — первый уровень
Второй уровень (рис.1.5.) удовлетворяет наши главные критерии, предъявляемые к архитектуре приложения.
Рисунок 1.5. Второй этап — второй уровень
Далее мы определяем способ взаимодействия клиента и сервера, а так же добавляем базу данных на сервере для хранения различной информации, необходимой для пользователя. Так получается третий уровень:
Рисунок 1.6. Третий этап — третий уровень
Четвертый уровень (рис.1.7.) отображает финальную архитектуру приложения, которую можно дополнить недостающей информацией, позволяющей получить полную картину, а так же разделить работу на три части.
Рисунок 1.7. Четвертый этап — четвертый уровень
Таким образом, мы получаем пятый уровень архитектуры (рис.1.8.), который полностью отображает все компоненты. Благодаря поэтапному проектированию получилось сформировать законченную концепцию разрабатываемой системы, необходимую для дальнейшего сегментирования и распределения работ. На данной диаграмме можно выделить три основные секции, которые были распределены внутри нашей команды.
Рисунок 1.8. Пятый уровень
Первая представляет собой серверную часть, где расположена база данных с собственной структурой данных. На сервере осуществляются различные вычисления и обработка запросов пользователей. Вторая часть — интерфейс и функции взаимодействия между модулями и сервером. Эта часть является связующем звеном между сервером и клиентом, а так же между всеми внутренними модулями и поэтому играет важную роль в разрабатываемой системе.
Третья часть — модуль 3D визуализации, осуществляет свою работу на стороне клиента с помощью данных, полученных с сервера. Данная часть выполняет рендеринг трехмерного виртуального помещения смоделированого с реального, а так же визуализацию кратчайшего пути и место неисправности.
Таким образом, разработка системы была разделена между тремя студентами факультета бизнес-информатики:
- · Андрей Сибиряков выполнил серверную часть.
- · Алексей Гайнутдинов отвечал за вторую секцию.
- · Михаил Пантилимонов разрабатывал третью секцию, которая и будет представлена более подробно в данной работе.
Далее, перед кратким рассмотрением модуля 3D визуализации, который в последствие будет более подробно описан во второй главе, необходимо лаконично описать первую и вторую секцию, чтобы воссоздать более полное представление об их функциях и взаимодействие внутри разрабатываемой системы.
Работа Алексея Гайнутдинова заключалась в разработке связующего компонента для приложения indoor — навигация. Любая взаимодействующая с пользователем система, в независимости от её архитектуры, испытывает потребность в интерфейсе — программе, предоставляющей совокупность средств и методов для работы с приложением. Интерфейс осуществляет обработку входных данных пользователя и выдает соответствующий результат. Данная операция осуществляется путем комбинирования различных функций, реализуемых в одном или нескольких модулях системы. Таким образом, основные задачи, решаемые Алексеем Гайнутдиновым, были связаны с проработкой дизайна пользовательского интерфейса, его тестированием, а так же компоновкой функций и преобразованием данных двух других разрабатываемых сегментов.
Основная задача, с которой столкнулся Андрей Сибиряков, заключалась в нахождении кратчайшего пути в неоринтированном графе P (Paths), описанном в подпункте 1.3. этой главы. Решение данной задачи позволило бы прокладывать оптимальный путь от одного маркера до другого.
Так как задача о поиске кратчайшего пути является одной из важнейших задач в теории графов, следовательно, на сегодняшний день существует большое количество вариантов ее решения. В ходе анализа данной проблемы и способов её решения было выделено несколько алгоритмов, удовлетворяющих её постановке и предоставляющих необходимый ответ на задачу о кратчайшем пути:
- 1) Алгоритм Дейкстры.
- 2) Алгоритм Беллмана-Форда.
- 3) Алгоритм Флойда-Уоршелла.
- 4) Алгоритм Левита.
- 5) Алгоритм Джонсона.
Особенности всех этих алгоритмов подробно описаны в работе А. Сибирякова. Для наглядности ниже будет представлена таблица с их характеристиками.
Таблица 1.1. Сравнение алгоритмов поиска кратчайшего пути в графе
Количество начальных вершин
Работа с рёбрами отрицательного веса
да (без отрицательных циклов)
да (без отрицательных циклов)
В результате сравнительного исследования, проведенного А.Сибиряковым, был выбран алгоритм Дейкстры. Это решение было аргументировано тем, что он работает только с ребрами, имеющими неотрицательный вес, а в нашей системе только такие ребра и существуют. Так же, в случае нашего графа путей, сложность алгоритма Дейкстры является наименьшей среди всех приведённых алгоритмов, так как граф P (Paths) связный и не является деревом. Стоит так же отметить, что во время его выполнения пройденные вершины маркируются. В нашем случае, это играет важную роль, т.к. необходимо знать не только «длину» кратчайшего пути до вершины, но и список вершин, через которые он проходит, чтобы воссоздать конечный маршрут. Благодаря решению данной задачи пользователь получит возможность прокладывать путь от точки А до точки Б внутри модуля 3D визуализации, указывая лишь входные данные и получая готовые данные с сервера, обрабатывающего его запрос.
Вторая задача, которая была решена в работе А.Сибирякова заключалась в проработке классов предметной области и построении необходимой структуры базы данных.
В ходе анализа предметной области было выделено четыре основных класса, содержащих нужные атрибуты и методы для работы системы и позволяющих предоставлять необходимые данные конечному пользователю. Для представления устройств внутри компьютерной сети был выбран класс Device. Так как все устройства в нашей сети являются абстрактными маркерами, то необходим класс Marker, описывающий их атрибуты. Для визуализации оптимального пути был создан класс ShortestPath, содержащий начальный маркер, конечный и промежуточные между ними. Для создания маркеров внутри 3D пространства был необходим класс, описывающий координаты маркера — Point. Далее представлены описанные выше классы со всеми их свойствами в виде диаграммы UML (рис.1.9.).
Рисунок 1.9. Диаграмма классов предметной области серверной части
После проработки необходимых классов была построена база данных, необходимая для хранения данных о сети, помещении и возможных путях прохода человека. Стоит отметить, что успешно функционирующая схема бд была реализована еще в прошлогодней курсовой работе А.Сибирякова, но она обладала недостатком в виде большого количества неиспользуемых полей и невозможности установить номер порта, через который соединены соседние устройства. Данные недостатки были устранены благодаря реконструкции необходимых таблиц. Оптимизации позволили избавиться от избыточности данных и предоставили возможность определить устройство, присоединеное на другом конце кабеля по номеру любого порта. Так же было совершенно несколько дополнительных усовершенствований, с которыми подробнее можно ознакомиться в работе А. Сибирякова. Далее будет представлена итоговая схема модели базы данных:
Рисунок 1.10. Диграмма базы данных
Теперь, после описания работы А. Сибирякова, необходимо дополнить описанную систему недостающим элементом — модулем 3D визуализации, который, как указывалось ранее, будет более подробно описан во второй главе.
Указанный выше модуль, далее именуемый как «3D МВ», является инструментом, необходимым для визуализации геометрических моделей в трехмерном пространстве с тремя однородными измерениями. В разрабатываемой системе, он предназначен для копирования объектов из реального мира и воссоздания их внутри виртуального. Данная операция предоставляет возможность взаимодействовать с ними, совершая различные манипуляции, а так же дополнять их вспомогательными объектами для решения различных задач, например тех, что описаны в пункте 1.1. Таким образом, основная функция модуля заключаются в предоставлении инструментария для:
- · Построения копии реального архитектурного сооружения с его собственной инфраструктурой внутри вирутального мира.
- · Взаимодействия с объектами виртуального мира.
- · Осуществления навигации внутри виртуального мира.
Предполагается, что копирование объектов будет осуществляться с помощью достоверных архитектурных планов построек, что, в свою очередь, обеспечит относительно высокую точность конечного результата. Благодаря 3D МВ пользователь сможет легко распозновать и соотносить объекты из виртуального мира с реальными. Это позволит значительно упростить задачу, связанную с ориентированием в закрытом пространстве, известную как задача локального позиционирования. Таким образом, благодаря разрабатываемому инструментарию, пользовать сможет смоделировать требуемое ему сооружение в виртуальном мире, разместив внутри него опозновательные и информацинные объекты, и сохранить итоговый результат. В последствии каждому пользователю предоставится возможность получать копию смоделированного виртуального пространства, взаимодействовать с ней и осуществлять необходимые запросы, на основании которых сервер, применяя различные алгоритмы и математические расчеты, построит виртуальный путь до места неисправности, относительно точно укажет на место повреждения инфраструктуры, а так же предоставит некоторые инструкции и дополнительную информацию по различным объектам, начиная от расположения устройства, заканчивая его техническими характеристиками. С помощью этих вычислений и инструкций, пользователь получит возможность локализовать и иправить сбой значительно быстрей, применив в реальном мире информацию, полученную из виртуального простраства на основе расчетов системы.
После краткого описания всех трех разрабатываемых сегментов, можно построить диаграмму, визуально описывающую взаимодействие трех сегментов разрабатываемой системы:
Рисунок 1.11. Взаимодействие сегментов системы
