Принцип работы показан на рисунке 2.2.
Цикл начинается, когда пользователь, на уровне представления взаимодействует с приложение, и при этом срабатывает экшен. В тоже время экшен изменяет глобальное состояние приложения, и в результате происходит перерендер представления в соответствии с изменениями.
Рисунок 2.2 - принцип работы REDUX
Redux является реализацией Flux-архитектуры -- паттерна для организации передачи данных в React-приложениях.
Таким образом реализовано практически каждое действие, совершаемое пользователем.
Теперь перейдем к типовым алгоритмам, которые были использованы при разработке. На рисунке 2.3 представлен алгоритм для построение календарной тепловой карты для модуля полноты данных:
Так как для решения задач требуется потоковое динамическое обновление данных для их актуальности, в каждом модуле есть веб-сокеты. Соединение становится защищенным и помехоустойчивым с помощью библиотеки Redux,
Рисунок 2.3 - блок-схема алгоритма построения тепловой карты
На рисунке 2.4 приведен обобщенный алгоритм работы с веб-сокетами.
«Анализ полноты данных»
Модуль «Анализ полноты данных» позволит специалистам визуально оценивать какая доля в объеме данных пришла с устройства некорректно или совсем не пришла (все ли данные собраны системой с устройств).
Это поможет оценить какие устройства работали в выделенный промежуток исправно, а какие нет и локализировать проблему. Поэтому данный модуль станет важным инструментом системы SEDMAX.
Рисунок 2.4 - блок-схема алгоритма организации работы веб-сокетов
2.5 Разработка программных модулей
Интерфейс визуализируется в виде так называемой «тепловой карты» (Heatmap), которая позволяет оценить плотность распределения данных, на временном промежутке. интернет автоматизация модуль интерфейс
Требовалось разработать два типа модуля для разных форматов.
1. Формат «Даты по месяцам»
Формат и структура данных, приходящих с бэкенда - это массив месяцев, где месяц - это массив из объектов с двумя полями: дата и значение в процентах за эту дату.
Следует сразу пояснить, что пользователь может выбирать не полные месяцы, но в ответе приходят полные, а даты, которые не нужны пользователю имеют значение «-1».
Если пользователь запрашивает данные за период с 11 апреля 2018 по 20 октября 2018, то в ответ на запрос придет структура:
[ // выбранные даты формируют массив месяцев
[ // месяц - массив дат
{
value: -1, // невыбранная пользователем дата месяца
date: '2018-04-01'
},
...
{
value: -1,
date: '2018-04-10'
},
{
value: 100, // выбран период с началом 2018-04-11
date: '2018-04-11'
},
...
{
value: 69,
date: '2018-04-30'
}
],
[
{
value: 55,
date: '2018-05-01'
},
...
/// МАЙ
],
[ { ИЮНЬ(Полный) } ], // данные от 2018-04-01 до '2018-10-31'
... // в ответе 7 месяцев
[ { СЕНТЯБРЬ(Полный) } ],
[
///ОКТЯБРЬ(Не полный)
...
{
value: 69, // выбранный период до 2018-10-20
date: '2018-10-20'
},
{
value: -1,
date: '2018-10-21'
},
...
{
value: -1,
date: '2018-10-31'
}
]
];
Логика построения компонента «Календарной тепловой карты»:
<Layout>
<Title gridArea="Title">
<h3>Календарная тепловая карта</h3>
</Title>
<Content gridArea="Heatmap">
{Data.map((month, indexMonth) => (
<MonthBlock
key={indexMonth}
width={this.getCountOfWeeks(
month[0].date,
month[month.length - 1].date
)}
>
<MonthContent>
{this.drawOffset(month)}
{month.map(date => (
<CalendarHeatmapCell
key={date.date}
cellValue={date.value}
cellColor={this.valuesToColorHSL(date.value)}
cellDate={date.date}
/>
))}
</MonthContent>
<MonthLabel
width={this.getCountOfWeeks(
month[0].date, month[month.length - 1].date)}
>
{format(new Date(month[0].date), 'MMMM', { locale: ru })}
</MonthLabel>
</MonthBlock>
))}
</Content>
<Content gridArea="XAxis" />
</Layout>
В результате получаем интерфейс, представленный на рисунке 2.3.
Рисунок 2.3 - тепловая карта оценки полноты данных «даты по месяцам»
2. Формат «часы в датах»
Позволяет оценить потери данных в конкретные часы в сутках.
Для данного формата структура данных выглядит почти так же, но добавляется разбиение на даты на часы:
[
[
{
value: 55,
date: '2018-11-29', //выбран период с 2018-11-29
hour: '00:00'
},
{
value: 54, // значение за
date: '2018-11-29', // дату
hour: '01:00' // и час
},
…
{
value: 50,
date: '2018-11-29',
hour: '23:00'
}
],
[ { 2018-11-30 } ],
[ { 2018-12-01 } ] //выбран период по 2018-12-01
]
Результат представлен на рисунке 2.4
Рисунок 2.4 - тепловая карта оценки полноты данных «часы по датам»
«Виджеты»
Инструмент «Виджеты» предназначен для отображения важных актуальных данных с различных устройств. Виджеты - это перетаскиваемые элементы, при этом отображение данных виджета оперативного контроля выполняется поверх всех остальных данных, включение/отключение отображения выполняется нажатием на кнопку в меню.
В результате работы над данным инструментов:
- были улучшены и оптимизированы react-компоненты;
- улучшена общая стабильность WebSocket подписок;
- добавлена возможность добавлять псевдонимы для параметров устройств, которые при этом сохраняются в localstorage браузера;
- исправлено отображение элементов: для отображения и скрытия виджетов в шапке страницы есть специальная кнопка, и теперь ее состояние привязывается к пользователю.
На рисунке 2.5 представлено модальное окно создания/редактирования виджетов. Форма для ввода названия, дерево для выбора устройств, доступные и выбранные параметры и дополнительные настройки.
Рисунок 2.5 - модальное окно создания нового виджета.
При создании нового виджета сработает цепочка функций.функция - сага (из библиотеки Redux). Проследим работу стандартных функций и работу библиотеки Redux на этом примере.
В результате заполнения полей и нажатия на кнопку «Создать» сработает обработчик handleCreateWidgetRequest(params) с выбранными параметрами.
Обработчик вызывает Redux-action CREATE_WIDGET_REQUEST:
export const createWidgetRequest = params => ({
type: CREATE_WIDGET_REQUEST,
params
});
Redux-action вызывает redux-saga:
function* watchCreateWidget() {
yield takeEvery(CREATE_WIDGET_REQUEST, requestCreateWidget);
}
После, функция-сага отправляет запрос на создание виджета и пере- запрашивает список всех виджетов(с только что созданным элементом), а так же обрабатывает ошибки:
export function* requestCreateWidget(action) {
const { params } = action;
try {
const response = yield call(createWidget, params);
const { data } = response;
yield put(createWidgetResponse(fromJS(data)));
yield* requestWidgetsList();
} catch (error) {
const statusCode = error.response.status;
errorsHandling(statusCode, 'action');
yield put(createWidgetFailed(error));
}
}
Функция, для отправки POST - запроса на создание виджета:
export const createWidget = params =>axios.post(
'/sedmax/web/widgets/drag/create', JSON.stringify(params)
);
На рисунке 2.6 представлены созданные виджеты с различными параметрами и с разных устройств.
Рисунок 2.6 - созданный перетаскиваемый виджет
«Мнемосхемы»
Инструмент «Мнемосхемы» имеет важную роль и обширный функционал. На мнемосхемах отражается основное оборудование, сигналы, состояние регулирующих органов.
Мнемосхемы помогают оператору, работающему в условиях большого количества поступающей информации, облегчить процесс информационного поиска, подчинив его определенной логике, диктуемой реальными связями параметров контролируемого объекта. Они облегчают оператору логическую систематизацию и обработку поступающей информации, помогают осуществлению технической диагностики при отклонениях процесса от нормы, обеспечивают внешнюю опору для выработки оптимальных решений и формирования управляющих воздействий.
На рисунке 2.7 представлена тестовая мнемосхема.
На рисунке 2.8 представлены паспорт и диспетчерские метки для объектов тестовой мнемосхемы.
Рисунок 2.7 - просмотр мнемосхем
Рисунок 2.8 - паспорт и диспетчерские метки объекта
«Редактор наборов»
Редактор наборов формирует наборы с выбранными параметрами устройств. Но при этом разные типы устройств поддерживают разные протоколы.
SEDMAX опрашивает устройства по разносторонним протоколам, группирует их и может передать другой системе уже по конкретному, нужному ей протоколу.
То есть редактор наборов позволяет унифицировать получение данных с устройств.
При создании данного модуля, на уровне представления использовались специальные компоненты высшего порядка (Higher order components).
Они позволяют создать единственный компонент, который динамически подстраивается под различные данные (в данном случае - под разные протоколы). То есть позволяет не создавать множество различных компонентов для множества протоколов, что уменьшает дублирование кода и улучшает его читабельность.
На рисунке 2.9 представлен список наборов с возможностью добавления, удаления и изменения его элементов.
Рисунок 2.9 - список наборов
На рисунке 2.10 представлены настройки набора для протокола Modbus.
Рисунок 2.10 - настройка набора
3. АНАЛИЗ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ
3.1 Тестирование
Тестирование - это процесс исследования программного продукта, позволяющий проверить соответствия между реальным поведением программы и ожидаемым поведением. Стоит понимать, что это важнейший этап жизненного цикла программного обеспечения, который позволяет:
- найти программные ошибки
- проверить качество кода
- проверить стойкость работы программы при разных степенях нагрузки
- исследовать связность компонентов программы и взаимодействие с внешними системами
Существует огромное количество видов тестирования, а также эталонная модель тестирования, так называемая «пирамиду тестирования», которая подразумевает использование четырех видов тестов.
На рисунке 3.1 представлена «пирамида тестирования».
Пирамида демонстрирует характеристики тестов: их важность, сложность, скорость и стоимость.
1) Модульное тестирование или Unit testing.
Юнит-тест - это код, который тестирует части кода: отдельные функции, классы и другие модули. Этот тип тестов лежит в основе пирамиды, они простые и легкие для написания. Суть теста в том, чтобы подать на вход функции какие-то данные, и на выходе получить нужный корректный результат. Это дают уверенность, что ваша программа работает как задумано. Такие тесты можно запускать многократно. Успешное выполнение тестов покажет разработчику, что его изменения не сломали ничего, что ломать не планировалось.
Рисунок 3.1 - «пирамида тестирования»
2) Интеграционное тестирование.
Фаза тестирования, при которой отдельные модули объединяются и тестируются в совокупности.
Интеграционное тестирование в качестве входных данных использует модули, над которыми было проведено юнит-тестирование, группирует их в более крупные множества, выполняет тесты, определённые в плане тестирования для этих множеств, и представляет их в качестве выходных данных и входных для последующего системного тестирования.
Интеграционное тестирование проводится после модульного тестирования и предшествует системному тестированию.
3) Системное тестирование.
Системное тестирование программного обеспечения -- это тестирование, выполняемое на полной, интегрированной системе, с целью проверки соответствия системы исходным требованиям. Системное тестирование относится к методам тестирования чёрного ящика, и, тем самым, не требует знаний о внутреннем устройстве системы.
4) Сквозное, End-to-End тестирование
Это тестирование приложения с точки зрения пользователя, и по сути - автоматизация его действий. Это самый затратный и долговременный метод тестирования, но при этом он очень важен, ведь он целиком проверяет работу приложения. Поэтому он находится на вершине пирамиды.
Очень важно понимать, что «пирамида тестирования» - это эталонная идеальная модель. У реальных систем дела обстоят по-другому. И тестирование не должно быть избыточным. Как правило, сам разработчик должен определять, что точно должно быть покрыто тестами, а что не нужно. То есть стопроцентного покрытия тестами быть не должно.
У системы SEDMAX автоматизированное тестирование на данном этапе является не обязательным этапом. Так как архитектура микросервисная, и сейчас находится на этапе модернизации под новые технологии и нужды, системные тесты проводить невозможно.
Поэтому при тестировании новых модулей для SEDMAX, использовалось модульное и сквозное тестирование.
Для End-to-end (сквозного) тестирования WEB-приложений существует много различных фреймворков. Но выбран был CYPRESS, так как по сравнению с аналогами он имеет ряд преимуществ:
- простая установка без лишних зависимостей
- позволяет легко и быстро писать тестовые сценарии
- запуск тестов в реальном времени локально или в CI
- дает возможность записать выполение тестов с отладочной информацией на видео или скриншоты.
- имеет широкий набор инструментов, открытый исходный код и множество дополнительных библиотек (например, будет так же использоваться cypress-testing-library), облегчающих написание тестов.