Дмитрий_ВБ писал(а):
...
Я подозреваю, что человеку, не способному записать алгоритм
псевдокодом вида:
Код:
ПРОЦЕДУРА
ДАННЫЕ: ...
НАЧАЛО
* ...
* цикл ...
* если (...)
* ...
* иначе если (...)
* ...
* иначе
* ...
* если (...) выход из цикла
* ...
* конец
* конец цикла
* ...
КОНЕЦ
и визулизация не поможет.
...
Это да... "разнорукость представлений одного и того же смысла" нужна... и изучение форм как переводимых друг в друга (на что, скажем, Ермаков внимание обращает), должно помогать...
С этим связано и следующее:
Сергей Прохоренко писал(а):
...
Отсюда я делаю вывод, что Дракон - это модификация блок-схем для изображения цикла Дейкстры. И в этом качестве Дракон неплох. Правда, с развитием языков программирования век блок-схем уже ушел. Но, чтобы объяснить студентам цикл Дейкстры, Дракон можно использовать.
Блок-схем, которые: а) "анархичны"; и б) графово представляют только императивную часть отчуждаемого знания - да, ушёл... и оно к лучшему...
Техноязык снимает анархию - и потому м.б. использован в составе формально-графической нотации для программно-строгого описания. Наряду с нотациями для неимперативных частей - о которых и Вы для своего проекта справедливо говорите - те же схемы зависимости компонентов. И Ермаков:
viewtopic.php?p=68824#p68824.
Также "разнорукость" необходима и в пределах любой формы - на уровне уже над-синтаксического. Тут в тему и о цикле Дейкстры - это не частность, а общность (паттерн "универсальной программы"). И потому через него м.б. представлен тот же дракон-силуэт - конечно же, со введением переменной состояния процесса (ведь упомянутую
здесь работу /Дейкстра, 1966/ и теорему Бёма-Джакопини вроде никто не отменял
)... Как - уже показывал "тривиальной теоремой о переписываемости спагетти-кода по Дейкстре" ((С) Info21).
Смысл той же работы Дейкстры показывает и путь обратного перехода - выделить Дейкстра-состояния для ЦД-ветвей, объявить их "силуэтно-шапочными"... и снова ввести "лишнюю" (относительно исходного представления) мета-переменную этого состояния. И обеспечить внутри веток "спагетти-переписанного (но при этом - частично-силуэтно-упорядоченного) Дейкстра-кода по ДРАКОНу" выбор по этому мета-состоянию (за счёт развилок с заземлением побочных выходов).
Ну и закономерный вопрос - если что так, что так "левой пяткой правое ухо чешем" - то при каких условиях нужен такой переход? Корректный ответ снова подсказывают размышления Сергея, TAU - и вывод из работы Дейкстры, процитированный у Шалыто. А именно:
Еще в 1966 г. Э. Дейкстра (Дейкстра Э. Взаимодействие последовательных процессов
/Языки программирования. М.: Мир, 1972, с. 9 – 86) предложил ввести так называемые переменные состояния, с помощью которых можно описывать состояния системы в любой момент времени, и использовал для этих целей целочисленные переменные. При этом им был поставлен вопрос о том, какие состояния должны вводиться, как много значений
должны иметь переменные состояния, и что эти значения должны означать? Он предложил сначала определять набор подходящих состояний, а лишь затем строить программу. Он также предложил сопоставлять процессы с переменными состояния и связывать процессы через эти переменные. По мнению Э. Дейкстры, диаграммы состояний
могут оказаться мощным средством для проверки программ. Все это обеспечивает поддержку его идеи, состоящей в том, что программы должны быть с самого начала составлены правильно, а не отлаживаться до тех пор, пока они не станут правильными.
...
Сергей Прохоренко писал(а):
3. Закрепляет вредные навыки у студентов. Дракон содержит в себе как важнейшую составную часть неструктурированные переходы (аналог GOTO), от которых всеми силами пытаются избавиться разработчики языков программирования и серьезные программисты. Правда, при автоматической генерации кода по Дракон-схеме это безопасно, но учить этому студентов для (в дальнейшем) программирования на других языках программирования - нехорошо
1. Навыки визуального программирования не могут быть вредными, за визуальным программированием - будущее.
2. ГРАФИТ - методология СТРУКТУРНОГО графического программирования, вставляются сразу законченные блоки БЕЗ возможности произвольной передачи управления в общем случае.
3. От GOTO настоящие высокопрофессиональные программисты никогда не пытались "всеми силами избавиться"
Настоящие профессионалы всегда писали о случаях, в которых применение GOTO оправданно.
Тут что важно? Что сформулированы ограничения:
1. Сергей фактически указал на "случаи применения goto" - автогенерация кода по графической модели. Что при ограничении такой модели только потоком управления удообно, если "родной язык" исполнителя - Ассемблер для архитектуры фон Неймана. И то внеимперативные средства, заложенные во ФЛОКС, не помешают.
2. Требование атомарности структуры управления. Это опять же есть и у Сергея - только он предлагает сохранить текстовую запись (расширенную знаками-организаторами структуры - многострочными скобками) и ввести адекватные этому управители детализации типа линуксовых "поворотных треугольников". Причём TAU дополнительно ограничивает явным запретом неструктурности и внутри атомарных конструкций ("БЕЗ возможности..."). О том же говорил и здесь:
...
Так что же общего у "дополнительных" (
в терминах Дмитрия_ВБ, вводимых им в обсуждаемом определении ДАЛВЯЗ - В.Ж.) структур? В понятиях шампур-метода - то, что их нельзя вывести вложением. Т.е. они неатомарны смысле сказанного здесь:
viewtopic.php?p=71937#p71937.
Но атомы сами м.б. неструктурны (хотя в авторском техноязыке таких нет - но нет и ШМ-ограничений на их "придумывание"). Так что естественным допограничением служит условие, чтобы атомы представляли только конструкции Дейкстры, описанные
здесь.
...
3. Идея Дейкстры о "составлении программ изначально правильными" разобрана наглядно (в меру логико-математической культуры читателя, конечно
) у Кауфмана в
Гл.2 второй части.
И она ограничивает нас в выборе "нестрого атомарных" структур по признаку "кризисности" предметки (в терминах Г.Р. Громова):
...
Конечно, наиболее тщательно нужно к этому относиться, когда предметная область является, как говорит Г.Р. Громов "кризисной", т.е.
... <при автоматизации "некризисных" рабочих мест> отношение числа успешных срабатываний к "отказам" оказывается лишь текущим показателем достигнутого выигрыша в росте производительности труда. Принципиально иная ситуация складывается, когда «отказ» связан с возможностью аварийного исхода. "Кризисная область" приложений компьютеров и должна быть поэтому основным объектом так называемого "доказательного" программирования.
...
Предметно можно показать на примере, который используют те же Поликарпова и Шалыто в своей книге - на программных часах-будильнике. Как создавать программу их работы?
Прежде всего заметим - создавать для конкретной парадигмы программирования и представления об исполнителе ("спецификации структуры" в терминах их работы). Т.е. ненимперативные сставляющие непренебрежимы. Далее - создавать вместе с руководством пользователя (вытекающим из нормальной постановки задачи как целого - с последующим выделением "машинной" части). Сие ни от формы записи, ни от реализующих структур ещё не зависит. Только от технологической дисциплины разработки...
А вот дальше вопрос - "сразу правильно" или "из общих слов"? И тут надо вспомнить - для чего предназначены часы-то?
Если для гражданина пользователя, чтобы ему более-менее вовремя вставать в свой законный выходной да не опоздать после работы на развлечения - то всё равно.
Если же чтобы показывать время на пульте системы, от которой мало-мальски жизнь/здоровье/благосостояние людей/природы зависит - то тут выбор может только перед "варваром" по Зелинскому ("гоблином" по Голубицкому с поправками отсюда: viewtopic.php?p=71257#p71257) стоять... Для адекватного гражданина сочинителя (ну или хотя бы опасающегося последствий, указанных Голубицким ) нет вопроса - "сразу правильно".
То же и для случая, когда от пользования часами как-то косвенно будет зависеть эффективность/надёжность пользователя в "кризисных" делах. Скажем, если употреблять часы дома, но чтобы вставать на серьёзную работу... или уже в личной жизни - чтобы не опоздать на свидание...
Короче - не нужен переход. Нужно сразу работать либо в неатомарном представлении структур управления (применительно к графической форме - допускающем многоадресный силуэт и пересадки, дающие goto), либо в атомарном. Второе однозначно требуется для "кризисных задач".
Притом это не отменяет утверждения, что "за визуальным программированием будущее" - только в единстве и взаимосвязи с текстовым... В котором всё то же самое "атомарное-неатомарное" м.б. выделено... только пишется иначе...