close

Вход

Забыли?

вход по аккаунту

Третьяков Андрей Юрьевич. Разработка кроссплатформенного приложения для управления Wi-Fi устройствами Rubetek через WebSocket API

код для вставки
АННОТАЦИЯ
ВКР 85 с., 35 рис., 2 табл., 10 источников, 1 прил.
УМНЫЙ
ДОМ,
WEBSOCKET,
WEB-ПРИЛОЖЕНИЕ,
«УМНЫЕ»
работа
разработке
УСТРОЙСТВА, АВТОМАТИЗАЦИЯ.
Выпускная
квалификационная
посвящена
кроссплатформенного приложения для управления Wi-Fi устройствами Rubetek
через WebSocket API, позволяющего просматривать показания с датчиков и
управлять бытовыми приборами и освещением.
В первой главе выпускной квалификационной работы приведено описание
предметной области. Проведен анализ и выбор наблюдаемых параметров.
Рассмотрены возможные методы сбора данных пользователя веб-сайта. Проведен
сравнительный анализ существующих решений. Проанализированы различные
методы разработки web-приложений, технологии связи для работы с несколькими
устройствами, а так же методы создания кроссплатформенных приложений.
Выявлены функциональные и нефункциональные требования к системе.
Во второй главе были составлены диаграммы вариантов использования,
классов, состояний и последовательности.
В третьей главе приведена структура протокола связи. Спроектированы
алгоритмы диалога клиент-сервер, обработки нового сообщения и обновления
параметров устройства.
В четвертой главе спроектирован интерфейс приложения, а так же
представлена реализация интерфейса приложения.
Графическая часть выпускной квалификационной работы включает
иллюстрации, таблицы, которые объединены в презентацию PowerPoint.
Библиографическая часть выпускной квалификационной работы включает в
себя 10 источников.
4
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1
6
АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ОБЗОР ПРОГРАММНЫХ
СРЕДСТВ РАЗРАБОТКИ
8
1.1
Описание предметной области
1.2
Функциональные и нефункциональные требования
11
1.3
Обзор аналогов
12
1.4
Анализ методов разработки web-приложений
17
1.5
Анализ технологий связи для работы с несколькими устройствами
21
1.6
Анализ методов создания кроссплатформенных приложений
27
2
МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
8
30
2.1
Диаграмма вариантов использования
30
2.2
Диаграмма классов
33
2.3
Диаграмма состояний
36
2.4
Диаграмма последовательности
39
3
ПРОЕКТИРОВАНИЕ СИСТЕМЫ УПРАВЛЕНИЯ «УМНЫМИ»
УСТРОЙСТВАМИ
43
3.1
Структура протокола связи
43
3.2
Алгоритм диалога клиент-сервер
48
3.3
Алгоритм обработки нового сообщения
49
3.4
Алгоритм обновления параметров устройства
51
4
РЕАЛИЗАЦИЯ КРОССПЛАТФОРМЕННОГО ПРИЛОЖЕНИЯ ДЛЯ
УПРАВЛЕНИЯ WI-FI УСТРОЙСТВАМИ RUBETEK
53
4.1
Проектирование интерфейса приложения
53
4.2
Реализация интерфейса приложения
55
5
ЗАКЛЮЧЕНИЕ
61
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
62
ПРИЛОЖЕНИЕ А – ФРАГМЕНТЫ ЛИСТИНГА ПРОГРАММЫ
63
УДОСТОВЕРЯЮЩИЙ ЛИСТ
83
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА ДОКУМЕНТА НА
ЭЛЕКТРОННОМ НОСИТЕЛЕ
84
6
ВВЕДЕНИЕ
В последние годы все больше увеличивается тенденция к упрощению и
автоматизации повседневных задач. Люди все чаще пользуются технологиями
удаленного и бесконтактного управления различными устройствами и техникой.
Это не только добавляет лишние минуты или даже часы в свободное время
человека, но и помогает экономить ресурсы, а также иметь возможность
контролировать все необходимые процессы на расстоянии. Рост популярности
автоматизированных
систем
управления
сервисными
функциями
жилых
помещений, таких как «умный дом», обусловлен стремлением человека к
комфорту
и
безопасность,
удобству.
будь
то
Дополнительной
противопожарная
привлекательностью
система
или
является
сигнализация
с
дистанционным оповещением [1].
Система «умный дом», или автоматизированная система управления
зданием – это интеграция в жилое пространство высокотехнологичных
инженерных систем с целью обеспечения единого управления и мониторинга.
Таким образом, «умный дом» – это жилой автоматизированный дом
современного
типа,
организованный
при
помощи
высокотехнологичных
устройств, предназначение которых направлено на энергосбережение и комфорт
при максимальной унификации. Система «умный дом» способна распознавать
разные ситуации и реагировать на них согласно программе.
Основной целью современной системы управления жилым пространством
«умный дом» является формирование сложных взаимосвязанных систем,
объединяющих технологии и оборудование разного рода, в результате чего одна
из систем может управлять другими по заранее заданным алгоритмам. Система
позволяет одной командой задать желаемые параметры, в результате которой
автоматика будет отслеживать режимы работы всех инженерных систем и
электроприборов в соответствии с внешними и внутренними условиями.
«Умный дом» является современным инструментом повышения комфорта и
уровня жизни, так как часть процессов происходит автоматически, а остальной
7
частью можно управлять удаленно, что делает ее актуальной для изучения и
совершенствования. Достоинством «умного» оборудования является возможность
легкого управления с любого устройства, поддерживающего Wi-Fi и интернет
подключение [2].
Целью
данной
работы
является
разработка
кроссплатформенного
приложения для управления Wi-Fi устройствами Rubetek через WebSocket API,
позволяющего просматривать показания с датчиков и управлять бытовыми
приборами и освещением. Для достижения данной цели необходимо решить
следующие задачи:
1) провести анализ предметной области;
2) осуществить анализ существующих аналогов;
3) построить функциональную модель системы и определения;
4) определить функциональные и не функциональные требования к
разрабатываемой системе;
5) спроектировать схему логики диалога с пользователем;
6) выбрать средства для разработки системы;
7) разработать основные алгоритмы системы;
8) разработать приложение для управления «умными» устройствами.
8
1
АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ОБЗОР ПРОГРАММНЫХ
СРЕДСТВ РАЗРАБОТКИ
1.1
Описание предметной области
В наше время идея умного дома, который включит кондиционер к приходу
владельца, откроет гараж, приглушит свет в комнате ребенка, уже не является
чем-то необычным и невозможным. На данный момент времени эта концепция
превратилась в реальный рынок всевозможных устройств и технологий,
способных облегчить жизнь каждому человеку. Однако их практически никто не
использует.
Согласно
исследованиям
международного
аналитического
агентства
Forrester Research, занимающегося исследованиями рынка информационных
технологий, на сегодняшний день даже в таких технологически развитых странах,
как США количество умных домов не превышает 6-7%. В России этот показатель,
на данный момент, не превышает и 0,5%.
Но у данной технологии большое будущее, что показывают тенденции ее
развития. Согласно прогнозам исследовательской компании Statista, количество
умных домов в России на протяжении 2018 года выростет до 2%, а к 2022 году
достигнет 8,5%. Данные можно представить в виде графика, изображенного на
рисунке 1.1. Так же в данную технологию щедро инвестируют крупные компании,
одной из которых является Google.
9
Рисунок 1.1 – График прогноза объема рынка умного дома в России за период
2018-2022 год
Из представленных данных можно сделать вывод о том, что актуальность и
рентабельность разработки различных приложений и сервисов для технологии
«Умный дом» растет с каждым днем.
Рассмотрим следующие «умные» устройства:
1) лампа, меняющая цвет освещения;
2) розетка, измеряющая энергопотребление;
3) реле, контролирующее электроприборы.
«Умная» лампа дает пользователю возможность управлять оттенками цвета,
менять яркость, задавать любой цвет. Для этого необходимо подключить ее к
приложению, предназначенному для управления данным устройством, и получить
полный доступ к функционалу.
Регулировка цвета является не только для преображения помещения, но и
для того, чтобы в нужный момент сконцентрировать внимание на работе,
установив холодный света, или же расслабиться, выставив в настройках теплый
10
тон. «Умная» лампа имеет мощность 7 ватт, что на 80% эффективнее обычных
ламп.
В сравнении с обычной лампой, «умная» имеет ряд преимуществ:
a) удаленный контроль освещения;
b) гибкие настройки оттенка, теплоты и яркости освещения;
c) энергоэффективность RGB-светодиодов без потери яркости.
Особенность «умной» розетки в том, что установив ее – человек получает
контроль над питанием нужного электроприбора. Больше не нужно будет
волноваться
о
не
выключенном
утюге.
Можно
знать
точно,
сколько
электроэнергии потребляет конвектор.
Можно выделить следующие достоинства «умной» розетки, в сравнении с
обычной:
a) удаленное управление бытовыми приборами;
b) контроль энергопотребления подключенных устройств.
«Умное» реле так же подключается пользователем к приложению.
Благодаря нему очень удобно управлять теплыми полами или поливом лужайки.
Это устройство совершенно незаметно, так как монтаж производится в
подрозетник или распределительную коробку.
Управление «умными» устройствами происходит обычно через смартфоны.
Чтобы получить приложение для мобильных устройств нужно зайти в магазин
приложений и, воспользовавшись поиском, найти интересующее вас. Так как
выбор достаточно велик, то пользователь может выбрать именно то, что будет
ему удобно. Но у мобильных приложений есть свои недостатки. Например, то,
что они привязаны к определенной операционной системе, а значит, если
разработчик
захочет
охватить
большую
аудиторию,
то
ему
придется
разрабатывать приложение заново уже для другой мобильной платформы.
В
качестве
альтернативы
данным
приложениям
рассмотрим
web-
приложения. Они имеют ряд преимуществ над своими мобильными аналогами:
1) Не требуют установки на устройство. Для того чтобы начать
пользоваться приложением пользователю нужно лишь перейти по адресу
11
конкретно взятого web-приложения с помощью интернет-браузера на любом из
имеющихся у него устройств, будь то персональный компьютер или мобильный
телефон.
2) Кроссплатформенность приложения. Пользователь может пользоваться
web-приложением, не зависимо от операционной системы, которая установлена
на его мобильном устройстве, например, Android или ios, или на его
персональном компьютере, например, Windows или Linux.
3) Возможность создавать такие же web-приложения, которые уже сейчас
есть в браузере в некий оффлайн. Разумеется, если функционал web-приложения
это позволяет, и в этом есть хоть какой-то практический смысл.
1.2
Функциональные и нефункциональные требования
В процессе разработки необходимо выделить некие требования к системе.
Требования к информационным системам, как и к программным продуктам,
делятся на две группы: функциональные и нефункциональные.
Функциональные требования – это требования, которые описывают, что
должно быть реализовано в системе или продукте, а так же действия
пользователей при взаимодействии с ними.
Нефункциональные требования – это требования, которые описывают, как
должна работать система или продукт, а так же какими характеристиками и
свойствами она должна обладать.
Для
разрабатываемой
системы
были
сформулированы
следующие
функциональные и нефункциональные требования:
1) приложение должно быть кроссплатформенным;
2) пользователь может добавлять новые устройства;
3) приложение должно отображать в каждом блоке только тот функционал,
который необходим для комфортной работы с устройством;
4) пользователь может просматривать показания датчиков, установленных
в устройствах;
5) пользователь может управлять добавленными устройствами;
12
6) приложение должно позволять пользователю точно настроить цвет,
оттенок и яркость освещения;
7) приложение должно иметь низкие системные требования.
1.3
Чтобы
Обзор аналогов
выделить преимущества разрабатываемой системы необходимо
рассмотреть аналоги.
В качестве аналогов разрабатываемого приложения были выбраны
следующие программные продукты: EasyHome, MajorDoMo и HouseClever.
Программа MajorDoMo является бесплатной и позволяет пользователю
управлять умными устройствами и получать данные от них. Программа имеет
средние требования к памяти, типу видеокарты и другим техническим
характеристикам настольного персонального компьютера. MajorDoMo можно
установить на Linux или Windows. Для запуска нужно скачать установочный файл
и запустить его. Рекомендуется не менять путь установки программного
обеспечения, так как в противном случае придется в ручном режиме менять путь
для каждого файла данной программы.
Можно заметить, что данное приложение имеет малое количество
поддерживаемых платформ и возможность работы только на персональном
компьютере. Так же наличие хоть и не высоких, но все же требований к
аппаратному обеспечению компьютера будет негативно сказываться на скорости
работы программы, что отрицательно влияет на комфортность использования
MajorDoMo пользователем. Пример работы приложения MajorDoMo представлен
на рисунке 1.2.
13
Рисунок 1.2 – Пример работы приложения «MajorDoMo»
Программа EasyHome устанавливается на планшетный компьютер на
Windows, Android или iOs. Подключается к контроллеру через Wi-Fi или
интернет. Имеет возможность работы с промышленными контроллерами, в том
числе Beckhoff и ОВЕН.
Внешний вид программного обеспечения можно сменить. Пользователю
доступна возможность по своему вкусу изменить иконки, надписи, фон и
расположение элементов интерфейса.
Стоит обратить внимание на то, что для того, чтобы начать полноценно
использовать программу нужно приобрести лицензию, стоимость которой
14
варьируется от 45 тысяч рублей, за версию с упрощенным функционалом, до 75
тысяч рублей за кроссплатформенную версию программного продукта. Пример
работы приложения «EasyHome» представлен на рисунке 1.3.
Рисунок 1.3 – Пример работы приложения «EasyHome»
Приложение
квартирами,
HouseClever
загородными
–
домами,
система
автоматического
офисными
и
управления
производственными
помещениями.
Приложение работает под операционной системой Android. Разработчик
позиционирует его, как готовую систему диспетчеризации для управляющих
компаний с ведением баз данных, с системой зашифрованной передачи данных, с
графиками и диаграммами статистики работы, с контролем и мониторингом за
управляемыми объектами, с возможностью подключения платежных систем и
многих других ресурсов.
Возможна работа с датчиками протечки, счетчиками, световыми приборами,
отоплением и сигнализацией.
15
Программное обеспечение работает на всех версиях
ОС Android.
Приложение позволяет индивидуально конфигурировать систему под запросы и
пожелания каждого пользователя.
К недостаткам приложения можно отнести то, что в старых версиях
операционной системы Android не корректно работает графическое отображение
диаграмм статистики.
Рисунок 1.4 – Пример работы приложения «HouseClever»
Сравнение приложений представлено на таблице 1.1.
16
Таблица 1.1 – Сравнение приложений
Критерий /
Разрабатываемое
Приложение
приложение
1
2
Цена
Бесплатно
EasyHome
Major
House
DoMo
Clever
3
4
5
45, 60 и 75
Бесплатно
Бесплатно
Есть
Нет
тыс. руб. в
зависимости
от типа
лицензии
Кроссплат-
Есть
форменность
Есть, +15тыс.
руб. к
стоимости
лицензии для
Linux и
MacOS
Системные
Низкие
Низкие
Средние
Низкие
Есть
Есть
Есть
Есть
Есть
Есть
Есть
Есть
Есть
Нет
Нет
Есть
Есть
Нет
Нет
Нет
требования
Добавление
устройства
Управление
устройствами
Отдельный
функционал
для
каждого
устройства
Возможность
работы в качестве
web-приложения
17
Продолжение таблицы 1.1.
1
2
3
4
5
Просмотр
Есть
Есть
Есть
Есть
Есть
Нет
Нет
Нет
показаний
датчиков
Настройка цвета,
оттенка и яркости
освещения
1.4
Анализ методов разработки web-приложений
Для выбора необходимого метода разработки web-приложения нужно
учитывать множество факторов [3], например:
1) бюджет, выделенный на создание приложения;
2) сложность проекта, который нужно реализовать;
3) трудоемкость, необходимая для выполнения поставленной перед
исполнителем задачи;
4) уровень знаний у разработчиков.
Можно выделить четыре группы методов:
1) Разработка web-приложения с нуля.
Данный метод разработки предполагает, что web-приложение будет
разрабатываться с чистого листа, а значит, в этом случае навык разработчика
будет играть решающую роль в успешности создания проекта. Основные аспекты,
которые нужно знать исполнителю:
a) язык разметки гипертекста – HTML;
b) язык программирования;
c) принцип функционирования сетей.
Выделим достоинства данного метода разработки:
a) так как разработчик пишет все сам, то ему не придется
разбираться с чужыми системами;
18
b) нет ограничений в используемых инструментах разработки.
В качестве недостатков выделяют следующее:
a) максимальная трудоемкость процесса;
b) высокий
порог
вхождения,
так
как
необходимо
обладать
достаточным количеством знаний;
c) повышенный шанс получить результат низкого качества, в связи с
тем, что данный метод очень зависим от недостатков в вышеизложенных
пунктах.
2) Разработка с помощью конструктора.
Этот метод подразумевает работу исполнителя с конструктором, то есть он
собирает приложение из готовых блоков. Изначально разработчику предлагается
выбрать шаблон, с которым ему предстоит работать. Данный способ разработки
удобен для создания простых сайтов, например, сайтов-визиток.
В качестве примера платформы, предлагающей услуги конструктора,
рассмотрим uCoz. Для начала требуется зарегистрироваться на выбранной
площадке. Следующим шагом будет выбор типа шаблона, например, интернетмагазин, онлайн-визитка, так же имеются более профессиональные шаблоны,
которые при желании можно купить. После выбора можно будет начать заполнять
сайт содержимым, благодаря предложенному платформой web-интерфейсу.
Достоинства данного способа:
a) самый быстрый метод создания проекта, что, в некоторых случаях,
является крайне важным аспектом;
b) при использовании бесплатных шаблонов, является самым
дешевым методом;
c) удобная площадка для разработки, благодаря предлагающемуся
web-интерфейсу;
d) на выходе получаем готовый сайт, для которого не нужно
покупать хостинг.
Выделим недостатки:
a) низкое качество конечного проекта;
19
b) в связи с тем, что разработчик работает с предложенным ему
набором различных функций, его функционал может получиться настолько
ограниченным, что, в конечном счете, может не соответствовать
требуемому web-приложению.
3) Разработка с применением системы управления содержимым.
В первую очередь разработчик, решившийся воспользоваться данным
методом, должен найти подходящий под нужды проекта движок. Он уже будет
содержать необходимый функционал и исполнителю нужно будет только
настроить выбранный движок и изменить под себя дизайн. Конечно, не всегда
удается найти то, что будет полностью соответствовать требованиям проекта, изза чего придется выбирать другой метод разработки web-приложения.
Выделим достоинства у этого метода:
a) высокая скорость разработки, за счет использования готового
движка;
b) не требователен к знаниям исполнителя в области сетевой
разработки;
c) благодаря
популярности
данного
метода
количество
неосвещенных проблем, с которыми может столкнуться разработчик,
крайне мало;
d) возможность расширения функционала при помощи различных
плагинов.
Так же присутствует ряд недостатков:
a) Исходя из жалоб пользователей на плохую устойчивость при
нагрузке, можно сделать вывод о плохой оптимизации данного метода, что
делает необходимым самостоятельное улучшение кода.
b) Обновления движка могут негативно сказаться на работе
подключенных
плагинов,
так
как
они
просто
могут
перестать
поддерживаться. Вероятность того, что часть сайта может перестать
работать является серьезным недостатком.
20
c) Часть систем управления содержимым может иметь платные
тарифы на использование, что способно увеличить бюджет разработки.
d) Безопасность данного метода крайне низкая, что обусловлено
популярностью системы.
4) Разработка с применением фреймворков.
Этот метод очень похож на разработку приложения с нуля. Только в случае
использования разработчиком необходимых ему фреймворков, он избавляется от
части рутинной работы, избавляется от части проблем, с которыми столкнулся бы
при написании проекта самостоятельно.
Выбор фреймворка зависит от нужд исполнителя. Нужно учитывать, что
выбор фреймворка, являющегося не популярным, может негативно сказаться на
количестве справочного материала. Так же стоит обратить внимание, чтобы он
обновлялся, иначе, спустя некоторое время, придется его заменить.
Преимущества данного метода таковы:
a) ускоряет разработку сайта;
b) сокращает время работы над проектом за счет реализации
рутинной работы;
c) обеспечивает
высокую
устойчивость
web-приложения
к
нагрузкам, что позволяет быть наиболее предпочтительным методом для
разработки;
d) является улучшенной версией разработки с чистого листа, что
уменьшает порог вхождения.
Можно выделить следующие минусы этой методики:
a) хотя скорость разработки и выше, чем у первого метода, но
остается довольно медленной, в сравнении с остальными;
b) остается необходимость в знании материала, который требуется
реализовать.
Выбранный метод – разработка web-приложения с помощью фреймворков.
Решающими критериями, повлиявшими на конечный выбор, стали:
1) высокая производительность;
21
2) отсутствие ограничений;
3) отсутствие необходимости реализации рутинных задач.
1.5
Анализ технологий связи для работы с несколькими
устройствами
Для
корректной
работы
приложению
необходимо
обмениваться
сообщениями между браузером и сервером в режиме реального времени. В цели
работы указано, что управление устройствами будет происходить через
WebSocket API. Проведем анализ технологий связи, чтобы убедится в том, что
данная технология выбрана не случайно.
WebSocket (WS) – это протокол полнодуплексной связи поверх TCPсоединения. То есть с помощью этого протокола можно передавать и принимать
сообщение
одновременно.
Он
позволяет
в
режиме
реального
времени
обмениваться сообщениями между браузером и сервером.
WebSocket уже давно не являются экспериментальными, его используют в
браузерных играх, интерактивных, а так же платежных системах. WebSocket уже
стали частью современного веба.
Для web-разработчиков всегда было проблемой получение реакции браузера
на события, которые происходят на сервере. HTTP-протокол имеет свои
недостатки, и его за это критиковали все разработчики. Один из таких
недостатков – проблема постоянного соединения с сервером. Реализация HTTPпротокола изначально не предполагала подобного рода взаимодействия.
Например, если необходимо получить данные с сервера в браузер, то нужно
сделать очередной запрос к серверу и это предполагает перезагрузку страницы. То
есть, если открыли сайт в браузере, загрузили страницу, просмотрели, а к этому
времени на сервере в данной странице произошли изменения, то необходимо
перезагрузить эту страницу, чтобы получить новую информацию.
Есть
довольно
большое
количество
задач,
где
нужно
получить
асинхронность, используя HTTP-протокол. То есть, если на сервере произойдут
изменения, то нужно получить эти изменение в браузере, без перезагрузки. Один
22
из таких примеров — это чат, где люди общаются, и когда один другому
отправляет сообщения, то сообщения видны получателю моментально, без
перезагрузки страницы. Раньше, создание такого вида приложения было нелегкой
задачей, находились разные степени интерпретации, которые имитировали pushдействия сервера. Один из таких примеров — это организованные на клиенте
фреймы, которые перезагружаются раз в секунду и отправляют запросы на сервер.
23
Рисунок 1.5 – Классическая модель программирования сетевых приложений
В этом подходе есть много минусов — создается очень большое количество
запросов на сервер, тяжело организовать правильную структуру приложений. А
самая главная проблема — это то, что создается эмуляция реакций на серверные
24
события. Клиент, то есть браузер, всегда будет получать данные с большой
задержкой.
Теперь посмотрим на AJAX [4]. Когда объект XMLHTTPRequest появился в
браузерах,
положение
немного
улучшилось.
В
данном
случае
можно
взаимодействовать с сервером по схеме Long Polling [5]. Суть данной схемы
такова:
1) клиент (браузер) отправляет запрос на сервер;
2) соединение не закрывается, клиент ожидает наступления события;
3) когда события происходит – клиент получает ответ на свой запрос;
4) клиент тут же отправляет новый запрос.
25
Рисунок 1.6 – Модель приложений для сети на AJAX
В классической модели web-приложения:
1) пользователь заходит на страницу и нажимает на любой её элемент;
2) браузер формирует запрос и отправляет его серверу;
26
3) в ответ сервер генерирует совершенно новую страницу и отправляет её
браузеру;
4) браузер полностью перезагружает всю страницу.
При использовании AJAX:
1) пользователь заходит на страницу и нажимает на любой её элемент;
2) скрипт, на JavaScript, определяет, какая именно информация необходима
для обновления страницы;
3) браузер отправляет соответствующий запрос на сервер;
4) сервер возвращает только ту часть документа, на которую пришёл
запрос;
5) скрипт вносит изменения с учётом полученной информации без
необходимости полной перезагрузки страницы.
С помощью этого подхода можно получать асинхронные запросы к серверу,
а ответы обрабатывать с помощью функций обратного вызова. Но и этот подход
имеет некоторые недостатки. Главный недостаток этого подхода заключается в
том, что здесь сервер и серверные события не являются инициаторами
взаимодействия. Не так давно появился новый протокол, у которого нет
вышеперечисленных недостатков. Новая технология WebSocket представляет
собой реализацию протокола полнодуплексной связи поверх TCP-соединения [6].
Рассмотрим плюсы и минусы протокола WebSocket. Используя данную
технологию необходимо забыть о стандартной модели HTTP-протокола —
«запрос/ответ на запрос». В рамках технологии WebSocket браузер и сервер в
любой момент могут отправлять и принимать данные, то есть они становятся
равными участниками.
WebSocket устанавливает одно единственное соединение клиента с
сервером. Для работы с WebSocket обе стороны, как клиент, так и сервер, должны
поддерживать данную технологию. Все новые браузеры поддерживают протокол
WS, а серверная часть реализуется разработчиком. Когда сервер и клиент готовы
к «бою», они могут отправлять через WebSocket текстовые сообщения. Передача
27
и прием данных, в данном случае, происходят сразу же, так как данная
технология создает двунаправленные каналы связи.
Так как соединение с клиентом и сервером не закрывается, в связи с тем,
что он держится открытым постоянно, это позволяет избежать передачи лишних
данных, например HTTP-заголовков. В стандарте WebSocket нет никаких
ограничений по количеству открытых соединений и по очередности запросов.
В конечном итоге был выбран WebSocket. Решающими критериями выбора
стали:
1) отсутствие возможности передачи лишних данных, например HTTPзаголовков, в связи с тем, что соединение с клиентом и сервером не закрывается;
2) отсутствие ограничений по количеству открытых соединений и по
очередности запросов.
1.6
Анализ методов создания кроссплатформенных приложений
Для
создания
десктопного
приложения
на
основе
web-технологий
рассмотрим два основных варианта:
1) NW.js, который был раньше известен как node-webkit;
2) Electron, носивший ранее название arom-shell.
Так как выбор между ними не так очевиден, то необходимо провести
сравнение этих двух сред. Для этого проведем анализ самых важных отличий и
составим таблицу, для удобности восприятия.
И NW.js и Electron предоставляют платформу для разработки десктопных
приложений с HTML в качестве представления и NodeJS для доступа к
системному API для работы с жестким диском или, например, железом [7]. Но
существуют принципиальные различия между двумя проектами.
В NW.js нужно указать URL основной страницы в package.json и она будет
открываться в качестве главного окна приложения. В Electron же так называемой
точкой входа является программа на NodeJS. В данном случае вместо указания
URL-адреса напрямую необходимо создать окно и загрузить в него, с помощью
API, необходимый HTML-файл.
28
NW.js загружает необходимую нам HTML-страницу и эта страница
получает доступ к контексту Node.js, за счет чего можно сделать вывод, что
парадигма NW.js является более браузеро-ориентированной. При наличии
нескольких открытых окон, все они получают доступ к общему Node.js контексту.
С другой стороны мы обратим внимание на то, что Electron имеет более
NodeJS-ориентированный подход. Он запускает среду выполнения Node.js,
которая будет иметь возможность открывать окна, в которые и будут в
последствии загружаться необходимые web-страницы. Стоит понимать, что это
означает то, что связать несколько окон с основным процессом будет намного
сложнее.
В Electron отсутствует какой-либо механизма для защиты исходного кода.
Трудно назвать Asar достаточной защитой, так как по сути это простой ter-архив,
который может распаковать фактически любой пользователь и тем самым
получить доступ ко всем файлам и исходному коду.
NW.js же позволяет собрать исполняемый файл и обеспечить его защитой
через V8 Snapshot. Данное решение, конечно, не является лучшей защитой для
исходного кода, но когда это является альтернативой тому, чтобы оставить код
открытым, то стоит воспользоваться именно такой мерой безопасности. Из
минусов можно выделить, что будет присутствовать небольшая потеря
производительности.
Если говорить о скорости запуска приложений на Electron и NW.js, то по
личным ощущениям приложения на Electron открываются быстрее как на
Windows, так и на других платформах. Причем разница ощущается даже в том
случае, если мы отключим защиту V8 Snapshot на NW.js.
Сравнение приложений представлено на таблице 1.2.
29
Таблица 1.2 – Сравнение приложений
Критерий \
NW.js
Electron
1
2
3
Скорость работы
Средняя
Высокая
Платформы
Windows, Linux, Mac
Windows, Linux, Mac
Точка входа
HTML и JavaScript
JavaScript
Защита исходного
V8 Snapshot
ASAR Archive
Фреймворк
кода
По большому счету, единственным существенным различием между этими
двумя библиотеками является способность обеспечить безопасность исходного
кода. На мой взгляд, это единственная причина, по которой NW.js лучше, чем
Electron. Именно поэтому в ходе разработки приложения будет использоваться
NW.js. Но это не изменяет того факта, что Electron так же является очень
качественным
проектом,
которым
с
удовольствием
разработчики подобного вида программного обеспечения.
пользуются
многие
30
2
МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
2.1
Диаграмма вариантов использования
Суть данной диаграммы состоит в следующем: проектируемая система
представляется в виде множества сущностей или актеров, взаимодействующих с
системой с помощью, так называемых вариантов использования. При этом
актером
или
действующим
лицом
называется
любая
сущность,
взаимодействующая с системой извне. Это может быть человек, техническое
устройство, программа или любая другая система, которая может служить
источником воздействия на моделируемую систему так, как определит сам
разработчик. В свою очередь, вариант использования служит для описания
сервисов, которые система предоставляет актеру. Другими словами, каждый
вариант использования определяет некоторый набор действий, совершаемый
системой при диалоге с актером. При этом ничего не говорится о том, каким
образом будет реализовано взаимодействие актеров с системой.
Отдельный вариант использования обозначается на диаграмме эллипсом,
внутри которого содержится его краткое название или имя в форме глагола с
пояснительными словами.
Конструкция или стандартный элемент языка UML вариант использования
применяется для спецификации общих особенностей поведения системы или
любой другой сущности предметной области без рассмотрения внутренней
структуры
этой
сущности.
Каждый
вариант
использования
определяет
последовательность действий, которые должны быть выполнены проектируемой
системой при взаимодействии ее с соответствующим актером. Диаграмма
вариантов может дополняться пояснительным текстом, который раскрывает
смысл или семантику составляющих ее компонентов. Такой пояснительный текст
получил название примечания или сценария.
Актер представляет собой любую внешнюю по отношению к моделируемой
системе сущность, которая взаимодействует с системой и использует ее
функциональные возможности для достижения определенных целей или решения
31
частных задач. При этом актеры служат для обозначения согласованного
множества ролей, которые могут играть пользователи в процессе взаимодействия
с проектируемой системой. Каждый актер может рассматриваться как некая
отдельная роль относительно конкретного варианта использования. Стандартным
графическим обозначением актера на диаграммах является фигурка "человечка",
под которой записывается конкретное имя актера.
Отношение расширения определяет взаимосвязь экземпляров отдельного
варианта
использования
с
более
общим
вариантом,
свойства
которого
определяются на основе способа совместного объединения данных экземпляров.
Если имеет место отношение расширения от варианта использования А к
варианту использования В, то это означает, что свойства экземпляра варианта
использования В могут быть дополнены благодаря наличию свойств у
расширенного варианта использования А.
Отношение включения между двумя вариантами использования указывает,
что некоторое заданное поведение для одного варианта использования
включается в качестве составного компонента в последовательность поведения
другого варианта использования. Один вариант использования может быть
включен в несколько других вариантов, а также включать в себя другие варианты.
Отношение включения, направленное от варианта использования А к
варианту использования В, указывает, что каждый экземпляр варианта А
включает в себя функциональные свойства, заданные для варианта В. Эти
свойства специализируют поведение соответствующего варианта А на данной
диаграмме [8].
Для работы приложения
на диаграмме вариантов использования был
выделен актер пользователь – это обычный человек, который использует
приложение для просмотра статистики и управления умными устройствами.
На основании вышеизложенного можно выделить следующие прецеденты:
«Добавление нового устройства» – позволяет добавлять устройство в
основной блок страницы для последующей работы с ним. Для этого нужно
выбрать его из списка доступных устройств.
32
«Просмотр статистики» – позволяет посмотреть статистику устройства.
«Просмотр справки» – предоставляет возможность просмотра справки, для
правильной работы с приложением.
«Управление
устройствами.
устройствами»
Данный
вариант
–
позволяет
использования
управлять
состоит
добавленными
из
следующих
прецедентов:
«Выбор устройства для управления» – выбор конкретного устройства для
управления.
«Включение устройства» – позволяет включить устройство.
«Выключение устройства» – позволяет выключить устройство.
«Изменение параметров» – позволяет изменять параметры для тех «умных»
устройств, для которых это возможно.
Между актером и вариантами использования
«Добавление нового
устройства», «Просмотр справки», «Просмотр статистики» и «Управление
устройствами»
стоит
связь
ассоциации,
показывающая
возможность
использования актером данных прецедентов.
Между вариантом использования «Управление устройствами» и «Выбор
устройства для управления» стоит связь включения, так как она показывает, что
включаемый вариант использования обязателен для выполнения.
Между
вариантами
использования
«Управление
устройствами»
и
«Включение устройства» стоит связь расширения, так как оно показывает, что
данный вариант использования не является обязательным и его выполнение
зависит от ситуации. Аналогично и для прецедента «Выключение устройства».
Связь расширения стоит между вариантами использования «Управление
устройствами» и «Изменение параметров» указывая на то, что расширяющий
вариант использования выполняется лишь при условии того что для устройства
возможно изменение параметров.
Диаграмма вариантов использования кроссплатформенного приложения
представлена на рисунке 2.1.
33
Рисунок 2.1 – Диаграмма вариантов использования
2.2
Диаграмма классов
Диаграмма классов служит для представления статической структуры
модели
системы
в
терминологии
классов
объектно-ориентированного
программирования. Диаграмма классов может отражать, в частности, различные
взаимосвязи между отдельными сущностями предметной области, такими как
объекты и подсистемы, а также описывает их внутреннюю структуру и типы
отношений. На данной диаграмме не указывается информация о временных
аспектах функционирования системы. С этой точки зрения диаграмма классов
является
дальнейшим
развитием
концептуальной
модели
проектируемой
системы [8].
Класс в языке UML служит для обозначения множества объектов, которые
обладают одинаковой структурой, поведением и отношениями с объектами из
других классов. Графически класс изображается в виде прямоугольника, который
34
дополнительно может быть разделен горизонтальными линиями на разделы или
секции. В этих разделах могут указываться имя класса, атрибуты (переменные) и
операции (методы). Обязательным элементов обозначения класса является его
имя.
Кроме внутреннего устройства или структуры классов на соответствующей
диаграмме указываются различные отношения между классами.
Отношение зависимости является наиболее общей формой отношения в
языке UML. Все другие типы отношений можно считать частным случаем
данного отношения. Отношение зависимости показывает, что изменение одного
класса влечет изменение другого класса. Чаще всего применяется, когда один
класс использует другой в качестве аргумента. Изображается пунктирной линией
со стрелкой, направленной от зависимого класса к независимому.
Отношение обобщения – это отношение между общей сущностью
(суперклассом, или родителем) и ее конкретным воплощением (субклассом, или
потомком). Обобщения иногда называют отношениями типа "является", имея в
виду, что одна сущность является частным выражением другой, более общей.
Обобщение означает, что объекты класса-потомка могут использоваться всюду,
где встречаются объекты класса-родителя, но не наоборот. Изображается в виде
линии с большой незакрашенной стрелкой.
Отношение ассоциации показывает, что один класс каким-то образом связан
с другим классом. Изображается сплошной линией, соединяющей классы.
Отношение агрегации имеет место между несколькими классами в том
случае, если один из классов представляет собой некоторую сущность,
включающую в себя в качестве составных частей другие сущности. Графически
отношение агрегации изображается сплошной линией, один из концов которой
представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из
классов, который представляет собой «целое». Остальные классы являются его
«частями».
Отношение композиции является частным случаем отношения агрегации.
Это отношение служит для выделения специальной формы отношения «часть-
35
целое», при которой составляющие части в некотором смысле находятся внутри
целого. Специфика взаимосвязи между ними заключается в том, что части не
могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и
все его составные части. Графически отношение композиции изображается
сплошной линией, один из концов которой представляет собой закрашенный
внутри ромб. Этот ромб указывает на тот из классов, который представляет собой
класс-композицию или «целое». Остальные классы являются его «частями».
На основе описания диаграммы вариантов использования можно выделить
следующие классы:
«Пользователь» – может управлять, изменять параметры определенных
устройств и просматривать их статистику; этот факт описывается наличием
ассоциативной связи с классом «Устройство».
«Устройство» – родительский класс для классов: ««Розетка»» и «Лампа».
Класс «Устройство» хранит сведения об устройствах, такие как: название
устройства, IP устройства, тип устройства.
«Розетка» – данный класс содержит данные
об энергопотребление. Он
является дочерним классом класса «Устройство». Наследует все атрибуты
родителя и помимо этого имеет свой атрибут: энергопотребление.
«Лампа» – содержит данные об интенсивности излучаемого света и его
цвете. Является дочерним классом класса «Устройство» и наследует его
атрибуты, а также имеет свои атрибуты: интенсивность света и цвет.
Диаграмма классов приложения представлена на рисунке 2.2.
36
Рисунок 2.2 – Диаграмма классов
2.3
Диаграммы
последовательности
Диаграмма состояний
состояний
предназначены
состояний
и
для
переходов,
описания
которые
в
возможной
совокупности
характеризуют поведение элемента модели в течение его жизненного цикла.
Каждая диаграмма состояний представляет собой конечный автомат.
Конечный автомат – модель для спецификации поведения объекта в форме
последовательности его состояний, которые описывают реакцию объекта на
внешние события, выполнение объектом действий, а также изменение его
отдельных свойств.
В
контексте
языка
UML
понятие
конечного
автомата
обладает
дополнительной семантикой. Вершинами графа конечного автомата являются
состояния, которые изображаются соответствующими графическими символами.
Дуги графа служат для обозначения переходов из состояния в состояние.
37
Конечный
автомат
описывает
поведение
отдельного
объекта
в
форме
последовательности состояний, охватывающих все этапы его жизненного цикла,
начиная от создания объекта и заканчивая его уничтожением.
Под состоянием понимается абстрактный метакласс, используемый для
моделирования отдельной ситуации, в течение которой имеет место выполнение
некоторого условия. Состояние может быть задано в виде набора конкретных
значений атрибутов класса или объекта, при этом изменение их отдельных
значений будет отражать изменение состояния моделируемого класса или
объекта.
Начальное состояние представляет собой частный случай состояния,
которое не содержит никаких внутренних действий (псевдосостояния). В этом
состоянии находится объект по умолчанию в начальный момент времени. Оно
служит для указания на диаграмме состояний графической области, от которой
начинается процесс изменения состояний.
Конечное (финальное) состояние представляет собой частный случай
состояния,
которое
также
не
содержит
никаких
внутренних
действий
(псевдосостояния). В этом состоянии будет находиться объект по умолчанию
после завершения работы автомата в конечный момент времени. Оно служит для
указания на диаграмме состояний графической области, в которой завершается
процесс изменения состояний или жизненный цикл данного объекта.
Событие является самостоятельным элементом языка UML. Формально,
событие представляет собой спецификацию некоторого факта, имеющего место в
пространстве и во времени. Про события говорят, что они "происходят", при этом
отдельные события должны быть упорядочены во времени. После наступления
некоторого события нельзя уже вернуться к предыдущим событиям, если такая
возможность не предусмотрена явно в модели [8].
Составное состояние – такое сложное состояние, которое состоит из других
вложенных в него состояний. Последние будут выступать по отношению к
первому как подсостояния.
38
Последовательные подсостояния (sequential substates) используются для
моделирования такого поведения объекта, во время которого в каждый момент
времени объект может находиться в одном и только одном подсостояний.
Поведение объекта в этом случае представляет собой последовательную смену
подсостояний, начиная от начального и заканчивая конечным подсостояниями.
В отдельных случаях переход может иметь несколько состоянийисточников и несколько целевых состояний. Такой переход получил название –
параллельный переход. Графически такой переход изображается вертикальной
черточкой. Если параллельный переход имеет две или более входящих дуг, то его
называют соединением. Если же он имеет две или более исходящих из него дуг,
то его называют ветвлением [9].
На
рисунке
2.3
представленная
диаграмма
состояний
класса
«Пользователь», который использует приложение для управления «умными»
устройствами.
В самом начале происходит ветвление на следующие состояния:
1) состояние «Справка просмотрена», если пользователь не знает, как
пользоваться приложением, то после ее просмотра он может, вернувшись в
начало перейти к добавлению устройства;
2) состояние «Устройство добавлено»;
3) состояние «Статистика просмотрена»;
4) состояние «Устройство выбрано для управления», если устройства уже
были добавлены на основной блок страницы.
Этот возможно благодаря наличию параллельного перехода, называемого
соединением.
После наступления состояния «Устройство выбрано для управления»
происходит ветвление на следующие состояния:
1) состояние
«Статистика
просмотрена»,
если
пользователю, после чего вернуться в начало;
2) составное состояние «Управление устройством».
она
необходима
39
Составное состояние использует ветвление для предоставления вариантов
управления устройством.
Рисунок 2.3 – Диаграмма состояний
2.4
Диаграмма последовательности
Для моделирования взаимодействия объектов во времени используются
диаграммы последовательности. Взаимодействие изображается в виде двумерной
схемы. По вертикали проходит временная ось, направленная сверху вниз. По
горизонтали указываются роли, которые представляют отдельные роли.
На диаграмме последовательности изображаются только те объекты,
которые непосредственно участвуют во взаимодействии. Ключевым моментом
40
для диаграмм последовательности является динамика взаимодействия объектов во
времени.
В UML диаграмма последовательности имеет как бы два измерения. Первое
слева направо в виде вертикальных линий, каждая из которых изображает линию
жизни отдельного объекта, участвующего во взаимодействии. Крайним слева на
диаграмме изображается объект, который является инициатором взаимодействия.
Правее изображается другой объект, который непосредственно взаимодействует с
первым. Таким образом, все объекты на диаграмме последовательности образуют
некоторый порядок, определяемый очередностью или степенью активности
объектов при взаимодействии друг с другом.
Вторым измерением диаграммы последовательности является вертикальная
временная ось, направленная сверху вниз. Начальному моменту времени
соответствует самая верхняя часть диаграммы. Взаимодействия объектов
реализуются посредством сообщений, которые посылаются одними объектами
другим. Сообщения изображаются в виде горизонтальных стрелок с именем
сообщения, а их порядок определяется временем возникновения. То есть,
сообщения,
расположенные
на
диаграмме
последовательности
выше,
инициируются раньше тех, которые расположены ниже. Масштаб на оси времени
не указывается, поскольку диаграмма последовательности моделирует лишь
временную упорядоченность взаимодействий типа «раньше-позже».
Сообщение представляет собой законченный фрагмент информации,
который отправляется одним объектом другому. При этом прием сообщения
инициирует выполнение определенных действий, направленных на решение
отдельной задачи тем объектом, которому это сообщение отправлено.
Синхронный вызов обычно представляет операцию вызова – отправка
сообщения и ожидание реакции на него.
Асинхронный вызов представляет отправку сообщения и дальнейшее
продолжение работы без ожидания реакции.
41
Комбинированный фрагмент состоит из ключевого слова и одного или
нескольких вложенных фрагментов. Значение вложенных фрагментов зависит от
ключевого слова.
Условный фрагмент (alt) – имеет два или более вложенных фрагмента,
каждый из которых имеет начальное сторожевое условие. Когда поток
управления достигает условного фрагмента, выполняется тот из его вложенных
фрагментов, сторожевое условие которого является истинным. Если сторожевое
условие истинно более чем у одного вложенного фрагмента, выбор одного из
таких фрагментов осуществляется случайным образом.
Необязательный фрагмент (opt) – является частным случаем условного
фрагмента: имеется один вложенный фрагмент, который выполняется в случае,
если его сторожевое условие истинно, и не выполняется, если оно ложно.
Инициатором моделируемого процесса является «Пользователь». Он
непосредственно взаимодействует с объектом «Система» и «Устройство».
Сообщение «Просмотр справки» заключено в необязательный фрагмент и
выполняется только тогда, когда сторожевое условие будет истинно.
«Пользователь» посылает синхронное сообщение «Добавление нового
устройства» объекту «Система», который в свою очередь посылает «Запрос на
добавление устройства» объекту «Устройство» и ожидает ответного сообщения о
подтверждении добавления. После этого «Система» отправляет обратное
сообщение «Устройство добавлено» объекту «Пользователь».
«Пользователь» посылает синхронное сообщение «Добавление нового
устройства» и ожидает ответного сообщения от объекта «Система» о добавлении.
Сообщение «Просмотр статистики» заключено в необязательный фрагмент
и выполняется при истинности сторожевого условия.
Во фрагменте «Управление устройством» описана последовательность
взаимодействия объекта «Пользователь» с объектами «Система» и «Устройство».
Данный фрагмент состоит из:
1) синхронного
сообщения
от
объекта
«Система» о выборе устройства для управления;
«Пользователь»
к
объекту
42
2) возвращаемого сообщения о том, что устройство выбрано;
3) альтернативного фрагмента состоящего из двух вложенных фрагментов
выполняющихся, когда их сторожевые условия являются истиной;
4) необязательного фрагмента изменение параметров устройства.
Диаграмма последовательности представлена на Рисунке 2.4.
Рисунок 2.4 – Диаграмма последовательности
43
ПРОЕКТИРОВАНИЕ СИСТЕМЫ УПРАВЛЕНИЯ «УМНЫМИ»
3
УСТРОЙСТВАМИ
3.1
Структура протокола связи
Аспекты работы протокола полнодуплексной связи WebSocket, в рамках
данного приложения, можно разобрать на примере алгоритма диалога клиентсервер
[10].
Данный
алгоритм
в
общем
виде
представляет
собой
детерминированный конечный автомат, изображенный на рисунке 3.1.
Рисунок 3.1 – Конечный автомат алгоритма диалога клиент-сервер
В конечном автомате существуют переходы и состояния. В данном случае
автомат имеет 6 состояний и 10 переходов.
Изначально автомат находится в начальном состоянии (S0). По переходу
«Запрос подключения» состояние меняется на новое – подключено к устройству
(S1).
Из состояния S1 по переходу «Запрос ключа» попадаем в состояние, когда
ключ получен (S2). Так же из состояния S1 можно перейти в конечное состояние
(S5).
Переход «Ответ на установку соединения» отвечает за переход из состояния
S2 в состояние, когда клиент может отправлять запросы с данными серверу (S3).
При необходимости, если понадобится сменить ключ, можно повторить запрос,
44
используя переход «Запрос ключа». Возможет и переход в конечное состояние
(S5).
Из состояния S3, благодаря переходу «Запрос передачи данных»,
происходит изменение состояния на новое – «Передача данных успешна» (S4).
Так же из состояния S3 можно перейти в S5.
Состояние S4 является предпоследним и имеет два перехода: в конечное
состояние (S5) или же снова в S4, если передачу данных необходимо провести
повторно.
Рассмотрим основные аспекты работы с WebSocket подробнее:
1) Данные.
Данные поверх WebSocket передаются в виде стандартного JSON.
2) Ключи, подписи и т.д.
Ключи, подписи и случайности передаются в виде 8 шестнадцатеричных
цифр, представляющих беззнаковое 32-бит число. Буквы всегда должны быть в
верхнем регистре.
3) Запрос соединения.
После подключения клиента, сервер выдает запрос, представленный на
рисунке 3.2.
Рисунок 3.2 – Пример серверного запроса после подключения клиента
Запрос содержит следующие параметры:
a) «deviceId» – идентификатор устройства;
b) «deviceType» – тип устройства;
c) «seed» – случайность для передачи данных на устройство – «tx_seed».
Если ключа нет – клиент должен прислать запрос на ключ, представленный
на рисунке 3.3.
45
Рисунок 3.3 – Пример запроса ключа у устройства
Это запросит новый ключ у устройства. Надо будет подтвердить выдачу
ключа нажатием кнопки.
После чего устройство пришлет свой ключ, как представлено на рисунке
3.4.
Рисунок 3.4 – Пример ответа устройства с предоставлением ключа
Время выдачи ключа – 10 секунд. В течение этого времени нужно нажать на
кнопку.
Если время прошло – ключ надо запрашивать заново.
Если нужно сменить ключ – нужно произвести новый запрос, показанный
на рисунке 3.5.
Рисунок 3.5 – Пример запроса нового ключа у устройства
В таком случае ключ поменяется, и другие клиенты не смогут больше
подключаться к этому устройству.
Если у клиента уже есть ключ для этого устройства, то запрос проводить не
требуется и можно приступать к следующим операциям.
4) Ответ на установку соединения.
Имея ключ и «tx_seed», клиент отправляет ответ на установку соединения,
как представлено на рисунке 3.6.
Рисунок 3.6 – Пример ответа клиента на установку соединения
46
Данный запрос содержит в себе следующие параметры:
a) «seed» – случайность для приема данных от устройства (надо
сгенерировать случайно) – «rx_seed»;
b) «sign» – подпись запроса.
Далее идет обмен подписанными и неподписанными запросами.
5) PING/PONG.
Клиент должен периодически (не реже 1 раза в 5 секунд) отправлять
запросы типа, указанного на рисунке 3.7.
Рисунок 3.7 – Пример запроса клиента
Устройство будет отвечать, как показано на рисунке 3.8.
Рисунок 3.8 – Пример ответа устройства
Запросы также могу быть подписанными.
6) Подписывание запросов.
Рассмотрим запрос, представленный на рисунке 3.9.
Рисунок 3.9 – Пример запроса на установку соединения
Отмеченная часть является телом запроса, «sign» – сгенерированная
подпись.
Подпись генерируется так, как представлено на рисунке 3.10.
Рисунок 3.10 – Пример генерации подписи
Для данной строки получается:
47
Рисунок 3.11 – Пример генерации подписи для запроса на установку соединения
После использования подписи «tx_seed» увеличивается на единицу.
Соответственно, после проверки подписи «rx_seed» тоже надо увеличить на
единицу.
7) Передача данных.
Для данных используются запросы с «type="data"». Пример представлен на
рисунке 3.12.
Рисунок 3.12 – Пример запроса для передачи данных
Далее перечисляются переменных, которые необходимо изменить.
Устройство всегда подтверждает принятые изменения. Рассмотрим пример,
изображенный на рисунке 3.13.
Рисунок 3.13 – Пример изменения переменной
Если переменная изменилась из-за внешнего воздействия, устройство
отправит соответствующий запрос.
Рассмотрим несколько важных алгоритмов, использующихся в процессе
разработки приложения:
1) алгоритм диалога клиент-сервер;
2) алгоритм обработки нового сообщения (события);
3) алгоритм обновления параметров устройства.
48
3.2
Алгоритм диалога клиент-сервер
Алгоритм диалога клиент-сервер начинает свою работу с подключения
клиента к устройству.
Чтобы предотвратить передачу непроверенных данных в устройство – оно
требует наличие соответствующего ключа у клиента. Для получения ключа –
клиент отправляет соответствующий запрос.
Далее клиент проверяет, был ли им получен ключ от устройства, и если он
был получен, то передает свои данные устройству, чтобы обеспечить работу
WebSocket. В случае если этого не произошло – запрос повторяется.
После ответа на установку соединения клиент может сменить полученный
ключ, запросив новый. Это нужно в тех случаях, если требуется прервать доступ
всех прочих клиентов к данному устройству.
Имея полную связь с устройством и актуальный, ключ клиент может начать
управлять устройством, запросив передачу данных.
Алгоритм прекращает свою работу в том случае, если клиент перестанет
управлять устройством.
На рисунке 3.14 представлена схема алгоритма диалога клиент-сервер.
Рисунок 3.14 – Схема алгоритма диалога клиент-сервер, лист 1
49
Рисунок 3.14, лист 2
3.3
Алгоритм обработки нового сообщения
Алгоритм обработки нового сообщения в WebSocket – ws.onmessage.
Данный алгоритм работает по следующей схеме.
Вначале сообщение проверяется на наличие подписи. В случае если
подпись присутствует, то необходимо вычислить собственную подпись и
сравнить их.
50
При совпадении подписей производится обновление состояния устройства
на состояние из сообщения, и алгоритм заканчивает свою работу. Если же
подписи не совпадают, то алгоритм завершает свою работу с ошибкой.
В случае, когда сообщение содержит подпись, алгоритм производит
проверку сообщения на наличие в нем «зерна», то есть параметра «seed»,
необходимого для обмена данных с устройством.
Если сообщение содержит в себе «зерно», то происходит запрос текущего
ключа. Следующим шагом является обновление идентификатора и типа
устройства, после чего алгоритм завершает работу.
Когда в сообщении нет параметра «seed», алгоритм проверяет событие на
наличие в нем ключа.
Сообщение, в котором содержится только ключ, определяется алгоритмом
как запрос на подключение. В этом случае производится «рукопожатие» и
подключение считается успешным. Затем алгоритм завершает свою работу.
Если сообщение не имеет подписи, не содержит «зерно» и не имеет ключа,
то это сообщение неизвестно обработчику, что приводит к незамедлительному
завершению работы алгоритма.
На рисунке 3.15 представлена схема алгоритма обработки нового
сообщения.
51
Рисунок 3.15 – Схема алгоритма обработки нового сообщения
3.4
Алгоритм обновления параметров устройства
Алгоритм, занимающийся обновлением параметров устройства, достаточно
прост. Рассмотрим принцип его работы на устройстве с изменяющимися
параметрами – на «умной» лампе.
Первым шагом является проверка на включенность режима управления
устройством.
В случае, когда управление устройством не производится, алгоритм
завершает свою работу.
Если же режим управления устройством активен, то производится отправка
новых значений цвета и яркости на устройство. После чего алгоритм
возвращается в начало с небольшой задержкой, которая составляет триста
миллисекунд.
52
Данная задержка нужна для более стабильной работы системы и не является
очень заметной для пользователя, а значит, не сказывается негативно на комфорте
использования приложения.
На рисунке 3.16 представлена схема алгоритма обновления параметров
устройства.
Рисунок 3.16 – Схема алгоритма обновления параметров устройства
53
4
РЕАЛИЗАЦИЯ КРОССПЛАТФОРМЕННОГО ПРИЛОЖЕНИЯ ДЛЯ
УПРАВЛЕНИЯ WI-FI УСТРОЙСТВАМИ RUBETEK
4.1
Проектирование интерфейса приложения
Любое web-приложение в качестве основного способа представления
информации пользователю использует передачу HTML страниц. Перед тем, как
приступать к разработке самого приложения, необходимо сформировать
структуру будущих страниц. Шаблон будет содержать в себе следующие блоки:
1) верхний блок – меню навигации;
2) основной блок – основное содержание страницы;
3) нижний блок – полезные ссылки, контакты и т.д.
Начнем с первого блока – меню навигации. Данная часть страницы будет
отведена под кнопки управления. Она не должна занимать много места и
отвлекать пользователя от основного блока, но должна оставаться удобной для
доступа и правильно упорядоченной.
Основной же блок занимает большую часть страницы и содержит в себе
основную информацию и функционал. При добавлении устройств, блок будет
пополняться новыми блоками с соответствующим устройству функционалом.
Последний из представленных блоков – нижний. В нем продублирована
контактная
информация
из
справки,
чтобы
пользователь
имел
больше
возможностей доступа к ней.
Пример расположения блоков на странице представлен на рисунке 4.1.
54
Рисунок 4.1 – Шаблон страниц приложения
55
4.2
Реализация интерфейса приложения
Основная страница приложения представлена на рисунке 4.2. На ней
пользователь имеет доступ к следующим возможностям:
1) добавлять новые устройства, благодаря пункту «Добавить новое
устройство» в меню навигации;
2) обратиться к справке, при возникновении вопросов по работе
приложения;
3) просмотреть информацию о добавленных им устройствах в режиме
реального времени;
4) изменять параметры добавленных им устройств.
Дизайн данной страницы выполнен в основных цветах компании Rubetek и
содержит дополнительные элементы оформления, для комфорта восприятия
пользователя.
Рисунок 4.2 – Основная страница приложения
Подключение устройств осуществляется в отдельном модальном окне,
представленном на рисунке 4.3.
56
В нем пользователь может выбрать необходимое ему устройство из списка,
показанного на рисунке 4.4. Выбрав необходимое устройство, пользователь
может добавить его, нажав кнопку «Добавить устройство» или же выйти из
модального окна на основную страницу, нажав на крестик в верхнем правом углу
или же на затемненную область за пределами модального окна.
Рисунок 4.3 – Модальное окно для добавления устройства
Рисунок 4.4 – Модальное окно для добавления выбранного устройства
57
Рассмотрим интерфейс основного окна при добавлении следующих
устройств:
1) розетка;
2) реле;
3) лампа.
Блок управления «умной» розеткой имеет 4 поля:
1) иконка розетки;
2) название розетки;
3) мощность, потребляемая подключенным к розетке прибором;
4) кнопки управления розеткой.
Иконка представлена круглым векторным изображением самой розетки.
Потом идет название розетки. Мощность расположена в правой части блока и
имеет серый цвет текста. Кнопки управления для розетки – это включение и
выключение устройства.
Окно с добавленной «умной» розеткой представлено на рисунке 4.5.
Рисунок 4.5 – Окно с добавленной «умной» розеткой
58
Блок управления «умным» реле имеет всего 3 поля:
1) иконка реле;
2) название реле;
3) кнопки управления реле.
Иконка, название и кнопки управления выполнены и расположены в блоке
аналогично с тем, как они выполнены и расположены в блоке «умной» розетки.
Вид окна с добавленным «умным» реле представлен на рисунке 4.6.
Рисунок 4.6 – Окно с добавленным «умным» реле
Для блока управления «умной» лампой создано 4 поля:
1) иконка лампы;
2) название лампы;
3) поля для управления яркостью и цветом лампы;
4) кнопки управления лампой.
Иконка, название и кнопки управления, расположенные в блоке «умной»
лампы, аналогичны блокам других «умных» устройств.
59
Управление яркостью осуществляется с помощью указания в процентах
необходимого уровня яркости. За цвет отвечают поля: красный, зеленый и синий.
Они заполняются так же процентами.
На рисунке 4.7 изображен вид окна с добавленной «умной» лампой.
Рисунок 4.7 – Окно с добавленной «умной» лампой
Важным моментом является возможность пользователя воспользоваться
справкой, благодаря которой он сможет найти решение возникшей у него
проблемы.
Если пользователь не смог найти ответа на интересующий его вопрос он
может обратиться с ним по указанной в нижней части справки почте. После чего,
дождавшись ответа, воспользоваться полученным ответом для решения своей
проблемы.
Модальное окно справки представлено на рисунке 4.8.
60
Рисунок 4.8 – Модальное окно справки
61
ЗАКЛЮЧЕНИЕ
В результате выполнения данной работы было спроектировано и
разработано приложение для управления Wi-Fi устройствами Rubetek. Перед
проектированием была проанализирована предметная область, рассмотрены
существующие аналоги и проведён сравнительный анализ. Была рассмотрена
архитектура
приложения,
описаны
применяющиеся
алгоритмы,
выбрано
подходящее средство реализации, а также рассмотрен вид приложения.
В результате выполнения данной работы все поставленные цели были
достигнуты.
62
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
1. Роб ванн Краненбург. The Internet of Things: A critique of ambient
technology and the all-seeing network of RFID. — Pijnacker: Telstar Media, 2008. —
62 c.
2. Оливер Херсент. The Internet of Things: Key Applications and Protocols. —
Willey, 2012. — 370 c.
3. Гото Келли, Котлер Эмили. Web-редизайн, 2-е издание. — СПб.:
«Символ-Плюс», 2006. — 416 c.
4. Дейв Крейн, Эрик Паскарелло, Даррен Джеймс. AJAX в действии:
технология — Asynchronous JavaScript and XML = Ajax in Action. — М.: Вильямс,
2006. — 640 c.
5. Дэниел Вулстон. Ajax и платформа .NET 2.0 для профессионалов = Pro
Ajax and the .NET 2.0 Platform. — М.: Вильямс, 2007. — 464 c.
6. Генри С. Уоррен, мл. Глава 5. Подсчет битов // Алгоритмические трюки
для программистов = Hacker’s Delight. — М.: Вильямс, 2007. — 288 c.
7. Roy Sutton. Desktop Targets // Enyo: Up and Running: Build Native-Quality
Cross-Platform JavaScript Apps. — 2-nd ed.. — O'Reilly, 2015. — 83 c.
8. Леоненков А.В. Самоучитель UML. 2-е издание. – СПб.: "БХВПетербург", 2004. – 161 c.
9. Крэг Ларман. Применение UML 2.0 и шаблонов проектирования =
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design
and Iterative Development. — 3-е изд. — М.: Вильямс, 2006. — 736 с.
10. Дуглас Камер. Сети TCP/IP, том 1. Принципы, протоколы и структура =
Internetworking with TCP/IP, Vol. 1: Principles, Protocols and Architecture. —
М.: «Вильямс», 2003. — 880 c.
63
ПРИЛОЖЕНИЕ А
(обязательное)
ФРАГМЕНТЫ ЛИСТИНГА ПРОГРАММЫ
ws.js
var ws;
var tmr;
var last_id;
var key="12345678";
var tx_seed, rx_seed;
var data_relay1, data_relay2, data_light, data_light2, data_rfDiscovery, timerId1, timerId2, knopka1,
knopka2;
function hex6(value)
{
var hex=(value >>> 0).toString(16).toUpperCase();
while (hex.length < 6)
hex="0" + hex;
return hex;
}
function hex8(value)
{
var hex=(value >>> 0).toString(16).toUpperCase();
while (hex.length < 8)
hex="0" + hex;
return hex;
}
function ws_init()
{
ws_ui_disconnected();
}
function ws_ui_connected()
{
// Buttons
document.getElementById("btnConnect").disabled=true;
64
document.getElementById("btnDisconnect").disabled=false;
}
function ws_ui_handshake_ok()
{
document.getElementById("btnRelay1").disabled=false;
document.getElementById("btnRelay1").style.background='#E0E0E0';
data_relay1=false;
document.getElementById("btnRelay2").disabled=false;
document.getElementById("btnRelay2").style.background='#E0E0E0';
data_relay2=false;
document.getElementById("btnRelay3").disabled=false;
document.getElementById("btnRelay3").style.background='#E0E0E0';
data_relay3=false;
document.getElementById("btnRelay4").disabled=false;
document.getElementById("btnRelay4").style.background='#E0E0E0';
data_relay4=false;
document.getElementById("btnlight").disabled=false;
document.getElementById("btnlight").style.background='#E0E0E0';
data_light=false;
document.getElementById("btnlight2").disabled=false;
document.getElementById("btnlight2").style.background='#E0E0E0';
data_light2=false;
document.getElementById("btnSendKU").disabled=false;
document.getElementById("btnSendKI").disabled=false;
document.getElementById("btnSendKP").disabled=false;
document.getElementById("btnSendCloudServer").disabled=false;
document.getElementById("btnSendTimeZone").disabled=false;
document.getElementById("btnSendRGBOff").disabled=false;
document.getElementById("btnSendRGBOn").disabled=false;
document.getElementById("btnSendlamp").disabled=false;
document.getElementById("btnSendRGBW").disabled=false;
document.getElementById("btnSendRGBR").disabled=false;
document.getElementById("btnSendRGBG").disabled=false;
65
document.getElementById("btnSendRGBB").disabled=false;
document.getElementById("btn_rfDiscovery").disabled=false;
document.getElementById("btn_rfDiscovery").style.background='#E0E0E0';
}
function ws_ui_disconnected()
{
// Buttons
document.getElementById("btnConnect").disabled=false;
document.getElementById("btnDisconnect").disabled=true;
document.getElementById("btnRelay1").disabled=true;
document.getElementById("btnRelay1").style.background='#E0E0E0';
document.getElementById("btnRelay2").disabled=true;
document.getElementById("btnRelay2").style.background='#E0E0E0';
document.getElementById("btnRelay3").disabled=true;
document.getElementById("btnRelay3").style.background='#E0E0E0';
document.getElementById("btnRelay4").disabled=true;
document.getElementById("btnRelay4").style.background='#E0E0E0';
document.getElementById("btnlight").disabled=true;
document.getElementById("btnlight").style.background='#E0E0E0';
document.getElementById("btnlight2").disabled=true;
document.getElementById("btnlight2").style.background='#E0E0E0';
document.getElementById("devId").value="";
document.getElementById("devType").value="";
document.getElementById("devVersion").value="";
document.getElementById("stpm_U").value="";
document.getElementById("stpm_I").value="";
document.getElementById("stpm_Pact").value="";
document.getElementById("stpm_Papp").value="";
document.getElementById("stpm_kU").value="";
document.getElementById("stpm_kI").value="";
document.getElementById("stpm_kP").value="";
document.getElementById("btnSendKU").disabled=true;
document.getElementById("btnSendKI").disabled=true;
document.getElementById("btnSendKP").disabled=true;
document.getElementById("cloudServer").value="";
66
document.getElementById("timeZone").value="";
document.getElementById("btnSendCloudServer").disabled=true;
document.getElementById("btnSendTimeZone").disabled=true;
document.getElementById("rgb_LevelOff").value="";
document.getElementById("rgb_LevelOn").value="";
document.getElementById("btnSendRGBOff").disabled=true;
document.getElementById("btnSendRGBOn").disabled=true;
document.getElementById("lamp_Level").value="";
document.getElementById("RTC_time").value="";
document.getElementById("rgb_LevelW").value="";
document.getElementById("rgb_LevelR").value="";
document.getElementById("rgb_LevelG").value="";
document.getElementById("rgb_LevelB").value="";
document.getElementById("btnSendlamp").disabled=true;
document.getElementById("btnSendRGBW").disabled=true;
document.getElementById("btnSendRGBR").disabled=true;
document.getElementById("btnSendRGBG").disabled=true;
document.getElementById("btnSendRGBB").disabled=true;
document.getElementById("btn_rfDiscovery").disabled=true;
document.getElementById("btn_rfDiscovery").style.background='#E0E0E0';
}
function ws_connect()
{
// Buttons
document.getElementById("btnConnect").disabled=true;
document.getElementById("btnDisconnect").disabled=false;
// Clearing log
ws_clear_log();
// Getting host
var host=document.getElementById("host").value;
ws_log("Connecting to "+host);
// Opening connection
ws = new WebSocket("ws://"+host+":80/");
ws.onopen =
function()
67
{
ws_log("Connected");
ws_ui_connected();
// Setting ping timer
tmr=setInterval(
function()
{
ws.send('{"type":"ping"}');
}, 3000);
};
ws.onclose =
function(evt)
{
ws_log("Connection closed code=" + evt.code + " reason=" + evt.reason);
clearInterval(tmr);
ws_ui_disconnected();
};
ws.onmessage =
function(evt)
{
var str=evt.data;
if (str=='{"type":"pong"}') return;
if (document.getElementById("wsLog").checked)
ws_log("<<< "+str);
var data=eval("(" + str + ")");
var seed_pos=str.indexOf(",\"seed\":\"");
var key_pos=str.indexOf(",\"key\":\"");
if (data.sign != null)
{
// Has signature
var sign_str=str.substring(1, str.indexOf(",\"sign\":\""));
var my_sign=hex8(CRC32.str(hex8(rx_seed++) + key + sign_str));
if (my_sign != data.sign)
ws_log("signature error mine='"+my_sign+"' !");
68
if ( (data.data != null) && (data.data.currentState != null) )
{
//ws_log("<<< "+str);
ws_currentState(data.data.currentState);
}
} else
if (data.seed != null)
{
// Got TX seed
tx_seed=parseInt("0x"+data.seed);
// Sending key request
ws_send('{"type":"currentKeyRequest"}');
// Log
ws_log("Press button on device..");
// Device ID & Type
document.getElementById("devId").value=data["dev:id"];
document.getElementById("devType").value=data["dev:type"];
} else
if (data.key != null)
{
// Got key
key=data.key;
// Sending our handshake
rx_seed=Math.floor(Math.random() * 2147483647);
ws_send_signed("\"type\":\"handshake\",\"seed\":\"" + hex8(rx_seed) + "\"");
// Log
ws_log("Handshake finished");
ws_ui_handshake_ok();
} else
{
//ws_log("not signed");
}
};
}
function ws_disconnect()
69
{
ws_ui_disconnected();
clearInterval(tmr);
ws.onclose=null;
ws.close();
ws_log("Connection closed");
}
function ws_send(msg)
{
if (document.getElementById("wsLog").checked)
ws_log(">>> "+msg);
ws.send(msg);
}
function ws_send_signed(msg)
{
msg="{" + msg + ",\"sign\":\"" + hex8(CRC32.str(hex8(tx_seed++) + key + msg, 0)) + "\"}";
ws_send(msg);
}
function ws_send_data(msg)
{
ws_send_signed('"type":"data",'+msg);
}
function ws_btn_relay1()
{
ws_send_data('"relay:on[0]":'+(! data_relay1));
}
function ws_btn_relay2()
{
ws_send_data('"relay:on[1]":'+(! data_relay2));
}
function ws_btn_relay3()
{knopka1=!knopka1;
if (knopka1==true)
{
timerId1 = setInterval(function ws_btn_relay1()
70
{
if (data_relay1==true) {
ws_send_data('"relay:on[0]":'+(! data_relay1));
}
else {
ws_send_data('"relay:on[0]":'+(! data_relay1));
}
}, 200);
}
else
{
setTimeout(function ws_btn_relay1() {
clearInterval(timerId1);
}, 200);
}
}
function ws_btn_relay4()
{knopka2=!knopka2;
if (knopka2==true)
{
timerId2 = setInterval(function ws_btn_relay2()
{
if (data_relay2==true) {
ws_send_data('"relay:on[1]":'+(! data_relay2));
}
else {
ws_send_data('"relay:on[1]":'+(! data_relay2));
}
}, 200);
}
else
{
setTimeout(function ws_btn_relay2() {
clearInterval(timerId2);
}, 200);
71
}
}
function ws_btn_light()
{
ws_send_data('"lamp:on[0]":'+(! data_light));
}
function ws_btn_light2()
{
ws_send_data('"lamp:mode[0]":'+(! data_light2));
}
function ws_send_kU()
{
ws_send_data('"pwr:Vcal":'+parseFloat(document.getElementById("stpm_kU").value));
}
function ws_send_kI()
{
ws_send_data('"pwr:Ical":'+parseFloat(document.getElementById("stpm_kI").value));
}
function ws_send_kP()
{
ws_send_data('"pwr:Pcal":'+parseFloat(document.getElementById("stpm_kP").value));
}
function ws_send_cloudServer()
{
ws_send_data('"cloud:server":"'+document.getElementById("cloudServer").value+'"');
}
function ws_send_timeZone()
{
ws_send_data('"rtc:tz":'+Math.floor(parseFloat(document.getElementById("timeZone").value)*3600.0
));
}
function ws_send_rgbOff()
{
ws_send_data('"rgb:level[0]":'+parseInt(document.getElementById("rgb_LevelOff").value));
72
}
function ws_send_rgbOn()
{
ws_send_data('"rgb:level[1]":'+parseInt(document.getElementById("rgb_LevelOn").value));
}
function ws_send_lamp()
{
ws_send_data('"lamp:brightness[0]":'+parseInt(document.getElementById("lamp_Level").value));
}
function ws_send_rgbW()
{
ws_send_data('"lamp:W[0]":'+parseInt(document.getElementById("rgb_LevelW").value));
}
function ws_send_rgbR()
{
ws_send_data('"lamp:R[0]":'+parseInt(document.getElementById("rgb_LevelR").value));
}
function ws_send_rgbG()
{
ws_send_data('"lamp:G[0]":'+parseInt(document.getElementById("rgb_LevelG").value));
}
function ws_send_rgbB()
{
ws_send_data('"lamp:B[0]":'+parseInt(document.getElementById("rgb_LevelB").value));
}
function ws_rfDiscovery()
{
ws_send_signed('"type":"data","child:ev1527:discovery":'+(! data_rfDiscovery));
}
function ws_currentState(data)
{
if (data["relay:on[0]"] != null)
{
data_relay1=data["relay:on[0]"];
if (data_relay1)
73
document.getElementById("btnRelay1").style.background='#40E040'; else
document.getElementById("btnRelay1").style.background='#E0E0E0';
}
if (data["relay:on[1]"] != null)
{
data_relay2=data["relay:on[1]"];
if (data_relay2)
document.getElementById("btnRelay2").style.background='#40E040'; else
document.getElementById("btnRelay2").style.background='#E0E0E0';
}
if (data["relay:on[2]"] != null)
{
data_relay3=data["relay:on[2]"];
if (data_relay3)
document.getElementById("btnRelay3").style.background='#40E040'; else
document.getElementById("btnRelay3").style.background='#E0E0E0';
}
if (data["relay:on[3]"] != null)
{
data_relay4=data["relay:on[3]"];
if (data_relay4)
document.getElementById("btnRelay4").style.background='#40E040'; else
document.getElementById("btnRelay4").style.background='#E0E0E0';
}
if (data["lamp:on[0]"] != null)
{
data_light=data["lamp:on[0]"];
if (data_light)
document.getElementById("btnlight").style.background='#40E040'; else
document.getElementById("btnlight").style.background='#E0E0E0';
}
if (data["lamp:mode[0]"] != null)
{
data_light2=data["lamp:mode[0]"];
if (data_light2)
74
document.getElementById("btnlight2").style.background='#40E040'; else
document.getElementById("btnlight2").style.background='#E0E0E0';
}
if (data["pwr:Vrms"] != null)
{
document.getElementById("stpm_U").value=data["pwr:Vrms"];
}
if (data["pwr:Irms"] != null)
{
document.getElementById("stpm_I").value=data["pwr:Irms"];
}
if (data["pwr:Pact"] != null)
{
document.getElementById("stpm_Pact").value=data["pwr:Pact"];
}
if (data["pwr:Papp"] != null)
{
document.getElementById("stpm_Papp").value=data["pwr:Papp"];
}
if (data["dev:version"] != null)
{
document.getElementById("devVersion").value=data["dev:version"];
}
if (data["pwr:Vcal"] != null)
{
document.getElementById("stpm_kU").value=data["pwr:Vcal"];
}
if (data["pwr:Ical"] != null)
{
document.getElementById("stpm_kI").value=data["pwr:Ical"];
}
if (data["pwr:Pcal"] != null)
{
document.getElementById("stpm_kP").value=data["pwr:Pcal"];
75
}
if (data["cloud:server"] != null)
{
document.getElementById("cloudServer").value=data["cloud:server"];
}
if (data["rtc:tz"] != null)
{
document.getElementById("timeZone").value=parseFloat(data["rtc:tz"]) / 3600.0;
}
if (data["rgb:level[0]"] != null)
{
document.getElementById("rgb_LevelOff").value=parseInt(data["rgb:level[0]"]);
}
if (data["rgb:level[1]"] != null)
{
document.getElementById("rgb_LevelOn").value=parseInt(data["rgb:level[1]"]);
}
if (data["rtc:time"] != null)
{
document.getElementById("RTC_time").value=data["rtc:time"];
}
if (data["lamp:brightness[0]"] != null)
{
document.getElementById("lamp_Level").value=parseInt(data["lamp:brightness[0]"]);
}
if (data["lamp:W[0]"] != null)
{
document.getElementById("rgb_LevelW").value=parseInt(data["lamp:W[0]"]);
}
if (data["lamp:R[0]"] != null)
{
document.getElementById("rgb_LevelR").value=parseInt(data["lamp:R[0]"]);
}
if (data["lamp:G[0]"] != null)
{
76
document.getElementById("rgb_LevelG").value=parseInt(data["lamp:G[0]"]);
}
if (data["lamp:B[0]"] != null)
{
document.getElementById("rgb_LevelB").value=parseInt(data["lamp:B[0]"]);
}
if (data["child:ev1527:discovery"] != null)
{
data_rfDiscovery=data["child:ev1527:discovery"];
if (data_rfDiscovery)
document.getElementById("btn_rfDiscovery").style.background='#40E040'; else
document.getElementById("btn_rfDiscovery").style.background='#E0E0E0';
}
if (data["child:ev1527:seen"] != null)
{
var id=parseInt(data["child:ev1527:seen"]);
if (id != 0)
{
document.getElementById("rfID").value=hex6(id);
ws_log("child:ev1527:seen: "+hex6(id));
} else
{
document.getElementById("rfID").value="";
}
}
}
function ws_log(text)
{
var ta=document.getElementById("log");
ta.value += text + "\n";
ta.scrollTop = ta.scrollHeight;
}
function ws_clear_log()
{
document.getElementById("log").value="";
77
}
function ws_send_raw()
{
var msg=document.getElementById("rawmsg").value;
ws_send_signed(msg);
}
test.html
<html>
<link href="css/bootstrap.css" rel="stylesheet" />
<link href="css/bootstrap-theme.css" rel="stylesheet" />
<link href="blocks.css" rel="stylesheet">
<link href="https://fonts.googleapis.com/css?family=Source+Sans+Pro" rel="stylesheet">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Rubetek devices</title>
<style>
body {
padding: 30px;
background: url(pic/bg.png) right bottom no-repeat;
background-size: 100%;
}
</style>
</head>
<script src="js/bootstrap.min.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa"
crossorigin="anonymous"></script>
<body onload="ws_init()">
<font face="sans-serif">
<script src="crc32.js"></script>
78
<script src="ws_client.js"></script>
<meta charset="utf-8">
<button class="btn btn-info" data-toggle="modal" data-target="#dobavl">Добавить новое
устройство</button>
<div id="dobavl" class="modal fade">
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<button class="close" data-dismiss="modal">x</button>
<h4>Подключение устройства</h4>
</div>
<div class="modal-body">
Выберите устройство Rubetek которое хотите подключить:
<form method="post" name="drop_down_box">
<select name="menu" size="1">
<option selected="selected" value="first">Умная розетка</option>
<option value="second">Лампа RGB</option>
<option value="third">Умное реле</option>
</select>
</form>
</div>
<div class="but0"><button id="btnConnect" onclick="ws_connect()" type="button"
class="btn btn-success">Добавить устройство</button></div>
<div class="modal-footer">
При возникновении вопросов – смотрите F.A.Q.
</div>
</div>
</div>
</div>
<button class="btn btn-info" data-toggle="modal" data-target="#sprav">Справка</button>
<div id="sprav" class="modal fade">
<div class="modal-dialog">
<div class="modal-content">
79
<div class="modal-header">
<button class="close" data-dismiss="modal">x</button>
<h4>Справка по программе</h4>
</div>
<div class="modal-body">
Добавление нового устройства происходит нажатием на кнопку «Добавить новое
устройство» в меню навигации, выбором устройства из раскрывающегося списка и нажатием на
кнопку «Добавить устройство», выбранное устройство появится в основном блоке страницы.
<p></p>
Добавленное устройство можно включить и выключить нажатием на кнопки
«Вкл» и «Выкл».
<p></p>
Изменение параметров осуществляется только для тех устройства, для которых
это предусмотрено. В добавленном устройстве появятся ячейки, в которые можно ввести новые
значения параметров.
<p></p>
Статистика показывается у определенных устройств рядом с кнопками «Вкл» и
«Выкл».
</div>
<div class="modal-footer">
При
возникновении
вопросов,
пишите
на
почту:
<a
href="mailto:[email protected]">[email protected]</a>
</div>
</div>
</div>
</div>
<div class="roz">
<div><img src="pic/roz2.png" alt="KARTINKA" class="img-rounded"></div>
<div class="text">Розетка</div>
<div class="dop1">1,67 Вт</div>
<div
class="but"><button
class="btn
btn-lg
btn-primary"
id="btnRelay1"
btn-lg
btn-primary"
id="btnRelay1"
onclick="ws_btn_relay1()">Вкл</button></div>
<div
class="but2"><button
class="btn
onclick="ws_btn_relay1()">Выкл</button></div>
80
</div>
<div class="lamp">
<div><img src="pic/lamp2.png" alt="KARTINKA" class="img-rounded"></div>
<div class="text">Лампа</div>
<div class="dop2">
Яркость: <input id="rgb_LevelW" style="width: 40" />% <button id="btnSendRGBW"
onclick="ws_send_rgbW()">Set</button>&nbsp;&nbsp;&nbsp;&nbsp;
Красный: <input id="rgb_LevelR" style="width: 40" />% <button id="btnSendRGBR"
onclick="ws_send_rgbR()">Set</button>&nbsp;&nbsp;&nbsp;&nbsp;
Зеленый: <input id="rgb_LevelG" style="width: 40" />% <button id="btnSendRGBG"
onclick="ws_send_rgbG()">Set</button>&nbsp;&nbsp;&nbsp;&nbsp;
Синий: <input id="rgb_LevelB" style="width: 40" />% <button id="btnSendRGBB"
onclick="ws_send_rgbB()">Set</button>&nbsp;&nbsp;&nbsp;&nbsp;
</div>
<div
class="but"><button
class="btn
btn-lg
btn-primary"
id="btnRelay1"
btn-lg
btn-primary"
id="btnRelay1"
onclick="ws_btn_relay1()">Вкл</button></div>
<div
class="but2"><button
class="btn
onclick="ws_btn_relay1()">Выкл</button></div>
</div>
<div class="rele">
<div><img src="pic/rele2.png" alt="KARTINKA" class="img-rounded"></div>
<div class="text">Реле</div>
<div
class="but"><button
class="btn
btn-lg
btn-primary"
id="btnRelay1"
btn-lg
btn-primary"
id="btnRelay1"
onclick="ws_btn_relay1()">Вкл</button></div>
<div
class="but2"><button
class="btn
onclick="ws_btn_relay1()">Выкл</button></div>
</div>
</body>
</html>
blocks.css
.roz {
81
position:relative;
height: 100px;
background: #ffffff;
padding: 20px;
margin-top: 3px;
border: solid 5px #03a9f4;
font: bold 24px 'Source Sans Pro';
}
.lamp {
position:relative;
height: 100px;
background: #ffffff;
padding: 20px;
margin-top: 3px;
border: solid 5px #03a9f4;
font: bold 24px 'Source Sans Pro';
}
.rele {
position:relative;
height: 100px;
background: #ffffff;
padding: 20px;
margin-top: 3px;
border: solid 5px #03a9f4;
font: bold 24px 'Source Sans Pro';
}
.but {
position: absolute;
right: 100px;
top: 25px;
}
.but2 {
position: absolute;
right: 20px;
top: 25px;
82
}
.but0 {
position: relative;
left: 20px;
bottom: 10px;
}
.text {
position: absolute;
left: 100px;
top: 30px;
}
.dop1 {
position: absolute;
right: 180px;
top: 35px;
color: darkgrey;
font: bold 20px 'Source Sans Pro';
}
.dop2 {
position: absolute;
right: 180px;
top: 35px;
color: darkgrey;
font: bold 14px 'Source Sans Pro';
}
84
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
Наименование
группы атрибутов
атрибута
1. Описание
Обозначение документа
документа
(идентификатор(ы)
файла(ов))
Наименование документа
Класс документа
Вид документа
Аннотация
Использование
документа
2. Даты и время
3. Создатели
4. Внешние
ссылки
5. Защита
6. Характеристики
содержания
Дата и время
копирования документа
Дата создания документа
Дата утверждения
документа
Автор
Изготовитель
Ссылки на другие
документы
Санкционирование
Классификация защиты
Объем информации
документа
Характеристики документа
на электронном носителе
\ ВКР_презентация.ppt
Демонстрационные плакаты
к выпускной
квалификационной работе
ЕСКД
Оригинал документа на
электронном носителе
Демонстрационный
материал, отображающий
основные этапы выполнения
выпускной
квалификационной работы
Операционная система
Windows 7, Microsoft
PowerPoint 2007
13.06.2018
17.06.2018
18.06.2018
Третьяков А.Ю.
Третьяков А.Ю.
Удостоверяющий лист
№ 140043
ОГУ имени И.С. Тургенева
По законодательству РФ
718848 Б
85
7. Структура
документа(ов)
Наименование плаката
(слайда) №1
Наименование плаката
(слайда) №2
Наименование плаката
(слайда) №3
Наименование плаката
(слайда) №4
Наименование плаката
(слайда) №5
Наименование плаката
(слайда) №6
Наименование плаката
(слайда) №7
Наименование плаката
(слайда) №8
Наименование плаката
(слайда) №9
Наименование плаката
(слайда) №10
Наименование плаката
(слайда) №11
Наименование плаката
(слайда) №12
Титульный лист
Цели и задачи работы
График прогноза объема
рынка умного дома в России
за период 2018-2022 год
Сравнение приложения с
аналогами, лист 1
Сравнение приложения с
аналогами, лист 2
Диаграмма вариантов
использования
Диаграмма состояний
Диаграмма
последовательности
Схема алгоритма диалога
клиент-сервер
Схема алгоритма обработки
нового сообщения
Схема алгоритма обновления
параметров устройства
Пример работы программы
1/--страниц
Пожаловаться на содержимое документа