Блок-схема та виклики методів

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

введіть тут опис зображення

У мене є 3 інші методи, які також викликають GetQueue (), і мені цікаво, чи правильно я це представляю. Потік AddQueue () візуально виглядає як він порушений.

ПРИМІТКА. Зміни, внесені в мою блок-схему:

введіть тут опис зображення

flowchart

— Кіт Барроуз
джерело

Чи справді потрібен цей рівень живописних деталей? Я знаю, що свого часу подібні блок-схеми були популярними, але, схоже, вони сьогодні з багатьох причин вийшли з ладу ... По суті вони є зайвою формою документації; ви повинні постійно їх оновлювати, і код вже повинен адекватно представляти те, що відображається на блок-схемі потоків (тобто: час краще витрачати на створення більше коду).

— Роберт Харві

Це просили від мене, перш ніж перейти до іншого клієнта.

— Кіт Барроуз

@ Роберт Харві: Блок-схеми були корисні в старі часи, коли люди писали код машини або асемблера безпосередньо. Вони можуть бути корисними для ранніх програмістів FORTRAN та BASIC, які не мали гарного набору структур управління. Сьогодні, ну, єдиною причиною я б це зробив, якщо клієнт хотів їх доставити і був готовий заплатити мені гідно.

— Девід Торнлі

Розробляючи їх з нуля, я вважаю дуже корисним використання жовтих наліпок, повертаючи 90 градусів для прийняття рішень. Це дозволяє переміщати їх і вставляти процеси між ними. Коли ви все не надішліть, тоді введіть їх у своє програмне забезпечення.

— Майкл Райлі - AKA Gunny

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

— Майкл К

Відповіді:

Використовуйте символ підпрограми для виклику методу (попередньо визначений процес)

введіть тут опис зображення

— Роберт Харві
джерело

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

Я прийняв рішення про те, що я відокремлюю підпрограму CALLS від підпрограми REFERENCES. Для першого я використовую звичайний прямокутник, що показує виклик із зробленими аргументами, використовуючи будь-які змінні, які діють у цей момент виконання програми.

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

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

Я також використовую символ "документ", щоб сказати, що деталі слід шукати з переліку коду.

Сенс схеми для мене полягає не в створенні програми, а в тому, щоб іншим було легше зрозуміти програму. Я думаю, що допомога як погляд з пташиного польоту, і про цю мету слід пам’ятати. Вони не призначені для візуального опису КОЖНОЇ деталі вашої програми, деталі видно з коду при необхідності. Блок-схема - це лише одне зображення вашої програми з точки зору високого рівня.

Підтримка діаграм потоків на високому рівні також означає, що менше потребує оновлення, оскільки код змінено.

Вони - фотографії. Як і будь-яка хороша документація щодо програмного забезпечення для історії, повинна містити також зображення, які дають альтернативну точку зору на код.

— Логіка Пану
джерело