DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 15:11

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 79 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 15 Июнь, 2019 06:40 

Зарегистрирован: Понедельник, 10 Июнь, 2019 00:35
Сообщения: 10
Степан Митькин писал(а):
RDF-представление или другое логическое описание ДРАКОН-схем трудно написать, а ещё труднее прочитать.

Хочу отметить что RDF-представления (их много разных) никоим образом не претендуют на способ представления Д-диаграмм для пользователя.
Эту задачу нужно оставить Д-конструктору или просто картинку дать посмотреть. RDF-представление это стандартизированный способ записи графа. Преимущество по сравнению с другими подобными представлениями типа JSON - наличие SPARQL и SHACL и много еще другого.

RDF-представлениe Turtle легче читать как текст чем скажем XML. Но все равно Дракон-диаграмма лучше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Июнь, 2019 09:25 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Степан Митькин писал(а):
Пример.
Следует ли данная схема правилам языка ДРАКОН?
Я не знаю.
Изображение
Рассмотрим нижнюю часть схемы Степана Митькина.

Это сложный случай: он в моих книгах не описан. Следует его обсудить.

Я начну с похожего, но более простого случая.
Назовем его "Устранение двойной стрелки без пересадки лианы" (УДС).

Случай УДС строго определен согласно правилам языка ДРАКОН и описан в моих книгах.

Понятия "Макроикона" и "Валентная точка", а также действия с ними строго определены.

Вот последовательность действий, позволяющая построить дракон-схему типа УДС.
Черный кружок — это валентная точка.

Вложение:
Для Митькина  Цикл со стрелкой.png
Для Митькина Цикл со стрелкой.png [ 59.33 КБ | Просмотров: 7771 ]


В моем примере (типа УДС) двойная стрелка цикла превратилась в единственную стрелку без использования операции "Пересадка лианы".

Но в примере Степана Митькина такой прием не работает.
В примере Митькина требуется пересадка лианы в точку, совпадающую со стрелкой цикла.

У меня такая операция вызывает большие сомнения.
Я боюсь, что она может провоцировать ошибки.
Поэтому ее следует запретить.

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

Кроме того, нельзя превращать лиану в стрелку цикла.

Разрешается создавать стрелку цикла только и исключительно с помощью макроиконы "Цикл со стрелкой".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 16 Июнь, 2019 08:34 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
PSV100 писал(а):
Обратная же сторона медали возможностей "двумерного структурного" программирования -- отход от "классических" формальных методов верификации (и в целом принципов построения моделей).

Либо необходимо преобразовывать алгоритмические модели к "классике", либо применять рассуждения на основе иных методик (понятие систем переходов, автоматные методологии и пр.).
Вы не упомянули принципиальный момент. Язык ДРАКОН задуман и реализован как почти БЕЗОШИБОЧНЫЙ язык.

Некоторые пользователи уже оценили эту особенность языка ДРАКОН.

======================

Отзыв инженера vtral о языке ДРАКОН

Цитата:
Язык Дракон - это способ визуального описания алгоритмов, исключающий ошибки.

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

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

Собственно этот язык [дракон] и не для программистов создавался, а для простых инженеров, таких как я.
http://ledway.ru/post136332.html#p136332

Цитата:
Еще раз.
Дракон не создает оптимальный код.
Дракон исключает ошибки алгоритмов.

Какой смысл в оптимальном коде, если сам алгоритм содержит ошибки?
http://ledway.ru/post136337.html#p136337

=================================

Отзыв Сергея Иголкина (Orthodox) о языке ДРАКОН

Цитата:
Дракон, на самом деле — чертовски хорош.
Не тем, что красивые диаграммки. Или охрененные разнообразные возможности (хотя хватает).

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

http://sharaga.org/index.php?s=&showtop ... t&p=170889

============================

Отзыв индивидуального предпринимателя Сергея Ефанова о языке ДРАКОН

Цитата:
Переписал на ДРАКОНе довольно запутанную функцию из реального проекта.

Функция заработала сразу!

Более того, при переносе алгоритма в дракон-схему, я обнаружил, что у меня в ней была ошибка! Эта функция работала уже довольно давно, не в одной сотне изделий. Ошибка не была фатальной, она возникала редко, и компенсировалась переподключением к серверу. Но она была!

В тексте на Си её было незаметно. А при попытке перенести алгоритм на дракон-схему, ошибка стала не просто заметной — алгоритм в этом месте «не вырисовывался»!
http://we.easyelectronics.ru/drakon/pro ... mment41891


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 16 Июнь, 2019 09:12 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Продолжение дискуссии

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

Либо необходимо преобразовывать алгоритмические модели к "классике", либо применять рассуждения на основе иных методик (понятие систем переходов, автоматные методологии и пр.).
Язык ДРАКОН задуман и реализован как почти БЕЗОШИБОЧНЫЙ язык. Это достигается с помощью нового метода.

ИЗЛОЖЕНИЕ НОВОГО МЕТОДА
ПРИМЕНИТЕЛЬНО К МЕДИЦИНЕ


Цитата:
ДОКАЗАТЕЛЬСТВО ПРАВИЛЬНОСТИ КЛИНИЧЕСКИХ АЛГОРИТМОВ

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

Язык ДРАКОН обеспечивает не полное, а частичное решение этой задачи, которое выполняется с помощью исчисления икон.

Исчисление икон реализует частичное доказательство правильности клинических алгоритмов в процессе их построения методом визуального логического вывода.

Метод охватывает только графику дракон-алгоритмов и не затрагивает текст, размещаемый внутри икон.

ПРОГРАММА ДРАКОН-КОНСТРУКТОР

Частичное доказательство правильности клинических алгоритмов осуществляется не вручную, а автоматически с помощью программы ДРАКОН-конструктор.

Программа выполняет три задачи:

 помогает врачу разработать и нарисовать клинический алгоритм в диалоговом режиме;

 хранит в своей памяти правила исчисления икон и применяет их при вычерчивании графики дракон-алгоритма;

 реализует частичное доказательство правильности клинического дракон-алгоритма.

Благодаря исчислению икон частичное доказательство правильности графики алгоритма осуществляется без участия человека и достигается автоматически и совершенно бесплатно, так как дополнительные затраты труда, времени и ресурсов не требуются.

Во избежание ошибок врачу-разработчику клинического алгоритма запрещено рисовать какие-либо линии на чертеже.

Все линии автоматически рисует ДРАКОН-конструктор. Пользователь лишь управляет этим процессом, выбирая из меню нужные иконы (и макроиконы) и указывая на чертеже валентные точки.

ДРАКОН-конструктор, подчиняясь разумным указаниям пользователя (и отклоняя неразумные) автоматически применяет правила визуального логического вывода.

Полученный результат (практически безошибочное автоматическое проектирование графики дракон-схем) является значимым достижением [24, pp. 425-472].

Тщательно разработанные и теоретически обоснованные правила построения дракон-алгоритма, учитывающие особенности зрительного восприятия, позволяют облегчить и ускорить понимание алгоритма.

Благодаря правилам сложный и запутанный клинический алгоритм можно преобразовать и представить в виде комплекта ясных, доходчивых и дружелюбных (people-friendly) дракон-схем.

Высокая скорость разработки и сертификации клинических алгоритмов. Ожидаемые результаты использования языка ДРАКОН и ДРАКОН-конструктора в медицине можно описать следующим образом.

 Быстрота экспертной оценки. (Опытный врач, не знакомый с языком ДРАКОН, способен быстро понять предъявленный ему клинический дракон-алгоритм и сразу же указать содержащиеся в нем ошибки и неточности).

 Высокая скорость компьютерной разработки. (Молодой врач, знающий алгоритм и освоивший ДРАКОН-конструктор, способен предъявить листинг алгоритма через 20-30 минут после начала разработки алгоритма).

 Высокая скорость разработки и отладки клинического алгоритма. (Совместная работа молодого врача и его научного руководителя, с учетом нескольких переделок алгоритма по замечаниям руководителя, не превышает двух-трех часов).

БУДУЩЕЕ АЛГОРИТМИЧЕСКОЙ КЛИНИЧЕСКОЙ МЕДИЦИНЫ

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

В перспективе для всех нозологических форм, предусмотренных в Международной классификации болезней (МКБ-10, МКБ-11), будут созданы алгоритмы диагностики и лечения, размещенные в базе данных клинических дракон-алгоритмов (БД КДА) с возможностью демонстрации на больших экранах в режиме анимации.

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

 медицинские учебники, курсы лекций и учебные пособия;
 медицинские руководства;
 клинические рекомендации;
 протоколы диагностики и лечения;
 медицинские стандарты;
 публикации в медицинских журналах и книгах.

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 17 Июнь, 2019 05:07 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 239
Откуда: Россия, Стерлитамак
Владимир Паронджанов писал(а):

У меня такая операция вызывает большие сомнения.
Я боюсь, что она может провоцировать ошибки.
Поэтому ее следует запретить.

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

Кроме того, нельзя превращать лиану в стрелку цикла.

Разрешается создавать стрелку цикла только и исключительно с помощью макроиконы "Цикл со стрелкой".

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

По поводу ее пересадки на стрелку цикла, тут да, скорее всего ошибочно


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Июнь, 2019 20:08 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Паронджанов писал(а):
PSV100 писал(а):
Обратная же сторона медали возможностей "двумерного структурного" программирования -- отход от "классических" формальных методов верификации (и в целом принципов построения моделей).

Либо необходимо преобразовывать алгоритмические модели к "классике", либо применять рассуждения на основе иных методик (понятие систем переходов, автоматные методологии и пр.).

Вы не упомянули принципиальный момент. Язык ДРАКОН задуман и реализован как почти БЕЗОШИБОЧНЫЙ язык.
...
Это достигается с помощью нового метода.

В данном случае, действительно, имеется принципиальный момент. Обратимся к теоретическим основам, приведенным в википедии:
Часть VII // Теоретические основы языка ДРАКОН. — С. 449—472.
Цитата:
Глава 34. ИСЧИСЛЕНИЕ ИКОН
...
§10. ДОКАЗАТЕЛЬСТВО ПРАВИЛЬНОСТИ АЛГОРИТМОВ

Роберт Андерсон подчеркивает: «целью многих исследований в области
доказательства правильности программ является... механизация таких до-
казательств» [8]. Дэвид Грис указывает, что «доказательство должно опе-
режать построение программы» [9].

Объединив оба требования, получим, что автоматическое доказатель-
ство правильности должно опережать построение алгоритма. Нетрудно
убедиться, что предлагаемый метод обеспечивает частичное выполнение
этого требования. В самом деле, в начале главы было показано, что любая
правильно построенная шампур-схема является строго доказанной теоре-
мой. В алгоритмах дракон-конструктора закодировано исчисление икон.
Поэтому любая шампур-схема, построенная с его помощью, является ис-
тинной, то есть правильно построенной. Этот результат очень важен. Он
означает, что:
Цитата:
Дракон-конструктор осуществляет 100%-е автоматическое доказа-
тельство правильности шампур-схем, гарантируя принципиальную
невозможность ошибок визуального синтаксиса

В начале главы мы задали смешной вопрос: если шампур-схемы – это
теоремы, кто должен их доказывать? Ответ прост. Их никто не должен
доказывать, так как все они раз и навсегда доказаны. Потому что работа
дракон-конструктора построена как реализация исчисления икон.
А теперь добавим ложку дегтя в бочку меда. К сожалению, данный
метод позволяет доказать правильность шампур-схемы и только. Это со-
ставляет лишь часть от общего объема работы, которую нужно выполнить,
чтобы доказать правильность алгоритма на 100%. Здесь необходима ого-
ворка.
Частичное доказательство правильности алгоритма с помощью дра-
кон-конструктора осуществляется без какого-либо участия человека и
достигается совершенно бесплатно, так как дополнительные затраты тру-
да, времени и ресурсов не требуются. Так что полученный результат (без-
ошибочное автоматическое проектирование графики дракон-схем) следу-
ет признать значительным шагом вперед.

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

И дальнейшие уточнения там же вызывают неоднозначное понимание:
Цитата:
Глава 36. ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМАМ И ПРОГРАММАМ (ШАМПУР-МЕТОД)
...
§7. ЧЕМ РАЗЛИЧАЮТСЯ НАШ ПОДХОД К ДОКАЗАТЕЛЬСТВУ
ПРАВИЛЬНОСТИ И ПОДХОД ДЕЙКСТРЫ?
Цитата:
Мы используем идею Дейкстры о доказательстве правиль-
ности программ, развивая ее и перенося на абстрактные
дракон-схемы (шампур-схемы).

Цитата:
В главе 34 мы разработали логическое исчисление икон,
которое определяет порядок работы дракон-конструктора.
Благодаря этому дракон-конструктор осуществляет авто-
матическое доказательство правильности шампур-схем.

В чем отличие от подхода Дейкстры? Во-первых, мы говорим не о
полном, а о частичном доказательстве правильности.
Во-вторых, Дейкстра предлагает программистам доказывать правиль-
ность программ не автоматически, а вручную с помощью разработанных
им математических методов (преобразование предикатов и др.) [4].
Мы же предлагаем доказывать правильность не вручную, а автома-
тически.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Июнь, 2019 20:11 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Продолжение (там же):
Цитата:
Глава 36. ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМАМ И ПРОГРАММАМ (ШАМПУР-МЕТОД)
...
§10. ПЕРЕХОД ОТ ОДНОМЕРНОГО ТЕКСТА
К ДВУМЕРНОЙ ГРАФИКЕ РОЖДАЕТ НОВЫЕ ВОЗМОЖНОСТИ

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

В рамках одномерного текста устранить эти ограничения и запреты
невозможно. Но это вовсе не значит, что ситуацию в принципе нельзя
улучшить. Чтобы добиться улучшения, надо перейти от текста к графике.
Точнее, перейти от одномерного текстового структурного программирова-
ния к двумерному визуальному структурному программированию.
Задача состоит в том, чтобы значительно уменьшить число запретов
и ограничений. То есть предоставить алгоритмистам и программистам до-
полнительную свободу действий.
Цитата:
Эту задачу и решает язык ДРАКОН. Следуя по мудрому
пути, начертанному основоположниками структуризации,
визуальный язык ДРАКОН устраняет ненужные барьеры
и препятствия. И позволяет совершить прыжок из царства
необходимости в царство свободы.

Цитата:
Каким образом? Благодаря замене одномерного (текстового)
структурного подхода на двумерный (визуальный) струк-
турный подход. Последний, разумеется, также является сис-
темой правил. Но в «двумерной» системе правил значитель-
ная часть запретов снимается. То, что раньше было нельзя,
теперь можно.

Многие запреты (неизбежные при текстовом структурном програм-
мировании) «перегибают палку». Они противоречат здравому смыслу и
затрудняют понимание алгоритмов и программ

§11. УПРАВЛЯЮЩИЕ СТРУКТУРЫ, КОТОРЫЕ ЗАПРЕЩЕНЫ
В ТЕКСТОВОМ СТРУКТУРНОМ ПРОГРАММИРОВАНИИ
И РАЗРЕШЕНЫ В ВИЗУАЛЬНОМ

В книге приведено большое количество примеров таких структур. Здесь
нет необходимости их повторять. Поэтому мы приведем только один при-
мер. Рассмотрим схему на рис. 260.
В классическом структурном программировании управляющая струк-
тура на рис. 260 и многие другие запрещены. Они считаются неструктур-
ными. Но такие алгоритмы часто встречаются на практике.
Что отсюда следует?
Цитата:
Наш ответ таков: текстовые управляющие структуры иг-
рали важную роль в эпоху текстового программирования.
В ту пору они были единственно возможным решением. Но
сегодня, в эпоху компьютерной графики и визуальной ал-
горитмизации (визуального программирования) подобные
ограничения и запреты следует признать устаревшими.
Потому что во многих случаях (хотя и не всегда) они иска-
жают нормальный ход человеческой мысли.

Цитата:
Недопустимо запрещать правильный процесс мышления.
Его надо разрешить. И ДРАКОН разрешает.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Июнь, 2019 20:13 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
В целом, проблематика запретов не в недостатке выразительных средств, а как раз в здравом смысле.
На примере тех же циклов:
Код:
y := 1;
while x > 0 do
    x := x − y;
    y := y + 1;
end

В исходной "структурщине" цикл есть команда под "защитой" (повторно исполняемая, пока защита истинна), плюс инвариант (напр.: y > 0), ограничивающая функция (напр.: x стремится к нулю). Чем больше возникает "неструктурных" отношений (goto вовнутрь, внутри и из цикла, break, continue и т.п.), тем сложнее (или невозможно) определить "реквизиты" алгоритмических конструкций для доказательных рассуждений.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Июнь, 2019 20:17 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Паронджанов писал(а):
Рассмотрим нижнюю часть схемы Степана Митькина.
Это сложный случай: он в моих книгах не описан. Следует его обсудить.
...
Нельзя пересаживать лиану на линию со стрелкой цикла. Это опасно и потому должно быть запрещено.
Кроме того, нельзя превращать лиану в стрелку цикла.
Разрешается создавать стрелку цикла только и исключительно с помощью макроиконы "Цикл со стрелкой".

Там же, в "теоретических основах", имеются положения для такого решения:
Цитата:
Глава 36. ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМАМ И ПРОГРАММАМ (ШАМПУР-МЕТОД)
...
§22. ОПЕРАЦИИ С ЛИАНОЙ И ОПЕРАТОР GOTO
Цитата:
Операции с лианой моделируют все без исключения функ-
ции заменителей goto (например, досрочный выход из цик-
ла), а также некоторые функции goto, которые невозможно
реализовать с помощью заменителей. Однако они не приво-
дят к хаосу, вызванному бесконтрольным использованием
goto.

Цитата:
С эргономической точки зрения, действия с лианой на по-
рядок эффективнее и удобнее, чем goto и заменители. Кроме
того, они весьма эффективно корректируют недостатки клас-
сического (текстового) структурного программирования.

Приведем пример. В главе 7 мы рассмотрели эргономические преимущес-
тва схемы на рис. 62 по сравнению с рис. 61. Показано, что улучшение эр-
гономичности достигнуто за счет использования равносильных преобра-
зований алгоритмов: вертикального и горизонтального объединения. При
этом за кадром осталась важная проблема – проблема синтаксиса.
Как построить указанные схемы? Теперь мы имеем возможность осве-
тить этот вопрос. Схема на рис. 61 представляет собой структурный блок,
полученный с помощью операции «ввод атома». В отличие от нее схема
на рис. 62 – это лианный блок, построенный методом пересадки лианы.
Уместно вспомнить предостережение Гленфорда Майерса:
«Правила структурного программирования часто предписы-
вают повторять одинаковые фрагменты программы в разных
участках модуля, чтобы избавиться от употребления операто-
ров goto. В этом случае лекарство хуже болезни. Дублирование
резко увеличивает возможность внесения ошибок при изме-
нении модуля в будущем» [8, с. 138].
Как видно на рис. 53, 56, 62 пересадка лианы позволяет элегантно и
без потерь решить эту непростую проблему, одновременно улучшая на-
глядность и понятность алгоритма, обеспечивая более эффективное топо-
логическое упорядочивание маршрутов.
Пересадка лианы узаконивает лишь некоторые, отнюдь не любые пе-
редачи управления, поскольку определение операции «пересадка лианы»
(см. главу 33, тезис 28) содержит ряд ограничений.
Запрет на образование нового цикла вызван тем, что переход на опе-
ратор, расположенный выше (раньше) в тексте программы, считается
«наихудшим применением оператора goto [8, с. 135]. Указанный запрет
вводится, чтобы выполнить требование: использовать goto только для пе-
редачи управления вперед по программе, которое считается более прием-
лемым.
Запрет на образование второго входа в цикл соответствует требова-
нию структурного программирования, согласно которому цикл, как и лю-
бая простая программа, должен иметь не более одного входа.
Лишь третий запрет является оригинальной особенностью шампур-
метода: он запрещает передачи управления, изображение которых с помо-
щью лианы ведет к пересечению линий.
Таким образом, пересадка лианы разрешает только те переходы вниз
по дракон-алгоритму, которые образуют связи с валентными точками и
изображаются легко прослеживаемыми маршрутами, то есть не пересека-
ющимися линиями.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Июнь, 2019 20:21 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Однако, если декларируется запрет операции в циклах аля "continue", то этот запрет не согласуется с требованием обеспечить все возможные популярные конструкции циклов, согласно смежной теме:
https://forum.drakon.su/viewtopic.php?f=62&t=6151#p100768

И как отмечено выше в этой теме, понятие цикла также тесно переплетено с силуэтом, и требований для "лианы" недостаточно, напр.:
https://forum.drakon.su/viewtopic.php?f=62&t=6151#p103309
Вложение:
c1.png
c1.png [ 5.49 КБ | Просмотров: 7694 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 18 Июнь, 2019 21:16 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
PSV100 писал(а):
Всё же, выше имеется сравнение несоизмеримого. У Дейкстры под правильностью программ подразумевается её корректность по сути (предметному содержимому), т.е. вне акцента на вопросе о правильно построенных формулах (такой вопрос является обычной косвенной проблематикой формальной системы).
Вы правы.
Поясню свою позицию.

1. ДРАКОН не дает 100% защиты от ошибок. Тем не менее, благодаря ДРАКОНу вероятность ошибок очень мала.

2. Какие ошибки наиболее опасны? Наибольшую вероятность появления ошибок создают разветвления и циклы. То есть конструкции, описываемые служебными (ключевыми) словами (см. пункт 3).

3. Из языка ДРАКОН исключены служебные слова, организующие поток управления: goto, break, continue, if, then, else, case, of, switch, while, do, repeat, until, for, foreach, loop, exit, when, last. Вместо них используется математически строгая графика управления, которая реализует ту же самую функцию, что и перечисленные служебные слова.

4. При использовании ДРАКОНа функции, реализуемые указанными служебными словами, не записываются вручную, а формируются автоматически. Поэтому вероятность ошибок, вызванных разветвлениями и циклами, сведена практически к нулю.

5. Таким образом, при использовании ДРАКОНа остаются лишь опечатки и ошибки, появляющиеся на ЛИНЕЙНЫХ участках программ. Однако такие ошибки можно сравнительно легко выявить и устранить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 19 Июнь, 2019 19:58 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
adva писал(а):
Владимир Паронджанов писал(а):
У меня такая операция вызывает большие сомнения.
Я боюсь, что она может провоцировать ошибки.
Поэтому ее следует запретить.

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

Кроме того, нельзя превращать лиану в стрелку цикла.


Владимир Даниелович, не могу с вами согласиться.
Иногда нужно пересаживать лиану на стрелку цикла.

Вот смотрите: эта диаграмма на странице 352 "Учись писать, читать..."
Там после иконы Действие с текстом "B := B - A" лиана стоит на стрелке цикла, и это хорошо.

Вложение:
strelka.jpg
strelka.jpg [ 201.79 КБ | Просмотров: 7677 ]


Но самое главное, запрет на пересадку лианы на стрелку цикла приводит к уродливым диаграммам.
А именно, появляется лишний излом и лишняя линия.
На эту проблему указывают пользователи Drakon Editor и DrakonHub.

Вот такая уродливая диаграмма:

Вложение:
dron-urodsky.png
dron-urodsky.png [ 35.49 КБ | Просмотров: 7677 ]


Эта диаграмма, по-моему, и по мнению пользователей, выглядит лучше:

Вложение:
dron-krasivy.png
dron-krasivy.png [ 33.92 КБ | Просмотров: 7677 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июнь, 2019 13:12 

Зарегистрирован: Вторник, 27 Май, 2008 13:24
Сообщения: 155
Цитата:
Эта диаграмма, по-моему, и по мнению пользователей, выглядит лучше:
Да, вторая выглядит лучше, но понятнее для зрительного восприятия первая. Меньше напрягает. Драконом зрение натренировано после движения вправо по горизонтали в точке соединения с вертикалью - движение вниз. А во второй схеме надо сломать навык, задуматься, увидеть стрелку где-то вверху и изменить движение мысли на противоположное, сломать внесознательный стереотип. Вторая схема добавляет лишнюю умственную операцию. Или придется в точках соединения вставлять дополнительные указатели направления чтобы исключить эту операцию. Что загромоздит. Вертикаль цикла указующая возврат должна быть чистой. В отличие от вертикали на которой сливаются несколько выходов из икон "выбор"- после них не думая вниз - так на первой схеме.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июнь, 2019 15:35 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Да, вторая несравненно хуже.
Выходя на вертикаль из какого-то среднего вопроса, мы не понимаем, куда идти - вверх или вниз.
Мы должны пройти вниз до упора (а это может быть несколько страниц-экранов!!!), чтобы увидеть облом - оказывается, вверх надо было. И ещё несколько экранов обратно.

Первое правило когнитивной эргономики: форма должна быть однозначной!
Если есть т-образный перекрёсток, направление его прохода должно быть строго определено правилами и сидеть в подкорке у аналитика.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июнь, 2019 16:03 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 585
dvuugl писал(а):
Вторая схема добавляет лишнюю умственную операцию.

Alexey_Donskoy писал(а):
Да, вторая несравненно хуже.
Выходя на вертикаль из какого-то среднего вопроса, мы не понимаем, куда идти - вверх или вниз.

Я тоже так сначала думал. Мне было очевидно, что т-образный перекрёсток надо проходить единообразно:
либо справо-налево, либо сверху-вниз.
Но пользователи убедили меня в обратном.

Вопрос к dvuugl и Alexey_Donskoy:
Как вы используете ДРАКОН?
Вы программируете на ДРАКОНе или вы составляете ДРАКОН-схемы для документации и ТЗ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июнь, 2019 17:25 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Степан Митькин писал(а):
Но пользователи убедили меня в обратном.
Это не тот случай, когда надо слушать пользователей.
Пользователи не являются профессионалами в вопросах когнитивной эргономики, и их суждения надо оценивать весьма критично.
Как правило, человек крайне ленив, и если у него изначально закрепились неправильные навыки, он всеми силами будет противиться переобучению, даже если понимает всю выгоду от этого. А подавляющее большинство и не понимает.

Пример неадекватного суждения пользователя: "Эта картинка выглядит лучше".

Пример адекватного суждения: "Какого фига во всплывающем диалоге фокус не в поле ввода? Вводя через этот диалог сотни чисел в день, я вынужден КАЖДЫЙ РАЗ тратить лишние усилия на то, чтобы ткнуть мышью в поле ввода! Какого фига я не могу после ввода данных подтвердить их нажатием Enter? Только потому, что криворукий программист не озаботился назначить выбранную кнопку по умолчанию?" (тут все дружно узнают свою систему интернет-банкинга или, скажем, майкрософтовский диалог выбора файла, и т.д. и т.п. Характерно, что "поколение компьютерной мыши" зачастую даже не понимает сути этих претензий, изначально привыкнув к суперзатратному, крайне неэргономичному стилю своей работы за компом!)

Цитата:
Вы программируете на ДРАКОНе или вы составляете ДРАКОН-схемы для документации и ТЗ?
Я использую для документации и ТЗ, а также иногда при реверс-инжиниринге (перевести старый код в визуальное представление для поиска ошибок, например).
Если бы я считал Дракон полезным для программирования, то давно написал бы свой редактор. К сожалению, большая часть задач, решаемых в процессе программирования, лежит отнюдь не в алгоритмическом слое. Кроме того, плохо продуманный язык и редакторы вносят дополнительную сложность, что заметно снижает эффективность работы с ними...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июнь, 2019 17:51 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1356
Кроме т-образного перекрёстка есть и кресто-образные перекрёстки.

Alexey_Donskoy писал(а):
Более десятка лет предлагаю ... банальные закругления, ...
Не годятся, т.к. не могут строго локализоваться также, как точки соединения линий.

Есть примеры: закругления не используются электрических схемах, не используются в ГОСТ 19.701-90.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июнь, 2019 18:30 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
LKom писал(а):
Кроме т-образного перекрёстка есть и кресто-образные перекрёстки.
В большинстве схем принято элементарное решение - пересечение есть просто пересечение, а соединение обозначается жирной точкой.
Однако в алгоритме не может быть крестообразных соединений, поэтому нет и вопроса.
В алгоритме могут быть слияния нескольких линий, но совершенно неразумно для этого использовать "перекрёсток", ибо получится абсолютная путаница.

Цитата:
Не годятся, т.к. не могут строго локализоваться также, как точки соединения линий
Недостаток конкретной реализации? Теоретических проблем и препятствий нет.

Цитата:
Есть примеры: закругления не используются электрических схемах, не используются в ГОСТ 19.701-90.
Совершенно неадекватное суждение.
Электрические схемы существенно отличаются от направленного графа алгоритма. Сравнивать их нельзя почти ни по каким критериям.
ГОСТ на алгоритмы? Да не смешите мои тапочки! Он ориентирован на старинные технологии черчения и десятки лет как уже необратимо устарел.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июнь, 2019 21:05 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Степан Митькин писал(а):
Эта диаграмма, по-моему, и по мнению пользователей, выглядит лучше

Изображение
Согласен.

Теперь нужно показать, как ее построить с помощью исчисления икон.

Я буду строить упрощенную диаграмму, вот такую

Вложение:
Для Митькина  Цикл стрел2 Образец.png
Для Митькина Цикл стрел2 Образец.png [ 52.17 КБ | Просмотров: 7615 ]


Построение будет показано в следующем сообщении


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 20 Июнь, 2019 21:09 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
С чего начать?
Исходная схема — это макроикона "Цикл со со стрелкой". Выбираем в ней валентную точку, лежащую на вертикальной линии.
В эту валентную точку вставляем макроикону Развилка.
И т.д. см. рисунок.

Вложение:
Для Митькина  Цикл со стрелкой 2.png
Для Митькина Цикл со стрелкой 2.png [ 170.88 КБ | Просмотров: 7615 ]


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 79 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2024, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB