Методы и алгоритмы выбора программной архитектуры систем Интернета вещей тема диссертации и автореферата по ВАК РФ 05.13.01, кандидат наук Ядгарова Юлия Владимировна

• Ядгарова Юлия Владимировна
• кандидат наук
• 2020

Оглавление диссертации кандидат наук Ядгарова Юлия Владимировна

СОКРАЩЕНИЯ

ВВЕДЕНИЕ

1. АНАЛИЗ СПЕЦИФИКИ СИСТЕМ ИНТЕРНЕТА ВЕЩЕЙ, ПРОГРАММНЫХ АРХИТЕКТУР И ДОСТИГАЕМЫХ ПАРАМЕТРОВ КАЧЕСТВА ПРИ РАЗРАБОТКЕ ПО

1.1. Интернет вещей как продолжение развития телекоммуникационных технологий и его основные свойства

1.2. Текущее состояние и стандартизация систем Интернета вещей

1.3. Классификация систем Интернета вещей

1.4. Модели качества программных систем

и важнейшие параметры качества систем Интернета вещей

1.5. Анализ применимости параметров качества программной системы к системам Интернета вещей

1.5. Анализ процесса разработки программной архитектуры

и понятие шаблонов архитектуры

1.6. Понятие тактик разработки и их связь с шаблонами архитектуры

1.6.1. Связь тактик разработки и шаблонов архитектуры

1.7. Методы оценки трудоемкости программных проектов

1.7.1. Принципы параметрических моделей

1.7.2. Оценка по методике СОСОМО II

1.8. Оптимизация систем с интервальными параметрами

и операции сравнения интервалов

1.8.1. Сравнение интервалов, основанное на мере близости

Выводы по главе

2. ЗАДАЧА ВЫБОРА АРХИТЕКТУРЫ И МЕТОД ПРОГНОЗИРОВАНИЯ ПАРАМЕТРОВ КАЧЕСТВА ДЛЯ СИСТЕМ ИНТЕРНЕТА ВЕЩЕЙ

2.1. Онтология программной архитектуры

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

2.3. Модель выбора базового шаблона архитектуры и тактик

разработки систем Интернета вещей

2.3.1. Расчет интервальной функции оценки с помощью методики СОСОМО II

Выводы по главе

3. МЕТОДИКА ВЫБОРА ПРОГРАММНОЙ АРХИТЕКТУРЫ

ДЛЯ СИСТЕМ ИНТЕРНЕТА ВЕЩЕЙ

3.1. Постановка задачи и алгоритм выбора шаблона

программной архитектуры и тактик разработки

3.2. Функциональное моделирование процесса выбора шаблона программной архитектуры и тактик разработки

3.2.1. Формирование вектора параметров качества

3.2.2. Формирование списка шаблонов архитектур и тактик разработки

3.2.3. Решение задачи СБР в трех вариантах

3.2.4. Оценка и вариация полученных архитектур

3.2.5. Верификация подхода

3.3. Разработка программного средство поддержки принятия решений

при выборе архитектуры систем Интернета вещей

3.3.1. Структура системы поддержки принятия решений

3.3.2. ЕЯ-моделирование системы поддержки принятия решений

Выводы по главе

4. ВЕРИФИКАЦИЯ И ОЦЕНКА ЭФФЕКТИВНОСТИ МЕТОДИКИ

4.1. Описание проектов, цели, анализ требований и окружения

4.1.1. Проект для домашней автоматизации («Eclipse Smart Home»)

4.1.2. Проект для мониторинга энергии («OpenEnergyMonitor»)

4.2. Применение методики проектирования

программной архитектуры и СППР EEDR

4.2.3. Анализ полученных результатов

Выводы по главе

ЗАКЛЮЧЕНИЕ

СПИСОК ЛИТЕРАТУРЫ

ПРИЛОЖЕНИЯ

1. Некоторые архитектурные шаблоны ПО, их достоинства и недостатки

1.1. Архитектура «Клиент-сервер»

1.2. Архитектура «Peer-to-peer»

1.3. Архитектура «Каналы и фильтры»

1.4. Событийно-ориентированная архитектура

1.5. Архитектура «Издатель-подписчик»

1.6. Сервисно-ориентированная архитектура

1.7. Архитектура слоев

1.8. Архитектура микроядра (плагинов)

1.9. Архитектура микросервисов

2. Основные тактики разработки и адресуемые параметры качества

3. Модель раннего проектирования COCOMO II

4. Основные методы оценки качества программных архитектур

5. Типы модификации шаблонов тактиками проектирования

5.1. Архитектура слоев

5.2. Архитектура «Каналы и фильтры»

5.3. Архитектура «Клиент-сервер»

5.4. Сервисно-ориентированная архитектура

5.5. Архитектура микросервисов

5.6. Архитектура «Peer-to-peer»

5.7. Архитектура «Издатель-подписчик»

5.8. Событийно-ориентированная архитектура

5.9. Архитектура микроядра (плагинов)

СОКРАЩЕНИЯ

АТС - автоматическая телефонная станция БД - база данных

ЛПР - лицо, принимающее решения

МСЭ - Международный союз электросвязи

ПО - программное обеспечение

СППР - система поддержки принятия решений

DARPA - Defense Advanced Research Projects Agency

ERM - Entity-Relationship Model

JMS - Java Message Service

IDEF0 - Icam DEFinition for Function Modeling

IoT - Internet of Things

IIoT - Industrial Internet of Things

KLOC - Kilo Lines Of Code

MVC - Model-View-Controller

OSGi - Open Services Gateway initiative

OSI - Open Systems Interconnection

OWL - Web Ontology Language

RFID - Radio Frequency Identification

RMI - Remote Method Invocation

SOA - Service-Oriented Architecture

SOAP - Simple Object Access Protocol

ВВЕДЕНИЕ

В последнее десятилетие быстрое развитие интернет-технологий, алгоритмов сетевого взаимодействия и повышение доступности вычислительных устройств [131] привели к появлению и быстрому развитию технологии, которая получила название Интернета вещей 1 . На международном уровне данная концепция приобретает сформировавшиеся черты, что можно проследить по появлению четкой классификации типов подобных систем, стандартов взаимодействия устройств, а также выделению фундаментальных характеристик технологии в соответствии с рекомендациями Международного союза электросвязи (МСЭ) [40]. Вслед за появлением Интернета вещей стало возможным построение высокоинтеллектуальных производственных систем и приложений, в основе управления которыми лежит связь между всеми основными устройствами производственной системы, а также центрами управления, в которых производится мониторинг и расчет операций. Подобные системы получили в литературе название Промышленного Интернета . Однако в основе построения большинства типов систем 1оТ (к которым также относятся системы 11оТ) так или иначе лежат принципы системного анализа.

В России на уровне федеральных органов власти проблематика передовых производственных технологий (в том числе технологий Интернета вещей) стала активно обсуждаться и рассматриваться в качестве приоритетного направления развития промышленности с 2013 года. Одним из показателей, характеризующих потенциал развития технологии, является ее общая выгода для экономики. Другим существенным показателем важности развития является количество подключенных к системам Интернета вещей устройств, которое, по разным прогнозам, достигнет 50 млрд по всему миру к 2025 году.

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

1 Internet of Things (англ.).

2 International Telecommunication Union, ITU (англ.).

3 IloT, Industrial Internet of Things (англ.).

положительное влияние систем Интернета вещей на различные показатели эффективности было неоднократно доказано успешными проектами (можно рассмотреть системы «Умный дом» и, к примеру, значительное повышение уровня безопасности подобного жилища). В то же время, принимая во внимание, что системы Интернета вещей можно с уверенностью отнести к сложным и требования к достигаемым параметрам таких комплексов сильно зависят от отрасли, достижение требуемых атрибутов с помощью только сетевых алгоритмов взаимодействия не представляется возможным [3, 4]. Особенно актуальна проблема выбора программной архитектуры, так как в конечном итоге ошибка на управляющем уровне сводит на нет эффективность работы коммуникационных и сетевых алгоритмов. При этом, наряду с широким развитием аппаратных и сетевых стандартов технологии, в сфере стандартов разработки программной части наблюдается пробел и для ряда классов подобных систем вопрос оптимального построения программной части платформы остается открытым. Ввиду широкого распространения технологии и величины подобных систем, ошибки в построении программной архитектуры ведут к значительному удорожанию и увеличению сроков проекта, что подтверждается исследованиями. К примеру, отчеты группы Стэндиша4 в 2018 году показали, что в крупных компаниях 19% проектов прекращаются до завершения, а затраты на 52% проектов превышают изначально заданную оценку.

Отчасти данный пробел был заполнен отраслевыми стандартами. К примеру, при разработке систем Промышленного Интернета (классифицированного в данной работе как один из типов систем Интернета вещей), рекомендуют придерживаться официального документа, разработанного для поддержки построения подобных комплексов - стандарта на разработку типовой архитектуры5 [97]. В данном стандарте, разрабатываемом Консорциумом по внедрению Промышленного интернета, показаны основные модели построения, элементы, связи и концептуальные ограничения, свойственные указанным системам.

4 Standish Group Report (англ.).

5 Industrial Internet reference architecture (англ.).

В России проблемами разработки систем Интернета вещей и теоретическими основами данной технологии занимались исследователи А. В. Росляков, С. В. Ваняшин, А. Ю. Гребешков [41], В. А. Бородин [5], Л. Черняк [55], В. П. Куприяновский и др. [23]. По аналогии считая технологии многоагентных систем [24, 49] теоретической основой появления систем Интернета вещей, можно сказать, что построением и теоретическим обоснованием данных систем занимались достаточно большое число исследовательских групп [33, 107]. Перспективы становления технологии, а также потенциальные вопросы стандартизации технологии, адресации и сетевых технологий рассмотрены в работах Р. Алгулиева [ 1]. Вопросы перехода от концепции метаКИП к сетям предприятий описаны в работах В. Б. Тарасова [50]. За рубежом проблема освещена подробнее в работах A. Bassi [64], R. Weber [142], F. Wortmann [146], F. Xia [147] и S. Yang [150]. Большое количество работ адресует конкретные классы систем Интернета вещей, к примеру, Industry 4.0 6[103] или системы Умный город [151]. Некоторые исследования, связянные прежде всего с организацией многоагентных производственных линий, были приведены в работах В. В. Таратухина [138].

С точки зрения экономического развития и влияния систем на экономику и мониторинг глобальных транзакций, можно отметить работы Е. Л. Логинова [31].

Что касается методов построения информационных систем, необходимо отметить работы В. В. Кулямина [21, 22] и С. В. Синицына [44], посвященные верификации программного обеспечения. В работах С. В. Гусса [11], В. Н. Гусятникова [12], Е. М. Лаврищевой [26, 27], А. В. Рудакова [42] описываются технологии и компоненты разработки. Большой вклад в исследование параметров качества ПО внесли исследования А. И. Таганова [48] С. А. Орлова [34], А. А. Карпунина [16] и А. А. Пивеня [37]. Работы А. Н. Терехова [51], И. А. Лысенко [32] и Н. Попова [38] раскрывают процесс проектирования ПО. Вопросы разработки распределенных систем затронуты в исследованиях А. А. Кондратьева [18] и А. М. Федотова [53]. Среди зарубежных работ в области

6 Промышленность

качества программных систем необходимо обратить внимание на B. Boehm [69] и L. Bass [63] со справочниками построения программных архитектур, а также

A. Gillies [87], S. Kan [104], L. Lundberg [112], описывающих достижение параметров качества ПО. Фундаментальными вопросами разработки программной архитектуры занимались исследователи N. Medvidovic [117], G. Abowd [56], D. Garlan [86], С. Hofmeister [95], M. Shaw [133]. Подробную информацию о конкретных методах и способах построения проектов можно найти в работах N. Harrison [90], D. Garlan [86], M. Klein[108], P. Kruchten [110].

Однако в области качества построения именно архитектур, связанных с технологиями Интернета вещей, наблюдается недостаток информации, вызванный прежде всего относительной новизной технологии и некоторым разбросом в понимании того, что современные исследователи включают в это понятие. Среди зарубежных работ в этой области необходимо отметить J. Gubbi [88] с детальным разбором архитектурных элементов Интернета вещей, R. Khan [107], S. Datta [79], S. Krco [109], H. Ning [118] с примерами программных архитектур построения систем. В России, проводя некоторые параллели с надежностью технических систем и качеством производственных процессов, необходимо отметить работы

B. К. Федюкина [54] и Р. С. Судакова [45]. Вопросы надежности программных средств поднимались в исследованиях Б. В. Палюха [35, 36]. Отдельные достигаемые параметры качества, а также важность их достижения и оценки описаны в работах I. D. Addo [57], S. Ciraci [76], A. Ouksel [121], C. Sarkar [130]. Исследование

C. А. Толкачева [52] посвящено промышленному Интернету вещей.

Конкретные архитектуры построения систем IoT разнятся от многоуровневых вариантов с наличием/отсутствием промежуточных узлов (Fog-узлов) [70, 81], использованием/неиспользованием облачных технологий [89]. Исследованиями построения конкретных архитектур для проектов Интернета вещей с определенными параметрами качества занимались исследовательские группы по всему миру, что отражено в работах А. Н. Терехова и P. Desai [51, 81].

Основными принципами, лежащими в основе успешного функционирования систем Интернета вещей, являются:

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

2. Принцип информационной безопасности: условие, при котором система функционирует без позволения неавторизированного доступа, любые изменения в данных в системе сохраняются и могут быть отслеживаемы [19].

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

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

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

С учетом вышесказанного, обобщая принципы и параметры систем промышленного Интернета на более общий класс систем Интернета вещей, возникает вопрос о нахождении общей зависимости достигаемых параметров качества систем Интернета вещей от используемой программной архитектуры. Проблема построения и оценки архитектур систем Интернета вещей указана среди основных вызовов, предъявленных к данной технологии в настоящее время [61, 113, 136]. Вторым значимым вопросом, поднимаемым в данной работе, является выбор релевантных различным типам систем 1оТ параметров качества. Построение методики выбора программной архитектуры системы в зависимости от требуемых параметров качества позволит повысить качество внедрения путем уменьшения ошибок на начальном этапе проекта и в результате повысить вероятность успешного функционирования результирующей системы [72].

Объект и предмет исследования. Объектом исследования является процесс выбора программной архитектуры систем Интернета вещей. Предметом исследования

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

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

Для достижения поставленной цели в диссертационной работе решаются следующие задачи:

1. Системный анализ процесса разработки программных систем применительно к области Интернета вещей, типовых закономерностей и связей.

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

3. Создание методики выбора шаблонов архитектур и тактик разработки для систем Интернета вещей, удовлетворяющих заданным параметрам качества.

4. Разработка тактико-стратегического метода прогнозирования необходимых параметров качества для реализации в системе Интернета вещей в рамках указанной методики.

5. Создание алгоритмов выбора базового шаблона программной архитектуры и тактик для систем Интернета вещей, а также проблемно-ориентированной системы поддержки принятия решений и управления процессом проектирования подобных систем.

6. Верификация методики на базе открытых проектов разработки систем Интернета вещей.

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

Научная новизна работы. В диссертации получены следующие результаты:

1. Разработана методика выбора шаблонов архитектур и тактик разработки для систем Интернета вещей на основе структурно-параметрического синтеза конфигурации архитектуры, удовлетворяющей заданным параметрам качества при минимизации трудоемкости разработки. Преимущество методики заключается в раннем определении ведущего шаблона программной архитектуры.

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

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

4. Разработаны алгоритмы выбора шаблонов архитектуры и тактик разработки, реализующие указанную методику.

5. Разработана проблемно-ориентированная система поддержки принятия решений при построении программной части системы Интернета вещей.

Тематика исследований соответствует паспорту специальности 05.13.01 по разделам: п. 7 «Методы и алгоритмы структурно-параметрического синтеза и идентификации сложных систем»; п. 9 «Разработка проблемно-ориентированных систем управления, принятия решений и оптимизации технических объектов»; п. 11. «Методы и алгоритмы прогнозирования и оценки эффективности, качества и надежности сложных систем».

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

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

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

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

Реализация результатов работы. Результаты диссертационного исследования и разработанная платформа нашли применение:

- ООО «Атос АйТи Солюшенс энд Сервисез»;

- в учебном процессе кафедры «Компьютерные системы автоматизации производства» МГТУ им. Н. Э. Баумана.

На защиту выносятся следующие основные результаты и положения:

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

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

3. Тактико-стратегический метод прогнозирования релевантных для различных типов систем Интернета вещей требуемых параметров качества программной архитектуры в рамках указанного подхода.

4. Алгоритмы синтеза шаблонов архитектуры и тактик разработки, поддерживающие указанный подход.

5. Архитектура проблемно-ориентированной системы поддержки принятия решений при построении программной части системы Интернета вещей.

Введение диссертации (часть автореферата) на тему «Методы и алгоритмы выбора программной архитектуры систем Интернета вещей»

Апробация работы

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

Международный конгресс по интеллектуальным системам и информационным технологиям (IS-IT, Дивноморское, 2016-2019 гг.), Научная сессия НИЯУ МИФИ-2014, VI Всероссийская научно-практическая конференция «Нечеткие системы и мягкие вычисления» (НСМВ-2014), 2015 Annual Conference of the North American Fuzzy Information Processing Society (NAFIPS) (Redmond, WA USA), 2015 International IFIP Working Conference on Enterprise Interoperability (Nimes, France), DAAAM International 2016 (Vienna, Austria), I-ESA 2016 (Interoperability for enterprise systems and applications, Portugal).

1. АНАЛИЗ СПЕЦИФИКИ СИСТЕМ ИНТЕРНЕТА ВЕЩЕЙ,

ПРОГРАММНЫХ АРХИТЕКТУР И ДОСТИГАЕМЫХ ПАРАМЕТРОВ

КАЧЕСТВА ПРИ РАЗРАБОТКЕ ПО

1.1. Интернет вещей как продолжение развития телекоммуникационных

технологий и его основные свойства

Официально история технологий телекоммуникации и связи начинается с изобретения Александром Беллом телефона в 1876 году [15]. Развитие телефонных сетей с этого времени шло быстрыми темпами: вскоре во многих городах России стали появляться телефонные станции. Затем, с развитием технологии, произошел переход от сетей с ручной коммутацией к цифровым АТС.

Ключевую роль в дальнейшем развитии систем телекоммуникации сыграло появление и широкое развитие сети Интернет, изначально разработанной для оборонного ведомства США по заказу агентства DARPA . Основной отличительной особенностью данной сети стал принцип коммутации пакетов, позволяющий доносить информацию до участников даже при нестабильном соединении. Большой вклад в развитие сети внесли исследования, посвященные сетям и протоколам [75]. В 1997 году была выработана новая концепция развития сетей связи общего пользования, названная конвергенцией [20].

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

Интернет вещей как термин был впервые упомянут в 1999 году Кевином Эштоном, основателем MIT Auto-ID центра [136]. В последние годы технологии Интернета вещей набирают популярность во многих сферах науки и техники. Здесь

7 DARPA (англ. Defense Advanced Research Projects Agency) - Управление перспективных исследовательских проектов Министерства обороны США.

следует отметить, что идеи Интернета вещей во многом перекликаются с идеей многоагентных самоорганизующихся систем, подробно освещенных в работах В. И. Городецкого [6-8], Г. Б. Евгенева [14], С. Рассела [39] и М. Wooldridge [145], Некоторые параллели многоагентных систем с системами 1оТ также прослеживаются в исследованиях [135, 137, 144, 148], что позволяет говорить об определенной зрелости появления технологии, как логичного прикладного приложения теории агентных систем.

Однако, наряду с этим, данное определение до сих пор не несет ясного смысла для пользователей технологии.

В литературе и на веб-ресурсах в большинстве случаев используют две основные характеристики. Первая - Интернет вещей является сетью, что подразумевает использование термина только в единичной форме (как и в случае Интернета, Интернет вещей только один). Вторая касается так называемых «вещей», относящихся к данному понятию. Это любые физические объекты нашего мира. Данные объекты являются частью самой технологии, соединены в сеть и имеют уникальные идентификаторы. Состояние каждого объекта можно отследить, а в некоторых случаях и управлять им. Данные устройства имеют связь между собой и могут работать совместно, тем самым получая определенное преимущество от кооперации. Как раз в этот момент наблюдается очевидная корреляция с теорией агентных систем, которая говорит о синергетическом эффекте от кооперации агентов [7, 8]. Однако же, проводя такую аналогию, невозможно не отметить определенную степень упрощения технологии в случае 1оТ. Преимущества от кооперации могут в широком смысле затрагивать многие сферы деятельности (так как широта распространения систем 1оТ сейчас достаточно велика). В число их входят как преимущества в достижении новой функциональности (чего не было раньше из-за недостатка технологии) - к примеру, системы оперативного мониторинга состояния продуктов в логистике, так и улучшение качества и удешевление существующих процессов [138] (к примеру, увеличение качества производственных процессов, связанное с превентивным обслуживанием оборудования). Таким образом, новизна технологии напрямую связана с ее определением - «вещи» в данном контексте относятся к ежедневным физическим

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

Среди определений, относящихся к Интернету вещей, также попадаются термины «глобальный», «вездесущий». Наряду с этим, встречается упоминание «всеобъемлющих» или «всепроникающих» систем, обладающих следующими характеристиками [94]:

1. Неявное построение. Системы сложно идентифицировать, они состоят из множества связанных модулей.

2. Сетевая модель взаимодействия. Устройства соединены единой коммуникационной инфраструктурой.

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

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

5. Распределенность. Наблюдается комбинированный (синергетический) эффект от распределенных данных и устройств.

6. Чувствительность к окружающей среде. Устройство осведомлено об окружающих устройствах и среде.

7. Адаптивность. Активность системы зависит скорее от внутренних решений, чем от вмешательства пользователя.

8. Обработка естественного языка. С точки зрения взаимодействия с человеком, система способна обрабатывать сигналы естественного языка.

Некоторые источники идентифицируют системы Интернета вещей, явно указывая на задействованные технологии и протоколы: Интернет, Облачные Вычисления [84], КРГО8, 1Ру6 [92].

Отдел стандартизации телекоммуникаций Международного союза электросвязи определяет вещи в концепции 1оТ как «Объекты физического мира (физические вещи)

8 RFID (англ. Radio-frequency identification) - радиочастотная идентификация.

или информационного мира (виртуальные вещи), которые можно идентифицировать и интегрировать в сети связи» [25].

В то же время, официальное определение Интернета вещей, приведенное в Рекомендации МСЭ-Т Y.2060 [40], гласит, что «1оТ - глобальная инфраструктура информационного общества, обеспечивающего передовые услуги за счет организации связи между вещами (физическими или виртуальными) на основе существующих и развивающихся совместимых информационных и коммуникационных технологий».

«Вещью» в данном контексте называется как физический объект, так и объект виртуального (информационного) мира (например, программа), которые могут быть идентифицированы и объединены через коммуникационные сети. Схема взаимодействия физических и виртуальных вещей показана на Рисунке 1 [40].

Рис. 1. Взаимодействие физических и виртуальных вещей [40]

При написании данной диссертации будем считать Интернет вещей

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

1.2. Текущее состояние и стандартизация систем Интернета вещей

Наибольшую популярность системы Интернета вещей приобрели в 2010-2017 годах, с удешевлением оконечных устройств, появлением технологий для безопасной и быстрой передачи данных, а также с развитием интернета и протоколов взаимодействия. Данные условия благотворно сказались на появлении большого числа относительно недорогих и простых оконечных устройств, которые в короткие сроки можно было собрать в готовое решение. При этом горизонт планирования до 202 5 года ведущих специалистов телекоммуникаций оценивается в 50 миллиардов вещей, подключенных между собой в сеть [141].

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

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

1. Стандартизация Интернета вещей9.

2. Стандартизация сетей последующих поколений10.

3. Системы телевидения на основе Интернета11.

В рамках инициативы IoT-GSI была приведена эталонная модель IoT, включающая горизонтальные уровни взаимодействия устройств (Рисунок 2).

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

9 IoT-GSI (англ. Internet of Things Global Standards Initiative) - Глобальная инициатива стандартизации Интернета вещей.

10 NGN-GSI (англ. Next Generation Networks Global Standards Initiative) - Глобальная инициатива стандартизации сетей следующих поколений.

11 IPTV-GSI (англ. IPTV Global Standards Initiative) - Глобальная инициатива стандартизации цифрового телевидения.

Рис. 2. Эталонная модель IoT согласно МСЭ-Т Y.2060 [40]

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

Наряду с МСЭ, достаточно большим влиянием обладает Европейский

12

интеграционный проект 1оТ-А [64], в который входят различные компании и целью которого является разработка архитектурной модели Интернета вещей.

Функциональная модель 1оТ-А отличается от модели МСЭ (Рисунок 3) и состоит из семи горизонтальных уровней и двух вертикальных.

Рис. 3. Функциональная модель IoT-A [64]

Internet of Things - Architecture (англ.) - Интернет вещей - Архитектура.

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

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

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

13

построении систем Производства 4.0 ввиду сложности и неоднозначности функциональной области, существуют отдельные стандарты, регламентирующие построение таких систем. В 2013 году Консорциумом Индустриального Интернета14 для систем IoT, относящихся к Промышленному Интернету вещей был разработан документ под названием «Industrial Internet Reference Architecture »15 [97] - стандарт, регламентирующий уровни построения, сложность, технические детали и особенности

13 Industry 4.0 (англ.).

14 IIC (англ. Industrial Internet Consorcium).

15 Референциальная архитектура Промышленного Интернета (англ.).

внедрения подобных систем на производстве. Указанный документ принимали к сведению большинство западных компаний при разработке систем 11оТ, что показало высокую применимость методологии на практике. В России описание некоторых технологий как предпосылок к созданию Промышленного Интернета вещей отслеживаются в работах Е. В. Судова [46, 47] и А. Ф. Колчина [17].

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

1.3. Классификация систем Интернета вещей

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

Одной из наиболее популярных практических классификаций систем 1оТ является классификация Postscapes16, которая делит все множество решений на семь различных категорий («Умный дом», «Умный транспорт», «Умное здравоохранение», «Умные продажи», «Умный транспорт», «Умный дом» и «Умное производство»). Некоторые исследования дополняют данную классификацию системами типа «Умный город» [151].

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

В качестве примера более общей классификации систем 1оТ, приведем

16 URL: http://postscapes.com/internet-of-things-award/2014/

разделение, предложенное компанией «Deutsche Telekom» 140]. В данном случае системы разделены на горизонтальные и вертикальные решения (Рисунок 4).

Рис. 4. Горизонтальные и вертикальные решения IoT [140]

К вертикальным относят решения, охватывающие все уровни архитектуры, начиная от датчиков и заканчивая оконечными приложениями, особенностью которых является ориентированность на конкретную область (в случае вертикального IoT-решения для энергетики, проект может содержать модули от датчиков до приложений мониторинга). В данном случае существуют компании, специализирующиеся на производстве решений для специфических областей промышленности (к примеру, SAP MII, решения для Умного транспорта [132] предлагаемые компанией «Google»).

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

17

работают системы «IoT Starter kits », призванные облегчить построение физического

уровня системы Интернета вещей. Платформы Интернета вещей, в первую очередь,

18

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

17 IoT Starter kits (англ.) - стартовый набор Интернета вещей.

18 Open Systems Interconnection basic reference model - базовая эталонная модель взаимодействия открытых систем.

входят крупные промышленные холдинги, такие как «National Instruments», «SAP», «Siemens», «General Electric», «PTC», являются управление подключенными устройствами, поддержка протоколов взаимодействия устройств и оборудования, а также функции базовой аналитики и предоставление пользовательских интерфейсов по управлению/мониторингу. Отдельно можно выделить решения визуализации, которые разрабатываются специально для специфических систем IoT, а также решения, предоставляющие развернутые аналитические функции для сбора и манипуляции данными от устройств.

Классификация систем Интернета вещей, используемая в работе, была произведена на основании 20 открытых проектов, при этом не учитывались сведения об архитектуре и качестве указанных проектов. В соответствии с этим были выделены классификационные таксоны, на основании которых определялся тип системы Интернета вещей. Классификация показана на Рисунке 5.

Рис. 5. Классификационные таксоны предметной области

Указанные классификационные таксоны далее положены в основу продукционной системы выбора параметров качества. Соответственно, множество решений IoT разделяется в зависимости от типа устройств, их стационарности/мобильности, количества производителей, частоты добавления

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

1.4. Модели качества программных систем и важнейшие параметры качества систем Интернета вещей

В литературе существует достаточно большое количество источников, посвященных проблемам качества программного обеспечения: в работах L. Maurya [115], O. Preiss [127] рассматриваются общие вопросы качества систем, в то время как в своих исследованиях H. Kubicek [111], K. Kearney [106] и С. Weinstock [143] описывают достижение конкретных параметров в процессе разработки.

Так как в данном разделе описывается понятие качества программного обеспечения, необходимо, прежде всего, определить данное понятие. Наиболее применимым с практической точки зрения является определение качества ПО как системы параметров, которые могут быть оценены с помощью ряда метрик. Впервые такой подход был использован в работе [116], доработан в исследованиях [67, 71, 59, 119] и в итоге привел к появлению первого стандарта качества ПО ISO 9126 [99].

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

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

В дальнейшем указанный стандарт был существенно доработан и изменен. В конечном итоге, это привело к созданию в 2005 году следующего стандарта ISO 25000:2005 [10] и модели качества, называемой sQuaRE19. На основе данного стандарта в свою очередь был создан ГОСТ ISO/IEC 25010 2015 [10]. В данном стандарте были определены восемь основных характеристик качества ПО, указанные на Рисунке 6.

Качество системы/ программной продукции

Функцио- Уровень Совмести- Удобство Надежность Защищен- Сопро- Переноси-

нальная производи- использова-

мость ность вождаемость мость

пригодность тельности ния

Функцио- Временные Сосущест- Определя- Защищен- Конфиден- Модульность Адаптиру-

нальная характери- вование емость ность циальность Возможность емость

полнота стики Интеропе- пригодности Готовность Целостность многократ- Устанавли-

Функцио- Использова- рабельность Изучаемость Отказоус- Неподдель- ного ваемость

нальная ние ресурсов Управляемость тойчивость ность использования Взаимоза-

корректность Функцио- Потенциаль- Защищенность от ошибки Восстанав- Отслеживае- Анализируе- меняемость

нальная целесообраз- ные возмож- Эстетика интерфейса ливаемость мость мость

ности Подлинность Модифицируе-

ность Доступность мость

Тестируемость

Рис. 6. Характеристики качества ПО, стандарт ГОСТ ISO/IEC 25010 2015 [10]

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

Измерение указанных характеристик в большинстве случаев проводится с использованием метрик качества, не описанных в новом Стандарте, но широко освещенных в документах КОЛЕС 9126-1 [99], КОЛЕС 9126-2 [100], КОЛЕС 9126-3 [101], КОЛЕС 9126-4 [102]. Данные Стандарты, в частности, определяют разделение на внешние и внутренние метрики, а также метрики качества в использовании, которые измеряют эффекты применения программного обеспечения в определенной среде применения. Способ применения метрик описан в Технических отчетах,

19 Systems and software Quality Requirements and Evaluation - Требования и оценка качества систем и программ (англ.).

применяемых для любого вида программного обеспечения для любого приложения. Ниже приведено краткое описание характеристик.

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

- Функциональная полнота. Степень, до которой множество функций покрывают специфические задачи и цели пользователей.

- Функциональная корректность. Уровень, до которого система предоставляет корректные результаты с заданным уровнем точности.

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

Производительность. Показывает эффективность использования ресурсов в ходе выполнения работы. В состав включают:

- Временные характеристики. Показывают, насколько ответ системы и время обработки запроса удовлетворяет заявленным требованиям.

- Использование ресурсов. Характеристика, показывающая, какие ресурсы и в каком количестве используются системой.

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

Совместимость. Показывает эффективность взаимодействия системы с другими системами (подсистемами). Состоит из следующих подхарактеристик:

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

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

Удобство использования. Определяет эффективность продукта для конкретного пользователя (насколько продукт/сервис помогает достичь цели). Включает характеристики:

- Определяемость пригодности. Уровень, до которого пользователи могут распознать продукт и его применимость для конкретной задачи.

- Изучаемость. Характеристика, показывающая, насколько система может быть понятна и быстро освоена новыми пользователями.

- Управляемость. Уровень, до которого система является легкой в управлении.

- Защищенность от ошибки. Степень, до которой система защищена от пользовательских ошибок.

- Эстетика пользовательского интерфейса. Уровень удобства взаимодействия с пользователем.

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

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

- Защищенность. Уровень, до которого система, продукт или компонент удовлетворяют характеристикам надежности в обычном состоянии.

- Готовность. Уровень, до которого система доступна каждый раз, когда приходит запрос на использование.

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

- Восстанавливаемость. Уровень, до которого система может восстановиться после сбоя с сохранением пользовательских настроек/данных. Защищенность. Уровень защищенности системы от внешних/внутренних атак и

неавторизированного доступа. Включает характеристики:

- Конфиденциальность. Характеристика, показывающая, насколько данные защищены от неавторизированных пользователей.

- Целостность. Уровень, с которым система поддерживает целостность данных.

- Неподдельность. Характеристика, показывающая, насколько авторство действий в системе невозможно подменить.

Список литературы диссертационного исследования кандидат наук Ядгарова Юлия Владимировна, 2020 год

СПИСОК ЛИТЕРАТУРЫ

1. Алгулиев Р., Махмудов Р. Интернет вещей //Информационное общество. - 2013. -№. 3. - С. 42-48.

2. Алефельд Г., Херцбергер Ю. Введение в интервальные вычисления. - 1987.

3. Арчибальд Р. Управление высокотехнологичными программами и проектами. Учебное пособие. - ДМК Пресс, 2010.

4. Беккер Й. Менеджмент процессов. - Эксмо, 2007.

5. Бородин В. А. Интернет вещей - следующий этап цифровой революции //Образовательные ресурсы и технологии. - 2014. - №. 2 (5).

6. Городецкий В. И. и др. Прикладные многоагентные системы группового управления //Искусственный интеллект и принятие решений. - 2009. - №. 2. - С. 3-24.

7. Городецкий В. И. Самоорганизация и многоагентные системы. I. Модели многоагентной самоорганизации //Известия Российской академии наук. Теория и системы управления. - 2012. - №. 2. - С. 92-92.

8. Городецкий В. И. Самоорганизация и многоагентные системы. II. Приложения и технология разработки //Известия РАН. Теория и системы управления. - 2012. - №. 3.

- С. 55-75.

9. ГОСТ Р ИСО/МЭК 7498-1-99 «Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель».

10. ГОСТ Р ИСО/МЭК 25010-2015 «Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения. Модели качества систем и программных продуктов».

11. Гусс С. В. Элементы повторного использования для программных систем учебного назначения. Концептуальное проектирование и анализ //Математические структуры и моделирование. - 2009. - №. 2 (20).

12. Гусятников В. Н., Безруков А. И. Стандартизация и разработка программных систем. Учебное пособие. - 2013.

13. Евгенев Г. Б. Системология инженерных знаний //М.: Изд-во МГТУ им. Баумана.

- 2001. - Т. 376.

14. Евгенев Г. Б. Технология создания многоагентных прикладных систем //Одиннадцатая национальная конференция по искусственному интеллекту: Труды конференции. - 2008. - Т. 2. - С. 306-312.

15. Жарков М. А., Кучерявый А. Е. Основные положения системы сигнализации ОКС № 7 для сети связи Российской Федерации //ЦНТИ «Информсвязь». - 1996.

16. Карпунин А. А., Ганев Ю. М., Чернов М. М. Методы обеспечения качества при проектировании сложных программных систем //Надежность и качество сложных систем. - 2015. - №. 2 (10).

17. Колчин А. Ф., Овсянников М. В., Стрекалов А. Ф. Управление жизненным циклом продукции [и др.]. - 2002.

18. Кондратьев А. А., Тищенко И. П., Фраленко В. П. Разработка распределенной системы защиты облачных вычислений //Программные системы: Теория и приложения. - 2011. - Т. 2. - №. 4.

19. Корченко А. Г. Построение систем защиты информации на нечетких множествах //К.: МК-Пресс. - 2006. - Т. 320.

20. Кох Р., Яновский Г. Г. Эволюция и конвергенция в электросвязи. - М.: Радио и связь, 2001.

21. Кулямин В. В. Методы верификации программного обеспечения //Всероссийский конкурсный отбор обзорно-аналитических статей по приоритетному направлению «Информационно-телекоммуникационные системы. - 2008. - Т. 117.

22. Кулямин В. В. Технологии программирования. Компонентный подход //М.: Интернет-Университет информационных технологий. - 2007.

23. Куприяновский В. П., Намиот Д. Е., Куприяновский П. В. Стандартизация Умных городов, Интернета вещей и Больших Данных. Соображения по практическому использованию в России //International Journal of Open Information Technologies. - 2016.

- Т. 4. - №. 2.

24. Курейчик В.М., Вагин В.Н., Лебедев Б.К., Тарасов В.Б. Интеллектуальные системы. Коллективная монография // под ред. В.М. Курейчика - М.: Физматлит, 2005.

- 288 с.

25. Кучерявый А. Е. Интернет вещей //Электросвязь. - 2013. - №. 1. - С. 21.

26. Лаврищева Е. М., Петрухин В. А. Методы и средства инженерии программного обеспечения: Учебник. - 2006.

27. Лаврищева Е. М., Рожнов А. М. Концепция аналитической оценки характеристик качества программных компонентов. - 2004.

28. Левин В. И. Дискретная оптимизация в условиях интервальной неопределенности //Автоматика и телемеханика. - 1992. - №. 7. - С. 97-106.

29. Левин В. И. Интервальное дискретное программирование //Кибернетика и системный анализ. - 1994. - Т. 30. - №. 6. - С. 91-103.

30. Левин В. И. Сравнение интервалов и оптимизация в условиях неопределенности //Вестник Тамбовского университета. Серия: Естественные и технические науки. -2002. - Т. 7. - №. 3.

31. Логинов Е. Л. «Интернет вещей» как аттрактор объективной экономической реальности //Национальные интересы: приоритеты и безопасность. - 2010. - №. 18.

32. Лысенко И. А., Смирнов А. А., Полищук Л. И. Исследование процесса разработки программного обеспечения инфотелекоммуникационных систем //Системи озброення i вшськова техшка. - 2014. - №. 4. - С. 103-106.

33. Норенков И. П., Кузьмик П. К. Информационная поддержка наукоемких изделий. СДЬ Б -технологии. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - С. 320.

34. Орлов С. А., Цилькер Б. Я. Технологии разработки программного обеспечения. Учебник для вузов. 4-е издание. Стандарт третьего поколения. - Издательский дом "Питер", 2012.

35. Палюх Б. В. и др. Интеллектуальная система поддержки принятия решений по управлению сложными объектами с использованием динамических нечетких когнитивных карт //Программные продукты и системы. - 2013. - №. 4.

36. Палюх Б. В., Кемайкин В. К., Дорожкин А. Д. Надежность программных средств экономических информационных систем. - 2008.

37. Пивень А. А., Скорин Ю. И. Тестирование программного обеспечения //Системи обробки шформаци. - 2012. - №. 4 (1). - С. 56-58.

38. Попов Н. Проектирование информационных систем //М.: Форум. - 2009.

39. Рассел С., Норвиг П. Искусственный интеллект. Современный подход. - ИД Вильямс, 2006.

40. Рекомендация МСЭ-Т Y.2060. Будущие сети: целевые установки и цели проектирования, http://www.itu.int/ru/ Pages/default.aspx 2011 [электронный ресурс]. -26 с.

41. Росляков А. В., Ваняшин С. В., Гребешков А. Ю. Интернет вещей. - 2015.

42. Рудаков А. В. Технология разработки программных продуктов //Рудаков АВ - М.: Академия. - 2005.

43. Рыжко А. Л. и др. Экономика информационных систем: учебное пособие //М.: Финансовый университет. - 2014. - С. 41.

44. Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения //М.: БИНОМ. - 2008. - Т. 368. - С. 6.

45. Судаков Р. С. Надежность и эффективность в технике: справочник //М.: Машиностроение. - 1989. - Т. 6. - С. 111.

46. Судов Е. В. и др. Технологии интегрированной логистической поддержки изделий машиностроения //М.: ООО Издательский дом «ИнформБюро». - 2006. - Т. 232.

47. Судов Е. В. Интегрированная информационная поддержка жизненного цикла машиностроительной продукции. Принципы. Технологии. Методы. Модели. - ООО Издательский дом "МВМ", 2003. - С. 264-264.

48. Таганов А. И. Методика анализа и сокращения рисков проектов сложных программных систем по характеристикам качества //Вестник Рязанского государственного радиотехнического университета. - 2010. - №. 31. - С. 77-82.

49. Тарасов В. Б. Агенты, многоагентные системы, виртуальные сообщества: стратегическое направление в информатике и искусственном интеллекте //Новости искусственного интеллекта. - 1998. - №. 2. - С. 5-63.

50. Тарасов В.Б. Концепция метаКИП: от компьютерно -интегрированного производства к Internet/Intranet-сетям предприятий //Программные продукты и системы. - 1998. - №3. - С. 19-22.

51. Терехов А. Н. и др. Объектно-ориентированная методология разработки информационных систем и систем реального времени //Объектноориентированное визуальное моделирование. - 1999. - С. 4-20.

52. Толкачев С. А., Михайлова П. Ю., Нартова Е. Н. Цифровая трансформация производства на основе промышленного интернета вещей //Экономическое возрождение России. - 2017. - №. 3. - С. 79-89.

53. Федотов А. М. Методологии построения распределенных систем //Вычислительные технологии. - 2006. - Т. 11. - №. Избранные доклады X Российской конференции "Распределенные информационно-вычислительные ресурсы" ' (DICR-2005), Новосибирск 6-8 октября 2005 г. - С. 3-16.

54. Федюкин В. К. Управление качеством производственных процессов: Учебное пособие //М.: КноРус. - 2013. - Т. 232.

55. Черняк Л. Интернет вещей: новые вызовы и новые технологии //Открытые системы. СУБД. - 2013. - №. 4. - С. 14-18.

56. Abowd G. D., Allen R., Garlan D. Formalizing style to understand descriptions of software architecture //ACM Transactions on Software Engineering and Methodology (TOSEM). - 1995. - Т. 4. - №. 4. - С. 319-364.

57. Addo I. D. et al. Reference architectures for privacy preservation in cloud-based IoT applications //IJSC. - 2014. - Т. 2. - №. 4.

58. Albrecht A. J., Gaffney J. E. Software function, source lines of code, and development effort prediction: a software science validation //IEEE transactions on software engineering. - 1983. - №. 6. - С. 639-648.

59. Arthur L. J. Measuring programmer productivity and software quality. - John Wiley & Sons, Inc., 1985.

60. Bachmann F. et al. Designing software architectures to achieve quality attribute requirements //IEE Proceedings-Software. - 2005. - Т. 152. - №. 4. - С. 153-165.

61. Bandyopadhyay D., Sen J. Internet of things: Applications and challenges in technology and standardization //Wireless personal communications. - 2011. - Т. 58. - №. 1. - С. 49-69.

62. Barry B. et al. Software engineering economics //New York. - 1981. - Т. 197.

63. Bass L., Clements P., Kazman R. Software architecture in practice. - Addison-Wesley Professional, 2003.

64. Bassi A. et al. Enabling things to talk. - Springer-Verlag Berlin An, 2016.

65. Bengtsson P. O. et al. Architecture-level modifiability analysis (ALMA) //Journal of Systems and Software. - 2004. - T. 69. - №. 1-2. - C. 129-147.

66. Boehm B. et al. Cost models for future software life cycle processes: COCOMO 2.0 //Annals of software engineering. - 1995. - T. 1. - №. 1. - C. 57-94.

67. Boehm B. W. et al. Merritt.: Characteristics of Software Quality. - 1978.

68. Boehm B. W. Software engineering economics //IEEE transactions on Software Engineering. - 1984. - №. 1. - C. 4-21.

69. Boehm B. W., Brown J. R., Lipow M. Quantitative evaluation of software quality //Proceedings of the 2nd international conference on Software engineering. - IEEE Computer Society Press, 1976. - C. 592-605.

70. Bonomi F. et al. Fog computing and its role in the internet of things //Proceedings of the first edition of the MCC workshop on Mobile cloud computing. - ACM, 2012. - C. 13-16.

71. Bowen T. P., Wigle G. B., Tsai J. T. Specification of software quality attributes. -Rome Air Development Center, Air Force Systems Command, 1985.

72. Bralla J. G. Design for excellence. - McGraw-Hill Professional Publishing, 1996.

73. Buchanan R. Wicked problems in design thinking //Design issues. - 1992. - T. 8. - №. 2. - C. 5-21.

74. Caporuscio M., Inverardi P., Pelliccione P. Formal analysis of architectural patterns //European Workshop on Software Architecture. - Springer, Berlin, Heidelberg, 2004. - C. 10-24.

75. Cerf V., Kahn R. A protocol for packet network intercommunication //IEEE Transactions on communications. - 1974. - T. 22. - №. 5. - C. 637-648.

76. Ciraci S., Van Den Broek P. Evolvability as a quality attribute of software architectures //The International ERCIM Workshop on Software Evolution. - 2006. - C. 6-7.

77. Clements P. et al. Evaluating software architectures. - Beijing : Tsinghua University Press, 2003.

78. Coplien J. O., Bj0rnvig G. Lean architecture: for agile software development. - John Wiley & Sons, 2011.

79. Datta S. K., Bonnet C., Nikaein N. An IoT gateway centric architecture to provide novel M2M services //2014 IEEE World Forum on Internet of Things (WF-IoT). - IEEE, 2014. -C. 514-519.

80. Daya S. et al. Microservices from Theory to Practice: Creating Applications in IBM Bluemix Using the Microservices Approach. - IBM Redbooks, 2016.

81. Desai P., Sheth A., Anantharam P. Semantic gateway as a service architecture for iot interoperability //2015 IEEE International Conference on Mobile Services. - IEEE, 2015. -C. 313-319.

82. Dolan T. J. Architecture assessment of information-system families: A practical perspective. - 2003.

83. Eugster P. T. et al. The many faces of publish/subscribe //ACM computing surveys (CSUR). - 2003. - T. 35. - №. 2. - C. 114-131.

84. Fehling C. et al. Cloud computing patterns: fundamentals to design, build, and manage cloud applications. - Springer Science & Business Media, 2014.

85. Fielding R. T., Taylor R. N. Architectural styles and the design of network-based software architectures. - Doctoral dissertation: University of California, Irvine, 2000. - C. 151.

86. Garlan D., Shaw M. An introduction to software architecture //Advances in software engineering and knowledge engineering. - 1993. - C. 1-39.

87. Gillies A. Software quality: theory and management. - Lulu. com, 2011.

88. Gubbi J. et al. Internet of Things (IoT): A vision, architectural elements, and future directions //Future generation computer systems. - 2013. - T. 29. - №. 7. - C. 1645-1660.

89. Hâberle T. et al. The connected car in the cloud: a platform for prototyping telematics services //IEEE Software. - 2015. - T. 32. - №. 6. - C. 11-17.

90. Harrison N. B., Avgeriou P. Leveraging architecture patterns to satisfy quality attributes //European conference on software architecture. - Springer, Berlin, Heidelberg, 2007. - C. 263-270.

91. Harter D. E., Krishnan M. S., Slaughter S. A. Effects of process maturity on quality, cycle time, and effort in software product development //Management Science. - 2000. - T. 46. - №. 4. - C. 451-466.

92. Haubenwaller A. M., Vandikas K. Computations on the edge in the internet of things //Procedia Computer Science. - 2015. - T. 52. - C. 29-34.

93. Heemstra F. J. Software cost estimation //Information and software technology. - 1992. - T. 34. - №. 10. - C. 627-639.

94. Hoepman J. H. In things we trust? Towards trustability in the Internet of Things //International Joint Conference on Ambient Intelligence. - Springer, Berlin, Heidelberg, 2011. - C. 287-295.

95. Hofmeister C., Nord R., Soni D. Applied software architecture. - Addison-Wesley Professional, 2000.

96. IFPUG I. Function point counting practices manual, release 4.2 //International Function Point Users Group, USA-IFPUG, Mequon, Wisconsin, USA. - 2004.

97. Industrial Internet Consortium et al. The industrial internet reference architecture technical paper //Retrieved in April. - 2016.

98. ISO/IEC 15504-6. Information technology - Process assessment. 2013.

99. ISO/IEC 9126-1. Software engineering -Product quality-part1: Quality model. 2002.

100. ISO/IEC 9126-2. Software engineering -Product quality-part2: External metrics. 2002.

101. ISO/IEC 9126-3 Software engineering -Product quality- part3: Internal metrics. 2002.

102. ISO/IEC 9126-4 Software engineering -Product quality- part4: Quality In Use metrics. 2002.

103. Kagermann H., Lukas W. D., Wahlster W. Industrie 4.0: Mit dem Internet der Dinge auf dem Weg zur 4. industriellen Revolution //VDI nachrichten. - 2011. - T. 13. - №. 1.

104. Kan S. H. Metrics and models in software quality engineering. - Addison-Wesley Longman Publishing Co., Inc., 2002.

105. Kazman R. et al. The architecture tradeoff analysis method //Proceedings. Fourth IEEE International Conference on Engineering of Complex Computer Systems (Cat. No. 98EX193). - IEEE, 1998. - C. 68-78.

106. Kearney K. T., Torelli F. The SLA model //Service Level Agreements for Cloud Computing. - Springer, New York, NY, 2011. - C. 43-67.

107. Khan R. et al. Future internet: the internet of things architecture, possible applications and key challenges //2012 10th international conference on frontiers of information technology. - IEEE, 2012. - C. 257-260.

108. Klein M. H. et al. Attribute-based architecture styles //Working Conference on Software Architecture. - Springer, Boston, MA, 1999. - C. 225-243.

109. Krco S., Pokric B., Carrez F. Designing IoT architecture (s): A European perspective //2014 IEEE World Forum on Internet of Things (WF-IoT). - IEEE, 2014. - C. 79-84. [109]

110. Kruchten P. B. The 4+ 1 view model of architecture //IEEE software. - 1995. - T. 12. -№. 6. - C. 42-50.

111. Kubicek H., Cimander R., Scholl H. J. Organizational interoperability in e-government: lessons from 77 European good-practice cases. - Springer Science & Business Media, 2011.

112. Lundberg L. et al. Quality attributes in software architecture design //Proceedings of the IASTED 3rd International Conference on Software Engineering and Applications. -IASTED/Acta Press, 1999. - C. 353-362.

113. Ma H. D. Internet of things: Objectives and scientific challenges //Journal of Computer science and Technology. - 2011. - T. 26. - №. 6. - C. 919-924.

114. Maurya L. S. Comparison of software architecture evaluation methods for software quality attributes //Journal of Global Research in Computer Science. - 2010. - T. 1. - №. 4.

115. Maurya L. S. Comparison of software architecture evaluation methods for software quality attributes //Journal of Global Research in Computer Science. - 2010. - T. 1. - №. 4.

116. McCall J. A., Richards P. K., Walters G. F. Factors in software quality. volume i. concepts and definitions of software quality. - GENERAL ELECTRIC CO SUNNYVALE CA, 1977.

117. Medvidovic N., Taylor R. N. Software architecture: foundations, theory, and practice //Proceedings of the 32nd ACM/IEEE International Conference on Software EngineeringVolume 2. - ACM, 2010. - C. 471-472.

118. Ning H., Wang Z. Future internet of things architecture: like mankind neural system or social organization framework? //IEEE Communications Letters. - 2011. - Т. 15. - №. 4. -С. 461-463.

119. Oman P., Pfleeger S. L. Applying software metrics. - John Wiley & Sons, 1996. - Т. 46.

120. OSGi™ Alliance - The Dynamic Module System for Java [электронный ресурс]. URL: https://www.osgi.org/ (дата обращения: 25.09.1990).

121. Ouksel A. M., Sheth A. Semantic interoperability in global information systems //ACM Sigmod Record. - 1999. - Т. 28. - №. 1. - С. 5-12.

122. Pahl C., Giesecke S., Hasselbring W. An ontology-based approach for modelling architectural styles //European Conference on Software Architecture. - Springer, Berlin, Heidelberg, 2007. - С. 60-75.

123. Parnas D. L. On the criteria to be used in decomposing systems into modules //Software pioneers. - Springer, Berlin, Heidelberg, 2002. - С. 411-427.

124. Perry D. E., Wolf A. L. Foundations for the study of software architecture //ACM SIGSOFT Software engineering notes. - 1992. - Т. 17. - №. 4. - С. 40-52.

125. Pfleeger S. L., Atlee J. M. Software engineering: theory and practice. - Pearson Education India, 1998.

126. Pranam A. Software Development Methodologies //Product Management Essentials. -Apress, Berkeley, CA, 2018. - С. 65-74.

127. Preiss O., Wegmann A., Wong J. On quality attribute based software engineering //Proceedings 27th EUROMICRO Conference. 2001: A Net Odyssey. - IEEE, 2001. - С. 114-120.

128. Rellermeyer J. S. et al. The software fabric for the internet of things //The Internet of Things. - Springer, Berlin, Heidelberg, 2008. - С. 87-104.

129. Richards M. Software architecture patterns. - O'Reilly Media, Incorporated, 2015.

130. Sarkar C. et al. A scalable distributed architecture towards unifying IoT applications //2014 IEEE World Forum on Internet of Things (WF-IoT). - IEEE, 2014. - С. 508-513.

131. Serafeimidis V., Smithson S. Information systems evaluation in practice: a case study of organizational change //Journal of Information Technology. - 2000. - Т. 15. - №. 2. - С. 93105.

132. Shahraray B. et al. Enhanced view for connected cars: пат. 9403482 США. - 2016.

133. Shaw M. et al. Software architecture. - Englewood Cliffs: prentice Hall, 1996. - Т. 101.

134. Stirbu V. Towards a restful plug and play experience in the web of things //2008 IEEE International Conference on Semantic Computing. - IEEE, 2008. - С. 512-517.

135. Stone P., Veloso M. Multiagent systems: A survey from a machine learning perspective //Autonomous Robots. - 2000. - Т. 8. - №. 3. - С. 345-383.

136. Sundmaeker H. et al. Vision and challenges for realising the Internet of Things //Cluster of European Research Projects on the Internet of Things, European Commision. - 2010. - Т. 3. - №. 3. - С. 34-36.

137. Taratukhin V. V., Yadgarova Y. V. Industrial Internet Reference Architectures and Agent-Based Approach in Design and Manufacturing //Emerging Trends in Information Systems. - Springer, Cham, 2016. - С. 117-124.

138. Taratukhin V., Yadgarova Y. Towards a socio-inspired multiagent approach for new generation of product life cycle management //Procedia computer science. - 2018. - Т. 123. - с. 479-487.

139. Taylor R. N. The role of architectural styles in successful software ecosystems //Proceedings of the 17th International Software Product Line Conference. - ACM, 2013. -С. 2-4.

140. Vogt A. Industrie 4.0 / IoT Vendor benchmark 2017 [Электронный ресурс] // Industrie 4.0 / IoT Vendor Benchmark 2017 - Deutsche Telekom. URL: https://www.telekom.com/resource/blob/440774/298ffca551f45120f513eb47956c0b78/dl-experton-benchmark-report-data.pdf (дата обращения: 28.09.2019)

141. Waldner J. B. Nanocomputers and swarm intelligence. - John Wiley & Sons, 2013.

142. Weber R. H., Weber R. Internet of Things, vol. 12 //New York: Springer. - 2010. - Т. 10. - С. 978-3.

143. Weinstock C. B., Goodenough J. B. On system scalability, performance-critical systems //School of Computer Science Carnegie. - 2006. - Т. 103. - С. 104.

144. Weiss G. (ed.). Multiagent systems: a modern approach to distributed artificial intelligence. - MIT press, 1999.

145. Wooldridge M. An introduction to multiagent systems. - John Wiley & Sons, 2009.

146. Wortmann F., Fluchter K. Internet of things //Business & Information Systems Engineering. - 2015. - T. 57. - №. 3. - C. 221-224.

147. Xia F. et al. Internet of things //International Journal of Communication Systems. -2012. - T. 25. - №. 9. - C. 1101.

148. Yadgarova Y. V., Taratukhin V. V., Skachko E. N. Multi-agent product life cycle environment. Interoperability issues //International IFIP Working Conference on Enterprise Interoperability. - Springer, Berlin, Heidelberg, 2015. - C. 101-112.

149. Yadgarova Y., Taratukhin V. An Interoperable Cloud Environment of Manufacturing Control System //Enterprise Interoperability VII. - Springer, Cham, 2016. - C. 3-12.

150. Yang S. H. Internet of things //Wireless Sensor Networks. - Springer, London, 2014. -C. 247-261.

151. Zanella A. et al. Internet of things for smart cities //IEEE Internet of Things journal. -2014. - T. 1. - №. 1. - C. 22-32.

ПРИЛОЖЕНИЯ

1. Некоторые архитектурные шаблоны ПО, их достоинства и недостатки

В области стандартизации построения архитектурных стилей существуют стандарты ISO и IEEE. В работах [86, 129] описаны основные методы построения и стили архитектур ПО. В частности, в исследованиях M.Richards [129] наблюдается отсылка к шаблонам проектирования, которые являются в какой-то мере синонимом к архитектурным шаблонам.

Ниже приведен список основных используемых сейчас шаблонов архитектуры. Приведенные шаблоны наиболее хорошо задокументированы в литературе и в целом наиболее изучены:

• Архитектура «Клиент-сервер».

• Архитектура «Peer-to-peer».

• Архитектура «Каналы и фильтры».

• Событийно-ориентированная архитектура.

• Архитектура «Издатель-подписчик».

• Сервис-ориентированная архитектура (SOA).

• REST архитектура.

• Архитектура слоев.

• Архитектура «Микроядро» (архитектура плагинов).

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

1.1. Архитектура «Клиент-сервер»

Клиент-серверный стиль архитектуры [85, 86, 129] является хорошо известным и широко применяемым для разработки сетевых приложений. Один из множества приложений-клиентов инициирует запрос к приложению-серверу, который выполняет вычисления и выдает ответ. Достаточно распространенным примером клиент-

серверной архитектуры является веб-сайт. Веб-браузер (клиент) инициирует запрос к серверу. Сервер в свою очередь возвращает данные, которые затем интерпретируются браузером. Основные элементы данного шаблона показаны на Рисунке 36.

Рис. 36. Элементы шаблона архитектуры «Клиент-сервер»

Компонентами данного шаблона являются клиент и сервер. Ограничения:

Только клиент может инициировать соединение с сервером. Сервер может быть клиентом у других серверов. Клиенты не могут соединяться друг с другом. Преимущества:

Хорошая модифицируемость шаблона: общие сервисы необходимо модифицировать только в одном месте.

Хорошая доступность и модульность: централизованный контроль над ресурсами, который также может быть распределен между несколькими серверами.

Недостатки:

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

Снижение доступности в случае увеличения нагрузки на сервер. Сервер является потенциальной точкой отказа в приложении.

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

1.2. Архитектура «Peer-to-peer»

Данный архитектурный шаблон описан в [74, 86, 129].

В противоположность шаблону «Клиент-сервер», данный стиль содержит

48

компоненты, эквивалентные по структуре и функциям (пиры ). Все пиры в равной степени производят и потребляют данные (Рисунок 37).

Рис. 37. Элементы шаблона архитектуры «Peer-to-peer»

Ограничения:

Пиры соединены напрямую между собой, между ними нет промежуточных компонентов.

Пиры являются производителями и потребителями данных.

' Peer (англ.) - точка.

- Отсутствие центрального компонента. В то же время, может присутствовать один компонент, в функции которого входит предоставление метаданных о других пирах.

- Пиры являются автономными и управляют своей активностью. Они не контролируются центральным компонентом.

- Пиры могут быть добавлены и удалены из системы в любое время.

Преимущества:

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

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

- Масштабируемость и модульность: система может быть легко масштабируема добавлением новых пиров (модулей).

Недостатки:

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

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

1.3. Архитектура «Каналы и фильтры»

Данный архитектурный шаблон описан в источниках [85, 129]. Содержит компоненты под общим названием фильтры, которые трансформируют данные, полученные от других подобных элементов, и отправляют данные следующему фильтру в цепочке. Фильтры соединены друг с другом через т.н. каналы, которые представляют собой путь потока данных. Одни и те же фильтры могут быть дублированы в зависимости от нагрузки или использованы при построении других систем, как показано на Рисунке 38.

Рис. 38. Элементы шаблона архитектуры «Каналы и фильтры»

Каналы не производят трансформации данных.

Ограничения:

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

Фильтры независимы друг от друга, не разделяют состояние.

Фильтры могут выполняться параллельно.

Фильтры обрабатывают данные практически без задержек.

Преимущества:

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

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

- Доступность. Если хотя бы один фильтр в цепи выходит из строя, не работает вся связка.

1.4. Событийно-ориентированная архитектура

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

Первой версией указанного шаблона архитектуры была версия, состоящая из двух компонентов - потребителя и источника события. В начальной версии архитектура в основном использовалась внутри одного приложения, позволяя потребителям реагировать на определенные типы событий (Рисунок 39).

Рис. 39. Элементы событийно-ориентированной архитектуры (начальная версия)

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

Рис. 40. Элементы событийно-ориентированной архитектуры (современная версия)

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

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

В число элементов стиля входят:

- Источник события - инициирует событие и отправляет его шине событий.

- Шина событий - компонент, ответственный за распределение событий обработчикам.

- Обработчик события - компонент, который регистрируется в шине и получает уведомления, когда происходит определенный тип события.

Ограничения:

- Источник не знает количество, функции и структуру обработчиков.

- Обработчики независимы друг от друга.

Преимущества:

- Возможность переиспользования. Любой из элементов можно использовать многократно.

- Модифицируемость решения. Компоненты могут быть заменены без затрагивания связанных.

- Производительность. Возможность одновременно обрабатывать запросы несколькими обработчиками параллельно приводит к потенциально высокой производительности решения.

- Масштабируемость. Каждый обработчик может быть масштабируем независимо. Узким местом является только шина событий.

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

Недостатки:

- Сложность тестирования. Значительно повышается сложность тестирования асинхронных запросов и отслеживание их обработки при наличии нескольких обработчиков.

- Корректность работы. Из-за асинхронности поиск причин отказа может быть сложнее и как следствие - затяжной период поиска ошибки.

- Производительность. С точки зрения недостатков решения, шина увеличивает время отклика.

- Доступность. Шина событий является потенциальной точкой отказа.

1.5. Архитектура «Издатель-подписчик»

Шаблон упомянут в работах [83, 129]. В составе он содержит т. н. издателей, которые отправляют данные в сервис событий. Сервис событий, в свою очередь, предоставляет публикацию тем подписчикам, которые интересуются данной темой. В общем случае, существует три вариации публикации - тема, контент или тип.

Очевидно сходство между данным архитектурным стилем и стилем, определенным ранее (событийно-ориентированным). Между ними существует

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

Данный стиль был изначально разработан для того, чтобы разорвать связь между источником события и его потребителем. К примеру, в приложениях просмотра погоды получатель данных не особенно интересуется изначальным источником данных. Основные элементы шаблона приведены на Рисунке 41.

Рис. 41. Элементы событийно-ориентированной архитектуры (современная версия)

Компоненты архитектуры включают:

Издатель - производитель данных. Поставляет данные в сервис событий. Подписчик - потребитель данных. Регистрируется на определенный тип события в сервисе событий.

Сервис событий - содержит хранилище и управляющую логику для подписчиков. Является ответственным за уведомление подписчиков о событии.

Ограничения:

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

Преимущества:

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

поэтому могут быть изменены без влияния друг на друга.

Недостатки:

Производительность. Сервис событий добавляет сложности обработки и увеличивает время задержки системы.

Сложность отладки. Так же, как и в событийно-ориентированной архитектуре, усложняется обработка и отладка ошибок.

Доступность. Сервис событий является потенциальной точкой отказа.

1.6. Сервисно-ориентированная архитектура

Шаблон упомянут в [129].

Сервисно-ориентнированный стиль (SOA) содержит слабо связанные сервисы, которые обладают хорошо определенными интерфейсами и могут быть скомбинированы различными способами при построении приложения. Сервисы связываются друг с другом вне зависимости от платформы, на которой они построены. На Рисунке. 42 показаны основные элементы шаблона БОЛ.

Рис. 42. Элементы сервисно-ориентированной архитектуры

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

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

- Каталог сервисов - компонент, который содержит записи о зарегистрированных сервисах, их интерфейсах и местонахождении в системе.

- Потребитель сервиса - компонент, в данный момент нуждающийся в функциональности сервиса.

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

- Сервисы являются независимыми, не сохраняют и не дублируют состояние других сервисов.

- Поставщикам сервисов необходимо регистрировать свою функциональность в каталоге.

Преимущества:

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

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

Недостатки:

- Сложность реализации. Данный шаблон архитектуры сложнее для реализации, чем остальные стили.

- Сложность отладки и контроля. Изменение отдельных сервисов непросто отслеживать.

1.7. Архитектура слоев

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

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

|— Модуль 3 —|

* Г

Модуль 1 --1- Модуль 2 ■ 1

БД * J

Рис. 43. Элементы архитектуры слоев

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

Ограничения:

Каждый элемент программы является частью одного (и только одного) уровня. Как минимум существует 2 уровня.

Каждый уровень способен обращаться только к смежному.

Преимущества:

Модифицируемость. Слои могут изменяться при сохранении интерфейсов взаимодействия.

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

Недостатки:

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

Надежность. При отказе одного из уровней вся система также становится нерабочей.

1.8. Архитектура микроядра (плагинов)

Шаблон упомянут в работе [129].

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

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

Рис. 44. Элементы архитектуры микроядра

Компоненты архитектуры:

Микроядро - предоставляет минимально необходимую функциональность для системы.

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

Ограничения:

- Плагины независимы друг от друга и не могут связываться напрямую.

Преимущества:

- Хорошая модифицируемость. Плагины могут разрабатываться без влияния друг на друга.

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

Недостатки:

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

1.9. Архитектура микросервисов

Шаблон описан в [80].

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

Компоненты архитектуры: микросервисы. Ограничения:

- Микросервисы самодостаточны и могут работать при отсутствующих или неработающих зависимых сервисах.

Преимущества:

- Хорошая модифицируемость. Микросервисы достаточно легко модифицировать ввиду четкого разграничения функциональности.

Рис. 45. Элементы архитектуры микросервисов

Возможность переиспользования. Один и тот же сервис может предоставлять

функции множеству других сервисов.

Хорошая масштабируемость и изначальная модульность.

Изоляция ошибок изначально на приемлемом уровне в связи с независимостью сервисов.

Недостатки:

Сложность реализации. Сложность растет с ростом числа вовлеченных сервисов в приложение.

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

Безопасность и защищенность микросервисов ввиду распределенности в среднем ниже, чем у монолитных архитектур.

2. Основные тактики разработки и адресуемые параметры качества

Тактики доступности

Обнаружение

1 Пинг-эхо Компонент программы имеет возможность выполнить однократный опрос другого компонента. Ожидает ответ в течение определенного промежутка времени.

2 Пульсация Компонент программы периодически опрашивает другой компонент. При этом возможна передача данных.

3 Обработка исключений Компонент может определить, что произошло исключение, и семантически обработать его.

Восстановление

Голосование Выполнение одинаковых процессов на дополнительных модулях с одинаковыми внешними данными. Выход процессов отправляется компоненту, который фиксирует некорректное поведение.

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

Пассивная Существует копия системы, включающаяся в работу в случае сбоя

избыточность основного модуля.

Резервная копия Существует копия ландшафта системы, сконфигурированная с

ландшафта целью замены множества вышедших из строя компонентов.

Повторное восстановление

Повторное включение Компонент, в котором произошел сбой последний раз, включается

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

Контрольная точка / Запись состояния периодически или в ответ на определенное

точка восстановления воздействие.

Профилактика

Удаление из сервиса Возможность удалить компонент из работы с целью предотвратить возможный сбой.

Транзакционность Выполнение логически связанных шагов вместе.

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

Тактики модифицируемости

Локализация изменений

Семантическая Разбиение на модули и сохранение их семантической

согласованность согласованности.

Предупреждение Декомпозиция системы с учетом возможных грядущих

изменении изменений.

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

Абстракция общих Выделение основных общих сервисов в отдельные модули,

сервисов позволяющее модифицировать основные функции в одном месте.

Предотвращение пост-эффектов

Области видимости Декомпозиция компонентов в зависимости от зоны

ответственности и выделение области видимости модулей.

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

Ограничение связей Ограничение количества связей между модулями. Модуль может обмениваться данными только с ограниченным количеством других модулей.

Использование промежуточных компонентов Если два модуля зависят друг от друга, включение «посредника», ответственного за данную зависимость.

Отложенное связывание

Регистрация во время выполнения Регистрация работающих компонентов уже во время выполнения.

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

Полиморфизм Отложенное связывание вызовов методов.

Замена компонентов Возможность замены компонентов во время выполнения.

Соблюдение протоколов Регистрация независимых процессов по одинаковым протоколам во время выполнения.

Тактики производительности

Потребление ресурсов

Увеличение вычислительной эффективности Уменьшение вычислительной сложности алгоритмов.

Уменьшение накладных расходов Загрузка необходимых модулей и ресурсов только по мере необходимости.

Управление темпом событий Уменьшение частоты мониторинга и опроса переменных среды.

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

Управление ресурсами

Распараллеливание Параллельное выполнение процессов.

Копии данных Кэширование и синхронизация копий.

Улучшение доступных ресурсов Внедрение быстрых вычислительных ресурсов, сети, памяти.

Арбитраж ресурсов

Политика планирования Планирование загрузки сети, буферов и процессоров.

Тактики информационной безопасности

Соп ротивление атакам

Аутентификация пользователей Аутентификация паролем, сертификатом, и т.д.

Авторизация пользователей Присвоение ролей доступа и доступ к ресурсам на основании роли.

Сохранение конфиденциальности данных Кодирование данных и связей между ними.

Сохранение целостности Использование чек-сумм, хэшей данных.

Ограничение воздействия Ограничения на доступ к сервисам, модулям или хостам.

Ограничение доступа Применение демилитаризованных зон, брандмауэров.

Обнаружение атак

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

Восстановление после атаки - идентификация

Контрольный журнал Сохранение записи о каждой транзакции системы с идентификацией времени и автора изменений.

Восстановление после атаки - восстановление

Проверка доступности Повторяют тактики доступности.

Тактики способности к взаимодействию

Локализация

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

Управление интерфейсами

Оркестрация Использование механизма контроля за выполнением сервисов/компонентов - управление порядком вызовов и их координация.

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