Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Для достижения цели работы должны быть решены следующие задачи:

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

4) реализовать и протестировать мобильное приложение.

1. Теоретические аспекты изучения критериев выбора средств мобильных приложений

1.1. Понятие и особенности мобильной среды. Мобильное приложение.

Продажи мобильных приложений возрастает ежегодно. По данным компании «Связной» в сентябре 2019 года было реализовано 10,1 млн. смартфонов, что по отношению на сентябрь 2018 года является 7% приростом. Моно отметить, что так же постепенно увеличивается и рынок мобильных приложений. Многообразие рынка при этом обеспечивает увеличение численности клиентов тем компаниям, которые имеют свое приложение или адаптивное интернет–представительство и открытие новых ниш, которые фирма занимает. Фирменные мобильные приложения дифференцируются в информационную систему компании, что так же расширяет информационные потоки в организации [15].

Мобильная среда – сфера существования переносных и носимых ЭВУ [2].

Развитие данной мобильной среды напрямую взаимосвязано с прогрессом мобильных инноваций, которые позволили создать мобильные устройства такими, какими они являются в настоящее время. Действенно на развитие мобильной среды повлияло существование общедоступного мобильного Интернета и его активное использование, проникновение в массы. Мобильный интернет позволил идеализировать мобильную среду из простого способа связи в нового пользователя создания, развития и использование информации. Сейчас это заметно, в первую очередь, по активному развитию мобильной журналистики, активности роли отдельного человека в коммуникации, возможности самому становиться её успешным участником, оказывать влияние на других [3].

При этом мобильная среда выявила активный рост объема информации и уровня ее потребления. Из сведений IDC, начиная с 2011 года объем данных на планете как минимум удваивается каждые два года. Причиной этого является доступность мобильного Интернета во многих государствах. Теперь любой пользователь может продуцировать и использовать контент практически всюду. Однако Интернет помог получать информацию, по сути, в шаговой доступности, то с появлением мобильных приложений необходимая информация находиться у пользователя непосредственно в кармане. Само понятие «мобильная среда» включает в себя все переносные устройства, но инженеры-разработчики, сужают его исключительно до следующего перечисления мобильных устройств: телефоны, смартфоны, фаблеты, КПК, планшетные компьютеры, носимые устройства (умные часы, браслеты) и (реже) электронные книги. Подобное сужение обусловлено популярностью и первоочередностью разработки именно для этих устройств.

Среди особенностей мобильной среды можно выделить (рис. 1.1):

Рисунок 1.1 Особенности мобильной среды [6]

Выявить приложение можно через термин компьютерной программы: последовательность инструкций, предназначенных для исполнения устройством управления компьютера. Однако стоит уточнить, что данная последовательность реализуется на мобильном устройстве (телефоне, смартфоне, планшете и т. д.) [18].

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

Создатели приложений также предлагают распространять свои программы в магазинах приложений с возможностью зарабатывать от распределения прибыли по продажам. Выделяются популярные продавцы, такие как AppStore, где только рекомендованные приложения могут распространяться и запускаться на iOS устройствах, и Google Play, приложения в котором работают на устройствах с Android OS [1].

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

В настоящее время для разработки мобильных приложений действует два вида средств создания: инструменты разработки для создания нативных мобильных приложений и инструменты получения web–приложений адаптированных под мобильные приложения. Чтобы произвести анализ, были выбраны средства разработки нативных приложений, потому что в данной сфере они более популярны и пользуются спросом. Таким образом, будет рассмотрено три наиболее популярных средства создания приложений: Android studio, Eclipse, NetBeans IDE. Для анализа данных программных продуктов были выбраны следующие критерии:

функциональность;
удобство интерфейса;
возможность подключения дополнительных модулей;
требовательность к системе;
возможность подключения к системам контроля версий;
наличие встроенных компонентов тестирования приложения [14].

Android Studio – разработка компании Google. Основана на программном обеспечении IntelliJ IDEA от компании JetBrains, официальное средство разработки Android приложений. Актуальная на данный момент версия приложения 2.2. Данная среда разработки доступна для Windows, OS X и Linux. Функционал данного приложения использует язык Java для написания программного кода. Создание интерфейса происходит drag–n–drop способом, однако можно использовать XML. Чтобы создание интерфейса было удобным используют шаблоны, направленными на задачу, которую должно совершать приложение. Интерфейс данного ПО перегружен. Интерфейс библиотек приложения имеет вид выпадающего древа и нужно отводить очень много места в общем интерфейсе, может случиться так, что информация становится нечитаемой. То же самое происходит и с окном отладки. В функционале Android Studio возможности подключения дополнительных плагинов нет. Это средство создания имеет высокие требования к технической эксплуатации ЭВМ, по сравнению с аналогами. Минимальный объем памяти ОЗУ требуемое для данного продукта 2 Гб. Однако чтобы работа была комфортной с данной программой рекомендуемый объем памяти 8 Гб, это не проблема для современных компьютеров, но на ПК старше 2014 года данная среда функционирует очень заторможенно, не говоря о параллельном запуске других, даже не очень емких приложений. Также нет возможности прямого подключения к сервисам контроля версий, что делает работу над одним приложением группой лиц более сложной. Работает встроенный модуль для эмуляции Android-устройства. У данного эмулятора существуют требования отдельных ресурсов, что увеличивает требовательность ПО к ПК.

Eclipse – среда создания, принадлежащая компании Eclipsefoundation [4]. Более новая версия Eclipse 4.6(Neon). Применяемый язык для написания мобильных приложений – Java. Использует в своем функционале средства для создания мобильных приложений и web – приложений, работает с языками C++и PHP. Для создания интерфейса не существует шаблонов, или готовых объектов. Но есть возможность синхронизации разных ПК для разработки одного проекта посредствам облачных сервисов. Простой и удобный интерфейс. Панель библиотек имеет древовидную структуру, но проблема предыдущего продукта здесь решена просто – можно сворачивать окна, которые не используются. Имеется помощник для написания простого Hello world приложения. Есть возможность подключения дополнительных плагинов для расширения функционала. В программе можно включить целый модуль Eclipse Marketplace, предоставляющий на выбор сразу три «Рынка» плагинов: Eclipse Marketplace, Obeo Marketplace и RedHat. Имеется возможность реализации индивидуальных плагинов и их внедрения без получения лицензии или обязательной презентации разработки на рынке. Системных требований для данного ПО нет, но при использовании на ПК средней производительности 2012 года не было проблем. С помощью синхронизации с облаком в системе нет каких-либо соединительных средств для подключения к системам контроля версий. Эмуляции устройства не существует [26].

NetBeans IDE– разработка фирмы NetBeans Community. Более новая версия приложения 8.2. В этой разработке функционал полностью осуществляется с помощью плагинов. Поэтому ПО поддерживает огромный объем применяемых языков. Для создания нативных мобильных приложений применяется Java, но есть возможность разработки web–приложения написанного на HTML5 или JS+PHP. Встроенного отладчика не существует, но есть возможность подключения удаленного отладчика через сеть «Интернет». Интерфейс сходен с интерфейсом Eclipse, за исключением отсутствия окна отладки, и существования разметки номеров строк. Требования к ЭВМ простые. Для минимальной работы продукта требуется 512 мегабайт ОЗУ, для более слаженной работы стоит применять компьютер с 2 Гб. Есть встроенную возможность подключения к системам контроля версий. Работает с GitHub, Mercurial и Subversion. Встроенных элементов для тестирования приложения нет. Таким образом, анализ средств разработки мобильных приложений можно свести в таблицу, оценивая рассмотренные критерии по пятибалльной шкале (табл. 1.).

Сведем некоторые параметры рассмотренных платформ в табл. 1

Таблица 1. Сравнение платформ разработки мобильных приложений

№ п/п	Критерий	Appery.io	ShoutEm	Eclipse	Intellij IDEA	AndroidStudi o
1.	Удобство использования	9/10	8/10	5/10	8/10	9/10
2.	Документация	★★★★☆	★★★☆☆	★★★★☆	★★★★☆	★★★★☆
3.	Лицензия	Коммерческая	Коммерческая	EclipsePublic License	Условнобесплатная	Бесплатная (Apache 2.0)
4.	Стоимость	Имеется бесплатная пробная версия и пре- миум-версия - $180	Начальная версия – $19.90 в месяц, безлимитная – $119.90 в месяц	Бесплатная	Ultimateediti on - $499.00- . Есть бесплатная версия программы (Community Edition)	Бесплатно
5.	Поддерживаемые языки программирования	JS	JS	Java, С, С++, Perl, Python, Ruby и др.	Java, Python, Ruby, C, C++ идр.	Java
6.	Предназначение разработки	Мобильные версии сай- тов и приложения	Только мобильные версии сайтов	Программы и мобильные приложения	Программы и мобильные приложения	Только мобильные приложения
7.	Категория платформы	Облачный сервис (он- лайн-инструменты)	Облачный сервис (он- лайн-инструменты)	Требует инсталляции на компьютер разработчика	Требует инсталляции на компьютер разработчика	Требует инсталляции на компьютер разработчика
8.	Поддержка командной разработки	Да	Нет	Да	Да	Да
9.	Поддерживаемые языки разметки	HTML5, CSS	HTML5, CSS	XML	XML	XML
10.	Поддерживаемые ОС	iOS, Android, Windows Phone	iOS, Android, Windows Phone	iOS, Android, Windows Phone	Android	Android
11.	Безопасность	★★★★☆	★★★☆☆	★★★☆☆	★★★★☆	★★★★☆
12.	Быстродействие	★★★★☆	★★★★☆	★★★☆☆	★★★★★	★★★★★

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

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

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

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

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

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

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

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», предназначен для представления модели данных (в данном случае – списка распознанных блюд) на экране операции в виде списка.

NewDishDialogFragment – диалоговое окно, появляющееся при нажатии на кнопку «+» на экране редактирования чека. Предоставляет возможность ввести информацию и новом блюде: его название, цену за ед. и количество.

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

Рис. 2.10. Файлы программного кода приложения

В папке src\main\res\layout содержатся файлы разметки приложения (рис. 2.11). activity_bill_editor.xml – как и другие файлы разметки, начинающиеся с «activity_», отвечает за разметку соответствующего экрана. Содержит viewэлементы для отображения списка блюд, кнопки добавления нового блюда и общей суммы по чеку.

bill_editor_list_item.xml – представление одного блюда из списка на экране редактора чека (название, количество, стоимость).

bill_editor_list_item_dialog_fragment.xml – разметка диалогового окна, появляющегося при клике на один из элементов списка в редакторе чека.

result_group_view.xml – разметка представления итогов по пользователю на экране результатов.

result_child_view.xml – разметка представления элемента детализации списка блюд по каждому пользователю.

user_choice_item.xml – представление блюда на экране выбора пользователей.

user_list_item.xml – представление отметки пользователя о разделении на него суммы блюда.

Рис. 2.11. Файлы разметки проекта

3.2. Реализация компонентов обработки данных

Приложение содержит порядка 3500 строк кода.

Приложение написано на языке Java [26], язык разметки – XML.

Подключенный модуль распознавания изображений tess-two написан преимущественно на С++ [5].

Загрузка изображения с камеры или из галереи.

При нажатии на кнопки «Галерея» или «Камера» конструируется соответствующий требуемому действию объект класса Intent, передаваемый в функцию startActivityForResult. Эта функция запускает новую операцию (Activity), и её результат будет возвращен в метод onActivityResult. Код метода приведен на рис. 2.12.

Рис. 2.12. Обработка нажатий на кнопки «Галерея» и «Камера»

Распознавание изображения

Взаимодействие с используемой библиотекой tess-two реализовано в классе TextRecognizer (рис. 2.13). Библиотека tess-two открыта для использования и доступна на ресурсе [5]. Tess-two является ответвлением проекта tesseract-android-tools, набором программных интерфейсов и файлов сборки для библиотеки оптического распознавания символов Tesseract и библиотеки обработки изображений Leptonica.

При вызове в объекте класса TextRecognizer функции processImage, принимающей на вход обрабатываемое изображение, в TessBaseAPI вызывается метод getUtf8Text, возвращающий строку с обнаруженным текстом.

Добавление нового пункта списка

Поведение диалога добавления нового пункта списка реализовано в классе NewDishDialogFragment, объект которого вызывается при нажатии на кнопку “+” на экране первой вкладки. В разметке диалога new_dish_dialog.xml расположены поля для ввода данных о добавляемом пункте. При нажатии в диалоге на кнопку “ОК” с применением шаблона «Listener» экран (Activity) редактора чека оповещается о создании нового объекта и производится сохранение данных о заказе и обновление выводимой адаптерами списков информации. На рис. 2.13 приведен программный код, сохраняющий информацию о новом пункте списка.

Рис. 2.13 Файлы разметки проекта

Рис. 2.14 Создание нового пункта чека

Подсчет суммы к оплате для каждого гостя.

При каждом клике на значок выбора или отмены выбора блюда происходить пересчет сумм к оплате для всех пользователей при вызове функции recountSums (рис. 2.15).

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

Преобразование чека в список блюд

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

Рис. 2.15. Функция recountSums

Рис. 2.16. Функция initDishes

3.3. Функциональное тестирование

Функциональное тестирование – это тестирование программного обеспечения в целях проверки реализуемости функциональных требований, то есть способности программного обеспечения в определенных условиях решать задачи, нужные пользователям [8]. Функциональные требования определяют, что именно делает программное обеспечение, какие задачи оно решает. Используя методологию функционального тестирования, проверим работу с заявлениями.

Тест № 1

Цель: протестировать функцию ввода пользователем позиций из чека вручную.

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

Входные данные: пользователь находится на экране редактирования позиций чека.

Процедура тестирования: пользователь нажимает на кнопку добавления нового блюда «+», появляется диалоговое окно, куда пользователь вводит данные о блюде (название, количество и стоимость). Если пользователь введет данные не во все поля, они будут заполнены значениями по умолчанию. После ввода данных и новой позиции пользователь нажимает «Ок» и диалоговое окно закрывается.

Полученный результат: совпадает с ожидаемым.

Вывод: тест пройден

Тест № 2

Цель: протестировать функцию загрузки изображения из галереи.

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

Входные данные: пользователь находится на экране загрузки изображения.

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

Полученный результат: совпадает с ожидаемым.

Вывод: тест пройден

Тест № 3

Цель: протестировать функцию распознавания позиций чека на фотографии.

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

Входные данные: пользователь находится на экране загрузки изображения, изображение уже загружено.

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

Полученный результат: совпадает с ожидаемым.

Вывод: тест пройден

Тест № 4

Цель: протестировать функцию ввода количества пользователей.

Ожидаемый результат: количество гостей успешно введено в приложение, и оно готово к работе с заданным количеством гостей.

Входные данные: пользователь находится на экране ввода количества пользователей.

Процедура тестирования: пользователь с помощью ползунка выбирает нужное ему число и подтверждает свой выбор нажатием на кнопку «Ок».

Полученный результат: совпадает с ожидаемым.

Вывод: тест успешно пройден.

Тест № 5

Цель: протестировать функцию выбора и отмены выбора пользователем пункта из распознанного/введенного списка.

Ожидаемый результат: при нажатии на флажок пользователя под блюдом изменяется его состояние изменяется на «отмечено». При повторном нажатии флажок снимается.

Входные данные: пользователь находится на экране выбора пользователями пунктов списка.

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

Полученный результат: совпадает с ожидаемым.

Вывод: тест успешно пройден.

Тест № 6

Цель: протестировать функцию вывода выбранных товаров и сумм к оплате для каждого пользователя.

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

Входные данные: пользователь находится на экране выбора пользователями пунктов списка.

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

Полученный результат: совпадает с ожидаемым.

Вывод: тест успешно пройден.

Тест № 6

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

Ожидаемый результат: предупреждение успешно отображается, если какое-то из блюд не было выбрано ни одним пользователем.

Входные данные: пользователь находится на экране выбора пользователями пунктов списка.

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

Полученный результат: совпадает с ожидаемым.

Вывод: тест успешно пройден.

3.4. Юзабилити-тестирование

Юзабилити-тестирование (проверка эргономичности) – метод оценки удобства продукта в использовании, основанный на привлечении пользователей в качестве тестировщиков, испытателей и суммировании полученных от них выводов [17].

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

Модератор выдает сразу весь список заданий участнику. Временные ограничения на выполнение заданий не накладывались. Замечания от респондентов во время прохождения тестирования письменно фиксировались модератором тестирования.

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

ЗАКЛЮЧЕНИЕ

Доля мобильного интернета растет ежедневно [15]. Многие люди проводят по нескольку часов в день, играя в различные компьютерные игры, в особенности в то время, когда ничего другого сделать нельзя, например, по дороге на работу, учебу, в поезде и т. д. Регулярно выходят новые компьютерные игры для телефонов и других мобильных устройств. Скачивание мобильных приложений не требует долгого времени и специальных навыков, установка также проста и понятна.

В рамках работы было разработано мобильное приложение для Android. Для достижения данной цели были решены следующие задачи:

осуществлена постановку задачи, выделены требования к приложению;
произведен обзор существующих решений для разделения чеков;
изучены современные средства разработки мобильных приложений для Android;
определены требования и спроектировано мобильное приложение; 5) реализовано и протестировано мобильное приложение.

Все поставленные задачи были решены, цель достигнута.

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

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

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

БИБЛИОГРАФИЯ

Android Studio Features. [Электронный ресурс] URL: https://developer.android.com/studio/features.html (дата обращения: 26.11.2019).
Appery.io: Enterprise Mobile App Builder & MBaaS. [Электронный ресурс] URL: https://appery.io/ (дата обращения: 06.11.2019).
Download Android Studio and SDK Tools | Android Studio. [Электронный ресурс] URL: https://developer.android.com/studio/index.html (дата обращения: 26.11.2019).
Eclipse - The Eclipse Foundation open source community website. [Электронный ресурс] URL: https://www.eclipse.org/downloads/ (дата обращения: 26.11.2019).
Fork of Tesseract Tools for Android. [Электронный ресурс] URL: https://github.com/rmtheis/tess-two/ (дата обращения: 06.05.2017).
IntelliJ IDEA the Java IDE – JetBrains. [Электронный ресурс] URL: https://www.jetbrains.com/idea/ (дата обращения: 26.11.2019).
Introduction to Material Design. [Электронный ресурс] URL: https://material.google.com/ (дата обращения: 25.11.2019).
Kaner, Falk, Nguyen. Testing Computer Software. – USA: Wiley Computer Publishing, 1999. – 42 p.
MVP and MVC Architectures in Android. [Электронный ресурс] URL: https://www.techyourchance.com/mvp-mvc-android-1/ (дата обращения: 26.11.2019).
Shoutem - Make an App - Build Apps with Easy Application Creator. [Электронный ресурс] URL: www.shoutem.com/ (дата обращения: 26.11.2019).
Арлоу Дж., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование. 2-е издание. – М.: Издательство «Символ-Плюс», 2017. – 624 с.
Архитектура Android-приложений. Часть II – архитектурные стили и шаблоны. [Электронный ресурс] URL: https://habrahabr.ru/post/140655/ (дата обращения: 22.11.2019).
Бурнет Э. Привет, Android! Разработка мобильных приложений. 2-е издание. – СПб.: Издательство «Питер», 2012. – 256 с.
Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. – СПб.: Издательство «Питер», 2003. – 432 с.
Ведомости – Интернет-аудитория России растет за счет мобильных устройств. [Электронный ресурс] URL: https://www.vedomosti.ru/technology/articles/2016/01/28/625779-internet-auditoriya-rossiirastet-schet-mobilnih-ustroistv/ (дата обращения: 22.11.2019).
Дейтел П., Дейтел Х., Уолд А. Android для разработчиков. 3-е издание. – СПб.: Издательство «Питер», 2016. – 512 с.
Нильсен Я., Будиу Р. Mobile Usability. Как создавать идеально удобные приложения для мобильных устройств. – М.: Эксмо, 2013. – 256 с.
Операции. [Электронный ресурс] URL: https://developer.android.com/guide/components/activities.html (дата обращения: 22.11.2019).
Основы создания приложений. [Электронный ресурс] URL: https://developer.android.com/guide/components/fundamentals.html (дата обращения: 22.11.2019).
Приложения в Google Play – Clever Bill Splitter. [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.cleverturtles. splitter&hl=ru (дата обращения: 02.11.2019).
Приложения в Google Play – Split Bill Advanced. [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=br.com.fml. splitbilladvanced2&hl =ru (дата обращения: 22.11.2019).
Приложения в Google Play – Split Bill. [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.msafiullah.splitbill (дата обращения: 22.11.2019)
Приложения в Google Play – Split Bills – Repayr. [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=lundesoft.com. repayrlight&hl=ru (дата обращения: 21.11.2019).
Приложения в Google Play – SplittPay подели чек с другом! [Электронный ресурс] URL: https://play.google.com/store/apps/details?id= com.github.rchugunov.splitpay&h l=ru (дата обращения: 22.11.2019).
Приложения в Google Play – Делим чек. [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.wemir_apps. split_bill&hl=ru (дата обращения: 05.11.2019).
Шилдт Г. Java 8. Полное руководство. – М.: Издательский дом «Вильямс», 2017. – 1376 с.