DRAKON.SU

Текущее время: Вторник, 07 Июль, 2020 13:25

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




Начать новую тему Ответить на тему  [ Сообщений: 69 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 23 Октябрь, 2010 21:53 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Илья Ермаков писал(а):
Да, просится разнести ещё и по горизонтали. Как раз задействовать плоскость.
Достаточно неплохое косметическое улучшение.
Принципиальная разница в том, что алгоритм записывается в иерархическое дерево (которое конечно не одномерное), исполняемые элементы алгоритма являются листьями, а не нанизываются на шампур. Листья не заканчиваются продолжением связей, а возвращают управление на управляющий элемент уровнем выше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 24 Октябрь, 2010 14:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Геннадий Тышов писал(а):

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

Язык Дракон самостоятельно в настоящее время не имеет применения. Автор не использует его для разработки реальных алгоритмов, а рисует иллюстрации в неспециализированных графических редакторах для пропаганды языка Дракон. При этом частному языку Дракон приписываются свойства всей системы Графит-Флокс в целом, в частности языка программирования.

Прошу не воспринять это сообщение, как попытку дерзить.

Чегой-то не понял... ведь эти схемы есть просто результат "областной декомпозиции", как в SADT или как предлагалось здесь... и не перекликается ли это с принципом развёртки нелинейного алгоритма в командную модель, о котором говорил Илья Ермаков в этом сообщении?...

Относительно "приписывания части свойств целого" - в /Паронджанов, 2001, с. 191-192/ говорилось, что кроме императивных знаний есть и другие, не содержащиеся в дракон-схемах... там был и Рис. 100 с первоначальной классификацией визуализируемых знаний (уточнена, напр. здесь).

А о каком самостоятельном примененении Вы говорите?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Октябрь, 2010 18:45 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1066
Откуда: Россия, Чебоксары
Кстати, на HiAsm очень похожа эта нотация ;)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Октябрь, 2010 18:56 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Alexey_Donskoy писал(а):
Кстати, на HiAsm очень похожа эта нотация

Кто бы, язык Дракон обновил, можно и реализовать.
Или язык Дракон расширить конструкцией "Дерево подзадачи".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 25 Октябрь, 2010 22:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Ну, тело циклов и так сбоку справа выносится.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 01:03 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Илья Ермаков писал(а):
Ну, тело циклов и так сбоку справа выносится.
Вложение:
Новый_01.png
На схеме, помеченные действия не вынесены вправо, они засоряют уровень управляющих элементов.
Здесь элементы управления образуют последовательность, по терминологии структуризации - следование.
По Дамке действия к управляющим элементам выносятся вправо, каждая последовательность действий к управляющему элементу образует следование не имеющее внизу продолжение.
У Дамке, в принципе, нет необходимости в операции пересадка лианы.

Нужен когнитолог для экспертной оценки принципа построения блок-схем по Дамке.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 03:37 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Илья Ермаков в viewtopic.php?p=52881#p52881 писал(а):
Для ряда алгоритмов самая важная информация - цепи атомарных событий, которые они могут порождать. Когда нужно не изучать по слоям, а видеть все цепи. Иерархическая схема в таком случае заставляет буксовать.

Видимо, это то же самое, что "вычисление структуры Крипке" - т.е. развёртка диаграммы состояний-переходов (автоматного графа), каждое состояние которого помечено поднабором базовых свойств, истинных в этом состоянии (из набора свойств, интересующих сочинителя структуры)?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 05:02 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Геннадий Тышов писал(а):
Илья Ермаков писал(а):
Да, просится разнести ещё и по горизонтали. Как раз задействовать плоскость.
Достаточно неплохое косметическое улучшение.

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

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

В очередной раз: "Братва, не стреляйте в друг друга//Вам нечего больше делить" :))
Илья же уже говорил о возможности развернуть силуэт в этом сообщении именно в дерево. Точно так же можно развернуть ДМ-схему на языке, определённом здесь - тогда и получится форма дерева процедур - только тогда и ветвлениями дерева считать также развилки. Также и код по маршруту между вставками, конечно, показывать надо - это когда визуал дракон-модели в терминах определения степени содержательности в этом подразделе является не полностью концептуализированным. У Прохорова в пи-схемах (Фиг.12 из автореферата) тот же принцип - только дерево строится иначе и последовательный код (операторные цепочки), насколько я могу видеть, текстом отображаются. Однако эргономичнее будет этот код изначально свёртывать также, как и вставки - заменяя, допустим, на абстракцию шампур-блока в виде вершины ОС6 по определению из этого пункта - а по щелчку раскрывать содержание. Но это всё вряд ли нужно считать частью ДРАКОНа - а как отдельный язык (конструкции которого создаются на основании дракон-схемы или дракон-модели) почему бы и не реализовать...
Кстати, пи-схемы, как я вижу, реализуют и визуализацию исключений и синхронизации - судя по видимой части алфавита... А на Фиг.16 у Прохорова вижу возможное решение по "диаграмме размещения" - т.е. структурно-топологическое представление реализации - актив-знание, взаимосвязанное с импер-знанием. Пи-синт-язык, видимо, это те же синтдиаграммы, только древовидные - как давнее предложение dvuugl по организации описания типов. Кстати, и это имеет свои корни - см. хотя бы изображение этой текстово-визуальной среды разработки для Паскаля (статья 1984-го года):
Вложение:
Комментарий к файлу: Вид интерфейса системы Пекан.
СоврКомп_Теслер-ЯП-извл(снимок программы).djvu [88.32 КБ]
Скачиваний: 242
Здесь в окне Expression display (среднее внизу) можно увидеть всё ту же диаграмму синтаксического разбора выражения - очевидно, построенную автоматически. Кстати, рядом и фрагмент ГСА, причём вертикали, насколько можно видеть, упорядочены вправо. Так что опять "всё уже украдено до нас" :) А все основные возможности, продемонстрированные на этом виде, нужно реализовать и в современной среде разработки - если полагать, что она не самостоятельна, а выдаёт продукт для промышленного компилятора/верификатора, то тем не менее полезны и демонстрация областей видимости, и показ значений величин (конечно, по умолчанию, если среда сама не исполняет описания, а перекладывает это на промышленные системы), и исходный текст (на "нейтральном языке" в смысле, разъясняемом в этом сообщении) для текущей единицы реализации (если языком является Оберон - то модуля).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 10:30 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 218
Откуда: Казань
Возможно, скажу банальность.
Есть поговорка: "на вкус и цвет товарища нет", можно продолжить "на вкус, цвет и графическое представление алгоритмов товарища нет".
Дело в том, что большую роль играет привычка. Если человек привык использовать в своей работе блок-схемы, то его трудно будет заставить использовать Дракон, UML или другие диаграммы. Кто-то привык использовать Дракон и уже не смыслит, как вообще можно представлять алгоритмы по-другому, кроме как на Драконе.

Есть две концепций программирования, которые мне нравятся, и которые, как я думаю, могут решить многие проблемы связанные с надежностью программ:
1) Доказательное программирование (Дейкстра, Грис, Бейбер и др)
2) Пошаговое уточнение (Вирт и с некоторой натяжкой Кнут, с его концепцией грамотного программирования).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 11:22 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Геннадий Тышов писал(а):
На схеме, помеченные действия не вынесены вправо, они засоряют уровень управляющих элементов.


Циклы с условием в конце практически никогда не используются. Если такой цикл возник, то в большинстве случаев это признак, что что-то не так спроектировано в структуре алгоритма. См. базовую схему "полный проход" - подготовительное действие до цикла, затем цикл с условием в начале. Практически всегда так, кроме совсем примитивных случаев, где в цикле повторяется одно действие 1 или более раз.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 15:03 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Rifat писал(а):
...большую роль играет привычка. Если человек привык использовать в своей работе блок-схемы, то его трудно будет заставить использовать Дракон, UML или другие диаграммы. Кто-то привык использовать Дракон и уже не смыслит, как вообще можно представлять алгоритмы по-другому, кроме как на Драконе.

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

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

Пошаговое уточнение позволяют видеть и пи-подобные схемы - тогда не нужно всё вправо выносить... А объединение выходов - это же получается возврат к шампур-схемам?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 19:09 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 77
Откуда: Астрахань
Rifat писал(а):
Есть две концепций программирования, которые мне нравятся, и которые, как я думаю, могут решить многие проблемы связанные с надежностью программ:
1) Доказательное программирование (Дейкстра, Грис, Бейбер и др)
2) Пошаговое уточнение (Вирт и с некоторой натяжкой Кнут, с его концепцией грамотного программирования).

Добавьте "разработка через тестирование". Можно считать это дополнением к 2 - сначала напиши, как пользовать будешь, потом пиши код.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 19:44 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
И.с. Drakon дорабатывается для формирования блок-схем по Дамке. Схема получила название вида - "Задача". В схеме дополнительно используются иконы: "ПодЗадача", "If", "While", "Until", "For".
Вложение:
Новый_44_1.png
Схема "Задача", выбрана и видны точки ввода. Сейчас отработаны вопросы: графика икон, ввод и удаление икон.

Какое будет ваше мнение?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 20:26 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
Неплохо... Что касается конструкции "Задача".

Но я бы очень настойчиво советовал не делать выносок для циклов и условий. Это уже жуткая путаница.

Ведь до условия можно просто вставить Вашу "задачу" - а сбоку от неё прорисовать условие как обычно в ДРАКОНе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 26 Октябрь, 2010 21:06 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 218
Откуда: Казань
В принципе схема нравится, но можно сделать еще лучше:
1) Тело оператора IF не должно быть на одном уровне с телом оператора UNTIL. Тело оператора IF должо идти до тела оператора UNTIL
2) Лучше если каждый уровень вложенности будет на одной вертикали для всех операторов. А для этого ветки IF лучше разместить не горизонтально, а вертикально.
Или же как вариант можно расположить ветки IF по разные стороны от ромбика.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Октябрь, 2010 06:22 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Rifat писал(а):
В принципе схема нравится, но можно сделать еще лучше:
...
2) Лучше если каждый уровень вложенности будет на одной вертикали для всех операторов. А для этого ветки IF лучше разместить не горизонтально, а вертикально.
Или же как вариант можно расположить ветки IF по разные стороны от ромбика.

А что-то подобное, видимо, и сделал Прохоров...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Октябрь, 2010 06:28 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Илья Ермаков писал(а):
Неплохо... Что касается конструкции "Задача".

Но я бы очень настойчиво советовал не делать выносок для циклов и условий. Это уже жуткая путаница.

Ведь до условия можно просто вставить Вашу "задачу" - а сбоку от неё прорисовать условие как обычно в ДРАКОНе.

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

Нужно реализовать цикл Дейкстры - и там тоже есть над чем подумать при такой организации...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Октябрь, 2010 09:34 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Некоторые идеи Дамке реализованы в проекте Logichart для PROLOG'а. Дано определение грамматики.
Вложение:
Logichart - A Prolog Program Diagram and its Layout.pdf [254.61 КБ]
Скачиваний: 312

Для императивных языков:
Вложение:
A Description of Hichart Program Diagrams for C.pdf [158.78 КБ]
Скачиваний: 259

Внутреннее представление H-code здесь:
Вложение:
Generation of the Hichart Program Diagrams (en).pdf [801.83 КБ]
Скачиваний: 296


Последний раз редактировалось Рэйлвэй Каген Среда, 03 Ноябрь, 2010 19:11, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 27 Октябрь, 2010 09:40 

Зарегистрирован: Пятница, 13 Март, 2009 16:36
Сообщения: 218
Откуда: Казань
Драконограф писал(а):
И вообще лучше бы делать это как схему верхнего уровня - где нет цепочек операторов (по умолчанию), а есть их заместители - одиночные вершины, каждую из которых можно независимо по команде развернуть и также свернуть...

Считаю, что скрывать код от самого себя не надо. (Если допустим написал программу, через пол года уже забыл как программа работает, а надо немного оптимизировать, открываешь схему, а там 3 прямоугольника, ну и ладно где здесь может тормозить. Открываешь первый прямоугольник, там несколько присваиваний, открываешь второй, там цикл, ну и ладно цикл и цикл, а открываешь еще, а там еще 2 уровния вложенности и того O(N^3))
Надо чтобы вся структура программы была сразу видна.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 29 Октябрь, 2010 19:14 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Работа по дополнению и.с. Drakon иерархическими схемами "Дерево" продолжена.
С некоторыми результатами можно познакомиться здесь.
Какие мнения будут?
Вложение:
Новый_45.png


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

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


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

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


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

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