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

Original article

Development of Architecture for Connecting a System Module for People with Disabilities

_              И, Alexey G. Tarasov

Introduction . To develop new system modules of software to help employees with disabilities, it is required to work out an architectural solution for the interaction of all parts of the system. As a result of the analysis and design, it is necessary to obtain a software architecture that must meet a number of standard requirements. First of all, it should be safe. To do this, you should take into account the error logging system, event auditing, the possibility of disabling the functionality immediately after putting it into commercial operation, internal mechanisms for validating client input requests and server responses. This study is aimed at the development of basic system maintenance options, the analysis of exception cases under interacting with the user for further evaluation of the architecture efficiency, and the direct project development.

Materials and Methods. The architectural decision was carried out using the Unified Modeling Language (UML), which helps to build visual images of the life cycle and interaction of all components of the system. The syntax of the UML deployment diagram was used to study the interaction of the main modules of the future system, and the syntax of the UML sequence diagram was used to process the lifecycle. A use case diagram was also applied to describe the main use cases. To study the interaction of the main modules of the future system, the UML deployment diagram syntax was used. For life cycle processing, the UML sequence diagram syntax was applied. In addition, a use case diagram was applied to describe the base use cases.

Results . An architecture that has a scheme for the interaction of individual modules and systems, as well as options for using the software package for the future implementation of the software product, has been developed. The proposed system architecture meets the requirements of security, reliability (fault tolerance), and performance. The authors have fixed the functional requirements of the system of assistance to employees of enterprises with hearing problems for the possibility of their employment and work on the telecommunication Internet. Basic variations of system maintenance have been developed.

Discussion and Conclusions. Building a competent architecture provides taking into account cases that go beyond the normal use of the system, and applying a fuzzy model to determine the system efficiency. Further in-depth description of deployment and operation options will enable to implement an efficient and productive system.

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

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

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

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

Информатика, вычислительная техника и управление

• –    кроссплатформенность — программный продукт должен охватывать основные операционные системы;

• –    отказоустойчивость — система должна стабильно работать в случае перебоев в работе;

• –    безопасность — система должна поддерживать логирование, мониторинг и аудирование событий пользователя;

• –    горизонтальную масштабируемость — при увеличении количества клиентов программный продукт должен работать с той же скоростью за счет увеличения количества серверов;

• –    производительность — система должна работать без задержек в режиме реального времени.

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

Материалы и методы. UML — это специальный язык моделирования, который применяется при разработке архитектуры вычислительных систем, программного обеспечения, сетевой архитектуры и при построении бизнес-процессов¹ [2, 3].

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

• 1.    Диаграмма последовательности (т. н. sequence diagram) — описывает процесс приема звонков и их обработки с точки зрения сотрудника организации².

• 2.    Диаграмма прецедентов (т. н. use case diagram) — описывает варианты использования системы.

• 3.    Диаграмма развертывания (т. н. deployment diagram) — описывает архитектуру системы.

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

exte^

extend extend

Звонок с заказом extend

Звонок с консуль- тацией оператором с нарушениям

Обработка жалобы здоровым оператором

Звонок с жалобой оператором с нарушениями

При обработке заказа оператор получил речевые субтитры

Обработка консультаций

Обработка заказа

Обработка заказа здоровым оператором

Рассмотрение жалобы ри обработке жалобы оператор не получил ечевые субтитры

При обработке заказа оператор не получил речевые субтитры

При обработке жалобы оператор получил речевые субтитры

Сотрудник

При обработке консультации оператор получил речевые

Прием и обработка входящего звонка

■A.^

extend

extend здоровым оператором

Обработка консультации оператором с нарушениями

При обработке консультации оператор не получил речевые субтитры субтитры

Рис. 1. Диаграмма вариантов использования системы (рисунок авторов)

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

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

Сотрудник

Интерфейс пользователя

Сервер сотрудника

База данных

Сервер клиента

Сервис аудита

Сервис логирования

Loop While отказ в доступе count < Авторизация

Авторизация

Запрос данных сотрудника

Данные сотрудника

	Данные сотрудника
Личный кабинет
Аlt
	Ошибка
Ошибка

Событие авторизация

Запрос канала связи для клиента

Принять звонок

Запрос канала связи

Субтитры

Субтитры

Аlt

Роботизированная система

Ошибка обработки

Ошибка обработки

Поток данных

Субтитры

Событие обработки голоса

Информация с логами

Сотрудник

Рис. 2. Диаграмма последовательности действий сотрудника (рисунок авторов)

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

Информатика, вычислительная техника и управление

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

Рис. 3. Диаграмма развертывания компонентов системы (рисунок авторов)

На рис. 3 представлена диаграмма развертывания проекта микросервисной архитектуры [4, 5], которая состоит из трех блоков.

Internet. В сети интернет расположены визуальные модули для взаимодействия пользователя и клиента (User Interface, UI). Стоит заметить, что каналы для реализации у клиента представлены тремя платформами: IOS, Android, Web, тогда как у сотрудника — только Web-каналом. В первую очередь, это связано с тем, что сотруднику обычно не требуется подобные приложения под мобильные операционные системы из-за характера работы и безопасности.

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

Узлы. Это комплексная система, состоящая из сервисов, взаимодействующих между собой. Основные из них — это сервис для получения запросов от клиента и сотрудника. Их задача получить запрос, обработать его и настроить взаимодействие между собой при помощи специальных компонентов — сокетов, которые позволяют обмениваться данными в режиме реального времени. Эти компоненты получают данные о клиенте и сотруднике из специальных сервисов, взаимодействующих с реляционной базой данных при помощи языка SQL [6]. Для отказоустойчивости и скорости база данных также имеет несколько узлов, но не менее двух. Все действия пользователя и клиента передаются в сервисы аудирования и логирования при помощи очередей сообщений. Это дает некоторые преимущества — асинхронность передачи данных и сохранность всей информации в случае отказа сервисов. При этом хранение такой информации нецелесообразно в реляционной базе в связи с однотипностью и простотой структуры. По этой причине желательно использовать документноориентированную СУДБ NoSQL [7, 8]3. Стоит заметить, что независимые базы данных в каждом из узлов обеспечивают высокую производительность, а консистентность и актуальность данных реализуется через механизм, репликации которого будут подробно описаны в следующих исследованиях. Механизм «Master-Slave» в реляционных и нереляционных базах данных необходим для возможного вертикального масштабирования и минимизации затрат ресурсов в случае увеличения нагрузки на отдельный узел.

Все запросы из сети Internet в локальную сеть происходят по протоколу HTTP следующими методами:

• -    GET — в случае получения информации от любого из модулей;

• -    POST — в случае создания записей в любом из модулей;

• -    PUT — в случае изменения в любом из модулей.

Запросы к сохраняемой информации происходят внутри транзакций для обеспечения целостности данных [9–11].

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

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