Зачем нужны блок-схемы?

Приходилось слышать мнение, что блок-схемы строятся по программному коду для каких-либо целей, например, объяснения алгоритма работы программы заказчику.

А по-моему, блок-схема - это первый шаг на пути разработки программы, помогающий получить начальное представление о том, какой будет программа. Далее схема уточняется написанием псевдо-кода, по которому уже пишется программный код.

Какое ваше мнение?

1

Да, к стати. Я не рисую блок-схемы на бумажке. У меня для этого есть специальный стенд с магнитными фигурками.

Миниатюры

 

0

Чуть не забыл. Ещё два магнитных датчика положения иглы. Итого 9 датчиков.

0

Для станка блок-схема будет выглядеть несколько иначе - она в более крупную клетку, чем блок-схемы, о которых идёт речь в данной теме. К тому же для нормального понимания блок-схемы любого вида абсолютно побоку, квадратом, обозначен элемент схемы, овалом, треугольником или чем-то ещё. В то время как в блок-схемах из данной темы, насколько я знаю, есть строгие требования о том, какой элемент какой фигурой надо рисовать

0

Сообщение от SmittWesson Попробуйте без блок-схемы создать алгоритм работы вот этого станка.

Не вижу никаких проблем.
И не вижу большой разницы, в каком виде записан алгоритм работы.

0

Разница есть в том, насколько быстро и по простому читатель поймёт принцип работы. Можно вообще на китайском языке написать (иероглифами), принципиальной разницы нет, но понимать это будет намного сложнее (больше времени уйдёт на вникание)

0

Поэтому внешний вид должен зависеть от решаемой задачи, а не сводиться к стандартному языку блок-схем. Для каких-то задач это может быть таблица, для каких-то простой список действий/требований по пунктам, а для каких-то, может быть, и схема со стрелочками.

0

Сообщение от Shamil1 Поэтому внешний вид должен зависеть от решаемой задачи, а не сводиться к стандартному языку блок-схем

А кто-то обратное утверждал?

0

Тема будет бесконечный холивар с весомыми аргументами между большинством “Для сдачи зачетов в универе” и другими. Для посещаемости хороша т.к. тема знакома от школьника до кодера с 20 летним стажем… поэтому ее не закроют =).

0

Блок-схемы нужны только в том случае, если программа пишется на ассемблере. Что касается языка высокого уровня, то здесь блок-схемы абсолютно не нужны. Говорят, что программу, написанную на блок-схеме, можно написать на разных языках. Тогда представим, что алгоритм использует стандартную функцию какого-то языка программирования, которая также есть в других языках, но по другому называется, и, возможно, немного по-другому используется. Ярким примером является функция, которая возвращает случайное число. В разных языках она записывается по-разному - rand(), random(), mt_rand(), Math.random(), а в некоторых вообще нужно создавать объект класса Random. Вопрос: как это реализовать в блок-схеме? Мне в голову приходит только или словестное описание в блоке, или использование названия функции одного из языков, но опять же, программист, который пишет код по блок-схеме, может не знать языка, с которого названия этой функции было взято, а если и догадается по названию, то может не знать, какое именно случайное число получает эта программа: от 0 до 1, от 0 до 65536 и т.д. Как по мне, для универсальности описания алгоритма лучше использовать какой-то из существующих языков программирования, например C++, и чтоб он был стандартом (но это не точно).
Еще момент, если в моем коде присутствует такая строчка:
то как это будет описано в блок-схеме? Нужно ли для каждого условия писать отдельный ромбик, или можно все условия написать в одном ромбике, и где будет вызыватся функция - в ромбике или другом блоке (в последнем случае еще придется ввести дополнительную переменную)? Если все писать в одном ромбике, то все просто не поместиться в один ромбик, а если писать в нескольких блоках, то это приведет к избыточности.
Что касается наглядности, то программный код является более наглядными, чем блок-схемы, так как в программе не только четко видно, что за чем идет, но еще и то, что находиться в условном блоке, цикле (конечно же при наличии отступов), чего не скажешь про блок-схемы, так как там, посмотрев на отдельный блок, нельзя сразу ответить на вопрос, находиться ли он, например, в условном операторе, а в программном коде достаточно пролистать вверх, и посмотреть, где начинается отступ, независимо от количества строк в условном операторе.
Это далеко не единственные нюансы блок-схем.

0

Из воспоминаний советского программиста. Надеюсь, что прочитают мои оппоненты. Давным давно, еще в докомпьютерную эру (с двадцатых годов) применялись для изображения последовательных процессов или алгоритмов блок-схемы (flowcharts). На них отдельные элементарные (на данном уровне абстракции) шаги изображались прямоугольничками, последовательность шагов – стрелочками, а ветвления (проверки условий) ромбиками. В самом-самом начале, когда языков программирования еще не было, а программы непосредственно кодировались числовыми кодами или, в лучшем случае, писались в «содержательных обозначениях», как рекомендовал патриарх нашего ремесла Александр Львович Брудно, блок-схемы были важным подспорьем. В таковом качестве во время оно их и застандартизировали.
Прошли десятилетия, то есть минули целые эпохи. А от программистов по-прежнему требовали чертить эти чертовы стрелочки и ромбики. Смысла в этом было аж никакого. Во-первых, теоретически доказано, что любой алгоритм, записанный на языке высокого уровня (на любом языке) имеет эквивалентное графическое представление в виде блок-схемы и почти наоборот, любая правильная блок-схема (фишка тут в слове «правильная») эквивалентна некоторому тексту на том или ином языке программирования. Но текст программы завсегда лучше блок-схемы, хотя бы потому, что последней можно только любоваться, а первый – это реальный кусок программы, который компилируется и выполняется на машине. Есть разница? Во-вторых, блок схема может показать только синхронный, строго последовательный процесс вычислений, а в жизни такое наблюдается разве что в небольших несложных программах. Реальные же системы – это не однопоточные алгоритмы, а целые искусственные миры, где множество населяющих их объектов-персонажей (как программных, так и аппаратных) взаимодействуют друг с другом, посылая в непредсказуемые моменты времени сигналы и возбуждая прерывания, и где множество потоков вычислений исполняются одновременно и ассинхронно, порой еще и на множестве процессоров и машин. Получается, что блок-схемами можно проиллюстрировать только маленькие кирпичики, но никак не всю систему, но зачем дополнительно иллюстрировать то, что и так внятно и понятно (с комментариями) записывается в текстовом виде?
Казалось бы, не нужны, так не пользуйтесь. А действительно не нужны – любой программист, хоть разработчик, хоть представитель заказчика предпочтет посмотреть исходный текст программы, а не эти картинки. Непрограммисту они – тем более до лампочки. И только ГОСТу, в лице его полномочного представителя – нормоконтролера, они нужны. Дороги как произведения изобразительного искусства. Он их проверяет на соответствие требованием оформления – такая-то ширина линий, столько-то миллиметров длина стрелочки, такой-то отступ квадратика от ромбика... Смысл схемы контролеру совершенно недоступен. Можете себе представить, какая халтура там процветала? В нашей конторе (как и в сотнях и тысячах таких же контор по всему Союзу) сидели тетки-чертежницы и тушью на кальках рисовали никому не нужные стрелочки и ромбики. Зато безработицы не было! Уже Союз загибался, но в девяностом году, если не ошибаюсь, успели под занавес выпустить новый ГОСТ все на ту же тему рисования блок-схем. Какая-то навязчивая, неотвратимая мания. Ну да ладно...

5

По личному опыту на языках высокого уровня думаешь над алгоритмом сразу в терминах языка. Блок схемы рисовал, со всеми ромбиками и прочими прибамбахами если нужно было объяснить что там делается или не специалисту, или просто человеку с каким другим языком. Кстати, в реальной программе почти все делается не через IF, а через циклы. На блок схемах циклы только запутывают разумное объяснение. Рисовал ромбики.
Для Assembler-а блоки полезны, но не доводилось сочинять столь сложных модулей Assembler-а.
Всегда Ваш - Etien

Добавлено через 28 минут
В реальном времени блоки иногда помогают. Там легко проставить временную последовательность и необходимые задержки.
Всегда Ваш - Etien

1

Если изображать цикл на блок-схеме по ГОСТ-у, там вообще нет никакой понятности для начинающего, с большим трудом можно найти пример для цикла с постусловием, у которого постусловие в блоке условия расположено так, как и любят его располагать на блок-схеме с использованием, так называемого, блока условия. Цикла с предусловием с использованием блока условия вообще нет в примерах в ГОСТ-е, как и нет примера изображения цикла с параметром. Все это, по-видимому, придумано позже, внезависимости от ГОСТ-а (или ГОСТ сделан весьма халтурно). Но это придумывание разумно, именно из-за этого придумывания появились программы переводящие элементы блок-схемы в программный код (примеры редкие, видел программу под DOS, ну и современную AFCE) Именно из-за этого придумывания появились программы составляющие блок-схему по коду (как мне кажется, это менее практично чем первое). Вы говорите на начальном этапе полезна для освоения языка блок-схема, согласен. Но мало кто вообще объясняя блок-схемы ученикам(не по ГОСТу, а в том виде, как это общепринято) и делает акцент на то, что это графический способ изображения алгоритмов, между прочим более близкий к языку программирования, чем просто описания алгоритма по пунктам, правда при этом весьма громоздкий. Мои студенты, которым преподаю технологию программирования, и которым явно давали блоку-схемы явно не понимали, что блок-схема это тоже алгоритм, по которому можно написать программу. Первые задания у них были весьма простые, но они начали с написания программы, и продолжили с постановкой задачи и составлением блок-схемы. Я от них, конечно, требовал выполнить задание в другой последовательности. Получилось, что они могут написать программу, но не могут нормально написать постановку задачи (определить входные и другие переменные, написать формулы для вычислений и др.), а блок-схемы у них, в большинстве случаев были сами по себе, а программный код сам по себе, код не вязался с блок-схемой. За исключением того, когда блок-схема была составлена автоматически, по коду. При этом они не понимали, что задача наших блок-схем показать именно алгоритм, они не понимали, зачем я настаиваю на том, что-бы удалить блок описания переменных. Попались студенты которые вообще не понимали почему элементы блок-схемы имеют различную форму. Когда я им показал, что в программа AFCE при установке элемента сразу прописывается соответствующий код, до них наконец дошло, что элементы блок-схемы и операторы близки по смыслу.

0

Блок схемы нужны когда надо показать самую общую логику работы или протокол.
На самом начальном этапе обучения программированию нужны до тех пор пока обучаемый не научился представлять циклы в уме.
А больше нигде не нужны.

Сообщение от tvitaly1 Если изображать цикл на блок-схеме по ГОСТ-у

Ну, ГОСТ он для документации, а учить всегда надо как будет понятнее обучаемому, не глядя на ГОСТ, который не для этого создавался.

А вообще где-то на просторах Интернета есть более продвинутые блок-схемы под названием языка Дракон. Автор только у этого языка очень смешной. Пытается куда-нибудь свой Дракон пристроить и что-нибудь с этого поиметь. И реально считает его новым словом в программировании, но это видимо уже старческий маразм пошел. Хотя если смотреть на Дракон как на более богатые по выразительным возможностям блок-схемы, то он вполне так ничего.

0

блок-схемы были нужны в языках из 70х годов типа раннего диалекта Бейсика, Фокала, Кобола.
Ну знаете, когда программа обязана была писаться с нумерацией строчек метками перехода и GOTO между ними были обычным явлением.
ну и как в таком коде без предварительного рисунка со стрелочками?

Но стоп, если мы программируем в структурном стиле. Один вход - один выход, все вложенные условия и циклы написаны через отступ, ни одной метки перехода и.т.д. Зачем же нам рисовать стрелочки поверх кода?

А потом прошло время и преподы совершенно забыли, а зачем они вообще блок-схемы рисовали в юности в первую очередь. И стали их требовать "шоб було"

1

0

Сообщение от Kuzia domovenok перехода и GOTO между ними были обычным явлением. ..... ни одной метки перехода и.т.д.....

Современные языки программирования позволяют обходится без перехода на метку, тем не менее, переходы в алгоритме имеются, например,
оператор условия в неполной форме, - мы либо выполняем часть операторов по условию, либо пропускаем(обходим, переходим на строку за телом оператора условия в неполной форме) их,
оператор условия в полной форме, - мы либо выполняем часть операторов по условию, а часть других обходим, либо обходим операторы для который условие выполнение ложно, и выполняем другие операторы, для которых логическое отрицания условия истинно.
Оператор выбора, тут вообще переход осуществляется на подобие меток, в которых указывается условие перехода.
Оператор цикла с постусловием, мы можем возвратится к началу тела цикла в котором находится группа операторов для повторения, либо продолжить программу.
Так что не надо ля-ля о том, что переходов(стрелочек переходов и т.п.) в современной программе нет.

0

Сообщение от tvitaly1 Так что не надо ля-ля о том, что переходов(стрелочек переходов и т.п.) в современной программе нет.

Вы цитируете "ни одной метки перехода", а отвечаете на придуманное Вами же "ни одного перехода".

0

Увы, вы ничего не поняли из того, что я объяснял. Я и не говорил про метки перехода, я говорил, что часть алгоритма (часть операторов) мы пропускаем на определенных операторах при определенных условиях, а фактически переходим в иную точку программы, или строку. Может по рисунку будет понятней. На операторе условия в полной форме может возникнуть одна из двух ситуаций, представленная на картинки.

Миниатюры

 

0

Сообщение от tvitaly1 Так что не надо ля-ля о том, что переходов(стрелочек переходов и т.п.) в современной программе нет.

Ключевое слово в структурном стиле
в современной программе нет бызымянных недокументированных переходов вникуда на метку в клиническом случае вне пределов одного блока текста.
GOTO нарушает все какие только возможно заповеди хорошего структурного программирования и без блок-схемы в программах с ними действительно невозможно разобраться.
И напротив, красиво вложенные друг в друга блоки циклов и условий, с отступами, не слишком большой величины - просто лишают блок-схемы всякого смысла. Ты и так от одного взгляда на код будешь видеть все эти "БЛОКИ" у себя в голове.

0

Сообщение от tvitaly1 Я и не говорил про метки перехода, я говорил, что часть алгоритма (часть операторов) мы пропускаем

Зачем же тогда цитировали про метки перехода? Вам надо было цитировать вот это:

Сообщение от Kuzia domovenok Один вход - один выход, все вложенные условия и циклы написаны через отступ, ни одной метки перехода и.т.д. Зачем же нам рисовать стрелочки поверх кода?

0