UpAndDown/README.md

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

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

UseCase №1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.API-Маршруты

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

9.Контракт

Register-Request

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

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

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

Response - 201 - Created

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

Errors

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

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

• users(guid(PK), login(unique), hashed_password)

UseCase №2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.API-Маршруты

• POST /api/v1/Auth/Login - Вход пользователя в систему и получение токена
• POST /api/v1/Auth/Logout - Отозвать токен и выйти из системы.

9.Контракт

Login-Request

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

Response - 200 - OK

{
  "token": af32df3bas739f272bd109c823
  "expiresIn": 36000000  // 10 часов
}

Errors

• 401 BAD_CREDENTIALS — неверный логин/пароль (А1)
• 422 VALIDATION_FAILED — пустые поля (А2)

Logout-Request

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

Response - 200 - OK

{
  "token": af32df3bas739f272bd109c823
  "expiresIn": 36000000  // 10 часов
}

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

• users(guid(PK), login(unique), hashed_password)

UseCase №3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.API-Маршруты

• GET /api/v1/User/Diaries - получить кусок дневника пользователя (требует Authorization: Bearer ) query-параметры: from (int, по умолч. 0), count (int, по умолч. 20)
• GET /api/v1/User/TreatmentSchemes - получить кусок дневника пользователя (требует Authorization: Bearer ) query-параметры: from (int, по умолч. 0), count (int, по умолч. 20)

9.Контракт

Diaries-Request

Response - 200 - OK

{
  diaries: [
    {
      "guid": "e89b6a0c-4b0f-4722-a410-1e0c1864bf8a",
      "time": "10.08.2025",
      "mania_level": 1,
      "depression_level": 2,
      "mood_level": 3,
      "activity_level": 4,
      "appetite_level": 5,
      "dream_level": 6,
      "anxiety_level": 7,
      "treatment_scheme": {
        "guid": "bf6d1555-39e9-4d73-8928-4763627f4dd5"
        "treatment_name": "Bipolar I Scheme"
        "medications": [
          {
            "guid": "8af2dfa9-3add-413c-9a0e-ff605088f1d5",
            "name": "Litii Carbonate",
            "dose": 1800,
            "unit": "mg",
            "is_urgent": false
          }
        ]
      }
    }
  ]
}

Errors

• 401 TOKEN_REQUIRED|TOKEN_EXPIRED — токен недействителен, либо отсутствует
• 500 DATA_LOAD_FAILED — ошибка при загрузке данных (А2)

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

• users(guid(PK), login(unique), hashed_password)

UseCase №4

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

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

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

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

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

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

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

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

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

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

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

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

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

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