0: Я заколебался выставлять стрелочки. Артефакт, который нужно сделать красиво по госту. Там все куда проще. Любая диаграмма это скетч. Привет, меня зовут Миронов Никита. Я пробрался на эту студию, в которой снимают только
1: Про бипин, чтобы рассказать вам про юмл. Люди аналитики, товарищи, вам не надо уже ничего учить. Никакие сиквенсы, никакие BPM очень скоро ваши работодатели узнают, что такое клод. 10 апреля приглашаю на конференцию, которая называется BPM плюс.
2: А как экономить миллионы рублей и повышать эффективность бизнес процессов с помощью i приходите, будем рады очень вас видеть много раз. Я слышал, что мой BPM отстой, но я не понимал, почему и сегодня я хочу вместе с вами разобраться, отстой он или нет, и рассказать вам про удивительный.
3: Мир сиквенс, диаграмм. Как их готовить? С чем, зачем и почему, почему меня надо слушать? Ну я вот 6 или 7 лет уже занимаюсь аналитикой. Я начинал там с бизнес анализа, потом был системным аналитиком, сейчас вообще копаюсь в системах на уровне чуть ли не девопса.
4: И мне интересно, но работаю до сих пор аналитиком. Поговорим про сиквенсы, про язык общения, аналитика с командой. Ну и не только рассмотрим сценарий использования для бизнес аналитиков, для системных аналитиков. Вот будем идти потихонечку, значит,
5: Чуть чуть про себя. Вот лицо на кадре лицо здесь, в принципе, все. Вы это уже знаете. Люблю задачки от идеи до реализации. Именно поэтому для меня там сиквенс это не супер документация, не такой прямо артефакт, который нужно сделать красиво по гостам. Нет, нет, это
6: Скетч на самом деле, и об этом мы сегодня и поговорим. Существует проблема. Никто не любит читать большие тексты. Вот большая часть людей визуалы, и, как и в BPM, большая часть пользователей использует
7: Программки как способ визуализации, фактически как способ заставить разработчика посмотреть на твою красивую картинку, потому что все же любят картинки. Значит, если можем ли мы не рисовать сиквенсы и вообще, что это такое можем? Тут надо дать краткую историческую
8: Ставку, которой нет в презентации про юмл. Мы не будем сейчас рассказывать о теории. И кто придумал, зачем, почему 2 версии, какие там более 15 типов диаграмм есть. Мы расскажем о самой понятной оо той, которая выжила текст.
9: Есть шанс, что люди просто не прочитают, вы можете писать текстом, как и vpn, как и юмл. Легко, пожалуйста, хоть голосовыми, вот. Но есть шанс, что никто не прочитает. Есть способ лучше рисовать, значит, под сиквенс диаграммой понимают какой-то скетч взаимодействия. Это
10: Не стандарт, это не чертёж, это не техническое задание. Ни в коем случае. Это картинка, у которой всего 1 смысл сказать, че происходит? Какая-то последовательность. Ты мне, я тебе, я подумал, я сказал, нет, я сказал, да, все достаточно просто. Обычно сиквенс.
11: Программа используется не для общения между участниками какими-то там, не между менеджером заказчиком, нет, для этого есть более удобные инструменты, потому что такое общение обычно требует ветвления каких-то дополнительных правил, с этим отлично справляется.
12: Тот самый BPM, когда мы говорим про программный код, там все куда проще. То есть программный код. По большому счёту, это строгая последовательность логики, иногда с лёгким ветвлением. Что будет, если то, если это если здесь
13: Вот для этого нужен сиквенс. Зачем это системному аналитику? Вообще сиквенс? Диаграмма понимается любым разработчиком, абсолютно любым не найдётся разработчика, который её не поймёт. При этом там BPM диаграмма аналитического уровня может быть разработчику непонятна просто потому, что он не владеет
14: Тем языком общения. Значит, обычно её читают 4 Роли. Это тестировщик, разработчик, архитектор и техлид. У каждой Роли есть свои потребности в этой сиккенс диаграммки, но в целом это просто универсальный механизм общения. Можно показать картинку.
15: Когда вместо того, чтобы долго объяснять всем что-то текстом, зачем она бизнес аналитику, она нужна для того, чтобы не использовать другие нотации там, где они не нужны, не рисуйте, пожалуйста vpn взаимодействие систем http вызов.
16: И другие очень технические штуки воспринимайте система в BPM как чёрный ящик. Мне кажется, это справедливо и очень удобно, когда вам нужно раскрыть этот чёрный ящик. Типа, а что там вот происходит? Вам как бизнес аналитику иногда нужно все-таки нарисовать какой-нибудь сиквенс. Почём?
17: Потому что ваша аудитория это технические специалисты. Вам нужно с ними договориться, какие данные будут ходить, как часто они будут обновляться. Самый простой пример, который я могу привести, это согласование какой-нибудь выгрузки. Ни для кого не секрет, что есть такие сценарии, когда там данные нужны.
18: Ежесекундно, буквально, когда можно подождать час до обновления данных, когда данные обновляются по ночам большой выгрузкой такой. И вот здесь, вот в этих вот способах и механизмах обновления, хорош будет sequence в описании логики, что нужно
19: Сделать над этими данными, там, когда их запросить, когда посмотреть новые можно использовать BPM. То есть это не конкуренция, это дополнение. Просто теперь немножко про участников существует 4 на самом деле самых распространённых участников.
20: Программы это некоторый актёр actor с английского. Клиент, кстати, должен сказать, если вы хотите подробнее углубиться, в это все есть замечательный учебник фаулера. Называется он введение в юмл. Насколько я помню, можно с ним
21: Ознакомиться. Он есть на просторах интернета, там буквально 5 страничек и очень дельные примеры. Некоторые цитаты из этого учебника мы будем сегодня приводить. Но для тех, кто хочет глубинно посмотреть на это все и почитать про историю емль рекомендую, значит, на
22: Есть клиент у нас есть это какой-то эктор. Обычно эктором может быть не только клиент. Это любой пользователь, администратор, модератор. В общем, любой человек есть participants, участник, фактически действия и есть несколько значков для
23: Самых используемых прикладных сервисов это data base для хранилища и очередь не буду пытаться даже выговорить это слово вот это kafka будем вот там написано кафка будет Кавка, значит про стрелки тоже сразу быстро расскажу всего.
24: Предлагаю вам сказать, что в сиквенсе 3 типа стрелки. Пусть вы меня закидаете палками. Сплошная пунктирная и самовызов все остальное не лучше, не надо. Там есть ещё асинхронные потоки, можно, можно изгаляться, можно, но не нужно.
25: Я последний раз видел асинхронную стрелку для показания асинхронного взаимодействия, ну, примерно в этом учебнике и 1 раз на диаграмме другого человека, который вышел из вуза и просто решил, что так нужно. Вот я вам предлагаю выбрать 3 стрелки. Сплошная пунктир.
26: И, собственно говоря, самовызов для того, чтобы вот, вот весь инструментарий, который нам нужен, что за стрелки, сплошная, это вызов от инициатора какому-то получателю. Пунктир это ответ от получателя инициатору с
27: Каким-то там кодом ответа данными. Неважно. Ну и самовызов это когда вам нужно показать, что я подумаю, там, типа, на данном примере, там сирм спрашивает, сирм. Валидация данных напомнила, повар спрашивает повара, вот пример.
28: Об этом. Дальше есть ещё кусочки фрагментов, которые можно использовать в диаграмме. Это блоки альтернативных сценариев, это обычный ифелс на самом деле, да нет, какие-то позитивные результаты, негативные результаты, любая бизнес логика, которая требует какого-то
29: Есть опциональная штука. Вот это супер вещь. Это когда вам нужно, например, опционально проверить 2 фактор. Очень удобно выделять это в опциональный блок и не тормозить основной сценарий. Повторение луп это любые сценарии опроса, каждые 5
30: Секунд или для каждого элемента нужно запросить данные. Вот это про это, реф, это ссылка на другую схему. Вот эта удивительная часть. Рефом можно прятать огромные куски. Мы дальше об этом посмотрим. Очень полезный инструмент. Прямо рекомендую
31: Ну, пример. Тут же у вас есть типовой процесс оплаты, а у вас задача, чтобы в конце процесса оплаты нужно оценку поставить оплате там от 1 до 5 удовлетворённость. И вот как показать, что это должно быть после процесс
32: Оплаты реф, процесс оплаты и дальше вызов нужной вам последовательности. Очень удобно. Ещё есть супер инструмент, который называется комментарии, комментарии это заметки на Полях. Для того, кто будет читать. Иногда туда можно погрузить бизнес логику.
33: Иногда можно погрузить какие-то особенности выбора, иногда можно погрузить особенности сообщений, все это нужно нам только для того, чтобы читателю было удобнее, ну, выдать читателю больше контекста про эту схему, значит, есть примерно 1 инструмент, который стал стандартом.
34: В отрасли и очень сильно рекомендую всем рисовать. Именно так. Речь идёт про план эмэль. Это генерация диаграммы из кода. Значит, расскажу собственный пример. На 1 работе я делал сиквенсы.
35: По оплате на сайте через платёжный шлюз, и я честно рисовал их в чудесном сервисе, который сейчас называется app diagrams точка нет, а в простонародье известен как дрое я заколебался.
36: Вставлять стрелочки. Это было просто ужасно. Дело в том, что вы никогда не знаете аналитики, которые начинают свою деятельность, обычно раскапывают поток взаимодействия во время исследования, да.
37: И им часто нужно эту схему менять в друю. Это очень больно. Вот я вам не рекомендую, рекомендую почувствовать себя программистами и писать диаграмму в виде кода у плант юмл достаточно простой синтаксис, который может освоить каждый, а также
38: Он есть в чудесном сервисе, который называется storm бипин. Давайте посмотрим, это диаграмма, которую мы будем смотреть дальше. Но суть такая, что вы слева пишите, значит, ваш эмэль план юэль код, назовём его. Так он находится в рамочках.
39: Start юль указываете участников эктор participants клиент личный кабинет сервис. Указываете там базу данных. Можно им проставлять последовательность отображения. Менять достаточно удобно и вот такими нехитрыми.
40: Вызовами там клиент вызывает лк, нажимает вернуть товар, мы описываем диаграмму в чем как бы plus plus Ровно в том, что если мне нужно взять и убрать вот этот вот блок, я его убираю и моя диаграмма.
41: Переделывается на лету. Я ручками не правлю никакие стрелочки. Пожалуйста. 2026 год. Не правьте ручками стрелочки. Очень. Ну очень вас прошу, давайте обратно вернём. Нам это ещё пригодится. Так вернёмся. Значит, мы посмотрели, как это выглядит.
42: Посмотрели в чем плюсы едем дальше. Самый важный тезис этого видео любая диаграмма это скетч цитата из книжечки, про которую я вам раньше говорил лучше хороший дизайн, невалидном юмл, чем валидный, но плохой дизайн.
43: Под дизайном здесь понимается систем дизайн, то бишь архитектура приложений. В чем смысл этого тезиса? Смысл в том, что эмэль изначально задумывался, как у него было 3 режима использования первые 2 были про проектирование систем с помощью
44: То есть там наши чудесные отцы запаривались по системам, которые полностью описывали всеми диаграммами необходимые сервисы и их связанность, а потом они нажимали кнопочку автогенерации и получали
45: Готовый код. Вот этот подход не выжил. Выжил только подход, когда мы хотим донести какую-то информацию до разработки и делаем скетч. Собственно, 3 тезиса. Нет компилятора, нет линтера. Это, если что, тот сервис, который
46: Проверяет правильность того, что вы написали. Никто не проверяет эту самую правильность. Единственный критерий это команда поняла задачу. Не нужно рисовать, все нужно рисовать. Вот, вот, вот, как-то необходимо и достаточно дальше про это все решают локальные договорённости. Един
47: Единственный, короче, кто скажет, что ваш сиквенс правильный или неправильный, это команда. Строгих правил нету. Есть только те правила, о которых вы договорились. Значит, примеры этих договорённостей на слайде жёлтая стрелка. Договорились? Рисуете, пожалуйста, хоть зелёную, хоть красную.
48: Вас просто перестанут понимать в какое-то время все остальные, да, но в целом в целом вообще любая диаграмма скетч, я исключительно этому придерживаюсь. Красная рамка для внешних систем, хоть жёлтая показывать или не показывать.
49: Возвраты и все ошибки. Вот решите с командой. Вам это надо или нет, или вы и так друг друга. Понимаете? Глубина вложенности тоже самое, формат подписи, стрелок. Все, вот как вы договоритесь. Ну, напоминает, это стандарт.
50: По моделированию BPM н, который был разработан командой шторма и открыт там примерно такая же логика. Вы выделяете те элементы, которыми вы хотите, ну, которые вы считаете правильным использовать, и договариваетесь, что мы будем делать вот так супер. Очень удобно. Я вам
51: Сделал ещё шпаргалку, когда нужно рисовать BPM энн. А когда сиквенс, значит, главный тут вопрос, кто будет это читать для BPM энн? Это обычно бизнес заказчик, какой-то владелец процесса. В общем, человек ближе к бизнесу для сиквенса. Обычно это разработчик, архитектор, тестировщик, ну и самый
52: Интересно, что BPM н система представляется черным ящиком. Задачка 1 прямоугольник сделать магию. Ну, этого достаточно, a sequence уже раскрывает эту магию фактически, кто пойдёт за данными, как он пойдёт за данными, через какой протокол он пойдёт за данными, какой ответ он может получит.
53: Как ему нужно авторизоваться, чтобы получить эти данные. В общем, там много что может быть, но это все BPM свёрнуто в 1 маленький квадратик. Очень удобно. Ну и масштаб, да, что сиквенс это маленькое интеграционное взаимодействие пиэм может быть достаточно большим, фактически
54: Sequence. Не конкуренты, они просто дополняют друг дружку. Так, самое интересное, когда не рисовать сиквенс. Ну это когда у вас линейный процесс. Ну просто там это 1, 2, все, конец, когда у вас карта компонентов. Ну это, то есть, когда вы хотите посмотреть
55: Не, не последовательность вызовов, не динамику, а статику какую-то, как сервис расположены, как они друг с другом общаются. Но когда у вас бизнес процесс с десятью ролями или когда у вас 1 вызов, вам нужно написать спецификацию этого вызова, а не рисовать.
56: Какой-то sequence. Зачем он непонятно. Сиквенс это когда 1 система говорит другой, a2 что-то ей отвечает. Вот тогда уже появляется какое-то взаимодействие антипаттерн, дублирование, сиквенс это обзорная экскурсия, фактически не техническое задание. Вы можете конечн.
57: Договориться с командой и принять, что там мы пишем самый подробный сиквенс. Сиквенс является артефактом технического задания, но лучше так не делать. Вот сиквенс служит для визуализации, для простоты. У вас всегда за сиквенсом будет идти информация.
58: Об аппе, вызовах, об очередях, о схемах баз данных. Вы детализируете эту информацию в других артефактах, а сиквенс нужен просто, чтобы команда посмотрела такая интеграционно, такая, ну мне нравится, вроде все просто вот здесь вот мы упадём, потому
59: Потому что вот здесь вот запрос огромный. Переделай, пожалуйста, 2 антипаттерн простыня. Я даже не знаю, как поставить в эту презентацию такую большую схему, поэтому вот я их сделал 2, чтобы они рядом лежали. Но смысл здесь простой, когда диаграмма из читаемой превращается в нечитаемую.
60: Давайте аналогию BPM. Н, это любая диаграмма с дорожками. Когда ты даже не понимаешь, че происходит, тебе приходится брать Лупу, зумить конкретный кусок и понимать, что там происходит.
61: Вот как это, собственно, решается? Это решается как раз через реф. То есть вы даёте ссылку на куски процесса, либо вы её декомпозирует. Понимаю, понимаю, что бывают сервисы, особенно внутри, ну, внутрикорпоративные, кото
62: Которые требуют такого большого количества вызовов. Повторюсь, лучше делать проще, сложно. Само получится в реальности. Конечно, вам придётся сделать эту большую диаграмму, но вы будете плакать, страдать и смотреть на неё с ужасом. Значит, 5 ошибок, которые
63: Всегда делают. И вот слишком много их значит ui как участник, честно скажу, я сам это делаю, значит только я не говорю, что это форма или кнопка, а я говорю, что это фронтенд, и, наверное, это уже не ошибка, потому что я считаю его
64: Участникам взаимодействия, потому что фронтенд это кусок кода, который у вас расположен, который скачивается на локальный компуктер, а оттуда запускается перегруз альтернативных сценариев. Вот здесь, правда, любая диаграмма, это, как сказал 1 классик в чате,
65: Любая диаграмма показывает нам лишь часть какой-то процент от реальности, и если вы захотите на сиквенсе описать все, все, все возможные негативные ответы с помощью alt сценариев, вас никто не остановит.
66: Но будет ли это информативно и кому это будет нужно, не очень понятно. Поэтому перегруз альтернативных сценариев, как будто бы, как будто бы, собственно говоря, не стоит. Это тоже самое, что BPM, н, когда мы говорим, а что будет, если на клиента упадёт метеорит, и он не ответит нам в какой-то момент?
67: Это вот примерно о том же возврат без данных кто-то показывает синхронный ответ, кто-то не показывает в принципе, юмл говорит о том, что если вызов по стрелочке нарисован синхронным, то не нужно рисовать обратную стрелочку, но, в общем, лучше показать, как будто бы схема вакуум.
68: Ну это когда у вас нет никакой связи, это просто какая-то картинка для визуализации. Она на чем основана? Она сама артефакт штука сомнительная, ну и устаревшая схема это когда вы даёте другому человеку представление о работе.
69: Сервисов, которые ошибочны. Старо. Ведь фактически, да, такие схемы служат аналитиком для погружения в контекст системы. И если мы натыкаемся на, как сказать, на контекст, который устарел, мы свои предположения и новые изменения.
70: Строим на таком зыбком фундаменте и очень быстро они разработчиком по коду так посмотрятся и такой, ой, а тут не тот сервис был, ну как бы и все. Поэтому лучше держать какие-то версии и смотреть, когда данные были обновлены. Ну давайте к живому примеру наконец-таки сейчас пойдём, что
71: Значит, давайте начнём с простого. Вот у нас есть текстом какие-то шаги, типа там клиент нажимает вернуть магазин, проверяет срок возврата, запрашивает у склада статус, если можно, создаёт заявку, уведомляет клиента работа аналитика это работа с
72: Кейсами. Простите за мой англицизм. Это работа с альтернативными сценариями, со всем тем счастьем, которое может у нас произойти. И диаграмма как раз-таки тут может помочь тем, что она, если BPM, помогает нам понять, а че пойдёт
73: Не так. У человека то second заставляет задуматься, а что будет, если у сервиса не будет необходимых данных, чтобы принять какое-то решение или отправить заявку дальше? Значит, вот здесь предлагается уже на этом шаге возникают вопросы. А если срок вышел, кто именно?
74: Магазин и там склад работает синхронно, не синхронно. Ждать его, не ждать. Пойдёмте посмотрим, как все это из кода превращается в красивую картинку, что
75: То здесь есть 1 и очень важное, это будет в пасхалках в конце. Это автономеров. Пожалуйста, включайте его. Очень удобно, потому что вы не будете думать. 1. Вот здесь я вам скажу, стрелка 1, стрелка 2, стрелка 3. Вы сразу понимаете, про что речь?
76: Значит, здесь представлены участники. Клиент вызывает личный кабинет, нажимает вернуть товар активейт лк. Я специально не представил вам этот элемент раньше. Элемент называется жизненный цикл системы. Он
77: Говорит о том, когда система работает, активно выполняет какой-то процесс или нет. Они там могут убиваться. Есть какая-то логика, честно скажу, я давно хочу от него отказаться. Вот, потому что в реальности программисты сами решают синхрон.
78: Это работает асинхронно, это работает. Будет ли у нас ожидать процесс, чего-то не будет ожидать. Я не вижу большого смысла в жизненном цикле системы. Вот поспорьте в комментариях. Готов, готов подебатировать, но я рисую. Вот
79: Вот по простому, на весь, чтоб красивенько было с полосочкой. Значит клиент нажимает вернуть товар. Лк отправляет запрос в сервис заказов. Запрос на возврат ордер айди, значит,
80: В этой схеме описано, ну, типа запрос на возврат. Получить данные можно, конечно, не так. Можно пойти иначе и написать протокол обычно, ну, происходит чуть иначе, значит, указывается.
81: Ну, это я сейчас делюсь уже рабочими, какой-то рабочей практикой. Можно этого не делать, а можно делать все зависит от того, насколько вы погружены в техническую часть. Ну, например, укажем протокол, укажем метод, укажем путь.
82: Можем написать там запрос на возврат, если хочется. Но, в принципе, обычно так никто не пишет. И напишем, что там о ордер. И, например, вот так ордер айди супер. Мы же патчем конкретный заказ.
83: Замечательно. Обычно это выглядит вот так. Дальше ордер сервис некоторый, который поймал наш запрос, пошёл в базу данных и получил данные заказа здесь до уровня селектов. Аналитики обычно не опускаются. Не знаю, как вы можно здесь написать.
84: Типа select from че то там ну не знаю можете как хотите дальше по бизнес данным получается заказ, дата, статус товара. Можно в принципе тело ответа сюда попробовать засунуть если вам нужно
85: Для логики дальше вот самовызов ордер вызывает ордер проверяет срок возврата. Тут есть умный комментарий, что срок возврата 14 дней с момента получения этот умный комментарий нужен для читателя, чтобы объяснить следующую развилку. Развил.
86: Срок не истёк. Значит мы проверяем возможность приёмки. Здесь, наверное, тоже будет какой-то метод. Не будем его сейчас выдумывать, но просто понимаете, что за за этим вызовом стоит какой-то протокол.
87: Вот, а это не просто там Вася сходил к Пете, нет, там есть какая-то реализация. Вот, значит, у нас 2 варианта. Срок не истёк. Тогда мы проверяем возможность приёмки, создаём заявку на возврат, получаем заявку, выкидываем её обратно пользователю.
88: Если срок истёк, мы, собственно говоря, ему отказываем, деактивируем наших чудесных участников, заканчиваем лаконично, красиво. Что дальше к этой схеме нужно прикрепить? К этой схеме нужно прикрепить описание, что это были за вызовы под номером 1. Это как?
89: Какая-то кнопка это какие-то макеты номер 2, это какая-то спецификация, ну метода, который нужно написать что он умеет, какие ответы он возвращает, как нужно авторизовываться? 3 из какой таблицы нужно брать данные, какие данные? 6 вызов
90: На складе. Что это за вызов? Как он работает? Как его применять? 8 вызов создания заявки, создать заявку на возврат. Это нужно указать, в какую таблицу нужно записать эту чудесную заявку. Ну и, собственно, 11 или 13.
91: Это пользовательский юикс, как он должен выглядеть, что должен видеть пользователь и зачем? То есть фактически сиквенс это такая интеграционная штука, которая описывает связь между действием в чёрном ящике. Мне вот нравится описывать, что
92: Vpn работает с системами, а сиквенс это вот давайте распишем, а че происходит внутри этого раздражающего фактора? Значит, здесь пример, что будет, если эту схему усложнить и здесь обратите внимание.
93: Что наш процесс возврата на склад, который мы нарисовали чуть выше, он спрятан под ссылку на другую диаграмму, а вокруг него построена другая логика, значит, если усложнить и нам нужно, например, добавить внешнюю систему и
94: Какую-то работу с этой внешней системой, то мы можем вместо того, чтобы перерисовать кусок, можем просто сослаться на него и нарисовать другую логику рядышком с ссылкой на нашу предыдущую диаграмму. Достаточно удобно, собственно
95: Немножко советов, как читать чужую схемку. Обычно схемы рисуют слева направо. Обычно самый левый участник это инициатор можно сделать иначе, но это вот если вам очень нужно 1 стрелка, какой главный поток попробуйте проигнорировать все альтернативные сценарии и
96: Следить просто за нитью повествования в целом а что это зачем, где развилки после этого пути можно заходить в развилки и смотреть че происходит в дополнительных сценариях, что скрыто в ref. Ну надо поискать отдельные диаграммы, если там сосланы.
97: Если есть ссылки на них, хороший аналитик оставит ссылки где-то рядышком. Ну и где точки отказа? Это вот пройти по каждому пути, по каждому, по каждой стрелочке и подумать, а что пойдёт не так? Есть ли у сервиса необходимые данные? Есть ли у сер?
98: Необходимые разрешения, попробовать сломать все это, попробовать сказать, что все, ничего не получилось, поиграть в такого маленького халка, который должен крушить и ломать, желательно не ломать при этом монитор секретики сначала
99: Можно написать текст, потом нарисовать вообще взрослые аналитики думают, Сикун с диаграммами. То есть это такое профессиональное искажение, которое уже не убрать. Вот если мне меня попросят быстро в моменте
100: На бумажке, нарисовать какую-то описание какого работы, какого-нибудь метода, то я начну инстинктивно рисовать что-то похожее на сиквенс диаграмму. 1 сиквенс, 1 сценарий не нужно мешать в кучу. Диаграмма должна быть простой, удобной и красивой. Ну,
101: Можно прочитать как тест кейс. Да, вполне валидно. Иногда его сложно проверить, но в целом для тестировщиков очень удобно. Они тоже этим пользуются. Просто об этом знайте. Внешние системы в рамку супер совет можно не только внешние системы в рамку, а ещё и
102: И компоненты своей системы оборачивать в рамку. Ну, например, фронтенд бэкенд, там база данных, а это соседний сервис. Это упрощает просто восприятие. Автонабор, навигация супер авто.
103: Auto намбер навигация 1 слово, оно предотвращает миллиард вопросов, а про какую стрелку идёт речь? Файлы с диаграммами лучше хранить в репозитории, версионировать, потому что их очень просто потерять.
104: Здесь ещё 1 совет не пользуйтесь открытыми генераторами, если у вас данные, которые защищены политикой индей, пользуйтесь какими-то локальными способами, либо у вас в инструменте.
105: Документирование типа конфлюенса должен быть макросс, либо можно локально настроить работу с плантю себе. Если у вас очень щекотливая и интересная информация, группируйте по слоям пользова.
106: Слева бэкенд, в центре, внешний справа ну это про то, что диаграмма читается слева направо хорошо было, чтобы это было так. Ну и рисуйте с помощью ai да, у storm ПИН есть чудесный рисоватор, чудесный иай помощник, которому можем.
107: Написать словами, а он превратит это все в диаграммку. Что самое важное из того, что я сегодня рассказал сиквенс, это скетч, это не чертёж, это не техническое задание, это просто способ визуализации, если нужно показать
108: Связанность сервисов это 1 из лучших вариантов на текущий момент. Сиквенс это язык общения с командой разработчик. Архитектор кьюэй. Им не нужен дополнительный словарь для того, чтобы прочитать то, что ты сказал. Им можно скинуть картин.
109: И сказать, а че ты на это думаешь? И он тебе ответит по делу. Он поймёт, что это за сервисы, кому они нужны, что это за вызовы. Ему будет достаточно этой информации, не нужно вызывать его на отдельный звонок и спрашивать. Ну, собственно говоря, участники стрелки и 1 развилка, это уже очень полезно.
110: Если ты добрался до этой глубины, то ты воспринимаешь системы как набор сервисов, а не как чёрный ящик. И ты смог заглянуть внутрь. Собственно, попробуйте нарисовать сикман шторм, ипиэн. Можно сделать это 2 способами. Это создать с чистого листа. Это просто открыть эдитор.
111: И начать там писать, либо создать с помощью ai давайте мы это и попробуем сделать.
112: Так, попробуем создать сикус диаграммку с помощью ai так?
113: Процесс подготовки, презентации и записи видео. Почему, говорю, процесс, ну, допустим, записи видео.
114: Грамма учти ревью презентации съёмку, монтаж, публикацию, закидывание помидорами.
115: И что твой BPM н отстой.
116: Так, у нас тут есть, короче, автор есть ревур, есть аудитория, вот, значит, какой-то сервис презентации, мы, автор, создаём презентацию в каком-то сервисе.
117: Презентации. Потом ему, короче, Реву еру, отдаём на Реву Реву ер провайд фидбэк. Интересно, он сделал пунктирной стрелочкой провайд фидбэк, потому что, а давайте мы тог
118: Да у нас же не сервис презентации, на самом деле у нас google slides.
119: Google slides. А вот это, допустим, YouTube, или че там будет? Во, значит, я автор, автор, автор, это мне не надо.
120: Напишем на русском, на русском.
121: Аналитики. Так, значит. Ага, теперь у меня создался. Теперь мне нужно создать для них псевдонимы, потому что я все поменял.
122: Ща.
123: Ооо, не надо так делать, так.
124: Ага, вот держится.
125: Должно работать так теперь Никита создаёт презентацию в google слайдах гуугл, слайды присылают её саммит фо ревью это не совсем так. Значит, у нас же как у нас же.
126: Дальше google слайды мне условно отвечают, что
127: Что презентация создана.
128: Дальше я её закидываю.
129: Ревью еру.
130: Проверь презентацию.
131: Так, ревьюер. Вот, кстати, он может мне сказать, что все плохо. У нас же как происходит? У нас же ревьюер проверил презентацию.
132: Он же мне может, получается ответить, что все плохо. Значит, нам нужен альт, сценарий, альт. Все хорошо. Давайте сначала все плохо напишем. Если все плохо, то у нас ревьюер отвечает мне.
133: Что надо переделать?
134: А если все хорошо, то бишь лс пок, то он мне как раз-таки только не п.
135: Ревью.
136: Получается прова фидбэк надо удалить update презентейшн ревьюер автор он же мне вот так возвращает правильно, правильно почему не нарисовался альт, потому что нужно закончить блок.
137: Ок, окей. Так, дальше, собственно говоря, если
138: Update презентейшн этот блок мы рассматривать не будем.
139: Предположим, что у нас одноразовая проверка и все. На самом деле, там должен быть loop. Если нужно это показать, как будто бы лень дальше нужно записать видео. Ну,
140: Допустим, edit and montage.
141: Отредактировать видео, опубликовать видео, что это за п у нас осталось? Ага, потому что у нас google slides, автор п. Автор, презентация создана какая-то, да.
142: Буква ну, бывают такие сложности с
143: Ну вот такая вот смешная диаграмма получилась. Ха ха. Ну опять же, да, эта диаграмма больше смахивает на процесс. Вот получается для этой, конкретно, для этого конкрет.
144: Пример бипи н не отстой, можно выбирать, мне кажется, top теперь вы знаете, что такое сиквенсы, когда их использовать, когда нужно выбирать BPM, а когда нет, опять же вас никто не останавливает, пользуйтесь с умом.
145: Seite, в то, как работают системы. Доносите свои мысли до разработчиков и делайте классные фичи, люди, аналитики, товарищи. Вам не надо уже ничего учить. Никакие сиквенсы, никакие. BPM, очень
146: Скоро ваши работодатели узнают, что такое клод. Ну, кстати, вообще не шутка. И вообще, это вам надо, если честно, думать не про вот такие хардверные скилл.
147: А про умение излагать свои мысли, про то, как работать сай, про то, как это все может помогать вашим бизнес процессам и вашим текущим работам. И поэтому я вас ещё дополнительно вас и Никита там будет, и я там буду, мы там все будем
148: 10 апреля приглашаю на конференцию, которая называется BPM plus y. Как экономить миллионы рублей и повышать эффективность в бизнес процессах с помощью i. Приходите, будем рады очень вас видеть.