Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

– создавать на основании полученного задания лист учета рабочего времени;

– заполнять отчет сотрудника на основании листа учета рабочего времени;

– выполнять синхронизацию с основной учетной системой;

– загружать измененные и новые данные в мобильное приложение;

– выгружать измененные и новые данные из мобильного приложения в основную учетную систему;

– отслеживать этапы синхронизации данных.

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

– выделять цветом просроченные задания;

– выделять цветом листы учета рабочего времени;

– зеленый цвет – закрыт и сдан;

– серый цвет – закрыт, но не сдан;

– красный цвет – не сдан и не закрыт.

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

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

2 ПРОЕКТИРОВАНИЕ

2.1 Анализ существующих разработок

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

– «Агент плюс 2.0 курьерская служба»;

– автоматизация диспетчерских служб «Наполеон».

Разработка «Агент Плюс 2.0 Курьерская служба» ориентированно на работу курьера. Данная система специализируется на работе с грузами.

Разработка «Автоматизация диспетчерских служб «Наполеон»» в свою очередь ориентированно на работу непосредственно с товарами.

Ниже представлена сравнительная таблица существующих разработок и разрабатываемого мобильного приложения «Мобильное автоматизированное рабочее место сервис-инженера». [19]

Таблица 1 – Сравнительная характеристика мобильного приложения и существующих разработок

Продолжение таблицы 1

Как видно из таблицы, что существующие разработки по многим пунктам удовлетворяют требованиям. Однако, они не подходят для организации «РОСИНКАС», так как интеграция этих разработок невозможна с учетной системой организации без значительной доработки, как самих решений, так и учетной системы. Исходя из этого, было принято решение создать мобильное приложение, которое бы в полной мере удовлетворяло нуждам организации.

2.2 Требования к мобильному АРМ

Перед разработкоймобильного автоматизированного рабочего места

сервис – инженера перечислим основные требования к нему:

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

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

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

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

Основные функции, выполняемые системой:

– хранение необходимой информации;

– ввод необходимой информации;

– ведение документов, специализированных отчетов;

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

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

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

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

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

– мобильное устройство или планшетный компьютер;

– процессор Intel x86 и ARM с архитектурой ARMv5TE и выше (ARMv6, ARMv7, ARMv8);

– минимальный размер RAM 256 мегабайт;

– сенсорный экран;

– соединение с Internet 500 Kb/сек (1 Mb/сек).

Требования к программному обеспечению:

– операционная система мобильного устройства Android 2.3 и выше;

– мобильная платформа «1С Предприятие 8».

Требования к пользователям:

– пользователь мобильного приложения должен уметь пользоваться мобильным устройством под управлением операционной системы Android.

2.3 Архитектура системы мобильного АРМ и алгоритм синхронизации

с основной учётной системой

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

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

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

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

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

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

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

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

Рисунок 2 – Блок-схема синхронизация с основной учетной системой

2.4 Спецификация данных

Описание протокола и механизма обмена данными

Для синхронизации данных с основной учетной системой предприятия используется Web-сервис. Web-сервис идентифицируется строкой URI (UniformResourceIdentifier) – унифицированным идентификатором ресурса (символьная строка, позволяющая идентифицировать какой-либо ресурс).

Web-сервис имеет программный интерфейс, представленный в формате WSDL (Web ServicesDescriptionLanguage) – язык описания web-сервисов и доступа к ним, основанный на языке XML. Предназначен для унифицированного представления внешних интерфейсов web-службы и используется для того, чтобы другая программа знала, что такой «сервис» есть у этой программы (в данном случае, основная учетная система выкладывает сведения о сервисе в формате файла WSDL).

Приложение взаимодействует с web-сервисом путем обмена сообщениями протокола SOAP (SimpleObjectAccessProtocol). Протокол SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTPS и другие, но чаще всего SOAP используется поверх HTTP. SOAP используется для обмена произвольными сообщениями в формате XML и удаленного вызова процедур. [19]

Для того чтобы мобильное приложение могло обращаться к процедурам, описанным в web-сервисе основной учетной системы необходимо:

– создать web-сервис в основной учетной системе и в модуле web-сервиса прописать все необходимые процедуры;

– опубликовать созданный web-сервис встроенными средствами конфигуратора.

Все параметры операций web-сервиса описываются при помощи типов XDTO и могут представлять собой либо значения XDTO, либо объекты XDTO.

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

Характеристики

Список файлов ВКР