Комментарии 5
Рассмотрим неструктурную программу на рис. 1 слева.
Добрый день. Можете объяснить, почему Вы считаете показанную схему - неструктурной программой? По мне - очень даже структурная. Только отсутствие доп. нумерации? Хотел Ваше мнение услышать.
Спасибо за вопрос. Ответ на рисунке.
На схеме 1 показана структурная программа. Рассмотрим желтый блок Z. В этот блок можно вложить структурную программу
do X while C, как показано на схеме 2. При этом схема 2 тоже будет структурной программой.
Но. Если острие горизонтальной стрелки над блоком Х оторвать и пересадить на вход блока А, мы получим уже неструктурную программу как показано на схеме 3.
Структурное программирование — парадигма программирования, в основе которой лежит представление программы в виде иерархической структуры блоков. Концептуализирована в конце 1960-х — начале 1970-х годов на фундаменте теоремы Бёма — Якопини, математически обосновывающей возможность структурной организации программ, и работы Эдсгера Дейкстры «О вреде оператора goto» (Goto considered harmful).
В соответствии с парадигмой, любая программа является структурной, если она строится без использования оператора goto, состоит из трёх базовых управляющих конструкций: последовательность, ветвление, цикл и операции вложения.
Спасибо за ответ. Мне не совсем понятно. Вы обращаете внимание на оператор goto. В программировании, особенно в ООП сложно его использование, хотя если по правде сказать - break для выхода из цикла - это тоже для меня своего рода goto. Но я не об этом.
В программировании использование оператора goto можно минимизировать до нуля. Но ведь не в процессах. Там переход "goto" - есть чуть-ли не нормальность. А вы ваш язык позиционируете и как для описания процессов. Ваш пример с поиском счастья тому пример, хотя уверен, что все три состояния имеют право быть одновременно. Те. я могу продолжать искать счастье и дальше, даже путешествуя и при том инвестируя в бизнес. В другой ветке мы с вами разговаривали об одном из ваших медицинских алгоритмов, где был переход в воздух из одной ветке в другую с командой "продолжайте промывать водой", если помните. Это не что иное как отсылка, те. goto.
Критичный подход к использованию goto возник на фоне безрассудного его использования и возникновения спагетти-кода. Но. Ввод дополнительной конструкции для пробега всех состояний как у вас вместо приведенными вами goto в исходной программе чревато тоже ухудшением читаемости, увеличением времени исполнения, повторениями каких-то участков кода или дополнительными вызовами это как функций, если ветки чересчур сложными будут итд. А вызов функции в программировании - это тоже потеря времени исполнения и дополнительные затраты на память.. Я не сторонник goto. Просто комьютер и программирование - есть сложные штуки. Там есть такие конструкции как event, interrupt, delegate, async итд. Конструкции,которые усложняют прямое протекание структуры, но являются неотъемлемой частью решений на современных языках программирования. Те. наличие goto или его отсутствие - не самая сложная проблема. И goto присутствует, только реализован он по-другому.
Я понимаю, что пример абстрактный и это моё личное восприятие, но исходный код мне лучше читается чем тот, который вы вывели без использования goto. И как комментатор ниже соглашусь - то, что вы указали - есть конечный автомат. Но вы это почему-то не упомянули. И примером с поиском счастья привели совсем не конечный автомат.
И последнее, что я не понял. Хотя словами до этого я уже это как-бы упомянул. Вы вели разговор о программировании, переключились в примере на процессы. Я вижу разницу между этими двумя этими областями. Хотя и схожестей конечно-же тоже немало. Но всё-же.
К счастью, с 1961 данное направление продумали сильно глубже . Вместо понятия "имя ветки" используют "состояние", а алгоритм, который ветвится в зависимости от состояния - "автомат состояний" или "конечный автомат".
Действительно, многие алгоритмы намного легче понимаются людьми, если они оформлены в виде конечных автоматов. На этой основе даже развилась целая Switch-технология.
Как выше заметил @Myclass - в статье нет определения "неструктурной программы". Возможно, имелось ввиду "алгоритм не в виде конечного автомата" ? Тогда суть метода Ашкрофта-Манны - это набор правил, как преобразовать любой алгоритм в конечный автомат.
Визуальный язык ДРАКОН: математические истоки алгоритмической макроконструкции «силуэт» и метод Ашкрофта-Манны