ПКСС_КР_Селезнев

1.

МИНОБРНАУКИ РОССИИ
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«МИРЭА – Российский технологический университет»
РТУ МИРЭА
Институт информационных технологий (ИИТ)
Кафедра игровой индустрии
Дисциплина «Проектирование клиент-серверных частей»
КУРСОВАЯ РАБОТА
Тема: Разработка клиент-серверной системы управления модерацией
контента и анти-токсичностью.
Студентка: Селезнев С.А.
Группа: ИКБО-33-22
Руководитель: старший преподаватель Батанов А.О.
Москва 2025

2. Цель

Спроектировать клиент-серверную систему модерации пользовательского контента, обеспечивающую
контроль качества, безопасность и соответствие правилам платформы с акцентом на автоматизацию,
скорость обработки и масштабируемость.
Задачи
1. Идентификация предметной области автоматизации
2. Обзор и анализ аналогичных систем модерации
3. Выбор методологий концептуального моделирования
4. Разработка модели бизнес-процесса модерации «Как есть»
5. Разработка функциональной модели «Как должно быть»
6. Формулирование функциональных и нефункциональных требований
7. Выбор методологий логического моделирования
8. Разработка диаграмм логической модели системы модерации
9. Проектирование логической модели данных
10. Разработка архитектуры клиент-серверной системы модерации

3. 1. Идентификация предметной области автоматизации

Ключевые участники:
Пользователь (автор контента)
Модератор
Система модерации контента (автоматизированная)
Внешние системы и компоненты:
ML-сервис автоматической проверки
Сервис правил модерации (Rules Engine)
Система авторизации / проверки прав доступа
Сервис уведомлений (уведомления о статусе поста)
Система логгирования действий (история решений)
База данных постов и решений модерации

4. 2. Обзор и анализ аналогичных клиент серверных систем

Критерий
Модерация
Perspective API (Jigsaw/Google)
в
крупных
соц.
Проектируемая система
сетях (например, Meta)
Ключевая
цель
Предоставление
для
API
оценки
токсичности текста сторонним разработчикам.
Полный контроль над конвейером
Баланс
между
модерации для собственной платформы, (качество/скорость)
максимизация охвата и минимизация аудируемостью
рисков.
Сильные
стороны
Высокое
качество
предобученных
моделей, простота интеграции.
автоматизацией
и
гарантированной
всех
действий
для
средней/крупной платформы.
Глубокая интеграция с данными
Архитектурная
чистота
пользователя, масштаб для тренировки независимость:
уникальных моделей, многоуровневая микросервисов,
проверка (AI+человек).
и
применение
Outbox
и
Saga
для
максимальной надежности и возможности
кастомизации под нужды платформы.
Слабые
стороны
"Черный
внешнего
ящик",
сервиса,
зависимость
возможные
стоимость при больших объемах.
от
Экстремально сложная и дорогая
Необходимость
задержки, в разработке и поддержке система, сопровождения
неприменима
для
самостоятельного
ML-моделей
и
стороннего инфраструктуры.
использования.
Архитектурн
ый стиль
SaaS (API как сервис).
Сверхсложная
система
со
распределенная
Микросервисы
с
акцентом
на
множеством Событийно-ориентированную
специализированных сервисов.
архитектуру
(EDA)
для
гибкости
и

5. 3. Выбор методологии и технологии концептуального моделирования клиент-серверной системы

3. Выбор методологии и технологии
концептуального моделирования клиентсерверной системы
Методология/Нотация
UML
Область
Используется
моделирования
Обоснование применения
для
и
описания сосредоточиться на архитектуре
структур взаимодействия
Event Storming
позволяет
UML
системы в целом.
Используется для анализа и
моделирования бизнес-процессов
Event
Storming
сосредоточиться
на
позволяет
событиях,
происходящих в системе, а не на
конкретных
действиях
или
структурах данных
C4 Model
Используется
моделирования
программных систем
для
Данная модель позволяет
архитектуры провести
детализацию
последовательную
системы
—
от
общего контекста до конкретных
реализаций на уровне кода

6. 4. Разработка и анализ модели бизнес-процесса «Как есть»

4. Разработка и анализ модели бизнеспроцесса «Как есть»
EventStorming
BPMN-диаграмма

7. 5. Разработка функциональной модели «Как должно быть»

System Context Diagram

8. 6. Разработка требований к клиент-серверной системе

6. Разработка требований к клиентсерверной системе
Use-case диаграмма
Utility Tree NFR

9. 7. Выбор методологии и технологии логического моделирования клиент-серверной системы

Что
Зачем
использовалось
UML Class
Для демонстрации классов, их атрибутов, операций и
отношений между объектами.
ERD
Построить модель данных
Uml Sequence
Моделирование взаимодействия за определенный
отрезок времени
UML State
Нужна для моделирования поведения объекта или
системы
ArchiMate
Позволяет моделировать архитектуру системы

10. 8. Разработка диаграмм логической модели клиент-серверной системы

UML Class
Sequence-диаграмма

11. 8. Разработка диаграмм логической модели клиент-серверной системы

Sequence диаграмма «Успешная автоматическая
модерация»
Sequence диаграмма «Ручная модерация с эскалацией»

12. 8. Разработка диаграмм логической модели клиент-серверной системы

UML State диаграмма
UML State диаграмма

13. 9. Разработка логической модели данных

Рисунок 2.7 - ER-диаграмма

14. 10 . Разработка архитектуры клиент-серверной системы

10 . Разработка архитектуры клиентсерверной системы
Критерий для сравнения
Монолитная архитектура
Модульный монолит
Микросервисная архитектура
Внутреннее строение
Одно цельное приложение без
Единое приложение, разбитое
Набор небольших, автономных
внутренних границ.
Процесс деплоя
Деплой
всего
на логические, изолированные модули.
приложения
целиком как единого артефакта.
Надежность
и
отказоустойчивость
Сбой в любой части кода
потенциально
останавливает
Используемые технологии
минусы
сложности
приложения
единым
блоком, несмотря на модульность.
всю
систему.
Ключевые
Деплой
Схож с монолитом, но лучшая
модульная
изоляция
может
В основе общий стек, но внутри
стек (язык, фреймворки, БД) для всего
модулей возможны разные библиотеки
приложения.
и подходы.
Сложность масштабирования,
рост
кодом.
"коммунальных"
Независимое
развертывание
каждого сервиса.
Проблема в одном сервисе не
должна выводить из строя остальные.
локализовать проблемы.
Одинаковый технологический
и
и слабосвязанных сервисов.
проблем
с
Риск
между
"протекания"
модулями
истинного
масштабирования.
и
логики
отсутствие
независимого
Каждый сервис может быть
написан на своем стеке технологий.
Значительная
эксплуатации,
сложность
мониторинге
обеспечении взаимодействия.
в
и

15. 10 . Разработка архитектуры клиент-серверной системы

10 .
Разработка
архитектуры
клиентсерверной
системы
Arсhimate диаграмма