Владимир Паронджанов писал(а):
Rifat писал(а):
В презентации увидел и свой комментарий, что довольно таки лестно, как будто бы цитата известного деятеля.
Со страницы 95 приводятся несколько слайдов, где, как я понял, показывается, что всё, что есть в структурном программировании, есть и в Дракон-схемах. Что как бы доказывает, что термин "двумерное структурное" программирование правильный. Но обычное структурное программирование ограничивается тремя управляющими конструкциями, а Дракон-схема не ограничивается. И вот эти излишества уже не делают Дракон-схему похожей на структурные схемы Дейкстры. Если, допустим, к структурным схема Дейкстры добавить всего один небольшой элемент: разрешить произвольные переходы внутри схемы, то это уже будет не структурная схема.
Рифат, термин "Двумерное структурное программирование" применительно к языку ДРАКОН ввели Илья Ермаков и Жигуненко в статье :
Цитата:
ДВУМЕРНОЕ СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ; КЛАСС УСТРЕМЛЁННЫХ ГРАФОВ.
(ТЕОРЕТИЧЕСКИЕ ИЗЫСКАНИЯ ИЗ ОПЫТА ЯЗЫКА «ДРАКОН»)
viewtopic.php?p=76041#p76041Цитата из заметок по структурному программированию Дейкстры.
Цитата:
И для программ совершенно безнадежно пытаться устанавливать правильность тестированием, исключающим малейшие сомнения, если не принимается во внимание структура этих программ. Другими словами, мы отмечаем, что степень возможной уверенности в правильности программы определяется не только внешним описанием программы и режима ее работы, но существенно зависит от ее внутренней структуры.
Возвращаясь к основному предмету наших рассмотрении, т. е. к по-настоящему большим программам, мы заключаем из предыдущего, что их величина сама по себе требует высокого уровня уверенности в отдельных компонентах программы. Если вероятность правильности отдельной компоненты равна р, то вероятность правильности всей программы, состоящей из N таких компонент, равна примерно
P = p^N
Если число N будет очень велико, то значение р должно быть очень и очень близко к 1, если мы хотим, чтобы значение Р существенно отличалось от нуля!
Если теперь принять предпосылку, что задача программиста не только в том, чтобы изготовить правильную программу, но и в том, чтобы убедительно продемонстрировать ее правильность, то приведенные выше соображения существенно влияют на деятельность программиста: его продукция должна иметь удобную структуру.
Последующая часть этой монографии посвящена в основном исследованию того, какая структура программы может оказаться наиболее удобной для применения. В дальнейшем читателю станет ясно, что правильность программ не является единственным предметом моих рассмотрении; я буду заниматься также проблемой приспособляемости, или управляемости программ. Я выделяю проблему управляемости программ преднамеренно и постараюсь обосновать этот выбор.
...
В предыдущем разделе мы высказали утверждение, что программист должен придать своей программе "удобную структуру"; структура программы упоминалась в связи с проблемой убедительной демонстрации правильности программы.
Но как же мы убеждаем? И как мы убеждаемся? Как мы достигаем понимания? Общему обсуждению именно таких вопросов посвящен этот раздел. Я приношу самые искренние извинения профессиональным психологам, поскольку мои рассуждения будут совершенно дилетантскими. Однако я надеюсь (и верю), что они помогут нам обрести критерий для оценки полезности предлагаемой структурной организации.
Среди интеллектуальных средств, которые применяются для понимания программы (или для доказательства ее правильности), я хотел бы четко выделить следующие три:
(1) перечисление;
(2) математическая индукция;
(3) абстракция.
В статье Илья Ермаков и Жигуненко есть несколько фактических ошибок относительно истории структурного программирования. Самое понятие структурного программирования рассматривается очень упрощенно. (Дейкстра писал "Apparently, IBM did not like the popularity of my text; it stole the term "Structured Programming" and under its auspices Harlan D. Mills
trivialized the original concept to the abolishment of the goto statement.") Сам же Дейкстра выводит структуру программы из интеллектуальных средств, которые есть для доказательства корректности программы. Он считал, что программист должен не только написать (правильную) программу, но и обосновать ее правильность.
В статье же, где упоминается про "двумерное структурное программирование" нет этих обоснований. По сути происходит подмена понятия.