DRAKON.SU https://forum.drakon.su/ |
|
Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМАМ https://forum.drakon.su/viewtopic.php?f=62&t=2928 |
Страница 3 из 4 |
Автор: | Владислав Жаринов [ Суббота, 30 Октябрь, 2010 05:02 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Rifat писал(а): Надо чтобы вся структура программы была сразу видна. Согласен - и это не вопрос. Решается на уровне среды - д.б. команда "Развернуть всё <дерево>". А скрывать имеет смысл в ходе сочинения (если оно осуществляется через дерево) - чтобы сократить те участки, над которыми в данный момент не работаешь. |
Автор: | Владислав Жаринов [ Суббота, 30 Октябрь, 2010 05:13 ] |
Заголовок сообщения: | О подходах к комплексной формализации знаний |
Геннадий Тышов в viewtopic.php?p=52936#p52936 писал(а): Язык Дракон самостоятельно в настоящее время не имеет применения. Автор не использует его для разработки реальных алгоритмов, а рисует иллюстрации в неспециализированных графических редакторах для пропаганды языка Дракон. Уже говорилось, что ДРАКОН и не должен иметь самостоятельное применение, если ставится задача комплексного описания решения какой-либо проблемы - см. замечание Ильи в этом сообщении или /Паронджанов, 2001, с 183, п. Описание данных/ - там, правда, лишь общие соображения, а каково было конкретное решение - мы знаем по ФЛОКСу. Если нужно показать только алгоритм - то непонятны претензии - мы же не знаем, какие алгоритмы разрабатываются создателем техноязыка сейчас... Возникает и вопрос: а в чём рисовать схемы такого вида, как в книгах Паронджанова? Для этого нужен специализированный редактор, поддерживающий по крайней мере и шампур-метод, и КогниСтиль... я такого не знаю на сегодня. На возможное возражение, что можно отрисовать что-то в шампур-редакторе, а потом что-то "нафотошопить" на пэлобразе этой отрисовки в пикселграф-редакторе есть очевидное соображение - структура знания формируется целостно, и разрывать процесс оформления - значит, нагружать сочинителя "избыточной сложностью" - ему д.б. представлена возможность пользоваться всеми языками и методами визуализации в одной среде. Т.е. налицо отрыв от сути процесса сочинения - о чём говорил Валерий Лаптев : "...сначала напиши, как пользовать будешь, потом пиши код.". Кое-что следует сказать и о роли текста. Можно ли считать, что визуализация полностью исключает "сплошной текст" из описания? На мой взгляд, в общем случае нет - и видимо, это тоже имеет в виду тот же Info21, говоря о сторонниках визуализации знаний как об "адептах ДРАКОНа" - т.е. на мой взгляд несколько иронически (если я неправ - автор меня поправит ). Для чего нужен текст - удобно понять, представив себе уже не процесс сочинения комплексной модели, а процесс её интерпретации. Пусть читатель (исполнитель, рецензент) чего-то не понял в модели. Что дальше? Он обратится к сочинителю - и в основе их диалога будет лежать речь - устная и/или письменная (то же заочно-сетевое общение). В этом диалоге сочинитель будет, обращаясь к модели (допустим, полностью визуальной на семействе граф-языков, определённых на страницах этого раздела, включая КогниСтиль и Графит-пояснения), разъяснять текстом моменты, вызвавшие вопросы у читателя. Текст (на естественном языке) связывает воедино "хорошо структурированные" при сочинении составляющие предметной области, он же содержит не формализуемые строго элементы знания, указывая (и допуская при "нематематичности" построения) случаи и условия неполной определённости этой области - то, что не укладывается в импер-, деклар-, актив-схемы. Ну и общекультурная составляющая у него есть - он выстраивает последовательность изложения, формирует переходы между мыслями, в т.ч. выраженными на визуальной основе.
Акимов О.Е. в download/file.php?id=1946 на с. 321 писал(а): В процессе познания вещи часть знания приходится на понятия об этой вещи (функциональные элементы), а часть - на представления о ней (структурные элементы). Этому и соответствует "графитное" представление хорошо формализуемой части предмета описания.Как видим, многое нужно ещё от специализированного редактора, чтобы работать полностью в нём... |
Автор: | Владислав Жаринов [ Суббота, 30 Октябрь, 2010 06:05 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Геннадий Тышов писал(а): Работа по дополнению и.с. Drakon иерархическими схемами "Дерево" продолжена. С некоторыми результатами можно познакомиться здесь. Какие мнения будут? Вложение: Новый_45.png "Хвостов" не должно быть - какую бы форму не выбирали. Каждый маршрут должен приводить к своей вершине Конец (Останов). Пи-дерево в этом смысле понятнее. А почему у вершин Вопрос стало по три выхода? |
Автор: | ==== [ Суббота, 30 Октябрь, 2010 10:31 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Драконограф писал(а): 1. "Хвостов" не должно быть - какую бы форму не выбирали. 2. Каждый маршрут должен приводить к своей вершине Конец (Останов). 3. Пи-дерево в этом смысле понятнее. 4. А почему у вершин Вопрос стало по три выхода? 1. "Хвост" - терминология бытовая, не адекватная. В терминах теории графов - лист. О формах листов, что можно говорить? Это, или икона без ветки на месте листа, или ветка(и) пустого блока (в этом случае помечены знаком ? критические точки ввода), или пустая ветка блока "Если". 2. Имеем дело с деревом. Если дошли до листа, то возвращаемся на уровень выше к узлу. Останова не происходит. 3. "Пи-дерево" - что такое не знаю. "В этом смысле" - в каком смысле? По принципу "бритва Оккама" новые сущности не привлекаем, руководствуемся описанием Дамке. http://forum.oberoncore.ru/viewtopic.php?p=52854#p52854 4. В данном контексте икона именуется "Если", имеет вход, имеет выход - если не является конечной на шампуре, имеет 2-е ветки Да, Нет - соответствующие then и else. Одна из веток может заканчиваться переходом (Goto, Break, Continue) - лианой или быть пустой. Возможно, надо предусмотреть переход - выход (Exit) в виде иконы "Конец". |
Автор: | Рэйлвэй Каген [ Суббота, 30 Октябрь, 2010 12:41 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Дополнено сообщение о прототипах в части визуализации императивных языков. Вообще, тему визуализации атрибутных грамматик японцы топчут с начала 80-х. В рамках исследовательских программ даже был создан учебно-методический комплекс HCode2 с использованием автоматического генератора HiTS. По сабжу: никакой альтернативщины в этом подходе нет. Просто, в отличие от реляционной грамматики(Дракон) используется атрибутная грамматика(HiTS, HCode2, HiCHART, LogiCHART). Противопоставлять их бессмысленно. Совместное использование этих грамматик возможно, но не всегда. Не всякая конфигурация, записанная с помощью атрибутной грамматики может быть транслирована в конфигурацию на основе реляционной грамматики. Для обратной трансляции, если не ошибаюсь, ограничений нет. |
Автор: | ==== [ Суббота, 30 Октябрь, 2010 14:11 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Рэйлвэй Каген писал(а): По сабжу: Противопоставление с Драконом не предполагалось, больше имелось ввиду - взаимное дополнение. Схема "Дерево" и схемы Дракона предназначены для представления алгоритма и можно сравнивать их по различным критериям. никакой альтернативщины в этом подходе нет. ... Противопоставлять их бессмысленно. Совместное использование этих грамматик возможно, но не всегда. Для расширения функциональных возможностей дорабатывается и.с. Drakon. В основу разработки взята практика Дамке и В.Д. Паронджанова. Нет привязки к конкретному языку программирования и предусматривает внимание на алгоритме в проблемной области. В ваших ссылках использованы конкретные языки программирования с изменением формы записи. К вопросу о трансляции. Среда Drakon предлагает хранение программных текстов в полях алгоритма и формирование шаблона текста программного кода модуля с реализацией модели конечного автомата. |
Автор: | Рэйлвэй Каген [ Суббота, 30 Октябрь, 2010 14:25 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Рэйлвэй Каген писал(а): Не всякая конфигурация, записанная с помощью атрибутной грамматики может быть транслирована в конфигурацию на основе реляционной грамматики. Для обратной трансляции, если не ошибаюсь, ограничений нет. - это сказано в отношении представлений графовой модели алгоритма с помощью различных визуальных грамматик. Рассматривать мои слова в контесте трансляции в программный код модели конечного автомата не стоит. Это совсем другая тема.
|
Автор: | ==== [ Суббота, 30 Октябрь, 2010 14:29 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
В любом случае, есть результат общего применения, а не разговоры на тему Дракона многие годы. |
Автор: | Рэйлвэй Каген [ Суббота, 30 Октябрь, 2010 14:38 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Уважаемый, я Вам что-то должен??? Вы уж скажите прямо, а то какими-то намёками сыпете. Я чесслово ниче непонял из Вашего последнего сообщения. |
Автор: | ==== [ Суббота, 30 Октябрь, 2010 14:42 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Рэйлвэй Каген В "A Description of Hichart Program Diagrams for C" видим дерево, но нет следования по структурному программированию с входом сверху и выходом внизу. |
Автор: | ==== [ Суббота, 30 Октябрь, 2010 14:43 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Нет, это я оправдываюсь. Извините. |
Автор: | Рэйлвэй Каген [ Суббота, 30 Октябрь, 2010 14:44 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
И какой вывод из этого? ("нет следования по..") |
Автор: | ==== [ Суббота, 30 Октябрь, 2010 14:47 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Продолжать заниматься самостоятельно делом, которое можешь делать. |
Автор: | Рэйлвэй Каген [ Суббота, 30 Октябрь, 2010 14:57 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
А я так думаю, что это просто другая форма структурных конструкций. Они тоже структурные, но по-другому. Вы же хотите видеть только императивное следование сверху вниз. Этого, вероятно, можно достичь, если конец будет веткой, а не листом. Я уже испытывал совмещенные формы грамматик, напр. ПРОТОН, но она далеко неидеальна и взамен одних проблем всегда вылезают другие, соответственно, есть над чем подумать. Так что Ваше предложение заслуживает внимания. |
Автор: | Владислав Жаринов [ Воскресенье, 31 Октябрь, 2010 00:24 ] |
Заголовок сообщения: | О реализации подхода Дамке в Ты-среде |
Геннадий Тышов писал(а): 1. "Хвост" - терминология бытовая, не адекватная. В терминах теории графов - лист. Эти термины приложимы к любым графам, безотносительно к семантике ("надстройке" над графом без текста). Термин "хвост" отражает свойство конкретной интерпретации графа - маршрутной - незавершённость маршрута. Поэтому Ваши 1 и 2 у меня относятся к одному и тому же - мы по-разному понимаем, как отобразить маршрутную структуру в виде дерева. Я считаю, эргономично будет полагать дерево "развёрткой" совокупности маршрутов - у Вас, получается, что-то вроде "дерева вывода" логического програмирования (раз можно возвращаться) - а какова цель возвратности? и что при этом должен делать исполнитель такой модели? а что на уровне выше происходит, когда к нему вернулись?О формах листов, что можно говорить? Это, или икона без ветки на месте листа, или ветка(и) пустого блока (в этом случае помечены знаком ? критические точки ввода), или пустая ветка блока "Если" . 2. Имеем дело с деревом. Если дошли до листа, то возвращаемся на уровень выше к узлу. Останова не происходит. Геннадий Тышов писал(а): 3. "Пи-дерево" - что такое не знаю. "В этом смысле" - в каком смысле? То, что во вложении в это сообщение изображено на Фиг.12. Оно изображает именно развёртку структуры маршрутов, насколько можно понять - и без "хвостов". В смысле прослеживаемости исполнения алгоритма это нагляднее - каждый маршрут представлен своим путём по дереву.Геннадий Тышов писал(а): 4. В данном контексте икона именуется "Если", имеет вход, имеет выход - если не является конечной на шампуре, имеет 2-е ветки Да, Нет - соответствующие then и else. Одна из веток может заканчиваться переходом (Goto, Break, Continue) - лианой или быть пустой. Возможно, надо предусмотреть переход - выход (Exit) в виде иконы "Конец". Вот этот самый выход (без "да/нет") - он для чего? А куда может вести переход?Просьба давать именно свои ответы - т.е. как у Вас реализовано. |
Автор: | ==== [ Воскресенье, 31 Октябрь, 2010 04:31 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Драконограф О диссертации Прохорова есть в сообщении http://forum.oberoncore.ru/viewtopic.php?p=52888#p52888. В автореферате поиском не нашел упоминания о ПИ-дереве или просто дереве. С нотацией ознакомится можно по книге Дамке, конкретная реализация будет в тестовом выпуске и.с. Drakon. |
Автор: | Владислав Жаринов [ Воскресенье, 31 Октябрь, 2010 12:59 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Геннадий Тышов писал(а): Драконограф О диссертации Прохорова есть в сообщении http://forum.oberoncore.ru/viewtopic.php?p=52888#p52888. В автореферате поиском не нашел упоминания о ПИ-дереве или просто дереве. С нотацией ознакомится можно по книге Дамке, конкретная реализация будет в тестовом выпуске и.с. Drakon. Ну, так. Была указана конкретная иллюстрация в автореферате - и вложенном именно в сообщение 52880 (не 888). Прохоров называет эти схемы пи-схемами алгоритмов - просто длинно слишком Будет ли к среде объяснение реализации (на уровне составленного Рэйлвей Каген для его ПРОТОНа) - в этом вопрос. Книгу Дамке можно понимать по-разному - как и книгу Паронджанова или любую иную |
Автор: | ==== [ Воскресенье, 31 Октябрь, 2010 13:07 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Да, полагаю, будет самостоятельный раздел в справке. |
Автор: | Владислав Жаринов [ Вторник, 02 Ноябрь, 2010 05:46 ] |
Заголовок сообщения: | Re: Альтернативный ВИЗУАЛЬНЫЙ СТРУКТУРНЫЙ ПОДХОД К АЛГОРИТМА |
Геннадий Тышов писал(а): Да, полагаю, будет самостоятельный раздел в справке. Спасибо. Кстати, для контроля определений - под "развёрткой" маршрутного графа я понимаю то, что справа на этом рисунке: Вложение: Здесь развёрнут циклический алгоритм, причём показаны состояния вычисления в узлах. Конечно, это конкретизация при известных исходных данных, потому и маршрут один - для общего случая мы рассматриваем для каждого условия его альтернативы и в результате строится уже "дерево возможностей", где листами всегда будут вершины-терминаторы языка (Конец, а для Д2М-определения техноязыка - также и Останов).
Ну, естественно, не по шампур-методу оформлено - "змейкой" с обратными следованиями - но суть не в этом. А в том, что путь показан проходящимся до завершения и легко отделяемым от других возможных путей. И самое главное - без перемены направления следования на графе и/или структурных свойств нешампур-вершин (как было в исходной граф-схеме у условий по два выхода - так и здесь). Это всё в совокупности обеспечивает улучшение восприятия. Тогда как схемы с "альтернативной" трактовкой топологии вносят "избыточную сложность". Не всё, что можно придумать теоретически, нужно нести в любые прикладные области - каждой "предметке" - свой теоретический аппарат... P.S. Кстати, "по Дамке" нет необходимости в пересадках лиан именно за счёт дублирования кода, имеющего место при "развёртывании". |
Автор: | Владислав Жаринов [ Вторник, 02 Ноябрь, 2010 18:22 ] |
Заголовок сообщения: | О проблемах и вариантах представления систем алгоритмов |
Геннадий Тышов писал(а): Рэйлвэй Каген писал(а): По сабжу: Противопоставление с Драконом не предполагалось, больше имелось ввиду - взаимное дополнение. Схема "Дерево" и схемы Дракона предназначены для представления алгоритма и можно сравнивать их по различным критериям. никакой альтернативщины в этом подходе нет. ... Противопоставлять их бессмысленно. Совместное использование этих грамматик возможно, но не всегда. Согласен - это дополнительная форма представления, только прежде всего не алгоритма, а системы алгоритмов - чтобы можно было её "охватить одним взглядом" (симультанно). Только для этого нужна возможность свёртки линейных участков, о чём говорил выше. И ещё раз - ну не работает сочинитель естественным образом исключительно с деревом задачи - пусть даже оно будет в той форме, которую я посчитал выше эргономичной. В общем случае для него не менее (если не более) естественно визуализировать алгоритмы, связывая их через вставки. Поэтому как минимум дерево должно и их включать - если мы хотим использовать его как представление для сочинения, а не просто для обзора дракон-модели (напомню, что этот термин понимается, как определено в этом подпункте). Поскольку дракон-модель отражает решение задачи, разбитое на подзадачи, то можно говорить о древовидном представлении этой модели и как о "дереве задачи". А не менее оптимально, на мой взгляд - если дерево дракон-модели всё-таки строить обзорно, как производное от этой модели - тогда оно служит только для навигации, как дерево модели в DesignIDEF, а редактирование всё-таки происходит в дракон-схемах модели (как это определено и для ДМ-языка здесь). В любом случае крайне важно, чтобы два разных представления были именно представлениями одного и того же описания задачи - и их редактирование (естественно, попременное) отражалось бы на этом единственном описании (реально и хранимом в документе среды). На это же указывал Дмитрий_ВБ в своих предложениях. Но вижу потенциальные сложности программной реализации "редактируемости со многих сторон" - ведь остальные открытые представления надо либо "сбрасывать" при первой же подтверждённой команде оператора на изменение (считая временными по отношению к выбранному для редактирования), либо (если все представления считаются постоянными) перестраивать в соответствии с каждым изменением. И не замедлит ли это снова отклик среды на действия оператора? |
Страница 3 из 4 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |