🤖 UML-диаграмма для интеграционного Use Case за 3 минуты: ChatGPT + PlantUML 🤖


🔗 Статья с инструкцией - пошаговый гайд с картинками и примерами


Если вы знаете инструмент, в котором можно описать диаграмму через код, то на помощь в её разработке приходит Искусственный Интеллект.

ChatGPT / DeepSeek - Искусственный Интеллект
PlantUML - Инструмент для создания любых UML-диаграмм через код


Инструкция по созданию UML Sequence:

1️⃣ Открой ChatGPT / DepSeek и войди аккаунт
Вход в аккаунт нужен, чтобы использовать улучшенную модель ИИ.

2️⃣ Выполни команду

Работай как опытный системный аналитик.
Сделай код для plantUML, чтобы создать UML Sequence диаграмму.
Не показывай альтернативные сценарии.

Сценарий:
<название сценария>

Пользователи и системы:
<участники сценария>

Описание сценария:
<описание Use Case>

Заполни название сценария и список участников (пользователи, фронтенды, бэкенды, внешние системы, БД).

Скопируй и вставь на место <описание Use Case> детализированный Use Case с описанием сценария интеграции.
Пример Use Case.

Отправь запрос к ChatGPT.

3️⃣ ChatGPT вернет в ответ код диаграммы для PlantUML

4️⃣ Вставь полученный код в PlantUML

5️⃣ Обязательно проверь и скорректируй результат:
5.1. Вручную поправь код по аналогии - это быстрее
5.2. Проси уточнения кода у ChatGPT дополнительными запросами


➕ Плюсы:
1. Диаграмма за 3+15 минут, с учетом проверки результатов.
2. Не надо писать код самому
3. Легко делать правки, т.к. диаграмма через код, и при любых правках всё двигается автоматически

➖ Минусы:
1. Use Case должен быть описан идеально. Без него диаграмму не сделать, либо будет много правок в придуманном ИИ варианте
2. ChatGPT / DeepSeek делает ошибки и за ними надо вносить правки
3. Лучше работает DeepSeek. Но и ChatGPT можно натренировать


🔗 Статья с инструкцией


❗️ Рекомендую использовать этот лайфхак только при знании и понимании нотации.
Для тех, кто только изучает UML, рекомендую использовать ИИ для проверок, но помните - он ошибается.


#ИнтеграцииGA

🏆 Маппинг данных - что это и зачем? 🏆

Маппинг - это процесс сопоставления полей (данных) из одной системы с соответствующими полями в другой системе.
Это нужно, так как разные системы могут описывать один и тот же объект данных по-разному.

Этот процесс всегда необходим в задачах на интеграции.

Маппинг описывают в виде таблицы.
Допустимо делать и в виде структурированного списка, но по опыту - таблицы удобнее.


➡️ В таблице с маппингом делают несколько основных колонок:

- название параметра на разговорном языке;
- описание, требования к валидации, ФЛК (форматно-логический контроль) и преобразованиям, если это необходимо;
- названия параметра в API каждой системы (например, поле из JSON, поле из xml или другого формата сообщения, query из URL и др);
- название параметра в БД системы, если она есть в описании Use Case.
- типы данных в каждой системе / БД.

Допустима вариативность с колонками.
Их может быть больше, а может быть и меньше.


Если говорить про задачу на интеграцию системы #BookingGA с Unisender для подписки пользователей на рассылку, то 👉 таблица маппинга под часть задачи "чтение сообщения из топика Kаfka и добавление пользователя в лист контактов Unisender" 👉 будет содержать колонки:

- название поля на русском
- название поля в сообщении Kafka (JSON)
- название поля в БД Сервиса Уведомлений BookingGA, т.к. туда будет сохранена информация о подписке пользователя на город
- название параметра в API системы Unisender, куда будем отправлять данные о новом пользователе для листа контактов
- общее описание поля, требования к его обработке и проверкам
- типы данных в сообщении Kafka (JSON), API Unisender и БД. Я бы добавила только отдельную колонку “Тип данных в БД Уведомлений”. Все остальные типы данных не так важны или очевидны.


Маппинг помогает разработчикам понять, какие данные нужно получать из внешней системы, с которой интеграция, что важно сохранить в БД или сопоставить с ней, а что нужно просто показать пользователю и не надо держать в памяти программы 🙌

#ИнтеграцииGA

💎 Заполненный шаблон реального интеграционного Use Case 💎

Готов итоговый файл Confluence с примером интеграционного Use Case:
👉 Авторассылка email по расписанию через интеграцию с Unisender

Внутри:
✅ микросервисная архитектура
✅ есть брокер Kafka
✅ задача запускается по cron (автоматически, по расписанию).

Всё на уровне системы, без участия пользователей.
Максимально подробный и детальный пример.


👉 Шаги для его создания:

1️⃣ Анализ API-документации внешней системы Unisender.

2️⃣ Тестирование API через Postman (можно другой инструмент),
чтобы понять, как API Unisender реально работает и его "подводные камни".

3️⃣* Обсудили алгоритмы авторизации запросов во внешние системы.
В случае Unisender можно отправить все настройки подключения в конфигурационный файл, а API-ключ туда же или в Key Store (хранилище ключей).

4️⃣ Встроили новую функциональность в архитектуру проекта
и показали это на схеме архитектуры C4/Container:
+ какие сервисы / микросервисы задействованы (если это не монолит)
+ какие БД используются
+ нужны ли брокеры в процессе
+ и другие детали

5️⃣ Знаем, что нужны задачи на доработку БД в МС Уведомлений,
чтобы хранить информацию о:
+ соответствии городов и их list_id в Unisender
+ какие пользователи (email) и на какие города подписаны для рассылки

6️⃣ Описали интеграционный Use Case (вер1),
используя полученный опыт работы с API, понимание архитектуры: зафиксировали, как будут перетекать данные между микросервисами системы.

7️⃣ Дополнили его UML Sequence диаграммой
и узнали, как её строить (в статье оставила ссылку на специальный AI-бот от GetAnalyst по генерации идеального кода PlantUML 😎).

8️⃣ Узнали что такое маппинг данных.
Добавила несколько таблиц маппинга в статью.

9️⃣ Зафиналила список задач на разработку.
В идеале ещё доделать предложенный список вложенных статей, но уже в этом виде разработчики могут начинать работу над задачей и остатки важной документации формировать сами!


Полезный образец для развития насмотренности и получения опыта 💎

#ИнтеграцииGA #BookingGA

📌 Подборка полезных материалов по Интеграциям от GetAnalyst 📚


Послушать и посмотреть:

🎧 Postman: навык тестирования REST API за вечер

🎧 Опасные интеграции - про альтернативные сценарии и обработку типовых ошибок

🎧 Подкаст "Проблемы в работе с задачами на интеграции"

🎧 Доставить и не потерять: синхронизация данных в распределенных системах - основы очередей сообщений

🎧 Подкаст "Идемпотентность и коммутативность API: что это и как применяют на практике"

🎧 Подкаст "Kafka: что нужно знать Системному аналитику" - глубже в понимание очередей и брокером


Познакомиться с теорией:

📝 Как аналитику работать с задачами на интеграции — пошаговая инструкция
В этой статье вы найдете пошаговую инструкцию, которая станет помощником при проектировании интеграций для любых систем.

📝 Отличия между обычными и интеграционными Use Case

📝 Инструменты системного аналитика для тестирования в API

📝 Работа Kafka - что надо знать для работы СА



Практические руководства по Postman:

📚 Практическое руководство по Postman - тестирование API DaData (с нуля до результатов)

📚 Практическое руководство по Postman - тестирование API ChatGPT

📚 Практическое руководство по Postman - тестирование API Unisender


Шаблоны постановок задач:

💎 Полный интеграционный Use Case - рассылка email через Unisender (с брокерами и микросервисами)

💎 Полный интеграционный Use Case - автоматическое создание задач во внутренней системе ToDoist для сотрудников компании после оплаты заказов

💎 Интеграционный REST API-метод - поиск структурированных адресов



Ещё больше про интеграции:

🎓 Практический курс Интеграции Систем - работа онлайн с Екатериной Ананьевой и экспертами программы

🎓 Материалы для самообучения по Интеграциям (пакеты вебинаров)

Всё по интеграциям от GetAnalyst вы всегда можете найти в канале по хэштегу #ИнтеграцииGA 🙌


Прекрасных выходных!

Бывают моменты, когда теряешь ориентиры в карьере.

Не понимаешь, куда расти, в каком направлении двигаться. Вроде всё умеешь — но хочется большего, хочется развиваться и в навыках, и в деньгах. Но как и куда?

⭐️ В такие моменты помогает одна простая, но мощная практика — написать "резюме мечты".

Не текущее.
А такое, где ты — тот, кем хочешь стать.

Почти как в детстве про "я хочу стать космонавтом", но уже с позиции взрослого человека 🙃


Садишься и честно придумываешь себе будущий опыт работы (наконец-то можно!) 😊

✅ Навыки:
+ проектирование архитектуры
+ нотация С4
+ проектирование REST API
+ интеграции
+ микросервисы
+ Kafka
+ RabbitMQ
+ Postman на продвинутом уровне
+ ...

✅ Опыт работы:
+ Убрал хаос в компании по работе с REST API и ввёл корпоративные стандарты проектирования
+ Работал с высоконагруженной системой и проектировал внутренний обмен данными
+ Продумывал сложные цепочки интеграций микросервисов с участием брокеров, gRPC, REST API
+ Проектировал архитектуру для переезда с монолита на микросервисы
+ Управлял командой из 12 аналитиков распределенных по командам продукта
+ Работал в Германии на позиции ведущего системного аналитика более 3-х лет
+ ...

✅ ЗП:
от 100 000 $ /год


Пишем всё, что когда-то и где-то слышали от более опытных коллег. Мечтаем. Ищем вдохновение в статьях на хабре, в цифрах ЗП в вакансиях на LinkedIn. Для вдохновения еще полезно посещать митапы, конференции и обучения))


Это может показаться странным. Как будто ты приписываешь себе несуществующий опыт. Кто-то это ради "лишь бы взяли" делает 😅
Но у вас другая история. Вы к этому опыту планируете прийти.

Магия в том, что такой практикой ты даёшь себе чёткий вектор: куда я хочу расти 📈🔮

Появляется фокус. А вместе с ним — план.
После этой практики ты даже неосознанно начинаешь движение к цели 🙌 (а если опубликовать, так вообще можно случайно "сесть на ракету" и ускориться...😅)


У меня вообще всё, что записано на бумаге, обычно через время сбывается. Такой вот ритуал исполнения желаний 🪄

Попробуйте 😉
Это работает!

🤖 Как эффективно использовать ChatGPT для проектирования БД и SQL-запросов | 17 Апреля, 19:00 Мск 🤖

Использование ChatGPT и аналогичных нейросетей для работы аналитика всё еще может вызывать вопросы. Где-то это помогает, а где-то наоборот - отнимает время 📉

Кроме того, есть проблема: нейросети не всегда правы. И если неопытный аналитик пытается использовать их бездумно, ошибки гарантированы.

Но в то же время, если вы используете нейросеть:
✔️ Умея решать задачи самостоятельно
✔️ Зная алгоритмы работы и последовательности команд
✔️ Используя правильные связки инструментов
то она может стать вашим помощником! 🤝


👉 Если вы умеете проектировать БД на логическом уровне, ищите возможность развиваться в темах БД и SQL, и хотите ускорять свою работу с использованием нейросетей, то приглашаю вас на онлайн-практику:

🤖 Использование ChatGPT для проектирования БД
🗓 17 апреля, чт
🕘 19:00 - 21:30 МСК
👉 Подробности и запись

План:
1. Знакомство с ChatGPT (и не только)
2. Проектирование физической модели БД PostgreSQL
3. Автоматическая отрисовка ER-модели с использованием ChatGPT и дополнительных инструментов
4. Создание реальной БД и SQL-запросы в DBeaver

✅ Запись будет доступна после занятия.
✅ Для всех участников сейчас доступно занятие в записи по SQL-запросам с практикой в реальной БД 😎


По вопросам можно писать через сайт или @getanalyst 💬

💻 Когда Системный Аналитик работает с REST API 💻

Глядя в вакансиях Системных Аналитиков на ключевые слова "REST API", полезно понимать, что может за этим скрываться.

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


👉 1. При создании новой функциональности
У вас в команде Frontend + Backend разрабатываются отдельно - разные кодовые базы.
Frontend / Мобильные приложения взаимодействуют с Backend по REST API.

Когда в системе нужно добавить новую функциональность, то от аналитика ожидают, что он может:

+ со стороны Backend - проектировать REST API:
▫️ Определить REST API методы, которые нужно разработать для работы Frontend.
▫️ Описать алгоритмы их работы, которые будут программировать разработчики.
▫️ Продумать требования к обработке ошибок.
▫️ Сделать ролевую модель доступов к REST API методам.
▫️ Спроектировать структуру API-методов:
+ на естественном языке описать входные параметры запроса и параметры ответа на запрос.
+ продумывать техническую реализацию и описывать сразу тип метода (GET, POST, ...), endpoint (URL), query-параметры, headers запроса и ответа, тело JSON запроса и ответа, статус-код ответа.
▫️ Описывать маппинги (сопоставление) данных между БД и параметрами API-методов (в URL, JSON).
▫️ Формировать техническую API-документацию, которую в дальнейшем будут использовать разработчики: в Postman, Confluence или Swagger (OpenAPI).

+ со стороны Frontend - подключение разработанного на Backend REST API метода:
▫️ Читать техническую REST API-документацию.
▫️ Проверять работу готовых REST API методов через Postman, чтобы убедиться, что все работает так, как описано в документации.
▫️ Описывать маппинги (сопоставление) данных между UI и параметрами API-методов (в URL, JSON).


👉 2. Интеграции внешние - подключение сторонних систем по REST API
Состав подзадач аналогичен подключению API на Frontend.
Отличия:
1. Работа ведется не с внутренней API-документацией, а с чужой - на внешние системы.
2. Интеграции - это обычно про взаимодействие Backend-ов. Алгоритм работы может включать одновременно несколько компонентов: наш Frontend, наш Backend (+БД), внешний Backend.
3. Всвязи с этим больше таблиц маппингов данных в постановках задач:
✔️ Маппинг 1: UI + наш REST API,
✔️ Маппинг 2: наш REST API + внешний REST API + наша БД.


👉2.1. Интеграции - создание интеграционных REST API-методов (дополнительно к п. 2)
Нужно сделать REST API-метод на Backend, который будет вызывать любой API внешней системы (хоть REST, хоть SOAP, хоть GraphQL).
Состав подзадач аналогичен проектированию API-методов на Backend.

Маппиг данных теперь будет не только для БД и параметрами нашего API-метода (в URL, JSON). К нему добавятся еще и параметры внешней системы, которые могут быть в любом формате в зависимости от вида API.


👉 3. Интеграции внутренние - обмен данными между сервисами и микросервисами по REST API
Состав подзадач аналогичен подключению API на Frontend, но больше компонентов в описании алгоритмов и таблиц маппингов.


👉 4. Для анализа ошибок работы ПО
Что-то пошло не так при работе Frontend (или мобильного приложения)?
Открываем консоль.
Анализируем запросы и ответы REST API методов.
Тестируем сложные ситуации через Postman, смотрим на результаты и ищем причины ошибок.



Рекомендация:
Для Системного аналитика важно понимать REST API не только с точки зрения возможностей, но и с точки зрения ограничений, типовых проблем и ошибок в проектировании.
Чем лучше вы их понимаете, тем качественнее будет работать ПО разработанное по вашим требованиям.


#RestApiGA