Разработка модуля подготовки отчетности о состоянии киберфизического объекта "Умный офис"

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

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 28.11.2019
Размер файла 5,8 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

19.Нажатие кнопки «Сохранить».

20. Проверка корректности ввод данных (E2).

21. Сохранения даты и времени.

22. Закрытие всплывающего окна настройки даты и времени.

23. Нажатие на кнопку «Сохранить шаблон».

24. Проверка корректности данных (E3).

15. Сохранение шаблона.

R1: повторять пока шаблон не будет сформирован по нуждам пользователя.

E1: Система выдает сообщение о некорректном вводе электронной почты и предлагает повторный ввод

E2: Система выдает сообщение о некорректном вводе даты или времени и предлагает повторный ввод.

E3: Система выдает сообщение об отсутствии названия шаблона или получателя при указанном времени генерации отчета, и предлагает повторный ввод.

Название: Просмотр журнала операций (табл. 1.6).

Акторы: Пользователь.

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

Таблица 1.6

Просмотр журнала операций

Действия актора

Отклик системы

1. Нажатие кнопки «Просмотр журнала операций» на панели настроек.

2. Открытие всплывающего окна со списком отправленных отчетов.

3. Выбор отчета, информацию о котором необходимо узнать

4. Нажатие кнопки «Посмотреть информацию»

5. Переход на страницу с информацией о выбранном отчете.

6. Просмотр информации

Название: Генерация отчета в заданное время (табл. 1.7).

Акторы: Модуль подготовки отчетности.

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

Таблица 1.7

Генерация отчета в заданное время

Действия актора

Отклик системы

1. Наступление времени генерации отчета.

2. Заполнение шаблона данными

3. Отправка сгенерированного шаблона на почту отправителя.

4. Добавление информации об отправленном отчет в журнал

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

Во второй главе будет описано проектирование модуля подготовки отчетности о состоянии киберфизического объекта Умный офис в целом и конкретно модули создания шаблонов, выбора получателя и непосредственной генерации отчетов.

2.1 Разработка моделей to be бизнес-процессов модуля подготовки отчетности

2.1.1 Разработка модели to be бизнес-процесса «Создание отчета»

Модуль подготовки отчетности должен быть простым в использовании, но в то же время эффективным и производительным. Модуль подготовки отчетности должен быть сфокусирован именно на подготовке отчетных документов, а не визуализации данных. Таким образом алгоритм модуля подготовки отчетности должен работать по алгоритму, представленному на рисунке 2.1. Пользователь выбирает пользовательскую группу (см. рис. 2.2), к которой он относится. Это необходимо для того, чтобы при настройке шаблона и виджетов пользователь мог выбрать умные вещи, принадлежащие пользовательской группе данного пользователя или дочерним группам. Во-первых, это может значительно облегчить поиск необходимой вещи, а во-вторых, у пользователя просто не должно быть необходимости строить отчеты по чужим умным вещам. После выбора группы пользователей открывается страница работы с шаблонами. Здесь необходимо настроить рабочую область (шаблон отчета) под свои нужды, выбрать получателя, дату и время отправления (генерации) отчета. На шаблоне находятся только текстовые поля, графики и таблицы незаполненные данными. Шаблон необходимо сохранить, так он появится в списке созданных шаблонов.

Рисунок 2.1 Модель to be бизнес-процесса «Создание отчета"

Рисунок 2.2 Диаграмма активностей «Выбор пользовательской группы»

2.2 Разработка модели to be бизнес-процесса «Создание шаблона»

2.2.1 Текстовое описание модели to be бизнес-процесса «Создание шаблона»

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

2.2.2 Формальное описание модели to be бизнес-процесса «Создание шаблона»

Модель бизнес-процесса проектирования модуля создания шаблонов в состоянии «как должно быть» представлена в виде диаграммы активностей на рисунке 2.3.

Рисунок 2.6 Диаграмма активностей «Создание шаблона»

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

Рисунок 2.4 Диаграмма активностей «Изменение шаблона»

Рисунок 2.5 Диаграмма активностей «Удаление шаблона»

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

Рисунок 2.6 Диаграмма активностей «Выбор виджетов»

Рисунок 2.7 Диаграмма активностей «Настройка каждого виджета»

2.3 Разработка модели to be бизнес-процесса «Выбор получателя»

2.3.1 Анализ модели to be бизнес-процесса «Выбор получателя»

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

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

Рисунок 2.8 Диаграмма активностей «Выбор получателя»

2.4 Разработка модели to be бизнес-процесса «Генерация отчета»

2.4.1 Текстовое описание модели to be бизнес-процесса «Генерация отчета»

Отчет генерируется по наступлению заданной даты и времени генерации отчета, следовательно дата и время должны быть установлены заранее, а именно в любой момент создания или внесения изменений в шаблон. Нажатием на соответствующую кнопку необходимо установить дату и время генерации отчета, а также при необходимости указать периодичность повтора. Генерация отчета заключается в том, что при наступлении момента создания отчета происходит заполнение макета (шаблона) данными. Заполненный шаблон отправляется на почту получателю. Информация об отправленном отчете сохраняется в журнале операций.

2.4.2 Формальное описание модели to be бизнес-процесса «Генерация отчета»

Модель бизнес-процесса проектирования модуля генерации отчета в состоянии «как должно быть» представлена в виде диаграммы активностей на рисунке 2.9.

Рисунок 2.9 Диаграмма активностей «Генерация отчета в заданное время»

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

Рисунок 2.10 Диаграмма активностей «Настройка даты и времени генерации отчета»

Рисунок 2.11 Диаграмма активностей «Настройка возможности повторной генерации отчета»

Модель составляющей бизнес-процесса проектирования модуля генерации отчета («Просмотр журнала операций») в состоянии «как должно быть» представлена в виде диаграмм активностей на рисунке 2.12.

Рисунок 2.12 Диаграмма активностей «Просмотр журнала операций»

2.5 Используемые технологии

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

Таблица 2.1

Обоснование выбора используемых технологий

Область использования

Технология

Обоснование выбора

Проектирование

UML

Опыт работы, простота понимания.

Язык программирования

C#

Опыт работы

Среда разработки

MS VisualStudio

Опыт работы, язык программирования

Программная архитектура

MVC

Опыт работы, система «Менеджер сценариев»

Язык разметки

HTML5

Опыт работы, популярность.

Обеспечение интерактивности веб-страниц

JavaScript, JQuery

Популярность.

Реляционная БД

MS SQL

Опыт работы, простая интеграция с MS Visual Studio

БД временных рядов

InfluxDB

Требование заказчика

Подход к реализации реляционной БД

Code first

Система «Менеджер сценариев»

Хранение и передача данных внутри модуля

JSON

Популярность.

Формат отчета

.pdf

Требование заказчика

Система «Менеджер сценариев». Так как модуль подготовки отчетности является прототипом, который в последующем будет внедрен в систему, заказчиком была предложена уже реализованная система, которая будет предоставлять данные для модуля подготовки отчетности.

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

Система «Менеджер сценариев» была написана на языке программирования C#, а база данных была реализована подходом Code First. Это означает, что до того, как начать реализацию модуля подготовки отчетности необходимо разобраться со структурой базы данных и подключить ее к реализуемому модулю.

UML - Unified Modeling Language - унифицированный язык графического описания. UML предназначен для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

В UML используются следующие виды диаграмм:

7. Структурные:

· Диаграмма классов.

· Диаграмма компонентов.

· Диаграмма композитной/составной структуры.

· Диаграмма кооперации.

· Диаграмма развёртывания.

· Диаграмма объектов.

· Диаграмма пакетов.

· Диаграмма профилей.

8. Поведенческие:

· Диаграмма деятельности.

· Диаграмма состояний.

· Диаграмма вариантов использования.

· Диаграммы взаимодействия:

o Диаграмма коммуникации.

o Диаграмма обзора взаимодействия.

o Диаграмма последовательности.

o Диаграмма синхронизации.

Основные достоинства языка UML:

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

2. Диаграммы просты для понимания неподготовленным пользователям.

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

C# - объектно-ориентированный язык программирования, выпущенный в 2000 году компанией Microsoft. Прародителями языка C# являются C++ и Java. От Java C# унаследовал основную часть синтаксиса, единственность наследования, а также динамическую загрузку кода при выполнении программы и строгую типизацию. C++ передал C# перегруженные операторы, арифметические операции с плавающей точкой, а также некоторые особенности синтаксиса.

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

Таким образом язык программирования C# имеет следующие преимущества:

· Объектно-ориентированность.

· Компонентно-ориентированный подход к программированию.

· Невысокая машинно-архитектурная зависимость программного кода.

· Гибкость.

· Легкость повторного использования программных компонентов.

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

Microsoft Visual Studio - один из самых известных продуктов Microsoft, который позволяет разрабатывать код на языке C# и является интегрированной средой разработки программных продуктов. Разметка страницы позволяет просто ориентироваться в коде программы, специальные оповещения позволяют быстро найти и исправить популярны ошибки выбрав один из предложенных вариантов решения проблемы, присутствует возможность рефакторинга кода, а также множество решений для тестирования написанного кода.

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

Преимуществами такого подхода к проектированию можно считать:

· Единую концепцию системы.

· Так как компоненты являются независимыми, система будет легко расширяемой.

· Возможность вывода одних данных в различных видах.

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

HTML5 (Hyper Text Markup Language) - язык для структурирования и представления содержимого на веб-страницах. Позволяет взаимодействовать веб-страницам в разных браузерах, расширяет возможности веб-страниц, не нарушая работы существующих. Достоинствами HTML считаются скорость загрузки сайтов, экономия трафика на хостинге и возможность постоянного контроля над сайтом создателем. К недостаткам относятся фиксированный набор тегов и отсутствие информации о значении содержания, заключенного в тегах.

JavaScript - мультипарадигменный язык программирования, который позволяет сделать веб-страницу интерактивной. Изначально имел название LiveScript, но был переименован в JavaScript для получения большей популярности, однако с языком Java никак не связан. JavaScript не требует предварительной обработки и интерпретируется браузером во время загрузки веб-страницы. Данный язык может работать совместно с другими языками программирования. К недостаткам можно отнести разную интерпретацию веб-страниц для разных браузеров.

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

MS SQL - система управления реляционными базами данных. SQL сервер предназначен для хранения баз данных и обеспечения доступа к базам данных из других систем. SQL сервер поддерживает язык XML и протокол HTTP, средства повышения быстродействия и доступности, которые позволяют распределить нагрузку для бесперебойной работы системы. SQL сервер позволяет создавать резервные копии без отключения пользователей, это позволяет хранить и работать с базами данных, занимающими большой объем памяти.

InfluxDB - база данных для хранения временных рядов от InfluxData. InfluxDB разработан специально для временных данных, в том числе для хранения данных датчиков Интернета вещей, и аналитики в реальном времени. InfluxDB написан на языке программирования Go, а также не имеет внешних зависимостей. Основными преимуществами базы данных InfluxDB являются:

· Sql подобный язык запросов, который позволяет быстро научиться писать запросы агрегированных данных.

· Простые и высокопроизводительные API записи и запросы HTTP.

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

· Возможность хранить миллиарды измерений.

· Возможность работы в кластерном режиме.

· Наличие клиентских библиотек для большого количества языков программирования.

JSON - текстовый формат обмена данными. Основан на JavaScript и используется при передаче объекта с сервера клиенту в качестве промежуточного формата. Главным плюсом данного формата является его простота и понятность неподготовленному пользователю.

Формат.pdf - межплатформенный формат электронных документов. Изначально данный формат разработала фирма Adobe Systems и предоставила пользователям ряд возможностей языка PostScript. Прежде всего формат.pdf предназначен для предоставления полиграфической продукции в электронном виде.

К плюсам использования формата файлов.pdf можно отнести:

· Открывается на любых устройствах с любыми операционными системами.

· Множество программ для просмотра файлов формата.pdf.

· Большинство современного печатного оборудования имеет аппаратную поддержку данного формата.

· При открытии на любом устройстве документ выглядит одинаково.

· Возможность настройки параметров безопасности.

2.6 Инфологическая модель базы данных

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

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

Общий список информационных сущностей и их атрибутов представлен в таблице 2.2.

Таблица 2.2

Инфологическая модель базы данных

Сущность

Атрибуты

Администратор

Логин

Пароль

ФИО

Является ли главным администратором

Контроллер

Идентификатор

Пароль

Название

Описание

Тип

Адрес

Номер пользовательской группы

Сценарий

Идентификатор

Название

Описание

Скрипт

Автор

Является ли опубликованным

Тип

Номер пользовательской группы

Пользовательская группа

Идентификатор

Название

Номер родительской пользовательской группы

Описание

Датчик

Идентификатор

Название

Описание

Тип

Номер контроллера

Номер пользовательской группы

Умная вещь

Идентификатор

Название

Описание

Тип

Номер контроллера

Номер пользовательской группы

Пользователь

Логин

Пароль

Тип пользователя

Информация

ФИО

Номер пользовательской группы

Шаблон отчета

Идентификатор

Название

Дата

Время

Номер пользовательской группы

Получатель

Виджет

Идентификатор

Название

Координата X

Координата Y

Длина

Ширина

Дата начала

Дата окончания

Номер контроллера

Номер шаблона

Все сущности в таблице 2.2. уже были реализованы в рамках другого проекта, за исключением сущностей «Шаблон отчета» и «Виджет». Данные сущности будут реализованы в рамках разработки модуля подготовки отчетности.

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

2.7 Даталогическая модель базы данных

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

Также по инфологической модели видно, что работу системой осуществляют пользователи и администраторы. Пользователи в свою очередь делятся на интеграторов и обычных пользователей. Администратор занимается администрированием системы и чисткой данных. Только администратору доступен список приватных сценариев пользователей. Это необходимо для проверки адекватности сценариев пользователей. Интегратор отвечает за датчики, контроллеры и умные вещи, а также распределяет пользователей своей пользовательской группы по дочерним группам. Обычный пользователь пользуется системой, то есть умные вещи в его помещении управляются сценариями

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

В таблице 2.3 в общем виде представлено описание всех таблиц, атрибутов и типов атрибутов, хранящихся в базе данных

Таблица 2.3

Даталогическая модель базы данных

Сущность

Атрибуты

Тип данных

Администратор

Логин

Строка

Пароль

Строка

ФИО

Строка

Является ли главным администратором

Логический

Контроллер

Идентификатор

64-разрядное целое число

Пароль

Строка

Название

Строка

Описание

Строка

Тип

Целое число

Адрес

Строка

Номер пользовательской группы

64-разрядное целое число

Сценарий

Идентификатор

64-разрядное целое число

Название

Строка

Описание

Строка

Скрипт

Строка

Автор

Строка

Является ли опубликованным

Логический

Тип

Целое число

Номер пользовательской группы

64-разрядное целое число

Пользовательская группа

Идентификатор

64-разрядное целое число

Название

Строка

Номер родительской пользовательской группы

64-разрядное целое число

Описание

Строка

Сущность

Атрибуты

Тип данных

Датчик

Идентификатор

64-разрядное целое число

Название

Строка

Описание

Строка

Тип

Целое число

Номер контроллера

64-разрядное целое число

Номер пользовательской группы

64-разрядное целое число

Умная вещь

Идентификатор

64-разрядное целое число

Название

Строка

Описание

Строка

Тип

Целое число

Номер контроллера

64-разрядное целое число

Номер пользовательской группы

64-разрядное целое число

Пользователь

Логин

Строка

Пароль

Строка

Тип пользователя

Целое число

Информация

Строка

ФИО

Строка

Номер пользовательской группы

64-разрядное целое число

Шаблон отчета

Идентификатор

64-разрядное целое число

Название

Строка

Дата

Дата

Время

Время

Номер пользовательской группы

64-разрядное целое число

Получатель

Строка

Виджет

Идентификатор

64-разрядное целое число

Название

Строка

Координата X

64-разрядное целое число

Координата Y

64-разрядное целое число

Длина

64-разрядное целое число

Ширина

64-разрядное целое число

Дата начала

Дата

Дата окончания

Дата

Номер контроллера

64-разрядное целое число

Номер шаблона

64-разрядное целое число

Графическое представление даталогической модели представлено в виде диаграммы классов на рисунке 2.13.

Рисунок 2.13 Диаграмма классов

2.7 Диаграмма компонентов модуля подготовки отчетности

Для формирования представления об архитектуре модуля подготовки отчетности была реализована диаграмма компонентов (см. рис 2.14). Н диаграмме компонентов видно, что модуль подготовки отчетности получает данные из системы «Менеджер сценариев». Причем данные с датчиков хранятся в базе данных временных рядов InfluxDB, а данные о системе в базе данных MS SQL. Под данными о системе понимаются данные о пользовательских группах, зарегистрированных в системе, о существующих в системе датчиках, контроллерах и умных вещах. Помимо этого, в БД MS SQL хранятся данные о пользователях, администраторах и сценариях, но они не влияют на работу модуля подготовки отчетности.

Рисунок 2.14 Диаграмма компонентов модуля подготовки отчетности

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

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

3.1 Интеграция модуля с системой «Менеджер сценариев»

Для интеграции модуля подготовки отчетности с системой «Менеджер сценариев» необходимо подключиться к базе данных системы. В системе «Менеджер сценариев» в качестве базы данных была выбрана PostgreSQL и подход к реализации code first.

3.1.1 Создание модели

В среде MS Visual Studio в проекте модуля подготовки отчетности с помощью диспетчера пакетов NuGet был добавлен пакет EntityFramwork6.2.0 (рис. 3.1). Данный пакет позволяет создать класс, производный от DBContext.

Рисунок 3.1 Пакет EntityFramwork6.2.0

Для создания модели необходимо добавить в проект элемент “ADO.NET EDM”, а в качестве выбора содержимого модели указать «Пустая модель Code First». Таким образом автоматически сгенерируется класс производный от DBContext. В конструкторе класса указывается строка подключения (рис. 3.2).

Рисунок 3.2 Конструктор класса, производного от DBContext

Для определения сущностей были созданы свойства DBSet<T> по одному для каждой сущности (см. рис. 3.3). То есть данное свойство эквивалентно таблице в физической базе данных.

Рисунок 3.3 Определение сущностей

Для описания сущностей был созданы классы для каждой сущности, с указанием необходимых атрибутов (рис 3.4).

Рисунок 3.4 Описание сущности

Для создания связей между сущностями был использован переопределяемый метод «OnModelCreating» (рис.3.5).

Рисунок 3.5 Создание связи между сущностями

3.1.2 Строка подключения

После создания DBContext класса в конфигурационном файле web.config создается раздел “ConnectionString” в котором и необходимо прописать строку подключения (рис. 3.6).

Рисунок 3.6 Строка подключения БД

3.1.3 Миграции

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

9. enable-migrations

В результате выполнения в проекте появилась папка “Migrtions” и да файла: конфигурации и начальной миграции.

10. add-migration "Название миграции"

В результате в папку буде добавлена новая миграция. В миграции определены два метода UP() и DOWN() (см. рис. 3.7). UP отвечает за добавление, а DOWN за удаление

Рисунок 3.7 Созданная миграция

11. update-database

В результате выполнения данной команды выполняется миграция

Теперь созданная база подключена и готова к работе.

3.2 Работа с БД временных рядов

3.2.1 Развертывание БД временных рядов

На официальном сайте “Influx” можно найти информацию по установке InluxDB, а также ссылку на скачивание. Была выбрана версия для операционной системы Windows x64.

Для развертывания “InfluxDB” нет установочного файла.exe, необходимого разархивировать скачанный архив, а файлов, находящихся в архиве, будет достаточно для корректной работы СУБД. Для запуска сервера СУБД необходимо запустить приложение «Influxd.exe», после откроется консоль, представленная на рисунке 3.10. InfluxDB готова к работе. Для осуществления работы через консоль необходимо открыть приложение «Influx.exe».

3.2.2 Создание и работа с базой данных

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

Для создания базы данных необходимо запустить InfluxDB и открыть консоль для работы с приложением. В консоли необходимо написать следующую строку: «Create database test», где test - это название базы данных.

Возможность подключиться к InfluxDB через Visual Studio напрямую нет, поэтому необходимо открыть диспетчер пакетов NuGet и добавить пакет «InfluxDB.LineProtocol». Данная библиотека позволяет записывать метрики на языке C# в InfluxDB. На рисунке 3.8. показан метод добавления записей в базу данных, где «value» - это случайное число, «dt» - дата и время записи показания, «tableName» - название таблицы, а «TextBox» - поле для вывода ошибки, host - имя устройства, с которого происходит запись).

Рисунок 3.8 Метод добавления записей в БД

После того как база заполнена данными, их необходимо использовать. Для использования данных хранящихся в InfluxDB необходимо подключить библиотеку «InfluxData.Net» в диспетчере пакетов NuGet. Данная библиотека предоставляет доступ к REST API базы данных InfluxDB. На рисунке 3.17. изображен метод извлечения записей из базы данных, где «tableName» - название таблицы, а «tb» - поле вывода.

Рисунок 3.9 Метод извлечения данных из БД

3.3 Реализация модуля подготовки отчётности

3.3.1 Проект MVC

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

После создания модели были реализованы блоки Controller и View. Сначала было создано два контроллера. Для каждого контроллера были созданы представления. Каждое представление соответствует одному из ActionLink в контроллере. В первом контроллере был создан всего один ActionLink и одно представление, отвечающие за выбор пользовательской группы - Index. Второй контроллер отвечает за страницу создания шаблона и имеет представление WorkPanel.

В представлении WorkPanel помимо обычной разметки используются стили и дополнительно подключенные библиотеки JavaScript. Стили хранятся в файле с расширением.css, и подключаются с помощью тега <link>, а библиотеки хранятся в файле с расширением.js. и подключаются с помощью <script>. В файле с определением стилей заданы параметры отображения тегов на экране. С помощью файла с подключенными библиотеками JavaScript задается интерактивность страницы.

3.3.2 Drag&Drop

Наличие Drag&Drop означает наличие возможности перетаскивать элементы на экране с помощью мыши. Возможность перетаскивать элементы на экране позволяет библиотека JQuery. Для перетаскивания элементов из панели настройки шаблона был реализован метод draggable со свойством Helper:”clone”. Это позволяет не просто перетащить изображение виджета, а создать копию данного элемента и перемещать ее. В данном проекте необходимо, чтобы виджеты перемещались только по рабочей области, для этого изначально задается метод droppable для элемента рабочей области. Это означает, что действия будут происходить после того, как пользовать опустит перетаскиваемый элемент в указанную область.

Для изменения размера виджетов также используется библиотека JQuery и метод resizemove. То есть, когда пользователь тянет за какой-либо из краев иконки виджета, она изменяется в размере.

3.3.3 JSON

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

JSON объект для шаблона является массивом объектов, где каждый объект представляет из себя идентификатор, название, электронную почту, дату и время:

report = [{

id": 0,

"name": "",

"mail": "",

"date": "",

"time":""

}];

JSON объект для виджета также является массивом объектов, однако здесь для каждого объекта должны быть определены идентификатор, название, координату X, координату Y, длину, ширину, дату начала отсчета, дату окончания и номер контроллера:

widget = [{

"id": "",

"name": "",

"X": "",

"Y": "",

"Width": "",

"Height": "",

"startDate": "",

"endDate": "",

"controller": ""

}];

Таким образом при каждом изменении какого-либо из параметров происходит запись или перезапись объектов JSON. После внесения всех необходимых изменений и нажатия на кнопку «Сохранить». Данные из представления передаются в контроллер в формате объекта JSON, преобразуются, а потом из контроллера происходит вызов метода для сохранения данных в реляционную базу данных.

3.3.4 Формирование файла в формате.pdf

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

pdfDocument myDoc = new pdfDocument(ReportName, "Me", false);//создание файла

pdfPage myFirstPage = myDoc.addPage(); //создание страницы

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

pdfTable myTable = new pdfTable(); //создание таблицы

myTable.tableHeader.addColumn(new pdfTableColumn("id", predefinedAlignment.csRight, 50)); //добавление заголовков

pdfTableRow myRow = myTable.createRow(); //добавление строки

myRow[0].columnValue = k.ToString();заполнение строки данными для первого столбца

Условиями корректной работы являются:

12. Весь текст в файле должен быть на английском языке.

13. Заголовком первого столбца должно быть “id”.

3.3.5 Отправка отчет на электронную почту

Для отправки отчета на почту необходимо было создать электронную почту, с которой бы уходили письма для получателя. Была создана почта на mail.ru (логин: reportpreparation, пароль: HsePerm2015). Для отправки письма сначала необходимо подключить в проект пространство имен System.Net.Mail, а затем создать новый экземпляр класса SmtpClient. Именно с помощью протокола SMTP (Simple Mail Transfer Protocol) появилась возможность отправить письмо на электронную почту из приложения.

SmtpClient client = new SmtpClient("smtp.mail.ru", 25);

Далее необходимо задать учетные данные, сообщение и вложение:

client.Credentials = new NetworkCredential("reportpreparation@mail.ru", "HsePerm2015");//Задание учетных данных

MailMessage message = new MailMessage(from, to, subject, text); //создание сообщения

Attachment file = new Attachment(attach);//создание вложения

message.Attachments.Add(file);//добавление вложения в сообщение

Далее остается только отправить сообщение на электронную почту:

client.Send(message); //отправка сообщения

3.6 Интерфейс

3.6.1 Выбор пользовательской группы

При запуске модуля подготовки отчетности пользователь попадает на страницу выбора пользовательской группы (рис. 3.10). Это необходимо для того, чтобы при построении дальнейших отчетов для выбора были доступны только те контроллеры, которые находятся в пользовательской группе пользователя. На экране представлен выпадающий список со всеми пользовательскими группами. После выбора группы необходимо нажать на кнопку «Выбрать».

Рисунок 3.10 Выбор пользовательской группы

3.3.2 Рабочая область

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

Рисунок 3.11 Страница создания шаблона

Для отображения списка виджетов необходимо навести мышью на элемент «Виджеты» в панели настроек шаблона (рис. 3.12).

Рисунок 3.12 Список виджетов

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

Рисунок 3.13 Страница создания шаблона с отображением панели настройки виджетов

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

3.3.3 Сохранение файла в формате.pdf

Для сохранения файла в формате.pdf необходимо выбрать место сохранения отчета на компьютере и указать название. После выбора места сохранения происходит заполнение шаблона данными и сохранение созданного файла. В отчете будут отображены выбранные виджеты в выбранных местах, но уже заполненные данными. На рисунке 3.14 представлен пример отчета, в котором выбран виджет «Таблица», контроллер - 8, начальная дата - 20.05.2019 и конечная дата - 21.05.2019.

Рисунок 3.14 Пример сформированного отчета в формате.pdf

3.3.4 Отправка отчета на электронную почту

Отправка сообщения с отчетом происходит при указании пользователем электронной почты в окне создания шаблона. На указанную электронную почту приходит письмо (рис. 3.15) от reportpreparation@mail.ru. Темой письма является слово «Отчет» и название отчета. В тексте письма сказано, что отчет находится во вложении.

Рисунок 3.15 Входящее сообщение с отчетом во вложении

Заключение

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

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

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

15. Произведен анализ бизнес-процессов, а именно на пример системы ThingsBoard составлены диаграммы активностей в состоянии «как есть» для бизнес-процессов.

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

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

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

19. Модуль протестирован, а именно составлены тесты по технологии «черного ящика», после чего тесты были запущены, а выявленные ошибки исправлены.

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

Список сокращений и условных обозначений

КФС - киберфизическая система

КФО - киберфизический объект

Дашборд -панель, для визуального представления данных

Виджет - визуальный элемент на дашборде, отображающий необходимую инфромацию

Библиографический список

1. J. Manuka, M. Chui, J. Bughin, R. Dobbs, P. Bisson and A.Marrs, “Disruptive technologies: Advances that will transform life, business, and the global economy,” McKinsey Global Institute, May 2013.

2. Викентьева О.Л., Дерябин А.И., Шестакова Л.В., Кычкин А.В. Синтез информационной системы управления подсистемами технического обеспечения интеллектуальных зданий // Вестник МГСУ. 2017. Т. 12. Вып. 10 (109). С. 1191-1201.

3. C.-S. Shih, J.-J. Chou, N. Reijers and T.-W. Kuo, “Designing CPS/IoT applications for smart buildings and cities,” IET Cyber-Physical Systems: Theory & Applications, vol. 1, pp. 3-12, October 2016.

4. В. Дробот, “Перспективы развития киберфизических производственных систем,” Control Engineering Россия, vol. 5, 2018.

5. D. Ratasich, F. Khalid, F. Geissler, R. Grosu, M. Shafique and E. Bartocci, “A roadmap toward the resilient Internet of Things for Cyber-Physical Systems,” IEEE Access, vol. 7, pp. 13260-13283, January 2019.

6. J. Liu, H. Zhou, X. Liu, G. Tian, M. Wu and W. Wang, “Dynamic evaluation method of machining process planning based on digital twin,” IEEE Access, vol. 7, pp. 19312-19323, January 2019.

7. Киберфизические системы и разумные города [Электронный ресурс]//IBM: [сайт]. URL: https://www.ibm.com/developerworks/ru/library/ba-cyber-physical-systems-and-smart-cities-iot/ (дата обращения: 15.03.2019)

8. Н. Уткин, «Значение стандартизации киберфизических систем для экономики России,» Главный метролог, 2017.

9. Отчет [Электронный ресурс]//Академик: [сайт]. URL: https://dic.academic.ru/dic.nsf/mas/41234/отчёт (дата обращения: 10.03.2019)

10. X.Yu and Y. Xue, " Smart Grids: A Cyber-Physical Systems Perspective," Proceedings of the IEEE, vol. 104, pp. 1058 - 1070, March 2016.

11. J. Liu, T. Tang, W. Wang, B. Xu, X. Kong and F. Xia, " A Survey of Scholarly Data Visualization," IEEE Access, vol. 6, pp. 19205 - 19221, March 2018.

12. ГОСТ Р 55710-2013 Освещение рабочих мест внутри зданий. Нормы и методы измерений.

13. B. Zhao, H. Lu, S. Chen, J. Liu and D. Wu, “Convolutional neural networks for time series classification,” Journal of Systems Engineering and Electronics, vol. 28, pp. 162-169, March 2017.

Размещено на Allbest.ru

...

Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.