Sequence Diagram: красивое оформление (бантики 🎀). Часть 3

Продолжаем разбираться с PlantUML. Сегодня посмотрим фишки, которые делают диаграммы ещё нагляднее:

1️⃣ Нумерация сообщений
autonumber
Чтобы не прописывать номера шагов вручную, используйте ключевое слово autonumber. Оно автоматически пронумерует все сообщения, что удобно при изменениях в диаграмме.
Пример:

@startuml
autonumber
User -> System: Запрос данных
System --> User: Ответ
@enduml

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

2️⃣ Перенос текста
Если шаг слишком длинный, используйте \n для переноса строки и улучшения читаемости.
Пример:

User -> System: Запрос на получение\nданных о пользователе

3️⃣ Примечания
Добавляйте поясняющие примечания, чтобы выделить важные детали или уточнить логику.
Пример:

@startuml
autonumber
User -> System: Запрос данных
note right of User: Какое-то примечание
System --> User: Ответ
@enduml

Попробуйте применить эти возможности в своих диаграммах на plantuml.com — они помогут сделать описание процессов ещё понятнее!

#sequence #plantuml #diagrams

Последнее время часто слышим от разных спикеров, что:

Системный аналитик — это про интеграции, БД, REST API и кафку.

❓ Что думаете? Напишите своё мнение в комментариях
👇👇👇👇👇

Суббота — самое время повторить изученное! За последние две недели мы много говорили о Sequence Diagram. Давайте освежим в памяти, как с помощью этой диаграммы можно показать взаимодействие между:

✅ Пользователь ↔️ Система
✅ Фронтенд ↔️ Бэкенд
✅ Система ↔️ Внешние API
✅ Система ↔️ Система

А ещё нет ничего удобнее, чем написать диаграмму текстом, вместо того чтобы вручную рисовать идеальные стрелки.

Мы разобрали в трёх частях полезные элементы PlantUML. Переходите к постам, копируйте код и смотрите, как он отрендерится на plantuml.com.

🔗 Sequence Diagram — полезные элементы:
📌 Часть 1
📌 Часть 2
📌 Часть 3 про бантики на диаграмме 🎀

Хороших выходных!

С вами Вера и Юрий,
Основатели AnalystCore

Что происходит после нажатия на кнопку «Войти»? 🤔

Недавно на собеседовании мы обсуждали диаграммы и процессы, и мне задали интересный вопрос:

💬 «Расскажите последовательно, что происходит после нажатия на кнопку Войти?»

❓ Цель такого вопроса — проверить, насколько глубоко кандидат понимает процессы. Мыслите ли вы только на уровне фронта? Или заглядываете в бэкенд? Понимаете ли архитектуру, безопасность, работу сессий, что там с паролями?

🔍 Разобрали бы несколько таких задач и вопросов, которые реально встречаются на интервью?
Голосуйте в опросе ниже
👇👇👇👇👇

#interview

Что происходит после нажатия на кнопку «Войти»? 🚀
Вопрос с собеседования

Разбираем процесс последовательно, чтобы понять, как кандидат погружается в детали.

🔹 1. Действия на фронтенде
* Пользователь вводит логин/пароль и нажимает «Войти».
* Фронтенд собирает данные и отправляет запрос на сервер (POST /auth/login).
* Возможна валидация данных на клиенте (например, проверка длины пароля, формата email).

🔹 2. Валидация и обработка на сервере
* Бэкенд принимает запрос и проверяет его структуру (JSON, параметры, корректность полей).
* Проходит валидация логина и пароля (например, проверка длины, запрещённые символы).
* Сервер запрашивает данные пользователя из БД.

🔹 3. Проверка учётных данных
* Бэкенд сравнивает введённый пароль с захешированным паролем в БД.
* Если пароль совпадает → успешная авторизация.
* Если нет → сервер отправляет ошибку (401 Unauthorized).

🔹 4. Генерация токенов и управление сессией
* Сервер генерирует JWT-токен / session ID для аутентифицированного пользователя.
* В некоторых случаях сервер может обновить refresh-токен, если используется OAuth.
* Информация о сессии может быть записана в кеш (Redis) или БД.

🔹 5. Ответ от сервера и обработка на фронте
* Сервер отправляет ответ с access-токеном и данными пользователя.
* Фронтенд получает токен и сохраняет его (например, в localStorage или cookies).
* Пользователь перенаправляется на главную страницу.

🔹 6. Дополнительные механики
* Если включена двухфакторная аутентификация (2FA) → сервер требует дополнительного подтверждения.
* Если несколько неудачных попыток входа → аккаунт может быть заблокирован или требуется капча.
* Если логин с нового устройства → система может запросить подтверждение через почту/SMS.

На что смотрит интервьюер?
✔️ Глубина мышления — ограничиваетесь ли только фронтом или понимаете, что происходит дальше?
✔️ Знание архитектуры — умеете ли объяснить кеширование, работу токенов?
✔️ Безопасность — знаете ли про хранение паролей, OAuth 2.0, сессии?

Вот так один простой вопрос может показать, насколько вы разбираетесь в процессе!

#interview

Задача с собеседования: продумываем доработку 🚀

Представьте, что вы системный аналитик в продуктовом онлайн-магазине с доставкой.

📌 Задача:
Есть клиенты, которые давно не делали заказ. Нужно, чтобы система отправляла им уведомление, мотивируя вернуться.

На первый взгляд — звучит просто. Но интервьюеру важно проверить, насколько глубоко вы копаете и понимаете, какие нюансы скрываются за этой задачей.

В ходе этого «расследования» вы можете выйти на то, что:
🔍 Нужен сервис уведомлений, потому что его нет.
🔍 Придётся разрабатывать админку для маркетологов, чтобы они могли настраивать сегменты клиентов и тексты сообщений.
🔍 Вопросы интеграции: с чем и как будет взаимодействовать система?

❓ Как бы вы проанализировали и спроектировали это задание на собеседовании? 🤔
Пишите свои мысли в комментариях!
👇👇👇👇👇

#interview

Вопросы с собеседований: синхронное или асинхронное взаимодействие? 🤔

На собеседованиях системным аналитикам часто дают практические задачи: определить, какое взаимодействие здесь уместно — синхронное или асинхронное?

🔹 Синхронное взаимодействие — когда один сервис ждёт ответа от другого перед выполнением следующих шагов. Если ответа нет, процесс приостанавливается.
Пример: Пользователь запрашивает баланс на сайте банка → фронтенд ждёт ответ от сервера, прежде чем показать сумму.

🔹 Асинхронное взаимодействие — когда сервис не ждёт ответа и продолжает работать. Ответ может прийти позже, когда данные будут готовы.
Пример: Пользователь сделал заказ → магазин отправляет запрос на доставку → заказ оформлен, а информация о доставке поступит отдельно.

❓Определите, какое взаимодействие можно сделать в этих случаях:

1️⃣ Мастер-система владеет справочником оргструктуры. Другие сервисы используют его данные.
➡️ Синхронное или асинхронное взаимодействие?

2️⃣ Есть курсы валют, сервису они нужны. Как их получать?
➡️ Синхронное или асинхронное?

3️⃣ Покупка/продажа акций.
➡️ Синхронное или асинхронное?

4️⃣ Купил билеты в кино → сервис отправки писем должен отправить письмо.
➡️ Синхронное или асинхронное?

5️⃣ Проверка наличия товара в магазине при оформлении заказа.
➡️ Синхронное или асинхронное?

📌 Какой вариант выбрали бы вы?
Пишите в комментариях, разберём в следующем посте!
👇👇👇👇👇

#interview

Разбираем задачу 🤔: синхронное или асинхронное взаимодействие? ЧАСТЬ 1.

1️⃣ Мастер-система владеет справочником оргструктуры. Другие сервисы используют его данные.
➡️ Асинхронное
🔹 Данные в справочнике меняются не мгновенно. Если каждый сервис будет запрашивать их синхронно перед каждым использованием, это создаст лишнюю нагрузку на мастер-систему.

Как сделать?
* Мастер-система может пушить изменения в другие сервисы через Kafka/RabbitMQ.
* Либо другие системы могут периодически обновлять справочник (например, раз в 24 часа).

Почему не синхронное?
❌ Если перед каждым действием сервису нужно ждать ответ от мастер-системы, он будет работать медленнее и может зависнуть, если мастер-система недоступна.
❌ При высокой нагрузке (например, много пользователей одновременно запрашивают данные) система может просто не выдержать.

👇👇👇👇👇

2️⃣ Есть курсы валют, сервису они нужны. Как их получать?
➡️ Асинхронное
🔹 Курсы валют не меняются каждую секунду, а значит нет смысла запрашивать их в реальном времени. Обычно обновления приходят раз в несколько минут или часов.

Как сделать?
* Обновлять курсы валют через периодический запрос (polling).
* Либо получать события о смене курса через брокер сообщений.
* Хранить курсы в кеше или в БД, чтобы сервисы не запрашивали их каждый раз.

Почему не синхронное?
❌ Если каждый сервис будет делать HTTP-запрос при каждом расчёте, это создаст избыточную нагрузку.
❌ Если API курсов недоступно, система зависнет или не сможет корректно выполнить расчёты.

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

👇👇👇👇👇

3️⃣ Покупка/продажа акций.
➡️ Синхронное
🔹 Цена акций меняется каждую секунду. Пользователь должен получить подтверждение сделки сразу, иначе цена может измениться.

Как сделать?
* При отправке запроса сервис брокера фиксирует цену и даёт мгновенный ответ.
* Запрос выполняется транзакционно — если что-то пошло не так, откатываем операцию.

Почему не асинхронное?
❌ Если отправить запрос в очередь и ждать обработки, пользователь не узнает, купил ли он акцию по желаемой цене.
❌ Если ответ приходит с задержкой, цена уже могла измениться, и сделка становится неактуальной.

📌 Когда асинхронное всё же возможно?
Если пользователь делает отложенную заявку (например, «купить акцию, если цена упадёт ниже 100$»), тогда логика может быть асинхронной.

Продолжение следует...

#interview

Разбираем задачу 🤔: синхронное или асинхронное взаимодействие? ЧАСТЬ 2.

4️⃣ Купил билеты в кино → сервис отправки писем должен отправить письмо.
➡️ Асинхронное
🔹 Покупка билетов должна быть независимой от отправки письма. Даже если письмо не отправилось, билеты всё равно должны быть куплены.

Как сделать?
* Сервис покупки ставит задачу в очередь на отправку письма.
* Сервис уведомлений обрабатывает очередь и отправляет письма в фоновом режиме.

Почему не синхронное?
❌ Если сервис отправки писем вдруг упадёт, пользователь не сможет купить билет.
❌ Если отправка письма занимает несколько секунд, это замедлит процесс покупки.

📌 Когда синхронное всё же возможно?
Если, например, перед покупкой требуется подтверждение через email/SMS (например, двухфакторная аутентификация), тогда синхронный запрос может быть оправдан.

👇👇👇👇👇

5️⃣ Проверка наличия товара в магазине при оформлении заказа.
➡️ Синхронное
🔹 Пользователь должен сразу знать, можно ли купить товар, а не ждать обновления информации.

Как сделать?
* Перед подтверждением заказа система делает запрос в складскую систему.
* Если товар есть — заказ подтверждается, если нет — выводится ошибка.

Почему не асинхронное?
❌ Если проверка будет асинхронной, пользователь сможет оформить заказ на несуществующий товар.
❌ Если складская система не отвечает, заказ повиснет в неопределённом статусе.

📌 Когда асинхронное всё же возможно?
Если магазин работает по предзаказу (например, товар можно заказать, даже если его нет в наличии), тогда можно оформить заказ, а проверку сделать позже.

👇👇👇👇👇

Вывод
Как видно, выбор синхронного или асинхронного взаимодействия зависит от:
🔹 Требований к скорости отклика — нужен мгновенный ответ или можно подождать?
🔹 Риск-факторов — если сервис недоступен, что произойдёт?
🔹 Нагрузки на систему — сколько запросов в секунду ожидается?

#interview

📣 Внимание! Сегодня стартует запись на новый поток курса «Системный аналитик.БАЗА»

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

Что вас ждёт?
⛰️ Актуальная программа и навыки на 2025 год, которые нужны работодателям
⛰️ 8 заданий, проверяемых экспертом. На выходе документация для вашего портфолио
⛰️ Через 4 месяца сможете начать искать работу и проходить собеседования
⛰️ Помощь с трудоустройством: проверим ваше резюме и проведём тестовый собес 💪

Как проходит обучение?
1️⃣ Получаете доступ и начинаете смотреть видеоуроки
2️⃣ Будете заниматься сами, но не в одиночестве. Вас добавляют в чат потока с поддержкой от авторов курса
4️⃣ Получаете сертификат
5️⃣ Готовитесь к трудоустройству
6️⃣ Ищете работу с поддержкой экспертов

Поток стартует 14 марта, а количество мест очень ограничено — не упустите свой шанс стать уверенными системными аналитиками как можно скорее.

За подробностями 👉 analystcore.com

Успейте занять место!

Задача с собеседования: спроектируйте взаимодействие 🔍

📌 Условие:
У нас есть 1 сервис, который публикует данные, и 4 других сервиса, которые эти данные читают. Нужно спроектировать взаимодействие между ними.

Как организовать взаимодействие, чтобы система была надёжной и масштабируемой?
Возможные решения:

1️⃣ Синхронный вариант
Как работает:
Читающие сервисы сами запрашивают данные у основного сервиса (API, БД).
Данные обновляются по запросу, когда потребителю это нужно.

Плюсы/минусы:
✅ Простая реализация через REST API или GraphQL.
✅ Каждый сервис сам решает, когда обновлять данные.
❌ Четыре сервиса нагружают основной сервис запросами.
❌ Если один сервис запрашивает данные раз в час, а другой — раз в секунду, их версии могут отличаться.

Когда подходит?
✔️ Если данные меняются редко и можно получать их по требованию.

2️⃣ Асинхронный вариант
Как работает:
Основной сервис отправляет данные сам через брокер сообщений (Kafka, RabbitMQ).
Читающие сервисы подписаны на события и получают данные, как только они появляются.

Плюсы/минусы:
✅ Основной сервис не перегружается — данные не запрашиваются лишний раз.
✅ Все подписчики получают обновления в реальном времени.
✅ Если один из сервисов временно недоступен, он получит данные позже.
❌ Требует настройку брокера сообщений и подписок.
❌ Нужно контролировать, обработал ли сервис сообщение или потерял.

Когда подходит?
✔️ Если данные обновляются часто, и важно передавать их мгновенно.
✔️ Если подписчиков много, и мы не хотим перегружать основной сервис.

Вывод:
* Если данные меняются редко, можно обойтись синхронными запросами.
* Если нужны мгновенные обновления, лучше использовать асинхронную публикацию через брокер сообщений.

#interview

Объявляем рубрику страхов! 🙀

Опытные аналитики, делитесь в комментариях, чего вы боялись или боитесь на работе? Особенно много страхов у специалистов с опытом от 1 до 3 лет.
Мы будем делиться страхами коллег, своими собственными из прошлого и историями наших учеников.

😱 Страх 1. Я боюсь читать мессенджер — вдруг там вопрос, на который я не смогу ответить.
А если ваш наставник ушёл в отпуск или старший коллега по цеху недоступен — вообще кошмар.

Правда в том, что системным аналитикам пишут постоянно. Это члены команды, заказчики, коллеги из других отделов. Смежники часто задают вопросы:
❓ А если мы добавим новое поле в API, у вас ничего не сломается?
❓ Вы используете наш метод? Мы его хотим выпилить.
❓ На что влияет ваш справочник? Как другие системы его используют?
❓ Вы в коде готовы к такой-то ошибке от нас? Мы её немного изменили, надеемся, вас не задело.
❓ Если мы пришлём вам в этом параметре N/A, что будет?

Вначале реакция стандартная, и её не нужно стыдиться:
😱 Откуда я знаю? Я на этом проекте всего полгода!
😱 Откуда мне знать, что в коде у разработчиков?
😱 Опять придётся лезть в код, а я там ничего не понимаю…
😱 О нет… Придётся отвлекать разработчиков. Как бы перебороть это чувство и всё-таки написать?..
😱 Но я же не отвечаю за то, как наши справочники используют другие системы. Я правда должен это знать?

Любая из этих реакций — нормальная. Вы не одиноки!

Главное — не позволяйте этому подорвать вашу уверенность:
1️⃣ Вы не обязаны отвечать сразу. Этот вопрос вообще-то отвлёк вас от рабочих задач. Выделяйте отдельное время в день на такие вопросы.
2️⃣ Не бойтесь сказать, что вам нужно время на поиск ответа. Вы не можете знать всё. И ответ не ожидают только от вас. Вы — это входная точка в команду. Подключайте коллег.
3️⃣ Да, вам снова придётся идти к разработчикам. Это нормально. У вас Confluence, у них код. Вы отвечаете за разные вещи.
4️⃣ С каждым таким вопросом вы лучше узнаёте систему. Через несколько месяцев сможете отвечать сразу, без доп. исследований.

ЭТОТ СТРАХ МОЖНО СНИЗИТЬ 👇
Первый шаг — вести документацию 📄. Если там будет описано всё важное, походы по отделам сократятся в разы.

📌 На курсе «Системный аналитик. БАЗА» результат — написанная документация.
Вы сможете задавать вопросы по вашему проекту, а мы поможем и подскажем, как лучше организовать доку в вашем случае.

✨ Старт потока — 14 марта.
Успевайте записаться!

#страхинаработе

Наш курс — про БАЗУ, которая нужна джунам, мидлам и даже сеньорам! 🚀

К нам приходят как новички в IT, так и те, кто уже работает 1—3 года системным аналитиком.
Сложно качественно и уверенно выполнять свою работу, когда не владеешь базой. Но хорошая новость — это быстро исправляется!

🔹 У нас индивидуальный подход к каждому, и для каждого отличается уровень сложности.
🔹 Прокачиваем то, что нужно ученику здесь и сейчас.
Задания варьируются и адаптируются под уровень знаний каждого!
🔹 Такой подход возможен только на небольших потоках.

С какими запросами приходят наши ученики?
💼 «Хочу сменить работу» — но не хватает знаний для работы в другой компании, был ограниченный круг задач, а на рынке требуют большего.
📊 «Дали задачу по проектированию БД» — но я никогда этого не делал.
📄 «Поручили составить документацию» — а как её начать делать и как оформлять, непонятно.
🎓 «На проекте я единственный системный аналитик» — и не у кого спросить best practice.

Если вы узнали себя — мы готовы помочь.
Мы работаем лично с каждым и доводим до результата. Приходите на поток курса Системный аналитик.БАЗА. Успевайте!

😱 Страх 2. Мне дали задачу, которую я никогда не делал(а). ЧТО ДЕЛАТЬ??

Первое — успокоиться. Важно понять, что вы не одиноки, и никто не хочет, чтобы вы завалили задачу.

Скажите своему продакту или тимлиду, что у вас есть трудности.
Они отвечают за результат команды и сроки, поэтому заинтересованы в том, чтобы задача была выполнена. Им самим не нужны простои, так что они сделают всё, чтобы помочь вам:
🔹 Подскажут, куда копать.
🔹 Найдут нужного человека.
🔹 Дадут документацию или помогут разобраться сами.

Так что не стесняйтесь задавать вопросы и просить помощи.

Что делать, если задача незнакомая?
1️⃣ Не бойтесь сказать, что вам нужна доп. информация. Никто не ожидает, что вы экстрасенс и сразу всё знаете.
2️⃣ Разбейте задачу на части. Разделите её на понятные шаги и начните с тех, в которых уверены.
3️⃣ Подключите коллег. Если есть наставник, тимлид или опытный аналитик — спросите, как он бы подошёл к этой задаче.
4️⃣ Используйте документацию и наработки. Возможно, похожая задача уже решалась. Посмотрите Confluence, Jira, старые ТЗ, переписки в чатах.
5️⃣ Запрашивайте ревью. Прежде чем двигаться дальше, уточните, правильно ли вы поняли суть задачи.

💡 Помните, если вам дали незнакомую задачу — значит, вам доверяют! Это возможность прокачаться и научиться новому. Главное — не бояться спрашивать, искать информацию и делать шаги вперёд. 🚀

❓Были ли у вас такие ситуации? Как справлялись?
Делитесь в комментариях! 👇

#страхинаработе

Всем привет! 👋
С вами Вера, основатель AnalystCore.

Сегодня я просто хочу поделиться фразой, которой руководствуюсь в работе:

Лицо системного аналитика — это его документация, продукт его работы

- Программное обеспечение — это продукт, результат работы команды.
- Оборудование — это физический продукт, результат работы инженеров и разработчиков.
- Документация — это продукт работы системного аналитика.

Если мы будем относиться к документации как к продукту, она будет на высоте.

Немного рекомендаций по ведению документации:

1️⃣ Убирайте дублирование. Если одно и то же описание повторяется в нескольких местах, его легко забыть обновить везде и документация «разъедется».
2️⃣ Делайте перекрёстные ссылки. Документация должна читаться, как Википедия, где вы переходите по ссылкам.
3️⃣ Описывайте ровно столько, сколько нужно вашей команде и вашему проекту. Ни больше, ни меньше.
4️⃣ Не рисуйте схему ради схемы. Визуализация должна помогать, а не усложнять.
5️⃣ У документации, как и у любого продукта, есть свои пользователи — менеджеры, разработчики, тестировщики, смежники. Спросите их, что они хотят найти в документации.

Так документация будет приносить пользу, а её актуальность будет проще поддерживать.

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

За 8+ лет опыта я была на 15+ проектах и видела разную документацию — хорошую, плохую, очень плохую. За это время я сформировала best practices, которые делают документацию понятной, красивой, читаемой и такой, за которую не стыдно.

Хочу закончить пост своей любимой мыслью:

Давайте работать так, чтобы было не стыдно.
Не стыдно за свою работу. Не стыдно за свою документацию. 💪

#sa_dev

Привет!
С вами Вера и Юрий, основатели AnalystCore.

Мы активно дорабатываем наш сайт и платформу. 🙂 На выходных зарелизили изменения:
- Начали вести главную страницу.
- Выкатили новый раздел «База знаний». Там будут статьи по животрепещущим вопросам системных аналитиков.
- Доработали архитектуру, поправили баги.

Сегодня просто хочется сказать спасибо, что вы с нами ❤️. Нам очень приятно, когда вы пишете в ЛС и что-то спрашиваете. Когда вы ставите реакции и пишете комментарии, мы понимаем, что всё это не зря и мы делаем действительно важное дело.

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

🔥 Единственная мотивация двигаться вперёд — это отклик аудитории. Поддерживайте нас огонёчками, и мы будем становиться только лучше!

❌ Внимание! Набор на поток 14 марта закрыт

Места на курс «Системный аналитик. БАЗА» закончились!

Мы не гонимся за количеством, а работаем на результат. Поэтому набираем ограниченное число учеников, чтобы лично работать с каждым и доводить до цели.

✨ Этот поток собрал большой ажиотаж, и все места уже заняты.
Тем, кто долго сомневался — в следующий раз действуйте быстрее! 😉

Что делать, если не успели?
1️⃣ Ждите анонсов новых потоков.
2️⃣ Доступен тариф «Только послушать» 🎧 — можно изучать материалы уже сейчас, а затем перейти на тариф с практикой, чатом, доп. темами в новом потоке.

Спасибо за доверие! Будем рады видеть вас в следующих запусках. 💙

Задача с собеседования: разрабатываем Use Cases для лифта 🚀

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

📌 Основной сценарий:

Пользователь заходит в лифт, выбирает этаж и едет.

Но реальность сложнее! Какие есть альтернативные сценарии и расширения?
Продумываем все возможные кейсы, включая неожиданные ситуации:

🔹 Что если лифт перегружен?
🔹 Что если не работает кнопка вызова?
🔹 А если пассажир передумал и хочет сменить этаж?
🔹 Как быть, если лифт застрял?
🔹 А что если лифт движется без пассажиров?
🔹 Не забываем про необычные Use Case — например, посмотреться в зеркало!

❓ Как бы вы ответили на собеседовании?
Выберите все варианты, которые можно оформить в отдельный Use Case, альтернативный сценарий или расширение.

👇👇👇👇👇

В следующем посте разберём ответы.

#interview