DRAKON.SU

Текущее время: Четверг, 17 Июнь, 2021 10:44

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




Начать новую тему Ответить на тему  [ Сообщений: 49 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 09 Октябрь, 2017 17:25 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Alexey_Donskoy писал(а):
Владимир Ситников писал(а):
Вы о том, что "нет смысла в Драконе, т.к. он в любом реальном проекте займёт не более 1%"?
Нет, только о том, что применение инструмента должно быть оправданным.

Во во. Я и думаю, что Дракон может быть применим для разнообразных ПЛК алгоритмов. А может и не быть. Это, конечно, надо понять.
Но, прежде чем применять, там вообще был вопрос "а не будет ли оно перезагружаться". Его, наверное, можно считать закрытым, т.е. следующий вопрос "а есть ли в ПЛК задачи, для которых Дракон уместен".

Вот пример: у меня в квартире 12 DI (кнопки, датчики), 6 AO (яркость света). Ну и муторно всё это на ST писать. Там из требований: "к вечеру яркость должна снижаться, но должна быть возможность включить полную". "Если свет включился по датчику, то выключается через 2 минуты, а, если вручную, то через 30". И т.п.
Да, как-то написал, как-то работает, но мутный код получается.
Будет ли лучше с Драконом? Хз. Может, и будет. SFC редактор в CoDeSys вообще неудобный, поэтому там только ST и остаётся.

Цитата:
И никого не знаю, кто бы работал на IL (и для чего его выгодно было бы применить).

Моя догадка:
1) Сделать ПЛК, поддерживающий "только IL" гораздо проще, чем ПЛК, поддерживающий другие языки.
2) IL может служить как "ассемблер для ПЛК". Ну, байткод и т.п. Не для "рукописного кода", а чтобы "в него генерировать".

Alexey_Donskoy писал(а):
Сам я всегда ST выберу :)

Ну, у меня наличие ST было определяющим при выборе ПЛК.

Alexey_Donskoy писал(а):
Но для потока управления визуальный SFC не даёт принципиальных преимуществ перед текстовым ST. И зачем он тогда?

Но слишком уж вычурно выглядят эти приседания с TON/TOF, когда нужна "просто пауза".
Для задач "обработки какого-нибудь протокола" на ST это будет CASE с разнообразными переходами.
Если он будет разбавлен паузами, ожиданиями, то и не сказать, что "ST код хорошо читаем".
Как раз в этом плане,

Alexey_Donskoy писал(а):
Предлагать же нечто третье из той же серии - ну если только это даст какие-то ОЧЕНЬ большие бонусы.
ИМХО, разумеется.

Это точно. Я вот и смотрю есть ли вообще примеры, когда Дракон будет давать какие-нибудь плюсы.
Но, факт остаётся фактом: отзывов на Дракон варианты схем нет. Возможно, и в самом деле оно никому не нужно.

Alexey_Donskoy писал(а):
Цитата:
Сейчас бета-тестируют вариант с прошивкой MasterScada.
О, интересно!

Собственно, ссылка: http://www.owen.ru/catalog/97633842. Там же ссылка на форум: http://www.owen.ru/forum/showthread.php?t=26220
По факту, они запустили Linux, в нём Lua. Ну и 61131 компилируют в Lua код.


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Alexey_Donskoy писал(а):
Цитата:
зачем вообще тогда нужно 61131, если есть C?
Затем, что С - принципиальное зло. Даже при грамотном подходе разработка надёжных приложений на нём крайне затруднена.

Цитата:
Ну я и не предлагаю составлять программу целиком на Драконе. Скорее, в духе SFC, когда на SFC рисуется общая схема, а конкретные действия уже на каких-то 61131 языках.
А как вы думаете, почему в стандарт включены столь разные языки?
Очевидно, потому, что ни один из них не годится на все случаи жизни.

Я сначала подумал, что вы, быть может, ругаете людей, которые едва программируют на 61131 и говорите, что "если они не умеют программировать, то им вообще ничто не поможет".

Но, если всё же рассматривать со стороны "определённые языки могут быть полезны для определённых задач", то возникает ненулевая вероятность, что "взамен SFC-ST связки" может больше подойти "Дракон-ST".


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

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Владимир Ситников писал(а):
Я сначала подумал, что вы, быть может, ругаете людей, которые едва программируют на 61131 и говорите, что "если они не умеют программировать, то им вообще ничто не поможет".
Ну, так тоже можно сказать. Если они не представляют чётко, как ТП в ПЛК выполняется, то никакой визуальный инструмент не спасёт.
А если представляют и умеют, то, в общем, без разницы получается.

Цитата:
"взамен SFC-ST связки" может больше подойти "Дракон-ST".
А вот как раз об этом я писал выше: масло масляное.
И то, и другое - связки бесполезные.
Более того, они вредные - потому как единство стиля нарушается, труднее обозреть программу, легче сделать серьёзные ошибки и не заметить их.
Связки FBD+(ST,SFC,Дракон) - пожалуйста. Скажем, регулирование удобнее в FBD описывать, а временную логику - в ST.


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Alexey_Donskoy писал(а):
А если представляют и умеют, то, в общем, без разницы получается.

Тут тоже некая ниша может быть. Код можно в блокноте писать, а можно в IntelliJ IDEA. Только не говорите, что "без разницы" =)

Alexey_Donskoy писал(а):
Связки FBD+(ST,SFC,Дракон) - пожалуйста. Скажем, регулирование удобнее в FBD описывать, а временную логику - в ST.

Понял о чём вы говорите. Т.е. по-вашему вопрос не в том, что "Дракон сложно-невозможно" использовать в этой области, а в том, что ST/SFC и так лучше.
Возможно.
Возможно, более перспективным будет добавить async/await в ST так, чтобы можно было прямо посреди кода писать "пауза на N секунд", а компилятор сам превращал код в автоматную форму.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Октябрь, 2017 19:24 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
Владимир Ситников писал(а):
Тут тоже некая ниша может быть. Код можно в блокноте писать, а можно в IntelliJ IDEA.
Разумеется.
Но здесь выходит вот что. Я пытался приблизительно оценить эргономику работы с Драконом, и получилась забавная картинка: от 30% до 50% затрат у меня занимает решение совершенно левых задач - лишней сложности, привнесённой особенностями инструмента.
То есть вдобавок к основной алгоритмической задаче мне приходится почти столько же думать о том, как красиво отобразить (да что там красиво, вообще отобразить это на плоскости с учётом запретов на пересечения и т.п.), попутно решая квесты на тему "как добавить развилку в середину сложного переплетения "лиан".
Подчёркиваю, инструмент (Ты-среда) - не самая большая сложность. Самая большая - как всё развести на плоскости по правилам Дракона.
И это на маленьких, вполне обозримых задачах.
А на больших - сложность разводки будет возрастать экспоненциально.
Не могу оценить, насколько быстрее я решаю алгоритмические задачи на визуальном языке по сравнению с текстовым, но думаю, что лишняя сложность перекрывает все выгоды...

Цитата:
Возможно, более перспективным будет добавить async/await в ST так, чтобы можно было прямо посреди кода писать "пауза на N секунд", а компилятор сам превращал код в автоматную форму.
Однозначно. Это правильный путь со всех точек зрения.


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Alexey_Donskoy писал(а):
Но здесь выходит вот что. Я пытался приблизительно оценить эргономику работы с Драконом, и получилась забавная картинка: от 30% до 50% затрат у меня занимает решение совершенно левых задач - лишней сложности, привнесённой особенностями инструмента.

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

Alexey_Donskoy писал(а):
Подчёркиваю, инструмент (Ты-среда) - не самая большая сложность. Самая большая - как всё развести на плоскости по правилам Дракона.

Скажем так: ПЛК это по сути автомат, а писать автоматный код вручную тяжеловато. Вроде, последовательный код должно быть писать гораздо проще, (ну проще написать действие1;пауза;действие2, чем аналогичный, который проверяет "прошла ли пауза"). Но, посмотрим. Будут попадаться ПЛК задачи, может, попробую оформить в виде Дракон схем.

Например, "задача про насосы", вроде несложно разложилась в Ты-среде и основное время ушло на придумывание того "где же должен заканчиваться цикл", "а должен ли быть экземпляр процесса управления насосом единственный или по одному экземпляру на насос" ну и на борьбу со средой. Но, конечно, остался осадочек от того, что "непонятно в какой переменной сохраняется номер фактически работающего насоса" (т.е. из основного процесса приходится выключать все, либо как-то объявлять переменные -- ну и начнётся та же лабуда что в 61131 c VAR_INPUT, VAR_OUTPUT и т.п.).

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

Alexey_Donskoy писал(а):
Цитата:
Возможно, более перспективным будет добавить async/await в ST так, чтобы можно было прямо посреди кода писать "пауза на N секунд", а компилятор сам превращал код в автоматную форму.
Однозначно. Это правильный путь со всех точек зрения.

Вы, кстати, думали над async/await/coroutines в своей среде?
Конечно, те, "кто не боится ST" и без async/await напишут. Не так красиво будет, но напишут.
Некий минус в том, "тех, кто боятся ST" (а таких много) будет тяжело затащить не эту поляну.
А на связку "Дракон+CFC" их заманить гораздо проще.


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

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

Цитата:
Вы, кстати, думали над async/await/coroutines в своей среде?
Ни в одной из моих сред за десятки лет не возникало таких проблем. Всякие паузы и прочие выдержки времени элементарно и незаметно для пользователя решаются локальными переменными-счётчиками, привязанными либо к модельному циклу, либо часам реального времени (в т.ч. тикам процесора).
Это при том, что у меня в основном FBD, которая каждый цикл просчитывается полностью (ну или какие-то пути графа можно для ускорения расчёта пропускать по условию).

Вообще, ИМХО, FBD для инженеров в огромном количестве задач всяко проще и удобнее алгоритмически ориентированных языков.


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5175
Откуда: Москва
viewtopic.php?f=142&t=6092


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5175
Откуда: Москва
Владимир Ситников на Easyelectronics http://forum.easyelectronics.ru/viewtop ... 47#p475747 писал(а):
Касательно, эргономики:
текущая Дракон ИС подходит для рисования самого алгоритма на Драконе, но вот программировать конечную программу вряд ли удобно.

Всю тему не перечитывал, но в Дракон ИС нет "подсветки синтаксиса", "нет поиска", "нет автодополнения", "нет проверки на ходу" и т.п.

Навигация от ошибки C компилятора в проблемный блок Дракон схемы? Не, не слышали.

Отладка Дракон схемы в Дракон редакторе? Туда же.

Что если сделать редактор языка Дракон на базе JetBrains MPS?
MPS это как раз среда для создания языков программирования.

При этом, в самой платформе MPS заложены основные моменты. Автодополнение, поиск использований, проверка (поиск ошибок) на ходу и многое другое.

Я, например, в свободное время занимаюсь разработкой среды для программирования микроконтроллеров на языках группы МЭК 61131 (ST и т.п.).

Так вот: вполне может оказаться, что вместо языка SFC стоит сделать ДРАКОН.

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

Вот пример: Изображение
Тут "PROGRAM, variables" это ST язык, а диаграмма посредине это "язык диаграмм".

При этом, надпись R_TRIG это не просто текстовая надпись, а на неё можно щёлкнуть и перейти к определению соответствующего блока R_TRIG (в конкретном случае, блок написан на ST, но не суть).

Есть желающие помочь с разработкой/тестированием? (вопрос, скорее, по части Дракон редактора на базе MPS, но и по части 61131 тоже буду рад помощи

Владимир, насчет JetBrains MPS — эта идея еще в силе?
Или нет?


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Паронджанов писал(а):
Владимир, насчет JetBrains MPS — эта идея еще в силе?
Или нет?

Как я говорил, у меня не было цели "просто создать Дракон редактор чтобы был".
Была мысль использовать язык Дракон для использования в ПЛК программах.

Нужен ли там Дракон -- это как раз непонятно.


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Решил посмотреть какого сорта нужны структуры данных для хранения Дракон-схем и набросал прототип.

Пока пришёл к таким выводам:
1) Для указания циклов нужны пары "метка - goto". В графике, конечно, нужно рисовать простой стрелкой
2) "Выбор" (switch) -- непонятная штука. Особенно непонятно, где заканчивается этот самый выбор. Это к вопросу о том, является ли возврат "в середину switch" или это "просто возврат"
3) Пока непонятно как сочетать "текстовое пояснение" и "реальный код". Иногда удобно прямо код писать, иногда текст.

Получилось такое:
Вложение:
выбор_редактора_текст.png
выбор_редактора_текст.png [ 229.35 КБ | Просмотров: 8415 ]


Вложение:
затопление_насосной_текст.png
затопление_насосной_текст.png [ 125.64 КБ | Просмотров: 8415 ]


Вложение:
поиск_символа_текст.png
поиск_символа_текст.png [ 62.51 КБ | Просмотров: 8415 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 14 Октябрь, 2017 21:02 
Аватара пользователя

Зарегистрирован: Среда, 09 Ноябрь, 2016 00:33
Сообщения: 114
Откуда: Tallinn
я как то думал на тему как хранить данные дракон схем в текстовом формате, сделал парсер https://github.com/raydac/drakono


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Игорь Мазница писал(а):
я как то думал на тему как хранить данные дракон схем в текстовом формате, сделал парсер https://github.com/raydac/drakono

Интересный подход.

У меня больше вопрос был в таком направлении: на картинке "затопление_насосной_текст.png" используется конструкция "ErrorFlag=TRUE". Я хочу, чтобы в подобных случаях это был не текст, а прямо ссылка на какую-то настоящую переменную. Так, чтобы можно было "найти все использования" этой переменной и т.п.

И тут возникает несколько побочных эффектов:
1) Если требовать корректности кода, то сами переменные где-то должны быть объявлены. Ну я и прицениваюсь "где их объявлять".
Вроде как "в драконе принято" объявлять "параметры схемы" выноской справа у кружка "начало".

2) При фактическом наборе текста нужно, чтобы среда правильно поняла печатаем ли мы просто текст, или мы печатаем код.

3) Элементы типа "ввод", "вывод" слишком уж свободные. По-хорошему, там же не произвольный текст должен быть. А ссылки на объявленные сущности. И возникает резонный вопрос: а на какие сущности разумно ссылаться. Где-то должен быть объявлен перечень агентов и их свойств (ну, у кого что можно получить и кому что отправить)?

4) В "for-цикле" тоже неоднозначно "где именно" объявляются переменные


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5175
Откуда: Москва
Владимир, посмотрите Описание формата drt, которое составил Эдуард Ильченко (8 страниц) — по состоянию на март 2016 г.
http://drakon.su/programma_is_drakon#op ... ormata_drt


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Встроил "Д-схему" в МЭК блок.
Видео можно посмотреть тут: http://recordit.co/NuKIU34mZK

На видео показано следующее:
а) 0:48 Использование МЭК переменных в "Д-схеме".
Вложение:
мэк_переменные.png
мэк_переменные.png [ 81.27 КБ | Просмотров: 8388 ]

б) 1:00 Код можно писать как во вспомогательной области, так и в основной.
в) 2:40 "поиск использований переменной".
Вложение:
поиск_использований.png
поиск_использований.png [ 167.31 КБ | Просмотров: 8388 ]

Вложение:
использования.png
использования.png [ 83.64 КБ | Просмотров: 8388 ]

г) 2:56 "переименование переменной". Т.е. меняем название переменной в месте её объявления, и в Д-схеме она обновляется автоматом


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

Зарегистрирован: Понедельник, 14 Декабрь, 2015 19:18
Сообщения: 126
А может ли Ваш редактор стать заменой программированию на Си?

Разверну мысль.

1) Данность
У меня на прошлом месте работы в одном отделе использовался(используется) язык программирования Си.
Модифицируется программа, которая закачивается на контроллер, который:
-управляет задвижками,
-уставками
-и т.п.
в автоматизированной системе, отвечающей за добычу и распределение нефтепродуктов.

2) Понимание
Я когда смотрел код - там сплошные алгоритмы! "Если так, делай то", "исходя из появления таких-то условий включай это".
Там много кода, много файлов. Причем, как я понял, динамическим выделением памяти там не пользовались.
И к каждой строчки этих куч алгоритмов комментарий! Теперь я понимаю какой это ужас!

3) Потребность
После прочтения "Чистого кода" я понял, что программа должна быть самодокументирована - и методы, и переменные можно назвать так, чтобы без комментариев было всё понятно.
Но, даже сделав так всё-равно будет куча текста кода и только лишь разработчик этой системы, проработавшей над её созданием и модификацией лет 5, понимает все нюансы. При очередной модификации он лезет в эти тонны кода, пытаясь вспомнить все нюансы и даже ему это не сразу дается!

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 16 Октябрь, 2017 11:24 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Невзоров писал(а):
А может ли Ваш редактор стать заменой программированию на Си?

Это коварный вопрос. Звучит почти так же, как "а может ли язык Дракон стать заменой программированию на Си?"
По-моему, Дракон заменой программированию на Си стать не может.
Дополнением -- возможно.

Технически, реализация Си для MPS уже есть (см http://mbeddr.com/ ), то есть можно сделать так, чтобы Дракон-схемы выступали как один из способов записи функций в проекте на Си.

Владимир Невзоров писал(а):
У меня на прошлом месте работы в одном отделе использовался(используется) язык программирования Си.

Т.е. актуальность пропала :-)


Владимир Невзоров писал(а):
Я когда смотрел код - там сплошные алгоритмы! "Если так, делай то", "исходя из появления таких-то условий включай это".
Там много кода, много файлов. Причем, как я понял, динамическим выделением памяти там не пользовались.
И к каждой строчки этих куч алгоритмов комментарий! Теперь я понимаю какой это ужас!

Я не зря тут прошу конкретные примеры ПЛК программ. Да, возможно, что запись каких-нибудь из функций на Драконе упростила бы понимание.
Возможно, где-то больше подойдут автоматы (state machines: https://vimeo.com/78412221 )



Владимир Невзоров писал(а):
После прочтения "Чистого кода" я понял, что программа должна быть самодокументирована - и методы, и переменные можно назвать так, чтобы без комментариев было всё понятно.
Но, даже сделав так всё-равно будет куча текста кода и только лишь разработчик этой системы, проработавшей над её созданием и модификацией лет 5, понимает все нюансы. При очередной модификации он лезет в эти тонны кода, пытаясь вспомнить все нюансы и даже ему это не сразу дается!

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

2) Причины, что алгоритм именно такой. Иными словами, Д-схема отвечает на вопрос "каким образом мы решаем задачу", но она не отвечает на вопросы "а зачем здесь понадобилась такая-то проверка" или "а почему эти два действия выполняются именно в таком порядке, а не наоборот". Всегда есть требования (например "запуск мотора должен выполняться при нажатом тормозе"), и по-хорошему, в программе должны быть отсылки к этим требованиям.
Так, чтобы по действию можно было понять из-за какого требования оно сделано, и наоборот: по требованию понять где оно встречается в коде.
Пример такого можно посмотреть тут: https://vimeo.com/78415217

Так вот: да, Дракон-схему можно дополнить ссылками на требования, но ссылки на требования можно ставить и в обычном коде. Иными словами Дракон сам по себе не упрощает понимание требований.


Владимир Невзоров писал(а):
Собственно, вопрос.
Может ли Ваш ДРАКОН-редактор стать заменой этой писанины и куче Си файлов и их взаимосвязям, чтобы было просто - что-то вроде листа ДРАКОН-схемы взамен одного файла, где всё ясно и понятно?!

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


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

Зарегистрирован: Понедельник, 14 Декабрь, 2015 19:18
Сообщения: 126
Цитата:
2) Причины, что алгоритм именно такой. Иными словами, Д-схема отвечает на вопрос "каким образом мы решаем задачу", но она не отвечает на вопросы "а зачем здесь понадобилась такая-то проверка" или "а почему эти два действия выполняются именно в таком порядке, а не наоборот". Всегда есть требования (например "запуск мотора должен выполняться при нажатом тормозе"), и по-хорошему, в программе должны быть отсылки к этим требованиям.
Так, чтобы по действию можно было понять из-за какого требования оно сделано, и наоборот: по требованию понять где оно встречается в коде.
Пример такого можно посмотреть тут: https://vimeo.com/78415217

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

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

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

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

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

Да... "Процесc vs Момент".
Я выбираю процесс!


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

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 200
Владимир Невзоров писал(а):
Цитата:
См. выше. Сделать так, чтобы Дракон-схемы выступали как один из альтернативных языков записи Си-функций -- можно. Станет ли программа проще, если её целиком написать в виде Дракон-схемы? Вот тут сомневаюсь.

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

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

Это я к чему? Я к тому, что не будет "универсального языка на все случаи жизни".

Если речь о решении квадратного уравнения, то пара строк на Си будут гораздо понятнее, чем куча квадратиков на Драконе.
Если же говорить, что "Си это текст, а Дракон это графика, которая легче воспринимается", то и тут можно пример привести:
Вложение:
math.png
math.png [ 24.38 КБ | Просмотров: 8336 ]


Функция на Си с формулой может выглядеть гораздо понятнее, чем "куча Дракон-блоков, в каждом из которых ещё и код скрыт".


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

Зарегистрирован: Понедельник, 14 Декабрь, 2015 19:18
Сообщения: 126
Цитата:
Если речь о решении квадратного уравнения, то пара строк на Си будут гораздо понятнее, чем куча квадратиков на Драконе.


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

Сейчас пытаюсь понять предмет "алгоритмы и структуры данных".
Для меня это очень большая и не познанная область.
Сейчас дошел в учебнике до описания АВЛ деревьев.
Читаю что это такая то штука, что есть операции поиска, вставки и т.п. но суть я не понимаю ни на 1%.

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

Цитата:
Взять ту же задачу "описания требований". Вы что, предлагаете требования описывать на Драконе? Какой в этом смысл?
У требования есть "название", "описательная часть". Какой смысл при этом вкладывать эти же самые слова в квадратики?

Что касается требований. Честно говоря, я понял для себя "требования" что-то в духе:

Вложение:
ссылка на требования.png
ссылка на требования.png [ 15.15 КБ | Просмотров: 8329 ]


Есть иконка. Есть комментарий с ссылкой п.3


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

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


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

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


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

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