DRAKON.SU

Текущее время: Пятница, 26 Февраль, 2021 06:59

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




Начать новую тему Ответить на тему  [ Сообщений: 24 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 12:46 

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

Прошу Вас высказать соображения на тему "ДРАКОН и функциональное программирование".

В частности, желательно осветить и обсудить тему:

ПРИНЦИПЫ ПОСТРОЕНИЯ ГИБРИДНЫХ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ, ОБРАЗОВАННЫХ СОЕДИНЕНИЕМ ДРАКОНа И ФУНКЦИОНАЛЬНЫХ ЯЗЫКОВ


Последний раз редактировалось Владимир Паронджанов Суббота, 15 Сентябрь, 2012 14:46, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 15 Сентябрь, 2012 14:31 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5086
Откуда: Москва
8 апреля 2012 года Степан Митькин сделал сообщение о связи ДРАКОНа и функциональных языков:
Степан Митькин писал(а):
Вышел DRAKON Editor 1.10
В этой версии:
..........................................
2. Добавлен язык Javascript.
3. Добавлен язык Erlang.
Сайт проекта: http://drakon-editor.sourceforge.net/

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

Единственное отличие функционального ДРАКОНА от его процедурного собрата - отсутствие циклов.

Всё остальное, включая Силуэт, остаётся как прежде и отлично работает.
viewtopic.php?p=72000#p72000

Отсюда вытекает такая формулировка:
Цитата:
Тезис Степана Митькина

ДЛЯ ФУНКЦИОНАЛЬНОГО ПРОГРАММИРОВАНИЯ ДРАКОН ХОРОШО ПОДХОДИТ

Уважаемые коллеги!

Что Вы думаете по этому поводу?
Прошу поддержать или опровергнуть (или прокомментировать) заявление Степана Борисовича.


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5086
Откуда: Москва
Доктор технических наук, профессор Андрей Александрович Тюгашев (псевдоним TAU) писал(а):
Восхитительно и интересно! Надо посмотреть - еще не слышал о применении блок-схем для функционального программирования, в нем больше диаграммы потоков данных идут.
viewtopic.php?p=72035#p72035

Уважаемый Андрей Александрович!

Если нетрудно, изложите Ваше мнение по этому вопросу в развернутой форме.


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5086
Откуда: Москва
usr345 создал тему
Цитата:
Как изобразить condition-case в ДРАКОН-Lisp

viewtopic.php?f=78&t=2774

В этой теме в порядке эксперимента исследован вопрос о возможности языка Дракон-Лисп.

Тема очень интересная, но выводов там я не нашел.

Уважаемый usr345!

К какому заключению Вы пришли по результатам Вашего эксперимента?
Просьба пояснить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 16 Сентябрь, 2012 13:44 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Да, это будет интересно. Тем более, что выводов предполагается два - один связан и с техноязыком как нотацией в императивной парадигме, другой - только с исчислением графов для представления функциональной в чистом виде...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: ДРАКОН-Erlang
СообщениеДобавлено: Среда, 03 Октябрь, 2012 14:10 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 550
Функциональное программирование - область интересная. Полная фанатизма и тайны.
В чём его соль? Чем же оно так хорошо?
Простого ответа я не нашёл. Пришлось разбираться.

Как говорит нам Теорема Бёма — Якопини, любой алгоритм можно составить из блоков всего трёх видов:
1. Последовательность действий.
2. Развилка по результатам логического выражения.
3. Цикл.

Эти блоки есть почти во всех языках программирования. Именно наличие этих блоков
и делает языки похожими.

Но функциональные языки стоят особняком.
Их отличие в том, что у них нет циклов. То есть остаются только два вида строительных блоков:
1. Последовательность.
2. Развилка.

Циклы программировать, конечно, можно и нужно. Но неявно.
Для неявного выражения циклов активно используются:
1. рекурсия;
2. композиция функций.

То есть получается, что выразительная сила функциональных языков нарочно урезана.
Зачем?
А затем, чтобы уменьшить сложность программ.
Благодаря отсутствию циклов все переменные можно сделать только для чтения. Каждый символ в программе имеет только одно вечное значение. Это жутко удобно.
Кроме того, можно устранить скрытые сторонние эффекты.
Когда в результате вызова процедуры "что-то" меняется "где-то".

Вот практические следствия этого упрощения:

1. Композиция функций получается безопасной. Замыкания (closures) можно читать буквально.
2. В обычных языках значение переменной может меняться. Поэтому
при чтении программ приходится догадываться, какое значение принимает переменная
в каждом месте, где она упоминается. Что требует вдумчивого изучения контекста.
А это ненужная умственная работа.
3. Самое главное. Аргументы и возвращаемый результат функций передаются по значению. Из-за этого функцию можно рассматривать как систему, в которой чётко обозначены вход и выход. Это эргономично!

Всё вроде бы хорошо, но есть небольшая проблема.
Функциональные программы уж больно трудно читать.

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

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

В качестве подопытного кролика был взят язык Erlang. Почему?
1. Он очень простой и понятный.
2. В нём изначально есть поддержка параллельного программирования.

DRAKON Editor реализует ДРАКОН-Erlang.

Подробности описаны в этой статейке.

Повторю свои тезисы:
1. Функциональные языки не имеют принципиальный отличий от "обыкновенных" (кроме отсутствия циклов).
2. Трудность чтения функциональных программ вызвана исключительно традицией их записи.
3. ДРАКОН может быть успешно использован для улучшения понимаемости функциональных программ.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 03 Октябрь, 2012 14:50 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Владимир Паронджанов писал(а):
Доктор технических наук, профессор Андрей Александрович Тюгашев (псевдоним TAU) писал(а):
Восхитительно и интересно! Надо посмотреть - еще не слышал о применении блок-схем для функционального программирования, в нем больше диаграммы потоков данных идут.
viewtopic.php?p=72035#p72035

Уважаемый Андрей Александрович!

Если нетрудно, изложите Ваше мнение по этому вопросу в развернутой форме

Хммм... Не сразу увидел ветку.

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

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

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

Не знаю, удалось ли мне выразиться, как просил глубокоуважаемый Владимир Даниелович, "в развернутой форме" :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 03 Октябрь, 2012 16:52 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 550
TAU писал(а):
У чистых функциональных программ, вообще говоря, нет ни последовательности, ни состояния.

Нельзя говорить, что в функциональных программах совсем нет последовательности.
Функциональное программирование производит частичное упорядочение операций.
То есть иногда последовательность задаётся жёстко. Иногда остаётся на усмотрение компилятора.

Например: Result = cool(bar(foo(X)))
Здесь последовательность вызова функций критически важна. Она определяет суть алгоритма.
Сначала вызывается foo, затем bar, а уж потом cool.
Вложение:
sequental.png
sequental.png [ 3.11 КБ | Просмотров: 13769 ]

Другой пример: Result = cool(foo(X), bar(Y))
Здесь действия упорядочены только частично:
- сначала вызывается foo или bar или обе одновременно;
- затем вызывается cool.
Вложение:
parallel.png
parallel.png [ 4 КБ | Просмотров: 13769 ]

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

Текущая версия DRAKON Editor'а пока не поддерживает такое изображение параллельных действий. К счастью, для реализации гибридного языка ДРАКОН-Erlang это не требуется.

Я настаиваю на выводе, который я сделал, программируя на языке ДРАКОН-Erlang:
В своей сути Функциональное программирование не имеет существенных отличий от процедурного. И там, и там программист обязан вручную задать шаги,
требуемые для решения задачи.

Эмоциональное ощущение: графическое управление потоком выполнения вкупе с преимуществами функционального программирования даёт невиданную ясность алгоритмов.


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5086
Откуда: Москва
Степан Митькин писал(а):
графическое управление потоком выполнения вкупе с преимуществами функционального программирования даёт невиданную ясность алгоритмов.


Уважаемый Степан Борисович!

Если можно, раскройте и детализируйте этот тезис. То есть ответьте на вопрос: В чем заключается НЕВИДАННАЯ ЯСНОСТЬ АЛГОРИТМОВ? По пунктам первое, второе, третье и т.д.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 04 Октябрь, 2012 17:00 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 550
Владимир Паронджанов писал(а):
То есть ответьте на вопрос: В чем заключается НЕВИДАННАЯ ЯСНОСТЬ АЛГОРИТМОВ? По пунктам первое, второе, третье и т.д.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 05 Октябрь, 2012 08:00 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1095
Откуда: Россия, Чебоксары
Степан Митькин писал(а):
Но волшебное "заработало!" быстрее приходит.
Может, это просто опыт? :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 05 Октябрь, 2012 22:34 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 550
Alexey_Donskoy писал(а):
Степан Митькин писал(а):
Но волшебное "заработало!" быстрее приходит.
Может, это просто опыт? :wink:

сын ошибок скучный :)

Выложил HTML-версию статьи:
http://drakon-editor.sourceforge.net/drakon-erlang/intro.html


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5086
Откуда: Москва
В сообщении viewtopic.php?p=75245#p75245 Степан Митькин писал(а):
Подробности описаны в этой статейке.
У меня три замечания.

1. Это не статейка, а статья. Причем очень серьезная. На 23 страницах.

2. Статья чрезвычайно интересная. Содержащая важные новые идеи. А может быть, даже революционная.

3. Степан Борисович, Вы дали ссылку
http://sourceforge.net/projects/drakon- ... f/download

    Это косвенная ссылка. На моем быстром ноутбуке эта ссылка открывается медленно. Мне кажется, лучше давать не косвенную, а прямую ссылку:
    http://ignum.dl.sourceforge.net/project ... Erlang.pdf

    Прямая ссылка (через ignum.dl. и без download) открывается моментально. Как Вы считаете?

В сообщении viewtopic.php?p=75245#p75245 Степан Митькин писал(а):
Всё вроде бы хорошо, но есть небольшая проблема.
Функциональные программы уж больно трудно читать.
Плохая формулировка. Слово "небольшая" вводит в заблуждение и портит всю обедню. Слово "небольшая" надо удалить. После этого формулировка становится приемлемой.

В конце сообщения viewtopic.php?p=75245#p75245 Степан Митькин писал(а):
Повторю свои тезисы:
1. Функциональные языки не имеют принципиальный отличий от "обыкновенных" (кроме отсутствия циклов).
2. Трудность чтения функциональных программ вызвана исключительно традицией их записи.
3. ДРАКОН может быть успешно использован для улучшения понимаемости функциональных программ.

Приветствую тезисы Митькина. Обобщая их, предлагаю для обсуждения формулировку:
Цитата:
Тезис Степана Митькина

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


Степан Митькин писал(а):
Выложил HTML-версию статьи:
http://drakon-editor.sourceforge.net/drakon-erlang/intro.html


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

Я выделил из статьи отрывок. И перевел этот отрывок на русский язык.

Цитата:
Algorithm is the core of software. It is the algorithm that produces the desired output of a program. Therefore, if the algorithm is easy to understand, the whole program is easy to maintain, extend and document.

Unfortunately, the traditional way of recording algorithms is wrong. This is a major problem of programming in general, not only functional programming. Algorithms in most of the modern programs are written using text. This text is called "the source code".

Usually, source code is indented in a special way and highlighted with different colors in the editor. But it is plain text. Text is bad because humans are not very good at understanding text. Their eyes and brains have been optimized for seeing images during millions of years. Text is a recent invention. The human biological hardware is not natively compatible with text.

If the algorithm is presented as an picture instead of text, it can be easier to understand.
There are a lot of ways to draw an algorithm. Choosing the right one is critically important. A bad picture can be worse than text. A good picture will leverage the ability of the human being to perceive information simultaneously.

Flowcharts are a popular graphical notation for representing algorithms. Many developers do not like flowcharts. The reason is that complex algorithms tend to end up in badly cluttered flowcharts. Those can be harder to figure out than text-based programs. As a result, graphical programming is often dismissed as an unsuccessful experiment.

But the problem is not in graphical programming itself. The problem is that flowcharts as a graphical language are not good enough. The good news is, it is possible to improve this language.

DRAKON provides such improvement. It offers several simple, but effective rules that cardinally increase readability of a diagram. DRAKON is a visual language that can be described as flowcharts optimized for ergonomics. The creators of DRAKON paid great attention to human visual habits.

Every little detail of DRAKON is aimed at ensuring fast and easy understanding.

That is why DRAKON is an excellent candidate for visualization of a functional programming language. The clarity of DRAKON is something that functional programming can greatly benefit from.


Перевод на русский язык
Цитата:
Алгоритм является ядром программного обеспечения. Именно алгоритм определяет желаемый результат программы. Если алгоритм пригоден для легкого и быстрого понимания, то вся программа окажется удобной для сопровождения, внесения изменений, расширения функциональных возможностей и документирования.

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

Как правило, исходный код пишут с отступами (индентацией) и выделяют нужные слова разными цветами в редакторе. Эти приемы (отступы и цвет) полезны, но они не изменяют природы текста. Трудность в том, что люди далеко не всегда способны глубоко понять сложный текст. Человеческий глаз и мозг в течение миллионов лет, предшествовавших появлению текста, привыкли воспринимать зрительные образы окружающего мира. Мира, в котором текст полностью отсутствовал. Текст — недавнее изобретение. Электробиохимическая структура нервной системы человека (biological hardware) на начальном этапе эволюции была приспособлена к зрительным образам внешнего мира, но не знакома с текстом и не адаптирована к нему.

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

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

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

Блок-схемы — графическая нотация для представления алгоритмов. Подобные схемы считаются устаревшими и не пользуются популярностью. По мнению большинства, использование блок-схем не только не ускоряет, а наоборот, тормозит процесс программирования. В итоге графическое программирование часто называют неудачным экспериментом.

Но проблема отнюдь не в графическом программировании. А в том, что блок-схемы имеют существенные недостатки. К счастью, эти недостатки можно устранить.

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

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

За счет повышенного внимания к мелким деталям графики ДРАКОН обеспечивает быстрое и легкое понимание сложного алгоритма.

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


Примечания

1. Мой перевод не дословный, а вольный, то есть отредактированный.

2. Причина редактирования в том, что, по моему мнению, в тексте Митькина есть резковатые, неосторожные выражения, которые могут вызвать возражения оппонентов.

3. Я стремился сделать русский текст более осторожным. С этой целью я ввел несколько пояснений (отсутствующих в исходном тексте).

4. Если Степан Борисович не согласен с моими правками, следует их (правки) игнорировать.

5. В этой статье Степан Борисович выдвигает новые идеи и делает смелые заявления. Я поддерживаю эти идеи и заявления. И хочу пожелать Степану Борисовичу успехов в продвижении этих идей.

6. Недостатком статьи является слишком короткий список литературы.
Желательно добавить дополнительные источники. Это объясняется тем, что необычные идеи нуждаются в дополнительном обосновании и привлечении большого количества дополнительной литературы.

Расширенный список литературы (не притянутой за уши, а только по делу) поможет убедить оппонентов, что автор знаком с современной литературой по предмету (и по смежным вопросам) и умеет тщательно обосновать свои утверждения, опираясь на авторитетные источники.

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

Уважаемые коллеги!

Желательно обсудить статью Степана Борисовича Митькина на нашем форуме.
Трудность в том, что статья на английском.
Я перевел только очень малый фрагмент статьи.


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

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

Предлагаю для обсуждения
Цитата:
Тезис Степана Митькина

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


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Есть МЭКовский язык FBD. Можете свои функции разработать. Для примера из темы рисунок на FBD выглядит примерно так. Лучше чем на Драконе, да еще реализован (в отличие) кучей коммерческих продуктов.
Неудобно говорить, что уже много раз писал. Имеет смысл делать два языка в одном флаконе: Дракон и FBD.


Вложения:
fp1.PNG
fp1.PNG [ 2.65 КБ | Просмотров: 13581 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Октябрь, 2012 23:31 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 550
Дмитрий Дагаев писал(а):
Есть МЭКовский язык FBD. Имеет смысл делать два языка в одном флаконе: Дракон и FBD.

FBD имеет важное преимущество.
Он позволяет визуально обозначать потоки данных через функции.

Возьмём наш пример:
Код:
Result = cool(foo(U), bar(V))

Недостаток этой записи в том, что в ней три действия упакованы в одну строку. Упакованы слишком плотно. Распаковка требует некоторых умственных усилий.

Можно переписать этот пример по-другому:
Код:
X = foo(U)
Y = bar(V)
Result = cool(X, Y)

Здесь каждое действие занимает одну строку. Читателю не нужно парсить сложное, обильно вложенное выражение.

Но и тут есть проблема. Длина текста возрасла за счёт появления переменных X и Y. Кроме того, читатель вынужден сканировать глазами исходный текст, чтобы выявить места, где переменные определяются и где используются.

Конечно, тот факт, что переменные в Эрланге не могут менять своего значения, серьёзно облегчает чтение. Да и современные среды разработки помогают. Они подсвечивают вхождения переменной при её выделении.

Тем не менее, FBD (functional block diagrams) намного нагляднее текста. Поток данных можно отследить пальцем. Это гораздно легче, чем своими собственными глазами (чуть не сказал "руками") искать подстроку в тексте. Путь данных виден невооружённым глазом.
Но, как всегда, есть одно "но". Неудобно делать ветвление. Здесь ДРАКОНу равных нет. Вот как бы объединить ДРАКОН и FBD?

Дмитрий Дагаев предлагает вставлять FBD внутрь икон ДРАКОНа.
Вот так:
Вложение:
fbd_in_icon.png
fbd_in_icon.png [ 50.02 КБ | Просмотров: 13558 ]

(Взято из http://drakon.su/_media/biblioteka/alaverdy_drakon.pdf).

Преимущества FBD в этом примере неочевидны.
- Блоки ИЛИ и И лучше выражены в FBD.
- ДРАКОН чётче отслеживает различные комбинации результатов проверок.

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

У меня вопрос к участникам форума, и особенно к Дмитрию Дагаеву:

Как можно объединить визуальную наглядность потоков данных FBD и чёткость ветвления ДРАКОНа?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 07 Октябрь, 2012 23:35 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 550
Владимир Даниелович, спасибо большое за перевод.
Перевод получился лучше, чем оригинал.


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Смешивать, но не взбалтывать.

1. Единый редактор, который загружает Файл.Дракон и Файл.fbd (http://forum.oberoncore.ru/viewtopic.php?f=62&t=3337), включая функциональные блоки стандарта 499.
2. Масштабирование с возможностью раскрывание внутренностей блока. Во вставленном Вами примере при увеличении масштаба иконка ВОПРОС раскрывается в FBD схему.
FBD 499 служит верхним уровнем. И может раскрыться в Дракон-схему. Мои старые примеры с раскрытием FBD 499 в Дракон на рисунках.
3. Связываем переменные на уровне кодогенераторов.
4. На этом можно строить немаленькие системы: АСУТП, тренажеры, экспертные системы диагностики http://forum.oberoncore.ru/viewtopic.php?f=62&t=3355.
5. Не забываем, что распределенные АСУТП уже так строят.


Вложения:
lev1.png
lev1.png [ 50.88 КБ | Просмотров: 13546 ]
lev0.png
lev0.png [ 26.74 КБ | Просмотров: 13546 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: ДРАКОН-FBD-Эрланг
СообщениеДобавлено: Вторник, 09 Октябрь, 2012 13:05 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 550
Дмитрий Дагаев писал(а):
Смешивать, но не взбалтывать.

То есть эта диаграмма на ДРАКОН-Эрланге:
Вложение:
first_to_upper2.png
first_to_upper2.png [ 25.51 КБ | Просмотров: 13509 ]

превращается в эту:
Вложение:
drakon_fbd.png
drakon_fbd.png [ 19.37 КБ | Просмотров: 13509 ]

Дмитрий, я правильно понимаю вашу мысль?


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

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 145
Откуда: Москва
Да, правильно. Но:
- при уменьшении масштаба это превратится в прямоугольник - иконку ДЕЙСТВИЕ,
- эргономически цветная схема на мой взгляд не совсем понятна, напрашивается присваивание (чтобы виден RETURN в конце функции, как советуют классики :) )


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

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


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

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


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

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