Файл: Критерии выбора средств разработки мобильных Приложений (Теоретические аспекты изучения критериев выбора средств мобильных приложений).pdf

Как видно из таблицы, инструменты, позволяющие создавать мобильные приложения, как правило, имеют высокую стоимость, либо имеют низкий уровень безопасности и быстродействия. Этими недостатками не обладает IDE AndroidStudio.

2. Проектирование мобильного приложения для разделения чека в кафе и ресторанах

2.1. Требования к мобильному приложению

Функциональные требования к мобильному приложению представлены так:

1. пользователь должен иметь возможность вводить позиции из чека вручную;
2. продукт должнен распознавать наименование и количество заказанных блюд по фотографии счета, путем загрузки изображения с устройства пользователя;
3. продукт должен предоставлять функцию ввода количества пользователей;
4. пользователь должен иметь возможность выбора и отмены выбора пункта из распознанного/введенного списка;
5. программа должна выводить выбранные товары, их количество и сумму к оплате для каждого пользователя;
6. программа должна выводить на экран предупреждение, сообщающее о несовпадении реальной итоговой суммы и суммы по пользователям.

Нефункциональные требования:

1. продукт должен быть создан для ОС Android (версия Lollipop и более поздние);
2. распознавание данных должно осуществляться с помощью открытой библиотеки OpenCV;
3. приложение должно работать в автономном режиме (без подключения к сети Интернет);
4. интерфейс приложения должен быть выполнен в соответствии с принципами Material Design [7];
5. финансовые расчеты в приложении предполагаются в рублевой валюте;
6. интерфейс продукта должен быть русифицирован.

2.2. Варианты использования мобильного приложения, диаграмма последовательности

Для разработки продукта был применен язык графического описания для объектного моделирования UML [14, 11]. Выстроена модель взаимодействия внешнего актера с приложением в виде диаграммы вариантов использования.

В процессе разработки был выявлен один актер «Пользователь».

Пользователь – использующий приложения, у которого есть возможность применение функционалом приложения.

Диаграмма вариантов применения приложения представлена на рис. 2.1.

Рис. 2.1. Диаграмма вариантов применения

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

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

Убрать пункт из списка – удалить из списка позиций чека ранее добавленный пункт списка. Можно прервать операции.

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

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

Выбрать пункт меню – выбрать из ранее введенных один пункт меню как оплачиваемый текущим клиентом.

Нумерация действий пользователя при работе с приложением показана на рис. 2.2.

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

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

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

При остатке блюд, которые не выбрал никто из гостей, высветится предупреждение.

Рис. 2.2. Диаграмма последовательности

2.3. Проектирование архитектуры мобильного приложения

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

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

Экран выбора фотографий дает пользователю возможность выбрать существующее контрольное изображение из галереи пользователя или сделать новую фотографию с помощью камеры.

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

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

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

Рис. 2.3. Диаграмма компонентов

2.4. Проектирование интерфейса мобильного приложения

После запуска приложения пользователь должен указать количество гостей, на которых будет разделен чек (рис. 2.4).

Рис. 2.4. Экран ввода количества гостей

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

Экран выбора фотографии изображен на рис. 2.5.

Экран редактирования чека (Рис. 2.6) позволит пользователю вручную редактировать, добавлять или удалять позицию чека (название блюда, количество и стоимость) с помощью диалоговых окон. Одна из этих операций может быть прервана, поэтому никаких изменений не будет. Когда весь элемент управления будет передан, пользователь сможет перевести приложение в режим выбора пользователя из элементов управления, заказанных им.

Рис. 2.5 Экран выборов фото

Рис. 2.6. Экран редактирования чека

На экране, позволяющем гостям выбирать контрольные точки (рис.2.7), будет использоваться цветовой код: когда гость, выбранный в верхней части экрана, помечает определенный элемент как заказанный, рядом с именем появится маркер соответствующего цвета. блюда Таким образом, будет четко указано, сколько гостей и кто конкретно заказал каждый отдельный элемент управления. Когда гость снова выбирает блюдо, маркер удаляется.

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

Рис. 2.7. Экран выбора гостями и экран результатов пунктов чека

3. Реализация мобильного приложения «fairsplit» для разделения чека в кафе и ресторанах

3.1. Архитектура, компоненты мобильного приложения

С точки зрения обработки взаимодействия между пользовательским интерфейсом и его логикой, реализованное приложение следует архитектурной модели «Модель, представление, презентатор» (MVP) [12]. Схема взаимодействия его компонентов представлена на рис. 2.8.

Рис. 2.8. Диаграмма взаимодействия MVP

Ключевым различием шаблона MVP от MVC является то, что представление ничего не знает о модели данных и наоборот – модель данных ничего не знает о представлении. При любом изменении данных в модели представление не оповещается напрямую, и задачей компонента Presenter является получить актуальные данные из модели, чтобы при необходимости обновить View [9].

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

Файловая структура приложения представлена на рис. 2.9.

Рис. 2.9. Файловая структура приложения

В папке «src\main\java\com.example.gulnara.graduatework» содержатся файлы исходного кода приложения (см. рис. 2.10).

В папке «model» находятся классы User и Dish, представляющие в программе необходимые понятия предметной области: блюдо и гость (пользователь).

Другие файлы исходного кода распределены в зависимости от экрана, работу которого они обеспечивают: «guestNumber» содержит код операции, в которой приложение запрашивает количество гостей. В папке «pickPhoto» находится код, отвечающий за загрузку изображения чека из галереи или камеры устройства в приложение и дальнейшее распознавание текста на нём. В «billEditor» находятся файлы исходного кода, отвечающего за возможность редактирования распознанного чека на соответствующем экране. Код в директории «billSplitting» отвечает за предоставление пользователям возможности разделения общей суммы чека, а в «results» - за отображение итоговых сумм к оплате для каждого пользователя.

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

Эта операция (Activity) – «основная» в подобных проектах, предлагаемая пользователю первой при запуске приложения [19].

PickPhotoActivity – экран загрузки изображения. Предоставляет пользователю два способа добавить в приложение изображение чека: с помощью камеры или уже существующее в галерее. После того, как пользователь загружает изображение, происходит распознавание текста на нем.

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

BillParser – класс, осуществляющий парсинг текста, полученного с изображения. Служит для преобразования строки в список позиций чека.

BillEditorActivity – отвечает за возможность экран редактирования модели чека, полученной в результате распознавания изображения.

Как и другие файлы исходного кода, чье название заканчивается на «Activity» в подобных проектах, операция (Activity) представляет собой один экран с пользовательским интерфейсом [18].

BillEditorAdapter – как и другие файлы исходного кода с названием, оканчивающимся на «-Adapter», предназначен для представления модели данных (в данном случае – списка распознанных блюд) на экране операции в виде списка.