Стадия реализации состояла заключалась в переносе структурной схемы хранилища данных непосредственно в РСУБД посредством запуска сгенерированного SQL-кода.

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

2.2.1 Выделение сущностей, атрибутов, ключей, связей

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

В процессе формализации предметной области БД созданы 2 базы данных: клиентская база данных customers, содержащая необходимую информацию о клиентах организации ООО "ПриветБанк" и база данных sip_response, в которой находится информация, необходимая для контроля вызова модулем sip_response, в рамках которого генерируется автоматизированный ответ на клиентский запрос.

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

1) значения всех атрибутов таблицы атомарны (неделимы);

2) каждый неключевой атрибут функционально полно зависит от первичного ключа таблицы;

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

4) отсутствуют многозначные зависимости, не являющиеся функциональными зависимостями;

5) любая зависимость определяется только его возможными ключами таблицы.

2.2.1.1 Проектирование клиентской базы данных

В рамках данной ВКР смоделирована БД организации, основным назначением которой является хранение данных о пользователях услугами организации и состоянии их учетной записи.

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

Статическая информация о клиентах банка находится в трех таблицах: customers, customers_accounts и auth. Таблица customers содержит уникальный ID клиентов банка, а также их имена, фамилии, отчества и дату рождения.

Несмотря на создание уникальных атрибутов вместе с таблицей, данные атрибуты будут храниться отдельно внутри последовательностей. Это особенность СУБД PostgreSQL - хранить ID записи только тогда, когда нужно разработчику.

Таблица customers_accounts содержит банковские счета, прикрепленные к клиентам банка. В данном случае присутствует связь "один ко многим", где связаны атрибут customer_id таблицы customers_accounts и атрибут id таблицы customers. Дополнительно каждый счет имеет свой уникальный ID, а также состояние баланса на банковском счете.

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

Сущность финансовых транзакций описана в таблице transactions. Каждая финансовая транзакция имеет собственный уникальный ID. Также в таблице записан партнер транзакции (это может быть другой банковский счет, оператор сотовой связи и т.д.), формат транзакции (cash-in, где баланс пополняется или cash-out где баланс уменьшается) и сумма транзакции.

Сущность доступных в банке программ описана в таблицах credits, deposits и pension_programs. В данных трех таблицах записана информация о доступных в банке кредитах, вкладах и пенсионных программах. Также в таблицах хранятся недоступные, однако используемые клиентами услуги. У каждой услуги есть собственный уникальный ID, название, описание, процентная ставка и временной срок (если это кредит или вклад). Доступ к данным подобного рода осуществляется в модуле sip_response без дополнительной аутентификации.

Связи между клиентами банка и услугами, которыми они пользуются описываются в БД customers как отдельные таблицы, где присутствуют связи "многие-ко-многим". Данные связи олицетворяют 3 таблицы: customers_credits, customers_deposits и customers_pensions. В данных таблицах рассматриваются связи пользовательских ID и ID банковских услуг, состояние баланса в рамках программы (например, оставшаяся сумма погашения кредита или накопившаяся сумма по вкладу), а также срок окончания действия услуги (если это не пенсионная программа).

Дополнительно БД customers также хранит данные, доступ к которым может быть предоставлен без аутентификации. Информацией, указанной в 2 таблицах news и exchange_rate, может воспользоваться любой полноправный гражданин, даже если он не является клиентом банка. Таблица news хранит последние новости банка, состоящие из даты и полноценного описания.

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

Дополнительно хотелось подчеркнуть, что в рамках ВКР происходила имитация не всей базы данных клиентов банка, а только той части, необходимой первой версии модуля sip_response для ответов на базовые пользовательские запросы.

2.2.1.2 Проектирование базы данных информационной системы

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

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

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

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

Комплекс метаданных состоит из 4-х таблиц: keywords, answers, templates и statements. Таблица keywords содержит список ключевых слов, которые могут быть связаны с запросами. Именно на основании ключевых слов система может определиться с тем, связан ли запрос с клиентской потребностью.

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

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

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

Связи между базой знаний и метаданными хранятся в отдельных 4-х таблицах requests_answers, requests_statements, requests_templates и requests_keywords. Именно в этих таблицах каждый запрос имеет связь с информацией, необходимой для точного ответа на запрос. Именно в подобных таблицах можно найти список ключевых слов, связанных с конкретным запросом или составные части, формирующие в совокупности ответ на запрос (таблицы requests_answers и requests_statements соответственно). В каждой таблице описывается связи сущностей БД "многие-ко-многим".

Также в БД sip_response описывается сущность журнала вызовов, описанная таблицей call_history. После каждого вызова пользователя, вне зависимости от результата записываются данные о звонке, обработанном модулем sip_response. В таблице содержится уникальный ID звонка, ID, отмеченный системой Asterisk в атрибуте call_agi_id, время завершения вызова, ссылка на сгенерированный аудиофайл ответа пользователю, ID запроса из таблицы requests, ID клиента из БД customers и статус ответа пользователю (успешно/не успешно/перенаправление в центр технической поддержки).

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

2.2.2 Проектирование диаграмм "сущность-связь"

Для наглядности предметной области спроектированы диаграммы БД "сущность-связь" с применением графических средств отображения модели. В качестве средства визуализации использован программный продукт EA 12. Сначала созданы таблицы проектируемой БД. Затем добавлены атрибуты с выделением первичных ключей и присвоением ограничения "NOT NULL" для некоторых атрибутов. Напоследок средствами EA проведена визуализация полученной базы данных с последующим нанесением связей между таблицами. В приложении Б показаны итоговые физические схемы двух БД: клиентской БД и БД модуля sip_response.

2.3 Выводы по разделу

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

3. Реализация информационной системы

В разделе приведено описание по формированию тестового окружения, реализация которого наиболее близка к среде целевой организации. Далее описывается создание баз данных, необходимых для работы модуля. Затем следует основная часть работы - реализация проекта sip_response как приложения, осуществляющего общение с платформой Asterisk через шлюзовой интерфейс AGI. Реализация проекта расписана по частям, каждая из которых охватывает отдельный модуль системы. После этапа реализации описан процесс непрерывного тестирования системы в совокупности с платформой IP-телефонии Asterisk. В заключение раздела подводится итог проделанной работы путем описания всех реализованных требований, описанных в первом разделе выпускной квалификационной работы, а также конкретный путь реализации и преимущества, которые несет в себе реализация работы модуля sip_response.

3.1 Формирование окружения для разработки системы

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

1) Операционная система. Основным требованием к окружению создание среды на базе операционной системы GNU/Linux в виду того, что платформа IP-телефонии Asterisk в данный момент может работать только на Linux системах.

Таким образом, средой программного окружения выбрана операционная система Debian 8 (Jessie). В данной операционной системе имеется пакетный менеджер apt, с помощью которого можно устанавливать необходимое ПО.

Тестирование функционала в локальной среде, как и сама разработка, проходила в рамках операционной системы Fedora 24, также построенной на ядре Linux. Основным различием между системами являлся пакетный менеджер. В ОС Fedora используется пакетный менеджер dnf. Однако данный факт не повлиял на работоспособность окружений, как и на сам процесс разработки.

2) СУБД. В рамках реализации модуля sip_response для формирования хранилища данных выбрана СУБД PostgreSQL. Выбор СУБД обоснован в разделе 2.2 данной ВКР.

3) Язык программирования. В рамках разработки модуля sip_response в качестве языка программирования выбран язык Python. Рабочим интерпретатором языка являлся интерпретатор версии 2.7 сделан принципиальный отказ от разработки под интерпретатор версии 3 ввиду отсутствия его поддержки интерфейсом Asterisk.

Выбор среди существующих решений для реализации интеграции модуля с существующим функционалом Asterisk состоял из девяти языков программирования: Bash, Java, Pascal, Perl, PHP, Python, Ruby, C и Haskell. В конечном итоге для разработки модуля sip_response был выбран язык Python по следующим причинам:

знание языка Python разработчиком модуля sip_response, что впоследствии значительно сократило время, отведенное на разработку;

простота языка и высокая скорость разработки;

поддержка обновленного интерфейса Asterisk;

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

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

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

4) Интерфейс системы IP-телефонии. В платформе IP-телефонии Asterisk существует возможность расширения существующего функционала за счет выполнения сторонних программ через шлюзовой интерфейс Asterisk (Asterisk Gateway Interface - AGI). Именно AGI выбрано в качестве интерфейса общения между интерпретатором Python и диалпланом Asterisk.

Реализация обмена данными с диалпланом Asterisk проведена через внешний модуль Python под названием pyst2. Процесс обмена данными в основном заключался в передаче состояния системы другой системе посредством переменных. Таким образом, логика работы каждого из компонентов модуля сохранялась только внутри модуля.

5) Среда разработки. Очень важным моментом являлся выбор среды для написания программного кода модуля sip_response. В итоге выбрана связка текстового редактора Sublime Text 3 с необходимыми расширениями для языка Python, а также терминал командной строки Linux, в которой запускался интерпретатор Python 2.7 для тестирования изменений.

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

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

Платформа Asterisk способна проигрывать аудиофайлы в процессе соединения с клиентом в формате gsm. Для конвертации аудио в формат gsm использовалась утилита sox, запускаемая программой на языке Python в виде выполнения системной командой. Утилита sox, приняв на вход аргумент формата файла, осуществляет его транскодирование в формат gsm, сохраняя результат в новом файле, который впоследствии проигрывается платформой Asterisk.

Для конвертации речи в текст через запрос к внешнему API речевого распознавания наиболее четко работает с аудиофайлами в формате wav. Для конвертации в формат wav использовалась утилита FFmpeg, запускаемая подключаемым Python-модулем pydub. Аналогично функция конвертации файла принимает на вход необходимый исходный формат файла и преобразует его в wav. Предполагалось использовать модуль pydub и в транскодировании в формат gsm, однако возникли проблемы с поддержкой gsm-кодеков утилитой FFmpeg.

7) Интерфейс СУБД. После выбора самой СУБД необходимо также выбрать интерфейс работы с базами данных, через который можно бы осуществить подключение к базе и проводить тестовые запросы. В качестве интерфейса к СУБД PostgreSQL был выбран модуль языка Python psycopg2.

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

Для выполнения данной задачи импортирован сторонний модуль Python SpeechRecognition, представляющий собой API для общения с внешними системами речевого распознавания. В качестве систем распознавания использованы две среды: Google Speech API и Wit. ai. Выбор данных систем обосновывается в разделе 3.3.3, где наиболее подробно описывается механизм речевой обработки данных.

9) Интерфейс конвертации текста в речь. В реализации модуля sip_response также выполняется процесс конвертации текста в речевой формат для формирования части полноценного ответа на клиентский запрос перед непосредственным слиянием частей в общий ответ. Для этого использована система Google Speech, позволяющая запрашивать обработку текста в голос на нескольких речевых языках. Взаимодействием с Google Speech управляет сторонний модуль Python gTSS (Google Text-to-Speech), позволяющий упростить процедуру конвертации текста в речь до двух-трех строчек программного кода.

Взаимодействие модуля sip_response с вышеперечисленными инструментами показано на диаграмме компонентов в приложении В. В разделе 2.1.2 наиболее подробно описаны процессы взаимодействия модуля sip_response с внешними системами.

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

В итоге данная проблема решена подготовкой шаблонов-аудиофайлов посредством нескольких запросов в Google Speech API через командную строку Linux. Итогом подготовки шаблонов стал отсортированный перечень аудиофайлов, относительные пути к которым прописаны в базе данных. На рисунке 3.1.2 представлена визуализация дерева аудиофайлов-шаблонов, доступных как для диалплана системы Asterisk, так и для модуля sip_response.

Рисунок 3.1.2 - дерево файловой системы аудиофайлов-шаблонов

Данное дерево файловой системы состоит из следующих узлов:

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

2) builtin - раздел, в котором хранятся конкретные фразы, которые будут являться частями полноценного ответа на пользовательский запрос; в свою очередь фразы отсортированы в файловой системе по трем категорям:

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

б) requests (для воспроизведения формата пользовательского запроса, выбранного системой для дальнейшей обработки);

в) templates (дополнительные фразы, которые могут быть включены и в категорию requests, и в категорию answers).

Все полноценные утилиты установлены через пакетный менеджер операционной системы Debian apt. Подключаемые модули языка Python установлены через менеджер зависимостей pip, предназначенный конкретно для установки модулей Python.

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

Также после ручной установки всех необходимых программ написан отдельный скрипт на языке Bash - языке командной оболочки Linux, который автоматически устанавливает все необходимые утилиты. Работа данного скрипта полностью протестирована и отлажена на новой "пустой среде", созданной запуском отдельного виртуального контейнера.

Далее описываются ключевые инструменты непосредственного самого процесса разработки и тестирования модуля sip_response.

3.1.1 Система контроля версий

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

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

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

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

В рамках разработки проект sip_response разделен на 3 ветки:

master - ветка со стабильным программным кодом;

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

intermediate - промежуточный программный код, который проходит через этап тестирование на окружении, аналогичном инфраструктуре организации, где работает как система IP-телефонии Asterisk, так и СУБД PostgreSQL.

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

3.1.2 Контейнеризация тестового окружения

На начальном этапе процесса разработки стояла проблема использования системы IP-телефонии для тестирования работы модуля sip_response. Система IP-телефонии является достаточно тяжеловесным программным обеспечением, которое трудно развернуть на локальной среде и еще труднее поддерживать его в рабочем состоянии. Именно поэтому принято решение развернуть полноценное тестовое окружение с необходимым ПО (в частности, с платформой Asterisk) внутри контейнера. Данное решение можно называть "контейнеризацией" тестового окружения.

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

Программным обеспечением для реализации контейнера на локальной машине, работающей на ОС Fedora 24, являлся такой продукт, как Docker. Docker - программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы, например LXC. Docker позволяет "упаковать" приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами.

Инструкция по созданию контейнера описывается как код в отдельном конфигурационном файле - Dockerfile. В качестве основного контейнера взят шаблон asterisk-testsuite из общего репозитория контейнеров Docker Hub. Контейнер asterisk-testsuite содержит не только установленную систему IP-телефонии Asterisk, но и тестовое окружение Asterisk testsuite, позволяющего запускать тесты, проверяющие работу платформы IP-телефонии как единого целого.

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

docker build - t asterisk-testsuite github.com/sboily/asterisk-testsuite. git

docker run - i - t asterisk-testsuite /bin/bash

docker ps - a

Листинг 3.1.2.1 - развертывание тестового окружения в Docker-контейнере

3.1.3 Выбор SIP-клиента

Под SIP-клиентом воспринимается программное обеспечение, способное подключаться к серверу IP-телефонии и поддерживать клиентские вызовы к этой системе. По своему существу SIP-клиенты действуют как обычные телефоны, только работают не по АТС, а по IP-сети, передавая данные по локальной или глобальной сети.

Основным назначением SIP-клиентом в разработке и тестировании модуля sip_response являлась имитация вызова к IP-телефонии от лица клиента как часть end-to-end тестирования. Таким образом, совершая вызов к системе IP-телефонии Asterisk, тестировался функционал системы, отдельные части и нововведения в программный код.

Выбор SIP-клиента для разработки основывался на ОС, поддерживаемых программой. Необходимо выбрать тот клиент, который работал бы на операционной системе Fedora. Всего рассмотрено порядка 10-15 клиентов. Задачу выбора усложняли отчетливо видимые недостатки инструментов. Например, утилита Zoiper не поддерживала проигрывание аудиофайлов системой Asterisk, а программа Jitsi могла работать только на Java 7 - устаревшей версии интерпретатора.

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

3.2 Реализация баз данных системы

В ходе разработки модуля sip_response реализованы две базы данных в рабочую СУБД PostgeSQL 9.5: клиентская БД customers и база данных модуля sip_response. Процесс реализации разбит на 4 этапа: создание баз данных, создание таблиц, добавление тестовых данных и тестирование запросов средствами языка программирования Python.

Создание баз данных осуществлено посредством подключения к командной строке PostgreSQL и ввода команды CRAETE DATABASE дважды: один раз для создания БД customers и один раз для создания БД sip_response.

Создание таблиц осуществлено посредством наката SQL-скриптов в базы данных, к которым происходило подключение через командную строку. введены команды исполнения скриптов, указанные в листинге 3.2.1, после чего интерпретатор командной строки PostgreSQL поочередно выполнял запросы CREATE TABLE, написанные в скриптах, создавая новые таблицы.

\i sql/create_tables_customers. sql

\i sql/create_tables_sip_response. sql

\i sql/insert_into_customers. sql

\i sql/insert_into_sip_response. sql

Листинг 3.2.1 - выполнение SQL-скриптов создания схемы БД

Далее сгенерированы тестовые данные посредством наката SQL-скриптов с SQL-операторами INSERT. Команды выполнения скриптов также доступны для просмотра в листинге 3.2.1.

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

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

Тестирование запросов к СУБД осуществлялось посредство запуска командной строки интерпретатора Python 2.7, импортированием модуля psycopg2 как интерфейса работы с PostgreSQL и запуском функции подключения к базам данных, имея необходимые данные для полноценного доступа. Дополнительно после этого протестированы отдельные запросы, чтобы проверить корректность их выполнения и понять принцип упаковки данных модулем psycopg2 для последующей обработки результатов запроса.

3.3 Разработка модулей системы

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

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

В случае разработки модуля sip_response выделено несколько подсистем:

1) диалплан платформы Asterisk extensions. conf;

2) основной модуль main. py как запускаемый файл;

3) подсистема речевой обработки данных recognition. py;

4) подсистема контроля вызовов control. py;

5) интерфейс работы с базами данных db_interface. py.

Каждая из подсистем отдельно описывается в следующих подразделах ВКР.

3.3.1 Разработка диалплана информационной системы

Любая операция, происходящая с соединением по каналу связи, управляется Asterisk исходя из настроек, указанных в файле диалплана. В операционных системах GNU/Linux полным названием файла диалплана является /etc/asterisk/extensions. conf. В контексте конфигурации диалплана для реализации модуля sip_response подразумевается:

1) запуск кода на Python в системе Asterisk;

2) последующая конфигурация логики диалплана для обмена данными с модулем.

Запуск стороннего программного кода решается посредством оформления специальных AGI-скриптов. Под аббревиатурой AGI подразумевается шлюзовой интерфейс Asterisk (Asterisk Gateway Interface), позволяющий расширять семантику диалплана Asterisk. Фактически модуль работает в виде отдельного приложения, где исполняемый файл main. py запускается встроенной функцией диалплана AGI. Интерфейс AGI может выполнять программы на многих языках программирования при наличии соответствующих библиотек, однако создателями Asterisk рекомендуется использовать язык Python, выбранный для разработки модуля.

Обмен данными между диалпланом и подсистемами модуля sip_response сконфигурирован путем использования стандартных функций диалплана. Основной концепцией будет передача данных в потоках stdin, stdout и stderr, что является основой межпроцессорного взаимодействия в операционных системах GNU/Linux.

На рисунке 3.3.1.1 показана блок схема, отображающая последовательность обработки вызова диалпланом системы Asterisk в соответствии с заданными условиями.

Рисунок 3.3.1.1 - блок-схема работы диалплана Asterisk

Конфигурация диалплана, описанная специфичным языком конфигурации DSL, разделена на несколько логических частей.

1) Создание пользователей.

2) Начало вызова.

3) Прием вызова и просьба озвучить запрос.

4) Опрос пользователя на корректность данных по распознаванию запроса.

5) Аутентификация пользователя.

6) Ответ на запрос пользователя.

7) Прерывание вызова.

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

3.3.2 Разработка основного модуля

Основным модулем системы является файл main. py. Именно этот файл совершает обмен данными между модулем sip_response и системой IP-телефонии Asterisk, а также выполняет базовые операции, запрашиваемые диалпланом. В основной модуль импортированы как внутренние подсистемы, являющиеся частью приложения, так и AGI-оболочка для общения с Asterisk - модуль pyst и модули стандартной библиотеки Python для работы с системой: sys, os и re.

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

Рисунок 3.3.2.1 - блок-схема работы модуля main. py

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

1) Обработка запроса.

2) Опрос пользователя на корректность распознанного запроса.

3) Аутентификация.

4) Генерирование ответа на пользовательский запрос.

5) Логгирование.

3.3.3 Разработка подсистемы речевой обработки данных

Основным назначением подсистемы речевой обработки данных является работа с аудиоданными, получаемыми и генерируемыми модулем информационной системы IP-телефонии sip_response. Функционал подсистемы разбит на несколько функций, вызываемых как основным модулем main. py, так и системой контроля вызова.

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

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

На данный момент функция работает следующим образом: все запросы по конвертации направляются в модуль pydub, который в свою очередь вызывает FFmpeg. Исключение составляет формат GSM, который преобразуется через утилиту sox.

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

Рисунок 3.3.3.1 - блок-схема работы процесса конвертации речевого запроса

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

В данном случае используется внешний Python-модуль gTTS, работающий с Google Speech API. Речь генерируется в том же формате, что и в популярном внешнем сервисе Google Translate. В данном случае при вызове функции просто запускается функция генерирования аудиоданных из API с последующей записью в бинарный файл. В итоге подсистеме контроля вызова на выход отдается ссылка на аудиофайл для дальнейшей генерации полноценного ответа.

4) Слияние файлов. Основной целью процесса слияния файлов является генерация полноценного связанного ответа пользователю посредством последовательного склеивания кусков файла, поступающих на вход функции. Для этого вызывается модуль pydub который в свою очередь посылает запрос на утилиту FFmpeg по слиянию файлов.

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

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

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

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

Рисунок 3.3.4.1 - блок-схема работы процесса поиска подходящего запроса

2) Аутентификация по пользовательским данным. На рисунке 3.3.4.2 показана блок схема, отображающая процесс аутентификации пользователя в соответствии с достоверностью запрашиваемых данных.

Рисунок 3.3.4.2 - блок-схема работы процесса аутентификации пользователя

3) Ответ на запрос пользователя. На рисунке 3.3.4.3 показана блок схема, отображающая процесс формирования полноценного ответа на пользовательский запрос.

Рисунок 3.3.4.3 - блок-схема работы процесса формирования ответа

4) Логгирование. Процесс логгирования состоит из 2-х операций: подключения к БД и выполнению INSERT-запроса с теми данными, которые поступили на вход от основного модуля.

3.3.5 Разработка интерфейса базы данных

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

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

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

3.4 Тестирование работы системы

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

Всего существуют несколько видов тестирования программного обеспечения: unit-тестирование, интеграционное тестирование, smoke-тесты, приемочно-пользовательское тестирование, тесты производительности, end-to-end тестирование, а также нагрузочное тестирование. В итоге на первых стадиях разработки решено использовать стратегию end-to-end тестирования (E2E). E2E-тестирование заключается в тестировании функционала программного продукта со стороны пользователя.

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

В ходе разработки проводилось непрерывное тестирование программного продукта. Вообще после реализации "каркаса" модуля sip_response разработка проводилась следующим образом:

1) переход на ветку testing в системе контроля версий;

2) написание функционала, контактирующего с внешними API без участия системы IP-телефонии Asterisk с возможностью добавления входных данных;

3) проверка функционала посредством запуска приложения с соответствующими входными данными; корректировка возникших ошибок в коде;

4) commit изменений в ветке testing переход на ветку intermediate с дальнейшим слиянием изменений из ветки testing коммандой git cherry-pick;

5) доведение исходного кода в ветке intermediate до рабочего состояния;

6) выкат изменений в git-репозиторий и дальнейшая загрузка изменений в тестовую среду IP-телефонии;

7) тестирование функционала путем тестового звонка в систему Asterisk;

8) выявление ошибок и корректировка исходного кода в локальной среде с дальнейшей загрузкой в git-репозиторий;

9) повтор шага 7 до тех пор, пока код из ветки intermediate не станет полноценно работать;

10) слияние работающих изменений в ветку master;

11) проверка работы ветки master; корректировка появившихся ошибок;

12) регистрация изменений; закрытие поставленной задаче в личном to-do листе; переход к новой задаче, возвращаясь к шагу 1 итерации разработки.

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

В дальнейшем при совершенствовании программного продукта планируются написать отдельные тесты на языке Python, которые будут прогоняться автоматически при загрузке commit-а в удаленный Git-репозиторий.

3.5 Реализация требований к модулю

При постановке задачи на внедрение/разработку ИС определены следующие требования:

1) функциональные требования;

2) требования к безопасности;

3) требования к удобству использования;

4) требования к производительности;

5) требования к срокам внедрения;

6) требования к ПО для сопровождения проекта;

7) требования к расходам на сопровождение проекта.

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

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

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

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