Дизајнот и тестот не можат да бидат извршени од кој било генератор. Најлесен начин е преку
ШТАНБАХ (је) - „Верувам дека споредбата на различните техники при дизајнирањето на програмите не е одлучувачка“, пишува Волкер Елстерман и го оправдува тоа со фактот дека техниките на блок-дијаграмот, структурираниот дијаграм и псевдокодот постојано биле засновани на идејата за модуларна структура и Пристапот да биде ист. Елстерман, автор на статијата „Како научив да сакам структурирани дијаграми“ во CW бр. 30 јули 25, се занимава со одговорот даден од Јирген Евалд под наслов „Круната се должи на модуларното програмирање“ во CW бр. 34 беше објавен на 22 август. (Во меѓувреме, групата дискутанти е проширена за да го вклучи Херман Ланге. Погледнете ја статијата „Не создавајте го модулот произволно“ во ова издание.)
Во однос на Евалд, кој е член на универзитетот, Елстерман вели дека „веројатно повторно ќе стане јасно дека теоријата и практиката/апликацијата имаат сосема различни проблеми“. За практичарите - така Елстерман - тоа е помалку за самите дијаграми и нивната форма, но повеќе за применливоста, ученоста и успехот.
Потоа Елстерман накратко ги објаснува алтернативните техники:
Програмата се развива команда по команда со блок-дијаграмот.Ова е во спротивност со сите барања на добро структурирана и пријателска програма за одржување. Но, по долг период на вежбање, секој програмер автоматски доаѓа до блок-дијаграм кој е многу сличен на дијаграмот за модуларен проток. (Видете мод. План од Јирген Евалд во CW од 22 август)
Како што може да се види од споредбата „Структурен дијаграм: модуларен распоред“ во CW од 22 август, двата дијаграма се подеднакво значајни. Структураграмот нуди повеќе простор за текст од една страна.
Понатамошен развој на структурограмите е псевдокод. (Исто така евидентно од споредбата во CW од 22 август 1980 година.) Во случај на псевдокод, лентите во структурграмот едноставно се заменуваат со стандардизирани кодови.
Елстерман понатаму: Техниките за развој се поддржани од алатки и генератори како што се „Пет“ и „Делта“. Сепак, тие само го олеснуваат рачниот напор на документирање. Вистинскиот проблем е како да се најде патот од блок-дијаграмот до структурираната програма. Особено сум загрижен за програмерите за практична примена кои треба да развиваат програми секој ден. Најлесен начин е преку структураграмите. Ниту една алатка не може правилно да ја претстави логиката на програмата. Одлучувачкиот чекор на дизајнот на програмата се изведува на бирото со хартија и молив:
- Скицирајте го структурограмот,
Според мое мислење, нема подобро средство за репрезентација од структураграмот за да се провери логиката на програмата пред да кодирате. Еве еден пример: (Ниту еден генератор нема да ја обвини логиката.)
Тестот на овој структураграм се состои од проверка на блок од структура по блок на структура и тест прашања во врска со:
- Од каде потекнуваат податоците?
- Каде одат податоците?
- Како се преместуваат податоците?
- Дали е дозволен трансферот?
Со овие прашања се наоѓа: ако се прочита следниов запис, тој ја пребришува областа на главниот запис-1. (Ова е многу честа грешка кај почетниците.) Сега може да се изврши следната исправка:
Искуството покажа дека програмите дизајнирани и тестирани на овој начин содржат само грешки направени во кодирањето и лесно може да се најдат во машинскиот тест.
Програма „господар за управување со податоци“. сега чини само еден ден од времето на дизајнирање, остатокот е прашање на напорна работа и зависи од рутината за кодирање и системското знаење на програмерот.
Најлесен начин до структурираното програмирање е преку структурограмите. Рачно изготвување и тестирање на работната маса не може да го направи кој било генератор. Сепак, тие можат да ја поедностават документацијата и одржувањето на дијаграмите.
Варијанти на структураграмите се модуларни графикони на проток и псевдокод. Тие се засноваат на истата идеја за структурирање, но се прикажани на илустрацијата. различни и некогаш како едниот, некогаш другиот повеќе.