После конфигурирования системы для проверки JWT на валидность, был создан сервис «JWTHandlerService», задача которого состоит в генерации новых JWT токенов. Ниже на рисунке 11 приведены методы класса данного сервиса.

Рисунок 11. Методы класса JWTHandlerService.

Метод «Create», в свою очередь вызывается в классе сервиса «AccountRepository», где производится авторизация пользователя и другие операции, связанные с предоставлением доступа.

Отдельно стоит отметить, что секретный ключ, использующийся для создания подписи токенов JWT хранится вне исходного кода в конфигурационном файле «appsettings.json». Такой подход позволит генерировать секретный ключ вне системы, например, при реализации Continuous Integration для развертывания сервиса на сервере.

Еще одной важной особенностью и использования JWT является необходимость ограничения времени жизни токена. Это производится для уменьшения рисков, связанных с похищением токена. В таком случае для того, чтобы избежать ограничения времени доступа пользователя к системе, было решено в дополнение к JWT использовать так называемый refresh token. Данный тип токена используется исключительно в целях обновления JWT токена и как правило имеет более продолжительный срок жизни. Создание этого токена производится при каждой авторизации пользователя в системе. Затем сгенерированный токен вместе с JWT передается пользователю и записывается в базу данных в таблицу «refresh tokens». Для обновления JWT токена пользователю, в свою очередь, необходимо по специальному запросу передать оба токена. При валидности обоих токенов система производит генерацию нового JWT токена и направляет его в ответе на запрос.

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

Для получения доступа к ключевым точкам API серверной части, клиентской части необходимо вместе с основным HTTP запросом передать заголовок «Authorization», содержащий префикс «Bearer» и полученный при авторизации JWT токен. Если токен валиден, сервер производит запрашиваемую операцию. В противном случае - возвращает статус запроса 401, что означает, что пользователь не авторизован для выполнения запрашиваемой операции. В дальнейшем при получении ответа 401 клиентская часть может произвести либо обновление JWT токена при помощи refresh токена, либо перенаправить пользователя на страницу авторизации.

2.3.3 Проектирование и реализация программного интерфейса

Applications Programming Interface (API) - это программный интерфейс системы, который обеспечивает связь различных программных компонентов между собой. Одной из разновидностей API является так называемый Web API - интерфейс для доступа к приложению по веб-протоколу, например, HTTP. В рамках текущей работы серверная часть приложения выполняется в формате Web API, что позволяет полностью инкапсулировать код серверной части и отделить его от кода, отвечающего за интерфейс. Такое разделение дает возможность разработки нескольких интерфейсов системы. Причем их размещение в качестве сайта не обязательно. Взаимодействовать с серверной частью при реализации такого подхода могут также как различные мобильные приложения, так и другие серверные программы.

Существует некоторое количество вариантов разработки Web API с точки зрения архитектуры. В рамках текущей работы был применен подход REST [23], который позволяет унифицировать формат взаимодействия клиента и сервера. При проектировании API серверной части были реализованы следующие принципы:

· Каждый запрос построен из нескольких составных частей:

o Метод запроса - один из методов HTTP протокола, а именно GET, POST, PUT или DELETE. При этом каждый из методов соответствует необходимой операции над сущностью, а именно GET соответствует получению, POST - созданию, PUT - обновлению и DELETE, соответственно, - удалению. Такой подход позволяет реализовать принцип CRUD при помощи средств HTTP протокола

o URL начинается с базовой сущности, которая обрабатывается при помощи запроса. Например «GET /documents»

o При необходимости доступа к записи по ее идентификатору, к URL запроса приписывается соответствующий идентификатор. Например «PUT /documents/234»

o Для обозначения выполнения операции над сущностью, к URL приписывается название соответствующей операции. Например: «POST /auth/signin»

o Для доступа к дочерним сущностям, сначала указывается родительская сущность с ее идентификатором, а затем домен дочерней и ее идентификатор при необходимости. Например «GET /documents/234/comments»

· Данные между клиентом и сервером передаются в формате JSON. Данный формат весьма широко используется различными сервисами и поддерживается большинством языков программирования. Также стоит отметить, что все поля в объектах JSON передавались в формате «snake case», как пример - «access_token».

Перед началом разработки серверной части необходимо также произвести две дополнительные настройки. Первая заключается в открытии API для кросс-доменных запросов, называемых Cross-Origin Resource Request (CORS) [24]. Такая настройка позволяет производить запросы между разными доменами, что по умолчанию заблокировано в целях безопасности системы. Это необходимо при размещении клиентской и серверной части системы на различных серверах или на различных доменах. Также стоит отметить, что данная настройка используется только для доменов, обозначенных в конфигурационном файле «appsettings.json». При этом для всех остальных доменов API серверной части остается закрытым. Вторая настройка заключается в указании правила преобразования полученного JSON в объекты соответствующих классов. Данные настройки производятся в методе «ConfigureServices» класса «Startup». Ниже на рисунке 12 приведен код, производящий соответствующую конфигурацию системы.

Рисунок 12. Конфигурация CORS и стратегии преобразования JSON.



Реализация конечных точек API средствами ASP.NET Core производится посредством создания соответствующих контроллеров. Каждый контроллер отвечает за отдельный набор сущностей. Классы контроллеров располагаются в папке «Controllers». При этом наименование каждого класса контроллера должно оканчиваться суффиксом «Controller», что позволяет фреймворку производить автоматическую загрузку файлов и настройку конечных точек. Также стоит отметить, что для ускорения и унифицирования настройки контроллеров в системе был создан атрибут «KMSController». Задача данного атрибута заключается в указании единого для всех конечных точек API URL-префикса «api», а также использования названия контроллера для формирования части адресной строки запроса, отвечающей за основную запрашиваемую сущность.

Для формирования обработчиков запросов следует в соответствующем контроллере создать метод и пометить его одним из атрибутов: HttpGet, HttpPost, HttpPut и HttpDelete. Также такой метод должен возвращать тип «IActionResult», который может быть в дальнейшем преобразован фреймворком для выдачи ответа клиентской части в запрашиваемом формате. Еще один немаловажный фактор - вынесение обработки пользовательских запросов в отдельный поток. Данная операция критически важна, поскольку при выполнении вычислений в основном потоке работы серверной программы, новые запросы по тому же URL будут ожидать обработки предыдущих запросов, что, в свою очередь, может значительно уменьшить производительность системы в-целом. Для вынесения обработки HTTP запросов в отдельный поток каждый метод контроллера помечается как асинхронный, и все длительные операции, такие как взаимодействие с базой данных и файловой системой осуществляются также при помощи вызова асинхронных функций. Для того, чтобы преобразовать метод в асинхронный необходимо к названию метода приписано модификатор «async», обернуть возвращаемый тип в тип «Task», а все вызовы асинхронных функций внутри метода производить с пометкой «await». Ниже на рисунке 13 приведен пример асинхронного метода контроллера «CompetencesController».

Рисунок 13. Метод «Update» контроллер «CompetencesController»

Как видно из рисунка 13, все запросы к базе данных выполняются в отдельном от основного потоке, что не блокирует систему и позволяет обрабатывать одновременно большое количество запросов. Также стоит отметить, что получение данных от клиентской части СУЗ осуществляется через указание соответствующих параметров метода, помеченных следующими атрибутами:

· FromRoute - выделение переменной из URL запроса

· FromQuery - получение данных, отправленных в качестве дополнительных параметров URL запроса после идентификатора «?»

· FromBody - получение данных из тела HTTP запроса

Для передачи и получения объектов в системе используются так называемые Data Transfer Object (DTO). DTO представляет собой класс с необходимым и достаточным набором полей для передачи информации от сервера клиенту и получения данных от клиента. Все классы, использующиеся для передачи данных, расположены в директории «Models» и кроме полей содержат конструктор, принимающий на вход объект модели базы данных и заполняющий на ее основе поля класса. Такой подход позволяет отделить формат общения между клиентом и сервером от формата данных в базе данных.

Также стоит отметить, что сериализация соответствующих DTO объектов в формат JSON для передачи клиентской части СУЗ производится автоматически средствами фреймворка. Для этого соответствующий объект следует передать в один из методов: BadRequest, NotFound или Ok. При этом каждая из перечисленных функций добавляет к ответу соответствующий HTTP код.

Еще один важнейший аспект настройки серверной части приложения - настройка обработки ошибок и исключений. Для этого был реализован перехватчик запросов «ErrorHandlerMiddleware», который оборачивает выполнение всех обработчиков клиентского запроса в конструкцию «try-catch» и при возникновении исключения отправляет клиентской части описание возникшей ошибки, при этом не останавливая работу серверного приложения.

Обработка всех запросов в серверной части СУЗ реализована по описанным выше принципам. В результате разработки серверной части были созданы 92 конечные точки для управления записями в базе данных и проведения необходимых операций. Исходный код серверной части СУЗ размещен в репозитории на Github: https://github.com/v1996-96/kms. В следующей части работы описан процесс разработки клиентской части СУЗ и настройка связи клиентской части приложения с серверной частью.

2.4 Клиентская часть системы

2.4.1 Схема страниц клиентской части системы

Интерфейс клиентской части СУЗ выполнен в формате «Single-page application» (SPA), что позволяет избежать загрузки каждого элемента интерфейса в отдельности и, за счет этого, ускоряет обработку пользовательского взаимодействия. При использовании подхода SPA, весь код клиентской части загружается один раз при первом подключении к серверу. Затем исходный код может быть сохранен в кэше браузера, что, в свою очередь, ускорит дальнейшую загрузку клиентской части СУЗ. Также такой подход очевидно может снизить нагрузку на серверную часть приложения без потери функциональности.

На данный момент существует большое количество различных фреймворков и библиотек, предоставляющих возможность создания SPA приложений, таких как React, Vuejs [25] и Angular. Для создания клиентской части СУЗ был выбран фреймворк Vuejs, поскольку данный фреймворк имеет весьма низкий порог вхождения, и он быстрее остальных производит рендер элементов пользовательского интерфейса. Кроме того, данный фреймворк имеет весьма широкую поддержку сообществом, а также для использования с Vuejs существует большое количество дополнительных модулей и библиотек, которые расширяют функционал фреймворка и позволяют в короткие сроки реализовывать новый функционал в пользовательском интерфейсе.

Соответственно приведенному в разделах 2.1.1 и 2.1.2 обзору функциональности системы и вариантов пользовательского взаимодействия, была спроектирована схема страниц клиентской части СУЗ, а также правила по перемещению между страницами. Ниже на рисунке 14 представлена схема страниц клиентской части системы.

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

Как видно из схемы, клиентская часть состоит из двух разделов: раздел авторизации и внутренняя часть СУЗ. Все страницы системы, кроме страниц авторизации, регистрации и восстановления пароля, доступны пользователю только при наличии валидного JWT токена, который, в свою очередь можно получить только в процессе аутентификации в системе.



Рисунок 14. Схема страниц клиентской части СУЗ.

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

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

2.4.2 Разработка интерфейса клиентской части

На данный момент существует большое количество способов разработки интерфейса вебсайтов. Наиболее правильный и результативный подход к разработке интерфейса состоит из следующих этапов:

1. Проектирование пользовательского взаимодействия (User experience)

2. Формирование макетов страниц системы

3. Разработка дизайна страниц системы

4. Верстка страниц системы согласно составленному дизайну

Однако по причине отсутствия навыков в дизайне вебсайтов, а также для ускорения процесса разработки СУЗ, было принято решение использовать готовый набор элементов пользовательского интерфейса и, тем самым, от первого этапа перейти сразу к четвертому. Существует немалое количество расширений для фреймворка Vuejs, предоставляющих такую функциональность. Среди них можно выделить следующие: Quasar Framework, Vue Material, Vuetify [26] и Element UI. Все перечисленные расширения предоставляют широкий спектр элементов интерфейса, который можно использовать для быстрого прототипирования приложений. В рамках текущей работы был выбран Vuetify, поскольку данное расширение на данный момент довольно активно развивается, получая поддержку от сообщества, а также имеет отличную документацию ко всем реализованным компонентам. Расширение Vuetify основано на дизайн-системе Material Design, разработанной Google.

Для начала разработки пользовательского интерфейса с использованием фреймворка Vuejs с расширением Vuetify была установлена среда разработки Node.js вместе с пакетным менеджером NPM. После успешной установки ПО, были выполнены следующие консольные команды:

· «npm install -g vue-cli» - консольной программы для создания проектов на Vuejs

· «vue init vuetifyjs/webpack» - инициализация проекта с использованием заранее подготовленного шаблона, основанного на Webpack. Webpack - это инструмент для сборки файлов проекта.

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

· «api» - модули для взаимодействия с серверной частью приложения. Для отправки HTTP запросов использовался пакет «axios» [27].

· «components» - переиспользуемые компоненты интерфейса. Каждый компонент оформлен в отдельный файл с расширением «.vue». Данные компоненты были разделены на 3 типа:

o «template» - компоненты, использующиеся для подготовки шаблонов страниц

o «ui» - компоненты, главная задача которых состоит в отображении переданных им данных и передаче событий о пользовательском взаимодействии родительским компонентам

o «active» - данный тип компонентов способен совершать запросы к серверной части приложения. Такой тип компонентов необходим для повторного использования элементов формы, подгружающих свое содержимое из базы данных

· «mixins» - модули для повторного использования необходимого функционала между страницами и компонентами системы

· «models» - модели данных, используемые для проверки консистентности данных, полученных через API. Для создания моделей использовались пакеты «ampersand-state» и «ampersand-collection».

· «router» - конфигурация постраничной навигации в фреймворке Vuejs, осуществляемая при помощи пакета «vue-router» [28]

· «store» - общее локальное хранилище приложения. Данное хранилище позволяет передавать данные между компонентами, а также загружать и хранить информацию при перемещении между страницами. Для создания локального хранилища использовался пакет «vuex» [29]

· «views» - набор компонентов страниц приложения.

· «utils» - набор модулей для выполнения некоторых, общих для различных компонентов системы, функций.

Разработка интерфейса системы заключалась в создании компонентов для отображения страниц, а также в настройке постраничной навигации. Для этого в первую очередь были созданы файлы шаблонов: app.layout.vue и account.layout.vue. Данные файлы содержат разметку, общую для двух выделенных при проектировании групп страниц, а именно страницы авторизации и страницы самой СУЗ.

Отдельно стоит отметить особенности настройки постраничной навигации. Для ее реализации в папке «router» был создан файл «index.js», в котором в JavaScript объекте описана конфигурация роутинга. Основной особенностью постраничной навигации, реализованной в текущем проекте и зачастую применяемой при реализации SPA, является использование History API [30]. History API - это интерфейс, позволяющий манипулировать историей браузера в пределах сессии, а именно историей посещения страниц в пределах вкладки [31]. Данный интерфейс предоставляет возможность сохранять историю перемещения между страницами при использовании SPA, которое, по сути, использует лишь одну страницу. Для включения данного функционала в конфигурационном объекте было добавлено соответствующее поле «mode: `history'».

Также особенностью настройки постраничной навигации является указание родительских и дочерних страниц, что позволяет реализовывать шаблонные компоненты и при навигации между страницами перезагружать лишь часть интерфейса. Такой подход был использован для внедрения на сайт навигационных панелей, меню и поисковой строки, которые, в свою очередь, были размещены в файле шаблона «app.layout.vue». Кроме того, в родительских компонентах есть возможность предварительной загрузки данных, используемых повсеместно на различных страницах и компонентах системы, что исключает необходимость повторной загрузки данных и уменьшает количество запросов к серверной части. Компоненты, соответствующие страницам, было решено распределять по отдельным папкам. Каждая такая папка содержит как минимум 3 файла:

· «index.vue» - основной файл компонента страницы, в котором прописаны ссылки на дополнительные файлы компонента, а также логика работы страницы на языке JavaScript

· «template.html» - содержит разметку страницы, выполненную на языке HTML и содержащую дополнительные служебные теги и атрибуты, используемые фреймворком Vuejs

· «config.js» - содержит конфигурационные параметры страницы, а именно различного рода константы и настройки

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

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

Также стоит отметить, что в интерфейсе СУЗ предусмотрено включение ночного режима, который затемняет все элементы интерфейса, что уменьшает нагрузку на глаза пользователя при чтении документов в ночное время.

Рисунок 15. Главная страница СУЗ.

Ниже на рисунке 16 представлен внешний вид раздела «My work». Данный раздел содержит список документов, созданных пользователе, список закладок, список проектов, за которыми следит пользователь, а также историю просмотра документов в системе. Цель данной страницы - упрощение навигации пользователя по системе.

Рисунок 16. Интерфейс раздела «My work»

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

Рисунок 17. Страница управления настройками СУЗ.

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

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

Рисунок 18. Интерфейс создания проекта.

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

Рисунок 19. Страница проекта.

Ниже на рисунке 20 представлен внешний вид страницы документа. На данной странице размещены заголовок документа, подзаголовок, текст, список комментариев, а также кнопки для создания закладки и редактирования документа.



Рисунок 20. Страница документа

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

Рисунок 21. Страница редактирования документа.

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

2.4.3 Реализация функционала клиентской части

Первое действие, предпринятое при реализации функционала клиентской части СУЗ, заключалось в настройке связи кода клиентской части с серверной частью. Для этих целей был установлен пакет «axios», предоставляющий возможность создания асинхронных Ajax запросов. Для настройки подключения в директории «api» были созданы следующие файлы:

· http.js - создание нового объекта пакета axios с указанием домена, на котором расположен API серверной части системы. При этом стоит отметить, что данное доменное имя указано в качестве переменной окружения, что позволяет при сборке проекта производить изменения в данной конфигурации

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

· Остальные файлы в данной директории представляют собой обертки для методов, реализующие запросы к базе данных. Данные модули импортируются в файле index.js и инъектируются в основной объект, который затем использует системой для отправки запросов

Также для обработки ответов, полученных от серверной части СУЗ, были созданы модели, соответствующие по структуре DTO классам серверной части системы. Модели каждой сущности распределены по своим директориям. Кроме того, стоит отметить, что для сущностей были созданы три типа моделей: полные модели, короткие модели и списки. Полные модели содержат все возможные поля сущности и как правило используются при получении данных при запросе сущности по идентификатору, при создании новой сущности и ее редактировании. При запросе списка, соответственно, использовались модели списков, которые имеют в системе единый формат - поле «count» и поле «results», содержащее список коротких моделей. Также короткие модели использовались при получении информации о дочерних сущностях в случаях, когда они передавались в модели вместе с основной. Для создания моделей использовались пакеты «ampersand-state» и «ampersand-collection», которые позволяют проверять данные на соответствие указанному шаблону и производить проверку типов и целостности данных, полученных от сервера.

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

Следует подробнее остановиться на устройстве vuex и принципе его работы. Хранилище vuex состоит из 4-х компонентов:

· state - описывает общую структуру хранилища

· getters - функции для получения вычисляемых значений, основанных на данных, содержащихся в полях хранилища

· mutations - методы, производящие преобразования в хранилище

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

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

Для целей настройки авторизации был создан модуль «account.js». В state части модуля хранятся токены: JWT, refresh token и invite token. Также в модуле реализованы методы для авторизации, регистрации, выхода из системы, а также для получения данных профиля пользователя. В дальнейшем все операции по управлению аккаунтом пользователя производятся при помощи созданного модуля. В дополнение к модулю «account» были использованы следующие плагины:

· «vuex-persistedstate» [32] - данный плагин сохраняет содержимое хранилища в cookie файлах в целях сохранения сессии при закрытии вкладки и при открытии новых вкладок в браузере

· «vuex-shared-mutations» [33] - данный плагин позволяет синхронизировать хранилища между вкладками браузера. Такой функционал крайне необходим для обновления сессии на всех вкладках, на которых открыта СУЗ, если на одной из вкладок произошло обновление JWT токена

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

· ROUTER_MIDDLEWARE - метод, вызываемый при переходах между страницами системы. Данный метод производит проверку авторизации пользователя и перенаправляет его на страницу авторизации в случае, если отсутствует JWT токен или истек его срок действия

· SETUP_HTTP_MIDDLEWARE - данный метод производит настройку перехватчиков HTTP запросов, которые приостанавливают запрос в случае, если в данный момент производится обновление токена, а также перенаправляют пользователя на страницу авторизации, в случае если от сервера был получен HTTP код 401

· SETUP_AUTH_CHECKS - данный метод производит инициализацию функции, которая в определенные интервалы времени производит дополнительную проверку статуса авторизации пользователя и запускает процесс обновления токена при необходимости

Приведенные выше методы вызываются при инициализации клиентского приложения в файле «main.js».

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

· Для управления постраничной навигацией, конечные точки API, реализующие поиск, на вход принимают поля limit и offset, определяющие количество запрашиваемых записей и отступ от начала выборки соответственно. Такой подход, кроме постраничной навигации, также позволяет реализовывать постепенную подгрузку контента

· Поисковой запрос передается в поле query

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

Таким образом были созданы расширения, реализующие несколько различных типов поиска: постраничный поиск, поиск с конкатенацией результата, поиск ограниченного числа записей, а также, поиск единственной записи. Каждое из расширений было продублировано для использования как в компонентах Vuejs в качестве миксина [34], так и в локальном хранилище клиентской части. Ниже на рисунке 22 в качестве примера приведена часть кода расширения, отвечающая за инициализацию запроса к базе данных и обработку результата.



Рисунок 22. Часть файла search-paginate.js

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

Еще одной важной особенностью расширения является обработка вызова функции поиска. В случае, если запуск поиска производится одновременно с вводом поискового запроса в текстовое поле, новые поисковые запросы могут создаваться при вводе каждого нового символа, что повышает нагрузку на базу данных и ухудшает опыт использования системы. Для того, чтобы ограничить количество поисковых запросов к базе данных и их частоту, при этом, не ограничивая возможности системы, был использован метод «debounce» библиотеки «lodash» [35]. Данный метод ограничивает минимальное время между выполнением функции. В случае, если функция вызывается слишком часто, код будет выполнен с параметрами, переданными при последнем вызове, предшествовавшем минимально допустимому промежутку времени без вызовов функции. Ниже на рисунке 23 приведен соответствующий код.

Рисунок 23. Использование метода «debounce».

Далее следует рассмотреть еще один важный аспект разработки клиентской части СУЗ, а именно валидация веб-форм. Валидация данных, введенных пользователем, крайне важна, поскольку предоставляет возможность быстрого оповещения пользователя о возможных ошибках проведения операции еще до ее инициализации. На данный момент существует большое количество способов реализации функционала валидации веб-форм, которые можно использовать совместно с фреймворком Vuejs. В рамках текущей работы был выбран пакет «vuelidate» [36], поскольку данный пакет предоставляет весьма удобный API по сравнению с другими решениями, а также отлично интегрирован в экосистему Vuejs. Для использования данного пакета в первую очередь была произведена инициализация при помощи команды «Vue.use(Vuelidate)». Далее в компонентах системы появляется возможность использовать поле «validations», в котором описаны правила валидации данных.

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

Рисунок 24. Правила валидации формы создания проекта.

После инициализации правил валидации, статус валидности формы в-целом и отдельных полей доступен через параметр «$v» как в JavaScript коде компонента, так и в HTML шаблоне. Таким образом была выполнена настройка валидации формы создания проекта. На рисунке 25 представлен пример неверно заполненной формы с соответствующими сообщениями об ошибке.

Рисунок 25. Сообщения об ошибке при валидации формы создания проекта.

Последний аспект, требующий рассмотрения в данной работе - процесс создания и настройки текстового редактора для создания и редактирования документов. На данный момент существует большое количество различных плагинов, реализующих функционал по редактированию текста в браузере. Здесь под редактированием текста подразумевается написание текста, указание шрифта, размера текста, его размещения, цвета и другие виды форматирования. Однако такие редакторы, как CKEditor или TinyMCE, предоставляя достаточный для нужд СУЗ набор функционала, являются платными решениями в то время, как среди бесплатных пакетов довольно трудно найти решение с достаточным функционалом, большим комьюнити и хорошей поддержкой. Для реализации текстового редактора в рамках текущей работы был выбран плагин Quill [37], предоставляющий широкие возможности по интеграции в различное окружение, а также по расширению функционала. Также стоит отметить, что данный пакет является бесплатным и обладает крупным комьюнити - репозиторий в Github набрал более 17 тысяч звезд.

Из коробки плагин Quill предоставляет набор тем для оформления текстового редактора, а также набор инструментов для форматирования текста. Кроме того, стоит отметить, что отличительной особенностью данного плагина является весьма гибкий API, предоставляющий доступ к внутренним параметрам и функциям плагина для его детальной настройки. Именно наличие такого API позволило реализовать собственный интерфейс по управлению форматированием текста с использованием компонентов интерфейса Vuetify. Это, в свою очередь, позволило добиться единства стиля среди страниц СУЗ. Еще одной отличительной особенностью выбранного плагина является использование собственного формата текста, используемого помимо HTML для разметки и форматирования текста. Данный формат представляет из себя JSON объект, содержащий информацию о перемещении курсора, вводе и форматировании текста. В дальнейшем при развитии системы эту особенность текстового редактора можно использовать для реализации одновременного редактирования одного документа несколькими пользователями. Однако на данный момент представленный формат используется для инициализации текстового редактора при редактировании ранее созданного документа. При этом сам JSON объект хранится в базе данных наряду с текстом документа.

При редактировании документа также крайне важно периодически сохранять изменения, произведенные в документе, с целью уменьшения риска потери информации. Для этой цели была использована связка из вотчера изменений и ранее описанной функции «debounce». Таким образом при каждом изменении текста, вызывается функция сохранения, которая, в свою очередь, выполняется при остановке ввода текста на 10 секунд или, в случае непрерывного ввода текста, раз в две минуты. Кроме вышеописанных настроек был добавлен функционал, позволяющий при нажатии комбинации клавиш Ctrl+S производить сохранение изменений в документе. Все описанные настройки текстового редактора выполнены в файле «index.vue» директории «src/views/app/project-views/editor».

В данном разделе был подробно рассмотрен процесс реализации функционала клиентской части СУЗ, а именно настройка подключения к серверной части, создание локального хранилища и настройка авторизации, создание расширений для унификации доступа к поисковым возможностям СУЗ, настройка валидации веб-форм, а также особенности настройки текстового редактора. Исходный код клиентской части СУЗ размещен в репозитории на Github: https://github.com/v1996-96/kms-frontend. В следующем разделе описан процесс подготовки проекта к его дальнейшему развертыванию на сервере.

2.5 Сборка и развертывание системы управления знаниями

Сборка СУЗ в качестве коробочного решения - необходимый этап разработки СУЗ, позволяющий компаниям без труда разворачивать решение в собственной ИТ инфраструктуре. Для целей упаковки СУЗ использовалось программное обеспечение (ПО) Docker [38]. Docker - это ПО для автоматизации развертывания и управления приложениями, которое позволяет упаковывать приложение, с учетом окружения и зависимостей, в контейнер, который затем может быть запущен в любой среде с поддержкой виртуализации. В рамках текущего проекта Docker используется для сборки и упаковки отдельно составных частей СУЗ: клиентская часть, серверная часть, база данных и прокси сервер.

Для реализации конфигурации проекта был создан дополнительный репозиторий, содержащий только конфигурационные файлы и переменные окружения. Поскольку СУЗ состоит из нескольких относительно независимых частей, возникает необходимость их сборки в отдельные контейнеры и последующем связывании. Для этих целей использовалась утилита docker-compose [39], предоставляющая возможность описывать и запускать многоконтейнерные приложения. Настройка утилиты docker-compose заключается в создании файла «docker-compose.yml», содержимое которого приведено на рисунках 26 и 27. Конфигурация в данном файле описывается на языке YAML. Настройка сборки контейнеров, в свою очередь, описана в файлах «Dockerfile».

Рисунок 26. Настройка утилиты docker-compose

Рассмотрим приведенный на рисунке 26 код подробнее. Директива «volumes» производит конфигурацию локального файлового хранилища, в котором контейнеры могут размещать файлы для их сохранения при удалении самих контейнеров или их перезапуске. В данном случае «attachments» отвечает за сохранение файлов, прикрепленных к документам, «node_modules» - директория, хранящая файлы JavaScript пакетов, загруженных из NPM репозитория, а «pgdata» - директория, необходимая для сохранения файлов базы данных.

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

· «proxy» - HTTP сервер, основанный на nginx, в задачи которого входит получение HTTP запросов к клиентской и серверной части и, затем, их перенаправлении для выполнения. Также прокси сервер способен кешировать результат, тем самым снижая нагрузку на СУЗ.

· «frontend» - сервер клиентской части СУЗ, основанный на Nodejs, в задаче которого входит выдача файлов сборки клиентской части СУЗ

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

Ниже на рисунке 27 приведен код конфигурации сервисов для серверной части СУЗ и базы данных.

Рисунок 27. Настройка утилиты docker-compose.

Основная трудность при настройке подключения серверной части СУЗ к базе данных заключалась в запуске серверной части СУЗ после инициализации сервера базы данных. Для этих целей была указана директива «depends_on», определяющая порядок запуска контейнеров. Однако это не гарантирует доступность базы данных при запуске серверной части, поскольку процесс запуска сервера базы данных может быть весьма продолжительным. Для преодоления возникшей проблемы была использована утилита «dockerize» [49], при помощи которой можно отложить выполнение команды до получения доступа к внешнему ресурсу, в данном случае - сервера базы данных.

На рисунке 28 приведен пример конфигурации сборки контейнера серверной части СУЗ.

Рисунок 28. Пример содержимого файла «Dockerfile»

Развертывание подготовленной сборки может быть произведено при помощи специальной команды «docker-compose up -d». При этом утилита автоматически производит сборку контейнеров, их последовательный запуск и связывание. Процесс сборки может занять продолжительное время, а также может быть весьма требовательным к ресурсам системы, что необходимо учесть при выборе сервера, на котором планируется размещение СУЗ.

Исходный код файлов для настройки коробочного решения размещен в репозитории на Github: https://github.com/v1996-96/kms-publish.

В целях тестирования процесса размещения СУЗ было выполнено размещение СУЗ на тестовом сервере. Для этих целей было решено использовать облачный сервис Vscale.io, поскольку данный сервис предоставляет весьма простой интерфейс, удобный набор образов и операционных систем, низкие цены, а также размещение в датацентре в Москве или Санкт-Петербурге. Также данный сервис позволяет при создании сервера выбрать образ с поддержкой Docker окружения, что необходимо для развертывания СУЗ. Тестовый образ системы размещен по адресу http://kmsoftware.tk/. Для доступа в систему можно использовать почтовый адрес «test@kmsoftware.tk» и пароль «kmsoftware».

Выводы: в данной главе был рассмотрен процесс разработки системы управления знаниями. Выявлен набор необходимых функциональных возможностей системы управления знаниями, спроектированы варианты пользовательского взаимодействия с системой, разработана архитектура системы. Далее приведено описание процесса разработки базы данных. Также детально описан процесс разработки серверной части СУЗ, а именно настройки подключения к базе данных, аутентификаии и авторизации пользователей, а также проектирования и реализации API. Приведено описание процесса разработки клиентской части СУЗ, а именно проектирование постраничной навигации, разработка интерфейса клиентской части системы, а также реализация его функционала. В последнем разделе главы рассмотрен процесс сборки СУЗ в качестве коробочного решения и даны рекомендации по развертыванию готового коробочного решения на сервере.



ГЛАВА 3. ОСОБЕННОСТИ ВНЕДРЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ ЗНАНИЯМИ

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

Запуск разработанной системы управления знаниями компаниям следует проводить инкрементально, поскольку эффект от использования системы можно оценить лишь в долгосрочной перспективе [41]. Такая особенность заключается в скорости создания и трансформации знаний в пределах компании, а также во временных особенностях жизненного цикла проекта. Например, если один проект имел продолжительность 3 месяца, то знания, полученные во время деятельности проекта, могут быть использованы в рамках других схожих проектов лишь по прошествии 2-3 месяцев после внедрения СУЗ в бизнес-процессы компании. Таким образом, оценить результат от использования СУЗ можно лишь по прошествии довольно длительного срока. Для более эффективного внедрения СУЗ в бизнес-процессы компании следует начать использование СУЗ в рамках 2-3 проектов со сходной спецификой и затем постепенно расширять использование системы на других проектах при необходимости.

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

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

Еще один важный аспект внедрения системы управления знаниями в компании - измерение эффективности и последствий использования системы управления знаниями. Основная трудность в данном случае заключается в выявлении метрик, напрямую зависящих от эффективности применения СУЗ и при помощи которых представляется возможным делать выводы об оправданности использования СУЗ в компании. В качестве такой метрики можно использовать один из следующих показателей:

· Время, необходимое для запуска нового проекта

· Время, необходимое для поиска решения операционной задачи

· Частота возникновения ошибок в операционной деятельности

· Время, необходимое для обучения нового сотрудника

· Повышение квалификационно-образовательного уровня персонала

· Количество обращений к базе знаний

· Оценка роста количества документов, хранимых в СУЗ

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

Для более эффективного использования СУЗ в компании, следует интегрировать СУЗ с другими информационными системами компании:

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

· HRM система - ведение профиля пользователя и его компетенций с целью поиска эксперта по выбранной проблематике

· BI система - автоматическое сохранение отчетов по деятельности проекта, а также данных, послуживших основой для принятия управленческих решений

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

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



ЗАКЛЮЧЕНИЕ

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



СПИСОК ЛИТЕРАТУРЫ

1. Sydow J., Lindkvist L., DeFillippi R. Project-based organizations, embeddedness and repositories of knowledge. - 2004.

2. Davenport T. H., Prusak L. Working knowledge: How organizations manage what they know. - Harvard Business Press, 1998.

3. Nonaka I., Takeuchi H. The knowledge-creating company: How Japanese companies create the dynamics of innovation. - Oxford university press, 1995.

4. Ajmal M. M., Koskinen K. U. Knowledge transfer in project?based organizations: an organizational culture perspective // Project Management Journal. - 2008. - Т. 39. - №. 1. - С. 7-15.

...