Най-лесният начин е чрез структограми

STEINBACH (je) - „Вярвам, че сравнението на различни техники при проектирането на програми не е решаващо“, пише Фолкер Елстерман и обосновава това с факта, че техниките на блоковата диаграма, структурираната диаграма и псевдокода последователно се основават на модулната концепция Подходът да бъде същият. Елстерман, автор на статията "Как се научих да обичам структурираните диаграми" в CW №. 30 от 25 юли, се занимава с отговора, даден от Юрген Евалд под заглавие „Короната се дължи на модулно програмиране“ в CW №. 34 е публикуван на 22 август. (Междувременно групата дискутанти беше разширена, за да включи Херман Ланге. Вижте статията „Не създавайте модула произволно“ в този брой.)

По отношение на Евалд, който е член на университета, Елстерман казва, че "вероятно отново ще стане ясно, че теорията и практиката/приложението имат напълно различни проблеми". За практикуващите - така че Elstermann - това е по-малко за самите диаграми и тяхната форма, но повече за приложимостта, усвояемостта и успеха.

След това Елстерман обяснява накратко алтернативните техники:

Програма се разработва команда по команда с блок-схемата, което противоречи на всички изисквания на добре структурирана и лесна за поддръжка програма. Но след дълъг период на практика всеки програмист автоматично достига до блок-схема, която е много подобна на модулната схема на потока. (Виж мод. План от Юрген Евалд в CW от 22 август)

Както се вижда от сравнението "Структурна диаграма: модулен график" в CW от 22 август, двете диаграми имат еднакво значение. Структограмата предлага повече място за текст от едната страна.

По-нататъшно развитие на структуктограмите е псевдокодът. (Видно също от сравнението в CW от 22 август 1980 г.) В случая на псевдокод, стълбовете в структуктограмата просто се заменят със стандартизирани кодове.

Elstermann по-нататък: Техниките за разработка се поддържат от инструменти и генератори като "Pet" и "Delta". Те обаче улесняват само ръчните усилия по документиране. Истинският проблем е как да намерим пътя от блоковата диаграма до структурираната програма. Особено съм загрижен от практическите програмисти, които трябва да разработват програми всеки ден. Най-лесният начин е чрез структограмите. Нито един инструмент не може да помогне за правилното представяне на логиката на дадена програма. Решаващата стъпка от дизайна на програмата се извършва на бюрото с хартия и молив:

- Скицирайте структограмата,

Според мен няма по-добро средство за представяне от структуктограмата за проверка на логиката на програмата, преди да кодирате. Ето пример: (Нито един генератор няма да повреди логиката.)

Тестът на тази структуктограма се състои от проверка на структурен блок по структурен блок и тестови въпроси за:

- Откъде идват данните?

- Къде отиват данните?

- Как се преместват данните?

- Разрешен ли е трансферът?

С тези въпроси се открива: ако се прочете следният запис, той презаписва областта на главния запис-1. (Това е много често срещана грешка за начинаещи.) Вече може да се направи следната корекция:

Опитът показва, че програми, проектирани и тествани по този начин, съдържат само грешки, които са допуснати в кодирането и са лесни за намиране в машинния тест.

Програма "управление на основните данни". сега струва само един ден от времето за проектиране, останалото е въпрос на упорита работа и зависи от рутинното кодиране и системните познания на програмиста.

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

Вариантите на структуктограмите са модулни блок-схеми и псевдокод. Те се основават на една и съща идея за структуриране, но са показани на илюстрацията. различни и понякога като единия, понякога другия повече.