MVP: 1) Возможность создания/добавления документов по отделам, 2) Интеграция с сервисом сотрудники. 3) Возможность редактировать, подписовать документы БП: 1) Дизайн приложения должен быть в корпаративных цветах. 2) Срок хранения док-ов 5 лет. БО: 1) Система доступна ток сотрудникам имеющим корпаратив учёт запись. 2) Удалять доки могут только пользователь с уровнем доступа админ ФТ- Описывают что система должна делать или какими функциональностями обладать. ФТ: 1) Пользователи должны иметь возможность создавать новые документы 2) Подписание доков осуществляется с помощью ЭЦП. 3) Система должна поддерживать функцию пойска по опред параметрам НФТ- описывают ограничения, производительность, безопастность, надёжность НФТ: 1) Доступ должен быть защищен паролями и аутентификацией. 2) Система должна быть доступна 24/7, 3) Система должна обрабатывать 50 транзакции в секунду. US- описание ФТ с точки зрения пользака( что жолжно реализ, почему важно, и как работать) US- Как сотрудник компании, я могу подписать заявление на отпуск в СЭД, чтобы ускорить процесс оформления отпуска UC- Рекция системы на действия пользователя. UC- Название, цель, Акторы, триггер, предусловия, Осн сцен, Альт сцен, постусловия. Сбор треб: 1)Интервью заказчики,пользаки, 2) Наблюдение и анализ текущих процессов 3) Анкеты опросы 4) Прототипы, демо версии 5) Сессий мозгового штурма 6) Анализ конкурентов Требования: Понятность, еденичность, атомарность, измеримость, выполнимость, актуальность, проверяемость, трассировка ( связь между БТ) Kafka- раскидывает сообщения в журнал пользак САМ забирает нужную инфу из топиков. Нужна подписка (топик- тема(партиции), категория, канал) - Архивирование документов: Все документы поступают в топики Kafka, откуда они могут быть переданы в системы долговременного хранения Rabbit MQ – помещает сообщение в очередь и отслеживает статус сообщения, есть гарантия доставки. - Уведомления о новых документах: Быстрая доставка уведомлений пользователям или другим системам о новых документах или изменениях в документах. - Маршрутизация задач: Направление задач на обработку в различные отделы или системы на основе сложных правил маршрутизации. АПИ- програмный интерфейс Рест апи – система настройки общения между двумя системами ( клиент отправляет запрос, система отвечает) 1. REST API (Representational State Transfer API) — это стандарт архитектуры для взаимодействия между компонентами программного обеспечения через интернет с помощью HTTP методов. 2. RESTful API является более строгим подходом к проектированию API в сравнении с обычным REST API. 3. SOAP— это протокол обмена сообщениями между компьютерами в сети, использующий XML для структурирования данных. SOAP часто используется для вызова удаленных процедур. 4. Шина данных — это архитектурный шаблон, который позволяет различным приложениям обмениваться данными через общий канал (шину). Это позволяет интегрировать различные системы и обеспечивает централизованное управление данными. 5. Kafka — это распределенная платформа для обработки потоков данных и работы с сообщениями в реальном времени. Он позволяет надежно передавать сообщения между различными компонентами системы. Партиции в Apache Kafka — это способ разделения данных внутри темы (topic) для улучшения производительности и масштабируемости. Когда вы отправляете сообщение в тему, Kafka распределяет его по одной из партиций этой темы. Это позволяет нескольким потребителям (консьюмерам) читать сообщения параллельно, что ускоряет обработку данных. 6. RabbitMQ — это ПО для обмена сообщениями между различными приложениями и службами. Он реализует протокол AMQP (Advanced Message Queuing Protocol) и обеспечивает надежную доставку сообщений в асинхронном режиме. Методы: GET – получение данных с сервера в УРЛ. POST отправка данных на сервер (в теле запрос ключ-значение) PUT обновление или создание ресурса на сервере ( новое знач в теле запроса) PATCH частичное обновление ресура ( в теле запроса ключ значение) Delete – Удаление с сервера Эндпоинт, заголовки Хедер, тело бади, -----в ответе тож самое ток коды ещё 1**инф, 200 успех, 201 создан, 301 перемещен, 307 временно перемещ, 4** на стороне клиента 400 некорректный запрос, 401 аутентификация, 403 доступ запрещен, 404 ресурс не найдён XML - это способ организации данных в виде древовидной структуры с использованием тегов, элементов и атрибутов для хранения информации в удобном для чтения и обработки формате. XSD - язык описания структуры и ограничений для XML документов JSON - формат обмена данными, который состоит из пар "ключ:значение". Он включает в себя объекты (набор пар "ключ:значение"), массивы (упорядоченный список значений), строки, числа, логические значения (true/false) и null. JSON легко читаем для людей и удобен для машины для обмена данными. В таблицу описания параметров интеграции API включаются следующие столбцы: 1. Наименование атрибута: Название параметра или поля. 2. Тип: Тип данных, которые ожидаются (например, строка, число, булево значение и т. д.). 3. Обязательность: Указание, является ли параметр обязательным для запроса (да/нет). 4. Краткое описание: Описание параметра на простом языке, объясняющее его назначение. Таблица описания интеграции API обычно содержит следующую информацию: 1. Endpoint (точка доступа): URL, по которому можно обращаться к API. 2. Методы запросов (HTTP методы): Какие действия можно выполнить с помощью API (например, GET,POST. 3. Параметры запроса: Какие данные нужно отправить в запросе (например, ключи, значения и т. д.). 4. Параметры ответа: Какие данные будут возвращены в ответ на запрос. 5. Описание ошибок: Какие ошибки могут возникнуть при использовании API и как их обрабатывать. 6. Примеры запросов и ответов: Как выглядят типичные запросы к API и соответствующие ответы. 1. Монолитное приложение: Все компоненты приложения работают вместе как единое целое. Это простой подход, но может быть сложно масштабировать. Плюсы: 1. Простота разработки и тестирования. 2. Легче масштабировать на начальных стадиях. 3. Проще управлять целым приложением. Минусы: 1. Сложнее масштабировать с ростом проекта. 2. Одна ошибка может повлиять на всю систему. 3. Обновления требуют перезапуска всего приложения. 2. Клиент-серверная архитектура: Приложение разделено на клиентскую часть (интерфейс) и серверную часть (обработка данных). Клиенты обращаются к серверу для получения информации. 3. Многоуровневая архитектура: Приложение разделено на несколько уровней (например, уровень представления, бизнес-логики, хранилища данных), что упрощает поддержку и развитие. 4. Микросервисная архитектура: Приложение состоит из небольших автономных сервисов, каждый из которых выполняет отдельную функцию. Это позволяет легко масштабировать и обновлять части системы независимо друг от друга. Плюсы: 1. Легче масштабировать отдельные компоненты. 2. Улучшенная отказоустойчивость — один сервис падает, другие продолжают работать. 3. Большая гибкость разработки и обновлений. Минусы: 1. Усложненное управление большим количеством сервисов. 2. Дополнительные накладные расходы на коммуникацию между сервисами. 3. Требуется более сложная инфраструктура для развертывания и мониторинга. UML- Актор, линия жизни, запрос, ответ, линия взаимодействия БПМН- события, потоки, задачи, шлюзы, пул, дорожки. БД- 1. Реляционная база данных: - Использует таблицы для хранения данных. - Данные организованы в виде строк (записи) и столбцов (полей). НЕРЕЛЯЦ- всё в единой таблице
