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

@sysghost · Регистрация: 12.01.2016

Студворк — интернет-сервис помощи студентам

Приветствую

Дракон - https://ru.wikipedia.org/wiki/... 0%9E%D0%9D

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

Вот что мне удалось найти:
Неклассическая теория алгоритмов и язык ДРАКОН

По теме микроконтроллеров:
Обсуждение ИС Дракон
ИС Дракон. Вопрос - ответ.
Приручить Дракона
Графический язык ДРАКОН для программирования микроконтроллеров
Алгоритм работы датчика температуры и влажности DHT11
AVR Dragon и PDI интерфейс
Дракон на Андроиде

...если что пропустил, извините, что google накопал.

Кроме того я читал на других форумах, в частности специализирующихся на Драконе, так что кое какие представления имею, но думаю ситуация такова, что специалистам он уже не нужен а новичкам, для кого он и создавался, создать нормальную программу не по силам. Конечно есть три более менее рабочие версии Дракона, да и тут я нашел ветку с драконоподобной средой разработки - Легкий путь к созданию блок-схем: Diagram Designer но все же хотелось бы обсудить причины по которым данная идея так и не получила широкого распространения.

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

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

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

Достоинства блочного программирования (имхо):

1. Быстрое восприятие информации и ориентирование в блок схеме программы.
2. Легкое понимание алгоритма для тех, кто с ними знаком вообще, но не знаком с программированием в частности.
3. Блочное трансформирование алгоритма, что уменьшает вероятность ошибок части кода при изменении программы так как сам код внутри блока скрыт и не может быть изменён случайно.
4. Экономия времени при изучении блок схем чужих программ или их фрагментов.
5. Возможность закрепления за каждым блоком фрагментов кода программ из разных языков программирования, да и не только кода но и любых самостоятельно заданных процедур или других данных включая специализированные команды обращения к аппаратной части. (Возможно поэтому он оказался наиболее удобен для программирования пикконтроллеров.)

Возможно Вы назовете еще некоторые существенные для вас достоинства, но я перейду к недостаткам.

Добавлено через 29 минут
Недостатки вообще и существующих реализаций в частности (имхо):

1. Отсутствие возможности автоматического импорта программного кода из других языков программирования в формат блок схем. Это является на мой взгляд самым основным недостатком из-за которого не развивается Дракон. Данный недостаток свойственен всем существующим версиям программ (имхо - возможно я ошибаюсь?).
Этот же фактор затрудняет отладку программ созданных в Драконе с помощью других программ.
2. Усложненный просмотр фрагментов кода и отсутствие подсветки синтаксиса, это то-же свойственно практически всем существующим версиям. Да, посмотреть код конечно можно, иначе было бы невозможным вобще составление программного кода, только алгоритма, но реализация на мой взгляд неудобна. Подсветки синтаксиса я не видел ни у кого, возможно ошибаюсь?
3. Компиляция конечной программы и отладка, тут тоже пусто, в лучшем случае есть простая проверка на отсутствие закрывающих тегов или явно отсутствующих частей кода.
4. Работа с VCL то-же нигде не реализована, а это основная проблема уже для новичков.
5. Интеграция в другие программы, например то-же Делфи, что то-же могло бы быть полезно для начинающих.
6. Реализация построения сложных блок схем перечеркивает изначальное удобство в визуальном восприятии, так как на некотором этапе мишура из линий и икон становится не разборчивой а попытки навести порядок приводят к еще большему хаосу. Некоторые решения (костыли) были придуманы, а именно запрет на пересечение лиан (линий соединяющих блоки), вынесение фрагментов блок схем в отдельные модули, уменьшение количества текстовой информации на теле иконок и тому подобное. Данные действия приводят к тому, что пользователь вынужден ориентироваться не в основном окне алгоритма а то и дело перескакивать по под-окнам, что перечеркивает все 4 первых пункта достоинств Дракона.
7. Увеличивается время на построение программы за щет того, что необходимо изучить и сам Дракон, и конечный язык программирования, пусть и менее детально чем это требовалось бы при программировании без вспомогательных средств визуализации.

Это возможно то-же не все, но на что хотелось бы обратить внимание в первую очередь, дополните если что.

Добавлено через 50 минут
Пути устранения недостатков, опять же по моему скромному мнению:

1. Вероятно подход к визуальному представлению блок-схем стоит изменить.

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

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

@CoderHuligan · 03.05.2018, 14:11

Сообщение от Shamil1

Вы сформулируйте задачу нормально. Возможно, её можно решить вообще без использования состояний.

Ну, вот попробуйте вот такой алгоритм6 есть 2 светодиода - красный синий. Есть 4 кнопки, которые ими управляют. А дальше всё ясно:
состояние1 - горит синий светодиод, не горит красный светодиод.
состояние2 - горит красный светодиод, не горит синий светодиод.
состояние3 - горят оба светодиода.
состояние4 - не горит ни один светодиод.

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
состояние1:
    если(нажата кнопка "включить синий светодиод") то  иди к состояние1
    если(нажата кнопка "включить красный светодиод") то {включаем красный светодиод, выключаем синий} иди к состояние2
    если(нажата кнопка "включить оба светодиода") то {включаем красный} иди к состояние3
    если(нажата кнопка "выключить оба светодиода") то {выключаем синий} иди к состояние4
состояние2:
    если(нажата кнопка "включить синий светодиод") то {включаем синий, выключаем красный}иди к состояние1
    если(нажата кнопка "включить красный светодиод") то  иди к состояние2
    если(нажата кнопка "включить оба светодиода") то  {включаем синий} иди к состояние3
    если(нажата кнопка "выключить оба светодиода") то {выключаем красный} иди к состояние4
состояние3:
    если(нажата кнопка "включить синий светодиод") то  {выключаем красный} иди к состояние1
    если(нажата кнопка "включить красный светодиод") то  {выключаем синий} иди к состояние2
    если(нажата кнопка "включить оба светодиода") то иди к состояние3
    если(нажата кнопка "выключить оба светодиода") то {выключаем оба светодиода} иди к состояние4
состояние4:
    если(нажата кнопка "включить синий светодиод") то {включаем синий} иди к состояние1
    если(нажата кнопка "включить красный светодиод") то  {включаем красный} иди к состояние2
    если(нажата кнопка "включить оба светодиода") то {включаем оба светодиода} иди к состояние3
    если(нажата кнопка "выключить оба светодиода") то  иди к состояние4

Вот такой алгоритм работы.

Сообщение от sysghost

Можно ли сказать то-же самое так, что принятые на сегодняшний день условности в построении программ и вызывают трудности творческого подхода?

Так точно!

Сообщение от sysghost

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

Совершенно верно! Существует определённые общепринятые вещи. Это как некий этикет. Если его не соблюдать тебя просто не возьмут на работу.
Некоторые языки позволяют большую свободу самовыражения, но люди изобрели совершенно другие языки, которые НАВЯЗЫВАЮТ особый стиль поведения. Взять тот же пых - PHP. Раньше там был модуль cqlite представляющий из себя базу данных пользовательского режима. Можно было обращаться к ней в процедурном стиле. В новых версиях включили модуль cqlite3 к которому теперь можно обращаться ТОЛЬКО средствами ООП посредством драйвера PDO, хотя само посебе cqlite реализовано в обычном процедурном стиле.. Об этом можно только материться, ибо нормальных слов просто нет.. Нас вынуждают использовать ООП везде, даже в простых задачах, на вроде обращения к базе данных.. А если мне оно не нравится?

Сообщение от sysghost

Думаю с точки зрения удобства это работает

Это работает через пень-колоду. Оно изобрели только для облегчения вороченьем большими обьёмами кода. Я не видел ни одной программы в ООП, которая бы не глючила по чёрному.

Сообщение от sysghost

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

Для микроконтролёров это убийственно. Тут только автоматы нужны.

Сообщение от sysghost

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

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

@Sindbad_M · 03.05.2018, 15:45

Сообщение от CoderHuligan

Ну, вот попробуйте вот такой алгоритм6 есть 2 светодиода

А это точно не контрпример? Интуитивное решение короче и лаконичней, выгода от состояний неочевидна.

C
1
2
3
4
    если(нажата кнопка "включить синий светодиод") то  {включаем синий} 
    если(нажата кнопка "включить красный светодиод") то {включаем красный}
    если(нажата кнопка "включить оба светодиода") то {включаем синий} {включаем красный}
    если(нажата кнопка "выключить оба светодиода") то {выключаем синий} {выключаем красный}

@Shamil1 · 03.05.2018, 15:54

Сообщение от CoderHuligan

Ну, вот попробуйте вот такой алгоритм6 есть 2 светодиода - красный синий. Есть 4 кнопки, которые ими управляют.

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

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
function включить синий светодиод:
    если(нажата кнопка "включить красный светодиод") то {включаем красный светодиод, выключаем синий}
    если(нажата кнопка "включить оба светодиода") то {включаем красный}
    если(нажата кнопка "выключить оба светодиода") то {выключаем синий}
    
function включить красный светодиод:
    если(нажата кнопка "включить синий светодиод") то {включаем синий, выключаем красный}
    если(нажата кнопка "включить оба светодиода") то  {включаем синий}
    если(нажата кнопка "выключить оба светодиода") то {выключаем красный}
    
function включить оба светодиода:
    если(нажата кнопка "включить синий светодиод") то  {выключаем красный}
    если(нажата кнопка "включить красный светодиод") то  {выключаем синий}
    если(нажата кнопка "выключить оба светодиода") то {выключаем оба светодиода}
    
function выключить оба светодиода:
    если(нажата кнопка "включить синий светодиод") то {включаем синий}
    если(нажата кнопка "включить красный светодиод") то  {включаем красный}
    если(нажата кнопка "включить оба светодиода") то {включаем оба светодиода}

Добавлено через 2 минуты

Сообщение от CoderHuligan

Я не видел ни одной программы в ООП, которая бы не глючила по чёрному.

Фатальное невезение или не там смотрите?

@Sindbad_M · 03.05.2018, 16:03

Сообщение от Shamil1

Ваш код закцикливается и грузит процессор на 100%

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

@sysghost · 03.05.2018, 16:07 **[ТС]**

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

@Shamil1 · 03.05.2018, 16:11

Сообщение от sysghost

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

Как и везде: сначала используете наиболее простые стандартные подходы, затем начинаете комбинировать стандартные подходы, затем начинаете придумывать свои подходы.

Ребёнку говорят: "розетку трогать нельзя"
Взрослому говорят: "розетку трогать можно, но нужно её обесточить"
Электрику-стажёру говорят: "розетку трогать можно, но в таких-то случаях её нужно обесточить"
Электрику-профессионалу ничего не говорят, он и сам всё знает.

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

@Shamil1 · 03.05.2018, 16:13

Сообщение от Sindbad_M

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

Я понял так, что "иди к" - это GOTO, за использование которого агитирует автор сообщения.

@Shamil1 · 03.05.2018, 16:16

Сообщение от sysghost

Дракон

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

@Sindbad_M · 03.05.2018, 17:05

Сообщение от Shamil1

Я понял так, что "иди к" - это GOTO, за использование которого агитирует автор сообщения.

Значит я не понял автора. Зачем весь этот огород с состояниями? Даже с GOTO, в четыре раза короче и лаконичней:

C
1
2
3
4
5
6
старт:
    если(нажата кнопка "включить синий светодиод") то  {включаем синий} 
    если(нажата кнопка "включить красный светодиод") то {включаем красный}
    если(нажата кнопка "включить оба светодиода") то {включаем синий} {включаем красный}
    если(нажата кнопка "выключить оба светодиода") то {выключаем синий} {выключаем красный}
    иди к старт

@Shamil1 · 03.05.2018, 17:29

Сообщение от Sindbad_M

Зачем весь этот огород с состояниями?

Я тоже не понимаю.

Когда я писал свой вариант, я использовал только то, что заведомо работает. Возможно, {включаем синий} вызывает ошибку, если синий уже включён. Поэтому у меня больше проверок, чем Вашем коде.

Сообщение от Sindbad_M

если(нажата кнопка "включить синий светодиод") то {включаем синий}

Кнопку могут нажать, когда оба светодиода уже горят. Правильно будет:

C
1
если(нажата кнопка "включить синий светодиод") то  {включаем синий} {выключаем красный}

При условии, что включение включенного и выключение выключенного не вызывают проблем. Но можно написать обёртку для {включаем синий} и эту проверку поместить туда.

@CoderHuligan · 03.05.2018, 20:39

Сообщение от Sindbad_M

А это точно не контрпример? Интуитивное решение короче и лаконичней, выгода от состояний неочевидна.

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

Сообщение от Shamil1

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

Не принимается, ибо задача типична для микроконтролёров.

Сообщение от Shamil1

Во-вторых, Ваш код её не решает. Ваш код закцикливается и грузит процессор на 100%.

Вы же не ребёнок и понимаете, что задача упрощена до предела, ради сути. В реальности там будут режимы ожидания, таймеры и пр.

Сообщение от Shamil1

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

Не принимается. Не понятно кто вызывает эти функции.

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

@Sindbad_M · 03.05.2018, 22:06

Сообщение от Shamil1

Я понял так, что "иди к" - это GOTO, за использование которого агитирует автор сообщения.

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

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
состояние1:
    если(нажата кнопка "включить синий светодиод") то  иди к состояние1
    если(нажата кнопка "включить красный светодиод") то {включаем красный светодиод, выключаем синий} иди к состояние2
    если(нажата кнопка "включить оба светодиода") то {включаем красный} иди к состояние3
    если(нажата кнопка "выключить оба светодиода") то {выключаем синий} иди к состояние4
    иди к состояние1
состояние2:
    если(нажата кнопка "включить синий светодиод") то {включаем синий, выключаем красный}иди к состояние1
    если(нажата кнопка "включить красный светодиод") то  иди к состояние2
    если(нажата кнопка "включить оба светодиода") то  {включаем синий} иди к состояние3
    если(нажата кнопка "выключить оба светодиода") то {выключаем красный} иди к состояние4
    иди к состояние2
состояние3:
    если(нажата кнопка "включить синий светодиод") то  {выключаем красный} иди к состояние1
   .....и т.д.

Добавлено через 36 минут

Сообщение от CoderHuligan

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

Сообщение от CoderHuligan

А как отслеживать её работу? При помощи флага или состояния, как в моём случае. Понятно?

Мне казалось очевидным что "{включаем синий}" это абстракция, которой в структурном программировании соответствует подпрограмма. Если для выполнения каких-то действий требуются проверки, то их выполняют в теле подпрограммы. Собственно это уже заметил Shamil1, да я именно это и имел в виду:

Сообщение от Shamil1

Но можно написать обёртку для {включаем синий} и эту проверку поместить туда

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

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

Добавлено через 10 минут

Сообщение от CoderHuligan

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

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

@sysghost · 04.05.2018, 00:34 **[ТС]**

Сообщение от CoderHuligan

Ну, вот попробуйте вот такой алгоритм6 есть 2 светодиода - красный синий. Есть 4 кнопки, которые ими управляют. А дальше всё ясно:
состояние1 - горит синий светодиод, не горит красный светодиод.
состояние2 - горит красный светодиод, не горит синий светодиод.
состояние3 - горят оба светодиода.
состояние4 - не горит ни один светодиод.

Ну не знаю, вопрос не мне, но на мой взгляд это должно выглядеть так:
1 шаг - назначить: порт 1 - синий светодиод, порт 2 - красный светодиод, порты 3,4,5,6 - кнопки с 1 по 4, переменная А - авария (про переключение состояние переменной я тут писать не буду что бы не усложнять просто запоминает состояние авария)
2 шаг - порты с 1 по 6 перевести в состояние Вход
3 шаг - по очереди опросить состояние входов с 1 по 6, сравнить уровень на входе с 0:
если порт 1 в состоянии 0 перевести порт 1 в состояние Выход и перейти к порту 2, иначе значение переменной а - в состояние авария
если порт 2 в состоянии 0 перевести порт 2 в состояние Выход перейти к порту 3, иначе значение переменной а - в состояние авария
...
если порт 6 в состоянии 1 - записать значение авария, иначе продолжить
4 шаг - проверить состояние переменной авария, если 1 то менять состояние портов 1 и 2 с 0 на 1 и обратно (мигать) - индикация состояния авария циклически до снятия питания, иначе продолжить
5 шаг - проверить состояние порта 3, если 1 - порт 1 перевести в состояние 1, иначе далее
проверить состояние порта 4, если 1 - перевести порт 1 в состояние 0 и перевести порт 2 в состояние 1, иначе далее
проверить состояние порта 5, если 1 - проверить состояние порта 1, если 0 - поменять состояние на 1, проверить состояние порта 2, если 0 поменять на 1, иначе далее
проверить состояние порта 6, если 1 - перевести порты 1 и 2 в состояние 0
6 шаг - перейти к шагу 5

Добавлено через 8 минут
На случай, если это не светодиоды а некие устройства, которые нельзя переключать чаще чем раз в N секунд, то:
шаг 6 - пауза в N секунд
шаг 7 - перейти к шагу 5

@Shamil1 · 04.05.2018, 02:46

Сообщение от CoderHuligan

Не принимается, ибо задача типична для микроконтролёров.

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

Сообщение от CoderHuligan

Не принимается. Не понятно кто вызывает эти функции.

Функции вызываются в цикле ожидания.

Сообщение от CoderHuligan

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

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

Сообщение от CoderHuligan

Жду лучший вариант.

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

@Shamil1 · 04.05.2018, 11:08

Вот вариант с таблицей переходов (для анализа производительности у меня недостаточно информации).

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#include <stdio.h>
typedef void (*Handler)(void);
 
// microcontroller commands
void BlueOn(void)  { printf ("Включаем синий. "); }
void BlueOff(void) { printf ("Выключаем синий. "); }
void RedOn(void)   { printf ("Включаем красный. "); }
void RedOff(void)  { printf ("Выключаем красный. "); }
 
// handlers for the signals
void BlueOnRedOn(void) { BlueOn(); RedOn(); }
void BlueOnRedNone(void) { BlueOn(); }
void BlueOnRedOff(void) { BlueOn(); RedOff(); }
void BlueNoneRedOn(void) { RedOn(); }
void BlueNoneRedNone(void) { }
void BlueNoneRedOff(void) { RedOff(); }
void BlueOffRedOn(void) { BlueOff(); RedOn(); }
void BlueOffRedNone(void) { BlueOff(); }
void BlueOffRedOff(void) { BlueOff(); RedOff(); }
 
// jump table
Handler bothOff[4] = { BlueNoneRedNone, BlueOnRedNone, BlueNoneRedOn, BlueOnRedOn };
Handler blueOn[4] = { BlueOffRedNone, BlueNoneRedNone, BlueOffRedOn, BlueNoneRedOn };
Handler redOn[4] = { BlueNoneRedOff, BlueOnRedOff, BlueNoneRedNone, BlueOnRedNone };
Handler bothOn[4] = { BlueOffRedOff, BlueNoneRedOff, BlueOffRedNone, BlueNoneRedNone };
Handler* handlers[4] = { bothOff, blueOn, redOn, bothOn };
 
int main(void) {
    Handler* current = bothOff;
    for(;;) {
        int n;
        scanf("%d", &n); // signal from microcontroller
        if(n < 0 || n > 3) break;
        current[n]();
        current = handlers[n];
        printf("Готово!\n");
    }
    return 0;
}

https://ideone.com/eMPNcL (введите последовательность входных сигналов на вкладке input)

@Sindbad_M · 04.05.2018, 11:10

Сообщение от sysghost

На случай, если это не светодиоды а некие устройства, которые нельзя переключать чаще чем раз в N секунд, то:
шаг 6 - пауза в N секунд

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

@sysghost · 04.05.2018, 12:12 **[ТС]**

Сообщение от Sindbad_M

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

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

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

@Shamil1 · 04.05.2018, 12:28

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

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#include <stdio.h>
typedef void (*Handler)(void);
 
// microcontroller commands
void BlueOn(void)  { printf ("Включаем синий. "); }
void BlueOff(void) { printf ("Выключаем синий. "); }
void RedOn(void)   { printf ("Включаем красный. "); }
void RedOff(void)  { printf ("Выключаем красный. "); }
 
// handlers for the signals
void BlueOnRedOn(void) { BlueOn(); RedOn(); }
void BlueOnRedNone(void) { BlueOn(); }
void BlueOnRedOff(void) { BlueOn(); RedOff(); }
void BlueNoneRedOn(void) { RedOn(); }
void BlueNoneRedOff(void) { RedOff(); }
void BlueOffRedOn(void) { BlueOff(); RedOn(); }
void BlueOffRedNone(void) { BlueOff(); }
void BlueOffRedOff(void) { BlueOff(); RedOff(); }
 
// jump table
Handler bothOff[4] = { 0, BlueOnRedNone, BlueNoneRedOn, BlueOnRedOn };
Handler blueOn[4] = { BlueOffRedNone, 0, BlueOffRedOn, BlueNoneRedOn };
Handler redOn[4] = { BlueNoneRedOff, BlueOnRedOff, 0, BlueOnRedNone };
Handler bothOn[4] = { BlueOffRedOff, BlueNoneRedOff, BlueOffRedNone, 0 };
Handler* handlers[4] = { bothOff, blueOn, redOn, bothOn };
 
int main(void) {
    Handler* current = bothOff;
    for(int n;;) {
        scanf("%d", &n); // signal from microcontroller
        if(n < 0 || n > 3) break;
        if(current[n]) {
            current[n]();
            current = handlers[n];
        }
        printf("Готово!\n");
    }
    return 0;
}

https://ideone.com/g8KynM

@sysghost · 04.05.2018, 12:49 **[ТС]**

2 Sindbad_M
Но если Вы хотели этим примером донести мысль о том, что для управления двумя и более разными процессами требующими задержек в времени линейное выполнение программы не годится, это я понимаю.
Кроме предложенного варианта с сохранением текущего времени и сравнением в каждом цикле вижу еще одно решение.
Мы можем производить опрос кнопок с минимальным временем, которое будет задаваться паузой как у меня в шаге 6 но при этом в шаге 7 добавлять 1 к двум переменным отвечающим за время задержки если они активны а перед переключением в новое состояние проверять значения этих переменных с тем, что если их значение меньше N/x, где N по прежнему время, требуемое для задержки, то переключение не проводить, иначе провести переключение и обнулить переменную времени задержки конкретного порта.
Это возможно сложнее чем отслеживать текущее время, но просто как вариант.

Добавлено через 2 минуты

Сообщение от Shamil1

ИМХО данная оптимизация имеет смысл, только если в подавляющем большинстве случаев по-прежнему нажата та же кнопка.

А если нажаты две или более?

@Shamil1 · 04.05.2018, 13:39

Сообщение от sysghost

А если нажаты две или более?

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

Новые блоги и статьи Все статьи Все блоги /
Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Jin X 06.09.2026 Скрипты Tampermonkey для CyberForum, ChatGPT, Claude и пр. Работая с форумом и нейросетями в браузере часто хочется что-то подкорректировать или добавить какого-то функционала. Ниже прикреплён. . .	Программа опроса у.з. расходомера SLS-720F Argus19 02.09.2026 Программа опроса у. з. расходомера SLS-720F Программа опрашивает один раз в минуту три ультразвуковых расходомера SLS-720F через интерфейс RS-485 по протоколу Modbus RTU. Опрашиваются регистры. . .	Hyper-V: Компьютер должен поддерживать доверенный платформенный модуль 2.0. Maks 31.08.2026 При установке Windows 11 на виртуальную машину Hyper-V 2-го поколения вылезла такая ошибка: Решение: в параметрах виртуальной машины, в разделе "Безопасность" (Security) активировать флаг. . .	Архитектура биовида Стива в Майнкрафте: Зачем бонобо кубический каннибализм anaschu 30.08.2026 Кубический Вагинокапитализм в Minecraft: Математический инвариант ОДУ и рок Стивов-бонобо Главная задача разработанной «Модели Всего» — наглядно продемонстрировать наличие системной «судьбы». . .
Оттачиваю умение писать js программы. russiannick 30.08.2026 Проектом выходного дня стало написание Книги шифров Виженера. Итогом стала версия 200, синий туман. Синий туман назван так, потому что замораживает текст под собой. Нажатие синих кнопок управляют. . .	мат медиц модель 30. презентация проекта anaschu 27.08.2026 хоп хоп хоп хидахоп, а я кладую))	Как у меня протекала болезнь zorxor 27.08.2026 Здравствуйте, друзья! Эта запись блога предназначена именно для вас - для моих дорогих друзей, которые знали меня лично. Чтобы ответить на вопрос - а что же со мной произошло на самом деле? Я учился. . .	Нашел вот забавное видео о измерениях. Лучшее что я видел на эту тему kumehtar 26.08.2026 ILETXiw9bMQ Основная суть и тезисы по измерениям: 0D (Нулевое измерение): точка, не имеющая длины, ширины, высоты или объема. Объект не может перемещаться в 0D. 1D (Первое измерение):. . .

@sysghost 40 / 40 / 6 Регистрация: 12.01.2016 Сообщений: 406

	Дракон - визуальный алгоритмический язык программирования и моделирования 26.04.2018, 21:12. Показов 9769. Ответов 65 Метки dragon, алгоритм, блок схема, визуализация разработки, дракон, программа, среда программирования (Все метки) Приветствую Дракон - https://ru.wikipedia.org/wiki/... 0%9E%D0%9D Захотел найти на вашем форуме информацию по данному языку и понял что тут его особо не жалуют, только кое где он пришелся по душе при программировании пик-контроллеров. Вот что мне удалось найти: Неклассическая теория алгоритмов и язык ДРАКОН По теме микроконтроллеров: Обсуждение ИС Дракон ИС Дракон. Вопрос - ответ. Приручить Дракона Графический язык ДРАКОН для программирования микроконтроллеров Алгоритм работы датчика температуры и влажности DHT11 AVR Dragon и PDI интерфейс Дракон на Андроиде ...если что пропустил, извините, что google накопал. Кроме того я читал на других форумах, в частности специализирующихся на Драконе, так что кое какие представления имею, но думаю ситуация такова, что специалистам он уже не нужен а новичкам, для кого он и создавался, создать нормальную программу не по силам. Конечно есть три более менее рабочие версии Дракона, да и тут я нашел ветку с драконоподобной средой разработки - Легкий путь к созданию блок-схем: Diagram Designer но все же хотелось бы обсудить причины по которым данная идея так и не получила широкого распространения. Так-же хотелось бы все-же обсудить саму идею и поделиться своими соображениями почему верхи не хотят а низы не могут... Я предлагаю всем желающим тезисно высказаться что именно им не нравится и что нравится в Драконе, плюс хотелось бы услышать идеи как все же вдохнуть жизнь в Дракона. Просьба излагать свои мысли понятно для всех. Добавлено через 24 минуты Изложу некоторые свои соображения по поводу визуального представления алгоритмов. Конечно это не ново но хочу подытожить. Итак, блок схемы принято составлять из отдельных фрагментов - иконок (графических единиц, блоков программы) наглядно отображающих элементарные ячейки программы, подробнее Вы можете прочитать в Википедии, ссылка в первом посте темы. Достоинства блочного программирования (имхо): 1. Быстрое восприятие информации и ориентирование в блок схеме программы. 2. Легкое понимание алгоритма для тех, кто с ними знаком вообще, но не знаком с программированием в частности. 3. Блочное трансформирование алгоритма, что уменьшает вероятность ошибок части кода при изменении программы так как сам код внутри блока скрыт и не может быть изменён случайно. 4. Экономия времени при изучении блок схем чужих программ или их фрагментов. 5. Возможность закрепления за каждым блоком фрагментов кода программ из разных языков программирования, да и не только кода но и любых самостоятельно заданных процедур или других данных включая специализированные команды обращения к аппаратной части. (Возможно поэтому он оказался наиболее удобен для программирования пикконтроллеров.) Возможно Вы назовете еще некоторые существенные для вас достоинства, но я перейду к недостаткам. Добавлено через 29 минут Недостатки вообще и существующих реализаций в частности (имхо): 1. Отсутствие возможности автоматического импорта программного кода из других языков программирования в формат блок схем. Это является на мой взгляд самым основным недостатком из-за которого не развивается Дракон. Данный недостаток свойственен всем существующим версиям программ (имхо - возможно я ошибаюсь?). Этот же фактор затрудняет отладку программ созданных в Драконе с помощью других программ. 2. Усложненный просмотр фрагментов кода и отсутствие подсветки синтаксиса, это то-же свойственно практически всем существующим версиям. Да, посмотреть код конечно можно, иначе было бы невозможным вобще составление программного кода, только алгоритма, но реализация на мой взгляд неудобна. Подсветки синтаксиса я не видел ни у кого, возможно ошибаюсь? 3. Компиляция конечной программы и отладка, тут тоже пусто, в лучшем случае есть простая проверка на отсутствие закрывающих тегов или явно отсутствующих частей кода. 4. Работа с VCL то-же нигде не реализована, а это основная проблема уже для новичков. 5. Интеграция в другие программы, например то-же Делфи, что то-же могло бы быть полезно для начинающих. 6. Реализация построения сложных блок схем перечеркивает изначальное удобство в визуальном восприятии, так как на некотором этапе мишура из линий и икон становится не разборчивой а попытки навести порядок приводят к еще большему хаосу. Некоторые решения (костыли) были придуманы, а именно запрет на пересечение лиан (линий соединяющих блоки), вынесение фрагментов блок схем в отдельные модули, уменьшение количества текстовой информации на теле иконок и тому подобное. Данные действия приводят к тому, что пользователь вынужден ориентироваться не в основном окне алгоритма а то и дело перескакивать по под-окнам, что перечеркивает все 4 первых пункта достоинств Дракона. 7. Увеличивается время на построение программы за щет того, что необходимо изучить и сам Дракон, и конечный язык программирования, пусть и менее детально чем это требовалось бы при программировании без вспомогательных средств визуализации. Это возможно то-же не все, но на что хотелось бы обратить внимание в первую очередь, дополните если что. Добавлено через 50 минут Пути устранения недостатков, опять же по моему скромному мнению: 1. Вероятно подход к визуальному представлению блок-схем стоит изменить. а) Исключить возможность перетаскивания блоков вручную. Для этого нужно отойти от существующих гостов на построение подобных схем как устаревших полностью или частично. Под частичным я понимаю сохранение самих иконок для быстрого распознавания блоков но они не должны быть заодно и телом блока. Сама структура блоков должна быть более упорядоченная и выстраиваться самой программой по строгим законам. Варианты таких структур я приведу позже. Это как раз одна из тем обсуждения. б) Конечный пользователь должен иметь возможность самостоятельно создавать как сами блоки так и назначать соответствующий программный код каждому блоку. Хотя конечно изначально программа должна содержать базовые наборы как блоков так и возможность добавлять нужный программный код. Думаю нормальным будет если пользователь будет иметь возможность опционально подгружать нужный программный код по желанию и дополнять его своими наборами фрагментов кода но при этом основной пакет кода будет защищен от редактирования. Возможны варианты. в) Возможность автоматического сопоставления импортируемого кода с имеющимися заготовками для данного конкретного языка и заготовками самого пользователя и представление результата в виде графической блок-схемы Дракон. Само такое графическое представление будет возможным и удобным только при выполнения пункта а, а именно наличия механизма размещения блоков автоматически и строго по определенным законам. При этом не распознанные фрагменты можно то-же представлять графически в виде не распознанных блоков с возможностью их дальнейшей ручной идентификации. г) Отображение содержимого (фрагмента кода программы) блока в постоянно присутствующем окне с кодом всей программы и разумеется с поиском и подсветкой синтаксиса. Сам механизм такой реализации придуман (то-же FireBug для Mozilla или встроенный анализатор кода Хромоногого), то есть при клике или наведении мыши на блок - выделение кода в теле программы соответствующего данному блоку. При этом для редактирования самого пользовательского кода фрагмента или его комментирования должно вызываться отдельное окно. Таким образом будет возможным одновременно видеть и код самой основной программы и блок схему. д) Перемещение по лианам (линиям соединения блоков) по клику по лиане не требуется, для быстрого перемещения по линиям достаточно клика по точкам входа в два соединяемых блока, в конечном итоге нужно начало и конец лианы а не где и как она петляет. Кроме того случайный клик по блок схеме в токе прохождения другой лианы приведет к перемещению к не интересующему блоку. е) При наличии постоянно присутствующего она программы желательно вести проверку кода на лету, насколько это возможно и реализовано в других редакторах кода. ж) Максимально освободить основное окно программы от лишних элементов управления а управление реализовать через контекстное меню. з) Реализация обмена данными с внешними аппаратными устройствами, такими как микроконтроллеры например через блоки управления драйверами реализуемыми самим пользователем а не жестко заданными программой. Очевидно в таком случае нужно создать наборы заготовок таких блоков. и) Ну и само собой возможность распечатки блок схем в бумажном виде для изучения без компьютера. Конечно этот список можно продолжать, но как мне видно требуется комплексный пересмотр подхода к реализации Дракона, существующие варианты показали свою малую жизнеспособность. Это был список основных тезисов, каковы мне видятся на момент написания, идеи по детальной реализации некоторых этих пунктов я изложу позже (у меня их есть немного), кроме того хотелось бы услышать и ваши идеи и замечания. Позже я постараюсь графически изобразить как должна на мой взгляд строиться блок-схема и по каким алгоритмам, ведь и тут нужен алгоритм), а пока, пока. 0

@sysghost 40 / 40 / 6 Регистрация: 12.01.2016 Сообщений: 406
	03.05.2018, 16:07 [ТС]
	Опять не совсем то, если уж сравнивать то с Лисп-ом. Только все это не то что я хотел бы, да Лисп ближе всего, но и он имеет свой синтаксис, я же хотел бы что бы пользователь сам назначал синтаксис (и не синтаксис да-же а понятные конкретно ему названия и обозначения как это делается в обычных алгоритмах ) и сам его привязывал к имеющимся вариантам кода как он того желает. И это будет уже не синтаксис а обычный алгоритм. При этом будут и базовые решения и пользовательские. 0