Як краще намалювати складний flowchart з відображенням руху in/out даних?

Вітаю,

Отже, є певна програма, котра являє собою послідовний набір функцій, які викликаються одна за одною з умовної стартової функції в заданій послідовності аж до кінця. Під час виконання деякі функції генерують певні дані чи файли, які потім можуть як використовуватись як вхідні дані для наступних функцій, так і бути просто вихідним продуктом, який має отримати користувач

Потрібно намалювати фловчарт для потенційних майбутніх користувачів цієї програми, який би відображав послідовність дій і що і як відбувається під час них — щось типу інструкції по коритуванню + документації для майбутніх розробників. Проблема полягає в тому, що на ньому за запитом овнера бути відображено все:

— назви функцій в блоках

— напрям руху умовного користувача — що за чим викликається

— які саме дані потрапляють на вхід, і що саме генерується на виході, як аргументи для наступних функцій, так і окремі артефакти типу файлів

— кольорова легенда (оранжевий — код, синій — додаток де відображаються згенеровані дані, зелений — ексель і т.д.)

І от питання власне — як одночасно відобразити і послідовність виклику функцій (блоків), і те, які саме дані вони використовують і генерують після виконання, щоб не перенаситити схему конекторами і якось розрізняти їх ’тип’, щоб користувач розумів, де це рух даних, а де рух по власне програмі?

Умовний flow для прикладу

1. Виконується функція init_project(), яка генерує певні дані в templates_data

2. далі виконується функція create_inventory_data(), яка використовує templates_data як вхідний аргумент і генерує таблицю inventory_table в певному додатку

3. далі виконується функція export_to_excel(), аргументами якої є дані з таблиці inventory_table і певні дані користувача з user_data.json і на виході генерує ексель файл з даними таблиці для цього користувача

4. далі виконується функція яка використовує лише templates_data і т.д.

...

Поки що є наступні варіанти:

#1: підписувати конектори, які відображують рух даних і візуально їх виділяти (тип лінії, колір):

#2: прямо в блоках функцій вказувати вхідні/вихідні аргументи, а конектори залишити без підпису, можливо, виділяти їх візуально

Але в мене досвіду нема в таких штуках, буду вдячний за запропоновані ідеї, як краще це все реалізувати.

Дякую,

N.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Діаграма на 40+ блоків не має ніякого практичного сенсу — все одно її ніхто не зрозуміє. Зробіть кілька діаграм для логічних етапів або напишіть текстом у кілька зрозумілих абзаців

То, что описано на мой взгляд выглядит, как полный процесс компиляции.
Вот и гугли c++ compiler pipeline.

типу того, але це радше процес поступової валідації даних і генерації з них певних ’артефактів’
на початку є просто набір атрибутів і логіки, як саме це все валідувати і комбінувати
умовно, користувач задає свій набір даних в умовоному jsoni-i і далі:
функця f1 — перевіряє чи вони валідні;
f2 — складає їх в читабельну таблицю
f3 — генерує з них набір всіх можливих комбінацій
f4 — по вибору, для певної комбінації обчислює її вартість
f5 — перевіряє валідність комбінації, якщо параметр а встановлено <1;
і т.д., так поступово все розгортається, як сніжний ком
і це типу якось треба відобразити візуально

Вот и чередуй белым данные, серым обработчик.

Я б це зробив sequence діаграмою. Актори: арр, база, фійлове сховище, що конкретно робиться можна писати на стрілочках (стрілочки можеть бути довгі і багаторядкові), тону тексту можна вивести в ноутси.
Рекомендую подивитися Mermaid діаграми, що дозролять робити діаграми псевдокодом.

Відкривай draw.io і малюй в довільному форматі якщо щось маркетингове Якщо технічне то не треба мішати — флов своя діаграма, данні своя, виклики функцій своя
Ось приклад як sumsub маркетингові діаграми малюють docs.sumsub.com/...​data-sharing-restrictions Досить вдало і зрозуміло

напівтехнічне, це щось має бути як схематичний мануал-інструкція до того, як саме користуватися цим всім набором функцій/скриптів, який отримає кінцевий юзер — які саме кроки він повинен пройти, щоб отримати такі то чи інші дані

Я свого часу або draw.io використовував або ( якщо треба було ті діаргами у гіт-і зберігати ) то ось таку штуку mermaid.live
Блоки краще робити різними ( ще бажано за кольором) по типу того що вони роблять.. або якусь дію або це запит в базу а бо щось інше
Якщо треба визначити порядок виклику то краще ті стрілочки пронумеровати 1 — 99
тож буде зрозуміло з чого починається та як потім йде потік виконання
Якщо треба показати лише окремий функціонал то краще його винести у окрему діаграму та якщо вона передає управління у зовнішні системи то їх позначити умовно та описати (якщо треба) у незалежних окремих діаграмах
Завжди пам«ятайте кому ви будете показувати ці діаграми тож не робіть діаграму для не технічних персон з купою технічних деталей ( бази, HTTP виклики інше) бо не зрозуміють та навпаки якщо презентуєте діаграму комусь хто розбирається у тому що там «під капотом» то можна надати максимум тех опису
Блоки треба вивести окремо у «легенду» та описати що вони означають на діаграмі
Якось так..
Вибачте ящо мої коментарі мимо тож сміливо їх ігноруйте

Для розробки є корпоративне MS Visio
Окремий функціонал не передбачається, скоріше можливість розгалуження на певному етапі, коли після функції 2 можна викликати як 3,4,5(умовний flow#1.1) або ж 7,8,9 (flow#1.2)
З даними те саме, напр. в таблицях є залежності типу 1 до n коли дані однієї є базою для генерування кількох інших

теж користуюсь mermaid.live з нюансів трохи незручно описувати циклічні процеси на великій діаграмі

Рекомендую ознайомитись з en.wikipedia.org/wiki/Flowchart

Ви некоректно використовуєте позначення елементів.

Дякую, однак точність позначення елементів це інше питання, можуть бути і свої власні кастомні
Суть як саме сумістити 2 різних — data flow і control flow(якщо це воно?) — на одній схемі, якщо це взагалі можливо

По-перше, я так розумію, якщо це весь ваш алгоритм і в ньому не більше 7 операцій, то створення діаграми для цього — зайве. Я б зробив документ, де за допомогою псевдокоду або Python записав цей алгоритм.

По-друге, можна взяти елементи «процес», «файл», «база даних» і показати, що з одного процесу виходить файл, який разом із таблицею з БД переходить до наступного процесу.

Ось приклад: подивіться, як ми зобразили наш процес розробки: www.dnt-lab.com. Ми одразу показали і процес, і deliverables, або вхідні документи.

та де весь(я б тоді і не питав за це), реальний наявний flow використовує ~20 функцій (не рахуючи малих вкладених типу формат даних для екселя), генерує 7-8 таблиць і експортує 4-5 файлів

Тоді можна сміливо сумістити елементи «операція» та «файл», «база даних».

Підписатись на коментарі