Структурное программирование

Перейти к навигацииПерейти к поиску
Парадигмы программирования

Структу́рное программи́рование — парадигма программирования, в основе которой лежит представление программы в виде иерархической структуры блоков. Концептуализирована в конце 1960-х — начале 1970-х годов на фундаменте теоремы Бёма — Якопини, математически обосновывающей возможность структурной организации программ, и работы Эдсгера Дейкстры «О вреде оператора goto» (англ. Goto considered harmful).

В соответствии с парадигмой, любая программа, которая строится без использования оператора goto, состоит из трёх базовых управляющих конструкций: последовательность, ветвление, цикл; кроме того, используются подпрограммы. При этом разработка программы ведётся пошагово, методом «сверху вниз».

Методология структурного программирования появилась как следствие возрастания сложности решаемых на компьютерах задач, и соответственно, усложнения программного обеспечения. В 1970-е годы объёмы и сложность программ достигли такого уровня, что традиционная (неструктурированная) разработка программ перестала удовлетворять потребностям практики. Программы становились слишком сложными, чтобы их можно было нормально сопровождать. Поэтому потребовалась систематизация процесса разработки и структуры программ.

Методология структурной разработки программного обеспечения была признана «самой сильной формализацией 70-х годов».

По мнению Бертрана Мейера, «Революция во взглядах на программирование, начатая Дейкстрой, привела к движению, известному как структурное программирование, которое предложило систематический, рациональный подход к конструированию программ. Структурное программирование стало основой всего, что сделано в методологии программирования, включая и объектное программирование»[1].

История

Первоначально идея структурного программирования появилась на свет в связи с оператором goto и сомнениями в целесообразности его применения. Впервые подобные сомнения высказал Хайнц Земанек (Heinz Zemanek) на совещании по языку Алгол в начале 1959 года в Копенгагене. Однако это выступление не привлекло к себе внимания и не имело последствий. Эдсгер Дейкстра вспоминает: «До некоторой степени я виню себя за то, что в то время не смог оценить значимость этой идеи»[2][3][4].

Ситуация коренным образом изменилась через десять лет, когда в марте 1968 года Дейкстра опубликовал своё знаменитое письмо «Оператор Go To считается вредным» (Go To Statement Considered Harmful). Это поистине исторический документ, оказавший заметное влияние на дальнейшее развитие программирования.

Судьба самого документа очень интересна. Дело в том, что Дейкстра дал статье совсем другое название: «Доводы против оператора GO TO» (A Case against the GO TO Statement).

Однако в момент публикации произошло нечто непонятное — статья почему-то загадочным образом превратилась в «Письмо к редактору», причем прежнее название столь же загадочно исчезло. Что произошло на самом деле? Дейкстра объяснил таинственное превращение статьи в письмо лишь много лет спустя, в 2001 году, за год до смерти.

Журнал Communications of the ACM опубликовал мой текст под названием «Оператор GOTO считается вредным». В последующие годы его часто цитировали. К сожалению, зачастую это делали люди, которые видели в нём не больше, чем сказано в заголовке. Этот заголовок стал краеугольным камнем моей славы…

Как все это случилось? Я отправил статью под названием «Доводы против оператора GO TO». Чтобы ускорить публикацию, редактор превратил мою статью в «Письмо к редактору». При этом он придумал для статьи новое название, которое изобрел сам. Редактором был Никлаус Вирт[5][6].

Цель

Цель структурного программирования — повысить производительность труда программистов, в том числе при разработке больших и сложных программных комплексов, сократить число ошибок, упростить отладку, модификацию и сопровождение программного обеспечения.

Такая цель была поставлена в связи с ростом сложности программ и неспособностью разработчиков и руководителей крупных программных проектов справиться с проблемами, возникшими в 1960—1970 годы в связи с развитием программных средств[7].

Спагетти-код

Основная статья: Спагетти-код

Структурное программирование призвано, в частности, устранить беспорядок и ошибки в программах, вызванные трудностями чтения кода, несистематизированным, неудобным для восприятия и анализа исходным текстом программы. Такой текст нередко характеризуют как «спагетти-код».

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

Спагетти-код назван так потому, что ход выполнения программы похож на миску спагетти, то есть извилистый и запутанный. Иногда называется «кенгуру-код» (kangaroo code) из-за множества инструкций jump.

В настоящее время термин применяется не только к случаям злоупотребления goto, но и к любому «многосвязному» коду, в котором один и тот же небольшой фрагмент исполняется в большом количестве различных ситуаций и выполняет много различных логических функций[8].

Спагетти-код может быть отлажен и работать правильно и с высокой производительностью, но он крайне сложен в сопровождении и развитии[8]. Доработка спагетти-кода для добавления новой функциональности иногда несет значительный потенциал внесения новых ошибок. По этой причине становится практически неизбежным рефакторинг — главное лекарство от спагетти.

Оператор goto

Основная статья: goto

Начиная с 1970-х годов, оператор безусловного перехода goto оказался в центре систематической и всевозрастающей критики. Неправильное и необдуманное использование оператора goto в исходном тексте программы приводит к получению запутанного, неудобочитаемого «спагетти-кода». По тексту такого кода практически невозможно понять порядок исполнения и взаимозависимость фрагментов.

Впервые эта точка зрения была отражена в статье Эдсгера Дейкстры «Оператор Go To считается вредным»[3][9]. Дейкстра заметил, что качество программного кода обратно пропорционально количеству операторов goto в нём. Статья приобрела широкую известность, в результате чего взгляды на использование оператора goto были существенно пересмотрены. В работе «Заметки по структурному программированию»[10] Дейкстра обосновал тот факт, что для кода без goto намного легче проверить формальную корректность.

Код с goto трудно форматировать, так как он может нарушать иерархичность выполнения (парадигму структурного программирования) и потому отступы, призванные отображать структуру программы, не всегда могут быть выставлены правильно. Кроме того, оператор goto мешает оптимизации компиляторами управляющих структур[11].

Некоторые способы применения goto могут создавать проблемы с логикой исполнения программы:

  • Если некоторая переменная инициализируется (получает значение) в одном месте и потом используется далее, то переход в точку после инициализации, но до использования, приведёт к тому, что будет выбрано значение, которое находилось в памяти, выделенной под переменную, до момента выделения (и которое, как правило, является произвольным и случайным).
  • Передача управления внутрь тела цикла приводит к пропуску кода инициализации цикла или первоначальной проверки условия.
  • Аналогично, передача управления внутрь процедуры или функции приводит к пропуску её начальной части, в которой производится инициализация (выделение памяти под локальные переменные).

Доводы против оператора goto оказались столь серьёзными, что в структурном программировании его стали рассматривать как крайне нежелательный. Это нашло отражение при проектировании новых языков программирования. Например, goto запрещён в Java и Ruby. В ряде современных языков он всё же оставлен из соображений эффективности в тех редких случаях, когда применение goto оправданно. Так, goto сохранился в Аде — одном из наиболее продуманных с точки зрения архитектуры языков за всю историю[12].

Однако в языках высокого уровня, где этот оператор сохранился, на его использование, как правило, накладываются жёсткие ограничения, препятствующие использованию наиболее опасных методов его применения: например, запрещается передавать управление извне цикла, процедуры или функции внутрь. Стандарт языка C++ запрещает обход инициализации переменной с помощью goto.

Теорема о структурном программировании

Основная статья: Теорема Бёма — Якопини

Теорему сформулировали и доказали итальянские математики Коррадо Бём и Джузеппе Якопини (Giuseppe Jacopini). Они опубликовали её в 1965 году на итальянском языке и в 1966 году на английском[13]. Наряду с теоремой, в статье Бёма и Якопини описывались методы преобразования неструктурных алгоритмов в структурные на примере созданного Бёмом языка программирования P′′. Язык P′′ — первый полный по Тьюрингу язык программирования без оператора goto.

Теорема Бёма-Якопини написана сложным языком и в непривычных обозначениях. Если использовать современную терминологию и обозначения, она примет вид:

Любая программа, заданная в виде блок-схемы, может быть представлена с помощью трёх управляющих структур:

  • последовательность — обозначается: f THEN g,
  • ветвление — обозначается: IF p THEN f ELSE g,
  • цикл — обозначается: WHILE p DO f,

где f, g — блок-схемы с одним входом и одним выходом,

р — условие,
THEN, IF, ELSE, WHILE, DO — ключевые слова[14].

Пояснение. Формула f THEN g означает следующее: сначала выполняется программа f, затем выполняется программа g.

Как отмечает Харлан Миллс (англ. Harlan Mills), данная теорема резко контрастирует с обычной (в 1960—1970 годы) практикой программирования, когда наблюдалось массовое использование операторов перехода goto[14].

Бём и Якопини не употребляли термин «структурное программирование». Тем не менее, доказанную ими теорему (и её последующие вариации у разных авторов) впоследствии стали называть «теоремой о структурном программировании», «структурной теоремой»[14], «теоремой о структурировании»[15].

Принципы структурного программирования

Становление и развитие структурного программирования связано с именем Эдсгера Дейкстры[10][16].

Принцип 1. Следует отказаться от использования оператора безусловного перехода goto.

Принцип 2. Любая программа строится из трёх базовых управляющих конструкций: последовательность, ветвление, цикл.

  • Последовательность — однократное выполнение операций в том порядке, в котором они записаны в тексте программы.
    Бертран Мейер поясняет: «Последовательное соединение: используйте выход одного элемента как вход к другому, подобно тому, как электронщики соединяют выход сопротивления со входом конденсатора»[17].
  • Ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения заданного условия.
  • Цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется заданное условие (условие продолжения цикла).

Принцип 3. В программе базовые управляющие конструкции могут быть вложены друг в друга произвольным образом. Никаких других средств управления последовательностью выполнения операций не предусматривается.

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

  • В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция «Вызов подпрограммы». При выполнении такой инструкции работает вызванная подпрограмма. После этого продолжается исполнение основной программы, начиная с инструкции, следующей за командой «Вызов подпрограммы».
  • Бертран Мейер поясняет: «Преобразуйте элемент, возможно, с внутренними элементами, в подпрограмму, характеризуемую одним входом и одним выходом в потоке управления»[17].

Принцип 5. Каждую логически законченную группу инструкций следует оформить как блок. Блоки являются основой структурного программирования.

Блок — это логически сгруппированная часть исходного кода, например, набор инструкций, записанных подряд в исходном коде программы. Понятие блок означает, что к блоку инструкций следует обращаться как к единой инструкции. Блоки служат для ограничения области видимости переменных и функций. Блоки могут быть пустыми или вложенными один в другой. Границы блока строго определены. Например, в if-инструкции блок ограничен кодом BEGIN..END (в языке Паскаль) или фигурными скобками {…} (в языке C) или отступами (в языке Питон).

Принцип 6. Все перечисленные конструкции должны иметь один вход и один выход.

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

Принцип 7. Разработка программы ведётся пошагово, методом «сверху вниз» (top-down method)[18].

Метод «сверху вниз»

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

Если говорить точнее, заглушка удовлетворяет требованиям интерфейса заменяемого фрагмента (модуля), но не выполняет его функций или выполняет их частично. Затем заглушки заменяются или дорабатываются до настоящих полнофункциональных фрагментов (модулей) в соответствии с планом программирования. На каждой стадии процесса реализации уже созданная программа должна правильно работать по отношению к более низкому уровню. Полученная программа проверяется и отлаживается[19].

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

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

При сопровождении и внесении изменений в программу выясняется, в какие именно процедуры нужно внести изменения. Они вносятся, не затрагивая части программы, непосредственно не связанные с ними. Это позволяет гарантировать, что при внесении изменений и исправлении ошибок не выйдет из строя какая-то часть программы, находящаяся в данный момент вне зоны внимания программиста[18][20][21][22][23][24].

Следует также учесть, что в «Предисловии» к книге «Структурное программирование»[25] Тони Хоар отмечает, что принципы структурного программирования в равной степени могут применяться при разработке программ как «сверху вниз», так и «снизу вверх»[26].

Подпрограмма

Основная статья: Подпрограмма

Подпрограммы не являлись необходимым условием возможности реализации структурного программирования[27]. Изначально подпрограммы появились как средство оптимизации программ по объёму занимаемой памяти — они позволили не повторять в программе идентичные блоки кода, а описывать их однократно и вызывать по мере необходимости. К настоящему времени[] данная функция подпрограмм стала вспомогательной, главное их назначение — структуризация программы с целью удобства её понимания и сопровождения.

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

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

Достоинства структурного программирования

Следование принципам структурного программирования сделало тексты программ, даже довольно крупных, нормально читаемыми. Серьёзно облегчилось понимание программ, появилась возможность разработки программ в нормальном промышленном режиме, когда программу может без особых затруднений понять не только её автор, но и другие программисты. Это позволило разрабатывать достаточно крупные для того времени программные комплексы силами коллективов разработчиков, и сопровождать эти комплексы в течение многих лет, даже в условиях неизбежных изменений в составе персонала.

  1. Структурное программирование позволяет значительно сократить число вариантов построения программы по одной и той же спецификации, что значительно снижает сложность программы и, что ещё важнее, облегчает понимание её другими разработчиками.
  2. В структурированных программах логически связанные операторы находятся визуально ближе, а слабо связанные — дальше, что позволяет обходиться без блок-схем и других графических форм изображения алгоритмов (по сути, сама программа является собственной блок-схемой).
  3. Сильно упрощается процесс тестирования и отладки структурированных программ.

Ясность и удобочитаемость программ

Структурное программирование значительно повышает ясность и удобочитаемость программ[28]. Эдвард Йордан поясняет:

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

Структурным программам, напротив, свойственна тенденция к последовательным организации и исполнению[29].

Улучшение удобочитаемости структурных программ объясняется тем, что отсутствие оператора goto позволяет читать программу сверху донизу без разрывов, вызванных передачами управления. В итоге можно сразу (одним взглядом) обнаружить условия, необходимые для модификации того или иного фрагмента программы[30].

Двумерное структурное программирование

Основная статья: ДРАКОН § Двумерное структурное программирование

Р-технология производства программ, или «технология двумерного программирования»[31] была создана в Институте кибернетики имени В. М. Глушкова[32]. Графическая система Р-технологии программирования закреплена в стандартах ГОСТ 19.005-85[33], ГОСТ Р ИСО/МЭК 8631—94[34] и международном стандарте ISО 8631Н.

Автор Р-технологии программирования доктор физико-математических наук профессор Игорь Вельбицкий предложил пересмотреть само понятие «структура программы». По его мнению, «структура — понятие многомерное. Поэтому отображение этого понятия с помощью линейных текстов (последовательности операторов) сводит практически на нет преимущества структурного подхода. Огромные ассоциативные возможности зрительного аппарата и аппарата мышления человека используются практически вхолостую — для распознавания структурных образов в виде единообразной последовательности символов»[35].

Методология двумерного структурного программирования существенно отличается от классического одномерного (текстового) структурного программирования[36][37].

Идеи структурного программирования разрабатывались, когда компьютерная графика фактически ещё не существовала и основным инструментом алгоритмиста и программиста был одномерный (линейный или ступенчатый) текст. До появления компьютерной графики методология классического структурного программирования была наилучшим решением[10].

С появлением компьютерной графики ситуация изменилась. Используя выразительные средства графики, появилась возможность видоизменить, развить и дополнить три типа базовых (текстовых) управляющих структурных конструкций, а также полностью отказаться от ключевых слов if, then, else, case, switch, break, while, do, repeat, until, for, foreach, continue, loop, exit, when, last и т. д. и заменить их на управляющую графику, то есть использовать двумерное структурное программирование[33][36].

См. также

Примечания

  1. ↑ Мейер Б. Почувствуй класс. Учимся программировать хорошо с объектами и контрактами. — Пер. с англ. — М.: Национальный открытый университет ИНТУИТ: БИНОМ. Лаборатория знаний, 2011. — 775с. — С. 208. — ISBN 978-5-9963-0573-5
  2. ↑ Э. Дейкстра. Оператор goto считается вредным. Дата обращения: 2 ноября 2014. Архивировано 23 февраля 2007 года.
  3. ↑ 1 2 Dijkstra E. Go To Statement Considered Harmful // Communications of the ACM, Volume 11, No. 3, March 1968, pp. 147—148. — Association for Computing Machinery, Inc. Дата обращения: 3 ноября 2014. Архивировано 2 января 2015 года.
  4. ↑ См. также материалы из Архива Дейкстры. E. W. Dijkstra Archive. The manuscripts of Edsger W. Dijkstra. — Department of Computer Science The University of Texas at Austin Архивная копия от 20 апреля 2005 на Wayback Machine
  5. ↑ Рукопись EWD1308 из Архива Дейкстры. What led to «Notes on Structured Programming» — Nuenen, 10 June 2001. — Department of Computer Sciences. The University of Texas at Austin, USA Архивная копия от 21 марта 2015 на Wayback Machine
  6. ↑ Расшифровка рукописи EWD1308 из Архива Дейкстры. What led to «Notes on Structured Programming» — Nuenen, 10 June 2001. — Department of Computer Sciences. The University of Texas at Austin, USA Архивная копия от 19 ноября 2014 на Wayback Machine
  7. ↑ Лингер Р., Миллс Х., Уитт Б. Теория и практика структурного программирования. — Пер. с англ. — М.: Мир, 1982. — 406с. — С. 7.
  8. ↑ 1 2 3 John Vlissides, Kyle Brown, Gerard Meszaros AntiPatterns: The Survival Guide. Spaghetti code Архивная копия от 27 января 2021 на Wayback Machine.
  9. ↑ Э. Дейкстра. Оператор Go To считается вредным. Дата обращения: 2 ноября 2014. Архивировано 23 февраля 2007 года.
  10. ↑ 1 2 3 Дейкстра Э. Заметки по структурному программированию. // Дал У., Дейкстра Э., Хоор К. Структурное программирование. — М.: Мир, 1975. — С. 7–97.
  11. ↑ Donald Knuth. Structured Programming with go to Statements Архивировано 19 мая 2013 года. 1974
  12. ↑ Code Complete: A Practical Handbook of Software Construction Архивная копия от 2 июня 2017 на Wayback Machine Redmond: Microsoft Press, 1993. 880 p.
  13. ↑ Bohm, Corrado; and Giuseppe Jacopini. Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules (англ.) // Communications of the ACM : journal. — 1966. — May (vol. 9, no. 5). — P. 366—371. — doi:10.1145/355592.365646. Архивировано 5 марта 2016 года.
  14. ↑ 1 2 3 Harlan D. Mills Mathematical Foundations for Structured Programming. — February 1972. — Federal Systems Division. IBM Corporaton. Gaithersburg, Maryland. p. 4. Дата обращения: 10 ноября 2014. Архивировано 10 ноября 2014 года.
  15. ↑ Бутаков Е. А. Методы создания качественного программного обеспечения ЭВМ. — М.: Энергоатомиздат, 1984. — 232с. — С. 114.
  16. ↑ Notes on Structured Programming. By Prof. Dr. Edsger W. Dijkstra — T. H. Report 70-WSK-03 Second Edition April 1970. Дата обращения: 3 ноября 2014. Архивировано 17 марта 2019 года.
  17. ↑ 1 2 3 Мейер Б. Почувствуй класс. Учимся программировать хорошо с объектами и контрактами. — Пер. с англ. — М.: Национальный открытый университет ИНТУИТ: БИНОМ. Лаборатория знаний, 2011. — 775с. — С. 209. — ISBN 978-5-9963-0573-5
  18. ↑ 1 2 Wirth N. Program Development by Stepwise Refinement // Communications of the ACM, Volume 14, No. 4, April 1971, pp. 221—227. — Association for Computing Machinery, Inc.
  19. ↑ Гласс Р. Руководство по надежному программированию. — М.: Финансы и статистика, 1982. — 256с. — С. 84.
  20. ↑ Хьюз Дж., Мичтом Дж. Структурный подход к программированию. — М.: Мир, 1980. — 278c. — С. 29—71. (См. «Глава 2. Нисходящая разработка. Проектирование программы» и «Глава 3. Нисходящая разработка. Планирование и реализация»).
  21. ↑ Вирт Н. Систематическое программирование. Введение. — М.: Мир, 1977. — 184с. — С. 139—168. (См. «Глава 15. Пошаговая разработка программ»).
  22. ↑ Гласс Р. Руководство по надежному программированию. — М.: Финансы и статистика, 1982. — 256с. — С. 83-87. (См. Раздел «3.3.1. Программирование сверху вниз и снизу вверх»).
  23. ↑ Лингер Р., Миллс Х., Уитт Б. Теория и практика структурного программирования. — М.: Мир, 1982. — 406с. — С. 324—327. (См. Раздел «7.3.3. Структурное программирование по нисходящему принципу» и «Раздел 7.3.4. Программирование с использованием принципа пошаговой реорганизации»).
  24. ↑ Иванова Г. С., Ничушкина Т. Н. Проектирование программного обеспечения. Учебное пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ. — М.: Московский государственный технический университет им. Н. Э. Баумана. Факультет Информатики и систем управления, 2002. — 74с. — С. 28-31. Дата обращения: 4 ноября 2014. Архивировано 2 декабря 2014 года.
  25. ↑ Дал У., Дейкстра Э., Хоор К. Структурное программирование. — М.: Мир, 1975. — 247c.
  26. ↑ Хоор К. Предисловие. // Дал У., Дейкстра Э., Хоор К. — М.: Мир, 1975. — 247c. — С. 6.
  27. ↑ Авачева Т. Г., Пруцков А. В. Современный взгляд на концепцию структурного программирования (рус.) // Cloud of Science : Журнал. — 2019. — Т. 6, № 4. — С. 646–665. Архивировано 7 ноября 2019 года.
  28. ↑ Йодан Э. Структурное проектирование и конструирование программ. — Пер. с англ. — М.: Мир, 1979. — 415с. — С. 174.
  29. ↑ Йодан Э. Структурное проектирование и конструирование программ. — Пер. с англ. — М.: Мир, 1979. — 415с. — С. 174, 175.
  30. ↑ Йодан Э. Структурное проектирование и конструирование программ. — Пер. с англ. — М.: Мир, 1979. — 415с. — С. 175.
  31. ↑ Вельбицкий И. В., Ходаковский В. Н., Шолмов Л. И. Технологический комплекс производства программ на машинах ЕС ЭВМ и БЭСМ-6. — М.: Статистика, 1980. — 263с. — С. 5.
  32. ↑ Стогний А. А. Предисловие. // Вельбицкий И. В., Ходаковский В. Н., Шолмов Л. И. Технологический комплекс производства программ на машинах ЕС ЭВМ и БЭСМ-6. — М.: Статистика, 1980. — 263с. — С. 3.
  33. ↑ 1 2 Межгосударственный стандарт ГОСТ 19.005-85. Единая система программной документации. Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения. Unified system for program documentation. R-charts. Graphical chart symbols and conventions for charting. 1985.
  34. ↑ ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления. Information technology. Program constructs and conventions for their representation. Госстандарт России. — Издательство стандартов, 1995. Дата обращения: 30 октября 2014. Архивировано 30 октября 2014 года.
  35. ↑ Знакомьтесь, Р-технология // НТР: проблемы и решения. — 1987, № 13, 7-20 июля. — С. 4, 5.
  36. ↑ 1 2 Ермаков И. Е., Жигуненко Н. А. Двумерное структурное программирование; класс устремлённых графов. (Теоретические изыскания из опыта языка «ДРАКОН»). — М.: МГУ им. М. В. Ломоносова, 2010. — С. 452—461. — (Сборник трудов V Международной конференции «Инновационные информационно-педагогические технологии в системе ИТ-образования»). (недоступная ссылка)
  37. ↑ Шамардина Е. И., Манюнин П. А. Язык алгоритмических чертежей «ДРАКОН», его математическая модель и редактор // Новые информационные технологии. Тезисы докладов XVII Международной студенческой конференции-школы-семинара. — М.: МИЭМ, 2009. — 399с. — С. 279, 280. — ISBN 978-5-94506-223-8. Дата обращения: 30 октября 2014. Архивировано 20 мая 2012 года.