Проектування та випробування не можуть виконуватися будь-якими генераторами. Найпростіший спосіб - це через
ШТЕЙНБАХ (je) - "Я вважаю, що порівняння різних методів при розробці програм не є вирішальним", пише Фолькер Ельстерманн і обгрунтовує це тим, що методи блок-схеми, структурованої схеми та псевдокоду послідовно базувались на ідеї модульної структури та Підхід бути однаковим. Ельстерманн, автор статті "Як я навчився любити структуровані схеми" в CW №. 30 від 25 липня, йдеться про відповідь, яку дав Юрген Евальд під заголовком "Корона завдяки модульному програмуванню" в CW №. 34 було опубліковано 22 серпня. (Тим часом, група дискутантів була розширена, включивши Германа Ланге. Див. Статтю "Не створюйте модуль довільно" у цьому випуску.)

Що стосується Евальда, який є членом університету, Ельстерманн каже, що "знову стане ясно, що теорія і практика/застосування мають абсолютно різні проблеми". Для практикуючих - так Ельстерманн - це менше про самі діаграми та їх форму, але більше про застосовність, навчальність та успіх.
Потім Ельстерман коротко пояснює альтернативні методи:
За допомогою блок-схеми програма розробляється командою за командою, що суперечить усім вимогам добре структурованої та зручної для обслуговування програми. Але після тривалого періоду практики кожен програміст автоматично приходить до блок-схеми, яка дуже схожа на модульну схему. (Див. Модуль План Юргена Евальда в CW від 22 серпня)
Як видно з порівняння "Структурна діаграма: модульний графік" у CW 22 серпня, обидві схеми однаково значущі. Структограма пропонує більше місця для тексту з одного боку.
Подальшим розвитком структуктограм є псевдокод. (Це також видно з порівняння в CW від 22 серпня 1980 р.) У випадку псевдокоду, стовпчики в структуктограмі просто замінюються стандартизованими кодами.
Ельстерманн далі: Технології розробки підтримуються інструментами та генераторами, такими як "Домашня тварина" та "Дельта". Однак вони лише полегшують ручне зусилля з оформлення документації. Справжня проблема полягає в тому, як знайти шлях від блок-схеми до структурованої програми. Мене особливо турбують практичні програмісти, яким доводиться розробляти програми щодня. Найпростіший спосіб - це через структограми. Жоден інструмент не може допомогти правильно представити логіку програми. Вирішальний крок розробки програми здійснюється за робочим столом з папером та олівцем:
- Намалюйте структуктограму,
На мій погляд, немає кращого засобу представлення, ніж структуктограма для перевірки логіки програми перед кодуванням. Ось приклад: (Жоден генератор не буде винуватити в логіці.)
Тест цієї структуктограми складається з перевірки структурного блоку за структурним блоком та тестових питань щодо:
- Звідки беруться дані?
- Куди йдуть дані?
- Як переміщуються дані?
- Передача дозволена?
З цими запитаннями можна знайти: якщо прочитаний наступний запис, він перезаписує область головного запису-1. (Це дуже поширена помилка для початківців.) Тепер можна зробити наступне виправлення:
Досвід показав, що програми, розроблені та протестовані таким чином, містять лише помилки, допущені в кодуванні, і їх легко знайти в машинному тесті.
Програма "Управління основними даними". зараз коштує лише один день часу проектування, решта - справа напруженої роботи і залежить від рутинного кодування та системних знань програміста.
Найпростіший спосіб структурованого програмування - за допомогою структуктограм. Ручне складання та тестування на столі не може виконувати жоден генератор. Однак вони можуть спростити документацію та обслуговування діаграм.
Варіантами структуктограм є модульні блок-схеми та псевдокоди. Вони базуються на одній і тій же ідеї структурування, але показані на ілюстрації. різні, а іноді як один, іноді інші більше.