Проектування та випробування не можуть виконуватися будь-якими генераторами. Найпростіший спосіб - це через

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

випробування

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

Потім Ельстерман коротко пояснює альтернативні методи:

За допомогою блок-схеми програма розробляється командою за командою, що суперечить усім вимогам добре структурованої та зручної для обслуговування програми. Але після тривалого періоду практики кожен програміст автоматично приходить до блок-схеми, яка дуже схожа на модульну схему. (Див. Модуль План Юргена Евальда в CW від 22 серпня)

Як видно з порівняння "Структурна діаграма: модульний графік" у CW 22 серпня, обидві схеми однаково значущі. Структограма пропонує більше місця для тексту з одного боку.

Подальшим розвитком структуктограм є псевдокод. (Це також видно з порівняння в CW від 22 серпня 1980 р.) У випадку псевдокоду, стовпчики в структуктограмі просто замінюються стандартизованими кодами.

Ельстерманн далі: Технології розробки підтримуються інструментами та генераторами, такими як "Домашня тварина" та "Дельта". Однак вони лише полегшують ручне зусилля з оформлення документації. Справжня проблема полягає в тому, як знайти шлях від блок-схеми до структурованої програми. Мене особливо турбують практичні програмісти, яким доводиться розробляти програми щодня. Найпростіший спосіб - це через структограми. Жоден інструмент не може допомогти правильно представити логіку програми. Вирішальний крок розробки програми здійснюється за робочим столом з папером та олівцем:

- Намалюйте структуктограму,

На мій погляд, немає кращого засобу представлення, ніж структуктограма для перевірки логіки програми перед кодуванням. Ось приклад: (Жоден генератор не буде винуватити в логіці.)

Тест цієї структуктограми складається з перевірки структурного блоку за структурним блоком та тестових питань щодо:

- Звідки беруться дані?

- Куди йдуть дані?

- Як переміщуються дані?

- Передача дозволена?

З цими запитаннями можна знайти: якщо прочитаний наступний запис, він перезаписує область головного запису-1. (Це дуже поширена помилка для початківців.) Тепер можна зробити наступне виправлення:

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

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

Найпростіший спосіб структурованого програмування - за допомогою структуктограм. Ручне складання та тестування на столі не може виконувати жоден генератор. Однак вони можуть спростити документацію та обслуговування діаграм.

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