Skip to content

Latest commit

 

History

2 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 

Repository files navigation

ФГАОУ ВО «ИТМО» — Проектирование вычислительных систем

Единый отчёт по ЛР 1–3 (сквозная тема)

Тема: Программный сервис автоматизации проведения и проверки рубежных работ по дисциплине «ОПД» (дистанционные задания, автопроверка, хранение результатов и анализ самостоятельности; интеграция с университетским порталом Liferay).
Исполнитель: студент(ка) группы …
Руководитель:
Год: 2025


Аннотация

Работа описывает программный сервис для дистанционного проведения рубежных работ по дисциплине «ОПД» в ИТМО. Сервис обеспечивает генерацию индивидуальных вариантов, интерфейс выполнения заданий, автоматическую проверку и выставление результата, долговременное хранение заданий/решений/оценок, сбор поведенческих метрик для оценки самостоятельности и анти-списывания, тренировочный режим и интеграцию с порталом университета (Liferay/SSO). Представлены: самостоятельное техническое задание (по требованиям методички), логическая архитектура системы (контекст, компоненты, последовательности, ER-модель), а также аспектное проектирование по критически важным нефункциональным требованиям (безопасность, надёжность/отказоустойчивость, масштабируемость/производительность, тестопригодность/верифицируемость, удобство/доступность). Включены таблицы требований с приоритетами, спецификация API, тест-план, матрица трассируемости и чек-лист соответствия заданиям ЛР1–ЛР3. Формат и глубина разделов согласованы с примерами отчётов и указаниями преподавателя.

Ключевые слова: рубежная работа; автопроверка; Liferay; SSO; анти-списывание; поведенческие метрики; логическая архитектура; ER-модель; нефункциональные требования.


Содержание

  1. Предпосылки и допущения (общие)
  2. Предметная область / Введение
  3. Концепция продукта
  4. Лабораторная 1 — Техническое задание (самостоятельный документ)
  5. Лабораторная 2 — Синтез логической структуры системы
  6. Лабораторная 3 — Аспектное проектирование (NFR)
  7. Спецификация API (фрагмент)
  8. Тест-план (фрагмент)
  9. Чек-лист соответствия заданию
  10. Приложения (диаграммы, таблицы)

Предпосылки и допущения (общие)

  • Проект — чисто программный; аппаратные аспекты не применяются (Н/П).
  • Интеграции: портал Liferay (SSO), реляционная БД, почта/веб-уведомления; по необходимости — очередь задач/кэш.
  • Допускается уточнение требований в процессе выполнения ЛР2–ЛР3; результаты перетекают между этапами одной темы.

Предметная область / Введение

Сервис предназначен для организации рубежных работ по «ОПД» в дистанционном формате: создание индивидуальных вариантов, выполнение в веб-интерфейсе, автоматическая проверка, выставление оценки, хранение артефактов и аналитика самостоятельности на основе поведенческих метрик. Интеграция с Liferay обеспечивает единую точку входа (SSO), уведомления и снижение нагрузки преподавателей.


Концепция продукта

В одно предложение. Программный сервис для дистанционной рубежной работы по «ОПД» с автогенерацией вариантов, автопроверкой, оцениванием и аналитикой самостоятельности, интегрированный с Liferay.

В один абзац. Сервис формирует индивидуальные варианты, предоставляет интерфейс для решения, автоматически проверяет ответы, рассчитывает итоговый балл, хранит решения и метрики, выявляет признаки недобросовестности, отправляет уведомления и строит отчёты для студента и преподавателя; предусмотрен тренировочный режим и API-интеграции с порталом ИТМО.


Лабораторная 1 — Техническое задание (самостоятельный документ)

Предпосылки и допущения: требования приведены построчно, сгруппированы; у каждого — приоритет Must/Should/Could/Won’t. Аппаратные аспекты: Н/П.

4.1. Назначение и область применения

  • (Must) Сервис автоматизирует проведение рубежных работ по «ОПД» в дистанционном формате.
  • (Must) Сервис применяется в учебном процессе ИТМО и интегрируется с Liferay (единая учётная запись/SSO).
  • (Should) Использование сервиса снижает трудозатраты преподавателей на подготовку, проверку и анализ.

4.2. Термины (сокращённо)

  • Вариант — индивидуальный набор заданий для студента.
  • Сабмишн — отправленное студентом решение.
  • Метрики — поведенческие показатели (время, переключения вкладок, скорость набора и пр.).
  • Анти-списывание — механизмы выявления недобросовестных попыток.

4.3. Функциональные требования (поведение «чёрного ящика», ≥1 страницы)

Генерация и назначение

  • F-1 (Must) Создание пула заданий с параметрами сложности/тематики.
  • F-2 (Must) Генерация индивидуальных вариантов на основе правил (случайность/семена/пулы).
  • F-3 (Must) Назначение вариантов группам/студентам с дедлайном и шкалой оценивания.
  • F-4 (Should) Версионирование банка заданий.

Интерфейс выполнения

  • F-5 (Must) Веб-интерфейс решения с автосохранением черновиков.
  • F-6 (Must) Типы заданий: тесты, короткий ответ, код/файл, развернутый ответ.
  • F-7 (Should) Доступность (a11y): навигация клавиатурой, контрастность, alt-тексты.
  • F-8 (Must) Фиксация действий пользователя (старт/пауза/время бездействия).

Автопроверка и выставление результата

  • F-9 (Must) Автоматическая проверка формальных задач (тесты, код через стенд).
  • F-10 (Must) Расчёт итогового балла (вес заданий, штрафы).
  • F-11 (Should) Полуавтоматическая проверка развернутых ответов (рубрикатор).
  • F-12 (Must) Публикация результатов и обратной связи по политике курса.

Хранение артефактов

  • F-13 (Must) Хранение заданий, вариантов, решений, протоколов проверки, оценок.
  • F-14 (Should) Экспорт результатов (CSV/JSON), печать отчётов.

Метрики и анти-списывание

  • F-15 (Must) Сбор поведенческих метрик (время, переключения вкладок, скорость ввода).
  • F-16 (Should) Индикаторы самостоятельности (эвристики/пороговые значения).
  • F-17 (Could) Детектор схожести решений (текст/код) и аномалий таймингов.

Тренировочный режим

  • F-18 (Must) Тренировочный режим (без учёта в ведомости).
  • F-19 (Should) Подсказки/разбор типичных ошибок в тренировках.

Роли и доступ (RBAC)

  • F-20 (Must) Роли: Студент, Преподаватель, Администратор; разграничение операций.
  • F-21 (Must) Аутентификация через Liferay/SSO; авторизация по сущностям (курс/группа/задание).

Уведомления и интеграции

  • F-22 (Should) Почтовые и веб-уведомления (назначение, дедлайн, результат).
  • F-23 (Should) Интеграция с журналом успеваемости (выгрузка оценок).
  • F-24 (Could) Вебхуки/REST для внешних аналитик.

Эксплуатация

  • F-25 (Must) Аудит значимых событий (вход, сабмишн, изменение оценки).
  • F-26 (Should) Агрегированные отчёты по курсу/группе/студенту.

4.4. Нефункциональные требования (ПО; ≥5)

  • N-1 (Must) Безопасность: шифрование трафика; вход через SSO; журналирование; RBAC.
  • N-2 (Must) Защита от XSS/CSRF/SQLi; ограничение частоты запросов.
  • N-3 (Should) Бекапы БД (RPO≤5 мин, RTO≤1 час); изоляция отказов; graceful degradation.
  • N-4 (Should) Масштабирование под пиковые нагрузки; эффективность автопроверки.
  • N-5 (Should) Переносимость: контейнеризация; внешние конфигурации; IaC (опционально).
  • N-6 (Should) Удобство: понятная навигация, единый UI-паттерн; доступность (WCAG AA).
  • N-7 (Should) Тестопригодность: модульные/интеграционные/e2e тесты, фикстуры данных.
  • N-8 (Could) Трассируемость: связь требований с тестами/диаграммами/релизами.
  • N-9 (Should) Наблюдаемость: метрики/логи/трейсы для ключевых сценариев.
  • N-10 (Could) Обновляемость без простоя (rolling).
  • N-11 (Should) Конфиденциальность: минимизация/защита ПДн.
  • N-12 (Won’t) Аппаратные специфики, не связанные с ПО (Н/П).

4.5. Режимы работы

  • R-1 (Must) Экзаменационный режим: фиксированные окна времени, жёсткие правила.
  • R-2 (Must) Обычный режим рубежной: гибкие дедлайны, публикация результатов.
  • R-3 (Must) Тренировочный режим: без учёта в ведомости, расширенные подсказки.

4.6. Ограничения на применение/реализацию

  • О-1 (Must) Использование единого входа Liferay/SSO (корпоративные политики).
  • О-2 (Should) Соответствие требованиям ИБ университета; хранение ПДн в РФ.
  • О-3 (Won’t) Аппаратные ограничения — Н/П.

4.7. Перспективные возможности

  • P-1 (Could) Продвинутые анти-списывающие модели (ML).
  • P-2 (Could) Интеграция с внешними тренажёрами/песочницами.
  • P-3 (Could) Адаптивная генерация вариантов по профилю студента.

4.8. Матрица трассируемости (фрагмент)

ID Артефакт модели/диаграмма API Тест/проверка
F-2 Диаграмма компонентов; последовательность «Студент проходит рубежную» /variants, /assignments e2e-RB-01
F-9 Компонент «Автопроверка»; последовательность «Автопроверка и оценка» /submissions/check INT T-CHK-02
F-15 Компонент «Сбор метрик»; последовательность «Анализ самостоятельности» /metrics UNIT MTR-01; e2e ANT-02
N-3 Аспект ЛР3 «Надёжность» DR/BCP (RPO/RTO)
R-3 Режимы работы /training/* e2e-TR-01

4.9. Принятые допущения

  • D-1 Внешний журнал оценок допускает импорт по CSV/REST.
  • D-2 SSO предоставляет подтверждённые роли и группы обучающихся.
  • D-3 Пиковая нагрузка ≤ N одновременных попыток (уточняется в эксплуатации).

Лабораторная 2 — Синтез логической структуры системы

Предпосылки и допущения: моделирование без конкретики реализации; диаграммы — Mermaid; без кода на C.

5.1. Контекстная диаграмма

graph TD
  ST[Студент] -->|SSO| Liferay[(Портал Liferay/SSO)]
  PR[Преподаватель] -->|SSO| Liferay
  AD[Администратор] -->|SSO| Liferay

  Liferay -->|OAuth2/OpenID| SERVICE[Сервис рубежных работ]
  SERVICE --> DB[(Реляционная БД)]
  SERVICE --> MQ[(Очередь/Кэш)]
  SERVICE --> MAIL[(Почта/Веб-уведомления)]

  ST -->|Веб-интерфейс| SERVICE
  PR -->|Веб-интерфейс| SERVICE
  AD -->|Веб-интерфейс| SERVICE
Loading

5.2. Диаграмма компонентов/подсистем

graph LR
  subgraph UI[UI/Frontend]
    UI1[Рубежная работа]
    UI2[Тренировка]
    UI3[Преподаватель/Отчёты]
  end

  subgraph CORE[Сервис]
    GEN[Генерация вариантов]
    CHK[Автопроверка]
    GRD[Оценивание]
    MTR[Сбор метрик]
    ANT[Анти-списывание]
    REP[Отчётность]
    TRN[Тренировочный режим]
    API[REST API/Вебхуки]
    AUD[Аудит]
  end

  DB[(Реляц. БД)]
  MQ[(Очередь/Кэш)]
  MAIL[(Почта/Уведомл.)]

  UI1 --> API
  UI2 --> API
  UI3 --> API

  API --> GEN
  API --> CHK
  API --> GRD
  API --> MTR
  API --> ANT
  API --> REP
  API --> TRN
  API --> AUD

  GEN --> DB
  CHK --> DB
  GRD --> DB
  MTR --> DB
  REP --> DB
  TRN --> DB
  ANT --> MQ
  CHK --> MQ

  API --> MAIL
Loading

5.3. Диаграммы последовательностей (ключевые сценарии)

5.3.1. Студент проходит рубежную

sequenceDiagram
  participant S as Студент
  participant UI as Веб-клиент
  participant API as API сервиса
  participant GEN as Генерация
  participant DB as БД

  S->>UI: Вход через Liferay/SSO
  UI->>API: Запрос назначенного варианта
  API->>GEN: Сформировать/получить вариант
  GEN->>DB: Чтение пула задач
  DB-->>GEN: Набор
  GEN-->>API: Вариант
  API-->>UI: Вариант и таймер
  S->>UI: Ответы / автосохранение
  UI->>API: POST /submissions
  API->>DB: Сохранение сабмишна
  API-->>UI: Подтверждение
Loading

5.3.2. Автопроверка и выставление оценки

sequenceDiagram
  participant API as API сервиса
  participant CHK as Автопроверка
  participant GRD as Оценивание
  participant DB as БД

  API->>CHK: Проверить сабмишн
  CHK->>DB: Эталоны/тесты
  DB-->>CHK: Правила/данные
  CHK-->>API: Результаты по заданиям
  API->>GRD: Рассчитать итог
  GRD->>DB: Сохранить результат/протокол
  DB-->>GRD: OK
  API-->>Студент/Преподаватель: Публикация результата
Loading

5.3.3. Анализ метрик самостоятельности

sequenceDiagram
  participant Client as Клиент
  participant MTR as Сбор метрик
  participant ANT as Анти-списывание
  participant DB as БД
  participant TCH as Преподаватель

  Client->>MTR: События (тайминги, фокус окна)
  MTR->>DB: Запись метрик
  ANT->>DB: Анализ метрик/сравнение решений
  ANT-->>TCH: Индикаторы самостоятельности (отчёт)
Loading

5.3.4. Тренировочный режим

sequenceDiagram
  participant S as Студент
  participant UI as Веб-клиент
  participant TRN as Тренировки
  participant DB as БД

  S->>UI: Запуск тренировки
  UI->>TRN: Запрос задач тренировки
  TRN->>DB: Получение задач/подсказок
  DB-->>TRN: Данные
  TRN-->>UI: Набор задач с подсказками
  UI->>TRN: Проверка/разбор
  TRN-->>UI: Обратная связь (без оценки)
Loading

5.4. Модель данных (ER)

erDiagram
  USERS {
    uuid id PK
    string sso_id UNIQUE
    string role
    string group_id
  }
  TASKS {
    uuid id PK
    string course
    string topic
    int difficulty
    json spec
    bool active
  }
  VARIANTS {
    uuid id PK
    uuid user_id FK
    uuid assigned_by FK
    timestamp deadline
    json seed_rules
  }
  SUBMISSIONS {
    uuid id PK
    uuid variant_id FK
    uuid user_id FK
    timestamp submitted_at
    json answers
    string status
  }
  RESULTS {
    uuid id PK
    uuid submission_id FK
    float score
    json per_task
    json protocol
  }
  METRICS {
    uuid id PK
    uuid user_id FK
    uuid submission_id FK
    json events
    json indicators
  }

  USERS ||--o{ VARIANTS : назначено
  USERS ||--o{ SUBMISSIONS : подаёт
  VARIANTS ||--o{ SUBMISSIONS : имеет
  SUBMISSIONS ||--|| RESULTS : приводит к
  SUBMISSIONS ||--o{ METRICS : метрики
  TASKS ||--o{ VARIANTS : включены через seed_rules
Loading

Индексы: USERS(sso_id), VARIANTS(user_id, deadline), SUBMISSIONS(variant_id, user_id, submitted_at), RESULTS(submission_id), METRICS(submission_id).

5.5. Роли и права (RBAC)

Роль Права
Студент Просмотр назначений; выполнение; отправка решений; просмотр результатов; запуск тренировок
Преподаватель Создание/редактирование задач; назначение/снятие; просмотр и корректировка оценок; отчёты; просмотр индикаторов
Администратор Управление курсами/ролями; конфигурация интеграций; аудит и доступ к логам

5.6. Ограничения/предпосылки интеграций и ИБ

  • SSO — источник истины для идентичности и ролей.
  • Реляционная БД — централизованное хранилище; ПДн минимизируются и защищаются.
  • Журналы аудита хранятся согласно политике ИБ; доступ — по роли.

Лабораторная 3 — Аспектное проектирование (NFR)

Предпосылки и допущения: рассматриваются критически важные NFR; аппаратные факторы — Н/П.

Безопасность

  • Цель: конфиденциальность/целостность данных, корректный доступ по ролям.
  • Риски: XSS/CSRF/SQLi; компрометация аккаунтов; эскалация привилегий; утечка ПДн.
  • Решения: SSO (OIDC); строгий RBAC; TLS; валидация ввода; CSP/HTTP security headers; CSRF-токены; секреты вне кода; аудит.
  • Метрики/приёмка: 0 критических в SAST/DAST; чек-лист OWASP ASVS L1/L2; отсутствие утечек в логах.
  • Следы: ТЗ N-1/N-2; ЛР2 (RBAC, API, аудит); тесты SEC-*.

Надёжность/отказоустойчивость

  • Цель: доступность сервиса при сбоях и быстрое восстановление.
  • Риски: отказ БД; пики нагрузки; сбои интеграций; потеря данных.
  • Решения: регулярные бэкапы (RPO≤5 мин, RTO≤1 час); ретраи с джиттером; очереди для асинхронных задач; circuit breaker.
  • Метрики/приёмка: аптайм ≥ 99.5%; успешные учения DR-плана; MTTR ≤ 1 час.
  • Следы: ТЗ N-3; ЛР2 (MQ/кэш); тесты REL-*.

Масштабируемость и производительность

  • Цель: устойчивость к пикам одновременных попыток; быстрая автопроверка.
  • Риски: рост латентности; блокировки при проверке; переполнение очередей.
  • Решения: горизонтальное масштабирование stateless-компонентов; кэш горячих данных; очереди проверки; профилирование; лимиты.
  • Метрики/приёмка: p95 API < 300 мс (чтение), < 1 с (постановка проверки); пропускная способность ≥ X/мин.
  • Следы: ТЗ N-4; ЛР2 (CHK, MQ); тесты PERF-*.

Тестопригодность/верифицируемость

  • Цель: снизить регрессии и ускорить выпуск.
  • Риски: flaky-тесты; ручные процедуры; недостоверные данные.
  • Решения: unit/integration/e2e; фикстуры и анонимизация реальных данных; контракты API; smoke-набор; покрытие ключевых сценариев.
  • Метрики/приёмка: покрытие критических модулей ≥ 80%; CI ≤ 15 мин; 0 блокирующих дефектов на приёмке.
  • Следы: ТЗ N-7; ЛР2 (API/диаграммы); тест-план.

Удобство/доступность (UX/a11y)

  • Цель: понятный интерфейс, доступность для всех групп пользователей.
  • Риски: путаница сценариев; недоступные элементы; перегрузка интерфейса.
  • Решения: единый дизайн-гайд; клавиатурная навигация; контрастность; aria-атрибуты; форматируемые отчёты; локализация.
  • Метрики/приёмка: успешность базовых задач ≥ 95% в UX-тестах; WCAG AA; −30% времени на типовые операции.
  • Следы: ТЗ N-6; ЛР2 (UI/экраны); e2e UX-*.

Спецификация API (фрагмент)

Метод Путь Запрос Ответ Auth Примечания
GET /api/v1/tasks course, topic, page 200 OK: список задач SSO/JWT Фильтрация по курсу/темам
POST /api/v1/variants body: {userId, rules} 201 Created: {variantId} SSO/JWT Назначение варианта
GET /api/v1/variants/{id} 200 OK: {tasks, deadline} SSO/JWT Студент/преподаватель
POST /api/v1/submissions body: {variantId, answers} 202 Accepted: {submissionId} SSO/JWT Постановка на проверку
POST /api/v1/submissions/{id}/check 200 OK: {perTask, score} SSO/JWT Автопроверка/оценивание
GET /api/v1/results/{submissionId} 200 OK: {score, protocol} SSO/JWT Просмотр результата
POST /api/v1/metrics body: {submissionId, events} 204 No Content SSO/JWT Сбор метрик
GET /api/v1/reports/course/{courseId} q=group,user 200 OK: агрегированный отчёт SSO/JWT Отчётность

Тест-план (фрагмент)

Уровень Объект Требования Условия Критерии приёмки
Unit Генерация вариантов (правила/семена) F-2 Fixtures; edge-cases Покрытие ≥ 80% модулей GEN
Unit Автопроверка формальных задач F-9 Тест-эталоны 100% позитив/негатив правил
Integration Сабмишн → проверка → результат F-9/F-10 DB+CHK+GRD p95 < 1 с постановка
E2E Студент проходит рубежную F-5..F-13 Браузерные сценарии Успешность ≥ 95%
Security OWASP ASVS чек-лист N-1/N-2 SAST/DAST 0 критических
Reliability DR-план восстановления N-3 Бэкапы/restore RTO ≤ 1 час; RPO ≤ 5 мин

Чек-лист соответствия заданию

Требование из задания Где выполнено
ЛР1: Самодостаточное ТЗ; требования построчно, приоритеты Раздел 4 (4.3–4.7)
ЛР2: Логическая архитектура; диаграммы (контекст, компоненты, последовательности, ER) Раздел 5 (5.1–5.4)
ЛР3: Аспектное проектирование ≥5 NFR Раздел 6
Таблицы: требования, API, тест-план, матрица трассируемости Разделы 4.8, 7, 8
Чек-лист соответствия PDF Раздел 9
Формат: русский, академический; «Н/П» для аппаратных аспектов Весь документ

Приложения (диаграммы, таблицы)

  • Диаграммы Mermaid включены в разделы 5.1–5.4 и GitHub отрисует их автоматически.
  • При необходимости экспортируйте диаграммы в SVG/PNG с помощью Mermaid Live Editor.

Примечание по интеграциям: для прототипа достаточно Liferay/SSO, реляционной БД и почты/уведомлений; ввод очереди/кэша рекомендован при росте нагрузки (сценарии проверки/антимошенничества).

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors