Программная реализация работы

Реализация архитектуры приложения

Для реализации данного хранилища и работы с ним выбрана «Луковая» архитектура (Onion architecture).

Данная архитектура содержит следующие элементы:

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

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

Фабрика репозиториев, данная фабрика вызывает репозиторий, в котором хранятся данные, а также конкретную структуру базы данных. Т. е. если вы изначально использовали базу данных, которая реализована на платформе «Oracle», а потом реализовали базу данных на платформе «MS SQL Server», то вам необходимо будет только переписать методы, которые работают с базой данных, но не их сигнатуру.

Класс для работы с BLOB хранилищем, данный класс используется для работы с BLOB хранилищем, которое реализован специально для данной модели предметной области.

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

Репозитории для работы с базой данных, данная часть отвечает за то, как реализованы интерфейсы, т. е. как в реальности происходит работа с базой данных.

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

Хранилище больших двоичных объектов, которое расположено на облачной платформе «Microsoft Azure».

Реляционная база данных, которая расположена на облачной платформе «Microsoft Azure».

Фабрика юнитов, которая вызывает конкретную модель базы данных.

Клиенты, которые работаю с веб-приложением.

Реализация объектно-ориентированной модели На основе выявленных требований к структуре хранилища реализована следующая модель классов (см. Приложение Г). Как мы видим, класс «User» имеет ссылки на класс: «TextCorpus», «TextCorpusFile», «Annotation» и «Template» с определенными свойствами: «AccessType» и «UserType». Тип данных «AccessType» и «UserType» являются перечислениями. Перечисление «AccessType» может принимать значения: «Read», «Write», «ReadWrite». Перечисление «UserType» может принимать значения: «Guest» и «Owner».

Основываясь на работах С. Амер-Яхиа, М. Фернандез и других для создания динамически дополняемых атрибутов использовалась структура дерева, которое ссылается само на себя.

Каждый элемент «TreeElement» содержит:

Поле «Child», которое хранит ссылку на вложенный элемент дерева.

Поле «Next», которое хранит ссылку на следующий элемент дерева.

Поле «Value» хранит значение элемента дерева.

Поле «Attribute», которое ссылается на класс «AttributeName».

«AttributeName» хранит поле «Name» и может быть использован несколько раз при формировании элементов дерева или при формировании других деревьев. Данная структура использована для динамического добавления данных в «TextCorpus», «TextCorpusFile» и «Annotation».

Класс «TextCorpus» может содержать в себе несколько ссылок на классы «TextCorpusFile», но и каждый экземпляр класса «TextCorpusFile» может находиться в нескольких классах «TextCorpus», поэтому между ними стоит связь «ассоциация». Каждый «TextCorpusFile» может иметь несколько «Annotation», однако ни один класс «Annotation» не может быть построена без использования класса «TextCorpusFile», поэтому между ними стоит связь «композиция». Каждый класс «Annotation» должен быть построен с использованием нескольких классов «Template» или ни одного, тогда мы получим не маркированный текст, также мы можем добавлять и удалять из класса «Annotation» ссылки на класс «Template».

Класс «User», «TextCorpus», «TextCorpusFile», «Annotation» и «Template» наследуются от одного общего класса «EntityModel», который имеет только поле «Id», это сделано для того, чтобы обеспечить взаимодействие с базой данных.

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

Реализация структуры базы данных.

На основе реализованной модели классов была построена реляционная база данных. Все таблицы, кроме связующих таблиц («TextCorpus_User», «TextCorpusFile_User», «Annotation_User», «Template_User», «Annotation_Template» и «TextCorpus_File») имеют уникальный первичный ключ «Id». В реляционной базе данных отсутствуют связи «многие ко многим» и для их моделирования пришлось реализовывать связующие таблицы. Некоторые из связующих таблиц, такие как «TextCorpus_User», «TextCorpusFile_User», «Annotation_User», «Template_User» имеют дополнительные поля: «AccessType» и «UserType».

В базе данных было решено, не создавать отдельных таблиц для перечислений «AccessType» и «UserType», которые были созданы в диаграмме классов, поэтому они хранятся как строки.

Каждый элемент «TreeElement» содержит:

Поле «Id», которое хранит уникальный номер идентификатора.

Поле «ChildId», которое хранит номер на вложенный элемент дерева.

Поле «NextId», которое хранит номер на следующий элемент дерева.

Поле «Value», которое хранит значение элемента дерева.

Поле «AttributeId», которое ссылается на столбец «Id» таблицы «AttributeName».

«AttributeName» хранит поле «Name» и «Id», которое является уникальным идентификатором и может быть использован несколько раз при формировании элементов дерева или при формировании других деревьев. Данная структура была использована для динамического добавления данных в таблицах «TextCorpus», «TextCorpusFile» и «Annotation».

Реализация структуры BLOB хранилища.

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

Структура BLOB хранилища.

Учетная запись должна хранить три контейнера «files», «plainfiles» «annotations». Контейнер «files» хранит текстовые файлы, где имя текстового файла формируется из уникального номера, который сохранен в базе данных, расширение также берется из базы данных. Контейнер «plainfiles» хранит текст без форматирования, где имя текста без форматирования формируется из уникального номера, который сохранен в базе данных, расширение также берется из базы данных. Контейнер «annotations» хранит аннотации, где имя аннотации формируется из уникального номера, который сохранен в базе данных, расширение также берется из базы данных.

Количество строк кода полученного решения.

Количество строк полученного решения, включая библиотеки, веб-приложение, в котором находятся реализованные веб-сервисы, автоматическое тестирование и консольное приложение для исследовательского тестирования, составляет 5188. Если посчитать без учета автоматического тестирования, консольного приложения для исследовательского тестирования, то получиться 3897 строк кода.

Размещение базы данных, BLOB хранилища и веб-приложения на облачной платформе.

После того как веб-сервисы были реализованы согласно диаграммам представленным в третьей главе, на облачной платформе «Microsoft Azure» были размещены: экземпляр сервера «MS SQL Server», экземпляр BLOB хранилища и веб-приложение, которое содержит все веб-сервисы, для работы с базой данных и BLOB хранилищем.

Экземпляр сервера «MS SQL Server» был создан на сайте платформы «Microsoft Azure». С использованием программного обеспечения «Microsoft SQL Server Management Studio» выполнено подключение к экземпляру сервера, который расположен на облачной платформе и написан запрос, который создает базу данных.

Выполнение запроса Экземпляр BLOB хранилища был создан на сайте платформы «Microsoft Azure», все необходимые контейнеры были созданы также на данном сайте.

Создание контейнеров.

При помощи программного обеспечения «Microsoft Visual Studio 2013» веб-приложение было опубликовано на платформу «Microsoft Azure».

Для использования веб-служб в своем приложении необходимо добавить ссылку (http://textcorpuswebservice20160408093307.azurewebsites.net/UserService.svc?wsdl).

Для программной реализации была выбрана «Луковая» архитектура, которая позволяет не зависеть от определенной реализации базы данных, и разрешает заменить базу данных на другую, если в этом возникнет необходимость, а также создана объектно-ориентированная модель, которая является ядром данной архитектуры. На основе созданной объектно-ориентированной модели была реализована реляционная база данных и BLOB хранилище. Далее реляционная база данных, BLOB хранилище и веб-приложение были размещены на облачной платформе «Microsoft Azure». Было высчитано количество строк кода реализованного решения для того чтобы иметь общие представления о проделанной работе.