ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Journal influence

Higher Attestation Commission (VAK) - К1 quartile
Russian Science Citation Index (RSCI)

Bookmark

Next issue

2
Publication date:
16 June 2024

Model and algorithm of selecting software architecture for IoT systems

Date of submission article: 22.07.2019
UDC: 004.05
The article was published in issue no. № 4, 2019 [ pp. 682-689 ]
Abstract:The paper presents an analytical model for cost estimation and an algorithm for selecting a basic pat-tern of software architecture, as well as design tactics for the IoT (Internet of things) systems. It gener-alizes the concept of IoT technologies, reviews software systems quality parameters, emphasizes the main significant parameters applicable to IoT systems and proposes methods to achieve them. The nec-essary quality parameters of software systems are achieved by implementing the basic pattern of soft-ware architecture and related design tactics. The paper introduces the analytical model of dependency of project labor intensity on the used el-ements of software architecture. The project labor intensity is calculated according to the COCOMO II method. The search algorithm for the basic architecture pattern and design tactics is presented. The in-dicated algorithm is built on the basis of a local search when solving the problem of satisfying con-straints with minimizing the labor intensity function. Selecting a pattern, user preferences are also tak-en into account. The model and algorithm allow selecting the most appropriate architecture patterns and tactics for a particular type of project at early stages of their design. Indicated approach allows reducing errors in software architecture design at the initial stage of IoT-architecture pattern selection. The paper considers implementation of this approach in the project of flexible workspace management system development. It is advisable to use the approach to achieve the required system quality parameters and minimize errors when selecting software architecture at the ini-tial stages of the project, finally reducing the project cost. The approach can also be used to develop fully functional prototypes on a tight schedule.
Аннотация:В статье приведены аналитическая модель оценки стоимости и алгоритм выбора базового шаблона программных архитектур и тактик проектирования для систем Интернета вещей. Обобщено понятие IoT-технологий, сделан обзор параметров качества программных систем, выделены основные значимые параметры применительно к системам Интернета вещей, приведены методы их достижения. Необходимые параметры качества программных систем достигаются реализацией базового шаблона программной архитектуры и сопутствующих тактик проектирования. В работе представлена аналитическая модель зависимости трудоемкости проекта, рассчитан-ной по методике COCOMO II, от используемых элементов программной архитектуры. Приведен алгоритм поиска базового шаблона архитектуры и тактик проектирования. Указанный алгоритм построен на основе локального поиска при решении задачи удовлетворения ограничений с минимизацией функции трудоемкости, при этом в расчет принимаются предпочтения пользователя при выборе шаблона. Модель и алгоритм позволяют выбирать наиболее подходящие для конкретного типа проекта шаблоны архитектуры и тактики на ранних этапах проектирования. Указанный подход позволяет сократить ошибки в построении программной архитектуры на начальном этапе при выборе шаблона IoT-архитектуры. Рассмотрено применение данного подхода в проекте разработки системы гибкого управления рабочими пространствами. Применение подхода целесообразно для достижения требуемых параметров качества системы и минимизации ошибок при выборе программной архитектуры на начальных стадиях проекта, что в конечном итоге ведет к снижению его стоимости. Подход может также применяться при создании работоспособных прототипов в сжатые сроки.
Authors: Yu.V. Yadgarova (y.v.yadgarova@gmail.com) - Bauman Moscow State Technical University (Postgraduate Student), Moscow, Russia
Keywords: csp-task, architecture pattern, design tactics, quality parameters of software architecture, software architecture design, iot architecture, quality of IoT systems
Page views: 2773
PDF version article
Full issue in PDF (4.91Mb)

Font size:       Font:

Термин «Интернет вещей» был впервые упомянут в 1999 г. Кевином Эштоном [1]. В последние годы технологии Интернета вещей набирают популярность во многих сферах науки и техники, однако зачастую пользователи данной технологии не могут дать им четкое определение.

На международном уровне данная концепция приобретает сформировавшиеся черты, что можно проследить по появлению классификации типов подобных систем, стандартов взаимодействия устройств, а также по выделению фундаментальных характеристик технологии в соответствии с рекомендациями Международного союза электросвязи (МСЭ-Т). Однако в основе построения большинства типов систем IoT (Internet of things) так или иначе лежат принципы системного анализа.

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

Обзор публикаций

Наибольшую популярность системы Интернета вещей приобрели в 2010–2017 гг., когда удешевились оконечные устройства, появились технологии для безопасной и быстрой передачи данных, а также активно развивались Интернет и протоколы взаимодействия. Данные факторы благотворно сказались на появлении большого числа относительно недорогих и простых оконечных устройств, которые в короткие сроки можно было собрать в готовое решение. Наряду с простыми решениями на рынке стали появляться профессиональные системы с достаточно сложной и разветвленной логикой, к возникновению которых причастны уже целые компании и международные комитеты (например, Концепция промышленности 4.0 и Industrial Internet Consorcium, Консорциум промышленного Интернета).

Проблемы выбора и построения систем Интернета вещей наиболее полно описаны в зарубежной литературе. Среди основных исследований в данной области можно выделить работы [3–6]. Проблемы разработки систем Интернета вещей в России и теоретические основы данной технологии изложены в [7, 8], а перспективы становления технологии, а также потенциальные вопросы стандартизации, адресации и сетевых коммуникаций – в [9].

Некоторые исследователи сходятся во мнении, что для приложений Интернета вещей не может быть единого стандарта программной архитектуры, так как сам по себе термин не несет какую-либо контекстную информацию для принятия даже предварительных проектировочных решений [10, 11]. Однако в данной работе предпринята попытка опровергнуть такое мнение путем выявления общих нефункциональных требований к различным типам IoT-решений и создания средства поддержки проектирования для конкретных типов систем Интернета вещей. Подобная методика применительно к системам промышленного Интернета вещей была разработана Консорциумом индустриального Интернета. Среди опубликованных документов можно выделить [12] – стандарт, регламентирующий уровни построения, сложность, технические детали и особенности внедрения подобных систем на производстве. Указанный документ принимали к сведению большинство западных компаний при разработке систем промышленного Интернета вещей, что показало высокую применимость методологии на практике.

Модель выбора шаблона программной архитектуры

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

Полагаем, что критерием достижения параметра качества программной системы является реализация в выбранной архитектуре множе- ства тактик проектирования T = {ti}, i = 1, …, n, отвечающих за упомянутый параметр качества. При этом некоторые шаблоны программных архитектур по своему исходному построению удовлетворяют определенным параметрам качества. Данное условие представим булевой переменной xij, определяющей соответствие базового шаблона архитектуры i требуемому параметру качества j:

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

В качестве оценки трудоемкости среди множества аналитических методик оценки выбрана наиболее применимая к начальной стадии проекта – COCOMO II (англ. Constructive cost model – конструктивная модель стоимости) [13, 14].

Для решения задачи выбора шаблона архитектуры и тактик проектирования введем понятие вектора параметров качества системы. Им будем называть совокупность параметров качества, зависящую от типа системы и требований: St = S{i. t}, где i = 1, …, k – параметр качества; t = 1, …, n – тип системы. Каждый параметр качества характеризуется либо реализацией его в базовом шаблоне архитектуры, либо суммой тактик проектирования, необходимых для его достижения на базовом шаблоне: , где Tk – тактика проектирования; m – количество тактик, необходимое для реализации параметра; xij = 1, если реализация тактики проектирования для достижения не требуется, xij = 0 в обратном случае.

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

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

Трудоемкость проекта задается формально как функция зависимости от количества тысяч строк кода:

                            (1)

где Q – трудозатраты, выраженные в человеко-месяцах; EAF – фактор корректировки трудозатрат в зависимости от среды; α – фактор, зависящий от детальности оценки (постоянная величина, для предварительной оценки равная 2,94); , где SFj – факторы масштаба.

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

.

Выразим также трудоемкость разработки одного модуля через трудоемкость всего проекта: , где n – количество модулей в проекте. Тогда принимаем , где t – усредненное количество строк кода на один модуль. Переписывая выражение (1), получаем трудоемкость проекта:

Количество строк кода является величиной, зависящей от типа изменения шаблона. Фактор масштаба, используемый в настоящей зависимости, по сути, также зависит от типа изменения шаблона (так как риски, архитектура и т.д. зависят от типа изменения). В результате получаем ,                         (2)

где m – тип изменения шаблона по таблице 2.

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

Функция f = b(m) в данном случае представляет изменение фактора масштаба в зависимости от типа изменения шаблона. Рассматривая фактор масштаба по методике COCOMO II, получаем базовое значение: ,

где SFj – фактор масштаба.

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

Тогда, считая изменения факторов прецедентности от низкого до высокого, получаем фактор масштаба n(Добкш) = 1,49.

Получим результирующую функцию:

.

На рисунке показан график зависимости относительной трудоемкости от вариации tсв в диапазоне от 0,1t до t.

Аналогично высчитываются зависимости для остальных типов из таблицы 2.

Таким образом, общая трудоемкость проекта для выбранного базового типа состоит из базовой относительной трудоемкости реализации шаблона (выраженной через величину t) и суммы относительных трудоемкостей n тактик проектирования:

                        (3)

где m – тип изменения по таблице 2. Величина t зависит как от шаблона архитектуры, так и от реализации компонента и рассчитывается с помощью метода функциональных точек для каждого конкретного проекта. Таким образом, задача сводится к нахождению такой комбинации базового шаблона архитектуры и тактик, при которой относительная величина трудоемкости является минимальной: Q → min.

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

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

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

-     ограничения на качество: для достижения минимального уровня параметра качества реализация как минимум одной тактики проектирования, адресующей параметр качества;

-     ограничение предпочтения: в области построения архитектуры большую роль играют предпочтения (опыт) команды с определенным шаблоном/тактиками проектирования;

-     минимизация относительной стоимости решения, рассчитанной по методике COCOMO.

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

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

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

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

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

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

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

4. Для выбранной конфигурации вычисление относительной трудоемкости Q по методике COCOMO II.

5. Формирование окрестности путем выделения набора конфигураций с замененным элементом (тактикой или шаблоном). На данном этапе применяется эвристика с минимальными конфликтами.

6. Для элементов окрестности вычисление относительной трудоемкости по методике COCOMO II. Выбирается новая начальная конфигурация по условию Q ® min.

 

Результаты исследования и их обсуждение

 

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

Вектор параметров качества для систем Интернета вещей указанного типа будет включать надежность (Н), производительность (П), модифицируемость (Мод) и информационную безопасность (ИБ) как первичные параметры. Особенностью выбранного шаблона архитектуры является высокий уровень модифицируе- мости и способности к взаимодействию. При Таблица 4
Оценка шаблона архитектуры Брокер
Table 4
Evaluation of the Broker architecture pattern

Тактика	Тип изменения шаблона	Относительная 
стоимость
Увеличение вычислительной эффективности (П)	Модк	1,19t
Уменьшение накладных расходов (П)	Модк	1,19t
Управление темпом событий (П)	Добкш	3,857t
Распараллеливание (П)	Модк, Дубк	1,428t
Копии данных (П)	Дубк	0,238t
Улучшение доступных ресурсов (П)	Модк	1,19t
Политика планирования (П)	Добкш, Модк	5,047t
Пинг-эхо (Н)	Модк	1,19t
Обработка исключений (Н)	Модк	1,19t
Голосование (Н)	Дубк, Добкш	4,095t
Активная избыточность (Н)	Дубк	0,238t
Пассивная избыточность (Н)	Дубк, Модк	1,458t
Повторное включение компонента: затемнение (Н)	Дубк, Модк	1,458t
Аутентификация пользователей (ИБ)	Добкш	3,857t
Авторизация пользователей (ИБ)	Добкш	3,857t
Сохранение конфиденциальности данных (ИБ)	Модк	1,19t
Сохранение целостности (ИБ)	Модк	1,19t

этом для достижения вектора параметров каче- ства необходимо дополнительно реализовать тактики, адресующие надежность, производительность и безопасность. Список данных тактик с относительной стоимостью реализации (n = 5, а tмод. = 0,2t) частично представлен в таблице 4.

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

Заключение

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

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

Литература

1.    Sundmaeker H., Guillemin P., Friess P., Woelffle S. Vision and challenges for realising the Internet of Things. CERP IoT, 2010, 230 p.

2.    Рекомендация МСЭ-T Y.2060. Обзор Интернета вещей. 2012. 22 с. URL: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11559&lang=ru (дата обращения: 12.03.2019).

3.    Bass A., Bauer M., Fiedler M., Kramp T., van Kranenburg R., Lange S., Meissner S. Enabling Things to Talk. Springer-Verlag GmbH, 2013, 325 p.

4.    Xia F., Yang L.T., Wang L., Vinel A. Internet of things. Int. J. of Commun. Syst. 2012, vol. 25, no. 9, pp. 1101–1109. DOI: https://doi.org/10.1002/dac.2417.

5.    Weber R.H. Internet of things – new security and privacy challenges. Computer Law & Security Review, 2010, vol. 26, iss. 1. DOI: https://doi.org/10.1016/j.clsr.2009.11.008.

6.    Wortmann F., Flüchter K. Internet of things. Business & Inform. Syst. Eng., 2015, vol. 57, no. 3, pp. 221–224.

7.    Росляков А.В., Ваняшин С.В., Гребешков А.Ю. Интернет вещей. Самара: Изд-во ПГУТИ, 2014. 200 с.

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

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

10. Gubbi J., Marusicet S., Buyya R., Palaniswami M. Internet of Things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems. 2013, vol. 29, no. 7, pp. 1645–1660. DOI: 10.1016/j.future.2013.01.010.

11. Khan R., Zaheer R., Khan S.U., Khan S. Future internet: the internet of things architecture, possible applications and key challenges. Proc. FIT Conf., 2012, pp. 257–260. DOI: 10.1109/FIT.2012.53.

12. Lin S.W., Martin R.A., Miller B.W., Durand J. et al. Industrial internet reference architecture technical report. IIC, 2015.

13. Boehm B.W. Software engineering economics. Broy M., Denert E. (eds.): Pioneers and Their Contributions to Software Engineering, 2001, pp. 99–150. DOI: 10.1007/978-3-642-48354-7_5.

14. Boehm B., Horowitz E., Madachy R., Clark B., Westland J.C., Selby R. Cost models for future software life cycle processes: COCOMO 2.0. Annals of Software Engineering. 1995, vol. 1, no. 1, pp. 57–94. DOI: 10.1007/BF02249046.

References

  1. Sundmaeker H., Guillemin P., Friess P., Woelffle S. Vision and Challenges for Realising the Internet of Things. CERP IoT, 2010, 230 p.
  2. Recommendation MSE-T Y.2060. Internet of Things Review. 2012, 22 p. Available at: https://www.itu.
    int/ITU-T/recommendations/rec.aspx?rec=11559&lang=ru (accessed 12.03.2019).
  3. Bassi A., Bauer M., Fiedler M., Kramp T., van Kranenburg R., Lange S., Meissner S. Enabling Things to Talk. Springer-Verlag GmbH, 2013, 325 p.
  4. Xia F., Yang L.T., Wang L., Vinel A. Internet of Things. Int. J. of Commun. Syst. 2012, vol. 25, no. 9, pp. 1101–1109. DOI: 10.1002/dac.2417.
  5. Weber R.H. Internet of Things – New Security and Privacy Challenges. Computer Law & Security Review. 2010, vol. 26, iss. 1. DOI: 10.1016/j.clsr.2009.11.008.
  6. Wortmann F., Flüchter K. Internet of things. Business & Information Systems Engineering. 2015, vol. 57, no. 3, pp. 221–224. DOI: 10.1007/s12599-015-0383-3.
  7. Roslyakov A.V., Vanyashin S.V., Grebeshkov A.Yu. Internet Veshchey. Samara, PSUTI Publ., 2014, vol. 340, 200 p.
  8. Chernyak L. Internet of things: new challenges and new technologies. OSP. DMS. 2013, no. 4, pp. 14–18.
  9. Alguliev R., Makhmudov R. Internet of things. Information Society. 2013, no. 3, pp. 42–48.
  10. Gubbi J., Marusicet S., Buyya R., Palaniswami M. Internet of things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems. 2013, vol. 29, no. 7, pp. 1645–1660. DOI: 10.1016/j.future.2013.01.010.
  11. Khan R., Zaheer R., Khan S.U., Khan S. Future internet: the internet of things architecture, possible applications and key challenges. Frontiers of Information Technology. Proc. 10th Intern. Conf. IEEE, FIT, 2012, pp. 257–260. DOI: 10.1109/FIT.2012.53.
  12. Lin S.W., Martin R.A., Miller B.W., Durand J., et al. Industrial internet reference architecture. IIC, Tech. Rep. 2015. DOI: 10.13140/RG.2.2.18076.90249.
  13. Boehm B.W. Software engineering economics. Broy M., Denert E. (eds.): Pioneers and Their Contributions to Software Engineering, 2001, pp. 99–150. DOI: 10.1007/978-3-642-48354-7_5.
  14. Boehm B., Horowitz E., Madachy R., Clark B., Westland J.C., Selby R. Cost models for future software life cycle processes: COCOMO 2.0. Annals of Software Engineering. 1995, vol. 1, no. 1, pp. 57–94. DOI: 10.1007/BF02249046.

Permanent link:
http://swsys.ru/index.php?page=article&id=4656&lang=en
Print version
Full issue in PDF (4.91Mb)
The article was published in issue no. № 4, 2019 [ pp. 682-689 ]

Back to the list of articles