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

АННОТАЦИЯ
ВКР 100 с., 37 рис., 8 табл., 20 источников, 1 прил.
ВЗАИМОДЕЙСТВИЕ
МОБИЛЬНОГО
КЛИЕНТА
И
СЕРВЕРА
СИТУАЦИОННОГО ЦЕНТРА ДЛЯ РЕШЕНИЯ ПРОБЛЕМ ГОРОДСКОГО
ХОЗЯЙСТВА.
Выпускная квалификационная работа посвящена разработке схемы
взаимодействия мобильного приложения и сервера ситуационного центра для
решения
проблем
городского
хозяйства
и
разработке
мобильного
приложения, использующую эту схему взаимодействия с сервером.
В первой главе происходит описание предметной области, проводится
обзор существующих подходов к взаимодействию с сервером и ставятся
задачи исследования.
Во второй главе проводится исследование и анализ существующих
подходов взаимодействия мобильного приложения и сервера, выделяются их
недостатки и преимущества и, на основе полученных данных, формируется
схема взаимодействия мобильного приложения и сервера для решения
проблем городского хозяйства.
В третьей главе проводится проектирование мобильного приложения,
использующего разработанную схему взаимодействия с сервером, где
указывает логика взаимодействия, структурная схема и общий алгоритм
работы мобильного приложения.
В
четвертой
мобильного
подсистем
главе
приложения,
приложения,
происходит
описываются
проводится
непосредственная
алгоритмы
построение
работы
логики
реализация
отдельных
диалога
с
пользователем и приводятся экранные формы сайта и мобильного
приложения.
4
Содержание
ВВЕДЕНИЕ
6
1 АНАЛИЗ И ИССЛЕДОВАНИЕ ПОДХОДОВ К ВЗАИМОДЕЙСТВИЮ
МОБИЛЬНОГО ПРИЛОЖЕНИЯ С СЕРВЕРОМ ДЛЯ РЕШЕНИЯ ПРОБЛЕМ
ГОРОДСКОГО ХОЗЯЙСТВА
8
1.1 Описание предметной области сервиса по решению проблем городского
хозяйства
8
1.2 Обзор существующих подходов к взаимодействию мобильного клиента и
сервера для мониторинга удаленных объектов
12
1.3 Исследование и анализ технологий взаимодействия мобильного клиента и
сервера ситуационного центра для решения проблем городского хозяйства
22
1.4 Постановка задачи исследования
27
2 РАЗРАБОТКА СХЕМЫ ВЗАИМОДЕЙСТВИЯ МОБИЛЬНОГО
ПРИЛОЖЕНИЯ И СЕРВЕРА СИТУАЦИОННОГО ЦЕНТРА ДЛЯ
РЕШЕНИЯ ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА НА ОСНОВЕ
АНАЛИЗА СУЩЕСТВУЮЩИХ РЕШЕНИЙ
30
2.1 Исследование и анализ подходов к взаимодействию клиента и сервера по
мониторингу состояний удаленных объектов
30
2.2 Анализ преимуществ и недостатков существующих мобильных решений,
основанных на их взаимодействии с сервером
32
2.3 Разработка схемы взаимодействия мобильного приложения с сервером
ситуационного центра для решения проблем городского хозяйства
34
3 ПРОЕКТИРОВАНИЕ МОБИЛЬНОГО ПРИЛОЖЕНИЯ СЕРВИСА ДЛЯ
РЕШЕНИЯ ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА
40
3.1 Логическая схема построения сети сервиса решения проблем городского
хозяйства
40
3.2 Логика взаимодействия мобильного приложения с сервером
ситуационного центра
43
3.3 Структурная схема мобильного приложения
48
5
3.4 Общий алгоритм функционирования схемы взаимодействия мобильного
приложения с сервером ситуационного центра
51
4 РЕАЛИЗАЦИЯ ВЗАИМОДЕЙСТВИЯ МОБИЛЬНОГО ПРИЛОЖЕНИЯ И
СЕРВЕРА СИТУАЦИОННОГО ЦЕНТРА ДЛЯ РЕШЕНИЯ ПРОБЛЕМ
ГОРОДСКОГО ХОЗЯЙСТВА
54
4.1 Разработка алгоритмов работы отдельных подсистем мобильного
приложения
54
4.2 Построение логики диалога с пользователем
59
4.3 Экранные формы информационной системы, реализующая
разработанную методику
66
4.4 Методика тестирования взаимодействия мобильного приложения и
сервера ситуационного центра для решения проблем городского хозяйства
77
ЗАКЛЮЧЕНИЕ
82
СПИСОК ЛИТЕРАТУРЫ
84
ПРИЛОЖЕНИЕ А - ЛИСТИНГ КОДА ОСНОВНЫХ ФУНКЦИЙ
86
УДОСТОВЕРЯЮЩИЙ ЛИСТ № 165178
98
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА ДОКУМЕНТА
НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
99
6
ВВЕДЕНИЕ
Невозможно
представить
современный
мир
без
информационных
технологий. Они внедрены практически во все сферы человеческой деятельности,
включая социальную, экономическую и научно-техническую. Основная цель
применения информационных технологий является улучшение качества жизни
каждого человека за счет автоматизации последовательности получения
обработанных данных и оперативного получения конечной информации за счет
скорости выполнения задач техническими устройствами.
Информационные системы позволяют выполнять сбор необходимых
данных, эффективно обрабатывать полученную информацию и передавать ее в
измененном виде пользователю для дальнейшей ручной обработки. Сбор данных
обычно происходит при помощи вспомогательных устройств и дополнительного
программного обеспечения. В качестве вспомогательных устройств повсеместно
выступают мобильные телефоны. В современном мире мобильные устройства не
являются редкостью и их мощность с каждым годом только растет. Помимо их
основной цели применения — связывать людей в любой точке земного шара, они
могут быть применены и для решения широкого круга задач, которые могу быть
выполнены при помощи дополнительных модулей. Такими модулями могут
выступать WiFi, камера, модуль распознавания географического положения
пользователя (GPS, ГЛОНАСС), модуль взаимодействия с сетью и другие. После
передачи
данных
информационная
система
выполняет
их
обработку
в
соответствии с определенным ранее заданным алгоритмом. В большинстве
случаев проводится аналитика, формируются графики и указываются отклонения
от норм и способы приведения представленных параметров в нормализованные
пределы. На последнем этапе работы информационной системы конечный
пользователь получает выходные данные в наиболее удобном для понимания
виде.
Сферы применения описанной ранее информационной системы и методы ее
работы достаточно многообразны. Например, она позволяет эффективно решать
7
проблемы городского хозяйства. Так как город обычно располагается на
значительной территории, то управление состоянием городской инфраструктуры,
разнесенной на ее площади, является первостепенной задачей администрации
города.
Систематическое
наблюдение
за
элементами
инфраструктуры
и
своевременное получение информации об их текущем состоянии позволяет
провести анализ и сделать выводы о дальнейших шагах к повышению качества
обслуживания. В связи с ростом городов и их инфраструктуры информационная
система такого рода никогда не потеряет актуальность, и сферы ее применения
будут только расширяться.
Целью
выпускной
квалификационной
работы
является
повышение
эффективности управления городским хозяйством за счет внедрения новой схемы
взаимодействия мобильного приложения и сервера ситуационного центра.
Для осуществления поставленной цели необходимо выполнить следующие
задачи:

рассмотреть существующие подходы взаимодействия мобильных
приложений и серверов по мониторингу состояний объектов;

провести
исследование
и
анализ
технологий,
позволяющих
эффективно проводить взаимодействие мобильного устройства с сервером;

сформулировать задачи исследования;

провести анализ архитектуры информационной системы мониторинга
состояний объектов;

разработать
схему
взаимодействия
мобильного
приложения
с
сервером, позволяющую эффективно решать проблемы городского хозяйства;

провести
проектирование
мобильного
разработанную схему взаимодействия с сервером;

разработать мобильное приложение.
клиента,
использующего
8
1 АНАЛИЗ И ИССЛЕДОВАНИЕ ПОДХОДОВ К ВЗАИМОДЕЙСТВИЮ
МОБИЛЬНОГО ПРИЛОЖЕНИЯ С СЕРВЕРОМ ДЛЯ РЕШЕНИЯ
ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА
1.1 Описание предметной области сервиса по решению проблем городского
хозяйства
Решение проблем городского хозяйства относится к классу задач
мониторинга состояния удаленных объектов посредством универсальных методик
взаимодействия специализированных технических устройств и последующей
обработкой полученной информации для представления ее в наглядном для
конечного пользователя виде.
Городское хозяйство представляет собой совокупность объектов, которые
имеются в собственности города, и состояние которых находится под полным его
контролем. Обязанностью города в данном случае является поддержка состояний
контролируемых объектов в удовлетворительном состоянии, что позволяет
обеспечить должным образом качество жизни его населения. В качестве таких
контролируемых объектов могут выступать мусорные баки, фонари столбов,
участок дорожного покрытия, состояние общественных помещений и т.п.
Для контроля состояния общественно-значимых объектов необходимо
наличие специального подразделения — управляющий центр. Он позволяет на
основе полученной информации о состояниях наблюдаемых объектов проводить
анализ полученного материала и организовывать мероприятия, направленные на
улучшения и стабилизацию их состояния. Управляющий центр имеет в своем
распоряжении всю необходимую информацию о контролируемых объектах, месте
их расположения и параметрах, за которыми необходимо вести наблюдение.
Некоторые параметры объектов могут быть зафиксированы через специальные
устройства автоматической фиксации — датчики, которые позволяют передавать
данные независимо от человека, а некоторые — только через специальных
работников центра, которые вручную заносят необходимую информацию в
мобильное приложение для ее передачи на сервер ситуационного центра.
9
Например, в качестве таких параметров могут выступать загрязненность
территорий и т.п. Список контролируемых параметров у каждого из удаленных
объектов различный, соответственно должен быть и разный формат отчета,
фиксирующего текущее состояние объектов, который должно формировать
мобильное устройство.
Основное предназначение приложения является формирование отчета о
текущем состоянии наблюдаемого удаленного объекта по сформированной
сервером ситуационного центра структуре. Набор полей отчета и их тип может
варьироваться и зависит от ситуации. Вариант использования мобильного
приложения работником диспетчерского центра представлен на рисунке 1.
Рисунок 1 — Вариант использования мобильного приложения работником
диспетчерского центра
10
Помимо формирования отчета, мобильное приложение предоставляет
работнику также ряд дополнительных опций, которые обеспечивают его всеми
необходимыми данными для обеспечения предоставления информации о
контролируемом объекте.
Для того чтобы начать пользоваться мобильным приложением необходимо
авторизоваться. Авторизация представляет собой процесс подтверждения прав
пользователя на выполнение анализа состояния объектов, зарегистрированных в
системе. Данные для авторизации выдаются каждому работнику для его
уникальной идентификации при найме на работу. После успешного входа в
систему работником ему присваивается дополнительный идентификационный
номер. Благодаря которому, диспетчер управляющего центра имеет возможность
сообщать конкретному пользователю, посредством отправления уведомления на
его мобильное устройство, о необходимости проведения анализа состояния
объекта, а не всем подряд.
Таким образом, оповещение получит работник,
который находится ближе всего к наблюдаемому объекту или к которому данное
сообщение предназначается.
Центр диспетчеризации имеет возможность контролировать действия
своего работника по выполнению своих профессиональных задач удаленно. Это
означает, что любое перемещение будет фиксироваться в информационной
системе. Такой контроль становится возможным благодаря распространенности
среди мобильных устройств модуля распознавания местоположения своего
владельца. Таким образом, когда приложение запущено оно транслирует свое
текущее местоположение в информационную систему, которая в свою очередь
отображает ее на основной карте в панели управления этой системой.
После получения уведомления о необходимости проведения анализа о
текущего состояния наблюдаемого удаленного объекта, при запуске приложения
прокладывается маршрут от текущего местоположения работника до объекта с
указанием дистанции и времени движения. За предоставлением информации о
состоянии объекта ответственен только работник диспетчерского центра, на
телефон которого пришло уведомление. Это ограничение связано с тем, чтобы не
11
произошло
коллизий
дублирующих
между
данных
о
исполнителями
текущим
и
состоянии
не
было
объекта.
предоставлено
Таким
образом,
оптимизируются человеческие ресурсы на выполнение других задачи.
После достижения работником до удаленного контролируемого объекта он
обязан зафиксировать текущее его состояние по необходимым параметрам и
отправить полученные данные в центр обработки. Так как набор контролируемых
параметров для каждого объекта различен, то и структура отчета может быть
разной. В него могут входить как графические данные в виде фотографий и видео,
так и текстовые — от обычных комментарий до предоставления подробного
отчета в любом известном современном формате doc, docx, pdf, xls и другие. Все
эти документы прикладываются в отчет в соответствии со структурой,
полученной от сервера, и отправляются туда. Информационная система
анализирует полученные данные, обновляет графики, предпринимает шаги по
стабилизации состояния объектов, имеющих отклонения от нормативных
параметров, и сохраняет данные для последующего воспроизведения. Графики
доступны
только
в
панели
диспетчера
для
наглядного
отображения
заинтересованным лицам.
После успешного принятия документов, подтверждающих состояние
удаленного объекта, на мобильный телефон работника придет подтверждение
полученных данных, которые он может потом просмотреть в истории о
состояниях конкретного объекта. Если же происходит отклонения в принятии
документов, то высылается новый формат отчета для заполнения.
Пользователю мобильного устройства доступна история отчетов объекта.
Он может фильтровать ее по определенной дате или по периоду. В детализации
конкретного отчета доступно время формирования отчета и подробные данные,
которые входили в отчет.
При возникновении проблем, связанных с предоставлением отчета о
текущем состоянии объекта работник диспетчерского центра может связаться с
диспетчером для дальнейших инструкций.
12
1.2 Обзор существующих подходов к взаимодействию мобильного клиента и
сервера для мониторинга удаленных объектов
Росту мобильных приложений по всему миру способствует потребность
человечества в инструментах, позволяющих выполнять широкий круг задач, в
которые входят:

анализ небольших порций данных;

выполнение офисных задач;

работа с финансами;

наблюдение за удаленными объектами;

развлечение;

общение;

выполнение обработки изображений и другие.
Все разработанные приложения уникальные, имеют разное предназначение
и
используют
различные
технологии.
В
зависимости
от
используемой
операционной системы (ОС) мобильные приложения делятся на 2 вида:

приложения, разработанные под операционную систему Android;

приложения, разработанные под операционную систему iOS.
Наличие
конкурирующих
операционных
систем
обусловлено
их
характеристиками и доступностью мобильных устройств, на которые могут быть
они установлены. Если параметры ОС примерно сопоставимы, то ценовой
диапазон мобильных устройств имеет серьезную разницу. Кроме того, не менее
важной ролью играет пользовательский опыт использования устройств, так как с
самой распространенной ОС проще научиться пользоваться.
Было проведено исследование по оценке рынка мобильных устройств с
различной
операционной
системой
во
всем
мире
международной
исследовательской и консалтинговой компанией IDC. Согласной ей, ОС Android
занимает лидирующие позиции по отношению к своему прямому конкуренту iOS.
Результаты исследования представлены на рисунке 2. Это обусловлено низкой
ценовой
категорией
разнообразием.
устройств,
на
которых
установлен
Android,
и
их
13
Рисунок 2 – Оценка рынка мобильных устройств в разных годах
Как видно из рисунка 2, операционная система Android является самой
распространенной и сохраняет свою тенденцию к росту на протяжении многих
лет. Таким образом, аналоги мобильных приложений, взаимодействующие со
своими серверами для мониторинга состояний удаленных объектов, будут браться
под
операционную
систему
Android
на
основе
исследований
по
распространенности в мире.
Мобильные приложения могут быть независимые от внешних технических
устройств – серверов, и зависимые, которые во время своей работы интенсивно
взаимодействуют с сервером. В независимых приложениях присутствует вся
необходимая информация для ее корректной работы. В отличие от независимых
мобильных приложений, зависимые представляют собой тонкий клиент, который
предназначен только для ввода, вывода и первичной обработки информации. Они
имеют небольшой вес, так как вся логика обработки данных ложится на сервер.
Взаимодействие приложения с сервером происходит при помощи программного
интерфейса
приложения
(API),
который
представляет
собой
набор
стандартизированных и задокументированных методов. Общая схема «общения»
между удаленными устройствами представлена на рисунке 3.
14
Рисунок 3 — Общая схема «общения» мобильного устройства с сервером
Мобильное
устройство
посылает
запрос
на
получение
данных
с
необходимыми параметрами. Сервер получает запрос, обрабатывает его и
возвращает результат, который в свою очередь отображается в мобильном
приложении.
Все мобильные приложения, доступные широкому кругу пользователей,
находятся в магазине приложений Google Play. Этот магазин позволяет загружать
любое бесплатное (или платное, при наличии оплаты) приложение на устройство,
работающее под ОС Android.
В качестве аналогов были выбраны 5 приложений, позволяющих проводить
мониторинг удаленных объектов:
1) WBD Диспетчер - дистанционный мониторинг объектов.
Приложение позволяет вести удаленное наблюдение за объектами,
зарегистрированные в системе. На данный момент в качестве таких объектов
выступают котельные. Основными элементами которых являются котел и вода,
циркулирующая вокруг него и тем самым выполняющая теплоотдающую
функцию. Поэтому основными контролируемыми параметрами объекта являются:

температура наружного воздуха;

температура подачи воды;

температура обратной воды.
На рисунке 4 представлен список наблюдаемых объектов с краткой
информацией по основному набору параметров.
15
Рисунок 4 — Список наблюдаемых объектов приложения WBD Диспетчер
Кроме основного набора параметров в качестве дополнительных могут
выступать:

наличие электроэнергии;

время работы котла;

наличие уровня воды.
Все эти параметры становятся доступны пользователю, когда он переходит
к окну детализации. В нем, помимо набора параметров с указанными значениями,
представлено общее состояние котельной, которое определяется сервером на
основе данных полученных от датчиков. Выделены следующие состояния
объектов:

стабильно - набор параметров объекта находится в пределах
допустимого;

значению;
внимание - какой-то из параметров объекта подходит к граничному
16

опасность - какой-то из параметров объекта вышел за пределы
граничного значения.
На рисунке 5 представлено окно детализации состояния котельной с
уровнем «Опасность».
Рисунок 5 — Окно детализации информации об объекте
После достижения какого-либо объекта до этого состояния в управляющий
центр посылается уведомление о критической ситуации котельной. Центр уже по
полученным данным формирует мероприятия по стабилизации состояния. Кроме
того, в приложении доступна функция просмотра истории состояний объектов и
фильтрации их по дате.
WBD Диспетчер выступает в роли терминала, показывающего данные
датчиков, полученные от сервера, определяющие текущее состояние объекта.
Набор параметров фиксированный и поэтому при изменении их состава придется
переписывать приложение, что непременно повлечет за собой финансовые
расходы. Таким образом, помимо отсутствия гибкости в анализе текущего
состояния котельной, набор параметров трудно поддается масштабированию, что
непосредственно сказывается на качестве полной картины о состоянии объекта.
17
2) Мобильный Диспетчер.
Мобильный диспетчер представляет собой приложение, позволяющее
контролировать перемещение удаленных объектов. В качестве таких объектов
могут выступать транспорт, дети, пожилые люди и т.п. Так как набор параметров
в каждом из указанных примеров разный, то мобильный диспетчер позволяет
следить
только
за
скоростью
перемещения
и
текущем
географическом
местоположении. Состояние объектов формируется на основе этих двух
параметров. На рисунке 6 представлен экран с наблюдаемыми объектами.
Рисунок 6 – Окно с множеством наблюдаемых объектов
На карте наглядно представлены объекты мониторинга в разных цветовых
сегментах:

красный – состояние объекта, выражающее превышение какого-либо
из параметров своего допустимого значения;

зеленый – состояние объекта является допустимым.
На рисунке 7 представлен экран с наблюдаемым набором параметров
объекта.
18
Рисунок 7 – Окно с наблюдаемыми параметрами
Мобильный диспетчер позволяет построить маршрут до выбранного
объекта или вручную обновить данные параметров, которые приходят с датчиков.
Также пользователю доступна история состояний объекта, где он может
посмотреть в каком состоянии находился объект в различные периоды времени.
Если какой-либо из объектов выходит за границы допустимых значений
параметров, то на мобильное приложение приходит уведомление. Примером
события, которое генерирует уведомление, может быть выход объекта за пределы
отчерченной геозоны.
Взаимодействие
с
сервером
для
мониторинга
состояний
объекта
стандартное за счет малого количества параметров. Основным моментом их
«общения» является обновление состояния объектов по требованию пользователя.
3) Мобильный мониторинг.
19
Мобильный мониторинг от компании Navitel позволяет наблюдать за
перемещение удаленных объектов. В качестве таких объектов обычно выступает
транспорт со стандартным набором контролируемых параметров:

скорость;

топливо;

пробег.
Совокупность представленных параметров формирует текущее состояние
объекта. На рисунке 8 представлен экран с набором параметров наблюдаемого
объекта.
Рисунок 8 – Экран, представляющий параметры объекта
Перевод состояния объекта в тревожный происходит при значительном
превышении только одного параметра объекта – скорость. Когда данное событие
наступает,
формируется
соответствующее
уведомление
на
мобильное
приложение. Все прошедшие события можно посмотреть в истории наблюдения
за состоянием объекта.
20
Взаимодействие мобильного приложения с сервером происходит в рамках
загрузки данных от датчиков и формирования уведомления на мобильный
телефон
администратора,
осуществляющего
наблюдение
за
удаленными
объектами.
4) Geonet.kz - GPS мониторинг.
Данное мобильное приложение позволяет наблюдать за удаленными
объектами разного типа. В качестве объектов могут выступать как техника, так и
люди, и животные. На рисунке 9 представлен экран выбора объектов наблюдения
с указанием типа объекта в виде разных иконок.
Рисунок 9 – Экран выбора объектов для наблюдения
В качестве наблюдаемых параметров, формирующих состояние объекта,
выступает скорость и географическое местоположение пользователя. Системы
уведомления критических состояний объекта нет. Таким образом, приложение
только позволяет пассивно контролировать текущие состояния наблюдаемых
объектов, без активного участия сервера при возникновении критических
21
ситуаций. На рисунке 10 представлен экран с информацией о параметрах
текущего объекта.
Рисунок 10 – Экран с параметрами объекта
Все представленные аналоги предназначены для наблюдения удаленных
объектов для конкретных прикладных задач. Некоторые применяются для
наблюдения за транспортом, некоторые за людьми, но у каждого из них есть
общие черты, необходимые для наблюдения за объектами разного рода:

получение информации о текущем состоянии объекта;

формирование уведомления о критическом состоянии объекта;

формирование истории изменения состояний объекта.
Каждое мобильное приложение характеризуется определенным набором
параметров, которые может обеспечить определенная схема взаимодействия с
сервером. Так как схемы взаимодействия у всех приложения разные, то и набор
требуемых характеристик тоже будет разный. В таблице 1 представлена
сравнительная характеристика мобильных приложений.
22
Таблица 1 – Сравнительная характеристика мобильных приложений мониторинга
за состоянием удаленных объектов
Характеристики
Разрабатываемое
мобильное
приложение
WBD
Мобильный Мобильный Geonet.kz
Диспетчер диспетчер
-
мониторинг GPS
мониторинг
1. Динамический
набор параметров
состояний
объектов
+
-
-
-
-
2. Разнообразие
наблюдаемых
объектов
+
-
+
-
+
3. История
изменения
состояния объекта
+
+
+
+
-
4. Система
уведомлений
+
+
+
+
-
5. Ручное
формирование
отчета на основе
наблюдений
+
-
-
-
-
1.3 Исследование и анализ технологий взаимодействия мобильного клиента и
сервера ситуационного центра для решения проблем городского хозяйства
Работа мобильного приложения тесно связна с коммуникацией с удаленным
сервером на понятном для обоих языке. Единый формат пересылаемых данных
позволяет
эффективно
взаимодействовать
сторонам
общения
в
обоих
направлениях. На данный момент наиболее популярные форматы JSON и XML.
Расширяемый язык разметки (XML) представляет собой язык разметки
документов и формат передачи данных. XML является подмножеством
стандартного обобщенного языка разметки (SGML), который хорошо известен
тем, что он является подмножеством языка разметки HTML. Язык разметки – это
система маркеровки или тэгов, которые указывают на логическую структуру
документа (параграфы) и содержит инструкции размещения его на странице.
23
XML
позволяет
при
помощи
специализированного
языка
разметки
структурировать данные в наиболее читаемый вид. Пример документа XML
представлен в листинге 1:
<messages>
<message id="100">
<from>Сергей</from>
<to>Иван</to>
<title>Напоминание</title>
<body>Не забудь прийти на событие</body>
</message>
<message id="101">
<to> Сергей </to>
<from> Иван </from>
<title>Re: Напоминание</title>
<body>Хорошо</body>
</message>
</messages>
Листинг 1 – Пример документа XML
В листинге 1 можно увидеть, что информация о 2-х сообщениях логически
разделена на блоки при помощи системы тэгов. Кроме того, к тэгам существует
возможность прикреплять дополнительную информацию в виде атрибутов. На
примере к записи была дополнительно добавлена информации об уникальном
идентификаторе.
Преимущества языка разметки XML:
1)
легко читаемый;
2)
расширяемый;
3)
позволяет структурировать данные в логические блоки;
4)
поддерживает большое количество представлений одних и тех же
данных;
5)
может быть использован для передачи данных между приложениями;
6)
поддерживается широким кругом приложений;
7)
использует Unicode;
8)
поддерживает комментарии;
9)
простота в написании программ, необходимых для обработки XML
документов;
10)
большое количество приложений и библиотек, работающих с XML.
24
Другим форматом передачи данных является JSON (JavaScript Object
Notation). Он ориентирован на удобочитаемость и легкость в его обработке
приложениями. Он состоит из следующих структур:
1)
объекты. Обозначаются фигурными скобками, внутри которых могут
находиться все остальные структуры.
2)
коллекция пар ключ/значение. Ключом может выступать только
строка. Значение пары может быть представлено любым типом и даже объектом.
3)
отсортированный список значений, который может быть представлен
массивом, вектором, листом или последовательностью. Представления списка
значений зависит от используемого языка программирования для обработки.
В листинге 2 представлен пример формата данных JSON:
[
"message": {
"id": 100,
"from": "Сергей",
"to": "Иван",
"title": "Напоминание",
"body": "Не забудь прийти на событие"
},
"message": {
"id": 101,
"from": "Иван",
"to": "Сергей",
"title": "Напоминание",
"body": "Хорошо"
}
]
Листинг 2 – Пример структуризации информации в JSON
Как видно из листинга 2 сообщения находятся в массиве и представляются в
наиболее читаемом виде для пользователя.
Преимущества формата передачи данных JSON:
1)
простота представления данных;
2)
удобочитаемость;
3)
легковесный за счет отсутствия поддержки языка разметки;
4)
может быть использован для передачи данных между приложениями;
5)
позволяет наиболее эффективно обрабатывать данные за счет своей
упрощенной структуры;
25
6)
использует Unicode;
7)
поддерживается широким кругом приложений;
8)
простота в написании программ, обрабатывающие форматы данных
JSON за счет внутренней поддержки этого формата большинством языков
программирования;
9)
большое количество приложений и библиотек, работающих с JSON.
Каждый из представленных форматов передачи данных может быть
использован
при
взаимодействии
сервера
и
мобильного
приложения.
Сравнительная характеристика форматов представлена ниже:
1)
удобочитаемость
кода.
Формат
JSON
проще
воспринимается
программистом за счет отсутствия языка разметки, описывающего данные.
2)
простота обработки и создания. Некоторые языки поддерживают
обработку формата JSON «из коробки». То есть этот формат можно обработать
средствами большинства языков программирования.
3)
меньший размер передачи данных. При использовании мобильного
приложения как клиента, взаимодействующего с сервером, наименьший размер
передаваемых данных является одним из наиболее главных факторов при выборе
формата передачи данных. Так как правильный выбор формата позволяет
экономить интернет-трафик, а значит и денежные ресурсы.
4)
расширяемость.
XML
за
счет
использования
языка
разметки
подвержен явлению расширяемости.
5)
быстрота обработки. Обработка документов XML медленная и
затруднительная. Многие из библиотек обработки могут использовать в
приложении большое количество дополнительной памяти за счет сложности и
стоимости обработки больших файлов.
Таким образом, наиболее приемлемым форматом передачи данных между
сервером и мобильным приложением, учитывающим все преимущества и
недостатки, является формат JSON.
26
Инициатором взаимодействия мобильного приложения с сервером может
быть, как само мобильное приложение, так и сервер. Сервер может отправить
соответствующие сообщения на телефон только через Cloud Messaging.
Cloud Messaging представляет собой сервис, позволяющий отправлять
сообщения
от
сервера
к
клиенту.
На
данный
момент
сервисами,
поддерживающими операционной системой Android, является Google Cloud
Messaging (GCM) и Firebase Cloud Messaging (FCM).
GCM, разработанный компанией Google, представляет собой сервис
передачи сообщений между сервером и клиентами. Он позволяет обрабатывать
отправление, маршрутизацию и очередь поступающих сообщений от сервера.
Схема работы данного сервиса представлена на рисунке 11.
Рисунок 11 – Схема работы сервиса облачных сообщений GCM
После регистрации мобильного приложения в сервисе GCM, ему
присваивается
уникальный
идентификационный
номер.
Помимо
ключа,
позволяющего отправлять сообщения, сервер должен хранить в себе список
уникальных номеров каждого из зарегистрированных приложений. Связка ключа
и идентификационного номера позволяет целенаправленно отправлять сообщение
на мобильное устройство.
FCM, разработанный компанией Firebase, это новая унифицированная
платформа, внедренная компанией Google для замены GCM. Это мульти
платформенное
решение,
позволяющее
обрабатывать
отправление,
маршрутизацию и очередь сообщений от сервера к клиенту. FCM представляет
собой развитие GCM и имеет встроенную поддержку в сервисы Google на
27
мобильном устройстве. Сообщение может быть отправлено как сервером, так и с
использованием консоли.
FCM позволяет отправлять сообщения 3-мя различными путями:
1)
на конкретное устройство;
2)
на группу устройств;
3)
на устройства, подписанные на определенные темы.
Схема работы FCM представлена на рисунке 12.
Рисунок 12 – Схема работы сервиса облачных сообщений FCM
Таким образом, FCM представляет собой улучшенную версию GCM,
которая включает в себя ядро GCM с использованием новейших инструментов
разработки для упрощения взаимодействия между клиентом и сервером. Кроме
того, поддержка GCM была полностью остановлена их разработчиками, и
использование данного сервиса в текущем проекте не является целесообразным.
1.4 Постановка задачи исследования
Поддержка объектов городской инфраструктуры в оптимальном состоянии
имеет огромное значение не только для администрации города, но и для его
жителей. Эффективное и своевременное оповещение об отклонениях от
28
нормативного диапазона значений параметров объекта позволяет оперативно
выработать мероприятия по устранению причин, повлекших изменение.
На данный момент существующие решения не позволяют получить отчет о
текущем состоянии удаленного объекта с различным набором параметров. Данное
ограничение позволяет контролировать только один тип объектов или множество
объектов со скудным набором параметров. Переключение наблюдения за другим
типом или расширение набора параметров не представляется возможным с
технической точки зрения или на текущее действие может быть потрачено
достаточно большое количество человеческих ресурсов. Таким образом,
адаптация мобильного приложения под различные требования предметной
области в сфере наблюдения за состоянием удаленных объектов является
приоритетной задачей.
Предлагается разработать схему взаимодействия мобильного приложения с
сервером ситуационного центра, позволяющего мгновенно реагировать на
запросы о наблюдении за текущим состоянием контролируемого объекта и
предоставлять отчет с динамическим набором контролируемых параметров. Эта
схема не только позволяет улучшить качество жизни населения города за счет
эффективного контроля за состоянием объектов городской инфраструктуры, но и
быстро адаптировать ее для других задач со схожей семантикой.
Таким образом, в качестве задач исследования выступают:
1)
обзор
существующих
подходов
взаимодействия
мобильного
приложения и сервера по мониторингу состояний удаленных объектов;
2)
анализ
преимуществ
и
недостатков
существующих
подходов
взаимодействия мобильного приложения и сервера;
3)
на основе анализа существующих решений, обусловленных их схемой
взаимодействия мобильного приложения с сервером, выработать универсальное и
гибкое решение, позволяющее формировать отчет о текущем состоянии объекта с
динамическим набором параметров;
29
4)
спроектировать мобильное приложение, реализующее разработанную
схему взаимодействия мобильного приложения с севером ситуационного центра
для решения проблем городского хозяйства;
5)
разработать мобильное приложение, реализующее разработанную
схему взаимодействия мобильного приложения с севером ситуационного центра
для решения проблем городского хозяйства.
К функциональным требованиям мобильного приложения можно отнести:
1)
авторизация пользователя;
2)
генерация уникального идентификатора мобильного приложения для
отправки уведомлений;
3)
просмотр контролируемых объектов на карте;
4)
генерация уведомления на основе данных, полученных от сервера;
5)
построение маршрута до объекта;
6)
указание времени и расстояния движения до выбранного объекта;
7)
построение экрана отчета на основе структуры, полученной от
сервера;
8)
возможность прикрепить файл любого формата к отчету;
9)
просмотр истории изменения состояния объекта;
10)
возможность фильтровать историю изменения состояния по дате
возникновения.
К
нефункциональным
требованиям
мобильного
приложения
можно
отнести:
1)
устойчивость к сбоям;
2)
простота использования;
3)
оптимальная производительность;
4)
надежность и доступность;
5)
безопасность, в которую входит блокировка неавторизованного
доступа к данным и функциям приложения;
6)
удобство и простота обслуживания;
7)
тестируемость.
30
2 РАЗРАБОТКА СХЕМЫ ВЗАИМОДЕЙСТВИЯ МОБИЛЬНОГО
ПРИЛОЖЕНИЯ И СЕРВЕРА СИТУАЦИОННОГО ЦЕНТРА ДЛЯ
РЕШЕНИЯ ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА НА ОСНОВЕ
АНАЛИЗА СУЩЕСТВУЮЩИХ РЕШЕНИЙ
2.1 Исследование и анализ подходов к взаимодействию клиента и сервера по
мониторингу состояний удаленных объектов
На данный момент представлено достаточное количество подходов к
взаимодействию мобильного приложения и сервера для мониторинга состояний
удаленных объектов, но ни один из них не может быть применен для решения
проблем городского хозяйства. Рассмотрим, какие подходы наиболее часто
встречаются в текущее время.
Сейчас, в основном, информацию о текущем состоянии объекта передают
датчики. Это устройства, позволяющие фиксировать значение параметров объекта
в автоматическом режиме. Как и любое другое устройство оно подвержено износу
и неисправностям, что может негативно отразиться на конечном состоянии
объекта. В то же время датчики являются незаменимым источником получения
информации динамически перемещающихся объектов. Например, датчики могут
фиксировать изменения в скорости перемещения транспортного средства и т.п.
На данный момент мобильные приложения представляют собой некие
терминалы, главной функцией которого является отображение последнего
значения датчиков и, в некоторых приложениях, формирование уведомления,
если эти значения вышли за рамки допустимых значений. Этот процесс
происходит за счет формирования запроса от приложения «по требованию», т.е.
тогда, когда пользователь войдет в приложение и сам запросит необходимые
данные.
Несомненно, некоторые мобильные приложения позволяют формировать
уведомление об отклонениях в параметрах объекта и без участия пользователя, но
ввиду того, что датчики подвержены сбоям, то возможны ложные срабатывания,
что может негативно отразиться на процессе наблюдения за объектами. Неверные
31
значения датчиков могут приходить на сервер на протяжении достаточно
большого периода времени прежде, чем это будет замечено, тем самым
дестабилизируя общее состояние конкретного объекта или объектов. Кроме того,
интервал обновления информации с датчиков может сильно варьироваться, что
связано работой модуля передачи данных. В связи с тем, что наблюдаемый объект
перемещается, то он может войти в зону, где передача данных с датчиков может
быть затруднена или вообще отсутствовать. Кроме того, не все параметры
объекта могут быть покрыты датчиками. Например, состояние загрязненности
местности и т.п. Таким образом, существующие недостатки датчиков могут
оказывать
серьёзное
влияние
на
наблюдение
за
состоянием
городской
инфраструктуры.
В
большинстве
случаев
инициатором
взаимодействия
мобильного
приложения и сервера является приложение. Оно формирует управляющие
сигналы серверу, в которых указывает, какие данные необходимо получить и в
каком формате. После получения данных, он их обрабатывает и представляет
пользователю в наглядном и удобном виде.
В таком способе взаимодействия сервер выполняет пассивную роль. Он
получает запрос на предоставление данных и формирует ответ. При этом
структура данных всегда жестко зафиксирована и не может быть динамически
изменена. Поэтому существующие подходы по наблюдению за состояниями
объектов являются узкоспециализированными и могут быть применены только в
конкретной предметной области. В то же время, так как данные имеют
неизменяемый характер, то и их отображение в мобильном устройстве тоже будет
жестко задано и любое изменение в данных будет формировать серьезные
финансовые и трудовые затраты для изменения формата представления данных в
мобильном приложении.
Таким
образом,
из
вышесказанного
можно
сделать
вывод,
что
представленные на рынке подходы взаимодействия мобильного приложения и
сервера по наблюдению за состояниями удаленных объектов являются
узкоспециализированными
и
подвержены
предоставлению
недостоверных
32
данных, что может негативно отражаться на всём процессе наблюдения за
состоянием удаленных объектов.
2.2 Анализ преимуществ и недостатков существующих мобильных решений,
основанных на их взаимодействии с сервером
На основе преимуществ и недостатков подходов к взаимодействию
мобильного приложения с сервером для мониторинга состояния удаленных
объектов возможна разработка методики, которая не только не будет уступать
существующим решениям, но и в чём-то превосходить их.
Ранее были рассмотрены несколько подходов к мониторингу состояний
объектов, позволяющие решать разные прикладные задачи. В качестве таких
задач
выступало
наблюдение
за
состоянием
котельной,
отслеживание
местоположение детей, животных и транспорта, и другие. Преимуществом всех
подходов заключалось в глубокой ориентированности мобильного приложения в
определенную предметную область. Что позволяло выполнять неординарные
инструкции в процессе анализа состояния удаленных объектов.
Но в то же время основное преимущество становится и главным
недостатком.
В
современном
мире
возможность
адаптации
мобильного
приложения под постоянно изменяющиеся условия играет ключевую роль в
конкуренции между государственными и частными предприятиями. В связи с
глубокой предметной ориентированностью изменение или переориентация
существующих мобильных приложений под другие технические требования,
связанные с наблюдением за удаленными объектами, становится практически
невозможным или может потребовать слишком высокой цены.
При анализе существующих подходов можно выделить следующие общие
функции мобильных приложений:
1)
получение информации о текущем состоянии объекта на основе
жестко фиксированного набора параметров. В качестве таких параметров может
выступать скорость транспорта, географическое местоположение объекта,
уровень воды в котельной и т.п. Данная функция является основополагающей для
33
любого мобильного приложения, который позволяет наблюдать удаленно за
объектами. Недостаточно просто получать информацию о состоянии, необходимо
также иметь возможность манипулировать разными типами объектов и их
параметрами, что позволяет отсечь ненужные наблюдения.
2)
существование подсистемы уведомлений. Так как состояние объекта
формируется на основе его параметров, то выход за пределы их допустимых
значений
должен
оперативно
фиксироваться
контролирующими
лицами.
Основным инструментом, позволяющим немедленно оповестить ответственного
лица о сложившейся ситуации, является система уведомлений.
3)
журналирование
состояний
объекта.
Мобильное
приложение
позволяет в наглядном виде предоставить историю состояний объекта в виде
набора параметров, которую можно отфильтровать по своему усмотрению. Эта
функция позволяет увидеть насколько эффективны мероприятия по стабилизации
состояния контролируемого объекта.
Совокупность представленных функций определяет ядро мобильных
приложений по наблюдению за состоянием удаленных объектов. Несомненно, для
обеспечения работы ядра необходимо взаимодействия с сервером, который
обеспечивает всей необходимой информацией.
Выделим недостатки существующих мобильных решений для мониторинга
объектов:
1)
отсутствие универсальности. Существующие подходы могут быть
использованы только в конкретной предметной области. Незначительные
изменения в наборе параметров, определяющее текущее состояние объекта,
является критическим и требует значительных расходов финансовых и
человеческих ресурсов.
2)
добавление нового типа наблюдаемого объекта со своим набором
параметров в информационную систему может вызвать трудности отображения в
мобильном приложении, так как при его разработке это может не учитываться.
3)
отсутствие ручного формирование отчета о текущем состоянии
объекта. Существующие мобильные решения опираются на данные, получаемые
34
от датчиков. Так как никто не может гарантировать качество таких данных, то
могут быть ложные срабатывания системы уведомления по предупреждению
опасных ситуаций.
Кроме того, датчики могут быть неисправными, неверно
настроенными или находиться вне зоны действия сети, чтобы передать
необходимые данные на сервер, что может развить феномен «старения» данных.
Таким образом данные, полученные от датчиков, могут ввести в заблуждение
контролирующий орган.
4)
отсутствие системы предупреждения критических ситуаций. Во всех
представленных мобильных решениях отсутствует система предупреждения.
Система уведомления срабатывает только когда критическая ситуация возникла, а
не когда необходимо провести исследование текущего состояния объекта на
наличие скрытых дефектов.
На основе ядра функций мобильных приложений по наблюдению за
состояниями удаленных объектов и недостатков существующих решений
возможна разработка методики взаимодействия мобильного приложения с
сервером ситуационного центра для решения проблем городского хозяйства.
2.3 Разработка схемы взаимодействия мобильного приложения с сервером
ситуационного центра для решения проблем городского хозяйства
Разрабатываемая методика призвана учесть недостатки существующих
решений и обеспечить эффективное взаимодействие мобильного приложения с
сервером ситуационного центра для мониторинга за состоянием удаленных
объектов для решения проблем городского хозяйства.
Схема
взаимодействия
должна
позволять
мобильному
приложению
выполнять ряд основных функций:
1)
оперативно уведомлять пользователя мобильного приложения о
необходимости проведения анализа состояния объекта по запросу диспетчера
управляющей компании;
2)
уведомлять пользователя о необходимости проведения анализа
состояния объекта по специально составленному расписанию;
35
3)
динамически формировать отчет о текущем состоянии объекта;
4)
позволять загружать разнородные документы;
5)
позволять обрабатывать состояния разнородных объектов;
6)
эффективно обрабатывать сообщения от сервера;
7)
эффективно синхронизировать данные в мобильном приложении и на
сервере;
8)
эффективно обрабатывать исключительные ситуации.
Потребность в новой схеме обусловлена созданием универсального
механизма взаимодействия мобильного клиента и сервера для мониторинга
состояния удаленных объектов, который эффективно реагирует на изменение
предметной области и обеспечивает минимизацию расходов, направленных на ее
переориентирование и адаптацию.
В
ранее
представленных
мобильных
решениях,
направленных
на
мониторинг состояний объектов, инициатором взаимодействия с сервером было
всегда только мобильное приложение. Оно само запрашивало актуальное
состояние наблюдаемого объекта и на основе этих данных формировало
уведомление. Данные подходы не позволяют в полной мере контролировать
состояние объектов и предупреждать развитие неблагоприятных ситуаций.
Поэтому, очевидно, что возможность начать двустороннее взаимодействие
должна быть у обоих сторон.
Инициатором в новой схеме клиент-серверного взаимодействия может
быть, как сервер, так и мобильное приложение. Зависит от механизма
уведомления о необходимости проведения анализа текущего состояния объекта.
Запросить информацию о состоянии может как диспетчер управляющего центра,
так и мобильный телефон, содержащий в себе специально составленное
расписание, в котором указано периодичность проверки объекта. Данный способ
уведомления не требует активного участия диспетчера. В конце рабочего дня
диспетчер может проверить насколько верно проводился анализ объектов по
расписанию.
36
На
рисунке
13
представлена
диаграмма
последовательности,
представляющая взаимодействие мобильного клиента с сервером ситуационного
центра, где инициатором взаимодействия является сервер.
Рисунок 13 – Диаграмма последовательности взаимодействия мобильного
приложения с сервером, инициатором которого является сервер
Опишем действия, происходящие при взаимодействии мобильного клиента
с сервером, где его инициатором является сервер:
1)
для идентификации пользователя ему необходимо авторизоваться в
системе;
2)
диспетчер управляющего центра через веб-сайт формирует запрос на
очередной анализ текущего состояния объекта;
37
3)
сервер отправляет сообщение со всей необходимой информацией для
представления оповещения о необходимости формирования уведомления на
мобильное устройство;
4)
мобильное устройство по полученной информации формирует
внутреннее уведомление;
5)
пользователь переходит по полученному уведомлению в мобильное
приложение;
6)
мобильное приложение загружает всю необходимую информацию об
объекте, включая его местоположение, и формирует оптимальный путь до этого
объекта с указанием времени движения;
7)
после достижения до контрольного объекта пользователь запрашивает
у сервера структуру отчета;
8)
по полученной структуре формируется окно отчетности в наиболее
удобном для заполнения виде с указанием списка полей и документов,
необходимых для формирования отчета;
9)
после
заполнения
отчета
всеми
необходимыми
данными
он
отправляется на сервер для изменения текущего состояния объекта;
10)
после чего на мобильное приложение приходит ответ об успешности
совершенного действия.
Весь процесс предоставления информации о текущем состоянии объекта по
запросу контролируется диспетчером управляющего центра через веб-сайт. Это
становится возможным благодаря наличию в мобильных устройствах модуля
GPS, который с определенной точностью определяет текущее местоположение
пользователя. Мобильное приложение передает данные о своем местоположении
в управляющий центр только когда оно активно.
В
связи
с
расширением
числа
работников
управляющего
центра
диспетчером может быть достаточно сложно вручную контролировать процесс
анализа состояния удаленного объекта. В этом случае он может составить
специальное расписание для пользователя, по которому он будет самостоятельно
проводить анализ состояния. Такое расписание загружается в начале каждого дня
38
для синхронизации данных, хранящихся на сервере. На рисунке 14 представлено
взаимодействия
мобильного
клиента
с
сервером,
где
инициатором
взаимодействия является мобильное приложение.
Рисунок 14 – Диаграмма последовательности взаимодействия мобильного
приложения с сервером, где инициатором взаимодействия является
мобильное приложение
Последовательность шагов, представленных на рисунке 14, практически
аналогична шагам, представленных на рисунке 13. Основным отличием двух
способов взаимодействия является то, что для того, чтобы его инициатором стало
мобильное приложение необходимо после авторизации пользователя загрузить
расписание предоставление отчетов по определенным объектам. В соответствии с
39
этим
расписанием
формируется
внутреннее
уведомление
на
мобильном
устройстве. Сервер со своей стороны уже имеет готовую структуру отчета,
который он должен передать по запросу мобильного приложения.
Благодаря разработанной схеме взаимодействия, мобильное приложение
будет обладать следующими особенностями:
1)
возможность
получения
актуальной
информации
о
уведомления,
позволяющая
не
текущем
состоянии объекта;
2)
продвинутая
система
только
уведомлять пользователя о необходимости проведения анализа текущего
состояния объекта по запросу диспетчера, но и автоматически, в соответствии с
ранее загруженным расписанием, инициировать запрос;
3)
возможность предупреждения опасных состояний объекта, которая
становится возможными благодаря расписанию об анализе состояний объекта;
4)
возможность проводить анализ состояния объекта с разным набором
параметров;
5)
формировать отчетность о текущем состоянии различной структуры;
6)
возможность анализировать состояние разнородных объектов.
Таким
образом,
благодаря
разработанной
схемы
взаимодействия
мобильного приложения и сервера достигается универсальность в анализе
состояний, которая может быть применена к объектам в различных предметных
областях. Помимо прочего, обеспечивается гибкость к постоянно изменяющимся
требованиям, которая приводит к минимизации расходов финансовых и
человеческих ресурсов.
40
3 ПРОЕКТИРОВАНИЕ МОБИЛЬНОГО ПРИЛОЖЕНИЯ СЕРВИСА ДЛЯ
РЕШЕНИЯ ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА
3.1 Логическая схема построения сети сервиса решения проблем городского
хозяйства
Сервис
для
решения
проблем
городского
хозяйства
позволяет
контролировать состояние объектов городской инфраструктуры и находить
решения по стабилизации отклонений от нормальных значений параметров,
формирующих текущее состояние объекта. В работу сервиса вовлечено
множества различных устройств и лиц, позволяющих информационной системе
корректно работать. Основными элементами информационной системы являются:
1)
Мобильное приложение. Предназначено для обработки первичной
информации и предоставления динамического отчета о текущем состоянии
удаленного объекта. Помимо своего основного назначения, предоставляет
инструменты,
призванные
обеспечить
пользователя
всей
необходимой
информацией для успешного выполнения своего задания.
2)
Сервер
ситуационного
центра.
Представляет
собой
ядро
информационной системы, в которое включены следующие функции:
 предоставление актуального состояния контролируемых объектов;
 позволяет производить запрос о проведении анализа состояния
удаленного
объекта
конкретному
пользователю
информационной
системы;
 позволяет
динамически
генерировать
структуры
отчетов
для
мобильного приложения на основе различных наборов параметров;
 позволяет на основе имеющейся информации строить графические
иллюстрации, показывающие динамику изменения состояния объектов во
времени;
 позволяет
формировать
внутренний
отчет
показывающий историю изменения состояния объектов.
по
периодам,
41
3)
Сервер баз данных. Предназначен для хранения информации
информационной системы и логической обработки данных.
4)
Диспетчер управляющего центра. В компетенцию которого входят:
 проводить контроль состояния удаленных объектов;
 проводить актуализацию текущего состояния объектов;
 проводить анализ причин, повлекших отклонения от нормального
состояния объекта, и на его основе формировать мероприятия по их
устранению;
 проводить анализ историй состояний объектов по периодам;
 формировать отчет по состояниям объектов по периодам.
На рисунке 16 представлена логическая схема построения сети.
Рисунок 16 – Логическая схема построения сети сервиса мониторинга за
состоянием удаленных объектов
42
В основу построения сети входит трехзвенная архитектура. Она включает в
себя:
1)
слой представления. Содержит в себе пользовательский графический
интерфейс информационной системы. Предназначен для ввода и вывода
информации пользователю.
2)
слой бизнес-логики. Содержит в себе всю логику, соответствующую
бизнес-правилам. Представляет собой интерфейс между слоем представления и
слоя данных. Он позволяет разгрузить все остальные слои и более эффективно
проводить взаимодействие между ними.
3)
слой данных. Содержит в себе базу данных информационной
системы, интерфейс манипулирования данными и логику их первичной
обработки.
Преимущества трехзвенной архитектуры:
1)
высокая производительность и легковесные объекты, хранящиеся в
базе данных;
2)
расширяемость. Каждый слой может быть расширен горизонтально;
3)
производительность. Слой представления позволяет кэшировать
запросы и проводить другие оптимизационные работы за счет перемещения задач
на другие слои;
4)
высокая степень гибкости в разработке и конфигурации;
5)
широкие возможности в переиспользовании;
6)
улучшение целостности данных;
7)
улучшение безопасности. Клиент не имеет прямого доступа к базе
данных;
8)
легкая поддержка и модификация за счет разбиения информационной
системы на слои.
Недостатки трехзвенной архитектуры:
1)
сложности в разработке;
2)
требуется оборудование, находящееся в высоком ценовом диапазоне.
43
Трехзвенная архитектура является развитием двухзвенной, в которой
отсутствует слой бизнес-логики. Благодаря этому достигается более быстрое
взаимодействие между оставшиеся слоями. Но ввиду того, что трехзвенная
архитектура
является
наиболее
надежной,
не
сильно
уступает
в
производительности и расширяема, то она становится наиболее очевидным
решением при выборе архитектуры для информационной системы.
3.2 Логика взаимодействия мобильного приложения с сервером
ситуационного центра
Клиент и сервер устанавливают соединение с помощью HTTP протокола.
HTTP (HyperText Transfer Protocol — «протокол передачи гипертекста») – это
протокол прикладного уровня передачи данных широко используемый в сети
Интернет. Он предполагает существование потребителей (или клиентов), которые
являются инициаторами соединения и посылают запрос, и поставщиков (или
серверов), которые в большинстве случаев ожидают соединения для получения
запроса, выполняют обработку полученных данных и возвращают обратно
сообщение с результатом.
Взаимодействие с сервером происходит при помощи API (application
programming interface), который представляет собой набор методов, доступных
для взаимодействия с удаленной системой. В таблице 2 представлены методы API
необходимые
для
взаимодействия
мобильного
приложения
и
сервера
ситуационного центра для мониторинга состояния удаленных объектов. Все
адреса запросов, представленные в таблице 2, являются относительными. Сервер
располагается по адресу http://gorod.yougid.ru. В состав запроса обязательно
входят:
1)
строка запроса – состоит из адреса ресурса и метода передачи,
который указывает на способ обращения к ресурсу;
2)
заголовки – предназначены для передачи служебной информации о
запросе;
3)
тело сообщения – данные, передаваемые в запросе.
44
Таблица 2 – API для взаимодействия клиента с сервером
Адрес запроса
/api/login
Метод
Параметры
Структура
запроса
запроса
ответа
POST
login – логин
password – пароль
success – успех
error - неудача
Назначение
Аутентификация
в системе
Получение
/api/objects
GET
–
objects – список списка
объектов
контролируемых
объектов
Получение
/api/objects/:id
GET
id – идентификатор
объекта
object – объект
информации о
конкретном
объекте
/api/object/:id/report
GET
id – идентификатор
объекта
fields –
Запрос на
структура
список полей
отчета
будущего отчета
Отправление
/api/object/:id/report
POST
id – идентификатор success – успех
объекта
error – неудача
отчета о
текущем
состоянии
объекта
history –
/api/object/:id/history
GET
Получение
id – идентификатор история
истории
объекта
состояний
состояний
объекта
объекта
Получение
/api/object/:id/history/:id GET
id – идентификатор
объекта
report – отчет
отчета по
выбранному
состоянию
Формат передачи данных должен быть понимаем обоими участниками
взаимодействия. В данной работе был выбран формат JSON, которые позволяет
структурировать информацию в виде набора пар – ключ и значение. В качестве
45
ключа выступает только строка, а в качестве значения могут выступать числа,
строка, массив и объект.
Для эффективного решения задачи мониторинга удаленных объектов
разного типа и формирования динамического отчета необходим протокол
запросов и ответов, который должен понимать, как сервер, так и мобильное
приложение, и качественно обрабатывать.
Согласно разработанной методике
взаимодействия, основными элементами динамического формирования отчета
является загрузка информации об анализируемом удаленном объекте, загрузка
структуры будущего отчета и отправление его на сервер. Рассмотрим структуры
ответов по загрузке необходимых данных для формирования отчета.
Главная особенность в загрузке информации об объекте является
разнородность объектов. Поэтому структура формата передачи данных должна
быть настолько универсальной, насколько это возможно. В таблице 3
представлена структура ответа, которая будет возвращена сервером, при запросе
мобильным приложением информации о конкретном объекте информационной
системы.
Таблица 3 – Структура ответа сервера с информацией об объекте
Наименование
Тип поля
Описания поля
Пример
2
3
4
поля
1
id
Long
Уникальный
1100
идентификатор
объекта
name
String
Наименование
Котельная №1
объекта
type
String
Тип объекта
Котельная
lat
Double
Широта
52.989951
местоположения
объекта
46
Продолжение таблицы 3
1
lon
2
4
3
Double
Долгота
36.034711
местоположения
объекта
image
String
Изображение,
/images/kotelnaya.jpg
определяющее объект
state
Boolean
Флаг, указывающий
True
на необходимость
анализа реального
состояния объекта
Благодаря структуре ответа, показанной в таблице 2, достигается гибкость в
вопросе получения информации об объектах разного типа. Этой информации
достаточно, чтобы указать местоположение объекта на карте и выделить его
среди себе подобных. По полю state определяется необходимость в проведении
ручного анализа текущего состояния удаленного объекта, результатом которого
будет отчет.
После
получения
информации
об
объекте
необходимо
загрузить
информацию о структуре отчета. В таблице 4 представлен ответ сервера на запрос
о загрузке структуры отчета.
Таблица 4 – Структура ответа сервера на запрос о формировании отчета
Наименование Тип поля
Описание поля
Пример
поля
1
fields
2
Array
3
4
Содержит в себе список {
полей, описывающих отчет
fields: [{….}]
}
47
Продолжение таблицы 4
1
2
name
String
3
Наименование поля
4
Температура
наружного воздуха
type
String
Тип поля
Text
document_type Array
Тип документа
[pdf, doc]
network_filed
Указывает на параметр, в
t_outer_wind
String
который необходимо
отправить поле
unit
String
Единица измерения
МПа
comment
String
Комментарий к полю
Допустимы
только
символы +- и числа
В массиве fields содержится список объектов с полями name, type,
network_type, unit и comment, формирующие отчет необходимый управляющему
центру. Тип поля может быть только одним из следующих значений:
1)
text – представляет собой текстовое поле, предназначенное для ввода
текста;
2)
document – представляет собой поле, позволяющее загружать
документ любого формата (pdf, doc, docx, xls и другие);
3)
image – представляет собой поле, предназначенное для загрузки
изображения из разных источников (камера и галерея);
4)
video – представляет собой поле, позволяющее загружать видео.
Поле document_type появляется только если тип поля указан как document, в
остальных случаях оно отсутствует. Это поле предназначено для контроля
загрузки документов только определенных типов.
С помощью указанного набора полей и их описания формируется экран
отчета в мобильном приложении, который, после заполнения всех полей,
отправляет данные на сервер. Благодаря динамическому формированию полей
достигается разносторонняя структура отчета.
48
3.3 Структурная схема мобильного приложения
Для эффективного обеспечения выполнения своих функций мобильное
приложение разбито на ряд подсистем, каждая из которых выполняет свою
функцию. Подсистемы не находится изолированно друг от друга, они постоянно
взаимодействуют друг с другом с целью предоставления пользователю
ожидаемого результата. Разбитие приложения на подсистемы имеет множество
плюсов, по сравнению с программой, разрабатываемой в одной подсистеме. В
качестве таких плюсов могут выступать:
1)
высокий уровень поддержки;
2)
низкий порог входа в разработку приложения;
3)
масштабируемость;
4)
тестируемость;
5)
логическое разделение на части.
Подсистема представляет собой набор модулей с некоторым количество
интерфейсов, через которые они взаимодействуют друг с другом. Модуль в свою
очередь является логически завершенным фрагментом приложения, состоящая из
набора классов и пакетов, каждая из которых имеет свой круг ответственности.
Совокупность подсистем, их состав, и связи между ними образуют структурную
схему мобильного приложения.
Разрабатываемое мобильное приложение состоит из ряда взаимосвязанных
подсистем:
1)
подсистема
авторизации
и
аутентификации
позволяет
идентифицировать данные пользователя в системе и предоставить ему права на
действия согласно его должностным инструкциям;
2)
подсистема уведомлений состоит из двух модулей:
 модуль планирования по расписанию – позволяет на основе
загруженного расписания формировать уведомления, независимо от
сервера;
49
 модуль
обработки
уведомления
–
позволяет
обрабатывать
уведомления из разных источников и формирует управляющие сигналы в
ответ на полученное оповещение.
3)
подсистема работы с картой и объектами на карте позволяет
манипулировать картой всеми возможными способами и выполнять следующие
действия над объектами:
 загрузка объектов;
 обновление объектов;
 просмотр информации об объекте;
 обработка состояния объектов.
4)
подсистема формирования отчета позволяет формировать отчет в
зависимости от структуры, полученной от сервера. В состав нее входят:
 модуль подготовки отчета – загружает структуру будущего отчета и
формирует на ее основе экран со всеми необходимыми полями;
 модуль загрузки и валидации данных – следит за корректным вводом
данных в поля отчета и позволяет формировать специальные инструменты
для удобного внесения данных;
 модуль формирования отчета – по полученной структуре отчета и
введенным данным формирует предварительный отчет и отправляет его на
сервер.
5)
подсистема работы с журналом состоит из следующих модулей:
 модуль формирования журнала – позволяет по полученным данным
от сервера сформировать историю состояний текущего объекта;
 модуль управления журналом – позволяет проводить фильтрацию
состояний по дате или определенному периоду;
 модуль формирования отчета – позволяет получить историю отчета
конкретного состояния объекта.
6)
подсистема маршрутизации состоит из следующих модулей:
 модуль работы с маршрутом – позволяет построить оптимальный
маршрут от текущего местоположения пользователя до удаленного объекта;
50
 модуль работы с данными о маршруте – предоставляет служебную
информацию о текущем маршруте, в которую в основном входит время
движения и расстояние пути.
На рисунке 17 показана структурная схема мобильного приложения со
всеми связями.
Рисунок 17 – Структурная схема мобильного приложения
51
3.4 Общий алгоритм функционирования схемы взаимодействия мобильного
приложения с сервером ситуационного центра
Применение
разработанной
методики
взаимодействия
мобильного
приложения и сервера позволяет получить качественную и достоверную
информацию о текущем состоянии удаленного объекта. Запросить состояние
может как диспетчер управляющего центра, так и мобильное приложение,
работающее по ранее загруженному расписанию. На рисунке 18 представлен
алгоритм работы диспетчера по созданию запроса на формирование отчета о
текущем состоянии объекта для сотрудника управляющей компании.
Рисунок 18 – Алгоритм формирования запроса на отчет диспетчером
52
После того, как запрос о создании отчета успешно создан, формируется
уведомление на телефон сотрудника, осуществляющего ручной контроль за
состоянием объекта. На рисунке 19 представлен алгоритм работы мобильного
приложения после создания запроса на формирование отчета.
Рисунок 19 – Алгоритм процесса формирования отчета
53
После того, как будет сформировано уведомление и открыто приложение по
этому
оповещению,
построится
маршрут
от
текущего
местоположения
пользователя до объекта с указанием служебной информации маршрута. В нее
входит информация о расстоянии и времени движении.
Как только пользователь доберется до объекта и приложение это увидит, то
можно будет сформировать окно для удобного и эффективного создания отчета на
основе структуры, полученной от сервера, по определенным правилам. Правила
загружаются вместе со структурой и представляют собой ограничения,
накладываемые на каждое из полей. Очень важно загружать информацию полной
от сервера, иначе отчет получится неполным и работнику управляющей компании
придется часто его переделывать. Поэтому, если приложение обнаружит
неполную структуру отчета, то оно его перезапросит перед формированием
экрана отчета.
Представленный выше процесс взаимодействия мобильного приложения и
сервера позволяет формировать отчет о состоянии объекта любой структуры и в
процессе формирования изменять его, если он не будет удовлетворять некоторым
требованиям. Изменение структуры возможно, если диспетчер управляющего
центра отклонит представленный отчет и запросит другой. Это сделано
специально для такого случая, что отчет, сформированный работником, не
получается мгновенно диспетчером, после его запроса, он может быть создан
через некоторый промежуток времени. В связи с этим старая структура отчета
может потерять свою актуальность.
После того, как отчет будет принят диспетчером, иконка объекта вновь
поменяет цвет с красного на зеленый, а отчет будет занесен в историю отчетов
состояний объекта.
54
4 РЕАЛИЗАЦИЯ ВЗАИМОДЕЙСТВИЯ МОБИЛЬНОГО ПРИЛОЖЕНИЯ И
СЕРВЕРА СИТУАЦИОННОГО ЦЕНТРА ДЛЯ РЕШЕНИЯ ПРОБЛЕМ
ГОРОДСКОГО ХОЗЯЙСТВА
4.1 Разработка алгоритмов работы отдельных подсистем мобильного
приложения
Для более ясной картины работы мобильного приложения по обеспечению
контроля за состоянием удаленных объектов необходимо построить алгоритмы
работы отдельных его подсистем.
Среди всех представленных подсистем наибольший интерес вызывают:
1)
подсистема аутентификации и авторизации;
2)
подсистема работы с объектами на карте;
3)
подсистема формирования отчета;
4)
подсистема маршрутизации.
На рисунке 20 представлена блок-схема алгоритма работы подсистемы
авторизации.
Рисунок 20 – Алгоритм работы подсистемы авторизации
55
Для того, чтобы пользователь мог пользоваться функциями мобильного
приложения необходимо авторизоваться в системе. Процесс авторизации и
аутентификации необходим также для передачи специального идентификатора,
по которому диспетчер управляющего центра может отправлять уведомления.
После загрузки приложения он проверяет наличие специального токена и,
если он есть, проверяет его валидность в системе. Если токен не валиден или его
нет, то открывается окно входа в приложение, где пользователь должен ввести
регистрационные данные, выданные ему при приеме на работу. После успешного
ввода и подтверждения правильности введенных данных происходит загрузка
объектов и переход на экран, содержащий в себе карту и объекты, размещенные
на нем. Алгоритм работы подсистемы работы с картой и объектами представлен в
виде блок-схемы на рисунке 21.
Рисунок 21 – Алгоритм работы с картой и объектами на карте
56
После успешной загрузки объектов происходит их размещение на карте в
соответствии с их географическими данными. Помимо изображения маркеры
(специальные компоненты, отображающие удаленные объекты) обозначаются
специальной цветовой палитрой, означающее необходимость в предоставлении
отчета о текущем состоянии удаленного объекта:
1)
зеленый цвет – объект не требует предоставление отчета о его
текущем состоянии;
2)
красный цвет – объект требует немедленного предоставления отчета о
его текущем состоянии.
Пользователь может просмотреть информацию об объекте и, если требуется
отчет, выбрать его в качестве следующей цели для формирования отчета. В
момент выбора маркера происходит построение маршрута с выводом всей
необходимой служебной информации. На рисунке 22 представлен алгоритм
работы подсистемы маршрутизации.
Рисунок 22 – Алгоритм работы подсистемы маршрутизации
57
Как видно на рисунке 22, служебной информацией маршрута являются:
1)
время движения от текущего места пользователя до объекта в часах и
минутах;
2)
расстояние пути в метрах.
В соответствии с полученной информацией пользователь выбирает
наиболее удобный для него способ передвижения. После того, как пользователь
доберется до объекта, необходимо будет сформировать отчет об его состоянии.
Алгоритм формирования отчета представлен в виде блок-схемы на рисунке 23.
Рисунок 23 – Алгоритм работы формирования отчета о текущем состоянии
удаленного объекта
58
Первоначально происходит загрузка структуры требуемого отчета со
списком требуемых полей, необходимых для заполнения. После получения
структуры происходит формирование окна в соответствии с набором требуемых
полей в наиболее удобном для пользователя виде. На рисунке 24 представлен
алгоритм работы формирования окна на основе полученной структуры отчета.
Рисунок 24 – Алгоритм формирования окна для заполнения отчета
59
В соответствии с информацией, описывающей каждое поле, динамически
формируется экран, который пользователь может использовать для заполнения
необходимыми данными. Под каждое поле резервируется место на экране со
специальным условием, если оно есть. Например, если поле для ввода имеет тип
документ, то в это поле можно будет добавить только документ формата, который
допустим по описанию поля. Каждое поле является редактируемым и доступна
для просмотра его содержимого. Кроме того, для каждого поля может быть
дополнительно введен комментарий, который может содержать в себе служебную
информацию для работника управляющего центра с инструкциями по введению
данных в поле.
После успешного завершения формирования экрана с параметрами отчета
пользователь приступает к его заполнению. После окончания ввода всех
необходимых данных происходит отправление их на сервер. Сервер проверяет
правильность заполнения и, в случае корректности ввода, предоставляет
оформленный отчет диспетчеру. Если данные не корректны, то сервер возвращает
список ошибок для их устранения пользователю.
Диспетчер управляющего центра проверяет корректность заполнения отчета
и, если всё заполнено верно, возвращает подтверждение получения отчета. Если
отчет заполнен неверно, то пользователю заново пересылается структура отчета,
после чего он выполняет все дальнейшие шаги с самого начала.
Кроме своего основного предназначения в виде сигнала для формирования
отчета о
текущем
состоянии удаленных объектов, пользователь может
воспользоваться журналом отчета любого выбранного объекта, где он может
просмотреть успешно принятый отчет в любой момент времени, либо причину
отказа.
4.2 Построение логики диалога с пользователем
Для успешного решения поставленных задач необходимо эффективное
взаимодействие мобильного приложения и сервера ситуационного центра с их
пользователями. Информация и результаты, которые формируются сервером,
60
доступны диспетчеру через обычную WEB-страницу, которая может также
представлять собой панель администратора, при наличии соответствующих прав.
Таким
образом,
для
более
полной
картины
происходящих
процессов
целесообразно показать логику диалога с пользователем как со стороны
мобильного приложения, так и со стороны диспетчера.
В
начале
каждого
проектирования
пользовательского
интерфейса
происходит построение логики диалога с пользователем, которая показывает
способы осуществления взаимодействия пользователя с приложением. Для его
представления используется транзитивная сеть или сеть состояний и переходов.
Она показывает состояния, в которых может находиться система, при
осуществлении тех или иных действий. Сеть представляет собой направленный
граф, в котором состояния системы является его вершинами, а переходы между
ними обозначаются дугами. Состояние – это определенное положение системы,
которая
характеризуется
набором
визуальных
компонентов
доступных
пользователю. Дуги обозначают действия пользователя с системой (входной
сигнал) и обратную связь (выходной сигнал) прикладного интерфейса.
Транзитивная сеть имеет стартовое и конечное состояние. Стартовое состояние
представляет собой исходное состояние системы, ожидающее инициативные
действия со стороны пользователя. Конечное состояние указывается на
завершение взаимодействия пользователя с системой.
Пользователем мобильного приложения является сотрудник управляющего
центра, а пользователем панели администратора – диспетчер управляющего
центра. Перед тем, чтобы начать пользоваться информационной системой в
полной мере необходимо пройти аутентификацию и авторизацию, необходимую
для подтверждения своих прав на пользование данной системой.
На рисунке 25 представлена транзитивная сеть, указывающая на способы
осуществления взаимодействия работника управляющего центра с мобильным
приложением. Сеть состоит из 9 состояний и 15 переходов между ними. По
достижении состояния F, приложение прекращает работу. Это может произойти
только по воле сотрудника управляющей компании.
61
Рисунок 25 – Логика диалога с пользователем мобильного приложения
В представленной транзитивной сети получилось 9 состояний мобильного
приложения и 15 переходов. В таблице 5 представлено описание этих состояний:
Таблица 5 – Описание состояний транзитивной сети
№ состояния
Описание
V1
Стартовое
состояние.
Отображение
экрана
для
ввода
авторизационных данных.
V2
Отображение экрана с картой и наблюдаемыми объектами на
карте
V3
Вывод информации о выбранном объекте
V4
Построение маршрута и вывод его служебной информации
V5
Отображения экрана, соответствующего структуре отчета
V6
Вывод окна ожидания подтверждения получения отчета
V7
Вывод окна просмотра журнала отчетов
V8
Вывод окна выбранного отчета
F
Выход из приложения
62
Информация
о
входных
сигналах,
посланных
пользователем
и
обуславливающих изменения состояний пользовательского интерфейса, а также о
действиях системы, происходящих в ответ на эти сигналы, представлена в
таблице 6.
Таблица 6 – Описание переходов транзитивной сети
№ Дуги Входной сигнал
1
Е1
Реакция на входной сигнал
2
Нажатие на кнопку «Вход»
3
Пользователь авторизован;
переход на карту с объектами
Е2
Нажатие на кнопку «Вход»
Неверные авторизацонные
данные
Е3
Нажатие на объект на карте
Вывод информации о выбранном
объекте
Е4
Нажатие на кнопку
Вывод маршрута от пользователя
«Предоставить отчет»
до объекта и его служебной
информации на экран
Е5
Нажатие на карту
Скрытие информации о
выбранном объекте
Е6
Е7
Нажатие на кнопку
Загрузка структуры будущего
«Сформировать отчет»
отчета и формирование экрана
Нажатие на кнопку
Загрузка представленной
«Предоставить отчет»
информации и вывод окна
подтверждения данных от
диспетчера
Е8
Получение подтверждения
Переход на карту с объектами
отчета
Е9
Получение отклонения отчета
Загрузка новой структуры
будущего отчета и формирование
экрана отчета
63
Продолжение таблицы 6
1
2
Е10
3
Нажатие на кнопку «История
Вывод журнала отчетов,
отчетов»
отсортированных по дате в
сторону убывания
Е11
Нажатие на отчет
Вывод сформированного отчета
или причины его отклонения
Е12
Закрытие окна просмотра отчета
Переход на окно истории отчетов
Е13
Закрытие истории отчетов
Переход на окно карты с
объектами
Е14
Выход из приложения
Выход из приложения и его
закрытие
E15
Фильтрация отчетов по
Вывод отфильтрованных отчетов
выбранному параметру
по выбранному параметру
(например, по какому-либо
периоду)
Рассмотренная
приложения,
логика
описанные
диалога
состояния
с
и
пользователем
переходы
для
мобильного
позволяют
эффективно
взаимодействовать с мобильным устройством для достижения общей цели.
Очевидно, что полная функциональность приложения раскрывается только после
успешной аутентификации и авторизации пользователя. Это означает, что оно не
доступно широкому кругу пользователей, а только конкретным людям,
находящихся в штате управляющей компании.
Но так как функционирование мобильного приложения тесно связано с
работой диспетчера управляющей компании, то рассмотрим взаимодействие
диспетчера управляющей компании с панелью управления с целью получения
отчета о текущем состоянии наблюдаемого удаленного объекта. Взаимодействие
диспетчера с сервером происходит через веб-интерфейс. На рисунке 26
представлена транзитивная сеть, описывающая это взаимодействие.
64
Рисунок 26 – Логика диалога с пользователем информационной системы
В таблице 7 представлено описание состояний, в которых может быть
информационная система.
Таблица 7 – Описание состояний информационной системы
№ Состояния Описание
V1
Стартовое
состояние.
Отображение
экрана
для
авторизационных данных.
V2
Отображение экрана с картой и объектами на карте
V3
Вывод информации о состоянии выбранного объекта
V4
Отображение окна выбора исполнителя
V5
Отображение окна конструктора отчета
V6
Отображение окна просмотра присланного отчета
V7
Отображение окна просмотра истории отчетов
V8
Отображение окна с графиками по параметрам объекта
V9
Отображение окна детализации выбранного отчета
ввода
65
В таблице 8 описаны переходы, в которые входят входной сигнал от
пользователя и реакция на это действие от информационной системы.
Таблица 8 – Описание переходов транзитивной сети
№ Дуги Входной сигнал
1
Е1
Реакция на входной сигнал
2
Нажатие на кнопку «Вход»
3
Пользователь авторизован;
переход на карту с объектами
Е2
Нажатие на кнопку «Вход»
Неверные авторизацонные
данные
Е3
Нажатие на объект на карте
Вывод информации об объекте
Е4
Нажатие на кнопку запроса
Переход на окно выбора
отчета
исполнителя
Выбор исполнителя
Переход на окно конструктора
предоставления отчета
отчета
Нажатие на кнопку «Запросить
Отправление запроса на
отчет»
мобильное устройство; переход
Е5
Е6
на карту с объектами
Е7
Нажатие на уведомление о
Просмотр отчета
полученном отчете
Е8
Подтверждение отчета
Переход на карту с объектами
Е9
Отклонение отчета
Переход на окно конструктора
отчета
Е10
Нажатие на кнопку «Просмотр
Переход на окно просмотра
истории отчетов»
истории отчетов
Нажатие на кнопку «Просмотр
Переход на окно детализации
отчета»
отчета
Е12
Закрытие окна детализации
Переход на окно истории отчетов
Е13
Закрытие окна истории отчетов
Переход на окно карты с
Е11
объектами
66
Продолжение таблицы 8
1
2
3
Е14
Нажатие на кнопку «Графики»
Переход на окно с графиками
Е15
Закрытие окна с графиками
Переход на окно карты с
объектами
Е16
Нажатие на кнопку «Выход из
Выход из системы
системы»
E17
Фильтрация отчетов по
Вывод отсортированной истории
выбранному параметру
отчетов по выбранному
параметру
E18
Закрытие окна с информацией
Переход на карту с объектами
об объекте
4.3 Экранные формы информационной системы, реализующая
разработанную методику
Разработанная методика может быть использована для решения широкого
круга задач, связанных с наблюдением за состоянием удаленных объектов. Чтобы
показать практическую пользу методики рассмотрим ее применение на
конкретном примере.
Могут возникнуть ситуации, при которых необходимо будет производить
полный контроль за состоянием социально значимых объектов на протяжении
некоторого момента времени. В качестве примера возьмем следующие объекты:
1)
котельная. Наблюдаемыми параметрами могут являться:
а) температура наружного воздуха;
б) температура подачи воды;
в) температура обратной воды;
г) наличие электроэнергии;
д) давление воды;
е) состояние котельной;
ж) состояние помещения;
67
з) наличие воды.
2)
мусорные баки. Наблюдаемыми параметрами могу являться:
а) состояние мусорного бака;
б) наличие в нем мусора;
в) состояние окружающей территории.
В связи с тем, что новая методика позволяет манипулировать объектами
разного рода, то возможна организация наблюдения за их состояниями в рамках
одной информационной системы.
Несомненно, некоторые параметры объектов могут быть получены при
помощи датчиков автоматически, но они представляют собой механизм, который
может со временем передавать данные с некоторой погрешностью. Кроме того,
они не застрахованы от поломки. Поэтому ручной контроль за состоянием
объектов и по сей день является актуальной задачей.
Для того, чтобы производить эффективный контроль за состоянием
объектов необходим орган, позволяющий по мере необходимости генерировать
управляющие сигналы своим рабочим единицам по актуализации имеющейся
информации. В качестве такого органа обычно выступает центр управления за
состоянием
объектов,
в
который
входят
диспетчеры,
ответственные
за
актуализации состояния определенного количества объектов. Они имеют доступ к
панели диспетчера, где располагается вся имеющаяся информация об объектах:
1) географическое расположение объектов на карте города;
2) фотография объекта;
3) текущее состояние объектов, которое выражается при помощи цветовой
схемы:
а) зеленый – объект находится в актуальном состоянии;
б) красный – был запрошен отчет по текущему состоянию объекта.
На рисунке 27 представлена главная страница диспетчера, на котором
располагаются все подконтрольные ему объекты.
68
Рисунок 27 – Главная страница диспетчера
Помимо
наблюдаемых
объектов
диспетчер
может
контролировать
перемещение подконтрольных ему рабочих сотрудников. Они выделены на карте
маркером другого типа и имеют в центре иконки букву, на которую начинается их
имя. При нажатии на иконку сотрудников открывается информация о нем, в
которую входит:
1)
имя;
2)
фамилия;
3)
отчество;
4)
фотография;
5)
уникальный идентификатор внутри компании;
6)
контактный номер;
7)
дополнительный контактный номер;
8)
марка и модель рабочего мобильного телефона;
9)
график работы.
В связи с многообразием различных типов наблюдаемых объектов им
должна быть присвоена уникальная иконка, которая поможет выделить их среди
69
подобных объектов на карте, что позволяет диспетчеру произвести быстрый
поиск. Объекты могут быть помещены в кластеры с указанием количества
входящих в него объектов. По нажатию на кластеры они распадаются.
На
рисунке
28
представлена
подробная
информация
об
объекте
«Котельная».
Рисунок 28 – Подробная информация о выбранном объекте
В состав этой информации входит:
1) наименование объекта;
2) фотография объекта;
3) текущее состояние объекта:
а) ожидается отчет – отчет запрошен диспетчером конкретному
исполнителю;
б) отчет не ожидается.
4) адрес месторасположения объекта;
5) панель управления объектом:
а) запрос отчета;
б) история формирования отчетов;
70
в) графики, показывающие зависимость разных параметров объекта
от времени.
Рассмотрим в подробностях процесс формирования запроса на отчет. На
рисунке 29 представлено окно с конструктором структуры отчета.
Рисунок 29 – Окно с конструктором структуры отчета
После нажатия на кнопку запроса отчета открывается конструктор
структуры отчета с выбором необходимых полей. Каждое поле описывается 3
параметрами:
1) наименование поля - указывает на название поля в отчете;
2) тип поля – определяет то, какого формата данные ожидаются в этом
поле. В качестве примера типа поля можно выделить:
а) текстовый;
б) цифровой;
в) изображение;
г) pdf;
д) doc и другие.
3) комментарий
к
полю
предназначенный для исполнителя;
–
вспомогательный
служебный
текст,
71
4) единица измерения – указывает на единицу измерения поля (например,
МПа и т.п.).
При помощи этой информации формируется структура отчета на
мобильном приложении исполнителя. Поля единица измерения и комментарий
могут отсутствовать. На рисунке 30 представлено уведомление, которое получает
сотрудник центра, после отправки запроса на отчет.
Рисунок 30 – Уведомление на запрос отчета от диспетчера
По нажатию на данное уведомление открывается мобильное приложение со
списком объектов. Некоторые из них подсвечены красным цветом, что означает
потребность в формировании отчета. Те, которые подсвечены зеленым цветом не
требуют отчета. В остальном главное окно в мобильном приложении имеет
практически такую же визуализацию, как и на главной странице диспетчера.
На рисунке 31 представлено главное окно, которое видит сотрудник
управляющего центра при входе в приложение. Помимо представленных
объектов
он
также
видит
свое
местоположение,
чтобы
последовательность формирования отчета для необходимых объектов.
оценить
72
Рисунок 31 – Главное окно мобильного приложения сотрудника управляющего
центра
После нажатия на маркер контролируемого объекта открывается внизу
панель с детальной информацией об объекте. На рисунке 32 представлена панель
с информацией об объекте.
Рисунок 32 – Панель с информацией об объекте
73
После нажатия на кнопку предоставления отчета формируется маршрут от
текущего местоположения пользователя до объекта с предоставлением служебной
информации о маршруте: времени предполагаемого движения и расстояния. На
рисунке 33 представлено окно мобильного приложения с построенным
маршрутом до объекта.
Рисунок 33 – Маршрут от сотрудника до наблюдаемого объекта
Местоположение
пользователя
фиксируется
не
только
с
помощью
технологии GPS, но и с помощью аппроксимации текущего места при помощи
вышек сотовой связи. Второй тип определения местоположения доступен только,
если GPS недоступно в течение продолжительного периода времени.
После достижения сотрудника управляющей компании до наблюдаемого
объекта и нажатия на кнопку «Сформировать отчет» происходит запрос на сервер
ожидаемой структуры отчета. Как только структура отчета будет получена, на его
основе будет сгенерировано окно в мобильном приложении для наиболее
74
удобного заполнения сотрудником управляющего центра. На рисунке 34
представлен пример сформированного окна.
Рисунок 34 – Сформированное окно отчета по полученной структуре
После заполнения отчета необходимыми данными и отправки его на
проверку диспетчеру сотрудник управляющей компании ожидает результат
проверки отчета. На рисунке 35 представлено уведомление об успешном
принятии отчета.
Рисунок 35 – Уведомление о успешном принятии отчета
75
Помимо прочего пользователю доступна история формирования отчетов
для контроля за ходом предоставления отчета. В этом окне пользователь может
посмотреть причину отказа в принятии отчета или посмотреть конкретный
документ, характеризующий состояние объекта в конкретный момент времени.
На рисунке 36 представлена история предоставления отчета по конкретному
объекту, в данном случае «Котельная».
Рисунок 36 – История предоставления отчета в мобильном приложении
Воспользоваться
экраном
с
историей
предоставления
отчета
для
конкретного объекта можно только если он не требует на данный момент отчета о
его текущем состоянии.
Таким образом, в мобильном приложении доступны функции, призванные
обеспечить владельца мобильного устройства всей необходимой информацией
для формирования отчета и необходимые для непосредственного создания отчета
о его текущем состоянии.
Диспетчер по полученным показателям уже в автоматическом режиме
формирует графики для наглядного представления об изменении состояния
76
объекта во времени. На рисунке 37 представлена страница с графиками по
показателям конкретного объекта. В данном случае котельной.
Рисунок 37 – Страница с графиками по изменению значения показателей
контролируемого объекта во времени
На графике видны колебания показателей температуры наружного воздуха
и погрешность показателей. Остальные графики располагаются ниже на странице.
Помимо прочего, доступна кнопка выбора периода анализа показателей. После
установки фильтра такого типа показатели объекта масштабируются до
определенного временного промежутка. На данный момент доступны только
графики одного типа. Нулевые показатели на них означают отсутствие
информации для выбранного периода времени. Стоит отметить, что наблюдение
за разными показателями состояния объекта может происходить в разное время,
поэтому для некоторого выбранного периода информация может отсутствовать и
графики построены не будут.
Таким образом, благодаря разработанной методики и эффективной
коммуникации между клиентом и сервером достигается более полный контроль за
состоянием удаленных объектов с предоставлением информации в наглядном
виде.
77
4.4 Методика тестирования взаимодействия мобильного приложения и
сервера ситуационного центра для решения проблем городского
хозяйства
Тестирование системы взаимодействия клиента и сервера является залогом
успешного функционирования информационной системы. Существует как
основные функции системы, формирующие ее ядро, так и побочные,
обеспечивающие эффективное выполнение ядра. Представленная методика
тестирования
позволит
протестировать
ядро
системы,
обеспечивающий
взаимодействия мобильного приложения и сервера ситуационного центра для
решения проблем городского хозяйства, на наличие ошибок при последующем
изменении кода системы. Таким образом, создается уверенность в том, что при
любом изменении в функциональности системы, она будет работать в штатном
режиме.
Методика тестирования состоит из тест-кейсов, которые представляют
собой последовательность шагов с разных сторон взаимодействия для достижения
определённого результата. После чего, ожидаемый результат сравнивается с
полученным. Если результаты не совпадают, то указывается номер тест-кейса, где
была получена ошибка, и информационная система отправляется на доработку
разработчику.
Рассмотрим
текст-кейсы
для
проверки
функциональности
управления состояниями объектов под управлением сервера.
Тест-кейс №1 «Запрос отчета»
Шаги:
1)
выбрать наблюдаемый объект;
2)
нажать на кнопку «Запросить отчет»;
3)
выбрать исполнителя из списка доступных работников;
4)
сформировать структуру будущего отчета;
5)
нажать на кнопку «Запросить отчет».
Результат:
1)
иконка меняет зеленый цвет на красный;
панели
78
2)
на
мобильное
устройство
выбранного
работника
приходит
уведомление о запросе на формирование отчета;
Тест-кейс №2 «Выбор исполнителя»
Шаги:
1)
выбрать наблюдаемый объект;
2)
нажать на кнопку «Запросить отчет»;
3)
выбрать исполнителя из списка доступных работников;
4)
убрать выбранного исполнителя;
5)
снова добавить другого.
Результат: протестирована функциональность выбора исполнителя; выбран
исполнитель для формирования отчета.
Тест-кейс №3 «Формирование структуры отчета»
Шаги:
1)
выбрать наблюдаемый объект;
2)
нажать на кнопку «Запросить отчет»;
3)
выбрать исполнителя из списка доступных работников;
4)
добавить описание текстового поля;
5)
добавить описание числового поля;
6)
добавить описание поля с изображением;
7)
добавить описание поля с документами разных типов;
8)
сформировать структуру отчета.
Результат: сформирована структура отчета с полями разных типов.
Тест-кейс №4 «Подтверждение правильности заполнения отчета»
Шаги:
1)
получить оформленный отчет;
2)
нажать на кнопку «Подтвердить».
Результат:
1)
цвет иконки изменится с красного на зеленый;
2)
полученный отчет занесется в историю отчетов;
3)
показатели полученного отчета будут учтены в построении графиков;
79
4)
на мобильное устройство приходит уведомление об успешном
принятии отчета;
Тест-кейс №5 «Отклонение отчета»
Шаги:
1)
получить оформленный отчет;
2)
нажать на кнопку «Отклонить»;
3)
ввести тест с причиной отклонения;
4)
сформировать структуру отчета (при необходимости);
5)
нажать на кнопку «Запросить отчет».
Результат:
1)
отчет помечен как отклоненный;
2)
отчет отправляется в историю отчетов;
3)
формирование нового запроса отчета.
Рассмотрим тест-кейсы для проверки функциональности мобильного
приложения.
Тест-кейс №1 «Просмотр информации об объекте»
Шаги:
1)
запустить мобильное приложение;
2)
выбрать объект на карте.
Результат: появление внизу панели с информацией об объекте.
Тест-кейс №2 «Построение маршрута до объекта»
Шаги:
1)
запустить мобильное приложение;
2)
выбрать объект, помеченный красным цветом;
3)
нажать на кнопку «Предоставить отчет»;
Результат:
1)
построение маршрута от текущего местоположения пользователя до
объекта;
2)
предоставление времени движения;
3)
предоставление расстояния до объекта.
80
Тест-кейс №3 «Формирование экрана отчета»
Шаги:
1)
запустить приложение;
2)
выбрать объект, помеченный красным цветом;
3)
нажать на кнопку «Предоставить отчет»;
4)
нажать на кнопку «Сформировать отчет».
Результат: предоставление окна отчета, сформированного по загруженной
структуре.
Тест-кейс №4 «Отправление отчета»
Шаги:
1)
запустить приложение;
2)
выбрать объект, помеченный красным цветом;
3)
нажать на кнопку «Предоставить отчет»;
4)
нажать на кнопку «Сформировать отчет»;
5)
заполнить поля;
6)
нажать на кнопку «Отправить отчет».
Результат:
1)
появление окна ожидания ответа от диспетчера;
2)
появление
уведомления
на
панели
управления
диспетчера
загруженном отчете.
Тест-кейс №5 «Подтверждение правильности заполнения отчета»
Шаги:
1)
запустить приложение;
2)
выбрать объект, помеченный красным цветом;
3)
нажать на кнопку «Предоставить отчет»;
4)
нажать на кнопку «Сформировать отчет»;
5)
заполнить поля;
6)
нажать на кнопку «Отправить отчет»;
7)
открыть загруженный отчет на сайте;
8)
нажать на кнопку «Подтвердить».
о
81
Результат:
получение
уведомления
об
успешном
принятии
отчета
принятии
отчета
диспетчером.
Тест-кейс №6 «Отклонение отчета»
Шаги:
1)
запустить приложение;
2)
выбрать объект, помеченный красным цветом;
3)
нажать на кнопку «Предоставить отчет»;
4)
нажать на кнопку «Сформировать отчет»;
5)
заполнить поля;
6)
нажать на кнопку «Отправить отчет»;
7)
открыть загруженный отчет на сайте;
8)
нажать на кнопку «Отклонить»;
9)
ввести причину отклонения;
10)
сформировать новую структуру отчета;
11)
нажать на кнопку «Запросить отчет».
Результат:
получение
уведомления
об
успешном
диспетчером.
Ранее были описаны тест-кейсы для проверки работы ядра информационной
системы, для проверки работы других функций тест-кейсы строятся аналогичным
способом.
Для обеспечения правильной работы мобильного приложения необходимо
его протестировать на всех доступных мобильных устройствах, так как, из-за
специфики операционной системы, некоторые функции могут быть недоступны
или работать некорректно. Кроме того, стоит учесть варианты работы с
мобильным приложением в рамках отсутствия интернет-соединения или наличие
плохого соединения.
82
ЗАКЛЮЧЕНИЕ
Решение
проблем
городского
хозяйства,
связанных
с
состоянием
инфраструктуры города, является наиболее острой проблемой на протяжении
достаточно большого периода времени. Именно полный контроль управляющими
органами за параметрами контролируемых объектов ведет к наиболее спокойной
жизни жильцов города. Ведь потенциальные проблемы лучше предотвратить на
этапе зарождения, чем искать дальнейшие пути решения уже возникших проблем.
В данный момент представлено множество подходов по взаимодействию
мобильного приложения и сервера для мониторинга состояний удаленных
объектов. Но, в связи с многочисленными требованиями к объектам городской
инфраструктуры,
сложно
найти
универсальное
и
гибкое
решение,
удовлетворяющее потребности управляющей компании.
В ходе выполнения работ были проанализированы существующие способы
взаимодействия мобильного приложения и сервера для мониторинга состояния
удаленных объектов. В ходе которых был сделан вывод, что существующие
подходы не обладают достаточной гибкости в вопросе достоверного анализа
состояния наблюдаемых объектов различного типа.
Были описаны существующие подходы к взаимодействию мобильного
приложения и сервера для мониторинга состояния удаленных объектов. Было
проведено исследование и анализ технической части взаимодействия двух сторон.
С помощью диаграмм вариантов использования было проведено описание
предметной области, в ходе которых были выявлены функциональные и
нефункциональные
требования
к
мобильному
приложению
сотрудника
управляющего центра.
В аналитической части работы были проанализированы преимущества и
недостатки существующих подходов. Было выявлено, что существующие
рещения не обладают достаточной гибкостью в вопросе анализа состояния
объектов разных типов с различным набором параметров. Дальнейшее изменение
в процессе взаимодействия ведет к серьезным затратам различного типа. Далее на
83
основе полученной информации была разработана схема взаимодействия
мобильного
приложения
и
сервера
ситуационного
центра
для
гибкого
мониторинга состояния удаленных объектов различных типов, отвечающая
требованиям управляющей компании.
В части проектирования была проведена логическая схема построения сети,
рассмотрена логика взаимодействия мобильного приложения с сервером
посредством наборов методов, разработана структурная схема мобильного
приложения и приведены алгоритмы работы отдельных его подсистем.
В заключительной части была приведена логика диалога с пользователем
как со стороны мобильного приложения, так и со стороны сайта для
представления полной картины взаимодействия. Были представлены процессы
взаимодействия на экранных формах в наглядном виде.
Все поставленные задачи решены и цель была достигнута.
Описанный подход взаимодействия мобильного приложения и сервера
ситуационного центра обладает следующими качествами:
1)
универсальность – разработанная методика не функционирует только
для одного типа контролируемых объектов, она может быть применена для
объектов различного типа;
2)
гибкость – параметры, определяющие состояние объектов, не
являются постоянными значениями, они могут меняться в зависимости от
ситуации, и поэтому быстрая адаптация к новым требованиям является наиболее
приоритетной задачей в наше время;
3)
оперативность – все основные моменты взаимодействия мобильного
приложения и сервера сопровождаются уведомлениями.
84
СПИСОК ЛИТЕРАТУРЫ
1.
Буч, Г. Язык UML. Руководство пользователя. / Г.Буч, Дж Рамбо, И.
Якобсон. – 2-е изд. – Издательство: ДМК Пресс, 2007. – 496 c. – ISBN: 5-94074334-X, 0-321-26797-4.
2.
Вигерс, К. Разработка требований к программному обеспечению
[Текст] / К.Вигерс, Дж. Битти. – 3-е изд. – Издательство: Русская редакция, 2014. –
737 с. – ISBN: 978-5-7502-0433-5.
3.
Магазин интернет-приложений Google Play. [Электронный ресурс]. –
Режим доступа: https://play.google.com/store.
4.
Чекалин В. С. Экономика городского хозяйства: учебн. пособие
[Текст] – Спб: СПбГИЭА, 1999.
5.
Пупырев
Е.И.
Комплексная
модернизация
объектов
жизнеобеспечения современного мегаполиса / под редакцией д.т.н. Мирного А.Н.
– М.: Академия коммунального хозяйства им. К.Д. Памфилова, 2013. – 343 с.
6.
Буч, Г. UML. Классика CS. / Г.Буч – 2-е изд. – Издательство: Питер,
2006. – 736 c. – ISBN: 5-469-00599-2.
7.
Фаулер, М. UML Основы [Текст] / М. Фаулер. – СПб: Символ-Плюс,
2005. – 184 с. – ISBN: 5-93286-060-X.
8.
Медникс, З. Программирование под Android [Текст] / Медникс З.,
Дорнин Л., Мик Б., Накамура М.: Питер, 2013. – 560 с. – ISBN: 978-5-496-005265.
9.
Филлипс, Б. Android: Программирование для профессионала [Текст] /
Филлипс Б., Харди Б., Стюарт К.: Питер, 2017. – 688 с. – ISBN: 978-5-4461-04130.
10.
Голощапов, А. Google Android: Программирование для мобильных
устройств[Текст] / Голощапов А.: BHV, 2012. – 448 с. – ISBN: 978-5-9775-0729-5.
11.
Макконнелл, С. Совершенный код[Текст] / Макконнелл С.: BHV,
2015. – 896 с. – ISBN: 978-5-7502-0064-1.
85
12.
Developer
Android
[Электронный
ресурс].
-
http://developer.android.com/develop/index.html.
13.
Java™
Platform,
Standard
Edition
8
API Specification [Электронный ресурс]. - http://docs.oracle.com/javase/8/docs/api/.
14.
Google
Maps
Android
API
[Электронный
ресурс].
-
https://developers.google.com/maps/documentation/android-api/.
15.
Гриффитс, Д. Head First: Программирование под Android[Текст] /
Гриффитс Д., Гриффитс Д.: Питер, 2016. – 704 с. – ISBN: 978-5-496-02171-5.
16.
Пятин И.И. Использование информационных технологий для решения
проблем городского хозяйства [Текст] / А.Б. Нечаева, В.А. Зубарева, Р.А. Лунев,
И.И. Пятин, Д.В. Рыженков, А.А. Стычук, А.Е. Ястребков // Информационные
системы и технологии. – Орел: ПГУ, 2016. - №4/96. Июль – август 2016. – 120 с. –
С. 51-57.
17.
Гриффитс, Д. Head First: Программирование под Android [Текст] /
Гриффитс Д., Гриффитс Д.: Питер, 2016. – 704 с. – ISBN: 978-5-496-02171-5.
18.
Дейтел, Х. Android для разработчиков [Текст] / Дейтел П., Уолд А.:
Питер, 2016. – 512 с. – ISBN: 978-5-496-02371-9.
19.
Пятин И.И. Анализ требований к геоинформационным системам
мониторинга проблем городского хозяйства [Текст] / А.Б. Андреенков, А.С.
Бычкова, А.Б. Нечаева, В.А. Паршина, И.И. Пятин, С.А. Забелин, А.А. Стычук,
А.Е. Ястребков // Информационные системы и технологии. – Орел: ОГУ имени
И.С. Тургенева, 2017. - №4/102. Июль – август 2017. – 126 с. – С. 22-28.
20.
Клифтон Я. Проектирование пользовательского интерфейса Android
[Текст] / Клифтон Я.: ДМК-Пресс, 2017. – 452 с. – ISBN: 978-5-97060-449-6.
86
ПРИЛОЖЕНИЕ А
(обязательное)
ЛИСТИНГ КОДА ОСНОВНЫХ ФУНКЦИЙ
public class MainActivity extends AppCompatActivity implements OnMapReadyCallback,
OnMapClickListener, GoogleApiClient.ConnectionCallbacks,
ClusterManager.OnClusterItemClickListener<Trash>,
ClusterManager.OnClusterClickListener<Trash>, LocationListener {
public static final String REFRESH_ACTION = "ru.scenter.MainActivity.BroadcastReceiver";
public static final int TRASH = 100;
public static final int DONE = 50;
public static final int ADD_FUNC_RESULT = 1;
public static final int CROP_IMAGE_RESULT = 2;
private GoogleMap map;
private GoogleApiClient googleApiClient;
private Location lastKnownLocation;
private ImageView myLocation;
private ClusterManager<Trash> clusterManager;
private MyMapRender clusterRender;
private NonHierarchicalDistanceBasedAlgorithm<Trash> clusterAlgo;
private RecyclerView clusterMarkers;
private LinearLayout clusterMarkersWrapper;
private ClusterMarkersAdapter clusterMarkersAdapter;
private LinearLayout zoomLayout;
private SharedPreferences authStorage;
private Menu mainMenu;
boolean sendMarkerData;
private Marker myLocationMarker;
public static final int DRIVING_FAST_UPDATE = 500;
public static final int DRIVING_UPDATE = 500;
public static final int ZOOM_MARGIN = 108;
public static final String URI_EXTRA = "uri";
private LinearLayout panel;
private TextView pinName;
private TextView pinAddress;
87
private ImageView pinImage;
private Trash activeTrash;
private String currentPhotoPath;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main_window);
panel = (LinearLayout) findViewById(R.id.sliding_panel);
pinName = (TextView) findViewById(R.id.text_title);
pinAddress = (TextView) findViewById(R.id.text_address);
pinImage = (ImageView) findViewById(R.id.v_image);
Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
setSupportActionBar(toolbar);
SharedPreferences network = getSharedPreferences(AppConfig.NETWORK_STORAGE, 0);
authStorage = getSharedPreferences(AppConfig.AUTH_STORAGE, 0);
TextView login = (TextView) findViewById(R.id.user_phone);
TextView name = (TextView) findViewById(R.id.user_name);
login.setText(authStorage.getString(NetConfig.USER_LOGIN, ""));
name.setText(network.getString(GlobalContract.USER_NAME, ""));
clusterMarkersWrapper = (LinearLayout) findViewById(R.id.ll_wrapper_rv);
clusterMarkers = (RecyclerView) findViewById(R.id.rv_markers_search);
clusterMarkers.setLayoutManager(new LinearLayoutManager(this));
clusterMarkersAdapter = new ClusterMarkersAdapter();
clusterMarkers.setAdapter(clusterMarkersAdapter);
myLocation = (ImageView) findViewById(R.id.my_location);
myLocation.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
if (GeneralUtils.isLocationEnabled(MainActivity.this)) {
lastKnownLocation = getMyLocation();
if (lastKnownLocation == null) {
Toast.makeText(MainActivity.this, R.string.unavailableLocation,
Toast.LENGTH_LONG).show();
return;
}
88
map.animateCamera(CameraUpdateFactory.newLatLngZoom(MapUtils.convertLocationToLatLng(last
KnownLocation), 14));
} else {
Toast.makeText(MainActivity.this, R.string.unavailableLocation,
Toast.LENGTH_LONG).show();
}
}
});
SupportMapFragment mapFragment =
(SupportMapFragment) getSupportFragmentManager()
.findFragmentById(R.id.map);
mapFragment.getMapAsync(this);
if (googleApiClient == null) {
googleApiClient = new GoogleApiClient.Builder(this)
.addConnectionCallbacks(this)
.addApi(LocationServices.API).build();
googleApiClient.connect();
}
zoomLayout = (LinearLayout) findViewById(R.id.zoom_layout);
}
public void runRefreshIcon(boolean isRefresh) {
if (mainMenu != null) {
MenuItem r = mainMenu.findItem(R.id.marks_refresh_toolbar);
if (r != null) {
if (isRefresh) {
r.setVisible(true);
sendMarkerData = true;
r.setActionView(R.layout.refresh_icon_toolbar);
} else {
r.setVisible(false);
sendMarkerData = false;
r.setActionView(null);
}
}
}
}
89
private void animateToCity() {
map.animateCamera(CameraUpdateFactory.newLatLngZoom(GlobalContract.CITY, 11));
}
private void closeAll() {
activeTrash = null;
clusterMarkersWrapper.setVisibility(View.GONE);
panel.setVisibility(View.GONE);
ViewGroup.MarginLayoutParams params =
(ViewGroup.MarginLayoutParams)zoomLayout.getLayoutParams();
params.setMargins(0, 0, 0, (int)GeneralUtils.convertDpToPx(getApplicationContext(), 8));
zoomLayout.setLayoutParams(params);
}
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent imageReturnedIntent) {
super.onActivityResult(requestCode, resultCode, imageReturnedIntent);
if (requestCode == TRASH && resultCode == Activity.RESULT_OK) {
LatLng pos = new LatLng(imageReturnedIntent.getDoubleExtra("lat", 0),
imageReturnedIntent.getDoubleExtra("lon", 0));
map.animateCamera(CameraUpdateFactory.newLatLngZoom(pos, 18));
}
if (resultCode == Activity.RESULT_OK) {
if (requestCode == DONE) {
Intent intent = new Intent(this, CropImageActivity.class);
intent.putExtra(GlobalContract.MARKER_PHOTO, currentPhotoPath);
startActivityForResult(intent, CROP_IMAGE_RESULT);
} else if (requestCode == CROP_IMAGE_RESULT) {
SharedPreferences prefs = getSharedPreferences(AppConfig.APP_STORAGE, 0);
boolean containAdditionalFunctionality =
prefs.getBoolean(AppConfig.additionalFunctionality, false);
Uri imageUri = Uri.fromFile(new File(imageReturnedIntent.getStringExtra(URI_EXTRA)));
if (containAdditionalFunctionality) {
Intent intent = new Intent(this, ReportAddFunctionalityActivity.class);
intent.putExtra(ProviderContract.Marks.URL_IMAGE, imageUri.toString());
startActivityForResult(intent, ADD_FUNC_RESULT);
} else {
90
ContentValues vals = new ContentValues();
vals.put(ProviderContract.Marks._ID, activeTrash.getId());
vals.put(ProviderContract.Marks.URL_IMAGE, imageUri.toString());
Uri toggleOn = Uri.parse("content://" + ProviderContract.AUTHORITY + "/" +
ProviderContract.Marks.TABLE_NAME + "/remote/insert/1");
getContentResolver().insert(toggleOn, vals);
}
} else if (requestCode == ADD_FUNC_RESULT) {
ContentValues vals = new ContentValues();
vals.put(ProviderContract.Marks._ID, activeTrash.getId());
vals.put(ProviderContract.Marks.URL_IMAGE,
imageReturnedIntent.getStringExtra(ProviderContract.Marks.URL_IMAGE));
if (imageReturnedIntent.getExtras().containsKey(GlobalContract.REPOST_REASON))
vals.put(GlobalContract.REPOST_REASON,
imageReturnedIntent.getStringExtra(GlobalContract.REPOST_REASON));
Uri toggleOn = Uri.parse("content://" + ProviderContract.AUTHORITY + "/" +
ProviderContract.Marks.TABLE_NAME + "/remote/insert/1");
getContentResolver().insert(toggleOn, vals);
}
}
}
@Override
public void onMapReady(GoogleMap googleMap) {
map = googleMap;
map.getUiSettings().setMapToolbarEnabled(false);
clusterManager = new ClusterManager<>(this, googleMap);
clusterRender = new MyMapRender(this, googleMap, clusterManager);
clusterManager.setRenderer(clusterRender);
clusterAlgo = new NonHierarchicalDistanceBasedAlgorithm<>();
clusterManager.setAlgorithm(clusterAlgo);
clusterManager.setOnClusterItemClickListener(this);
clusterManager.setOnClusterClickListener(this);
map.setOnMarkerClickListener(clusterManager);
map.setOnMapClickListener(this);
map.setOnCameraChangeListener(clusterManager);
findViewById(R.id.zoom_in_button).setOnClickListener(new View.OnClickListener() {
91
@Override
public void onClick(View v) {
map.animateCamera(CameraUpdateFactory.zoomIn());
}
});
findViewById(R.id.zoom_out_button).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
map.animateCamera(CameraUpdateFactory.zoomOut());
}
});
getSupportLoaderManager().initLoader(1, new Bundle(), new
OrdersActivity.MarkerLoaderCallback(this, new JustDoIt() {
@Override
public void doIt(List<Trash> trashes) {
clusterManager.clearItems();
clusterAlgo.clearItems();
for (int i = 0; i < trashes.size(); i++) {
clusterManager.addItem(trashes.get(i));
if (activeTrash != null && activeTrash.getId() == trashes.get(i).getId()
&& trashes.get(i).getStatus().equals("on")) {
onClusterItemClick(trashes.get(i));
}
}
clusterManager.cluster();
}
}));
if (authStorage.getBoolean(GlobalContract.FIRST_USED, true)) {
Uri uri = Uri.parse("content://" + ProviderContract.AUTHORITY + "/" +
ProviderContract.Marks.TABLE_NAME + "/remote");
getContentResolver().query(uri, null, null, null, null);
authStorage.edit().putBoolean(GlobalContract.FIRST_USED, false).apply();
Uri g_uri = Uri.parse("content://" + ProviderContract.AUTHORITY + "/" +
ProviderContract.Marks.TABLE_NAME + "/group/add");
getContentResolver().insert(g_uri, null);
authStorage.edit().putBoolean(GlobalContract.FIRST_USED, false).apply();
}
}
92
@Override
public void onMapClick(LatLng latLng) {
closeAll();
}
@Override
public void onConnected(@Nullable Bundle bundle) {
if (lastKnownLocation == null && googleApiClient != null) {
lastKnownLocation = getMyLocation();
if (lastKnownLocation == null) {
animateToCity();
return;
}
map.animateCamera(CameraUpdateFactory.newLatLngZoom(MapUtils.convertLocationToLatLng(last
KnownLocation), 14));
if (ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_FINE_LOCATION) !=
PackageManager.PERMISSION_GRANTED && ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_COARSE_LOCATION) !=
PackageManager.PERMISSION_GRANTED) {
return;
}
LocationServices.FusedLocationApi.requestLocationUpdates(googleApiClient,
setNewUpdateRequest(DRIVING_UPDATE, DRIVING_FAST_UPDATE), this);
} else {
animateToCity();
}
}
@Override
protected void onStart() {
super.onStart();
if (googleApiClient != null && googleApiClient.isConnected()) {
if (ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_FINE_LOCATION) !=
PackageManager.PERMISSION_GRANTED && ActivityCompat.checkSelfPermission(this,
93
Manifest.permission.ACCESS_COARSE_LOCATION) !=
PackageManager.PERMISSION_GRANTED) {
return;
}
LocationServices.FusedLocationApi.requestLocationUpdates(googleApiClient,
setNewUpdateRequest(DRIVING_UPDATE, DRIVING_FAST_UPDATE), this);
}
}
@Override
protected void onStop() {
super.onStop();
if (googleApiClient != null && googleApiClient.isConnected())
LocationServices.FusedLocationApi.removeLocationUpdates(googleApiClient, this);
}
@Override
public boolean onClusterItemClick(Trash trash) {
closeAll();
activeTrash = trash;
if (trash.getStatus().equals("off")) {
AlertDialog.Builder builder = new AlertDialog.Builder(this);
TextView view = (TextView) getLayoutInflater().inflate(R.layout.marker_off_advice_layout,
null, false);
view.setText("Вы уверены, что вывезли мусор из мусорного ящика по адресу: " +
trash.getName() + "?");
builder.setView(view);
builder.setPositiveButton("Уверен", new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
openCamera();
}
});
builder.setNegativeButton("Отмена", new DialogInterface.OnClickListener() {
@Override
public void onClick(DialogInterface dialog, int which) {
activeTrash = null;
94
dialog.dismiss();
}
});
builder.setCancelable(false);
builder.create().show();
return true;
}
panel.setVisibility(View.VISIBLE);
pinAddress.setText(trash.getAddress());
pinName.setText(trash.getName());
if (trash.getStatus().equals("off")) {
pinImage.setImageResource(trash.getStatus().equals("on")?R.drawable.garbage_trash_on_main
:R.drawable.garbage_trash_off_main);
pinImage.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
openCamera();
}
});
} else {
pinImage.setImageResource(trash.getStatus().equals("on")?R.drawable.garbage_trash_on_main
:R.drawable.garbage_trash_off_main);
}
return true;
}
private Uri getCaptureImageOutputUri() {
Uri outputFileUri = null;
File getImage = getExternalCacheDir();
if (getImage != null) {
outputFileUri = Uri.fromFile(new File(getImage.getPath(), "pickImageResult.jpeg"));
}
return outputFileUri;
}
@Override
public boolean onClusterClick(Cluster<Trash> cluster) {
closeAll();
clusterMarkersWrapper.setVisibility(View.VISIBLE);
95
clusterMarkersAdapter.setCluster(cluster.getItems());
return true;
}
@Override
public void onLocationChanged(Location location) {
if (myLocationMarker == null)
myLocationMarker = map.addMarker(new
MarkerOptions().position(MapUtils.convertLocationToLatLng(location)).icon(BitmapDescriptorFactor
y.fromResource(R.drawable.garbage_car)));
else {
myLocationMarker.setPosition(MapUtils.convertLocationToLatLng(location));
}
}
public class MyMapRender extends DefaultClusterRenderer<Trash> {
private final float mDensity;
private final IconGenerator mIconClusterGenerator;
private final IconGenerator mIconItemGenerator;
private final Bitmap mIconItemGreen;
private final Bitmap mIconItemOrange;
private static final int CLUSTER_PADDING = 12;
private static final int ITEM_PADDING = 7;
private int icon;
public MyMapRender(Context context, GoogleMap map, ClusterManager<Trash>
clusterManager) {
super(context, map, clusterManager);
mDensity = context.getResources().getDisplayMetrics().density;
mIconClusterGenerator = new IconGenerator(context);
mIconClusterGenerator.setContentView(makeSquareTextView(context,
CLUSTER_PADDING));
mIconClusterGenerator.setTextAppearance(com.google.maps.android.R.style.ClusterIcon_Text
Appearance);
mIconItemGenerator = new IconGenerator(context);
mIconItemGenerator.setContentView(makeSquareTextView(context, ITEM_PADDING));
mIconItemGenerator.setBackground(makeClusterBackground(ContextCompat.getColor(context
, R.color.colorAccent)));
96
mIconItemGreen = mIconItemGenerator.makeIcon();
mIconItemGenerator.setBackground(makeClusterBackground(ContextCompat.getColor(context
, R.color.colorPrimary)));
mIconItemOrange = mIconItemGenerator.makeIcon();
}
@Override
protected void onBeforeClusterItemRendered(Trash item, MarkerOptions markerOptions) {
markerOptions.icon(BitmapDescriptorFactory.fromBitmap(BitmapFactory.decodeResource(get
Resources(), R.drawable.sc_default_marker)));
if (item.getStatus().equals("on")) {
markerOptions.icon(BitmapDescriptorFactory.fromBitmap(BitmapFactory.decodeResource(get
Resources(), R.drawable.garbage_trash_on)));
} else {
markerOptions.icon(BitmapDescriptorFactory.fromBitmap(BitmapFactory.decodeResource(get
Resources(), R.drawable.garbage_trash_off)));
}
}
@Override
protected void onBeforeClusterRendered(Cluster<Trash> cluster, MarkerOptions markerOptions)
{
int clusterSize = getBucket(cluster);
mIconClusterGenerator.setBackground(makeClusterBackground(getColor(clusterSize, false)));
BitmapDescriptor descriptor =
BitmapDescriptorFactory.fromBitmap(mIconClusterGenerator.makeIcon(getClusterText(cluster
Size)));
markerOptions.icon(descriptor);
}
protected int getColor(int clusterSize, boolean clusterEnabled) {
float maxSize = 70;
float size = Math.min((float)clusterSize, maxSize);
float value = clusterEnabled ? 0.5902F : (0.7686F - (size * 0.0084F));
float hue = clusterEnabled ? 30F : 0F;
return Color.HSVToColor(new float[]{hue, 1.0F, value});
}
97
private LayerDrawable makeClusterBackground(int color) {
ShapeDrawable mColoredCircleBackground = new ShapeDrawable(new OvalShape());
mColoredCircleBackground.getPaint().setColor(color);
ShapeDrawable outline = new ShapeDrawable(new OvalShape());
outline.getPaint().setColor(0x80ffffff);
LayerDrawable background = new LayerDrawable(new Drawable[]{outline,
mColoredCircleBackground});
int strokeWidth = (int) (mDensity * 3.0F);
background.setLayerInset(1, strokeWidth, strokeWidth, strokeWidth, strokeWidth);
return background;
}
private SquareTextView makeSquareTextView(Context context, int padding) {
SquareTextView squareTextView = new SquareTextView(context);
ViewGroup.LayoutParams layoutParams = new
ViewGroup.LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT,
ViewGroup.LayoutParams.WRAP_CONTENT);
squareTextView.setLayoutParams(layoutParams);
squareTextView.setId(R.id.text);
int paddingDpi = (int) (padding * mDensity);
squareTextView.setPadding(paddingDpi, paddingDpi, paddingDpi, paddingDpi);
return squareTextView;
}
@Override
protected boolean shouldRenderAsCluster(Cluster cluster) {
return cluster.getSize() > 1;
}
}
}
99
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
Наименование
группы атрибутов
атрибута
1. Описание
Обозначение документа
документа
(идентификатор(ы)
файла(ов))
Наименование документа
2. Даты и время
3. Создатели
4. Внешние
ссылки
5. Защита
6. Характеристики
содержания
Характеристики документа
на электронном носителе
\Презентация_ВКР_Пятин.ppt
Демонстрационные плакаты
к выпускной
квалификационной работе
Класс документа
ЕСКД
Вид документа
Оригинал документа на
электронном носителе
Аннотация
Демонстрационный
материал, отображающий
основные этапы выполнения
выпускной
квалификационной работы
Использование документа Операционная система
Windows 10, Microsoft
PowerPoint 2010
Дата и время
21.06.2018
копирования документа
Дата создания документа 15.06.2018
Дата утверждения
22.06.2018
документа
Автор
Пятин И.И.
Изготовитель
Пятин И.И.
Ссылки на другие
Удостоверяющий лист
документы
№ 165178
Санкционирование
ОГУ имени И.С. Тургенева
Классификация защиты
По законодательству РФ
Объем информации
8975265 Б
документа
100
7. Структура
документа(ов)
Наименование плаката
(слайда) №1
Наименование плаката
(слайда) №2
Наименование плаката
(слайда) №3
Наименование плаката
(слайда) №4
Наименование плаката
(слайда) №5
Наименование плаката
(слайда) №6
Наименование плаката
(слайда) №7
Наименование плаката
(слайда) №8
Наименование плаката
(слайда) №9
Наименование плаката
(слайда) №10
Наименование плаката
(слайда) №11
Титульный лист
Цели и задачи работы
Описание предметной
области
Сравнительная
характеристика
Логическая схема построения
сети
Схема взаимодействия
мобильного приложения и
сервера
Структурная схема
мобильного приложения
Общий алгоритм работы
мобильного приложения
Логика диалога мобильного
приложения с пользователем
Экранные формы сайта
Экранные формы мобильного
приложения