Разработка системной архитектуры киберфизической системы "Умный офис"

Рисунок 1.9 Группа прецедентов корректировки



Как можно было заметить из общей диаграммы Use Case, в перечисленных прецедентах присутствует как «Настройка оборудования», так и «Корректировка работы сценариев системы». Несмотря на то, что прецеденты являются реализацией одного механизма: настройка работы системы, разница между ними обусловлена тем, что настройка подразумевает под собой отсутствие существующих конфигураций и значений системы, в то время как корректировка работы сценариев системы реализует лишь корректировку значений, уже прошедших через один и более циклов PDCA.

Список функциональных требований

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

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

Атрибуты качества

В рамках настоящей работе, основными характеристиками качества киберфизической системы являются:

· Функциональность (способность системы решать поставленные задачи в рамках, очерченных границами проекта) с метриками:

o Отношение успешно решаемых системой задач к числу поставленных;

o Отношение точности измерений датчиков и расчетов системы к желаемым;

o Степень соответствия стандартам и законодательным актам;

· Надежность;

o Частота отказов системы;

o Степень соответствие стандартам надежности информационных систем;

· Удобство использования и сопровождения;

o Время, затрачиваемое пользователем на освоение функциональных возможностей системы;

o Объем усилий (временных затрат), затрачиваемое на работу в программе;

o Величина отклонений от среднего значения стабильной, штатной работы приложения;

o Время, затрачиваемое пользователем на внесение изменений в данные системы;

· Переносимость;

o Объемы трудозатрат, затрачиваемых на интеграции с другими системами и сервисами;

· Производительность:

o Отношение реальных показателей скорости и объема передачи данных к ожидаемым;



2.4 Выводы по главе разработки требований

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

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



3. Проектирование системной архитектуры

3.2 Выбор концепций для проектирования системы

Место микросервисов в системе

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

Обозначенная концепция имеет ряд недостатков, таких как:

1. Потребность в устойчивом и достаточном (по пропускной способности) подключении к сети Интернет;

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

3. Необходимость установки форматов обмена данными для каждой пары взаимодействующих микросервисов;

4. При недостаточности предварительного проектирования: осложнение тестирования и отладки при разработке.

Наряду с недостатками присутствуют и преимущества:

1. Возможность относительно легкой замены модуля в любой момент времени;

2. Модульность позволяет реализовывать микросервисы с использованием различных:

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

b. Фреймворков;

c. Связующего программного обеспечения;

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

4. Простота обновления и развертывания каждого из микросервисов вследствие небольшого «объема и веса»;

5. Наиболее прозрачная и модульная организация приложения за счет концентрации на основных функциях приложения. Как следствие: микросервис, как правило, выполняет единственную, атомарную функцию;

6. Простота иерархии взаимодействия сервисов (как правило, они находятся на одном уровне); однако, возможны и исключения.

Наиболее популярной средой для осуществления обозначенной архитектуры является система управления приложениями, такая как Kubernetes и ее надстройки:

· OpenShift;

· CloudFoundry;

· Docker Swarm;

· Apache Mesos и т.д.

Актуальность применения элементов микросервисной архитектуры относительно разрабатываемой системы обусловлена потребностью платформы в модульности. Т.к. высокую вероятность имеет наличие факта различных целей предприятий касательно офисных пространств, несмотря их на однородные цели и задачи. Таким образом, модульность платформы КФС «Умный офис» должна выражаться как в гибкости функциональности, так и в разрезе подключаемых датчиков и устройств. Последнее обозначенное требование подразумевает потенциальное наличие модуля / сервиса-коннектора устройств-датчиков и устройств-исполнителей не только друг с другом, но и с ядром управления киберфизической системы.

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

Реляционные базы данных

В соответствии с современными требованиями по разработке микросервисов, в каждом из модулей, реализующих определенный функционал, присутствует отдельная база данных. Одним из наиболее распространенных видов хранилищ является реляционная база данных [37]. В рамках настоящей работы под реляционной БД понимается хранилище данных, основанное на реляционной модели данных. С основными принципами реляционной модели и их формулировками можно ознакомиться в статье «A Relational Model of Data for Large Shared Data Banks» вышедшей в 1969--1970 годах под авторством Э.Ф. Коддом. В настоящее время обозначенный труд признан «классикой».

Несмотря на широкое применение и многолетний опыт использования реляционных БД, настоящая концепция обладает рядом недостатков:

1. Представление в «табличном» виде накладывает существенное ограничение на возможности представления предметной области;

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

3. Относительно большое количество памяти, занимаемой обозначенным видом БД;

4. Относительно низкая скорость доступа к данным;

5. Высокая степень возрастания сложности работы и оптимизации работы реляционной БД при потребности распределения данных между большим количеством серверов;

В свою очередь, обозначенное хранилище данных обладает рядом преимуществ:

1. Условная универсальность и наиболее широкая распространенность;

2. Простота и доступность восприятия вследствие одной используемой для построения конструкции: «Таблицы»;

3. Наличие строгих правил проектирования, основывающихся на математическом аппарате;

4. Независимость структуры и целостности данных от их практического применения в ПО;

5. Простота организации запросов и написания прикладного ПО;

6. Наличие широкого набор инструментов для работы.

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

Документоориентированные системы управления базами данных

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

В настоящее время документоориентированные БД представляются более сложной версией хранилищ типа “ключ-значение”. Такие хранилища имеют возможность работы с системами, подразумевающими множество связей между элементами и позволяют осуществлять выборку по запросу без полной загрузки отдельных документов в оперативную память. Поисковые механизмы таких СУБД позволяют находить как документы целиком, так и их отдельные части. В свою очередь, древовидная структура позволяет организовывать отдельные коллекции документов одного типа или схожей тематики. Примерами программных средств, представленных на рынке СУБД являются такие продукты как: CouchDB, Couchbase, MarkLogic, MongoDB, eXist и пр.

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

Базы данных с временными рядами

Также, в рамках настоящей работы предполагается, что данные, поступающие с устройств-датчиков киберфизической системы будут храниться в TSDB (Time Series database). Обозначенное решение обусловлено потенциальным возникновением проблем при количестве записей, поступающих в систему с датчиков физического окружения офисного пространства (примерное кол-во датчиков измеряется десятком на одно комнатное помещение; предполагается, что таких помещений не одно).

На основании соответствующих исследований, может быть сделан вывод о том, что информация, хранимая в традиционной, реляционной SQL СУБД склонна занимать больший объем памяти, чем в инструментах, разрабатывающихся специально для решения подобных задач. Краткий список наиболее популярных решений приведен в таблице ниже (с указанием языка, который поддерживает решение).

Таблица 3.1

Решения в области Time Series DB

Название решения	Язык
Cube	JavaScript
DalmatinerDB	Erlang
Druid	Java
eXtremeDB	SQL, Python, C / C++, Java, and C#
InfluxDB	Go
Informix TimeSeries	C / C++
IRONdb	C / C++
KairosDB	Java
Kx kdb+	Q
OpenTSDB	Java
Prometheus	Go
Riak-TS	Erlang
RRDtool	C
TimescaleDB	C
Whisper (Graphite)	Python

Брокер сообщений

Однако, при наличии различных источников информации, поступающей в систему, необходим инструмент унификации входных данных. В настоящее время проверенной практикой является применение «брокера сообщений» системы - посредника, регламентирующего передачу информации между отправителем и получателем внутри системы. Таким образом, «брокер» - это высоконагруженная система, распределяющая данные по хранилищам-адресатам, снижая общий объем нагрузки на систему.

В рамках настоящей работы «брокер сообщений» является условной абстракцией, исполняющей основные функциональные возможности обозначенного класса решений. Из чего следует вывод о том, что в процессе разработки обозначенная «абстракция» может быть заменена либо на тестовый генератор данных (в случае отсутствия реальных датчиков физического окружения), либо же на реально существующее решение-брокер (к примеру, Rabbit MQ или Mosquito MQTT).

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

АРМ и принципы построения модулей системы

В рамках настоящей работы проектирование архитектуры, как целой системы, так и отдельных модулей опирается на стадии планирования ранее обозначенного цикла PDCA, которые реализует пользователь при взаимодействии с системой посредством АРМ (автоматизированного рабочего места). Таким образом, наполнение условного модуля зависит от состава работ, производимых внутри определенной стадии цикла. Доступ пользователей к функциям системы описан в соответствующей таблице А.1. Также в приложении А (рисунок А.2.) представлен переработанный вариант диаграммы вариантов использования, в котором анализ показателей системы является продолжением мониторинга и условно может быть включен в этап проверки.

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

3.3 Построение архитектуры системы

Хранимая информация системы

На основании групп прецедентов диаграммы Use Case может быть сформирован первичный список областей предполагаемой информации, предполагаемой к хранению в базах данных разрабатываемой системы. Таким образом, для группы <пункт списка> актуально хранение данных о <подпункт списка>:

1. Планирования политики (с подгруппами):

a. Определении показателей системы (Заметка: настоящие данные предполагаются статичными (не имеющими форму временных рядов):

Формулах расчета;

Единицах измерения;

Названиях (справочных);

Методах анализа;

b. Работы с цифровым двойником:

Онтологии офисного пространства;

Цифровых схем и чертежей;

Физ. и мат. моделях окружения;

Сценариях работы системы;

c. Определения политики предприятия:

Целях и задачах системы;

Основных положениях политики;

Стоимости проведения политики:

1. Шаблонах формирования отчетности;

2. Методах анализа несоответствий;

2. Реализации политики:

a. Произведенных закупках оборудования и приобретенных услугах;

b. Формальных документах, регламентирующих работу системы;

c. Отчетах о работе системы;

d. Настройках параметров оборудования;

3. Проверки эффективности политики:

a. Мониторинге показателей системы;

b. Результатах анализа выявленных несоответствий;

c. Наилучших конфигурациях работы системы;

d. Анализе показателей работы системы;

4. Корректирующих мероприятий:

a. Документах с рекомендациями по улучшению работы системы (на основании интеллектуального анализа);

b. Документах с предложениями по улучшению работы системы (поступают от работников);

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

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

В свою очередь, в системе присутствуют области данных, которые могут быть использованы сразу в нескольких группах прецедентов. Наглядным примером такой области является информация о целях и задачах системы, которая применяется как в прецеденте «план-факт анализа» группы «проверки», так и в прецедентах «Определение значений показателей» и «Определение целей и задачи системы». Таким образом, нормальные значения для анализа могут быть импортированы из подгрупп «определения показателей» и «определения политики» группы «планирования». Аналогичным образом, информацию для прецедентов анализа показателей представляется возможным как хранить в отдельной области анализа, так и импортировать из области создания из цифрового двойника киберфизической системы.

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

Хранилища системы

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

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

1. Документоориентированная БД для хранения информации о:

a. Произведенных закупках оборудования и приобретенных услугах;

b. Нормативных документах, регламентирующих работу системы;

c. Отчетах о работе системы;

d. Целях и задачах системы;

e. Стоимости проведения политики;

f. Шаблонах формирования отчетности;

g. Описании методов анализа несоответствий;

h. Документах с рекомендациями по улучшению работы системы (на основании анализа);

Документах с предложениями по улучшению работы системы (поступают от работников);

2. Документоориентированной БД для хранения информации о:

a. Онтологии офисного пространства;

b. Цифровых схем и чертежей;

c. Физ. и мат. моделях окружения;

d. Сценариях работы системы;

e. Отчетах о работы системы за определенный период;

f. Настройках параметров оборудования;

3. Реляционная БД для хранения информации о:

a. Формулах расчета;

b. Единицах измерения;

c. Названиях (справочных);

d. Методах анализа;

e. Основных положениях политики;

4. OLAP хранилище для хранения информации о:

a. Результатах мониторинга показателей системы за определенный период;

b. Результатах анализа выявленных несоответствий;

c. Наилучших конфигурациях работы системы за цикл осуществления политики;

d. Анализе показателей работы системы;

5. БД временных рядов для хранения информации о:

a. Работе системы за определенный период;

b. Результатах анализа работы системы за определенный период.

3.3.1 Список элементов системы

Таким образом, включая ранее обозначенный список хранилищ системы, киберфизическая система «Умный офис» состоит из:

1. Ряда устройств, производящих непосредственное взаимодействие и физическим окружением:

a. Датчиков / счетчиков (производящие сбор информации о показателях физического окружения офисного пространства);

b. Контроллеров (внешнего или встроенного в устройство-исполнителя, отвечающего за реакцию устройства-исполнителя на внештатную ситуацию или в случае отсутствия связи с системой);

c. Исполнительного устройства (производящего физическое воздействие на окружение).

2. Ряда серверов и модулей, осуществляющих логику работы системы:

a. Списка серверов для обеспечения штатной работы системы на различных платформах:

Веб-сервер;

Сервер настольных приложений;

Сервер мобильных приложений;

b. Модуля сбора данных, который включает в себя ранее обозначенный брокер сообщений и комплекс средств и плагинов / адаптеров для сбора информации с датчиков системы;

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

Системы безопасности (при помощи Modbus TCP);

Базы и хранилища данных предприятия / компании;

OPC-средства при необходимости связи с производственным оборудованием;

d. Модуля защиты данных, предоставляющих достаточное и необходимое шифрование и защиту ее передачи через элементы системы и глобальную сеть Интернет;

e. Модуля DAO (в англ. ориг «Data Access Object»), предоставляющего паттерн для работы и доступа (осуществления операций CRUD) к различным данным в системе (в соответствии с бизнес-логикой и логикой работы системы);

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

g. Модуля запросов, который реализует выборку из одного и более хранилищ данных с целью передачи их для дальнейшей аналитики (см. «Модуль аналитики OLAP»), визуализации (см. «Модуль визуализации») и т.д.;

h. Модуля аналитики OLAP, который производит анализ данных системы при помощи соответствующих скриптов и выборки из хранилищ системы;

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

Библиотеками, написанными на Python;

Средой Open Modelica;

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

Модуля нагрузочного тестирования, который отвечает за проверку отдельных элементов, либо же системы в целом на работоспособность и производительность;

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

Модуля визуализации, ответственного за представление запрашиваемых клиентом (веб, мобильным и настольным) данных в заданной пользователем форме (дэшборды, различные виды графиков и диаграмм);

3. Хранилищ системы:

a. Документоориентированной базы данных, осуществляющей хранение:

Скриптов анализа данных (применяемых в «Модуле аналитики OLAP»);

Данных цифрового двойника офисного пространства предприятия;

Части справочных документов, имеющих структуру, наименее подходящую для хранения в реляционной БД;

Сценариев (и вариаций сценариев) работы системы;

b. Реляционной базы данных для хранения прочей справочной информации, не требующей особых условий для работы и хранения, не совместимых с концепцией реляционных БД;

c. Базы данных временных рядов, осуществляющей хранение сведений о работе системы за определенный интегратором период времени.

Контуры и сегменты системы

На рисунке приложения В.1. различными цветами отображены некоторые наборы модулей, отвечающие за осуществление определенных функций системы. Таким образом, «контур реализации сценариев системы», обозначенный серым цветом, отвечающий за адаптацию системы к изменениям физического окружения и осуществление сценариев. Фрагмент системы, ответственный за аналитику, обозначен синим цветом, документоориентированная часть БД - зеленым и т.п.

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

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



Соответствие Use Case и модулей системы

В целях проверки соответствия архитектуры требованиям, выдвинутым ранее, была построена таблица соответствия вариантов использования диаграммы Use Case и функциональных модулей системы. Обозначенная таблица приводит список наиболее значимых для выполнения отдельного Use Case модулей. Обозначенная таблица А.2. приведена в приложении А, и имеет название «Соответствие функциональных требований и модулей системы».

Вопросы для дальнейшего рассмотрения

Несмотря на вышеприведенное описание, перед автором настоящей работы остаются актуальными следующие вопросы:

1. Какова концепция архитектуры системы при развертывании?

2. Какую часть системы следует осуществить в качестве микросервисов?

3. Возможно ли построить достаточную и работоспособную архитектуру в соответствии с PDCA-циклом? Выводы по главе проектирования

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

На основании диаграммы вариантов использования и выделенных типов хранилищ был выделен ряд модулей, предназначенных для решения задач ее прецедентов. Обозначенные модули были объединены в обобщенный вариант архитектуры системы. Полученный вариант архитектуры был описан и разобран. Также в главе приведено описание диаграммы компонентов одного из модулей системы - модуля математических расчетов. По итогам главы выделены актуальные вопросы проектирования.



4. Выбор инструментов и методов для разработки системы

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

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

4.2 Выбор инструментов

Хранение документов и файлов в системе

В силу сложной / составной структуры документов, относящихся к характеристикам, схемам, настройкам и зависимостям как физического окружения, так и цифрового двойника, их хранение требует гибкости, которая отсутствует в традиционных реляционных SQL БД. Таким образом, становится актуальной рассмотрение технологий «NoSQ», преимуществами которой является гибкость схемы, масштабируемость и эффективность разработки [38].

Каждая «NoSQL» БД может быть отнесена к одному из следующих видов:

1. Словарные БД типа «ключ-значение»;

2. Документно-ориентированные базы;

3. Графовые базы данных (применяемых преимущественно при работе с социальными сетями);

4. Bigtable-подобные хранилища.

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

Таким образом, для хранения информации в рамках настоящей системы графовые БД и БД больших таблиц не соответствуют заданным требованиям, т.к. bigtable-решения склонны к меньшей скорости работы, чем БД ключ-значение или же документоориентированные БД [39].

Одним из наиболее популярных решений, используемых в подобных ситуациях, является «NoSQL» СУБД «MongoDB». В обозначенной СУБД отсутствует использование SQL - подобного синтаксиса. Несмотря на это, в СУБД присутствует возможность взаимодействия с ней непосредственно с использованием языка C#. Более того, «MongoDB» позволяет производить сохранение объектов системы в формате JSON или BSON и поддерживает индексацию для быстрого поиска как к целым документам, так и к их частям. Также «MongoDB» поддерживает кластеризацию благодаря механизму репликации, а также обеспечивает масштабируемость, создание партиций и шардинг. Отдельным плюсом «MongoDB» является его открытый исходный исходным код и бесплатной распространение. Оригинальный язык, на котором написана СУБД - С++.

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

Многомерная база данных OLAP-модуля

Для проведения анализа данных в рамках системы необходим соответствующий программный инструмент, реализующий принципы OLAP-концепции. Как показывает современная практика, проектирование многомерных хранилищ данных практически в каждом случае имеет прямую или косвенную связь с технологией OLAP [41].

Несмотря на то, что обозначенная технология была разработана и сформулирована в прошлом веке, большинство современных аналитических платформ имеют в своей основе именно OLAP-технологию. Зачастую обозначенное явление связано с зависимостью компаний с наследуемым (в ориг англ. «legacy») кодом. Однако, более молодые проекты все чаще используют технологии «Hadoop» и распределенные обработки (в англ. ориг. «Map reduce»). Стоит принять во внимание информацию о том, что компания Google объявила об остановке поддержки технологии «map reduce» в 2013 году, в связи с чем задача разработки столкнулась с потребностью поиска новых способов обработки аналитических данных. В настоящий момент, решением обозначенной задачи является применение технологии колоночных хранилищ данных.

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

Преимуществами колоночных баз данных являются:

1. Более эффективная выборка при применениях на больших таблицах (по сравнению с реляционными аналогами);

2. Неизменяемое время, затрачиваемое на изменение структуры таблиц (добавление или удаление столбца);

3. Встроенные инструменты сжатия данных;

4. В связи с чем, производится экономия дискового пространства.

К недостаткам обозначенной технологии могут быть отнесены:

1. Медленное добавление данных, характерное для OLAP-систем;

2. Отсутствие полноценных транзакций и SQL-синтаксиса;

3. Работа в файловой системе Hadoop (принимая во внимание отсутствие поддержки технологии «Map Reduce»).

На основании ранее обозначенных требований, наилучшим вариантом в рамках настоящей работы является использование инструмента «ClickHouse» - БД от компании «Yandex», которая уже успела зарекомендовать себя во время применения на реальных проектах компании. Обозначенная реализация колоночной БД позволяет выполнять операции агрегации и поиска быстрее аналогичных продуктов, а также не обязывает разработку к использованию Hadoop-технологии. Также следует отметить, что настоящее решение на текущий момент времени была положительно оценена сообществом. Ниже, на рисунке 3.1. приведено сравнение показателей «ClickHouse» с показателями решений-аналогов.

Таким образом, структура БД киберфизической системы «Умный офис» предполагается к построению в целях хранения данных, накопленных за день. Т.к. сведения с устройств-датчиков первично сохраняются в TSDB и раз в сутки отправляются в колоночную базу данных, предварительно сгруппированные по столбцам, соответствующим определенным метрикам и тэгам.

Рис 4.1 Сравнение времени обработки запроса «ClickHouse»

В свою очередь, стоит отметить, что самыми «дорогими» операциями для OLAP являются операции Select (выборки) и Update (обновления). На основании этого было произведено исследование операции Select на базе данных ClickHouse и бэнчмарка по скорости запросов - MongoDB. Результаты запросов представлены на иллюстрации 4.2.

Рис. 4.2 Сравнение скорости запросов

Из визуального анализа графика очевидно, что Select с группировкой в ClickHouse происходит на порядок быстрее, поскольку данная база данных была разработана специально для решения подобных задач [40].

Выбор Time Series Data Base

В рамках настоящей работы предполагается, что, поступающие с датчиков в реальном времени, проходят запись и обработку в БД рядов (в англ. ориг. «TimeSeries database») - influxDB. Причина выбора именно этого инструмента заключается в:

1. Удобстве использования и взаимодействия с иными инструментами;

2. Отсутствия зависимостей внутри БД;

3. Открытый исходный код;

4. SQL-подобный синтаксис.

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

Выбор языка для написания скриптов для системы

В настоящий момент времени написание различных скриптов внутри системы предполагается на языке Python. Обозначенный выбор совершен по причине наличия у языка следующих преимуществ:

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

2. Легкий и доступный для восприятия синтаксис, который имеет единообразный стиль написания;

3. Большое количество как источников справочной литературы: книг, сайтов, платных, бесплатных курсов, так и написанных другими авторами шаблонов и исходников;

4. Достаточное количество доступных сред разработки, сервисов и фреймворков, лучшими из которых признаны:

a. Django (свободный фреймворк для веб-приложений на языке Python, использующий шаблон проектирования MVC);

b. Flask (представитель класса фреймворков для создания открытых приложений, сознательно предоставляющий минимальный, базовый функционал);

c. Web2py (фреймворк с открытым кодом для разработки динамических веб-приложений, призванный сократить время на однотипные процессы веб-разработки, простоту внедрения и использования, так же следует концепции разработки MVC);

d. CherryPy (объектно-ориентированный веб-фреймворк. Спроектирован для быстрой разработки веб-приложений для сети Интернет. Представляет надстройку над HTTP-протоколом, но остаётся на низком уровне и не выходит за рамки требований RFC 2616);

e. Pylons (программный каркас для разработки веб-приложений, написанный на языке Python, имеет открытый исходный код. В обозначенном каркасе используется стандарт WSGI (в ориг. англ. Web Server Gateway Interface), что способствует эффективности повторного использования кода и модульности);

f. Pyramid (аналогичен Pylons; дизайн Pyramid основан на следующих принципах [42]:

Минимализм;

Простота взаимодействия;

Скорость работы;

Документированность;

Надёжность;

Открытость;

5. Совместимость с устройствами Raspberry Pi и Arduino (что может быть полезно при создании киберфизических систем, т.к. использование обозначенных устройств имеет широкий спектр применения, в том числе и в системе «Умный офис»).

4.3 Выводы по главе выбора инструментов

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



Заключение

На основании проделанной работы, может быть сделан вывод о том, что в ходе проведенного исследования были получены:

1. Результаты исследования предметной области КФС «Умный офис», включающие в себя обзор и анализ:

a. Понятий киберфизических системы в целом (определение, характерные черты, сферы применения, способы управления и разработки);

b. Предметной области КФС (понятий и технологий, имеющих отношение к ключевым особенностям и характерным чертам КФС);

2. Список требований к разрабатываемой системе (с соответствующими схемами и обоснованием);

3. Обобщенная архитектура киберфизической системы «Умный офис»;

4. Частичный выбор инструментов реализации разрабатываемой системы.

В ходе достижения поставленных целей и получения результатов были выполнены соответствующие задачи сформулированных в начале работы. Выполнение всех задач из числа обозначенных обеспечило достижение поставленной цели - формирование паттерна архитектуры для КФС «Умный офис». Разработанная архитектура позволяет хранить и обрабатывать информацию о:

1. Цифровом двойнике физического окружения офисного пространства;

2. Методах анализа поступающей в систему информации;

3. Предметной области системы (справочных показателях, нормативных документах, регламентах, шаблонах и пр.);

4. Целях и задачах системы, привязанных к конкретным показателям.

В ходе реализации архитектуры (продолжения настоящей работы над системой) предполагается использование современных инструментов обработки данных - высоконагруженных и оптимизированных СУБД (influxDB, ClickHouse, MongoDB). Дальнейшим развитием настоящей работы является доработка созданного паттерна архитектуры и его пошаговая реализация.



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

1. E. Lee et al. Cyber physical systems: Design challenges in Object Oriented Real-Time Distributed Computing (ISORC), 2008 [Материалы конференции] // 11th IEEE International Symposium on. IEEE, 2008, pp. 363-369.

2. US National Science Foundation, Cyber-Physical Systems (CPS) [Интернет-ресурс]

3. D. Miorandi, S. Sicari, F. De Pellegrini, I. Chlamtac Internet of things [Статья] // Ad Hoc Netw. 10(7), 2012, pp 1497-1516.

4. E.A. Lee, S.A. Seshia Introduction to embedded systems - a cyber-physical systems approach [Книга] // LeeSeshia.org, 2011.

5. C.Alippi Intelligence for Embedded Systems [Статья] // Springer Verlag, 2014, 283pp

6. Porter ME, Heppelmann JE How smart, connected products are transforming competition [Статья] // Harv Bus Rev, 2014, 92:11-64.

7. Heath, Steve Embedded systems design. EDN series for design engineers (2 ed.) [Книга] // Newnes, 2003, p. 2.

8. Wortmann, F., & Flьchter, K. Internet of Things. Technology and Value Added [Статья] // Internet of Things. Business & Information Systems Engineering, 2015, 57(3), 221-224

9. Fleisch E, Weinberger M, Wortmann F Business models for the internet of things. Bosch lab white paper, 2014 [Интернет-ресурс]

10. Popper, S., Bankes, S., Callaway, R., and DeLaurentis, D. System-of-Systems Symposium: Report on a Summer Conversation [Материалы конференции] // Potomac Institute for Policy Studies, Arlington, VA, July 21-22, 2004.

11. DeLaurentis D. System of Systems Definition and Vocabulary [Статья] // School of Aeronautics and Astronautics, Purdue University, West Lafayette, IN, 2007.

12. Lee, Edward Cyber Physical Systems: Design Challenges [Статья] // University of California, Berkeley Technical Report, January 23, 2008 No. UCB/EECS-2008-8.

13. Beck, A., Boeing, G., & Shannon, D. [Статья] // Systems and Methods for Analyzing Requirements, 2014, US Patent 8650186".

14. Saddik, A. El Digital Twins: The Convergence of Multimedia Technologies [Статья] // IEEE MultiMedia, April, 2018, 25 (2): 87-92.

15. Frдmling, Kary, Holmstrцm, Jan, Ala-Risku, Timo, Kдrkkдien, Mikko Product agents for handling information about physical objects [Статья] // Report of Laboratory of Information Processing Science series B, TKO-B 153/03, Helsinki University of Technology, 2003. 20 p.

16. Bacchiega, Gianluca Creating an Embedded Digital Twin: monitor, understand and predict Device Health Failure [Материалы конференции] // Inn4mech - Mechatronics and Industry 4.0 Conference presentation - 2018.

17. Gautier, Philippe L'Internet des Objets... Internet, mais en mieux [Статья] // France: AFNOR, 2011. ISBN 978-2-12-465316-4.

18. Saleh, M.S.; Althaibani, A.; Esa, Y.; Mhandi, Y.; Mohamed, A.A. Impact of clustering microgrids on their stability and resilience during blackouts [Материалы конференции] // International Conference on Smart Grid and Clean Energy Technologies (ICSGCE), 2015. pp. 195-200

19. Smart Home or Building. IoT Agenda [Интернет-ресурс]

20. What is SMART (S.M.A.R.T.). Computer Hope [Интернет-ресурс]

21. Yin Zhang, Meikang Qiu, Chun-Wei Tsai, Mohammad Mehedi Hassan and Atif Alamri Health-CPS: Healthcare Cyber-Physical System Assisted by Cloud and Big Data [Статья] // IEEE Systems Journal, 2015.

22. Bhatia S.K. Sood Exploring Temporal Analytics in Fog-Cloud Architecture for Smart Office HealthCare [Статья] // Mobile Networks and Applications, 2018.

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

24. P. Diament, S.L. Richert CPS PWG Draft Framework for Cyber-Physical Systems, Release 1.0 [Книга] // Cambridge, MA: MIT Press, 2016.

25. Molly B. Richardson, Peng Li, Julia M. Gohlke, and David B. Allison Effects of Indoor Thermal Environment on Human Food Intake, Productivity, and Comfort: Pilot, Randomized, Crossover Trial [Материалы конференции] // Obesity Symposium, 2018.

26. Solange Leder, GuyR.Newsham, Jennifer A.Veitch, SandraMancini and Kate E.Charles Effects of office environment on employee satisfaction: a new analysis [Статья] // Building research & information, 2015.

27. Geng Y, Ji W, Lin B, Zhu Y The impact of thermal environment on occupant IEQ perception and productivity [Статья] // Building and Environment, 2017

28. Maximilian Schneider and Linnйa Warnvik The Impact of Organizational Culture and Office Design on Innovation and Motivation [Статья] // JЦNKЦPING, 2018.

29. R. Padma Priya, J. Marietta, D. Rekha, B. C. Mohan and A. Amolik IoT-Based Smart Office System Architecture Using Smartphones and SmartWears with MQTT and Razberry [Материалы конференции] // Proceedings of the 2nd International Conference on Data Engineering and Communication Technology, Advances in Intelligent Systems and Computing, 2018.

30. K. Wiegers, J. Beatty, Software Requirements, Third Edition [Книга] // 2013.

31. Donovan, N., Brown, J. and Bellulo, L. Satisfaction with public services -- A discussion paper, Strategy Unit, Cabinet Office, London, November 2001 [Интернет-ресурс]

32. Grieves M. Origins of the Digital Twin Concept [Статья] // Florida Institute of Technology-NASA - 2017 - 8 с.

33. Губернский Ю.Д., Кореневская Е.И. Гигиенические основы кондиционирования микроклимата жилых и общественных зданий. [Статья] // Медицина, 1978.-192 с.

34. Банхиди Л. Тепловой микроклимат помещений: расчет комфортных параметров по теплоощущениям человека [Книга] // Пер. с венг. В.М. Беляева; Под ред. В.И. Прохорова и А.Л. Наумова.-.: Стройиздат, 1981.-248 с.

35. Здания жилые и общественные. Параметры микроклимата в помещениях. ГОСТ 30494-96 [Межгосударственный стандарт] // Госстрой России, ГУП ЦПП, 1999.

36. Moderate thermal environments - Determination of the PMV and PPD indices and specification of the conditions for thermal comfort. ISO 7730. Second edition [Межгосударственный стандарт] // 1994-12-15.

37. Дейт К. Дж. Введение в системы баз данных (Introduction to Database Systems). -- 8-е изд. -- М.: «Вильямс», 2006. -- 1328 с. -- ISBN 0-321-19784-4.

38. Документация по базе данных MongoDB [Интернет-ресурс]

39. Фаулер M. NoSQL: Новая методология разработки нереляционных баз данных [Книга] // М. Фаулер, П.Дж. Садаладж - М.: ООО "И.Д. Вильямс". - 2013. - 192 c.

40. Документация по базе данных ClickHouse. Overview of ClickHouse Architecture [Интернет-ресурс]

41. Конноли Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика [Книга] // Т. Конноли, К. Бегг. - М.: ООО "И.Д. Вильямс". - 2017. - 1440 c.

42. Pyramid Introduction [Интернет-ресурс]



Приложение А

«Use Case» диаграмма системы «Умный офис»

Рисунок А.1. Диаграмма Use Case системы «Умный офис», вариант I



Рисунок А.2 Диаграмма Use Case системы «Умный офис», вариант II



Таблица А.1

Соответствие функциональных требований и акторов

Прецедент	Сотрудник офиса	Руководитель отдела	Специалист БиОТ	Спец. тех. поддержки	Офис-менеджер	Интегратор
Анализ показателей безопасности		+	+		+
Анализ показателей комфорта		+	+		+
Расчет показателей энерго эффективности		+	+		+
Анализ энергопотребления		+	+		+
Анализ показателей системы		+	+		+
Анализ эксп. эффективности		+	+		+
Создание справочника показателей		+	+		+	+
Расчет значений для показателей системы		+	+		+
Определение показателей		+	+		+
Определение ключевых показателей		+	+		+
CRUD сценариев работы системы						+
Создание цифрового двойника						+
CRUD цифровых схем и Чертежей офиса						+
CRUD онтологии офиса						+
CRUD физ. и мат. моделей поведения офиса						+
Определение целей и задач системы		+			+
Планирование стоимости осуществления политики		+			+
Определение списка мероприятий		+			+
Работа с документами системы					+
Работа с отчетами о работе системы					+
Настройка параметров оборудования					+
Работа с оповещениями	+	+			+
Произведение закупок, оборудования, услуг					+
Создание предложения по улучшению работы системы	+
Корректировка работы сценариев системы					+	+
Оценка несоответствий		+			+
Формирование рекомендаций по работе системы		+			+
Просмотр предложений по улучшению системы		+			+
Формирование отчетности
Просмотр показателей энергопотребления	+
Просмотр показателей комфорта	+
План-факт анализ		+			+
Просмотр показателей безопасности	+				+
Просмотр показ. оборудов.		+			+
Анализ выявленных неисправностей		+			+
Сохранение наилучших конфигураций		+

Страница:

•  1 
•  2 
•  3 
•  4 

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

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

• Разработка аппаратно-программных модулей системной шины ISA

  Характеристики системной шины ISA. Проектирование устройств ввода/вывода для нее. Принципы построения и программирование модулей шины. Особенности использования прерываний. Применение прямого доступа. Процедуры инициализации системы ПДП.
  
  методичка [812,0 K], добавлен 14.07.2012
  

• Разработка адаптера связи ОЗУ с синхронной системной шиной

  Анализ архитектуры, структуры и элементной базы существующих ОЗУ и системных шин компьютеров. Разработка структурной и принципиальной схемы адаптера связи оперативного запоминающего устройства с синхронной системной шиной. Выбор элементов и узлов ОЗУ.
  
  курсовая работа [271,4 K], добавлен 17.09.2013
  

• Разработка модели состава и модели структуры электронной системы "Умный дом"

  Интеллектуальная система, которая объединяет электрические приборы посредством линии управления. Управление несколькими приборами. Схема устройств "Умного дома". Анализ связей между элементами системы. Система приема эфирного и спутникового телевидения.
  
  курсовая работа [5,1 M], добавлен 18.12.2010
  

• Разработка программного комплекса для автоматизации деятельности работников завода

  Исследование технологии проектирования базы данных. Локальные и удаленные базы данных. Архитектуры и типы сетей. Программная разработка информационной структуры предметной области. Обоснование выбора архитектуры "клиент-сервер" и операционной системы.
  
  дипломная работа [1,1 M], добавлен 15.02.2017
  

• Разработка информационной системы "Библиотека"

  Анализ предметной области. Основание, назначение для разработки, требования к программному средству. Выбор подхода и модели разработки ПС. Анализ требований, разработка и определение вариантов спецификаций. Описание объектов, свойств и методов.
  
  курсовая работа [510,3 K], добавлен 23.02.2011
  

• Проектирование АИС планирования и учета поставок деталей для сборки автомобилей на платформе В0 в ОАО "Автоваз"

  Проектирование информационнной системы планирования и учета поставок деталей внутри ОАО "АВТОВАЗ" из изготавливающих детали цехов на платформу В0. Формализация существующих бизнес-процессов. Выбор и разработка архитектуры, составление диаграмм.
  
  курсовая работа [8,2 M], добавлен 25.12.2011
  

• Разработка системы "Управление умным домом"

  Анализ технологий "умного дома", их базовые понятия. Описание технологического процесса и модель автоматизации. Разработка системы управления зданием. Анализ программного обеспечения. Технология производства программного продукта, разработка бизнес-плана.
  
  дипломная работа [1,8 M], добавлен 06.04.2015
  

• Описание системы "Виртуальный офис"

  Обзор существующих систем, технология виртуальной телекоммуникационной станции. Архитектура и функциональные возможности системы "Виртуальный офис", выбор и обоснование средств ее реализации, оценка практической эффективности, расчет необходимых затрат.
  
  дипломная работа [1,5 M], добавлен 30.03.2015
  

• Информационно-управляющие системы

  Классификация информационно-управляющих систем, технологии их проектирования. Функциональное назначение модулей корпоративной ИУС, анализ современного состояния рынка в этой области, описание архитектуры. Методологии моделирования предметной области.
  
  презентация [498,3 K], добавлен 14.10.2013
  

• Разработка и реализация информационной системы "Интернет-магазин телефонов и аксессуаров мобильной связи"

  Изучение предметной области и выявление основных задач Интернет-магазинов. Выбор средств разработки системы, базы данных, инфологической и даталогической моделей. Разработка программного приложения, программных модулей, представленных экранными формами.
  
  дипломная работа [4,2 M], добавлен 22.04.2015
  

• Разработка системы электронного документооборота банка "ВТБ 24"

  Анализ предметной области. Обоснование проектных решений по разработке автоматизированного рабочего места сотрудника канцелярии банка. Проектирование структуры базы данных и интерфейса системы. Разработка программных модулей и алгоритмов их работы.
  
  дипломная работа [2,1 M], добавлен 18.10.2015
  

• Разработка обучающего игрового приложение по дисциплине "Астрономия"

  Сбор и анализ сведений по предметной области по дисциплине "Астрономия" с целью разработки обучающего игрового приложения. Исследование алгоритмов и характеристик существующих программных систем аналогов. Разработка архитектуры программной системы.
  
  курсовая работа [4,1 M], добавлен 27.11.2014
  

• Проектирование сайта-визитки для автотехнического центра "Авант"

  Проектирование web-сайта. Пользовательские персонажи, детальная концепция сайта. Разработка скелетной схемы страниц, информационной архитектуры. Создание прототипа web-сайта. Выбор среды разработки. CMS системы и их анализ. Стадии проектирования сайта.
  
  курсовая работа [346,7 K], добавлен 18.09.2016
  

• Разработка приложений архитектуры клиент-сервер при помощи SQL

  Анализ архитектуры информационной системы, в структуру которой входят системы файл-сервер и клиент-сервер. Сравнение языков запросов SQL и QBE. Принципы разработки приложений архитектуры клиент-сервер при помощи структурированного языка запросов SQL.
  
  курсовая работа [88,9 K], добавлен 11.04.2010
  

• Разработка системы учета проката автомобилей

  Особенности архитектуры Java, виртуальная машина, кроссплатформенность приложений. Информационно-логическая модель предметной области, описание сущностей, атрибутов, ключей, связей. Реализация интерфейса пользователя, принципы разработки инструкции.
  
  курсовая работа [832,1 K], добавлен 06.01.2014
  

• Проектирование архитектуры системы "Букмекерская контора"

  Анализ текущих бизнес-процессов при работе букмекерской конторы. Построение функциональных моделей предметной области и диаграмм потоков данных. Основные меры по реорганизации бизнес-процессов и разрешению противоречий. Разработка мобильных приложений.
  
  курсовая работа [246,0 K], добавлен 10.01.2014
  

• Разработка алгоритмических модулей ПО RTA для оперативного анализа разных сценариев формирования опорной транспортной сети

  Методы и приемы оценки транспортной доступности территорий при разных контурах опорной транспортной сети. Проектирование архитектуры функционирования и разработка алгоритмических модулей системы RTA. Функциональные требования к ПО и описание его работы.
  
  дипломная работа [3,2 M], добавлен 08.12.2013
  

• Разработка автоматизированной информационной системы ООО "Фарватер"

  Описание системы-прототипа по видам обеспечения. Недостатки системы учета. Информация, подлежащая структуризации и системной организации. Исходящие и входящие информационные потоки. Проектирование базы данных предприятия. Разработка моделей базы данных.
  
  курсовая работа [3,2 M], добавлен 03.07.2012
  

• Разработка информационной системы "Реконструкция и ремонт зданий" для ТОО "Аскентжол" г. Караганда

  Выбор и обоснование аппаратного обеспечения. Типы архитектуры веб-приложений. Шаблоны проектирования архитектуры приложения. Разработка инфологической модели базы данных. Подготовка к разработке приложения. Рассмотрение причин возникновения паттернов.
  
  дипломная работа [3,0 M], добавлен 27.11.2022
  

• Разработка обучающей программы по русскому языку

  Описание предметной области. Компоненты и палитра компонентов. Выбор архитектуры приложения. Структурные и функциональные схемы. Описание разрабатываемых процедур и функций, таблица идентификаторов. Выбор стратегии тестирования и разработка тестов.
  
  дипломная работа [8,2 M], добавлен 18.06.2014
  

Другие документы, подобные "Разработка системной архитектуры киберфизической системы "Умный офис""

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам