2. Функциональные требования

Для выполнения ВКР были сформулированы следующие функциональные требования:

1. Программа должна идентифицировать менеджеров и каждому уникальному пользователю выдавать отчет только по его организаторам.

2. Программа должна иметь возможность работать с данными в локальном хранилище.

3. Программа должна собирать данные из Elasticsearch DB.

4. Программа должна обрабатывать и сопоставлять данные из двух систем и создавать отчет на основе объединения данных.

5. Программа должна иметь возможность взаимодействия с мессенджером «Slack».

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

Модули разрабатываемого приложения:

• Модуль работы с локальным хранилищем.

Данный модуль используется для постоянного хранения и взаимодействия с информацией в локальной базе данных. Информация в общем виде представляет собой связь «Аккаунт-менеджер» - «Клиент». Если более детально рассматривать структуру, то БД должна хранить четыре поля данных: Id организатора, название организатора, имя закрепленного менеджера, аккаунт Slack закрепленного менеджера.

• Модуль работы с Elasticsearch.

Модуль используется для получения необходимой информации о продажах из хранилища Elasticsearch.

• Модуль формирования файла отчёта.

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

• Slack API Web-Requester (Модуль работы с API Slack).

Модуль осуществляющий работу со Slack API, отвечающий за прием, обработку и отправку сообщений, а также передачу файлов.

Глава 2. Проектирование

2.1 Выбор технологий

В качестве языка программирования был выбран язык C#, среда выполнения – MS Visual Studio 2015, а СУБД – LiteDB и Elasticsearch.

Для реализации модуля работы с локальным хранилищем было выбрано такое решение как LiteDB, в качестве базы данных и ORM. Модуль включает в себя два компонента: база данных и одноименная библиотека с набором методов для обращения к БД.

LiteDB (база данных) – является не реляционной базой данных (MongoDB-like database), для использования нет необходимости в дополнительных развертываниях на серверах, файл базы данных храниться на локальном хранилище.

LiteDB (библиотека) – представляет из себя файл формата *.dll и полностью разработанный на платформе .NET

LiteDB на данный момент является одним из самых популярных встраиваемых решений, наравне с SQLite. Поэтому при выборе, также, рассматривались SQLite, и просто локальное хранение файлов данных.

Основаниями для выбора LiteDB послужили такие факторы как:

• Скорость работы с данными. В сравнении с SQLite и локальным хранением данных, LiteDB обгоняет своих конкурентов в записи и чтении коротких файлов.

Таблица 1. Сравнение LiteDB, SQLite и локального хранения.

Тест: 1000 записей по 10-50 атрибутов. Время в миллисекундах
	SQLite	LiteDB	Локальное хранение
Чтение	200	193	1526
Запись	753	235	21712
Тест: 100 записей по 100-500 атрибутов. Время в миллисекундах
	SQLite	LiteDB	Локальное хранение
Чтение	22	23	398
Запись	733	233	3812
Тест: 10 записей по 1000-10000 атрибутов. Время в миллисекундах
	SQLite	LiteDB	Локальное хранение
Чтение	4	15	620
Запись	1759	510	602

• Удобство использования при разработке. При выдаче библиотеке объекта, сериализация объектов происходит автоматический, то же самое происходит и при десериализации.

• Возможность бесплатного использования в коммерческих целях

Так как системная и программная архитектура модуля работы с Elasticsearch DB была предложена куратором проекта. Использование Elasticsearch и ORM-системы было обусловлено имеющейся архитектурой продукта.

Nest – это клиент который обеспечивает взаимодействие с Elasticsearch. На низком уровне к ES происходит обращение по HTTP-протоколу. NEST позволяет в более простой форме формировать запросы к хранилищу данных и преобразовывать ответы в объектную модель, что позволяет сократить время разработки и отладки кода.

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

Для работы со «Slack» API принято решение об использовании фреймворка MargieBot, с добавлением своих методов, для обеспечения доступа к необходимому функционалу.

MargieBot – простой фреймворк для Slack, с открытым исходным кодом, написанный на C#.NET. Представляет из себя набор методов, облегчающих работу с базовыми элементами Slack API.

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

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