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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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