Модуль информационной системы IP-телефонии

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

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

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

6) Диаграмма компонентов (component diagram).

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

Диаграмму компонентов, разработанную в ходе выполнения данной курсового проекта, можно увидеть в приложении Б. В данной модели отмечено взаимодействие платформы IP-телефонии Asterisk со встраиваемым модулем sip_response. Главным компонентом платформы Asterisk является диалплан, принимающий клиентский запрос как речевой сигнал и воспроизводящий сгенерированный запрос как простой аудиофайл. После приема входных данных диалплан перенаправляет их на вход модулю sip_response, где в свою очередь поочередно активизируются подсистемы, обрабатывающие запрос в различном формате. Также в данной диаграмме описано хранилище данных модуля в качестве простого объекта, включающего в себя TCP-порт 3306, используемый для соединения с самой системой IP-телефонии.

2.5 Разработка модели хранилища информации

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

На стадии формализации была сформирована схема базы данных встраиваемого модуля Asterisk sip_response, распределены данные по таблицам в соответствии с теориями нормальных форм, выделены сущности, атрибуты, ключи, связи между таблицами - компоненты, формирующие БД. Стадия применения графических средств отображения модели была реализована инструментом визуального моделирования Sparx Enterprise Architect посредством добавления таблиц, атрибутов, формирования первичных и внешних ключей и визуализации конечной схемы БД. Стадия реализации состояла заключалась впереносе структурной схемы хранилища данных непосредственно в РСУБД посредством запуска сгенерированного SQL-кода. Стадия проверки заключалась в отображение диаграмм как анализируемой, так и отредактированной БД в графическом формате. При тестировании реализации хранилища данных в данном случае использовался веб-инструмент администрирования СУБД phpMyAdmin.

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

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

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

Таблицы спроектированы в соответствии с теорией пяти нормальных форм:

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

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

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

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

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

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

В соответствии с теорией нормальных форм информация об истории звонков была разделена на 4 таблицы: call_info (время и продолжительность звонка, ссылка на mp3-файл записи звонка), call_members (ID диктора, голос которого был использован во время звонка и личные данные клиента: имя, фамилия, место проживания), call_number (абонентский номер) и call_status (номер канала соединения и статус ответа на звонок). В таблицах 2.5.1.1-2.5.4.4 представлена структура вышеперечисленных таблиц, атрибуты, тип данных атрибутов, а также выделены атрибуты, играющие роль первичного ключа (PK) и внешнего ключа (FK).

Таблица 2.5.1.1 - Таблица БД call_info

call_id (int)	call_date (datetime)	duration (time)	call_record (varchar(30))
PK

Таблица 2.5.1.2 - Таблица БД call_status

call_id (int)	speaker_id (int)	channel_number (int)	status (varchar(20))
PK+FK (call_info)	FK (speakers)

Все таблицы, содержащие информацию о звонках, используют в качестве первичного ключа уникальный ID звонка. Таблицы call_status, call_member и call_number связаны с таблицей call_info через внешний ключ - столбец call_id (вид связи: один ко многим). Также стоит отметить, что телефонный номер разделен на три атрибута для соблюдения правила атомарности атрибутов. В атрибуте call_record содержатся ссылки на записи звонков, а не сами аудиофайлы, так как хранение медиафайлов в БД замедляет работу с ней.

Таблица 2.5.1.3 - Таблица БД call_member

call_id (char)	country_code (varchar)	operator_code (int)	phone_number (int)
PK+FK (call_info)

Таблица 2.5.1.4 - таблица БД call_number

call_id (int)	customer_fname (varchar)	customer_lname (varchar)	city (varchar)
PK+FK (call_info)

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



Таблица 2.5.1.5 - Таблица БД speakers

speaker_id (char)	speaker_fname (char)	speaker_lname (char)	gender (char)	birth_day (int)	birth_month (int)	birth_year (int)	speak_sample (varchar)
PK

Словарь модуля был разбит на 2 таблицы: dictionary_word (таблица слов) и dictionary_phrase (таблица фраз). В обоих таблицах роль первичного ключа играет связка двух атрибутов: ID диктора + слово. Данный первичный ключ был выбран по той причине, что ни одно значение в данных таблицах не является уникальным: как один диктор может произнести несколько фраз, так и одно слово может быть записано несколько раз разными дикторами. Однако связка этих атрибутов будет иметь уникальное значение. В таблице dictionary_word хранится ссылка на запись слова определенным диктором и транскрипция слова, наличие которой упростит распознавание речи клиента. В таблице dictionary_phrase отсутствует транскрипция, так как сложно распознать длинную звуковую последовательность; эта таблица хранит шаблонные фразы, часто произносимые операторами call-центра для упрощения процедуры генерации ответа на клиентский запрос. В таблицах 2.5.1.6-2.5.1.7 наглядно представлена структура вышеперечисленных таблиц.

Таблица 2.5.1.6 - Таблица БД dictionary_word

speaker_id (char)	word (char)	transcription (char)	word_record (char)
PK+FK (speakers)

Таблица 9 - Таблица БД dictionary_phrase

speaker_id (char)	phrase_name (char)	phrase_record (char)
PK+FK (speakers)

2.5.2 Проектирование диаграммы «сущность-связь»

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

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

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

1) разработанная модель хранилища данных модуля sip_response (с последующей реализацией, описанной в разделе №3), которую можно увидеть в приложении В;

2) сформулированный комплекс UML-диаграмм, отображающих концепцию проекта в формате, понятном как профессионалом предметной области, так и целевой аудитории модуля (руководители банков, интернет провайдеров, транспортных компаний и т.д.), который можно увидеть в приложении Б;

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



3. ПРОЕКТИРОВАНИЕ МОДУЛЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ IP-ТЕЛЕФОНИИ

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

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

3.1 Общие сведения о разработке информационной системы

Согласно ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» выделяют следующие основные стадии создания и этапы разработки автоматизированной системы (АС).

1) Формирование требований к АС.

2) Разработка концепции АС.

3) Техническое задание.

4) Эскизный проект.

5) Технический проект.

6) Рабочая документация.

7) Ввод в действие.

8) Сопровождение АС.

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

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

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

Рисунок 3.1.1 - диаграмма Ганта



3.2 Анализ хранилища информации системы Asterisk

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

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

Структура хранения данных Asterisk состоит из двух БД. Основная БД - asterisk - состоит из 220 таблиц и содержит общую информацию системы IP-телефонии, поступающей с диалплана (механизма, направляющего каждый звонок от источника в пункт назначения). Дополнительная БД - asteriskcdrdb - содержит CDR-записи. CDR - сервис, обеспечивающий журналирование работы телекоммуникационного оборудования.

Asteriskcdrdb хранит метаданные, описывающие каждую телекоммуникационную транзакцию, но не описывающие контент данной транзакции. В общей сложности это 48 атрибутов, разбросанных по двум таблицам (cdr и cel), содержащих оперативные данные, заполняющиеся динамически. Информативные атрибуты таблицы cdr: ID абонента (src), название используемого канала (channel), состояние ответа (disposition), начало, конец и длительность звонка (start, end, duration), количество оплачиваемых секунд (bill). Информативные атрибуты таблицы cel: имя и номер абонента (cid_name, cid_num), время начала звонка (eventtime), название приложения, используемого диалпланом (appname), имя стороннего канала (peer).

БД asterisk содержит как справочные данные, так и оперативные. Справочными данными является информация об администраторах и пользователях системы (таблицы admins и users), резервном копировании системы телефонии (таблица backup), информация о напоминаниях пользователям (таблица areminder), устройствах, подключенных к телефонии (таблица devices). Динамическими данными является информация о соединениях, использующих широковещательное соединение (таблицы broadcast, conferencespro), факс-соединениях (таблица fax), входящих звонках (таблица incoming) и полученных СМС-сообщениях (таблица sms_messages).

БД встраиваемого модуля, названная sip_response также содержит набор справочных и оперативных данных. Всего БД содержит 7 таблиц. Справочными данными является информация о дикторах, принявших участие в разработке модуля (таблица speakers), словари слов и фраз, из которых программа генерирует ответ пользователю (таблицы dictionary_word и dictionary_phrase). Динамическими данными является информация обо всех звонках, в которых был задействован модуль sip_response (таблицы call_info, call_status, call_members и call_number).

В приложении В включительно представлены графические схемы баз данных платформы Asterisk, визуализированные посредством инструмента администрирования СУБД MySQL phpMyAdmin. Также в данном приложении представлен отрывок SQL-кода, предназначенный для создания таблицы call_members.

3.3 Реализация хранилища информации модуля

В текущем ходе разработки модуля sip_response была протестирована реализация добавления базы данных модуля в рабочую СУБД.

База данных на основе SQL кода была создана с помощью командной оболочки bash.

Листинг 3.3.1 - создание базы данных в MySQL

cd /opt

mysql

CREATE DATABASE sip_response;

USE sip_response

mysql sip_response < database2.sql

После создания БД с последующим добавлением таблиц РСУБД MySQL появилась совокупность структурированных и связанных между собой таблиц, но данные до сих пор отсутствуют Следующей задачей является заполнение созданной БД значениями. Также необходимо создать запись о модуле в таблицы modules существующей БД asterisk.

Существуют 2 способа добавления записей в таблицы: с помощью команды INSERT и с помощью загрузки записей из текстового файла (команда LOAD DATA LOCAL INFILE). Первый способ более удобен для добавления небольшого количества записей (не больше 5), второй способ - для большого количества записей. В данной задаче наиболее целесообразным выглядит добавление записей из текстового файла. Для этого для каждой таблицы необходимо создать отдельный текстовый файл, записать в него данные в специальном формате (табуляция между значениями полей, NULL-значения обозначаются как '\N') и загрузить данные из файла в таблицу при помощи командной строки MySQL. Для добавления записи о модуле достаточно выполнения команды INSERT. Для начального заполнения базы данных были созданы 7 текстовых файлов. На рисунке 5 показан формат записи строк в файл.



Рисунок 5 - формат текстового файла для добавления значений в БД

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

Листинг 3.3.2 - SQL-скрипт заполнения БД

USE sip_response;

LOAD DATA LOCAL INFILE '/opt/call_info.txt' INTO TABLE call_info;

LOAD DATA LOCAL INFILE '/opt/call_members.txt' INTO TABLE call_members;

LOAD DATA LOCAL INFILE '/opt/call_number.txt' INTO TABLE call_number;

LOAD DATA LOCAL INFILE '/opt/call_status.txt' INTO TABLE call_status;

LOAD DATA LOCAL INFILE '/opt/speakers.txt' INTO TABLE speakers;

LOAD DATA LOCAL INFILE '/opt/dictionary_word.txt' INTO TABLE dictionary_word;

LOAD DATA LOCAL INFILE '/opt/dictionary_phrase' INTO TABLE dictionary_phrase;

USE asterisk;

INSERT INTO modules (modulename, version, enabled) VALUES (`sip_response', `0.1.0', 1);

На рисунках 6-7 показаны результаты работы команд. В общей сложности в каждую таблицу, хранящую информацию о звонках, добавлено по 20 значений, в таблицы-словари - по 10, в таблицу информации о дикторах - 5.

Рисунок 6 - результат работы команды LOAD DATA в таблице call_info (БД sip_response)



Рисунок 7 - результат работы команды INSERT в таблице modules (БД asterisk)

3.4 Формирование алгоритмов реализации компонентов модуля

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

Алгоритмы реализации программного модуля выбраны исходя из возможностей языка программирования Python, выбранного в качестве языка программного кода модуля sip_response. Главным инструментом является интерпретатор языка Python версии 3, установленный на гостевой операционной системе.

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

Архитектура модуля sip_response, исходя из его первоначальной концепции, складывается из трех составляющих: подсистема обработки речевых сигналов (файл recognition.py), подсистема контроля вызова (control.py) и диалплан Asterisk с добавленным функционалом проектируемого модуля.

3.4.1 Запускаемый файл модуля

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

В зависимости от входных данных происходит объявление переменных и вызов той или иной подсистемы. Например, если модуль имеет переменную со значением «request» и ссылку на аудиофайл с клиентским запросом в качестве входных данных, то он запускает подсистему идентификации обработки речевых сигналов, передавая ей ссылку на файл. Или если в качестве входных данных модуля будет переменная со значением hangup, то в исполняемом файле будет вызвана подсистема контроля вызова для протоколирования завершенного вызова. Для этого программа отправляет переменную, полученную из диалплана, на вход подсистемы.

Для обмена данными между модулем sip_response и диалпланом Asterisk используются методы библиотеки agilib - встроенной библиотеки Python, предназначенной для работы Python-скриптов в формате AGI.

3.4.2 Подсистема обработки речевых сигналов

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

1) прием от диалплана Asterisk записанного звукового файла с голосовым запросом клиента;

2) идентификация звукового сигнала в аудиофайле посредством алгоритма распознавания речи;

3) формирование текстового файла на основании распознанного речевого сигнала;

4) передача текстового файла на вход подсистемы контроля вызова.

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

Для идентификации звукового сигнала используется сторонний инструмент распознавания речи Google Speech. Google Speech - это прикладной программный интерфейс (API), созданный компанией Google и находящийся в свободном доступе. Основным предназначением Google Speech является конвертация речи из аудиоформата в текстовый формат посредством использования моделей нейронных сетей. Интерфейс Google Speech может распознать более 80 языков, в том числе и русский язык, на основе которого модуль sip_response обменивается информацией с клиентов.

Обмен данными между модулем sip_response и Google Translate (сервисом реализации Google Speech) осуществляется через HTTP-запросы. Для реализации запросов используется библиотека Python urllib2. Перед непосредственным осуществлением запроса аудиофайл преобразуется из формата gsm в формат flac для корректной работы Google Speech API. Ответ на запрос от Google Translate записывается в текстовый файл формата JSON с помощью встроенной библиотеки json. Затем из JSON-файла извлекается ответ и записывается в текстовый файл. Путь к текстовому файлу передается на вход подсистеме контроля вызова. Исходный код подсистемы обработки речевых сигналов содержится в исполняемом файле recognition.py. Псевдокод работы исполняемого файла recognition.py указан в приложении Г.

3.4.3 Подсистема контроля вызова

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

1) прием на вход текстового файла с обработанным клиентским запросом;

2) обработка запроса на предмет его корректности;

3) поиск нужных слов и словосочетаний из текстового словаря БД;

4) поиск информации из клиентской БД целевой организации;

5) формирование полноценных фразы как ответа на клиентский запрос;

6) генерирование голосового сообщения в виде звукового файла путем нахождения аналогов текстовых слов/словосочетаний в фонетическом словаре БД модуля;

7) отправление сгенерированного звукового файла на вход диалплану системы Asterisk для дальнейшего воспроизведения клиенту;

8) передача диалплану Asterisk сигнала о перенаправлении вызова клиенту в случае отсутствия подходящего ответа на запрос;

9) протоколирование вызова в специальную таблицу-журнал базы данных после окончания соединения, дополнительно записывая основные сведения о вызове, такие, как длительность, абонентские данные и т.д..

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

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

Формирование готового ответа в виде аудиофайла реализуется посредством объединения нескольких файлов, соответствующих словам и словосочетаниям из БД. Для самого объединения вызываются методы библиотеки audiolab - сторонней библиотеки языка Python.

Статус выполнения подсистемы возвращается главному файлу sip_response.py, запускаемому диалпланом Asterisk. В случае прерывания соединения запускается обработка ошибок, в которой предусмотрен возврат диалплану статуса «hangup», говорящего о том, что соединение завершено.

Исходный код подсистемы контроля вызова содержится в исполняемом файле control.py. Псевдокод работы исполняемого файла sip_response.py указан в приложении Г.



3.4.4 Конфигурация диалплана системы Asterisk

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

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

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

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

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

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



3.5 Экономическое обоснование эффективности модуля

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

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

Бюджет на реализацию проекта практически не составляет финансовых затрат. Система Asterisk, на которую нацелен модуль sip_response, является бесплатной и предоставлена в открытом доступе сети Интернет. Разработка и последующая модификация модуля ведется в операционной системе Fedora, основанной на ядре Linux и являющейся свободным программным обеспечением, доступным бесплатно. В ходе разработки также используются Open-Source решения, такие, как среда разработки PyCharm, система контроля версий Git, интерпретатор Python 3 и AGI-библиотека интеграции Python-программ в систему Asterisk. То же самое касается и тестовой платформы, где все программные продукты (ОС AsteriskNOW, СУБД MySQL, платформа виртуализации VirutalBox, утилита управления виртуальными машинами Vagrant) распространяются бесплатно. Программа Sparx Enterprise Architect 11, использованная для создание ER-диаграммы БД и проектирования UML-диаграмм, является платным программным обеспечением, но лицензия на данный продукт приобретена университетом для образовательных целей. Таким образом, использование EA не является платным с точки зрения реализации программного продукта. Также следует отметить, что программное обеспечение как продукт не облагается НДС, что уменьшает себестоимость проекта и упрощает процесс его окупаемости.

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

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

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

3.5.1 Расчет себестоимости модуля

Себестоимость -- это стоимостная оценка используемых в процессе производства продукции (работ, услуг) природных ресурсов, сырья, материалов, топлива, энергии, основных фондов, трудовых ресурсов и других затрат на её производство и реализацию.

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

Расчет стоимости времени, затраченного на реализацию программного продукта (З). З = 500 (оценка полного рабочего дня разработчика в рублях) x 120 (примерное количество полных рабочих дней, потраченных на создание проекта) = 60000 руб..

Расчет стоимости времени, затраченного на модификацию программного продукта, исходя из потребностей заказчика (М). М = 500 (оценка полного рабочего дня разработчика в рублях) x 5 (примерное количество полных рабочих дней, потраченных на создание проекта) = 2500 руб..

Расчет амортизации персонального компьютера (А1). А = 30000 (общая стоимость комплектующих ПК) / 5 (гарантия на пользование ПК, лет) / 3 (подсчет амортизации за количество полных рабочих дней, потраченных на создание проекта) = 2000 руб..

Расчет амортизации персонального компьютера за время, затраченное на модификацию программного продукта, исходя из потребностей заказчика (А2). А = 30000 (общая стоимость комплектующих ПК) / 5 (гарантия на пользование ПК, лет) / 72 (подсчет амортизации за количество полных рабочих дней, потраченных на создание проекта) = 83 руб..

Сумма дивидендов с реализации программного продукта (Д) = 3000 руб.

Расходы на сопровождение программного продукта за 6 мес. (С) = 15000 руб.

Полная себестоимость проекта (П): П = З + М + С +Ф + Д = 60000 + 2500 + 2000 + 3000 + 15000 = 82583 руб.

3.5.2 Расчет сроков окупаемости модуля sip_response

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

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

Э= З1 - З2, (1)

где:

З1 - элементы производственных затрат, связанные с использованием заменяемой информационной технологии (или традиционного способа решения задачи);

З2 - элементы производственных затрат, связанные с использованием новой информационной технологии.

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

Следовательно, З1 = 20000 * 10 * 12 + 5 * 20000 / 5 = 2500000 (руб.)

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

Следовательно, З2 = 82583 + 15000 = 97583 (руб.)

По формуле, эффект от использования модуля sip_response будет:

Э = З1 - З2 = 2500000 - 97583 = 2402417 (руб.)

Срок окупаемости программного продукта в количестве лет рассчитывается по формуле:

Ток = А0/Э, (2)

где:

А - затраты, связанные с созданием программного продукта;

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

Следовательно, Ток = 82500 / 2402417 = 0,034

Таким образом, срок окупаемости данного проекта составляет 0,034 лет, (примерно 12 дней).

3.5.3 Расчет точки безубыточности модуля sip_response

Точка безубыточности (break-evenpoint- BEP) - объем продаж, при котором прибыль предпринимателя равна нулю. Для того чтобы рассчитать точку безубыточности в натуральном выражении, необходимо использовать следующие показатели:

1) Постоянные затраты на объем (FC);

2) Цена единицы товара (услуги, работы) (P);

3) Переменные затраты на единицу продукции (AVC).

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

BEP=FC/(P-AVC) (3)

Условия расчета точки безубыточности (данные берутся за 1 год).

Цена товара (P) = 82583 руб.

Постоянные издержки (FC = A1 + З) = 62000 руб.

Переменные издержки (FC = С*2 + М + А2) = 32583 руб.

BEP=62000/60000 = 1.03

Таким образом, необходимо продать 1 экземпляр модуля sip_response, чтобы сработать в ноль. Превышение данного объема продаж приведет к получению прибыли.

3.6 Безопасность и надежность модуля

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

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

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

3.6.1 Анализ возможных угроз информационной безопасности

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

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

1) Спам по сети интернет-телефонии. С возможностью использования IP-сетей для телефонных разговоров появилась возможность наводнения систем IP-телефонии звонками с предложениями услуг продаж (подобно спаму в электронной почте) или обычных DDoS- атак.

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

3.6.2 Анализ модели противодействия угрозам ИБ системы Asterisk

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

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

2) Создание «черного списка» телефонных адресов. Стандартная конфигурация диалплана Asterisk поддерживает ведение специального «черного списка» для блокировки соединения с абонентскими номерами, найденными внутри него. Таким образом можно сформировать некое правило: если с определенного адреса поступает подозрительно много запросов на соединение или голосовое сообщение пользователя отмечено как спам, то номер абонента заносится в черный список.

3.6.3 Реализация функции надежности модуля

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

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

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

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

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

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

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

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

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

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

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

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

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



ЗАКЛЮЧЕНИЕ

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

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

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

3) разработка моделей проектируемой системы в виде UML-диагарам, нацеленных на отображение концепции проекта и его компонентов;

4) формирование алгоритмов, на основе которых реализуется исходный код модуля sip_response.

В ходе выполнения курсового проекта:

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

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

3) сформированы как общие, так и технические требования к проекту, итогом чего стало создание полноценного технического задания (результаты можно увидеть в приложении А);