Дипломная работа: Разработка системы взаимодействия с клиентами SAAS-среды аренды сайтов

Результаты анализа:

Можно заметить перегрузку токенов на Втором уровне поддержки, и, в меньше мере, на Первом уровне поддержки, из-за петли потоков управления.

Каскадные потоки управления обусловлены специфичной структурой отдела взаимодействия с клиентами.

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

Минимальное время, затраченное на выполнение одного обращения, составляет 1.07 дня.

Максимальное время, затраченное на выполнение одного обращения, составляет 6,57 дня.

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

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

Требования к интерфейсу:

– Раздельный вход в систему,

– Общее хранилище обращений,

– Просмотр информации об обращении (ссылки),

– Возможность подачи обращения.

Индивидуальные требования для каждого пользователя системы изложены как возможности пользователя в моделировании системы взаимодействия с клиентами (см. гл. 2.2). Для проектирования интерфейса системы было решено следовать новейшим практикам создания прогрессивных веб-приложений (PWA - Google). В данную методику входят общие стандарты создания приложений нового поколения:

– доступность всех компонентов приложения пользователю,

– представление приложения после загрузки,

– наличие манифеста приложения,

– наличие полных метаданных приложения,

– необходимый стек технологий.

Дизайн интерфейса - Material Design (унифицированная система, содержащая инструменты, накопленный опыт, ресурсы для создания дизайна). Система, впервые представленная Google в 2014 году, является материалистичным подходом к представлению приложений. Пользователями данной системы являются Google, YouTube, ВКонтакте и т.д.

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

– описание бизнес-процесса,

– симуляцию работы системы,

– базу данных системы, описание интерфейса системы.

Глава 3. Разработка системы взаимодействия с клиентами

Создание современного и прогрессивного веб-приложения стандартизировано и включает в себя определенный стек технологий по версии PWA: HTML, CSS, JS. Приложение, соединенное с данными, должно иметь непрерывный контакт для получения, редактирования, отправки информации, таким образом, для разработки приложения использован JS-фреймворк Angular 5.2, позволяющий создать одностраничное приложение (SPA), не нарушая контакт с данными. Интегрированная среда разработки - Visual Studio Code. Вспомогательный инструмент - Google Dev Tools + Lighthouse. Для реализации спроектированного пользовательского интерфейса и использования системы Material Design. Были подключены пакеты анимации и дизайна (Angular Material, Angular Animations, HammerJS, Bootstrap CDN). Доступ к данным осуществляется с использованием библиотеки AngularFire2, способствующая совместной работе Firebase и Angular приложений.

3.1 Требования к разработке системы взаимодействия с клиентами

– NPM Package 3.10.8

– Angular CLI 1.7.3

– Angular 5.2.10

– Angular Material Package

– Angular Animations Package

– HammerJS

– AngularFire2 (Официальная библиотека для Angular и Firebase)

– Bootstrap CDN (CSS-фреймворк)

Разработка данного веб-приложения требует навыков работы с консольным клиентом, знания HTML, CSS, JavaScript, TypeScript.

3.1. Ограничения технологий разработки

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

Таблица 3.1. Ограничения бесплатного аккаунта Firebase

Ограничения Angular связаны с некорректным отображением в некоторых версиях браузеров. Несмотря на современную сбору фреймворка, она включает в себя большое количество полифиллов (web polyfills), помогающих корректному отображению в старых версиях браузеров (табл. 3.2).

Таблица 3.2. Поддержка браузеров Angular 5.2.10

3.2 Разработка базы данных

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

1. API ключ;

2. Домен проекта;

3. URL базы данных;

4. Идентификатор проекта;

5. Уникальный идентификатор отправителя;

6. Объектное хранилище.

Конфигурация уникальна для каждого проекта. Набор этих элементов является параметрами функции инициализации Firebase модуля внутри приложения.

Рисунок 3.1. Структуры данных.

3.3 Разработка интерфейса системы взаимодействия с клиентами

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

Добавляется маршрутизирующий модуль, импортирующий компоненты приложения, участвующие в маршрутизации и навигации. Модуль импортирует RouterModule и Routes для создания элемента класса Routes, включающего в себя пути маршрутизации к определенным компонентам - каждый путь может содержать ссылку, компонент, защитный компонент. Для программной навигации требуется импорт RouterModule и Router для создания элемента класса Router для выполнения навигации компонента по URL. Для настройки внешних характеристик интерфейса, подключается Material Design Package. В приложении создается дополнительный модуль, импортирующий отдельные блоки из библиотеки, соединенный с основным модулем приложения (см. прил. B). Взаимодействие с приложением строится по модели RBAC, которая предполагает разный функционал пользователей в зависимости от их роли в жизненном цикле приложения. В корневом каталоге создаются каталоги, группирующие компоненты приложения по RBAC-модели: Пользователь, Первый уровень поддержки, Второй уровень поддержки, Третий уровень поддержки (user, first, second, third). Также создаются каталоги для сервисов(services) и защитных компонентов (guards). Для каждого из уровней поддержки нужен отдельный сервис и защитный компонент. Сервис представляет из себя класс с набором get-/set-функций, устанавливающих и определяющих авторизацию определенного пользователя. Защитный компонент открывает доступ к определенному компоненту в маршрутизаторе функцией canActivate(), возвращающей двоичной значение авторизации пользователя. С помощью данной связи сервиса и защитного компонента была реализована система авторизации пользователей (сотрудников организации). Защитные компоненты устанавливаются в маршруты защищенных компонентов сотрудников службы поддержки, являясь провайдерами основного модуля приложения. Для удобства предоставления ссылок маршрутизатора, создаются компоненты навигационного меню и футера в отдельном каталоге (elements). Навигационное меню содержит ссылки маршрутов, отображающие выбранные компоненты в выводе маршрутизатора (router outlet). Таким образом, получается промежуточная структура приложения.

Рисунок 3.2. Структура приложения

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

Создается компонент домашней страницы, на которой размещены кнопки, позволяющие осуществить переход к действующим компонентам. Домашняя страница имеет пустую ссылку в маршрутизаторе, поэтому является стартовым «видом» при запуске приложения. Вид домашней страницы, содержит компоненты навигационного меню, футера, главного компонента с описанием приложения. Кнопка «+» является проводником в компоненту, позволяющему создавать тикеты клиентам (рис. 3.3). Кнопка доступ является проводником к компоненту авторизации.

Рисунок 3.3. Домашняя страница приложения

Компонент авторизации (см. рис. 3.4) пользователей содержит функцию авторизации в файле TypeScript (см. рис. 3.5). Функция использует элементы классов, импортируемые из сервисов каждого вида пользователей, функции сервисов по определению авторизованного пользователя. В случае совпадения вводимых в форму данных, происходит навигация к определенному компоненту, доступ к которому имеет лишь данный вид пользователей. Инициация функции происходит с момента отправки данных с формы, которые передаются как параметры функции.

Рисунок 3.4. Клиентские компоненты

Рисунок 3.5. Функция авторизации

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

Для представления данных, находящихся в коллекциях Firebase, компоненты, предоставляющие эти данные, должны импортировать модули платформы, описать поля класса тикета (наименование, описание, электронная почта, суть тикета и т.д.). Также в процессе предоставления данных принимает участие метод map() класса Observable, совершающий обработку полученных от сервера Firebase результатов. Описываются элементы коллекции и документов Firebase, с помощью которых происходит запись и чтение информации в функциях. Функция добавления тикета вызывается событием заполнения формы, и направляет результат отправки данных формы в коллекцию данных. Функции предоставления и удаления документа содержат идентификатор документа как параметр. Подобные функции, имеющие доступ к разным коллекциям данных, реализованы в компонентах трех уровней службы поддержки с некоторыми ограничениями (рис. 3.6).

Рисунок 3.6. Модуль маршрутизации

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

Второй уровень поддержки имеет доступ к коллекции тикетов второго уровня поддержки (создание, чтение, удаление) и возможность создания тикета для коллекции тикетов третьего уровня поддержки (передача тикета следующему уровню). Представление тикетов, как и в первом уровне поддержки, реализовано с помощью расширяющейся панели (Material Design) (см. прил. D).

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

3.2. Развертывание системы взаимодействия с клиентами

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

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

Манифест представляет с собой JSON файл с описанием приложения. Файл, который необходим для каждого Веб-расширения (WebExtension). Определяются имя, версия приложения, а также некоторые скрипты. Наличие манифеста поднимает рейтинг приложения в оценке Google Dev Tools и помогает корректному отображению приложения.

После публикации приложения произведена оценка Google Dev Tools, показавшая следующие результаты (см. рис. 3.7).

Рисунок 3.7. Оценка приложения Lighthouse (Google Dev Tools)

Приложение не завершено, поэтому не произведены завершающие процедуры развертывания приложения (добавление скрипта для офлайн доступа к данным, минимизация текста CSS и HTML).