Состав и структура программного комплекса

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

Базы данных.Так как MongoDBимеет подход NoSQL,то таблицы базы данных будут называться коллекциями, а строки таблиц – документами. Реализация коллекций также происходит на серверной части веб-комплекса. База данныхсостоит из трех коллекций:

1. User – коллекция пользователей. Структура документа имеет следующие обязательные поля:

a. email – почта, уникальное значение

b. password – хэш пароля

c. address – строка адреса

d. latLng–географические координаты адреса (широта и долгота)

e. login – ФИО

f. phone – телефон

g. role – роль, перечисляемый тип из трех значений: пациент, врач, администратор. Дефолтное значение «пациент», выставляется при регистрации

2. Worker – коллекция рабочих графиков врачей

a. id_user –идентификатор пользователя «врач»

b. estimated_time – затрачиваемое время на обход пациентов

c. patients – массив документов коллекции record (подробнее в описании коллекции). Порядок документов массива задает путь обхода пациентов.

d. start–время начала рабочего дня

e. end –время конца рабочего дня

3. Record – коллекция записей пациентов

a. id_user – идентификатор документа коллекции user

b. id_worker – идентификатор документа коллекцииworker

c. time_create – время создания записи

d. time_target – целевое время посещения пациента врачом. Применяется для планирования обхода. Назначается после расчета или перерасчета пути алгоритмом

e. comment – примечание, краткое описание причины вызова врача

Серверная сторона.Серверная сторона программного средствапредставляет независимый от интерфейса веб-сервис, использующий архитектуру REST. Взаимодействие с ним происходит по HTTP-протоколу (с помощью команд GET, POST, PUT, DELETE), а обмен данными осуществляется в формате JSON. СтруктураAPIвеб-сервиса представлена в виде схемы на рисунке 2.9

Состав и структура программного комплекса - student2.ru

Рисунок 2.9. API серверной части

Запросы производные от «auth» к API, не проходят проверку сессии по токену JWT. Остальные запросы – проходят проверку сессии.Токен может быть получен только после авторизации (запрос /auth/authenticate). В случае успешной проверки вызывается соответствующий запросу метод. Если токен неверный или отсутствует в заголовке запроса, то приходит ошибка «401 Authenticationerror». Данная ошибка может быть в двух случаях: когда токен неверный/отсутствует или закончилась сессия пользователя. Для последнего случая используется POST запрос /auth/check, который проверяет сессию и продлевает ее, если она не закрыта, а в ответе возвращает модель пользователя. Это решение полезно для SPAинтерфейса веб-сервиса. Перед отображением, компонент интерфейса посылает checkзапрос на сервер, после чего, на основании полученного ответа показывает соответствующий пользователю контент.

Запросык API вызывают соответствующие методы контроллера, которые взаимодействуют с базой данных и выполняют определенные действия. Запросы,проходящие проверку сессии, разделены на четыре вида: для врачей, пациентов, администратора или любой роли. Проверка ролей пользователя осуществляется аналогичным образом, как и проверка авторизации. При поступлении запроса, перед вызовом метода контроллера, происходит соответствующая проверка доступа, и в случае ее успеха вызывается уже самметод. Описание методов обрабатывающих запросы, как представлено на рисунке 2.9 делятся на 4 группы:worker, user, record, auth. В таблице 2.2 представлено подробное описание каждого метода.

Таблица 2.2

Описание методов обработки запросов

Запрос	Метод	Действие
GET /worker/	getWorker	Возвращает распределение рабочего графика врача на текущую неделю. Формат данных: массив моделей worker
GET /worker/	addWorker	Добавляет рабочий график на заданный пользователем промежуток из двух дат (время и дата начала и конца)

Продолжение таблицы2.2

Запрос	Метод	Действие
PUT /worker/	changeWorker	Изменяет временной промежуток рабочего графика
DELETE /worker	deleteWorker	Удаляет рабочий график
GET /worker/all	getDoctors	Возвращает массив работающих врачей на текущий день, у которых занятость (estimated_time) не превышает конец минус начало рабочего графика
GET /worker/all/:date	infoWorkers	Возвращает информацию о рабочих графиках врачей и их выполненных заявках, начиная с указанной даты в параметре запроса date
GET /record/all	getRecords	Возвращает список записей пациентов на текущий (сегодняшний) рабочий график врача
GET /record	getRecord	Возвращает текущую заявку пациента
POST /record	addRecord	Регистрирует заявку пациента
PUT /record	changeRecor	Изменяет данные текущей заявки
DELETE /record	delRecord	Удаляет заявку
GET /user	getUser	Возвращает модель текущего авторизированного пользователя
PUT /user	changeUser	Изменяет данные пользователя
GET /user/allUsers	getUsers	Возвращает список пользователей
PUT /user/setRole	setRole	Изменяет роль пользователя
DELETE /user	delUser	Удаляет пользователя
POST auth/register	register	Регистрирует нового пользователя
POST /auth	authenticate	Открывает сессию пользователя и возвращает JWT токен
POST /auth/check	check	Возвращает токен JWT если сессия пользователя открыта

Стоит отметить, что при создании, удалении или изменении (в случае смены врача) заявки, запускается алгоритм оптимизации маршрута, так как соответственно происходит изменение у врачасписка пациентов.

Интерфейс.Работу с запросами серверной стороны непосредственно берет на себя интерфейс программного средства и предоставляет пользователю следующие возможности:

1. Авторизация пользователей:

· Форма входа:

§ Адрес электронной почты

§ Пароль

· Форма регистрации:

§ Адрес электронной почты (уникальный)

§ Пароль

§ Подтверждение пароля

§ ФИО

§ Дата рождения

§ Адрес проживания

§ Номер полиса (уникальный)