DRAKON.SU

Try DRAKON and particularly DRAKON Editor for making diagrams. It can also generates code from diagrams. It supports visual programming in several programming languages, including Java, Processing.org, D, C#, C/C++ (with Qt support), Python, Tcl, Javascript, Lua and Erlang. Why to use DRAKON than other diagramming systems?

•No line intersections. You will never find in DRAKON diagram two or more lines intersecting each other! Not seen in other diagramming systems!

•Silhouette structure. It allows to break one diagram in to several logical parts. Not seen in other diagramming systems!

•No slanting or curved lines. Only straight lines with right angles.

•Icons are placed only on vertical lines.

•Branching is done in a simple, visible and consistent way.

•Each diagram has one entry and one exit.

DRAKON Editor homepage http://drakon-editor.sourceforge.net/

More about DRAKON here: http://en.wikipedia.org/wiki/DRAKON

Лучше всего вообще бы, конечно, чтобы обойтись без языка программирования в традиционном виде и человека-программиста как "слабого звена". Человеку, как известно, свойственно ошибаться. Лозунг: программирование без программистов!Когда априори правильная программа генерируется автоматические по спецификации логики управления - там, где это возможно.
Например, что-то вроде технологии ГРАФИТ-ФЛОКС, созданной в НПЦ АП имени Пилюгина.

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

Где это невозможно...
Си - один из худших вариантов с точки зрения возможностей, предоставленных программисту
по созданию ненадежного кода. Как пример использования более строгого языка могу привести опыт ОАО ИСС с Модулой-2

А лучше всего, я думаю, несколько надёжных слоев...Доверять на 99,999% можно только той системе, которая организована компонентно и послойно - и каждый слой обозрим и надёжен, собирается на основе возможностей нижележащего

Нужны ли блок-схемы? Альтернативы

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

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

Появляются подозрения, что система образования прогнила ...
аналогичная проблема наблюдается и за рубежом. ... Там же производится множество программ для выполнения этих самых схем - Dia, MS Visio, yEd, а значит списывать их не собираются. Вместо блок-схем иногда применяют диаграммы деятельности UML [7], однако удобнее они оказываются, разве что при изображении параллельных алгоритмов.

Периодически поднимается вопрос о том, что ни блок-схемы, ни UML не нужны, ...

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

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

--------------

9. Визуальный язык ДРАКОН \ http://drakon.su/

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

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

Даже само название занудное. Я предупреждал.
Но, блин, он работает!
Инженер, разрабатывающий ПО для управления своим механизмом КОДА вообще не видит. Видит только драконовсткие схемы, в деталях и без ошибок (однозначно), описывающие алгоритмы. Но выдать код для прошивки того же контроллера AVR дракон способен, с привлечением внешних программ.

Но я понимаю, самодельные велосипеды — зло. Нужно развиваться. Всё с большим уважением смотрю на язык ДРАКОН:
https://ru.wikipedia.org/wiki/ДРАКОН

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

Вот учебник:
http://drakon.pbworks.com/w/page/18205516/FrontPage

А здесь свободный редактор на языке tcl (которым я пока не пользовался):
http://drakon-editor.sourceforge.net/

Если уж и рассматривать графические кодогенераторы, то Дракон (вместе со всей его философией и методологией).

Его можно прикрутить к любому языку программирования и архитектуре.

ура! наконец-то в этой теме поставлена жирная точка! ))))))

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

Беккер Д.А., зав. лабораторией кафедры КДиП
ФГБОУ ВПО «Московский государственный строительный университет»

Был в 80-х такой весёлый язык программирования - "ДРАКОН". Суть - можно тупо рисовать блок-схемы ("ДРужелюбный Алгоритмический Конструктор, Обеспечивающий Наглядность", как-то так) и показывать бухгалтерам и насяльникам (даже если те - неизлечимые самодуры). Обидно за язык. Его ведь наши для Бурана-Энергии специально создали, состряпали, а потом - БАЦ! - и снова заставляют выводить странные закорючки.
Эх.
Сейчас бы 3D в программирование для всех этих regexp-ов и прочих "{ }" и "=()="

Суп. Почитал я про ДРАКОН и понял - еще не было оно тортом. Сорри. Там только возможность рисовать блоксхемы вмесо спецсимволов, но операторы всё ещё нужны... быди.

Не взлетит. ДРАКОН, IEC 61131 и т.д. делались не для продвижения методов разработки вперед. Их цель создать инструмент, которым могут пользоваться люди не обладающие навыками программирования, но знакомые с некоторой системой формального описания
В свой области они дают значительные преимущества: 50 инженеров-электриков рисующие ladder diagram'ы, вместо 50 инженеров пытающихся объяснить 5 кодомакакам (которые в первый раз в жизни видят реле), что им надо посчитать. Но как инструмент программирования общего пользования такие графические системы - обычно днище абсолютное

преимущества: 50 инженеров-электриков рисующие ladder diagram'ы, вместо 50 инженеров пытающихся объяснить 5 кодомакакам (которые в первый раз в жизни видят реле), что им надо посчитать
Если так, то, да, преимущества на лицо. Но уже и многие кодомакаки своими мозгами дошли до того, что лучше иметь знания не только в области кодописания, но и в той, для которой ты этот код собираешься писать. И если хоть один из тех пятидесяти инженеров знает хотя бы JavaScript или какой-нибудь Basic на начальном уровне — им уже не будут нужны ни пятёрка узкопрофильных кодомакак, ни ДРАКОН, ни 3D в программировании.
И, по моему, всё же, писать значительно проще, чем рисовать схемы.