7. Выходные данные должны посылаться так же в другие сервисы согласно разработанным стандартам взаимодействия, реализованные в программной системе.
8. Данная программа должна быть совместима с другими сервисами программной системы, посредством поддержки стандартов взаимодействия.
9. Функциональные требования представлены на диаграмме прецедентов (рис.Рисунок 1.4).
Полное описание прецедентов приведено в приложении А.
Рисунок 1.4. Диаграмма прецедентов
Сервис должен обеспечить возможность выполнения перечисленных ниже функций:
1. Создание/удаление/изменение корпусов текстов.
2. Добавление/удаление/изменение документов в корпусы.
3. Добавление информации о пользователе (регистрация пользователя).
4. Удаление/изменение информации о пользователе.
5. Получение информации о пользователе.
6. Получение информации о документе.
7. Получение информации о корпусе.
8. Поиск документов в базе.
9. Поиск документов по ключевым словам.
Полные требования к системе приведены в приложении B.
Глава 2. Проектирование хранилища текстов
На этапе проектирования сервиса описываются алгоритмы всех функций, разрабатывается архитектура системы, проектируются реляционная и нереляционная базы данных, а также описываются спроектированные классы. На данном этапе выбираются инструменты разработки сервиса для хранения корпусов.
2.1 Проектирование работы сервиса
При проектировании работы сервиса были созданы диаграммы активностей для каждой функции контракта сервиса.
Добавление информации о пользователе (регистрация нового пользователя) представлено на рисунке Рисунок 2.1.
Рисунок 2.1. Добавление нового пользователя
Изменение информации о пользователе представлено на рисунке Рисунок 2.2.
Рисунок 2.2. Изменение информации о пользователе
Удаление информации о пользователе представлено на рисунке Рисунок 2.3.
Рисунок 2.3. Удаление информации о пользователе
Получение информации о пользователе представлено на рисунке Рисунок 2.4.
Рисунок 2.4. Получение информации о пользователе
Добавление информации о корпусе (создание нового) представлено на рисунке Рисунок 2.5.
Рисунок 2.5. Добавление информации о корпусе
Изменение информации о корпусе представлено на рисунке Рисунок 2.6.
Рисунок 2.6. Изменение информации о корпусе
Удаление информации о корпусе представлено на рисунке Рисунок 2.7.
Рисунок 2.7. Удаление информации о корпусе
Получение информации о корпусе представлено на рисунке Рисунок 2.8.
Рисунок 2.8. Получение информации о корпусе
Удаление документа представлено на рисунке Рисунок 2.9.
Рисунок 2.9. Удаление информации о документе
Изменение документа представлено на рисунке Рисунок 2.10.
Рисунок 2.10. Изменение информации о документе
Получение документа представлено на рисунке Рисунок 2.11.
Рисунок 2.11. Получение информации о документе
Поиск документа по ключевым словам представлен на рисунке Рисунок 2.12.
Рисунок 2.12. Поиск документа по ключевым словам
Поиск документов по названию представлен на рисунке Рисунок 2.13.
Рисунок 2.13. Поиск документов по названию
Для функции добавления документа было выполнено проектирование работы сервиса в виде диаграммы активностей (рис. Рисунок 2.14).
Рисунок 2.14. Добавление документа
2.2 Проектирование баз данных
На основе поведенного анализа были выделены сущности предметной области. Результаты представлены в виде ERD на рисункеРисунок 2.15.
Рисунок 2.15. Диаграмма сущность-связь
Были выделены следующие сущности и атрибуты:
1. Пользователь с информацией о ФИО, электронной почтой, логине и пароле пользователя.
2. Корпус с информацией о названии корпуса.
3. Документ, содержащий оригинальный файл, плоский текст, аннотацию, строку HTML-разметки и название.
Информация о пользователях и корпусах содержится в реляционной СУБД (рис. Рисунок 2.16), а также ключи нереляционной части хранящихся документов в корпусах (DocumentId), названия документов и оригинальный файл.
Рисунок 2.16. Схема реляционной базы данных
Работа с реляционной базой данной осуществляется с помощью Entity Framework, ниже представлена получившаяся модель (рис. Рисунок 2.17).
Рисунок 2.17. Entity Designer Diagram
В документо-ориентированной базе данных хранится информация о документах. Так как документы в документо-ориентированных СУБД не имеют четкой структуры, была определена примерная схема информации, которая будет храниться в формате JSON (рис. Рисунок 2.18).
Рисунок 2.18. Примерная структура документа в документо-ориентированной базе данных
Гибкость структуры позволит хранить любую дополнительную информацию о документе помимо определенной выше.
Древовидная структура для хранения индексов на основе естественно-языковой адресации также может храниться в документо-орентированной базе данных в виде файлов с серилизованными объектами.
2.3 Диаграмма классов
Следующим этапом проектирования стало создание диаграммы классов (рис. 2.19). Диаграмма классов контракта сервиса включает в себя классы для работы с выделенными сущностями: User, Document, Corpus, а также интерфейс сервиса.
Рисунок 2.19. Диаграмма классов
ICorporaStorageServise - интерфейс-контракт сервиса (CorporaStorageServise), описывающий доступные другим сервисам операции:
1. AutorizeUser(string Login, string Password) : User - возвращает информацию о пользователе по логину и паролю.
2. GetCorpora(int UserId) : Corpus[] - возвращает список всех корпусов пользователя.
3. GetDocuments(int CorpusId) : Document[] - возвращает список всех документов в корпусе.
4. GetDocument(int Document) : Document - возвращает информацию о документе.
5. MakeCorpus(string Name, Document[] documents) : int - создает общий корпус с выбранными документами (можно создать и пустой корпус, передав пустой массив).
6. MakeCorpus(string Name, Document[] documents, int UserId) : int - создает частный корпус с выбранными документами (можно создать и пустой корпус, передав пустой массив).
7. AddUser(User user) : int - регистрация нового пользователя.
8. UpdateUser(User user) : void - изменение информации о пользователе. По старому идентификатору обновляются все поля.
9. DeleteUser(int userId) : void - удаление информации о пользователе по идентификатору. При этом происходит удаление всех корпусов пользователя.
10. AddDocument(Document document) : int - добавление нового документа.
11. UpdateDocument(Document document) : void - изменение документа. По старому идентификатору обновляются все поля.
12. DeleteDocument(int documentId) : void - удаление документа по идентификатору.
13. UpdateCorpus(Corpus corpus) : void - изменение корпуса. По старому идентификатору обновляются все поля.
14. DeleteCorpus(int corpusId) : void - удаление корпуса по идентификатору. При этом происходит удаление всех документов корпуса.
15. FindDocuments(string Name, int corpusId) : Document[] - поиск документа по имени.
16. FindText(string Text) : Document[] - поиск фрагмента по документам.
Диаграмма классов (рис. Рисунок 2.20.) сервиса включает в себя вспомогательные классы для работы с базами данных: UserModel, DocumentModel, CorpusModel - классы для работы с реляционной базой данной с помощью Entity Framework; AzureDocument - класс для работы с документо-ориентированной базой данных.
Класс реализации сервиса помимо реализации контракта имеет различные вспомогательные методы.
Рисунок 2.20. Диаграмма классов реализации сервиса
Классы для работы с индексацией (рис. Рисунок 2.21) на основе естественно-языковой адресации включают в себя классы структуры индексов: NLAStructure и NLAHeadDocument, которые включают в себя словарь ссылок на класс IndexStructureObject.
Рисунок 2.21. Диаграмма классов для работы с индексацией
Словарь (Dictionary) был выбран, так как его можно сериализовать в формате JSON, а также скорость доступа Dictionary не сильно уступает стандартной реализации хэш_таблицы (Hashtable), а для типов-значений скорость даже превосходит, так как в основе обоих структур лежит хеш-таблица [8, 16].
IndexStructureObject содержит следующий уровень структуры и/или ссылки на идентификаторы документов, в которых содержится соответствующее ключевое слово. Класс NLAStructureHelper содержит методы для добавления идентификатора документа к соответствующему ключевому слову, а также удаления идентификатора документа из всей структуры. Также в классе NLAStructureHelper содержаться вспомогательные методы.
2.4 Архитектура системы
При создании системы в отдельные функциональные блоки были выделены:
1. Компонент для стемминга текста.
2. Контракты сервиса.
3. Реляционная база данных
4. Нереляционная база данных.
5. Сам сервис.
Для описания архитектуры системы была создана диаграмма компонентов, представленная на рисунке 2.22.
Рисунок 2.22. Диаграмма компонентов сервиса-хранилища
CorporaStorageServise.svc - компонент реализации сервиса, который использует библиотеку с контрактом сервиса (CorporaStorageServiseContract.dll), то есть с описанием его интерфейса, а также общую библиотеку (CommonLibrary.dll), в которую войдут все необходимые для реализации стандартов взаимодействия классы.
Для хранения реляционных данных будет использоваться также располагаемая на сервисах Azure база данных SQL Azure (RelationDatabase), предоставляемая как сервис. DocumentDatabase - Cosmos DB, нереляционная база данных как сервис для хранения документов. Также используется сторонняя реализация стеммера по алгоритму стемминга Портера (Stemmer.dll).
2.5 Технико-экономическое обоснование
Стоимость разработки программы составит 40 486 рублей, а её расчет и обоснование выбранных инструментальных средств приведены в приложении C. Расчет стоимости проводился по методологии Work Breakdown Structure (WBS) или иерархическая структура работ. Данная методология была выбрана исходя из текущей стадии жизненного цикла программы, а также она не требует накопленной статистики. Данная методология обладает преимуществами для небольших проектов с небольшим количеством участников, а именно:
1. Не требует сильных затрат.
2. Позволяет увеличить производительность и контроль [25].
2.6 Итоги проектирования
На этапе проектирования были создана архитектура сервиса для хранения корпусов текстов, которая позволяет удовлетворить выдвинутые ранее требования к сервису. Во-первых, были выделены классы контракта сервиса, позволяющие взаимодействовать с ним. Во-вторых, были выделены классы для взаимодействия с базами данных, а также для реализации индексации на основе естественно-языковой адресации.
Выделенные методы контракта сервиса покрывают все функциональные требования. Также выделение контрактов в отдельные библиотеки позволяет использовать класс ChannelFactory при работе с сервисом.
Глава 3. Реализация сервиса для хранения корпусов
Сервис для хранения корпусов был реализован как WCF-сервис на языке C#, при этом в качестве интегрированной среды разработки программы была использована среда Visual Studio 2017.
3.1 Реализация CRUD-функций
При реализации CRUD функций были использованы API используемых баз данных (Cosmos DB и SQL Azure), а также технология Entity Framework и LINQ для работы с реляционной базой данных. Для увеличения производительности Entity Framework время жизни контекста ограничивался методом сервиса.
CRUD-функций для пользователя и корпуса, а также реляционная часть документа реализуются с помощью LINQ-запросов. Например, добавление пользователя происходит следующим образом (рис. Рисунок 3.1):
Рисунок 3.1. Добавление пользователя
При добавлении или изменении пользователя происходит проверка другого наличия пользователя с таким логином (рис. Рисунок 3.2):
Рисунок 3.2. Проверка наличия другого пользователя с таким логином
При этом, при удалении корпуса происходит удаление связанных с ним документов, а при удалении пользователя удаляются все личные корпусы.
Для нереляционной части документа используется предоставляемая Microsoft библиотека клиента Azure Cosmos DB, которая позволяет добавлять, удалять, изменять документы из коллекции, а также выполнять LINQ-запросы к документам. Например, добавление документа представлено на рисунке Рисунок 3.3.