UseCase'ы приложения:

Up And Down - система для учета и отслеживания состояния для людей, больных БАР

UseCase №1

1.Название: Зарегистрировать пользователя

2.Актор: Пользователь

3.Цель: Внести данные о новом пользователе в систему

4.Предусловия:

  • Пользователь не авторизован в системе
  • Пользователь с данным login'ом отсутствует в системе

5.Основной поток:

  • Пользователь заходит в приложение на любую страницу
  • Из-за отсутсвия авторизации приложение перенаправляет его на страницу авторизации
  • Пользователь кликает по ссылке, ведущей на странице регистрации
  • На странице регистрации пользователь вводит логин и пароль
  • Пользователь нажимает кнопку "Зарегистрироваться"
  • Система выводит сообщение, что пользователь зарегистрирован в приложении

6.Альтернативные потоки:

А1.Пользователь с таким логином уже есть в системе

  • Процедура регистрации проваливается
  • Выводится нотификация с сообщением об ошибке по причине наличия такого же логина в системе

А2.Пользователь оставил пустым логин или пароль

  • При попытке регистрации подсвечиваются незаполненные поля
  • Выводится сообщение об ошибке

7.Постусловия

  • Пользователь с указанным логином сохранен в БД

8.Маршруты

  • /api/v1/auth/register - Регистрация пользователя

9.Контракт

Request

{
  "login": "ivan_89",
  "password": "S3cureP@ssw0rd"
}

Требования к валидации:

  • login: 3-50 символов, [a–z0–9._-], уникальное значение
  • password: ≥ 8 символов

Response - 201 - Created

{
  "user": {
    "login": "ivan_89"
  }
}

Errors

  • 409 USER_EXISTS — пользователь с таким логином уже есть
  • 422 VALIDATION_FAILED — пустой логин/неправильный пароль
  • 400 BAD_REQUEST — сервер не смог десереализовать JSON

10. Используемые сущности ДБ

  • users(guid, login, hashed_password)

UseCase №2

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

2.Актор: Пользователь

3.Цель: Предоставить пользователю возможность получить его данные в виде дневника болезни

4.Предусловия:

  • Пользователь должен быть зарегистрирован в системе
  • Пользователь должен быть не авторизован в системе

5.Основной поток:

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

6.Альтернативные потоки:

А1.Введен неправильный логин или неправильный пароль

  • Пользователь не получает токен, авторизация провалена
  • Выводится сообщение об ошибке

А2.Поле логин или пароль оставлены пустыми

  • При попытке авторизации не происходит запрос токена. Авторизация провалена
  • Пустые поля подкрашиваются, как ошибочно заполненные
  • Выводится сообщение об ошибке

7.Постусловия

  • Сессия пользователя в виде токена сохраняется на сервере
  • Пользователь перенаправлен на основную страницу, где выводится его дневник болезни

UseCase №3

1.Название: Вход в систему

2.Актор: Пользователь

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

4.Предусловия:

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

5.Основной поток:

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

6.Альтернативные потоки:

А1.Записей в дневнике нет

  • Заместо вывода записей в дневнике, система выводит заглушку, информирующую пользователя, что дневник пуст
  • Система делает доступными операции с дневником

А2.Записи по какой-то причине не подгрузились

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

7.Постусловия

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

UseCase №4

1.Название: Просмотр схемы лечения

2.Актор: Пользователь

3.Цель: Предоставить пользователю список доступных схем лечения

4.Предусловия:

  • Пользователь авторизовался в системе
  • Пользователь находится на основной странице приложения
  • Основные данные на этой странице(дневник, схемы) уже выведены системой

5.Основной поток:

  • Пользователь кликает по блоку схемы лечения из списка схем.
  • Пользователь перенаправляется на страницу детального вывода схемы
  • Система выводит полную схему лечения: название, список основных лекарств, список срочных лекарств, пояснения когда принимать срочные лекарства

6.Альтернативные потоки:

А1. У данного пользователя отсутствуют схемы

  • Заместо поверхностного вывода схем списком выводится заглушка с информацией о том, что схем нет

А2. Детальная информация по схеме не загрузилась

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

7.Постусловия

  • Пользователь получил подробную информацию о схеме лечения
S
Description
No description provided
Readme 933 KiB
Languages
C++ 91%
CMake 7.5%
Dockerfile 1.4%