Список использованных источников

СОДЕРЖАНИЕ

ВВЕДЕНИЕ. 3

1 ПОСТАНОВКА ЗАДАЧИ.. 4

1.1 Тенденции развития технологий разработки приложений. 4

1.2 Описательная постановка задачи. 6

1.3 Формальная постановка задачи. 9

1.4 Декомпозиция задачи. 10

2 ПРОЕКТИРОВАНИЕ СИСТЕМЫ... 13

2.1 Основные требования, предъявляемые системе. 13

2.2 Выбор инструментальных средств. 16

2.3 Проектирование схемы функционирования системы.. 19

2.4 Перечень функциональности. 20

2.5 Моделирование структуры системы.. 22

2.6 Проектирование пользовательского интерфейса. 25

2.7 Методика тестирования конечного продукта. 29

3 РЕАЛИЗАЦИЯ СИСТЕМЫ... 30

3.1 Структура приложения. 30

3.2 Описание классов. 31

3.3 Описание реализаций основных функций приложения. 34

3.4 Реализация пользовательского интерфейса. 39

3.5 Результаты тестирования системы.. 44

ЗАКЛЮЧЕНИЕ.. 50

Список использованных источников.. 51

ВВЕДЕНИЕ

Организация ООО «Совместные покупки» предоставляет пользователям электронную торговую площадку для проведения так называемых «совместных покупок». Совместная покупка – это покупка группой лиц товара напрямую у поставщика или производителя по оптовой цене, что делает покупку более выгодной для каждого покупателя. Человека, который организует и производит закупку, называют организатором. После проведения закупки организатор обязан передать товар участникам закупки. Изначально, организатор назначал время и место встречи, где лично выдавал заказы участникам. Однако это приносило массу проблем. В связи с этим проект «Совместные покупки» необходимо было развивать. Одним из шагов развития стало открытие центров раздачи заказов. Данные центры решали проблемы с выдачей заказов участникам. Теперь, после проведения закупки, организатор расфасовывает товары клиентов по пакетам и передает их в центр раздачи заказов, откуда клиент может в любое время забрать свою покупку.

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

На сегодняшний день мобильные приложения находятся на пике своей популярности. Количество разработчиков мобильных приложений увеличивается, количество доступных приложений растет, а также и число их загрузок. Согласно статистике, за 2012 год рынок мобильных приложений в мире составил $7,83 млрд. И, по прогнозам, к 2016 составит $65,79 млрд.

Наиболее популярными, на сегодняшний день, мобильными платформами являются Apple iOS, Android и Windows Phone.

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

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

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

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

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

ПОСТАНОВКА ЗАДАЧИ

1.1 Тенденции развития технологий разработки приложений

1. Сервисная архитектура приложений

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

Веб-сервис (web-service) – это программная система, разработанная для поддержки интероперабельного межкомпьютерного (machine-to-machine) взаимодействия через сеть. Веб-сервис идентифицируется строкой URI (Uniform Resource Identifier – унифицированный идентификатор ресурса). Веб-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах (SOAP, XML-RPC, REST и т. д.).

Веб-сервис имеет ряд преимуществ по сравнению с настольными приложениями:

1) Веб-сервис не требует установки на компьютер. Для доступа к нему достаточно наличие подключения к Интернет.

2) Независимость от операционной системы.

3) Для внедрения обновлений нет необходимости обновлять приложения на каждом компьютере или устройстве, достаточно обновить систему на сервере.

4) Веб-сервис менее требователен к ресурсам, чем настольное приложение, т.к. все сложные вычисления происходят на стороне сервера.

Единственным недостатком веб-сервисов является наличие постоянного устойчивого широкополосного соединения с сетью Интернет, и, как следствие, большой объем сетевого трафика.

Веб-сервисы могут быть реализованы разными способами.

а) Веб-сервисы на основе SOAP

SOAP веб-сервис базируется на таких протоколах как UDDI, SOAP, WSDL и протоколах передачи данных (HTTP, SMTP, FTP и т.д.).

SOAP (Simple Object Access Protocol) — протокол обмена сообщениями между потребителем и поставщиком веб-сервиса;

WSDL (Web Services Description Language) — язык описания внешних интерфейсов веб-службы;

UDDI (Universal Discovery, Description and Integration) — универсальный интерфейс распознавания, описания и интеграции, используемый для формирования каталога веб-сервисов и доступа к нему.

Все эти протоколы основаны на XML.

На рисунке 1 приведена концептуальная схема технологии веб-сервисов на основе SOAP.

Рисунок 1 — Концепция веб-сервиса.

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

б) веб-сервисы RESTful

SOAP веб-сервис использует набор протоколов и стандартов, в то время как RESTful веб-сервис базируется только на протоколе HTTP.

REST не является протоколом, REST – это метод взаимодействия компонентов, при котором вызов удаленной процедуру представляет собой обычный HTTP-запрос, а необходимые данные передаются в качестве параметров запроса. Поэтому RESTful веб-сервис можно считать упрощенным вариантов SOAP веб-сервиса, и, как следствие более быстрым.

2. Рост популярности мобильных платформ

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

Данная тенденция обусловлена несколькими факторами. Первый фактор – это быстрое развитие технологий доступа к сети интернет. Технологии четвертого поколения мобильной связи (4G) позволяют осуществлять передачу данных со скоростью, превышающую 100 Мбит/сек.

Вторая причина роста популярности мобильных платформ – их удешевление. Каждый год средняя цена на мобильные устройства снижается приблизительно на 10%.

Наиболее популярными, на сегодняшний день, мобильными платформами являются Apple iOS, Android и Windows Phone.

1.2 Описательная постановка задачи

Имеется веб-служба для организации совместных покупок.

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

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

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

После проведения закупки организатор перемещает заказанные товары в центр раздачи заказов (ЦРЗ). ЦРЗ обеспечивает временное хранение и выдачу заказов.

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

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

Рисунок 2 — Диаграмма вариантов использования.

1.3 Формальная постановка задачи

Совместная покупка — это покупка товара группой лиц, непосредственно у поставщика по оптовой цене.

Этапы проведения совместной покупки:

1) Организатор получает у поставщика каталог товаров, размещает его на сайте и начинает «Совместную покупку».

2) Организатор осуществляет сбор заказов.

3) После того как все участники закупки сделали свои заказы, организатор отправляет общую заявку поставщику.

4) Поставщик, выставляет счет, где указаны заказанные товары и их цена.

5) Далее организатор оповещает всех участников закупки о наличии их заказов по счету и собирает с заказчиков предоплату.

6) После сбора предоплаты организатор производит оплату счета поставщику.

7) Поставщик получает деньги и отправляет груз через транспортную компанию.

8) По прибытию груза организатор распределяет заказы по каждому участнику закупки и перемещает заказы в ЦРЗ.

Все товары для участника покупки организатор формирует в пакеты.

ЦРЗ упрощает процесс выдачи пакетов участникам покупки. По различным причинам участник не всегда может прибыть на место встречи с организатором. В результате возникают проблемы с получением своего заказа.

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

Время хранения пакета в ЦРЗ, обычно, полгода, после чего пакет утилизируется.

Информация о каждом пакете в ЦРЗ хранится на сервере. Каждый пакет имеет свой номер и пин-код. Чтобы получить заказ, участник должен сообщить номер пакета и пин-код, если пин-код верен, участник получает пакет и платит определенную сумму за услугу хранения и выдачи.

Так как пакет в ЦРЗ хранится не больше полугода, то каждый год нумерация пакетов начинается с нуля. Номер пакета так же отображается с помощью штрих-кода. Штрих-код используется для упрощения процесса приема и выдачи пакета — вместо того, чтобы переписывать номер вручную, его можно считать сканером штрих-кодов.

Для функционирования системы необходимо разработать приложение, которое

а) обеспечивает подключение приложения к серверу для возможности получения необходимой информации об ЦРЗ и, находящегося в нем, пакете.

б) обеспечивает взаимодействие с ЦРЗ и пакетами: прием, выдача, перемещение.

б) автоматизирует ввод номера пакета для поиска в ЦРЗ с помощью функции сканера штрих-кодов.

1.4 Декомпозиция задачи

Разработку приложения можно разбить на следующие задачи и подзадачи:

1. Организация авторизации.

1.1. Реализация интерфейса авторизации.

1.2. Получения подтверждения об авторизации от сервера.

1.3. Отображение доступных ЦРЗ.

2. Реализация сканера штрих-кодов для автоматизированного получения номера пакета.

3. Организация приема пакетов.

3.1. Реализация интерфейса для ввода номера пакета.

3.1.1. Ввод номера вручную с клавиатуры.

3.1.2. Получение номера с помощью сканера штрих-кодов.

3.2. Реализация поиска пакета.

3.2.1. Отправка введенного номера на сервер.

3.2.2. Получение информации о пакете от сервера.

3.2.3. Реализация интерфейса для вывода информации о пакете.

3.3. Реализация приема пакета.

3.3.1. Реализация возможности отправки на сервер соответствующей информации о приеме пакета.

4. Организация выдачи пакетов.

4.1. Реализация интерфейса для ввода номера пакета.

4.1.1. Ввод номера вручную с клавиатуры.

4.1.2. Получение номеров с помощью сканера штрих-кодов.

4.2. Реализация поиска пакета.

4.2.1. Отправка введенного номера на сервер.

4.2.2. Получение информации о пакете от сервера.

4.2.3. Реализация интерфейса для вывода информации о пакете.

4.3. Реализация выдачи пакетов.

4.3.1. Реализация проверки пин-кода через сервер.

4.3.2. Реализация возможности отправки на сервер информации о выдаче пакета.

4.3.3. Реализация групповой выдаче пакетов.

5. Организация транспортировки пакетов.

5.1. Поиск доступных пакетов для перемещения.

5.1.1. Отправка запроса на сервер и получение информации о доступных пакетах.

5.1.2. Реализация интерфейса для отображения списка ЦРЗ, в которые можно переместить пакеты и интерфейса для отображения пакетов.

5.2. Реализация перемещения.

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

6. Вывод информации о складе.

6.1. Отправка запроса на сервер и получение информации о хранимых в ЦРЗ пакетах.

6.2. Реализация интерфейса для отображения списка хранимых пакетов.

6.3. Реализация возможности выдать выбранный пакет (переход на экран выдачи с номером выбранного пакета).

6.4. Реализация фильтрации пакетов по статусу, дате, получателю и отправителю.

7. Вывод информации о балансе.

7.1. Отправка запроса на сервер и получение информации о балансе ЦРЗ.

7.2. Реализация интерфейса для вывода полученной информации.

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

ПРОЕКТИРОВАНИЕ СИСТЕМЫ

2.1 Основные требования, предъявляемые системе

Для успешной реализации системы заказчиком были сформулированы основные задачи и требования к функционалу:

1. Авторизация пользователя в системе (отправка логина и пароля на сервер, получение подтверждения).

2. Получение и отображение списка доступных ЦРЗ с описанием и возможными действиями с ними (получение пакета, выдача пакета, перемещение пакета, склад пакетов, баланс ЦРЗ).

3. Реализация основных функций для работы с ЦРЗ:

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

Штриховой код (штрих-код) — это последовательность черных и белых полос, представляющая некоторую информацию в виде, удобном для считывания техническими средствами. По способу кодирования штрих-коды делятся на линейные и двухмерные. Линейные штрих-коды позволяют кодировать небольшой объем данных. Двухмерные штрих-коды были разработаны для кодирования большого объема информации.

К линейным штрих-кодам относятся такие форматы, как EAN8, EAN-13, UPC-A, UPC-E, Code56, Code128, Codabar и т.д. К двумерным – Aztec Code, Data Matrix, MaxiCode, PDF417, QR код и т.д.

В ЦРЗ для кодирования номеров пакетов используется линейный штрих-код формата EAN-13, т.к. он является наиболее распространённым и поддерживается практически всеми программами и всем оборудованием, работающими со штрих-кодами.

Для удобства хранения в ЦРЗ, пакты сортируются в 10 контейнеров, в зависимости от контрольного разряда номера пакета в штрих-коде.

Расчет контрольного разряда происходит по следующему алгоритму:

1) Все разряды нумеруются справа налево от 1 до 14.

2) Складываются значения всех четных разрядов, начиная со 2-го.

3) Полученная сумма умножается на 3.

4) Складываются значения всех нечетных разрядов, начиная с 3-го.

5) Складываются результаты, полученные во 2 и 3 шаге.

6) Значением контрольного разряда является наименьшее число, которое в сумме с величиной полученной в шаге 4, дает число, кратное 10.

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

3.3. Прием пакетов. Прием пакетов осуществляется только по номеру пакетов. Номер пакета вводится одним из двух способов: вручную с клавиатуры или с помощью сканера штрих-кодов.

3.4. Выдача пакетов. Поиск пакетов для выдачи осуществляется либо по номеру искомого пакета, либо по имени получателя пакета. Номер пакета вводится одним из двух способов: вручную с клавиатуры или с помощью сканера штрих-кодов. При поиске по имени отображаются все пакеты, предназначенные для данного получателя. При поиске по номеру пакета отображаются так же все пакеты, предназначенные для данного получателя, однако, первым в списке найденных пакетов стоит тот пакет, номер которого был введен. Первыми в списке стоят пакеты, которые имеют статус «На выдаче», т.е. эти пакеты можно выдать получателям. Для выдачи пакета необходимо проверить пин-код. Если пин-код верный, то пакет выдается получателю. Если пакетов, несколько, то, чтобы не выдавать пакет по одному, организуется выдача пакетов группой. Из списка найденных пакетов выделяются те, которые необходимо выдать, а при выдаче пин-код проверяется не для каждого выделенного пакета, а только для первого. Если пин-код верный, то все выделенные пакеты выдаются получателю.

3.5. Перемещение пакетов. При перемещении необходимо отобразить список ЦРЗ, для которых есть пакеты для перемещения, а так же список этих пакетов. Пакеты перемещаются либо в один ЦРЗ, либо в несколько ЦРЗ сразу. Для выбранных ЦРЗ автоматически подсчитывается количество перемещаемых пакетов и сумма, которую необходимо отдать курьеру за перемещение.

3.6. Склад пакетов. Склад пакетов – это список всех пакетов, находящихся в данном ЦРЗ. Приложение выводит найденные пакеты по частям, по 20 штук. Когда на экране появляется последний пакет, то приложение дополняет список еще одной частью пакетов и так до тех пор, пока не будут выведены все пакеты. Любой пакет из склада можно выдать получателю, для этого необходимо предусмотреть прямой переход из экрана склада на экран выдачи с номером выбранного пакета.
Так же необходимо реализовать фильтр по следующим критериям: статус, дата формирования, имя отправителя и имя получателя.

3.7. Баланс ЦРЗ. Отображение доходов и расходов ЦРЗ по дням за хранение, выдачу и перемещение пакетов.

Для реализации данного функционала был предоставлен RESTful веб-сервис, а так же его программный интерфейс API, с перечнем методов для получения необходимой информации.

2.2 Выбор инструментальных средств

Разработка приложения для Android может вестись практически на любом языке, однако чаще других используется язык Java, т.к. при разработке на языке Java не нужны дополнительные инструменты, как, например, NDK (Native Development Kit) и JNI (Java Native Interface). К этим инструментам советуют прибегать в редких случаях, таких как:

1. Необходимо увеличить производительность (например, сортировка большого объема данных).

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

3. Программирование на низком уровне.

Для создания программ на языке Java необходимо специальное программное обеспечение, которое можно загрузить с официального сайта разработчика, Oracle Corporation. К этому программному комплексу относятся такие инструменты как JRE (Java Runtime Environment) и JDK (Java Development Kit). JRE представляет собой среду выполнения — минимальную реализацию виртуальной машины, в которой запускается и выполняется программный код на Java. JDK — это в свою очередь целый набор инструментов, комплект разработчика приложений на языке Java. На самом деле, JRE также входит в состав JDK, равно как и различные стандартные библиотеки классов Java, компилятор javac, документация, примеры кода и разнообразные служебные утилиты. Весь этот набор распространяется свободно и имеет версии для различных ОС, поэтому любой может его скачать и использовать. В JDK не входит интегрированная среда разработки, её необходимо устанавливать отдельно.

Существуют многочисленные IDE (Integrated development environment – интегрированная среда разработки) для Java-разработки, например, NetBeans, IntelliJ IDEA, Borland JBuilder и другие.

Для многих IDE, например Eclipse или NetBeans, разработаны специальные плагины для разработки приложений для платформы Android. Каждая IDE имеет свои достоинства и недостатки. Например, IDE NetBean не имеет плагина для разработки графического интерфейса приложений для Android.

Наиболее функциональными средами разработки для платформы Android являются Eclipse и официальная IDE Android Studio. Обе IDE обладают схожим функционалом:

- Интеллектуальный редактор кода.

- Имеют шаблоны кода.

- Имеют интеграцию с веб-сервисом хостинга проектов.

- Поддерживают режим многооконного редактирования файлов.

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

Однако Android Studio имеет несколько недостатков, по сравнению с Eclipse:

- Android Studio не поддерживает работу сразу с несколькими проектами.

- Android Studio имеет более высокие системные требования.

В тоже время Eclipse, по сравнению c Android Studio, имеет свой недостаток: для разработки под Android необходимы дополнительные плагины.

Наиболее важным плагином для IDE Eclipse является ADT (Android Development Tools). ADT расширяет возможности Eclipse, что позволяет быстро настраивать новые проекты Android, создавать интерфейс приложения, добавлять компоненты на основе Android Framework API, отлаживать приложения, использующие Android SDK инструменты, а так же собирать и компилировать проект в файл с расширением APK.

Еще одним важным плагинов для разработчиков является AVD (Android Virtual Device). Этот плагин позволяет запускать эмулятор платформы Android. AVD имеет гибкую систему настроек и позволяет эмулировать любой девайс с операционной системой Android. AVD позволяет задать диагональ и разрешение экрана, версию операционной системы Android, тип процессора, наличие основной и дополнительной камеры, объем оперативной памяти, объем памяти, выделяемый для каждого приложения, объем внутренней памяти, наличие и объем карты памяти SD-card. Этот плагин помогает разработчикам тестировать свои проекты на разных устройствах с различными версиями операционной системы, с различными разрешениями дисплея и прочими характеристиками.

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

В качестве СУБД (системы управления базами данных) на сервере используется СУБД MySQL.

Данная СУБД имеет ряд преимуществ, по сравнению с другими СУБД:

- MySQL превосходит другие СУБД по скорости работы.

- В MySQL реализован кэш запросов, что позволяет увеличить скорость обработки повторяющихся запросов.

- MySQL оснащен большим количеством API для других языков.

- В комплект поставки MySQL выходят несколько пакетов для тестов и замеров производительности.

- MySQL поддерживает больше стандартных функций ODBC (Open Database Connectivity), чем другие СУБД.

- В MySQL имеется возможно сжатия доступных данных только для чтения таблиц, что повышает производительность.

- В MySQL реализована значительно более мощная система привилегий.

2.3 Проектирование схемы функционирования системы

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

Чаще всего клиент-серверные приложения состоят как минимум из трёх основных компонентов:

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

2) Серверная часть — это программа или скрипт на веб-сервере, обрабатывающая запросы пользователя (запросы от клиентского приложения). Серверную часть, так же как и клиентскую, можно писать практически на любом языке. Наиболее популярными языками являются PHP, Ruby, Python и Java.

При необходимости, приложение-клиент отправляет запрос к серверу через протокол HTTP. Сервер обрабатывает этот запрос, вызывая некоторый скрипт или метод, который формирует ответ и отсылает его клиенту. Ответ может быть представлен в разном виде: в виде текста, HTML-страницы, XML-файла или JSON-объекта.

3) База данных (БД, или система управления базами данных) — программное обеспечение на сервере, занимающееся хранением данных и их выдачей в нужный момент. База данных располагается на сервере. Серверная часть приложения обращается к базе данных, извлекая данные, которые необходимы для формирования ответа, запрашиваемого пользователем.

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

- клиент посылает http-запросы веб-серверу через сеть интернет;

- веб-сервер вызывает php-скрипт для обработки запроса;

- php-скрипт, при необходимости, обращается к базе данных;

- в итоге php-cкрипт возвращает ответ в виде JSON-объекта, из которого клиент извлекает необходимую информацию.

На рисунке 3 приведена графическая схема взаимодействия компонентов клиент-серверного приложения.

Рисунок 3 – взаимосвязь компонентов распределенного приложения.

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

2.4 Перечень функциональности.

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

Как <роль>, я <действие>, чтобы <ценность или влияние>.

В разрабатываемой системе всего одна роль — пользователь.

1. Как пользователь, я авторизовываюсь, чтобы получить список доступных ЦРЗ и иметь возможность взаимодействовать с ними.

2. Как пользователь, я хочу принять пакет в требуемый ЦРЗ.

2.1. Как пользователь, я ищу пакет в системе, чтобы его принять.

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

2.1.2. Как пользователь, я сканирую штрих-код пакета, чтобы его в системе.

2.2. Как пользователь, я принимаю пакет, для дальнейшей его выдачи.

3. Как пользователь, я хочу выдать пакет клиенту, чтобы получить деньги за его хранение.

3.1. Как пользователь, я ищу пакет в системе, чтобы его выдать.

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

3.1.2. Как пользователь, я сканирую штрих-код пакета, чтобы его в системе.

3.2. Как пользователь, я выдаю пакет клиенту, чтобы получить деньги за его хранение.

4. Как пользователь, я хочу переместить пакет из текущего ЦРЗ в другой ЦРЗ, чтобы получить деньги за его хранение.

4.1. Как пользователь, я выбираю из списка те ЦРЗ, в которые необходимо переместить пакеты.

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

5. Как пользователь, я смотрю список пакетов в выбранном ЦРЗ, чтобы узнать какие пакеты находятся на складе.

6. Как пользователь, я смотрю статистику за текущий месяц в выбранном ЦРЗ, чтобы узнать информацию о расходах и доходах.

2.5 Моделирование структуры системы

Исходя из перечня функциональности и поставленной задачи, моделируется структура системы. На рисунке 4 представлена диаграмма классов системы.

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

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

Класс Network организует связь с сервером и содержит в себе методы для совершения запросов к серверу, а класс Handlers отвечает за обработку ответов от сервера.

Класс Scanner используется для обработки изображения с камеры, позволяя получить номер по штрих-коду.

В большинстве классов данные представляются в виде списка, для отображения списков используются специальные классы адаптеры, такие как CrcAdapter, PackageArrayAdapter, StoragePackageAdapter и другие. Каждый адаптер должен иметь набор элементов, представляющие конкретные объекты (ЦРЗ или пакет). Каждый такой объект является экземпляром соответствующего DAO (Data Access Object) класса: CrcElem, PackageGroupElem, TransElem или BalanceElem.

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

Рисунок 4 – Диаграмма классов.

Рисунок 5 – Диаграмма последовательности.

Как видно из диаграмм, инициатором большинства действий является пользователь, а точкой взаимодействия является класс MyCrcActivity. Взаимодействие с сервером происходит через менеджер доступа, роль которого в системе будут играть два класса: Network (для отправки запросов) и Handlers (для получение и разбора ответов).

2.6 Проектирование пользовательского интерфейса

При запуске приложения пользователь попадает на экран авторизации, если до этого не был авторизован, в противном случае, пользователь попадает на главный экран, отображающий список доступных ЦРЗ. На рисунке 6 изображена схема интерфейса для экрана авторизации, на рисунке 6а) схема интерфейса главного экрана, на рисунке 7б) схема отдельного элемента списка главного экрана.

Рисунок 6 – схема интерфейса экрана авторизации.

Рисунок 7. а) – схема интерфейса главного экрана; б) схема элемента списка главного экрана.

Используя кнопки взаимодействия, пользователь может перейти на один из 5 экранов: экран приема пакета, экран выдачи пакета, экран перемещения пакетов, экран склада или экран баланса.

Операции приема и выдачи пакетов – схожие, поэтому их интерфейс можно представить одной схемой, представленной на рисунке 8.

Рисунок 8 – схема интерфейса для приема и выдачи пакетов.

Отсюда, и в случае выдачи, и в случае принятия пакета, пользователь может попасть всего на два экрана: экран для отображения найденных пакетов или экран сканнера штрих-кодов. Схема экрана сканера изображена на рисунке 9.Экран отображения найденных пакетов в обоих случаях будет иметь схожий интерфейс, поэтому их можно представить одной схемой интерфейса, изображенной на рисунке 10.

Рисунок 9 – схема интерфейса сканера штрих-кода.

а) б)

Рисунок 10 – а) схема интерфейса отображения найденных пакетов или ЦРЗ, б) схема элемента списка отображения найденных пактов.

Третий экран, на который можно попасть из главного экрана, это экран перемещения пакетов, схема его интерфейса идентична схеме интерфейса отображения найденных пакетов (рисунок 9а), отличие лишь в отображении элементов. Ниже, на рисунке 11, изображена схема элемента списка найденных ЦРЗ.

Рисунок 11 – схема элемента списка найденных ЦРЗ.

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

а) б) в)

Рисунок 12 – а) схема интерфейса отображения пакетов на складе, б) схема элемента списка пакетов, в) схема экрана для применения фильтра.

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

а) б)

Рисунок 13 – а) схема интерфейса отображения баланса ЦРЗ, б) схема элемента списка баланса.

2.7 Методика тестирования конечного продукта.

Тестирование готового продукта должно состоять из следующих пунктов:

1. Проверка авторизации

1.1. Проверка функции авторизации

1.2. Проверка сохранения состояния авторизации

2. Проверка сканнера штрих-кода

2.1. Проверка корректного отображения изображения с камеры

2.2. Проверка возможности считывать штрих-код и получения номера

3. Проверка функций для принятия пакетов

3.1. Проверка поиска пакетов

3.2. Проверка функции принятия пакета

4. Проверка функций для выдачи пакетов

4.1. Проверка поиска пакетов

4.1.1. Проверка поиска по номеру пакета

4.1.2. Проверка поиска по имени пользователя

4.2. Проверка возможности проверки пин-кода

4.3. Проверка возможности выдачи пакета

4.4. Проверка возможности групповой выдачи

5. Проверка функций для перемещения пакетов

5.1. Проверка получения списка пакетов для конкретного ЦРЗ

5.2. Проверка функции перемещения для одного ЦРЗ

5.3. Проверка функции перемещения для нескольких ЦРЗ

6. Проверка функций для склада

6.1. Проверка получения списка пакетов на складе

6.2. Проверка фильтрации списка

6.3. Проверка перехода на экран выдачи пакета

7. Проверка получения баланса

РЕАЛИЗАЦИЯ СИСТЕМЫ

3.1 Структура приложения.

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

- Java-классы

- Манифест приложения

- Ресурсы

- Сторонние библиотеки

На рисунке 14 изображена структура разрабатываемой системы.

Рисунок 14 – структура приложения.

1) Классы

Все разработанные Java-класса находятся в папке src.

2) Android-манифест.

Манифест приложения находится в корневой папке проекта и представляет собой XML файл, выполняющий следующие функции:

- Определяет имя Java-пакета приложения. Имя пакета представляет собой уникальный идентификатор для приложения.

- Объявляет минимальный уровень Android API, который требует приложение.

- Объявляет разрешения, которые приложение должно иметь для доступа к защищённым частям API и взаимодействия с другими приложениями.

- Описывает компоненты приложения — Activity, Service, BroadcastReceiver и прочие. Определяет имена классов, реализующие каждый из компонентов и оглашает их возможности (например, какие Intent-сообщения они могут обрабатывать).

3) Ресурсы.

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

При сборке Android-приложения генерируется специальный класс R, в котором содержится несколько наборов данных. Каждый набор данных – ссылка на отдельный ресурс. Эти ссылки используются в коде приложения для связи с ресурсами. Все автоматически генерируемые классы находятся в папке gen.

4) Сторонние библиотеки.

Сторонние библиотеки помещаются в папки Android 4.4.2, Android private Library, Android Dependencies. К ним относятся, например, библиотеки для поддержки минимальной версии ОС.

3.2 Описание классов.

Классы, отвечающие за бизнес-логику, скрывающуюся за интерфейсом, являются наследниками класса Activity. Жизненный цикл Activity представлен на рисунке 15.

Рисунок 15 – Жизненный цикл Activity.

Основные методы жизненного цикла Activity:

1) protected void onCreate();

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

2) protected void onStart();

За onCreate() всегда следует вызов onStart(), но перед onStart() не обязательно должен идти onCreate(), так как onStart() может вызываться и для возобновления работы приостановленного приложения. При вызове onStart() окно еще не видно пользователю.

3) protected void onRestart();

Если окно возвращается в приоритетный режим после вызова onStop(), то в этом случае вызывается метод onRestart(). Т.е. вызывается после того, как активность была остановлена и снова была запущена пользователем. Всегда сопровождается вызовом метода onStart().

4) protected void onResume();

Метод onResume() вызывается после onStart(). Система вызывает этот метод каждый раз, когда Activity переходит на передний план, в том числе, при первом создании.

5) protected void onPause();

Когда пользователь решает перейти к работе с новым окном, система вызовет для прерываемого окна метод onPause(). По сути происходит свертывание активности. Сохраняет незафиксированные данные. Деактивирует и выпускает монопольные ресурсы. Останавливает воспроизведение видео, аудио и анимацию. От onPause() можно перейти к вызову либо onResume(), либо onStop().

6) protected void onStop();

Метод onStop() вызывается, когда окно становится невидимым для пользователя. Это может произойти при ее уничтожении, или если была запущена другая активность (существующая или новая), перекрывшая окно текущей активности. Всегда сопровождает любой вызов метода onRestart(), если активность возвращается, чтобы взаимодействовать с пользователем, или метода onDestroy(), если эта активность уничтожается.

7) protected void onDestroy();

Метод вызывается по окончании работы активности, при вызове метода finish() или в случае, когда система уничтожает этот экземпляр активности для освобождения ресурсов. Вызывается перед уничтожением активности. Это последний запрос, который получает Activity от системы.

Для отображения информации часто используются различные списки. За построение элементов списка используются специальные классы, которые наследуются от класса Adapter. Каждый адаптер должен перегружать метод public View getView(), который отвечает за построение каждого элемента списка. В этом методе указывается какой XML-файл используется для построения элемента списка. Из этого файла отбираются элементы и заполняются необходимой информацией. Либо в этом методе может быть динамическое добавление элементов. Метод вызывается тогда, когда очередной элемент списка появляется на экране и возвращает готовый к отображению элемент.

Чаще всего в списках отображается информация, которая приходит в ответ на запрос к серверу. Для упрощения передачи данных от сервера к адаптеру, используются специальные объекты доступа к информации – Data Access Object (DAO). При получении ответа от сервера, создаются DAO-объекты и передаются адаптеру для отображения.

3.3 Описание реализаций основных функций приложения

1. Взаимодействие с сервером.

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

За отправку запросов к серверу отвечает отдельный класс Network. В этом классе содержатся статические методы, которые производят запросы.

Каждый отдельный запрос оформляется в виде метода, в котором необходимые параметры собираются в список пар «имя – значение». В каждый метод необходимо передать подпись пользователя authtoken, с помощью которого на сервере идентифицируется пользователь. Так же необходимо передать объект типа Handler, который отвечает за обработку ответа.

Например, так выглядит метод для получения списка доступных ЦРЗ:

public static void getDSList(String authtoken, Handler handler) {

ArrayList<NameValuePair> params = new ArrayList<NameValuePair>();

params.add(new BasicNameValuePair("m", "ds"));

params.add(new BasicNameValuePair("act", "myList"));

requestJSONAsync(baseurl, params, authtoken, handler);

}

После того, как все параметры для запроса собраны, они передаются статическому методу requestJSONAsync(), вместе с клиентской подписью и объектом-обработчиком. Кроме того, в этот метод передается URL сервера, к которому будет произведен запрос.

Запрос к серверу является долговременной операцией, поэтому, в версии ОС Android ниже 3.0, основной поток, в котором находятся все объекты управления интерфейса, будет заблокирован до тех, пор, пока запрос не выполнится. Кроме того, в версиях ОС Android 3.0 и выше, попытка произвести http-запрос приведет к аварийному завершению приложения с выбросом соответствующего исключения..

Исходя из этого, в методе requestJSONAsync() создается новый поток, в котором производится вызов метода requestJSON(). Этот метод вызывает метод requestString(), который производит http-запрос и возвращает ответ от сервера в виде строки. Далее эта строка преобразуется в объект JSON, который возвращается методом requestJSON(). Далее, если http-статус ответа 200 или 201, то созданный JSON-объект передаётся на обработку в объект-обработчик handler.

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

На разные запросы, приходят разные ответы, поэтому для каждого запроса необходим свой объект-обработчик. Все классы таких объектов собираются в одном классе Handlers. Каждый объект-обработчик наследуется от класса Handler. Чтобы иметь доступ к компонентам интерфейса, в объектах-обработчиках сохраняется ссылка на Activity, в котором эти объекты были созданы. Обработка ответа производится в методе void handleMessage(), в который передается ответ в виде JSON-объекта.

2. Авторизация.

При запуске приложения запускается класс MyCrcActivity, который проверяет состояние авторизации пользователя и отображает список доступных ему ЦРЗ. В случае, если авторизация не производилась, то запускается класc LoginActivity, который производит запрос к серверу, передает ему имя пользователя и пароль, а в ответ получает специальную строку – пользовательскую подпись, с помощью которой на сервере идентифицируется пользователь.

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

void saveText(String name, String value) {

sPref = getPreferences(MODE_PRIVATE);

Editor ed = sPref.edit();

ed.putString(name, value);

ed.commit();

}

String loadText(String name) {

sPref = getPreferences(MODE_PRIVATE);

String savedText = sPref.getString(name, "");

return savedText;

}

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

Если пользователь авторизован, то приложение делает запрос к серверу, получает список доступных ЦРЗ и выводит его на экран.

3. Сканер штрих-кодов.

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

Для получения изображения с камеры необходимы как минимум 4 объекта: Camera – объект, который предоставляет доступ к камере смартфона; SurfaceView – элемент интерфейса, на который выводится изображение с камеры; SurfaceHolder – объект-посредник между камерой и SurfaceView, отвечает за вывод изображения на SurfaceView; четвертый объект должен реализовать интерфейс SurfaceHolder.Callback. Этот интерфейс обязывает объект реализовать методы жизненного цикла SurfaceHolder, именно в этих методах запускается и останавливается вывод изображения.

Однако для обработки изображения в реальном времени этого недостаточно. Поэтому необходимо реализовать еще один интерфейс ­– Camera.PreviewCallback, в котором есть только один метод onPreviewFrame(). Этот метод вызывается каждый раз, когда изображение с камеры поступает в SurfaceHolder. Одним из аргументов этого метода является массив байт, который содержит в себе изображение с камеры. В этом методе производится обработка изображение для поиска штрих-кода и получение его номера.

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

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

Далее этот объект в объект BinaryBitmap, который позже будет передан на обработку.

2) Создается объект MultiFormatReader, который отвечает за обработку изображения штрих-кода.

MultiFormatReader mfr = new MultiFormatReader();

После создания его нужно настроить таким образом, чтобы он искал только те типы штрих-кодов, которые необходимы, т.е. штрих-код типа EAN-13. Для этого создается ассоциативный массив Map<DecodeHintType,Object>, в котором ключ указывает на тип настраиваемого параметра, а объект является параметром. Map<DecodeHintType,Object> hints = new HashMap<DecodeHintType, Object>();

Для настройки на определенный тип штрих-кода в этот массив добавляется элемент Vector<BarcodeFormat> с ключом DecodeHintType.POSSIBLE_FORMATS .

Vector<BarcodeFormat> decodeFormats = new Vector<BarcodeFormat>(1);

decodeFormats.add(BarcodeFormat.EAN_13);

hints.put(DecodeHintType.POSSIBLE_FORMATS, decodeFormats);

После этого этот массив добавляется в объект MultiFormatReader.

mfr.setHints(hints);

3) Обработка изображения и получение результатов. Обработка производится с помощью метода decodeWithState() объекта MultiFormatReader, в который передается подготовленное ранее изображение. Метода возвращает объект Result, из которого с помощью метода getText() можно получить номер штрих-кода в виде строки.

3.4 Реализация пользовательского интерфейса

Интерфейс каждого экрана, элемент списков и диалоговых окон в приложении описывается отдельными файлами на языке XML. Такие файлы называют файлами компоновки или Layout-файлами.

Расположение View-элементов на экране зависит от ViewGroup (Layout), в которой они находятся. Основные виды Layout:

- LinearLayout – отображает View-элементы в виде одной строки или столбца.

- TableLayout – отображает элементы в виде таблицы, по строкам и столбцам.

- RelativeLayout – для каждого элемента настраивается его положение относительно других элементов.

- AbsoluteLayout – для каждого элемента указывается явная позиция на экране в системе координат (x,y).

В каждом Layout-файле корневым элементом должен быть один из этих ViewGroup.

На рисунке 15 а) изображена структура компонентов одно из экранов. Как видно из рисунка, корневым элементом является LinearLayout. Это значит, что каждый его дочерний узел будет занимать одну строку. У корневого элемента всего один дочерний – LinearLayout. На первый взгляд может показаться бессмысленным вставлять один LinearLayout в корневой элемент LinearLayout. Однако, это не так, поскольку для дочернего узла выставляются отступы от края корневого. Это видно на рисунке 16 б), на котором изображена копия экрана авторизации.

а) б)

Рисунок 16 – а) структура компонентов экрана авторизации; б) экран авторизации.

Неавторизованный пользователь попадает на экран авторизации. Если же пользователь уже был авторизован ранее, то запускается главный экран, который изображен на рисунке 17.

а) б) в)

Рисунок 17 – а) главный экран; б) схема главного экрана; в) схема элемента списка главного экрана.

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

Экраны приема и выдачи пакетов, а также экран результата поиска пакетов практически идентичны. Экраны приема и выдачи пакетов изображены на рисунке 18, а экран результатов поиска на рисунке 19.

Экраны приема и выдачи пакетов содержат поле ввода номера или имени пользователя и несколько кнопок для поиска и включения сканера.

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

а) б)

Рисунок 18 – а) экран приема пакетов; б) экран выдачи пакетов.

а) б)

Рисунок 19 – Экран результатов поиска для: а) выдачи пакетов; б) приема пакетов.

Следующий экран, на который можно попасть из главного – это экран перемещения пакетов, изображенный на рисунке 20 а). Экран представляет собой список ЦРЗ, для которых имеются пакеты на складе. Поэтому при нажатии на один из ЦРЗ, пользователь попадает на экран склада пакетов. В этом случае экран склада будет отображать только те пакеты, которые доступны для перемещения в выбранный ЦРЗ. Экран склада представлен на рисунке 20 б).

а) б)

Рисунок 20 – а) экран перемещения пакетов; б) экран склада.

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

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

Рисунок 21 – экран баланса.

3.5 Результаты тестирования системы

ЗАКЛЮЧЕНИЕ

В процессе проведения квалификационной работы был произведен анализ предметной области.

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

Затем спроектированная система была реализована в виде программного обеспечения, которое отвечает всем требованиям заказчика.

После реализации программный продукт проходил тестирование по разработанному методу. В ходе проведения тестирования были выявлены и исправлены некоторые ошибки.

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

Список использованных источников

1. Совместные покупки. URL: https://sp2all.ru/help/?page=help (дата обращения: 01.06.2015).

2. Википедия | штриховой код. URL: https://ru.wikipedia.org/wiki/штриховой_код (дата обращения: 01.06.2015).

3. Википедия | European_Article_Number. URL: https://ru.wikipedia.org/wiki/European_Article_Number (дата обращения: 01.06.2015).

4. Habrahabr | Введение в Android NDK. URL: http://habrahabr.ru/post/203014/ (дата обращения: 4.06.2015).

5. Компьютер пресс | Тенденции развития технологий разработки приложений. URL: http://compress.ru/article.aspx?id=16579 (дата обращения: 4.06.2015).

6. Учебно-методические материалы для студентов кафедры АСОИУ | Веб-сервисы как средство интеграции приложений в WWW. URL: http://www.4stud.info/networking/web-services.html (дата обращения: 7.06.2015).

7. Википедия | Веб-служба. URL: https://ru.wikipedia.org/wiki/Веб-служба (дата обращения: 7.06.2015).

8. Систему онлайн-учета "Большая Птица" | В чем заключаются преимущества веб-сервиса и в чем его отличие от "настольных" программ? URL: http://bigbird.ru/faq/v-chem-zaklyuchayutsya-preimushchestva-veb-servisa-i-v-chem-ego-otlichie-ot-nastolnyh-programm (дата обращения: 9.06.2015).

9. Variety | Кто выигрывает войну на рынке смартфонов? URL: http://www.varietyrussia.com/film/01